Non-SMP/e packaging

[Russell Witt]

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 to simply giving people a loadlib that they could refresh on a
monthly/quarterly basis as required. This client pointed to a number of
other products that do not use SMP/e and he felt SMP/e way to cumbersome to
deal with (obviously, he was in charge of OEM products and not maintenance
to the operating system itself). Still, I have to ask, would clients prefer
to have an optional non-SMP/e installation procedure even when it means
having to download a fresh copy of the product in order to apply
maintenance?

I am not saying I can change the packaging of CA-1 by myself, but if many
clients are interested it is something I can push for. I have just never
seen a request like this before.

Russell Witt
CA-1 Level-2 Support Manager

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

Non-SMP/e Packaging

[Warner Mach]

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 enough that they can take advantage of it.

In any case, my process uses proper SMP commands and packaging with 
no degradation of SMP/E capabilities. It's not like I'm suggesting 
that nonsupported interfaces or methods be used.

So I will continue to strongly encourage my approach for those 
products that can benefit from it.


I am surprised that no one has mentioned the actual different
usages of SMP within IBM products themselves. As one of my 
fellow systems programmers once commented: "There is really
not one SMP. There is SMP as used for the operating system,
SMP as used in conjunction with CICS, and SMP as used in 
conjunction with IMS".

The way that SMP is used in conjunction with IMS is fully as far
from 'normal' as the use of SMP described in this thread.

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

Fw: Non-SMP/e packaging

[Shane Ginnane]

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 delivery) is an option, and causes more
> work for those choosing to use it who cares.
> If it becomes the default and causes more work for those of us that
> *do* maintain SMP environments it's all bad.
>
> As for other vendors shipping (only) non-SMP format, that's
> generally because they have no idea of how to package their product.
>
> Shane ...
CONFIDENTIAL
The information contained in this e mail and any attachments is
confidential. It is intended only for the named addressee(s). If you are
not the addressee(s) please notify the sender immediately. Do not disclose,
copy or distribute the contents to any other person other than the intended
addressee(s)

--
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: Non-SMP/e packaging

[R.S.]

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.
It's funny when someone ask about SRELs, the names 30+ years old - 
obviously missed conception. It is horrible how many commands, 
structures, objects are inside of SMP/E. It's both funny and horrible 
when I get CBPDO order: 40 tapes, only 5 of them contains product code, 
7 are empty (!) and 28 contains single "text file" - in fact some kind 
of installation description (and PTFs to be honest).


From the other hand  SMP/E already exist, while non-SMP/E method 
would be either very limited or would have to be created.



--
Radoslaw Skorupka
Lodz, Poland


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 request to go
backwards to simply giving people a loadlib that they could refresh on a
monthly/quarterly basis as required. This client pointed to a number of
other products that do not use SMP/e and he felt SMP/e way to cumbersome
to
deal with (obviously, he was in charge of OEM products and not
maintenance
to the operating system itself). Still, I have to ask, would clients
prefer
to have an optional non-SMP/e installation procedure even when it means
having to download a fresh copy of the product in order to apply
maintenance?

I am not saying I can change the packaging of CA-1 by myself, but if
many
clients are interested it is something I can push for. I have just never
seen a request like this before.

Russell Witt
CA-1 Level-2 Support Manager


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

FW: Non-SMP/e packaging

[Veilleux, Jon L]

 While SMP/E may be somewhat cumbersome to use, it is the best
repository for keeping information on what exactly is the current
maintenance level of a software product. Unloaded libraries may be
easier to use but aren't any help when there is a problem and you need
to know what level the code is at. I realize that the trend is to 'dumb
down' the systems programming requirements, but there are reasons why
z/OS is as stable as it is, and SMP/E plays a big part.
Personally, I wouldn't want to have to try to maintain and do problem
resolution on a system that didn't use SMP/E. It makes my job a lot
easier and is well worth the initial extra effort to install a product.
Ciao,
Jon

Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Russell Witt
Sent: Tuesday, September 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 SMP/e format. And this was the first time I had seen a
request to go backwards to simply giving people a loadlib that they
could refresh on a monthly/quarterly basis as required. This client
pointed to a number of other products that do not use SMP/e and he felt
SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM
products and not maintenance to the operating system itself). Still, I
have to ask, would clients prefer to have an optional non-SMP/e
installation procedure even when it means having to download a fresh
copy of the product in order to apply maintenance?

I am not saying I can change the packaging of CA-1 by myself, but if
many clients are interested it is something I can push for. I have just
never seen a request like this before.

Russell Witt
CA-1 Level-2 Support Manager

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

-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
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: Non-SMP/e packaging

[Rugen, Len]

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

CA used to promote CA-Activator (CA-Aggravator...) installs, may it rest
in pieces.

> 
>  While SMP/E may be somewhat cumbersome to use, it is the best
> repository for keeping information on what exactly is the current
> maintenance level of a software product. Unloaded libraries may be
> easier to use but aren't any help when there is a problem and you need
> to know what level the code is at. I realize that the trend is to
'dumb
> down' the systems programming requirements, but there are reasons why
> z/OS is as stable as it is, and SMP/E plays a big part.

--
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: Non-SMP/e packaging

[Rugen, Len]

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 IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-SMP/e packaging

[Daniel A. McLaughlin]

Whether one uses SMP/e or a vendor equivalent, it produces a more sound 
system. I've had products that are load and go (Plug and play?) and while 
they may work OK, maintenance is usually a module level replace and you 
aren't really sure what you've got.

I've used Activator with similar success to SMP/e, and I've even got my 
own way of updating exits whereas they aren't usermods. 

I'm wondering if the originator of the thread is leery of SMP/e, or feels 
that there aren't enough hours to do it.




Daniel McLaughlin
ZOS Systems Programmer
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; 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 IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.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: Non-SMP/e packaging

[Thompson, Steve (SCI TW)]

-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 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 to simply giving people a loadlib that they could refresh on a
monthly/quarterly basis as required. This client pointed to a number of
other products that do not use SMP/e and he felt SMP/e way to cumbersome
to
deal with (obviously, he was in charge of OEM products and not
maintenance
to the operating system itself). Still, I have to ask, would clients
prefer
to have an optional non-SMP/e installation procedure even when it means
having to download a fresh copy of the product in order to apply
maintenance?


Perhaps what you should do is have a survey done of your client base and
ask them.

But going back a few weeks, there was a discussion about this very
thing. Boole & Babbage used to provide (for AutoOPERATOR at least) two
tapes. The first was the load and go. The remainder and onto the second
tape was all the SMP/E files related to that load and go install. It was
entirely the customer's choice to only lay down the executables and
never put down the backing SMP/E files (basically, the SMP/E install was
a copy of the install that was done at ole Drool & Babble that had been
backed up to tape - everything was there).

Customers could choose to re-order the system, and they would get it
again, with all the maint already on it (all you had to do was wait
until a "PUT" was produced and then order it - what you got was the
customer install system with the PUT already applied).

As I recall (this was up to 1993), we had customers who never installed
the SMP/E components but only laid down the target files. One might
wonder why they would do it that way when some HIPER maint might come
out that they absolutely had to have (and yes, that happened a few times
too).

But, if the customers want things simple, and don't want to take up the
space, and you allow them to let you do all their maint and then ship it
to them to just lay down... Well, you might be able to market this and
have a charge for it.

Later,
Steve Thompson

--
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: Non-SMP/e packaging

[Mark Zelden]

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, 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 maintenance? 
Since almost all shops have high speed internet access and vendors
have electronic downloads, think of all the time and DASD (even though
DASD is "cheap") you would save by not having to deal with an SMP/E
environment and distribution libs. 

I hate to say it -  but think win-doze, PFCSKs, zNextGen. Think of a
small shop with few support people. If we truly want to attract new 
comers to this platform (or at least keep the existing install base)
and make it easier and quicker to install and maintain software, 
this may be a fine alternative to SMP/E for many products. 

I think what is important is to know exactly what level of software 
you are running to help in problem determination and to know "where 
do I go from here" to upgrade.  If vendors distributed well defined
levels of their software in run-time only format, this isn't an issue.

A perfect example is Innovation's FDR. I have used it in virtually
every shops I've been at for 20+ years. I have never missed having an
SMP/E install nor have I had any issues / problems related to 
problem determination because I didn't know exactly what level of
software I was running. Oh..and guess what... FDR only takes a couple
of hours to install (if that). 

Some of the people on this list keep telling us to get over ourselves 
and we probably need to.  The IT world has changed a lot in the last 20
years but this platform really hasn't for the most part. Putting windows 
GUIs and web wizard front ends to everything doesn't cut it because the
underlying processes are still too complex and "old-timer" experience 
is still needed when there is a problem. 

My 2 cents...

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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: Non-SMP/e packaging

[Ed Gould]

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 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 to simply giving people a loadlib that they could refresh  
on a
monthly/quarterly basis as required. This client pointed to a  
number of
other products that do not use SMP/e and he felt SMP/e way to  
cumbersome to
deal with (obviously, he was in charge of OEM products and not  
maintenance
to the operating system itself). Still, I have to ask, would  
clients prefer
to have an optional non-SMP/e installation procedure even when it  
means

having to download a fresh copy of the product in order to apply
maintenance?

I am not saying I can change the packaging of CA-1 by myself, but  
if many
clients are interested it is something I can push for. I have just  
never

seen a request like this before.

Russell Witt
CA-1 Level-2 Support Manager

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


--
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: Non-SMP/e packaging

