Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Thu Dec 11, 2003 7:09 am Post subject:
cobcurious,
INTRDR is an IBM-reserved name identifying the internal reader. The system places the output records for the internal reader into a buffer in your address space. When this buffer is full, JES places the contents on the spool; later, JES retrieves the new job from the spool.
Internal reader routines allow TSO jobs or application programs to submit job streams to JES3 using output data sets. When a job stream enters the system, data management assigns the data sets directly to an internal reader. If an internal reader is not available, the system dynamically creates one. When JES3 schedules the internal reader, input service can proceed to process the data set as an input stream.
As mentioned, an application program can create a job and pass it to the JES3 internal reader. To pass the job to the internal reader, the program must write the job to a data set for which SYSOUT=(class,INTRDR) has been specified. The internal reader reads the job, then gives it to JES3 where the job is processed like other reader-submitted jobs.
If the submitter of an internal reader job is either a TSO user or has an associated TSO userid, the TSO userid will be propagated to the submitted job.
To display a list of all the internal readers in the system at any one time, issue the *INQUIRY,A,D=INTRDR command. As the workload slows, input service will automatically terminate internal readers when they are no longer required. The operator can also stop the internal reader by issuing a *CANCEL,INTRDR or a *CANCEL,J=jobno command
Joined: 03 Dec 2002 Posts: 579 Topics: 1 Location: Iowa, USA
Posted: Fri Dec 12, 2003 9:02 am Post subject:
Similarly, in JES2, the internal readers can be displayed using the $DRDI command.
Also, there are 2 special JES2 readers - TSOINRDR to accept TSO session LOGON JCL and STCINRDR to accept started task START command JCL streams.
Hi ,
I thank you whole heartedly for the wonderful information.I want to know where does internal reader exactly fit in the processing cycle of a job ? We have to anyway run a job to process a program which "builds" the JCL ,it is obvious that the JCL which is "built" by the program is present at the output stage.Is it that the internal reader is present at the output phase of the job processing cycle which agains feeds the "built" jcl to the input phase ?
I would also like to know more on how to use internal
reader in CICS applications.Thank you again.
Regards
Itron
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Mon Dec 15, 2003 7:54 am Post subject:
cobcurious,
You are right that the Internal reader is present at the output phase of the job. The JCl is written into a file whose output destination is to the "internal" reader.When the dataset is closed and released, the system will "read" and process the contents just like any submitted job.
Code:
//OUTPUT DD SYSOUT=(,INTRDR)
You can use a TDQ which is a bit old technique of submitting batch jobs from CICS. Now CICS TS supports SPOOL OPEN/WRITE commands which directly submits job to JES. The advantage of using these commands are, no need of destination table definitions, no need of assingning TDQ in the CICS startup JCL to INTRDR etc.
you will find more information on INTDR in this topic
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum