> -----Original Message-----
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick
> Sent: Thursday, June 24, 2010 1:00 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: instream data
> 
> 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
> 
> -- 
> 
> Frank Swarbrick

That has been a restriction since the dawn of OS/360. In that case, I think it 
was due to the primitive nature of the reader code. IIRC, the original reader 
code (pre HASP), read cards from the card reader. When it detected in-stream 
data, it actually created an "temporary" OS dataset and wrote the cards into 
that dataset. The processing of PROCs (expansion) was done in another part of 
the code, not in the actual reader. So, to have "in stream" data would require 
a more complicated and advanced expansion. And that was not really possible at 
the time.

To the best of my limited knowledge, JES2 still sort of works this way. JCL is 
read in and written to the job's JESJCL SPOOL dataset. Instream data causes the 
allocation of a separate SPOOL dataset, with the data being written to it. When 
th end of the instream data is detected, this "sysin" SPOOL dataset is close 
and JES resumes writing the JCL images to the JESJCL SPOOL dataset. Once the 
job is totally read in, JES2 invokes a z/OS supplied routine to convert the JCL 
to internal text. If instream data were allowed in a PROC, this converter would 
need to know how to process it and create/write it to the a new JES SPOOL 
dataset. Which it does not know how to do. IIRC, JES passes parameters to the 
converter so that it can read the JESJCL SPOOL dataset and write to the 
$INTTEXT SPOOL dataset. But the converter does not have an interface create and 
write to a "new" sysin type SPOOL dataset.

Of course, that is not really a good reason to continue to have this 
restriction, IMO.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

----------------------------------------------------------------------
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