[Arthur T.]

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 clients, I thought everyone wanted


 Even if we limit ourselves to sysprogs, I'm not sure 
if there's *anything* that *everyone* wants.



products delivered in
SMP/e format. And this was the first time I had seen a 
request to go
backwards to simply giving people a loadlib that they 
could refresh on a
monthly/quarterly basis as required. This client pointed 
to a number of
other products that do not use SMP/e and he felt SMP/e way 
to cumbersome to
deal with (obviously, he was in charge of OEM products and 
not maintenance
to the operating system itself). Still, I have to ask, 
would clients prefer
to have an optional non-SMP/e installation procedure even 
when it means

having to download a fresh copy of the product in order to apply
maintenance?


 For some products, this can make sense.  I don't 
think that CA-1 is one of them.


 I've seen some vendor(s) effectively do both:  They 
give the user replacement loadlibs *and* replacement SMP 
datasets.  If an emergency comes up between distro cycles, 
they can send a PTF, but otherwise the user never has to 
use SMP.  IMO, this should be reserved for fully 
self-contained products that are not expected to be in 
LNKLST, LPA, etc.


 I prefer to apply the maintenance, myself.  In some 
cases, it can be good to have the fine control of APPLYing 
some fixes and not others.  But, I can understand that some 
people would enjoy the ease of "copy these libraries and 
you're done".



--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" 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: Non-SMP/e packaging

[Pat Schlehuber]

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/COREQ 
checking. If a Vendor is not going to use SMPE as it is supposed to be 
used, don't even bother trying, I would rather just have an unload file and 
move on. Having to debug their code and also debug their SMPE logic is a 
waste of my time. And no, reporting the errors to them does not 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: Non-SMP/e packaging

[John Cassidy]

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 install if I can over a non-SMP/E install but that may just be my
"old-timer" prejudice showing.
>
> I think what is important is to know exactly what level of software you
are running to help in problem determination and to know "where do I go
from here" to upgrade.  If vendors distributed well defined levels of
their software in run-time only format, this isn't an issue.
>
> Some of the people on this list keep telling us to get over ourselves
and we probably need to.  The IT world has changed a lot in the last 20
years but this platform really hasn't for the most part. Putting windows
GUIs and web wizard front ends to everything doesn't cut it because the
underlying processes are still too complex and "old-timer" experience is
still needed when there is a problem.
>
> My 2 cents...
>


John Cassidy (Dipl.-Ingr.)

Berninastrasse 9

8057 Zuerich

Europe

Telephone: +41 (0) 43 300 4602

Mobile:+41 (0) 79 207 3268


E-Mail: [EMAIL PROTECTED]

http://www.JDCassidy.net

http://www.europeunited.org

http://en.wikipedia.org/wiki/Europe_United





John Cassidy (Dipl.-Ingr.)

Berninastrasse 9

8057 Zuerich

Europe

Telephone: +41 (0) 43 300 4602

Mobile:+41 (0) 79 207 3268


E-Mail: [EMAIL PROTECTED]

http://www.JDCassidy.net

http://www.europeunited.org

http://en.wikipedia.org/wiki/Europe_United

--
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: Non-SMP/e packaging

[Tom Marchant]

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 has been a long time since I did anything with CA-1, but I don't remember
it ever having IFREQs on IBM maintenance, or even going into the same zone
or belonging to Z038.  Unless I am mistaken, Ed's comment doesn't apply.

All it takes to nullify the advantages of an SMP/E installation is *one*
request from the vendor to apply service with BYPASS(ID).

That said, my preference has generally been for an SMP/E install, provided
that it is done correctly.  This is no trivial matter, and as Mark pointed
out.  Innovation does a fine job without it.  I wouldn't ask them to divert
resources from product development to provide proper SMP/E packaging.

Tom Marchant

--
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: Non-SMP/e packaging

[Rob Scott]

Being an ex-sysprog and now a developer I go for SMP/E every time (and I
haven't got *that* many grey hairs...) 

There is a small amount of extra pain to setup the environment in the
first place - but after that the benefits way exceed any issues.

>From a development point of view, SMP/E helps me make sure that when I
ship a PTF that I am hitting all of the objects that I intend to. Maybe
development shops with fancy source-control software feel comfortable
without - personally I need the belt and braces of both what SCLM *and*
SMP/E tell me.

Without SMP/E - I would probably go for some sort of full library
replacement technique (maybe with some sort of build number) and I can
see how that might work quite well for small self-contained products.

As for supplying individual member replacements outside of SMP/E - it
sorta makes me shudder.


Rob Scott
Rocket Software, Inc
275 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

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,
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
maintenance? 
Since almost all shops have high speed internet access and vendors have
electronic downloads, think of all the time and DASD (even though DASD
is "cheap") you would save by not having to deal with an SMP/E
environment and distribution libs. 

I hate to say it -  but think win-doze, PFCSKs, zNextGen. Think of a
small shop with few support people. If we truly want to attract new
comers to this platform (or at least keep the existing install base) and
make it easier and quicker to install and maintain software, this may be
a fine alternative to SMP/E for many products. 

I think what is important is to know exactly what level of software you
are running to help in problem determination and to know "where do I go
from here" to upgrade.  If vendors distributed well defined levels of
their software in run-time only format, this isn't an issue.

A perfect example is Innovation's FDR. I have used it in virtually every
shops I've been at for 20+ years. I have never missed having an SMP/E
install nor have I had any issues / problems related to problem
determination because I didn't know exactly what level of software I was
running. Oh..and guess what... FDR only takes a couple of hours to
install (if that). 

Some of the people on this list keep telling us to get over ourselves
and we probably need to.  The IT world has changed a lot in the last 20
years but this platform really hasn't for the most part. Putting windows
GUIs and web wizard front ends to everything doesn't cut it because the
underlying processes are still too complex and "old-timer" experience is
still needed when there is a problem. 

My 2 cents...

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead Zurich North America
/ Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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: Non-SMP/e packaging

[David Andrews]

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 would have to adapt its internal change
management procedures to coexist with SMP -- probably an awful lot of
work and local development upheaval.

-- 
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]

--
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: Non-SMP/e packaging

[Tom Schmidt]

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 which facilitates IBM
>>maintenance.
>>
>It has been a long time since I did anything with CA-1, but I don't 
remember
>it ever having IFREQs on IBM maintenance, or even going into the same zone
>or belonging to Z038.  Unless I am mistaken, Ed's comment doesn't apply.
>
>All it takes to nullify the advantages of an SMP/E installation is *one*
>request from the vendor to apply service with BYPASS(ID).
>
>That said, my preference has generally been for an SMP/E install, provided
>that it is done correctly.  This is no trivial matter, and as Mark pointed
>out.  Innovation does a fine job without it.  I wouldn't ask them to divert
>resources from product development to provide proper SMP/E packaging.
 
 
My experience must predate Tom's - I certainly do remember UCC-1 
maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.).  However, that was 
a long, long, long time ago and Russell's current methods might well no 
longer need that.  I do not, for example, recall having PTF issues with CA-
1 in the slightly more recent past.  And I am not now a CA-1 customer so I 
(a) can't say and (b) don't have a vote.  
 
But if Russell believes he can ship working code with or without SMP/E, I 
believe him.  
 
My present work location has contract requirements that ALL software must 
be installed via SMP/E (if SMP/E is at all an option).  Software that is 
not available via SMP/E is generally not allowed here.  
 
-- 
Tom Schmidt 
Madison, WI 
 

--
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: Non-SMP/e packaging

[Thompson, Steve (SCI TW)]

-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
"proper packaging".  IDP would have to adapt its internal change
management procedures to coexist with SMP -- probably an awful lot of
work and local development upheaval.


In a certain company's case, the change to SMP/E support allowed them to
go to source level maint. The number of fixes done by ZAP that some how
never got converted to source was a thorn in their side. In that case,
going to SMP/E based support was both simple and greatly desired
(internally) and answered a request by several of their customers.

However, your point is quite right. For certain companies with certain
products, it would take some time to change (with quite some effort) to
a change control system to match to the APAR/PTF scheme needed by SMP.
And it may not even be possible to change their current system so that
they would have to develop a new system. And while doing this, they
would have to make sure they didn't break things for their currently
supported products and customers. A conundrum.

Later,
Steve Thompson

--
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: Non-SMP/e packaging

[R.S.]

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 manage the code. Even SMP/E could be 
simpler. Current conceptions are for historical reasons, not because of 
real needs. Compromise between history and usability makes SMP/E 
difficult to understand and then cumbersome.


Why don't we think about "SMP2" - new approach, totally free of old junk.
My $0.02

--
Radoslaw Skorupka
Lodz, Poland

--
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: Non-SMP/e packaging

[Ed Finnell]

 
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-maint with AS/400 and got bit a couple  
years 
back when it destroyed their production data. They were only down 72 hours  
while the Marketing rep downloaded the updated CD and drove 60 miles to do the  
upgrade/
reinstall.

--
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: Non-SMP/e packaging

[Doug Henry]

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

--
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: Non-SMP/e packaging

[R.S.]

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 signed onto auto-maint with AS/400 and got bit a
couple  years 
back when it destroyed their production data. They were only down 72
hours  
while the Marketing rep downloaded the updated CD and drove 60 miles to
do the  
upgrade/

reinstall.


What consequences ?
Why do you think the new solution will be bad ?
Having that DB2 would never appear, the same for almost any new thing in IT.
Sometimes I observe such approach: do not touch anything. Usually 
problems arise when the change is a must, i.e. WLM goal mode.


