Ma Pics Book

MAPICS Book

Jimmy Sansi

Contents Custom Print File Overrides ......................................................... 2

Date Conversions .......................................................................... 4

Purchase Order Offline Load ........................................................ 8

Inventory Audit Reports ............................................................. 12

Backing Up ................................................................................. 16

Applying Program Updates ........................................................ 26

Database Tuning ......................................................................... 29

System Performance ................................................................... 39

Additional Resources .................................................................. 41

Custom Print File

Overrides One of the neat features of XA is the ability to setup OS/400

print file overrides for any report without having to

customize any code. The overrides are setup in the Cross

Application Support module and can be setup a variety of

ways including by user, report, company and warehouse

depending on the report.

However there may be times when you want to create

overrides using the XA method for applying an override to a

custom report or job that is executed from within an XA

environment. This can be accomplished by configuring the

report and then calling program AXZPOV1R to retrieve the

override parameters.

First you will need to create the report override record in the

Cross Application Support module. The Printer file name is

one of the parameters you will use when to pass to the

AXZPOV1R program when called.

At the most basic level there are two parameters passed

when calling AXZPOV1R, the print file override name and

the control data such as warehouse or company number.

CL code calling program AXZPOV1R and retrieves a string

variable containing the OS/400 OVRPRTF report override

command.

PGM

/* PRTF OVERRIDE PROGRAM PARMS */

DCL VAR(&P1RPNM) TYPE(*CHAR) LEN(10)

DCL VAR(&P1CNTL) TYPE(*CHAR) LEN(10)

DCL VAR(&P1PFNM) TYPE(*CHAR) LEN(10)

DCL VAR(&P1AOOQ) TYPE(*CHAR) LEN(1)

DCL VAR(&P1AOAT) TYPE(*CHAR) LEN(1)

DCL VAR(&P1RTNC) TYPE(*CHAR) LEN(1)

DCL VAR(&P1CMD) TYPE(*CHAR) LEN(512)

/* Change P1RPNM to the name of the report override */

CHGVAR VAR(&P1RPNM) VALUE('ORDACKRP ')

CHGVAR VAR(&P1CNTL) VALUE(' ')

/* Retrieve OVRPRTF command for this report */

CALL PGM(AXZPOV1R) PARM(&P1RPNM &P1CNTL &P1PFNM +

&P1AOOQ &P1AOAT &P1RTNC &P1CMD)

/* If return code is valid then apply override */

IF COND(&P1RTNC *EQ '0') THEN(CALL PGM(QCMDEXC) +

PARM(&P1CMD 512))

CALL PGM(ORDACK)

DLTOVR FILE(ORDACKRP)

MONMSG MSGID(CPF9841)

ENDPGM

This is a straight forward override that works best as a

report or user/report override combination, if you want to

create an override by company or warehouse you would

need to place the appropriate value into the variable

P1CNTL to signify the override to use otherwise it should

be left blank.

Here are the return variables from program AXZPOV1R, as

shown in the sample source code your program should

check return variable P1RTNC to make sure the call was

successful and handle any errors returned appropriately.

Output Parameter Description

P1PNFM Program file name

P1AOOQ Outq override allowed

P1AOAT Attribute override allowed

P1RTNC Return code (0=okay, 1 =error)

P1CMD OVRPRTF command string

Date Conversions Dates stored in the XA database files are stored in a non-

standard 7 digit format of CYYMMDD that does not work

well when using them with RPG or CL programs and you

can‟t easily use the date operations ADDDUR or SUBDUR

functions without scrubbing the date into a more

standardized format such as MMDDYY.

Typically in most XA shops you would find old utility

programs written by past programmers to get around the

date dilemma using a kludge like combination of RPG

programs with MOVE operands and substring logic to

convert from regular date formats to XA and vice versa.

While these programs do suffice fortunately now in modern

times there are a couple of macro programs that can do the

date manipulation and conversions for you.

The first program you can use, AXZDT will do date

conversions and of course error checking. Here is the

parameter table.

Parameter Description

RQUEST (5A) *FILE = Convert USER to

FILE

*USER = Convert FILE to

USER

*CALC = Add FILE date to

USER and store in FILE

*DIFF = Calculate

difference in days between

USER and FILE, store in

FILE

USRFMT (1N) User date format

0 = System value

1 = MMDDYY

2 = DDMMYY

3 = YYMMDD

4 = CYYDDD (Julian)

USER (6N) Date in user format

FILE (7N) Date in XA format

ERROR (1A) Error code

„ „ = No Error

„E‟ = Parameter Errors

„I‟ = Invalid date

Let‟s take a look at a sample CL program to convert the date

December 20th

, 2008 to the XA file format of 1081220.

PGM

DCL VAR(&RQUEST) TYPE(*CHAR) LEN(5) VALUE('*FILE')

DCL VAR(&USRFMT) TYPE(*DEC) LEN(1 0) VALUE(1)

