Sv: Sv: CHGJOB - An Routing Entry Solution

Hi John
>Have you gotten this to work?  

Well, yes and no.

NO
--
No, because last time I was in charge of the actual running a mch, my users
didn't do that. It was just a matter of telling them what was good behaviour.
But I had another use of the routing entry/request processor: When compiling in
QPGMR with a 'compilation jobd' (but with the std SBMJOB from PDM) my
preprocessor analyzed the request-command, searched the source for 'compilation
instruction comments' and eventually modified the CRTxxx command. Worked fine,
did for example create reference files in the batchjob's QTEMP, modified
formtype (yes, we used preprinted forms at that time) and so on. I wrote an
artikle for NEWS to accompain my program, but it was never published. I can
send that + the program to you John or to midrange.com if any interest.

YES
---
Yes, because I just set it up (after your letter) on my own AS'er (where there
is no significant change from the Shipped V4R1).

QINTER has now a new routing entry: ADDRTGE SBSD(QINTER) SEQNBR(8888)
CMPVAL(QCMDB) PGM(TEST/QINTERBTCH) CLS(QGPL/QBATCH) where seq 8888 is after the
comparevalue QCMDI, but before *ANY (If you use QSYS38/SMBJOB it should
probably be before comparevalue QCMD38)

SBMJOB has the shipped default of RTGDTA(QCMDB). You could of cause consider to
change command default in some way to '*JOBD' for advanced use (not needed
here). Most IBM-jobd's have rtgdta QCMDB (but QINTER as shipped has NOT).

The request processor for seq 8888 in QINTER is quite simple:
PGM                                    
SNDMSG 'Violation of QINTER' *N *ALLACT
TFRJOB QBATCH                          
ENDPGM                                 

The TFRJOB has a default QCMDI, but in SBS(QBATCH) this falls in the same
*ANY-entry as normal batch programs. You could also modify the CLP - qualifying
TFRJOB to QCMDB, testing on TYPE from RTVJOBA or many other funny games.

This works fine for jobs submitted directly to or transferred into
JOBQ(QINTER).

REMEMBER: DO NEVER EVER CHANGE IBM-SUPPLIED OBJECTS 'BY HAND'. USE A CL-PROGRAM
('NEWREL') TO DO IT, UNLESS YOU ARE SHURE THAT NEXT RELEASE WILL NOT DESTROY
YOUR CHANGES.



Regards

Henrik Krebs

------------------------------------------------------------
Henrik Krebs
IT Consultant (IBM AS/400)
Phone +45 31 57 83 23
Mobile +45 40 88 83 23
Email: Henrik.Krebs@Scout.Net
Web: http://users.cybercity.dk/~dko3534
Snailmail: Amagerbrogade 62, 3-24, DK-2300 Copenhagen
------------------------------------------------------------

>John Earl <johnearl@lns400.com> wrote:

>Henrik,

>Have you gotten this to work?  It seems like it should, but I tried something
>similar a few years back and found that a user's JOBD supplied the routing
data
>both for their interactive job, as well as for any batch job they may submit. 
My
>investigations led me to conclude that unless you are programmatically
supplying a
>JOBD for the submitted job (and its different than the JOBD for the signed on
>user), routing data was not a good indication of whether the job was  batch or
>interactive.
>
>Did I mis-read the problem, or have you found another way to make this idea
work?
>
>TIA,

>jte


>Henrik Krebs wrote:

>> This seems to be the intended way (by IBM) to have an intelligent control
with
>> the problem:
>>
>> The DSPSBSD probably give you a picture like this:
>>
>> Seq Nbr    Program       Library       Compare Value
>>    10      QCMD          QSYS          'QCMDI'
>>    20      QCMD          QSYS          'QS36MRT'
>>    40      QARDRIVE      QSYS          '525XTEST'
>>   700      QCL           QSYS          'QCMD38'
>>  9999      QCMD          QSYS          *ANY
>>
>> The Batchjobs have (controlled by the JOBD) Routing Data of 'QCMDB', i.e. it
>> will hit seq# 9999. You can use CHGRTGE (or ADDRTGE seq 8888 Compare pos 1
to
>> 'QCMDB') to change the the program name to another requestprocessor. A
>> requestprocessor is nothing but a program that process the command(s) found
as
>> requestmessages in the jobs external messagequeue.
>
>> Example:
>   If needed: RCVMSG type *RQS from *EXT - remove it or not,
>     eventually modify it and send it back
>   Do something else (ending with a TFRJOB?)
>   Eventually execute the original QCMD-request-
>     processor: TFRCTL if you have not processed the command
>
> The program leaves many possibilities. What about:
>   IF (&JOBUSER *EQ 'ERIC') (CHGJOB RUNPTY(18))
>   ELSE (TFRJOB JOBQ(NIGHTSLOW))
> or
>   IF (&JOBUSER *NE 'ERIC') (+
>     SNDBRKMSG ('What ' *cat &JOBUSER *BCAT
>     'just has done is the reason...') *ALLACT)
>
> Regards
>
> Henrik Krebs

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---