Retrieve the exact table of MI object types via the undocumented API QLICNV.
On IBM i, historically there are two flavors when referring to objects. At the MI level, MI objects are categorized by a 2-byte MI object type code (1-byte type code and 1-byte subtype code). At the OS level, external objects (also known as CL objects) are categorized by external symbolic type names—for example, *FILE. An external object may consist of one or more MI objects. Each MI object type also has a corresponding descriptive external object type name; for example, the external object type name of a cursor object (with MI object type hex 0D50) is *MEM (Member). As you might know, the number of MI object types changes from release to release. This makes sense for an object-based system that has been evolving continuously.
Strictly speaking, only the object types that are visible at the OS level are external object types. For example, cursor object (*MEM) isn't a valid external object type. Here, the term "external object type" refers to the descriptive name of an MI object type.
As you might know, there are a couple of ways to find out which MI object types are supported by a specific IBM i VRM (version, release, and modification level):
- The Internal object types document provides a map from MI object types to external object types.
- The Convert Type (QLICVTTP) API allows you to convert an external object type to corresponding MI object type and vice versa.
Unfortunately, the above methods either cannot be used programmatically or don't completely fulfill our requirement. For example, the QLICVTTP API refuses to convert an MI object type whose subtype code is greater than or equal to hex 50 (or, in other words, object types that are not strictly said external object types)—for example, cursor object (hex 0D50) whose external type is *MEM.
So is it possible to retrieve the exact table of MI object types supported by the current IBM i VRM? Yes, and the answer lies in a program object, QSYS/QLICNV.
- Subject: Object types in the QSYS file system (and in save files)
- From: Dave McKenzie <davemck@xxxxxxxxxx>
- Date: Thu, 15 Feb 2001 15:13:46 -0800
There's a table of object types in the pgm QSYS/QLICNV which you can see by
dumping it with SST. It includes internal types (e.g. x0C90, data space index,
AKA access path) as well as external types (e.g. x1901, file). On my V4R4
machine it has 287 types....
The "table of object types in the pgm QSYS/QLICNV" mentioned by Dave resides in the associated space of the QLICNV program. The format of QLICNV's associated space is the following:
1. CHAR(32). Unknown
2. BIN(4). Number of MI object type entries available
3. CHAR(28). Unknown
4. CHAR(11) Array of MI object type entries
4.1. CHAR(7) External object type name
4.2. CHAR(4) MI object type code and subtype code
Additionally, since the QLICNV program is in the user domain and therefore can be accessed from user state programs, once the system pointer to QLICNV is available, a user program can access the table of MI object types stored in QLICNV's associated space via the Set Space Pointer from Pointer (SETSPPFP) MI instruction. Note that the initial public authority of QLICNV is set to *EXCLUDE and therefore cannot be accessed by a user with neither proper private authority to QLICNV nor the *ALLOBJ special authority. Thus, you should not resolve the system pointer to QLICNV using the Resolve System Pointer (RSLVSP) MI instruction. Instead, you should use the resolved system pointer to QLICNV (with authorities set in it) stored in the System Entry Point Table (SEPT), which I discussed in my article "Are You Taking Full Advantage of the System Entry Point Table Object?". The offset of QLICNV's system pointer in the SEPT is hex 0490; therefore, when referring to it as an array element of the system pointer array stored in SEPT, the array subscript is hex 4A.
Applicable Example Programs of Listing MI Object Types via QLICNV
The steps for retrieving the table of MI object types stored in QLICNV's associated space are quite straightforward:
- Get QLICNV's system pointer stored in the SEPT. (System built-in _SYSEPT is very handy for retrieving the space pointer addressing SEPT's associate space.)
- Obtain a space pointer addressing QLICNV's associated space via the SETSPPFP instruction.
- Work with the 11-byte MI object type entries via the returned space pointer.
Example ILE RPG program t175.rpgle below, which is provided by the open-source project i5toolkit, achieves the above-mentioned steps:
* @file t175.rpgle
* Output of T175 might like the following:
* 0E09 ALRTBL
* 1B01 AUTL
* 1E05 BLKSF
* 1937 BNDDIR
fQSYSPRT o f 132 disk
d sept_spp s *
d sept s * dim(7000)
d qlicnv *
d qlicnv_ptr * procptr overlay(qlicnv)
d map_entry_t ds qualified
d ex_type 7a
d mi_type 4a
d spp s *
d map_table ds qualified
d num_ent 10i 0
d ent likeds(map_entry_t)
d i s 10i 0
d ws s 1a
d mi_type s 4a
d ex_type s 7a
// locate QLICNV's system pointer in SEPT
sept_spp = sysept();
qlicnv = sept(x'4A');
// retrieve space pointer addressing the associated
// space of QLICNV
spp = setsppfp (qlicnv_ptr);
for i = 1 to map_table.num_ent;
mi_type = map_table.ent(i).mi_type;
ex_type = map_table.ent(i).ex_type;
*inlr = *on;
oQSYSPRT e MAPREC
i5/OS Programmer's Toolkit also provides a Qshell utility command, lsobjtypes, that prints all supported MI object types to the standard output following the same rationale. C source code of lsobjtypes is available at https://i5toolkit.svn.sourceforge.net/svnroot/i5toolkit/qsh/lsobjtypes.c. To locate a specific entry by MI object type or external object type in the output of lsobjtypes, you can connect lsobjtypes and a grep command with a pipeline metacharacter (|). For example, the following QShell command locates the entry of Java Program (*JVAPGM):
> lsobjtypes | grep 0250
The following Shell commands sort the output of lsobjtypes by MI object type in the QShell and PASE Shell environments, respectively:
lsobjtypes | sort -k 1.1,1 # in QShell
qsh_out -c "lsobjtypes" | sort -k 1.1,1 # in PASE Shell environment
Where should we use this method?
Although the method of listing MI object types via QLICNV has been tested at V6R1 and earlier VRMs, you ought to pay attention to the fact that the QLICNV program is not an API officially documented by IBM and could possibly be changed in the future. So, the method introduced here is more suitable for tool programs being aware of their target VRMs.
Calling QLICNV to Convert MI Object Types to and from External Object Types
As a program object, QLICNV can be called to convert an input MI object type to a corresponding external object type and vice versa (if you have *EXECUTE authority to it). However, since QLICNV expects parameters passed to it as scalar data objects rather than space pointers, QLICNV can be called only from MI programs. Gene Gaunt wrote a very nice post in the MI400-L mailing list that describes the parameter list of QLICNV: http://archive.midrange.com/mi400/200201/msg00029.html. In that post, Gene also provided a nice MI program that "calls the undocumented API (QLICNV) for all 65536 MI object types (from X"0000" through X"FFFF") and builds a list of the valid object types in that range."
Different Sets of MI Object Types Supported by Different IBM i VRMs
Investigating the difference between sets of MI objects supported by different IBM i VRMs sometimes can be helpful for understanding the evolving progress of the platform. The following is the output of a PASE Shell diff command being applied to the output of the lsobjtypes command on V5R2 and V5R4, respectively, from which you can find out that there was no time zone (*TIMZON) object as of V5R2. Actually, the *TIMZON object type along with the time zone-related commands (e.g., WRKTIMZON) and the QTIMZON system value were introduced in V5R3 to achieve more effective time-zone management.
> 0DEE OHCUR
> 0E11 PDFMAP
> 0EA7 SORTSEQ
> 0EA8 MRD
> 1907 PRTIMG
> 192F TIMZON
> 1939 NWSCFG
> 1E51 OLBSF
> 1EB2 POBSF
< 2001 SOMOBJ
> lines are from lsobjtypes' output at V5R4
< lines are from lsobjtypes' output at V5R2
At the End
Like many of my articles, this article is based largely on the research of IBM i experts who have been contributing to the platform and the IBM i community for decades. It's their continual efforts that allow the younger generation of developers to learn about this excellent platform. They and the platform itself have taught us not only ways to build better software but also the scientific attitudes of software design. I sincerely thank them!