DCL VAR(&USER) TYPE(*DEC) LEN(6 0) VALUE(081208)

DCL VAR(&FILE) TYPE(*DEC) LEN(7 0)

DCL VAR(&ERROR) TYPE(*CHAR) LEN(1)

CALL PGM(AXZDT) PARM(&RQUEST &USRFMT &USER &FILE +

&ERROR)

/* At this point variable *FILE = 1081220 */

ENDPGM

Now it‟s time to convert from XA formatted date of

1081201 to a more standard date 120108 in the format of

MMDDYY.

PGM

DCL VAR(&RQUEST) TYPE(*CHAR) LEN(5) VALUE('*USER')


DCL VAR(&USER) TYPE(*DEC) LEN(6 0) VALUE(0)

DCL VAR(&FILE) TYPE(*DEC) LEN(7 0) VALUE(1081201)

DCL VAR(&ERROR) TYPE(*CHAR) LEN(1)

CALL PGM(AXZDT) PARM(&RQUEST &USRFMT &USER &FILE +

&ERROR)

/* At this point variable *USER = 120108 */

ENDPGM

The other useful date program is AXZPDR and its purpose

is to return the current date and time. AXZPDR can be

useful when called in conjunction with AXZDT. When

calling program AXZPDR it has three parameters:


USRFMT (1N) Date Format

DTUSR (7N) Current Date

DTIME (6N) Current Time

Here is a sample CL program to call AXZPDR and retrieve

current date and time. You will need to examine return

variable USRFMT against the parameter table for AXZDT

to find out the format the date will be returned in.

PGM


DCL VAR(&DTUSR) TYPE(*DEC) LEN(6 0)

DCL VAR(&DTIME) TYPE(*DEC) LEN(6 0)

CALL PGM(AXZPDR) PARM(&USRFMT &DTUSR &DTIME)

/* &DTUSR is equal to current date in USRFMT format */

/* &DTIME is equal to current time in HHMMSS format */

ENDPGM

At this point the benefit would be to write a program that

calls AXZPDR to retrieve the current date and then convert

it into the format of your choice using AXZDT.

Purchase Order Offline

Load Quite frequently the need to create purchase orders from

outside systems and third party programs arises. To fit this

requirement there is an available enhancement PTF

SH67254 for XA R6 and R7. However if you are using an

older version of XA there is another little known way to

create and modify purchase orders from your own custom

programs through a collection of API programs that comes

with the Purchasing module to make this happen.

Of course nowadays the preferred way to get any data into

XA including your own customized Integrator objects

would be to use the System-Link module or the lesser

enhancement offline load PTF. In a pinch though this

method will work for creating simple straight forward POs

or can be used to create POs in an automated fashion

without user intervention as is required when using the

offline load technique. These APIs have been tested on

release 5 through release 7.

The available API programs that can be used to generate

and modify purchase orders are as follows:

AMIAI10R

Assign purchase order number. This program retrieves the

next available purchase order number from the SYSCTL file

and then increments the record. You should never access

and directly make changes to SYSCTL!

AMIAI01R

Access and maintain purchase order master file POMAST.

AMIAI02R

Access and maintain purchase order item file POITEM.

AM6AI01R

Access and maintain the purchase order comments file

POCOMT.

The parameters for each of these programs are as follows


RTNCD Return code

FNCTN Function code

LCKOUT Record locking

Data Structure Data structure of parameter

file.

The last parameter for each program is a data structure

(except for AMIA10R, the last parameter can simply be a 7

character alpha field to hold the purchase order number) of

the corresponding file containing all the fields that can be

maintained using the API call, to use them simply define the

corresponding file as an external data structure and then

pass that data structure as the data structure parameter when

calling the API.

The list of files to define as the data structure for each

program as follows:

ZDATI01R

Purchase order master file POMAST for program

AMIA01R.

ZDATI02R

Purchase order item file POITEM for program AMIAI02R.

ZDAT601R

Purchase Order comment file POCOMT for program

AM6AI01R.

The best way to get a thorough layout for each of these files

including extended field descriptions and requirements is by

utilizing the File Record Layout Report AMZ14 that you

can run by selecting the appropriate option off of the

Reports menu in Cross Application Support module by

selecting to “Specify Files.” Not only will this report list all

of the fields but often times the correct data for key fields

including the characteristics for those fields.

Here is some sample ILE RPG code for both the prototype

specifications and the data structure definitions used to

retrieve an available PO number and maintain the POMAST

file.

d RTVPONbr PR EXTPGM('AMIAI10R')

d RTNCD 1

d FNCTN 1

d LCKOUT 1

d PONBR 7

d CRTPOM PR EXTPGM('AMIAI01R')

d RTNCD 1

d FNCTN 1

d LCKOUT 1

d POMRCD like(dZPOMST)

d dZPOMST e ds extname(ZDATI01R) inz(*EXTDFT)

Sample calls in ILE RPG to retrieve the PO number and

create a purchase order.

RTVPONbr(pRTNCD:pFNCTN:pLCKOUT:dZPONBR);

CRTPOM(pRTNCD:pFNCTN:pLCKOUT:dZPOMST);

For more information on the API programs, including

information on additional APIs available to do a variety of

purchasing related tasks take a look at Appendix D of the

Purchasing user manual.

Inventory Audit Reports When utilizing material requirements planning based

systems it is critical to maintain very high levels of accuracy

in bills of materials and inventory otherwise it will cause

chaos in those planning systems. There are several audit

reports available designed to help maintain a high degree of

inventory accuracy and the integrity of inventory

management item balance file including the Allocation

Quantity Audit Report, On Order Quantity Audit Report,

and Location Quantity Audit Report.

It is also generally a good idea and typically requested from

accounting personnel that some sort of perpetual inventory

report be run on a daily basis. In addition if your XA

environments are tailored for batch/lot control, running an

additional inventory report over the location detail file

makes sense. Let‟s examine each of the inventory auditing

reports available.

Allocation Quantity Audit Report

The Allocation Quantity Audit report AMI9A2 processes

item balance records in the file ITEMBL correcting the

manufacturing allocated quantity (MALQT) and pick list

requirements (PLREQ) fields by comparing the quantities to

the manufacturing data records and customer order releases.

The command SBMALQAUD to call this report was

introduced with release 6 as part of enhancement PTF

SH64159.

On Order Quantity Audit Report

The On Order Quantity Audit report AMI9C2 checks the

item balance file on order records against open

manufacturing and purchase orders. The command

SBMOOQAUD to call this report was introduced starting

with release 6 as part of enhancement PTF SH64166.

Location Quantity Audit Report

The Location Quantity Audit report AMIC21 makes

comparisons between the item balance file ITEMBL on

hand quantity against the location quantity file SLQNTY

and prints any differences. This is simply a report and does

not modify any records, if you have a discrepancy between

these two files it should be corrected by using a combination

of Inventory Adjustment (IA) and Location Adjustment

(LA) transactions using the location quantity detail and

transaction entry options in the Inventory Management

module. The command SBMLCQAUD to call this report

was introduced starting with release 6 as part of

enhancement PTF SH64160.

Release 5 Considerations

Unfortunately the enhancement PTFs to run the audit

reports where only made available for releases 6 and 7.

However it is possible to create a CL program to call the

report programs directly and print the On Order Quantity

and Allocation Quantity Audits as in the example below.

You would need to run the Location Quantity audit report

manually since it does not actually modify any records it

can be run ad hoc any time.

/* Automate On Order Quantity and Allocation Quantity */

/* Audits in Inventory Management – YY Environment */

PGM

ADDLIBLE LIB(AMALIBY)


STRMAPICS ENDS(YY) MENU(*NONE)

CALL PGM(AMIPVF) PARM(0 'YY')

CALL PGM(AMIPVA) PARM(0 'YY')

ENDMAPICS

ENDPGM

Inventory Transaction Register

The inventory transaction register report AMV3G prints out

a detailed report of all inventory transactions processed

since the last time the register was run. It essentially is a

listing of all the data associated with the transaction that is

stored in the Inventory Transaction History file IMHIST.

The command PRTIMTXR is available for all releases so

you can automate the job.

If you are running a large volume of inventory transactions

this report will be incredibly large and is capable of

becoming thousands of pages in length rendering it quite

useless unless you need to pinpoint a specific transaction

posted. Along with the regular register is an identical report

that lists only the transactions that are in error, this error

report can help identify issues with IM batches that need to

be corrected or investigated further.

Perpetual Inventory Report

This is simply a report by warehouse and item that queries

the item balance file and calculates the perpetual inventory

balances by multiplying the on-hand quantity by standard

cost, average cost or last cost depending on how you

tailored questionnaire response I006. Running some sort of

perpetual is a good idea since it allows a “snapshot” of the

inventory value at a certain time in history, the only other

way to get this data is to look at specific inventory

transaction records stored in the IMHIST file which would

be very cumbersome.

The stock Inventory Valuation report AMISS can be found

in the reports section of the Inventory Management module.

This report can be run ad hoc, however it has a couple of

potential drawbacks including the inability to run it as a

batch job (so it can‟t be automated as part of a scheduled job

or backup routine) and it also includes items that have zero

quantity on hand which you may or may not want to see.

The easiest way to generate your own perpetual inventory

report would be to create a Query/400 query or if you are

using another reporting tool you could also use the

following SQL routine:

For detailed inventory listing by warehouse, location and

batch/lot you can use the stock report Location Stock Status

Detail AMISD or write your own over file SLQNTY.

Scheduling the Reports

Since the On Order and Allocation quantity audits directly

make changes to the item balance file these reports need to

be run after hours or as part of the backup routine otherwise

they can hang up trying to contend with record locks from

user jobs. Running the audit reports coupled with a

