On 3 Feb 2006 17:52:43 -0800, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (Greg Price) wrote:
>Edward E. Jaffe wrote:
>> Shmuel Metz (Seymour J.) wrote:
>>> In <[EMAIL PROTECTED]>, on 02/02/2006
>>> at 08:13 AM, "Edward E. Jaffe"
<[EMAIL PROTECTED]> said:
>>>
>>>> Not for PDSE.
>>>>
>>> Why would AMASPZAP processing be any different for PDSE?
>Just to expand on what Ed said ever so slightly, AMASPZAP
can navigate
>the structure of load modules in PDSs itself, find the
code to be zapped,
>change it and rewrite it - all without calling the
Program Binder or Linkage
>Editor. (Imagine the service aid calling the Linkage
Editor on OS/360 - talk
>about extra overhead.)
>
>The shifting sands of the structure of Program Objects
are not "known" by
>AMASPZAP, so it invokes Program Binder code to read the
object, change it,
>and rewrite it. When the Binder rewrites the program
(which probably will
>be a different number of bytes due to more IDR_Z data) it
is stored as a new
>member in the PDSE which then supercedes the old member.
>
>I also believe it is true to say that OPEN for UPDAT of a
PDSE will never
>cause a PDSE member to be updated in place because of the
member
>versioning that PDSEs effectively provide for existing
connections.
Sorry to resurrect an old thread, but I was cleaning
up some papers and happened to come across IBM's 1989
response to the PDSPAIN White Paper. It stated:
"IBM's goal in any improvements to PDSs is to continue to
support these benefits
...
(5) The ability to perform updates in place by rewriting
data blocks."
Yes, I understand that it was a goal, not a
hard-and-fast destination. I just thought you might be as
amused as I was by this fortuitous discovery.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
