Re: Quickie Answer = Job Scheduler

more from Al Macintyre

The program I was working on is now running perfectly from the Job Scheduler,
and the exact same CL program will run on-line perfect, and I have got it
working for one warehouse, and I am now working on getting it for the others.
This experience has taught me some stuff.

1. If we have a menu option that some user wants placed on the scheduler - I
DO NOT WANT to be playing around with that CL figuring out how to make sure it
works on both the scheduler and on-line.  My current one has a whole bunch of
IF code conditioned on &TYPE - if on-line do this, if batch do that, then I
have to test the program in both scenarios & in the mean time if it is not
working perfectly, and a power user is participating in the testing, what
happens if the on-line version breaks & how do I distinguish between when it
is running on a batch because it came from an on-line vs. when it came from
job scheduler, whose users might not be following any naming convention?
Whatever the BPCS code is, I will clone (copy) to a similar name for purposes
of Job Scheduler version.

2. There is stuff I need to learn, style wise. so as to do this modifying more
productively.  

I would like to put some of the BPCS setups into a standard CL which is called
by the CL that is doing the actual work.   There are several BPCS jobs to get
at library list, security, override parameters etc.  I want to put the whole
lot in a CL that gets everything that is needed, then that CL would be called
by any Job Scheduler CL.

I also need to learn variations on how parameter passing works when we do not
want prompt screens in the job stream, but we do want to call vanilla BPCS
code whenever practical, that might happen to have prompt screens in their
streams. 

Robert Noey
> Are you aware of SYS664.  It sets up the local data area so that jobs may
>  run outside of BPCS.  The CL should include CALL PGM(SYS664)
PARM('SYS664').

Thanks - I found this RPG object.  Apparently SYS664 was new at 4.0.04
I did not find where its source was stored - I sometimes like to look at how
something works to add to my understanding - but sometimes security code is
hidden for security reasons.
 
Walter Schaff
>  You need to add a call to SYS664B.  It will set the LDA with the proper
>  security values to allow other programs to execute
>   CALL  SYS664B PARM('SYS664B')

We do not have that version on BPCS 405 CD - when I did WRKOBJ SYS66* I found
a bunch of 660 variants SYS662C and the single SYS664

Thanks also to the tips from Roger & Boris - I used a combination of your
suggestions & continuing on the line I was on of 

It failed - why did it fail - figure that out - fix it
re-test 3 ways - on-line, scheduler forced, scheduler timed release - redo
above from where I said "It failed"

I am still an OS/400 trainee.  I had looked at the Job Scheduler months ago &
decided it was still beyond my training, but since then I have been to some
IBM classes, so when a co-worker took a simple report of a menu - 

simple for users in that it was a Y2K conversion from S/36 code, with
parameters embedded in the job stream & one menu option for each facility
warehouse combination they might need - written before I learned DDS & now
many user prefer a menu option for a report with no prompt choices

anyhow this power user took the CL name off the menu & tried it on the job
scheduler then came to me for help, asking "Al, can you put a MONMSG at line
4300 to automatically reply with "I" because it runs Ok if we do that at
QSYSOPR"  Well I want to encourage power users who read 2nd level error
message text & make a strong effort to understand what that information
signifies, but when I looked at the earlier errors in the job log, it was
saying things like COPIES = a bunch of blanks was an invalid choice, so I
tackled it from perspective of 
1. It is not getting at the BPCS defaults
2. Why not
3. Let's plug in some ME defaults just in case

The vast majority of my users, when they get into any kind of trouble, stare
at the 1st level error clue & forget everything I ever told them about 2nd
level or other details easily accessible via a couple of key strokes.  Almost
all of our User Menus now have 999 for Sign-off & a close neighbor for Sign-
off with *LIST.  End user training does mention that if you have a problem
that we have not yet figured out how to fix, that doing the with *LIST will
provide clues for MIS is real constructive.  Very few users remember this on
the occasion of the next crisis, and some users take the *LIST every time they
sign-off.  Thus, I value my occasional power user.
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---