Re: SMP/E SE37 Retry and ++ZAP

[Arthur T.]

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

CBT Delinker (was: SMP/E SE37 Retry and ++ZAP)

[Paul Gilmartin]

In a recent note, Greg Price said:

> Date: Thu, 2 Feb 2006 00:13:25 +1100
> 
> > Know of any good delinkers at cbttape.org?
> 
> I think David Noon's delinker in CBT file 90 is pretty powerful,
> as long as your not talking about program objects.
> 
Indeed.  Thanks.  Program objects is not a problem today.  However
I needed to use CBT file 135.  Read on ...

> I haven't looked into it fully, but you may even be able to get
> it to wrap MCS around the object decks.  It handles the
>
True.  But it has the slightly irritating habit of emitting
a NAME into what I'd like to use for testing as secondary
input.

> various reusability levels, APF settings, and AMODE/RMODE
> settings, although it would pre-date AMODE64.
> 
And it fails on a boundary condition: I have an empty CSECT
(not my doing; another ISV's; but that's why I'm trying to
delink).  For the empty CSECT, it emits a TXT record with a
count of 0, on which Binder whines:

IEW2322I 1220  1 INCLUDE  SYSLIB(WHATEVER)
IEW2552E 4607 RECORD NUMBER  2 OF THE CURRENT OBJECT MODULE HAS AN INVALID 
LENGTH FIELD.
IEW2307E 1032 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID DATA.

(But I can edit that out with ISPF/PDF.)

> It's written in PL/I so maybe AMODE64 could be added fairly
> easily if required.
> 
... but we don't have a PL/I compiler.  Is anyone maintaining this,
eager to fix a boundary condition problem (the comment dates are
pretty old)?  Probably just a matter of testing at the bottom of a
loop when it should have been done at the top.

And now, I have the problem of validation.  When I run two Binder
steps with inputs respectively the original load module and the
output of DELINKI (with empty TXT record removed), the load maps
are more different than I can readily reconcile.  How might I
assure myself that I'm getting an equivalent load module?

Thanks,
gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

In a recent note, "Shmuel Metz (Seymour J.)" said:

> Date: Sun, 5 Feb 2006 19:49:21 -0500
> 
> In <[log in to unmask]>, on
> 02/04/2006
>at 12:52 PM, Greg Price <[log in to unmask]> said:
> 
> >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.
> 
> Aren't AMASPZAP and BINDER both part of DFSMSdfp? You'd think that the
> developers would talk to each other :-(
> 
Modularity.  The code is available in Binder; AMASPZAP might
better exploit it than replicate it and track any changes.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
02/04/2006
   at 12:52 PM, Greg Price <[EMAIL PROTECTED]> said:

>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.

Aren't AMASPZAP and BINDER both part of DFSMSdfp? You'd think that the
developers would talk to each other :-(
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

AMA140T ... BINDER ERROR (was: SMP/E SE37 Retry and ++ZAP)

[George Kozakos]

I thought the component id would simply be found via the MVS Diagnosis:
Reference 1.1.1 if you know the module name or the component name. This
actually gives two fields - the product id and the component id. e.g. for
supervisor control the product id is 5752 and the component id is SC1C5.
But the component id field in a PMR is the concatenation of these two
fields and is actually referred to as the program component id. If you have
a LOGREC entry for the error the PIDS or program id is the field required
as the component id in a PMR.

Regards,
George Kozakos

--
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

Re: AMA140T ... BINDER ERROR (was: SMP/E SE37 Retry and ++ZAP)

[Skip Robinson]

This might depend on the level of support you've contracted for, but I
generally see two methods for determining component id.

A. In the ETR 'dialog', you can leave compid blank and drill down through a
successive series of menus to the actual product/component that you want to
report the problem to. Not necessarily the component you believe to be
responsible; I sometimes suspect a third party product but feel obligated
to start with the thingie that actually abended, which may be--or appear to
be--an IBM component.

B. Paste in the compid from what you believe to be a similar APAR. I once
thought this would be the most accurate designation, but I've had a case or
two where a PMR was rerouted immediately to some other component id. I
never researched the discrepancy.

So if you have the interactive option, start with Plan A, and if you hit a
dead end, switch to Plan B.

OK, I stacked the deck by naming the plans A and B. If only life were
intrinsically that simple.  ;-)

.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 02/04/2006
01:31:29 PM:

> On Fri, 3 Feb 2006 14:27:46 -0700, Paul Gilmartin <[EMAIL PROTECTED]
> STORTEK.COM> wrote:
> >
> >   DUMPuncompress
> >  AMA140T UNABLE TO COMPLETE OPERATION DUE TO BINDER ERROR,
>FUNCTION = INCLUDE, RC=8, RSN=83000514
> >  AMA113I COMPLETED DUMP REQUIREMENTS
> > * BOTTOM OF DATA ***
> >
> > ... Looks as if another PMR is needed.
> >
> I searched IBMLink for this; this looks very much like OW02423, but
> shouldn't that have been fixed by z/OS 1.5?
>
> PMR submitted.
>
> BTW, how does one fill in the "Component ID" for a PMR?  "AMASPZAP"
> was invalid, as was "Service Aids".  I copied the Component ID from
> OW02423 since it's so similar, but I wonder if supplying possibly
> incorrect, or merely obsolete, information is more of an hindrance
> than a help.
>
> -- gil

--
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

Re: AMA140T ... BINDER ERROR (was: SMP/E SE37 Retry and ++ZAP)

[Ray Mullins]

They're pretty good at bouncing the PMR's around until it hits the right
area.

I open DB2 PMRs under one component ID even if the problem resides in a
different component ID area of DB2, because the right component ID isn't
recognized.

Later,
Ray

-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. 

--ilvi 



 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Saturday 04 February 2006 13:31
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: AMA140T ... BINDER ERROR (was: SMP/E SE37 Retry and ++ZAP)
> 
> On Fri, 3 Feb 2006 14:27:46 -0700, Paul Gilmartin 
> <[EMAIL PROTECTED]> wrote:
> >
> >   DUMPuncompress
> >  AMA140T UNABLE TO COMPLETE OPERATION DUE TO BINDER ERROR,
>FUNCTION = INCLUDE, RC=8, RSN=83000514
> >  AMA113I COMPLETED DUMP REQUIREMENTS
> > * BOTTOM OF DATA ***
> >
> > ... Looks as if another PMR is needed.
> >
> I searched IBMLink for this; this looks very much like 
> OW02423, but shouldn't that have been fixed by z/OS 1.5?
> 
> PMR submitted.
> 
> BTW, how does one fill in the "Component ID" for a PMR?  "AMASPZAP"
> was invalid, as was "Service Aids".  I copied the Component ID from
> OW02423 since it's so similar, but I wonder if supplying 
> possibly incorrect, or merely obsolete, information is more 
> of an hindrance than a help.
> 

--
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

Re: RESTORE (was: SMP/E SE37 Retry and ++ZAP)

[Paul Gilmartin]

On Sat, 4 Feb 2006 14:24:45 -0500, Arthur T. <[EMAIL PROTECTED]> wrote:
>
>   I do suspect that implementing UNDO would be *very*
> tricky.  PREs and SUPs would be a problem, especially as
> any mod with a PRE for the mod you're UNDOing would also
> have to be UNDOne.  Finding the "before" data and getting
> it properly linked/bound/copied would be another
> hurdle.  Despite that, it would be a very handy tool, and
> would probably be used much more than RESTORE if it were
> available.
>
This is an unusual instance in which I find the design of
VM/CMS VMFMERGE preferable to SMP/E.  VMFMERGE has no
analogue of a distribution library, nor any operation
analogous to ACCEPT.  Instead it maintains renamed elements
in a "DELTA" library, analogous to the SMPPTS; and current
level elements in a "MERGE" library, analogous to SMP/E's
target libraries.  The VMFRESTORE operation merely copies
elements at the correct older level from the DELTA library
(PTS) to the MERGE library (target).  On the whole, SMP/E
is better, but it shouldn't say, "NIH!" to superior features
of VMFMERGE.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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

AMA140T ... BINDER ERROR (was: SMP/E SE37 Retry and ++ZAP)

[Paul Gilmartin]

On Fri, 3 Feb 2006 14:27:46 -0700, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>
>   DUMPuncompress
>  AMA140T UNABLE TO COMPLETE OPERATION DUE TO BINDER ERROR,
   FUNCTION = INCLUDE, RC=8, RSN=83000514
>  AMA113I COMPLETED DUMP REQUIREMENTS
> * BOTTOM OF DATA ***
>
> ... Looks as if another PMR is needed.
>
I searched IBMLink for this; this looks very much like OW02423, but
shouldn't that have been fixed by z/OS 1.5?

PMR submitted.

BTW, how does one fill in the "Component ID" for a PMR?  "AMASPZAP"
was invalid, as was "Service Aids".  I copied the Component ID from
OW02423 since it's so similar, but I wonder if supplying possibly
incorrect, or merely obsolete, information is more of an hindrance
than a help.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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

Re: RESTORE (was: SMP/E SE37 Retry and ++ZAP)

[Arthur T.]

On 4 Feb 2006 10:18:42 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] wrote:



I agree wholeheartedly with Robert (and, I think, Arthur.  His
position is less clear to me.)  However, we will be a distinct
minority.  In particular, Kurt Q. takes the opposite side:

  Linkname: IBM-MAIN archives -- October 2001 
(#1977)
   URL: 
http://bama.ua.edu/cgi-bin/wa?A2=ind0110&L=ibm-main&P=R97276


   Because that is not what RESTORE does.  As designed 
and implemented,
   RESTORE's function is to un-do whatever happened 
during APPLY and to
   bring the target libraries back to an "accepted" 
service level, which by
   definition is the the level found in the distribution 
libraries.  I
   think I understand what you are asking for, but that 
is not what RESTORE

   does.

At least what we desire is to be considered a Requirement 
for a new function

(call it UNDO), not merely an enhancement to RESTORE.


 Yes, you agree with me.

 It's true that RESTORE, by design and function, takes 
us back to the ACCEPTed level.  In some cases, that's what 
you want; "Bring me back to just after the previous PUT 
level", for instance.


 What I've found more often, though, is that I would 
like to back off a single PTF or APAR.  Currently, that is 
usually difficult or impossible, unless you happen to be 
trying just after an ACCEPT.  The catch-22 is that you 
don't want to ACCEPT maintenance until you're *sure* it's 
not a problem.


 So yes, RESTORE has a valid place.  But that place 
does not allow one to un-APPLY a single mod out of many 
that have been APPLYed since the last ACCEPT.  Your idea of 
an UNDO command would be wonderful.


 I do suspect that implementing UNDO would be *very* 
tricky.  PREs and SUPs would be a problem, especially as 
any mod with a PRE for the mod you're UNDOing would also 
have to be UNDOne.  Finding the "before" data and getting 
it properly linked/bound/copied would be another 
hurdle.  Despite that, it would be a very handy tool, and 
would probably be used much more than RESTORE if it were 
available. 


--
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

RESTORE (was: SMP/E SE37 Retry and ++ZAP)

[Paul Gilmartin]

In a recent note, Arthur T. said:

> Date: Sat, 4 Feb 2006 11:51:11 -0500
> 
> On Sat, 4 Feb 2006 01:29:09 -0500, in bit.listserv.ibm-main
> [log in to unmask] ("Robert A. Rosenberg") wrote:
> 
> >There is only one MAJOR DESIGN problem IMO with the
> >current implementation of RESTORE - It wants to remove too
> >much as opposed to acting as a way of just removing the
> >designated SYSMOD (ie: Restoring the system to the state
> >it would have been in if the SYSMOD had never been APPLY'ed)
> 
>   Not to mention that if you've RECEIVEd maintenance or
> HOLDDATA between the APPLY and the RESTORE, you may find it
> difficult (or nearly impossible) to get your system back to
> the state just before APPLYing the SYSMOD you want to
> RESTORE.  Re-APPLYing the rest of the backed-off
> maintenance may bring in new SUPs or PE fixes.
> 
I agree wholeheartedly with Robert (and, I think, Arthur.  His
position is less clear to me.)  However, we will be a distinct
minority.  In particular, Kurt Q. takes the opposite side:

   Linkname: IBM-MAIN archives -- October 2001 (#1977)  

URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0110&L=ibm-main&P=R97276

Because that is not what RESTORE does.  As designed and implemented,
RESTORE's function is to un-do whatever happened during APPLY and to
bring the target libraries back to an "accepted" service level, which by
definition is the the level found in the distribution libraries.  I
think I understand what you are asking for, but that is not what RESTORE
does.

At least what we desire is to be considered a Requirement for a new function
(call it UNDO), not merely an enhancement to RESTORE.

And "Re-APPLYing the rest of the backed-off maintenance" introduces even
more ambiguity.  Suppose I iteratively perform "RESTORE CHECK GROUP
SELECT( ... )", adding at each step to the select list SYSMODs that
cause conflicts because their APPLYed RMID(s) to not match those of
elements in the DLIBs.  The GROUP operand will cause some successors
of those precursors also to be RESTORED.  Do we wish to re-APPLY those?
In other words, is the desire to restore the system to a state matching
the point in time before the SELECTed SYSMOD(s) was applied, or to
undo only those SYSMODS which depend on the one SELECTed?

With the advent of the SMP/E "Improved load module build processing" in
OS/390 V2R5, SMP/E has recognized that elements can be obtained elsewhere
than from the DLIBs (but only, so far, for building load modules, not
for other operations).  Clearly, the element content necessary to do
what we desire exists within the union of the DLIBs and the SMPPTS,
but is the historical information available for SMP/E to know what to
do?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Arthur T.]

On Sat, 4 Feb 2006 01:29:09 -0500, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] ("Robert A. Rosenberg") wrote:


At 12:37 -0800 on 02/01/2006, Barry Schwarz wrote about 
Re: SMP/E SE37 Retry and ++ZAP:



Which can often be resolved with an intervening RESTORE.


There is only one MAJOR DESIGN problem IMO with the 
current implementation of RESTORE - It wants to remove too 
much as opposed to acting as a way of just removing the 
designated SYSMOD (ie: Restoring the system to the state 
it would have been in if the SYSMOD had never been APPLY'ed)


 Not to mention that if you've RECEIVEd maintenance or 
HOLDDATA between the APPLY and the RESTORE, you may find it 
difficult (or nearly impossible) to get your system back to 
the state just before APPLYing the SYSMOD you want to 
RESTORE.  Re-APPLYing the rest of the backed-off 
maintenance may bring in new SUPs or PE fixes.  


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Robert A. Rosenberg]

At 12:37 -0800 on 02/01/2006, Barry Schwarz wrote about Re: SMP/E 
SE37 Retry and ++ZAP:



Which can often be resolved with an intervening RESTORE.


There is only one MAJOR DESIGN problem IMO with the current 
implementation of RESTORE - It wants to remove too much as opposed to 
acting as a way of just removing the designated SYSMOD (ie: Restoring 
the system to the state it would have been in if the SYSMOD had never 
been APPLY'ed). It should ONLY go to the DLIBS  for elements being 
backed off if there is no SYSMOD still in APPLY status that is being 
SUP'ed or PRE'd by the SYSMOD being removed - Otherwise it should get 
them from the APPLY status SYSMOD (IOW: Redo the APPLY for those 
elements ONLY automatically as part of the RESTORE). There are a 
number of cases where due to PRE/SUP Chains the attempt to back off a 
single element ends up backing off a large number of elements due to 
the prior version being in a multi-element SYSMOD (which triggers 
more SYSMODs/Elements in the mix before SMPE is done.


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Greg Price]

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.

Cheers,
Greg P.



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?

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Edward E. Jaffe]

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?
  


Because the IEWBIND interface doesn't provide support to allow ZAP in place.

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

In a recent note, Craddock, Chris said:

> Date: Fri, 3 Feb 2006 14:22:56 -0600
> 
> > Why would AMASPZAP processing be any different for PDSE?
> 
Can PDSE members be updated in place?

> It used to be (until I opened a PMR on it 3 or 4 years ago) that you
> could not zap program objects. AMASPZAP just curled up its toes and
> barfed if you presented it with a program object. It is probably still
> the case that you can't zap program object contents in classes other
> than B_TEXTxx, but at least you can apply zaps to code.
> 
If I were to believe the manual, I'd think you can even zap program
objects in HFS.  But it doesn't always work.  The program:

//ZAPEXEC   PGM=AMASPZAP
//SYSPRINT   DD SYSOUT=A
//SYSLIB DD PATHOPTS=ORDONLY,
//  PATH='/bin'
//SYSIN  DD *
 DUMPcompress
 DUMPuncompress

produces:

* TOP OF DATA 
**
 IGWSPZAP  INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC DATA RECORDS ON 
DIRECT ACCESS STORAGE.
  DUMPcompress

 **RECORD LENGTH: 007C CLASS: B_TEXT   MEMBER NAME: compress
   CSECT NAME:  CEESTART
   4700   4702   90ECD00C   053047F0  30180014   CE030310   
002C   C3C5C5E2
 [ snip! ]

 AMA113I COMPLETED DUMP REQUIREMENTS
So far so good.  However:
  DUMPuncompress
 AMA140T UNABLE TO COMPLETE OPERATION DUE TO BINDER ERROR, FUNCTION = INCLUDE, 
RC=8, RSN=83000514
 AMA113I COMPLETED DUMP REQUIREMENTS
 BOTTOM OF DATA 


... Looks as if another PMR is needed.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Ray Mullins]