--
Radoslaw Skorupka
Lodz, Poland

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

FW: Non-SMP/e packaging

[Veilleux, Jon L]

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 predate Tom's - I certainly do remember UCC-1
maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.).  However, that
was a long, long, long time ago and Russell's current methods might well
no longer need that.  I do not, for example, recall having PTF issues
with CA-
1 in the slightly more recent past.  And I am not now a CA-1 customer so
I
(a) can't say and (b) don't have a vote.  
 
But if Russell believes he can ship working code with or without SMP/E,
I believe him.  
 
My present work location has contract requirements that ALL software
must be installed via SMP/E (if SMP/E is at all an option).  Software
that is not available via SMP/E is generally not allowed here.  
 
--
Tom Schmidt
Madison, WI 
 

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

-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
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: Non-SMP/e packaging

[Edward Jaffe]

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 request to go
backwards to simply giving people a loadlib that they could refresh on a
monthly/quarterly basis as required. This client pointed to a number of
other products that do not use SMP/e and he felt SMP/e way to cumbersome to
deal with (obviously, he was in charge of OEM products and not maintenance
to the operating system itself). Still, I have to ask, would clients prefer
to have an optional non-SMP/e installation procedure even when it means
having to download a fresh copy of the product in order to apply
maintenance?

I am not saying I can change the packaging of CA-1 by myself, but if many
clients are interested it is something I can push for. I have just never
seen a request like this before.
  


A non-SMP/E install can seem desirable to someone without much SMP/E 
experience (or for whom a "re-boot" is considered a problem solution), 
but such an install introduces it's own set of problems, the most 
serious of which (IMHO) is its inability to "call in" required fixes for 
IBM components.


The most recent example for us was APAR OA17010 against RMF. That APAR 
fixed a serious problem with ERBSMFI that would result in a recovery 
loop when invoked by the current (E)JES release on back-level z/OS 
systems. Once IBM fixed the problem, we added the requisite IFREQ 
statements to our SMP/E MCS. We've had similar recent issues over the 
past couple of years with the z/OS Console Restructure, z990 
Exploitation Feature, JES2, JES3, OMVS, and other components. We can 
distribute our own fixes -- no problem. But, there's just no equivalent 
method for synchronizing required IBM maintenance when performing a 
non-SMP/E install!


Rather than taking any giant backward leaps (IEBCOPY and ZAPs give me 
bad dreams), I'm waiting patiently for IBM to finish the z/OS 
implementation of its cross-platform "Solution Installer". That should 
help relieve any "ease of use" issues associated with SMP/E while, at 
the same time, continuing to provide maintenance tracking and 
cross-component synchronization needed by complex products installed in 
a robust, mission-critical environment like z/OS.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
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: Non-SMP/e packaging

[Jon Brock]

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  
insurance companies signed onto auto-maint with AS/400 and got bit a couple  
years 
back when it destroyed their production data. They were only down 72 hours  
while the Marketing rep downloaded the updated CD and drove 60 miles to do the  
upgrade/
reinstall.


--
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: Non-SMP/e packaging

[Ed Finnell]

 
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 errors on the CD.   



>>
That's the beauty of downsizing. don't have to worry with no high-end  
sysprogs anymore just let the machine do the work! Until it breaksand
then teflon blades recommended on all circulating apparatus. No more  
designated blamees to point to.

--
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: Non-SMP/e packaging

[David Cole]

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 maintenance 
philosophy for huge and hugely complex software structures (the 
entire operating system, and its myriads or subproducts, for example).


Incremental?
  - You RECEIVE and APPLY new maintenance to a software base.
  - If you don't like it, you can RESTORE the base and then
REJECT the maintenance.
  - But if you do like it, you can then ACCEPT the
maintenance and, thereby, establish a NEW BASE for
subsequent maintenance.

So the "base" to which you RECEIVE and APPLY maintenance increments 
over time. And once maintenance has been ACCEPT'd into the base, you 
CANNOT remove it. All you can do is to RECEIVE, APPLY and ACCEPT 
superseding maintenance.


Supporting an incremental maintenance philosophy for complex and 
fluidly interrelated software systems requires complex capabilities. 
It's simply in the nature of the beast, so there is no way to keep 
both SMP/E and the maintenance process itself from being complex.





The major reason why Cole Software packages z/XDC with SMP/E is that 
it makes the management of post-release maintenance very simple for 
me, and it makes the installation of maintenance trivially simple for 
our customers. Also, it leads our customers to use an installation 
process that is uniform across our customer base, and from a support 
standpoint, that is extremely valuable.


But there are two things that we've done to our SMP/E process that 
are, perhaps, unique and that extensively simplify the process both 
for ourselves and for our customers. Both of these characteristics 
are made possible by the fact that, from an installation issues point 
of view, z/XDC is pretty simple. (They would not work for complex 
products with complex interrelations with other products.)


