-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Monday, January 09, 2012 4:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Error apply ZAP
On Mon, 9 Jan 2012 15:32:26 -0800, Charles Mills wrote:
The resource spent on adding
Of Paul Gilmartin
Sent: Tuesday, January 10, 2012 8:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Error apply ZAP
...
Let me give an example. Suppose after I have APPLYed PTFs A, B, and C in
sequence I detect a bug. I'd like to isolate the causing PTF. So I do what
is necessary to RESTORE C and test
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Charles Mills
The resource spent on adding emphasis to the description of a
deficiency
would better have been used to repair it.
LOL. Ain't it the truth! Every software team should have that on a
plaque on the
On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote:
PTF1 with Elements A and B and PTF2 that PREs
PTF1 which replaces PTF1's Element A. If you RESTORE PTF1 you must
also have SMPE RESTORE PTF2 since you need to all back to the version
of Element A that PTF1 replaced. I do not remember
On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote:
On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote:
To back out PTF2
ALL that is needed is to select Element A from PTF1 and ignore PTF1's
Element B (since B is at PTF1 level even after PTF2 is APPLY'ed and
thus there is no need
On Tue, 10 Jan 2012 08:23:05 -0600, Paul Gilmartin wrote:
On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote:
On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote:
This backtracking continues until you find a set of PTFs
in the PRE/SUP chain that contains all the Elements (and only
On Tue, 10 Jan 2012 09:05:05 -0600, Tom Marchant wrote:
On Tue, 10 Jan 2012 08:23:05 -0600, Paul Gilmartin wrote:
On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote:
On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote:
This backtracking continues until you find a set of PTFs
in
On Tue, 10 Jan 2012 10:23:37 -0600, Paul Gilmartin wrote:
Let me give an example. Suppose after I have APPLYed PTFs
A, B, and C in sequence I detect a bug. I'd like to isolate the
causing PTF. So I do what is necessary to RESTORE C and
test again. The bug is still there. So I'd like to
On Tue, 10 Jan 2012 12:37:42 -0600, Tom Marchant wrote:
Let me give an example. Suppose after I have APPLYed PTFs
A, B, and C in sequence I detect a bug. I'd like to isolate the
causing PTF. So I do what is necessary to RESTORE C and
test again. The bug is still there. So I'd like to RESTORE
I believe it replaces the existing IDR record with a empty one
snip
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
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
It's a major design shortcoming that one can't REDO a ZAP. It would
be so easy -- if PARM=REDO and
the content of the module matches the REP, assume it's OK. And SMP/E
should supply the
On Mon, 9 Jan 2012 10:01:43 -0600, Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
It's a major design shortcoming that one can't REDO a ZAP. It would
be so easy -- if PARM=REDO and
the content of the module matches the
Of
Chase, John
Sent: Monday, January 09, 2012 11:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Error apply ZAP
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
It's a major design shortcoming that one can't REDO a ZAP. It would
be so easy
On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote:
I think that you answered your own question.
aside from not recovering the
victim(s) of a ++DELETE command?
I could never understand why that is the case. RESTORE should restore
everything.
Yup. There's another one that's about as
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
I wonder why ++DELETE precludes RESTORE? It should be straightforward
to rebuild program objects from
parts in the DLIBs.
I think ++DELETE also purges any meta-data associated with the
immediately by reply e-mail and delete this message. Thank you for your
cooperation
-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de
Chase, John
Enviada em: segunda-feira, 9 de janeiro de 2012 16:37
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: Error apply
In
f255efe0ecf08c4a9c1db6aff4235417181f2...@ch2wpmail1.na.ds.ussco.com,
on 01/09/2012
at 10:01 AM, Chase, John jch...@ussco.com said:
How does RESTORE not accomplish an UNDO,
The OP is talking about AMASPZAP, not SMP.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position;
On Mon, 9 Jan 2012 12:37:21 -0600, Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
I wonder why ++DELETE precludes RESTORE? It should be straightforward
to rebuild program objects from
parts in the DLIBs.
I think
At 11:53 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP:
On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote:
I think that you answered your own question.
aside from not recovering the
victim(s) of a ++DELETE command?
I could never understand why that is the case
] On Behalf
Of Robert A. Rosenberg
Sent: Monday, January 09, 2012 1:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Error apply ZAP
At 11:53 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply
ZAP:
On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote:
I think that you answered your own
On Mon, 9 Jan 2012 16:51:06 -0500, Robert A. Rosenberg wrote:
On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote:
I think that you answered your own question.
aside from not recovering the
victim(s) of a ++DELETE command?
I could never understand why that is the case. RESTORE should
On Mon, 9 Jan 2012 15:32:26 -0800, Charles Mills wrote:
The resource spent on adding emphasis to the description of a deficiency
would better have been used to repair it.
LOL. Ain't it the truth! Every software team should have that on a plaque on
the wall.
I don't always do it, but I am
At 18:26 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP:
RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs
that are not the SYSMOD being designated as being RESTORED. Instead
of using ONLY the elements that are in the SYSMOD being RESTOREd (by
using
Gerhard:
I honestly don't remember ever having the issue with IBM module(s). I
memory goes back to early MVS 2.0 and if we did have an issue it was
because TMS or some other vendor code hit the same module (open). In
the case of TMS it wasn't their fault so much as IBM didn't give
exits
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
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
In
f255efe0ecf08c4a9c1db6aff4235417181f2...@ch2wpmail1.na.ds.ussco.com,
on 01/09/2012
at 10:01 AM, Chase, John jch...@ussco.com said:
How does RESTORE not accomplish an UNDO,
The
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
choelsc...@humana.com
Humana.com
Keeping CAS and Metavance safe for all HUMANAty
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ed Gould
Sent: Saturday, January 07, 2012 2:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Error apply
On 1/7/2012 2:31 PM, Ed Gould wrote:
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
In ec61ef1aa63c694b8a23a9e1350cca22cf2...@dr000s061.sfr.net, on
01/06/2012
at 08:00 PM, Helio Jose Da Silva helio.si...@rural.com.br said:
How can I resolve this error?
!. Relink
2. Contact the vendor
There are two separate issues. The AMA120I message means that you
won't have an audit
On Fri, 6 Jan 2012 14:29:12 -0600, Staller, Allan wrote:
The real problem is the AMA104I message - VERIFY REJECT. The most likely
cause is that this zap has already been applied.
Another possibility that a pre-requisite zap is missing.
The fastest way to determine this is to take a copy SYSIN
-snip--
I seem to remember (20+ years ago?) that re-linkediting the load module
would preserve the existing IDR entries and allow for another 19 (but I
could be mistaken on this)
In
4bbf0d2ae8a42b43b88ff0033094ed124c34e...@simmbxwpg02s02.rsc.humad.com,
on 01/07/2012
at 08:44 PM, Chris Hoelscher choelsc...@humana.com said:
I seem to remember (20+ years ago?) that re-linkediting the load
module would preserve the existing IDR entries and allow for another
19 (but I could
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
All list,
I'm applying some zaps and getting the following error:
NAME NATURAL NATRGUI
AMA120I NATURAL NO IDR SPACE - RE-LINK
AMA128I UPDATES ENABLED BY OVERRIDE PARM
VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC
AMA104I VERIFY REJECT - SET NO GO SWITCH
The JCL is
//ZA0JZAP JOB
, January 06, 2012 14:00
To: IBM-MAIN@bama.ua.edu
Subject: Error apply ZAP
All list,
I'm applying some zaps and getting the following error:
NAME NATURAL NATRGUI
AMA120I NATURAL NO IDR SPACE - RE-LINK
AMA128I UPDATES ENABLED BY OVERRIDE PARM
VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC
On 01/06/12 15:00, Helio Jose Da Silva wrote:
All list,
I'm applying some zaps and getting the following error:
NAME NATURAL NATRGUI
AMA120I NATURAL NO IDR SPACE - RE-LINK
AMA128I UPDATES ENABLED BY OVERRIDE PARM
VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC
AMA104I VERIFY REJECT - SET NO
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Helio Jose Da Silva
Sent: Friday, January 06, 2012 2:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Error apply ZAP
All list,
I'm applying some zaps and getting the following error
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
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
40 matches
Mail list logo
