>>> On 10/2/2009 at 4:28 PM, in message <053f2631ec9c584883847c8b4970a22805058...@josqems1.jsq.bsg.ad.adp.com>, "Farley, Peter x23353" <[email protected]> wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Frank Swarbrick >> Sent: Friday, October 02, 2009 6:15 PM >> To: [email protected] >> Subject: Re: multiple jobs / same name > <Snipped> >> Still I find the use of having your user ID on it extremely limiting. >> Especially if your user ID is 7 characters! (At SHARE I noticed that >> Peter Van Dyke's user ID is VANDYKE. So he'd be really limited. And > is >> an 8 character user ID not allowed?) There are better ways to find > your >> output, so why limit yourself? If I submitted a large set of jobs and >> then wanted to look at the output and all I saw was FJS1, FJS2, FJS3, > etc; >> yikes! No good. Meaningful names are good. > > That's all well and good for system programmers who control their own > destiny. We application types have to live within the rules set for us, > and 7-character TSO userid's plus a requirement to use that userid as > the first part of your batch job names has been the rule in every large > application shop at which I ever worked. Whether that is technically > necessary is never the issue -- it's always a management/political > issue.
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. -- 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
