Re: Sv: CHGJOB - An Routing Entry Solution -- MIDRANGE-L

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
>
> ------------------------------------------------------------
> 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
> ------------------------------------------------------------
>
>
>
> ----------
> Fra: Eric <Eric@norcov.com>
> Til: 'midrange-l@midrange.com'
> Emne: CHGJOB
> Dato: 2. juni 1998 19:00
>
> Recently users have discovered that they can move their batch jobs to
> QINTER.  This really degrades performance on an F35.  What is the best way
> to keep users from moving their jobs to QINTER yet still allowing them to
> move jobs to other jobqs.  Thanks in advance for any assistance.
>
> Eric Kempter
> Director of MIS
> Commair Mechanical Services
>
> +---
> | 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
> +---
> +---
> | 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
> +---





+---
| 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
+---