PDSEs are (were?) funny about having multiple DCB's opened against them, and
being opened UPDAT, OUTIN or INOUT.  I remember that in an earlier life, we
had to disable update in place if the target was a PDSE.

Later,
Ray

-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. 

--ilvi 



 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris
> Sent: Friday 03 February 2006 12:23
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: SMP/E SE37 Retry and ++ZAP
> 
> > 
> >Ed said:
> > 
> > >Not for PDSE.
> 
> Shmuel said;
> 
> > Why would AMASPZAP processing be any different for PDSE?
> 
> It used to be (until I opened a PMR on it 3 or 4 years ago) 
> that you could not zap program objects. AMASPZAP just curled 
> up its toes and barfed if you presented it with a program 
> object. It is probably still the case that you can't zap 
> program object contents in classes other than B_TEXTxx, but 
> at least you can apply zaps to code. 
> 
> CC
> 

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Craddock, Chris]

> 
>Ed said:
> 
> >Not for PDSE.

Shmuel said;

> Why would AMASPZAP processing be any different for PDSE?

It used to be (until I opened a PMR on it 3 or 4 years ago) that you
could not zap program objects. AMASPZAP just curled up its toes and
barfed if you presented it with a program object. It is probably still
the case that you can't zap program object contents in classes other
than B_TEXTxx, but at least you can apply zaps to code. 

