iSeries tweaks for better OneWorld performance
So you know, there is really no silver-bullet to improving performance for OneWorld.
There are many tweaks that need to be made. So are controllable on the iSeries and
Deployment side, and some are on the network side.
TCP/IP - iSeries
Double-check with your network admins before making any of these changes to assure
that your network can handle this and that you will not have any conflicts
MTU (Maximum Transmission Unit):
Under the Routing Entry Information (CHGRCPRTE) there is a setting for the
MTU, this should be set to *IFC so the max bandwidth can be used.
The TCP Attributes has a buffer size, this should be set to 64k (65536) for both
the send and receive.
Make sure that your Deployment Servers DNS name is in the Host Table. The
iSeries will look there first, before accessing your network DNS system. This
will shave off a few milliseconds on any query return.
Put the QUSRWRK in its own share-pool – OneWorld INIT jobs will consume as much
memory as you give it.
Rule of thumb for the Citrix side is that a users job will take on average 100 Mb of
memory per session (if BSFN’s run on the MetaFrame server – you PD environment, not
the WPD environment).
On the server side, they will consume as much as they need to fulfill the job. We had 290
concurrent users (and about 30 other web users) coming in through QUSRWRK, and
took 20 Gb of memory. Rule of thumb for consumption of OneWorld users on the
iSeries (Xe statistic) is 15Mb allocated in the memory pool of the QSERVER sbs for
every OneWorld user.
If you do not put them in a share pool of their own, they will take memory from *BASE
which is used for all batch jobs and app jobs – this will effect everything (besides the OS
which runs in *MACHINE and printers which run in *SPOOL).
An average UBE will take about 150-200Mb of memory to run. This really depends
upon the UBE running, but for your average user, this is reasonable.
In Xe you can choose between painting the grid all-at-once or page-at-a-time. Using
Page-at-a-time is much faster initial results for the user and easier on the INIT job, but if
they need to go to the end of the output, it will take longer than all-at-once.
This has been changed in E810 (pre update I1) to go back to all-at-once. A step back in
my opinion, and they are planning on fixing this in 8.95
This should be set to *OPTIMIZE (not *MAX – that will kill your system)
If you have SMP (symmetric multi-processing), this is very handy for OW jobs.
These are the pre-start jobs for QUSRWRK and what OneWorld uses to connect to the
iSeries. OneWorld users typically use 7-9 ODBC connections for their session.
Therefore the initial number of INIT jobs should be 5-8 times the number of concurrent
users you will be expecting.
An easy way to tell the number of concurrent connections is to run this command on your
iSeries DSPACTPJ QUSRWRK QSYS/QZDASOINIT (or where ever your
QZDASOINIT jobs run). You will want to reset the statistics then run it again awhile
longer to get a good average.
The rule of thumb for setting these up are as follows:
Start jobs – *YES
Do you want these jobs to start when the SBS comes up
Initial number of jobs – 800
This is the number of jobs that will start when QUSRWRK comes up, the larger
the number, the longer it takes to bring the SBS completely up, but you will have
that many ready for the users when they start signing on. This number should be
about ½ to ¾ your peak total number of users.
Threshold – 8
This number will equal the number of ODBC connections (Data Sources) it takes
for a user’s session – normally 7-9, unless you’ve added a bunch of custom
libraries to OCM. An easy way to tell this number is to list all the libraries that
your OneWorld users will hit:
DD*** – Data Dictionary
OL*** – Object Librarian
SY*** – System Lib
SVM*** – Server Lib
***DTA – Business Data
***CTL – Control Tables
CO***** – Central Objects
***** – Any Custom Libs
Additional number of jobs – 16
This number should be equal to starting up 2 new user sessions in OneWorld, or
double the number in the threshold parameter – that way you always have enough
open connections to fill two OneWorld user requests, plus anyone else sneaking
Maximum number of jobs – *NOMAX
I would suggest a large number here. Ours is set to *NOMAX
Note; whatever number you put in here will not prevent people from signing on.
If you indicate 1000 here and 999 INIT jobs are in use, the next person to sign on
with sign in using a BATCH Immediate (BCHI) job rather than a pre-start job.
Maximum number of uses – 100
This can vary, if you restart the subsystem and the OneWorld services every
night, this can be lower, if you restart the SBS and services once a week, then
setting it between 100 & 150 should be okay. It takes just as much memory and
IO to start a new one as it does to keep one listening.
Here is a write up from IBM on this parameter:
The maximum number of sequential uses which can be handled by each prestart job before
the job will be ended rather than reinitialized. The default is 200. The same job number is
used for 200 different connections. If this is set to 1, the job is used one time and then
ended after the client disconnects.
Note: The subsystem will immediately end QZDASOINIT jobs in a status of PSRW when the
number of QZDASOINIT jobs in a status of PSRW is above the Threshold plus the
Additional number of jobs values. It will end QZDASOINIT jobs that are in a PSRW state
until the number of jobs in a PSRW state is equal to or below the Threshold plus the
Additional number of jobs values.
Pool identifier – 1
This should be pointing the newly setup share pool – not *BASE which will be 2,
as a failover
PeopleSoft (JDE) takes advantage of SMP (Symmetrical Multiprocessor). If you have
purchased this feature, make sure you’re taking advantage of it:
0 = OFF
1 = ON
2 = System Controlled
Make sure it is 1 (ON)
UBE’s can really tax the system. Make sure that any large UBEs are scheduled (if they
can be) to run during off-peak hours (and that the BSFN’s they call run on the enterprise
Prior to the new i5 Chips that are in the new 5 Series, the rule of thumb was to run 1 less
concurrent UBE than you have processors. The new chips will handle a little more load
Tuning UBE’s is specific to your shop though and is a hard area to suggest tips on. I
would really check the load that long running UBE’s put on your system and the
possibilities of off-loading BSFN’s that users kick off, to run on the server if they tax the
Definitely make sure that your files are setup to handle the MAX 1 TB index size.
Ex. DSPFD – PRODDTA/F0101 (ACCPTHSIZ *MAX1TB).
If you moved from World to OneWorld, these could still be set to *MAX4GB.
Make sure that you utilize OneWorld indexes. World did not always have keys on their
files or logicals, this allowed for duplicate data and would produce several unnecessary
informational messages on OneWorld UBEs
SQL Packages (SQLPKG):
If you are using Client Access (now called iSeries Access, and soon to be changed again),
there is an option to utilize a SQL Package. Setting your DSN up to have a SQL package
for each library will eliminate corruption and the packages from filling up too quickly.
OneWorld like SQLPKG’s to have a max setting of 500Mb, even though the iSeries can
handle much larger (max depends on the OS version). If the SQLPKG gets any larger,
the query will spend more time searching the package than running the query.
These should be cleaned up at least once every two weeks. Anytime a new file is created
or an existing one is modified, this need to be deleted so the SQLPKG will reflect the
If you have a lot of security on your users, these will fill up with security query
information, rather than file information.
To see what is in a SQLPKG – run the command (PRTSQLINF – PRODDTA/****
*SQLPKG). This will printout a spool file with the information.
Note – We have seen that in 8.10, if you run a UBE from the command line with the
RUNUBE command, it will use a different index (or at least do a table scan vs index
scan) for a file, than if you ran that same UBE from within OneWorld. To fix this, we had
to run all the UBE’s from within OneWorld to create the SQLPKG for that UBE in the
system library (E810SYS or B7333SYS).
OneWorld requires journaling to be turned on for numerous files. Hence why OWJRNL
is installed with the upgrade or initial install of OneWorld.
It is beneficial to keep the journals and the journal receivers in a separate ASP than the
rest of the data. This is a good rule for any system that uses journaling or a HA (High
Packages are built in the IFS; they are then deployed to a library and the IFS. When
submitting a full package, turn off journaling of the IFS (if you are using an HA system)
directory /ONEWORLD/PACKAGES/ to speed up the process. When you turn it back
on, double check afterwards that your package has been sent across to your backup
Client Access (iSeries Access):
These settings take a lot of testing because they are specific to your shop and to the
version of both OneWorld and Client Access that you are on. They will also change as
you upgrade and enable new modules.
Ex. The Enable Lazy Close Support – in Xe it was suggested to check this. In E810, we
were having issues with the security kernel not relieving locks on the F98OWSEC,
unchecking this so it forced a close on exit fixed that problem.
Changing the INI is a pretty touchy area. If you have a test server (not environment), that
would be the ideal place to make the change, since this does effect all environments and
can cause some interesting results. Here’s a few tips on the INI settings to look at:
maxNetProcesses=3 There should be 1 for every 3-4 Call Object Kernels
The Lock Manager (sometimes called the TP Monitor) should contain the AS/400
system name (Server= ). With this entry, the Server name will get cached and
UBE’s that refer to it will run faster (anytime a UBE has to log the system it ran
on and the time will benefit from this). This also helps any Master BSFN that
runs on the server for data integrity.
[NETWORK QUEUE SETTINGS]
InstallERSpecs=N (This is primarily for the Event Rules)
Configuring your kernels – again this area is my suggestions only, but I will describe
what they are for and you can determine how many to put in.
Description Number of Kernels
[JDENET_KERNEL_DEF2] 1 per CPU -1 (if you have 8 processors, then set this to 7)
The UBE_Kernel does not do all the UBE work. UBE’s will run in their designated JOBQ’s, not
solely through here. UBE’s and package installs run as RUNBATCH processes on the server.
Data replication Kernel
[JDENET_KERNEL_DEF4] 1 for every 50 concurrent users
Security Kernel – Processes will fail if there are not enough security kernels. Users will also get
the message that the security kernel is busy. Set the max to follow the rule in number of kernels,
but the Autostart to 1 or 2.
There can only be one Lock Manager running
This is the Call Object Kernel. This runs not only the MBF’s but all BSFN’s mapped to the
server. This will take some toying with to get tuned for your shop.
The JDBNET (server-to-server) Kernel should start with 1, add more if you utilize it more.
[JDENET_KERNEL_DEF8] (Xe and prior) 1 per CPU
The Package Build Kernel should follow closely the same guidelines as the UBE Kernel. This is
replaced with DEF11 in later releases.
You should only need one SAW Kernel. One CNC and Admins will use SAW.
There is really only one Scheduler per system
[JDENET_KERNEL_DEF11] 1 per CPU
Same as DEF8, the JDE Queue is what is important rather than the number of Kernels.
There can only be one UBE Subsystem Kernel
[JDENET_KERNEL_DEF13 - 24]
These are all new to 8.10 & 8.11 and I have not spent a lot of time tweaking these & testing them.
As any iSeries Admin will tell you – the more disk arms you have on a system, the faster
Last Minute Notes:
Make sure that you are current on OS400 cumulative updates and the APARs. If you use
TSE’s and seeing sluggish performance, try setting them to 16 color mode instead of the
default 256 color mode. You don’t need a lot of colors in OneWorld (I’m color blind and
function just fine in there).
This is personal documentation from Kristian Bryant and not PeopleSoft. Changes
to enhance performance should be done with careful consideration and not during
peak load times.