perpetual inventory report during a dedicated backup

provides a very clean daily cutoff period where inventory

transactions will be prevented from occurring making any

reconciliation or researching inventory issues much easier.

For sample CL programs to run the audit reports and

transaction register as part of the backup routine see the

chapter on backing up XA.

Additional Transaction Registers

Although not necessarily used for inventory accuracy

purposes there are two additional inventory transaction

registers that should be run from time to time to help keep

database file sizes small. These can be found in the

Customer Order Management and Purchasing modules and

utilize the same report AMV3G as the IM transaction

register. The information contained in the COM and PUR

registers contains IW, RW, SA transactions related to sales

orders and RP transactions from purchase order receipts.

Backing Up One of the more important responsibilities performed by a

system administrator is ensuring a good backup is running

daily. If the schedule of your business operations allow it

running the XA backup routine is a good idea. Not only will

it save important data files the backup job does some other

maintenance tasks as well so if your shop isn‟t running

twenty-four seven or can at least spare a couple hours of

downtime you should definitely run the XA backup routine.

There are a couple of things that need to be done to ensure

the backup goes off without a hitch, namely closing out

transaction batches and ensuring users have logged out of

there sessions to the environment that is being backed up.

Trying to get users comply with either of these tasks is

almost always easier said than done often leaving active or

suspended batches that will stall out a backup or users who

have gone home for the day that leave there sessions open.

Improperly closed transaction batches seem to occur most

often in the Inventory Management and Accounts

Receivable modules although it is possible that improperly

closed batches in Purchasing, Production Monitoring and

Control and Repetitive Production modules can cause a

backup to fail. One solution to active or suspended batch

issue is to have a person like an operator go through the

batches and close them out prior to running the backup or at

the end of the day when everyone has gone home,

alternatively you can write a custom program to process the

inventory transaction batch control file INTRNC closing

batches by changing the field BSTAT equal to „C‟.

If your system is running only one XA environment you

should also set the OS/400 system value QINACTITV

interactive job time-out to something other than *NONE as

this will automatically log off idle users after a specific

amount of time in minutes. This system value ends sessions

of idle users who have gone home for the day except I have

seen instances where users won‟t get logged out for

whatever reason. To get around this you can also end the

interactive subsystem that users are logged in through

QINTER and also flag a backup setting to end sessions that

will be covered in a moment.

If you are using any of the Power Architecture programs

like Power-Link or Net-Link there is an idle timeout setting

that works exactly like the QINACTITV timeout setting that

you can configure through the Application Settings of the

System tab in Power-Link itself. In the backup

configuration there are also settings you will want to enable

that will end inactive, active, prestart client jobs and batch

jobs.

Auto-log off settings for Power Architecture programs.

XA Backup Options Screen.

If you are running XA release 5 you will also need to ensure

that there are not any ABENDed jobs as this will also

prevent the backup from running, this can be done by

selecting using the job status program in the CAS module or

by creating a custom program that removes records from the

JOBACT file but first check that the job is not active which

can be done by calling the OS/400 Retrieve Job Status API

QWCRJBST. As of release 7 checking for ABENDed jobs

is no longer an issue except for any un-attached UJOBs with

ABEND status which is highly unlikely to occur.

If after all this you are still having problems with the backup

not getting dedicated mode try ending and re-starting the

QUSRWRK subsystem from within the pre and post backup

routine. Doing this along with ending the interactive

subsystems will essentially cut off all access to the system

ensuring there are no jobs keeping any locks on files

preventing the backup from running. The downside of doing

so is that after the pre backup job runs if for any reason the

backup job fails to get dedicated mode it just ends and

doesn‟t run the post backup job, so if you have shut down

all the subsystems no one can access the system including

the administrator whom then needs to start all the

subsystems again. One way to get around this is to create a

second interactive subsystem that requires a specific device

name to connect that an administrator can log into to start up

subsystems.

Lastly a detailed job log is created as part of the backup

program to be used for further problem analysis and will be

required if requesting help from support.

Backup Methods

XA offers two methods of backing up data files. The first is

the traditional backup to tape option and the other is backing

up to disk which saves all of the XA data files into OS/400

save files located in the library AMSLIBy (where y is the

designator for your environment). If you opt for backing up

to disk you will either have to manually run the option to

save the backup to disk onto a physical tape or write a CL

program to accomplish the same thing. If your system is

tight on disk space you will probably want to run the backup

to tape option, the downside to backing up to tape is that it

can take longer to process since tape drives are slower then

hard drives.

Whether backing up to disk or backing up to tape if you

need to save any custom programs or libraries you will need

to incorporate the routines to do so in the pre or post backup

commands. If backing up to tape a simple SAVLIB

command will suffice or if backing up to disk create a save

file and save custom objects to the save files. Investigation

of the stock XA program that saves a disk backup to tape

reveals that it issues the OS/400 SAVSAVFDTA command.

It is important to note that these backups pertain to XA data

