opinion: Should We Package All Exits Using SMP/E?

Few sites will be without at least a couple of site-written exits: code that gets control at set points within normal z/OS or associated subsystem processing. When I first started as a systems programmer, our exits were packaged as SMP/E usermods. Today, this seems like a lost art, as many sites store the exit code in a PDS or their source code management system like CA Endevor.

So, is this a good idea, or are these sites flirting with disaster?

Usermod Review

Before we go further, let's quickly review SMP/E usermods using an example: IEFACTRT. This is a z/OS exit that gets control at the end of a step or job. Sites often use this to output information about the step or job that has just completed.

Sites create their own assembler IEFACTRT module to be called to do the processing needed. As this exit is normally in SYS1.LPALIB, it is packaged as an SMP/E usermod. SMF parameters are changed so this exit gets control at the end of every step or job.

SMP/E usermods are rarely accepted. So is the site wants to back out the change, they simply do a SMP/E Reject, and the original version of the exit supplied by the vendor (if any) is restored.

Why Do It

I've been at several sites where the source, or at least the current source, for an exit has been lost. Installing exits as SMP/E usermods (with the source) protects against this. Providing the usermod has been packaged with the source, that source is always available in SMP/E. What's more, we don't have to worry about creating the assemble/compile or bind job: SMP/E handles this all (though we may need to create some JCLIN for SMP/E if there's something special in the bind job we need). SMP/E can handle the normal COPYLIBS, includes or MACLIBs we may need for the compile or assembler.

More importantly, if z/OS maintenance or a new version updates the exit or something it needs, we'll know about it. When we try to SMP/E APPLY the maintenance, the APPLY will fail because our usermod is there. SMP/E tells us we need to do something. We will need to REJECT our usermod, APPLY the maintenance, and then re-APPLY our USERMOD.

When we do this re-APPLY, our usermod (which includes the source) will be recompiled and bound. A modification to MACLIBS or includes will be picked up with our re-APPLY.

Bottom line: our exit is well-controlled using SMP/E.

But Is SMP/E Really Necessary?

In our example, we've put a module into a library holding other z/OS modules that are SMP/E controlled. If we're going to do that, we really need SMP/E: we absolutely do not want a library with a mix of SMP/E and non-SMP/E controlled modules. This is especially true if our exit modifies an existing vendor-provided module.

But let's look at an MQ channel exit. This isn't a module supplied with IBM MQ. We create our own channel exit program, call it whatever we like, and then specify this name in an IBM MQ channel definition. We could simply create this exit, store the source in SCM software like CA Endevor, and away we go. So SMP/E isn't really necessary, but it is nice.

I've often seen sites that don't re-compile (or re-assemble) or re-bind their exits with new software releases. So, they may be running with z/OS 2.3, but have an IEFACTRT exit that was last assembled with z/OS 1.8. Now this IEFACTRT may still run fine, but in my opinion it's a risk. Often exits aren't fully tested with software upgrades. So, they may run OK normally, but exceptional circumstances could create problems.

But if we use SMP/E, we'll have to re-APPLY our usermods with a new software release: using the latest includes, macros and included modules. A little safer.

So far in this article I've assumed that a usermod includes the source for an exit. This doesn't have to happen: it's possible to create a usermod, but not include the source. So when the usermod is applied, it gets the source from a PDS. Yes, this can be done, but I really don't like it. I have seen usermods that cannot be re-applied because, well, the source has been lost. It's no extra effort to include the source in a usermod.

Any Downside?

Usermods aren't always the solution to managing exits.

Usermods need an 'owning' FMID: the product that they affect. If you have a product that isn't SMP/E installed, then using a usermod may not be as valuable.

Creating usermods can take a bit of practice for the novice, so many avoid the effort. After the first one or two, this isn't such a big deal.

SMP/E environments are usually managed by the group installing the product. If a different group is responsible for the exit, then this may cause some organisational problems.

Conclusion

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.