First, we follow a cumulative methodology (not an incremental one) 
for our maintenance. This means the following:


  (a) Every maintenance file that we publish contains all
  maintenance, accumulated since the product's release
  date. The nice thing about this is that when a
  customer needs to apply a year or two's worth of
  back maintenance, all he has to do is download,
  RECEIVE and APPLY just one maintenance file. That's
  all.

  (b) This requires the customer never to ACCEPT z/XDC
  maintenance. Why not? Because the cumulative
  maintenance file is always designed to fit the product
  as it was originally installed. If an ACCEPT were to
  be done, then the installation libraries would be
  irretrievably changed such that the maintenance file
  would no longer fit.

  (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: This removes the prior maintenance data from
SMP/E's database.

RECEIVE: This introduces the new maintenance file
into SMP/E's database.

APPLY: This applies the new maintenance to z/XDC's
TLIBS.

Second, we are able to insure that all dependances that z/XDC might 
have, either on Operating System capabilities or on other products, 
are resolved at EXECUTION time, not at installation time. By doing 
this, we are then able to require our customers to NOT install z/XDC 
into there existing SMP/E libraries, but instead to create an 
entirely independent set of SMP libraries (CSI, PTS, etc.) devoted 
solely to z/XDC!


The benefits of this are profound:

(1) Waste of disk space? NOT! After initial installation, the 
z/XDC-dedicated SMP database and libraries start out at 30 tracks. 
Ok, allowing reasonable space for expansion, it might be better to 
allocate a hundred or so (at most!).


(2) Since z/XDC's SMP/E datasets are independent from the rest of the 
system, we can impose optional settings that (a) are specific to 
z/XDC's maintenance needs and (b) are uniform across our customer 
base and (c) do not conflict with the needs of other products.


(3) Since the SMP/E datasets are independent and uniform, we can 
provide canned JCL for our customers to use that work right out of the box to:

  (a) Purge older SMP/E datasets (CSI, PTS, etc.) and
  product installation libraries (DLIBs and TLIBs)
  (b) Create new ones
  (c) Establish all needed SMP/E definitions and settings
  (d) Install the product into new TLIBs and DLIBs
  (e) Apply all accumulated maintenance
This is a suite of four jobs that take a grand total of four minutes 
to run (even on a flop-top system such as ours!).


(4) Since the SMP/E process is uniform and the SMP/E phase jobs are 
all canned, the installing programmer can run a successful install 
with no (zero na-

Re: Non-SMP/e packaging

[Arthur T.]

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

REJECT: This removes the prior maintenance data from
SMP/E's database.

RECEIVE: This introduces the new maintenance file
into SMP/E's database.

APPLY: This applies the new maintenance to z/XDC's
TLIBS.

 
I suspect that many (if not most) commercial products 
would benefit from taking an approach such as ours.


 Please don't encourage this misuse of SMP.

 I like your product, but this technique is contrary 
to the spirit of SMP.  Therefore, it causes cognitive 
dissonance in some of us who do understand SMP, and wish to 
use it correctly.  Since the technique is different from 
what I'm used to, it takes longer than if it were the 
normal, "complicated" SMP install of maintenance.  ACCEPT, 
(Optionally REJECT,) RECEIVE, APPLY is the normal route for 
mass maintenance, and takes very little time or thought, as 
long as the maintenance is packaged correctly.


 Since many sysprogs are "just" SMP jockeys, is it too 
much to ask that they be able to use SMP?  If they can, 
then there should be no need to "simplify" things for them.


N.B.
 Please note the quotes around 'just', above.  Those 
are scare quotes, not greengrocer quotes, and I mean no 
disparagement towards competent SMP jockeys.



--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" 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: Non-SMP/e packaging

[Binyamin Dissen]

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 3 minutes and would have  used 
:>a flashlight and a magnifying glass to fix errors on the CD.   

:>That's the beauty of downsizing. don't have to worry with no high-end  
:>sysprogs anymore just let the machine do the work! Until it breaksand
:>then teflon blades recommended on all circulating apparatus. No more  
:>designated blamees to point to.

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

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Non-SMP/e packaging

[Ed Gould]

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 deliverable state which facilitates IBM
maintenance.



SIGH/ They don't play nicely with others. So you are right, but  
there are other who do. I was not saying CA is good or bad and I was  
not making my comments saying one vendor is good or bad.  There are  
vendors who do play by the rules some don't. Some who do not need to  
know what maintenance level is. A program that opens a file processes  
records probably does not need to know the PTF level of MVS. (there  
are some exceptions but I won't point fingers at this time).


Programs that are dependent on mvs PTF level are IMO a must for smpe  
packaging. I know of one vendor that is extremely dependent on JES2  
maintenance levels. I honestly don't remember if they SMPe packaged  
or not but I have read a bucket from the vendor and they talk about  
IBM PTF numbers. I do remember that they expect *YOU* (or your  
company) to be on almost bleeding edge JES2 maintenance.


Ed

It has been a long time since I did anything with CA-1, but I don't  
remember
it ever having IFREQs on IBM maintenance, or even going into the  
same zone
or belonging to Z038.  Unless I am mistaken, Ed's comment doesn't  
apply.


All it takes to nullify the advantages of an SMP/E installation is  
*one*

request from the vendor to apply service with BYPASS(ID).

That said, my preference has generally been for an SMP/E install,  
provided
that it is done correctly.  This is no trivial matter, and as Mark  
pointed
out.  Innovation does a fine job without it.  I wouldn't ask them  
to divert

resources from product development to provide proper SMP/E packaging.

Tom Marchant

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


--
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: Non-SMP/e packaging

[Greg Saccomanno]

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 front of it.  Those tools to simplify the install only seem to make it 
harder and take much longer (unless you go with blind faith or do it 
frequently enough to remember the idiosyncrasies).  If there are 
customization steps in addition to SMP just spell them out and let me do 
the customization.

Now, of course in some cases a full replacement process may be fast and 
easy but its more annoying and time consuming to have to know the 
peculiarities each vendor can come up with for installing/supporting their 
product(s).  If the product is that simple, the SMP install should also be 
simple (again, I don't know what the packager has to go through to get it 
ready for me but defining a few SMP data sets then running 
receive/apply/accept from then on really isn't that big a deal).

Remember, you asked for opinions and just about everyone has one :)

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: Non-SMP/e packaging

[Gerhard Postpischil]

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


Gerhard Postpischil
Bradford, VT

--
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: Non-SMP/e packaging

[tony babonas]

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.

Seems the best of both worlds.



-Original Message-
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 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 manage the code. Even
SMP/E could be 
simpler. Current conceptions are for historical
reasons, not because of 
real needs. Compromise between history and usability
makes SMP/E 
difficult to understand and then cumbersome.

Why don't we think about "SMP2" - new approach, totally
free of old junk.
My $0.02

-- 
Radoslaw Skorupka
Lodz, Poland

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

--
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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 do not use 
>SMP/e

It's not my dog.

>I am not saying I can change the packaging of CA-1 by myself, but if
>many clients are interested it is something I can push for.

I see nothing wrong with helping him to shoot himself in the foot as
long as you don't impose it on your other customers. I'd consider the
lack of proper SMP packaging to be a significant reason for dropping a
product, other things being equal.

-- 
 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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

It would be a service nightmare.

>I hate to say it -  but think win-doze, 

Is that QOS acceptable to you?

-- 
 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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. 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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

(3) Stop doing (1)

(4) Eliminate the need for (2)
 
-- 
 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: Non-SMP/e packaging

[Timothy Sipples]

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 SMP/E designs (and documentation) for each
product.  It is possible to make any SMP/E procedure easy or hard.

One example I remember is WebSphere Host On-Demand, which originally had a
"just dump these files to HFS, change the Domino Go HTTP for z/OS config,
..." installation procedure.  It was all manual.  Then (Version 3? 4?)
SMP/E packaging came into being, but we techies wrestled with that for a
couple versions until the product team figured out how to do it right,
including the tape ordering and shipment mechanics. Nowadays it's pretty
slick as the SMP/E packaging got more refined and the delivery mechanisms
improved, including electronic delivery for both original versions and
patches. There were lots of incremental improvements along the way for
operational convenience that wouldn't be appreciated without some mainframe
experience, many of which my customers recommended and that we implemented.

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 packaging.)  But
as a product matures this is a good area to improve, because it makes
everybody's job easier (including the vendor's).

Are there any "exceptional" examples of SMP/E packaging that people would
point to as "the best"?  Perhaps that would help educate vendors, because a
lot of them do probably scratch their heads wondering if SMP/E is worth it
during their early development phases.

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/OS
Management Console.  Maybe there's room here for some new SMP/E face.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
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: Non-SMP/e packaging

[Binyamin Dissen]

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 the system to loop/crash and  

:>>(2) you use the manual screen to fix memory so that an IPL is
:>>not needed

:>(3) Stop doing (1)

In Ye Olde Days, quite often stuff was put on live systems. My understanding
is that such activities are frowned on nowadays.

:>(4) Eliminate the need for (2)

Sometimes someone else causes the problem.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Non-SMP/e packaging

[Alan Watthey]

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.

--
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: Non-SMP/e packaging

[Rob Scott]

Pretty much what we do with MXI G2 - much easier (and cheaper) than
cutting and mailing cartridges. 



Rob Scott
Rocket Software, Inc
275 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 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 RECEIVED into a
samplib.   The supplied install
jobs do all the SMPE stuff.

Seems the best of both worlds.



-Original Message-
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 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 manage the code. Even SMP/E could be
simpler. Current conceptions are for historical reasons, not because of
real needs. Compromise between history and usability makes SMP/E
difficult to understand and then cumbersome.

Why don't we think about "SMP2" - new approach, totally free of old
junk.
My $0.02

--
Radoslaw Skorupka
Lodz, Poland

--
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: Non-SMP/e packaging

[Daniel A. McLaughlin]

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 product install 
sometimes SMPe makes sense, other times not so much. Some vendors use full 
file replacements, as I recall, and that works just as well.

 




Daniel McLaughlin
ZOS Systems Programmer
Crawford & Company
PH: 770 621 3256
*









--
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: Non-SMP/e packaging

[Rob Scott]

TASID just uses the XMIT format datasets and then you run with the
resultant datasets - there is no SMP/E involved.

I think what the original poster was on about was that the XMIT format
datasets are received and then SMP/E JCL is run using the dataset
contents.

This is what we do :

Each FMID "package" is supplied (in TSO XMIT form) as a PDS with members
called "SMPMCS" and "Fn" where Fn is the relfile number.

These members are themselves unloaded datasets in TSO XMIT format - you
just run some sample JCL to unXMIT them into normal datasets amd then
run the  SMP/E RECEIVE using these DASD datasets as SMPPTFIN input
instead of the traditional cart/tape input.



Rob Scott
Rocket Software, Inc
275 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 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 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 product
install sometimes SMPe makes sense, other times not so much. Some
vendors use full file replacements, as I recall, and that works just as
well.

 




Daniel McLaughlin
ZOS Systems Programmer
Crawford & Company
PH: 770 621 3256
*

--
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: Non-SMP/e packaging

[David Cole]

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: This removes the prior maintenance data from
SMP/E's database.

RECEIVE: This introduces the new maintenance file
into SMP/E's database.

APPLY: This applies the new maintenance to z/XDC's
TLIBS.

 
I suspect that many (if not most) commercial products would benefit 
from taking an approach such as ours.


 Please don't encourage this misuse of SMP.


Hi Arthur,

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 enough that they can take advantage of it.


In any case, my process uses proper SMP commands and packaging with 
no degradation of SMP/E capabilities. It's not like I'm suggesting 
that nonsupported interfaces or methods be used.


So I will continue to strongly encourage my approach for those 
products that can benefit from it.







I like your product [thank you -dbc], but this technique is contrary 
to the spirit of SMP. [I'm not sure I agree that SMP has a "spirit". 
;)] Therefore, it causes cognitive dissonance in some of us who do 
understand SMP, and wish to use it correctly.  Since the technique 
is different from what I'm used to, it takes longer than if it were 
the normal, "complicated" SMP install of maintenance.  ACCEPT, 
(Optionally REJECT,) RECEIVE, APPLY is the normal route for mass 
maintenance, and takes very little time or thought, as long as the 
maintenance is packaged correctly.


As I explicitly state in z/XDC's Installation Guide:

"If you don't like SMP, if you don't know SMP, if you
don't want to know SMP, then this is the installation
process for you. It is self contained, and it works very
well. Just use the installation jobs and process that
I've supplied, and you won't have to go anywhere near
your system's SMP libraries. In fact, you will have an
easier time then the experienced Sysprog who is probably
going to insist on remangling this stuff into something
that works 'the right way'. (Oh well.)"

Note particularly the last sentence:
"In fact, you will have an easier time then the
experienced Sysprog who is probably going to insist on
remangling this stuff into something that works 'the
right way'."
Perhaps your view of the "correct" way of using SMP is more limited 
than it could be?







Since many sysprogs are "just" SMP jockeys, is it too much to ask 
that they be able to use SMP?  If they can, then there should be no 
need to "simplify" things for them.


Many of my customers are small shops that cannot afford to hire 
people dedicated to being "SMP jockeys". So, anything I can do to 
simplify their lives with respect to my product, they're grateful for.


In fact, the same goes for the large shops as well. Even the 
dedicated SMP jockeys appreciate the exceedingly low impact that the 
SMP/E phase of z/XDC's installation process has on their lives. 
They've already got more than enough to do coping with the more 
complicated installs.


And of course, appreciative customers benefit us in many ways.


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Paul Gilmartin]

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 packaging.)  But
> as a product matures this is a good area to improve, because it makes
> everybody's job easier (including the vendor's).
> 
On the whole, it's easier for the vendor if a new product is designed
from the start to meet the requirements of SMP/E packaging and service
delivery.  The alternative is too likely that the developers confront
the SMP/E packaging specialist as the deadline approaches:  "Marketing
says we need our product SMP/E packaged.  Here are the PROCLIBs,
LOADLIBs, and MACLIBs ..."

-- 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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't just to avoid an IPL, it was to avoid
a cold start.
 
