Seymour:
I didn't say anything about the IDR space (and indeed I relinked a
few modules) to get the zap on.
It was difficult with quantity of the zaps. I hated to get the mail
opened daily as the number of envelopes with zaps was scary at times.
One ugly day I had 5 envelopes with 5 separate zaps in each envelope.
I had enough work without having to deal with the paperwork that went
along with each.
One nice thing I will admit very rarely did zaps go against multiple
modules.
Ed
On Jan 7, 2012, at 7:17 PM, Robert A. Rosenberg wrote:
At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply
ZAP:
Robert:
I used to have a vendor that would send out zaps almost weekly and
IDR space was at a premium on the vendors modules. We dropped the
vendor so I don't know how they did resolve the constant zap
issue. I can't remember of ever having the issue with IBM as they
send out module replacement (thanks!)
I feel its important to maintain the IDR to find out what level
the module is at. With the vendor I spoke of it was somewhat of an
issue at times.
That is why I am a strong supporter of module replacement and zaps
are for emergency fixes only.
As I noted, and someone here confirmed, doing a relink adds extra
IDR room (if the current IDR Record is full). IOW: The AMA120I
message by suggesting the relink would add another IDR record with
room for another 19 IDENTIFY commands. The IDR record is on a per-
loadmodule basis and thus is shared by all the CSECTs in the Load
Module. In the case of your vendor, so long as the ZAPs came with
IDENTIFY commands and you did not supply the PARM override, every
19 ZAPs (~5 months) a relink would be needed to add another IDR
record to be used.
Ed
On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote:
At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re:
Error apply ZAP:
First the IDR (forget what the acronym stands for) is an
optional list
of zaps applied to this module (load module?). Due to the
structure of
the directory, IIRC, you are limited to 19 IDR entries
per module (load module?). The IDR data is set by an AMASPZAP
control
statement. IDENTIFY.
The message AMA120I message below may be safely ignored. It is
indicated
that there is no space left to record additional IDR
information. The
only impact of this is that it will make it difficult to
determine which
zaps have already been applied.
If you relink as the AMA120I suggests/instructs the Binder adds
another (empty) IDR record so you can use the IDENTIFY statement
(think this is automatic although it may be triggered by
supplying a Binder command to add more IDR Space). As you note,
this allows you to track what ZAPs have been installed. If I
remember IDR is ID Record. There are IDR records for each CSECT
in the Load Module (they come from the Assembler) so you can see
what the assembly date of the CSECT is (there is only one for the
last linkedit).
--------------------------------------------------------------------
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
---------------------------------------------------------------------
-
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN