Re: ISPF Edit: Introduce New SUBMIT Module
The button caused a Unit Exception on the last read; BSAM and QSAM called EODAD at that point. There is no need for /*EOF in that scenario. HASP added the /*EOF in support of the internal reader, but it was also useful for a card reader. Consider //MYJOBJOB ... ... //FOO DD * ... /*EOF ./BAD JOB ... However, a // would work just as well for that purpose. -- 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: Friday, June 25, 2021 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021 21:21:31 +, Gibney, Dave wrote: >In the days of cards, when your //SYSIN DD * might be the last file in the >current deck on the reader > The lore communicated to me was: When the reader's hopper is empty, the reader hangs on a read. Three's a button the operator can press to simulate EOF in the channel status. So, does /*EOF allow unattended operation of the reader? I believe that //name JOB ... likewise serves to terminate the previous job. How does //SYSIN DD *,DLM=XX interact with /*EOF or //name JOB ...? In a CDC 6400 OS, a job was terminated by a 6-7-8-9 punch in column 1, invalid in either text or binary encoding. I heard legends of another OS (UNISYS?) which simply stacked SYSINs on a batch input tape. If any job opened either too many SYSINs or too few, subsequent jobs read the wrong data sets. -- 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: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021 21:21:31 +, Gibney, Dave wrote: >In the days of cards, when your //SYSIN DD * might be the last file in the >current deck on the reader > The lore communicated to me was: When the reader's hopper is empty, the reader hangs on a read. Three's a button the operator can press to simulate EOF in the channel status. So, does /*EOF allow unattended operation of the reader? I believe that //name JOB ... likewise serves to terminate the previous job. How does //SYSIN DD *,DLM=XX interact with /*EOF or //name JOB ...? In a CDC 6400 OS, a job was terminated by a 6-7-8-9 punch in column 1, invalid in either text or binary encoding. I heard legends of another OS (UNISYS?) which simply stacked SYSINs on a batch input tape. If any job opened either too many SYSINs or too few, subsequent jobs read the wrong data sets. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
It causes an ENDREQ. -- 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: Thursday, June 24, 2021 5:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > >It is easy to copy some or all of the data to an internal reader, followed by >a '/*EOF'. ... > I've never needed a '/*EOF'. What's it good for? -- 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: ISPF Edit: Introduce New SUBMIT Module
In the days of cards you didn't need no stinking /*EOF -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gibney, Dave [gib...@wsu.edu] Sent: Thursday, June 24, 2021 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module In the days of cards, when your //SYSIN DD * might be the last file in the current deck on the reader > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Thursday, June 24, 2021 2:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > > > >It is easy to copy some or all of the data to an internal reader, followed > >by a > '/*EOF'. ... > > > I've never needed a '/*EOF'. What's it good for? > > -- 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: ISPF Edit: Introduce New SUBMIT Module
If you are using an ACB for job submission it terminates the stream, thus generating a job number, without closing the file. So you can keep the file open for further job submission. Strangely enough, although /*EOF is not a JES3 JECL statement, it works on JES3 as well. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 24 June 2021 22:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > >It is easy to copy some or all of the data to an internal reader, followed by >a '/*EOF'. ... > I've never needed a '/*EOF'. What's it good for? -- 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: ISPF Edit: Introduce New SUBMIT Module
In the days of cards, when your //SYSIN DD * might be the last file in the current deck on the reader > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Thursday, June 24, 2021 2:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > > > >It is easy to copy some or all of the data to an internal reader, followed > >by a > '/*EOF'. ... > > > I've never needed a '/*EOF'. What's it good for? > > -- 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: ISPF Edit: Introduce New SUBMIT Module
Like war, absolutely nothin' On Thu, Jun 24, 2021 at 5:12 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > > > >It is easy to copy some or all of the data to an internal reader, > followed by a '/*EOF'. ... > > > I've never needed a '/*EOF'. What's it good for? > > -- gil > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021 12:28:18 +, Seymour J Metz wrote: > >It is easy to copy some or all of the data to an internal reader, followed by >a '/*EOF'. ... > I've never needed a '/*EOF'. What's it good for? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
It appears to me that the way the ISPF SUBMIT command works is that it writes the member (with current updates) to ISPCTL0, then invokes the TSO SUBMIT command for that dataset. Oddly enough, this works even for a temporary dataset. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
No, I'm saying that *if* IBM ships an ISRCMDS table that means that EDIT lets ISPF look up the command. Are you referring to "ISPEXEC foo""? That goes through TSO command processing before handing foo off to ISPF, while ADDRESS ISPEXEC "oo" hads of foo dirctly to ISPF. BTW, the text in the manual must have been written in the Paleolithic; it mentions CLIST but not REXX. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] Sent: Thursday, June 24, 2021 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021, at 16:38, Seymour J Metz wrote: > Is there an ISRCMDS tables? If so, that's how EDIT recognizes its > command. Are you sure? You're saying that ispf edit presents the panel then doesn't immediately process the command line to parse its own valid commands? Or does it (if such a command table exists) set each internal cmd to ... trying to remember ... "PASSTHRU" is it? Why would it introduce an extra layer of command processing for its own commands? > Also it's valid to specify SELECT PGM(foo) in a command table. That's why I said "or programs" in "other commands (ie clists, rexx execs or tso command processors) or programs " meaning either select cmd() or select pgm(). A lot of people, in my recollection, assumed that select cmd() could not pass control to a load module, whereas it could ... if that was a (tso) command processor. -- Jeremy Nicoll - my opinions are my own. -- 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: ISPF Edit: Introduce New SUBMIT Module
What kind of PLIST does the program expect? What was the full message? Are you saying that an entry of SELECT CMD($MD) called SUB? What was the table name? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, June 24, 2021 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module Hi R'Shmuel AMV"SH, I tried PGM(foo) and got ABEND 66D Code 02. I tried CMD(foo), but, that gave me the TSO "version" of SUBMIT, including a prompt for DSNAME. What I really want is to invoke foo the same way that ISPF EDIT/VIEW/BROWSE invokes SUBMIT. That is, it SUBMITs what the user is EDITin/BROWSEing/VIEWing. Thanks and regards, David On 2021-06-24 11:38, Seymour J Metz wrote: > Is there an ISRCMDS tables? If so, that's how EDIT recognizes its command. > Also it's valid to specify SELECT PGM(foo) in a command table. > > > -- > Shmuel (Seymour J.) Metz > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C8f10a8dd8c93401a105908d937263722%7C84df9e7fe9f640afb435%7C1%7C0%7C637601459577261428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WD9bJTFgTb9vqcu1%2BTDsYFSUiiFTlOskqq8j%2BHMfg9c%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] > Sent: Thursday, June 24, 2021 10:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > On Thu, 24 Jun 2021, at 14:55, David Spiegel wrote: >> Hi Jeremy, >> I have an existing RYO SUBMIT Assembler program. >> (Also, without Control Block chasing, I have not a way to access RPLRBAR >> (for Job Number).) > How does that answer my question? > > Why would you not wrap your existing code in just enough ispf macro > assembler to make it work? > > > I noticed that other people talked about ispf command table processing > in answer to your question about how ispf recognises a "submit" command, > but I'm under-convinced that command tables are relevant. Surely ispf edit > recognises all its command line commands because it parses the command > line to determine what it's being asked to do? > > Command tables are (or used to be) only for starting other commands (ie > clists, rexx execs or tso command processors) or programs from any ispf > command line on arbitrary panels in any application. Eg the "tso" that one > can type before a tso command on a commandline executes a "select ..." > via a command-table definition (or it used to). > > -- > Jeremy Nicoll - my opinions are my own. > > -- > 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: ISPF Edit: Introduce New SUBMIT Module
Hi R'Shmuel AMV"SH, I tried PGM(foo) and got ABEND 66D Code 02. I tried CMD(foo), but, that gave me the TSO "version" of SUBMIT, including a prompt for DSNAME. What I really want is to invoke foo the same way that ISPF EDIT/VIEW/BROWSE invokes SUBMIT. That is, it SUBMITs what the user is EDITin/BROWSEing/VIEWing. Thanks and regards, David On 2021-06-24 11:38, Seymour J Metz wrote: Is there an ISRCMDS tables? If so, that's how EDIT recognizes its command. Also it's valid to specify SELECT PGM(foo) in a command table. -- Shmuel (Seymour J.) Metz https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C8f10a8dd8c93401a105908d937263722%7C84df9e7fe9f640afb435%7C1%7C0%7C637601459577261428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WD9bJTFgTb9vqcu1%2BTDsYFSUiiFTlOskqq8j%2BHMfg9c%3Dreserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] Sent: Thursday, June 24, 2021 10:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021, at 14:55, David Spiegel wrote: Hi Jeremy, I have an existing RYO SUBMIT Assembler program. (Also, without Control Block chasing, I have not a way to access RPLRBAR (for Job Number).) How does that answer my question? Why would you not wrap your existing code in just enough ispf macro assembler to make it work? I noticed that other people talked about ispf command table processing in answer to your question about how ispf recognises a "submit" command, but I'm under-convinced that command tables are relevant. Surely ispf edit recognises all its command line commands because it parses the command line to determine what it's being asked to do? Command tables are (or used to be) only for starting other commands (ie clists, rexx execs or tso command processors) or programs from any ispf command line on arbitrary panels in any application. Eg the "tso" that one can type before a tso command on a commandline executes a "select ..." via a command-table definition (or it used to). -- Jeremy Nicoll - my opinions are my own. -- 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: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021, at 16:38, Seymour J Metz wrote: > Is there an ISRCMDS tables? If so, that's how EDIT recognizes its > command. Are you sure? You're saying that ispf edit presents the panel then doesn't immediately process the command line to parse its own valid commands? Or does it (if such a command table exists) set each internal cmd to ... trying to remember ... "PASSTHRU" is it? Why would it introduce an extra layer of command processing for its own commands? > Also it's valid to specify SELECT PGM(foo) in a command table. That's why I said "or programs" in "other commands (ie clists, rexx execs or tso command processors) or programs " meaning either select cmd() or select pgm(). A lot of people, in my recollection, assumed that select cmd() could not pass control to a load module, whereas it could ... if that was a (tso) command processor. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
> I need help to figure out how to add a new Primary Command to ISPF Edit, > so that I can test a RYO SUBMIT Command written in Assembler. David, Define your own command table using the ISPF Command Table Utility aka 3.9 https://www.ibm.com/docs/en/zos/2.4.0?topic=commands-using-command-tables-define Bruce Koss presented at share about how to add your own commands to the command table https://share.confex.com/share/119/webprogram/Handout/Session11559/11559%20-%20An%20Experienced%20ISPF%20User%20Shares%20his%20Secrets.pdf Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
Is there an ISRCMDS tables? If so, that's how EDIT recognizes its command. Also it's valid to specify SELECT PGM(foo) in a command table. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org] Sent: Thursday, June 24, 2021 10:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module On Thu, 24 Jun 2021, at 14:55, David Spiegel wrote: > Hi Jeremy, > I have an existing RYO SUBMIT Assembler program. > (Also, without Control Block chasing, I have not a way to access RPLRBAR > (for Job Number).) How does that answer my question? Why would you not wrap your existing code in just enough ispf macro assembler to make it work? I noticed that other people talked about ispf command table processing in answer to your question about how ispf recognises a "submit" command, but I'm under-convinced that command tables are relevant. Surely ispf edit recognises all its command line commands because it parses the command line to determine what it's being asked to do? Command tables are (or used to be) only for starting other commands (ie clists, rexx execs or tso command processors) or programs from any ispf command line on arbitrary panels in any application. Eg the "tso" that one can type before a tso command on a commandline executes a "select ..." via a command-table definition (or it used to). -- Jeremy Nicoll - my opinions are my own. -- 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: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021, at 14:55, David Spiegel wrote: > Hi Jeremy, > I have an existing RYO SUBMIT Assembler program. > (Also, without Control Block chasing, I have not a way to access RPLRBAR > (for Job Number).) I should have added to my previous answer: - depending on how you've written your RYO submit, it might already (almost) work if you merely invoke it by preceding its member name with a "!" (as one has to for assembler - or I guess more properly - load module macros). - How does your RYO solution access the contents of an edit or view file buffer without (already) using ispf services via isplink or ispexec? - ISTR you wanted to TPUT info to the screen? Why would you do that when instead you could use SETMSG to display it in a standard ispf message? -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021, at 14:55, David Spiegel wrote: > Hi Jeremy, > I have an existing RYO SUBMIT Assembler program. > (Also, without Control Block chasing, I have not a way to access RPLRBAR > (for Job Number).) How does that answer my question? Why would you not wrap your existing code in just enough ispf macro assembler to make it work? I noticed that other people talked about ispf command table processing in answer to your question about how ispf recognises a "submit" command, but I'm under-convinced that command tables are relevant. Surely ispf edit recognises all its command line commands because it parses the command line to determine what it's being asked to do? Command tables are (or used to be) only for starting other commands (ie clists, rexx execs or tso command processors) or programs from any ispf command line on arbitrary panels in any application. Eg the "tso" that one can type before a tso command on a commandline executes a "select ..." via a command-table definition (or it used to). -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
Hi Jeremy, I have an existing RYO SUBMIT Assembler program. (Also, without Control Block chasing, I have not a way to access RPLRBAR (for Job Number).) Regards, David On 2021-06-24 09:50, Jeremy Nicoll wrote: On Thu, 24 Jun 2021, at 03:25, David Spiegel wrote: Hi, I need help to figure out how to add a new Primary Command to ISPF Edit, so that I can test a RYO SUBMIT Command written in Assembler. Let's assume that my module is called $UBMIT (with an ALIAS of $UB). I do not want to write an Edit Macro to do this. (I already wrote one of these). nor do want to invoke an Edit Macro which will call the Command Processor. Why precisely is an edit macro not an adequate solution, if you write it in assembler? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021, at 03:25, David Spiegel wrote: > Hi, > I need help to figure out how to add a new Primary Command to ISPF Edit, > so that I can test a RYO SUBMIT Command written in Assembler. > Let's assume that my module is called $UBMIT (with an ALIAS of $UB). > I do not want to write an Edit Macro to do this. (I already wrote one of > these). nor do want to invoke an Edit Macro which will call the Command > Processor. Why precisely is an edit macro not an adequate solution, if you write it in assembler? -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
Why would it require authorization? Just adding it to the ISPF command table or to SELECT on relevant panels should be enough. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Lizette Koehler [stars...@mindspring.com] Sent: Wednesday, June 23, 2021 11:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module Just a guess But look at SYS1.PARMLIB member IKJTSOxx Or use the TSO Command PARMLIB To see where it exists, what member it is, and what the contents are You might need to set up something in this member AUTHCMD AUTHPGM etc... Is the module a TSO Command Processor? https://www.ibm.com/docs/en/zos/2.1.0?topic=reference-tsoe-commands-subcommands Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Wednesday, June 23, 2021 7:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Edit: Introduce New SUBMIT Module Hi, I need help to figure out how to add a new Primary Command to ISPF Edit, so that I can test a RYO SUBMIT Command written in Assembler. Let's assume that my module is called $UBMIT (with an ALIAS of $UB). I do not want to write an Edit Macro to do this. (I already wrote one of these). nor do want to invoke an Edit Macro which will call the Command Processor. (The user will type $UB on the Edit Command Line and use the RYO program instead of the IBM-supplied SUB.) (As an aside, one of the reasons it has to be written in Assembler is so that the program can access the INTRDR's RPLRBAR and thereby TPUT the Job Number after SUBMIT.) Another related question: How does ISPF "know" what SUBMIT means? Thank you in advance, David -- 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: ISPF Edit: Introduce New SUBMIT Module
Hi R'Shmuel AMV"SH,
I am aware that ISPF EDIT calls SUBMIT.
I want to be able to call a pre-existing Assembler program (which is in
a PDS ahead of SYS1.CMDLIB and will be renamed to $UBMIT (thereby
"exposing" the IBM SUBMIT)) by changing one character of the ISPF
Primary Command, so that for an interim period, users can use either the
IBM SUBMIT or the RYO SUBMIT. If all goes well, I am planning to retire
the RYO SUBMIT after a trial period.
Thanks and regards,
David
On 2021-06-24 08:28, Seymour J Metz wrote:
ISPF EDIT SUBMIT calls TSO SUBMIT. Did you mean that you want to RYO?
It is easy to copy some or all of the data to an internal reader, followed by a
'/*EOF'. If you need to capture the jobid, a small assembler program can do
that using the ACB/RPL interface.
--
Shmuel (Seymour J.) Metz
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C66e3e9ba8d374ad1013c08d9370b966f%7C84df9e7fe9f640afb435%7C1%7C0%7C637601345181896421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=BkvKEHYwu%2BVSrDCQoAwda4mOndOH0VXjMGGN2FOYLiI%3Dreserved=0
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Spiegel [dspiegel...@hotmail.com]
Sent: Thursday, June 24, 2021 6:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do
an ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for
DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
You can call you program anything you want and create a command table entry for
it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
i.e. (look in option 3.9 of ISPF) and add
YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
Then when the user types "yourCMD" it will invoke "yourPGM"
The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
'somedataset(member)'".
However, if you call your program SUBMIT then it will work outside of ISPF as well,
although it will work if you called it yourPGM just as well. The command table just
keeps them from having to type "TSO yourPGM" instead of just yourPGM or yourCMD.
In any case, you don't want to replace IBM's submit, you just want to make sure
that yours is located before IBM's in either a steplib or in a linklist dataset
that occurs BEFORE sys1.cmdlib.
I think using the name SUBMIT is a really really bad idea, unless you are going
to create a alias for IBM's submit (maybe call it IBMSUB), so that if need be
you can use it in case yours fails.
--
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: ISPF Edit: Introduce New SUBMIT Module
ISPF EDIT SUBMIT calls TSO SUBMIT. Did you mean that you want to RYO?
It is easy to copy some or all of the data to an internal reader, followed by a
'/*EOF'. If you need to capture the jobid, a small assembler program can do
that using the ACB/RPL interface.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Spiegel [dspiegel...@hotmail.com]
Sent: Thursday, June 24, 2021 6:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do
an ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for
DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
> You can call you program anything you want and create a command table entry
> for it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
>
>
> i.e. (look in option 3.9 of ISPF) and add
>
> YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
>
>
> Then when the user types "yourCMD" it will invoke "yourPGM"
>
> The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
> 'somedataset(member)'".
>
> However, if you call your program SUBMIT then it will work outside of ISPF as
> well, although it will work if you called it yourPGM just as well. The
> command table just keeps them from having to type "TSO yourPGM" instead of
> just yourPGM or yourCMD.
>
>
> In any case, you don't want to replace IBM's submit, you just want to make
> sure that yours is located before IBM's in either a steplib or in a linklist
> dataset that occurs BEFORE sys1.cmdlib.
>
> I think using the name SUBMIT is a really really bad idea, unless you are
> going to create a alias for IBM's submit (maybe call it IBMSUB), so that if
> need be you can use it in case yours fails.
>
> --
> 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: ISPF Edit: Introduce New SUBMIT Module
I don't see where the OP is asking for the job number. If he doesn't need it, then there's no need for any assembler code. If he does need the job number, then OUTTRAP won't help, since he doesn't want to use SUBMIT. In that case, a small program using ACB/RPL can copy to the internal reader and return the jobid. There's probably already something on the CBTTAPE that does that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of ITschak Mugzach [imugz...@gmail.com] Sent: Thursday, June 24, 2021 8:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Edit: Introduce New SUBMIT Module In this case I would write a small rexx program to call the assembler. As it is rexx, the name typed assumed to be a macro. BTW, the problem can easily be solved by rexx OUTTRAP (to capture the job number). ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Thu, Jun 24, 2021 at 2:46 PM Rupert Reynolds wrote: > > > > > > > If I read this right, OP is asking for a replacement for the edit SUB > command, which does some alternative processing before the job is > submitted, but is basically quite similar to the original SUB. > > If a Rexx EDIT macro is not acceptable, my first instinct is to look for a > zOS exit that runs when writing to the internal reader, or a JES2 exit that > runs when jobs are submitted (there will be more than 1). > > As an alternative, can automation do what's required? > > Roops > > > . > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of David Spiegel > > Sent: Thursday, June 24, 2021 5:09 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > > > Hi Brian, > > I am familiar with the Command Table. I want to set up a command to do an > > ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME. > > That is, SUBMIT what is being EDITd/BROWSEd/VIEWd. > > > > Thanks and regards, > > David > > > > > > > > -- > 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: ISPF Edit: Introduce New SUBMIT Module
In this case I would write a small rexx program to call the assembler. As it is rexx, the name typed assumed to be a macro. BTW, the problem can easily be solved by rexx OUTTRAP (to capture the job number). ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Thu, Jun 24, 2021 at 2:46 PM Rupert Reynolds wrote: > > > > > > > If I read this right, OP is asking for a replacement for the edit SUB > command, which does some alternative processing before the job is > submitted, but is basically quite similar to the original SUB. > > If a Rexx EDIT macro is not acceptable, my first instinct is to look for a > zOS exit that runs when writing to the internal reader, or a JES2 exit that > runs when jobs are submitted (there will be more than 1). > > As an alternative, can automation do what's required? > > Roops > > > . > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of David Spiegel > > Sent: Thursday, June 24, 2021 5:09 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > > > Hi Brian, > > I am familiar with the Command Table. I want to set up a command to do an > > ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME. > > That is, SUBMIT what is being EDITd/BROWSEd/VIEWd. > > > > Thanks and regards, > > David > > > > > > > > -- > 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: ISPF Edit: Introduce New SUBMIT Module
> > > If I read this right, OP is asking for a replacement for the edit SUB command, which does some alternative processing before the job is submitted, but is basically quite similar to the original SUB. If a Rexx EDIT macro is not acceptable, my first instinct is to look for a zOS exit that runs when writing to the internal reader, or a JES2 exit that runs when jobs are submitted (there will be more than 1). As an alternative, can automation do what's required? Roops > . -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of David Spiegel > Sent: Thursday, June 24, 2021 5:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Edit: Introduce New SUBMIT Module > > Hi Brian, > I am familiar with the Command Table. I want to set up a command to do an > ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME. > That is, SUBMIT what is being EDITd/BROWSEd/VIEWd. > > Thanks and regards, > David > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
What you are trying to do is effectively an ISPF Edit Macro that you call $UB,
and it will work with Edit and View. You can code an edit macro in assembler.
It is just a load module that would reside in ISPLLIB (or steplib or linklist).
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck
“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.” - - - John Wooden
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Spiegel
Sent: Thursday, June 24, 2021 5:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do an ISPF
Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
> You can call you program anything you want and create a command table entry
> for it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
>
>
> i.e. (look in option 3.9 of ISPF) and add
>
> YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
>
>
> Then when the user types "yourCMD" it will invoke "yourPGM"
>
> The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
> 'somedataset(member)'".
>
> However, if you call your program SUBMIT then it will work outside of ISPF as
> well, although it will work if you called it yourPGM just as well. The
> command table just keeps them from having to type "TSO yourPGM" instead of
> just yourPGM or yourCMD.
>
>
> In any case, you don't want to replace IBM's submit, you just want to make
> sure that yours is located before IBM's in either a steplib or in a linklist
> dataset that occurs BEFORE sys1.cmdlib.
>
> I think using the name SUBMIT is a really really bad idea, unless you are
> going to create a alias for IBM's submit (maybe call it IBMSUB), so that if
> need be you can use it in case yours fails.
>
> --
> 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: ISPF Edit: Introduce New SUBMIT Module
So write an edit macro to copy the all the lines onto a Rexx stack and use
"SUBMIT * END(//)" (or similar) to submit it! You can then use OUTTRAP() to
capture the message from SUBMIT and stop the screen breaking up.
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Spiegel
Sent: 24 June 2021 17:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do an ISPF
Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
> You can call you program anything you want and create a command table entry
> for it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
>
>
> i.e. (look in option 3.9 of ISPF) and add
>
> YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
>
>
> Then when the user types "yourCMD" it will invoke "yourPGM"
>
> The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
> 'somedataset(member)'".
>
> However, if you call your program SUBMIT then it will work outside of ISPF as
> well, although it will work if you called it yourPGM just as well. The
> command table just keeps them from having to type "TSO yourPGM" instead of
> just yourPGM or yourCMD.
>
>
> In any case, you don't want to replace IBM's submit, you just want to make
> sure that yours is located before IBM's in either a steplib or in a linklist
> dataset that occurs BEFORE sys1.cmdlib.
>
> I think using the name SUBMIT is a really really bad idea, unless you are
> going to create a alias for IBM's submit (maybe call it IBMSUB), so that if
> need be you can use it in case yours fails.
>
> --
> 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: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do
an ISPF Edit SUBMIT, not a TSO SUBMIT. That also means no for
DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
You can call you program anything you want and create a command table entry for
it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
i.e. (look in option 3.9 of ISPF) and add
YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
Then when the user types "yourCMD" it will invoke "yourPGM"
The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
'somedataset(member)'".
However, if you call your program SUBMIT then it will work outside of ISPF as well,
although it will work if you called it yourPGM just as well. The command table just
keeps them from having to type "TSO yourPGM" instead of just yourPGM or yourCMD.
In any case, you don't want to replace IBM's submit, you just want to make sure
that yours is located before IBM's in either a steplib or in a linklist dataset
that occurs BEFORE sys1.cmdlib.
I think using the name SUBMIT is a really really bad idea, unless you are going
to create a alias for IBM's submit (maybe call it IBMSUB), so that if need be
you can use it in case yours fails.
--
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: ISPF Edit: Introduce New SUBMIT Module
You can call you program anything you want and create a command table entry for
it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
i.e. (look in option 3.9 of ISPF) and add
YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
Then when the user types "yourCMD" it will invoke "yourPGM"
The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
'somedataset(member)'".
However, if you call your program SUBMIT then it will work outside of ISPF as
well, although it will work if you called it yourPGM just as well. The command
table just keeps them from having to type "TSO yourPGM" instead of just yourPGM
or yourCMD.
In any case, you don't want to replace IBM's submit, you just want to make sure
that yours is located before IBM's in either a steplib or in a linklist dataset
that occurs BEFORE sys1.cmdlib.
I think using the name SUBMIT is a really really bad idea, unless you are going
to create a alias for IBM's submit (maybe call it IBMSUB), so that if need be
you can use it in case yours fails.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
Have a look at ISPF 3.9 (COMMAND). This is the command table where you define new primary commands to ISPF. At end, copy table ISPCMDS (or ISRCMDS depending on your APPL id) to the first dataset in ISPTLIB concatanation to make it public to all users. As per your second question, There are commands that are built-in in ISPF and others that are define to the command table. for example. your program can be defined as CMD($UBMIT) for the name you want to use under ISPF. TSO parmlib only needed if the program is authorized (TSO, by definition is unauthorized). HTH *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Thu, Jun 24, 2021 at 5:25 AM David Spiegel wrote: > Hi, > I need help to figure out how to add a new Primary Command to ISPF Edit, > so that I can test a RYO SUBMIT Command written in Assembler. > Let's assume that my module is called $UBMIT (with an ALIAS of $UB). > I do not want to write an Edit Macro to do this. (I already wrote one of > these). nor do want to invoke an Edit Macro which will call the Command > Processor. > > (The user will type $UB on the Edit Command Line and use the RYO program > instead of the IBM-supplied SUB.) > > (As an aside, one of the reasons it has to be written in Assembler is so > that the program can access the INTRDR's RPLRBAR and thereby TPUT the > Job Number after SUBMIT.) > > Another related question: How does ISPF "know" what SUBMIT means? > > Thank you in advance, > David > > -- > 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: ISPF Edit: Introduce New SUBMIT Module
Just a guess But look at SYS1.PARMLIB member IKJTSOxx Or use the TSO Command PARMLIB To see where it exists, what member it is, and what the contents are You might need to set up something in this member AUTHCMD AUTHPGM etc... Is the module a TSO Command Processor? https://www.ibm.com/docs/en/zos/2.1.0?topic=reference-tsoe-commands-subcommands Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Wednesday, June 23, 2021 7:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Edit: Introduce New SUBMIT Module Hi, I need help to figure out how to add a new Primary Command to ISPF Edit, so that I can test a RYO SUBMIT Command written in Assembler. Let's assume that my module is called $UBMIT (with an ALIAS of $UB). I do not want to write an Edit Macro to do this. (I already wrote one of these). nor do want to invoke an Edit Macro which will call the Command Processor. (The user will type $UB on the Edit Command Line and use the RYO program instead of the IBM-supplied SUB.) (As an aside, one of the reasons it has to be written in Assembler is so that the program can access the INTRDR's RPLRBAR and thereby TPUT the Job Number after SUBMIT.) Another related question: How does ISPF "know" what SUBMIT means? Thank you in advance, David -- 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
