LongEx Mainframe Quarterly - November 2018
If you're currently upgrading your system to z/OS 2.3 system, you'll be working through all of the migration steps that are published by IBM.
With z/OS, if you submit a job, then your output will include something like this:
07.39.02 JOB38089 IEF404I JOB001 = ENDED = TIME=07.39.02 07.39.02 JOB38089 $HASP395 JOB001 ENDED = RC=0000
I know what you're thinking: "our output doesn't look like this." In fact, almost no z/OS site will see this. And that makes sense. This doesn't tell us much does it? Did all the steps execute or not? Any non-zero return codes? How much CPU did they consume? This doesn't help us.
The chances are that you'll see something a bit more like this:
07.39.02 JOB38089 ---TIMINGS (SEC)--- 07.39.02 JOB3808 -STEPNAME PROCSTEP PROGRAM RC EXCP TCB SRB CLOCK 07.39.02 JOB3808 -STEP001 IEFBR14 00 45 .00 .00 .06 07.39.02 JOB3808 -STEP002 SAS SAS 00 155K 69.07 .00 242.46 07.39.02 JOB3808 IEF404I JOB001 = ENDED = TIME=07.39.02 07.39.02 JOB3808 -JOB001 ENDED. TOTAL CPU=69.07. TOTAL ELAP TIME= 242.52 07.39.02 JOB3808 $HASP395 JOB001 ENDED = RC=0000
How is this done? By an exit called IEFACTRT.
IEFACTRT is an SMF exit: it runs at set points during SMF processing. SMF is our z/OS recording feature: writing records when notable events happen. One of these notable events is the end of a job. IBM provide us with an 'exit point:' a point in normal SMF processing where we can execute our own code. IBM gives every exit point a name: IEFACTRT in our case.
So, when a job ends, SMF will write a record: a type 30 subtype 5 to be precise. This record has all sorts of information about the job: return codes, CPU used, I/Os performed, memory used, and more. They're great for systems programmers wanting to find out what has happened in the past. Most sites would like to see this information in the job log. So, rather than go through our SMF type 30 records, we can see this information right now. This is where we use the IEFACTRT exit.
We write a module (usually called IEFACTRT, but we can use another name) that does what we want: output some information to the joblog when the job ends. We then 'install' this exit. Now, every time a job ends, this code will be run, and will output what we want.
Every exit will be documented by the vendor. This includes information about when the exit is run, how it is activated, why we may want to use it, and more. In particular, this documentation will tell us about the rules that must be followed by the exit, and what information is provided to the exit.
Let's look at IEFACTRT. According to the IBM documentation, it is executed when the following SMF records are created:
What Exits Can Do
There are a lot of potential exit points that can be used. The IBM MVS Installation Exits manual for z/OS has 55 exits, not including DFSMS, JES, RMF, VTAM and TSO. Exits are not limited to z/OS; many other program products (IBM and ISV) provide exits points. For example, RACF has 19 exit points, CA-ACF2 32, Connect:Direct 8.
Let's look at some examples of exits.
Exits are normally programmed in assembler, but this is not always the case. For example, IBM MQ channel exits can be coded in C or assembler. IBM Metal C can also be used in place of assembler for most exits.
Exits are powerful. They get control in the middle of z/OS and other subsystem processing, and can change how that processing occurs. For example, the RACF password exit ICHDEX01 can determine how RACF passwords are encrypted in the RACF database. Exits often gain control in supervisor state, so they have 'superuser' authority: securing each exit is critical. Checking who has access to create or modify exits is one of the first things any security auditor will check.
Equally important is that anyone writing or modifying an exit must have sufficient skills to stop the exit from destroying anything. An error in an exit can quickly crash your z/OS system. Exits must not only perform processing required, but have robust error handling and recovery logic.
Because of the security and reliability issues, many sites minimize the use of exits. We talk more about the best practices in creating, using and maintaining exits in our partner article.
Whenever we buy software, there's often things we want it to do that it doesn't. Or things that it does do, but we want done differently. Exits give us the ability to fix this, and tailor the software to our needs.
But this power comes at a price. Exits must be secured, and should only be created or modified with those that have the right skills and experience. An error in an exit can have catastrophic consequences.