Re: BPCS and using the Sys Req Attn key.
"Alister Wm Macintyre \(Wow\)" <[email protected]>
| Newsgroups | gmane.comp.systems.as400.bpcs |
|---|---|
| Message-ID | <008701d24f58$c6fcd360$54f67a20$@com> |
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 -- This is the BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L-Zwy7GipZuJhWk0Htik3J/[email protected] To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request-Zwy7GipZuJhWk0Htik3J/[email protected] Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l.