Nedd Help with RCVMSG CL problem

[Guest.Visitor]

I have a CL program that calls a program that calls several other programs. Some of the programs are C programs and other more mysterious objects. When backup is running at night one of the programs is error out. I see a MCH5802 message in the job log: MCH5802 Escape 20 06/01/00 02:17:07 < ckMiObject 000CEC QDBCRTME QSYS 010C From Program . . . . . . . : RmsLockMiObject Message . . . . : Lock operation for object PRINTQUEUE not satisfied. Cause . . . . . : The lock operation was not satisfied for object PRINTQUEUE in the specified time interval of 30 seconds. CPF3222 Diagnostic 40 06/01/00 02:17:07 QDBCRTME QSYS 14D2 QC2SYS QSYS *STMT To module . . . . . . . . . : QC2SYS To procedure . . . . . . . : system Statement . . . . . . . . . : 6 Message . . . . : File PRINTQUEUE in library NETOVPRBT in use. Bla, bla, bla....I can not monitor for this message because it is not in the current call stack. I thought I could do a RCVMSG *LAST command to get it but the program must already be removed from the call stack. Is there a way other than reading through the job log to get this message so I can take appropriate action????

[B.Myrick]

Keith, Can you set this up as an automatic response for the Qsysopr message queue? Bret

[Guest.Visitor]

If you are on a RISC 400, do you know if any of the "more mysterious objects" came from CISC things? I seem to remember something like this in moving stuff from 3.2 to 4.x. bobh

[Guest.Visitor]

No, what is going on is the J.D. Edwards OneWorld software has a RUNUBE command that calls some AS/400 C programs. I don't think it is a CISC/RISC issue. thanks

[Guest.Visitor]

No, the message never hits QSYSOPR, what is happening is we are running the RUNUBE command which is J.D.Edwards program to call OneWorld UBEs (C programs). The machine check is issued an hits the job log but never hits Qsysopr. thanks

[B.Myrick]

Keith, Have you gone to www.jdedwards.com and reviewed the Knowlege Garden? I've always found that somewhat helpful. If you don't find the subject in a search, you can e-mail a question to open a call. Bret

[Guest.Visitor]

I have not done that yet, the thing is I understand why the JDE programs are error out due to the backup. I just wish I could figure out how to monitor for the message or receive it out of the job log so I can take appropriate action. thanks

[Guest.Visitor]

Perhaps there's another approach to the problem. I'm not familiar with JDE, but... Can you skip backing up that PRINTQUEUE file? If you're on a release that supports the OMITOBJ parm, your backup command could be something like SAVLIB LIB(*ALLUSR) DEV(TAPnn) OMITOBJ((NETOVPRBT/PRINTQUEUE *FILE)) Does this happen always, most of the time, sometimes? If a JDE application has a lock on the object, you could do WRKOBJLCK OBJ(NETOVPRBT/PRINTQUEUE) OBJTYPE(*FILE) and find out if it's locked, and what's locking it. If you know what's locking it, perhaps the application could be shut down while the backup runs; alternatively, the application could put an exclusive lock on PRINTQUEUE so the backup won't allocate it and cause the app to crash. I'm not familiar with Save While Active, but would that enable you to back up the object without locking it too long? "PRINTQUEUE" sounds like it would contain ephemeral data; could you somehow back up just the file object but not the data in it? Or do a separate SAVOBJ on it?

[Guest.Visitor]

I had a problem like this before. It was a message which could not be monitored but needs to be checked. Like you, I tried RCVMSG *LAST but without success. I solved it by running RCVMSG within a loop to search out the desired message-id: LOOP: RCVMSG PGMQ(*SAME) MSGQ(*PGMQ) MSGTYPE(*NEXT) + MSGKEY(*TOP) RMV(*YES) MSGDTA(&MSGDTA) MSGID(&MSGID) IF COND(&MSGID *EQ ' ') THEN(GOTO NOMSG) IF COND(&MSGID *EQ 'msg-id') THEN(GOTO FOUND) GOTO LOOP Hope this helps!