Many objects within i5/OS can be varied on and varied off. These objects include devices, controllers, lines, network servers, etc. In many cases, it may be desirable to perform some set of user-defined actions at vary on or vary off time. For example, consider a topology in which you have two systems that share a switchable IASP between them. Assume that when the IASP is attached to a system, a given subsystem should also be active (i.e., if and only if the IASP is attached). That means that when the IASP is switched, the subsystem on the "old" side must be ended and then started on the "new" side. But how can you realize this requirement without manual intervention? The answer is that you should create your own exit program using the QIBM_QDC_VRYEXIT exit point!
Which Exit Point Format Should I Use?
Each exit point is accompanied by an exit point format name. Depending on the exit point format name specified, the system will supply your exit program with different arguments and expect different return values. The QIBM_QDC_VRYEXIT exit point supports four exit point format names:
- PRON0100—The exit programs are called prior to the object being varied on.
- PSON0200—The exit programs are called after the object vary on has started.
- PROF0100—The exit programs are called prior to the object being varied off.
- PSOF0200—The exit programs are called after the object vary off has started.
Notice that you can choose to have your custom logic occur either before or after the vary operations occur. It's also worth mentioning that if the logic occurs prior to the vary operation, you have the option to specify a return code dictating whether or not the vary operation should continue or halt (i.e., assuming a forced vary wasn't issued). Once you've selected the exit point format(s) in which you're interested, it's time to create your program(s).
Example Time
All right, you've learned about exit points, exit point formats, and which exit point formats the QIBM_QDC_VRYEXIT exit point supports; now it's time to look at an example from beginning to end. The following example demonstrates how to create an exit program that will be called after an ASP device description is varied on.
(Note that the PSON0200 exit point format name is assumed for this example.)
Step 1: Given the PSON0200 exit point format name, use the i5/OS Information Center to determine the arguments your program's expected to support. You will find that it must support four arguments: ObjectName [CHAR(10)], ObjectType [CHAR(10)], FormatName [CHAR(8)] and Status [BINARY(4)].
Step 2: Create your exit program within ILE. The following skeleton code is written in ILE C:
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
// The following C struct mimics the data passed by the
// QIBM_QDC_VRYEXIT exit program using the PSON0200 exit point
// format name
typedef struct {
// name of object being processed
char object_name[10];
// type of object being processed
char object_type[10];
// user exit format name being used
char format_name[8];
int status; // vrycfg status;
// 0 = successful,
// 1 = not successful,
// 2 = rejected by pre-proc exit pgm,
// 3 = status of vary request unknown
} PSO200_fmt_t;
/**
* Main program entry point.
*/
int main(int argc, char *argv[]) {
PSO200_fmt_t input;
// Populate the PSO200_fmt_t structure with program arguments
memcpy(&input, (PSO200_fmt_t *) argv[1], sizeof(PSO200_fmt_t));
// At this point, the input structure contains all of the information
// supplied to us by the operating system. We can now proceed to
// perform our user-defined logic here (e.g., start the
// appropriate subsystem).
return 0;
}
Step 3: Compile your ILE program object (e.g., given the program in Step 2, you should use the CRTBNDC CL command).
Step 4: Register your exit program with the system. You can use the following CL command:
FORMAT(PSON0200)
PGMNBR(*LOW)
PGM(MYLIB/MYPGM)
THDSAFE(*SYSVAL)
PGMDTA(*JOB *CALC DEVDASPD)
TEXT('EXAMPLE EXIT PROGRAM')
You could alternatively use the WRKREGINF CL command and work your way through the various prompts to achieve the same result (but don't forget to populate the PGMDTA argument). You can also use WRKREGINF to deregister exit programs whose use is no longer wanted.
Step 5: Using the VRYCFG CL command, test your exit program by varying off and then varying on an ASP device description. Your exit program will be called post-vary-on time.
My Point of Exit!
By now, you should see just how easy it is to get started creating your very own exit programs, specifically those involving device vary configurations. Again, the QIBM_QDC_VRYEXIT exit point was added in V5R3, so its potential usability should be very widespread by now. If you don't have an immediate need for this today, it's definitely something handy to keep within your programming tool belt.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online