Re: SMP/E and IDR (was: Binder SETSSI ...?)
How would this work for ++MOD elements in RELFILE format. Should I supply the IDENTIFY as input to Binder when I link the ++MOD element so Binder will imbed it in the IDR? Same for ACCEPT into DLIB? Yes. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. Huh? I assume you're talking about the SYSLIN for a link edit step in JCLIN. SMP/E recognizes some binder control statements, and some it does not. INCLUDE, NAME, CHANGE, REPLACE, and ALIAS are recognized and processed very specifically. Any other control statements found in the JCLIN, including IDENTIFY, are not recognized by SMP/E, but rather are simply saved and passed somewhat blindly to the binder when the load module (or program object) is linked. Passing IDENTIFY blindly to the binder would likely give you incorrect results, because as I think someone already mentioned, IDENTIFY must follow the module it is associated with, and SMP/E does not preserve this association for IDENTIFY. If you want to use IDENTIFY, you should append it to the module object deck described by ++MOD. This is how IBM does it for many (all?) of its PTFS. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
On Tue, 2 Dec 2014 09:13:56 -0500, Kurt Quackenbush wrote: OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. Huh? I assume you're talking about the SYSLIN for a link edit step in JCLIN. For my first use of SYSLIN I meant the DDNAME output from HLASM; I could/should have said SYSPUNCH. For the second, I meant, and should have said, ... Binder commands in instream MOD elements. ... SMP/E recognizes some binder control statements, and some it does not. INCLUDE, NAME, CHANGE, REPLACE, and ALIAS are recognized and processed very specifically. Any other control statements found in the JCLIN, including IDENTIFY, are not recognized by SMP/E, but rather are simply saved and passed somewhat blindly to the binder when the load module (or program object) is linked. Passing IDENTIFY blindly to the binder would likely give you incorrect results, because as I think someone already mentioned, IDENTIFY must follow the module it is associated with, and SMP/E does not preserve this association for IDENTIFY. It probably gets worse with RESTORE. If you want to use IDENTIFY, you should append it to the module object deck described by ++MOD. This is how IBM does it for many (all?) of its PTFS. I have known SMP/E to report errors on finding junk in inline ++MOD elements. But today, I can't force the error; junk lines are simply RECEIVEd intact into the SMPPTS. I see no evidence of them in the SYSPRINT from APPLY; my test lines should have caused errors. How would this work for ++MOD elements in RELFILE format. Should I supply the IDENTIFY as input to Binder when I link the ++MOD element so Binder will imbed it in the IDR? Same for ACCEPT into DLIB? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In 8902901628988927.wa.paulgboulderaim@listserv.ua.edu, on 11/30/2014 at 11:51 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: Can this information be supplied from HLASM Yes. (but this would be harder for us to automate.) Why can't you pass the necessary variables through SYSPARM? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In CAE1XxDHQB8Mn99LQZcydqGc5QHGPR5HJC-bNPmv0H==um7c...@mail.gmail.com, on 11/30/2014 at 01:19 PM, John Gilmore jwgli...@gmail.com said: AINSERT is then used to 'save' them, and AREAD is used to put them into the output. That's not even wrong! He needs a PUNCH or REPRO to get them into the output. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
Shmuel was, of course, entirely correct in saying that a PUNCH or REPRO statement is necessary to get them into the output; but this surpassingly obvious observation is not very interesting. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: They must follow the section---CSECT, RSECT, or labeled-common block---to which they refer; and great care is required in those situations in which sections are assembled in non-contrigtuous pieces, when, e.g., such constructions as |ALFACSECT | . . . |BETA CSECT | . . . |ALFACSECT | . . . are used, as I learned to to my sorrow on another occasion. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 19:32:45 -0500, Shmuel Metz (Seymour J.) wrote: at 11:51 AM, Paul Gilmartin said: Can this information be supplied from HLASM Yes. Can it be more straightforward than JWG's suggestion? (but this would be harder for us to automate.) Why can't you pass the necessary variables through SYSPARM? That might require editing every source file (of hundreds) to parse and elaborate SYSPARM. (In fact, it might be necessary only to edit a common header macro.) OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
In CAE1XxDG4NRGnr2hk-=cdsgdxqs1nuv7ucbru4ntyy_ebkmx...@mail.gmail.com, on 12/01/2014 at 11:18 AM, John Gilmore jwgli...@gmail.com said: surpassingly obvious It should have been obvious *before* you incorrrecvtly described the roles in AINSERT and AREAD. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: No, although it is certainly possible that you wrote something with convoluted logic that works that way. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
At 11:18 -0500 on 12/01/2014, John Gilmore wrote about Re: SMP/E and IDR (was: Binder SETSSI ...?): Shmuel was, of course, entirely correct in saying that a PUNCH or REPRO statement is necessary to get them into the output; but this surpassingly obvious observation is not very interesting. The AINSERTs and AREADs are needed to sequence IDENTIFY binder control statements properly: They must follow the section---CSECT, RSECT, or labeled-common block---to which they refer; and great care is required in those situations in which sections are assembled in non-contrigtuous pieces, when, e.g., such constructions as |ALFACSECT | . . . |BETA CSECT | . . . |ALFACSECT | . . . are used, as I learned to to my sorrow on another occasion. Everyone is forgetting/ignoring the need for these commands to occur AFTER the end of the object deck. IOW: If I am in in JCL I would reference the Object Deck and then do a DD * to insert the commands. While you can use a PUNCH to generate the command during assembly there is no way (to my knowledge) to do DEFERRED PUNCH (ie: For the PUNCH output to be queued and then flushed once the END statement has been processed). The closest method I can think of is to make the assembly a BATCH assembly where the first input is the actual code and the 2nd is the set of PUNCH Statements. IOW: CSECT . . . END PUNCH . . PUNCH John Gilmore, Ashland, MA 01721 - USA -- 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: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 11:51:39 -0600, Paul Gilmartin wrote: On Sun, 30 Nov 2014 09:03:18 -0500, John Gilmore wrote: The availability of control-section specific IDRs and the IDENTIFY binder control statement have, however, made SETSSI obsolescent. Does SMP/E support the Binder IDENTIFY statement? I don't see it mentioned among LKED CONTROL in: LMOD entry (distribution and target zone) SMP/E for z/OS Reference SA23-2276-01 http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/ident.htm URL should have been: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim2000/enttlm.htm Clearly, this should be specific to a particular service level of each MOD element, but I see nothing akin to a LKED CONTROL subentry on a MOD entry (op. cit.) Can this information be supplied from HLASM (but this would be harder for us to automate.) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 13:19:31 -0500, John Gilmore wrote: One formats the text of an IDENTIFY control statement as a sequence of character set symbols that are card images. AINSERT is then used to 'save' them, and AREAD is used to put them into the output. Feels a lot like PUNCH. This really ought to be an assembler intrinsic, or at least in SYS1.MACLIB. I would be happy to work through an example with you. Thanks. The descriptions are in HLASM and/or Binder manuals; I'll try to RTFM if desired. On 11/30/14, John Gilmore wrote: About Linker IDENTIFY control statement Paul Gilmartin wrote The answer is yes. The only sequencing requirement is that a sections IDENTIFYs must follow it (or, of course, its insertion point). follow it? The it being: o The ESD record that introduces the CSECT? o The first TXT record of the CSECT? o The last TXT record of the CSECT? I don't know how much control HLASM gives over position of AREAD (PUNCH?) output relative to ESD and TEXT records. We have a SECTIONPROLOGUE convention (that can't be the name of a library macro (alas); it's at least a SYSPRINT eyecatcher.) If this were to be incorporated in a MACRO; AINSERT is deferred; elaborated only upon return to open code. If (probably) the AREAD must follow the elaboration of the AINSERT, can the AREAD be AINSERTed? This might be of little use. Either the customer sends a dump, in which case we rely on TXT eyecatchers, or we (less probably) ask for a query of the SMP/E MOD entry, in which case the desired information appears as the RMID subentry. We already do some postprocessing of SYSPUNCH (in order to insert SMP/E CSECT arguments). We might insert Binder IDENTIFY commands there, also. 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: SMP/E and IDR (was: Binder SETSSI ...?)
It sure does. Ed On Nov 30, 2014, at 11:51 AM, Paul Gilmartin wrote: On Sun, 30 Nov 2014 09:03:18 -0500, John Gilmore wrote: The availability of control-section specific IDRs and the IDENTIFY binder control statement have, however, made SETSSI obsolescent. Does SMP/E support the Binder IDENTIFY statement? I don't see it mentioned among LKED CONTROL in: LMOD entry (distribution and target zone) SMP/E for z/OS Reference SA23-2276-01 http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/ com.ibm.zos.v2r1.ieab100/ident.htm Clearly, this should be specific to a particular service level of each MOD element, but I see nothing akin to a LKED CONTROL subentry on a MOD entry (op. cit.) Can this information be supplied from HLASM (but this would be harder for us to automate.) 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: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 16:05:04 -0600, Ed Gould wrote: It sure does. Cite? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
A large percent (all?) of IBM SMP maintenance comes along with a setssi card. Not exactly what I was looking for but I think it will do: http://publibz.boulder.ibm.com/epubs/pdf/gim3rf01.pdf v The only IMASPZAP control statements allowed in a SYSMOD are: Control statements ABSDUMP DUMP NAME VER ABSDUMPT DUMPT REP VERIFY BASE IDRDATA SETSSI A setssi Card is valid for the binder. On Nov 30, 2014, at 7:38 PM, Paul Gilmartin wrote: On Sun, 30 Nov 2014 16:05:04 -0600, Ed Gould wrote: It sure does. Cite? 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: SMP/E and IDR (was: Binder SETSSI ...?)
On Sun, 30 Nov 2014 22:53:22 -0600, Ed Gould wrote: A large percent (all?) of IBM SMP maintenance comes along with a setssi card. Not exactly what I was looking for but I think it will do: http://publibz.boulder.ibm.com/epubs/pdf/gim3rf01.pdf v The only IMASPZAP control statements allowed in a SYSMOD are: Control statements ABSDUMP DUMP NAME VER ABSDUMPT DUMPT REP VERIFY BASE IDRDATA SETSSI A setssi Card is valid for the binder. But I was asking about IDENTIFY. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
Paul: I am not going to do your homework. IDENTIFY is a valid binder control statement so it must work in SMPE. Ed On Nov 30, 2014, at 11:10 PM, Paul Gilmartin wrote: On Sun, 30 Nov 2014 22:53:22 -0600, Ed Gould wrote: A large percent (all?) of IBM SMP maintenance comes along with a setssi card. Not exactly what I was looking for but I think it will do: http://publibz.boulder.ibm.com/epubs/pdf/gim3rf01.pdf v The only IMASPZAP control statements allowed in a SYSMOD are: Control statements ABSDUMP DUMP NAME VER ABSDUMPT DUMPT REP VERIFY BASE IDRDATA SETSSI A setssi Card is valid for the binder. But I was asking about IDENTIFY. -- 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: SMP/E and IDR (was: Binder SETSSI ...?)
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim1000/lmodacc.htm?lang=en On Sun, Nov 30, 2014 at 11:42 PM, Ed Gould edgould1...@comcast.net wrote: Paul: I am not going to do your homework. IDENTIFY is a valid binder control statement so it must work in SMPE. Ed On Nov 30, 2014, at 11:10 PM, Paul Gilmartin wrote: On Sun, 30 Nov 2014 22:53:22 -0600, Ed Gould wrote: A large percent (all?) of IBM SMP maintenance comes along with a setssi card. Not exactly what I was looking for but I think it will do: http://publibz.boulder.ibm.com/epubs/pdf/gim3rf01.pdf v The only IMASPZAP control statements allowed in a SYSMOD are: Control statements ABSDUMP DUMP NAME VER ABSDUMPT DUMPT REP VERIFY BASE IDRDATA SETSSI A setssi Card is valid for the binder. But I was asking about IDENTIFY. -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