master and transaction files only and will not backup the

application libraries, there are additional XA menu options

to do so or the application libraries can be backed up as part

of a weekly or monthly save entire system performed by

selecting option 21 from the “save” menu of OS/400.

One final word regarding the pre and post backup

commands is that it is very important to write good quality

code and be sure to do some error checking within them. If

either of these programs hang up with a message wait it will

stop the backup until the message is answered and if

interactive subsystems have been ended no one will be able

to access the system.

Release Considerations

If you are running release 7 of XA there is a new option

available to schedule and run your backup job from the

OS/400 job scheduler. Releases prior to 7 allow you to

manually schedule a single backup job and places the

backup job into a job queue requiring you to go through the

process of scheduling the backup daily.

Tying It All Together

Regardless of what backup method selected you should

utilize the pre and post backup commands to run your own

custom CL programs to close out active or suspended

transaction batches, end and restart subsystems, save any

custom libraries and perform maintenance tasks. The pre

and post backup commands are specified in the backup

options program.

Backup Options for Pre and Post-Backup Commands.

A sample pre-backup program that shuts down the

appropriate subsystems, closes out the Inventory

Management transaction batches and runs several reports,

these reports are covered more thoroughly in another

chapter. Lastly it prints a report on what object locks are on

the SYSCTL file, the XA backup job tries to allocate

SYSCTL and if it can‟t the backup fails so this report can

help you diagnose any remaining jobs holding up your

backup from running.

PGM

ENDSBS SBS(QINTER) OPTION(*IMMED)

DLYJOB DLY(60)

/* End Java Servers for Release 7 Only */

PSICTLUJB ENV(YY) UJOB(PSVJUP) REQUEST(*END)

DLYJOB DLY(300)

PSICTLJVS REQUEST(*LIST) ENVLIST(YY) CTLOPT(*END)

GLBSRV(*YES)

ENDSBS SBS(QUSRWRK) OPTION(*IMMED)


DLYJOB DLY(300)

/* Custom program to close active and suspended IM batches

*/

CALL PGM(CLSBCH)

/* Print Inventory Transaction Register */

PRTIMTXR PROMPT(*NO) ENDS(YY)

/* Print Allocation Quantity Audit Report */

SBMALQAUD PROMPT(*NO) ENDS(YY)

/* Print On Order Quantity Audit Report */

SBMOOQAUD PROMPT(*NO) ENDS(YY)

/* Print Location Quantity Audit Report */

SBMLCQAUD PROMPT(*NO) ENDS(YY) RPTFMT(*SUMMARY)

/* Print report on object locks on SYSCTL file */

WRKOBJLCK OBJ(AMFLIBY/SYSCTL) OBJTYPE(*FILE) MBR(*ALL) +

OUTPUT(*PRINT)

ENDPGM

CL code for Post Backup program that saves custom library

and the Integrated File System then starts up the interactive

and batch subsystems so users can get back on the system.

PGM

CRTSAVF FILE(AMSLIBY/CUSSAVF) TEXT('Custom Data Library')


CRTSAVF FILE(AMSLIBY/IFS) TEXT('IFS Save File')


SAVLIB LIB(CUSLIB) DEV(*SAVF) +

SAVF(AMSLIBY/CUSSAVF) OUTPUT(*PRINT)

SAVDLO DLO(*ALL) DEV(*SAVF) SAVF(AMSLIBY/IFS)

STRSBS SBSD(QINTER)

STRSBS SBSD(QUSRWRK)

ENDPGM

RPG source code listing for the CLSBCH program that

closes active and suspended inventory transaction batches.

FINTRNC UP E DISK

FQSysPrt O F 132 Printer OFLIND(*IN90)

*

D Count S 5 0

*

C If Not *IN30

C Except Header

C Seton 30

C EndIf

C If BStat = 'A' Or

C BStat = 'S'

C If *IN90 = *On

C Except Header

C Setoff 90

C EndIf

C Except Detail

C Eval BStat = 'C'

C Update INTRNCTA

C Add 1 Count

C EndIf

CLR Except PrtCount

*

* Audit Report

*

OQSYSPRT E Header 2 03

O UDATE Y 9

O 42 'Records in Batch file'

O 66 'INTRNC that were active

O 82 'and auto-closed'

O 125 'Page:'

O PAGE 130

O E Header 1

O 17 'Previous Batch'

O 40 'Month/Day Time of'

O 64 'Batch Rcd Error Rcd'

O 77 'Total'

O E Header 2

O 18 'Batch Sts Number'

O 40 'of Update Update'

O 62 'Count Count'

O 78 'Quantity'

O 101 'Total Amount'

O E Detail 1

O BSTAT 6

O BATCH Z 16

O MODAY Y 28

O UTIME 41 ' : : '

O BCNTM J 52

O BERRS J 63

O TOQTY J 81

O TOAMT J 102

O E PrtCount 2 1

O 25 'Records updated . . .:’

O Count J 34