-- 
 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 :-(
 
-- 
 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: Non-SMP/e packaging

[Eric N. Bielefeld]

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 
installed without SMP/E.  As the complexity of the product grows, using 
SMP/E becomes more necessary.  I would vote for the original poster of this 
question to make SMP/E or an IEBCOPY unload an option.  I've never used any 
of their products, so I don't know what is involved in installing them.


It's been a few years since I've installed Syncsort, but I believe they give 
you the option to use either.  I always did Syncsort without SMP/E.  I 
usually used the non SMP/E method if givin the choice.  It usually went 
quicker.  Also, I always had a gripe about installing an extra 20 or 30 
datasets that get allocated with SMP installs, especially since most of them 
went into its own set of SMP libraries.  I know disk is cheap, but I always 
bothered me to allocate all of those libraries.


I do see the value in having a standard way of installing all program 
products using SMP/E, but I also like having a choice.


Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee Wisconsin
414-475-7434


--
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: Non-SMP/e packaging

[Mark Yuhas]

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 is
frustrating, but, the benefits of SMP/E far and away outweigh the
frustrations.

--
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: Non-SMP/e packaging

[Arthur T.]

 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. 
Yes, it is different than "normal",


In any case, my process uses proper SMP commands and 
packaging with no degradation of SMP/E capabilities. It's 
not like I'm suggesting that nonsupported interfaces or 
methods be used.


 Using a system in a way that was never envisioned by 
the creators can be brilliant innovation.
It can also be what is termed "gaming the system".  That 
latter is sometimes ethically dubious.  The fact that 
you're not breaking any SMP rules doesn't, automatically, 
make your technique not a misuse.  I will certainly admit 
that it's much better than requiring BYPASSID, hand-editing 
PTFIN, or onerous additional manual steps (each of which 
has been required by other vendors).



"If you don't like SMP, if you don't know SMP, if you
don't want to know SMP, then this is the installation
process for you.



   "In fact, you will have an easier time then the
experienced Sysprog who is probably going to insist on
remangling this stuff into something that works 'the
right way'."
Perhaps your view of the "correct" way of using SMP is 
more limited than it could be?


 Perhaps.

Many of my customers are small shops that cannot afford to 
hire people dedicated to being "SMP jockeys". So, anything 
I can do to simplify their lives with respect to my 
product, they're grateful for.


 Given what your product is used for, I'm surprised to 
find that it's used by very small shops.  Since it is, I'll 
certainly grant that those shops might have an easier time 
with your technique.


In fact, the same goes for the large shops as well. Even 
the dedicated SMP jockeys appreciate the exceedingly low 
impact that the SMP/E phase of z/XDC's installation 
process has on their lives.


 That will vary from person to person.  If you said, 
"Even some dedicated ...", instead of "Even the dedicated 
...", I'd agree with you.  I'm not sure where I'd stand 
with "most" instead of "some".


 Seeing that no one else, here, is jumping in to agree 
with me, I may have to accept "most".


 You've found a technique that you like and that gets 
very little negative comment.  I can't, and probably 
shouldn't, argue with that.  So, I'll stop.



--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" 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: Non-SMP/e packaging

[Tom Marchant]

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 vendors publish anything like IBM's
Enhanced HOLDDATA to inform users of known PEs?

Tom Marchant

--
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: Non-SMP/e packaging

[Tom Marchant]

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 "misuse" of SMP/E.
>>Yes, it is different than "normal",
>
>>In any case, my process uses proper SMP commands and
>>packaging with no degradation of SMP/E capabilities. It's
>>not like I'm suggesting that nonsupported interfaces or
>>methods be used.

But why does it require that previously received maintenance be
REJECTed and that previously APPLY'ed maintenance be RESTORed?
>
>  Using a system in a way that was never envisioned by
>the creators can be brilliant innovation.
>It can also be what is termed "gaming the system"...

Well said

>>In fact, the same goes for the large shops as well. Even
>>the dedicated SMP jockeys appreciate the exceedingly low
>>impact that the SMP/E phase of z/XDC's installation
>>process has on their lives.
>
>  That will vary from person to person.  If you said,
>"Even some dedicated ...", instead of "Even the dedicated
>...", I'd agree with you.  I'm not sure where I'd stand
>with "most" instead of "some".
>
>  Seeing that no one else, here, is jumping in to agree
>with me, I may have to accept "most".

I, for one, agree with you, Arthur.
>
>  You've found a technique that you like and that gets
>very little negative comment.  I can't, and probably
>shouldn't, argue with that.  So, I'll stop.
>
Tom Marchant

--
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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 do a restore. Your description seems
to imply a degradation of that capability.
 
-- 
 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: Non-SMP/e packaging

[David Cole]

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 maintenance, not just the most recent.
  - That means that the file as a whole has to be APPLY'd to
the instance of the product that existed immediately
after initial install.
  - That means that all prior maintenance has to be removed
before the new maintenance file can be successfully
APPLY'd.
  - And that's what RESTORE and REJECT do.
  - And that's why our canned maintenance JCL contains
RESTORE, REJECT, RECEIVE and APPLY, in that order.
In other words, the process is fully automated by a
single job.

Note, the only time our maintenance job fails is when the SYSPROG 
does an ACCEPT of prior maintenance. Doing that prevents RESTORE from 
reverting the libraries to their initial installation state (a state 
which the cumulative maintenance file does NOT fit.)


But even that's not so bad, because it also is trivially easy for the 
customer to recover simply by rerunning the initial installation 
jobs, a process that, for our product, takes about 4 minutes.


As I said in my initial post, the advantage of cumulative maintenance 
over incremental maintenance is that customers, when they eventually 
get around to applying maintenance (a far less frequent event than I 
would like), need only download the latest maintenance file. They 
don't need to go scurrying around looking for older maintenance, and 
I don't need to maintain the older maintenance as individual files.







Using a system in a way that was never envisioned by the creators 
can be brilliant innovation. It can also be what is termed "gaming 
the system"...


Well said


I prefer to call it, simply, a good idea.



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[David Cole]

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 and
service without having to first do a restore. Your description seems
to imply a degradation of that capability.


For our product doing a RESTORE (and REJECT) is a trivial 
inconvenience. Our canned maintenance JCL contains RESTORE, REJECT, 
RECEIVE and APPLY, in that order. In other words, the process is 
fully automated by a single job that runs, on most systems, in less 
than one minute.




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Ed Gould]

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

Management Console.  Maybe there's room here for some new SMP/E face.




Timothy,

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


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: Non-SMP/e packaging

[Rugen, Len]

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 wintel platform.
> 
> Ed
archives at http://bama.ua.edu/archives/ibm-main.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: Non-SMP/e packaging

[Tom Marchant]

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 maintenance is cumulative, not incremental.
>   - That means that the latest maintenance file always
> contains all maintenance, not just the most recent.

There is no reason you couldn't have a new PTF that SUPed all
previous maintenance, nor is there any reason you couldn't 
include all maintenance in a single file.

>   - That means that the file as a whole has to be APPLY'd to
> the instance of the product that existed immediately
> after initial install.

That is not proper packaging of maintenance.

>   - That means that all prior maintenance has to be removed
> before the new maintenance file can be successfully
> APPLY'd.

That is because the maintenance is poorly designed.

>   - And that's what RESTORE and REJECT do.

But that is not what RESTORE and REJECT are for.

>   - And that's why our canned maintenance JCL contains
> RESTORE, REJECT, RECEIVE and APPLY, in that order.
> In other words, the process is fully automated by a
> single job.

It sounds to me as if your installation and maintenance processes
do not benefit at all from the use of SMP/E
>
>Note, the only time our maintenance job fails is when the SYSPROG
>does an ACCEPT of prior maintenance. Doing that prevents RESTORE from
>reverting the libraries to their initial installation state (a state
>which the cumulative maintenance file does NOT fit.)

Therefore your maintenance is not properly packaged.
>
>But even that's not so bad, because it also is trivially easy for the
>customer to recover simply by rerunning the initial installation
>jobs, a process that, for our product, takes about 4 minutes.
>
>As I said in my initial post, the advantage of cumulative maintenance
>over incremental maintenance is that customers, when they eventually
>get around to applying maintenance (a far less frequent event than I
>would like), need only download the latest maintenance file. They
>don't need to go scurrying around looking for older maintenance, and
>I don't need to maintain the older maintenance as individual files.
>
>
>
>
>
>
>>>Using a system in a way that was never envisioned by the creators
>>>can be brilliant innovation. It can also be what is termed "gaming
>>>the system"...
>>
>>Well said
>
>I prefer to call it, simply, a good idea.
>
Those are not the words that come to my mind.

Tom Marchant

--
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: Non-SMP/e packaging

[Schwarz, Barry A]

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 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 to simply giving people a loadlib that they
could refresh on a monthly/quarterly basis as required. This client
pointed to a number of other products that do not use SMP/e and he felt
SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM
products and not maintenance to the operating system itself). Still, I
have to ask, would clients prefer to have an optional non-SMP/e
installation procedure even when it means having to download a fresh
copy of the product in order to apply maintenance?

I am not saying I can change the packaging of CA-1 by myself, but if
many clients are interested it is something I can push for. I have just
never seen a request like this before.

Russell Witt
CA-1 Level-2 Support Manager

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

--
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: Non-SMP/e packaging

[Thompson, Steve (SCI TW)]

-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 canned maintenance JCL contains RESTORE, REJECT, 
RECEIVE and APPLY, in that order. In other words, the process is 
fully automated by a single job that runs, on most systems, in less 
than one minute.



