Routing interactive jobs to subsystem

[Guest.Visitor]

I am trying to force a certain group of users to operate in a different subsystem. However, I can't do it with subsystem Workstation entries as they need to be able to do this from various workstations. I have given the user profiles a different JOBD to use, specified a different routing entry on that JOBD, created the new subsystem, and added the routing entry to the subsystem. The subsystem is sharing the same class as QINTER, being the QINTER class. I have also added the same new routing entry (at a lower sequence) to QPGMR subsystem in case the primary subsystem isn't operational, so that the jobs will still be separated. I have also created a JOBQ to be serviced by the new subsystem, with the same name as the subsystem. When I log on with one of the profiles, I get the correct JOBD, but I am running in QINTER. QINTER doesn't have the new routing entry, whereas both the new subsystem and QPGMR do. I confess that my understanding of routing entries and classes is very limited, but I thought that what I have done should work. Or is it too late by the time the sign on screen is displayed, and the only way to do it is via workstation entries or TFRJOB? Any ideas? Thanks in advance. Russell

[Guest.Visitor]

Russell, You are correct. Once the sign-on screen is displayed, you are already too late. OS/400 assigns interactive subsystems via workstation name/type entry. If you have more than one interactive subsystem with similar workstation entries, the results are unpredictable (as of OS/400 ver 3.2). If you want to assign subsystems by user-id, you could specify an initial program in the user-id where you specify a TFRJOB command pointing to a job queue attached to the desired interactive subsystem.

[David Abramowitz]

TTBOMK, what you are trying to accomplish may only be done through workstation entries. I have never heard of doing this any other way, , , , ,but.....keep trying, and let us know if you succeed, and how you did it! Dave

[G.Gaunt]

If you want to assign subsystems by user-id, you could specify an initial program in the user-id where you specify a TFRJOB command pointing to a job queue attached to the desired interactive subsystem. That could lock the job in an infinite loop, if the transfered-to subsystem's routing entry program (for example QCMD) executes the user profile's initial program as the routing step starts. Instead, try something like this in a QINTER common routing entry program:

 IF (&USER = 'TOM') (TFRJOB JOBQ(A)) IF (&USER = 'BOB') (TFRJOB JOBQ(B)) IF (&USER = 'SUE') (TFRJOB JOBQ(C)) RRTJOB RTGDTA(QCMDI)

[Guest.Visitor]

Gene, Could you expand a bit on your suggestion. I understand the bit you have posted, but what should I set up in the JOBD and the Profile? I would also like to make it not hard-coded, but RTVJOBA only returns the accounting code, and not the routing data. Is there any other attribute of the job or user that can be retrieved (and how) that could be used? I can use the accounting code at a pinch, but we have already used it for another purpose and it becomes a bit complicated. Thanks everyone for the responses, Russell

[Guest.Visitor]

My apologies! I should have checked first before opening my big mouth. I dug up my old programs and found this:

 PGM CHKOBJ OBJ(QTEMP/ONETIME) OBJTYPE(*DTAARA) MONMSG MSGID(CPF0000) EXEC(DO) CRTDTAARA DTAARA(QTEMP/ONETIME) + TYPE(*CHAR) LEN(1) TFRJOB JOBQ(QSYS/QCTL) ENDDO CHGJOB RUNPTY(8) CALL PGM(QCMD) ENDPGM 

This was an initial program for one of my security officer profiles. It was used for emergency situations such as run-away looping programs.

[G.Gaunt]

I'm sorry I was vague. Here is a way to route specific users into specific subsystems, regardless of workstation location. Suppose you've created a subsystem named BASEMENT, a job queue named SPEEDY, and you've attached SPEEDY into BASEMENT like this:

 ADDJOBQE SBSD(BASEMENT) JOBQ(SPEEDY)

Make up some string for routing data, say 'HELLO'. Enter this string into the routing data in job descriptions. Also enter a job queue name in the request data in the job descriptions, like this:

 CHGJOBD JOBD(ROOKIES) RTGDTA('HELLO') RQSDTA('SPEEDY')

Attach the job descriptions to user profiles like this:

 CHGUSRPRF USRPRF(GENE) JOBD(ROOKIES)

Create the following CL program, I'll call it TOP001CL:

 PGM DCL VAR(&JOBQUEUE) TYPE(*CHAR) LEN(10) RCVMSG PGMQ(*EXT) MSGTYPE(*RQS) MSG(&JOBQUEUE) TFRJOB JOBQ(&JOBQUEUE) ENDPGM

