Re: Inventory Month End Close

[MacWheel99@xxxxxxx]

I hope this reply is not too long 

>  From:    bcollett@tokheim.com (Ben Colletti)
>  
>  We are using version 6.1, client server, on an AS400.  
We are BPCS 405 CD Mixed Mode on AS/400 V4R3 @ security level 30
We have similar hassles.

> INV903 does not successfully complete. 
> When I ask out MIS manager why, he tells me that 
> there probably is someone on the system.  

We have also had failures related to the media that the inventory history is 
being off-loaded to ... I believe the architecture needs to be modified to a 
2 step process ...
1. Do 100% of the INV900 end-month except copy the old stuff to tape ... it 
would go to an intermediate on-line file.
2. Transcribe the intermediate file to tape, so that if that fails, you do 
not blow the whole INV900 update run, with a mess of recovery hassles.

> I have asked him to shut down the system to all users except myself 
> while this program is run but for some reason he can't figure out
>  how to do that.  

I believe that you may be asking the impossible of the wrong person - you 
should first be asking the CEO to insist that no one be allowed to sabotage 
end-of-month processing, but a compromise is possible - you can get 
"dedicated" access to BPCS files for INV900 if you rephrase what it is that 
you need ... there are several alternative ways to accomplish this.

(a) STOP *ALL SUB SYSTEMS command blanket kills everything that anyone is 
running on the system ... sign on sessions, jobq, printers, the works ... and 
prevents anyone else from signing on in the middle of INV900 or whatever you 
do not want them signing on in the middle of ... I normally run this as the 
second step of a backup ... my first step is WRKACTJOB F14 to see who is 
doing what right now to evaluate the consequences of me disrupting currently 
running BPCS jobs. 

At this point, the only place where anyone can do anything is at the MAIN 
CONSOLE ... I suggest an experiment ... the next time your MIS manager 
prepares the system for backup - you be there at the main console & see if 
you can get into BPCS from the main console, then try some other work station 
or connected PC & see if it can get into BPCS ... if in fact after all sub 
systems were stopped, you can get into BPCS from main console, while other 
connected addresses can not, then that is one possible approach ... you will 
need to know the password to get into a user-id that is authorized to STOP 
ALL SUB SYSTEMS & you will need to know how to RESTART THE SYSTEM when you 
are all finished to let other users resume normal connections.  

The act of starting BPCS from main console may re-start some of the 
sub-systems that impact whether other people at other sessions can get back 
in conflict with EOM, and since this is not a standard total system restart, 
some functions might not be working correctly.

Assuming your testing is satisfactory, ask the MIS manager to create a menu 
just for your needs, to use at the main console to both take the system down, 
and get it back to normalcy when EOM is completed.

Check out the options on IBM menu GO CMDSBS, many of which will be invisible 
unless you do it from a System Security Administrator sign-on.

(b) The hardware connections to the AS/400 can be individually varied off 
from WRKCFGSTS ... you may need special security access to *IO CONFIG

 ... you do not have to do them one by one ... you can do them in clusters, 
by varying off their controllers or communication lines, ethernet card, etc. 
and you can be doing this from any display station, not just the main console.

Now if someone is in the middle of doing something on a connection you are 
trying to vary off, the AS/400 will give you error message associated with 
this & so you have to kill their work session first via WRKACTJOB.  

While varied off, they cannot sign back on again UNLESS they have particular 
brands of PC connection software that can over-ride a central host vary off 
from the remote point (one of which we have) - so you have to know which PCs 
have that capability & make sure their operators KNOW what the management 
consequences will be if they conflict with end-of-month operations.  

A CL program could be written to automate some of this work, but I 
personnally prefer to try to know what a user is doing before I kill their 
session ... killing user work sessions can have dire consequences to the BPCS 
data base integrity.

> I'm not a techie but there must be a way that I can run this program 
> on a regular monthly basis and be assured that it will successfully 
complete.  
> Does anyone else out there have this problem and how can it be solved? 

(c) We do not do either of the above in their entirety. 

There is a MANAGEMENT ISSUE regarding END OF MONTH processing bigger than 
INV9 ... We do not want ANY USER doing ANY update work on BPCS after the EOM 
cut-off before the accounting department is finished ... we have a people 
process by which individual departments report to accounting "we are done 
with 100% transactions for the month" then accounting tells everyone "we have 
reached a particular check point ... EVERYONE PLEASE STAY OFF OF BPCS until 
we let you know that we are finished with EOM" ... the same kind of people 
communications process occurs when we do physical inventory.

Everybody who updates BPCS thoroughly understands this concept ... it is a 
standard employee educational process.  The only remaining problem for us are 
the random shop employees who need to use INV300 SFC300 BOM300 SFC350 etc. 
from the shop floor ... they don't know accounting process timing, they just 
know they need to check some information, right now ... so THEIR work 
stations & the controllers for same are the ONLY ones we vary off.

We use a fiscal calendar in which all EOM & EOY falls on a weekend, so the 
disruption to other departments work is minimalized.
 
Al Macintyre  ©¿©
http://www.cen-elec.com
MIS Manager, Programmer Analyst, Jack of All Trades, Master of None
+---
| 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
+---