Re: INTRDR and submitted JobID
On Thu, 15 Oct 2020 11:17:45 -0500, Salva Carrasco wrote: >Not yet: DML was expanded to 8 char. > More context, please. Which statement in which earlier ply are you discussing? And what's a "DML"? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Not yet: DML was expanded to 8 char. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
I did this years back and I think I used the ACB interface and ENDREQ. This link may help; https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa600/iea3a6_Obtaining_a_job_identifier.htm On Wed, Oct 14, 2020 at 10:44 PM Seymour J Metz wrote: > Originally it was the Reader/Interpreter. In MVS it is JES2 and JES3. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Pew, Curtis G [curtis@austin.utexas.edu] > Sent: Wednesday, October 14, 2020 5:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: INTRDR and submitted JobID > > On Oct 14, 2020, at 4:33 PM, Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > > I wish JCL had never provided > >//SYSIN DD * Generated Statement > > > > Isn’t it JES2 that does that? > > > -- > Pew, Curtis G > curtis@austin.utexas.edu > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Originally it was the Reader/Interpreter. In MVS it is JES2 and JES3. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pew, Curtis G [curtis@austin.utexas.edu] Sent: Wednesday, October 14, 2020 5:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID On Oct 14, 2020, at 4:33 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > I wish JCL had never provided >//SYSIN DD * Generated Statement > Isn’t it JES2 that does that? -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
I found generated DD * and implied /* to be great conveniences. But I wish that they had chosen a better default for SPACE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, October 14, 2020 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID On Wed, 14 Oct 2020 20:57:19 +, Seymour J Metz wrote: >No. IBM provided DD * to terminate DD *, back when there was a street drug >called Primary Control Program. Later IBM made /* optional for DD * in MFT and >MVT, but by then people were used to providing it and in some cases didn't >realize that it hadn't been needed for decades. > "DD *"? ITYM "/*" I wish JCL had never provided //SYSIN DD * Generated Statement ... it happens to me only when I miskey, e.g. "/SYSUT1" instead of "//SYSUT1". I'd rather have a detected syntax error. > On Wed, 14 Oct 2020 21:00:30 +, Seymour J Metz wrote: >IBM couldn't due that, because they used the same sigil for symbolic >parameters and temporary dataset names. R14, as I recall. > They didn't need to it that way. They could have made symbol reference "&(NAME)" rather than "&NAME" with no lexical ambiguity. > >From: Paul Gilmartin >Sent: Wednesday, October 14, 2020 4:30 PM >... >This would never have been a problem if JCL made reference to undefined >symbols a syntax error. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
On Oct 14, 2020, at 4:33 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > I wish JCL had never provided >//SYSIN DD * Generated Statement > Isn’t it JES2 that does that? -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Make that "provided /* to terminate DD *" -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Seymour J Metz [sme...@gmu.edu] Sent: Wednesday, October 14, 2020 4:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID No. IBM provided DD * to terminate DD *, back when there was a street drug called Primary Control Program. Later IBM made /* optional for DD * in MFT and MVT, but by then people were used to providing it and in some cases didn't realize that it hadn't been needed for decades. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Wednesday, October 14, 2020 4:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID This is a nice illustration of some general rule that probably deserves a psychological study. First, there was JCL. Then, SYSIN data, which (naturally) was terminated by the next JCL card (which always start with //). Then, some wanted a way to put JCL in SYSIN data. So, DD DATA was invented. But wait, how do you stop DD DATA? So, /* was invented. But wait, now I want to read in a few /* cards too! So, DLM= was created. Now, the JCL team declared the next complaint would get the requestor a punch in the face. So, naturally every SYSIN stream ever created has a useless /* at the end, and DD DATA without DLM has only been coded once since 1969. sas On Wed, Oct 14, 2020 at 3:15 PM Sri h Kolusu wrote: > > (I would have used IEBGENER. "New Hammer" phenomenon.) > > Old habit :) > > >>> What does the "$$" after the "/*" do? > > It is terminating the >//SORTIN DD DATA,DLM=$$ > > Since I am building the JCL in-line, I had to use the DLM > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
On Wed, 14 Oct 2020 20:57:19 +, Seymour J Metz wrote: >No. IBM provided DD * to terminate DD *, back when there was a street drug >called Primary Control Program. Later IBM made /* optional for DD * in MFT and >MVT, but by then people were used to providing it and in some cases didn't >realize that it hadn't been needed for decades. > "DD *"? ITYM "/*" I wish JCL had never provided //SYSIN DD * Generated Statement ... it happens to me only when I miskey, e.g. "/SYSUT1" instead of "//SYSUT1". I'd rather have a detected syntax error. > On Wed, 14 Oct 2020 21:00:30 +, Seymour J Metz wrote: >IBM couldn't due that, because they used the same sigil for symbolic >parameters and temporary dataset names. R14, as I recall. > They didn't need to it that way. They could have made symbol reference "&(NAME)" rather than "&NAME" with no lexical ambiguity. > >From: Paul Gilmartin >Sent: Wednesday, October 14, 2020 4:30 PM >... >This would never have been a problem if JCL made reference to undefined >symbols a syntax error. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
No. IBM provided DD * to terminate DD *, back when there was a street drug called Primary Control Program. Later IBM made /* optional for DD * in MFT and MVT, but by then people were used to providing it and in some cases didn't realize that it hadn't been needed for decades. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Wednesday, October 14, 2020 4:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID This is a nice illustration of some general rule that probably deserves a psychological study. First, there was JCL. Then, SYSIN data, which (naturally) was terminated by the next JCL card (which always start with //). Then, some wanted a way to put JCL in SYSIN data. So, DD DATA was invented. But wait, how do you stop DD DATA? So, /* was invented. But wait, now I want to read in a few /* cards too! So, DLM= was created. Now, the JCL team declared the next complaint would get the requestor a punch in the face. So, naturally every SYSIN stream ever created has a useless /* at the end, and DD DATA without DLM has only been coded once since 1969. sas On Wed, Oct 14, 2020 at 3:15 PM Sri h Kolusu wrote: > > (I would have used IEBGENER. "New Hammer" phenomenon.) > > Old habit :) > > >>> What does the "$$" after the "/*" do? > > It is terminating the >//SORTIN DD DATA,DLM=$$ > > Since I am building the JCL in-line, I had to use the DLM > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
IBM demurred for years allowing system symbols to be used in batch JCL. There were several spirited discussions at SHARE as to how they should work. Some possibilities: -- Substitute values at submit time -- Substitute values at conversion time -- Substitute values at execution time These questions are complicated by the possibility of a job executing on any member of a MAS or even on another NJE node. Not to mention the chance of symbol collision with internal JCL variables. All of these possibilities confuse the question of what value did the user intend? What did she get? There was no consensus among participants. When IBM finally conceded to customer demand, they imposed some rules, which are documented. But to protect users from unexpected results, the default was to disallow substitution unless the installation explicitly allowed it--presumably after lots of testing. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lars Höglund Sent: Wednesday, October 14, 2020 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):SV: INTRDR and submitted JobID CAUTION EXTERNAL EMAIL Hi Do You the reason why the default for SYSSYM is DISALLOW? //Lasse -Ursprungligt meddelande- Från: IBM Mainframe Discussion List För Lizette Koehler Skickat: den 14 oktober 2020 20:38 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: INTRDR and submitted JobID I think System Symbols are only available when the JES2 Class says SYSSYM=ALLOW Otherwise I think they are not available to a batch job. They are probably available to an STC Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, October 14, 2020 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID > I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract a > job's own JobID. Is there a simpler way? Gil, How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like this? //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTOUT DD SYSOUT=(*,INTRDR) //SYSINDD * OPTION COPY //* //SORTIN DD DATA,DLM=$$ //SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID /* // EXPORT SYMLIST=* // SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID /* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD *,SYMBOLS=JCLONLY JOBNAME FOR THIS JOB IS : &SYSJOBNM JOBID FOR THIS JOB IS : &SYSJOBID //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY /* $$ Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
This is a nice illustration of some general rule that probably deserves a psychological study. First, there was JCL. Then, SYSIN data, which (naturally) was terminated by the next JCL card (which always start with //). Then, some wanted a way to put JCL in SYSIN data. So, DD DATA was invented. But wait, how do you stop DD DATA? So, /* was invented. But wait, now I want to read in a few /* cards too! So, DLM= was created. Now, the JCL team declared the next complaint would get the requestor a punch in the face. So, naturally every SYSIN stream ever created has a useless /* at the end, and DD DATA without DLM has only been coded once since 1969. sas On Wed, Oct 14, 2020 at 3:15 PM Sri h Kolusu wrote: > > (I would have used IEBGENER. "New Hammer" phenomenon.) > > Old habit :) > > >>> What does the "$$" after the "/*" do? > > It is terminating the >//SORTIN DD DATA,DLM=$$ > > Since I am building the JCL in-line, I had to use the DLM > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
I am guessing it is due to where the job gets converted. If the symbol being used is different on different LPARs in a PEX, then you could get different results. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lars Höglund Sent: Wednesday, October 14, 2020 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SV: INTRDR and submitted JobID Hi Do You the reason why the default for SYSSYM is DISALLOW? //Lasse -Ursprungligt meddelande- Från: IBM Mainframe Discussion List För Lizette Koehler Skickat: den 14 oktober 2020 20:38 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: INTRDR and submitted JobID I think System Symbols are only available when the JES2 Class says SYSSYM=ALLOW Otherwise I think they are not available to a batch job. They are probably available to an STC Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, October 14, 2020 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID > I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract a > job's own JobID. Is there a simpler way? Gil, How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like this? //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTOUT DD SYSOUT=(*,INTRDR) //SYSINDD * OPTION COPY //* //SORTIN DD DATA,DLM=$$ //SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID /* // EXPORT SYMLIST=* // SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID /* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD *,SYMBOLS=JCLONLY JOBNAME FOR THIS JOB IS : &SYSJOBNM JOBID FOR THIS JOB IS : &SYSJOBID //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY /* $$ Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
On Wed, 14 Oct 2020 12:15:07 -0700, Sri h Kolusu wrote: >> (I would have used IEBGENER. "New Hammer" phenomenon.) > > Old habit :) > And you couldn't resist doing it twice! What does the "$$" after the "/*" do? > >It is terminating the >//SORTIN DD DATA,DLM=$$ >Since I am building the JCL in-line, I had to use the DLM > Oops! I missed that part. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Terminates input processing matching the DLM=$$ What does the "$$" after the "/*" do? -Original Message- From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, Oct 14, 2020 2:06 pm Subject: Re: INTRDR and submitted JobID On Wed, 14 Oct 2020 11:01:38 -0700, Sri h Kolusu wrote: >> I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract >> a job's own JobID. Is there a simpler way? > >How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like >this? > Thanks. I had been looking at some old JCL, perhaps older than &SYSJOBID or SYMBOLS= where I had done: address ISPEXEC 'vget ( ZSEQ ) shared' '... JOB'ZSEQ /* (depends on prefix length.) */ (I would have used IEBGENER. "New Hammer" phenomenon.) What does the "$$" after the "/*" do? >//STEP0100 EXEC PGM=SORT >//SYSOUT DD SYSOUT=* >//SORTOUT DD SYSOUT=(*,INTRDR) >//SYSIN DD * > OPTION COPY >//* >//SORTIN DD DATA,DLM=$$ >//SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, >// MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID >/* >// EXPORT SYMLIST=* >// SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID >/* >//STEP0100 EXEC PGM=SORT >//SYSOUT DD SYSOUT=* >//SORTIN DD *,SYMBOLS=JCLONLY >JOBNAME FOR THIS JOB IS : &SYSJOBNM >JOBID FOR THIS JOB IS : &SYSJOBID >//SORTOUT DD SYSOUT=* >//SYSIN DD * > OPTION COPY >/* >$$ Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
> (I would have used IEBGENER. "New Hammer" phenomenon.) Old habit :) >>> What does the "$$" after the "/*" do? It is terminating the >//SORTIN DD DATA,DLM=$$ Since I am building the JCL in-line, I had to use the DLM Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
On Wed, 14 Oct 2020 11:01:38 -0700, Sri h Kolusu wrote: >> I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract >> a job's own JobID. Is there a simpler way? > >How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like >this? > Thanks. I had been looking at some old JCL, perhaps older than &SYSJOBID or SYMBOLS= where I had done: address ISPEXEC 'vget ( ZSEQ ) shared' '... JOB'ZSEQ /* (depends on prefix length.) */ (I would have used IEBGENER. "New Hammer" phenomenon.) What does the "$$" after the "/*" do? >//STEP0100 EXEC PGM=SORT >//SYSOUT DD SYSOUT=* >//SORTOUT DD SYSOUT=(*,INTRDR) >//SYSINDD * > OPTION COPY >//* >//SORTIN DD DATA,DLM=$$ >//SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, >// MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID >/* >// EXPORT SYMLIST=* >// SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID >/* >//STEP0100 EXEC PGM=SORT >//SYSOUT DD SYSOUT=* >//SORTIN DD *,SYMBOLS=JCLONLY >JOBNAME FOR THIS JOB IS : &SYSJOBNM >JOBID FOR THIS JOB IS : &SYSJOBID >//SORTOUT DD SYSOUT=* >//SYSINDD * > OPTION COPY >/* >$$ Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
I think System Symbols are only available when the JES2 Class says SYSSYM=ALLOW Otherwise I think they are not available to a batch job. They are probably available to an STC Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, October 14, 2020 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID > I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract a > job's own JobID. Is there a simpler way? Gil, How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like this? //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTOUT DD SYSOUT=(*,INTRDR) //SYSINDD * OPTION COPY //* //SORTIN DD DATA,DLM=$$ //SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID /* // EXPORT SYMLIST=* // SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID /* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD *,SYMBOLS=JCLONLY JOBNAME FOR THIS JOB IS : &SYSJOBNM JOBID FOR THIS JOB IS : &SYSJOBID //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY /* $$ Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
A corollary is that you have to use the VSAM interface to submit the job; you can't use QSAM. You have to use an ACB and RPL, not a DCB. A footnote is that when FTP submits a job using SITE FILETYPE=JES it displays 125 When JOBn is done, will retrieve its output Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Wednesday, October 14, 2020 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: INTRDR and submitted JobID Refer to "Assembler Services Guide" "Obtaining a job identifier". "Issue an ENDREQ macro after writing a complete job to the internal reader. The job identifier is returned in the RPLRBAR field of the request parameter list (RPL)." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Hi, If you write to the INTRDR with an ACB/RPL and then do an ENDREQ on the RPL after the last JCL record, then you should find the JOBID in RPLRBAR of the RPL. This would make it available after the job has been submitted, as I believe the ENDREQ is like an /*EOF and would cut the recognised job off, so needs to be after the last card. Cheers Stephen Stephen R. Donaldson, Code Magus Limited (England reg. no. 4024745) Number 6, 69 Woodstock Road, Oxford, OX2 6EY, United Kingdom Voice: +44 1865 310 768 Fax: +44 1865 316 979 Cell: +44 787 9897709 Support: +44 1865 589826 Skype:vixxmovz http://www.codemagus.com mailto:step...@codemagus.com On 14/10/2020 18:37, Paul Gilmartin wrote: I see that the UNIX SUBMIT command shows the JobID of the submitted job. What interface makes this available. I suspect it's in JES or Assembler Services, but I don't know how to find it. At what point in processing is the submitted JobID available?: o INTRDR OPEN? o INTRDR CLOSE? o somewhere in between? I'm wondering whether when dynamically generating JCL the job's own JobID is available for embedding in SYSIN or PARM for a later step. I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract a job's own JobID. Is there a simpler way? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
> I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract > a job's own JobID. Is there a simpler way? Gil, How about using system symbols &SYSJOBID and &SYSJOBNM ? Something like this? //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTOUT DD SYSOUT=(*,INTRDR) //SYSINDD * OPTION COPY //* //SORTIN DD DATA,DLM=$$ //SYMSUBJ JOB (B004273,BIN#,BLDG#,DEPT#),&SYSUID, // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID /* // EXPORT SYMLIST=* // SET SYSJOBNM=&SYSJOBNM,SYSJOBID=&SYSJOBID /* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD *,SYMBOLS=JCLONLY JOBNAME FOR THIS JOB IS : &SYSJOBNM JOBID FOR THIS JOB IS : &SYSJOBID //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY /* $$ Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Refer to "Assembler Services Guide" "Obtaining a job identifier". "Issue an ENDREQ macro after writing a complete job to the internal reader. The job identifier is returned in the RPLRBAR field of the request parameter list (RPL)." On Wed, 14 Oct 2020 12:37:01 -0500 Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: :>I see that the UNIX SUBMIT command shows the JobID of the submitted job. :>What interface makes this available. I suspect it's in JES or Assembler Services, :>but I don't know how to find it. :>At what point in processing is the submitted JobID available?: :>o INTRDR OPEN? :>o INTRDR CLOSE? :>o somewhere in between? :>I'm wondering whether when dynamically generating JCL the job's own :>JobID is available for embedding in SYSIN or PARM for a later step. :>I've used an IKJEFT TSO ISPF step or SDSF screen scraping to extract :>a job's own JobID. Is there a simpler way? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and NJE
I want to thank those who responded, but I may have led people astray by mentioning CA-7. We are planning to use NCF which is indeed part of the base. A shared COMDS is quite impossible, as the new sysplex will ultimately be in a different city. The essence of my question, to which nobody responded, was whether specifying a DD like //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE would produce the same results as adding /*ROUTE XEQ NODE to the JCL? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and NJE
There are various methods of managing the enterprise, but the fundamental question is whether to share the communication data set. Having worked in a similar environment for a long time, I highly recommend *not* sharing the COMMDS but using one of the supported communication methods such as SNA (if you're inclined) or TCP/IP. Sharing any dataset across sysplex boundaries is highly problematic. Best to have a single COMMDS in the production sysplex and let the product orchestrate job submission. In any case NJE comes into play for submitting jobs and handling output. These considerations apply equally to CA-7 and TWS. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Tuesday, February 14, 2017 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: INTRDR and NJE You can ftp to the lpar with SITE FILETYPE=JES SITE FILETYPE=JES PUT 'dataset.with.jobstream' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst Sent: Tuesday, February 14, 2017 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: INTRDR and NJE We are planning to split our production sysplex (where we also do development) into a purely production sysplex and a development syslpex. What I am researching is how best to set up jobs that are submitted by our scheduler (CA-7) on the production system to run on the development sysplex. These would be infrastructure type jobs. CA-7 allows us to direct jobs to a particular internal reader DD statement for submission. One alternative is certainly to add the /*ROUTE XEQ statements to the JCL to be submitted via NJE. A second alternative would be to code a CA-7 job submission exit that adds the /*ROUTE XEQ statement when appropriate. What I wonder is whether there is some combination of internal reader DD statements and JES2 JECL to produce this same affect for jobs to be submitted via NJE. That would be the less effort than the alternatives. If I specify something like //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to NODE to be executed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: INTRDR and NJE
Our Dev and Prod Data Centers were out of shared DASD range so NCF was necessary Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, February 14, 2017 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: Re: INTRDR and NJE Could be. I've been fine with ICOMs among Monoplexes. So I didn't go there with NCF. You can do Batch Terminals via ICOM also. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, February 14, 2017 11:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > NCF was a bundled part of CA-7 when we ran it. I'm not aware of > additional costs for running it. > > Jerry Whitteridge > Manager Mainframe Systems & Storage > Albertsons - Safeway Inc. > 623 869 5523 > Corporate Tieline - 85523 > > If you feel in control > you just aren't going fast enough. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, February 14, 2017 12:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > But, I think costs more :) > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge > > Sent: Tuesday, February 14, 2017 11:25 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > > > Also look into the use of CA-7 NCF which allows not sharing the COMMDS. > > > > Jerry Whitteridge > > Manager Mainframe Systems & Storage > > Albertsons - Safeway Inc. > > 623 869 5523 > > Corporate Tieline - 85523 > > > > If you feel in control > > you just aren't going fast enough. > > > > > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > Sent: Tuesday, February 14, 2017 12:19 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: EXTERNAL: Re: INTRDR and NJE > > > > It takes carefully shared DASD for the COMDS. You can run Additional > > ICOM instances in development. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst > > > Sent: Tuesday, February 14, 2017 10:56 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: INTRDR and NJE > > > > > > We are planning to split our production sysplex (where we also do > > > development) into a purely production sysplex and a development > syslpex. > > > > > > What I am researching is how best to set up jobs that are > > > submitted by our scheduler (CA-7) on the production system to run > > > on the development sysplex. These would be infrastructure type jobs. > > > > > > CA-7 allows us to direct jobs to a particular internal reader DD > > > statement for submission. > > > > > > One alternative is certainly to add the /*ROUTE XEQ statements to > > > the JCL to be submitted via NJE. > > > > > > A second alternative would be to code a CA-7 job submission exit > > > that adds the /*ROUTE XEQ statement when appropriate. > > > > > > What I wonder is whether there is some combination of internal > > > reader DD statements and JES2 JECL to produce this same affect for > > > jobs to be submitted via NJE. That would be the less effort than > > > the alternatives. If I specify something like > > > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > > > NODE to be executed? > > > > > > -- > > > -- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-
Re: EXTERNAL: Re: INTRDR and NJE
IIRC, NCF was an option 15-20 years ago when I supported the product hat allowed communications back to CA7 from a remote site, don't know of any additional costs, I've never had the need to set it up, we shared SOME DASD with systems not in the same PLEX and or MAS so we used ICOM and ROUTE statements to run jobs on the appropriate LPAR - Original Message - From: "Jerry Whitteridge" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, February 14, 2017 1:28:09 PM Subject: Re: EXTERNAL: Re: INTRDR and NJE NCF was a bundled part of CA-7 when we ran it. I'm not aware of additional costs for running it. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, February 14, 2017 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: Re: INTRDR and NJE But, I think costs more :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, February 14, 2017 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > Also look into the use of CA-7 NCF which allows not sharing the COMMDS. > > Jerry Whitteridge > Manager Mainframe Systems & Storage > Albertsons - Safeway Inc. > 623 869 5523 > Corporate Tieline - 85523 > > If you feel in control > you just aren't going fast enough. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, February 14, 2017 12:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: INTRDR and NJE > > It takes carefully shared DASD for the COMDS. You can run Additional > ICOM instances in development. > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst > > Sent: Tuesday, February 14, 2017 10:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: INTRDR and NJE > > > > We are planning to split our production sysplex (where we also do > > development) into a purely production sysplex and a development syslpex. > > > > What I am researching is how best to set up jobs that are submitted > > by our scheduler (CA-7) on the production system to run on the > > development sysplex. These would be infrastructure type jobs. > > > > CA-7 allows us to direct jobs to a particular internal reader DD > > statement for submission. > > > > One alternative is certainly to add the /*ROUTE XEQ statements to > > the JCL to be submitted via NJE. > > > > A second alternative would be to code a CA-7 job submission exit > > that adds the /*ROUTE XEQ statement when appropriate. > > > > What I wonder is whether there is some combination of internal > > reader DD statements and JES2 JECL to produce this same affect for > > jobs to be submitted via NJE. That would be the less effort than the > > alternatives. If I specify something like > > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > > NODE to be executed? > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Warning: All e-mail sent to this address will be received by the > corporate e- mail system, and is subject to archival and review by > someone other than the recipient. This e-mail may contain proprietary > information and is intended only for the use of the intended > recipient(s). If the reader of this message is not the intended > recipient(s), you are notified that you have received this message in > error and that any review, dissemination, distribution or copying of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately. > > > -- > For IBM-MAIN subscribe / signoff / archive access instru
Re: EXTERNAL: Re: INTRDR and NJE
Could be. I've been fine with ICOMs among Monoplexes. So I didn't go there with NCF. You can do Batch Terminals via ICOM also. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, February 14, 2017 11:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > NCF was a bundled part of CA-7 when we ran it. I'm not aware of additional > costs for running it. > > Jerry Whitteridge > Manager Mainframe Systems & Storage > Albertsons - Safeway Inc. > 623 869 5523 > Corporate Tieline - 85523 > > If you feel in control > you just aren't going fast enough. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, February 14, 2017 12:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > But, I think costs more :) > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Jerry Whitteridge > > Sent: Tuesday, February 14, 2017 11:25 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > > > Also look into the use of CA-7 NCF which allows not sharing the COMMDS. > > > > Jerry Whitteridge > > Manager Mainframe Systems & Storage > > Albertsons - Safeway Inc. > > 623 869 5523 > > Corporate Tieline - 85523 > > > > If you feel in control > > you just aren't going fast enough. > > > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Gibney, Dave > > Sent: Tuesday, February 14, 2017 12:19 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: EXTERNAL: Re: INTRDR and NJE > > > > It takes carefully shared DASD for the COMDS. You can run Additional > > ICOM instances in development. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst > > > Sent: Tuesday, February 14, 2017 10:56 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: INTRDR and NJE > > > > > > We are planning to split our production sysplex (where we also do > > > development) into a purely production sysplex and a development > syslpex. > > > > > > What I am researching is how best to set up jobs that are submitted > > > by our scheduler (CA-7) on the production system to run on the > > > development sysplex. These would be infrastructure type jobs. > > > > > > CA-7 allows us to direct jobs to a particular internal reader DD > > > statement for submission. > > > > > > One alternative is certainly to add the /*ROUTE XEQ statements to > > > the JCL to be submitted via NJE. > > > > > > A second alternative would be to code a CA-7 job submission exit > > > that adds the /*ROUTE XEQ statement when appropriate. > > > > > > What I wonder is whether there is some combination of internal > > > reader DD statements and JES2 JECL to produce this same affect for > > > jobs to be submitted via NJE. That would be the less effort than the > > > alternatives. If I specify something like > > > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > > > NODE to be executed? > > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Warning: All e-mail sent to this address will be received by the > > corporate e- mail system, and is subject to archival and review by > > someone other than the recipient. This e-mail may contain proprietary > > information and is intended only for the use of the intended > > recipient(s). If the reader of this message is not the intended > > recipient(s), you are notified that you have received this message in > > error and that any review, dissemination, distribution or copying of > > this message is strictly pr
Re: EXTERNAL: Re: INTRDR and NJE
NCF was a bundled part of CA-7 when we ran it. I'm not aware of additional costs for running it. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, February 14, 2017 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: Re: INTRDR and NJE But, I think costs more :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, February 14, 2017 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > Also look into the use of CA-7 NCF which allows not sharing the COMMDS. > > Jerry Whitteridge > Manager Mainframe Systems & Storage > Albertsons - Safeway Inc. > 623 869 5523 > Corporate Tieline - 85523 > > If you feel in control > you just aren't going fast enough. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, February 14, 2017 12:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: INTRDR and NJE > > It takes carefully shared DASD for the COMDS. You can run Additional > ICOM instances in development. > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst > > Sent: Tuesday, February 14, 2017 10:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: INTRDR and NJE > > > > We are planning to split our production sysplex (where we also do > > development) into a purely production sysplex and a development syslpex. > > > > What I am researching is how best to set up jobs that are submitted > > by our scheduler (CA-7) on the production system to run on the > > development sysplex. These would be infrastructure type jobs. > > > > CA-7 allows us to direct jobs to a particular internal reader DD > > statement for submission. > > > > One alternative is certainly to add the /*ROUTE XEQ statements to > > the JCL to be submitted via NJE. > > > > A second alternative would be to code a CA-7 job submission exit > > that adds the /*ROUTE XEQ statement when appropriate. > > > > What I wonder is whether there is some combination of internal > > reader DD statements and JES2 JECL to produce this same affect for > > jobs to be submitted via NJE. That would be the less effort than the > > alternatives. If I specify something like > > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > > NODE to be executed? > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Warning: All e-mail sent to this address will be received by the > corporate e- mail system, and is subject to archival and review by > someone other than the recipient. This e-mail may contain proprietary > information and is intended only for the use of the intended > recipient(s). If the reader of this message is not the intended > recipient(s), you are notified that you have received this message in > error and that any review, dissemination, distribution or copying of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information
Re: EXTERNAL: Re: INTRDR and NJE
But, I think costs more :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, February 14, 2017 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL: Re: INTRDR and NJE > > Also look into the use of CA-7 NCF which allows not sharing the COMMDS. > > Jerry Whitteridge > Manager Mainframe Systems & Storage > Albertsons - Safeway Inc. > 623 869 5523 > Corporate Tieline - 85523 > > If you feel in control > you just aren't going fast enough. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, February 14, 2017 12:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: Re: INTRDR and NJE > > It takes carefully shared DASD for the COMDS. You can run Additional ICOM > instances in development. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Jeffrey Holst > > Sent: Tuesday, February 14, 2017 10:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: INTRDR and NJE > > > > We are planning to split our production sysplex (where we also do > > development) into a purely production sysplex and a development syslpex. > > > > What I am researching is how best to set up jobs that are submitted by > > our scheduler (CA-7) on the production system to run on the > > development sysplex. These would be infrastructure type jobs. > > > > CA-7 allows us to direct jobs to a particular internal reader DD > > statement for submission. > > > > One alternative is certainly to add the /*ROUTE XEQ statements to the > > JCL to be submitted via NJE. > > > > A second alternative would be to code a CA-7 job submission exit that > > adds the /*ROUTE XEQ statement when appropriate. > > > > What I wonder is whether there is some combination of internal reader > > DD statements and JES2 JECL to produce this same affect for jobs to be > > submitted via NJE. That would be the less effort than the > > alternatives. If I specify something like > > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > > NODE to be executed? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Warning: All e-mail sent to this address will be received by the corporate e- > mail system, and is subject to archival and review by someone other than the > recipient. This e-mail may contain proprietary information and is intended > only for the use of the intended recipient(s). If the reader of this message > is > not the intended recipient(s), you are notified that you have received this > message in error and that any review, dissemination, distribution or copying > of this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: INTRDR and NJE
Also look into the use of CA-7 NCF which allows not sharing the COMMDS. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Tuesday, February 14, 2017 12:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: INTRDR and NJE It takes carefully shared DASD for the COMDS. You can run Additional ICOM instances in development. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jeffrey Holst > Sent: Tuesday, February 14, 2017 10:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: INTRDR and NJE > > We are planning to split our production sysplex (where we also do > development) into a purely production sysplex and a development syslpex. > > What I am researching is how best to set up jobs that are submitted by > our scheduler (CA-7) on the production system to run on the > development sysplex. These would be infrastructure type jobs. > > CA-7 allows us to direct jobs to a particular internal reader DD > statement for submission. > > One alternative is certainly to add the /*ROUTE XEQ statements to the > JCL to be submitted via NJE. > > A second alternative would be to code a CA-7 job submission exit that > adds the /*ROUTE XEQ statement when appropriate. > > What I wonder is whether there is some combination of internal reader > DD statements and JES2 JECL to produce this same affect for jobs to be > submitted via NJE. That would be the less effort than the > alternatives. If I specify something like > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to > NODE to be executed? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and NJE
It takes carefully shared DASD for the COMDS. You can run Additional ICOM instances in development. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jeffrey Holst > Sent: Tuesday, February 14, 2017 10:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: INTRDR and NJE > > We are planning to split our production sysplex (where we also do > development) into a purely production sysplex and a development syslpex. > > What I am researching is how best to set up jobs that are submitted by our > scheduler (CA-7) on the production system to run on the development > sysplex. These would be infrastructure type jobs. > > CA-7 allows us to direct jobs to a particular internal reader DD statement for > submission. > > One alternative is certainly to add the /*ROUTE XEQ statements to the JCL to > be submitted via NJE. > > A second alternative would be to code a CA-7 job submission exit that adds > the /*ROUTE XEQ statement when appropriate. > > What I wonder is whether there is some combination of internal reader DD > statements and JES2 JECL to produce this same affect for jobs to be submitted > via NJE. That would be the less effort than the alternatives. If I specify > something like > //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to NODE > to be executed? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and NJE
You can ftp to the lpar with SITE FILETYPE=JES SITE FILETYPE=JES PUT 'dataset.with.jobstream' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst Sent: Tuesday, February 14, 2017 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: INTRDR and NJE We are planning to split our production sysplex (where we also do development) into a purely production sysplex and a development syslpex. What I am researching is how best to set up jobs that are submitted by our scheduler (CA-7) on the production system to run on the development sysplex. These would be infrastructure type jobs. CA-7 allows us to direct jobs to a particular internal reader DD statement for submission. One alternative is certainly to add the /*ROUTE XEQ statements to the JCL to be submitted via NJE. A second alternative would be to code a CA-7 job submission exit that adds the /*ROUTE XEQ statement when appropriate. What I wonder is whether there is some combination of internal reader DD statements and JES2 JECL to produce this same affect for jobs to be submitted via NJE. That would be the less effort than the alternatives. If I specify something like //INTRDR1 DD SYSOUT=(A,INTRDR),DEST=NODE will that send the job to NODE to be executed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr (and IEC141I 013-6)
FYI,
If you use the z/OSMF Jobs REST API, you can submit JCL using RECFM, LRECL,
etc and use long record lengths. FWIW, you can also control user
correlators and system symbols for submitted jobs.
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_API_PutSubmitJob.htm
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Fri, Oct 21, 2016 at 2:59 PM, scott Ford wrote:
> Gil,
>
> Wow, it proves the point the Intrdr can handle bigger records.
>
> On Wednesday, October 19, 2016, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 17 Oct 2016 20:10:49 -0500, Paul Gilmartin wrote:
> > >On Mon, 17 Oct 2016 19:10:23 -0400, scott Ford wrote:
> > >
> > >>I am passing sysin data behind the actual JCL , it can be large up to
> > 32k..
> > >>I wasn't sure about punching the JCL and data to the Intrdr when the
> > >>logical record length us that large .
> > >>
> > >"punch"?
> > >
> > >The following submits a job that works nicely:
> > >
> > (That's on JES2. On JES3 the SYSUT1 and SYSUT2 data sets are garbled,
> > at least when viewed with SDSF.)
> >
> > >/* Rexx */ signal on novalue; /*
> > > Doc: Long records to INTRDR.
> > >*/
> > >
> > >trace R
> > >L = 32752 /* ISFUNLD fails with IEC141I 013-6 on SYSUT1 at 32753!? */
> > >RC = BPXWDYN( 'alloc rtddn(D) sysout writer(INTRDR) recfm(V,B)
> lrecl('L')
> > blksiz
> > >e(0) msg(2)' )
> > >
> > >trace Err
> > >call P '//'
> > >call P '//LONGINP JOB 505303JOB,''Paul Gilmartin'','
> > >call P '// MSGLEVEL=(1,1),REGION=0M'
> > >call P '//*'
> > >call P '// EXPORT SYMLIST=*'
> > >call P '//*'
> > >call P '//USERCOUTPUT JESDS=ALL,DEFAULT=YES,'
> > >call P '//* DEST=&SYSNAME..&SYSUID,'
> > >call P '// CLASS=R,PAGEDEF=V0648Z,CHARS=GT12'
> > >call P '//*'
> > >call P '//STEP EXEC PGM=IEBGENER'
> > >call P '//SYSPRINT DD SYSOUT=(,)'
> > >call P '//SYSIN DD DUMMY'
> > >call P '//SYSUT2DD SYSOUT=(,)'
> > >call P '//SYSUT1DD *'
> > >call P 'Long record test.'
> > >call P right( 'Long record 1', L - 4 )
> > >call P right( 'Long record 2', L - 4 )
> > >call P '//'
> > >return( RC )
> > >
> > >P:
> > >trace C
> > >address 'MVS'
> > >S.1 = arg( 1 )
> > >'EXECIO 1 DISKW' D '(STEM S.'
> > >return( RC )
> > >
> > >If I try LRECL>=32753 up to 32756 the job runs OK, but I get IEC141I
> 013-6
> > >on the SYSUT1 spool data set when I try to copy it with code similar to
> an
> > >example in the SDSF guide. This might happen if some code were counting
> > >the RDW twice.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message:
> > INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr (and IEC141I 013-6)
Gil,
Wow, it proves the point the Intrdr can handle bigger records.
On Wednesday, October 19, 2016, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 17 Oct 2016 20:10:49 -0500, Paul Gilmartin wrote:
> >On Mon, 17 Oct 2016 19:10:23 -0400, scott Ford wrote:
> >
> >>I am passing sysin data behind the actual JCL , it can be large up to
> 32k..
> >>I wasn't sure about punching the JCL and data to the Intrdr when the
> >>logical record length us that large .
> >>
> >"punch"?
> >
> >The following submits a job that works nicely:
> >
> (That's on JES2. On JES3 the SYSUT1 and SYSUT2 data sets are garbled,
> at least when viewed with SDSF.)
>
> >/* Rexx */ signal on novalue; /*
> > Doc: Long records to INTRDR.
> >*/
> >
> >trace R
> >L = 32752 /* ISFUNLD fails with IEC141I 013-6 on SYSUT1 at 32753!? */
> >RC = BPXWDYN( 'alloc rtddn(D) sysout writer(INTRDR) recfm(V,B) lrecl('L')
> blksiz
> >e(0) msg(2)' )
> >
> >trace Err
> >call P '//'
> >call P '//LONGINP JOB 505303JOB,''Paul Gilmartin'','
> >call P '// MSGLEVEL=(1,1),REGION=0M'
> >call P '//*'
> >call P '// EXPORT SYMLIST=*'
> >call P '//*'
> >call P '//USERCOUTPUT JESDS=ALL,DEFAULT=YES,'
> >call P '//* DEST=&SYSNAME..&SYSUID,'
> >call P '// CLASS=R,PAGEDEF=V0648Z,CHARS=GT12'
> >call P '//*'
> >call P '//STEP EXEC PGM=IEBGENER'
> >call P '//SYSPRINT DD SYSOUT=(,)'
> >call P '//SYSIN DD DUMMY'
> >call P '//SYSUT2DD SYSOUT=(,)'
> >call P '//SYSUT1DD *'
> >call P 'Long record test.'
> >call P right( 'Long record 1', L - 4 )
> >call P right( 'Long record 2', L - 4 )
> >call P '//'
> >return( RC )
> >
> >P:
> >trace C
> >address 'MVS'
> >S.1 = arg( 1 )
> >'EXECIO 1 DISKW' D '(STEM S.'
> >return( RC )
> >
> >If I try LRECL>=32753 up to 32756 the job runs OK, but I get IEC141I 013-6
> >on the SYSUT1 spool data set when I try to copy it with code similar to an
> >example in the SDSF guide. This might happen if some code were counting
> >the RDW twice.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message:
> INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr (and IEC141I 013-6)
On Mon, 17 Oct 2016 20:10:49 -0500, Paul Gilmartin wrote:
>On Mon, 17 Oct 2016 19:10:23 -0400, scott Ford wrote:
>
>>I am passing sysin data behind the actual JCL , it can be large up to 32k..
>>I wasn't sure about punching the JCL and data to the Intrdr when the
>>logical record length us that large .
>>
>"punch"?
>
>The following submits a job that works nicely:
>
(That's on JES2. On JES3 the SYSUT1 and SYSUT2 data sets are garbled,
at least when viewed with SDSF.)
>/* Rexx */ signal on novalue; /*
> Doc: Long records to INTRDR.
>*/
>
>trace R
>L = 32752 /* ISFUNLD fails with IEC141I 013-6 on SYSUT1 at 32753!? */
>RC = BPXWDYN( 'alloc rtddn(D) sysout writer(INTRDR) recfm(V,B) lrecl('L')
>blksiz
>e(0) msg(2)' )
>
>trace Err
>call P '//'
>call P '//LONGINP JOB 505303JOB,''Paul Gilmartin'','
>call P '// MSGLEVEL=(1,1),REGION=0M'
>call P '//*'
>call P '// EXPORT SYMLIST=*'
>call P '//*'
>call P '//USERCOUTPUT JESDS=ALL,DEFAULT=YES,'
>call P '//* DEST=&SYSNAME..&SYSUID,'
>call P '// CLASS=R,PAGEDEF=V0648Z,CHARS=GT12'
>call P '//*'
>call P '//STEP EXEC PGM=IEBGENER'
>call P '//SYSPRINT DD SYSOUT=(,)'
>call P '//SYSIN DD DUMMY'
>call P '//SYSUT2DD SYSOUT=(,)'
>call P '//SYSUT1DD *'
>call P 'Long record test.'
>call P right( 'Long record 1', L - 4 )
>call P right( 'Long record 2', L - 4 )
>call P '//'
>return( RC )
>
>P:
>trace C
>address 'MVS'
>S.1 = arg( 1 )
>'EXECIO 1 DISKW' D '(STEM S.'
>return( RC )
>
>If I try LRECL>=32753 up to 32756 the job runs OK, but I get IEC141I 013-6
>on the SYSUT1 spool data set when I try to copy it with code similar to an
>example in the SDSF guide. This might happen if some code were counting
>the RDW twice.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr (and IEC141I 013-6)
On Mon, 17 Oct 2016 19:10:23 -0400, scott Ford wrote:
>I am passing sysin data behind the actual JCL , it can be large up to 32k..
>I wasn't sure about punching the JCL and data to the Intrdr when the
>logical record length us that large .
>
"punch"?
The following submits a job that works nicely:
/* Rexx */ signal on novalue; /*
Doc: Long records to INTRDR.
*/
trace R
L = 32752 /* ISFUNLD fails with IEC141I 013-6 on SYSUT1 at 32753!? */
RC = BPXWDYN( 'alloc rtddn(D) sysout writer(INTRDR) recfm(V,B) lrecl('L') blksiz
e(0) msg(2)' )
trace Err
call P '//'
call P '//LONGINP JOB 505303JOB,''Paul Gilmartin'','
call P '// MSGLEVEL=(1,1),REGION=0M'
call P '//*'
call P '// EXPORT SYMLIST=*'
call P '//*'
call P '//USERCOUTPUT JESDS=ALL,DEFAULT=YES,'
call P '//* DEST=&SYSNAME..&SYSUID,'
call P '// CLASS=R,PAGEDEF=V0648Z,CHARS=GT12'
call P '//*'
call P '//STEP EXEC PGM=IEBGENER'
call P '//SYSPRINT DD SYSOUT=(,)'
call P '//SYSIN DD DUMMY'
call P '//SYSUT2DD SYSOUT=(,)'
call P '//SYSUT1DD *'
call P 'Long record test.'
call P right( 'Long record 1', L - 4 )
call P right( 'Long record 2', L - 4 )
call P '//'
return( RC )
P:
trace C
address 'MVS'
S.1 = arg( 1 )
'EXECIO 1 DISKW' D '(STEM S.'
return( RC )
If I try LRECL>=32753 up to 32756 the job runs OK, but I get IEC141I 013-6
on the SYSUT1 spool data set when I try to copy it with code similar to an
example in the SDSF guide. This might happen if some code were counting
the RDW twice.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
I am passing sysin data behind the actual JCL , it can be large up to 32k.. I wasn't sure about punching the JCL and data to the Intrdr when the logical record length us that large . Scott On Monday, October 17, 2016, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 17 Oct 2016 18:23:09 -0400, scott Ford wrote: > > > >I read that the Intrdr max recsize was 32760, but am I right if I punch to > >the Intrdr I am still limited to 80 byte records? > > > No. I've certainly used >80. > > o JCL commands ignore all characters beyond 80 > > o SYSIN data sets may have far more than 80. > > o The rules for determining the values of LRECL and RECFM of > a SYSIN at DCB OPEN merge are largely undocumented. I believe > they differ between JES2 and JES3. I have a long unanswered RCF > on this. I should nudge it. > > o FTP imposes an antiquated limit of 254 on JESLRECL. This should be > fodder for an RFE. > > o LRECL= is allowed on DD SYSIN. It may not have the effect you want. > > o But RECFM= is prohibited on DD SYSIN. Go figger. > > o TSO and ISPF SUBMIT are oblivious; stuck in the 20th century. ISPF > submit quietly truncates to 80. I consider this data loss. > > o Beware that you may cause I/O errors on many utility SYSINs. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: > INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Mon, 17 Oct 2016 18:23:09 -0400, scott Ford wrote: > >I read that the Intrdr max recsize was 32760, but am I right if I punch to >the Intrdr I am still limited to 80 byte records? > No. I've certainly used >80. o JCL commands ignore all characters beyond 80 o SYSIN data sets may have far more than 80. o The rules for determining the values of LRECL and RECFM of a SYSIN at DCB OPEN merge are largely undocumented. I believe they differ between JES2 and JES3. I have a long unanswered RCF on this. I should nudge it. o FTP imposes an antiquated limit of 254 on JESLRECL. This should be fodder for an RFE. o LRECL= is allowed on DD SYSIN. It may not have the effect you want. o But RECFM= is prohibited on DD SYSIN. Go figger. o TSO and ISPF SUBMIT are oblivious; stuck in the 20th century. ISPF submit quietly truncates to 80. I consider this data loss. o Beware that you may cause I/O errors on many utility SYSINs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
What problem are you trying to solve with INTRDR? Are you using INTRDR in JCL? Are you doing a dynamic allocation for INTRDR? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > Sent: Monday, October 17, 2016 3:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Intrdr > > All, > > I read that the Intrdr max recsize was 32760, but am I right if I punch to the > Intrdr I am still limited to 80 byte records? > > Scott > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