Sample Report

Applying Program Updates Program fixes and updates come in two different flavors,

Program Temporary Fixes (PTF) and Program Corrective

Maintenance (PCM). The primary difference between the

two is that a PTF generally contains individual bug fixes

while PCMs contain an accumulation of individual PTFs

and all major program enhancements in a single package

applied at once from a CD or tape.

Before applying any XA PTFs or PCMs you will need to get

the AFD utility that allows you to download individual

PTFs from the Infor support site and convert them into a

format that then allows the XA Cross Application Support

modules Program Maintenance functions restore and apply

them to your XA environments. This function is covered in

the Cross Application Support manual as well.

When it comes to applying PCMs it is a much more

comprehensive and difficult task due to the number of steps

required to ensure success. First you will want to review the

PTF status inquiry program to find out what PCM level the

environment is currently at.

The current PCM level for this release 7 XA

environment is 4021.

After finding out the current PCM level get on the Infor

support site and download informational PTF SH12472.

This PTF contains a list of all PCMs and the corresponding

pre-requisite download for all PCMs dating back to XA

release 4.

Once you have identified the current PCM level your

environment is running at, utilizing the information from

SH12472 get back on the support site and order the latest

PCM CDs. You will need to order every PCM CD and

apply them in the order listed, you cannot skip PCMs.

PCM Apply Process

When you are ready to apply a PCM download the latest

pre-requisite PTF as it contains the very latest code changes

and bug fixes to ensure the PCM applies without any issues,

as customers apply PCMs new issues arise and the pre-

requisites can change even if they have been released

several months prior.

You must also carefully read the cover letter for the PCM,

that is part of the PCMs pre-requisite download, you are

about to apply as it will almost always have a list of

additional individual pre-requisite PTFs you must apply

before you can apply the PCM. This will be followed up by

post apply instructions or additional individual PTFs that

must be applied. This is a very important step and failure to

follow the cover letter can result in serious errors or the

PCM apply to fail altogether.

Also keep in mind that the pre-requisite PTFs required for

the PCM may themselves contain additional pre-requisite

PTFs you will need to apply… utilize the PTF Inquiry

feature in the Cross Application Support module to peruse

the PTF apply history logs to identify all pre-requisite PTFs

that need to be applied, if in doubt go ahead and apply the

PTF again.

The PCM load and apply process can vary in length of time

depending on how many changes are contained on the CD.

It is recommended that you backup your environment (the

PCM programs will prompt you to do so) just in case

something goes awry.

Lastly if you have modified any stock XA programs

(generally not a good idea) you will need to further evaluate

the documentation included with PCM to find out if you

need to upgrade the modified programs.

Aside from modifications if you are running a plain vanilla

install the PCM apply process should go smoothly without

any major issues, however as a precaution if you have

sufficient available disk space you may want to build a

secondary test environment and apply the PCM to it and

then have users perform some preliminary testing in critical

areas to make sure everything is working correctly before

applying the PCM to your live environment. Typically any

program bugs encountered after applying a PCM have a

downloadable PTF fix available. Creating additional

environments is covered in the Cross Application Support

manual.

Database Tuning It used to be that in the not so distant past the IT

programming staff for a company generated all of the

reports, programs and modifications for a given software

system. Because of this dependence on highly skilled

individuals tight control could be exerted over the design of

these programs and modifications ensuring performance of

the system, programs and underlying database did not

needlessly suffer from degradation due to poor process and

coding design.

At first the main performance degradation issues revolved

around users generating and running ad-hoc reports using

third party reporting tools… but with the advent of the

Integrator and Enterprise Integrator XA modules

customization has not only become routine but it has almost

become mandatory to accomplish business goals and tasks.

While Integrator has made customization a virtual piece of

cake at the very same time this sort of customization comes

at a cost of degrading performance especially when the

ability to customize Integrator objects is placed in the hands

of power users who don‟t necessarily understand the

underlying architecture database files and the nuances of the

iSeries platform.

The main issue lies with queries joining together two or

more files. The query optimizer built into OS/400 pre-

processes SQL queries behind the scenes selecting

appropriate files and indexes when they exist or modifying

the SQL statement, but when the optimal files or indexes do

not exist this will cause OS/400 to build temporary access

paths to accommodate the query request.

Remember that Integrator and other types of third party

reporting tools can make good business sense, but that the

high degree of flexibility and customization come at a cost

in performance and wreaking havoc by straying too far from

the baseline functions built into XA. It‟s best to have

competent IT individuals with a good understanding of the

databases and iSeries system work alongside users building

reports and customized objects before they are released for

mass consumption to all users. It is best to look at Integrator

as a tool to help extend the existing XA database or build

onto pieces fitting a specific business need, not to replace

the logic of the system as that path can only lead to failure

and much pain when faced with migrating volumes of

custom code to newer versions of the software.

Utilize Batch Processing

Keep in mind that a report is a report. That is, when trying

to look at or summarize slices of data over large files you

