Re: Adding a patch area
On 7/25/2018 8:46 AM, Jesse 1 Robinson wrote: There's no 'trick' to sawing a pretty lady in half if you know how to do it. Ed's analysis of the patch-area logic is spot on, but he is an ISV in control of his own code. If this was an installation exit, I'd fix it myself, but the module is provided source-free by a vendor. If Ed had a similar problem with a product like, say, CICS, he'd be in the same fix we're in. I’m not wedded to S-CONs, but they can simplify life in managing patch areas. I'm truly not sure what "trick" it is you think you're half-remembering here, but if you don't have assembler source code, then S-CONs don't simplify anything. They don't even exist! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
EXPAND expands the size of a CSECT; that's all it does. And we don't need no stinking S-con in the path area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, July 24, 2018 5:26 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Adding a patch area On Tue, 24 Jul 2018 20:17:05 +, Jesse 1 Robinson wrote: >Thanks! There's also a trick to create S-type constants with base-displacement >values to simplify branching into a patch area at the right spot. > I don't see this in the description of the EXPAND statement (but I didn't check the Advanced Facilities volume.) >-iriginal Message- >From: John Eells >Sent: Tuesday, July 24, 2018 9:38 AM > >Perhaps the Binder's EXPAND statement will do what you need. -- 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: Adding a patch area
While I will admit under duress to having coded hexadecimal patches, my preferred mode is to use a zapmaker; a program that postprocesses assembler output to generate the AMASPZAP input. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Wednesday, July 25, 2018 11:46 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Adding a patch area There's no 'trick' to sawing a pretty lady in half if you know how to do it. Ed's analysis of the patch-area logic is spot on, but he is an ISV in control of his own code. If this was an installation exit, I'd fix it myself, but the module is provided source-free by a vendor. If Ed had a similar problem with a product like, say, CICS, he'd be in the same fix we're in. I’m not wedded to S-CONs, but they can simplify life in managing patch areas. This particular 'usermod' has been utilized here for decades. Failing to implement the function altogether would impact hundreds of call center customer support folks. I'd hate to sully the mainframe's rep by admitting that we're not smart enough to keep it alive. . . 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 Ed Jaffe Sent: Tuesday, July 24, 2018 9:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Adding a patch area On 7/24/2018 7:12 PM, Jesse 1 Robinson wrote: > Yeah, touché. S-CON is an assembler thing. EXPAND is a binder thing. Have not > experimented with getting them to work together. Hoping the vendor will fix > this at the source. You're probably thinking of the ancient technique of assembling S-CONs into a patch area covered by a base register to aid in patch writing. There's no trick to it. If you defined for example 10S(*) at offset +10 from the start of your USING domain and the base was R11 you got: B010 B012 B014 B016 B018 B01A B01C B01E B020 B022 assembled at that location. You would then branch to the patch area when needed to fix a problem without reassembling. For example, if your code at +4E0 into the program was: 04E0 1B12 SR 1,2 04E2 5A10 AFB0 A 1,FIELD1 04E6 5010 AFB0 ST 1,FIELD1 and you needed to insert another subtract after the SR, you could patch that in pretty easily. Something like: VER 0010 B010,B012,B014,B016,B018 VER 04E2 5A10,AFB0 A 1,FIELD1 REP 0010 5B10,AFB4 S 1,FIELD2 REP 0014 5A10,AFB0 A 1,FIELD1 REP 0018 07FE BR 14 REP 04E2 45E0,B010 BAL 14,patch These days anything produced by a modern compiler and any serious, hand-written assembler code written in the last 20 years likely no longer uses those highly-restrictive S/360 programming techniques (aka "stone knives and bear skins") where a base register gave you a mere 4K of *forward* addressability PER REGISTER! 100% of our in-house-developed products use relative-to-PSW branching -- usually short (+/- 64K branch range) and sometimes long (+/- 2G branch range) -- exclusively for intra-CSECT branching. (Since z/OS 1.7 you've been able to use relative branches for inter-CSECT branches as well, but we do do that.) We use long (20-bit) displacement instructions (+/- 512K range per base register) for storage references as well. Patch areas still make sense, but S-CONs surely don't unless the patch area is defined as part of the program literals -- and THAT would be a tremendous waste of a precious 4K base register resource. Some things are best forgotten. After writing this, I wish I had followed my own advice... LOL -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1TGKEPtDiLuWByAn_86KpvY8BlGv-5cOL6dH_91DVYHPlfoNYkNxqIrs6_1lhpf_V3kX3vWxzYNBdSbyZXavly8fVbNRrKDcmW3LQqUc70XD5cx_ZcYqxYbZQKkbKobgwmyOQ-wxdRtbwTf8BhPLdk2RO3C0ecPttGU_6l_PqpKdmUzrU8GabZJhYY54K_dAgPIJyImCzK3N6q_s3Tt0xjPEA9kuy2yXb19WnUBFiNjpTb2aonXUDD9HftSbz0pLKC_Dl7jkRtywdsM8l3n4ryBjReyNjBCDx2NG8rOqBjE-NpsXKvHYDEVqUHQhJr9aPBditUkh3rTHciTvVVlnQZyr_p1b-1OqhwOwtXY9gBTyMm4rDYQimKUU9mKG048uc33JT-w1P-6_7wlEfOyzuiz2_0rdvECq53rp37KakHwCsPS5bLMgf6ygR5anSGUwN/https%3A%2F%2Fwww.phoenixsoftware.com%2F -- 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: Adding a patch area
There's no 'trick' to sawing a pretty lady in half if you know how to do it. Ed's analysis of the patch-area logic is spot on, but he is an ISV in control of his own code. If this was an installation exit, I'd fix it myself, but the module is provided source-free by a vendor. If Ed had a similar problem with a product like, say, CICS, he'd be in the same fix we're in. I’m not wedded to S-CONs, but they can simplify life in managing patch areas. This particular 'usermod' has been utilized here for decades. Failing to implement the function altogether would impact hundreds of call center customer support folks. I'd hate to sully the mainframe's rep by admitting that we're not smart enough to keep it alive. . . 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 Ed Jaffe Sent: Tuesday, July 24, 2018 9:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Adding a patch area On 7/24/2018 7:12 PM, Jesse 1 Robinson wrote: > Yeah, touché. S-CON is an assembler thing. EXPAND is a binder thing. Have not > experimented with getting them to work together. Hoping the vendor will fix > this at the source. You're probably thinking of the ancient technique of assembling S-CONs into a patch area covered by a base register to aid in patch writing. There's no trick to it. If you defined for example 10S(*) at offset +10 from the start of your USING domain and the base was R11 you got: B010 B012 B014 B016 B018 B01A B01C B01E B020 B022 assembled at that location. You would then branch to the patch area when needed to fix a problem without reassembling. For example, if your code at +4E0 into the program was: 04E0 1B12 SR 1,2 04E2 5A10 AFB0 A 1,FIELD1 04E6 5010 AFB0 ST 1,FIELD1 and you needed to insert another subtract after the SR, you could patch that in pretty easily. Something like: VER 0010 B010,B012,B014,B016,B018 VER 04E2 5A10,AFB0 A 1,FIELD1 REP 0010 5B10,AFB4 S 1,FIELD2 REP 0014 5A10,AFB0 A 1,FIELD1 REP 0018 07FE BR 14 REP 04E2 45E0,B010 BAL 14,patch These days anything produced by a modern compiler and any serious, hand-written assembler code written in the last 20 years likely no longer uses those highly-restrictive S/360 programming techniques (aka "stone knives and bear skins") where a base register gave you a mere 4K of *forward* addressability PER REGISTER! 100% of our in-house-developed products use relative-to-PSW branching -- usually short (+/- 64K branch range) and sometimes long (+/- 2G branch range) -- exclusively for intra-CSECT branching. (Since z/OS 1.7 you've been able to use relative branches for inter-CSECT branches as well, but we do do that.) We use long (20-bit) displacement instructions (+/- 512K range per base register) for storage references as well. Patch areas still make sense, but S-CONs surely don't unless the patch area is defined as part of the program literals -- and THAT would be a tremendous waste of a precious 4K base register resource. Some things are best forgotten. After writing this, I wish I had followed my own advice... LOL -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
On 7/24/2018 7:12 PM, Jesse 1 Robinson wrote: Yeah, touché. S-CON is an assembler thing. EXPAND is a binder thing. Have not experimented with getting them to work together. Hoping the vendor will fix this at the source. You're probably thinking of the ancient technique of assembling S-CONs into a patch area covered by a base register to aid in patch writing. There's no trick to it. If you defined for example 10S(*) at offset +10 from the start of your USING domain and the base was R11 you got: B010 B012 B014 B016 B018 B01A B01C B01E B020 B022 assembled at that location. You would then branch to the patch area when needed to fix a problem without reassembling. For example, if your code at +4E0 into the program was: 04E0 1B12 SR 1,2 04E2 5A10 AFB0 A 1,FIELD1 04E6 5010 AFB0 ST 1,FIELD1 and you needed to insert another subtract after the SR, you could patch that in pretty easily. Something like: VER 0010 B010,B012,B014,B016,B018 VER 04E2 5A10,AFB0 A 1,FIELD1 REP 0010 5B10,AFB4 S 1,FIELD2 REP 0014 5A10,AFB0 A 1,FIELD1 REP 0018 07FE BR 14 REP 04E2 45E0,B010 BAL 14,patch These days anything produced by a modern compiler and any serious, hand-written assembler code written in the last 20 years likely no longer uses those highly-restrictive S/360 programming techniques (aka "stone knives and bear skins") where a base register gave you a mere 4K of *forward* addressability PER REGISTER! 100% of our in-house-developed products use relative-to-PSW branching -- usually short (+/- 64K branch range) and sometimes long (+/- 2G branch range) -- exclusively for intra-CSECT branching. (Since z/OS 1.7 you've been able to use relative branches for inter-CSECT branches as well, but we do do that.) We use long (20-bit) displacement instructions (+/- 512K range per base register) for storage references as well. Patch areas still make sense, but S-CONs surely don't unless the patch area is defined as part of the program literals -- and THAT would be a tremendous waste of a precious 4K base register resource. Some things are best forgotten. After writing this, I wish I had followed my own advice... LOL -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
Yeah, touché. S-CON is an assembler thing. EXPAND is a binder thing. Have not experimented with getting them to work together. Hoping the vendor will fix this at the source. . . 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 Paul Gilmartin Sent: Tuesday, July 24, 2018 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Adding a patch area On Tue, 24 Jul 2018 20:17:05 +, Jesse 1 Robinson wrote: >Thanks! There's also a trick to create S-type constants with base-displacement >values to simplify branching into a patch area at the right spot. > I don't see this in the description of the EXPAND statement (but I didn't check the Advanced Facilities volume.) >-iriginal Message- >From: John Eells >Sent: Tuesday, July 24, 2018 9:38 AM > >Perhaps the Binder's EXPAND statement will do what you need. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
On Tue, 24 Jul 2018 20:17:05 +, Jesse 1 Robinson wrote: >Thanks! There's also a trick to create S-type constants with base-displacement >values to simplify branching into a patch area at the right spot. > I don't see this in the description of the EXPAND statement (but I didn't check the Advanced Facilities volume.) >-iriginal Message- >From: John Eells >Sent: Tuesday, July 24, 2018 9:38 AM > >Perhaps the Binder's EXPAND statement will do what you need. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
Thanks! There's also a trick to create S-type constants with base-displacement values to simplify branching into a patch area at the right spot. BTW vendor support sees some comments about a patch area but can't find an actual one. Like maybe it got omitted and no one ever complained before. Hrmph. . . 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 John Eells Sent: Tuesday, July 24, 2018 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Adding a patch area Jesse 1 Robinson wrote: > We have a vendor product for which we previously ZAPped some tailored code > into a patch area. The latest upgrade of the product module does not come > with a patch area. I seem to remember a method of adding a patch area to a > module for which no source is available. Using I think ASMH and IEWL. Sound > familiar? Sound doable? Skip, Perhaps the Binder's EXPAND statement will do what you need. Here's the example from the book, MVS Program Management: User's Guide and Reference, which you can find here: https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa231392/$file/ieab200_v2r3.pdf: Example In this example, EXPAND statements add a 250-byte patch area (initialized to zeros) at the end of control section CSECT1 and increase the length of named common area COM1 by 400 bytes. //LKED EXEC PGM=IEWBLINK //SYSPRINT DD SYSOUT=* //SYSLMOD DD DSNAME=PROJECT.PROGLIB,DISP=OLD //SYSLIN DD DSNAME=&,DISP=(OLD,PASS) // DD * EXPAND CSECT1(250) EXPAND COM1(400) NAME MOD1(R) /* (Note the caution in the book about addressability.) -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
Jesse 1 Robinson wrote: We have a vendor product for which we previously ZAPped some tailored code into a patch area. The latest upgrade of the product module does not come with a patch area. I seem to remember a method of adding a patch area to a module for which no source is available. Using I think ASMH and IEWL. Sound familiar? Sound doable? Skip, Perhaps the Binder's EXPAND statement will do what you need. Here's the example from the book, MVS Program Management: User's Guide and Reference, which you can find here: https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa231392/$file/ieab200_v2r3.pdf: Example In this example, EXPAND statements add a 250-byte patch area (initialized to zeros) at the end of control section CSECT1 and increase the length of named common area COM1 by 400 bytes. //LKED EXEC PGM=IEWBLINK //SYSPRINT DD SYSOUT=* //SYSLMOD DD DSNAME=PROJECT.PROGLIB,DISP=OLD //SYSLIN DD DSNAME=&,DISP=(OLD,PASS) // DD * EXPAND CSECT1(250) EXPAND COM1(400) NAME MOD1(R) /* (Note the caution in the book about addressability.) -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a patch area
Linkage editor EXPAND? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, July 24, 2018 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Adding a patch area [External Email] We have a vendor product for which we previously ZAPped some tailored code into a patch area. The latest upgrade of the product module does not come with a patch area. I seem to remember a method of adding a patch area to a module for which no source is available. Using I think ASMH and IEWL. Sound familiar? Sound doable? . . 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<mailto:robin...@sce.com> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Adding a patch area
We have a vendor product for which we previously ZAPped some tailored code into a patch area. The latest upgrade of the product module does not come with a patch area. I seem to remember a method of adding a patch area to a module for which no source is available. Using I think ASMH and IEWL. Sound familiar? Sound doable? . . 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<mailto:robin...@sce.com> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
