Non-SMP/e packaging

I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards t

Non-SMP/e Packaging

I guess I have to take strong exception to your characterization of my suggestion as a "misuse" of SMP/E. Yes, it is different than "normal", but my process suggestions offer significant benefits both to the vendor and the customer for those products whose installation requirements are simple

Fw: Non-SMP/e packaging

Forwarded to the list - Russ, can you change you return address please ???. > I would think my opinions on non-SMP delivery should be well known. > IMHO CA-1 has been very good with regard to SMP for quite a while > now. Somewhat of a beacon in that corporation. > > If it (unloaded, non-SMP delive

Re: Non-SMP/e packaging

I'm not CA-1 customer. Personally I would choose SMP/E, however it could depend on how the alternative way is designed. From the other hand I understand people who don't want SMP/E. It is too complex, and its complexity could give more troubles than profits. It is possible to do it simpler. I

FW: Non-SMP/e packaging

mber 12, 2006 12:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Non-SMP/e packaging I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in S

Re: Non-SMP/e packaging

But some vendors SMP/E usage is even worse than a non-SMP/E install. CA-1 may not be an offender, but I've spent a lot of time "fooling" SMP/E into applying vendor service that was poorly structured. If there is no trust in the SMP/E environment, it's not worth a 10 fold increase in time of instal

Re: Non-SMP/e packaging

Follow up to my last note; read the CA Common Services install process and see if SMP/E makes it easier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IB

Re: Non-SMP/e packaging

mmer Crawford & Company PH: 770 621 3256 * "Rugen, Len" <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 09/12/2006 08:40 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Non-SMP/e packaging Follow up to my last note;

Re: Non-SMP/e packaging

-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Russell Witt Sent: Monday, September 11, 2006 11:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Non-SMP/e packaging I had a request from a client today, asking when CA-1 would stop being delivered in

Re: Non-SMP/e packaging

I would hope 99% of us who have worked on this platform know and understand the benifits of SMP/E. I personally would choose an SMP/E install if I can over a non-SMP/E install but that may just be my "old-timer" prejudice showing. Trying to keep an open mind... Excluding major components (OS,

Re: Non-SMP/e packaging

Russell, I would suggest that you decline the request and say that since CA-1 "interacts" and is IBM module dependent it is in the best interest of all parties to be in a deliverable state which facilitates IBM maintenance. Ed On Sep 11, 2006, at 11:12 PM, Russell Witt wrote: I had a r

Re: Non-SMP/e packaging

On 11 Sep 2006 21:12:29 -0700, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Russell Witt) wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with c

Re: Non-SMP/e packaging

How many times have we seen an ISV's SMPE install that is simply an IEBCOPY unload and their CSI is less than acceptable. I have time and time again --- CA is a big culprit here had to manually go into the Receive sourcee and tweak their SYSMODs due to not even attempting to validate PREREQ

Re: Non-SMP/e packaging

Well said, it is impossible to replace 30+ years of experience and "feel" for the box with a GUI or equivalent dumbed-down product. Old (at 48) Timer. > I would hope 99% of us who have worked on this platform know and understand the benifits of SMP/E. I personally would choose an > SMP/E in

Re: Non-SMP/e packaging

On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: > >I would suggest that you decline the request and say that since CA-1 >"interacts" and is IBM module dependent it is in the best interest of >all parties to be in a deliverable state which facilitates IBM >maintenance. > It h

Re: Non-SMP/e packaging

75 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi/ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: 12 September 2006 09:49 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging

Re: Non-SMP/e packaging

On Tue, 2006-09-12 at 09:50 -0500, Tom Marchant wrote: > Innovation does a fine job without it. I wouldn't ask them to divert > resources from product development to provide proper SMP/E packaging. Of course, this would be an effort *much* larger than simply providing "proper packaging". IDP wou

Re: Non-SMP/e packaging

On Tue, 12 Sep 2006 09:50:10 -0500, Tom Marchant wrote: >On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould wrote: >> >>I would suggest that you decline the request and say that since CA-1 >>"interacts" and is IBM module dependent it is in the best interest of >>all parties to be in a deliverable state

Re: Non-SMP/e packaging

-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Tuesday, September 12, 2006 10:16 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging Of course, this would be an effort *much* larger than simply providing "p

Re: Non-SMP/e packaging

Mark Zelden wrote: [...] A perfect example is Innovation's FDR. I have used it in virtually I have never heard complaints about FDR support, etc. Is seems that SMP/E is not crucial to it. People discuss about *binary* alternatives: SMP/E or library unload. I think there are other ways to ma

Re: Non-SMP/e packaging

In a message dated 9/12/2006 11:03:25 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Why don't we think about "SMP2" - new approach, totally free of old junk. My $0.02 >> Well, if you're willing to accept the consequences. One of the local insurance companies signed onto auto-mai

Re: Non-SMP/e packaging

On Tue, 12 Sep 2006 18:02:49 +0200, R.S. <[EMAIL PROTECTED]> wrote: > >Why don't we think about "SMP2" - new approach, totally free of old junk. >My $0.02 See http://www.freepatentsonline.com/6715144.html to find out what Greg Daynes and company are thinking about. Doug --

Re: Non-SMP/e packaging

Ed Finnell wrote: In a message dated 9/12/2006 11:03:25 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Why don't we think about "SMP2" - new approach, totally free of old junk. My $0.02 Well, if you're willing to accept the consequences. One of the local insurance companies s

FW: Non-SMP/e packaging

You are thinking back to the days when UCC1 zapped IBM O/C/EOV modules instead of using SVCs and exit points to install their code. With zaps you MUST have the correct level of IBM code so pre-req entries were required. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 My experience must pre

Re: Non-SMP/e packaging

Russell Witt wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a req

Re: Non-SMP/e packaging

A Marketing rep? Well, there's your problem. A sysprog would have had the download done and the 60 miles driven in 2 or 3 minutes and would have used a flashlight and a magnifying glass to fix errors on the CD. Jon Well, if you're willing to accept the consequences. One of the local i

Re: Non-SMP/e packaging

In a message dated 9/12/2006 12:21:46 P.M. Central Standard Time, [EMAIL PROTECTED] writes: A Marketing rep? Well, there's your problem. A sysprog would have had the download done and the 60 miles driven in 2 or 3 minutes and would have used a flashlight and a magnifying glass to fix er

Re: Non-SMP/e packaging

Cole Software ships its z/XDC product in an SMP/E package, but we've made some unusual philosophical choices that result in a considerably simplified installation process as compared to the operating system and to most other products. Background: SMP/E is designed to support an incremental mai

Re: Non-SMP/e packaging

On 12 Sep 2006 10:28:29 -0700, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (David Cole) wrote: (c) So the maintenance job we provide does the following: RESTORE: This removes prior maintenance from the TLIBs, restoring them to their initial in

Re: Non-SMP/e packaging

On Tue, 12 Sep 2006 13:26:50 EDT Ed Finnell <[EMAIL PROTECTED]> wrote: :>In a message dated 9/12/2006 12:21:46 P.M. Central Standard Time, :>[EMAIL PROTECTED] writes: :>A Marketing rep? Well, there's your problem. A sysprog would have had the :>download done and the 60 miles driven in 2 or

Re: Non-SMP/e packaging

On Sep 12, 2006, at 9:50 AM, Tom Marchant wrote: On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: I would suggest that you decline the request and say that since CA-1 "interacts" and is IBM module dependent it is in the best interest of all parties to be in a deliverabl

Re: Non-SMP/e packaging

My choice would be to stick with SMP/E and not waste the time to create something else. I am not sure what is considered so difficult about SMP (from a customer perspective, I have never been a packager). The only time I find it difficult is when you stick something like Omegamons CICAT in fr

Re: Non-SMP/e packaging

Binyamin Dissen wrote: I don't think you can qualify as a true system programmer unless you (1) do something that causes the system to loop/crash and (2) you use the manual screen to fix memory so that an IPL is not needed How about entering stuff from the front panel and causing a machine c

Re: Non-SMP/e packaging

ssage- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Tuesday, September 12, 2006 11:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging Mark Zelden wrote: [...] > A perfect example is Innovation's FDR. I have used it in virtually I hav

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/11/2006 at 11:12 PM, Russell Witt <[EMAIL PROTECTED]> said: >I had a request from a client today, asking when CA-1 would stop >being delivered in SMP/e format and would be a simple >library-download. Ouch! >This client pointed to a number of other products that d

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/12/2006 at 08:49 AM, Mark Zelden <[EMAIL PROTECTED]> said: >Trying to keep an open mind... Excluding major components (OS, >subsystems like CICS/DB2/IMS etc.), would it really be that bad if >you just replaced the run time libs when you needed to upgrade / put >on

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/12/2006 at 06:02 PM, "R.S." <[EMAIL PROTECTED]> said: >Why don't we think about "SMP2" Because we outgrew it decades ago. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't care. W

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/12/2006 at 09:56 PM, Binyamin Dissen <[EMAIL PROTECTED]> said: >I don't think you can qualify as a true system programmer unless you >(1) do something that causes the system to loop/crash and >(2) you use the manual screen to fix memory so that an IPL is >

Re: Non-SMP/e packaging

FWIW, I keep hearing the same things from customers: 1. They want SMP/E. They don't like vendor- or product-specific procedures. Even if they're good ones, it's too much trouble to deviate from the standard. Time is precious, and it's nice to learn one way well. 2. They want more thoughtful

Re: Non-SMP/e packaging

On Tue, 12 Sep 2006 21:19:56 -0300 "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> wrote: :>In <[EMAIL PROTECTED]>, on 09/12/2006 :> at 09:56 PM, Binyamin Dissen <[EMAIL PROTECTED]> said: :>>I don't think you can qualify as a true system programmer unless you :>>(1) do something that causes th

Re: Non-SMP/e packaging

Timothy, I just ordered HOD V9 and I was told electronic download was no longer possible for the base product - only the PTFs. Where did you think you could get it from? I wasted weeks going round in circles with your colleagues. Regards, Alan. -

Re: Non-SMP/e packaging

[mailto:[EMAIL PROTECTED] On Behalf Of tony babonas Sent: 12 September 2006 20:35 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging I once installed a product called TASA from INFOSECINC. The package is downloadable from the company's web site as a binary file. It then is TSO REC

Re: Non-SMP/e packaging

I once installed a product called TASA from INFOSECINC. The package is downloadable from the company's web site as a binary file. It then is TSO RECEIVED into a samplib. The supplied install jobs do all the SMPE stuff. <<< Snippage Even TASID from IBM is done that way. But for an overall prod

Re: Non-SMP/e packaging

t [mailto:[EMAIL PROTECTED] On Behalf Of Daniel A. McLaughlin Sent: 13 September 2006 07:16 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging I once installed a product called TASA from INFOSECINC. The package is downloadable from the company's web site as a binary file. It then is

Re: Non-SMP/e packaging

At 9/12/2006 02:12 PM, ArthurT wrote: On 12 Sep 2006 10:28:29 -0700, David Cole wrote: (c) So the maintenance job we provide does the following: RESTORE: This removes prior maintenance from the TLIBs, restoring them to their initial installation state. REJECT

Re: Non-SMP/e packaging

In a recent note, Timothy Sipples said: > Date: Wed, 13 Sep 2006 13:55:22 +0900 > > I think it's certainly OK for software vendors to bring new products to > z/OS and worry less about SMP/E as they start. (I'd rather have the > products available than wait for the absolute finest SMP/E p

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/13/2006 at 10:41 AM, Binyamin Dissen <[EMAIL PROTECTED]> said: >Sometimes someone else causes the problem. Indeed, and when that happens you need to fix it. BTDTGTS[1][2]. Take the JOE side-chain mods - please! [1] No tee shirt, just the scars. [2] BTW, it wasn'

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/12/2006 at 07:37 PM, Gerhard Postpischil <[EMAIL PROTECTED]> said: >How about entering stuff from the front panel and causing a machine >check? How about just hitting the Restart key and causing a machine check? Which the CE claims is a software problem :-( --

Re: Non-SMP/e packaging

I wasn't going to say anything on this topic, but I finally decided to weigh in on it. I have mixed feelings. I like being able to just unload a couple libraries, run a couple of jobs, and then the product is installed. Products like FDR and ChicagoSoft's QuickRef I think are a lot easier ins

Re: Non-SMP/e packaging

Yes, what a wonderful idea! And, while we are at it, let's go back to keypunching source and JCL decks and microfiche. I miss keeping object decks at my desk. Sarcasm aside, SMP/E is just not an installation tool. SMP/E performs a myriad of functions that make my job easier. Yes, sometimes it

Re: Non-SMP/e packaging

Note: Significant and unmarked snippage throughout. On 13 Sep 2006 06:39:32 -0700, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (David Cole) wrote: I guess I have to take strong exception to your characterization of my suggestion as a "misuse" of SMP/E.

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 08:24:56 -0700, Mark Yuhas <[EMAIL PROTECTED]> wrote: > ... SMP/E is just not an installation tool. SMP/E performs a >myriad of functions that make my job easier No one has yet mentioned one of the big benefits of SMP/E that very few ISVs provide: HOLDDATA. How many

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 12:53:46 -0400, Arthur T. <[EMAIL PROTECTED]> wrote: > >On 13 Sep 2006 06:39:32 -0700, in bit.listserv.ibm-main >(Message-ID:<[EMAIL PROTECTED]>) >[EMAIL PROTECTED] (David Cole) wrote: > >>I guess I have to take strong exception to your >>characterization of my suggestion as a

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/13/2006 at 09:35 AM, David Cole <[EMAIL PROTECTED]> said: >In any case, my process uses proper SMP commands and packaging with >no degradation of SMP/E capabilities. One of SMP/E's capabilities is to install new functionality and service without having to first d

Re: Non-SMP/e packaging

At 9/13/2006 01:30 PM, TMerchant wrote: But why does it require that previously received maintenance be REJECTed and that previously APPLY'ed maintenance be RESTORed? Because our maintenance is cumulative, not incremental. - That means that the latest maintenance file always contains all

Re: Non-SMP/e packaging

At 9/13/2006 11:58 AM, SMetz wrote: In <[EMAIL PROTECTED]>, on 09/13/2006 at 09:35 AM, David Cole <[EMAIL PROTECTED]> said: >In any case, my process uses proper SMP commands and packaging with >no degradation of SMP/E capabilities. One of SMP/E's capabilities is to install new functionality

Re: Non-SMP/e packaging

On Sep 12, 2006, at 11:55 PM, Timothy Sipples wrote: FWIW, I keep hearing the same things from customers: SNIP some good stuff... Finally (and wondering aloud), there's this big "New Face of z" effort, as evidenced by such things as the no-charge IBM Tivoli OMEGAMON XE for z/

Re: Non-SMP/e packaging

I remember drag and drop installs on 3340's. "Hello, I dropped the SYSRES, can you drag one back from the vault?" > > There is one person who is going around saying that installing a > system will be drag and drop. If it really ever does come to that > the profession will have lost to the w

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 14:13:56 -0400, David Cole <[EMAIL PROTECTED]> wrote: >At 9/13/2006 01:30 PM, TMerchant wrote: That's Marchant, thank you. >>But why does it require that previously received maintenance be >>REJECTed and that previously APPLY'ed maintenance be RESTORed? > >Because our mainten

Re: Non-SMP/e packaging

Given the frequency of hiper alerts for V11 and 11.5, I think any departure from SMPE could lead to significant configuration problems. -Original Message- From: Russell Witt [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 9:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Non-SMP/e

Re: Non-SMP/e packaging

-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Wednesday, September 13, 2006 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging For our product doing a RESTORE (and REJECT) is a trivial inconvenience. Our

Re: Non-SMP/e packaging

PROTECTED] Sent: Tuesday, September 12, 2006 5:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging But some vendors SMP/E usage is even worse than a non-SMP/E install. CA-1 may not be an offender, but I've spent a lot of time "fooling" SMP/E into applying vendor service

Re: Non-SMP/e packaging

At 9/13/2006 02:37 PM, you wrote: On Wed, 13 Sep 2006 14:13:56 -0400, David Cole <[EMAIL PROTECTED]> wrote: >At 9/13/2006 01:30 PM, TMerchant wrote: That's Marchant, thank you. Sorry for the error. As for the rest, we each seem to disagree with everything the other has to say. I haven't

Re: Non-SMP/e packaging

At 9/13/2006 03:02 PM, SThompson wrote: If I don't have a clutch, and a shifter lever to horse around with while turning the wheel, talking on a hand-held cell phone, fiddling with the turn-signals, and adjusting the volume on the radio, I ain't happy. And what are you gonna do with it when the

Re: Non-SMP/e packaging

How about just hitting the Restart key and causing a machine check? Why would the RESTART key (which today is a function on the HMC, RESTART or PSW RESTART) cause a machine check?It causes a PSW RESTART, which loads a PSW from a defined low-store location. For many years, that PSW has inv

Re: Non-SMP/e packaging

-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Wednesday, September 13, 2006 2:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging The only thing I have against clutches is that it's hard to hold, uh, hands

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 14:13:56 -0400, David Cole <[EMAIL PROTECTED]> wrote: >At 9/13/2006 01:30 PM, TMerchant wrote: >>But why does it require that previously received maintenance be >>REJECTed and that previously APPLY'ed maintenance be RESTORed? > >Because our maintenance is cumulative, not increm

Re: Non-SMP/e packaging

I just did a quick count, I found 50 **.CSI.DATA files on my system. I have to get to the CORRECT SMP/E CSI before I can answer questions about proper maintenance levels. Maybe too many product installations start with "Create a new CSI"

Re: Non-SMP/e packaging

>You can't push start them automatics no more. I did it once as a kid. It took four guys and going downhill. I think you have to get moving at almost 50km/h. (That's 30mph for the metrically challenged). When in doubt. PANIC!! --

Re: Non-SMP/e packaging

Thanks for your comments, Mark. You raise some good points, requiring me to review choices originally made 15+ years ago. Almost all my maintenance is in the form of ++ZAPs. I do this because it simplifies various source management issues. Once I've published a release, there will be only one

Re: Non-SMP/e packaging

On 13 Sep 2006 11:26:08 -0700, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Ed Gould) wrote: There is one person who is going around saying that installing a system will be drag and drop. If it really ever does come to that the profession will have lost to th

Re: Non-SMP/e packaging

In a recent note, David Cole said: > Date: Wed, 13 Sep 2006 14:13:56 -0400 > > At 9/13/2006 01:30 PM, TMerchant wrote: > >But why does it require that previously received maintenance be > >REJECTed and that previously APPLY'ed maintenance be RESTORed? > > Because our maintenance is cumul

Re: Non-SMP/e packaging

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Arthur T. > Sent: Wednesday, September 13, 2006 3:05 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Non-SMP/e packaging > > > Actually, we'r

Re: Non-SMP/e packaging

Please also consider that we have to test everything that changed following maintenance. If you replace everything then everything has to be tested before roll out, as opposed to a targeted test of one area affected by a single PTF. (Not saying that this is hard for David's product but a concept.)

Re: Non-SMP/e packaging

lems then stick with it. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Wednesday, September 13, 2006 4:16 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging So the methodology works well. It is fast.

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 16:15:41 -0400, David Cole <[EMAIL PROTECTED]> wrote: >Thanks for your comments, Mark. You raise some good points, requiring >me to review choices originally made 15+ years ago. > You're welcome. >Almost all my maintenance is in the form of ++ZAPs. >So for each load modul

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 09:35:40 -0400, David Cole <[EMAIL PROTECTED]> wrote: >... >>> (c) So the maintenance job we provide does the following: >>> >>> RESTORE: This removes prior maintenance from the >>> TLIBs, restoring them to their initial installation >>> state. >>> >>>

Re: Non-SMP/e packaging

Patrick O'Keefe wrote: I agree with Arthur here. It souinds like your procedure just uses SMP as a driver for IEBCOPY. Yes, that's something SMP does, so I guess it's not a "misuse", but but it completely eliminates SMP's ability to coordinate maintenance (which is its only value, IM not so HO

Re: Non-SMP/e packaging

On Sep 13, 2006, at 3:04 PM, Arthur T. wrote: On 13 Sep 2006 11:26:08 -0700, in bit.listserv.ibm-main (Message- ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Ed Gould) wrote: There is one person who is going around saying that installing a system will be drag and drop. If it really ever does

Re: Non-SMP/e packaging

Seems vendors want to use a standard tool to do it their own (different) way - or ignore the fact said tool even exists. Pity the poor bastard that has to make the resultant "dogs breakfast" co-exist in a working production environment. Get it packaged, get it right. Shane ... --

Re: Non-SMP/e packaging

In a recent note, Alan Watthey said: > Date: Wed, 13 Sep 2006 10:10:22 +0200 > > I just ordered HOD V9 and I was told electronic download was no longer > possible for the base product - only the PTFs. > What?! No ShopZ? And I notice in this thread far more mention of feeding SMP/E with

Re: Non-SMP/e packaging

On Wed, 13 Sep 2006 14:28:36 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >Wouldn't SUPersede with element replacements accomplish the same >thing? (I know SUPersede is no good for ZAPs and IEBUPDTEs -- >BTDTGTS. DLI. NGDIA.) > SUP works fine for ZAPs, especially the way David is doing it.

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/13/2006 at 02:13 PM, David Cole <[EMAIL PROTECTED]> said: >Because our maintenance is cumulative, not incremental. It's not my dog. > - That means that all prior maintenance has to be removed > before the new maintenance file can be successfully > APPLY

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/13/2006 at 03:22 PM, Bruce Black <[EMAIL PROTECTED]> said: >Why would the RESTART key (which today is a function on the HMC, >RESTART or PSW RESTART) cause a machine check? Obviously because of a hardware glitch. But the CE refused to admit it until we dragged th

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/13/2006 at 04:04 PM, "Arthur T." <[EMAIL PROTECTED]> said: > If a drag-and-drop installation works, how can you consider it > a loss? That depends on what you mean by works. The Pinto worked, but I wouldn't want to be in one when it was rear ended. If

Re: Non-SMP/e packaging

At 14:13 -0400 on 09/13/2006, David Cole wrote about Re: Non-SMP/e packaging: Because our maintenance is cumulative, not incremental. - That means that the latest maintenance file always contains all maintenance, not just the most recent. A simple SUP (of all the prior Maintenance

Re: Non-SMP/e packaging

At 16:15 -0400 on 09/13/2006, David Cole wrote about Re: Non-SMP/e packaging: But SMP/E has a rather annoying restriction with respect to zap maintenance: "Only one ZAP can be applied to a module by a single APPLY command. If you need to install several ZAPs for a given m

Re: Non-SMP/e packaging

At 14:28 -0600 on 09/13/2006, Paul Gilmartin wrote about Re: Non-SMP/e packaging: Wouldn't SUPersede with element replacements accomplish the same thing? (I know SUPersede is no good for ZAPs Yes it is IF you just let the SUP insure that the VER would have worked and just have the RE

Re: Non-SMP/e packaging

At 9/13/2006 04:28 PM, you wrote: In a recent note, David Cole said: > Date: Wed, 13 Sep 2006 14:13:56 -0400 > > At 9/13/2006 01:30 PM, TMerchant wrote: > >But why does it require that previously received maintenance be > >REJECTed and that previously APPLY'ed maintenance be RESTORed? >

Re: Non-SMP/e packaging

At 9/13/2006 03:32 PM, LRugen wrote: I just did a quick count, I found 50 **.CSI.DATA files on my system. I have to get to the CORRECT SMP/E CSI before I can answer questions about proper maintenance levels. Maybe too many product installations start with "Create a new CSI" That's a good

Re: Non-SMP/e packaging

Dave wrote on 14/09/2006 05:33:21 PM: > >I just did a quick count, I found 50 **.CSI.DATA files on my system. I > >have to get to the CORRECT SMP/E CSI before I can answer questions about > >proper maintenance levels. Maybe too many product installations start > >with "Create a new CSI" > >

Re: Non-SMP/e packaging

At 9/13/2006 04:41 PM, MZelden wrote: I'm still not clear on the advatage SMP/E gives to you or your customers over a full IEBCOPY type replacement at each cumlative maintenance level. The only thing I can see for sure is that it would make auditors happy and shops that require SMP/E installed

Re: Non-SMP/e packaging

>> DLI. NGDIA.) >... Huh? Didn't like it. Not gonna do it again. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN

Re: Non-SMP/e packaging

At 9/13/2006 04:51 PM, PO'Keefe wrote: On Wed, 13 Sep 2006 09:35:40 -0400, David Cole wrote: I guess I have to take strong exception to your characterization of my suggestion as a "misuse" of SMP/E. ... I agree with Arthur here. It souinds like your procedure just uses SMP as a driver for IE

Re: Non-SMP/e packaging

David Cole wrote: At 9/13/2006 03:32 PM, LRugen wrote: I just did a quick count, I found 50 **.CSI.DATA files on my system. I have to get to the CORRECT SMP/E CSI before I can answer questions about proper maintenance levels. Maybe too many product installations start with "Create a new CSI"..

Re: Non-SMP/e packaging

At 9/13/2006 07:36 PM, SMetz wrote: On 09/13/2006 at 02:13 PM, David Cole <[EMAIL PROTECTED]> said: Because our maintenance is cumulative, not incremental. - That means that all prior maintenance has to be removed before the new maintenance file can be successfully APPLY'd. No it

Re: Non-SMP/e packaging

At 9/14/2006 04:40 AM, PGillis wrote: Dave, your maintenance strategy of restore prior to apply, could better be served by a single maintenance sysmod that contains all prior maintenance and SUPS all the potentially applied and accepted sysmods. Someone else may have suggested that during this

Re: Non-SMP/e packaging

On Thu, 14 Sep 2006 04:32:28 -0400 David Cole <[EMAIL PROTECTED]> wrote: :>At 9/13/2006 07:36 PM, SMetz wrote: :>>On 09/13/2006 at 02:13 PM, David Cole <[EMAIL PROTECTED]> said: :>>>Because our maintenance is cumulative, not incremental. :>>>- That means that all prior maintenance has to be re

Re: Non-SMP/e packaging

At 9/14/2006 05:00 AM, BDissen wrote: On Thu, 14 Sep 2006 04:32:28 -0400 David Cole <[EMAIL PROTECTED]> wrote: :>At 9/13/2006 07:36 PM, SMetz wrote: :>>On 09/13/2006 at 02:13 PM, David Cole <[EMAIL PROTECTED]> said: :>>>Because our maintenance is cumulative, not incremental. :>>>- That means

Re: Non-SMP/e packaging

In <[EMAIL PROTECTED]>, on 09/14/2006 at 03:15 AM, David Cole <[EMAIL PROTECTED]> said: >Right. My maintenance is in the for of ZAPs. And *that* is what is broken. Cumulative service should be PTF or FUNCTION, and ZAP is appropriate only for APAR and USERMOD. If you're relying on zaps for rout

  1   2   >