CC

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Shmuel Metz (Seymour J.)]

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?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Edward E. Jaffe]

Shmuel Metz (Seymour J.) wrote:

So, I wonder, does AMASPZAP update load modules in
place (somehow I had got the belief it does so), or
use conventional QSAM techniques and rewrite and STOW?



In place.
  


Not for PDSE.

--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 01/31/2006
   at 07:34 PM, Skip Robinson <[EMAIL PROTECTED]> said:

>My view as a customer is that 'permanent' product maintenance ought
>to be delivered in ++MOD format. ZAPs should be relegated strictly to
>APAR fixes: emergency workarounds that alleviate pain in the short
>term while a module revision is being developed and packaged.

AOL!

>SMP/E enforces the straight and narrow. 

Only with good service packaging. Some vendors are notorious for poor
packaging, and there's not much SMP can do about that.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 01/31/2006
   at 05:35 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>Lately I was testing a service installation containing
>++ZAP MCS

This is an SMP issue rather than an AMASPZAP issue.

>So, I wonder, does AMASPZAP update load modules in
>place (somehow I had got the belief it does so), or
>use conventional QSAM techniques and rewrite and STOW?

In place.

>Essentially, can AMASPZAP cause a SE37 ABEND?

No, but it's not AMASPZAP that handles the EXPAND.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Barry Schwarz]

Which can often be resolved with an intervening RESTORE.

Paul Gilmartin <[EMAIL PROTECTED]> wrote:In a recent note, Mark Zelden said:

