| Author |
Message
|
| jefflowrey |
 Posted: Thu Aug 25, 2005 5:49 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| Quote: |
| You could always reorder fields so that all comments came at the end of the one line... |
Jeff..perhaps I don't understand, but
| Code: |
| def ql(test) *comment |
isn't valid mqsc syntax |
Hrm. Should have doublechecked. So comments can only be on a line by themselves? You said "imbedded", so I thought something like
| Code: |
| def ql(test) *comment MAXMSGL(104897600) |
wasn't allowed. But you're saying that even
| Code: |
| def ql(TEST) MAXMSGL(104857600) *comment comment comment |
isn't allowed...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| hopsala |
| Posted: Thu Aug 25, 2005 7:42 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
| Code: |
def ql(TEST) MAXMSGL(104857600) *comment comment comment |
|
No this isn't allowed. I even made such experiments as "DEF QL(A) +*comment +MAXDEPTH(3)" or "DEF QL(A) MAXDEPTH(3) +*comment" - nothing works...
| wschutz wrote: |
| Perhaps, or what about the idea of allowing oneline AND filtering via parms for the "special cases" ie altdate and crdate/time? |
I don't see the point in you investing time coding all sorts of different filtering parameters if grep does it so efficiently. Putting it in one line gives maximum flexibility for all users.
Only users which seriously use the DESCR field (to which I see no reason why) will have a need for such a parm, I just don't think it's worth the effort. But hey, it's your time!  |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Aug 25, 2005 8:27 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
interesting discussion going on.
the original poster was already satisfied or found a solution, yet we continue discussing what 'else' can be done.
It was not clear to me why the original poster wanted this 'filtering', I guess he/she(?) wanted to take periodic 'snapshots' and find out if something changed in 'between' the time intervals?
Even if that were the case filtering on ALTDATE ALTTIME still gives a lot of confusion as for example xmit queues constantly change their ALTDATE ALTTIME every time a channel is started/stopped. I think it is the triggering causing this, so it may also apply to other triggered queues.
so you see a lot of changes when actually nothing changed.
I still feel that a (queryable) configuration audit trail inside MQ is really missing and hoped this would have been 'inherited' from the z/OS side in V6, but no luck...
If anyone is looking for an audit 'solution' taking snapshots at timed intervals and find changes to attributes of qmgrs / queues / channels / security settings etc...
<commercial_on>
the wheel is already invented and part of MQDocument.
<commercial_off>
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Aug 25, 2005 11:37 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
It was not clear to me why the original poster wanted this 'filtering', I guess he/she(?) wanted to take periodic 'snapshots' and find out if something changed in 'between' the time intervals?
|
If thats the case, then allowing a oneline format would be ideal:
1) take daily oneline backups via saveqmgr
2) use diff to see whats changed (if there is no altdate/time, then pesty things like trigger/notrigger being toggeled makes no difference).
Kupava...are you still there...is this what you really wanted to do?
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Aug 25, 2005 12:24 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
People get really get excellent service around here - even after they've solved the problem 
Imagine opening a pmr at IBM, a day later solving it by some workaround, and getting a call two weeks later with a new feature in the product!  |
|
| Back to top |
|
|
| bbburson |
| Posted: Thu Aug 25, 2005 12:48 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| hopsala wrote: |
Alors, a slightly odd but valid suggestion - what about putting ALTDATE in the DESCR field? I don't think most people use it anyway, and you could concat it to the end to preserve their text. |
NO NO NO -- don't mess with any field values. We *DO* use the DESCR field to tell our support group who to call if a queue is not being read.
Here's how I use saveqmgr:
-- run it with -s and -F to a temp file
-- grep out lines that start with * (comments) and lines that contain 'EV(' (where one of the event flags was enabled/disabled automatically as queues filled and emptied)
-- compare the resulting file with the previous version; if no difference toss today's copy and quit; otherwise save a few versions back
This runs nightly via cron (along with the supportpac to save authorizations), and has come in handy on several occasions when a queue manager needed to be rebuilt, moved to another machine, or cloned. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Aug 25, 2005 12:58 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
bbburson - I said *most* people don't use it, I didn't say anyone 
Besides, you won't have to use this one line option, I assume wschultz will supply it as a parameter and retain the default behavior as it always was - no skin off your back... But I guess it's all us to him. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 25, 2005 3:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
If IBM actually made the description field long enough to put, like, I dunno, a descent description there more people would use it! How I hoped that MQ 6.0 would expand this field to maybe 256 chars, so you could type up a little summary of the app, or put a link to a Intranet site that had info on the app, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Aug 25, 2005 4:55 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
I like the idea of a "-1" flag that produces the following output:
1. one DEFINE per line (and ALTER for the qmgr)
2. anything that is currently a comment is stripped out
So... if you want to see what changed, a simple "diff" will show you....
"-s" still supresses objects whose name begins with SYSTEM* (including the qmgr ALTER statement).
-F and -f are now equivalent (since -F supressed certain comments anyways)
A little research (with strace) indicates that runmqsc doesn't have a problem with long (ie >1024 bytes) lines, so there is no problem there.
Don't worry, no fields (including DESCR) will be hurt or injured ....
Any comments? any volunteers for beta?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 26, 2005 3:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| any volunteers for beta? |
I suppose it's only fair...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Aug 26, 2005 3:55 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I am not to fond of the -1 option...
currently saveqmgr output is "readable", can be put into documents "as is" and can be re-used for re-creation.
introducing the -1 for "diffing" purposes, still allows for re-creation to work,
but I would not like getting "documents" with one line mqsc commands...
as soon as an option is available, it will be used...
From another tool author's perspective... if you decided to add the -1 option, I would like some 'recognisable' marker at the beginning like "... created using the ONELINE option ..." or something so the file can be
processed differently then the original format.
So if you decide to build it, I'll be happy to test
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Aug 26, 2005 5:42 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| if you decided to add the -1 option |
I have
| Quote: |
| I would like some 'recognisable' marker at the beginning like "... created using the ONELINE option ..." |
I will
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 26, 2005 6:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Another thought about comments and ALTDATE is to include a duplicate entry for each record, that is purely a comment.
So
CREATE QUEUE(ABC)
*CREATE QUEUE(ABC) ALTDATE(...
Then ALTDATE/ALTTIME would be searchable, and the whole file would still be parsable by runmqsc...
But it's kinda ugly.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Aug 26, 2005 6:55 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
But it's kinda ugly.
|
agreed .... 
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 26, 2005 7:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But we're talking about simplifying things for machine processing.
Readability is not very important in this case.
In my opinion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
