Re: [SYS21] 31/ARE doens't run well in Machine Manager... -- SYSTEM21

You are correct Jeff.  I didn't consider this.  I'm man enough to own up.

Richard




Jeff_Klipa/Harvard@harvardind.com
Sent by: jbausers-l-bounces@midrange.com
01/24/2003 08:06 AM
Please respond to GEAC/JBA System 21 Users

 
        To:     CN=GEAC/O=JBA System 21 Users <jbausers-l@midrange.com>
        cc: 
        Subject:        [SYS21]   31/ARE doens't run well in Machine Manager...


My A/R person wanted to run the various permutations of 31/ARE Overdue 
Analysis
- in the night job...
I said sure, no problem...  I was her hero for a day...!!!  On the second 
day I
was a goat...!!!
How quickly we turn from hero to goat...!!!

Here's what happens when you run it from the menu...:

The task (SL/   /03/1230) is defined with an Interactive and Batch 
component.
Interactive Program to process request  . . SL407
Batch Program to process request (if any) . SL415CLP
Job Name (if Batch Program) . . . . . . . . SLOVRDUPAY
Initial Return Code for option  . . . . . . OP

When SL407 runs it stores the users selection criteria in a work file 
called
SLPWT.
It stamps the work record with Company/DateTime as the key and passes that 
key
to the Batch component of the task via the LDA.
257 2690L#SBMC is where the DateTime portion of that key is passed in the 
LDA...
The Batch component SL415CLP calls three programs...
SL408
SL409
SL415

Each of these programs uses the Company/DateTime key value passed in the 
LDA
from SL407.
This work record contains some essential data in order to make the report 
run
correctly without dumping...
Two such fields are:
OVRDWT         7  0 S  Overdue date  (This is the current date or report 
run
date)
ODPDWT        15    A  Overdue Periods (030060090120150) i.e. 
30,60,90,120,150
the overdue periods for the report...

So once the batch component finishes running successfully it dutifully 
deletes
the work record from the work file SLPWT...!!!
If you go and look in this file right now you should not find any records 
unless
someone has just submitted a job and is waiting for it to run...
Except that if someone submitted a 31/ARE job to run and it failed then 
this
work record will be left as evidence of that failure...!!!
Some of you may already see the problem but let me elaborate...

Here's what happens when you schedule this little beauty in Machine 
Manager...:

One of the really sweet features of Machine Manager is that it allows you 
to
schedule jobs to run whose tasks have an Interactive component defined.
(You cannot schedule a job that has NO Batch component...!!!)  In fact 
when you
schedule a task in MM that does have an Interactive program defined it 
actually
does a mock run of that Interactive program and requires you to enter the
desired criteria and then press F8 to mock-submit the job...!!!  MM then 
stores
your selection criteria and passes it along to the Batch component when 
the job
run time arrives.  That's all well and good - THE FIRST TIME IT RUNS...!!! 
 But
remember the DateTime key information stored in that work record in 
SLPWT...?!
Well after the first run that record is dutifully deleted from the work 
file
SLPWT...!!!  So the second night your scheduled 31/ARE report runs it 
falls over
quite ungracefully with 3 program dumps and a job log...  Each of the 
three
batch RPG programs dumps because the work record in SLPWT is missing... 
That
work record that is keyed on Company/DateTime, and which key information 
is also
passed in the LDA...!!!  But also remember that key information is now 
captured
and frozen in the MM record as well...  ever unchanging and completely 
useless
for automatically scheduling the 31/ARE report...

Now I don't want to get off on a rant here but please...!!!  Why in the 
world
would anyone design a report to run this way when you have such a 
wonderful tool
like Machine Manager that allows you to schedule these jobs to run on a 
regular
basis, after hours...!!!  The only reason I can think of is that the 
developer
never gave any thought to the concept of scheduling this report in the 
night
job...!!!

I did find a way to trick the MM jobs to run as scheduled...
First I captured the work records from SLPWT after I did the mock run of 
SL407
while scheduling the jobs to run in MM...
I stored those records in another work file where these records will never 
be
deleted...  I called it SLREPWRKXX.

Then I wrote a CL program with some SQL coding in it to change the date of 
the
OVRDWT field to the current date and then add these records back into the 
SLPWT
file...  I run this small CL from a custom task just before I run the 
31/ARE
reports in MM...  So the DateTime key info that is frozen in the MM 
scheduled
job records and the DateTime key info in the SLPWT work file will match 
when the
job runs in MM at night...  Every night, not just the first night...  That 
code
follows...  And if your file SLPWT is empty in the morning then your 
31/ARE
night jobs ran without fail...!!!

Now I'd rather not have to do this little work-around because when I'm 
gone my
replacement is not going to know what is going on with this little gem of 
a
mod...
Documentation only goes so far...  I'd like to see this option reworked so 
that
it can be scheduled in MM as part of standard product...  Thanks.

0001.00 
/*********************************************************************/
0002.00 /*   */
0003.00 /*     THIS PROGRAM LOADS SAVED SLPWT RECORDS FROM A FILE */
0004.00 /*     CALLED SLREPWRKXX BACK IN TO SLPWT SO THE NIGHT */
0005.00 /*     RUN OF 31/ARE Overdue analysis WILL WORK CORRECTLY...   */
0005.01 /*     NORMALLY THE SLPWT WORK FILE RECORDS ARE CREATED     */
0005.02 /*     FROM SL407 WHEN 31/ARE IS SUBMITTED...  ONCE THE JOB IS 
DONE  */
0005.03 /*     THE RECORD STORED IN SLPWT FOR THAT RUN IS DELETED... */
0005.04 /*     IN ORDER TO MAKE IT POSSIBLE TO SCHEDULE 31/ARE IN THE 
NIGHT  */
0005.05 /*     JOB YOU HAVE TO COPY THESE RECORDS OVER AND CHANGE THE 
DATES. */
0005.06 /*     YOU CAN CAPTURE THESE RECORDS FROM SLPWT AND STORE THEM */
0005.07 /*     IN SLREPWRKXX WHEN YOU FIRST ADD THE JOB TO MACHINE 
MANAGER.  */
0005.08 /*     IF YOU ADD/CHANGE/DELETE ANY 31/ARE JOBS IN MM YOU HAVE TO  
 */
0005.09 /*     ADD/CHANGE/DELETE THE CORRESPONDING RECORD IN SLREPWRKXX... 
  */
0005.10 /*   */
0006.00 /*     COMPILE THIS PGM WITH RUN-TIME RIGHTS OF *OWNER   */
0007.00 /*     ***********************************************   */
0018.00 /*   */
0019.00              PGM
0080.00 /*   */
0090.01 /* Define program specific variables */
0091.00              DCL        VAR(&IDAT) TYPE(*CHAR) LEN(7)
0098.00
0099.00              DCL        VAR(&SQL1) TYPE(*CHAR) LEN(150)
0100.00
0101.00              DCLF       FILE(SLREPWRKXX)
0104.01 /* Program Mainline Start   */
0105.00              RTVJOBA    CYMDDATE(&IDAT)
0122.00
0130.00 /* Update the Over Due Date for the Report with the current date 
and
store in OVRDWT */
0131.00              CHGVAR     VAR(&SQL1) VALUE('UPDATE SLREPWRKXX SET +
0131.01                           OVRDWT = '|| &IDAT || '  +
0131.02                           WHERE USERWT=''USERXXXX''')
0135.00
0136.00              RUNSQL     REQUEST(&SQL1)
0137.00
0138.00 /* Copy file from JBAMODSF/SLREPWRKXX to OSLF3/SLPWT *ADD ... */
0139.00              CPYF       FROMFILE(SLREPWRKXX) TOFILE(SLPWT) 
MBROPT(*ADD)
0153.00
0154.00 /* Program Mainline End   */
0155.00
0156.00                    RETURN
0173.00                    ENDPGM



_______________________________________________
This is the GEAC/JBA System 21 Users (JBAUSERS-L) mailing list
To post a message email: JBAUSERS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/jbausers-l
or email: JBAUSERS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/jbausers-l.