> Date: Wed, 1 Feb 2006 09:01:27 -0600
> 
> Why not? Why is changing a line or 2 of code and creating object code
> to be linked in a sysmod any better than zapping an instruction or 2?
> 
If the PTF consists of module replacements, APPLY REDO can be
used if necessary to recover from some errors. If it contains
a ++ZAP, APPLY REDO is bound to fail.


-
 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new 
and used cars.

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

In a recent note, Mark Zelden said:

> Date: Wed, 1 Feb 2006 09:01:27 -0600
> 
> Why not?  Why is changing a line or 2 of code and creating object code
> to be linked in a sysmod any better than zapping an instruction or 2?
> 
If the PTF consists of module replacements, APPLY REDO can be
used if necessary to recover from some errors.  If it contains
a ++ZAP, APPLY REDO is bound to fail.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Mark Zelden]

On Tue, 31 Jan 2006 19:34:14 -0800, Skip Robinson
<[EMAIL PROTECTED]> wrote:

>
>So, as interested as I am in an informed answer to the ZAP question, I'm
>far more interested in urging vendors to deliver PTFs that install
>serially. In other words, successive element updates that lead everyone in
>the same direction at the same pace. I don't trust ZAPs to fulfill that
>hope.
>

Why not?  Why is changing a line or 2 of code and creating object code
to be linked in a sysmod any better than zapping an instruction or 2?
If the vendor packages SMP/E updates correctly, there is nothing wrong
with a sysmod that uses ZAP.  Plenty of vendors do it correctly and
without problems.   Unfortunately there is at least one that doesn't
play by the rules.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

In a recent note, Arthur T. said:

> Date: Wed, 1 Feb 2006 01:04:39 -0500
> 
> your case, though, you might want to build DLIBs into which
> you ACCEPT the ZAP maintenance.  Then, the DLIB should have
> the updated CSECTS as MOD elements.  You can pull them out
> by hand, or get help from the GENERATE command.
> 
Would the MOD elements be in inline format, as is customary
for PTFs?  Or in relfile format; somewhat unattractive.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Greg Price]

> Know of any good delinkers at cbttape.org?

I think David Noon's delinker in CBT file 90 is pretty powerful,
as long as your not talking about program objects.

I haven't looked into it fully, but you may even be able to get
it to wrap MCS around the object decks.  It handles the
various reusability levels, APF settings, and AMODE/RMODE
settings, although it would pre-date AMODE64.

It's written in PL/I so maybe AMODE64 could be added fairly
easily if required.

Cheers,
Greg

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Robert A. Rosenberg]

At 17:35 -0700 on 01/31/2006, Paul Gilmartin wrote about SMP/E SE37 
Retry and ++ZAP:


If AMASPZAP causes a SE37 ABEND, an attempt to recover by COMPRESS 
and retry is largely futile.


Only the second and subsequent compresses. The first one may find 
"gas"/free-space in the library more than the size of the load module 
in question - IOW: After the initial compress you will have recovered 
enough room to save a new copy of the load module. OTOH: You can just 
go PDSE and never need to compress since all of the free space is 
available and there is no "gas" and also room for expansion.


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Robert A. Rosenberg]

At 22:38 -0600 on 01/31/2006, Ed Gould wrote about Re: SMP/E SE37 
Retry and ++ZAP:


I think its in the best interest of the vendor to supply replacement 
mods, especially with the INTERNET speed. I am not sure I want to 
talk about the side issue of security. Yes that needs to be 
addressed (somehow). I would like to hear how others might address 
that issue.


Digitally sign the fix. When you buy the product you are supplied 
with the Public Signing Key to verify any fixed transmitted via the 
Internet. You just use it to verify the supplied digital signature 
that came with the fix code.


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Arthur T.]

On 31 Jan 2006 20:42:00 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Paul Gilmartin) wrote:


Nonetheless, I've entertained the idea of applying the 
zaps locally,
delinking, and redistributing the affected CSECTs as ++MOD 
elements.
Subject to a determination by OCC that this violates no 
anti-reverse-

engineering clauses.

Know of any good delinkers at cbttape.org?


 The last delinker I used was DELINK0, the OS/360 
