Charles,
about 15 years ago we had a european product foisted up on us from a
user. This was not SMP installable.
The boss told me to try and install it.
It was a so so installation some minor gotchas but it went reasonably
smoothly..
I ran into a problem with it in execution (detail are blurred by
now). I contacted the author and was told to hand link edit one of
their modules outside of SMPE . I said that is iffy for this but what
about the rest of the product if we run into any issues? The answer
was yes we have had issues with that and that is the way the product
works.
I got off the phone and told my boss and he told me to drop it as the
product must be completely SMPe maintainable.
He told me to write him a memo and explain the issues and he
forwarded it up to his boss and the answer came back to delete the
product.
Ed
ps: I am replying to you directly as my reply to IBM-Main have been
bouncing and since no one is owning IBM main anymore I don't know who
to complain to.
On Sep 11, 2015, at 10:26 AM, Charles Mills wrote:
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:IBM-
[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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