Does this remind any one of the Automatic vs. Manual transmission
arguments of yesteryear?

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 battery dies? You can't push
start them automatics no more.

Later,
Steve Thompson

--
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: Non-SMP/e packaging

[Schwarz, Barry A]

Unfortunately, CA-1 has taken a big step backwards.  There currently are
three versions using the same FMID.  Recent updates have provided the
fun challenges of a V11 SYSMOD having a PREREQ for a V11.5 SYSMOD and a
V11 FMID-1 SYSMOD having a PREREQ (not an IFREQ) for an FMID-2 SYSMOD
when FMID-2 is not installed in most sites.  This on top of the fact
that 99% of the PTFs are coded as ++APAR.  And someone needs to learn
the difference between PRE and SUP.  But they are doing a better job
with HOLD and PE so there may be hope.

-Original Message-
From: Rugen, Len [mailto:[EMAIL 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 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 installation.  

CA used to promote CA-Activator (CA-Aggravator...) installs, may it rest
in pieces.

> 
>  While SMP/E may be somewhat cumbersome to use, it is the best 
> repository for keeping information on what exactly is the current 
> maintenance level of a software product. Unloaded libraries may be 
> easier to use but aren't any help when there is a problem and you need

> to know what level the code is at. I realize that the trend is to
'dumb
> down' the systems programming requirements, but there are reasons why 
> z/OS is as stable as it is, and SMP/E plays a big part.

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

--
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: Non-SMP/e packaging

[David Cole]

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 convinced you, and your response certainly does 
not convince me.


I guess we're just going have to leave it at that.

Deve Cole

--
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: Non-SMP/e packaging

[David Cole]

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 battery 
dies? You can't push start them automatics no more.


The only thing I have against clutches is that it's hard to hold, uh, 
hands with your sweetie when gearing down for a turn. Other than 
that, I HATE automatics!



[;)]
Dave

--
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: Non-SMP/e packaging

[Bruce Black]

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 invoked a system recovery routiine; as I recall, it usually is used 
when some system task is looping and can't be cancelled so it results in 
a S071 abend of that task.  Something like that


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.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: Non-SMP/e packaging

[Thompson, Steve (SCI TW)]

-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 with your sweetie when gearing down for a turn. Other than 
that, I HATE automatics!


You better. You make a living off of manual operators like us here at
Sterling.

Later,
Steve Thompson

--
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: Non-SMP/e packaging

[Mark Zelden]

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

So?

>   - That means that the latest maintenance file always
> contains all maintenance, not just the most recent.

Okay. That's a good thing.  

>   - That means that the file as a whole has to be APPLY'd to
> the instance of the product that existed immediately
> after initial install.

Because of the way you are packaging sample jobs and sysmods?

>   - That means that all prior maintenance has to be removed
> before the new maintenance file can be successfully
> APPLY'd.
>   - And that's what RESTORE and REJECT do.
>   - And that's why our canned maintenance JCL contains
> RESTORE, REJECT, RECEIVE and APPLY, in that order.
> In other words, the process is fully automated by a
> single job.
>

If all the PTF relationships are correct, why can't someone just
receive the cumulative maintenance and apply what hasn't been
applied previously? 

I guess for a small product your method works, but I don't 
see where it is any easier.  I would hate to do all that
extra restore / reject work for nothing.  Even prior to
RECEIVE ZONEGROUP(ALLZONES) (which has been available 
since OS/390 2.5) you could have supplied one additional
REJECT PURGE(dlibzone) ("mass mode reject") after your 
receive job to get rid of any extra sysmods received that
had already been accepted.  If they had not been accepted,
they wouldn't get re-received anyway. 

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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: Non-SMP/e packaging

[Rugen, Len]

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"  

--
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: Non-SMP/e packaging

[Ted MacNEIL]

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

--
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: Non-SMP/e packaging

[David Cole]

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 source library I have to keep for that release.


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 module, each one must be packaged separately
and installed by a separate APPLY command."

(from the ++ZAP MCS section of the SMP/E Reference
manual)

This means that if I packaged multiple fixes (to a single load 
module) into multiple ++APARs, then I would not be able to have them 
applied via a single APPLY command. Instead, I would have to require 
the SYSPROG to use a different APPLY command for each ++APAR. That 
would impose an unacceptable burden upon the SYSPROG.


It also leads to the incremental maintenance process being 
unacceptably complex, because when a customer decides to download and 
apply a year's worth of back maintenance, the one zap per module per 
APPLY restriction would require that customer to run as many 
APPLY-and-ACCEPT steps as there were fixes!


So for each load module, I have to gather my zaps together into a 
single ++APAR.


Well, after thinking about this requirement for awhile, and 
considering and testing various packaging strategies, I came to 
realized that treating maintenance as being cumulative rather than 
incremental was by far the best response to this restriction.


That was what got me started with the cumulative idea. But once 
there, a whole lot of other benefits (amply described in my prior 
posts) began cropping up.


So the methodology works well.
It is fast.
It is simple.
It is reliable.
It is easy for me to maintain and support.
It insures a high level of consistency across my customer base.
I'm happy with it.
My customers are happy with it.

So exactly, what is it I'm supposed to be caring about here?





At 9/13/2006 03:27 PM, MZelden wrote:

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


So?


   - That means that the latest maintenance file always
 contains all maintenance, not just the most recent.


Okay. That's a good thing.


Thanks.







   - That means that the file as a whole has to be APPLY'd to
 the instance of the product that existed immediately
 after initial install.


Because of the way you are packaging sample jobs and sysmods?


No, because the 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.
   - And that's what RESTORE and REJECT do.
   - And that's why our canned maintenance JCL contains
 RESTORE, REJECT, RECEIVE and APPLY, in that order.
 In other words, the process is fully automated by a
 single job.


If all the PTF relationships are correct, why can't someone just
receive the cumulative maintenance and apply what hasn't been
applied previously?


Because of the restriction that multiple ZAP fixes cannot be applied 
to the same load module via a single APPLY command.







I guess for a small product your method works, but I don't see where 
it is any easier.  I would hate to do all that extra restore / 
reject work for nothing.


It's not really "all that" much work, Mark. The canned JCL automates 
it and is very reliable.







Even prior to RECEIVE ZONEGROUP(ALLZONES) (which has been available 
since OS/390 2.5) you could have supplied one additional REJECT 
PURGE(dlibzone) ("mass mode reject") after your receive job to get 
rid of any extra sysmods received that had already been accepted. If 
they had not been accepted, they wouldn't get re-received anyway.


There have been many advances in SMP/E since around 1990 or so when I 
first started using SMP/E packaging. But I have not bothered to keep 
up. Why not? Well ...

  - I am not an SMP expert.
  - I don't live, breath, or even like the stuff.
  - What I did come up with works well and is well accepted
by my customers.
So I have no incentive whatsoever to "upgrade".

In any case, what you've mentioned here is not the issue. The real 
issue is the one-zap-per-APPLY restriction.








Regards,
Mark


Ditto,
Dave

--
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: Non-SMP/e packaging

[Arthur T.]

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 the wintel platform.


 We'll still be needed to design backup, security, and 
customization.


 If a drag-and-drop installation works, how can you 
consider it a loss?  Do you think things should be kept 
more complicated than necessary just so more of us can have jobs?


 Actually, we're almost there.  Isn't IBM still 
offering (for a fee) the service of "restore these tapes 
and IPL"?



--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" 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: Non-SMP/e packaging

[Paul Gilmartin]

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 cumulative, not incremental.
>- That means that the latest maintenance file always
>  contains all maintenance, not just the most recent.
>- That means that the file as a whole has to be APPLY'd to
>  the instance of the product that existed immediately
>  after initial install.
>- That means that all prior maintenance has to be removed
>  before the new maintenance file can be successfully
>  APPLY'd.
>- And that's what RESTORE and REJECT do.
>- And that's why our canned maintenance JCL contains
>  RESTORE, REJECT, RECEIVE and APPLY, in that order.
>  In other words, the process is fully automated by a
>  single job.
> 
Wouldn't SUPersede with element replacements accomplish the same
thing?  (I know SUPersede is no good for ZAPs and IEBUPDTEs --
BTDTGTS.  DLI.  NGDIA.)

-- 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: Non-SMP/e packaging

[McKown, John]

> -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're almost there.  Isn't IBM still 
> offering (for a fee) the service of "restore these tapes 
> and IPL"?

z/VM can be ordered on a DVD and installed from the DVD itself. I don't
know exactly how this works. z/VM installation is very simple compared
to z/OS installation. But then, z/VM really is a much simplier system in
many ways.

z/Linux, at least SUSE Linux SLES 10-RC3, comes on a DVD. You can IPL
the DVD using the HMC. You then must have the DVD available via http,
ftp, nfs, or smb. Nothing more too it. But again, in many ways, z/Linux
is also much simplier than z/OS.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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: Non-SMP/e packaging

[Jerry Whitteridge]

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

If I can apply a single PTF  to fix a single problem then I can get this
tested and rolled out through the sysplexes much faster and easier than
a full replacement. In these days of smaller staffing coming up with
people to do a full functional test of a product isn't always easy.

my 0.02 cents.
On Wed, 2006-09-13 at 16:15 -0400, David Cole wrote:
> Thanks for your comments, Mark. You raise some good points, requiring 
> me to review choices originally made 15+ years ago.
> 

> That was what got me started with the cumulative idea. But once 
> there, a whole lot of other benefits (amply described in my prior 
> posts) began cropping up.
> 
> So the methodology works well.
> It is fast.
> It is simple.
> It is reliable.
> It is easy for me to maintain and support.
> It insures a high level of consistency across my customer base.
> I'm happy with it.
> My customers are happy with it.
> 
> So exactly, what is it I'm supposed to be caring about here?
> 
-- 
Jerry Whitteridge
Safeway Inc.
(925) 951 4184


"WorldSecure Server " made the following
 annotations on 09/13/2006 02:36:24 PM
--
Warning: 
All e-mail sent to this address will be received by the Safeway corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain information proprietary to Safeway and is 
intended only for the use of the intended recipient(s).  If the reader of this 
message is not the intended recipient(s), you are notified that you have 
received this message in error and that any review, dissemination, distribution 
or copying of this message is strictly prohibited.  If you have received this 
message in error, please notify the sender immediately. 
  
==

--
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: Non-SMP/e packaging

[Imbriale, Donald (Exchange)]

Those all sound like good reasons to keep doing what you're doing.  Only
if/when customers want something else (which is what spawned this whole
thread to begin with), should you consider changing.  Your method may
not be "SMP/E Classic", but if it works and doesn't cause problems 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.
It is simple.
It is reliable.
It is easy for me to maintain and support.
It insures a high level of consistency across my customer base.
I'm happy with it.
My customers are happy with it.

So exactly, what is it I'm supposed to be caring about here?




***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

--
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: Non-SMP/e packaging

[Mark Zelden]

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 module, I have to gather my zaps together into a
>single ++APAR.
>


Now I see your problem. I didn't remember that.  I've run into this 
with other vendors and have to end up doing multiply apply runs.
(IIRC, apply check doesn't complain about this either!)

>My customers are happy with it.

I've installed / maintained your product at several past clients.
I didn't have any issues with your method. I can read and 
follow instructions.  :-)

>
>So exactly, what is it I'm supposed to be caring about here?

Perhaps only that you really aren't taking advantage of everything
SMP/E can do for you (and you customers). 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 products.

>>I guess for a small product your method works, but I don't see where
>>it is any easier.  I would hate to do all that extra restore /
>>reject work for nothing.
>
>It's not really "all that" much work, Mark. The canned JCL automates
>it and is very reliable.
>

I wasn't referring to human work, I was referring to computer work
that SMP/E has to do.  For your very small product it may be fine,
but imagine trying to use your method for a large or very large
product. SMP/E tends to be a bit of a CPU hog (although much improved
in recent years).

Cheers,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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: Non-SMP/e packaging

[Patrick O'Keefe]

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.
>>>
>>> REJECT: This removes the prior maintenance data from
>>> SMP/E's database.
>>>
>>> RECEIVE: This introduces the new maintenance file
>>> into SMP/E's database.
>>>
>>> APPLY: This applies the new maintenance to z/XDC's
>>>...
>>  Please don't encourage this misuse of SMP.
>
>Hi Arthur,
>
>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 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).  If you
are going to use that technique, why bother with SMP at all?  If your 
product does not need the coordination of fixes, you don't need SMP.

To someone trying to learn SMP, this technique is very misleading.
To those already familiar with SMP this could look like a marketting
gimick, just allowing you to say "We use SMP".

Pat O'Keefe 

--
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: Non-SMP/e packaging

[Edward Jaffe]

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).  If you
are going to use that technique, why bother with SMP at all?  If your 
product does not need the coordination of fixes, you don't need SMP.


