Re: SMP/E SE37 Retry and ++ZAP

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

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

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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 o

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

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

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

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

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

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

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

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

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

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

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 si

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

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

Re: SMP/E SE37 Retry and ++ZAP

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 int

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

ussion 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

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 i

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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 sh

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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 za

Re: SMP/E SE37 Retry and ++ZAP

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 us

Re: SMP/E SE37 Retry and ++ZAP

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 >

Re: SMP/E SE37 Retry and ++ZAP

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 t

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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 determinati

Re: SMP/E SE37 Retry and ++ZAP

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

Re: SMP/E SE37 Retry and ++ZAP

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 ra

Re: SMP/E SE37 Retry and ++ZAP

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 updat

Re: SMP/E SE37 Retry and ++ZAP

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 main

Re: SMP/E SE37 Retry and ++ZAP

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 s

SMP/E SE37 Retry and ++ZAP

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