As a pure customer, I also prefer SMPE install/maint for exactly the reason 
Charles's customer gave. No matter how cleverly designed, every non-SMPE 
process is a one-off dogie that has to be mastered on its own with little or no 
transfer to other products. SMPE, for better or worse, is a standard process 
that can be handed off from one person to another with minimal learning curve. 
In reality, that 'other person' is often your future self. ;-)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Charles Mills
Sent: Friday, September 11, 2015 8:27 AM
To: [email protected]
Subject: Re: SMP/E Help

> I assume one of the reasons you are venturing down this road is not so 
> much because you (or your customers) think the initial install of your 
> software in SMP/E format is very exciting, but rather because of the prospect 
> of follow-on service in PTF format.

I can't speak for the OP but I can speak to our own recent expedition into the 
wonderful world of building for SMP/E. No, the motivation had nothing to do 
with PTFs. We have a pretty simple product and for us, so far at least, for 
better or worse every fix consists of either (1) a change to configuration 
files in character form, so the change can be e-mailed as a simple text file or 
snippet with some edit instructions; or (2) an entire new build just like a new 
installation but with a JCL process that does not clobber existing customer 
parms. 

No, the motivation was customer requests. I said to a customer sysprog "I 
thought our IEBCOPY install was pretty good." He said "it's great, and SMP/E is 
a pain in the [butt], but it's a consistent pain in the [butt]. Every vendor's 
IEBCOPY install is unique."

Customers -- especially the largest customers -- don't IMHO by-and-large love 
SMP/E, but they know it and live and breathe it, and they want vendor products 
delivered that way.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Kurt Quackenbush
Sent: Friday, September 11, 2015 8:09 AM
To: [email protected]
Subject: Re: SMP/E Help

> I need some help with SMP/E. I need to convert our software to use 
> SMP/E. I am not a SMP/E heavy. I have the following;
>
> 1. Linklib
> 2. Proclib
> 3. Parmlib
> 4. JCLLIB ( for install ) , this can be removed , because SMP/E will 
> do it 5. Rexx Clistlib

Further thoughts on the process of packaging your software in SYSMOD
format:  I assume one of the reasons you are venturing down this road is not so 
much because you (or your customers) think the initial install of your software 
in SMP/E format is very exciting, but rather because of the prospect of 
follow-on service in PTF format.  Therefore, you must consider how you intend 
to supply parts/files later in PTFs before you create your initial FUNCTION 
SYSMOD.

In my opinion, most parts/files ("elements" in SMP/E terminology) are very 
simple to package and install.  Using your example, procs, parmlib members, 
sample JCL, execs, are all very simple to manage, package, and install, because 
they are just members of a partitioned data set that are copied and replaced by 
SMP/E.  It is modules and load modules that cause the most grief.

Traditional z/OS software is SMP/E packaged using MOD elements to describe 
modules that get link edited during the APPLY to create load modules (load 
modules or program objects).  It is link edit steps in JCLIN that tells SMP/E 
how to put the MODs together to create these load modules.  This is all a very 
well grooved path, but, JCLIN and MODs can be a great pain, and I'd say the 
cause of most grief for packagers and installers.

You can greatly simplify you and your customers' efforts if you can avoid MODs 
and JCLIN altogether.  That is, it is far simpler to package complete load 
modules using PROGRAM elements rather than as individual MODs with JCLIN.  
PROGRAM elements treat load modules as simple members of a partitioned data set 
that can be copied and replaced.  No JCLIN is necessary and no link edit 
processing is performed by SMP/E.

To determine if you can successfully use PROGRAM elements you have to consider 
the contents of your load modules and how they are built.  Do your load modules 
include any parts not supplied by you?  For example, callable services from 
CSSLIB or SCEELKED?  Modules from subsystems or other products, like SDSNLOAD 
or ISPLLIB?  Side decks (IMPORT
statements) to resolve DLL references?  If so, then you may want to, or need 
to, package individual modules as MODs and supply JCLIN to define your load 
modules.  Shucks.  However, if your load modules are rather simple and include 
only modules that you own, then you should consider using PROGRAM elements in 
your SYSMOD packaging for your initial FUNCTION and subsequent PTFs.

Kurt Quackenbush -- IBM, SMP/E Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to