It's been about 25 years since IBM started offering i5/OS. Sure, it was first called CPF and then OS/400, but "What the heck release are we on?" has been a question people have asked themselves ever since CPF V2R1M0 came out back in something like 1980.

System values have been around since the first date of the operating system. Yet it took roughly 10 years before IBM put the model number into the system values table. I don't believe the serial number was there from the beginning either, but I think it was added long before the QMODEL system value.

So we have serial number and model number easily accessible via DSPSYSVAL QSRLNBR and QMODEL. (For the sake of consistency, shouldn't it have been QSERIAL and QMODEL or QSRLNBR and QMODNBR? But I digress). So why don't we have the OS release level, and why don't we have the processor group?

I was recently installing Advanced System Concepts' Abstract software for a client. (ASC's Abstract and ProData's DBU are two tools, along with RPG xTools, that I normally request that my clients install if they don't have them, but many already do.) The vendor asked me for the serial number and processor group. I gave them the serial number quickly (DSPSYSVAL QSRLNBR) and then said that I didn't have a clue what the processor group was. So the vendor asked me to look at a feature code in the list of installed processor features. The vendor then translated that feature code to the processor group. That just doesn't seem simple to me.

When IBM went to processor group-based licensing fees, so did the rest of the software vendors for iSeries. This effectively replaced the model number licensing with the processor group-based licensing, which is virtually worldwide at this point. Today, it seems like model numbers are virtually pointless. I recently installed a Model 800 in a shop where an 820 previously lived. That 800 ran faster than the 820, but it was a P10 processor group, versus the P20 of the 820.

There have been so many model number changes over the years that IBM and third-party vendors alike have had a difficult time maintaining their pricing tables. Enter processor groups.

Today, processor groups come in P05, P10, P20, P30, and P40. There may also be a P50 processor group by the time this article hits the streets, but I haven't actually been in a shop that has one.

Recently, when attempting to add processor-based processing to a software product, I read up on the software license APIs. These APIs are a nightmare to work with, and I've encountered only a few vendors that actually use them. IBM provided these APIs to simplify third-party software installation and processor group or usage-based licensing.

About the only API documentation I've read that is worse than IBM's documentation of QzhbCgiParse (a CGI API) is that of the software licensing APIs. It's no wonder vendors are shying away from them.

So not only is it nearly impossible to see your processor group from command entry, it is equally as difficult to write a third-party software solution that leverages IBM's software licensing scheme.

While I can't solve IBM's shortcomings with its software licensing APIs, I can help to resolve the frustration of not knowing what processor group you have. In addition, why not just list all the licensing variables in one easy-to-read location?

I've also used the WRKLICINF CL command. While it does list the serial number and processor group in one place, it does not list the model number nor is it able to cut/paste that info into an email.

Shown below is a CL program named Display License Information (DSPLICINF). This program, along with its corresponding and optional command definition, allows you to display the following information:

• CPU serial number
• System model number
• Processor group
• OS version and release level

Since this information is available through a few different interfaces, I chose to use a high-level interface for all four pieces of information. Certainly, using MI would be faster, but this CL program runs fast enough for anyone's taste. In fact, on a little Model 170 with something like 15 CPW, it displays the information immediately.

Here's the source code:

DSPLICINF: PGM
/*************************************************************/
/** Display software license information **/
/** (c) Copyright 2005 - Robert Cozzi, Jr. **/
/** Unrestricted license to use this software granted to **/
/** the public. **/
/** No warranty is express or implied, and none is given. **/
/*************************************************************/

DCL VAR(&LICPGM) TYPE(*CHAR) LEN(16)

DCL VAR(&RTNDATA) TYPE(*CHAR) LEN(64)
DCL VAR(&RCVLEN) TYPE(*DEC) LEN(7) VALUE(64)
DCL VAR(&RTNLEN) TYPE(*CHAR) LEN(4)
DCL VAR(&MODEL) TYPE(*CHAR) LEN(4)
DCL VAR(&SERIAL) TYPE(*CHAR) LEN(8)
DCL VAR(&RELLVL) TYPE(*CHAR) LEN(6)
DCL VAR(&CPFVER) TYPE(*CHAR) LEN(9)
DCL VAR(&PRODINFO) TYPE(*CHAR) LEN(17) +
VALUE('5769SS1*ONLY 5050')