To someone trying to learn SMP, this technique is very misleading.
To those already familiar with SMP this could look like a marketting
gimick, just allowing you to say "We use SMP".
  


There have been posts in this thread and previously on IBM-Main from 
contributors who asserted that non-SMP/E installs are prohibited in 
their shops. These kind of blanket restrictions lead to SMP/E solutions 
that meet the "letter" rather than the "spirit" of the "law".


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
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: Non-SMP/e packaging

[Ed Gould]

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 come to that
the profession will have lost to the wintel platform.


 We'll still be needed to design backup, security, and  
customization.


*NOT* according to the person that was saying it was the *WAVE* of  
the future. I took issue with it when the person said it and still do.




 If a drag-and-drop installation works, how can you consider it  
a loss?  Do you think things should be kept more complicated than  
necessary just so more of us can have jobs?


The number of customization "jobs" still need to be done after the  
"final" job of a SERVPAC (I am NOT saying service pac's are bad) Its  
a fact of life that additional work is needed and to say it is a  
small effort is IMO untrue and in some cases an outright lie. If a  
drag and drop system were to appear, there would always be needed  
some tweaking (post installation jobs) that will always be needed.  
The person that was espousing the drag and drop was probably  
parroting some high level IBMer (guessing here) but it really  
belittled the profession, IMO.




 Actually, we're almost there.  Isn't IBM still offering (for a  
fee) the service of "restore these tapes and IPL"?



I have not heard of the service you speak of. But IMO each  
installation is different and cannot (generally) be done with a  
simple restore. Actually with the virtual DASD such a restore should  
really not be needed, if planned well (depending on the complexity).


Ed




--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" 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


--
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: Non-SMP/e packaging

[Shane]

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

--
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: Non-SMP/e packaging

[Paul Gilmartin]

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 downloaded TSO TRANSMITted relative files, rather than
ShopZ or its underlying function SMP/E RECEIVE FROMNETWORK.
Does the modal sentiment favor TSO TRANSMIT over RECEIVE FROMNETWORK
Why?  Lack of Internet connectivity from your z/Server?
Complexity?  Unfamiliarity?  Other (specify)?

-- 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: Non-SMP/e packaging

[Tom Marchant]

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.
You just can't use VER.


Tom Marchant

--
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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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

No it doesn't. There may be something in your packaging that forces
it, but it's not the mere fact of being a levelset.

>As I said in my initial post, the advantage of cumulative
>maintenance  over incremental maintenance is that customers, when
>they eventually  get around to applying maintenance (a far less
>frequent event than I  would like),

Could it be less frequent precisely because it is cumulative?
 
-- 
 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 the SE into the argument.

>It causes a PSW RESTART, which 
>loads a PSW from a defined low-store location. 

When it worked :-(

>For many years, that PSW 
>has invoked a system recovery routiine;

That came later; I used it to invoke DSS.
 
-- 
 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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 a D&D process is
less reliable than what we have now then it is a loss, regardless of
whether it nominally "works".
 
-- 
 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: Non-SMP/e packaging

[Robert A. Rosenberg]

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 SYSMOD IDs tells SMPE this fact).


  - That means that the file as a whole has to be APPLY'd to
the instance of the product that existed immediately
after initial install.


WHAT? You should be replacing the current versions of any Element 
that has been updated since the original release (thus replacing any 
copy that was previously updated) so there is NO NEED for it to be at 
FMID Release levels as you imply is required.



  - That means that all prior maintenance has to be removed
before the new maintenance file can be successfully
APPLY'd.


WHY? If you are supplying an "updated since original release" version 
of an element, why does the fact that the element is not at the 
original release level prevent the successful install of the 
cumulatively updated copy?



  - And that's what RESTORE and REJECT do.
  - And that's why our canned maintenance JCL contains
RESTORE, REJECT, RECEIVE and APPLY, in that order.
In other words, the process is fully automated by a
single job.


See Above. There is NO need for the current maintenance status an 
element to matter so long as it is a cumulative update of all changes 
to that element since original release and the update chain is 
documented in the SUPs.


BTW: From your description, you are shipping the equivalent of an IBM 
FMID FUNCTION Refresh. Such refreshes, can be APPLY'ed over ANY prior 
version of that FMID so long as the refresh is at a higher 
maintenance level than the FMID is currently at (if not then you must 
include all the missing Maintenance [ie: That which is already 
Applied] via an explicate naming in the Select or implicitly via 
GROUPEXTEND).


--
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: Non-SMP/e packaging

[Robert A. Rosenberg]

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 module, each one must be packaged separately
and installed by a separate APPLY command."

(from the ++ZAP MCS section of the SMP/E Reference
manual)

This means that if I packaged multiple fixes (to a single load 
module) into multiple ++APARs, then I would not be able to have them 
applied via a single APPLY command. Instead, I would have to require 
the SYSPROG to use a different APPLY command for each ++APAR. That 
would impose an unacceptable burden upon the SYSPROG.


NO IT DOES NOT. Just have the REPs in the ZAP (which would just REP 
the areas that were REPed by a prior APAR with the same data that was 
already there) and let the "SUP(APAR1, APAR2, etc.)" handle the lack 
of VERs issue OR just do the the ZAP on YOUR Maintenance copy and 
ship that APAR as a MOD not a ZAP.


Next Strawman excuse please.

--
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: Non-SMP/e packaging

[Robert A. Rosenberg]

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 REPs in the ZAP



 and IEBUPDTEs



Unless you play renumbering games on the source, you can use a 
cumulative IEBUPDTE stream (just do not do any Deletes but just 
replace lines that would be Deleted with dummy lines). You are thus 
just replacing the prior versions of the updated lines with new 
copies that have the same content along with inserting new lines when 
they did not exist in the SUPed copies.


--
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: Non-SMP/e packaging

[David Cole]

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?
>
> Because our maintenance is cumulative, not incremental.
>- That means that the latest maintenance file always
>  contains all maintenance, not just the most recent.
>- That means that the file as a whole has to be APPLY'd to
>  the instance of the product that existed immediately
>  after initial install.
>- That means that all prior maintenance has to be removed
>  before the new maintenance file can be successfully
>  APPLY'd.
>- And that's what RESTORE and REJECT do.
>- And that's why our canned maintenance JCL contains
>  RESTORE, REJECT, RECEIVE and APPLY, in that order.
>  In other words, the process is fully automated by a
>  single job.
>
Wouldn't SUPersede with element replacements accomplish the same
thing?  (I know SUPersede is no good for ZAPs and IEBUPDTEs --


Right. My maintenance is in the for of ZAPs.




BTDTGTS.


I get this. but ...


  DLI.  NGDIA.)


... Huh?



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[David Cole]

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

With z/XDC, it having a command interface, I've implemented the 
workaround. There's a LIST XDC command that displays the product's 
maintenance level.


Nevertheless, is it possible for me to:
  - Integrate my CSI into the System's CSI,
  - Yet still be able to create my own OPTIONS and UTILITY
definitions,
  - Without affecting any other product,
  - And without being affected by any other product?
  - And still have a simple way to reset when something gets
botched up in SMP? (i.e. as if I did a delete and
rebuild of the CSI?)
If so, then maybe I'll revisit my requirement for a separate CSI.


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Shane Ginnane]

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"
>
> That's a good point.
>
> With z/XDC, it having a command interface, I've implemented the
> workaround. There's a LIST XDC command that displays the product's
> maintenance level.
>
> Nevertheless, is it possible for me to:
>- Integrate my CSI into the System's CSI,
>- Yet still be able to create my own OPTIONS and UTILITY
>  definitions,
>- Without affecting any other product,
>- And without being affected by any other product?
>- And still have a simple way to reset when something gets
>  botched up in SMP? (i.e. as if I did a delete and
>  rebuild of the CSI?)
> If so, then maybe I'll revisit my requirement for a separate CSI.

