QSYSOPR

1,675 pts.
Tags:
AS/400
iSeries
QSYSOPR
I Could see DSPMSG QSYSOPR is being cleared by some user everytime(Once in aDay intentionally),I would like to know,is there any way that we can track the user who deleted the logs from QSYSOPR. I appreciate you wise advice on this

Software/Hardware used:
V6R1
ASKED: September 28, 2012  3:11 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

To add to my above question….User (some one) typing DSPMSG QSYSOPR and taking option F16=Remove messages not needing a reply.

am able track the users who used DSPMSG QSYSOPR..but unable to find who took the option of F16 to clear the logs…??? 

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • qmaster
    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...
    1,675 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • ToddN2000
    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.
    6,360 pointsBadges:
    report
  • LetItBe
    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.
    260 pointsBadges:
    report
  • qmaster
    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.
    1,675 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • qmaster
    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..!
    1,675 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following