Request processor (Was: RE: Running batch jobs in Qinter)

Tom:

I didn't use SBMJOB CMD() in this request processor. You are right, CMD is the 
same as RQSDTA with an added validation / prompt facility, and there's no need 
to distinguish here.

What the program did as far as I remember (in the initial form. A few more 
facilities were added later) was:

RCVMSG type RQS from *EXT.
Roughly interpreet the command, taking one of two routes:

Case 1 (A CRTxxx with a source member - typically created by option 14 in PDM):

1. Read the source for structured directives '*RQSB: xxxx',  '*RQSA: xxxx', 
'*PARM: xxxx') and remove trailing '*/' if any to find 'request Before', 
'request After' and additional parameters. As far as I remember it was possible 
to break theese commands into more 'lines' (messages) if they were terminated 
by a '+' - just like a CLProgram.

2. If any *RQSB, the xxx-part of this was send as requests to *EXT (SNDPGMMSG)

3. If any *PARM then theese parameters were added to the original request 
message if not there already (an exception: CRTCMD is always from PDM created 
with PGM(same as source member), so in this case I replaced this even if it is 
already in the request string.

4. Then this (eventually modified) string was send as requests to *EXT 
(SNDPGMMSG)

5. If any *RQSA, the xxx-part of this was send as requests to *EXT (SNDPGMMSG)

6. If the CRTxxx was a program create, then a final command was sent to *EXT to 
update the file with program references used to make xref inquiries (in-house 
command DSPCROSSREF)

7. If any changes to the job were done I also sent an *INFO to *EXT (SNDPGMMSG) 
to describe that I have changed the job

Case 1 (anything else):

Only step 4 above was done.

Finally a simple TFRCTL PGM(QCMD) and everything is back to normal as if the 
job came from SBMJOB or (in case that more request exists) STRDBRDR.

Back to the original tread: You could also in this program do a 'step 4' if 
this was a batch job in a subsystem ment for interactive jobs and then an 
TFRBCHJOB (after an 'abuse alarm' if wanted)

So, I do not use CMD() over RQSDTA(), I just talk about a string and give it 
the name 'command' because that is what it contains (and must contain if the 
program is QCMD). I have also seen a request processor that handled batchjobs 
for a general menu system that just had a parameter string here, no 'CALL' or 
such.

Regards

Henrik
http://hkrebs.dk/who.html



> Date: Thu, 12 Dec 2002 19:15:08 -0500
> From: qsrvbas@netscape.net (Tom Liotta)
> To: midrange-l@midrange.com
> Subject: RE: Running batch jobs in Qinter
> Reply-To: midrange-l@midrange.com
>
> Henrik:
>
> I too would prefer a routing program, though for the original question it p=
> robably doesn't need to do anything except retrieve the job type to see if =
> it's batch or interactive, end the job with an error message for batch jobs=
>  and TFRCTL to QCMD otherwise. No need to examine the *RQS message at all i=
> n this case.
>
> But in more robust cases such as yours, I'm curious about why you'd use CMD=
> () over RQSDTA(). I can understand why you'd avoid a length of 256, but a l=
> ength of 3000 is what RQSDTA() will accept as a maximum and CMD() must acco=
> mmodate the same length anyway, AFAIK.
>
> Tom Liotta
>
> midrange-l-request@midrange.com wrote:
>
> >   9. RE: Running batch jobs in Qinter (Henrik Krebs)
> >
> >
> >a better way to execute a command than using QCMDEXC is to re-send the 
>&RQSDTA
> >to *EXT type *RQS and give it over to original request processor by TFRCTL 
>to QCMD.
> >I used that once to do things to CRTxxx like processing in-source embedded
> >commands (OVRDBF before compile etc), build xref etc. In that way I manage
> > to be able to recompile entire production source files (a good guarantee
> >that your system is solid and source/object consistent).
> >
> >btw-1: VAR(&RQSDTA) LEN(256) will give you troubles. I often have use 
>commands
> --
> --
> Tom Liotta
> The PowerTech Group, Inc.