utility (as preserved on CBT).  As I recall, I had to zap 
it to allow it to handle the size of XA's IEANUC01.  I see 
that CBT now has a much more modern DELINKI (file 90), but 
I've never used it.


 In a production shop, you shouldn't ACCEPT ZAPs.  In 
your case, though, you might want to build DLIBs into which 
you ACCEPT the ZAP maintenance.  Then, the DLIB should have 
the updated CSECTS as MOD elements.  You can pull them out 
by hand, or get help from the GENERATE command.


 Not that I've tried the above, mind you.  You'd want 
to do significant testing and comparing of modules to 
verify that the technique works (if you actually try it, 
that is). 


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

On Tue, 31 Jan 2006 22:38:08 -0600, Ed Gould <[EMAIL PROTECTED]> wrote:
>
> I think its in the best interest of the vendor to supply replacement
> mods, especially with the INTERNET speed. I am not sure I want to
> talk about the side issue of security. Yes that needs to be addressed
> (somehow). I would like to hear how others might address that issue.
>
Transmit a SHA-1 checksum by whatever channel you now deem sufficiently
secure.  This will satisfy the security concerns of practically anyone
except John G.  The most recent report of SHA-1 collisions I heard last
summer was about O(2^63); I've seen no reviews of the more recent New
Scientist article John G. mentions.  I believe the greatest concern
remains masquerading, not preimaging.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

On Tue, 31 Jan 2006 19:34:14 -0800, Skip Robinson <[EMAIL PROTECTED]> wrote:
>
> I'm surprised as well that ZAPs--which I thought overwrote blocks in
> place--would lead to x37 problems. But I would rather comment on a problem
> behind the stated problem: delivering vendor-supplied fixes as ZAPs rather
> than CSECT replacements.
>
There were many PTFs involved.  The primary E37s may have come from module
replacements with the ZAP verify failures collateral damage.

> SMP/E enforces the straight and narrow. In order to install PTF C you must
> first (or concurrently) install PTFs A and B. Violating this stricture is a
>
Not quite so simple.  Unrelated PTFs may have no declared dependencies,
and the customer is free (and often prefers) to take the smorgasbord
approach.

> So, as interested as I am in an informed answer to the ZAP question, I'm
> far more interested in urging vendors to deliver PTFs that install
> serially. In other words, successive element updates that lead everyone in
> the same direction at the same pace. I don't trust ZAPs to fulfill that
> hope.
>
I agree wholeheartedly and my recent experience strengthens the conviction
we share.  Alas, in this instance we are not the Primary Vendor, but a
redistributor, so the choice is not ours.  In fact, the Primary Vendor
elects not to deal in SMP/E at all.  They ship us zaps, which we repackage
as PTFs.  They have a line of products well known, respected, widely
used, and with scarce alternatives; the sort of concern to which it is
impossible to say with credibility, "Package in SMP/E or we'll take our
custom elsewhere."

Nonetheless, I've entertained the idea of applying the zaps locally,
delinking, and redistributing the affected CSECTs as ++MOD elements.
Subject to a determination by OCC that this violates no anti-reverse-
engineering clauses.

Know of any good delinkers at cbttape.org?

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Ed Gould]

On Jan 31, 2006, at 9:34 PM, Skip Robinson wrote:
SNIP---



So, as interested as I am in an informed answer to the ZAP  
question, I'm

far more interested in urging vendors to deliver PTFs that install
serially. In other words, successive element updates that lead  
everyone in
the same direction at the same pace. I don't trust ZAPs to fulfill  
that

hope.

-SNIP


Skip,

I agree with you, but I also see quite a few vendors to the ZAP. a  
*LONG* time ago I screwed up a zap on Syncsort. I admit freely it was  
my error. This caused at least 2 addition phone calls for support to  
the vendor.


I think its in the best interest of the vendor to supply replacement  
mods, especially with the INTERNET speed. I am not sure I want to  
talk about the side issue of security. Yes that needs to be addressed  
(somehow). I would like to hear how others might address that issue.


Ed

--
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

Re: SMP/E SE37 Retry and ++ZAP

[Skip Robinson]

I'm surprised as well that ZAPs--which I thought overwrote blocks in
place--would lead to x37 problems. But I would rather comment on a problem
behind the stated problem: delivering vendor-supplied fixes as ZAPs rather
than CSECT replacements.

