Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
OS/390: internal reader
- Thread starter NewItron
- Start date
Hi Dimandja,
Can't remember why we did this at the site I was at. I have a feeling that the other way to do it in CICs needs a USER= and PASSWORD= fields in the jobcard, but I think that doing it through the internal reader this is not required.
Marc
Can't remember why we did this at the site I was at. I have a feeling that the other way to do it in CICs needs a USER= and PASSWORD= fields in the jobcard, but I think that doing it through the internal reader this is not required.
Marc
Hi Marc,
My understanding of the CICS internal reader was that it was the name of a TDQ used for that purpose. I'm not sure how the system knows to use that particular TDQ to submit to the JESQ. Maybe there's a special RDR proc that uses the TDQ as input. Anybody have any info?
BTW Marc, any news on the ISPF Macro?
Hi Itron,
The internal reader can also be used in batch pgms and utilities. In the JCL specify the O/P DD as:
SYSOUT=(,INTRDR)
When used in a pgm you usually write code to "build" the JCL and write it to the INTRDR. The JCL is then submitted to the JES I/P Queue. Not sure if that happens at CLOSE or at end of step or job. Probably CLOSE.
Hi D,
The advantage of using INTRDR to submit JCL is that you can customize it to reflect real time events. For example:
You have a pgm that must execute every day, but if certain conditions are present at the time of execution a special dataset must be used. To make things worse the name changes from execution to execution. The DNS is placed in a PDS member.
You can write a pgm to plop the DSN into the JCL and submit it to JES.
You might also be able to use utilities to get the DSN into the JCL and submit it.
Regards, Jack.
My understanding of the CICS internal reader was that it was the name of a TDQ used for that purpose. I'm not sure how the system knows to use that particular TDQ to submit to the JESQ. Maybe there's a special RDR proc that uses the TDQ as input. Anybody have any info?
BTW Marc, any news on the ISPF Macro?
Hi Itron,
The internal reader can also be used in batch pgms and utilities. In the JCL specify the O/P DD as:
SYSOUT=(,INTRDR)
When used in a pgm you usually write code to "build" the JCL and write it to the INTRDR. The JCL is then submitted to the JES I/P Queue. Not sure if that happens at CLOSE or at end of step or job. Probably CLOSE.
Hi D,
The advantage of using INTRDR to submit JCL is that you can customize it to reflect real time events. For example:
You have a pgm that must execute every day, but if certain conditions are present at the time of execution a special dataset must be used. To make things worse the name changes from execution to execution. The DNS is placed in a PDS member.
You can write a pgm to plop the DSN into the JCL and submit it to JES.
You might also be able to use utilities to get the DSN into the JCL and submit it.
Regards, Jack.
In the early days of IBM OS, a "reader" was a program that read JCL cards and submitted the job stream to the OS. That function was taken over by HASP or ASP, now know as JES2 and JES3, respectively. HASP (and ASP probably) added an internal reader, whereby a program could write JCL to be read by the reader.
In the early 70's, we had a function that required an unknown number of steps. Originally, the operater had to determine whether another step was required and load the JCL deck into the card reader. Later, we wrote a program that ran at the end of the job stream, determined whether another step was required and, if so, wrote the required JCL to an internal reader to start the next step.
In the early 70's, we had a function that required an unknown number of steps. Originally, the operater had to determine whether another step was required and load the JCL deck into the card reader. Later, we wrote a program that ran at the end of the job stream, determined whether another step was required and, if so, wrote the required JCL to an internal reader to start the next step.
Humm...interesting. Is it possible nowadays (on IBM) to for example:
1. Write JCL that has control flow logic. As in:
2. Have a program (COBOL) return/set a condition code upon termination. (The condition code should of course be retrievable by the JCL.) As in:
This type of thing is done routinely on many computers.
Dimandja
1. Write JCL that has control flow logic. As in:
Code:
RUN prog1
IF <good > THEN
RUN prog2
ELSE
<sound alarm AND/OR halt>
END-IF
Code:
READ file
IF <bad IO>
<set bad condition code AND/OR simply abend>
END-IFThis type of thing is done routinely on many computers.
Dimandja
In our shop we have an IMS on-line program which when given a specific command on-line, will write the necessary JCL to the internal reader with parameters entered on-line to be executed. Basically, the user online can request this job to be run anytime they need it simply by filling out the variable parameters on a screen and it will be submitted to the internal reader for processing.
With scheduling systems, trigger datasets and the like, you do not see the internal reader used much however, some of the old code is still around and is still being used.
etom
With scheduling systems, trigger datasets and the like, you do not see the internal reader used much however, some of the old code is still around and is still being used.
etom
One of the things that the internal reader allowed us to do was to bypass the number of job steps limit in the JCL that existed back then. There may be a larger or no limit today.
Of course, JCL is now much more powerful, as Dimandja pointed out. But it cannot communicate with an online user as in the case described by etom, so there is still a use for the internal reader.
Of course, JCL is now much more powerful, as Dimandja pointed out. But it cannot communicate with an online user as in the case described by etom, so there is still a use for the internal reader.
Hi D,
Yep. Except for the bell ringing, JCL can do what you mentioned. One could write a utility to ring the bell, though.
I fogot to mention in my previous post that a typical use of the INTRDR in CICS was to produce a batch report upon request from a terminal user. This obviates the need for printers specifically allocated to CICS and allows all CICS users to get hard copy reports even when they don't "own" a printer. A big money saver.
A typical approach to submitting jobs via INTRDR is to store a proc in proclib and then write the job card, the proc exec card with symbolic params, and optionally override DD stmts. The proc, hopefully, reduces the coding burden somewhat.
Current releases of CICS have a SPOOL cmd that is intended to replace INTRDR processing.
Regards, Jack.
Yep. Except for the bell ringing, JCL can do what you mentioned. One could write a utility to ring the bell, though.
I fogot to mention in my previous post that a typical use of the INTRDR in CICS was to produce a batch report upon request from a terminal user. This obviates the need for printers specifically allocated to CICS and allows all CICS users to get hard copy reports even when they don't "own" a printer. A big money saver.
A typical approach to submitting jobs via INTRDR is to store a proc in proclib and then write the job card, the proc exec card with symbolic params, and optionally override DD stmts. The proc, hopefully, reduces the coding burden somewhat.
Current releases of CICS have a SPOOL cmd that is intended to replace INTRDR processing.
Regards, Jack.
- Thread starter
- #11
Hi Everyone,
I thank all of you whole heartedly.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
I thank all of you whole heartedly.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
Hi Itron,
This link appears to be code of how to do it: This appears to be JCL showing how it's done: And this appears to be an article on CICs and the internal reader:
I hasten to add, that I've not read these in depth, but have just googled them.
Hope they are of some use.
Marc
This link appears to be code of how to do it: This appears to be JCL showing how it's done: And this appears to be an article on CICs and the internal reader:
I hasten to add, that I've not read these in depth, but have just googled them.
Hope they are of some use.
Marc
TonyJollans
Programmer
Hi itsmemani,
Jobs submitted to JES carry instructions (CLASS, DISP, etc.) which tell JES what to do with them. This is true whether they are submitted from TSO or CICS or your own program or anywhere else. If you don't explicitly provide values then defaults are taken.
This is a COBOL forum so I'm not going to rush into a detailed explanation of how OS/390 and its various subsystems work. Can you be a bit more specific in your question; what, exactly, is it that you want to know?
Enjoy,
Tony
------------------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading FAQ222-2244 before you ask a question.
Jobs submitted to JES carry instructions (CLASS, DISP, etc.) which tell JES what to do with them. This is true whether they are submitted from TSO or CICS or your own program or anywhere else. If you don't explicitly provide values then defaults are taken.
This is a COBOL forum so I'm not going to rush into a detailed explanation of how OS/390 and its various subsystems work. Can you be a bit more specific in your question; what, exactly, is it that you want to know?
Enjoy,
Tony
------------------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading FAQ222-2244 before you ask a question.
Hi itsmemani,
I don't know all the specifics, but most (all?) Job JCL is read by special cataloged procedures that invoke a "reader" that reads the JCL from a source pointed to in the proc and puts it on the JES input or hold Queue. From there it's processed like any other job.
How the system recognizes that a DD contains the INTRDR designation and how it invokes the proc is a matter of the system's logic. Don't know what that is.
Regards, Jack.
I don't know all the specifics, but most (all?) Job JCL is read by special cataloged procedures that invoke a "reader" that reads the JCL from a source pointed to in the proc and puts it on the JES input or hold Queue. From there it's processed like any other job.
How the system recognizes that a DD contains the INTRDR designation and how it invokes the proc is a matter of the system's logic. Don't know what that is.
Regards, Jack.
TonyJollans
Programmer
Hi itsmemani,
The purpose of the Internal Reader is, simply, to present JES with jobstreams for processing. It is a software substitute for a physical Card (or tape) Reader. These days most places don't have cards, and virtually every job is submitted for running via the Internal Reader; OS/390, for example, uses it to run STCs and TSUs.
Again, simply, the steps that take place are:
* Your job is written to a SYSOUT (logical) device.
* At some point (either when it is closed, or when otherwise instructed) the data on this device is passed to the Internal Reader. If not otherwise specified the authority (userid, etc.) of the outputting process is inherited at this point.
* The Internal Reader spools the job(s) and JES 'disposes' of them according to specified or defaulted dispositions.
* When appropriate Initiators are available, JES releases the jobs to be run.
I'm still not entirely sure what you're trying to find out, and how much of that you would consider 'submission'.
I don't know if this helps but consider the internal reader as a card reader and a SYSOUT device with CLASS=(,INTRDR) as a card punch; when the cards have been punched and a suitable instruction issued to an operator, (s)he moves them to the reader, from where they are processed like any other deck of cards.
Enjoy,
Tony
------------------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading FAQ222-2244 before you ask a question.
The purpose of the Internal Reader is, simply, to present JES with jobstreams for processing. It is a software substitute for a physical Card (or tape) Reader. These days most places don't have cards, and virtually every job is submitted for running via the Internal Reader; OS/390, for example, uses it to run STCs and TSUs.
Again, simply, the steps that take place are:
* Your job is written to a SYSOUT (logical) device.
* At some point (either when it is closed, or when otherwise instructed) the data on this device is passed to the Internal Reader. If not otherwise specified the authority (userid, etc.) of the outputting process is inherited at this point.
* The Internal Reader spools the job(s) and JES 'disposes' of them according to specified or defaulted dispositions.
* When appropriate Initiators are available, JES releases the jobs to be run.
I'm still not entirely sure what you're trying to find out, and how much of that you would consider 'submission'.
I don't know if this helps but consider the internal reader as a card reader and a SYSOUT device with CLASS=(,INTRDR) as a card punch; when the cards have been punched and a suitable instruction issued to an operator, (s)he moves them to the reader, from where they are processed like any other deck of cards.
Enjoy,
Tony
------------------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading FAQ222-2244 before you ask a question.
To take a different slant on your ques #1, here's why you may want to use an INTRDR:
In CICS the typical use of an INTRDR is to produce voluminous reports in batch mode because producing them on-line may degrade overall CICS performance.
BTW, CICS has recently introduced a spool writing feature that performs this function and reportedly has additional features.
Using INTRDRs in a batch environment is usually prompted by the fact that some of the required JCL content is not known until a certain point in the system cycle or may change from run to run.
For example, some field or fields of a recently created/updated file may tell you what other file(s) you have to process or what program(s) you must run next. You can write a pgm to construct and submit the required JCL via INTRDR after you've looked at the file and determined what new file or pgm to use in the next job.
Depending on the decision(s) to be made and/or the algorithms involved, trying to do something like this through other means can be diffficult if not impossible.
Regards, Jack.
In CICS the typical use of an INTRDR is to produce voluminous reports in batch mode because producing them on-line may degrade overall CICS performance.
BTW, CICS has recently introduced a spool writing feature that performs this function and reportedly has additional features.
Using INTRDRs in a batch environment is usually prompted by the fact that some of the required JCL content is not known until a certain point in the system cycle or may change from run to run.
For example, some field or fields of a recently created/updated file may tell you what other file(s) you have to process or what program(s) you must run next. You can write a pgm to construct and submit the required JCL via INTRDR after you've looked at the file and determined what new file or pgm to use in the next job.
Depending on the decision(s) to be made and/or the algorithms involved, trying to do something like this through other means can be diffficult if not impossible.
Regards, Jack.
- Status
Similar threads
- Locked
- Question
- Locked
- Question