RE: Automating month-end process

I am experiencing the same problem with automating monthend.  I think your 
"magic" that you refer to when replying to Dennis will help me.  The call to 
SYS664 looks like it can fix some of my problems.  Can you give me a sample of 
one of your LDA's, or a clue as to what to put in some of the obscure fields.  
I can fill in the basics, but I am lost on some of the other fields like YF1, 
YNUM, YTSB.

Thanks
Patricia
Patricia@lucks.com

-----Original Message-----
From: owner-bpcs-l@midrange.com On Behalf Of DAsmussen@aol.com
Sent: Friday, November 27, 1998 10:57 PM
To: BPCS-L@midrange.com
Subject: Re: Automating month-end process


Dennis,

In a message dated 98-11-25 12:37:36 EST, you write:

<<snip>>
I have some problems that need to be solved.
>  
>       1.- Getting a dedicated machine
>  *    I have CL written to "disable" user profiles and then "enable" them
>  when the process has finished


_WAY_ too much work here.  If you get the system properly dedicated, the user
profiles will be moot...

>  *    I have a daily backup routine that I run through the job scheduler
>  that restarts everything at 23:45.  It also stops IP from running so no
body
>  can get  an IP connection and run jobs       
>  *    What I have not solved is making sure that QBATCH does not have jobs
>  stacked up in the queue to execute after I have started the month-end
>  process.  WRKACTJOB does not have an outfile associated with it and that
>  really makes it tougher to get the info I need to cancel any jobs that are
>  running.  Because we are client/server, SNDBRKMSG does not work but is a
BMR
>  that I requested.  Who knows when an "E" BMR will get done.  I am guessing
>  that holding the QBATCH jobq would be the simplest answer.

Yes, HLDJOBQ QBATCH would be the easiest.  However, you'll still need to
determine if a job is running in _subsystem_ QBATCH, and I'm not sure of an
easy way to do that (unless WRKSBSJOB has an outfile option, but I'm not
signed on to be able to check).

>       2.- Getting the programs submitted 
>  *    I have a copy of the CL program SYSOVRC - that is what runs and it
>  shows(???) how the parms are put together.  Just have to interpret what it
>  does and then apply it to my situation.  Seems like a lot of "hard coding"
>  will occur and I just hate to do that.  Sooner or later that tends to bite
>  you bad.

You'll also need SYS003B, which actually starts SYSOVRC.  The only real
"magic" here is a call to SYS664 which establishes the LDA down to the binary
values that indicate that you have a valid license (see the FFD of file ZLDA).
Don't worry, SSA has already hard-coded these programs enough for everyone
;-)...

>  *    When you work with the SBMJOB command and are prompting for the
>  parameters, you have to key the 2nd one in hex and that does not give you
>  enough room to enter 512 hex characters.  I have keyed what I could and
then
>  looked at the source it created and then just added the necessary
characters
>  to get to 256.  

I'm not aware of any month-end programs that actually _need_ all 256 bytes
coded, although that doesn't mean that there aren't any.  If you have AS/Set
and can gen the code, look at the data structures in the *ENTRY PLIST to
determine what _needs_ to be passed.  Of course, if by "the second one" you
mean the second of three parameters, you'll have to key it all in -- a CL
program can help you with this and the trailing "X" is required in order for
the RPG to properly receive the third parameter.  If you have to work off the
joblogs for jobs submitted from the menu to get a PLIST, you don't need all
the blanks (x'40') at the end of the third parameter.  Many BPCS programs
don't use the third parameter at all (indicated by it being all blanks), in
which case the second wouldn't need the "X" at the end.

>       3.- Testing all these scenarios 
>  *    I do have a production machine and a test/dev machine.  We have only
>  been "live" since 8/1/98 and still have "major" problems to get corrected.
>  I spend most of my time working with other departments getting the "bugs"
>  worked out.  I also have a plan in place for getting 3 environments set up
>  on the test/dev machine where I can run through the month-end process till
I
>  have it working.  Very hard to do that on the production machine.

The test machine will help.  If your production machine has the available
DASD, it's actually fairly simple to establish another BPCS environment:
1.  Replicate libraries BPCSUSRF, BPCSUSR, and BPCSF (or whatever equivalent
you named them at your site) to new names like TESTUSRF, TESTUSR, and TESTF.
2.  Modify data area INLIBL in the appropriate "TEST" library to point at the
"TEST" libraries instead of the "BPCS" libraries.
3.  Modify data area SSASYS from position 170 for a length of 10 to point at
TESTF instead of BPCSF.
4.  Modify the BPCS job description in the test libraries to point at "TEST"
instead of "BPCS" libraries.
5.  Modify message L019301 in SSAZ03 and the "COMPANY" record in ZPAL01 to
indicate that you're in test instead of production.
6.  Modify any user tables/data areas that indicate library names to point at
the new libraries.
7.  Modify (line 30?) of BPCSMENU in TESTUSR/QCLSRC to point at the test
libraries instead of production and re-compile into TESTUSR.
8.  Call TESTUSR/BPCSMENU to access the new environment.

>  *    What happens now for month-end is another member of the
>  implementation team and I come back after hours (9:00 PM) and do
>  "EVERYTHING" manually.  New Years Eve I would prefer not to be at work
>  running month-end so I really have a strong desire to get this automated.
>  
>  I would like to hear what you have attempted and what your thoughts are.

At my last two sites, we merely created a small front-end program to call
SYS664 in order to establish the BPCS environment, and then submitted with the
three parameters via SYS003B.  We also modified SYS003B and SYSOVRC to _NOT_
reset LDA printer parameters based on the workstation data area or SSASYS to
provide greater printing flexibility (which SSA _REALLY_ needs to implement),
but this was not necessary for submitting jobs.  Unless you go the extra mile
to eliminate the need (we didn't at my last two sites), you will also need a
workstation data area with the same name as the submitted job.  Feel free to
write me directly if you have an specific questions about this note...

HTH!

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"If you hear a toilet flush followed by the words 'uh-oh', it's too late." --
Unknown Father of a Four-Year-Old
+---
| 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
+---

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