The IBM i 6.1 release introduces a new type of main storage memory pool that can only be used for data.
Data pools were created to isolate iSCSI disk I/O from other applications using the memory pool. By default iSCSI disk I/O uses the *BASE memory pool and can cause performance issues for any other applications that are also using the *BASE memory pool. The new data pools allow you to move the iSCSI disk I/O into its own memory pool, isolating it from other applications. The iSCSI virtual I/O shared data memory pool topic in the 6.1 Information Center will get you started on learning about this new support.
iSCSI support has been deprecated; the above paragraph is left for historical purposes. The information in the rest of this blog is accurate.
Data pools can’t be used by subsystems to run jobs. Data pools are defined by specifying *DATA for the activity level on the Change Shared Storage Pool (CHGSHRPOOL) command, for any one of the *SHRPOOLxx shared pools. The pool parameter on the Change Network Server Description (CHGNWSD) command indicates the pool to be used for iSCSI disk I/O. Storage for the data pool is allocated from main storage when the network server description is varied on.
While data pools were initially designed for the needs of the iSCSI I/O, they’re not limited to use by iSCSI. Data pools can also be used with the Set Object Access (SETOBJACC) command. The primary use of the SETOBJACC command is to improve application performance for jobs that access a database file in random order. Once the object is loaded into the pool, all read accesses to the file are done without a disk read, thereby eliminating much of the disk time needed to process the file.
The system won’t make any automatic performance adjustment to the size of data pools. The Change Pools (QWCCHGPL) API can be used to allocate and de-allocate data pools.
Another enhancement in memory pool management in release 6.1 is that you can move a running job to another memory pool. Previously you’d use the Reroute Job (RRTJOB) command to change the pool the job is running in. Now the Change Job Pool (QWCCHGJP) API can be used to move the job. The pool can be any pool defined in the subsystem the job is running in, the base pool or a private pool allocated for the job.
The two APIs to work with pools are:
Check out the source code and procedures I’ve provided that use these APIs to create commands to allocate and de-allocate memory pools and move a job to a different memory pool. Download Source code and procedures.
After placing the example command source in the QCMDSRC file and the example procedures in the QREXSRC file, you can create the commands with:
CRTCMD CMD(ALCPOOL) PGM(*REXX)CRTCMD CMD(DLCPOOL) PGM(*REXX)CRTCMD CMD(CHGJOBPOOL) PGM(*REXX)
Example 1 – Data pool for a highly used file
CHGSHRPOOL POOL(*SHRPOOL5) SIZE(500) ACTLVL(*DATA)
ALCPOOL POOL(*SHRPOOL5)
SETOBJACC OBJ(QINVFILE) OBJTYPE(*FILE) POOL(*SHRPOOL5)
(use the file)
DLCPOOL POOL(*SHRPOOL5)
Example 2 – Moving your job into your own pool
ALCPOOL POOL(MYPOOL) SIZE(400) ACTLVL(1)
CHGJOBPOOL POOL(MYPOOL)(after the job changes pools again or ends, deallocate the pool)
CHGJOBPOOL POOL(*INTERACT)
DLCPOOL POOL(MYPOOL)
Example 3 – Moving another job into the base pool
CHGJOBPOOL JOB(176753/MAY/QPADEV000S) POOL(*BASE)
Mike Russell wrote this week’s blog on changing memory pools and our new support for data pools. Mike is a member of the work management team and was the lead developer for this function. Thanks, Mike!
This blog was edited for currency on January 26, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.