Edward Jaffe notes: > As I stated, I've seen it done far more than I ever expected.
The problem, Ed, is that you expect (or at least hope for) mostly rational behavior, and you view such mechanisms as irrational and odd (because there are better, more appropriate, ways to do this). While I academically agree, I bet many such [remaining] practices are rooted in history, from a time when RACF (et al.) security control of access to SPOOLed SYSOUT data was simply not supported or a site didn't have an ESM to begin with. Paul Gilmartin remembers: > And as a user, I too have endured practices of bootleging > information to job processing components via the jobname, > simply because no other vehicle exists. I believe we have > test subsystems on which I still must adjust my jobname to > select a library tape subpool. Folks used existing knobs to control/enable desired function, and long ago there were insufficient knobs (particularly the concept of a JOB's so-called owner). So they used the knobs they knew they had at hand. JOB name was nothing more than a convenient knob, because little else was convenient/available. Edward Jaffe added: > Many JES2/SDSF shops control job/spool access primarily by > enforcing job name standards. It's pretty ugly... in response to Ted MacNEIL: > Welcome to 1980! > I know of nobody using jobname to protect access. As a software vendor, I can tell you authoritatively that this practice occurs at a significant plurality of customer sites. We frequently have to deal with customers who need a bit of help getting the "rules" right. They expect to be able to access certain output, and blame us when they can't. We hold their hands and help them understand the mess they are in, and figure out how to make it work for our products in their shop (at least on that particular day). Ed is right, it's pretty ugly. And more widespread that you would ever (rationally) expect. In fact, in the very early days of ESMs, back when ACF2 didn't even have a SAF interface (because SAF didn't yet exist or was still brand-new), instead of using the (still brand-new) USER= keyword parameter on the JOB statement (if it even was supported by the customer's current MVS/SP system), many installations used a feature of Top Secret to derive what TSS calls the ACID (what RACF calls the USER) from up to 8 characters selected by rule from fields such as the JOB name, Programmer Name, Accounting Information [sub]fields, etc. That practice continued at many TSS shops for years, and I recently shot a problem at a customer site where it's still the way things are done (~25 years later). Even for JES2 sites (who could use SDSF if they were desperate), RYO SPOOL browsers were common and used a variety of installation- specific knobs to control end (TSO) user access to SYSOUT data in both the distant and not-so-distant past. Stuff like this is hard for shops to change, much less give up. The reason I have little sympathy for them is that most of the pain is self-inflicted, especially since the cure is less costly than the continued hit on end user productivity. In the early 90s I remember being onsite at a large insurance company -- a TSS customer with very arcane rules for JOB and programmer names and accounting information field contents, all of which were used to construct the actual TSS ACID to be used. The rules were so restrictive that it was difficult for me to come up with much more than 20 different JOB names, much less mnemonic or suggestive ones. When I looked at the JOB queue, I typically saw dozens, even hundreds of identically-named JOBs. Picking up my own printouts at the remote printer was an exercise in snooping on everybody else's work, since the rules tended to make lowly programmers use JOB names that matched those submitted by other programmers. I was fighting not only the rules to get more than one of my JOBs to execute at the same time (an absolute requirement for a multi-address space product), but other programmers' JOBs as well. -- WB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