My view as a customer is that 'permanent' product maintenance ought to be
delivered in ++MOD format. ZAPs should be relegated strictly to APAR fixes:
emergency workarounds that alleviate pain in the short term while a module
revision is being developed and packaged. IBM, for example, almost never
ships a ++ZAP in a PTF. Other vendors do so for reasons that are equally
mysterious and suspect. I say 'suspect' because I fear that the motive is
to create an follow-your-taste smorgasbord of 'fixes' that the customer can
choose to install or not depending on...well, on what? How can a fix be
optional? If there's a problem, it needs a fix. If there's not a problem,
then something else may be in order. A usermod maybe. But not a PTF.

The power of this platform lies in good measure on a single path to glory.
IBM doesn't have to preach righteousness and hope for spirit to move us.
SMP/E enforces the straight and narrow. In order to install PTF C you must
first (or concurrently) install PTFs A and B. Violating this stricture is a
serious transgression. Consequently every customer with PTF C is running in
a known environment. The customer can expect a certain result, and if
there's a problem, IBM can diagnose and test in a duplicate environment.
That consistency benefits everybody.

So, as interested as I am in an informed answer to the ZAP question, I'm
far more interested in urging vendors to deliver PTFs that install
serially. In other words, successive element updates that lead everyone in
the same direction at the same pace. I don't trust ZAPs to fulfill that
hope.

.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 01/31/2006
04:35:05 PM:

> Lately I was testing a service installation containing
> ++ZAP MCS and receiving inexplicable verify failures.
> I also noticed multiple COMPRESSes to recover from
> SE37-04 ABENDs.  I started with the problem I knew how
> to solve, and increased the load library allocations.
> To my surprise, the ZAP verify problem vanished.
>


--
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

Re: SMP/E SE37 Retry and ++ZAP

[Arthur T.]

On 31 Jan 2006 16:35:27 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] wrote:



Lately I was testing a service installation containing
++ZAP MCS and receiving inexplicable verify failures.
I also noticed multiple COMPRESSes to recover from
SE37-04 ABENDs.  I started with the problem I knew how
to solve, and increased the load library allocations.
To my surprise, the ZAP verify problem vanished.

So, I wonder, does AMASPZAP update load modules in
place (somehow I had got the belief it does so), or
use conventional QSAM techniques and rewrite and STOW?
Essentially, can AMASPZAP cause a SE37 ABEND?


 I can't speak to your verify problem(s), but I *may* 
have the reason for your SE37 problem.


 AMASPZAP, indeed, does the update in place.  However, 
you're not necessarily running *just* AMASPZAP.  SMP ++ZAP 
can do an "expand zap" wherein it makes a CSECT (and 
therefore the LMOD) larger and zaps both the original area 
and the expanded area.  AMASPZAP can't change the size of a 
module, so SMP also calls LKED (or the BINDER), leading to 
the possibility of running out of space.


 You might want to see if the APARs causing E37s 
specify expand zaps. 


--
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

SMP/E SE37 Retry and ++ZAP

[Paul Gilmartin]

Lately I was testing a service installation containing
++ZAP MCS and receiving inexplicable verify failures.
I also noticed multiple COMPRESSes to recover from
SE37-04 ABENDs.  I started with the problem I knew how
to solve, and increased the load library allocations.
To my surprise, the ZAP verify problem vanished.

So, I wonder, does AMASPZAP update load modules in
place (somehow I had got the belief it does so), or
use conventional QSAM techniques and rewrite and STOW?
Essentially, can AMASPZAP cause a SE37 ABEND?

If AMASPZAP causes a SE37 ABEND, an attempt to recover
by COMPRESS and retry is largely futile.  Some modules
will remain in their original state at the instant of
ABEND; others modified by the ZAP.  The latter will get
verify errors on the retry.  The only way to avoid the
problem is to perform the ZAPs one module at a time.
If it succeeds, fine.  If SE37 occurs, the directory will
still contain the unmodified module and retry is possible.

Or have I completely misunderstood the source of the
verify errors?  If so, I'm puzzled at where they originated
and why the vanished coincidentally with resolution of
the out-of-space problem.

Thanks,
gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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