Thing-3
IBM OS and BPCS have many defaults, where things work various ways, that
sometimes can be a nuisance.
Consider the scenario of two different people using the same work station,
but they have different report management needs.
This is why some PC main Windows screens had more than one icon for
accessing BPCS . different icons for different application people.
Many defaults can be over-ridden, to reduce the nuisance value, but this
over-riding needs IT management policies, to avoid other nuisances.
When a new workstation-id first talks to BPCS, a work area is established,
which is a copy of the defaults for that environment.
We can both alter the environmental defaults, and we can also edit what the
rules are for any given work station session-id, to handle exceptions.
Unfortunately, the screen for editing this, also has environmental controls,
which we do not want people messing with, unless they are high powered
knowledgeable BPCS admins.
I suppose we could have cloned that software, and given end users access to
their printer defaults, while blocking access to the environmental controls.
It became left to IT to handle the editing of the BPCS work area which has
the printing rules for the work station session-ids.
So for example, there is one printer, designated the main, or system
printer, for the whole building.
We can set the default for reports to NOT print, but go on hold. This is
extremely helpful when many people have many reports.
We can adjust the printing sequence, then release a bunch for just one
person, or one department, so that they print together, and we do not have
reports for different people, intermingled in the batch which just walked
off.
We had a programming standard, except for some highly specialized forms like
Pos and other documents sent out of the company, that EVERY REPORT had in
the page headers: WHO generated this report, from what work station, date &
tme. This solved many problems, like when a reoort did not get where it
was supposed to go.
We can also cause the reports to be held again, after printing, so that in
case of accidents, we can still get that report.
People need to be taught how to kill their reports, when in fact they are
done with them.
People who work in other cities buildings, need to have their output go to a
printer in their building.
We also had departments, where we wanted 100% of the work from that
department, to go to the printer located in their part of the building.
We also had dummy spool files, not attached to any printer, to archive audit
trails which we wanted to be able to reference a while, and other reports we
did not want to delete right away, such as end fiscal reports. Different
dummies for different functions.
All of this could be managed by editing the BPCS work area, by work station
session-id, which had the printing rules.
IT had to run one of the *OUTFILE reports occasionally to identify what work
station names had joined the collection, and thus needed their printing
rules adjusted.
We also had a requirement, for all reports of certain kinds, directed to a
printer in a particular area, irrespective of whose session-id caused that
report.
Customer order acknowledgements to a printer in the customer service area.
Purchase orders to a printer in the Purchasing Manager's office.
Shop Order paperwork to a printer near the Production Management office.
Shipping paperwork to a printer in the Shipping / Receiving area.
The CL programs which generated those reports, could be modified.
1. The CL extracts the rules from the BPCS rules place, associated with
that work station session-id.
2. Our modification, substitutes the rules associated with the
designated printer, for that kind of paperwork.
Some CL generate multiple reports, where we might have different rules for
different ones . some special forms to go to the dept which manages those
reports, while some associated listings to a more general printer.
IT documentation, included some cheat sheets added to BPCSDOC.
This because sometimes, some dept decided to change the naming of the
workstation-id for THEIR printer.
If they did not notify IT promptly, this could break software trying to send
output to a printer-id which no longer existed.
There was also an IBM OS idiosyncrasy associated with old fashioned smart
devices on twinax, where we needed to do an extra power down up on the IBM
box, because the auto config did not work to our satisfaction.
Alister Wm Macintyre (Al Mac)
Panama Papers group:
https://www.linkedin.com/groups/8508998
midrange.com
