Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

CL program to exclude special users from QINACTIV time-out doesn't work

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CL program to exclude special users from QINACTIV time-out doesn't work

    Hi, I've been reading and applying the CL program recommended to exclude selected users from timing out like the rest. First, I changed the QINACTMSGQ from *DSCJOB to message queue BREAKQUEUE. In the BREAKQUEUE message queue, I configured the DELIVERY option to *BREAK and the BREAK HANDLING PROGRAM to CLMONINA (I made minor customizations to the program). The problem is, no one got disconnected after they reached the time-out limit. And all the messages are queued in BREAKQUEUE. Is there some step that I have left out or did I do something wrong here? I would appreciate any assistance as I've been trying to figure a way of doing this for quite a while now. Thanks! Regards, Kendra

  • #2
    CL program to exclude special users from QINACTIV time-out doesn't work

    Kendra, Where did you get your CL example? Could you modify it to simply send you a message at different points in the program letting you know if it is even doing anything? I have not actually ever tried to code the program you are speaking of, but I have always intended to someday. Scott

    Comment


    • #3
      CL program to exclude special users from QINACTIV time-out doesn't work

      Your CL program CLMONINA needs to do a RCVMSG WAIT(*nomax) against the inactive message queue and check for message ID CPI1126 which is "Job &3/&2/&1 has not been active." Then extract out &3 job number, &2 user profile and &1 job name. If the user is someone that should be timed out then do an ENDJOB JOB(&3/&2/&1) or DSCJOB JOB(&3/&2/&1) at that point. Post your CL source in this thread if you need to. Chris

      Comment


      • #4
        CL program to exclude special users from QINACTIV time-out doesn't work

        Hi Chris and Scott, Thanks for your suggestions. I got the CL program from the IBM AS/400 Technical Support Site. As you can see, the program seems to have the right 'moves' and I still face the same problem. Appreciate further advice on this matter. Thanks! Regards, Kendra CL Program: PGM DCL &THEQUEUE *CHAR 20 /* QINACTMSGQ SYSTEM VALUE */ DCL &INACTLIB *CHAR 10 /* QUEUE'S LIBRARY */ DCL &INACTQUEUE *CHAR 10 /* QUEUE NAME */ DCL &INACTDATA *CHAR 100 /* RAW MESSAGE DATA */ DCL &JOBNAME *CHAR 10 /* INACTIVE JOB NAME */ DCL &USER *CHAR 10 /* INACTIVE JOB USER */ DCL &NUMBER *CHAR 6 /* INACTIVE JOB NUMBER */ DCL &MSGDTALEN *DEC (5 0) DCL &MSGID *CHAR 7 /* MESSAGE TAKEN FROM THE QUEUE*/ /* */ /* GET THE NAME OF THE QUEUE TO MONITOR FROM THE SYSTEM VALUE */ /* */ RTVSYSVAL SYSVAL(QINACTMSGQ) RTNVAR(&THEQUEUE) CHGVAR &INACTQUEUE %SUBSTRING(&THEQUEUE 1 10) CHGVAR &INACTLIB %SUBSTRING(&THEQUEUE 11 10) /* */ /* MAIN LOOP. */ /* */ LOOP: /* */ /* WAIT FOR MESSAGE ON THE MESSAGE QUEUE */ /* */ RCVMSG MSGQ(&INACTLIB/&INACTQUEUE) WAIT(*MAX) + MSGDTA(&INACTDATA) MSGDTALEN(&MSGDTALEN) + MSGID(&MSGID) /* */ /* CHECK TO SEE IF IT IS THE RIGHT MESSAGE, IF NOT, SKIP IT. */ /* */ IF (&MSGID *NE 'CPI1126') THEN(GOTO SKIP) CHGVAR &JOBNAME %SUBSTRING(&INACTDATA 1 10) /* GET JOB NAME */ CHGVAR &USER %SUBSTRING(&INACTDATA 11 10) /* GET USER NAME*/ CHGVAR &NUMBER %SUBSTRING(&INACTDATA 21 6) /* GET JOB NUM */ /* */ /* SPECIAL USERS */ /* */ IF (&USER *EQ 'SPUSR') THEN(GOTO SKIP) /* leave alone*/ /* */ /* DEFAULT ACTION */ /* */ ENDJOB JOB(&NUMBER/&USER/&JOBNAME) GOTO SKIP /* */ /* */ /* OTHER ACTIONS GO HERE */ /* */ SKIP: GOTO LOOP /* GO GET MORE MESSAGES ABOUT OTHER TERMINALS */ ENDPGM

        Comment


        • #5
          CL program to exclude special users from QINACTIV time-out doesn't work

          Kendra, Is your system value QINACTITV set to *NONE? I guess the answer to that question would be NO since messages are appearing in the message queue. Maybe the CL program needs to run under the adopted authority of a user profile that can use ENDJOB which I believe would be a user that has *JOBCTL authority. Change the program user profile to *OWNER and then change the object owner to a such a profile. Chris

          Comment


          • #6
            CL program to exclude special users from QINACTIV time-out doesn't work

            Kendra, I would suggest changing the delivery mode back to *Dft. I would also suggest droppping the break handling program specification. (Best thing might be to re-create the message queue.) The way we use the program here is that the message queue program is a "never-ending" program. The RcvMsg Wait(*nomax) logic will emulate what you are trying to do with the break handling stuff. Make these changes and let me know how it goes. Bill

            Comment


            • #7
              CL program to exclude special users from QINACTIV time-out doesn't work

              Chris, Thanks for your suggestions. Well, the QINACTIV value was set to 30 minutes all along. And the owner of the program has a QSECOFR authority which includes ENDJOB. Have you managed to successfully implement this into your environment? Can you list a step-by-step procedure how this program can be put in good working order? Perhaps there are steps that I have missed out on... With much appreciation, Kendra

              Comment


              • #8
                CL program to exclude special users from QINACTIV time-out doesn't work

                Kendra, Your CL program looks fine to me. I've not implemented this techique, only read about it. I configured the DELIVERY option to *BREAK and the BREAK HANDLING PROGRAM to CLMONINA. This part confuses me. As far as I know, you don't need to assign a break handling program to the msg queue. Just submit your CL program to batch and let it run like a never-ending-program. And, are you saying that no one got timed out and had his/her job ended or that the timeout took longer than expected? The system watchdog will only check for inactive jobs every "QINACTITV" minutes. So, if QINACTITV is set to 30 minutes and the system watchdog checks for inactive jobs and then CHEWK signs on, the next time the sysetm watchdog checks for inactive jobs, CHEWK will be at 29 minutes. The next time the system watch dog checks, CHWEK will be inactive for 59 minutes and THEN this job will be disconnected/ended. Maybe you can put this batch job in debug and see what happens when it actually gets executed. Chris

                Comment


                • #9
                  CL program to exclude special users from QINACTIV time-out doesn't work

                  Kendra, You might also want to add the following command: CLRMSGQ MSGQ(QINACTMSGQ) You should add it right before the processing loop. You don't want to have the program run through a lot of old messages. Bill

                  Comment


                  • #10
                    CL program to exclude special users from QINACTIV time-out doesn't work

                    Thanks for all your advice. The program finally worked! This is how I applied your suggestions : 1. Direct all the CPI1126 messages in the QINACTMSGQ to another user-defined message queue e.g. BREAKQUEUE. Put the DELIVERY method as *HOLD. 2. Add a batch job which calls the never-ending CLMONINA program. The CLMONINA will END (and not DSC) the jobs that have timed-out. This is because I received the error message 'DSCJOB is not allowed for Server jobs' when I put DSCJOB instead of ENDJOB in the CLMONINA program. And voila, it works! Thanks again. You have all been truly helpful Best regards, Kendra

                    Comment


                    • #11
                      CL program to exclude special users from QINACTIV time-out doesn't work

                      Kendra, It shouldn't be necessary to drop back to ending the jobs rather than disconnecting. You have a couple of options: 1. Add a MonMsg MsgID(cpf0000) after your DscJob command. This will allow any problematic disconnects to just be ignored. 2. Check the job information and pre-ignore those that will be a problem. Jobs like these server jobs you mention will probably have a user name of QUSER. So, just check the user name for this value and skip processing it. We use option 1 above, but you could enhance option 2 so that your program handles all of the current exceptions to your disconnect logic. Bill

                      Comment

                      Working...
                      X