A UEPT will improve the performance of external program calls to user programs.
This article is a follow-up to my System Entry Point Table (SEPT) article. One of our readers, Mark Waterbury, suggested that I write it. In my SEPT article, I discussed the performance gains in API invocations brought by the SEPT object. Actually, to improve the performance of external program calls to user programs, you can also implement your own "SEPT," or, in other words, your User Entry Point Table (UEPT) objects for performance-critical applications following the same rationale of SEPT.
From the discussion in my SEPT article, you probably already realize that there's no doubt that a UEPT will also improve the performance of external program calls to user programs. This article will focus on the following topics:
- How to implement a UEPT via a User Space (USRSPC) object and how to use it
- When to maintain a UEPT
Implementing a UEPT via a User Space (USRSPC) Object
We always stand on the shoulders of giants. In most cases, we resolve problems by taking advantage of the knowledge left to us by our predecessors. Now, when you decide to implement a UEPT, you can simply borrow the design of the SEPT. Let's go through the process of implementing a UEPT step by step.
First, you must decide where to store the content (the system pointers to your user programs) of a UEPT. The SEPT object, QSYS/QINSEPT, is a permanent space object that resides in the machine context, or in other words, the QSYS library. The MI object type/sub-type code of the SEPT object is hex 19C3. The SEPT stores 16-byte system pointers to almost all APIs (user domain, system state programs in QSYS) and other programs in QSYS one by one in its associated space. So the object you use to store the content of your UEPT must fulfill the following criteria:
- It is a space object in the user domain or its associated space is in the user domain so that the UEPT can be accessed from user programs at security level 40 or above.
- It can be created, modified, or deleted conveniently by CL commands or APIs.
The answer is quite obvious: a user domain User Space (USRSPC) object. A user domain USRSPC has MI object type/sub-type code hex 1934. It can be created by the Create User Space (QUSCRTUS) API; it can be deleted by CL command Delete User Space (DLTUSRSPC); the content of a USRSPC can also be conveniently read or modified via User Space APIs or MI instructions. The Retrieve User Space (QUSRTVUS) API returns a piece of storage in a USRSPC directly. The Change User Space (QUSCHGUS) API modifies the content of a USRSPC directly; and the Retrieve Pointer to User Space (QUSPTRUS) API or the Set Space Pointer from Pointer (SETSPPFP) MI instruction retrieves a space pointer to the content of a user-domain user space so that the data in that user space can then be directly manipulated by high-level language (HLL) programs that support pointers. For example, you might create your UEPT object so that it can contain at least 2,048 system pointers, like the following.
CALL PGM(QUSCRTUS) PARM('UEPT QGPL' /* USRSPC name and library name */ 'UEPT' /* Object attribute */ X'00008000' /* Initial size of the UEPT USRSPC: 32K */ X'00' /* Initial value of the UEPT USRSPC */ '*USE' /* Public authority of the created UEPT USRSPC */ 'Your first UEPT' /* Text description */ ) |
To store system pointers to your user programs into the created UEPT, you could use either the QUSPTRUS API or the SETSPPFSP MI instruction to retrieve a space pointer addressing the associated space of your UEPT and then store system pointers to your user programs into your UEPT. To reserve the validity of pointers, it is important to make sure that each system pointer written into your UEPT object is aligned at 16-byte boundaries. Note that you must not use the QUSCHGUS API to write system pointers directly into your UEPT. The QUSCHGUS API does not preserve the tagged bits in the input pointers; therefore, the pointers written into a space object become invalid.
Fill System Pointers to User Programs into Your UEPT
Suppose you have three user programs—QGPL/PGMA, QGPL/PGMB, and QGPL/PGMC—that you want to store into your UEPT at offsets 0, 16, and 32, respectively. The following example ILE RPG program, filluept.rpgle, will add system pointers to PGMA, PGMB, and PGMC into your created UEPT.
/** * @file filluept.rpgle * */ h dftactgrp(*no)
/copy mih52 d ds d uept * d uept_fellow * procptr d overlay(uept) d uept_ptr s * d uepts s * dim(3) d based(uept_ptr) d qgpl s *
/free // resolve your UEPT [1] rslvsp_tmpl.obj_type = x'1934'; rslvsp_tmpl.obj_name = 'UEPT'; rslvsp2(uept : rslvsp_tmpl);
// retrieve a space pointer addressing the // associated space of the UEPT. [2] uept_ptr = setsppfp(uept_fellow);
// save system pointers to user programs // into the UEPT [3] rslvsp_tmpl.obj_type = x'0401'; rslvsp_tmpl.obj_name = 'QGPL'; rslvsp2(qgpl : rslvsp_tmpl);
rslvsp_tmpl.obj_type = x'0201'; rslvsp_tmpl.obj_name = 'PGMA'; rslvsp4(uepts(1) : rslvsp_tmpl : qgpl);
rslvsp_tmpl.obj_type = x'0201'; rslvsp_tmpl.obj_name = 'PGMB'; rslvsp4(uepts(2) : rslvsp_tmpl : qgpl);
rslvsp_tmpl.obj_type = x'0201'; rslvsp_tmpl.obj_name = 'PGMC'; rslvsp4(uepts(3) : rslvsp_tmpl : qgpl);
*inlr = *on; /end-free |
Notes on the above example program:
- [1] Resolve the system pointer uept to your UEPT.
- [2] Retrieve the space pointer uept_ptr, addressing the associated space of your UEPT. An array of system pointers to your user programs, uepts, is declared to be based on uept_ptr.
- Resolve each system pointer to your user programs in uepts by first resolving the system pointer to the context (library) in which your user programs reside and then resolving system pointers to your user programs via system built-in _RSLVSP4.
Prototypes of system built-ins _RSLVSP2 and _RSLVSP4 can be found in mih52.rpgleinc.
Alternatively, you may also use the Change User Space (CHGUSRSPC) command provided by the Space Object Tools subproject of open-source project i5/OS Programmer's Toolkit. Figure 1 is a screen-shot of writing a system pointer to program PGMA into the UEPT at offset 0 via the CHGUSRSPC command.
Figure 1: Write a system pointer to program PGMA into the UEPT. (Click image to enlarge.)
Using the following CL commands, you could implement the same jobs as the above-mentioned FILLUEPT program.
CHGUSRSPC USRSPC(UEPT) DTATYPE(*PTR) SYSOBJ(PGMA) OBJTYPE(*PGM) CHGUSRSPC USRSPC(UEPT) OFFSET(16) DTATYPE(*PTR) SYSOBJ(PGMB) OBJTYPE(*PGM) CHGUSRSPC USRSPC(UEPT) OFFSET(32) DTATYPE(*PTR) SYSOBJ(PGMC) OBJTYPE(*PGM) |
Use Your UEPT
Here is a simple example of how to use your prepared UEPT object to do external program calls to your user programs, testuept.rpgle.
/** * @file testuept.rpgle * */ h dftactgrp(*no)
/copy mih54 d ds d uept * d uept_fellow * procptr d overlay(uept) d uept_ptr s * d uepts s * dim(3) d based(uept_ptr) d argv s * dim(3) d UEPT_PGMA c 1
/free // resolve your UEPT rslvsp_tmpl.obj_type = x'1934'; rslvsp_tmpl.obj_name = 'UEPT'; rslvsp2(uept : rslvsp_tmpl); uept_ptr = setsppfp(uept_fellow);
// ... callpgmv( uepts(UEPT_PGMA) : argv : 0 );
*inlr = *on; /end-free |
Note that declaring a list of constants for index numbers of entries in your UEPT and including it into your programs that use the UEPT will make maintaining programs using the UEPT more convenient when your UEPT is upgraded from version to version.
When to Maintain a UEPT
Entries (system pointers) of the SEPT are resolved in the installation stage of the system and will never need to be updated until next installation, since the APIs they point to will never change. In contrast with the SEPT, user programs pointed to by entries (system pointers) in a UEPT are likely to change from time to time. So you must know when entries in your UEPT should be re-resolved to ensure that they point to the correct programs.
Just like other permanent objects in IBM i's single-level storage (SLS) address space, the segment ID of the base segment in the system pointer to a user program changes when one of the following occurs, which will then cause a resolved system pointer to the user program to become invalid:
- The user program is saved and restored to either the same library it has resided in or a different library.
- The user program is moved from one library to another library by using the Move Object (MOVOBJ) command.
- The user program is re-created by compiler commands, such as CRTBNDRPG or CRTPGM.
- The user program is modified by a Change Program (CHGPGM) command, unless the CHGPGM command is changing the program's text description only.
Note that a Rename Object (RNMOBJ) operation on a permanent object will not change the system pointer to it. Actually, according to the rationale that context objects (libraries) manage objects' addressabilities, there isn't a direct relationship between an object's symbolic ID (object name and MI object type) and the system pointer to it. That's why an object that has been renamed and moved to the QRPLOBJ library as the result of a create command with parameter REPLACE(*YES) has the system pointer pointing to it unchanged.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,
LATEST COMMENTS
MC Press Online