Re: Spool file forms handling "simulations"

>From Al Macintyre

I may not have a complete solution but partial assistance

I am answering this in 2 installments
this e-mail looks at the challenge from perspective of spool file pain in the 
butt generic resolution alternatives
other e-mail says WE HAVE DONE IT & here are the programs we done it in

>  From:    RickCarter@holley.com
>  
>  Mix mode 6.0.02 As400
    Mix mode 405 CD As/436

>  We currently have some custom mods to the pick and packing list programs
>  and with these mods are changes to the form type for these two print
>  documents.  We do centralized order entry but direct orders to differnent
>  shipping facilities based on the warehouse ID.  We have Jetforms software
>  that looks at the forms type for PICK or PACk and when it finds one of
>  these it directs the output for this document to the appropriate output
>  queue.  My problem is if I go back to vanilla BPCS, I want have the forms
>  type uniqueness for pick and pack so how can I direct these documents to
>  the appropriate facility without making custom changes to change the form
>  type.  Does BPCS have any kind of document handler file that will allow
>  something similiar.  One order entry person may enter orders to any
>  facility so changing workstation data area output queue want help here.
>  
>  Thanks

BPCS does have a forms handler at the user level, but it has some 
restrictions in which V6 may be more flexible than V4 - ie. our gripes at V4 
might not be relevant to V6.

How it works in general is that there is a global environment set of defaults 
regarding which job q our work will run off of, which spool file it will go 
to, what form length paper we use (in our case abbreviated green bar 68 lines 
@ 8 to inch on system printers & PC paper 8 x 11 in which some people want to 
print 8 to inch & some people want to print 6 to inch) how many copies of 
forms are desired whenever we print stuff, do we want our stuff automatically 
on hold, or just print 100% of our stuff.  There is a whole ton of variables.

Then each individual work station address can over-ride some of the defaults 
just for them & these defaults are in place for all reports generated until 
someone changes the defaults.  This can be done at the work station via a 
pop-up menu of system type options, and there is also an option at the system 
menu to review / adjust on behalf of work stations whose users are not folks 
who really understand all these variables.

We'd like to have more variables here than are provided.  But never the less 
it is a very powerful tool.  Our users tend to set their defaults & forget 
them, so that if we need different settings for different reports, it is easy 
to forget to reset the defaults, thus it is easier to set defaults to 
something like "put all my reports & JOBQ on hold" then I go to spool file to 
adjust / kill / release & similarly to JOBQ to alter run criteria then 
release, assuming end user understands what we doing.

This whole structure assumes that user-A is doing work for facility-A with 
departmental printer-A.  If in fact user-A is doing work whose output needs 
to go to facility printer-A B C D, then in practical terms the way to get 
that done is either:

Change the default values every time you switch your work effort between 
facilities - if your employees are like ours - this will get royally screwed 
up;

Put everything on hold, know how to manipulate the data manually & get it to 
the target printer - if your employees are like ours, there will be lots of 
griping;

Modify the CL like I describe later in this e-mail - I think this is the 
safest approach, except that the software in question is a bit of a nightmare 
to reverse engineer;

Use a multi-session work station in which the naming of the sessions is 
linked to the target --- at present we name our work stations according to 
department & a unique character for position on the cable thru e.g. BUY3 is 
session # 3 in the purchasing dept.  So possibly we could set up a work 
station called SHIP30F meaning physical device F in the shipping department 
in which by convention the session defaults will assume the output is going 
to the shipping printer in facility 30.

The user at device F would have at least one unique session for every 
facility served, and would be required to do the work for that facility on 
the corresponding session.

If your employees are like ours, this will get screwed up.

We also have a mixture of centralized personnel who work on applications 
globally & work in distant cities whose output needs to get to their 
printers.   A related issue is the generation of queries & BPCS reports in 
which it is not obvious on spool file which is which from a variety of 
selection criteria.

The spool variables includes something called USER-FIELD which is I think 8 
bytes & we have been modifying CL to plug in a value here to identify what 
generated it, in the case of Queries, 
or values from the prompt screen, in the case of BPCS reports.
In some cases I use concatenation to assemble several variables for that 
information field.

My memory says the form-id field is 8 characters long.  It can also be 
over-ridden by a CL line just before the program that actually outputs a 
print-out.

We are a mid sized company able to number our facilities 
20 30 40 50
Warehouses in facility 20 are 21 22 23 24 25 26 27 28 29 where the last digit 
is the item type - 1 warehouse for work-in-process, end-items for shipping, 
raw materials returned, QC rejects & so forth
The number system is consistent corporate wide

If I was in your boat, I would want the form type to be something like PACK20 
for facility 20 or PACK21 for the warehouse of stuff ready to be shipped out 
of there.

At some point in the flow of data, the end user would presumably select the 
facility or warehouse that they are generating these shipping documents for & 
that variable should be capturable in the CL for concatenation into the form 
identification.

You would need to enforce with your people that if they want to do more than 
one facility, they exit the job stream between facilities.

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