Steve,

That is, in fact, exactly what we have:
//PROC     DDAR02 PARMENV=PROD.APPLIB
//SORT     EXEC PGM=SORT
//DFSPARM  DD DSN=&PARMENV..PARM(DDAR021),
//            DISP=SHR                    

I simply would prefer to see:

//PROC     DDAR02
//SORT     EXEC PGM=SORT
//DFSPARM  DD *
 SORT FIELDS=(1,10,PD,A,   
              13,4,PD,A,   
              17,4,PD,A,   
              11,2,PD,A),  
              EQUALS       

Someone here did write a nice PEEK command where we type PEEK on the command 
line and put our cursor on the DD statement and it will go to the correct 
library and pull up the member.  But instream still seems to me to be better.

Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 6/24/2010 at 12:46 PM, in message <4c23a807.8060...@trainersfriend.com>,
Steve Comstock <st...@trainersfriend.com> wrote:
> Mark Jacobs wrote:
>> On 06/24/10 13:59, Frank Swarbrick wrote:
>>> 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?  Is there a technical reason, or is it just "because"?  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.
>>>
>>> Thanks,
>>> Frank
>>>
>>>    
>> 
>> My WAG would be a combination of the two. There might have been a good 
>> technical reason why not and to change the rules 40+ years after the 
>> fact might break working processes in unexpected ways.
>> 
> 
> 'sFunny, I didn't see your original post, Frank. Are you not
> posting to list directly now?
> 
> Anyway, it is what it is. But a simple xxxxxx.PARMLIB with members that
> contain what you would put into instream data seems to work just fine,
> right? Out of curiosity, why do you consider instream data better than
> that?
> 

>>> 

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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to