AS/400 user ID which i do not want to be disconnected at all.

1160 pts.
Tags:
AS/400
AS/400 user administration
AS/400 user permissions
AS/400 user profiles
iSeries
I have a user id which i do not want to be disconnected at all. Is that possible since i have set a system value for QDSCJOB. All profiles need to be disconnected if not active for above 15 mins, therafter after another 30 mins the interactive job is ended. But i need this one profile which submits a long running batch job not to be disconnected rather ended too.

Software/Hardware used:
as400, v5r4, i570

Answer Wiki

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

I must be missing something in your explaination.
How can an interactive job submit something if it is inactive?
A user would have to initiate the SBMJOB.
Can you give us more information on exactly what you are trying to do.
Then we can suggest a solution.

Discuss This Question: 8  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
    If you don't want the job to be disconnected, then don't disconnect it. ...i have set a system value for QDSCJOB. There is no such system value. The QDSCJOBITV system value only determines how long a job will remain in disconnected status after you disconnect it. The QINACTITV and QINACTMSGQ system values determine whether the system will automatically place a job in disconnected status. If you don't want that job to be disconnected, then the QINACTMSGQ system value is where you make that decision. You set a message queue in QINACTMSGQ and process the messages to choose the action. But your question is confusing. It's not clear what you need to do. A submitted job is not affected by disconnecting nor ending the job that submitted it. What is the problem? Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    In brief the QINACTITV and QINACTMSGQ is system value, which runs for all users working on the system. I dont want it to work on a specific user id. ie i do not want the QINACTMSGQ system value to take action on a specific user id. Is that possible.
    1,160 pointsBadges:
    report
  • TomLiotta
    In brief the QINACTITV and QINACTMSGQ is system value, which runs for all users working on the system. That's right. But the message queue in the QINACTMSGQ system is just a message queue. It doesn't matter if the system sends a message there for all users or just one user. Nothing will happen to the jobs just because a message is sent. But that's just the beginning. Now, if you have a program that receives those messages, the program can make any decisions that you code into that program. The program can decide to disconnect each job until it sees a message for the user that you want to leave alone. For that user, the program can choose not to disconnect. Here is some example code that does just about the minimum processing. First is a controlling program:
    pgm
    
       clrmsgq    QGPL/INACT
       chgmsgq    QGPL/INACT  dlvry( *BREAK ) pgm( mylib/MYBRKPGM )
    
       dountil  ( 1 *eq 0 )
          dlyjob     600
       enddo
    
       return
    
    endpgm
    You would set an interval in QINACTITV. You would also set the name of a message queue in QINACTMSGQ. The example program expects a message queue named INACT in QGPL, but you can create any message queue and use that name instead. The program starts by clearing any old messages off of the queue. It then assigns a "break handling" program to handle any new messages that arrive on the queue. Finally, it simply goes into an unending loop. It will stay in the loop until you cancel the job. You can use any kind of loop that you prefer. Normally I would have the program wait on a data queue, and I'd tell the program to end by sending a special entry to the data queue. As long as the job has the message queue set in *BREAK mode, the break-handling program will be automatically called whenever a new message arrives on the queue. Here is an example of such a program:
    pgm   ( &MSGQ &MSGQLIB &MSGMRK )
    
       dcl   &MSGQ        *char   10
       dcl   &MSGQLIB     *char   10
       dcl   &MSGMRK      *char    4
       dcl   &MSGID       *char    7
       dcl   &MSGDTA      *char   80
       dcl   &job         *char   10
       dcl   &jobuser     *char   10
       dcl   &jobnbr      *char    6
    
       rcvmsg      msgq( &MSGQLIB/&MSGQ ) msgkey( &MSGMRK ) +
                     rmv( *NO ) msgdta( &MSGDTA ) +
                     msgid( &MSGID )
    
     /*  This program monitors for inactivity. When detected, the user  */
     /*  of the job is checked to see if the job should be ended...     */
    
       dowhile   ( &MSGID *ne '       ' )
    
          if ( &MSGID = 'CPI1126' )  do
             chgvar   &job              %sst( &MSGDTA  1 10 )
             chgvar   &jobuser          %sst( &MSGDTA 11 10 )
             chgvar   &jobnbr           %sst( &MSGDTA 21  6 )
             if ( &jobuser *ne 'MYPRF' )  do
                dscjob   &jobnbr/&jobuser/&job
                monmsg ( cpf1300 )         /* Ignore "Not found", etc.  */
             enddo
          enddo
    
          rmvmsg   msgq( &MSGQLIB/&MSGQ ) msgkey( &MSGMRK )
          monmsg ( cpf2400 )               /* Ignore "Not found", etc.  */
    
          rcvmsg   msgq( &MSGQLIB/&MSGQ )  +
                     msgtype( *FIRST )  +
                     rmv( *NO ) keyvar( &MSGMRK ) msgdta( &MSGDTA ) +
                     msgid( &MSGID )
    
       enddo
    
       return
    
    endpgm
    It will be called automatically when a new message is sent to the queue. Break-handling programs get three parms sent in -- the message queue name, the message queue library and a message key. The program uses the message key to receive the first available message. Various message attributes get placed into variables. Then the program enters a loop to ensure that all messages that might be stacked on the queue are handled. The loop ends when a blank message ID is returned. Inside the loop, some tests are done. The first test makes sure that CPI1126 is the message ID. (You might send other messages to cause other processing.) If it's a CPI1126, then some message data is extracted. In your case, an important piece would be the user ID. I put a test in there to test for one named "MYPRF". You would test for the user that you want to skip. In the example program, if the user is not equal ('*ne') to MYPRF, then the inactive job is disconnected. You could program it to take any action you choose. After that, the message is removed from the queue, the next message is received and loop begins again. So, the example uses the QINACTITV and QINACTMSGQ system values to get the system to send messages. You submit the controlling program to some job queue such as QSYSNOMAX. You could have it submitted by your startup program or by a job scheduler entry. You might even have it run as an autostart job for your interactive subsystem. And until that job is ended, inactive jobs are disconnected unless they belong to MYPRF. That's all there is to the programming and all there is to managing all of it in one of its simple forms. There are a lot of variations, but those are up to you. You know best how it should work in your system. Tom
    125,585 pointsBadges:
    report
  • Rayj1031
    Is the batch job submitted to the QINTER subsystem? Are you trying to prevent an interactive user from being disconnected? A CL program to do this can be found: http://www-01.ibm.com/support/docview.wss?uid=nas1ccd92ccc0c87bd60862565c2007d2aa7
    335 pointsBadges:
    report
  • TomLiotta
    The IBM example above is (like mine) just an example. It does have flaws. A particular flaw is that it doesn't have the message queue allocated during the time that it is processing one of the messages. That window of vulnerability is very small, especially with how little processing is done in the loop, unless some unusual circumstance causes a delay or some additional coding is added. However, the structure is simpler than my example; so it might make it easier to see what's happening with the inactivity process. It's a good introductory step. There are always alternatives. Tom
    125,585 pointsBadges:
    report
  • HMSSL2K
    We use the following CL PGM to take care of that problem, you will need to define CL variable. LOOP: RCVMSG MSGQ(QUSRSYS/INACTIVE) WAIT(*MAX) + MSGDTA(&INACTDATA) MSGDTALEN(&MSGDTALEN) + MSGID(&MSGID) IF COND(&MSGID *NE 'CPI1126') THEN(GOTO + CMDLBL(SKIP)) CHGVAR VAR(&JOBNAME) VALUE(%SUBSTRING(&INACTDATA 1 + 10)) CHGVAR VAR(&USER) VALUE(%SUBSTRING(&INACTDATA 11 10)) CHGVAR VAR(&NUMBER) VALUE(%SUBSTRING(&INACTDATA 21 6)) IF COND(%SST(&USER 1 6) *EQ 'E42143') THEN(GOTO + CMDLBL(SKIP)) IF COND(%SST(&USER 1 6) *EQ 'E15755') THEN(GOTO + CMDLBL(SKIP)) IF COND(%SST(&USER 1 6) *EQ 'E01025') THEN(GOTO + CMDLBL(SKIP)) IF COND(%SST(&JOBNAME 1 2) *EQ 'CC') THEN(GOTO + CMDLBL(SKIP)) IF COND(%SST(&JOBNAME 1 5) *EQ 'DSP01') + THEN(GOTO CMDLBL(SKIP)) ENDJOB JOB(&NUMBER/&USER/&JOBNAME) OPTION(*IMMED) + LOGLMT(0) ADLINTJOBS(*ALL) MONMSG MSGID(CPF1362 CPF135A CPF1321) GOTO CMDLBL(LOOP) ACTION1: SKIP: GOTO CMDLBL(LOOP) ENDPGM
    3,175 pointsBadges:
    report
  • TomLiotta
    ...to take care of that problem... To take care of which problem? The message queue is allocated while RCVMSG is running, but not after the command ends and the command after it begins. The MONMSG after ENDJOB is a necessary addition that reduces the window of vulnerability but doesn't eliminate it. For example, what if message ID CPF135D is sent out of ENDJOB? Or what if someone gets allocation of the message queue while one of the CHGVAR commands is running? (It's pretty easy to do for a selfish programmer who wants to stay outside of the inactivity rules.) Unless the program causes the message queue to be allocated for the duration, there is opportunity to hijack the queue and manipulate the program's actions. In the example that I posted, I used CHGMSGQ DLVRY(*BREAK) in the controller program to help set the status of the queue until the job ends. It's not much, but it can help. Actually, the whole process for both examples is fairly bare of protections; but this isn't really a critical function. This is merely usage of a basic 'free' system feature for general convenience tied to some example programming for receiving messages. The serious handling of the conditions takes much more coding. That's not different from any aspect of our jobs, though. Everything we do is a trade off between cost and return on investment. We can always make programs more bullet-proof, more flexible, more useful. But it always adds some to the cost. That's just life. Tom
    125,585 pointsBadges:
    report
  • HumaidM
    I'm looking for scheduling a job for automatic disabling of all user ID's inactive since 60 days?
    10 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