Add a new routing entry to the interactive subsystem of sign-on screens (e.g. QINTER) like this:

 ADDRTGE SBSD(QINTER) SEQNBR(100) CMPVAL('HELLO') PGM(TOP001CL)

Now when a user signs on, TOP001CL runs first. It retrieves the job queue name from the job description's request data, and then transfers the job to the appropriate subsystem. In the example above, when user GENE signs on, his job runs briefly in QINTER, and then transfers to BASEMENT. Later you can maintain the target subsystems of users through either CHGUSRPRF JOBD(###), or CHGJOBD RQSDTA(###).

[Guest.Visitor]

Gene, I am following your technique, as it gives me the flexibility I want. I have it working quite well, except for one minor flaw: Users who should be starting and staying in QINTER are ending up in my special subsystem I suspect that it is something to do with the Class (for want of anything else to suspect) or some other attribute of the SBSD that i haven't got set up right - they are definitely NOT going through the TFRJOB process, but are being directed to the subsystem by some other means. The routing entries for the special subsystem are as follows: font color=blue Opt Seq Nbr Program Library Compare Value Pos 20 QCMD QSYS 'MOVEX11' 1 40 QARDRIVE QSYS '525XTEST' 1 700 QCL QSYS 'QCMD38' 1 9999 QCMD QSYS *ANY /font The entries for QINTER are: font color=blue Opt Seq Nbr Program Library Compare Value Pos 10 QCMD QSYS 'QCMDI' 1 20 QCMD QSYS 'QS36MRT' 1 40 QARDRIVE QSYS '525XTEST' 1 90 JOBTFRCL CECPRDCP 'MOVEX11' 1 700 QCL QSYS 'QCMD38' 1 9999 QCMD QSYS *ANY /font Note that I have removed QCMDI from the special subsystem, as I knew that would cause a problem. Note also that the entries for QPGMR subsystem are : font color=blue Opt Seq Nbr Program Library Compare Value Pos 10 QARDRIVE QSYS '525XTEST' 1 20 QCMD QSYS 'QCMDB' 1 50 QCMD QSYS 'MOVEX11' 1 700 QCL QSYS 'QCMD38' 1 9999 QCMD QSYS *ANY /font and I don't have a problem with random logins to QPGMR. When I created the routing entry in QINTER for MOVEX11, I used class QINTER as I want this special subsystem to be an alternate QINTER. The routing entry is: font color=blue Routing entry sequence number . . . . . . . : 90 Program . . . . . . . . . . . . . . . . . . : JOBTFRCL Library . . . . . . . . . . . . . . . . . : CECPRDCP Class . . . . . . . . . . . . . . . . . . . : QINTER Library . . . . . . . . . . . . . . . . . : QGPL Maximum active routing steps . . . . . . . : *NOMAX Pool identifier . . . . . . . . . . . . . . : 1 Compare value . . . . . . . . . . . . . . . : 'MOVEX11' Compare start position . . . . . . . . . . : 1 /font So I am almost there, I just need to keep everyone else out. Any thoughts? Thanks, Russell

[Guest.Visitor]

Russell, When more than one interactive subsystem (with similar workstation name/type entries) is active, there is no guarantee as to which subsystem any given workstation will be attach to. Most likely some of your users got into your special subsystem because the workstation they signed-on to was already attached to your special subsystem. One remedy for this is to return the QCMDI routing entry with another program to direct them back to the QINTER jobq and subsystem.

[G.Gaunt]

Your 'MOVEX11' and 'QCMDI' routing entries in QINTER look okay to me. Give transfer-bound users a job description with RTGDTA('MOVEX11') and RQSDTA('job queue name'). Give QINTER-remaining users a job description with RTGDTA('QCMDI') and RQSDTA(*NONE). Your 'MOVEX11' routing entry in your special subsystem isn't necessary (unless you plan to link 'MOVEX11' to still another custom routing entry program yet to be written). To activate this second 'MOVEX11', specify RTGDTA('MOVEX11') instead of the default RTGDTA('QCMDI') in your TFRJOB command in your QINTER subsystem. But if you don't need a custom routing entry program in your special subsystem, use either a 'QCMDI' routing entry or a catch-all routing entry with 'SEQNBR(9999) CMPVAL(*ANY) PGM(QCMD)'.