Comments on: QSYSOPR

By: TomLiotta

TomLiotta — Fri, 01 Mar 2013 04:18:41 +0000

Yeah, that took some research to track down and to see how it might actually work. Keep in mind that a useful rule-of-thumb can be simply not to use IBM Q* objects for application activity. Things can be easier in the long run, especially when future app, or OS, changes need to be made. Everything from authorities to how they work can be affected. — Tom

By: qmaster

qmaster — Fri, 01 Mar 2013 02:07:25 +0000

Tom,Thanks for T/ZC tip..this would help to point on some one by checking time stamp.and I’ll see the possibility of change the Q to different App QThanks All..!

By: TomLiotta

TomLiotta — Thu, 28 Feb 2013 06:42:26 +0000

It’s easy enough to track changes to QSYSOPR. But it can lead to more potential problems. Tracking would be for changes; and that means every message added or removed, by any process in the system, would generate an audit entry. You can run CHGOBJAUD against QSYSOPR *MSGQ to audit *CHANGE actions.
Now, since only a couple people should have *DLT data authority for QSYSOPR, you actually only need to track a couple users. That means you could run CHGUSRAUD to set OBJAUD(*CHANGE) only for those profiles. Then run CHGOBJAUD OBJAUD(*CHANGE) for QSYSOPR. That would only send audit entries from QSYSOPR when one of those profiles removed (or sent) QSYSOPR messages.
The problem with that will be audit entries whenever one of those profiles changed any audited object. It’s possible that you aren’t doing any object auditing at all, so maybe that’s not a big deal.
What you’ll see is a T/ZC entry for every change event. Those that are for removing messages will have a ‘Type of access’ value of (38) for ‘Remove’.
A better choice would be to change your custom jobs not to send messages to QSYSOPR. Have them sent to a message queue created and intended for application messages.
Tom

By: qmaster

qmaster — Thu, 28 Feb 2013 02:16:24 +0000

Tom, Did you got any chance to look for tracking F16 option? If so,Please share it here..Even i too tried…but no luckThanks in Advance.

By: LetItBe

LetItBe — Fri, 28 Sep 2012 19:42:55 +0000

This is an interesting topic for me because we are working on “automating” the 2nd shift here and intend to use QSYSOPR message queue with robot software to monitor the nightly batch jobs. As I understand it at this point, any messages what we send to the QSYSOPR message queue requiring a reply will be “texted” to a cell phone by the programmer on call. We will want to see information messages of satisfactory completion at certain key points of processing. I guess we can use messages requiring a reply for those too, but would prefer not to have to reply “ok” or whatever or what should be routine successful completion messages. I don’t know how “application message queues” work with robot.Just thought I’d chime in with what we are working on – maybe gmaster has a similar use at his shop.

By: ToddN2000

ToddN2000 — Fri, 28 Sep 2012 15:34:18 +0000

If job completion messages are being sent to QSYSOPR then it should only be for the operations department. If an individual user need to know if a job finished send the message to their message queue as defined in their user profile. If there is more than 1 user that needs to be notified you can try sending a break message. If the messages are gone and you still want to know if a job finished then you can check the log. DSPLOG QHST. Send it to print and search the spoolfile.

By: TomLiotta

TomLiotta — Fri, 28 Sep 2012 11:11:07 +0000

It was probable that that was what was being done.

But QSYSOPR is not where such messages should go. QSYSOPR is an IBM profile message queue that should be used for system messages. Custom applications should log messages to application message queues.

But it’s understood that that isn’t always the way things go.

However, because QSYSOPR receives system messages, there should only a very few users who have authority to change QSYSOPR. It can hold messages indicating trouble, so only high-security or *SYSOPR users should be allowed to change it (to delete messages). And those users should be reliable enough to know not to clear QSYSOPR except under prescribed procedures.

If you’ve granted authority to many users and the authority is used, it becomes much more difficult to track. If there are only a couple users, you can usually just ask them not to do it any more.

But I’ll still try to track how F16 does its work, when I get the time.

Tom

By: qmaster

qmaster — Fri, 28 Sep 2012 08:10:55 +0000

Problem with Clearing off the QSYSOPR is, We have some customized jobs which will put some FYI kind of messages in QSYSOPR,by deleting these messages,we were not able to track the status of some batch jobs at ease. So,if we can find the Culprit user here ,we can warn him or restrict him in doing so…

By: TomLiotta

TomLiotta — Fri, 28 Sep 2012 07:06:52 +0000

There normally shouldn’t be much in QSYSOPR to care about, so clearing non-inquiry messages shouldn’t bother anyone. QSYSOPR isn’t intended for any significant “logging”. (And it’s cleared automatically at IPL which would mess up logging real good for sites that reboot overnight.)

But it’s an interesting question. I’ve not taken a detailed look at the effects of F16. A quick test shows that there’s a difference between it and simple deletion of messages. If I get time and uncover anything, I’ll try to add it here.

Maybe someone else has info. It’ll be interesting to see if anyone can post details.

Tom