>>> On 10/2/2009 at 5:53 PM, in message <[email protected]>, Edward Jaffe <[email protected]> wrote: > Frank Swarbrick wrote: >> I am not a system programmer, but I am certainly trying to control my own > destiny. Which is why I am arguing for reasonable standards, or better yet > in this case, the ability to name my job what ever I want and not be forced > to some silly standard from the 1960's. So you are 100% right about it being > a management/political issue. If there is no technical reason for the > restriction then it seems to me there is no reason for the restriction at > all. Being a new z/OS shop I want things set up in ways that are good for > everyone (both systems and applications!), make sense, and not mired in the > past. Of course everyone will have their own opinion on what is best on why, > but "we've always done it that way" is generally not a good enough reason. >> > > I have personally not put my userid into a job name in nearly 25 years. > If I submit a job to compress a PDS, it's called "COMPRESS". That's what > makes sense to me. > > Before RACF, JES did not keep track of job ownership like it does today. > Job/spool security pretty much had to be based on job name. At least, it > was the most convenient method available in the 1960s and 1970s. That > was a long, long time ago. But, old habits die hard. > > (E)JES taught me the "hard" way that a VERY significant number--possibly > the vast majority--of JES2/SDSF installations still do job/spool > security by job name. And, most of them don't want to invest one iota of > extra time to convert from their arcane, jobname-based security scheme > to an elegant, modern, ownership-based standard--whether SAF or not. > Based on their requirements, we spent (IMHO too much) time adding job > name security functionality to make their conversions transparent. I > suspect IOF and the others have done similar things. > > [Aside: It's truly astonishing how many SDSF ISFPARMS specifications are > dedicated to masking all or part of the job name. If you took those > away, there would be almost nothing left!] > > It was painful adding code to (E)JES to support "security" that seems so > fragile and outdated... For a while, I felt like one of those guys > developing for MVS 3.8 on Hercules. A time warp! :-) > > It's not at all surprising to me that IBM completely dropped support for > ISFPARMS with SDSF for JES3 in z/OS 1.10.
Ed, you just made my day! Though I have no idea what ISFPARMS is, it sounds like that may be a good thing. :-) Anyway, it sounds like MVS has added many "modern" ideas, but many shops fail to utilize them. A shame. I understand that it doesn't always seem like the best way to spend time when "what we have works for us", but sometimes you have to at least reevaluate things, even if you end up changing little. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- 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