- yes (doesn't need to be the "System's"; I generally have a THIRDPTY.CSI
for example.
- yes
- probably
- probably
- maybe

For you to have a clash with another product you would have to be unlucky,
or stupid (especially if it's another of your own products).
You may be unsurprised to learn CA qualify for the latter - with 2 of their
own products.

If one starts to get cute with SMP, it'll bite. I have on occasion had to
resort to a full (DF/DSS) restore of the environment, and restart some
aspect of maintenence.
May not meet the definition of "simple" for some people - I find it no
major impost.

It should be noted I (almost) always ignore the demand for a separate CSI -
mangling done at initial install is time well spent in our shop. Separate
CSIs are built in need, as occasionally happens.

Shane ...

--
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: Non-SMP/e packaging

[David Cole]

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


Actually, yes. That was one of the reasons why I switched over to 
SMP/E packaging. (As I said in an earlier post, I don't even like the stuff!)


But beyond that, I find the main advantage is it makes both the 
packaging and the distribution of maintenance drop-dead easy!

  - The maintenance file is small, rarely growing to as much
as one megabyte.
  - So when distributed over the Internet, it's a very small
download.
  - A full product replacement would run to some 20 or 30
megabytes (ok for FTP, I guess, but much too big for
email).

SMP is very good at automating the precise targeting of maintenance 
to the elements that need changing. To achieve the same level of 
manual-work-relief, but without SMP, I would have to require the 
customer to do a full product download and replacement. That strikes 
me as being much harder.


Or for more precise targeting, I would have to come up with and 
maintain a custom job stream that (a) would change frequently over 
the life cycle of a product release and (b) would require local 
customization every time I changed it. That just seems to me to be an 
unnecessary hassle for the both of us.



BTW: Another advantage of cumulative packaging (vs. incremental 
packaging): It keeps the customer from picking/choosing which 
maintenance to apply and which to skip. Every time the SYSPROG 
decides to download/apply new maintenance, his only choice is to 
download the most recent maintenance file.


This contributes to a greater uniformity from one customer to the 
next, and that is a benefit to me (and ultimately, therefore, to the 
customer) when I have to shoot a new problem.


Of course, this also requires that my maintenance be perfect. I won't 
claim that I've succeeded on this point, but I will claim that I have 
come pretty darn close. In any case, if you don't trust the 
maintenance, then how can you trust the underlying product? It seems 
to me that it's all the same leap of faith.




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Ted MacNEIL]

>>   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 INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-SMP/e packaging

[David Cole]

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 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).  If you are going to use that technique, why bother with SMP 
at all?  If your product does not need the coordination of fixes, 
you don't need SMP.


To someone trying to learn SMP, this technique is very misleading. 
To those already familiar with SMP this could look like a marketting 
gimick, just allowing you to say "We use SMP".


Pat O'Keefe


Please see my recent response to MZelden for the advantages I find in 
using SMP/E vs. direct IEBCOPYs.


As to "coordinating maintenance", as I've already stated in this 
thread that z/XDC resolves its dependency issues at execution time, 
not at installation time. So there is no need for z/XDC to coordinate 
maintenance with anyone else, nor is there any need for anyone to 
coordinate maintenance with z/XDC. It is a non-issue.


And there it an additional advantage to execution time resolution of 
dependencies. It contributes to keeping the installed product uniform 
from one customer to the next. And that significantly reduces my 
source level maintenance burden. I don't ever have to (or want to) 
keep 2 or more versions of the same module.




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Paul Gillis]

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"


That's a good point.

With z/XDC, it having a command interface, I've implemented the 
workaround. There's a LIST XDC command that displays the product's 
maintenance level.


Nevertheless, is it possible for me to:
  - Integrate my CSI into the System's CSI,
  - Yet still be able to create my own OPTIONS and UTILITY
definitions,
  - Without affecting any other product,
  - And without being affected by any other product?
  - And still have a simple way to reset when something gets
botched up in SMP? (i.e. as if I did a delete and
rebuild of the CSI?)
If so, then maybe I'll revisit my requirement for a separate CSI.



I don't have a problem with multiple CSIs as long as there a a minimum 
of Global CSIs. At a previous client, we had only "1" Global CSI, with 
one or two CSIs per vendor/product. The Target/DLIB CSI naming 
convention made it relatively easy to locate a specific vendors CSIs. 
Then it is possible to have your own OPTIONS and UTILITY definitions 
without impacting or being impacted by any other product.


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


Paul Gillis

--
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: Non-SMP/e packaging

[David Cole]

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 doesn't. There may be something in your packaging that forces 
it, but it's not the mere fact of being a levelset.


I'm sorry, Shmuel, but your assertion, "No it doesn't" is a bit like 
asserting that two plus two does not equal four. I think I've 
explained quite adequately in my prior posts why my above statement 
is true. I think you're going to have to put a bit more effort into 
justifying your contradiction before I'd be willing to take you seriously here.







As I said in my initial post, the advantage of cumulative 
maintenance  over incremental maintenance is that customers, when 
they eventually  get around to applying maintenance (a far less 
frequent event than I  would like),


Could it be less frequent precisely because it is cumulative?


While you used XDC back in the '80s, to my knowledge you have not 
done so since, and to my knowledge you have never been involved in 
the installation of XDC (at least not since I started packaging it 
with SMP). So I don't think you're speaking here from personal 
experience. Because if you were, then I don't think you'd be making 
such a foolish statement as this.



BTW: What is it you're trying to say when you say, "It's not my dog"? 
Does that mean you don't have enough experience with an issue to have 
an opinion? I'm not sure. Please clarify.




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
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: Non-SMP/e packaging

[David Cole]

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


But then the VERs wouldn't fit. I like VERs. Should I like them? 
Others have pointed out that I could do without the VERs. I don't 
know, I'll have to think about that.


Dave

--
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: Non-SMP/e packaging

[Binyamin Dissen]

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 removed
:>>>  before the new maintenance file can be successfully
:>>>  APPLY'd.

:>>No it doesn't. There may be something in your packaging that forces 
:>>it, but it's not the mere fact of being a levelset.

:>I'm sorry, Shmuel, but your assertion, "No it doesn't" is a bit like 
:>asserting that two plus two does not equal four. I think I've 
:>explained quite adequately in my prior posts why my above statement 
:>is true. I think you're going to have to put a bit more effort into 
:>justifying your contradiction before I'd be willing to take you seriously 
here.

Assuming that you do it as a FUNCTION, you REWORK it and then "simply" update
the SUP list and specify RMIDs/UNIDs on any changed element.

You then should be able to REJECT, RECEIVE and APPLY REDO.

I do not understand why you need to do a RESTORE as part of the process.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Non-SMP/e packaging

[David Cole]

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 that all prior maintenance has to be removed
:>>>  before the new maintenance file can be successfully
:>>>  APPLY'd.

:>>No it doesn't. There may be something in your packaging that forces
:>>it, but it's not the mere fact of being a levelset.

:>I'm sorry, Shmuel, but your assertion, "No it doesn't" is a bit like
:>asserting that two plus two does not equal four. I think I've
:>explained quite adequately in my prior posts why my above statement
:>is true. I think you're going to have to put a bit more effort into
:>justifying your contradiction before I'd be willing to take you 
seriously here.


Assuming that you do it as a FUNCTION, you REWORK it and then "simply" update
the SUP list and specify RMIDs/UNIDs on any changed element.

You then should be able to REJECT, RECEIVE and APPLY REDO.

I do not understand why you need to do a RESTORE as part of the process.


To get the VERs to work. (Although it's been pointed out to me that 
it is not necessary to have VERs. I'll have to think about that.)





Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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: Non-SMP/e packaging

[Shmuel Metz (Seymour J.)]

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 routine service then there's a serious risk of
losing fixes the next time you reassemble.
 
-- 
 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