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