should utilize the batch processing feature built into OS/400

where possible, this way large report jobs can be run in the

background in a subsystem batch while users can do

something else without needing to wait.

Integrator and Enterprise Integrator come with the ability to

create your own Host Jobs and Host Reports. These two

options are tailor made specifically for submitting jobs to

batch subsystems to update large quantities or data or to

generate reports. Make use of these features when it makes

sense to do so and instruct users on how to make use of

these features. With the inherent flexibility of these tools

comes the possibility of swamping a system with a bunch of

interactive requests that would be better served as batch jobs

and reports. Also on some iSeries systems interactive jobs

are limited in processing resources by a governor built into

the system while batch jobs are not, take advantage of batch

processing when it makes sense to do so.

OS/400 System Values

The first place to look when tuning database performance is

the built in settings that are a part of OS/400 operating

system. There are a couple of ways you can set timeout

limits on queries made against the system to help prevent

users from consuming all of the system resources with a

malformed or badly created query. The first is by setting the

OS/400 system value Query processing time limit

QQRYTIMLMT, this value can be set to a number of

seconds ranging from 0 to 2147352578 or *NOMAX which

limits the amount of time that a query can run before the

operating system steps in and ends it.

The second option is to set a similar value as part of creating

an ODBC connecting to your system using the ODBC

driver that comes bundled with Client Access.

If your system has more than one processor you will want to

look into setting the system value for Parallel processing

degree QQRYDEGREE. QQRYDEGREE used in

conjunction with system feature DB2 Symmetric

Multiprocessing for OS/400 allows additional processor

resources to work on optimizing query access paths made to

the database in parallel; naturally this will help to improve

query performance.

Indexes and Logical Files

In this chapter we will focus on ways to get the most bang

for the buck in the least amount of time, since the majority

of un-optimized programs are going to originate from

reporting programs and Integrator objects the quickest way

to see performance gains is to look at the default OS/400

values governing query processing and to examine the

queries and in particular the number of indexes created on

the fly by the query optimizer as these can take long

amounts of time.

The term index is going to be used interchangeably with

logical file as the end result is roughly the same, a file

created over a physical file with specific key fields and

sequence.

Query Optimizer

OS/400 comes with a special database optimizer feature that

resides as a virtual layer between user programs and the

integrated DB2 database optimizing query access made

through SQL statements, OPNQRYF command, APIs,

Query/400 query definitions and ODBC connections. You

don‟t need to do anything to utilize the Query Optimizer as

it is built right into the database system running quietly in

the background without any intervention.

Essentially when any kind of query is issued the query

optimizer steps in and examines the query and the available

methods to access the data to satisfy the query, as part of

that examination the optimizer assigns a score to each

available method then selects the best scoring method to

satisfy the query request. An example of the optimizer at

work would be issuing an SQL statement to sequentially

access a physical file while query optimizer may select to

run the statement over a logical file if it determines that is

the best access plan by using a scoring system.

When working with a single file the query optimization

process is rather straight forward however when running

queries that join together two or more files is the point when

performance can become severely impacted. The worst case

scenario is when the query optimizer is optimizing a query

made upon two or more very large files and cannot find an

index and instead builds a temporary index to satisfy a

request as this is both time and resource consuming for the

system.

The query optimizer itself is a rather complex system and

for more than just simple performance gains a detailed

explanation is way out of the scope of this book. However if

you are going to be writing custom programs using

embedded SQL in or issuing SQL statements directly

against the system you should definitely check out the IBM

“DB2 Universal Database for iSeries Database

Performance and Query Optimization”1 manual for a

complete detailed analysis on optimizing the database and

programs.

SQL Performance Monitor

By now you are probably just how many new indexes are

going to have to be created to accommodate all of these

requests. So when it comes to database tuning an

indispensible tool is the SQL Performance Monitor feature

of iSeries Navigator.

The SQL Performance Monitor runs in the background

collecting detailed data on all of the queries executed on the

system. Later you can run analysis reports on this data and

find out just what programs are hammering the system the

hardest by displaying a variety of performance metrics

collected.

Like any sort of performance monitoring you should have

an established baseline created long before users start

complaining of poor query performance facilitating a knee

jerk reaction. Running a performance monitor collection for

about a week (during non crunch time month end process)

should give you a general idea of the typical system load in

relation to queries.

To start the system collecting performance data simply right

click on SQL Performance Monitors and select new SQL

Performance Monitor. Fill out a few fields,

1http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzajq/r

zajq.pdf

SQL Performance Monitor

The performance monitor will then be started, it‟s important

to note that as the running performance monitor is writing

data to a log file the log can become rather large so you will

want to keep an eye on it or turn off monitoring once you

have gathered sufficient data for analysis.

To create an analysis of the data right click on the

performance monitor you set up and select Analyze. This

brings up a whole host of options, the one we will

concentrate on specifically is “Index Create Information”,

check the appropriate box and click the View Results