DCL VAR(&LICINFO) TYPE(*CHAR) LEN(8) +
VALUE('LICP0100')

DCL VAR(&APIFMT) TYPE(*CHAR) LEN(8) +
VALUE('LICR0200')

DCL VAR(&APIERRORDS) TYPE(*CHAR) LEN(16) +
VALUE(X'0000000000000000')
DCL VAR(&PROCGRP) TYPE(*CHAR) LEN(4)
MONMSG MSGID(CPF0000)

/* Convert the return buffer length to INT4 */
NOTE1: CHGVAR VAR(%BIN(&RTNLEN)) VALUE(&RCVLEN)

RTVOBJD OBJ(QCMD) OBJTYPE(*PGM) SYSLVL(&CPFVER) +
LICPGM(&LICPGM)

CHGVAR VAR(%SST(&PRODINFO 1 7)) VALUE(%SST(&LICPGM +
1 7))
CHGVAR &RELLVL value(%SST(&CPFVER 1 1) *TCAT +
%sst(&CPFVER 3 1) *TCAT +
%SST(&CPFVER 4 1) *TCAT +
%SST(&CPFVER 6 1) *TCAT +
%SST(&CPFVER 7 1) *TCAT +
%SST(&CPFVER 9 1))
CHGVAR VAR(%SST(&PRODINFO 8 6)) VALUE(&RELLVL)
/* Retrieve the processor group and OS VxRxMx level */
NOTE2: CALL PGM(QLZARTV) PARM(&RTNDATA &RTNLEN &APIFMT +
&PRODINFO &LICINFO &APIERRORDS)

/* Extract the Processor Group */
NOTE3: CHGVAR VAR(&PROCGRP) VALUE(%SST(&RTNDATA 48 03))

/* Extract the OS/400 Version/Release/Modification Level */
NOTE4: CHGVAR VAR(&RELLVL) VALUE(%SST(&RTNDATA 27 06))

/* Get the Serial Number and Model Number */
NOTE5: RTVSYSVAL SYSVAL(QSRLNBR) RTNVAR(&SERIAL)
RTVSYSVAL SYSVAL(QMODEL ) RTNVAR(&MODEL)

/* Tell the end-user what was found. */
NOTE6: SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) +
MSGDTA(' Serial . . . . : ' *TCAT &SERIAL)
SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) +
MSGDTA(' Model . . . . : ' *TCAT &MODEL)
SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) +
MSGDTA(' Proc Group . . : ' *BCAT &PROCGRP)
SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) +
MSGDTA(' Ver Rel Mod . : ' *BCAT &RELLVL)

ENDPGM: ENDPGM

In the above example, the line identified with NOTE1 converts the return variable's length, which is hard-coded as the initial value of the &RCVLEN variable, to integer. Until V5R3, CL hasn't supported integer variables, so we store the length in a decimal variable and then convert it using the %BIN() built-in function.

The line tagged with NOTE2 calls the software licensing API QLZARTV (Retrieve Software License Information). This API returns runtime information about an installed software product.

Buried in the data returned by this API are the processor group and OS release levels. The line tagged with NOTE3 pulls out the processor group from the data returned by QLZARTV. The line tagged with NOTE4 retrieves the OS release level in VxRyMx format. These values are stored in the &PROCGRP and &RELLVL CL variables, respectively.

To be complete, I also want to display the CPU serial number and model number to the user. The lines tagged with NOTE5 accomplish this through the use of the traditional RTVSYSVAL command.

Finally, the lines tagged with NOTE6 send the information (somewhat formatted) to the end-user as completion messages. I tried to use informational messages; instead, however, they appear on Command Entry only when you have low-level messages turned on (via F10).

The command to call this CL program isn't really necessary. But I do like being able to type in commands, so here is the command definition source for DSLICSINF.

If you run the DSPLICINF command or simply call the CL program from command entry, you will receive the results as four informational messages, as shown below:

In this example, the DSPLICINF command is run and the serial number, model number, processor group, and version are displayed on four separate lines. Because the data doesn't always fill up the return variables, some data is left-justified and some is not. Hence, I use both *TCAT and *BCAT to create the output data.

Now, when a software vendor asks you what your processor group is, you can say, "Hold on while I run DSPLICINF and find out."

Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.