>>> On 6/25/2010 at 6:33 AM, in message <[email protected]>, "Shmuel Metz (Seymour J.)" <[email protected]> wrote: > In <[email protected]>, on 06/24/2010 > at 11:59 AM, Frank Swarbrick <[email protected]> said: > >>Now that we've been on z/OS for a few weeks I feel to need to ask a >>question that has annoyed me since I started working on z/OS two >>years ago. Instream datasets are good. Why are they not supported >>inside of procs? > > Because of the original implementation of the Reader/Interpreter in > OS/360. > >>Is there a technical reason, or is it just "because"? > > No; there's an economic and political reason; someone would have to > formally request it and provide a compelling business case. The same > applies to an option for substituting variables in instream data > sets[1]; it won't happen unless enough customers ask for it and > provide business cases. > >>We use procs for almost all of our production jobs, with many steps >>that could take advantage of instream datasets if not for this >>restriction. > > Is that sound configuration management? Are those data that you might > want to change without changing the JCL, or vice versa?
I don't see there being an disadvantage to changing instream data in a JCL PDS member versus changing it in a "parm" PDS member. Both have to go through the same change control to be implemented. I see using a "parm" library being useful only if more than one job is sharing the same parm data, or for use in our "operator controlled" parm library (which is not controlled by change control). But for most instream data, such as SORT control cards, it's simply a hassle. Not sure if my business case of "I just want it" is a compelling business case. :-) 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
