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 <IBM-MAIN@listserv.ua.edu> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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

Reply via email to