button.

Performance Monitor Analysis Options

After a few moments a grid like display will pop up listing

all of the queries along with various pieces of information

about each query. In particular you will want to focus in on

the “Time to create index” column.

In particular be on the lookout for queries that have a very

lengthy “time to create index” value. Once located scroll to

the right and collect the SQL statement and copy it as we

will plug it into the Run SQL statement screen in the next

section.

Run SQL Scripts

iSeries Access also comes with the ability to directly

execute SQL statements. But beyond just simple execution

it also comes with several great tools that allow you to

dissect and analyze the SQL query.

Simply take the SQL script that was copied from the SQL

Performance Monitor and past it into the Run SQL Script

screen. Then select the VisualExplain menu and choose

Explain.

VisualExplain runs the SQL statement through the query

optimizer and produces detailed information and a graphical

listing of the entire query.

From the Action menu select Advisor and it will bring up a

box detailing indexes that the query optimizer suggests you

build to try and optimize this particular query. It details the

file name and the key sequence of the fields to build a new

SQL index or logical file over.

Index Advisor

System Performance Here are a few general system performance tips to help keep

your system running at peak performance. Of course no

amount of tuning is going to help an undersized system that

is running at full capacity. An in depth discussion on

OS/400 performance analysis and tuning is beyond the

scope of this book but visit www.redbooks.ibm.com for

more information.

Generally you can find out how the system is performing at

a glance using the WRKSYSSTS and WRKACTJOB

commands provided with OS/400. For more advanced

performance monitoring you will need the licensed features

provided on the GO PERFORM menu. Also refer to the

chapter on database tuning.

Reorganize the database files to clean out deleted records

from the database tables. XA comes with a reorganize

function built right in the Cross Application Support

module. If you have never run file reorganization before you

will want to schedule a large chunk of downtime to do so as

the reorg requires a dedicated envrionment.

Run the reclaim storage command RCLSTG. The reclaim

storage process cleans up damaged objects and will require

your iSeries system is in dedicated mode.

Be sure to keep current on OS/400 PTFs, in particular

database group and Java group PTFs. You should setup your

system to automatically check for and download new PTFs

as they become available, then review the cover letter for

each downloaded fix and apply as appropriate.

If you are planning to upgrade to XA release 7 it is

important to note that the client architecture has

dramatically changed from prior versions. R7 client

programs have been completely rewritten in Java and make

use of a true client server technology unlike prior Browser

versions. Even though the Java processes have been

continually optimized since initially released they are much

more demanding and require more system resources than

before. So while that AS/400 model 170 may have cut the

mustard before you will need to upgrade to something more

modern. In addition to the above suggestions you there is a

lot of OS/400 settings you will need to make that are

detailed in Infor PTF SH14413.

Additional Resources The MAPICS-L Mailing List is the place to ask questions

and get answers from other XA professionals from all over

the globe. www.midrange.com

Books

Manufacturing expert Dave Turbide has authored the books

on core XA functions with the follwing titles MAPICS

Production Activity Control and MAPICS Planning. These

are the books for learning how to use the shop floor control

and planning modules of XA, Dave has also written several

other books covering computers and MRP based systems for

manufacturers. www.daveturbide.com

Tenney Publications has published books written or co-

authored by former IBM, Marcam and MAPICS employee

Bob Tenney. Several titles are available including the IFM

module, general ledger interfaces, Information Workplace,

Microsoft FRx and Presence programs.

www.tenneypubs.com

Third Party Software

American Viking Enterprises has third party add on

modules for accounting, order entry and sales analysis,

inventory, purchasing and more. www.avef.net

Jacana by Momentum Utilities has a suite of spool file

overlay and data mining reporting tools designed to

specifically work with the iSeries and comes with canned

reports for XA users. www.jacana.com

Paper-Less created the series of shop floor control and

manufacturing execution modules for XA including the

MES, MDCC and LEAP lean manufacturing modules.

www.paperlessllc.com

Fax*Star fax software is available with hooks into XA

providing document faxing for sales orders and quotes and

purchase orders. www.faxstar.com

Vanguard Systems has the Workflow application. Infor also

owns this system but as the writing of this book Vanguard

has consultants that you can hire to help develop Workflow

applications. www.vansystems.com

Infor Channel Partners

DKM Inc covers the Pacific coast region. www.dkminc.com

CISTech covers the Atlantic coast and South East and has

also developed many great XA add on modules for

accounting, general ledger, inventory and RF transactions.

www.cistech.net

TriMin Systems Inc covers Minnesota, Iowa and Missouri.

www.triming.com

Guide Technologies covers the areas of Ohio, Indiana,

Kentucky, Pennsylvania, West Virginia and New Jersey.

www.guidetechnologies.com

Watermark Solutions covers the areas of Texas, the Rocky

Mountains and parts of the south. www.wmerp.com

The System Decision is based out of New Zealand.

www.tsdint.com

Documents

Ma Pics Book