sg245410 PDF

Implementing SSA’s eBPCS
on the AS/400 System
Jaejin Ahn, Nick Camino, Peter Greenfield, Genyphyr Novak
International Technical Support Organization
http://www.redbooks.ibm.com
SG24-5410-00
SG24-5410-00
International Technical Support Organization
Implementing SSA’s eBPCS

on the AS/400 System
December 1999
Take Note!
Before using this information and the product it supports, be sure to read the general information in Appendix G,
“Special notices” on page 417.
First Edition (December 1999)
This edition applies to V4R4 of OS/400, Program Number 5769-SS1 and primarily to the Version 6.1.00 of eBPCS for
AS/400.
Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999. All rights reserved.

Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Chapter 1. Introduction to SSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 SSA profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.2 SSA Portfolio strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.3 eBPCS backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.4 Language support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.5 eBPCS for the AS/400 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Chapter 2. AS/400 introduction . . . . . .. . . . . .. . . . .. . . . . .. . . . . .. . . . . .5

2.1 AS/400 success factors. . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . .. . . . . .5
2.2 AS/400 technology in stride . . . . . . .. . . . . .. . . . .. . . . . .. . . . . .. . . . . .9
2.3 Why eBPCS on an IBM AS/400e. . . .. . . . . .. . . . .. . . . . .. . . . . .. . . . .10
Chapter 3. eBPCS architecture and products . . . . . .. . . . . .. . . . . .. . . . .11

3.1 Mixed-Mode eBPCS . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .11
3.2 Client/Server eBPCS. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .11
3.2.1 First Generation architecture . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .11
3.2.2 Second Generation architecture . . . . . . . . . . .. . . . . .. . . . . .. . . . .13
3.3 Semantic Messaging Gateways . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .17
3.3.1 The benefits of SMGs . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .17
3.3.2 Semantic messages . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .18
3.3.3 Message flow . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .20
3.3.4 External Messaging Interface (EMI) . . . . . . . .. . . . . .. . . . . .. . . . .22
3.3.5 Semantic Data Services . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .25
3.3.6 CHECKEMI . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .29
3.3.7 Available gateways and functions . . . . . . . . . .. . . . . .. . . . . .. . . . .29
3.4 eBPCS development toolsets . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .33
3.4.1 What is ADK? . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .34
3.4.2 Object Development Workbench (ODW) . . . . .. . . . . .. . . . . .. . . . .50
Chapter 4. AS/400 architecture . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .61

4.1 AS/400 integration . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .61
4.2 High Level Machine Interface . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .62
4.3 AS/400 64-bit RISC technology . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .62
4.4 Advanced I/O architecture . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .63
4.5 Single level storage. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .64
4.6 Logical partitioning (LPAR) . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .65
4.7 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .66
4.8 Object-based architecture . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .66
4.9 Integrated relational database (DB2 for AS/400) . . .. . . . . .. . . . . .. . . . .67
4.9.1 Data files. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .67
4.9.2 Database support . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .68
4.9.3 DB2 Universal Database (UDB) . . . . . . . . . . .. . . . . .. . . . . .. . . . .68
4.10 Data management. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .70
4.10.1 Integrated file system (IFS) . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .70
© Copyright IBM Corp. 1999 iii

4.11 System management . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . 71
4.11.1 Management Central . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . 73
4.11.2 System management facilities . . . . . . . . . . . . . .. . . . . .. . . . . .. . 74
4.12 Storage management . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . 75
4.13 Security, user profiles, and authority management . .. . . . . .. . . . . .. . 76
4.14 Work management . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . 77
4.15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . 77
Chapter 5. eBPCS sizing . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 79

5.1 Sizing methodology . . . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 79
5.2 What is a session? . . . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 80
5.3 AS/400 sizing example . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 80
5.3.1 Workload definitions . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 83
5.4 Execution . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 85
Chapter 6. Installation or migration to eBPCS V6.1.00 . . . . . . . . . . . . . . . 87

6.1 Installation documentation for eBPCS and other SSA products . . . . . . . . 87
6.2 General preparations and pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2.1 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.2 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.3 Software keys and other miscellaneous requirements . . . . . . . . . . . 88
6.2.4 Notes on TCP/IP configuration for Full Client/Server eBPCS . . . . . . 89
6.3 Migration to eBPCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.1 Preparing for the conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3.2 Developing an implementation plan . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3.3 Installing the new version of BPCS . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.4 Performing the system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.5 Notes about modified BPCS versions and System/36 BPCS versions93
6.3.6 Notes regarding converting BPCS CD to eBPCS . . . . . . . . . . . . . . . 94
6.3.7 Notes for Millennium toolset users . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4 Outline of conversion steps and program processing . . . . . . . . . . . . . . . . 94
6.4.1 Conversion processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.5 Dealing with problems or questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5.1 Providing the appropriate information . . . . . . . . . . . . . . . . . . . . . . . 98
6.5.2 Retaining your job log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.5.3 Conversion checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.6 Conversion programs overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.6.1 Conversion libraries reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.6.2 Conversion drivers reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.6.3 Incremental files libraries built by conversions . . . . . . . . . . . . . . . . 101
6.6.4 Incremental BPCS files libraries built for each step . . . . . . . . . . . . 102
Chapter 7. Database and the integrated file system (IFS) . . . . .. . . . . .. 103

7.1 AS/400 DBMS: DB2/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 103
7.1.1 File types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 104
7.1.2 Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 104
7.2 Integrated file system (IFS) . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 106
7.3 SQL concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 108
7.3.1 Relational database and terminology . . . . . . . . . . . . . . . .. . . . . .. 109
7.3.2 SQL terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 110
7.3.3 Types of SQL statements. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 111
7.4 DB2 for AS/400 catalog views . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 112
7.5 DB2 Universal Database (UDB) for AS/400 . . . . . . . . . . . . . . .. . . . . .. 114
iv Implementing SSA’s eBPCS on the AS/400 System

Chapter 8. Printing . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .117
8.1 AS/400 printing . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .117
8.1.1 AS/400 printer attachment. . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .117
8.1.2 AS/400 controllers and devices . . . . . . . . . . . .. . . . . .. . . . . .. . . .119
8.1.3 AS/400 output queue. . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .119
8.1.4 Printer files . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .120
8.1.5 Spooled files . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .120
8.1.6 Printer writer . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .123
8.1.7 Remote system printing. . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .124
8.1.8 Sharing printers. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .134
8.1.9 Using AS/400 NetServer shares . . . . . . . . . . .. . . . . .. . . . . .. . . .139
8.1.10 Printing using Telnet Printer Pass Through . .. . . . . .. . . . . .. . . .145
8.1.11 Printer emulation . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .145
8.1.12 Sharing a PC printer . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .146
8.2 Spool management . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .147
8.2.1 Creating output queues . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .147
8.2.2 Starting AS/400 printer writers. . . . . . . . . . . . .. . . . . .. . . . . .. . . .153
8.2.3 Work with Output Queues . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .156
8.2.4 AS/400 Printer menu . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .157
Chapter 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .159

9.1 AS/400 security architecture . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .159
9.1.1 Security levels. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .159
9.1.2 System integrity . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .159
9.2 AS/400 security system values . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .160
9.3 AS/400 users and groups . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .160
9.3.1 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .160
9.3.2 Special authorities. . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .160
9.3.3 User classes . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .160
9.3.4 Group profiles . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .161
9.3.5 Limited capability . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .161
9.4 AS/400 object protection . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .162
9.4.1 Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .162
9.4.2 *PUBLIC authority . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .163
9.4.3 Authorization lists . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .163
9.4.4 Adopted authority . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .163
9.4.5 Audit journal . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .164
9.5 eBPCS and security . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .164
9.5.1 Controlling access to eBPCS . . . . . . . . . . . . .. . . . . .. . . . . .. . . .165
9.5.2 AS/400 security access . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .166
9.5.3 Concepts of eBPCS security . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .166
9.5.4 Implementing standard eBPCS security . . . . .. . . . . .. . . . . .. . . .167
Chapter 10. eBPCS work management . . . . . . . . . . . . . . . . .. . . . . .. . . .173

10.1 Memory management concepts . . . . . . . . . . . . . . . . . . . .. . . . . .. . . .173
10.1.1 Storage pool configuration. . . . . . . . . . . . . . . . . . . . .. . . . . .. . . .173
10.1.2 Expert Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . .174
10.1.3 Time slice end system value . . . . . . . . . . . . . . . . . . .. . . . . .. . . .174
10.1.4 Dedicated night time or weekend processing. . . . . . .. . . . . .. . . .174
10.1.5 Isolating main storage for each batch thread . . . . . . .. . . . . .. . . .175
10.1.6 Machine pool faulting . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . .175
10.1.7 Activity levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . .175
10.1.8 Purge parameter characteristics . . . . . . . . . . . . . . . .. . . . . .. . . .176
v
10.1.9 Job accounting. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 176
10.1.10 System values . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 177
10.2 Basic memory configuration . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 179
10.2.1 Mixed-Mode green screen . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 179
10.2.2 Traditional batch work . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 179
10.2.3 First Generation Client/Server configuration. . . .. . . . . .. . . . . .. 180
10.2.4 Order Entry batch posting . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 181
10.2.5 Second Generation Client/Server configuration .. . . . . .. . . . . .. 183
10.3 Program security . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 184
10.4 End-user queries . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 184
10.5 Disk utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 184
10.5.1 Deleted records . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 184
10.5.2 Job logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 185
10.5.3 System journals . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 186
10.5.4 System history logs and problem logs . . . . . . . .. . . . . .. . . . . .. 186
10.5.5 User and device message queues . . . . . . . . . . .. . . . . .. . . . . .. 187
10.5.6 IPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 187
10.5.7 Reclaim spool storage . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 188
10.6 BPCS processing options . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 188
10.6.1 Application flag settings . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 188
10.6.2 BPCS Order Entry tuning . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 189
10.6.3 MSGID versus MSGCON . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 189
10.6.4 Generic BPCS considerations . . . . . . . . . . . . . .. . . . . .. . . . . .. 189
Chapter 11. Performance tuning and management . . . . . . . . .. . . . . .. 191

11.1 Developing a methodology . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 191
11.2 Establishing a base line . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 193
11.3 Platform balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 194
11.4 Capacity guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 194
11.5 Performance analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 196
11.5.1 AS/400 performance tools . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 196
11.5.2 Client analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 196
11.5.3 Network and communication analysis tools . . . . . . . . . .. . . . . .. 198
11.6 Application tuning techniques . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 201
11.6.1 Order Entry performance . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 201
11.6.2 eBPCS system values . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 201
11.6.3 Workstation interface setup considerations . . . . . . . . . .. . . . . .. 203
11.7 Application development options . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 204
11.7.1 BPCS compilation options . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 204
11.7.2 Program optimization . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 205
11.7.3 Remove Observability from production programs . . . . . .. . . . . .. 205
11.7.4 Private authorizations . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 205
11.8 DB2/400 management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 206
11.8.1 Access path maintenance . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 206
11.8.2 Disk utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 207
11.9 DB2/400 SQL tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 208
11.9.1 AS/400 database query optimization tools . . . . . . . . . . .. . . . . .. 209
11.9.2 Additional DB2/400 optimization techniques . . . . . . . . .. . . . . .. 217
Chapter 12. Logical Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 13. SSA product global support structure . . . . . . . . . . . . . . . . . 223

13.1 HelpLine's role in product support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
13.2 SSA International HelpLine organization overview . . . . . . . . . . . . . . . . 223
vi Implementing SSA’s eBPCS on the AS/400 System

13.3 Purpose of the SSA International HelpLine . . . . . . . . . . . . . . . . . . . . . .224
13.4 HelpLine responsibilities and activities . . . . . . . . . . . . . . . . . . . . . . . . .224
13.5 Helpline incident reporting policies and procedures. . . . . . . . . . . . . . . .224
13.6 Regional HelpLine office locations and languages . . . . . . . . . . . . . . . .225
13.7 HelpLine availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
13.7.1 Weekday support policy: Monday through Friday . . . . . . . . . . . . .225
13.7.2 Weekend support policy: Friday through Sunday and holidays . . .226
13.8 SSA International HelpLine product responsibilities . . . . . . . . . . . . . . .227
13.8.1 Technical teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
13.8.2 Product teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
13.9 Incident escalation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
13.10 When not to use the SSA International HelpLine . . . . . . . . . . . . . . . . .229
13.10.1 Examples of questions outside the scope of HelpLine . . . . . . . . .230
13.10.2 Obtaining product knowledge: SSA public education classes . . .230
13.10.3 Obtaining platform knowledge: AS/400 education classes . . . . . .231
Chapter 14. Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

14.1 Where to begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
14.1.1 OGS Online: SSA's OnGoing Support Web site. . . . . . . . . . . . . . .233
14.1.2 Hints and tips for searching OGS Infobase . . . . . . . . . . . . . . . . . .235
14.1.3 Logging your question using OGS . . . . . . . . . . . . . . . . . . . . . . . . .236
14.2 Questions about modifications to BPCS . . . . . . . . . . . . . . . . . . . . . . . .237
14.3 Methodology for faster software and end-user problem resolution . . . . .238
14.3.1 Internal coordination on site . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
14.3.2 Determining product maintenance responsibility . . . . . . . . . . . . . .239
14.3.3 Third-party modifications to core eBPCS . . . . . . . . . . . . . . . . . . . .239
14.3.4 Checking the run documentation and help text . . . . . . . . . . . . . . .240
14.3.5 Checking for already known resolutions to the problem on OGS . .240
14.3.6 What to do if you find a BMR that describes your problem. . . . . . .244
14.3.7 Ordering a completed BMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
14.3.8 Logging new issues with HelpLine to resolve your problem . . . . . .248
14.4 Gathering information and documentation . . . . . . . . . . . . . . . . . . . . . . .250
14.4.1 Identifying eBPCS Client/Server jobs on the AS/400 system . . . . .250
14.4.2 Determining if you are using a First or Second Generation BPCS .251
14.4.3 First Generation DFS jobs: SSATCP and PGM-ALAUNCH . . . . . .251
14.4.4 Second Generation OMS: NWI and PGM-NWICSTUB. . . . . . . . . .253
14.4.5 Identifying problems that fall between BPCS and OS/400 . . . . . . .258
14.5 BMR change management for BPCS version 6.x . . . . . . . . . . . . . . . . .260
14.5.1 What a BMR is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
14.5.2 Where to find the listing of BMRs pulled into your explosion build .261
14.5.3 What to do with a BMR: Testing your software fix . . . . . . . . . . . . .263
14.5.4 Testing multiple BMRs: Five new BMRs in two weeks . . . . . . . . . .266
14.5.5 What to do if problems still exist after a BMR is applied . . . . . . . .268
14.5.6 Moving the approved BMR to production . . . . . . . . . . . . . . . . . . . .268
Chapter 15. Tips and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271

15.1 Same database for Mixed-Mode and Second Generation Client/Server 271
15.1.1 Preliminary requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
15.1.2 Linking the environments to one database . . . . . . . . . . . . . . . . . .273
15.1.3 Environment setup for DFS applications . . . . . . . . . . . . . . . . . . . .277
15.1.4 Environment setup for green-screen applications . . . . . . . . . . . . .278
15.1.5 Environment setup for OMS applications . . . . . . . . . . . . . . . . . . . .279
15.1.6 Consideration for NLVs and DFS green-screen user libraries . . . .279
vii
15.1.7 Subsystem and job queue configuration. . . . . . . . . . . . . . . . . . . . 279
15.1.8 Updating the client PC software . . . . . . . . . . . . . . . . . . . . . . . . . . 281
15.1.9 Testing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
15.1.10 Naming conventions used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
15.2 BPCS client installation and management . . . . . . . . . . . . . . . . . . . . . . 283
15.2.1 AS/400 NetServer setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
15.2.2 BPCS client initial installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
15.2.3 BPCS client fix installation and management . . . . . . . . . . . . . . . . 288
15.3 eBPCS and journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Appendix A. TCP/IP basic installation and configurations . . . . . . . . . . . . 293

A.1 TCP/IP servers and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
A.2 Network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
A.3 Installing TCP/IP core applications on the AS/400 system . . . . . . . . . . . . . . 294
A.4 TCP/IP configuration using a command line interface . . . . . . . . . . . . . . . . . . 297
A.4.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
A.4.2 Creating a TCP/IP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
A.4.3 Creating a TCP/IP host table entry . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
A.4.4 Configuring a local domain and host name . . . . . . . . . . . . . . . . . . . . . .303
A.4.5 Starting TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
A.4.6 Stopping TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
A.4.7 Verifying the TCP/IP connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
A.5 TCP/IP configuration using Operations Navigator . . . . . . . . . . . . . . . . . . . . . 308
A.5.1 Accessing the TCP/IP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
A.5.2 Configuring a line for TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
A.5.3 Changing TCP/IP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
A.5.4 Configuring host table entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
A.5.5 Configuring the domain and host name . . . . . . . . . . . . . . . . . . . . . . . . .324
A.5.6 Configuring a TCP/IP route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
A.5.7 Starting and stopping TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
A.5.8 Verifying a TCP/IP connection (ping) . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
A.6 Connecting through a gateway or different network. . . . . . . . . . . . . . . . . . . . 331
A.6.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
A.6.2 Route configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
A.7 Starting an FTP session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Appendix B. AS/400 Client Access Express for Windows . . . . . . . . . . . . . 335

B.1 Client Access Express for Windows (5769-XE1) . . . . . . . . . . . . . . . . . . . . . . 335
B.1.1 Client Access Express for Windows functions . . . . . . . . . . . . . . . . . . . . 335
B.1.2 Client Access for Windows Family (5769-XW1). . . . . . . . . . . . . . . . . . .337
B.1.3 Client Access Base Family (5769-XY1) . . . . . . . . . . . . . . . . . . . . . . . . .337
B.1.4 AS/400 Client Access Extended Family. . . . . . . . . . . . . . . . . . . . . . . . .338
B.1.5 Obtaining Client Access Express for Windows . . . . . . . . . . . . . . . . . . . 338
B.1.6 License information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
B.2 Installing Client Access Express on the AS/400 system . . . . . . . . . . . . . . . . 338
B.3 Installing Client Access Express on the PC . . . . . . . . . . . . . . . . . . . . . . . . . . 341
B.3.1 Installation sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
B.3.2 Installation types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
B.3.3 Installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
B.3.4 Silent installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
B.3.5 Selected setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
B.3.6 Creating a custom install image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
B.3.7 Reinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
viii Implementing SSA’s eBPCS on the AS/400 System

B.4 Uninstalling Client Access Express from the PC. . . . . . . . . . . . . . . . . . . . . . 350
B.5 Service Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Appendix C. AS/400 Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . 353

C.1 New packaging of Operations Navigator. . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
C.2 Using Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
C.2.1 Managing AS/400 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
C.3 Operations Navigator functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
C.3.1 Basic Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
C.3.2 Job Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
C.3.3 Configuration and Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
C.3.4 Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
C.3.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
C.3.6 Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
C.3.7 Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
C.3.8 Integrated File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
C.3.9 AS/400 NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
C.3.10 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
C.4 Function Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Appendix D. Complementary products. . . . . . . . . . . . . . . . ...... ....... 393

D.1 AS/400 licensed program products and features . . . . . . . . ...... ....... 393
D.1.1 AS/400 Operating System (OS/400) features. . . . . . . ...... ....... 393
D.1.2 AS/400 licensed program products. . . . . . . . . . . . . . . ...... ....... 394
D.2 SSA partner products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... ....... 394
Appendix E. AS/400 advanced technology. . . . . . . . . . . . . . . . . . . . . . . . . . 395

E.1 Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
E.2 Web serving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
E.3 Lotus Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
E.4 Integration with Windows NT Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
E.5 Extended Adaptive Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
E.5.1 Planning for Extended Adaptive Cache . . . . . . . . . . . . . . . . . . . . . . . . 403
E.5.2 Extended Adaptive Cache Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 403
E.6 Managed availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
E.7 Business Intelligence solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
E.7.1 AS/400 enabling technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
E.7.2 Business Intelligence solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
E.7.3 Business Intelligence tools and applications. . . . . . . . . . . . . . . . . . . . . 405
E.8 e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
E.8.1 Characteristics of a successful e-business . . . . . . . . . . . . . . . . . . . . . . 406
E.8.2 Integration of e-business tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
E.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Appendix F. eBPCS supported languages . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Appendix G. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Appendix H. Related publications . . . . . . . ...... ....... ...... ....... 421

H.1 IBM Redbooks publications. . . . . . . . . . . . ...... ....... ...... ....... 421
H.2 IBM Redbooks collections. . . . . . . . . . . . . ...... ....... ...... ....... 421
H.3 Other resources . . . . . . . . . . . . . . . . . . . . ...... ....... ...... ....... 421
H.4 Referenced Web sites. . . . . . . . . . . . . . . . ...... ....... ...... ....... 422
ix
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
IBM Redbooks evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
x Implementing SSA’s eBPCS on the AS/400 System

Figures
1. AS/400 success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Change of AS/400e processor technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Workstation Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. First Generation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. SDO example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Message flow - Detailed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. External Messaging Interface (EMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. External Messaging Interface (EMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Semantic Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Software development life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. ADK architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. Development Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
14. Repository menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15. Top-Down Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16. Bottom-Up Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Sample Actions panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
18. ODW definition facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
19. ODW Repository overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
20. Application Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
21. Host message files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
22. Client string tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
23. Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
24. Uploading definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
25. Server generation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
26. Client generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
27. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
28. ODW process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
29. AS/400 system - An integrated system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
30. AS/400 Advanced application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
31. Advanced I/O architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
32. AS/400 Logical Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
33. Clustered configuration with a partitioned node . . . . . . . . . . . . . . . . . . . . . . . . 66
34. Integrated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
35. Peak hour sizing graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
36. IBM ERP Sizing Center flow model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
37. Product Support on OGS - System requirements . . . . . . . . . . . . . . . . . . . . . . 88
38. TCP/IP configuration - *LOOPBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
39. TCP/IP configuration - WRKTCPSTS *IFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
40. TCP/IP configuration - Host Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
41. TCP/IP configuration - Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
42. Product Support on OGS - Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
43. The eBPCS conversion process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
44. eBPCS conversion flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
45. Database function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
46. Database libraries selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
47. Run SQL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
48. File systems function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
49. AS/400 host printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
50. AS/400 printer attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
© Copyright IBM Corp. 1999 xi

51. Data streams and printer devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
52. Create Printer File - Printer device type parameter. . . . . . . . . . . . . . . . . . . . . 121
53. Data stream transforms when printing to an IPDS AFP (*YES) printer. . . . . .122
54. Host print transform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
55. Remote system printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
56. TCP/IP LPR and LPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
57. WRKSPLF shows the spooled file number (View 3) . . . . . . . . . . . . . . . . . . . . 125
58. Sending a spooled file to a remote host using LPR . . . . . . . . . . . . . . . . . . . . 126
59. LPR command when remote system is set to *INTNETADR . . . . . . . . . . . . . 126
60. Operations Navigator - TCP/IP servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
61. Properties option on the LPD server context menu . . . . . . . . . . . . . . . . . . . . 130
62. LPD Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
63. Changing the LPD server to start automatically . . . . . . . . . . . . . . . . . . . . . . . 131
64. Start option on the LPD server context menu . . . . . . . . . . . . . . . . . . . . . . . . .132
65. Using WRKACTJOB to view the active LPD servers . . . . . . . . . . . . . . . . . . . 133
66. Stop option on the LPD server context menu . . . . . . . . . . . . . . . . . . . . . . . . .134
67. AS/400 NetServer in Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . 135
68. New file share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
69. Creating a printer share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
70. Browse Output Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
71. Browse Printer File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
72. Define a printer share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
73. Finding AS/400 NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
74. Windows 98 network logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
75. Windows NT network logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
76. Map Network Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
77. Map Network Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
78. Available AS/400 NetServer shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
79. Installing a printer driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
80. Connect to printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
81. Add Printer Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
82. Telnet Printer Pass Through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
83. AS/400 NetServer - Sharing a PC printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
84. Create Output Queue (CRTOUTQ) display (Part 1 of 2) . . . . . . . . . . . . . . . . 148
89. The Create Device Description display (Part 1 of 3) . . . . . . . . . . . . . . . . . . . . 152
90. Create Printer Device display (Part 2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
91. Create Printer Device display (Part 3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
92. STRPRTWTR prompt command (Part 1 of 2). . . . . . . . . . . . . . . . . . . . . . . . .154
93. Additional information for the STRPRTWTR command (Part 2 of 2) . . . . . . . 154
94. Start Remote Writer (STRRMTWTR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
95. Example of Work with All Output Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
96. Example of option 5 on Output Queue EBPCSLCLQ . . . . . . . . . . . . . . . . . . .157
97. AS/400 Printer menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
98. Object authority elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
99. eBPCS security flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
100.System Parameters display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
101.Security Master Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
102.Add User Profile dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
103.Security Master Maintenance - Products A . . . . . . . . . . . . . . . . . . . . . . . . . . 168
xii Implementing SSA’s eBPCS on the AS/400 System

104.eBPCS Object Security Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
105.Adding a new object security record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
106.Security Master Maintenance - Program Object Name . . . . . . . . . . . . . . . . . 170
107.Group Maintenance options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
108.OEA menu container in Full Client/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
109.CEA batch posting parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
110.Installation display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
111.Performance analysis areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
112.ODBC Data Source Administrator Tracing tab dialog . . . . . . . . . . . . . . . . . . 197
113.Start Database Monitor display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
114.First level text of job log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
115.Second level text of job log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
116.HelpLine’s role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
117.HelpLine policies and procedure on OGS OnLine . . . . . . . . . . . . . . . . . . . . . 225
118.OGS main page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
119.OGS OnLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
120.OGS main page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
121.Product Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
122.Problem resolution process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
123.OGS problem resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
124.OGS BMR query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
125.OGS BMR details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
126.WRKACTJOB in a BPCS Client/Server environment . . . . . . . . . . . . . . . . . . 251
127.Option 1 from the Work With Job display for an SSATCP job . . . . . . . . . . . . 252
128.Job description settings to produce a detailed job log . . . . . . . . . . . . . . . . . . 253
129.PC client screen when the World has launched on the server . . . . . . . . . . . 254
130.Job log from an OMS 2.4.1 World launching a BPCS application . . . . . . . . . 254
131. Start Newi Daemon (STRNWID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
132.Display Program Information (DSPPGM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
133.Restore Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
134.Mixed-Mode data area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
135.Client/Server data area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
136.INLIBL data area - Mixed Mode (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
137.INLIBL data area - Mixed Mode (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
138.INLIBL data area - Client/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
139.Display Job Queue Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
140.Display Routing Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
141.LICPGM menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
142.Installed License Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
143.Confirm Installation selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
144.Specify installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
145.Install Licensed Programs - TCP/IP connectivity utilities. . . . . . . . . . . . . . . . 297
146.Ethernet network example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
147.Work with Communication Resources display. . . . . . . . . . . . . . . . . . . . . . . . 299
148.Create Line Description (Ethernet) display . . . . . . . . . . . . . . . . . . . . . . . . . . 300
149.CFGTCP menu display - Work with TCP/IP Interfaces . . . . . . . . . . . . . . . . . 300
150.Add TCP/IP Interface (ADDTCPIFC) display. . . . . . . . . . . . . . . . . . . . . . . . . 301
151.CFGTCP menu display - Work with TCP/IP Interfaces . . . . . . . . . . . . . . . . . 301
152.CFGTCP menu display - Work with TCP/IP Host Table Entries . . . . . . . . . . 302
153.Add TCP/IP Host Table Entry (ADDTCPHTE) display . . . . . . . . . . . . . . . . . 302
154.CFGTCP menu display - Work with TCP/IP Host Table Entries . . . . . . . . . . 302
155.Change TCP/IP Domain (CHGTCPDMN) display . . . . . . . . . . . . . . . . . . . . . 303
156.Work with Active Jobs display - QTCPIP job . . . . . . . . . . . . . . . . . . . . . . . . . 304
xiii
157.TCP/IP Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
158.End TCP/IP (ENDTCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
159.End TCP/IP Server (ENDTCPSVR) display . . . . . . . . . . . . . . . . . . . . . . . . . . 306
160.PING LOOPBACK display - Successful ping messages . . . . . . . . . . . . . . . . 306
161.PING RMTSYS display - Successful ping messages . . . . . . . . . . . . . . . . . . .307
162.PING RMTSYS—Unsuccessful ping messages. . . . . . . . . . . . . . . . . . . . . . . 307
163.Operations Navigator protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
164.Selecting the interface type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
165.Selecting the hardware resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
166.Choosing a Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
167.Creating a New Line Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
168.Ethernet Line Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
169.TCP/IP Interface Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
170.TCP/IP Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
171.TCP/IP Routing additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
172.Add Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
173.Advanced Routing Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
174.Defining servers to start when TCP/IP is started . . . . . . . . . . . . . . . . . . . . . .316
175.Interface start options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
176.New TCP/IP Interface Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
177.Host Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
178.Advanced Host Domain Information settings . . . . . . . . . . . . . . . . . . . . . . . . .319
179.Host Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
180.TCP/IP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
181.Port Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
182.Servers to Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
183.SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
184.Context menu - Properties option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
185.TCP/IP Host Table entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
186.Context menu - Properties option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
187.Host Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
188.Context menu - New Interface option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
189.TCP/IP Interface wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
190.Start TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
191.Stop TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
192.Ping from Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
193.Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
194.Two Ethernet LANs connected with routers example. . . . . . . . . . . . . . . . . . .331
195.CFGTCP menu display - Work with TCP/IP Routes. . . . . . . . . . . . . . . . . . . . 332
196.Add TCP/IP Route (ADDTCPRTE) display . . . . . . . . . . . . . . . . . . . . . . . . . . 332
197.CFGTCP menu display - Configure TCP/IP Applications . . . . . . . . . . . . . . . . 333
198.Change FTP Attributes (CHGFTPA) display . . . . . . . . . . . . . . . . . . . . . . . . . 334
199.Work with Licensed Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
200.Install Licensed Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
201.Display Software Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
202.Display Software Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
203.Client Access Express Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
204.Upgrade Client Access Express for reinstallation. . . . . . . . . . . . . . . . . . . . . . 348
205.Type of Upgrade selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
206.Start Upgrade settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
207.iPTF Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
208.AS/400 Operations Navigator - Component Selection window . . . . . . . . . . . 353
209.AS/400 system context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
xiv Implementing SSA’s eBPCS on the AS/400 System

210.General page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
211.Data to Collect page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
212.Stop Collection Services window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
213.Collection Services Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
214.Collect Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
215.Run Command dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
216.Basic Operations function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
217.Send Message dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
218.Printer Output desktop icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
219.Modifying Printer Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
220.Working with printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
221.Job Management function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
222.Server Jobs management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
223.Include option dialog box for Server Job management . . . . . . . . . . . . . . . . . 365
224.Configuration and Service Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
225.Hardware Inventory list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
226.Network function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
227.TCP/IP actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
228.TCP/IP Properties window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
229.AS/400 NetServer context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
230.Internet functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
231.IBM HTTP Server for AS/400 Web browser configuration. . . . . . . . . . . . . . . 371
232.Summary of security recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
233.Security function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
234.Create authorization list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
235.Authorization list details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
236.Audit Policy Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
237.Security Policy Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
238.Users and Groups function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
239.Create a new user based on an existing user profile. . . . . . . . . . . . . . . . . . . 376
240.Database function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
241.Database libraries selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
242.Run SQL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
243.File Systems function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
244.File systems management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
245.New Folder dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
246.Copying files in Windows Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
247.Copying files into a folder using the Paste button . . . . . . . . . . . . . . . . . . . . . 382
248.Renaming a folder in the file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
249.New share button. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
250.Delete button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
251.Setting permissions for file system objects . . . . . . . . . . . . . . . . . . . . . . . . . . 384
252.New file share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
253.Creating a file share. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
254.Browsing the IFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
255.Text Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
256.AS/400 NetServer share context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
257.Creating a share from file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
258.Monthly backup properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
259.Function Availability dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
xv
xvi Implementing SSA’s eBPCS on the AS/400 System
Tables
1. SSA global divisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Logging on to the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Logging on to the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Clicking the Applications button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Starting the BPCS Client/Server application . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Starting the BPCS Client/Server application . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. External Message Interface APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. SDO type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. SDO types and text representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Semantic Message Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Action types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12. Required object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
13. SSA Object Development Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
14. String tables and message files comparison table . . . . . . . . . . . . . . . . . . . . . . 55
15. Sizing questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
16. eBPCS conversion libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
17. Conversion driver programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
18. Incremental files libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19. Conversion databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20. Relationship of system terms to SQL terms . . . . . . . . . . . . . . . . . . . . . . . . . . 110
21. DDL and DML SQL statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
22. Dynamic SQL and miscellaneous statements . . . . . . . . . . . . . . . . . . . . . . . . 112
23. LPR command parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
24. Example printer queue names for some common printers . . . . . . . . . . . . . . 128
25. Standard eBPCS user profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
26. Summary of system utilization for the week of xx/xx/xx . . . . . . . . . . . . . . . . . 176
27. Interactive job breakdown by user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
28. System journals and journal receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
29. Prefixes used in Client Access ODBC driver error messages . . . . . . . . . . . . 198
30. Comparison of optimization analysis methods . . . . . . . . . . . . . . . . . . . . . . . . 216
31. Languages by country name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
32. Language by AS/400 code page (SBCS). . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
33. Language by AS/400 CCSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
34. Language and ETOA table mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
© Copyright IBM Corp. 1999 xvii

xviii Implementing SSA’s eBPCS on the AS/400 System
Preface
The SSA eBPCS Implementation for AS/400 redbook contains a collection of
knowledge derived from existing documentation and from SSA consultants and
AS/400 professionals who have experience with eBPCS and the AS/400 system.
This redbook is designed to assist SSA eBPCS customers, eBPCS consultants,
business partners, and IBM technical and service representatives. It targets
professionals who are directly involved with implementing a total business
solution consisting of AS/400 hardware, OS/400, eBPCS solutions, DB2/400
database, and supplemental solution products. This redbook provides a detailed
guide that explains specific tasks associated with implementing eBPCS on the
AS/400 system.
In this redbook, you explore the following topics:

• Introduction to SSA
• Introduction to the AS/400 system and architecture
• eBPCS product line and architecture
• eBPCS installation and configuration
• Sizing
• Database
• Printing
• Security
• eBPCS work management and performance tuning
• eBPCS in an LPAR environment
• Problem determination and resolution
• Helpful hints, tips, and techniques
Plus, this redbook addresses support structures, and supplemental products from
SSA partners in the Portfolio strategy.
The team that wrote this redbook

This redbook was produced by a collaboration between SSA and the International
Technical Support Organization, Rochester Center. It was produced from
documentation that exists within the SSA organization, and by a team of SSA and
IBM specialists. Much of the documentation remains anonymous, but the team
that edited the existing documentation and wrote the new parts are listed here.
Jaejin Ahn is a Senior IT Specialist for the AS/400 system at the ITSO Rochester
Center. He has 16 years of experience at IBM. He is a member of the application
development team and is responsible for ERP solutions on AS/400 systems.
Peter Greenfield is an AS/400 specialist currently working for SSA in the

Solutions Management Group. During seven years at SSA, he worked in the field
implementing SSA's solutions for many of their largest customers in Europe.
Then he moved to Chicago to manage the AS/400 Performance Center in their
R&D facility. He is currently a Product Manager for AS/400 and Shared Service
Centers which concentrates all of his skills learned both with SSA and with
previous companies.
Genyphyr Novak is an AS/400 specialist currently working for SSA as a System

Software Engineer on client/server run-time development. Previously, she was a
senior member of the SSA HelpLine working as a consultant on the AS/400
© Copyright IBM Corp. 1999 xix

Technical Team. She has been with SSA for two years. Before moving to Chicago
to work for SSA, she worked as a consultant at IBM Rochester on the Backup
Recovery and Media Services (BRMS) development team. While working with
that team, she helped to write A Practical Approach to Managing BRMS/400,
SG24-4840.
Nick Camino is the Global Technology Manager at SSA, specializing in the

AS/400 platform. Nick has enabled many of SSA's largest clients around the
world to be more competitive utilizing joint IBM and SSA solutions. Nick is a
frequent speaker at SSA users groups covering various AS/400 topics and SSA
service offerings. Prior to working in the field, Nick spent three years in R&D
developing and managing a variety of projects and teams. Nick has been with
SSA for six years and has 10 years experience in the IBM midrange market. Prior
to SSA, Nick did consulting work with the AS/400, S/38, and S/36 in the Midwest
marketplace.
Thanks to the following people for their invaluable contributions to this project:
Phil Hall
Mark Larson
Jennifer Watkins
SSA Inc.Headquarters (Chicago)
Mike Breitbach
Eric Warne
Adam Tumas
Dan Sundt
IBM Rochester
Ryan Rhodes
Jenifer Servais
International Technical Support Organization, Rochester Center
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Please send us your

comments about this or other Redbooks in one of the following ways:
• Fax the evaluation form found in “IBM Redbooks evaluation” on page 441 to
the fax number shown on the form.
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Send your comments in an Internet note to redbook@us.ibm.com
xx Implementing SSA’s eBPCS on the AS/400 System

Chapter 1. Introduction to SSA
SSA (System Software Associates, Inc.) is dedicated to the assessment, design,
development, implementation, and support of business solutions. SSA enhances
customer competitiveness through continuous innovation and integration of "best
of industry" software, services, and technology. SSA has been providing solutions
for manufacturing and industrial sector companies since 1981. Building on the
experience of serving key vertical industries within the industrial sector of the
mid-market, SSA is the enterprise resource planning industry's first portfolio
solutions provider. The new SSA Portfolio of products, functionality, and services
allows SSA to provide the right solution to the right market at the right time. Plus
it has the ability to change as customer demands and requirements change. The
company now offers, and services, tailored solutions for specific industries that
seamlessly integrate SSA's full eBPCS product suite with best-of-market
applications from third-party vendors.
1.1 SSA profile

SSA is focused on the requirements of mid-market and divisions of tier-one
companies, within targeted vertical industries. Such industries in particular
include automotive supply, consumer packaged goods (including fast-moving
consumer goods, food and beverage, and consumer electronics), pharmaceutical
or specialty chemical, and general manufacturing.
With more than 6,500 implementations at over 18,000 global sites, SSA
represents one of the world's largest installed bases of a single product,
addressing integrated processes, discrete and mix-mode manufacturing, supply
chain management, global financial application, and electronic commerce. SSA is
truly a global organization. There are SSA customers in 90 countries. This is also
confirmed by the geographic revenue breakdown of the company's business:
Approximately 35% from North America, 37% from Europe, Middle East, and
Africa, 18% from Asia Pacific, and 10% from Latin America.
Table 1. SSA global divisions
North America Latin America Europe, Middle Asia Pacific

East, and Africa
5 SSA principal 4 SSA principal 8 SSA principal 9 SSA principal

offices offices offices offices
4 affiliate offices 4 affiliate offices 8 affiliate offices 12 affiliate offices
9 support centers 8 support centers 16 support centers 21 support centers
1.2 SSA Portfolio strategy

SSA is committed to using the full complement of SSA Portfolio resources,
including the company, eBPCS software, strategic partnerships, and service
offerings, to deliver the right best-of-market solutions to each customer. The SSA
Portfolio is architected to evolve as industry and customer demands evolve, and
delivers individually tailored solutions that are flexible enough to satisfy its
customers' dynamic demands, without repetitive installation and integration
costs. The SSA Portfolio strategy also delivers systems that provide a
© Copyright IBM Corp. 1999 1

market-defining competitive advantage by leveraging industry-specific,
best-practice models and extensions of business processes across applications.
The SSA Portfolio approach is ideally suited to the mid-market (companies with
annual revenues of $50M to $1Billion) and divisions of Fortune 100 companies. It
focuses on these companies’ need for ERP systems to run their business
operations more efficiently, and to share mission-critical information rapidly
across the supply chain, from suppliers to customers. This new approach allows
SSA's customers to compete effectively, and to enhance their business
opportunities and revenue potential.
1.3 eBPCS backbone

SSA's eBPCS is a comprehensive set of integrated client/server applications that
address the core system needs of industrial sector enterprises on a global scale.
SSA has 6,500 client implementations. This is one of the world's largest installed
bases of a single product that addresses integrated process, discrete and
mixed-mode manufacturing, supply chain management, global financial
applications, and electronic commerce. eBPCS meets the key regulatory,
financial, and business practice requirements in every industrialized country
worldwide and is available in 20 languages. eBPCS is fully European currency
(euro) and Year 2000-compliant.
Leveraging SSA's domain experience in multi-mode manufacturing and supply

chain management, SSA and eBPCS bring added functionality to the key market
segments it serves. SSA continues to extend and enhance its core eBPCS
product with features and functions that benefit customers and project its
leadership position in those markets.
SSA's eBPCS product suite is a strong ERP core with a flexible infrastructure that
allows customers to easily interoperate specialized business processes from
third-party vendors. This allows customers to modify, extend, or replace
SSA-developed functionality with ease. Working closely with its partners, SSA
uses its own Semantic Message Gateway (SMG) and Adapter technologies as
the driving forces that enable fast, smooth integration and seamless
interoperability of partner technology. SSA serves as a single point of contact for
service and support of its full eBPCS product suite and third-party functionality
from the company's partners.
eBPCS is available on these platforms: IBM AS/400, UNIX HP 9000 with an

Oracle or Informix database, and Windows NT. eBPCS incorporates significant
new functionality and extended capabilities, including:
• Euro currency
• Electronic commerce
• Semantic Message Gateways (SMGs)
• Supply Chain Management enhancements
• Database extensions - Trade Funds Management
• Windows 98 and Windows NT clients support
2 Implementing SSA’s eBPCS on the AS/400 System

1.4 Language support
SSA has strong representation on an international scale, with software sales in
100 countries around the world. It serves 1,000 global customers from offices in
North America, Europe, the Middle East, Africa, South America, and Asia Pacific.
eBPCS is provided in 25 languages, which are split into two-tiers. Tier-1

languages are available at the time of general release of the product, and tier-2
languages are available as needed by customers. For further details of the
supported languages, refer to the Appendix F, “eBPCS supported languages” on
page 411.
1.5 eBPCS for the AS/400 system

Reliability, durability, and simplicity make the AS/400 system a favorite in the
manufacturing environment. The AS/400 system endures because IBM ensures
that the AS/400, the OS/400 operating system, and DB2 Universal Database are
scalable, extensible, and accessible. The price performance of the AS/400e
series is unmatched in the industry, while the security and technical advances
built into the AS/400e make it an ideal platform for e-business and other supply
chain demands.
IBM and SSA are engaged in several cooperative projects that will extend the
capabilities of eBPCS on the AS/400e servers. Such projects include: supply
chain extensions, e-business initiatives, joint global services, and solution
financing.
Introduction to SSA 3
Chapter 2. AS/400 introduction
This chapter describes the key concepts of the AS/400 system. One of the key
factors that differentiates the AS/400 system is the level of hardware and
software integration. For example, in a UNIX environment, the customer is
required to select software components from different vendors (operating system,
database software, system management software, and so on). They are also
required to integrate them to build a working environment for eBPCS.
The AS/400 system takes a different approach. The operating system (OS/400)
includes a complete range of "licensed programs" (middleware) and offers the
highest level of integration. By effectively reducing the extent of integration
required to be performed during implementation, the AS/400 system strategy
minimizes implementation costs and increases reliability. The AS/400 system
also provides a customer with the highest level of "ease-of-use" in today's
market. The initial ease of implementation and the ongoing ease of use,
combined with its reliable integration, makes the AS/400 system a
high-performing, low-cost business solution.
2.1 AS/400 success factors

The AS/400 system has a long and successful history worldwide. There are more
than 600, 000 AS/400 systems installed in over 150 countries. There are also
more than 30,000 business applications worldwide, including over 2,700 for
e-business. The reason for the success of the AS/400 system is founded in six
basic factors, which are presented in Figure 1, and described in the following list:
Figure 1. AS/400 success factors
• Architecture
The AS/400 system has a layered architecture that is divided into the actual
user interface (OS/400) and a Technology Independent Machine Interface
(TIMI). This architectural concept has allowed the AS/400 system to undergo
several fundamental technology changes, while protecting the customer’s

investment in information technology. The transparent migration of user
applications to 64-bit RISC-based hardware technology is a recent example of
the benefit of the AS/400 architecture.
• High level of integration
The AS/400 system offers the highest integration of both its hardware and
software components. Hardware, microcode, the operating system, and IBM
middleware are all tightly interlaced to allow maximum exploitation of all
available computing resources. Integration of Input/Output Processors (IOPs)
and Direct Access Storage Devices (DASD) yields valuable benefits (for
example, an extremely high level of reliability and availability). The AS/400
system's availability techniques range from using an Uninterruptible Power
Supply (UPS), RAID-5 protection, and DASD mirroring, all the way to
continuous operation based on a dual-system availability solution. Other
benefits from this kind of integration are proactive. Some of these benefits
include remote hardware and software maintenance, detailed and informative
diagnostic aids for problem determination and monitoring, and future
projection of system performance.
The following items are some of the features integrated into the AS/400
system:
– System availability:
• Battery Backup Unit (BBU)
• Continuously Powered Mainstorage (CPM)
• Uninterruptible Power Supply (UPS)
• Protection against system failures
• Backup database servers and systems
• Mirroring and RAID-5 (both at minimal performance cost)
• Menu-driven backup and recovery
• Journaling
• Commitment Control
• Auxiliary Storage Pools (ASPs)
• Save While Active function
• Clustering support
– Standard ease-of-use functions for:
• System customization
• Automatic procedures, start-up programs, and so on
• System values
• System tuning (managing memory, disk)
– Easy system management through:
• Easy hardware configuration and reconfiguration
• Autoconfiguration of devices
• Integrated file system (IFS) accessible through a standard AS/400
interface (DB2/400, PC, or UNIX file system)
• Minimal database installation, management, and operations activity
• Simple menu-driven functions
• Balancing data across disk units
• Native performance optimization of DB2/400

– Database management system integrated with OS/400:
• No additional cost for database software
• Integrated database administration tools and automated self-managing
database administration functions
• Excellent performance through microcode-imbedding, fine tuned with
hardware and OS/400
• Support for parallel database operations, symmetric multiprocessing
(SMP), and parallel I/O processing
• With V4R4 release, DB2 Universal Database (UDB) for AS/400 now
supports the storing, managing, and indexing of all forms of information,
including binary objects (such as spreadsheets, word processing
documents, and multimedia objects) within the database
• Interoperability and connectivity
The AS/400 system offers a wide range of communication capabilities and
functions that enable the AS/400 to communicate with IBM and non-IBM
systems.
The wide range of communication protocols supported by the AS/400 system
include:
– SNA (APPC, APPN, and HPR)
– TCP/IP
– OSI
– NetBIOS
– IPX/SPX
– AnyNet
The AS/400 system supports the following protocols and networks:
– IDLC (ISDN Data Link Control)
– IBM Token-Ring Network (IEEE 802.5 and 802.2)
– T1/E1/J1 and Fractional T1 Networks (high bandwidth)
– Asynchronous
– Binary Synchronous
– Synchronous Data Link Control (SDLC)
– X.21
– X.25
– Ethernet Version 2 or IEEE 802.3
– FDDI LANs
– ATM LANs
OS/400 has the following communication facilities:
– TCP/IP support
– X.21 Short Hold Mode (SHM) and Multiple Port Sharing (MPS)
– Remote workstation support
– 3x74 Remote Attach
– 5x94 Remote Attach
– Intersystem Communications Function
– Advanced Peer-to-Peer Networking (APPN)
– Dependent Logical Unit Requester (DLUR)
– Advanced Program-to-Program Communication (APPC)
– SNA Upline Facility to System/370 IMS and CICS hosts
– Binary Synchronous Communications Equivalence Link (BSCEL)
– ICF retail communications support
AS/400 introduction 7
– ICF finance communications support
– Non-ICF Finance Communications Support
– SNA Distribution Services (SNADS)
– SNA Primary Logical Unit 2 Support
– SNA/Management Services Transport
– Distributed Relational Database Support
– Object Distribution Facility (ODF)
– Display Station Pass-through
– Distributed Data Management (DDM)
– SNA Pass-through
– IBM Network Routing Facility (NRF) Support/400
– Autodial Support
– 3270 Device Emulation
– 3270 SNA API Support for IBM 3278 Model 3, 4, and 5
– ISDN Support
– 5394/5494 SNA Backbone Support
– File Transfer Support
– Interactive Terminal Facility (ITF)
– SAA Common Programming Interface for Communications (CPI-C)
– IPX/SPX Communications
– ATM LAN Emulation
The AS/400 system also supports the following functions:
– Kernel Threads
– Java Virtual Machine (JVM)
– Lotus Domino for AS/400
– Integrated file system (IFS)
– Web Serving
– Integrated PC Server (IPCS) or Integrated Netfinity Server (INS) running
the following server environments:
• Microsoft Windows NT Server
• IBM Firewall for AS/400
• IBM Warp Server
• Novell NetWare
• Client/server capability
The AS/400 system can operate with almost any client in any communication
environment. It can attach the following clients of choice:
– Microsoft Windows 3.1, Windows 3.11, Windows 95, Windows 98, and
Windows NT
– OS/2
– Macintosh
– UNIX (IBM-AIX, HP-UX, SUN-SPARC)
– Linux
• Scalability
AS/400e servers cover a wide range of performance capacities. For the
eBPCS environment, this means the AS/400e server can support from a few
users to thousands of users. Most of the AS/400e server models are
field-upgradable to more powerful models. This degree of customer
investment protection is exceptional. It is one of the contributing factors to the
AS/400e system's low cost of ownership in the long term.

• Price and performance
Many independent analysts have confirmed that the AS/400 system
represents a cost effective platform in the long run. The AS/400 system's
extensive integration yields significant cost advantages, high availability, easy
system management, and significant investment protection. This has been the
basis for its ten-year success in the dynamic world of information technology.
The AS/400 system delivers high computing performance at a low cost of
ownership and, therefore, scores high in customer satisfaction.
2.2 AS/400 technology in stride

The AS/400 system delivers tremendous growth over its product line. Single level
storage (SLS) makes it possible to completely change the underlying hardware
without affecting AS/400 applications and operating systems. Just as the AS/400
system continues to deliver tremendous capacity gains in its product line, it is
usually the first to bring new technology to the market.
In 1997, the 12-way AS/400 system was delivered using Power PC A35
microprocessors. Known as Apache technology, the Power PC A35
microprocessors provided a 4.6x growth.
In September 1998, the 12-way AS/400 system was delivered using the Power
PC A50 microprocessor. Known as code name Northstar, the Power PC A50
microprocessors nearly doubled the high-end capacity. This set of processors
provided the fourth generation since the AS/400 system’s inception in 1988, with
64-bit AS/400 Power PCs microprocessors.
This growth and implementation of new technology is possible because of the

AS/400 TIMI layer. TIMI allows the AS/400 system to incorporate significant new
hardware technology more quickly and transparently than any other vendor or
platform.
Figure 2 shows this change of hardware processor technology and previews what
is planned in future generations. More details can be found in "Logical
Partitioning: Divide and Conquer", by IBM Chief Engineer Frank G. Soltis, in the
January 1999 edition of NEWS/400 magazine.
V
Fu ture G iga P ro ce ss or DE
IN
N
I CO
1999+ P ulsar N S I L
I
ED 1.94X
IV ER 12 -W a y A 50 P P C A pp lications
EL 1998 6
D (N orth star) 4
ED O S /400
ER 12 -W a y 4.59X
L IV 1997 B
DE A 35 P P C i TIM I
D t
E RE 2.87X s H ardwa re
L IV 1996
DE
Figure 2. Change of AS/400e processor technology
AS/400 introduction 9
2.3 Why eBPCS on an IBM AS/400e
Migration to client/server and network-centric computing models has suffered a
number of high profile and expensive failures. The cost of building and
maintaining complex hardware and applications has risen dramatically. With
these facts in mind, the history of reliability, stability, and low maintenance costs
of the IBM AS/400 system become very attractive. Companies have come to
realize that total cost of ownership, not just hardware costs, is what is really
important with information systems.
SSA’s eBPCS on the AS/400 system helps to solve many of these problems. The
integrated operating system requires less setup and maintenance than other
hardware configurations. Therefore, a smaller staff is needed.
The other advantage of eBPCS on the AS/400 system is SSA’s coexistence

strategy. This feature allows a gradual transition from Mixed-Mode eBPCS to
Client/Server eBPCS. This approach reduces the risk of an "all or nothing"
conversion required by many other application software vendors.

Chapter 3. eBPCS architecture and products
This chapter discusses the architecture of the eBPCS Mixed-Mode and
Client/Server products, Semantic Message Gateways (SMG's), and the eBPCS
Development Toolset.
The Mixed-Mode and Client/Server products are both created from the same
application Repository. In fact, the same Repository is used for the AS/400, UNIX,
and NT products. Therefore, the functionality is identical. The only difference is
the presentation to the end user.
3.1 Mixed-Mode eBPCS

Mixed-Mode eBPCS is so called because it has two different architectures. The
majority of the product uses the standard green-screen text based (5250
emulation) representation to present information to the user. Two products,
Configurable Enterprise Accounting (CEA), and parts of Outbound Logistics
Management (OLM), use a client/server representation.
These First Generation Client/Server products can be described as fat client and
are common to both the Mixed-Mode product and the Client/Server product. They
are discussed in the following section.
3.2 Client/Server eBPCS

Two client/server architectures are used in the Client/Server version of eBPCS.
The majority of the product uses the Second Generation Client/Server, which is a
thin client representation. This consists of a messaging layer called Object
Messaging Server (OMS), and a presentation layer known as Object Presentation
Services (OPS).
The other two products (CEA, and part of OLM) use the First Generation
Client/Server as mentioned above.
From the AS/400 technical point of view, both products are true client/server or
Batch processes. Therefore, they can utilize the AS/400e Server base models
without adding the optional interactive feature card.
3.2.1 First Generation architecture

The underlying technology used for the First Generation Client/Server is known
as Distributed Function Services (DFS). This is a message-based system, which
facilitates communications between the client PC and the host AS/400 system.
All messages are channeled through a daemon, which talks to a specific TCP/IP
port. The daemon is submitted to batch, where it waits for a connection call from
a client. When this arrives, the client takes control of the daemon, and the
daemon re-submits another instance of itself to wait for the next client. The
daemon for First Generation Client/Server operation is started by submitting the
following command:
SBMJOB CMD(CALL PGM(TCLILIB/ALAUNCH) PARM('5000')) JOB(TCPIPJOB)

JOBD(TCLILIB/TCPIPJOBD) JOBQ(BPCSTCPIP) INLLIBL(TCLILIB BPCSF QGPL)

In this statement, TCLILIB is the TCPIP library name specified on the installation
panel, and BPCSF is the name of your eBPCS files library where the eBPCS
message files are stored. If multiple environments are running, you can use a port
number other than port 5000.
The client PC has to be configured to talk to the same TCP/IP port on which the
daemon is waiting. This is done via the eBPCS Session Manager Workstation
Settings. This panel allows the configuration of all Client/Server products, both
First and Second Generation.
The options used for First Generation are as follows:

• Transport API is WINSOCK.
• Objects library (BPCSO), Database library (BPCSF), and User library
(BPCSUSR) all refer to those in use in the environment being configured.
• The Port Number here should match the one that was used to submit the
ALAUNCH daemon.
• The TCP/IP address of the host AS/400 system.
Figure 3 shows the details of the Workstation Settings display.
Figure 3. Workstation Settings
When a CEA or OLM icon is selected from the Session Manager, a message is
sent to the TCP/IP Port specified on the client. If a session has not been started
already for this client, the user is prompted for a user profile and password. This
must be a valid AS/400 user profile, and the user must be enrolled in eBPCS
security for the environment being accessed.

The ALAUNCH job that is in a listening state is connected to the client. It then
submits another instance of itself ready for the next client.
The client sends a message to the host program WDKCOM, which calls the
appropriate server program. Messages containing application data are then
transferred between the client and the server using a series of specialized data
stores known as Transaction Data Repositories (TDRs).
The job stack for the user session contains both messaging and application
programs. The CPR programs (programs that begin with CPR) are the interface
between the client and the server, which are common to all of the products in
CEA and OLM. The application specific programs pass messages (data) through
these programs back to the client. Figure 4 shows the First Generation
architecture.
Client
Client program copies request

data to message log.
msg.data
log
copy of Send and Receive

to and from Client
WDKCOM receives incoming data

and passes it to CPR077B
WDKCOM
CPR077B passes message

copy of all Send and
CPR077B to CPR004B, which copies
Receive messages
messages to ZQN Log file.
ZQN CPR004B
Log File
Server
Server Response
TDR TDR
Figure 4. First Generation architecture
3.2.2 Second Generation architecture

eBPCS Second Generation uses SSA's Object Messaging Service (OMS) on the
server, and Object Presentation Service (OPS) on the client PC, to facilitate the
eBPCS Client/Server functionality.
3.2.2.1 Object Messaging Service (OMS)

OMS is know by many names, including: middleware, an Object Request Broker
(ORB), and a communications transport mechanism. The closest to the real
description of OMS is an ORB. OMS, in basic terms, provides the following
services:
eBPCS architecture and products 13

• A runtime support framework for Cooperative Business Objects (CBOs)
• Message routing between OMS servers
The SSA OMS server is supported on the AS/400 system, UNIX, and Windows
NT Server platforms.
3.2.2.2 Object Presentation Service (OPS)

OPS is a superset of OMS. For example, it includes OMS and adds specific
functionality. The additional functionality that OPS provides is presentation layer
support. This presentation layer support is what the end user sees as the
containers and application views while running eBPCS. The SSA OPS client is
supported on Windows 95, Windows 98, and Windows NT workstation.
3.2.2.3 eBPCS Second Generation application walk-through

This section describes what is taking place on the client and server as an eBPCS
Second Generation Application is started, used, and ended.
Logging on to the server

When the user enters the required logon information in the Welcome to BPCS
dialog box and presses the Logon button, the events shown in Table 2 occur in
the order given.
Table 2. Logging on to the server
OPS client Server connection daemon
The OPS client attempts to locate the server

on the network. If unsuccessful, processing
of the logon request stops.
The OPS client sends the log-on information

to the listening connection daemon on the
server.
The daemon checks the client version. If

there is a mismatch, an error code is sent
back to the client.
The daemon then verifies that the user has

access to the server and, if successful, starts
an OMS server under the users profile and
passes the connection to this OMS server.
An invalid user verification causes the
connection daemon to send an error code
back to the client, where upon processing, it
stops.
At this stage of the log-on process, the server connection daemon is no longer
involved, and returns to waiting for a new client connection event. From this point
onward, OPS on the client now interacts with the OMS server (Table 3 on page
15).

Table 3. Logging on to the server
OPS client OMS server
After a successful initialization, OMS sends

a message the client, informing the client
that it is ready to process messages.
The OPS client enables the Applications

button on the Welcome to BPCS dialog box.
At this point, both the OPS client and the OMS server are connected to each
other via a TCP/IP socket.
Clicking the Applications button

When the user clicks the Applications button on the Welcome to BPCS dialog
box, the interaction between the OPS client and the OMS server occurs as
explained in Table 4.
Table 4. Clicking the Applications button
The ODOGopher CBO processes the

message. This involves locating the
CONFIG* file and then creating a reply to the
message that contains the entries in this file.
Once the reply is constructed, it is sent back
to the client.
The OPS client processes the reply data and

populates the Select Database dialog box
with the data.
*: The CONFIG and ODOCFG files are normally located in the OMS runtime library
At this point, the user selects a database, which maps to a BPCS environment.
After selecting a database, the user navigates through the application containers
until the desired BPCS application is located.
Starting the BPCS Client/Server application

When the user double-clicks on the chosen application, for example Item Master,
which is BPCS program INV100, the client and server events shown in Table 5
occur.
Table 5. Starting the BPCS Client/Server application
The OPS client sends a NewInstance

message to the OMS server CBO called
ODOProcess. Included in this message is
the chosen database and the name of the
BPCS program to start.
The ODOProcess CBO performs verification

of the selected database name. The next
step is to start BPCS. The ODOProcess
CBO reads the starter program entry from
the ODOCFG file. This value is normally
BPCSMENU and starts this program.

After the OMS server has started BPCSMENU, there are now three processes
running: the OPS client on the PC, the OMS server, and BPCSMENU on the
server. Each of these processes is explained in Table 6.
Table 6. Starting the BPCS Client/Server application
OPS client OMS server BPCSMENU
The OMS server waits for

BPCSMENU to startup and
send a ready message.
BPCSMENU starts up,

performs the normal BPCS
initialization. BPCS menu
then calls program SYS500.
SYS500 connects back to

the OMS server, and sends
the BPCS logo screen.
The OMS server passes the

message to the
ODOProcess CBO.
ODOProcess sends a
message to SYS500 to
navigate BPCS to the BPCS
Main Menu.
SYS500 moves to the main

menu, and sends this
information to the OMS
server.
ODOProcess fills in the

reply, specifying the name of
the BPCS program to run,
which is INV100 in this
example.
SYS500 calls INV100.
INV100 sends a message to

the OMS server. This
message contains the
display data for this
application.
The OMS server packages

the data from INV100 and
forwards it to the client.
The OPS client formats the

data, populates the INV100
panel with this data, and
finally displays the panel to
the user.
From this point, any application interaction on the OPS client is sent as a
message to the OMS server, which in turn forwards the message to the BPCS
application. When the BPCS application has data to return, it sends the data to
the OMS server, which then passes it back to the OPS client. The OMS server is,
in effect, acting as a multiplexer. If the user starts another BPCS application (up

to a maximum of five concurrent applications), while the first is still running, the
OMS server performs the routing of the message from the OPS client to the
correct BPCS server application.
3.3 Semantic Messaging Gateways

This section introduces the basics of Semantic Messaging Gateways (SMGs),
including:
• External Messaging Interfaces
• Semantic Data Services
• Using SMGs
eBPCS contains a number of gateway objects that provide access to eBPCS

functionality. External applications use the Semantic Messaging Gateways to
communicate with the gateway objects, enabling eBPCS to do work on their
behalf. Semantic messages allow a two-way exchange of data to take place
between an external application and eBPCS. The SMGs are an integral
component of eBPCS business object capability for application interoperability.
SMGs provide a flexible, release independent integration capability between

eBPCS and legacy systems and other mission-critical enterprise applications.
SMGs are a set of high-level integration tools that provide a published, secure,
and reliable way of integrating applications with eBPCS. They also address the
needs of clients for an efficient means to inter-operate across eBPCS and
existing procedural and object applications.
Through SMGs, applications can inquire against and update eBPCS data. SMGs
can also publish changes in specific eBPCS data to any number of subscribing
external applications. SMGs offer high-level integration beyond that of an
interface. Traditional procedural Application Programming Interfaces (APIs)
demand rigid conformity to fixed sequences and often force recompilation of
external applications. On the contrary, SMGs allow external applications to
subscribe to events within eBPCS. SMGs offer a variety of solutions designed to
facilitate the integration of applications, and build upon the same object
messaging used within eBPCS.
3.3.1 The benefits of SMGs

Many clients rely on a combination of eBPCS and non-eBPCS systems in running
their business. Often, it is necessary for an external system to be notified of
changes made to certain data as a result of eBPCS processing. For example, you
may want to maintain two customer databases, one in eBPCS and the other in
another external system, where both must be consistent with one another. In this
situation, the external system must be notified if, for example, an eBPCS operator
adds a new customer. In the preceding example, why not allow the external
application direct access to the eBPCS database?
The reason you do not want the external application to have direct access to the
eBPCS database is because there are dangers in adopting this approach. First,
by allowing the external application direct access to the underlying database, it
becomes closely coupled to data structures that are liable to change. Changes
made to the eBPCS data structure, however small, can result in a
disproportionate amount of change to the external application or system. The

other, and perhaps more imminent danger of direct access by an external system
results in the bypassing of eBPCS application logic and validation, which
jeopardizes data integrity and consistency.
The use of the Semantic Messaging Gateways provides a solution to the problem
of communication between eBPCS Client/Server and external systems without
compromising data integrity or consistency. This is made possible because the
SMGs provide an interface to eBPCS. This interface is a standard, consistent
mechanism constant over the lifetime of eBPCS. Using it removes dependency
on the underlying Data Model. Also, if a system error occurs during the
processing of an eBPCS transaction, you may lock the record upon returning to
eBPCS. To correct this, unlock the record using Client/Server applications.
The SMGs ensure that all new data passes the eBPCS application logic and
validation, and therefore, maintains data integrity. Moreover, the semantic nature
of the interface allows clients to migrate and take advantage of additions to the
message content.
SSA delivers the following advantages with SMGs:

• The means that the external application communicates with eBPCS
Client/Server using the SMG
• The eBPCS Client/Server gateway objects, each class having a public
interface accessible using the SMGs programming interface
3.3.2 Semantic messages

Semantic messages are user-readable and constructed of self-describing data.
Each item of data contains information about its own type and has a label
describing the data item in business terms, for example:
[Description, String]"CompanyName"
[AddressLine1, String]"500 W. Madison"
The key requirement when communicating with semantic data messages is

consistency across all systems as to what the labels describe. For example, the
descriptions CompanyName or AddressLine1 should mean the same to all
systems. These labels remain constant, and systems can continue to
communicate even when changes are made to the underlying data structure.
Individual data items, known as Semantic Data Objects (SDOs), have these
optional properties:
• Label
• Value of a specific type
• Data type of value (defaults to String)
• Container to hold other data items

Root SDO = [ ]
Comment = “**** Login”
[ ]"**** Login"
{
[Message]"Logon"
[Object]"|SecurityGw"
{
[Data]
Containers {
[User]"YOURNAME"
[Password]"xx"
[LibraryListEntry]"SMGUSO"
[Database]""
}
}
}
Literals or Labels = Data inside the brackets [ ]

Values of a specific type = Data inside the quotes “ “
Figure 5. SDO example
In the example in Figure 7, there are eight SDOs, which include a root SDO, with
a comment describing the purpose of the SDO and seven other SDOs. These
seven SDOs each have a label as a means of identification: Message, Object,
Data, User, Password, LibraryListEntry, and Database. The Message SDO has
the value Logon and a type string. Note that, in this example, the type is not
specified because it is not required. The Data SDO is an example of a container,
since it contains the SDOs User, Password, LibraryListEntry, and Database. The
preceding example is an SDO that can be sent to any machine to log on to
eBPCS going through the security gateway object.
You can manipulate SDOs using the Semantic Data Services (SDS) commands.
For example, using the SDS APIs, a sending object can add additional
parameters to a message without affecting the target object. Semantic Data
Services are part of the eBPCS object-oriented (OO) infrastructure. They are
provided with the Semantic Messaging Gateways to allow direct communication
between external applications and objects encapsulating data and business
processes within eBPCS.
Using the SDS, you can add new data items to messages when eBPCS
functionality is enhanced without having to change or redefine existing interfaces.
Your system only need to change when it is able to use this new information.
Semantic Messages, SDOs, and the Semantic Data Services are described more
fully in 3.3.5, “Semantic Data Services” on page 25, and 3.3.5.1, “Semantic Data
Objects” on page 25.
eBPCS contains a number of gateway objects that provide access to the

functionality of eBPCS products. External applications use the Semantic
Messaging Gateways to communicate with the gateway objects enabling eBPCS
to do work on their behalf. Semantic messages allow a two-way exchange of data
to take place between an external application and eBPCS. Within the SMG, these

gateway objects are defined as objects that can receive inbound messages, such
as Create, Change, Delete, Destroy, and Query. They are also defined as objects
that send outbound messages in response to notification received as a result of
certain events taking place within eBPCS Client/Server.
Delete implies a "soft" delete, meaning that the record is inactivated. Destroy
implies a "hard" delete, meaning that the record is completely removed from the
database.
3.3.3 Message flow

There are two types of messages within the SMGs: Inbound and Outbound.
Figure 6 illustrates the message flow described in this section.
• Inbound messages are sent to eBPCS from an external application.
• Outbound messages are generated by eBPCS for an external application.
Inbound Gateway Objects

Messages:
• Create
• Change Customer
• Delete/Destroy Gw
• Query
• Etc...
eBPCS
Item
Outbound Gw
Notifications:
• Created Invoice
• Changed Gw
• Deleted/Destroyed
• Etc...
Figure 6. Message flow
3.3.3.1 Message scenario

A message sent to a gateway object to perform a process is similar to a user
doing the same task from a terminal. Removing the distinction between a user
and an external application presents a clear model for the way eBPCS handles
changes and events. The scenario follows this process:
1. The external application sends an inbound message to a gateway object to
perform processing.
2. The external application receives notification when any activity carried out by
eBPCS operators or other external applications changes the state of objects in
which an interest is registered.
3. The external application can then Query the object for information about its
state.
20 Implementing SSA’s e BPCS on the AS/400 System

eBPCS
Inbound Gateway eBPCS operator at

Message eBPCS operator
SDO eBPCS an eBPCS
at an terminal
eBPCS
Application terminal
External Outbound External

Application Message Notifier
Query
Message Entity
Figure 7. Message flow - Detailed
3.3.3.2 Inbound messages

External applications use SMGs to request eBPCS to work on their behalf, for
example, to create a new customer order or to post an inventory transaction.
Standard messages, such as Create, Change, Delete, and Destroy, change the
state of the eBPCS application data. A particular object representing either a
process or an entity within eBPCS handles inbound messages, for example:
CustomerGateway, CustomerOrderGateway, or InventoryGateway.
Another type of message is the Query message. The Query message is a

particular type of inbound message that does not cause the data within eBPCS to
change. The external application sends a Query message to find out the current
value of an object's properties. You may want to use a Query message because
your external application requires information about the current state of a
gateway object. The external application may do this after it has received
outbound notification indicating that a particular object has changed.
3.3.3.3 Outbound notifications

eBPCS generates outbound notifications in response to operations performed by
eBPCS operators on terminals, or in response to other inbound messages. An
external application can receive these notifications by requesting notification of
events from eBPCS. This is known as registering interest. Registering interest is
the process of requesting notification of events from eBPCS.
To reduce the number of messages sent to an external application, outbound

messages are only triggered by business processes modeled within the scope of
the SMG. For example, if the SMG maintains a customer, you receive messages
when a customer is created, changed, or deleted, provided you have registered
an interest in when these events occur.
After the external application receives notification that an event has occurred in
eBPCS, the external application can then send an inbound Query message to
obtain the customer instance data as described in the previous section on
inbound messages. Outbound notifications typically relate to entity events, such
as Created, Changed, Deleted, and Destroyed.
All outbound messages from gateway objects are received by an instance of the
Custom Notifier class. The Custom Notifier is the bridge between the gateway
object and the external application.

3.3.3.4 Outbound error messages
Besides outbound notifications, error messages are also sent to the external
application. These error messages may be due to a number of factors, such as:
eBPCS validation error
An error message may be returned stating that the transaction cannot
complete due to an eBPCS error. For example, the error message may
state that you are trying to change an immutable property or have not
sent in a value for a required field.
Message sent incorrectly
The SDO that you sent may not be in the proper format. For example,
you may be missing a container or quotes around a value.
Configuration issue
Your configuration may be incorrect.
3.3.3.5 Event notification scope

The gateway object targeted by an inbound message may interact with multiple
entity objects. These interactions may result in one or more outbound messages
to the custom notifier object and create unnecessary network traffic. Outbound
messages are designed to notify external applications that events occurred in
eBPCS. The external application must then query the gateway to retrieve the
attributes and, if necessary, determine the change.
3.3.3.6 Multiple notifications for the same gateway

When notifications are sent to the CustomerOrderGw, it can receive an additional
notification for the creation, change, or deletion of a note, which is part of the
customer object. This means that when you register interest in the maintenance
of a customer through the CustomerOrderGw, you receive a message indicating
that a customer order is created or changed. You can then query the customer
order for the notes that were created or changed.
3.3.4 External Messaging Interface (EMI)

The External Messaging Interface (EMI) is the means by which external
applications communicate with a Semantic Message Gateway. It is part of the
OMS architecture. With EMI, communication between the external application
and eBPCS is understood on a World-to-World basis. A World is a job under
which all SMG and BPCS objects run. This job is defined in a WORLDCFG file,
which allows you to define how the job will run. You can run multiple Worlds,
which allows you to connect to various BPCS databases, or allow jobs to run in
different subsystems and memory. The OMS World is also used in BPCS, and,
when in BPCS, the World is what a user is given when they log into BPCS.
Launch the application window. The World job calls the proper job in BPCS and
launches the underlying BPCS application that the SMG is invoking.
The external application can specify which World it wants to connect with and
start that World if it is not already running.

Note
A daemon job does not have to be waiting when the calling application is
already running on the AS/400 system. If the external application is coming to
the AS/400 system from another machine, an OMS daemon listening on a
TCP/IP port should be started so that SMG can launch the World.
The external application can also receive messages from eBPCS objects.
Objects within eBPCS invoke SMGs (when "interest" is registered in a type of
BPCS transaction in a configuration file) to send updates to the external
application, as if it is a BPCS user connected to a World talking to a client PC
connection. The external application can take the incoming messages and
update an external file, or call another application which is external to BPCS.
The External Messaging Client library and the EMI Adapter are supplied with the
SMGs. The external application must bind with an External Messaging Client
library that contains application program interfaces (APIs) called by the
application. Binding is the process of attaching the library to the external
application so the objects in that library can be used in the external application.
The external application then uses the APIs in this library to communicate with
the EMI Adapter.
Using an adapter within the eBPCS World and providing supporting code for the
EMI APIs and the inter-session communications protocol enables the
World-to-World communication to take place. The EMI Adapter allows the base
SMG/eBPCS code to treat the external World as an extension of itself, using the
World name element of the object to route messages through the EMI Adapter to
the external World (Figure 8). The EMI layer within the adapter accepts
messages from the external World and presents them for processing. The EMI
Adapter is transparent to the external application.
External
Application
External World World

Messaging Name EMI Name eBPCS
Client Library Adapter World
bounded with the API API
external applcation
Figure 8. External Messaging Interface (EMI)
To use the External Messaging Interface, the External Messaging Client library
must be bound into the external application. The External Messaging Client
library contains the APIs called by the external application when communicating
with the SMGs. When the external application calls one of these APIs, a
connection is made through a communications mechanism to the EMI Adapter.
The External Messaging Server object is configured to "listen" for an incoming

message on the appropriate communications channel (Figure 9 on page 24). The
incoming message contains all the information required by the EMI Adapter to
enable it to route the message to the target object. The message consists of the

target object name, an SDO containing the message parameters, and a Semantic
Data Object (SDO) in which to place the message reply. The EMI Adapter uses
another API to pass the message to the target object. Refer to 3.3.5.1, “Semantic
Data Objects” on page 25, for more information about SDOs.
Target
External Object
Application SDO with
Parameters
SDO for the
reply API
External External Gateway
Messaging Messaging Object
Client Library Server
Bounded with Object
External
Application
Figure 9. External Messaging Interface (EMI)
3.3.4.1 External Messaging Client library

The External Messaging Client library is bound into the external application and
contains APIs. The CHECKEMI section in the Semantic Message Gateway
Programmer's Reference, which can be found on OGS and also available on
CD-ROM with SMG product, provides an example of how to use the various API
commands in an external application. Table 7 lists some of the commands.
Table 7. External Message Interface APIs
API Description
EmiInit Initializes EMI and sets a global variable to contain the

application's World name and optionally opens a log file.
EmiDeinit De-initializes EMI.
EmiBuildObjectName Builds an object name given the instance, class, and World
names.
EmiSetTimeOut Allows the application to specify how long EMI waits for
certain operations.
EmiStartListening Allows an asynchronous application to maintain a listening

socket for event-driven connections.
EmiStopListening Removes the listening socket created by the

EmiStartListening API.
EmiConnect Allows an application to connect to a specified World or to

its parent application.
EmiDisconnect Closes down a connection created either by EmiConnect

or EmiCompleteClientConnection.
EmiDisconnectAndShutdown Closes down a connection and shuts down the World on

the other side of the connection.
EmiSend Sends a message using a connection to another World.
EmiPost Posts a message using a connection to another World.
EmiPeekMessage Tells the application if a message is available for a given

connection.

API Description
EmiGetMessage Gives the application a message for a given connection, or

waits until a message is available.
EmiSendReply Sends a reply in response to a message.
3.3.5 Semantic Data Services

The previous section introduced you to the concept of Semantic Messages, in
which you can specify message parameters using Semantic Data Objects
(SDOs). This section looks at Semantic Messages, SDOs, and the Semantic Data
Service APIs provided with the SMGs for manipulating the SDOs, including:
• The elements of an SDO
• The text representation of an SDO
• Using the SDS APIs
You can use SDOs to represent the layout of a view for use by the SMGs for
configuration information. Many of the classes in the eBPCS Class library also
use the hierarchical structures of SDOs in their instance data to represent data
relationships.
3.3.5.1 Semantic Data Objects

A Semantic Data Object has the following properties, all of which are optional:
• Label
• Value of a specified type
• Container that can contain other SDOs
Consider an SDO that represents the structure of a company as shown in Figure

10.
Label: Company
Value: Acme Inc
Type: String
Label:Phone Label: Employee Label: Employee

Value: 12345 Value: Bill Value: Ted
Type: Long Type: String Type: String
Label: Married Label: Age Label: Married Label: Age

Value: FALSE Value: 21 Value: TRUE Value: 45
Type: Bool Type: Long Type: Bool Type: Long
Figure 10. Semantic Data Objects
The Company SDO contains a Phone SDO and two Employee SDOs. Each
Employee SDO contains an Age SDO and a Married SDO. Note that SDOs are
identified by the use of SDO labels. The structure of the Company SDO reflects
the structure of a company. (A company has a phone number and a number of
employees). Similarly, an employee has an age and can be married. The
following example is the same SDO in written format:

[]
{
[Company,String]"Acme Inc"
{
[Phone,Long]"12345"
[Employee,String]"Bill"
{
[Married,Bool]"False"
[Age,Long]"21"
}
[Employee,String]"Ted"
{
[Married,Bool]"True"
[Age,Long]"45"
}
}
}
Note
The data in the SDO is case-sensitive.
SDO label
The label identifies an SDO similar to a field name on a form. If you need to know
an employee name, consult the Employee field. To find the employee name if it is
held as an SDO, look for an SDO with an Employee label. SDO labels are
optional.
SDO value and type

An SDO can have a single value, but a value cannot exist without an associated
type. In the example shown at the end of 3.3.5.1, “Semantic Data Objects” on
page 25, the Company SDO has the value Acme Inc. and a type of string. The
Phone SDO has the value 123456 and a type of Long. Table 8 details the valid set
of types. Note that SDO values are optional.
Table 8. SDO type
Type Meaning
Atom A multiple choice option, for example: yes, no, or maybe
Boolean A Boolean value (true or false)
Double A floating point number
Long An integer number
Object An eBPCS object reference
String An alphabetical, numeric, or alphanumeric value
Void No value
Decimal A precision number with a fixed number of decimal places
SDO container
An SDO can have a container that holds other SDOs. In the example shown at
the end of 3.3.5.1, “Semantic Data Objects” on page 25, the container of the
Company SDO contains three SDOs-one Phone SDO and two Employee SDOs:

Each Employee SDO has a container that contains an Age SDO and a Married
SDO. SDO containers are optional.
Representing an SDO in text

SDOs are represented in text as:
{
[Label,Type]"Value"
}
Here { } are containers. Root SDOs are handled differently, as described in “Root
SDOs” on page 28.
Table 9 shows the types of SDOs as they are represented in text.

Table 9. SDO types and text representations
Type When represented in text
Atom Atom
Boolean Bool
Double Double
Long Long
String <Nothing>
Decimal Decimal
Note
SDOs that are preceded with an asterisk (*) are supported for compatibility with
early versions of the Semantic Data Service only. You may see them
occasionally, when examining an SDO in text form.
The type String is the default type. If no type is specified when representing an
SDO in text, the type is assumed to be String. The representation of the value for
a Boolean type is either Yes or No. An example of an SDO type String may be
represented in text as:
[]
{
[Company,String]"Acme Inc"
{
[Phone,Long]"12345"
[Employee,String]"Bill"
{
[Married,Bool]"False"
[Age,Long]"21"
}
[Employee,String]"Ted"
{
[Married,Bool]"True"
[Age,Long]"45"
}
}
}

An Employee SDO and its container are shown in the following example:
[Employee]"Bill"
{
[Age,Long]"21"
[Married,Bool]"No"
}
If the Employee SDO has nothing in its container it is represented in text as:
[Employee]"Bill"
If the Employee SDO has no value, it is represented in text as shown here:

[Employee]
{
[Age,Long]"21"
[Married,Bool]"No"
}
If the Employee SDO has no label, it is represented in text as indicated in the

following example:
[]"Bill"
{
[Age,Long]"21"
[Married,Bool]"No"
}
If the Employee SDO has nothing in its container, no value, and no label, then it is
represented in text as shown here:
[]
This is considered a root SDO.
Root SDOs
An SDO can be contained within another SDO. An SDO not contained within
another SDO is referred to as a root SDO. In the example in “Representing an
SDO in text” on page 27, the Company SDO is an example of a root SDO. The
Phone SDO is not.
When representing an SDO in text, there is a limitation. The label and value of a
root SDO are not specified.
The Company SDO is not represented in text as shown earlier, but rather as
shown here:
{
[Phone,Long]"123456"
[Employee]"Bill"
{
[Age,Long]"21"
[Married,Bool]"No"
}
[Employee]"Ted"
{
[Age,Long]"45"
[Married,Bool]"Yes"
}
}

Where the Company SDO label and value are not displayed, only the container is
displayed.
3.3.6 CHECKEMI
Knowing the purpose and structure of SDOs, you can now use this information to
send messages using SMGs. The SMG package includes a program called
CHECKEMI. CHECKEMI is a sample program that you can use as an example for
programming an application that communicates with SMGs. You can also use this
application to test the SDOs that you are sending into eBPCS. Valid CHECKEMI
message syntax is described in the SMG Availability Guide, which can be found
on OGS.
If you want a demonstration of SMGs, refer to 3.3.6.1, “Using CHECKEMI in an

AS/400 environment” on page 29, which describes the CHECKEMI command for
the AS/400 environment. Note that you need a valid SDO to use CHECKEMI and
have the SMGs properly update eBPCS.
Note
You must be a valid eBPCS user for the SMGs to update eBPCS. You should
also include Logon and Logoff messages in your SDO. Refer to the SMG
Availability Guide for more information about Logon and Logoff messages.
You only need to use the Logon message once before sending other
messages. Once you log on and your security is validated, you can send as
many messages as you want through the SMG. Note that you should send the
Logoff message to cleanly shut down your ODO processes.
3.3.6.1 Using CHECKEMI in an AS/400 environment

Before you use CHECKEMI in an AS/400 environment, you must have the proper
library setup. Refer to the SMG Configuration Guide, which can be found on
OGS, for more information about libraries.
To use CHECKEMI in the AS/400 environment, type the following command on

the command line:
call checkemi (XXX'tests(###) 'output(###)')
In this command statement, note the following explanation:

• XXX represents the World name.
• Tests indicates the location of the SDO.
• ### (following tests) is the name of the SDO.
• Output specifies the location of the SDO reply.
• ### (following output) is the name of the reply SDO.
3.3.7 Available gateways and functions

This section provides a quick reference of all available Semantic Message
Gateways (SMGs) and what they can do.

Note
The guide shown in Table 10 lists the capabilities of gateways for the 6.1.00 GA
release, based on the best information at the time this redbook was published.
The plus (+) next to a gateway indicates that this gateway was still in
production at the time this redbook was published and the functions listed may
change.
Table 10. Semantic Message Gateways
OutboundNotification
DeriveObjectName
ChangeReference
CreateCollection
CreateReference
DeleteReference
ChangeTracking
Query Instance
CreateTracking
BPCS Program
DeleteTracking
Delete/Destroy
Query Class
Describe
AddLine
Change
Create
Apply
Post
Gateways
BankAccount ACP140 ■ ■ ■ ■ ■ ■ ■ ■
BankBranch + CSH130 ■ ■ ■ ■ ■ ■ ■ ■
BillOfMaterial BOM500 ■ ■ ■ ■ ■ ■
Carrier OLM100 ■ ■ ■ ■ ■ ■ ■
COLine ORD720 ■ ■ ■ ■ ■
COLineAllocation+ ORD720 ■ ■ ■ ■ ■ ■ ■ ■
Commodity+ PUR180 ■ ■ ■ ■ ■ ■ ■ ■
Company ACR120 ■ ■ ■ ■ ■ ■ ■ ■
Container+ API140 ■ ■ ■ ■ ■ ■ ■ ■
CostBucket CST150 ■ ■ ■ ■ ■ ■ ■ ■
CostSet CST140 ■ ■ ■ ■ ■ ■ ■ ■
Country SYS117 ■ ■ ■ ■ ■ ■ ■ ■
Currency CLD107 ■ ■ ■ ■ ■ ■ ■ ■
Customer ACR100 ■ ■ ■ ■ ■ ■ ■ ■
CustomerAddress+ ORD100 ■ ■ ■ ■ ■ ■ ■ ■
CustomerDocSequence+ ACR160 ■ ■ ■ ■ ■ ■ ■ ■
CustomerInvoice - ■ ■ ■ ■ ■
CustomerItem ORD150 ■ ■ ■ ■ ■ ■ ■ ■
CustomerOrder ORD720 ■ ■ ■ ■ ■ ■ ■ ■
CustomerPaymentType+ ACP170 ■ ■ ■ ■ ■ ■ ■ ■
CustomerSales - ■ ■ ■ ■ ■

DeriveObjectName
ChangeReference
CreateCollection
CreateReference
DeleteReference
ChangeTracking
Query Instance
CreateTracking
BPCS Program
DeleteTracking
Delete/Destroy
Query Class
Describe
AddLine
Change
Create
Apply
Post
Gateways
CustomerTerms+ ACR110 ■ ■ ■ ■ ■ ■ ■ ■
CustomerType ACR170 ■ ■ ■ ■ ■ ■ ■ ■
Department CAP120 ■ ■ ■ ■ ■ ■ ■ ■
Employee+ SFC150 ■ ■ ■ ■ ■ ■ ■ ■
Facility SYS190 ■ ■ ■ ■ ■ ■ ■ ■
ForecastSchedule - ■ ■ ■ ■ ■
FreightClass+ OLM125 ■ ■ ■ ■ ■ ■ ■ ■
FreightTerms+ OLM115 ■ ■ ■ ■ ■ ■ ■ ■
HarmonizationAnnex+ OLM191 ■ ■ ■ ■ ■ ■ ■ ■
Hazard+ OLM195 ■ ■ ■ ■ ■ ■ ■ ■
HazardousUNNAId+ OLM190 ■ ■ ■ ■ ■ ■ ■ ■
Inventory INV500 ■ ■ ■
InventoryHistory - ■ ■ ■ ■ ■
Item INV100 ■ ■ ■ ■ ■ ■ ■ ■
ItemClass+ INV160 ■ ■ ■ ■ ■ ■ ■ ■
ItemCost CST100 ■ ■ ■ ■ ■ ■ ■ ■
ItemFacility MRP140 ■ ■ ■ ■ ■ ■ ■ ■
ItemNote+ INV190 ■ ■ ■ ■ ■ ■ ■
ItemSales - ■ ■ ■ ■ ■
ItemStatus+ INV195 ■ ■ ■ ■ ■ ■ ■ ■
ItemType+ INV171 ■ ■ ■ ■ ■ ■ ■ ■
LaborTicket SFC600 ■ ■ ■ ■ ■ ■ ■
Load OLM510 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
LoadCarton OLM510 ■ ■ ■ ■ ■
LoadOrder OLM510 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
LoadShipment OLM510 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Location INV170 ■ ■ ■ ■ ■ ■ ■ ■
Lot INV130 ■ ■ ■ ■ ■ ■ ■ ■
LotNote+ INV130 ■ ■ ■ ■ ■ ■ ■

DeriveObjectName
ChangeReference
CreateCollection
CreateReference
DeleteReference
ChangeTracking
Query Instance
CreateTracking
BPCS Program
DeleteTracking
Delete/Destroy
Query Class
Describe
AddLine
Change
Create
Apply
Post
Gateways
Machine CAP170 ■ ■ ■ ■ ■ ■ ■ ■
Manufacture+ QMS100 ■ ■ ■ ■ ■ ■ ■ ■
ManufactureItemTest+ QMS105 ■ ■ ■ ■ ■ ■ ■ ■
ManufacturingMethod+ SYS135 ■ ■ ■ ■ ■ ■ ■
MaterialComponent BOM500 ■ ■ ■ ■ ■
MeansOfTransport+ OLM110 ■ ■ ■ ■ ■ ■ ■ ■
MethodCode+ SYS115 ■ ■ ■ ■ ■ ■ ■ ■
PickListConfirm+ ORD570 ■ ■ ■ ■ ■ ■
PlannedOrder MRP510 ■ ■ ■ ■ ■ ■ ■ ■
POLine PUR500 ■ ■ ■ ■ ■ ■ ■ ■
POReceipt+ PUR550 ■ ■ ■ ■ ■ ■
POReceiptInspection+ PUR550 ■ ■ ■ ■ ■ ■
PostalCode+ OLM170 ■ ■ ■ ■ ■ ■ ■ ■
PurchaseOrder PUR500 ■ ■ ■ ■ ■ ■ ■ ■ ■
ROReciept+ DRP550 ■ ■ ■ ■ ■ ■
Routing SFC100 ■ ■ ■ ■ ■ ■ ■ ■
RoutingOperation SFC100 ■ ■ ■ ■ ■ ■ ■ ■
RoutingOperationNote+ BOM190 ■ ■ ■ ■ ■ ■ ■
Salesperson+ SAL100 ■ ■ ■ ■ ■ ■ ■ ■ ■
ShippingCommision+ OLM142 ■ ■ ■ ■ ■ ■ ■ ■ ■
ShippingRoute+ OLM135 ■ ■ ■ ■ ■ ■ ■ ■
ShippingZone+ OLM130 ■ ■ ■ ■ ■ ■ ■ ■
ShipTo+ PUR130 ■ ■ ■ ■ ■ ■ ■ ■
ShopFloorBackflush+ SFC650 ■ ■ ■ ■ ■ ■
ShopOrder SFC500 ■ ■ ■ ■ ■ ■ ■ ■
SOMaterialAllocation SFC500 ■ ■ ■ ■ ■
SOMaterial SFC500 ■ ■ ■ ■ ■
SOOperation SFC500 ■ ■ ■ ■ ■
Specification QMS115 ■ ■ ■ ■ ■ ■ ■ ■

DeriveObjectName
ChangeReference
CreateCollection
CreateReference
DeleteReference
ChangeTracking
Query Instance
CreateTracking
BPCS Program
DeleteTracking
Delete/Destroy
Query Class
Describe
AddLine
Change
Create
Apply
Post
Gateways
TableRecordBPCS+ SYS105 ■ ■ ■ ■ ■ ■ ■ ■
TaxRate+ SYS140 ■ ■ ■ ■ ■ ■ ■ ■
TaxTable SYS150 ■ ■ ■ ■ ■ ■ ■ ■
UOMFactor INV120 ■ ■ ■ ■ ■ ■ ■ ■
Vendor ACP100 ■ ■ ■ ■ ■ ■ ■ ■
VendorContract+ PUR151 ■ ■ ■ ■ ■ ■ ■ ■
VendorContractDetail+ PUR152 ■ ■ ■ ■ ■ ■ ■ ■
VendorDocSequence+ ACR160 ■ ■ ■ ■ ■ ■ ■ ■
VendorQuote+ PUR150 ■ ■ ■ ■ ■ ■ ■ ■
VendorPaymenetType+ ACP170 ■ ■ ■ ■ ■ ■ ■ ■
VendorTerms+ ACP160 ■ ■ ■ ■ ■ ■ ■ ■
VendorType ACP150 ■ ■ ■ ■ ■ ■ ■ ■
Warehouse INV110 ■ ■ ■ ■ ■ ■ ■ ■
WarehouseInventory ■ ■ ■ ■ ■
WarehouseSales ■ ■ ■ ■ ■
WorkCenter CAP100 ■ ■ ■ ■ ■ ■ ■ ■
3.4 eBPCS development toolsets

There are two development toolsets associated with eBPCS:
• AS/SET Application Development Kernel (ADK), which is used for producing
and maintaining the green-screen application
• Object Development Workbench (ODW), which is used for the Client/Server
products
The code produced by these products is mainly OPM RPG, with the exception of
the interactive parts of the Second Generation Client/Server product, which are
ILE RPG. New versions of the toolset have been developed that generate ILE
RPG exclusively (note that new ILE generators were in testing at the time this
redbook was published). This will bring performance benefits and SSA's
development strategy in line with IBM. Both of these toolsets are Computer Aided
Software Engineering (CASE) tools. Software Engineering refers to the
disciplined, structured, and documented approach to software development.
Using CASE tools for software development helps increase your productivity,
quality, and efficiency. The concept of CASE consists of six components that are

commonly referred to as the software development life cycle. These six
components, as shown in Figure 12, are:
• Planning
• Analysis
• Design
• Construction (Application Generation)
• Project Management
• Implementation
Figure 11. Software development life cycle
The first three components (Planning, Analysis, and Design) involve system
planning tasks, such as flow charting, diagramming, Data Modeling, data
diagramming, entity relationships, and decomposition diagrams. CASE products
covering this portion of the software development life cycle are primarily PC
based, and are often referred to as Upper CASE tools. The latter components of
the cycle (Construction, Project Management, and Implementation) are primarily
application generation, and are often referred to as Lower CASE tools.
3.4.1 What is ADK?

ADK is a software engineering product developed by SSA that automates the
software development life cycle designed specifically for the IBM AS/400 system.
Completely menu-driven, ADK complies with IBM System Application
Architecture (SAA) Common User Access (CUA) standards and allows the
generation of applications that are fully SAA compliant.
ADK addresses the design and application generation components of CASE. It

allows the definition of an application program by defining its components, such
as files, fields, screens, and report layouts.
It then automatically generates the source code. The generated code and objects
can be executed as fully functional application programs. To make changes in the
application, the definition can be changed within ADK and regenerate the
appropriate code.

With ADK, you can:
• Generate display, batch, and report programs
• Improve the quality and consistency of your software applications
• Incorporate your existing RPG source code
ADK accelerates development time in the following ways:

• Initial development is faster because the application only needs to be defined,
rather than coded line by line.
• Lengthy code testing is greatly reduced since ADK-generated code is syntax
error-free.
• Code maintenance is eliminated since modifying the definition of the
application in ADK and re-generating the code can change an application.
3.4.1.1 Faster application development

ADK allows you to build a complete application by giving you the capability to
define any type of on-line display program, report program, batch program. After
defining an ADK program, you can generate its RPG/400 source code and
required objects. The resulting RPG/400 source code is documented and
structured.
Since ADK is menu driven, it steps through all the required functions in building
an application. ADK incorporates all SAA CUA standards. ADK makes full use of
action bars, action codes, pop-up windows, cursor-sensitive processing,
field-level Help, and an optional OS/400 command entry line on each panel.
3.4.1.2 Improved product quality

While ADK itself incorporates all SAA standards in it, it also allows you to
generate applications that are SAA compliant. For any generated application
involving display program screens, you can fully use all SAA standards, such as
windows, action bars, action codes, cursor-sensitive processing, field-level help,
and a panel command entry line.
All generated programs are full-function and can be run stand-alone or called
from within one of your own programs, menus, or applications. Since ADK has no
proprietary routines or run-time modules, you can port generated programs to
other AS/400s, regardless of whether ADK resides on the system.
Within each program type, you have complete calculation capability, such as
numeric calculations, alpha calculations, date arithmetic, pre-defined functions,
and conditional processing.
3.4.1.3 Reduced maintenance effort

For developing multiversion software applications, ADK provides software
version control through its concept of Application Sets. All programs for an
application can be created in one Application Set. When a new version is needed,
the programs can be copied to a second Application Set, and the next version
begun in that Set. The first version remains intact in the first Set.
The range of application programs that you can generate with the ADK product is
unlimited. You can build simple display programs, such as a menu or inquiry. You
can also generate very complex on-line maintenance programs involving multiple

files, header/detail relationships, conditional processing, and calls to external
programs.
ADK can generate any type of display, report, or batch program and link these
programs together, as well as link them to your own application programs. With
these abilities, the ADK product can generate the majority of required
applications.
3.4.1.4 Components of ADK

Figure 12 illustrates a high-level overview of the ADK product architecture. The
Product Security function controls the entire product. Within the Product Security
section, you can create Application Sets, default settings, standards, etc. All
standards and defaults are inherited down through the development process and
are carried across every program created within that Set.
The next component in the architecture is the Repository. Each Application Set
has access to only one Repository. Within the Repository are the Data Models,
Field Reference entries, define/re-create DDS files, etc. From the re-usable
specifications created in the Repository, you can define display, batch, and report
programs.
Figure 12. ADK architecture
With ADK, you can create:

• Display programs when an on-line interactive program is required
The display programs section contains a Screen Painter, Action Diagrammer,
and Report Ruler. Up to 200 screens can be defined in a display program.

• Report programs for the purpose of producing printed output
When defining a report program, the report layout can be customized and
report characteristics can be specified, such as level breaks, sorts,
sub-totaling, user-defined calculations, and printer characteristics.
• Batch programs to perform file processing where no screen displays are
required
A batch program updates the information in 50 files (an RPG limit) and
performs any calculations or actions that are required. Batch programs can
also be used to generate reports.
3.4.1.5 Understanding the Repository

In ADK, a Repository serves as a storehouse of re-usable information that can be
repeatedly accessed when you build an application. A Repository consists of
such definitions as:
• Data Models
• Files
• Fields and their properties (characteristics, attributes, and validations)
• Audit trails
• Field Reference entries
• Links between Data Model files
The Repository can pull in and use existing Data Description Specifications
(DDS) or create new DDS from within ADK. DDS files can be created from within
the define/re-create DDS section of the Repository, or from the Data Model. Once
the Data Model is created, the programs are created from the Data Model's
logical view of the data.
3.4.1.6 Creating a global Repository

The need may arise where Application Sets need to be separate entities, but
need to reference the same Repository. ADK allows you to create a global
Repository, where one or more Application Sets reference another Application
Set's Repository.
Although the Application Sets share the same Repository, the Application Sets
remain distinct entities and their respective programs are not shared.
For example, in Figure 14 on page 38, the Repository for Application Set 1
contains all the re-usable specifications, such as Data Models and files for Set 1,
Set 2, and Set 3. Since Application Set 2 and Set 3 both reference for the
Repository Set 1, they do not have their own Repository.

Figure 13. Development Repository
3.4.1.7 Functions of the Repository

All activities related to gathering and storing information within a given
Application Set are available through the Repository menu. Access the
Repository menu by selecting option 4 (Repository) from the ADK Main menu and
pressing Enter. The display shown in Figure 14 appears.
Figure 14. Repository menu
The Repository menu allows you to perform the following functions based on the
options shown in Figure 14:
• Define Data Models (option 1) allows you to define Data Models with its
associated files and fields. When defining Data Models, you can use files that

either do or do not exist as DDS objects. If the files do not exist, they can be
generated once the Data Model is defined. For files that do not exist, the
specified fields are pulled from the Field Reference section, along with the
field's characteristics, attributes, and validation.
• Field Reference (option 2) allows you to create a global definition of all fields
that you want to use in the Repository. You can either manually type in the
fields, such as their name and description, or you can retrieve existing DDS
file fields. When you define new files or re-create existing ones by using the
define/re-create files, the fields that make up these files must exist in this Field
Reference section.
• When fields are defined to a Data Model, they do not have to exist in the field
reference. However, if the field exists in the field reference, its characteristics,
attributes, and validation are pulled into the Data Model definition. If the field
does not exist in the field reference, default values for these items are
assigned. In either case, you can override these items at the Data Model level.
• Define/re-create DDS files (option 3) allows you to create new files, or
re-create existing ones. Files can be either physical, logical, or join logical.
When re-creating a file, you have the option to retain the file's current data.
For any file that is created or re-created, the fields must either be defined in
the Field Reference section or refer to fields defined in the Field Reference
section.
When defining physical files within the define/re-create section, you can
specify that the file should be journaled along with the journal name to be
used. Journaling is required if you plan to define commitment control.
• Define audit trails (option 4) allows you to create audit trail reports for any file.
The audit trail is a user-defined report that lists changes (for example, add,
delete, and update), or inquiries made to the file. Once you define the audit
trail reports, they are available whenever the file is used in a display or batch
program.
• Impact of change reports (option 5) allows you to produce either summary or
detail reports of where an item, such as a Data Model, file, or field, is used
within other items, such as programs, Data Models, or files.
• Change management control (option 6) allows you to specify that changes
made to one entity, such as a field, should be propagated to other entities,
such as files, Data Models, and programs.
• Action Subroutines (option 7) allows you to define reusable Action
Subroutines. Once these Action Subroutines are defined in the ADK
Repository, they can be referenced in any display, batch, or report program.
These Action Subroutines can also be attached to any field (either at the field
reference, Data Model, or program level) as part of the field's validation.
Action Subroutines are executed in an Action Diagram by using the EXSUBR
action keyword.
3.4.1.8 Approaching Data Modeling

The Data Model is probably the most important concept in ADK. A Data Model is
a grouping of one or more files that provide a logical view of the file field
information. Each Repository can contain one or more Data Models. The two
approaches to viewing Data Modeling are Top-Down and Bottom-Up.

3.4.1.9 Top-Down Data Modeling
The Top-Down Data Modeling method requires that you develop an application
from a high level (Data Model) down to the low level (file fields).
First, you create the Data Model (bringing in any existing files). Then, you define
the files and fields from within the Data Model. The fields are actually created and
stored in the Field Reference section of the Repository, making them available to
other users in the same Application Set. A program can be defined before the file
has been compiled. However, before compiling the program, you must first
compile the files.
Figure 15 illustrates the Top-Down Data Modeling method.
Figure 15. Top-Down Data Modeling
3.4.1.10 Bottom-Up Data Modeling

In the Bottom-Up Modeling approach, you begin by creating fields in the field
reference, Then, you define the files in the define/re-create DDS section (pull in
existing files). Finally, you create the Data Model.
When Data Models are defined, they can be defined with files that may exist as
DDS objects. If the Data Model contains files that do not yet exist, they can be
automatically generated once the Data Model is defined. For files that do not
exist as DDS objects, the fields that are specified are pulled from the Field
Reference section, along with their associated characteristics, attributes, and
validation.

You have the option to define the field characteristics, attributes, and validations
at the Field Reference or the Data Model levels. Figure 16 illustrates the
Bottom-Up Data Modeling method.
Note: The characteristics, attributes, and validations can be overridden at the

program level.
Figure 16. Bottom-Up Data Modeling
3.4.1.11 Defining fields

Field Reference allows you to create a global definition of all fields that you want
to use in the Repository. You can either retrieve existing DDS file fields, or
manually type in the fields, such as their name and description. When you define
new files or re-create existing files using the define/re-create files option, the
fields that make up the files must exist in the Field Reference.
When defining fields to a Data Model, the fields do not have to exist in the Field
Reference. However, when a field is defined to a Data Model, a check is
performed to see if the field exists in the Field Reference. If it does exist in the
Field Reference, its characteristics, attributes, and validation are pulled into the
Data Model definition. If it does not exist, default values for these items are
assigned.

The properties specified at the Field Reference level are inherited at the Data
Model level. The properties can be modified at the Data Model level, and then
inherited at the program level. Once again, the properties can be modified at the
program level.
Regardless of the changes made at the Data Model or program level, the
properties at the previous level are never affected. For example, if you make
changes to the field characteristics at the Data Model level, the field
characteristics at the Field Reference level are not affected.
Fields are composed of three properties:

Characteristics Aspects of a field such as the field name, field type, length, and
description.
Attributes Aspects of a field that apply when the field is used in a display
program screen. Attributes include whether the field is
input-capable or should be automatically incremented.
Validations Default edit checks that are defined for Repository fields, and
are then in effect whenever the field is used in an
ADK-generated program. Validations include edits such as
default values, existence checking against a file, and checking
against a list of values. Default values for field validation are not
carried over to template programs.
3.4.1.12 Overview of display programs

A display program is created when an on-line program is needed for user
interaction with one or more screens. display programs can be in the form of:
• Inquiry programs
• Prompts
• Menus
• Informational displays
• Maintenance processing, such as file update, delete, add, and transaction
processing.
Components of the display program

When defining a display program screen, the following items must be defined:
• Screen layouts
The screen layout consists of fields and constants that are painted using the
Screen Painter. The Screen Painter assists you in laying out the screens (you
can define up to 200 screens). Using the Screen Painter, you can select the
Data Model, files, and fields, and have them automatically laid out by ADK.
(Data Models and fields must be selected for each screen.) You can manually
lay out the screen and customize the ADK layout.
• Actions
All screens must have actions to drive the display of file data on the screen, to
drive the movement by the user from screen-to-screen, and to manipulate any
data or calculations. The action diagram allows you to define actions for all
created screens.
Display program templates provide a powerful method for automatically
generating display programs without having to manually define the screens,
actions, function keys, etc. When you manually define an ADK program, you

have to layout the screen and write the action diagrams that control the file
processing and navigation through the program. However, with templates, all
program functions, including file processing, are automatically generated.
Defining display programs

Defining a display program screen involves the following tasks:
1. Access the Display Program section from the ADK Main menu by selecting
option 1 (Display Programs). When the Display Programs panel appears,
enter the name and description of the Display Program.
2. On the Display Program Edit panel define various aspects of the display
program, such as whether the program is confidential and whether time
restriction should be defined.
3. Specify screen names and screen types on the Display Program Edit - Screen
Listing panel. Two types of screens can be defined: a full screen or a window
screen. When defining a window screen, you must provide window
coordinates, such as the lines and columns where the window should begin
and end. After defining the type of screen, and coordinates if necessary, the
Screen Painter appears.
4. For each screen you defined (except Menu type programs), you must select a
Data Model and Data Model fields. Fields can be laid out on the Screen
Painter by selecting F7 (Repaint Screen), or by painting them manually. ADK
automatically lays out your selected Data Model fields on the Screen Painter,
along with their descriptions. At this point, you can customize the panel, which
can consist of moving fields, underlining fields, and applying display, and color
attributes to the fields.
5. Define function key lists by either manually typing them as text literals or using
the keyword *FKEYS. *FKEYS automatically lays out the function keys defined
at the Application Set level and those defined on the function keys panel.
The following items are optional when defining a display program screen:
• File-level keywords, such as HOME, which means when a user presses the
HOME key, the cursor is positioned on the first input-capable field. These
keywords are defined on the Display Program Edit - Keywords panel.
• Screen-level keywords affect a screen when it is displayed when a display
program is run. These keywords are specified on the Display Program Edit -
Screen Listing panel.
• Help text refers to information explaining the function or purpose of the display
program screen. This help text is created on the Define Help Text panel.
• Three types of Subroutines can be defined for the display program: Action
Subroutines, External Source Subroutines, and Repository Action
Subroutines. Subroutines are defined on the Display Program Edit -
Subroutines panel.
• Parameters can be defined for the display program on the Display Program
Edit - Parameters panel. Once parameter fields are defined, they are just like
other fields within the display program and can either be placed on the Screen
Painter or used in Actions.
• An unlimited number of text lines can be specified for the Program Narrative.
Program Narrative is specified on the Display Program Edit - Program
Narrative panel.

• Data structures and data areas can be defined for the display program using
the Data Structures/Data Areas panel.
• Selection criteria can be specified for one or more files in the display program
using the Selection Criteria/Audit Reports/Commitment Control panel. Using
this panel, you can also activate commitment control or activate an audit
report for a physical file.
• Report layouts can be defined on the Display Program - Report Ruler Layouts
panel. Report Layouts can be customized using the Report Painter.
• Field groups can be defined to a group of fields, screen keywords, and/or
literals. Once a field group is defined, you can set the display attributes for all
items in the group by using the GRPATR action keyword. Field groups are
defined on the Field Groups panel.
All screens must have actions to drive the display of file data on the screen, to
drive the movement by the user from screen to screen, and to manipulate any
data or calculations. Actions are defined on the Action Definitions panel.
Once you define the display program screens, you can prototype the display
program. This allows you to design screens, and then examine the flow of the
screens before you compile the display program. Screens are selected for
prototyping by using the Prototype panel.
When you finish defining the display program, you are ready to compile and
execute the program.
3.4.1.13 Overview of report programs

Report programs are created for producing printed output. You can create report
programs for any report type, including labels, checks, and purchase orders, in
addition to standard column reports. For creating a report program, ADK provides
a full function Report Painter to assist in laying out the report exactly as you want
it to appear.
Tasks for defining report programs

Defining a report program consists of the following tasks:
1. From the ADK Main menu, access the Report Programs panel by entering an
Author ID, an Application Set, and selecting option 3 (Report Programs). The
report program name and description are entered on the Report Programs
panel.
2. Define various components of the report program using the Report Program
Edit panel. This includes specifying the Data Model that will be used in the
report program and specifying whether the program should be confidential.
3. Select the fields that you want to use in the report program using the Data
Model Field Selection panel. Fields are printed on the report and used in
defining actions and level breaks.
4. Once the fields are defined, you can specify level functions for them.
Field-level functions include level breaks, sorts, and page breaks. These
functions are defined on the Report Field Edit panel.
The following items are optional when defining a report program screen:
• Report headings, such as date and company name, can be specified to
appear on the report. These report headings are defined on the Report Setup

- Report Headings panel. The headings that appear on this panel are the
defaults that were defined at the Application Set level.
• Three types of subroutines can be defined for the report program: Action
Subroutines. Subroutines are defined on the Report Program Edit -
Subroutines panel.
• Parameters can be defined for the report program on the Report Program Edit
- Parameters panel. Once parameter fields are defined, they are just like other
fields within the report program and can either be placed on the screen or
used in Actions.
• Program narrative, an unlimited number of text lines describing the program,
can be specified. Specify the program narrative on the Report Program Edit -
Program Narrative panel.
• Data structures and data areas can be defined for the report program using
the Data Structures/Data Areas panel.
• Selection criteria can be specified for one or more fields in the Report
Program using the Selection Criteria panel.
A report program automatically creates the logic and prints report lines based on
the report layout. To perform data manipulation, you can specify the actions to
operate between the reading of the data and its printing.
In report programs, actions can be executed before or after level breaks. You can
define level-break actions for any field that has been defined as having a level
break on it. You can define an unlimited number of actions that are executed
when the report program is run. Actions are defined on the Report Actions panel.
After selecting a Data Model and the Data Model fields, a default layout of the
report can be obtained that includes the fields, text, page headings, footings, and
level breaks that have been defined. This layout is reported on the Report
Program Edit - Layout Ruler panel. You can modify this default layout.
When you finish defining the report program screens, you can compile and
execute the program.
3.4.1.14 Overview of batch programs

Batch programs are created to perform file processing where no on-line panels
are involved. Batch programs are generally used for file manipulation purposes.
If referential integrity rules are defined for any files in the program, they are
included in any generated batch program. referential integrity ensures that file
relationships are maintained when records are added to, or deleted from a file.
Defining batch programs

Defining a batch program consists of the following tasks:
1. From the ADK Main menu, access the Batch Programs panel by entering an
Author ID, an Application Set, and selecting option 3 (Batch Programs). The
Batch program name and description are entered on the Batch Programs
panel.

2. Various aspects of the batch program, such as whether the program is
confidential and whether time restriction should be defined to it are defined on
the Batch Program Edit Panel.
3. You must specify the Data Model and Data Model fields for the batch program
using the Data Model/Field Selection panel. At least one Data Model must be
selected. Up to 50 files can be used in the batch program. This task is required
when defining a batch program.
The following items are optional when defining a batch program screen:
• Parameters can be defined for the batch program on the Batch Program Edit -
Parameters panel. Once parameter fields are defined, they are just like other
fields within the batch program and can either be placed on the screen or used
in actions.
• Three types of Subroutines can be defined for the Batch Program: Action
Subroutines. Subroutines are defined on the Batch Program Edit -
Subroutines panel.
• An unlimited number of text lines can be specified for the program narrative.
Program narrative is specified on the Batch Program Edit - Program Narrative
panel.
• Data structures and data areas can be defined for the batch program using the
Data Structures/Data Areas panel.
• Selection criteria can be specified for one or more files in the batch program
using the Selection Criteria/Audit Reports/Commitment Control panel. Using
this panel, you can also activate commitment control or activate an audit
report for a file.
• Report layouts can be defined on the Batch Program - Report Ruler Layouts
panel. Report layouts can be customized using the Report Painter. Report
layouts can be customized using the Report Painter.
• A batch program needs to have actions to read the file. To perform data
manipulation, actions can be specified to operate between the reading of the
data and its printing. Actions are defined on the Batch Actions panel. This task
is required when defining a batch program.
Once the batch program is defined, you can compile the program and execute it.
3.4.1.15 Overview of Action Diagramming

The Action Diagramming facility is used to describe the special processing rules
and procedures that can be deduced from ADK's other components such as the
Repository, Data Model, or Screen Painter. Action Diagramming allows you to:
• Manipulate data
• Define calculations
• Execute pre-defined calculations
• Control file processing
• Execute OS/400 commands
• Call programs and pass parameters
• Provide commitment control
• Build conditional logic
• Perform unctions conditionally

All actions are defined as a series of Action Statements, such as:
QTR1 = JANSLS + FEBSLS + MARSLS
Or:
IF SALES > QUOTA
BONUS = 10% * (SALES-QUOTA)
END
Action Statements are executed by the generated program in the order that they
are listed (unless conditionals or GOTO statements are involved). In report and
batch programs, actions are defined in one place. However, in display programs,
multiple lists of actions can be defined for each screen in the program.
For example, for a single screen in a display program, a different set of actions
can be defined for each function key, each time Enter is pressed (Post-Enter
Actions), for execution prior to displaying a screen (Pre-Screen Actions), or for
execution after a screen is exited (Post-Screen Actions).
You can define an unlimited number of Action Statements per ADK program.
All Action Statements are defined on an Actions panel similar to the example in
Figure 17. The only difference between the three program types is the panel title.
Figure 17. Sample Actions panel
The Action Definitions panel allows you to define an unlimited number of actions
that are executed when the display, batch, or report program is run. Whenever an
Action Statement is added or updated, it is stamped with the date, time, and user
profile name. When the program definition is printed, this information appears for
each Action Statement.
Line numbers are automatically assigned by ADK and represent the order in
which the Actions will be executed. Lines can be copied (C), moved (M), deleted
(D), or inserted (I) by typing the appropriate symbols in the Line field.

Each Action Statement is assigned an action type in the type field. The action
type determines the functions that are performed in the action diagram. Table 11
lists the valid action types.
Table 11. Action types
Type Meaning
N Numeric actions
K Action Keyword
A Alpha actions
C OS/400 command
; Comment statement
+ Continuation lines
The Field/Kywd field is used to enter either the result field for the specified Action
Text, Action Keyword, or OS/400 command.
If you type in a field in the Field/Kywd field, it becomes the result of the Action
Text statement. For example, in the following statement. QTR1 is the field that is
the result of JANSLS + FEBSLS + MARSLS.
QTR1 = JANSLS + FEBSLS + MARSLS
Note the following conditions:

• If you enter an Action Keyword in the Field/Kywd field, it designates that you
are defining a keyword action, such as NXTSCR. If a keyword is used, the
Action Text serves as the parameters of the Keyword, for example, IF QTR1 >
0.
The Action Text field is used to enter the text component of your Action
Statement.
• If you enter a field in the Field/Kywd field, your Action Text should be a
calculation, a value, or another field.
• If you enter an Action Keyword in the Field/Kywd field, the Action Text
becomes the parameters for the Keyword, as illustrated here:
Type Field/Keyword Action Text
N QTR1 JANSLS+FEBSLS+MARSLS
K IF SALES>10000
K EXSUBR $DATE1
K END
• If you enter an OS/400 command in the Field/Kywd field, the Action Text
becomes the parameters for the command, as illustrated here:
Type Field/Keyword Action Text
C WRKOUTQ QPRINT
C CALL REPORT1 (’030999’ ’DATE2’)
C RMVM CUSTLIB/CUSTMST MBR (COMP1)

3.4.1.16 Overview of generating ADK programs
After defining an ADK program, the RPG/400 source code and required objects
can be generated for the program. Generation of a program is the actual
compiling of the program's required objects, such as an RPG object or CLP
object. The required objects are the actual objects that are necessary to run the
program. In fact, a program cannot be executed until its required objects are
generated. Table 12 lists the valid required object types.
Table 12. Required object types
Required object type Definition change
*CLP Parameters, Printer Files, Data Model Files
*DSPF Screens, Data Model Files
*FMTF Data Model Files, Sort Sequence
*HDSP Screens, Data Model Files, Help
*HINX Screens, Data Model Files, Help
*HRPG Screens, Data Model Files, Help
*HTXT Screens, Data Model Files, Help
*MSG Control Language Message
*PHY Data Model Files, Sort Sequence
*PRTF Printer Files
*RPG Screens, Printer Files, Parameters, Data Model Files
*SLGL Selection Criteria, Data Model Files
You can use required objects to execute the program from either within ADK or
from outside. No run-time or proprietary routines are placed in the objects, which
means that they can be ported to other AS/400 systems and run on an AS/400
without the ADK product being present.
All generated programs are full-function programs that can be run as a

standalone or called from your own programs, menus, and applications. In other
words, there is no difference between ADK generated programs and any other
programs on your AS/400 system.
While you can define specific programs within ADK, you can stream multiple
programs together to produce full application systems. Any ADK program can call
any other ADK program through the use of user-defined actions. In this manner,
programs can be sequenced into full job streams.
Full integration of ADK programs and your own application programs is possible,
since any ADK program can call any AS/400 program and any AS/400 program
can call any ADK program.
The generation of ADK programs is performed within ADK using one of three
options:
• The Action Choice of Compile options
• The GENPGM command, which allows you to generate all programs and also
to start and end the subsystem

• The GENERATE1 command, which only generates one specific program and
does it either interactively or in batch
3.4.2 Object Development Workbench (ODW)

ODW is a PC-based development tool that allows you to maintain application
components through the use of a graphical user interface (GUI) desktop. ODW
provides a total environment for developing client/server program definitions.
With ODW, you can create application definitions with point-and-click technology
and work on many different objects at once. You can move from one task to
another and even cut and paste information between the objects.
3.4.2.1 ODW tool

The ODW tool suite provides the total environment for developing client/server
program definitions. ODW Object Presentation Services (OPS) Designer is one of
the major components in the Object Development Workbench tool suite from
SSA.
You can define, design, and generate graphical, client/server programs for the
32-bit Windows environment with ODW OPS Designer. The definition facilities
shown in Figure 18 are part of ODW.
Figure 18. ODW definition facilities
Each ODW definition facility is explained in Table 13.

Table 13. SSA Object Development Workbench
Definition facility Description
This icon launches any one of these

Application Launcher facilities: Upload, Administration, Client, and
Server.
This tool provides an intuitive means of

Appset Transfer transferring Application Sets, message files,
and application containers between
Microsoft Windows NT/SQL server
repositories. Data may also be archived to
flat files.

Definition facility Description
The Object Control System (OCS) provides

Object Control System source control. The ODW Object Control
System enables you to check-in and
check-out definition objects from a central
development Repository to your own
working Repository environment. In addition
to the check-in and check-out capabilities,
Object Control allows you to add new
objects to the central Repository.
ODW Administration provides environment

ODW Administration and security control. This is where author
IDs, Application Sets, languages, and
system defaults are maintained.
The ODW OPS Designer allows you to

ODW OPS Designer maintain eBPCS applications. This includes
adding, deleting, or changing columns,
tables, Data Models, display programs, and
batch programs.
Use ODW Upload to extract data from the

ODW Upload ODW Repository and send it to the host
(AS/400 or UNIX) for generation. You can
also use it to create an intermediate version
of the data on your local drive for use with
ODW Verify.
This tool provides a reporting facility that

ODW Verify ensures that various dos and don’ts are
followed for eBPCS definitions.
ODW Verify serves as a syntax checker for
the ODW Repository that contains the
program definitions.
OPS Generator The OPS Generator allows the generation of

clients for eBPCS applications. The output
from this tool includes string table resource
files and View Layout Files (VLF).
This application creates an empty ODW

Repository Creator Repository on an Windows NT (SQL
Server).
3.4.2.2 ODW Repository overview

The ODW Repository can be broken up into two areas, application sets and
global definitions. Application sets contain definitions related to a particular
application, such as Accounts Payable. The ODW Repository also contains some
global definitions that can be used by any application set. These includes string
tables, message files, and containers.
Figure 19 on page 52 shows a list of components that make up an ODW

Repository.

Application ACP ACR BIL PUR ... ...
Sets
String Message
Global Tables Files
Figure 19. ODW Repository overview
3.4.2.3 Application Sets

An Application Set is a collection of related application definitions (for example,
all Accounts Payable definitions). An Application Set is divided into two areas:
database definition and applications. The database definition is a storehouse of
reusable objects (such as table, column, and Data Model). The applications can
be display programs or batch programs. For eBPCS client maintenance, we are
only interested in display programs. However, it helps to see how they fit into the
overall scheme. Figure 20 shows a list of components that make up an
Application Set.
A pp licatio n S e t
C olu m n s
• T ype
• L ength
R e fe re n ce d in
D atab as e T ab les
D efin itio n • C o lu m n L ist
• K ey Info
U se d in
D ata M od els
• T ab le L ist
• R elation ship
U se d b y
A p plication s
A p p lica tion s • D M L ist
• L ogic
Figure 20. Application Set
3.4.2.4 Database definition

Database definitions are a storehouse of reusable objects. An Application Set
can contain its own database definitions or it can refer to another Application
Set's database definitions. There can be only one database definition for each
Application Set.
Columns
A column is a piece of information. A column defines such characteristics as type
and length. To develop columns in ODW OPS Designer, you define a global

dictionary that contains an unlimited number of columns. You can then reference
the columns that you define in a table.
Tables
A table contains multiple columns. A table is a collection of related records
treated as a basic unit of storage. To develop tables in ODW OPS Designer, you
map all the columns to a table that represents a basic unit. You can then
reference the tables you define in a Data Model.
A table can be a physical table or a logical view of a table. You can set up:
• Physical tables, which contain columns that store actual data.
• Logical tables, which are built over the physical tables and define a new view
or key to access the physical table data.
• Joined tables, which is a union of one or more tables that do not actually exist
in eBPCS.
Data Models
A Data Model is a group of one or more tables that provide a logical view of the
column information in a table. A Data Model can show the relationships between
tables. It is also a logical representation of entity or table relationships contained
within a single definition.
Programs use Data Models to process tables by referring to the Data Model
instead of individual tables. Display and batch programs both reference and use
the Data Models to manipulate records and data. You must define Data Models
with tables that exist in the definition. A Repository can contain one or more Data
Models.
3.4.2.5 Object Presentation Services (OPS) applications

An application or program uses Data Models to manipulate database tables. An
application contains program logic. There are two types of applications allowed in
ODW: display programs and batch programs.
Display programs
Display programs are interactive client/server applications. These are of the
same type as the eBPCS OPS style applications. A display program allows the
definition of server logic as well as the client interface. Display programs cover
the following online processing functions:
• Inquiries
• Menus
• Prompts
• Informational displays
• Maintenance processing (table updates, deletes, adds, and transaction
processing)
You must perform the following steps for a display program:

1. Select the Data Models and columns for each screen or view model.
2. Define actions for each view model or screen. Actions are grouped according
to when they are run (for example, Pre-Screen and Post-Screen).

3. Define the view model or screen layout, which consists of columns, list box
definitions, and constants.
4. Define the client or GUI interface.
3.4.2.6 Batch programs

Batch programs run in a job queue and do not allow any user interaction. These
are often batch update or report type applications. A batch program allows the
definition of logic. You must complete the following tasks for a batch program:
1. Select Data Models and columns for the batch program.
2. Define the actions for the batch program.
3.4.2.7 Global objects

Global objects are available to all Application Sets. There are two main types of
global objects: containers and text definitions.
Containers
A container is an iconic representation of an application system, a group of
programs, or a single executable. These icons or containers instantiate on the
user interface at runtime, and serve as a grouping mechanism and shortcut for
launching an executable.
Containers provide easy access to the applications and program groups that your
end users use most often. For example, eBPCS consists of a number of
executable products in the entire eBPCS application system. Many products
relate to the financial industry, many to manufacturing, and so on. You may want
to create a group based on functional similarity, such as creating a container for
just the eBPCS financial products, one for just the manufacturing-related
products, or any configuration that makes sense.
eBPCS is considered the one and only application in ODW and is the main root.
The eBPCS runtime environment is designed to reference only the eBPCS
container as the main application. From this root, you define any number of other
containers. Within each container, you can place one or more containers or
discrete executables (individual program).
Text in ODW
When defining applications, text is used to describe data on windows. Currently,
there are three ways of defining strings for an ODW application:
• String table (client)
• Message file (host)
• Static text
Only client string tables and message files are external and allow for National
Language Support (NLS). The advantage of these externalized strings is that
different languages can be used with the same set of executable program files.
Table 14 on page 55 lists the characteristics of string tables and message files,
which are discussed in detail later in this chapter.

Table 14. String tables and message files comparison table
String tables (client) Message files (host)
Use where there is a GUI window only Use where there is a View Model/Character
screen Reference on GUI
Generation Generation
ODW OPS Generator ODW Generator
Resource file AS/400 Message file
Host
Compile
DLL
Client
3.4.2.8 Message files

Message files are host-based strings that can be used in the view model, screen
layout or report layout. They contain strings defined on the server. Message file
messages can be found in Action Diagram logic (to display error messages), as
text on the view model or character-based screen definition or in field validation
error messages. They can be referenced on client windows only if they are first
defined on the character-based screen or in the data structure. Message files are
not restricted by an Application Set.
When changes are made to a message file, the message file must be uploaded to
the host using ODW Upload. Next, the message file has to be generated on the
host using the ODW Generator for that host platform. For the AS/400 host, these
files are used to generate AS/400 message files that are read at execution time.
Similarly, the UNIX generator takes updated message files and generates
additional rows to the SSAZ01, SSAZ02, and SSAZ03 tables.
• Use where
–View Model/Character screen ODW AS/400
Upload
–Reference on GUI
• Global
–Available to all AppSets ODW AS/400
Generator
• Generation (AS/400)
–ODW AS/400 Generator
–AS/400 Message File Message File
–Host
Figure 21. Host message files
In ODW, multiple languages can be defined. Each language can have multiple
message files. Within each message file there are strings with unique message
IDs. Message file strings are referenced by message file name and message ID.
This design allows the same message file and message IDs to be defined in
multiple languages.
While each copy of the message file can have the same set of message IDs, the
associated message text can be in different languages. For example, if a view
model references the string Press Enter to return with the message ID MSG1234

in the English version of the EMPMSG message file, the French representation
can be defined with the message ID MSG1234 in the French version of the
EMPMSG message file with the same message ID.
If the screens show an application which displays the message text Press Enter
to return in English and in French, both message files are named EMPMSG. The
English version of the message file resides in the ENGLISH directory, and the
French version resides in the FRENCH directory.
To toggle between message file directories, you must modify the Action Diagram
to manipulate the directory list.
3.4.2.9 String tables

String tables contain strings defined on the client or GUI window. These strings
include window captions, radio button text, or checkbox text that cannot be
derived from the server (Figure 22). String table text can only be used from the
ODW GUI Screen Designer or the ODW Container Definition facility. Once a
string is defined in a string table, it can be accessed by any Application Set.
However, in eBPCS, string tables are still divided by Application Set.
String Table source is automatically generated during the View Layout File (VLF)
generation using the OPS Generator. This string table source is used along with a
C++ compiler to create the string table DLLs. The compiled DLLs must be placed
in the eBPCS directory path specified locally using the eBPCS Session Manager.
The default is c:\bpcscs\bpcsapps\str\eng.
GUI Window only Generation

• Radio button text • OPS Generator
• Title bars • Output
• Push buttons • VLF
• etc. • String table source
Compile
• DLL
View Layout Files GUI
ODW
OPS Generator
eBPCS
Definitions
Figure 22. Client string tables
The previous BPCS architecture required separate string tables for each
Application Set. Within Application Sets, the tables were separated into title bars,
menus, captions, and a headings list box. For example, ACP has string tables
called SSAACPT, SSAACPM, SSAACPC, and SSAACPH.
3.4.2.10 ODW process overview

The steps in the following sections demonstrate the ODW process for modifying
or extending eBPCS OPS applications. You see what each component in the

setup stores and processes. Using ODW, you follow this process each time you
make a modification or extension to eBPCS.
Performing modifications
ODW OPS Designer resides on the Windows NT client. eBPCS application
definitions reside on the Windows NT server in an SQL database. Follow these
steps:
1. Make your modifications or additions using ODW OPS Designer on a
Windows NT client workstation.
2. ODW stores your application definitions on the NT server in an SQL Server
database.
Figure 23. Modifications
Uploading definitions
After you make modifications, you need to upload the definitions to the host so
you can generate the server. The ODW Upload program resides on the ODW
client.
ODW Upload takes definitions from the Windows NT server and uploads them to
the host. Figure 24 illustrates this task.
Figure 24. Uploading definitions

Generating the server definitions
After you upload the definitions, you need to generate the server definitions on
the host. You run the ODW generator that generates eBPCS server objects from
the application definitions. The ODW Generator resides on the host. Figure 25
illustrates the server generation process.
Figure 25. Server generation process
Generating the client

After you upload and generate the server definitions, you need to generate the
client. Use the OPS Generator on the Windows NT client to locally generate the
client string table source files and view layout files (VLFs). The following process
occurs:
1. When you generate the client with the OPS Client Generator, ODW reads the
GUI definitions off the Windows NT server and then generates string table
source files and VLFs.
2. You need to compile the string table source files into dynamic link libraries
(DLLs).
Figure 26 illustrates client generation.
NT Generation Objects
Repository ODW View Layout Files
GUI
OPS Generator
eBPCS
Definitions
String Table
Source
Figure 26. Client generation
Testing
After you generate the client and the server, the last step is to test the application.
The following process occurs at eBPCS (run-time):

1. When you click an icon from an eBPCS container, eBPCS server objects are
started on the host.
2. The VLFs and string tables from the eBPCS client workstation are used to
determine the presentation.
Figure 27 illustrates the application testing process.
WinNT Client Host

eBPCS Workstation
AS/400
ODW eBPCS
Generation
Server Objects
Im age
eBPCS Client/Server Run-time

V LFs
String Table D LLs
Figure 27. Testing
3.4.2.11 ODW process

The entire ODW process for modifying eBPCS OPS applications is outlined here:
1. Make modifications or additions.
ODW stores eBPCS application definitions on the Windows NT Server.
2. Upload definitions to the host.
ODW takes definitions from the Windows NT server back to the client. Then it
uploads them to the host.
3. Generate the server.
ODW generates the eBPCS server objects on the AS/400 host.
4. Generate the client.
Use OPS Client Generator on the client. ODW generates string table DLLs
and VLFs.
5. Test the new application.
Run the eBPCS server objects on the host and read VLFs and DLLs off the
eBPCS client.

String Tables
VLFs NT Server
WinNT Client
NT Client
eBPCS Workstation
ODW
eBPCS Application Definition

• eBPCS C/S Run-time •ODW OPS Client Generator Repository
• VLFs •ODW OPS Designer
• String Table DLLs Host
• ODW AS/400 Upload
AS/400
ODW eBPCS
Generation
Server Objects
Image
ODW AS/400 Generator
Figure 28. ODW process

Chapter 4. AS/400 architecture
One of the key factors contributing to the commercial success of the AS/400
system is its integrated architecture. The integration covers both hardware and
software. This chapter discusses the architectural aspects of the AS/400 system.
4.1 AS/400 integration

The AS/400 system represents an integrated computing environment. This
integration includes the hardware, operating system, and middleware, and is
illustrated in Figure 29.
Applications Applications
OS/400
Database
Communications Application Dev. On-Line Help
Mgmt Security Performance Tuning
Spooling Multimedia
Systems Mgt. Graphics
OLTP Graphical Interface
Communications Server Support
Security DB2/400 Open Interfaces
Network
Management
Technology Independent Machine Interface
Online Licensed Internal Code

Systems Transaction
Management Processing AS/400 Kernel
Security
Communications
DB2/400
Operating System
AS/400 Hardware
Hardware and Microcode 64 Bit RISC PowerPC
Non-AS/400 AS/400
Figure 29. AS/400 system - An integrated system
The IBM engineers in Rochester, Minnesota, designed and built the AS/400
PowerPC AS hardware to integrate with OS/400. OS/400 includes a wide array of
middleware components including a relational database, an Internet server,
system management facilities, built-in facilities for change management, backup
and recovery, and spool or print handling. It also includes communication
capabilities such as SNA, TCP/IP, and IPX; a POP3 mail server; and client
support (OS/2, Windows 3.1, Windows 95, Windows 98, Windows NT, MacIntosh,
and some UNIX clients such as IBM AIX). As a part of OS/400, these middleware
products share the same packaging, competitive pricing, user interface,
installation, maintenance, security, and management facilities.
The integration of these components in the Rochester lab ensures that the
AS/400 system does not need a skilled systems integrator at the customer site.
The AS/400 system arrives ready to start. This integration means that the AS/400
system delivers a lower cost of ownership. Studies by such consulting groups as
International Data Corporation (IDC) and Emerging Technologies Group reveal

that the more integrated a computer system is, the lower the total cost of the
solution is.
4.2 High Level Machine Interface

When the AS/400 system was first announced, the high-level user interface was
referred to as the Machine Interface (MI). Today, this is referred to as a
Technology Independent Machine Interface (TIMI).
The TIMI layer is a design boundary that separates the hardware and Licensed
Internal Code (LIC) from the operating system (OS/400). This permits the
instructions used by the compilers of high level-languages to be generic and
machine (hardware) independent. These instructions are translated to a specific
hardware instruction set as part of the back end of the compilation process.
Hardware dependencies are absorbed by the LIC (internal microcode).
The ability of the AS/400 architecture to accommodate the transition from

Complex Instruction Set Computing (CISC)-based processors to Reduced
Instruction Set Computing (RISC)-based processors is one example of
Technology Independence.
A S /4 0 0
O S /4 0 0 A p p lic a tio n s
P C A p p lic a tio n s
U N IX A p p lic a tio n s
J a v a A p p lic a t io n s
O p e n A p p lic a t io n E n v ir o n m e n t
I n t e g r a t e d M id d le w a r e S e r v ic e s
T e c h n o lo g y I n d e p e n d e n t M a c h in e I n t e r f a c e
L ic e n s e d In te r n a l C o d e
H a rd w a re
Figure 30. AS/400 Advanced application architecture
4.3 AS/400 64-bit RISC technology

AS/400 PowerPC AS RISC hardware includes 64-bit processors, data paths, and
registers. The AS/400 system's TIMI allows the technology to be changed without
impacting the middleware and applications that run on top of this interface. This
was dramatically illustrated when the AS/400 system changed its processor
technology from CISC to RISC processors or from 48-bit to 64-bit addressing.
Once the change was made, all applications could automatically take advantage
of these new hardware capabilities.

Today, OS/400 is a 64-bit operating system, and its instructions perform 64-bit
operations. Functional units can sort, compare, load, add, and subtract values
that are 64-bit. Storage addressing uses 64-bits. Data paths move data from one
location to another—64-bits at a time (for example, from the cache to the
processor). The hardware registers are 64-bits long.
OS/400 middleware is also 64-bit, including DB2/400. This middleware exploits

the 64-bit support in the operating system and hardware.
All AS/400 system applications exploit the new 64-bit architecture. Older AS/400
system applications are automatically migrated to run under 64-bit RISC
technology. They do not have to be recompiled or rewritten to support 64-bit
addressing, 64-bit data paths, or 64-bit registers.
Complete 64-bit support is a key enabler for delivering performance to

demanding applications. New applications, such as data warehousing, data
mining, or Enterprise Resource Planning (ERP) solution, such as SSA’s eBPCS,
require the movement and analysis of a tremendous amount of information. A
64-bit system can deliver a better solution.
4.4 Advanced I/O architecture

Figure 31 on page 64 shows that, in addition to its main system processor, the
AS/400 system has a range of other processors, each dedicated to a particular
input/output (I/O) device type. A single, large AS/400 configuration can have well
over 200 processors.
The main system processor (which itself can actually comprise 12 separate
processors on the latest AS/400 systems) may encounter a request for data to be
read to, or written from, any I/O device (an operation whose duration is measured
in milliseconds (10- 3 second), rather than nanoseconds (10- 9 second) - the unit of
time used to measure main storage access times). When this happens, that
request for data is delegated to the particular microprocessor dedicated to that
I/O device. Meanwhile, the main system processor continues with executing
another application program.
This design provides the AS/400 system with its outstanding performance in the
commercial, transaction-based, environment. The AS/400 system is designed for
business computing. One of the main characteristics of that environment is that it
is I/O-intensive, rather than compute-intensive.
In addition to the benefit of outstanding performance in the business

environment, this design gives the AS/400 system an elegant method of
integrating diverse environments into a single, harmonious customer solution.
The microprocessors that look after a particular I/O device are accommodated on
I/O cards that fit into slots on the AS/400 system bus. One of these cards can be
the Integrated Netfinity Server. This is a PC on a card, and enables the AS/400
system to run, for example, Windows NT server. The AS/400 system's Internet
firewall capability also exploits the Integrated Netfinity Server.
AS/400 architecture 63
Processor Processor Processor Processor Up to 12 64-bit RISC
Processors
Cache . . .
System Main Storage Bus

M ain Main
I/O Interface Storage Storage
. . . Main
I/O Interface
Storage
SPD I/O Buses PCI I/O Buses
PCI LAN
LAN Attached
Devices
IOP IOP IOP IOP IOP

IOP
DASD F ram e Relay Token Ring Tw inax Tape Future

Eth ernet ASCII O ptical Co-pro cessors
T 1 / E1 / J1
W ireless Local Talk Apple
ATM FDDI
IPCS
Figure 31. Advanced I/O architecture
Note that Integrated PC Server (IPCS) provides a 200 MHz Intel Pentium
processor with up to 512 MB of main memory. Integrated Netfinity Server (INS)
provides a 333 MHz Intel Pentium II processor with up to 1024 MB of main
memory. IBM Netfinity Server is available on all AS/400 RISC models.
4.5 Single level storage

Application programs on an AS/400 system are unaware of underlying hardware
characteristics because of the Technology Independent Machine Interface (TIMI).
In the same way, they are also unaware of the characteristics of any storage
devices on the AS/400 system, because of single level storage.
As with TIMI, the concept of single level storage means that the knowledge of the
underlying characteristics of hardware devices (in this case, the hardware
storage devices—main storage and disk storage) reside in the System Licensed
Internal Code (SLIC). All of the storage is automatically managed by the system.
Programs work with objects, and objects are accessed by name, never by
address. No user intervention is ever needed to take full advantage of any
storage technologies.
The AS/400 system can address the number of bytes that 64 bits allows it to
address. For example, 264 is 18,446,744,073,709,551,616. Therefore, the
AS/400 system can address 18,446,744,073,709,551,616 bytes, or 18.4
quintillion bytes.
Single level storage enables another extremely important AS/400 benefit—object

persistence. Object persistence means that the object continues to exist in the
memory system forever. An ordinary machine requires that information be stored
in a separate file system if the information is to be shared or if it is to be retained
for a long time. Persistence of objects is extremely important for future support of
object-oriented databases. Objects need to continue to exist even after their
creator goes away. The AS/400 system is uniquely positioned to exploit this
characteristic of object persistence, where ordinary systems use a less-elegant

mechanism that requires them to store their persistent objects in a separate file
system with all the attendant performance implications.
4.6 Logical partitioning (LPAR)

As the performance of an enterprise class server grows, so does the requirement
to divide that performance to run multiple workloads independently. Partitioning
enterprise servers has become commonplace in the mainframe market since its
introduction in the mid-1980s. Typically, separate partitions are used for test
releases of applications or to service multiple business units or companies from a
single server.
The AS/400 system implementation is an adaptation of the S/390 logical partition

concept with flexible and granular allocation of system resources. The AS/400
logical partition implementation introduces both the flexibility to allocate
interactive performance, and high-speed internal communications between
partitions (Figure 32).
OS/400®
OS/400
OS/400
OS/400
Hypervisor
SMP
IOP IOP IOP IOP
Figure 32. AS/400 Logical Partitioning
Logical Partitioning (LPAR) enables multiple independent OS/400 instances or

partitions in an N-way symmetric multiprocessing (SMP) AS/400e 7xx, 6xx and
Sxx. Each partition requires its own processors, memory, disks, and system
console, with a CD-ROM and tape drive that can be allocated to each LPAR. With
LPAR, you can address multiple system requirements in a single machine to
achieve server consolidation, business unit consolidation, mixed production/test
environments, integrated clusters, and more.
All V4R4 systems have a primary partition with all resources initially allocated to
it. Creating and managing secondary partitions is performed from the primary
partition. The movement of processors, memory, and interactive performance
between partitions is achieved with only an IPL of the affected partitions. The
movement of IOP resources is achieved without an IPL.
OS/400 is licensed once for the entire system by its normal processor group,
regardless of the number of partitions. License management across partitions is
not supported. OS/400 V4R4 must be installed on each partition. Previous
releases are not supported on any logical partition.
The following Web site is available for installation support and technical
guidance. When planning logical partitions for an AS/400 system, rely on this
Web site for information, direction, and management tips:
http://www.as400.ibm.com/lpar/
4.7 Clustering
Logical partitioning creates independent systems within a single physical box.
Clustering can be seen as a superset of logical partitioning in that it provides a
single resource view that binds together two or more physical AS/400 systems.
These can, in turn, be logically partitioned if required.
Clustering offers increased high availability of applications and data. It does this
by providing automated recovery facilities across several combined AS/400
systems (defined as nodes in the cluster). For example, through clustering, an
application can be set up to run on a primary node, with a secondary node
defined for quick failover switching, when the primary node becomes unavailable.
The switchover would include the automatic switching of communications to the
secondary node.
It is also possible to imagine a cluster containing logically partitioned nodes. An

application can run in one partition, in its own primary node, and have its backup
secondary node ready on a logical partition in another node somewhere in the
cluster. Figure 33 illustrates the concepts of clustering.
5-Node Cluster
Partitioned
Node
Cluster Control
LAN
Figure 33. Clustered configuration with a partitioned node
4.8 Object-based architecture

Objects are the means through which information is stored and retrieved on the
AS/400 system. This concept is different from typical byte-string and file
manipulation in many other systems. Object orientation is part of the architecture
and affects both the operating system implementation and high-level language
interaction with the system.

As previously mentioned, the TIMI is a boundary (set of instructions) that
separates the hardware and LIC from the operating system. The AS/400 system
instructions have an operation code and operands. Unlike many other systems,
the operands are objects, and the instructions act on objects.
Objects have operational characteristics and a defined set of operations that can
be performed on them. Objects are addressed through 16-byte pointers. Eight
bytes are used for a machine address, and the other eight bytes are used for
information about the object pointed to and for reserved space. In addition to
providing addressability to the object, pointers provide access to the associated
storage, and are used to ensure data integrity and security.
Below the TIMI, LIC provides a tag bit for each quadword (16 bytes that must be
aligned on a 16-byte boundary) within main storage. This bit is not addressable
by the TIMI instructions used to address storage (that is, programs above the
TIMI have no direct access to the tag bit). The bit identifies quadwords in storage
containing TIMI pointers. The tag bit is turned on by LIC when a pointer is set and
turned off by the hardware any time the quadword is modified. This procedure
allows the system to detect invalid pointers and prevent illegal use of a pointer.
An attempt to subsequently use this data as a pointer results in an exception and
the instruction is not completed. It is not possible to counterfeit a pointer or to
modify a pointer in an invalid way. This provides for increased integrity of the
machine against intentional or unintentional software actions.
4.9 Integrated relational database (DB2 for AS/400)

The integrated relational database manager has always been one of the most
significant facilities that the AS/400 system has provided. Relying on a database
manager integrated into the operating system means that almost all of the user
data on the AS/400 system is stored in a relational database and that access to
the database is implemented by the operating system itself. Some database
functions are implemented at a low level in the AS/400 system architecture, and
some are even performed by the hardware to improve performance.
4.9.1 Data files

Data on the AS/400 system is stored in objects called physical files (tables). An
AS/400 physical file is located within an object called library (collection). Physical
files consist of records (rows) with a predefined layout. Defining the record layout
means that you define the data structure of the physical file in terms of the
attributes of data fields (columns) that make up that particular layout.
These definitions can be made through the native data definition language of
DB2/400 called Data Description Specifications (DDS). Alternatively, the
structure of a relational database can be specified using the data definition
statements provided by the Structured Query Language (SQL).
Using DDS, you can define logical files over your physical files or tables. Logical
files provide a different view of the physical data, allowing column subsetting,
record selection, joining multiple database files, and so on. They can also provide
the physical files with an access path when you define a keyed logical file.
An SQL view is almost equivalent to a native logical file. The selection criteria
that you can apply in an SQL view is much more sophisticated than in a native
logical file. An SQL index provides a keyed access path for the physical data
exactly the same way as a keyed logical file does. Still, SQL views and indexes
are treated differently from native logical files by DB2/400 and cannot be
considered to coincide exactly. For example, SQL views can have names longer
than 10 bytes, but DB2/400 files cannot.
For more information on DB2/400 and SQL, refer to the DB2 for AS/400
Database Programming , SC41-5701; DB2 for AS/400 SQL Programming,
SC41-5611; and DB2 for AS/400 SQL Reference Guide, SC41-5612.
4.9.2 Database support

The integrated database, DB2 for OS/400, provides stability and compatibility of
previous releases of the AS/400 database with the standards-based technology
required for a heterogeneous computing environment. DB2 for OS/400 provides
compliance in the area of standards compliance coupled with advanced function,
distributed capabilities, and performance. DB2 for OS/400 provides the following
features:
• Structured Query Language (SQL) standards conformance supplies the
industry standard database access language conforming to the IBM SQL
Version 1, ANSI X3.135.1992, ISO 9075-1992, and FIPS 127-2 standards.
Support is provided for embedded static, dynamic, and extended dynamic
SQL, together with IBM's Distributed Relational Database Architecture
(DRDA), Microsoft's Open Database Connectivity (ODBC), and Apple's Data
Access Language (DAL). A Call Level Interface (CLI) server mode is also
provided that allows developers to write applications that do database serving
for multiple users.
• A new type of index called Encoded Vector Indexes (EVI) can be created
using SQL. EVIs cannot be used to order records, but in many cases they can
improve query performance.
• Declarative referential integrity preventing conflicting data from being entered
in the database.
• Stored procedures allowing the distribution of application workloads between
a client and an application server.
• Triggers that cause automatic program execution before and after database
modifications.
• Two-phase commit transaction management to allow access to multiple
heterogeneous databases simultaneously.
• Data replication automatically in distributed DB2 family environment.
• System-wide database catalog allowing applications to query information
concerning all objects on a system using a single system catalog.
• Multiple-level concurrency control providing read stability, cursor stability,
uncommitted read, and no commit isolation levels.
• National Language Support to store data in a preferred language, character
set (single and double byte), and a sort sequence.
4.9.3 DB2 Universal Database (UDB)

DB2 for AS/400 has long provided facilities to address most customer
requirements. With V4R4, AS/400 support has been extended to include new

forms of information previously stored on the AS/400 system, but not managed by
DB2 for AS/400. With this release, DB2 Universal Database (UDB) for AS/400
now supports the storing, managing, and indexing of all forms of information
including binary objects (such as spreadsheets, word processor documents, and
multimedia objects) within the database. This support includes such features as
Binary Large Objects (BLOBs), user-defined functions, complex objects,
query-by-image content, and even spatial extenders. All of these features allow
customers to use one database management system to store, retrieve, and
manage all of their corporate information.
Performance and functional enhancements to the DB2 Universal Database for

AS/400 improve the processing of business intelligence queries. These
improvements include:
• The hash "group by" algorithm improves performance of grouping queries for
a large number of groups.
• The performance of MIN and MAX functions is improved with a suitable index,
if available to determine the minimum or maximum value of a query.
• Derived tables and common table expression support allow complex business
intelligence queries to be written without the use of views.
• Support for expressions in the GROUP BY and ORDER BY is also added.
• The QAQQINI file support allows the system administrator to set query
specific options (query time limit and query degree) in a source file similar to
QAQQINI file support used by PC applications. This aids in setting query
options for client/server-based applications.
IBM provided the following enhancements to DB2 Universal Database for AS/400
through the 1999 Database Enhance Pak or Group PTF SF99014.
• Large object support
With the addition of large objects (LOBs), DB2 Universal Database for AS/400
can store and manipulate data fields much larger than the current limits. An
AS/400 record with LOB fields can hold up to 15 MB of data. With the new
LOB support, you can look to DB2 Universal Database for AS/400 as a
platform for building applications that hold new data such as very large text,
image, and audio data.
• DATALINK data type
The DATALINK data type extends the types of data that can be stored in
database files. The actual data stored in the column is only a pointer to the
object such as an image file, a voice recording, or a text file. The method used
for resolving to the object is to store a uniform resource locator (URL). This
means that a row in a table can be used to contain information about the
object in traditional data types, and the object itself can be referenced using
the DATALINK data type.
DATALINKs also allow the referenced object to be "linked" to the database in
such a way as to prevent modification or deletion of the object while it is linked
to the database file. This relationship is maintained by having the database
interact with the file system that contains the object.
• User-defined types
User-defined types are derived from existing predefined types such as integer
and character. You can create your own types for strong typing and creating
functions for different types. You can call a function for each row of a result set
and return a value based on the user-defined type.
• User-defined functions
SQL now lets you define your own functions to use within the SQL itself. This
saves you time in reusing common building blocks that you develop yourself.
User-defined functions are necessary building blocks to support the database
extenders (extensions to support rich text and multimedia search and
manipulation) currently supported on UDB.
4.10 Data management

AS/400 system applications communicate with traditional, Non-Programmable
Terminal (NPT) display devices through display file objects , with printer devices
through printer file objects, and with standard AS/400 system database files
through database file objects.
The AS/400 system display file record format contains screen field definitions and
other screen control parameters. The screen field definitions can optionally obtain
their attributes from a database file field through a reference function. DDS is
used to define the display file record, database file record, and field attributes.
When a standard DDS file is used, AS/400 system workstation management is

responsible for formatting the device dependent data streams on output and
unformatting on input. The AS/400 system database file object defines record
field definitions and optionally identifies key (index) fields. The database field
definitions can also optionally be defined by referencing other database file field
definitions.
In most AS/400 system applications, the workstation and database field

definitions are integrated during the compile (create program) step. This is
referred to as externally described file support.
In addition to display, printer, and database interfaces, the AS/400 system

provides message queues, data areas, data queues, and others (for example,
Portable Operating System Interface Standard (POSIX) compliance).
4.10.1 Integrated file system (IFS)

To position the AS/400 system as a server-of-choice serving the major clients
such as PC clients, UNIX clients, and the AS/400 system clients themselves, you
must first implement each client's file system on the AS/400 system as natively as
possible.
The Integrated file system (IFS), including / (Root), QOpenSys, QFileSvr.400,

QSYS.LIB, QDLS, QOPT, QLANSrv, user-defined file system (UDFS), Network
File System (NFS), QNTC, and QNetWare, is a part of OS/400 that supports
input, output, and storage management similar to the PC and UNIX operating
systems. At the same time, it provides an integrated structure over all information
stored in the AS/400 system (Figure 34 on page 71). For more information on
IFS, refer to the OS/400 Integrated File System Introduction , SC41-5711.

A S /4 00 U se rs
A p p lic a tio n s IF S
A P Is M e n u s /C o m m an d s
O S /40 0
F ile NFS N etW a re NT
S e rve r S e rve r S erv er S erve r
In teg ra ted F ile S ys tem In terf ace
" R o o t" Q NTC

Q O p en S ys UDFS Q L A N S rv
F ile FS FS
F ile S y stem FS Inte g ra te d
S ystem
N e tfin ity
Q S Y S .L IB QOPT NFS Q F ileS v r.4 00 Q N etW a re S e rv e r
FS FS FS FS FS
Figure 34. Integrated file system
The key features of the IFS are:

• Support for storing information in stream files
• A hierarchical directory structure
• An integrated interface to access stream files, database files, documents, and
other objects stored in the AS/400 system
4.11 System management

Integrated with OS/400 are a number of system management functions that are
key to lowering the cost of ownership of the AS/400 system solution. These
functions include:
• Job management: OS/400 includes an environment to manage jobs for
users, operators, and programmers. An operator can look at all of the jobs
running on the system, or select only those associated with a specific queue
or user. They can sort them by CPU usage, view their properties, change their
priority, stop them, or delete them within the limitations of authority granted to
the operator.
• Printer management: The AS/400 system has a print output environment. An
operator can select what output to see: by printer, user, or queue. With the
printer management facilities, an operator can route the output to a different
printer, change the number of copies, print only selected pages, or print
duplex copies. AS/400 system print jobs can also be sent or mailed to other
AS/400 systems and users. Plain text print output can be viewed on the
AS/400 system before being printed. When using Advanced Function Printing
(AFP), Client Access/400 provides a viewer so a user can see the actual
AS/400 printed output (text, forms, or graphics) before it actually prints.
• Backup and recovery: OS/400 has a backup scheduling application that
allows an administrator to easily create a daily, weekly, and monthly backup
plan along with other scheduled tasks. The administrator selects what to back
up, where to back it up, and when to back it up.
• Managed availability: V4R4 introduces AS/400 Logical Partitioning (LPAR),
which enhances the role of the AS/400 system as a consolidated server. LPAR
provides the capability to run multiple independent OS/400 instances or
partitions (each with its own processor, memory and disks, in an N-way
symmetric multi-processing AS/400 system). With LPAR, companies have
both the power and flexibility to address multiple system requirements in a
single machine. LPAR is valuable to customers for server consolidation,
business unit consolidation, mixed production, and test environments, as well
as integrated clusters. AS/400 clustering is taking a major step forward with
the introduction of Cluster Resource Services as part of OS/400 V4R4 (APIs).
The complexity of managing systems in a cluster and keeping track of data
and applications is now handled by OS/400 V4R4. Protecting your business
from unplanned and planned outages, as well as site loss disasters, is easier
than ever. Cluster management and enhanced data resilience applications,
both provided by high-availability business partners, complete the total
solution.
• User management: When a new user is added to OS/400, besides entering
the user ID and password, an administrator can specify the maximum amount
of disk space the user can use to store information, the maximum priority at
which any of their jobs run, and accounting information for tracking AS/400
system resource consumption by the user and several other attributes. The
administrator can also specify the output queue and message queue for the
user, the language and sort order for the user, and integrate the user ID and
password with Novell NetWare, or OS/2 Warp Server for AS/400 running on
the Integrated Netfinity Server (or Integrated PC Server) or with Domino for
AS/400 running on the AS/400 natively.
• National Language Support (NLS): The AS/400 system has national
language support for over 50 languages and can support multiple languages,
sort sequences, and character sets per system. With this support, one user
can interact with the system in German, while another user converses in
French. Unicode (UCS-2) support is also available.
• Problem management: A complete problem management application is
included with OS/400. This support allows administrators to track, analyze the
causes of, prioritize, and report to IBM the problems associated with the
computing environment. The AS/400 system keeps track of the installed
products, release levels, and program temporary fixes (PTFs) that were
applied.
• Software fixes : Individual software fixes or PTFs can be applied to LIC,
OS/400, and licensed programs either permanently or temporarily. The benefit
of applying a fix temporarily is that it can be applied, tested, and removed if it
is appropriate to do so.
With advanced, built-in management features, the AS/400 system is a reliable,

secure, and virtually self-sufficient computing system. In case something goes
wrong, the AS/400 system also comes with all of the services and support for
which IBM is traditionally known.
Electronic Customer Support (ECS) is a direct electronic link to IBM marketing,

administration, technical, and service operations. ECS gives users and technical
staff on-line advice and provides configuration management assistance, problem
determination, and other service needs. ECS simplifies the PTF ordering
procedure by enabling the speedy receipt and application of PTFs, and quicker
problem resolution. The Copy-Screen facility permits a more accurate
user-to-specialist problem description, and direct electronic contact with AS/400

system specialists. ECS support is provided for software problems (LIC,
operating system, licensed programs and third-party applications), as well as for
hardware problems.
In addition to ECS, AS/400 system customers (under warranty or an IBM

maintenance agreement) may receive Service Director support. Service Director
monitors the AS/400 system in real time. When an error is entered into the
problem log, it is immediately and automatically analyzed and reported to IBM
through the ECS function on the AS/400 system. The problem is fed into IBM's
remote technical assistance information network and IBM's resources are used to
evaluate the situation. If a PTF is available that corrects the problem, it can be
downloaded to the AS/400 system. This can significantly reduce overall
downtime.
In addition to these system management facilities, other IBM and third-party

products are available to manage larger and distributed AS/400 system
environments. These products provide support for software distribution, client
management, performance analysis, capacity planning, and more.
4.11.1 Management Central

A suite of system management functions known as Management Central has
been integrated into Operations Navigator. These functions include:
• Collection services
This tool for collecting and managing performance data replaces the
traditional performance monitor function with a low-overhead, automated, and
on-going data collector. Data is captured with reduced system impact.
Processing occurs only if and when needed. Additionally, collection services
lets you control what data is collected and how that data is managed.
Each type of data supported by collection services can be controlled
individually without data loss or affecting the collection of other data.
A compatible performance monitor database is created based on the data in
the management collection object. However, you can defer the creation of the
database until a later time.
Collecting performance sample data is enhanced by:
– Reducing the impact of collecting performance data, especially on large
systems
– Allowing flexibility in the data collected
– Simplifying the management of performance data
– Promoting automated, continuous data collection
• Object packaging
The object packaging and distribution graphical interface provides an easy
way to send objects from any file system to one or more AS/400 systems in a
network. You can also restore objects, take snapshots of the objects, version
packages of objects, and post execution of commands. All of these functions
can be performed on a group or network of AS/400 systems and be scheduled
to occur at a time most convenient for your staff.
• PTF management for a distributed environment
If managing PTFs among several AS/400 systems is too complicated, the new
PTF management wizards are for you. The easy-to-use wizards walk you
through comparing the PTF levels of multiple AS/400 systems to a model
system that has a proven set of PTFs already installed. You then distribute
and install any missing PTFs on the remote AS/400 systems by simply
identifying the system or group of systems to be updated. You can run AS/400
commands as part of completing PTF installations or as part of normal
day-to-day operations.
• Inventory for multiple systems
With the new graphical interface, you can schedule regular inventory
collections of hardware, software, and PTF information for a group or network
of AS/400 systems. From the data collected, you can search for a specific
piece of information, export the information to a PC application for analysis, or
just compare information in multiple systems.
4.11.2 System management facilities

A variety of tools and functions are available to provide system availability and
management. Some are discussed in this section:
• System Managed Access Path Protection (SMAPP)
SMAPP supports and automates the process of selecting which access paths
should be protected. The system uses the EDTRCYAP value to estimate the
amount of journaling to perform. The shorter the time that is in this value, the
more journaling takes place, which impedes system performance, but it leads
to shorter IPLs. The longer the value is, the longer IPLs are. However, the
impact of journaling on CPU and DASD utilization is less.
• Expert Cache
Expert Cache provides a disk cache tuner option, which allows the AS/400
system to take advantage of available main storage capacity. It dynamically
responds to system jobs to cache pages of data in main storage to reduce the
time to process disk I/O.
• Integrated Hardware Disk Compression
Beginning with OS/400 V4R3, the compression of data on disk is supported by
OS/400. Data is dynamically compressed and uncompressed by the DASD
controller as data is written to and read from disk. Disk compression does not
affect the main CPU utilization since this function is performed by the DASD
controller IOP.
Support for Integrated Hardware Disk Compression is only provided by PCI
DASD controllers (#2741, and #2748) and SPD DASD controllers (#6533 and
#9754). In V4R3, the 17.54 GB drives are not supported. However, V4R4 of
OS/400 adds support for compression on 17.54 GB drives. Compression is
limited to user ASPs.
• Hierarchical Storage Management
OS/400 includes Hierarchical Storage Management (HSM) APIs that are used
by Backup and Recovery Media Services (BRMS), 5769-BR1, to provide HSM
functions. These APIs can also be used to develop custom HSM applications.
The APIs are documented in AS/400 Hierarchical Storage Management,

SC41-4450. Refer to the following Web site for more information on BRMS
and HSM: http://www.as400.ibm.com/hsmcomp
• Internet PTFs
Beginning with V4R3, AS/400 customers can download PTFs over the
Internet. The client hardware needed is a PC with Windows 95 or Windows
NT, a TCP connection to the AS/400 system over a LAN, and access to the
Internet. The various configurations and set up information are documented
on the Web at: http://as400service.rochester.ibm.com
Except for the medium of transport (Internet), the functionality is the same as
the ECS method of transport. The user selects the PTFs and options using a
Web browser and submits the order. At the referenced Web site above, the
user can also search on PTF cover letters and read them before the order is
even placed. The same entitlement rules that apply on the ECS connection
are enforced. In other words, if a user can acquire PTFs electronically over the
ECS, they can acquire PTFs over the Internet.
4.12 Storage management

One of the key resources on any computer system is the disk space that stores
the data, applications, and programs. The management of this storage space is
critical for an efficient and high performance server installation. Storage
management on the AS/400 system is automated. The AS/400 system takes care
of selecting the physical disk drive (DASD) to store the data, spreads the data
evenly across the disk arms, and continues to add records to files until specified
threshold levels are reached.
AS/400 system storage management uses single level storage (SLS). With single
level storage, there is a single, large address space for all storage (both main
storage and disk storage). Storage is addressed using a 64-bit (8-byte)
addressing structure. When an object is created, it is defined in a unique virtual
address space. There is a single page table (sometimes referred to as a page
directory) that maps all virtual addresses to corresponding physical addresses.
The benefits of single level storage include:
• All applications use one address space on the AS/400 system. Switching
processes (for example, from database to Internet) requires little time. There
is no need to flush out one address space and bring in another one.
• With single level storage, there is no need for swap or paging space. When
data needs to be moved out of memory, it goes directly to its permanent
location on disk. It is not written first to a swap file and then its permanent
location. AS/400 system disk space is not wasted for swap files.
• With single level storage, all information is in one large address space
regardless of it being in memory or on disk. All objects appear to be in
memory. When a program wants to reference data, it simply references it by
its address. There is no need for the program to translate addresses or go
through a lengthy process to determine where the file exists on disk. With disk
and memory managed through a common address space, the system can take
advantage of increased memory without requiring any complex memory
management activity.
• Single level storage also holds tremendous promise for object-oriented
programs such as Java. With the ability to have shared persistent objects, the
AS/400 system can eliminate the processing required on other systems to
hydrate and dehydrate objects.
Single level storage is a key reason why the AS/400 system is easy to develop
applications for, can support multiple applications, and is scaled to support a
large number of users. Single level storage, combined with the automated
storage management capabilities, makes the AS/400 system an easier system to
manage.
The AS/400 system customer can manage disk space on the AS/400 system as a
single entity. The disk space can be used by all of the applications. The system
determines when and where to extend individual files and spreads the data
across the disk arms to maximize performance. The system keeps track of the
disk usage and warns the AS/400 system administrator when the disk space in
the system Auxiliary Storage Pool (ASP) reaches a specified threshold value.
Advanced AS/400 system installations can deploy other disk management
options to increase control of the space management process.
OS/400 has sophisticated space allocation routines to create and store

information in the right size spaces. These routines look for the right sized block
versus selecting the first available block, regardless of size. The objective of
these routines is to effectively use the disk space by reducing file and free space
fragmentation. The AS/400 system automatically consolidates disk space
fragmentation where possible and also has a separate disk fragmentation utility.
4.13 Security, user profiles, and authority management

The AS/400 system has an outstanding reputation as a mission-critical
commercial server. Part of this reputation is due to the security of the AS/400
system. OS/400 has a single integrated security model. This security model is
shared by the operating system, database, mail, systems management, the
Internet, and communications functions. You can add a user once to OS/400, and
they can have access to all the appropriate components. These include OS/2
Warp Server and Novell NetWare on the Integrated Netfinity Server or Domino for
AS/400 running natively on the AS/400 system.
OS/400 has a single directory, which is the system distribution directory. This
directory is used by OS/400 e-mail (POP3 and OfficeVision) and Domino for
AS/400.
The AS/400 system has C2 security certification from the U.S. Department of
Defense and is the only computing system to have received certification for both
a database and operating system as a unit. The AS/400 system configuration that
was certified was a functional configuration that included non-programmable
terminals.
The AS/400 system has an object-based system architecture (see 4.8,

“Object-based architecture” on page 66). Everything is an object (including data,
programs, files, and so on) and is subject to object rules. These rules describe
what can be read, changed, deleted, or added, and by whom or what. The
AS/400 system checks those rules before it touches any object. This basic and
underlying capability provides AS/400 system customers with a powerful security
capability within their system. In addition, program objects have special rules that
do not allow them to run unless they are properly encapsulated by the system.

This makes the AS/400 system extremely virus resistant. AS/400 system objects,
including programs, files, and databases, are protected by the OS/400 security
mechanisms. When correctly implemented, this protection cannot be
compromised by someone who merely has access to the machine.
System authorization management is based on user profiles that are also objects.
All objects created on the system are owned by a specific user. Each operation or
access to an object must be verified by the system to ensure the user's authority.
The owner or appropriately authorized user profiles may delegate to other user
profiles various types of authorities to operate on an object. Authority checking is
provided uniformly to all types of objects within a file system.
The object authorization mechanism provides various levels of control. A user's

authority may be limited to exactly what is needed.
4.14 Work management

In the AS/400 system operational environment, work is managed by one or more
OS/400 subsystems and LIC. All system and user jobs run under the control of a
subsystem while LIC performs the actual task management according to
user-specified and internal priority schemes.
Subsystems are provided to permit job grouping for ease of CPU control and
main memory. The assignment of jobs to separate or shared main memory pools
can be accomplished within a single subsystem or managed by separate
subsystems. User jobs may be assigned to IBM-supplied or user-defined
subsystems.
4.15 Summary
The AS/400 system has the most brilliant architecture found on any business
computing system. There are many examples of where the AS/400 system's
architecture has delivered on its promise of making the most advanced
technology readily and continuously available to its customers. The AS/400
system has enabled its customers to:
• Integrate diverse environments (such as Microsoft Windows NT and Lotus
Domino) into the AS/400 system. All customer solutions require a range of
hardware and software products from a variety of vendors. The AS/400
system, through integrating these mixed environments, simplifies the task of
managing them.
• Move from CISC processor technology to RISC processor technology without
needing to recompile programs. Programs are saved off the CISC systems,
restored on the RISC systems, and run as fully 64-bit applications. On
ordinary machines, recompilation is necessary (sometimes some rewriting),
and the resulting programs do not fully exploit the 64-bit hardware.
The AS/400 system’s future-oriented architecture has enabled us to take

rapidly-changing hardware and software technologies in stride. This same,
flexible architecture will continue to serve us well in enabling our customers to
continue deploying the latest technologies, while causing the minimum possible
disruption to their work.
Chapter 5. eBPCS sizing
For any ERP implementation, one of the main questions is: How much hardware
will the application need to run my business? SSA has developed a rigorous
sizing process to help clients answer that question. Starting in late 1998, SSA
and IBM have been jointly administering the sizing process. Under the
partnership agreement, SSA develops the sizing tools, and the IBM ERP sizing
center processes and logs all sizing activity. The net result has been a consistent
and reliable sizing process regarded by the industry as "best of breed".
SSA and IBM encourage all BPCS users who are planning an upgrade, adding
additional users, or purchasing new software to complete a sizing questionnaire.
The sizing process is the single best tool to help determine production machine
size. The sizing tools have been developed for all supported versions of the
BPCS product line. As new products or changes to the existing line are
developed, the sizing tools will be updated to reflect any changes in the
performance characteristics of the products.
Please contact your local SSA or IBM representative for assistance in

commencing a sizing exercise. Sizing is not a trivial task and should only be
attempted with expert guidance by a trained SSA representative.
5.1 Sizing methodology

The primary aim of the benchmark was to provide a tool for use internally within
SSA, and externally by SSA's Partners, to size eBPCS for existing customers and
new prospects. This was achieved by "exercising" the software in true business
scenarios, capturing the main system characteristics, and with the IBM BEST/1
software, producing a series of workloads that can be used to estimate as
accurately as possible the AS/400 requirements.
The work was performed in the IBM Customer Benchmark Center, which is part of
the IBM Development Laboratories in Rochester, Minnesota. A set of business
scenarios were built based on discussions held with an existing client, and from
experienced field personnel adding their own scenarios. These scenarios
covered most of the BPCS products used by the majority of our customers.
Scripts were prepared which detailed each business transaction. These identified
if variables would be required for such input as "Item", "Customer", etc. Using the
Mercury Scripting tools in the Chicago Performance Center the "English" scripts
were recorded and tested. In Rochester, the scripts were debugged and tested,
and the database was amended where necessary.
Information from the customer was used to ensure that the correct Customer and
Item combinations would be used to represent the right complexity of customer
orders. This was fed into tables for use within the scripts.
The database did not contain any General Ledger or Manufacturing data. This
was created both manually and by using the scripting tools to provide realistic
volumes of data.
Each of the scripts was combined into scenarios that were executed
automatically by the tools. This involved defining the number of times each

process was executed within the main script. The main scripts represent the
"Workloads" to be used in the sizing tool. The workloads were run individually at
first to allow data to be collected by the performance tools for use in the BEST/1
sizing tool. Then, the scripts were run in tandem to fully exercise the AS/400
system. The results were modeled in BEST/1 to form a capacity planning tool for
eBPCS.
A questionnaire was developed to allow the individual client a means of inputting

data into the BEST/1 sizing model. The questions were designed to aid the client
in describing their business transactions in terms the sizing process can
understand. This information allows SSA to provide the client with an estimate of
the processor class and memory. The accuracy of the sizing estimate depends on
many variables such as the accuracy of the information provided by the customer.
SSA recognizes that it may be difficult to provide exact numbers on your
environment and the actual usage of the system in a production environment.
Sizing is an iterative process.
5.2 What is a session?

As you read through the sizing example, the definition of what makes up an active
session may not be apparent. The sizing assumes a very precise definition of an
active session. The understanding of the context of the term is important to the
success of the sizing process. For the purposes of AS/400 CPU sizing, an active
session is any device, terminal, or PC window that is actively conversing with the
AS/400 system.
If a PC has two green-screen sessions up and running BPCS applications, two

active sessions can be counted. In effect, one user is occupying two active
threads into the AS/400 system and, as such, is using twice as many resources
and a user who has one active session.
5.3 AS/400 sizing example

Take a few minutes to read through the following example of how to complete the
sizing questionnaire. SSA hopes it will expedite your collection of data by
providing the necessary transaction workload done through the many eBPCS
applications that your company will be running.
First, create a time line that graphs each application's workload from its starting
period through its peak time to when the workload is at a minimum. This time line
could turn out to represent a day, a week, a month, a quarter, or even a year. It all
depends upon your business environment. A peak hour graph should be created
as shown in Figure 35 on page 81.

Figure 35. Peak hour sizing graph
Once this graph or image is complete, next, identify a peak hour of workload
where the CPU is going to be the busiest. This is the transaction workload you
will record on the following pages.
This questionnaire captures the peak workload transactions generated by only

those eBPCS applications that are active during this peak hour. All other
workload transactions should not be recorded in the sizing questionnaire that are
outside of this peak time. If the transactions are recorded, they will lead to a
sizing estimate that is more than necessary to handle the workload. The theory is
that if the system is sized for the peak workload, where the CPU is going to be
the busiest, then SSA can provide a system sizing estimate to handle this peak
workload with acceptable response times. All other workloads outside of the peak
workload period should also provide acceptable response times on the same
CPU.
As you are recording your information on the peak workload transactions,

remember to record the number of active users performing this work. This user
information is necessary for SSA to properly determine the amount of system
memory necessary to support your application workload.
For the chart shown in Figure 35, the lines going across the graph represent the
eBPCS applications and the use of each application throughout the time line. If
you were to then study the graph, you could determine how the combined
application workload would effect a CPU running the application. The smooth
thick line represents the CPU workload and if you were to identify a peak hour of
activity, this would be represented by the vertical lines drawn.
Once the peak workload is identified, the transaction data and number of active
sessions representing this workload need to be recorded on the sizing
eBPCS sizing 81
questionnaire. For our example, the workloads and transactions are recorded as
shown in Table 15.
Table 15. Sizing questionnaire
Local Remote Totals
LAN WAN Sessions Transactions
Accounts Payable - payment - scenario
Active sessions 2 2 4
Number of payments selected per hour 12 12 24
Number of manual payments per hour 1 0 1
Accounts Receivable scenario
Number of customer invoice inquiries 10 20 30

per hour
Number of cash or memo postings per 20 20 40

hour
Configurable Enterprise Accounting scenario
Number of manual journals lines per 6 12 18

hour
Number of account inquiries per hour 5 10 15
Goods in scenario
Number of receipts from suppliers per 20 10 30

hour
Number of finished goods from factory 58 22 80

per hour
Order entry - Simple
Number of orders per hour 110 0 110
Number of order lines per hour 6 0 6
General sessions (Operators, etc.)
Application development sessions
Total active sessions 35
SSA will use this is the information to provide a system sizing estimate since the
sizing tool is based on measuring the peak workload transactions. Even though
you may be running additional eBPCS applications, these individual workloads

are not present during the peak time of the day and should not be recorded on the
sizing questionnaire. The SSA representative will take the completed sizing
questionnaire and forward it to IBM for processing.
5.3.1 Workload definitions

These definitions describe which transactions were included in the measured
workload. The questions in the questionnaire should be answered only for the
transaction expressed, not for each of those described in the following list:
• Accounts Payable Invoice scenario:
– Vendor Alpha Lookup
– Invoice Entry
• Accounts Payable Payments scenario:
– Payable Inquiry
– Payment Selection
– Cash Requirements Report
– Make Payments
– Manual Payments
– Bank Statement Posting
– Payments Inquiry
• Accounts Receivable scenario:
– Customer Inquiry
– Cash and Memo Posting
• CEA scenario:
This represents users of the client/server CEA product. It does not refer to all
financial products (see Accounts Payable and Accounts Receivable workloads
above). The CEA workload profile assumes that an Active User Session will
process a mixture of transactions, similar to the following examples:
– Enter Manual Journals with multiple lines per journal
– Perform Account Inquiries
– Perform FRW Builds and Downloads, which create extract files of financial
data from the AS/400 system for download to the client.
• Goods In scenario:
– Receive Raw Material or Packaging items from suppliers
– Review Purchase Order details
– Approve batches of lot-controlled material received
– Receive Finished Goods into Distribution Center from factory
• Inventory Control scenario:
– Perform stock adjustment inventory transactions
– Move stock between locations
– Review inventory balances by item, facility, warehouse and Lot/location
and transaction history
• Manufacturing Data Management scenario:
– Review Bills of Material
– Create New Item Masters
– Revise Bill of Material
– Create new Routing
eBPCS sizing 83
• Miscellaneous (eBPCS) scenario:
This workload should be used to represent any user that does not fall into any
of the other specified categories. It was measured using a mix of the following
transactions:
– Review Costed Bills of Material
– Review Inventory Balances by item, facility, warehouse and lot/location,
and transaction history
– Forward and backward Lot Trace
– Review Bills of Material
– Review Production Planning Data, switch to pegged demand
– Review Master Schedule Detail
– Review Re-supply Planning Data, switch to pegged demand
• Production Planning scenario:
– Amend Due date/Quantities on Planned Orders
– Select Planned Orders for Release
– Release and Print Selected Planned Orders to create shop orders
– Review Capacity Loading
– Review Production Planning data, switch to pegged demand
– Review Master Schedule Detail
– Review Re-supply Planning Data, switch to pegged demand
• Purchasing scenario:
– Create Purchase Orders Manually
– Print manually created Purchase Orders
– Select, Release and Consolidate Planned Purchase Orders
– Automatically Release Scheduled Orders (for example, those with
contracts)
– Review Purchase Order Details
– Print Scheduled Purchase Orders
• Sales Administration scenario:
– Review Planned Re-supply Orders
– Review Customer Account Details
– Review Customer Sales History
– Review Customer/Item X-reference Information
– Review Customer Order Details
• Shop Floor Control scenario:
– Manually Raise Shop Orders
– Print Released Shop Orders
– Reprint Shop Orders
– Enter Labor Tickets
– Post Labor Tickets
– Enter Labor Tickets that allow components to be issued automatically
– Post Labor Tickets and automatically issue components to shop orders
– Manually Issue Components to shop orders
– Receive End Products on shop orders
– Review Shop Order Transactions
• Simple Order Entry scenario:
A mix of multi-line orders: customer lookup on each order and item lookup on
each item. Each line has a single promotion associated with it.

• Multi-Currency Order Entry scenario:
As above, with the addition of multi currency.
• Complex Order Entry scenario:
As in Simple Order Entry, but with COMPLEX promotions.
• Simple EDI Order scenario:
A mix of multiline orders being entered electronically. The workload assumes
the order is being posted using the standard eBPCS order posting logic. Each
line has a single promotion associated with it.
• Multi-Currency EDI Order scenario:
As above, with the addition of multi currency.
• Complex EDI Order scenario:
As in Simple Order Entry, but with COMPLEX promotions.
• Application development sessions:
This represents the number of people performing development tasks. This can
be program writing, debugging, testing, etc.
• Operator sessions:
This represents the number of AS/400 operations people who will be
constantly active during the peak hour.
5.4 Execution
Figure 36 on page 85 outlines the flow of the SSA/IBM sizing process. The
process is designed to provide a consistent and repeatable result given the same
input. The SSA representative has been trained to assist the client in properly
completing the sizing questionnaire. Currently, only SSA representatives have
access to the sizing questionnaire from OGS.
Figure 36. IBM ERP Sizing Center flow model
eBPCS sizing 85
Chapter 6. Installation or migration to eBPCS V6.1.00
This chapter discusses the preparation required for installing e BPCS and
migrating from an existing release. Detailed instructions are shipped with eBPCS
products. These instructions guide you through the initial installation of the
product. Full configuration of the software is not covered under the installation
guide. However, basic system parameter initialization is covered in the guide.
Product specialists should determine the set up and parameters for each product
in eBPCS.
6.1 Installation documentation for eBPCS and other SSA products

The instructions for installing eBPCS server software are found by installing the
eBPCS client software on the PC. The PC client software installs automatically
with a self-extracting executable and a README file. Once installed, the server
installation documentation resides inside a directory called DOC under the BPCS
directory structure. There are several folders containing other useful BPCS
documentation as well. The installation instructions are in a folder called
DOC/INSTALL/AS400.
The installation documents are labeled for either Full Client/Server or

Mixed-Mode installation. Be sure to use the proper installation document for your
release of eBPCS. Be sure to read the documentation thoroughly before
beginning the installation.
For most other eBPCS products such as SMGs and AS/SET ADK, which do not
have a PC Client piece of software, the installation documentation is on the same
CD-ROM as the server software. Simply load the CD-ROM into a PC drive and
print out the installation documentation. An insert inside the jewel case of the
CD-ROM software should give you instructions about where the installation
documentation is located. This information is also available on OnGoing Support
(OGS) Online if you do not have access to a PC to obtain this information.
6.2 General preparations and pre-requisites

Review this list of tasks and pre-requisites to prepare for your installation:
• IBM PTF pre-requisites for various OS/400 release levels can be found in
Informational APAR II11801.
• You must be at V4R2 or higher of OS/400 to install eBPCS.
• You should have access to the AS/400 system from your PC network, for
Mixed-Mode via APPC or TCP/IP.
• TCP/IP should be configured on your AS/400 system if you will be using Full
Client/Server eBPCS. It is recommended for better performance when running
Mixed-Mode Client/Server.
• If you have purchased source for eBPCS and wish to modify or compile it, an
RPG compiler is required as well as the SQL Development Kit.
• If you will be using SMGs or modifying Electronic Commerce Manager (ECM)
batch programs, a C compiler is also recommended.

• If you are using ODW and will be modifying Client/Server eBPCS, an ILE RPG
and ILE C compiler are required on the server. Additional hardware and
software requirements for this product are listed on OGS Online in the System
Requirements documentation.
• Before beginning your installation, refer to the OGS Online Product Bulletins
page to see if there is any late breaking information about your release.
6.2.1 Sizing
We strongly recommend that your system be sized by SSA. See Chapter 5,
“eBPCS sizing” on page 79 for the sizing process. That was specifically
developed by SSA and IBM to determine the optimal sized system for your
installation and needs.
6.2.2 System requirements

Hardware and DASD space requirements for both PC and AS/400 hardware is
located on OGS OnLine for each product. This information is in a document
called V6.1.00 (eBPCS) System Requirements. This is found under the Product
Support link on OGS as shown in Figure 37.
Figure 37. Product Support on OGS - System requirements
6.2.3 Software keys and other miscellaneous requirements

SSA software license keys, access to an AS/400 user profile with *SECADM and
*ALLOBJ authorities, and access to a CD-ROM drive on the AS/400 system are
all required to install the software. You should obtain your software key from your

SSA representative prior to installing the software. Software installation requires
this key. You cannot complete the installation without the key.
eBPCS is supplied on CD-ROM media for installation on the server. Appropriate

drive hardware is required to load eBPCS onto the AS/400 system. Client
software is furnished on CD-ROM. A CD-ROM drive is required to install eBPCS
to the network server. Installation on individual PCs, where required, is achieved
either by installing directly onto the PC, in which case a CD-ROM drive is
required on the PC, or downloading from the PC network server.
6.2.4 Notes on TCP/IP configuration for Full Client/Server eBPCS

Proper TCP/IP set up is crucial to the operation of the Client/Server runtime
software in the Object Messaging System (OMS) library, commonly known as the
"NEWI" library. In general, the default configuration on the AS/400 system may be
used.
Specifically, ensure the following default configuration is present for proper OMS
operation:
1. Ensure TCP/IP interface is configured for a *LOOPBACK (Figure 38).
Work with TCP/IP Interfaces

Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display 9=Start 10=End
Internet Subnet Line Line

Opt Address Mask Description Type
10.1.47.52 255.255.255.0 CHI400ATR1 *TRLAN

127.0.0.1 255.0.0.0 *LOOPBACK *NONE
Figure 38. TCP/IP configuration - *LOOPBACK
2. Ensure the *LOOPBACK interface is running with this command:

WRKTCPSTS *IFC
The screen shown in Figure 39 should appear.
Work with TCP/IP Interface Status

5=Display details 8=Display associated routes 9=Start 10=End
12=Work with configuration status 14=Display multicast groups
Internet Network Line Interface

Opt Address Address Description Status
10.1.47.52 10.1.47.0 CHI400ATR1 Active
127.0.0.1 127.0.0.0 *LOOPBACK Active
F3=Exit F4=Prompt F5=Refresh F11=Display line information F12=Cancel

F13=Sort by column F24=More keys
Figure 39. TCP/IP configuration - WRKTCPSTS *IFC
3. Ensure that the DHCP is not set for "multiple homing". This is available only at
V4R4 and higher releases of OS/400. At the time this redbook was written,
Installation or migration to eBPCS V6.1.00 89

this interface does not work with OMS. This could cause the OS/400
UNIX-style API gethostbyname to resolve to two local hosts, instead of one.
4. Ensure that the Host table (CFGTCP option 10) has a correct value for
*LOCALHOST, and ensure that interface (usually LOOPBACK) is active under
option 1 (Figure 40).
Work with TCP/IP Host Table Entries

1=Add 2=Change 4=Remove 5=Display 7=Rename
Internet Host
Opt Address Name
10.1.49.52 SSAUSCHX
127.0.0.1 LOOPBACK
LOCALHOST
Figure 40. TCP/IP configuration - Host Table Entries
5. If you are using a Domain Name Server, ensure that searching *LOCAL first is
enabled for better performance. The OMS code for each instance of BPCS
which is started will resolve to "LOCALHOST". This lookup is faster if it is
configured on the AS/400 system and the AS/400 system searches the local
host table first.
6. Ensure that any DNS named listed is truly active and working. Ensure that
remote Internet DNS locations are truly active and are listed with the correct
IP address (CFGTCP option 12). See Figure 41.
Change TCP/IP Domain (CHGTCPDMN)
Type choices, press Enter.
Host name . . . . . . . . . . . SSAUSCHX
Domain name . . . . . . . . . . ssa.com
Host name search priority . . . *LOCAL *REMOTE, *LOCAL, *SAME

Domain name server:
Internet address . . . . . . . 123.456.789.101
Figure 41. TCP/IP configuration - Domain
6.3 Migration to eBPCS

The migration of your BPCS database from prior releases to 6.1.00 eBPCS is
handled with the tool called Conversion for the AS/400 2.0.09 - 6.1.00 . This
converts a BPCS database from release 2.0.09 or higher, up to 6.1.00.
The conversion installation and guide is very detailed. You should read the
documentation thoroughly for all sections pertaining to your FROM BPCS release
before beginning the tasks. Also, consider retaining SSA Professional Services
for assistance. You should have a good working knowledge of the AS/400 system

and physical and logical files on the system, as well as the contents of your own
BPCS database before beginning your conversion process.
The conversion of your data should be written into the project plan for
implementing BPCS at your site.
6.3.1 Preparing for the conversion

To ensure a smooth conversion process, you must perform several steps prior to
performing the actual conversion. If you carefully plan the conversion process
prior to execution, the likelihood of encountering errors is greatly reduced.
As an additional precaution, if the conversion library was not recently received,

contact a technical consultant at SSA International HelpLine at least one week
prior to the conversion. They can determine whether a more recent copy of the
conversion libraries and the conversion document are required.
Conversion instructions are also available on OGS OnLine at (Figure 42):

http://ogs.ssax.com/clients/support/Tech_Requirements/Conversion.zip
You can review the steps even before your software arrives.
Conversion software is provided free of charge to any customer with a current

OGS support contract. The conversion software is available on CD-ROM or tape
media.
Figure 42. Product Support on OGS - Conversions
6.3.2 Developing an implementation plan

Performing a BPCS conversion requires careful and thorough planning to ensure
success. Develop a detailed conversion implementation plan to clarify all steps
involved in the conversion process. You should thoroughly understand the

conversion process through careful review of this document. Have any questions
answered before proceeding with the conversion process itself.
6.3.2.1 Involve technical staff and testing resources

Involve appropriate technical staff members in the development of the
implementation plan, as well as the actual conversion. Review the entire
conversion process carefully with the appropriate technical staff prior to
implementing the conversion. Be sure your test plan for the data covers all
affected files, and checks appropriate changed fields. Use the Net Change
documents provided by SSA to gauge file changes that have occurred between
your current release of BPCS and the release to which you are moving.
6.3.2.2 Use a dedicated system to perform the conversion

Do not carry out the conversion on the target system when the system is in
production. Reserve a sufficient block of resource time (personnel and
equipment) for the conversion. To complete the conversion process, there must
be sufficient DASD to accommodate the FROM BPCS environment, the TO
BPCS environment, and the intermediate conversion environment.
Ensure all batch processing has completed in your live environment before
beginning the final live conversion. The conversion will not convert work files in
BPCS (which hold temporary data) to the new version. You should not have any
outstanding batch processing in an unfinished state before beginning the
conversion.
6.3.2.3 Be aware of DASD requirements

Due to the enhancements typically included in each new version of BPCS, the
size of each BPCS library (source and object) may increase with each new
release. Any change in library size is documented in the installation
documentation provided with each BPCS software release.
Experience has shown that a good rule of thumb is to expect that the BPCS Files
library increases by approximately 20% between versions. Therefore, if the
current file library is 100 MB in size, there must be approximately an additional
120 MB of DASD available for the new library resulting from the conversion
process.
The size of the Incremental BPCS Files libraries is slightly smaller than the
installed versions of the BPCS Files libraries due to the exclusion of many of the
logical files used by BPCS, but not used by the conversion programs. The size of
an Incremental Files library is typically 75% of the size of the Installed BPCS
Files library from which you are converting.
6.3.2.4 Perform trial conversions before final live conversion

Before performing the live conversion, do a trial conversion using a small sample
database (for example, a training database). After successfully completing the
trial conversion, convert the actual production data into a test environment. You
can access the resulting test environment offline, to familiarize users with the new
BPCS environment prior to a complete switchover.
6.3.2.5 Take a backup snapshot of TO and FROM files library

Be sure to make a snapshot copy of your FROM files library immediately prior to
running the conversion and your TO files library immediately after the conversion

has completed. This will assist you in troubleshooting if a problem is due to a
conversion issue as opposed to strictly program object-related application issues.
The Save Library (SAVLIB) command can be used to save this information onto
media, or if you have enough space on your system, into a *SAVF object.
6.3.3 Installing the new version of BPCS

Before the conversion process, install the TO version of BPCS on the AS/400
system. To install the TO version, follow the instructions provided with the TO
release. Training and testing under the TO version should also be performed prior
to the conversion. A thorough understanding of the functionality inherent in the
TO version and the primary differences between the FROM and TO versions is
critical to ensure a smooth transition.
The conversion programs are designed to initialize certain new data fields in the
TO version files. The initialized fields require a non-zero or non-blank default
value for successful BPCS operation. If you have modified files, you need to
ensure that when you convert your modified file, these default values are
correctly populated. Otherwise, decimal data errors in BPCS programs can result.
Note
The conversion programs are not designed to handle requirements specific to
user-modified programs or files or to convert data from user-defined work files.
6.3.4 Performing the system backup

SSA strongly recommends that you perform a full system backup of the target
system before initiating the conversion process. If you encounter any problems
that prevent the completion of the conversion process, you can restore the
original environment.
In addition, be aware that when performing saves of your files library to provide a
copy of the library for a test conversion, save the library when no one is using it.
Or use the Save While Active (SAVACT *LIB) parameter on your SAVLIB
command to perform the save. Be sure to save your access paths when saving
your BPCS files library for the test conversion (ACCPTH *YES). Choose F10 and
F9 to access these parameters on the SAVLIB command prompt.
If for some reason you have moved standard BPCS logical files to a library other
than your BPCS files library, for purposes of the conversion processing you
should move them into a single library, along with the physical files they are
based on.
6.3.5 Notes about modified BPCS versions and System/36 BPCS versions
If you modified BPCS files from a prior release, this utility will not convert them.
You need to install eBPCS and view the file structures in the new release to
determine how your modifications will function at the new release level. SSA
Professional Services can assist you in this task.
If you are on a release of BPCS prior to 2.0.09, such as a System/36 version of

BPCS, conversions are still possible. However, many customers at the older
releases are heavily modified, and in general, conversions will be faster and more

accurate if you retain SSA Professional Services to assist with older releases of
BPCS.
Additional software is required to convert System/36 BPCS to eBPCS. Contact

your SSA representative for details.
6.3.6 Notes regarding converting BPCS CD to eBPCS

If you are running BPCS CD (century dated version of BPCS version 4) and wish
to move up to eBPCS, there is a two-step process to complete the conversion.
First, order the additional utility called the BPCS CD to V6.x Pre-Processor. This
utility converts your BPCS CD release back to a database template that is at the
level of BPCS version 4.0.05. You do not need to install the actual 4.0.05 release
of BPCS to use this tool. The conversion utility provides the older database
template that you require. Then, use the standard Conversion for the AS/400
2.0.09-6.1.00 utility to complete the conversion process. This additional utility is
available from your SSA representative or the SSA International HelpLine.
6.3.7 Notes for Millennium toolset users

If you used the SSA Millennium tool or any other outside utility to alter a
non-century compliant release of BPCS to become century dated, you will not be
able to use the standard conversion utility to move from that release of BPCS to
eBPCS directly. You need to first bring your files library back to the standard
database template for that release level (pre-century dating) to use the SSA
conversion utility on your files library.
Century dating non-century compliant versions of BPCS is considered to be the

same as modifying every file in the BPCS database. The conversion utility will not
be able to map the fields to the next incremental database level. SSA
Professional Services may be available to assist you in the task of bringing your
database back to a pre-century dated level or to assist with building a custom
conversion to go directly to eBPCS.
6.4 Outline of conversion steps and program processing

This section offers a basic overview of the steps required for a successful BPCS
database conversion. You should always read the conversion documentation for
detailed steps.
1. Install eBPCS, and configure and save a unchanged (vanilla) BPCS
environment without any user data except the priming data provided by BPCS.
2. Read and analyze the Net Changes documentation from your release up to
eBPCS.
3. Analyze the need to convert modified files.
4. Analyze the need for DASD to hold intermediate converted data and test
conversion environments.
5. Install the conversion software.
6. Copy your live files into a set for test conversion (use save/restore
techniques). This allows test conversions without impacting live users in the
future.
7. Perform a test conversion of the data.

8. Convert any modified data you wish to keep, if required.
9. Test the converted data in eBPCS for accuracy of the conversion.
10.Make any changes to your conversion steps based on the outcome of testing
of the data after the conversion (keep accurate documentation internally of the
steps required for your conversion).
11.Perform the second test conversion of the data (if required).
12.Test the converted data (if required).
13.Repeat the test conversions and testing of the data as necessary.
14.Coordinate the conversion schedule with the other implementation of eBPCS
at your site, such as user training on new software and modifications required
for any specific eBPCS programs.
15.Prepare for final conversion of "live data", and ensure a proper time frame to
complete the live conversion.
16.Perform a final conversion and go live on eBPCS.
The following section outlines the steps performed by the conversion software in
further detail.
6.4.1 Conversion processing flow

There are four main phases in the conversion process:
• Pre-conversion Processing
• Conversion Initialization
• Main Conversion Processing
• Conversion Follow-up
This illustration of the e BPCS Conversion Process shown in Figure 43 on page 96

demonstrates the processing performed for a general BPCS conversion. The gray
processing steps are required. The steps that are not grayed are optional, but are
strongly recommended. Perform the steps in the order shown. Each of the four
conversion phases and the individual steps associated with each phase are
briefly summarized in the following sections.

Pre-Conversion Processing Conversion Installation
Review and clean up

Install New BPCS Restore Conversion
Implementation Plan Files library to be
Version Libraries
converted
Disk Backup Target

System
Main Conversion Processing Conversion Follow-up
Compile required
Post Conversion Setup additional
Build TO files library Conversion programs
Processing BPCS Environment
(2.0 - 5.1 only)
Convert Files to TO Test new BPCS Switch to Production

library Environment Environment
For each Version
Figure 43. The eBPCS conversion process
6.4.1.1 Phase 1: Preparing for the conversion

1. Develop an implementation plan: You should develop a detailed
implementation plan that outlines the procedures and personnel required for
the conversion. Set aside a dedicated block of time for the conversion. SSA
recommends that you perform the conversion while other users are not
attempting to access either version of BPCS.
2. Install the new BPCS version : Install the new version of BPCS on the target
system prior to beginning the conversion process. Follow the installation
instructions provided with the BPCS release to perform the installation
process.
3. Backup target system: Perform a full system backup of the target system
prior to beginning the conversion process. If you encounter any problems that
prevent the completion of the conversion process, you can restore the original
environment.
6.4.1.2 Phase 2: Installing conversion libraries and cleaning database

1. Restore the conversion libraries: The first step in conversion initialization is
restoring the conversion libraries. This process is done in two steps. First the
conversion installation programs are restored, and then these programs are
used to install the conversion libraries.
2. Review and clean up the files library for conversion : The FROM library
should be reviewed for extra files and members that are no longer needed. A
special command is provided to remove empty workstation file members.
Consider the amount of historical data that you require. For example, do you
need to convert 10 years of history files, or can the history be kept at the old
release level in a special archive environment? Converting only the data you
require greatly reduces the conversion processing time. Also review each file
for duplicate records. Remove any duplicate records in your database to avoid

conversion program errors caused by this condition. Once the database is
cleaned, back up the library again.
6.4.1.3 Phase 3: Running the conversions

1. Build a TO Files library: The CONVERT command first builds the TO Files
library for each version.
2. Compile the required conversion programs (optional): If you are
converting an older database (versions 2.0.09 up to 5.0.01), the CONVERT
command compiles any needed conversion programs before the actual
conversion takes place. In higher databases (versions 5.1.01 and above), all
conversion programs are already compiled.
3. Convert the files to the TO library : The actual conversion processing
occurs.
Note
The conversion sets all database files to CCSID 37. If your files were originally
set to a different CCSID, you need to change them back to that CCSID after the
conversion.
6.4.1.4 Phase 4: Conversion follow-up

1. Post conversion processing : Some versions require additional work after
the conversion is complete. Each version-specific conversion generates
reports to review the conversion processing.
2. Set up the new BPCS environment: If desired, you can create multiple
BPCS environments and file libraries to support training and testing.
3. Test the new BPCS environment: Test the newly converted BPCS
environment thoroughly prior to switching over to the production environment.
4. Switch to the production Environment: When the new BPCS environment is
tested and verified, place the new environment in production.
To successfully complete a conversion, complete the steps outlined above in the

order shown. The remaining sections in this chapter give more details of the
conversion process described in 6.4.1.1, “Phase 1: Preparing for the conversion”
on page 96 through 6.4.1.4, “Phase 4: Conversion follow-up”.
6.5 Dealing with problems or questions

Before the conversion, carefully review the conversion documentation to become
familiar with the entire process. Ensure that all instructions are clear and easy to
understand. If you have any questions related to the conversion process after
reviewing the manual, contact an SSA representative to clarify these issues
before initiating the conversion. If you encounter any problems during the
conversion, have all pertinent information available prior to contacting an SSA
representative or the SSA International HelpLine for assistance.

6.5.1 Providing the appropriate information
The following information should be available for the SSA contact:
• The BPCS FROM version and release identifier.
• The BPCS TO version and release identifier.
• The parameters used on the CONVERT command.
• The release date of the Conversion Utilities and Conversion Instruction
manual.
• Screen prints demonstrating the problem or listing the error, if available.
• Step or section where you encountered the problem.
• BPCS Conversion Checklist completed up to the point where you encountered
the problem.
• Information related to the installation of the TO version of BPCS where
applicable.
6.5.2 Retaining your job log

You should set message queue system values to retain the maximum information
possible for the job. The system value QJOBMSGQFL should be set to *PRTWRAP
to ensure that the job does not end abnormally if the message queue is full and
that job logs will print if the session should end abnormally.
In addition, you must terminate the conversion session prior to contacting SSA.
Sign off the session with the *LIST parameter to ensure that the conversion
processing history is retained. In other words, use the SIGNOFF *LIST command.
Move the spooled file into an output queue that will not be cleaned up by the
automatic system clean up utility.
6.5.3 Conversion checklist

A sample of the BPCS Conversion Checklist is provided in the conversion
documentation for your use. Use this Checklist to keep track of the conversion
process. The checklist is also useful for providing information to SSA when
questions or problems arise.
6.6 Conversion programs overview

The following information explains what the conversion process does and how it
works so you can better plan how you perform your database conversions. This
process shows an overview of how the conversion programs work. The program
flow for the conversion is as follows:
1. The CONVERT command calls the CONVERTC program. This program
controls the remaining driver programs. It sets up the information for each
version-specific conversion to run, and then proceeds through those
conversions.
2. The CONVERTC program calls other driver programs that perform functions
on the version-specific databases based on information from the CONVERTC
program. CONVERTC calls the following programs to complete each
conversion:

• CNVCREATEC builds databases if the final destination is less than
V5.1.01. It creates a duplicate of the Final BPCS Files library in the
CONVERT command. If the final destination is V5.1.01 or above,
CNVBLDFC is called to build the database. CNVBLDFC uses an
incremental database built specifically for conversions and is stored in a
Save File in the version-specific conversion libraries.
• CNVINSTALL analyzes the databases and builds the exclusion file (XEC),
and the Conversion control file used to process each file in the FROM
BPCS Files library.
• CNV900C drives the data file conversions. CNV900C checks each file for
conversion requirements and may copy it, call a program to convert it, or
bypass the file because it is excluded or has dependencies on other files
not yet converted.
• CNVCONVER processes those files with dependencies. It also calls the
Prime Update programs if the TO version is the final destination.
• CNV940C builds the Conversion Process Report for analysis of the
converted files.
3. CONVERTC either starts again at the top with the next conversion, or ends if
the completed conversion is the TO version.
Figure 44 contains additional information about the conversion processes and

libraries as do the tables in the following section. Please note these sizes are
estimates and the actual size of the library may vary when restored to your
system.
CONVERT - Cmd
CONVERTC - Pgm - Main Driver Proram
CNVBLDFC - CNVINSTALL - CNV900C - CNVCONVER -

Build Incremental Setup Conversion Convert BPCS Call Version
Files Library for version Files Specific Drivers
V2.0.09 to V5.1.01 to V5.2.02 to V6.0.00 to V6.0.02 to

V5.1.01 V5.2.02 V6.0.00 V6.0.02 V6.0.04
Conversion Conversion Conversion Conversion Conversion
Programs Programs Programs Programs Programs
V2.0.09 V5.1.01 V5.2.02 V6.0.00 V6.0.02 V6.0.04
Figure 44. eBPCS conversion flow

6.6.1 Conversion libraries reference
Table 16 describes the contents and use of each of the conversion libraries.
Table 16. eBPCS conversion libraries
Library Function Size (MB)
CNVINSTALL Objects required to install BPCS Conversion libraries and 0.5

create BPCS Conversion User Profile.
SSACNVDRV Contains objects used by all version-specific conversions. 2.9
SSACNV Converts databases from versions V2.0.09 through V5.0 to 22.4

versions V3.0 through V5.1.01.
SSACNV5152 Converts databases from version V5.1.01 toV5.2.02. 51.1
SSACNV5260 Converts databases from version V5.2.00 through V5.2.02 61.4

toV6.0.00.
Total Size of all Conversion Libraries 255.1
6.6.2 Conversion drivers reference

Table 17 explains the function of each of the conversion driver programs.
Table 17. Conversion driver programs
Program Function
CONVERTC Main conversion driver program, called from the CONVERT

command. Configures each version-specific conversion and calls
high-level driver programs.
CNVCREATEC Builds the target database library based on the Final BPCS Files
Library parameter of the CONVERT command. Used for TO versions
less than 5.1 only.
CNVBLDFC Builds the target database library based on the processed TO version.
Incremental databases are built from SAVFs in the conversion library
for each version.
CNV911C Sets the initial size of files in the Final TO BPCS files library. This
program checks the number of records in the FROM files library. If the
number of records is greater than the default size of 1,010,000 for
BPCS files, the initial size of the file is set to a size large enough to
accommodate the number of records to be loaded into it. The
algorithm used is for files with more than 900,000 records. The initial
size of the TO file is set to the number of records in the FROM file
rounded up to the most significant digit. For example, if the FROM file
has 3,750,000 records, the TO file initial size is set to 4,000,000 with
1000 increments of 1000. This gives a total capacity of 5,000,000
records.
CNVINSTALL Creates the Exclusion File and Conversion Control File for each
version-specific conversion and compiles the appropriate conversion
programs for the 2.0.09 to 5.1.01 conversion.
CNV900C Initializes the actual data conversion processing.

Program Function
CNV901C Steps through the Conversion Control File and calls programs to convert
the database.
CNV902C Converts individual files and calls conversion programs if needed, based
on rules set up in the CNVFIL file.
CNVCONVER Executes version-specific processing to be run after the majority of files

have been converted. Prime Update Processing is run from here if the
TO version is the Final Version.
CNVBLDLC Duplicates the logical files needed to run BPCS from the New Installed
BPCS files library. These files are not included in the initial build to the
final TO library to improve performance. This program is submitted to
batch as job BPCS_ADDLF.
Note that you can’t run BPCS until this job finishes. It may run for several
hours because it is rebuilding the access path for each logical file it
duplicates.
6.6.3 Incremental files libraries built by conversions

Table 18 details the incremental libraries used during the conversion.
Table 18. Incremental files libraries
BPCS Files Description Size (MB) -

library version Empty
V5.1.01 Files for conversions from 2.0.09 through 5.0 to 5.1.01 14.4
V5.2.02 Files for conversions from 5.1.01 to 5.2.02 25.8

version-specific
Total size of all empty incremental files libraries 187.7
Since the incremental files libraries do not contain all the logical files used by
BPCS, the size of your converted database into one of these libraries is smaller
than your original FROM Files library. A good rule of thumb is to calculate the
estimated size to be 75% of your original Files library. The size of these
incremental files libraries does not vary as much between versions.
For example, if you are converting a 1.7 GB Files library from V4.0.05 to V6.1.00,
you can estimate that the V5.1.01 Files library will be approximately 1.275 GB
(1.7 GB times 0.75). The V6.0.00, V6.0.02, and V6.0.04 incremental Files
libraries are slightly larger due to the new files and fields added to the database.
Also the final V6.1.00 Files library grows to more than 1.7 GB when you add the
logical files back into it at the end of the conversion by the BPCS_ADDLF batch
job.

6.6.4 Incremental BPCS files libraries built for each step
Table 19 maps which incremental libraries will be used for your conversion.
Table 19. Conversion databases
If you are converting And converting You will build the following BPCS files
from version to Version libraries
Any version < 5.1.01 Any version < 5.2 Your Final version
Any version < 5.1.01 5.2.02 V5.1.01, V5.2.02 (Final)
Any version < 5.1.01 6.0.02 V5.1.01, V5.2.02, V6.0.00, V6.0.02 (Final)
Any version < 5.1.01 6.0.04 V5.1.01, V5.2.02, V6.0.00, V6.0.02,

V6.0.04 (Final)
Any version < 5.1.01 6.1.00 V5.1.01, V5.2.02, V6.0.00, V6.0.02,

V6.0.04, V6.1.00 (Final)
5.1.01 5.2.02 V5.2.02 (Final)
5.1.01 6.0.02 V5.2.02, V6.0.00, V6.0.02 (Final)
5.1.01 6.0.04 V5.2.02, V6.0.00, V6.0.02, V6.0.04 (Final)
5.1.01 6.1.00 V5.2.02, V6.0.00, V6.0.02, V6.0.04,

V6.1.00 (Final)
5.2.02 6.0.02 V6.0.00, V6.0.02 (Final)
5.2.02 6.0.04 V6.0.00, V6.0.02, V6.0.04 (Final)
6.0.02 6.0.04 V6.0.04 (Final)
6.0.02 6.1.00 V6.0.04, V6.1.00 (Final)
6.0.04 6.1.00 V6.1.00 (Final)

Chapter 7. Database and the integrated file system (IFS)
DB2/400 is the integrated database management system (DBMS) of the AS/400
operating system that provides the structure, integrity, and data manipulation
components of the relational database model. This chapter reviews the concepts
and terminology of DB2/400, IFS, and SQL/400.
7.1 AS/400 DBMS: DB2/400

DB2/400 is the part of the operating system that controls the storing and
accessing of data by an application program. The data may be on internal
storage (for example, a database), on external media (diskette, tape, printer), or
on another system. Data management provides the functions that an application
uses in creating and accessing data on the system. It also ensures the integrity of
the data according to the definitions of the application.
DB2/400 is tightly integrated into the AS/400 operating system. In fact, it is

impossible to operate an AS/400 system without using DB2/400. OS/400 includes
control language (CL) commands that perform many database functions. These
include not only management commands but also operational commands.
Data management provides functions that allow you to manage files (create,
change, override, or delete) using CL commands. The functions also allow you to
create and access data through a set of operations (for example, read, write,
open, or close). Data management also provides you with the capability to access
external devices and control the use of their attributes for creating and accessing
data.
If you want to make more efficient use of printers, data management provides the
capability of spooling data for input or output. For example, data written to a
printer can be held on an output queue until the printer is available for printing.
On the AS/400 system, each file (also called a table) has a description that
describes the file characteristics and how the data associated with the file is
organized into records. Whenever a file is processed, the operating system
(Operating System/400 or OS/400) uses this description. Using the Display File
Description (DSPFD) command for the file in question, you can review
information and statistics on the file. The fields (also called columns) within a file
can also be displayed using the DSPFD command.
You can create and access data on the system by using these file objects. Data
management defines and controls several different types of files. Each file type
has associated CL commands to create and change the file. You can also create
and access data through the operations provided by data management.
The AS/400 system also implements a file management system similar to a PC

file system called the integrated file system (IFS). For more information, please
refer to 7.2, “Integrated file system (IFS)” on page 106.

7.1.1 File types
The data management functions support the following types of files:
• Database files: Files whose associated data is physically stored in the
system.
• Distributed data management (DDM) files: Files that allow access to data
files stored on remote systems.
• Intersystem communications function (OS/400-ICF) files (hereafter
referred to as ICF files): Allow a program on one system to communicate with
a program on the same system or another system.
• Save files: Files that are used to store compressed data on disk (without
requiring diskettes or tapes).
• Device files: Files that provide access to externally attached devices such as
displays, printers, tapes, diskettes, and other systems that are attached by a
communications line. The device files supported are display, printer, tape, and
diskette files.
Each file type has its own set of unique characteristics that determine how the file
can be used and what capabilities it can provide. However, the concept of a file is
the same regardless of the type of file it is. When a file is used by a program, it is
referred to by name, which identifies both the file description and, for some file
types, the data itself.
A file can be used in many ways on the AS/400 system. For example, it can be
accessed through a high-level language such as COBOL, RPG, C, or by CL. One
other way, which is becoming the standard in the computing industry, is through
SQL. We cover the SQL basics in the following section.
7.1.2 Operations Navigator

The creation and management of AS/400 databases are made easier by using
the Database function in Operations Navigator (Figure 45).
Figure 45. Database function
The available options under the Database navigation tree are Libraries, ODBC
Data Sources, and SQL Performance Monitors. When you select Libraries, a list
of libraries in the user portion of your AS/400 library list is displayed. To add
additional libraries for display, select Libraries. Right-click, and select Select

Libraries to Display. Doing this brings up a window similar to the one in Figure
46.
Figure 46. Database libraries selection
You can either enter the name of the library, or select the library from the list and
click Add. Be aware that the selected libraries are only temporarily added. If you
want to permanently add the libraries, you need to change the user portion of
your library list on the AS/400 system (System Value QUSRLIBL).
The context menu of Libraries also allows you to create a new library. You can
choose to create the library as an SQL collection. An SQL collection consists of a
library, a journal, a journal receiver, a catalog, and optionally a data dictionary.
You can also specify to create the library in another Auxiliary Storage Pool (ASP).
To create a new table, select the library. Right-click, and select New->Table. To
work with an existing table, right-click the selected table, and choose the
appropriate action from the context menu. For example, you can add or remove
columns in existing tables by selecting the Properties action. The Quick View
action allows you to easily view the data in a table. You can even edit the data by
double-clicking the table.
You can create, run, edit, debug, and save SQL statements by selecting Run SQL
Scripts from the Database context menu. If you are not familiar with SQL
statements, you can insert and modify an SQL statement example. To do so,
ensure that the SQL Statement Examples option under the View menu is selected
(with a check mark on the left). Then, select the desired statement from the
drop-down list as shown in Figure 47 on page 106, and click the Insert button.
Database and the integrated file system (IFS) 105

Figure 47. Run SQL Scripts
The Database function also includes the capability to monitor SQL performance.
To create an SQL performance monitor, select SQL Performance Monitors.
Right-click and select New.
You can perform other tasks such as:

• Create, delete, and display the properties of a view.
• Create, delete, and change journal properties. Start and end table journaling,
add, remove, activate, and deactivate remote journals.
• Create indexes from the Properties window of a table.
• Create, delete, and display the properties of a type.
• Create, delete, and display the properties for external procedures and
functions, SQL procedures and functions, and sourced User Defined
Functions (UDFs).
7.2 Integrated file system (IFS)

The integrated file system function in the Operations Navigator consists of the
IFS as well as File Shares (Figure 48 on page 107). The IFS allows you to work
with the files and folders on the AS/400 system. The folders in the IFS are
displayed in a hierarchical directory structure similar to the Windows Explorer
view. You can easily create, rename, delete, drag, and drop folders within and
between AS/400 systems and the PC desktop. Examples of manipulating files
and folders in the IFS are included later in C.3.8, “Integrated File System” on
page 378.
File Shares shows the AS/400 NetServer file shares. The Open AS/400
NetServer option in the File Share context menu opens a separate window, which

allows you to work with the AS/400 NetServer. For additional information on
NetServer, refer to C.3.9, “AS/400 NetServer” on page 384.
Figure 48. File systems function
The available file systems are:

• NFS : This represents the Network File System (NFS), which provides the user
with access to data and objects stored on a remote NFS server. An NFS
server can export a network file system that the NFS clients can mount
dynamically.
• QDLS : The document library services file system provides access to
documents and folders on the AS/400 system.
• QFileSvr.400: This file system provides access to other file systems that
reside on remote AS/400 systems.
• QLANSrv: The OS/2 Warp Server for AS/400 file system provides access to
the same directories and files that are accessible through the OS/2 Warp
Server for AS/400 licensed program. Users of the OS/2 Warp Server for
AS/400 applications can use the same data as the clients of an OS/2 Warp
Server.
• QNetWare: The NetWare file system provides access to local or remote data
objects that are stored on a server that runs Novell NetWare 4.10 or 4.11. It
also provides access to standalone PC servers running Novell NetWare 3.12,
4.10, 4.11, or 5.0.
• QNTC: This is the file system for Windows NT Server. You can access data
and objects that are stored on a server running Windows NT 4.0 or higher. It
includes the accessing of data on a Windows NT Server that is running on an
Integrated Netfinity Server.
• QOpenSys : The Open Systems file system is compatible with the UNIX-based
open system standards such as POSIX and XPG.
• QOPT: This is the Optical file system that provides access to stream data
stored on an optical media.
• QSYS.LIB: This is the library file system that supports the AS/400 library
structure by providing access to AS/400 database files and all other object
types that the library supports or manages.
• "root" : This is the most basic file system. It has the characteristics of the Disk
Operating System (DOS) and the OS/2 file systems.
• UDFS : This is a User Defined File System which resides on the Auxiliary
Storage Pool (ASP) of the user’s choice.

Note
Some of the file systems mentioned in the previous list are not a standard part
of Operating System/400. For example, the QLANSrv file system is only
available when the OS/2 Warp Server for AS/400 licensed program is installed
on the AS/400 system.
7.3 SQL concepts

DB2 for AS/400 SQL consists of the following main parts:
• SQL runtime support
SQL runtime parses and runs any SQL statement. This support is the part of
the Operating System/400 (OS/400) licensed program, which allows
applications that contain SQL statements to be run on systems where the DB2
Query Manager and SQL Development Kit licensed program are not installed.
• SQL precompilers
SQL precompilers support precompiling embedded SQL statements in host
languages. The following languages are supported:
– ILE C/400
– COBOL/400
– ILE COBOL/400
– AS/400 PL/I
– RPG III (part of RPG/400)
– ILE RPG/400
The SQL host language precompilers prepare an application program
containing SQL statements. The host language compilers compile the
precompiled host source programs. The precompiler support is part of the
DB2 Query Manager and SQL Development Kit licensed program.
• SQL interactive interface
The SQL interactive interface allows you to create and run SQL statements.
Interactive SQL is part of the DB2 Query Manager and SQL Development Kit
for AS/400 (5769-ST1).
• Run SQL Statements CL (RUNSQLSTM) command
RUNSQLSTM allows you to run a series of SQL statements, which are stored
in a source file. RUNSQLSTM command is part of the DB2 Query Manager
and SQL Development Kit licensed program.
• DB2 Query Manager for AS/400
DB2 Query Manager for AS/400 provides a prompt-driven interactive interface
that allows you to create data, add data, maintain data, and run reports on the
databases. Query Manager is part of the DB2 Query Manager and SQL
Development Kit licensed program. For more information, refer to DB2 for
AS/400 Query Manager Use, SC41-5212, and DB2 for AS/400 Query
Management Programming, SC41-5703.

• SQL REXX Interface
The SQL REXX interface allows you to run SQL statements in a REXX
procedure. This interface is part of the DB2 Query Manager and SQL
Development Kit licensed program.
• SQL Call Level Interface
DB2 for AS/400 supports the SQL Call Level Interface. This allows users of
any of the ILE languages to access SQL functions directly through procedure
calls to a service program provided by the system. Using the SQL Call Level
Interface, you can perform all of the SQL functions without needing a
precompile. This is a standard set of procedure calls to prepare SQL
statements, execute SQL statements, and fetch rows of data. You can even
perform advanced functions such as accessing the catalogs and binding
program variables to output columns.
For a complete description of all the available functions, and their syntax, see
DB2 for AS/400 SQL Call Level Interface, SC41-5806.
• QSQPRCED API
This Application Program Interface (API) provides an extended dynamic SQL
capability. SQL statements can be prepared into an SQL package and
executed using this API. Statements prepared into a package by this API
persist until the package or statement is explicitly dropped. QSQPRCED is
part of the OS/400 licensed program. For more information on the
QSQPRCED API, see the System API Reference, SC41-5801.
• QSQCHKS API
This API syntax checks SQL statements. QSQCHKS is part of the OS/400
licensed program. For more information on the QSQCHKS API, see the
System API Reference , SC41-5801.
• DB2 Multisystem
This feature of the operating system allows your data to be distributed across
multiple AS/400 systems. For more information on DB2 Multisystem, see the
DB2 Multisystem for AS/400, SC41-5705.
• DB2 Symmetric Multiprocessing
This feature of the operating system provides the query optimizer with
additional methods for retrieving data that include parallel processing.
Symmetric multiprocessing (SMP) is a form of parallelism achieved on a single
system where multiple processors (CPU and I/O processors) that share
memory and disk resource work simultaneously toward achieving a single end
result. This parallel processing means that the database manager can have
more than one (or all) of the system processors working on a single query
simultaneously.
7.3.1 Relational database and terminology

In the relational model of data, all data is perceived as existing in tables. DB2 for
AS/400 objects are created and maintained as AS/400 system objects. Table 20
on page 110 shows the relationship between AS/400 system terms and SQL

relational database terms. For more information on databases, see DB2 for
AS/400 Database Programming , SC41-5701.
Table 20. Relationship of system terms to SQL terms
System terms SQL terms
Library: Groups related objects. Collection: Consists of a library, a journal, a journal

Allows you to find the objects by receiver, an SQL catalog, and optionally a data
name. dictionary. A collection groups related objects and
allows you to find the objects by name.
Physical file: A set of records with Table: A set of rows with columns.
fields.
Record: A set of fields. Row: The horizontal part of a table containing a

serial set of columns.
Field: One or more bytes of related Column: The vertical part of a table of one data
information of one data type. type.
Logical file: A subset of fields and View: A subset of columns and rows of one or more
records of one or more physical files. tables.
SQL Package: An object type that Package: An object type that is used to run SQL
is used to run SQL statements. statements.
User Profile Authorization name or Authorization ID
7.3.2 SQL terminology

There are two naming conventions that can be used in DB2 for AS/400
programming: system (*SYS) and SQL (*SQL). The naming convention used
affects the method for qualifying file and table names and the terms used on the
interactive SQL displays. The naming convention used is selected by a parameter
on the SQL commands. For REXX, the naming convention is selected through
the SET OPTION statement. The two naming conventions are further explained
here:
• System naming (*SYS): In the system naming convention, files are qualified
by library name in the form:
library/file
Consider the case where the table name is not explicitly qualified and a
default collection name is specified for the Default relational database
collection (DFTRDBCOL) parameter of the CRTSQLxxx or the Control SQL
Package (CRTSQLPKG) commands. Then, the default collection name is
used. If the table name is not explicitly qualified and the default collection
name is not specified, the qualification rules are:
– The following CREATE statements resolve to unqualified objects:
CREATE TABLE
The table is created in the current library (*CURLIB).
CREATE VIEW
The view is created in the first library referenced in the subselect.
CREATE INDEX
The index is created in the collection or library that contains the
table on which the index is being built.

CREATE PROCEDURE
The procedure is created in the current library (*CURLIB).
– All other SQL statements cause SQL to search the library list (*LIBL) for
the unqualified table.
The default relational database collection (DFTRDBCOL) parameter applies
only to static SQL statements.
• SQL naming (*SQL): In the SQL naming convention, tables are qualified by
the collection name in the form:
collection.table
If the table name is not explicitly qualified and the default collection name is
specified in the Default relational database collection (DFTRDBCOL)
parameter of the CRTSQLxxx command, the default collection name is used.
If the table name is not explicitly qualified and the default collection name is
not specified, the rules are:
– For static SQL, the default qualifier is the user profile of the program owner.
– For dynamic SQL or interactive SQL, the default qualifier is the user profile
of the job running the statement.
7.3.3 Types of SQL statements

There are four basic types of SQL statements:
• Data definition language (DDL) statements
• Data manipulation language (DML) statements
• Dynamic SQL statements
• Miscellaneous statements
SQL statements can operate on objects created by SQL and AS/400 externally
described physical files and AS/400 single-format logical files, whether they
reside in an SQL collection. The DDL and DML SQL statements are outlined in
Table 21 on page 112.

Table 21. DDL and DML SQL statements
SQL DDL statements SQL DML statements
ALTER TABLE CLOSE

COMMENT ON COMMIT
CREATE COLLECTION DECLARE CURSOR
CREATE INDEX DELETE
CREATE PROCEDURE FETCH
CREATE SCHEMA INSERT
CREATE TABLE LOCK TABLE
CREATE VIEW OPEN
DROP COLLECTION ROLLBACK
DROP INDEX SELECT INTO
DROP PACKAGE UPDATE
DROP PROCEDURE
DROP SCHEMA
DROP TABLE
DROP VIEW
GRANT PACKAGE
GRANT PROCEDURE
GRANT TABLE
LABEL ON
RENAME
REVOKE PACKAGE
REVOKE PROCEDURE
REVOKE TABLE
The dynamic SQL and miscellaneous statements are outlined in Table 22.
Table 22. Dynamic SQL and miscellaneous statements
Dynamic SQL statements Miscellaneous statements
DESCRIBE BEGIN DECLARE SECTION

EXECUTE CALL
EXECUTE IMMEDIATE CONNECT
PREPARE DECLARE PROCEDURE
DECLARE STATEMENT
DECLARE VARIABLE
DESCRIBE TABLE
DISCONNECT
END DECLARE SECTION
INCLUDE
RELEASE
SET CONNECTION
SET OPTION
SET RESULT SETS
SET TRANSACTION
WHENEVER
7.4 DB2 for AS/400 catalog views

This section describes the views contained in a DB2 for AS/400 catalog. The
database manager maintains a set of tables containing information about the
data in the database. These tables are collectively known as the catalog. The
catalog tables contain information about tables, parameters, procedures,

packages, views, indexes, and constraints on the AS/400 system. The catalog
tables include the following files in the QSYS library:
• QADBXREF
• QADBPKG
• QADBFDEP
• QADBXRDBD
• QADBFCST
• QADBCCST
• QADBIFLD
• QADBKFLD
The catalog tables also include the following files in the QSYS2 library:
• SQL_LANGUAGES
• SYSPARMS
• SYSPROCS
Unlike the other catalog tables in QSYS, these catalog tables cannot be
populated from objects on the system. Therefore, you should regularly save
these tables.
The database manager provides views over the catalog tables. The views provide
more consistency with the catalog views of other IBM SQL products and with the
catalog views of the ANSI and ISO standard (called Information Schema in the
standard).
With the exception of SYSINDEXES, SYSKEYS, and SYSPACKAGES, each of

the following catalog views has a corresponding view defined in the Information
Schema. The catalog includes the following views and tables in the QSYS2
library:
SQL_LANGUAGES Information about the supported languages
SYSCHKCST Information about check constraints
SYSCOLUMNS Information about column attributes
SYSCST Information about all constraints
SYSCSTCOL Information about the columns referenced in a constraint
SYSCSTDEP Information about constraint dependencies on tables
SYSINDEXES Information about indexes
SYSKEYCST Information about unique, primary, and foreign keys
SYSKEYS Information about index keys
SYSPACKAGE Information about packages
SYSPARMS Information about procedure parameters
SYSPROCS Information about procedures
SYSREFCST Information about referential constraints
SYSTABLES Information about tables and views
SYSVIEWDEP Information about view dependencies tables
SYSVIEWS Information about the definition of a view
The catalog views in the QSYS2 library contain information about all tables,
parameters, procedures, packages, views, indexes, and constraints on the
AS/400 system.
In addition, an SQL collection contains a set of these views (except

SQL_LANGUAGES, SYSPARMS, and SYSPROCS) that only contains

information about tables, packages, views, indexes, and constraints in the
collection.
Tables and views in the catalog are like any other database tables and views. If
you have authorization, you can use SQL statements to look at data in the
catalog views in the same way that you retrieve data from any other table in the
AS/400 system. The database manager ensures that the catalog contains
accurate descriptions of the objects in the database at all times.
When you are trying to view only a couple of columns, you notice that one of them
is much longer than required. In this case, use the SUBSTR function on the
SELECT statement to use a substring length of a column. The following SQL
statement shows such a situation:
SELECT SUBSTR(NAME,1,30), SYS_TNAME FROM DB2400/SYSTABLES
Note: The NAME column is 128 characters long, but most, if not all, names are
less than 30.
This statement selects the NAME and SYS_TNAME columns from the table
SYSTABLES in collection DB2400. The two columns show up on the same
display due to the substring function cutting off the unnecessary characters of the
NAME column.
7.5 DB2 Universal Database (UDB) for AS/400

While DB2 for AS/400 has long provided facilities to address most customer
requirements, with V4R4, AS/400 support has been extended to support new
forms of information previously stored on the AS/400 but not managed by DB2 for
AS/400. With this release, DB2 Universal Database (UDB) for AS/400 now
supports the storing, managing, and indexing of all forms of information including
binary objects (such as spreadsheets, word processing documents, and
multimedia objects) within the database. This support includes features such as
Binary Large Objects (BLOBs), user-defined functions, complex objects, query by
image content, and even spatial extenders. All of these features allow customers
to use one database management system to store, retrieve, and manage all of
their corporate information.
Performance and functional enhancements to the DB2 Universal Database for

AS/400 improve the processing of business intelligence queries. These
improvements include:
• The hash "group by" algorithm improves performance of grouping queries for
a large number of groups.
• The performance of MIN and MAX functions is improved with a suitable index,
if available, to determine the minimum or maximum value of a query.
• Derived tables and common table expression support allow complex business
intelligence queries to be written without the use of views.
The following functions are available in DB2 Universal Database for AS/400
through the 1999 Database Enhance PAK or Group PTF SF99014:
• Large objects (LOBs) support allows DB2 UDB to store and manipulate data
fields much larger than the current limits. An AS/400 record with LOB fields
can hold up to 15 MB of data. With the new LOB support, DB2 UDB can be

used as a platform for building applications that hold new non-traditional types
of data, such as image and audio as well as very large text blocks.
• The datalink data type extends the types of data that can be stored in
database files. The data stored in the column is only a pointer to the actual
object such as an image file, a voice recording, or a text file. The method used
for resolving to the object is to store a uniform resource locator (URL). This
means that a row in a table can be used to contain information about the
object in traditional data types, and the object itself can be referenced using
the datalink data type.
• Datalinks also allow the referenced object to be "linked" to the database in
such a way that prevents modification or deletion of the object while it is linked
to the database file. This relationship is maintained by having the database
interact with the file system that contains the object.
• User-defined data types are derived from existing predefined types such as
integer and character data. You can create your own data types and create
functions for different types. You can call a function for each row of a result set
and return a value based on the user-defined type.
• SQL now allows the user-defined functions to be used within SQL itself.
User-defined functions are necessary building blocks to support database
extenders (extensions to support rich text and multimedia search and
manipulation) currently supported on UDB.

Chapter 8. Printing
This chapter describes a general overview of AS/400 native printing and printing
setup.
8.1 AS/400 printing

The following items are the major components of AS/400 host printing and are
described to give you an understanding of the capabilities of using AS/400 spool
management:
• Printer device description
• Output queue
• Printer file definition
• Printer writer
• Spooled file
As shown in Figure 49, an application creates a spooled file. The data is from the
application. The spooled file attributes (page size, number of copies, default font,
and so on) are from the printer file associated with the application. The spooled
file is placed into an output queue. A printer writer program then processes the
spooled file to generate the report on the printer. During this process, the printer
writer takes information from the printer device description.
Printer File
Definition
SSA
Output
eBPCS
Queue
Report
Spoo led
AS/400 File
CRTO UTQ
Printer
Report W riter Printer
Device
STRPRTW TR Description
or C RTD EV PRT
STR RMTW TR
Figure 49. AS/400 host printing
8.1.1 AS/400 printer attachment

This section shows the different printer attachment methods on the AS/400
system depending on the type of printer (Figure 50 on page 118). The following
attachment methods are a few of the possible alternatives:
• Printers attached to a workstation controller or to an IBM 5x94 (Remote
Control Unit)
• IPDS (Intelligent Printer Data Stream) printers: LAN attached

• ASCII printers attached to PCs
• ASCII printers: LAN attached
Note that these are printers directly attached and controlled by an AS/400
system. In other words, these are printers for which there is a device description.
All printers attached to remote systems or connected using a TCP/IP LPR/LPD
attachment are discussed in 8.1.7.2, “TCP/IP LPR and LPD printing” on page
124.
For information on printing SCS, IPDS, AFPDS, or USERASCII spooled files on

the different attachment methods and for information on IBM printers, refer to
AS/400 Printer Device Programming , SC41-5713, and IBM AS/400 Printing V,
SG24-2160.
eBPCS
Local
AS/400
5X94
Controller
Remote
LAN-attached
PC
S/390
RS/6000
Figure 50. AS/400 printer attachment
8.1.1.1 Printers attached to a workstation controller or IBM 5x94

Several IBM printers (including SCS or IPDS) can be attached directly to AS/400
workstation controllers by twinaxial cable. The same printers can also be
attached by twinaxial cable to a Remote Control Unit IBM 5x94.
8.1.1.2 IPDS printers: LAN attached

Any IPDS printers with an IBM Advanced Function Common Control Unit
(AFCCU) can be LAN-attached to an AS/400 system (for example, IBM 3130,
3160, InfoPrint 60, InfoPrint 62, 3900, and InfoPrint 4000). These printers support
one or more of the following attachments:
• SNA Token-Ring
• SDLC
• TCP/IP Token-Ring
• TCP/IP Ethernet
IBM Network Printers NP12 (4312), NP17 (4317), or NP24 (4324) with the
appropriate LAN card, TCP/IP Token-Ring, or TCP/IP Ethernet are supported.

Using the I-DATA 7913 Printer LAN Attachment box (TCP/IP Token-Ring or
Ethernet), it is also possible to attach the following IBM IPDS printers on the LAN:
IBM 3812, 3816, 3912, 3916, 3112, 3116, 4028, 4230, and 6400.
8.1.1.3 ASCII printers attached to PCs

All ASCII printers can be connected to a PC using the standard parallel or serial
port. PC5250 sessions are used to print AS/400 spooled files on the PC. When a
spooled file is sent to a PC5250 printer session, it needs to be converted to an
ASCII data stream supported by the target printer. There are three ways that this
conversion occurs:
• PC5250 transform based on a Printer Definition Table (PDT)
• PC5250 transform based on the Windows 95/NT printer driver
• Host print transform
8.1.1.4 ASCII Printers: LAN attached

ASCII printers may be attached directly on the LAN using Token-Ring or Ethernet
connections. Two system drivers, *IBMPJLDRV and *HPPJLDRV, allow you to
attach ASCII printers on the LAN:
• The *IBMPJLDRV driver supports all of the IBM printers (for example, IBM
4039 plus, 4312, 4317, and 4324) attached with a LAN card (TCP/IP address).
• The *HPPJLDRV driver supports all of the HP and HP-compatible printers (for
example, HP4 and HP5) attached using an HP JetDirect card (TCP/IP
address).
8.1.2 AS/400 controllers and devices

The AS/400 system can automatically configure any controller or device (printer
or display) attached to twinaxial or ASCII controllers. The same is done for
devices attached to an IBM 5494-EXT attached using LAN or WAN (Token-Ring
or Ethernet). This is accomplished by selecting automatic configuration through
the system value QAUTOCFG and using the Work with System Value
(WRKSYSVAL) command:
WRKSYSVAL QAUTOCFG
Automatic configuration also occurs for any Client Access or Telnet devices. The
system value that controls this is called QAUTOVRT. The WRKSYSVAL
command allows the configuration change as in QAUTOCFG.
Automatic configuration for remote controllers can be achieved using the system
value QAUTORMT. For additional information on local device and automatic
configuration, refer to AS/400 Local Device Configuration, SC41-5121. For
additional information on remote workstation support, refer to Remote Work
Station Support , SC41-5402.
8.1.3 AS/400 output queue

An output queue is a list of spooled files waiting to print. A single output queue
may have spooled files from many different jobs and many different users. In
some cases, a single job may place spooled files on more than one output queue.
Spooled files from a single output queue can be directed to multiple printers.
Printing 119
8.1.4 Printer files
Whenever you print using the AS/400 spooling system, a printer file is used. A
printer file determines how the system handles output from application programs.
We can define printer files in two groups:
• Program-described printer files
These printer files do not have any field or record-level formatting. The
attributes of the printer file are used to define how all of the data in the spooled
file is printed. Any positioning of information within the file has to be
determined by the application program. Most of the printer files use these
simple files.
• Externally-described printer files
These printer files have formatting defined using Data Description
Specification (DDS) external to the application program. Some of the
attributes of the printer file apply to all of the data. The DDS can override or
enhance these options for individual records or fields (for example, a single
field can be printed as a barcode). For detailed information on DDS output
keywords, refer to Data Description Specification, SC41-5712. An example of
a system-supplied printer file is QSYSPRT in the QSYS library.
8.1.5 Spooled files

The spooled files stored in output queues can have different origins and different
formats (data streams):
• Spooled files can be created on the AS/400 system by an application or by
pressing the Print Screen key.
• With Client Access/400, the network printing function can direct PC output to
an AS/400 output queue.
• You may also receive spooled files from host systems (IBM S/390), UNIX
systems (IBM RS/6000), OEM systems, or other AS/400 systems.
AS/400 S/390 or CA/400

Applications Other Network
Systems Printing
Spooled File
Printer Writer
SCS IPDS IPDS ASCII
ASCII
SCS Printer IPDS IPDS Printer
Printer Printer
AFP(*NO) AFP(*YES)
Figure 51. Data streams and printer devices

8.1.5.1 Data stream types
The AS/400 system supports different data streams and can automatically create
the majority of them. The Printer device type parameter in the printer file
determines the type of data stream to be created (Figure 52).
Create Printer File (CRTPRTF)
File . . . . . . . . . . . . . . MYPRTF Name

Library . . . . . . . . . . . *CURLIB Name, *CURLIB
Source file . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Source member . . . . . . . . . *FILE Name, *FILE
Generation severity level . . . 20 0-30
Flagging severity level . . . . 0 0-30
Device:
Printer . . . . . . . . . . . *JOB Name, *JOB, *SYSVAL
Printer device type . . . . . . *SCS *SCS, *IPDS, *LINE...
Text 'description' . . . . . . . *SRCMBRTXT
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
Figure 52. Create Printer File - Printer device type parameter
The printer device type parameter can be set to one of the following values:
• *SCS (SNA Character String)
SCS is used to control line mode printers, and has a relatively simple
structure.
• *IPDS (Intelligent Printer Data Stream)
A host-to-printer data stream used for Advanced Function Printing (AFP)
subsystems. It provides an attachment-independent interface for controlling
and managing all-point-addressable (APA) printers. It supports interactive,
two-way dialog between the printer driver and the printer (printer information,
cooperative recovery, and resource management).
Note that the AS/400-generated IPDS is a subset of the full IPDS.
• *AFPDS (Advanced Function Printing Data Stream)
A data stream for advanced function printers (independent of operating
systems, independent of page printers, and portable across environments).
AFPDS is a structured data stream divided into components called "objects."
AFPDS includes text, images, graphics, and barcodes and references AFP
resources (for example, overlays, page segments, and fonts).
• *LINE (Line data stream)
A LINE data stream referencing a page definition and a form definition with the
spooled file.
Printing 121
• *AFPDSLINE (AFPDS line data stream)
AFPDSLINE data stream is a mixture of AFP structured fields and LINE data.
Only certain AFP structured fields can be mixed with the line data.
• *USERASCII (ASCII data stream)
There is no formal structure that controls the use of the ASCII data stream to
control printers attached to systems providing ASCII support. There is no
architectural data stream standard to which ASCII printers can conform in the
interest of uniformity.
A *USERASCII spooled file can contain any form of ASCII printer data stream
(for example, PCL5, or PostScript).
The user should designate a printer that supports the data stream created in the
spooled file.
By default, AS/400 printer files use SNA character string (SCS) as the data
stream type. This type of data stream can be sent to any printer, including ASCII
printers using SCS-to-ASCII Host Print Transform. SCS spooled files can also be
sent to printers configured as *IPDS, AFP=NO, and *IPDS, AFP=*YES. The
printer writer handles this automatically. It looks at the printer’s device description
and transforms the SCS spooled file into the appropriate data stream. For IPDS
printers configured AFP (*YES), the standard process includes the steps as
illustrated in Figure 53.
SCS IPDS AFPDS

Data Data Data
Stream Stream Stream
Printer Writer Printer Writer Printer Writer
Data Stream Data Stream Data Stream

Converter Converter Converter
SCS IPDS AFPDS

IPDS AFPDS IPDS
AFPDS IPDS
IPDS
Printer Driver
IPDS Printer AFP(*YES)
Figure 53. Data stream transforms when printing to an IPDS AFP (*YES) printer
8.1.5.2 AS/400 host print transform

The host print transform (HPT) function allows SCS-to-ASCII and
AFPDS-to-ASCII conversion to take place on the AS/400 system instead of by
5250 emulators. Having the conversion take place on the AS/400 system
provides the following advantages:

• Consistent output for most ASCII printers
The host print transform function is capable of supporting many different types
of ASCII printer data streams (for example, the Hewlett-Packard Printer
Control Language (PCL), the IBM Personal Printer Data Stream (PPDS), and
the Epson FX and LQ data streams). Having the conversion done on the
AS/400 system ensures that the resulting ASCII printer data stream provides
the same printed output regardless of the emulator or device to which the
printer is physically attached.
• Support for many different ASCII printers
Currently, each emulator supports a limited number of ASCII printers. With the
host print transform function, most IBM printers and a large number of OEM
printers are supported.
• Customized printer support
Workstation customizing objects that come with the host print transform
function can be updated by the user to change or add characteristics to a
particular printer. Also, if the host print transform function does not have a
workstation customizing object for a printer you want to use, you can create
your own.
Figure 54 shows an overview of some of the ways in which ASCII printers can be
attached. Host print transform can be used to print to all of these printers.
Figure 54. Host print transform
8.1.6 Printer writer

A printer writer is an OS/400 program that takes spooled files from an output
queue and sends them to a printer defined on the AS/400 system. More than one
printer writer can be started to the same output queue (10 is the limit). However,
each writer name must be unique and of the same type.
The printer writer program takes spooled files, one at a time, from the output
queue based on their priority. The printer writer program prints a spooled file only
if its entry on the output queue indicates that it has a ready (RDY) status. You can
display the status of a particular spooled file by using the Work with Output
Queue (WRKOUTQ) command.
Printing 123
8.1.7 Remote system printing
Remote system printing is particularly useful for customers who have networked
systems for automatically routing spooled files to printers connected to other
systems. Output queue parameters define the target system. Depending on the
target system or printer, host print transform can be called to convert the spooled
file into an ASCII printer data stream.
8.1.7.1 Remote writer program

A remote writer is an OS/400 program that takes spooled output files from a
remote output queue and sends them to the specified remote system. The remote
writer, which is a system job, sends the spooled output files using SNADS,
TCP/IP, or Internetwork Packet Exchange (IPX). This function is known as remote
system printing on the AS/400 system. The Start Remote Writer (STRRMTWTR)
command is used to initiate remote system printing.
After the spooled output file is successfully sent to a remote system, it is deleted
or saved as determined by the SAVE spooled file attribute value.
DESTTYP:
A S /4 0 0 *O S 4 0 0
T C P /IP
SN A
D ESTTYP:
S /3 9 0
*S 3 9 0
SNA
A S /4 0 0
O th e r DE STTY P:
S p o o le d T C P /IP , S N A S ys te m *O T H E R
F ile
T C P /IP
DES TTY P:
P S F /2
*P S F 2
IP X
D ESTTYP:
N e tW a re 4 *N D S
Figure 55. Remote system printing
8.1.7.2 TCP/IP LPR and LPD printing

You can request to have your spooled file sent and printed on any system in your
TCP/IP network. The line printer requester (LPR) is the sending, or client portion,
of a spooled file transfer. On the AS/400 system, the Send TCP/IP Spool File
(SNDTCPSPLF) command, the TCP/IP LPR command, or remote system printing
provide this function by allowing you to specify which system you want the
spooled file printed on and how you want it printed. When sending a spooled file,
the host print transform function can also be used to transform SCS or AFPDS
spooled files into ASCII.
Printing the file is done by the printing facilities of the destination system. The
destination system must be running TCP/IP. The line printer daemon (LPD) is the
process on the destination system that receives the file sent by the LPR function.
See Figure 56 on page 125.

Figure 56. TCP/IP LPR and LPD
LPR/LPD prerequisites
TCP/IP must be started on the AS/400 host before LPR can be used to send files
or LPD can be used to receive files. The command to start TCP/IP on the AS/400
host is:
STRTCP
LPR on the AS/400 host

LPR is used to send a spooled file from the AS/400 host to an LPD server. The
LPD server can be another AS/400 host or any other machine that provides an
LPD server. There are LPD servers available for most popular operating systems.
Some printers, such as the IBM Network Printer, contain an operating
system-independent LPD server.
Before you send the file using LPR, you need to know the spooled file number.
This number is shown in the Work with Spooled Files (WRKSPLF) display in
Figure 57. Enter WRKSPLF, and press F11 twice to go to View 3. You may also
require the file, job, and user names for the spooled file.
Work with All Spooled Files

1=Send 2=Change 3=Hold 4=Delete 5=Display 6=Release 7=Messages
8=Attributes 9=Work with printing status
File
Opt File Nbr Job User Number Queue Library
QPJOBLOG 1 QPADEV0003 USERID01 001314 QEZJOBLOG QUSRSYS
Bottom
Parameters for options 1, 2, 3 or command
===>
F3=Exit F10=View 2 F11=View 4 F12=Cancel F22=Printers F24=More keys
Figure 57. WRKSPLF shows the spooled file number (View 3)
Note
Option 1 (Send) on the Work with Spooled Files display can only be used to
send the file to an SNA device. The LPR or SNDTCPSPLF command is used to
send the file to a TCP/IP device.
Printing 125
Using the LPR command to send the file to the LPD server
The LPR command (or the equivalent SNDTCPSPLF command) is used to send
a file from the AS/400 system to the LPD server. The LPD host can be another
AS/400 system or a non-AS/400 device. See Figure 58.
Send TCP/IP Spooled File (LPR)
Remote system . . . . . . . . .
Printer queue . . . . . . . . .
Spooled file . . . . . . . . . . Name

Job name . . . . . . . . . . . . * Name, *
User . . . . . . . . . . . . . Name
Number . . . . . . . . . . . . 000000-999999
Spooled file number . . . . . . *ONLY 1-9999, *ONLY, *LAST
Destination type . . . . . . . . *OTHER *AS400, *PSF2, *OTHER
Transform SCS to ASCII . . . . . *YES *YES, *NO
Bottom
F13=How to use this display F24=More keys
Figure 58. Sending a spooled file to a remote host using LPR
Specify the Internet address when the remote system is set to *INTNETADR
(Figure 59).
Send TCP/IP Spooled File (LPR)
Internet address . . . . . . . .
Bottom
Messages pending on other displays.
Figure 59. LPR command when remote system is set to *INTNETADR

Table 23 shows the LPR command parameters.
Table 23. LPR command parameters
Parameter Description
Remote system The name of the system to which the spooled file is sent. The
host name can be:
- A host name added by selecting Work with TCP/IP Host
Table Entries from the CFGTCP menu
- A host name that is resolved to a TCP/IP address by a
Domain Name Server
- *INTNETADR to use the value of the INTNETADR
parameter
Printer queue Specifies the name of the destination printer queue. For
destination systems that are AS/400 systems, this is the
name of an output queue to which the spooled file is sent.
The printer queue can contain both the library name and the
name of the printer queue (for example, QGPL/OUTQ1). If no
library is specified, the library list of the sending user is
searched on the destination system.
When sending a file to a non-AS/400 system, this name is

system independent. For some systems, the name may be
case sensitive. Enclose the name in apostrophes to ensure
the case is preserved. For example, use ‘OUTQ1’ to ensure
that the case in maintained.
Spooled file The name of the spooled file as displayed by the Work with
Spooled files command.
Job name The name of the job that created the spooled file. The special
value * is used to specify that the spooled file was created by
the same job issuing the LPR command.
User If the spooled file name is anything other than *, then this field
can be used to specify the user that created the spooled file.
If the user name is not specified, then all jobs currently

running are searched for a match against the job name
specified above.
Number If the spooled file name is anything other than * and the user
name has been specified, this field can be used to specify the
job number that created the spooled file.
Spooled file number The spooled file number as shown by the Work with Spooled
Files command.
Destination type The type of host that will receive the spooled file. This
parameter should be set to *AS400 when sending the file to
another AS/400 host.
Transform SCS to ASCII Set this parameter to *YES to transform the spooled file to
ASCII. When sending the spooled file to another AS/400
system, no transformation is necessary.
Printing 127
Table 24 shows the example printer queue names for some common printers.
Table 24. Example printer queue names for some common printers
Interface used Queue name
HP JetDirect Card (internal) ‘text’ for unformatted output

‘raw’ for formatted output
HP JetDirect Server (external) (3 port - 1 IP ‘text1’ or ‘raw1’ for port 1

address) ‘text2’ or ‘raw2’ for port 2
‘text3’ or ‘raw3’ for port 3
Integrated Network Option (IBM 4039, 3112, ‘prt0’

3116, Lexmark OPTRA)
Lexmark MarkNet XLe ‘/prt1’ for parallel port 1

‘/prt2’ for parallel port 2
‘/prt9’ or ‘/ser’ for serial port
IBM Network Print Server ‘pr1’ through to ‘pr8’
IBM Network Printer (4312, 4317, 4324) PASS (or TEXT if PASS does not work)
IBM 3130 ‘afccu2’
Intel Netport XL TEXT1 for parallel port 1

TEXT2 for parallel port 2
Intel Netport Pro LPTx_PASSTHRU where x = port no.

LPTx_TEXT where x = port no.
UNIX/RISC printer queue name (case sensitive)
PC printer queue name (often case sensitive)
Note
The Send TCP/IP Spooled File (SNDTCPSPLF) command can be used in
place of the LPR command. The parameters and capabilities of these two
commands are identical.
8.1.7.3 Configuring LPD on the AS/400 host

The LPD server can be configured and started using Operations Navigator.
Follow these steps:
1. Start Operations Navigator by clicking Start->Programs->IBM AS400 Client
Access->AS/400 Operations Navigator. The AS/400 Operations Navigator
window appears as shown in Figure 60 on page 129.

Figure 60. Operations Navigator - TCP/IP servers
2. Double-click the system icon (A) for the AS/400 system that you are
configuring. The system components appear.
3. Double-click the Network icon (B). The network components appear.
4. Double-click the Servers icon (C). The available server types appear.
5. Double-click the TCP/IP icon (D). All of the TCP/IP servers are listed in the
right window.
6. Right-click on the LPD server in the right-hand window. The context menu for
the LPD server appears (Figure 61 on page 130).
Printing 129
Figure 61. Properties option on the LPD server context menu
7. Select Properties from the context menu. The LPD Properties window
appears (Figure 62).
Figure 62. LPD Properties window
You can now select the number of listener jobs to be started and whether the LPD
server should be started whenever TCP/IP is started on the AS/400 system.
You can also specify that one or more LPD servers can be started automatically
using the Change LPD Attributes (CHGLPDA) command. See Figure 63 on page 131
for an example of the attributes that can be set using this command.

Change LPD Attributes (CHGLPDA)
Autostart servers . . . . . . . *YES *YES, *NO, *SAME

Number of initial servers . . . 2 1-20, *SAME, *DFT
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Figure 63. Changing the LPD server to start automatically
To start the LPD automatically whenever TCP/IP is started, set the Autostart
servers parameter to *YES. To ensure that the LPD must be started manually, set
the Autostart servers parameter to *NO.
The CHGLPDA command can also be used to specify how many LPD servers are
started when LPD is started. Figure 63 also shows an example of the attributes
that can be set using this command.
When LPD is started with the STRTCP command, the full number of servers
specified on this screen are started. When LPD is started with the STRTCPSVR
command, only one server is started.
An LPD server is required for each file that is received at one time. One LPD
server can be started, but it means that only one file can be received from a
remote LPR client at a time. It is more often useful to start two or more LPD
servers so that LPR clients are not forced to wait to send files.
Starting the LPD server manually

If you set the Autostart server parameter to *YES when setting the LPD server
attributes, the server is started when TCP/IP starts. You can start the LPD server
manually through Operations Navigator by following these steps:
1. Start Operations Navigator, and open the TCP/IP servers display (see steps 1
through 5 in 8.1.7.3, “Configuring LPD on the AS/400 host” on page 128).
Printing 131
Figure 64. Start option on the LPD server context menu
3. Select Start from the context menu. You can also start the LPD server
manually by issuing the command:
STRTCPSVR SERVER(*LPD)
Viewing the active LPD servers

You can use the Work with Active Jobs (WRKACTJOB) command to view the
currently active LPD server jobs (Figure 65 on page 133). The servers run in the
QSYSWRK subsystem and have names in the format QTLPDnnnn.

Work with Active Jobs
CPU %: 4.4 Elapsed time: 00:00:10 Active jobs: 128

2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...
Opt Subsystem/Job User Type CPU % Function Status

QTFTP31808 QTCP BCH .0 DEQW
QTGTELNETS QTCP BCH .2 DEQA
QTGTELNETS QTCP BCH .0 DEQW
QTLPD00839 QTCP BCH .0 DEQW
QTLPD02503 QTCP BCH .0 TIMW
QTMSNMP QTCP BCH .0 PGM-QTOSMAIN DEQW
QTMSNMPRCV QTCP BCH .0 PGM-QTOSRCVR TIMW
QTPOP00577 QTCP BCH .0 DEQW
More...
Parameters or command
===>
Figure 65. Using WRKACTJOB to view the active LPD servers
Stopping the LPD server manually

You can stop the LPD server manually through Operations Navigator by
completing these tasks:
1. Start Operations Navigator and open the TCP/IP servers display (see steps 1
to 5 in 8.1.7.3, “Configuring LPD on the AS/400 host” on page 128).
Printing 133
Figure 66. Stop option on the LPD server context menu
3. Select Stop from the context menu. You can also stop the LPD server jobs
manually with the command:
ENDTCPSVR SERVER(*LPD)
This command ends all LPD server jobs, including any that are currently
receiving any LPR requests.
8.1.8 Sharing printers

With AS/400 NetServer, you can make AS/400 output queues available as
network printers to PC clients in the network. Sharing an output queue with
AS/400 NetServer works almost the same as sharing a directory.
To open AS/400 NetServer in Operations Navigator, double-click on the options

Network->Servers->TCP/IP->AS/400 NetServer as shown in Figure 67 on page
135.

Figure 67. AS/400 NetServer in Operations Navigator
This opens up a new windows, which is shown in Figure 68.
Figure 68. New file share
The display shown in Figure 69 on page 136 appears.
Printing 135
Figure 69. Creating a printer share
Share name is used to identify the print share on the network.
You can type the name of the Output queue and Output queue library directly, or
you can click Browse... to open another display (Figure 70).
Figure 70. Browse Output Queues

You can select the output queue you want to use from the list. If the list is long
and you know approximately what you are looking for, you can search for a
specific output queue by specifying a name or a generic name using wildcards
and a library.
Note: On the AS/400 system, use the Edit Object Authority (EDTOBJAUT) command
to make sure that the users of this print share are authorized to use the output
queue.
Click OK to return to the previous dialog.
The Printer driver field contains the name of the printer driver that is appropriate
for this share. When PCs connect to the print share, this name identifies the
printer driver that has to be installed on the PC to use this share. The text string
has to match the name of a printer driver known to the operating system of the
PC. For example, IBM AFP 300 is the name of an IBM AFP printer driver. You can
find the name of the printer driver when you install the driver on the PC. This is
described in 8.1.9.3, “Installing a network printer” on page 143. In Figure 81 on
page 144, the available printer drivers for a manufacturer are listed under
Printers.
Spooled file type is Auto-select, User ASCII, Advanced Function Printing, or SNA
character string. These types are described here:
• Advanced Function Printing (AFP) is a printer definition language that is
typically used on laser printers attached to the AS/400 system. It is used to
mix text and graphics, and use such elements as overlays and page
segments.
• SNA Character String (SCS) is widely used with matrix and line printers
attached to the AS/400 system. SCS printers are typically used to print lists.
• User ASCII is used when the application is able to generate printer output
specific to a certain type of printer. An example of this is a PC printer attached
to a PC5250 session that uses Hewlett Packard’s Printer Control Language
(PCL). Another PC attached to the AS/400 system can generate output for a
PCL printer and send it directly to an AS/400 output queue configured for the
PC printer also attached to the AS/400 system. The AS/400 system takes care
of spooling the output, but passes the data to the printer without touching the
data stream itself.
• Auto-select tries to determine which type of printer data stream is used in the
output sent to the AS/400 system.
We suggest that you leave Auto-select "as is" unless you experience problems
when printing.
You can specify a Printer file and Printer file library if you need to define printer
attributes. The setting of the Spooled file type parameter overrides any spooled
file type information in the printer file. You can type the name of the printer file
and library directly, or you can click Browse... next to these parameters. When
you do, the window shown in Figure 71 on page 138 appears.
Printing 137
Figure 71. Browse Printer File
Click OK after you complete the Print Share Properties page. This updates the
list of shares in the AS/400 NetServer window. The output queue is then available
for use.
You can right-click on the share name in the AS/400 NetServer window to change
the properties or end the sharing of the output queue.
The other place in Operations Navigator where you can define a print share is
under Basic Operations, Printers. While the procedure to create a print share is
almost the same as before, it is based on the printer view of Operations Navigator
and not on AS/400 output queues.
Right-click on the printer you want to share, and select Sharing->New Share...
as shown in Figure 72 on page 139. The procedure to define a print share is
identical to the one previously described.

Figure 72. Define a printer share
Notice that some of the printers in Figure 72 (for example, PRT02) have a hand
symbol. This indicates that the output queue associated with the printer is already
shared.
8.1.9 Using AS/400 NetServer shares

We have worked with AS/400 NetServer only within the Operations Navigator.
Although you manipulate the AS/400 NetServer configuration from your PC with
Operations Navigator, your PC has no knowledge about AS/400 NetServer. In
Operations Navigator, you see the AS/400 NetServer because you are connected
to an AS/400 system.
8.1.9.1 Finding AS/400 NetServer shares

To use a shared resource, you have to connect to AS/400 NetServer. If you have
a simple network where everything is contained in one LAN segment and the
AS/400 NetServer domain is the same as that of your PC, the AS/400 NetServer
appears in your Network Neighborhood. If your PC is part of a more complex
network, it is more likely that you have to search for AS/400 NetServer.
There are several ways to find AS/400 NetServer. The method described here is
one of them. However, use the method with which you are familiar.
On your Windows desktop, select Start->Find->Computer. The window shown in

Figure 73 on page 140 appears.
Printing 139
Figure 73. Finding AS/400 NetServer
Enter the name of AS/400 NetServer, and click Find Now. AS/400 NetServer
should appear in the list, and the field Location should contain the domain name
of AS/400 NetServer.
However, if AS/400 NetServer and the Windows PC are in the same domain, the
location field appears as Network Neighborhood.
If the Windows PC user matches the AS/400 user but the passwords do not
match, the location field shows Unknown.
If AS/400 NetServer does not show up at all, enter the IP address of the server
instead of its name. This should work in most cases.
If AS/400 NetServer shows up correctly, connect to it by double-clicking on its

name.
If you use the same name and password to connect to Windows and your AS/400
system, you are transparently logged on to AS/400 NetServer.
Windows 95 and Windows 98 always try to log on automatically to a shared

resource using the Windows user name and password. If an automatic logon is
not possible, you are prompted for a password (Figure 74 on page 141 or Figure
75 on page 141).
To automatically logon from a Windows 95 or Windows 98 client, the Windows

user name and the AS/400 user profile name must match. If the names are
different, you cannot log on to AS/400 NetServer using this method because you
cannot specify a different user name in this dialog.

Figure 74. Windows 98 network logon
Windows NT is much more flexible. If it cannot logon to a shared resource

automatically, it presents a dialog asking for a user name and password (Figure
75).
Figure 75. Windows NT network logon
Once you successfully connect to AS/400 NetServer, an explorer-type window

opens. It presents you with all of the shares configured for directories and output
queues.
8.1.9.2 Mapping a network drive

Instead of using Network Neighborhood to find an AS/400 NetServer share, you
may want to map a network drive letter to shares that you use often. Sometimes
you need a drive letter to use the directory configured as an AS/400 NetServer
share. You can map a network drive with the Windows Explorer functions or you
can use Operations Navigator.
1. To map a drive letter to a AS/400 NetServer Share within Operations
Navigator, follow the path File Systems->File Shares.
2. Right-click on the file share name to which you want to map a drive letter, and
select Map Network Drive as shown in Figure 76 on page 142.
Printing 141
Figure 76. Map Network Drive
Another display appears as shown in Figure 77.
Figure 77. Map Network Drive
3. Specify the drive letter you want to use. The pull-down list only contains drive
letters that are currently not in use.
The Connect as field can contain an AS/400 user ID that you want to use to
logon to AS/400 NetServer. This option is only available for Windows NT and
is useful if you need different user names on Windows NT and on your AS/400
system. If the field is empty, the Windows user name is used to connect to
AS/400 NetServer.
Do not check the box Reconnect at logon if you want to use a drive letter with
an AS/400 NetServer resource only during one Windows session. Otherwise,
the connection is made every time you start your PC and log on to Windows. It
can greatly prolong the startup time of Windows.
4. Click OK to accept your changes.
Network drive free space

Windows for Workgroups, Windows 95, and Windows 98 display a maximum
available free space of 2 ,147, 483 KB for an AS/400 NetServer network drive.
This is a limitation of these Windows versions. Windows NT shows the correct
value.

8.1.9.3 Installing a network printer
Once you share an AS/400 output queue with the network, you need to enable
your client PC to direct output to this output queue. This is done by installing a
network printer in Windows.
There are three possible data streams that AS/400 NetServer printer shares use:
• SNA character string (SCS)
• Advanced Function Printing (AFP)
• User ASCII
It does not matter how the printer is attached to the AS/400 system, either locally,
over a LAN, or through a PC5250 printer emulation session. All you need to know
is the make and model of your printer:
• To use an IBM AFP or SCS printer, you can install the printer drivers shipped
with Client Access Express for Windows.
• If you are using AS/400 NetServer without Client Access Express for
Windows, you can find standalone AFP and SCS printer drivers in the Client
Access for Windows 95/NT directory (\QCA400\Win32\Install\Printer) on the
AS/400 system. An IBM AFP printer driver is also available from the IBM
Printing Company on their Web page at:
http://www.printers.ibm.com/driver.html
• If the printer you want to connect to is a PC printer used in a PC5250 printer
emulation session, see 8.1.12, “Sharing a PC printer” on page 146.
• If the printer that you share is neither an AFP or a SCS printer or a PC5250
printer emulation session, you need to install the driver of the printer
manufacturer.
Complete these steps to install a network printer on a PC using the printer drivers
installed with Client Access Express for Windows:
1. Connect to AS/400 NetServer and open the explorer view of the AS/400
NetServer shares. The window shown in Figure 78 appears.
Figure 78. Available AS/400 NetServer shares
2. Double-click on the print share you want to use. This opens a message box
(Figure 79 on page 144).
Printing 143
Figure 79. Installing a printer driver
3. Click Yes. This opens another message box (Figure 80).
Figure 80. Connect to printer
4. Click OK, and the Add Printer Wizard starts (Figure 81).
Figure 81. Add Printer Wizard
5. From the list of manufacturers, select IBM . From the list of printers, select the
proper model.
For AFP, the first four available models (IBM AFP 144 through IBM AFP 600)
are generic. The number represents the printer resolution in pixels per inch.
The rest of the list represents actual printer models. At the end of the list, you
can find an entry for Facsimile Support/400.
Select the appropriate printer model. The name of the printer model is the
Printer Driver name you need to specify when defining a print share as shown
in Figure 69 on page 136.
Click OK on this panel to add a printer object to your PC’s printer folder. You
can now use this printer from any Windows application.
8.1.9.4 Using AS/400 NetServer from the command prompt

There are still a few users who prefer a simple command line over a GUI. And
there are still commands in Windows 95/98 and Windows NT that allow network

configuration through a command prompt. Of course, these commands can also
be used in batch files. Here are a few examples:
• NET VIEW \\QAS400
Gives a list of all shared resources of an AS/400 NetServer QAS400.
• NET USE X: \\QAS400\QCA400
Maps the shared directory QCA400 on AS/400 NetServer QAS400 to drive X:.
• NET USE M: \\QAS400\QCA400 PASSWD /USER:ITSO65
Only works on Windows NT. It maps drive M: to the shared directory QCA400
of AS/400 NetServer QAS400, using the user name of ITSO65 and a
password of PASSWD.
• NET USE M: /DELETE
Disconnects the mapped drive with drive M:.
• DIR \\QAS400\QCA400
Displays the directory QCA400 of AS/400 NetServer QAS400.
8.1.10 Printing using Telnet Printer Pass Through

Printing from an AS/400 system over TCP/IP can also be achieved using Telnet
Printer Pass Through (Figure 82). Telnet Printer Pass Through is available with
the enhanced Telnet server on OS/400 V3R2 and later. The Telnet Printer Pass
Through mode allows the AS/400 user with a Telnet client that supports printer
emulation, to attach printer devices on the AS/400 system over the network and
to work over native TCP/IP.
Figure 82. Telnet Printer Pass Through
Telnet Printer Pass Through (TPPT) delivers the printer data stream between the
two systems as either EBCDIC or ASCII depending on the preferences of the
requesting client. Additionally, either of these two generic device types can be
more completely specified by requesting the AS/400 Host Print Transform (HPT)
function and selecting the specific manufacturer type. The printer data stream is
sent in ASCII.
8.1.11 Printer emulation

Printing AS/400 application output on PC-attached printers using such facilities
as Client Access/400 (CA/400) is referred to as printer emulation. In this case,
AS/400 spooled files in an SCS or an AFP data stream must be converted into an
Printing 145
ASCII printer data stream depending on the target PC printer. This conversion
can be done by one the following methods:
• PC5250 emulation based on a Windows printer driver
The transformation takes place on the PC, and only SCS spooled files can be
converted. No customization is possible.
• PC5250 emulation using Printer Definition Tables (PDT)
The transformation takes place on the PC, and only SCS spooled files can be
converted. Printer functions can be adapted by modifying the Printer Definition
Table (PDT). The modified PDT must be the Printer Definition Table (PDT).
The modified PDT must be available on all PCs using the printer.
• OS/400 host print transform
The transformation takes place on the AS/400 system. SCS and AFPDS
spooled files can be converted. Customization is possible by modifying the
Work Station Customizing (WSCST) object. The same WSCST object is used
for all printers of a similar type. For detailed information on host print
transform, see 8.1.5.2, “AS/400 host print transform” on page 122.
Redirecting PC application output, using the AS/400 system, to another PC

printer in the network is a combination of the previous two capabilities.
PC-generated output is sent to an AS/400 output queue in an ASCII printer data
stream and then printed on a Client Access/400 attached ASCII printer. This
brings the AS/400 spooling capabilities to the PC application output. For further
information, refer to the Chapter 7, “PC5250” in AS/400 Client Access Express for
Windows: Implementing V4R4M0 , SG24-5191.
8.1.12 Sharing a PC printer

This section shows you the difference between printer emulation and printer
sharing.
AS/400
1 NP12
PC2
PC1
Figure 83. AS/400 NetServer - Sharing a PC printer
Imagine the following situation (refer to Figure 83):
PC2 is connected to an AS/400 system on the Token-Ring using Client Access.

Printer NP12, which is a IBM Network Printer 12, is attached to PC2’s parallel
port. The printer is a PostScript printer.

There is a PC5250 printer emulation session on PC2 that connects NP12 to the
AS/400 system. In Figure 83 on page 146, this connection is represented with the
arrow marked with a "1". The AS/400 system cannot print to NP12 because the
printer is a PostScript printer, and the AS/400 system cannot produce PostScript
output.
While the AS/400 system cannot print to this printer directly, AS/400 NetServer
can share a printer output queue for this printer with the network. Section 8.1.8,
“Sharing printers” on page 134, explains how to do this.
In our example, the AS/400 system shares an output queue for printer NP12
using spooled file type User ASCII.
PC1 is connected to the AS/400 system and the AS/400 NetServer, and has
requested to install a network printer for the print share NP12. In the course of
installing the printer, the printer driver is requested, as shown in Figure 79 on
page 144. The printer driver used will be IBM Network Printer 12 because that is
the type of printer installed on PC1.
The (virtual) connection between PC1 and NP12 is shown as an arrow marked
with a "2" in Figure 83 on page 146.
Connection 1 is PC5250 printer emulation. The printer data stream is sent from
the AS/400 system to PC2, which, in turn, sends it to the printer attached to it.
Connection 2 is printer sharing. PC1 sends its printer data stream to the AS/400
system, which forwards it to the printer attached to PC2.
In this example, PC1 is spooling data to a PC-attached printer. Therefore, the

print share on AS/400 NetServer is configured to spooled file type User ASCII.
That means the AS/400 system does not process the data sent from PC1, but
sends it directly to PC2, which, in turn, passes it on to NP2.
8.2 Spool management

The following sections describe the AS/400 commands used to manage printed
output directed to the AS/400 spooling system. This includes:
• Creating output queues
– Local printing
– Remote printing
• Starting printer writers
– Local printers
– Remote printers
• Working with output queues
8.2.1 Creating output queues

The following section describes the steps to create AS/400 output queues to
support host printing.
Printing 147
8.2.1.1 Local printing
First, type CRTOUTQ (AS/400 system is not case sensitive), and press the F4 key.
See Figure 84 and Figure 85 for examples of the CRTOUTQ display.
Create Output Queue (CRTOUTQ)
Output queue . . . . . . . . . . > EBPCSLCLQ Name

Library . . . . . . . . . > QGPL Name, *CURLIB
Maximum spooled file size:
Number of pages . . . . . . . *NONE Number, *NONE
Starting time . . . . . . . . Time
Ending time . . . . . . . . . Time
+ for more values
Order of files on queue . . . . *FIFO *FIFO, *JOBNBR
Remote system . . . . . . . . . *NONE
User defined option . . . . . . *NONE Option, *NONE

+ for more values
More...
Figure 84. Create Output Queue (CRTOUTQ) display (Part 1 of 2)
User defined object:

Object . . . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Object type . . . . . . . . . *DTAARA, *DTAQ, *FILE...
Text 'description' . . . . . . . An output queue for AS/400 Host
Printing (Local)
Additional Parameters
Display any file . . . . . .. . *yes *NO, *YES, *OWNER

Job separators . . . . . . . . . 0 0-9, *MSG
Operator controlled . . .. . . *YES *YES, *NO
Data queue . . . . . .. . . . . *NONE Name, *NONE
Authority to check . .. . . .. *OWNER *OWNER, *DTAAUT
Authority . . . . . .. .. . . *USE Name, *USE, *ALL, *CHANGE...
Bottom
F24=More keys
This output queue normally has a printer device started using the Start Printer
Writer (STRPRTWTR) command. However, the same output queue can also be

used just as a report repository. The printouts or spooled files reside there until
they are printed, deleted, or moved to another output queue.
8.2.1.2 Remote printing

This section focuses on creating an output queue for LAN or WAN printing
capabilities. It shows how to configure to directly print to a printer that supports
LPR/LPD printer daemons. It also explains how to directly output to another host
(whether another AS/400 system, a UNIX system, or a Windows NT server) using
TCP/IP and LPR/LPD daemons. This facilitates the AS/400 system to use a LAN-
or WAN-attached printer, or a printer attached to another AS/400 system, other
hosts, or other servers.
For additional information on output queues, refer to the "Spool Support" chapter
in Data Management , SC41-5710.
Figure 86 shows an example for creating an output queue for a printer attached to
the LAN. First, type the CRTOUTQ command, and press the F4 key.
Output queue . . . . . . . . . . > EBPCSRMTQ Name

Library . . . . . . . . . . . > QGPL Name, *CURLIB
Maximum spooled file size:
Number of pages . . . . . . . *NONE Number, *NONE
Starting time . . . . . . . . Time
Ending time . . . . . . . . . Time
+ for more values
Order of files on queue . . . . *FIFO *FIFO, *JOBNBR
Remote system . . . . . . . . . > *INTNETADR
Remote printer queue . . . . . . > PASS
More...
F24=More keys
On the display in Figure 86, enter the following parameter values:

• Output queue: Name of the output queue. Substitute your printer name
instead of MVXRMTQ (It should be something meaningful.)
• Library: Name of the library for the output queue
• Remote system: *INTNETADR indicates that the printer is connected to the
system using TCP/IP
• Remote printer queue: Specify PASS. If you experience formatting problems,
try using TEXT. Consult your printer manual for additional information.
Printing 149
Writers to autostart . . . . . . 1 1-10, *NONE

Queue for writer messages . . . QSYSOPR Name
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Connection type . . . . . . . . > *IP *SNA, *IP, *IPX, *USRDFN
Destination type . . . . . . . . > *OTHER *OS400, *OS400V2, *PSF2...
Host print transform . . . . . . *YES *YES, *NO
Manufacturer type and model *IBM4317
Workstation customizing object *NONE Name, *NONE
Image configuration . . . . . . *NONE *NONE, *IMGA01, *IMGA02...
Internet address . . . . . . . . > '99.99.99.99'
Destination options . . . . . . *NONE
Print separator page . . . . . . *YES *YES, *NO
More...
F24=More keys
On the display in Figure 87, enter the following parameter values:

• Writers to autostart: 1
• Connection type: *IP (When CNNTYPE(*IP) is specified,
destination-dependent options are added to the control file which is sent to the
LPD server.)
• Destination type: *OTHER
• Manufacturer type and model: Enter a value according to your target printer
type (in this example, *IBM4317).
• Internet address: The Internet Protocol (IP) address of the network card in
the printer (in this example, 99.99.99.99). If you do not know this information,
check the configuration on the printer using the manual supplied with it or ask
the local network administrator.
Note that the Internet address is only prompted if *INTNETADR is specified for
the remote system.

User defined option . . . . . . *NONE Option, *NONE

+ for more values
User defined object:
User driver program . . . . . . *NONE Name, *NONE
Text 'description' . . . . . . . > 'Remote Output Queue For eBPCS
Printing 99.99.99.99'
Display any file . . . . . . . . > *owner *NO, *YES, *OWNER

Job separators . . . . . . . . . 0 0-9, *MSG
Operator controlled . . . . . . *YES *YES, *NO
More...
F24=More keys
The AS/400 system starts a remote writer for this output queue automatically.
This remote writer runs in the AS/400 subsystem called QSPL. When a spooled
file is in a ready state and the remote writer is started or active, the AS/400
system sends the output to the LAN-attached printer with the IP address of
99.99.99.99.
With special authority granted to this output queue, other LAN or WAN users can
share this printer from their desktop. For additional information on output queues,
refer to Chapter 5, "Spool Support", in Data Management , SC41-5710.
8.2.1.3 Creating a virtual printer device

Unfortunately, when printing to a remote writer, you do not have any direct
communication with the printer itself. A spooled file is simply sent to an IP
address. Problem determination and error recovery is limited, and there is no
feedback on printer status and little control of printer file options.
As of V4R1 and later releases of OS/400 (available for V3R7 with PTF
#SF51920), you can define an IPDS printer device description that makes your
LAN-attached IP printer look and act like a twinax attached device.
You can create a printer device description by typing CRTDEVPRT. Then, prompt it by
pressing the F4 key. The screen in Figure 89 on page 152 appears.
Printing 151
Create Device Desc (Printer) (CRTDEVPRT)
Device description . . . . . . . > EBPCSPRINT Name

Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 0 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Advanced function printing . . . *YES *NO, *YES
Port number . . . . . . . . . . > 5001 0-65535
Online at IPL . . . . . . . . . *YES *YES, *NO
Font:
Identifier . . . . . . . . . . > 11 3, 5, 11, 12, 13, 18, 19...
Point size . . . . . . . . . . *NONE 000.1-999.9, *NONE
Form feed . . . . . . . . . . . *TYPE *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Printer error message . . . . . *INQ *INQ, *INFO
More...
Figure 89. The Create Device Description display (Part 1 of 3)
The parameters with the ">" mark show which ones were changed. Leave the
defaults in the other fields. Press the Enter key to expand the hidden additional
parameters after you complete the fields on the display. The screens shown in
Figure 90 and Figure 91 on page 153 appear.
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR

Activation timer . . . . . . . . 170 1-2550, *NOMAX
Image configuration . . . . . . *NONE *NONE, *IMGA01, *IMGA02...
Maximum pending requests . . . . 6 1-31
Print while converting . . . . . *YES *NO, *YES
Print request timer . . . . . . *NOMAX 1-3600, *NOMAX
Form definition . . . . . . . . F1C10110 Name
Remote location:
Name or address . . . . . . . > '99.99.99.99'
User-defined options . . . . . . *NONE Character value, *NONE

+ for more values
More...
F24=More keys
Figure 90. Create Printer Device display (Part 2 of 3)

User-defined object:
Data transform program . . . . . *NONE Name, *NONE
User-defined driver program . . *NONE Name, *NONE
Text 'description' . . . . . . . > 'eBPCS Network Printer'
Remote network identifier . . . *NETATR Name, *NETATR, *NONE

Workstation customizing object *NONE Name, *NONE
More...
F24=More keys
Figure 91. Create Printer Device display (Part 3 of 3)
8.2.2 Starting AS/400 printer writers

Before a printer can print the spooled files, a printer writer program must be
started using either the autostart writer option or one of the following commands:
• STRPRTWTR (Start Printer Writer)
• STRRMTWTR (Start Remote Writer)
Normally, all writers are started when the system starts after an Initial Program
Load (IPL). This is done using the system value QSTRPRTWTR (Start printer
writers at IPL). The shipped value of QSTRPRTWTR is one (1), which starts all
writers. A change to this value becomes effective only at the next IPL. The writer
commands can be accessed using the Command Writer (GO CMDWTR) menu.
If a writer ends the request of a user or operator, it must be started before it can
print, unless requesting direct printing and bypassing the output queue. To end a
print writer (either a local or a remote), enter the command:
ENDWTR WTR(Writer Name) Option (*IMMED)
8.2.2.1 Local printer writer

Figure 92 and Figure 93 on page 154 show how to start a printer writer for a
locally attached printer.
Printing 153
Start Printer Writer (STRPRTWTR)
Printer . . . . . . . . . . . . > PRT01 Name, *ALL, *SYSVAL

Output queue . . . . . . . . . . > EBPCSLCLQ Name, *DEV
Queue for writer messages . . . > *REQUESTER Name, *DEVD, *REQUESTER
Form type options:
Form type . . . . . . . . . . *ALL Form type, *ALL, *STD, *FORMS
Message option . . . . . . . . *INQMSG *INQMSG, *MSG, *NOMSG...
File separators . . . . . . . . *FILE 0-9, *FILE
Drawer for separators . . . . . *DEVD 1-255, *DEVD, *FILE
Writer . . . . . . . . . . . . . *DEV Name, *DEV
More...
F24=More keys
Figure 92. STRPRTWTR prompt command (Part 1 of 2)
Start Printer Writer (STRPRTWTR)
Auto-end options:
Automatically end writer . . . *NO *NO, *YES
If yes, when to end . . . . . *NORDYF *NORDYF, *FILEEND
Allow direct print . . . . . . . *NO *NO, *YES
Align page . . . . . . . . . . . *WTR *FILE, *WTR, *FIRST
Initialize printer . . . . . . . *WTR *WTR, *FIRST, *ALL
Spooled file . . . . . . . . . . *NONE Name, *NONE, *LAST
Job name . . . . . . . . . . . . * Name, *
User . . . . . . . . . . . . . Name
Number . . . . . . . . . . . . 000000-999999
Spooled file number . . . . . . *ONLY 1-9999, *ONLY, *LAST
Starting page . . . . . . . . . *BEGIN Number, *BEGIN
Bottom
F24=More keys
Figure 93. Additional information for the STRPRTWTR command (Part 2 of 2)
Most of the parameters needed for a user or operator to start a printer writer are
on the first display (Figure 92). The information needed includes the name of the
writer, the name of the output queue (can be the writer name or a different name),
and where the printer attention messages are sent (for our example, the user or
operator that started the writer). There are other parameters that control what
form types to print, separator pages to be printed, and a name for the writer (if the
device name is not used).

The second display (Figure 93 on page 154) specifies if the printer should end
when no ready files are available, allow direct print (used to allow a program to
direct print to the device bypassing the queue; this can be used in a barcode
scenario), check page alignment, and initialize the writer. The other parameters
include:
• Spooled file
• Job name
• User
• Number
• Spooled file number
• Starting page
These parameters are used to print or reprint a specific spooled file. The
information for these parameters is retrieved by using the Work Output Queue
(WRKOUTQ) command and finding the spooled file to print or reprint. The
starting page parameter is used to start at a specific page in the spooled file for
print or reprinting.
8.2.2.2 Remote printer writer

The display in Figure 94 shows how to start a printer writer for a remotely
attached printer.
Start Remote Writer (STRRMTWTR)
Output queue . . . . . . . . . . > EBPCSRMTQ Name, *ALL

Queue for writer messages . . . *requester Name, *OUTQ, *REQUESTER
Form type options:
Form type . . . . . . . . . . *ALL Norm type, *ALL, *STD, *FORMS
Message option . . . . . . . . *NOMSG *NOMSG, *INQMSG, *MSG...
Writer . . . . . . . . . . . . . *OUTQ Name, *OUTQ, *SYSGEN

Auto-end options:
Automatically end writer . . . *NO *NO, *YES
If yes, when to end . . . . . *NORDYF *NORDYF, *FILEEND
Bottom
F24=More keys
Figure 94. Start Remote Writer (STRRMTWTR)
The STRRMTWTR command is different. It starts the writer using an output

queue name that was created as a remote queue. Some of the parameters are
the same as the STRPRTWTR command. The command specifies the queue for
messages, form type, writer name, and auto-end options.
Once the remote writer is started, all files in a ready status are sent or printed to
the remote printer or remote system.
Printing 155
8.2.3 Work with Output Queues
Now that the queue is created, you need to know how to display or view the
contents using the Work with Output Queues (WRKOUTQ) command. The
WRKOUTQ command shows the contents of a specific queue by indicating the
queue name, all output queues by specifying the special value *ALL, or all output
queues in a specific library by specifying the special value *ALL and the library
name.
From the display shown in Figure 95, you can access all output queues. Through
the options shown in Figure 95, you can:
• Change output queue attributes
• Hold an entire output queue Delete, work with (and display stored spooled
files), and release the queue
• Change the description of the queue
• Clear all spooled files stored in the queue
Work with All Output Queues

2=Change 3=Hold 4=Delete 5=Work with 6=Release 8=Description
9=Work with Writers 14=Clear
Opt Queue Library Files Writer Status

MRK MRK 0 RLS
QDMT QDMT 0 RLS
EBPCSRMTQ QUSRSYS 0 EBPCSRMTQ RLS
QDKT QGPL 0 RLS
QPRINT QGPL 6 RLS
QPRINTS QGPL 0 RLS
QPRINT2 QGPL 0 RLS
EBPCSLCLQ QUSRSYS 6 PRT01 RLS
QEZDEBUG QUSRSYS 0 RLS
QEZJOBLOG QUSRSYS 69 RLS
Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F12=Cancel F24=More keys
Figure 95. Example of Work with All Output Queues
Figure 96 on page 157 shows the Work with Output Queue display. This display
allows you to work with individual or groups of spooled files.

Work with Output Queue
Queue: EBPCSLCLQ Library: QUSRSYS Status: RLS/WTR

1=Send 2=Change 3=Hold 4=Delete 5=Display 6=Release 7=Messages
8=Attributes 9=Work with printing status
Opt File User User Data Sts Pages Copies Form Type Pty
QSYSPRT QSECOFR RDY 1 1 *STD 5
QPJOBLOG QSECOFR QPADEV0001 RDY 2 1 *STD 5
QSYSPRT QSECOFR WRKSYSVAL RDY 3 1 *STD 5
Bottom
Parameters for options 1, 2, 3 or command
===>
F3=Exit F11=View 2 F12=Cancel F20=Writers F22=Printers
F24=More keys
Figure 96. Example of option 5 on Output Queue EBPCSLCLQ
In the top right-hand corner, the Status field refers to the status of the output
queue (RLS - Released) and the status of the printer writer (WTR - Writing) in this
example. The following list shows all of the output queue status possibilities:
HLD (Held) The queue is held.
HLD/WTR (Held/Writer) The queue is attached to a writer and is held.
RLS/WTR (Release/Writer) The queue is attached to a writer and is released.
RLS (Released) The queue is released, and no writer is attached.
8.2.4 AS/400 Printer menu

The AS/400 Printer menu (Figure 97 on page 158) can be helpful to a user who is
not familiar with the system. It can be accessed by entering GO PRINTER on a
command line. This menu has options to work with spooled files, output queues,
printers, and writers. Remember, a user always has access to spooled files that
they created. However, if you want to manipulate other printing features, you
need *SPLCTL special authority.
Printing 157
PRINTER Printer
Select one of the following:
1. Work with spooled output files

2. Work with printers
3. Change job printer
4. Work with printer device status
5. Work with output queues
6. Display default system printer
7. Change default system printer
70. Related commands
Selection or command
===>
F3=Exit F4=Prompt F9=Retrieve F12=Cancel F13=Information Assistant

F16=AS/400 Main menu
(C) COPYRIGHT IBM CORP. 1980, 1998.
Figure 97. AS/400 Printer menu

Chapter 9. Security
This chapter describes the basic AS/400 security concepts. It also offers some
recommendations on how to setup security in a SSA’s eBPCS environment.
9.1 AS/400 security architecture

System security is an integrated function of the AS/400 system. It is implemented
at the instruction level and controls all AS/400 software functions. Users are
identified and authenticated by a single security mechanism, at the system level,
for all functions and environments available on an AS/400 system. This includes
program development and execution, database applications, office applications,
and so forth. All objects on an AS/400 system are under security control,
including libraries and files, display stations, operator console functions,
programs, menus, and so on. For further information, refer to OS/400 Security -
Reference, SC41-5302.
9.1.1 Security levels

The AS/400 system has five levels of security controlled by the entry in the
QSECURITY system value. An IPL is required to make a change. IBM
recommends running at level 40. The security levels are:
• Level 10: Level 10 is no longer supported starting at V4R3.
• Level 20 (Password): The system requires a user ID and password for signon.
All users are given access to all objects.
• Level 30 (Password and Resource): The system requires a user ID and
password for signon. The security of resources is enforced.
• Level 40 (Password, Resource, and Operating System Integrity): The system
requires a user ID and password for signon. The security of resources is
enforced. Additional integrity protection features are also enforced.
• Level 50 (Password, Resource, and enhanced Operating System Integrity):
The system requires a user ID and password for signon. The security of
resources is enforced. Level 40 integrity protection and enhanced integrity are
enforced. Security level 50 is intended for AS/400 systems with high security
requirements. It is designed to meet C2 security requirements.
9.1.2 System integrity

The integrity of the operating system is an important prerequisite for the
implementation of security controls. The AS/400 system has good integrity for
several reasons:
• Precisely controlled storage that addresses limits for a user
• Security implementation at the instruction level
• A physical keylock that controls the operating system security environment
• A precisely defined method that provides limited capabilities for users
• A security system that is an integral part of the total system
• A communications environment with security features built in at the lowest
level
• Special hardware to validate software pointers

• Complete auditing capabilities of system and user functions
• Because AS/400 objects can be accessed only by name, security cannot be
bypassed to access an object
9.2 AS/400 security system values

The AS/400 system has over 100 variables that control system-wide functions.
These are called system values . Some of the system values are security related.
These security-related system values fall into four main categories:
• General security defaults
• Audit control
• Password rules
• Other system values related to security
9.3 AS/400 users and groups

The following terms and concepts are involved in defining users and their
authorities to the AS/400 system. Users are defined with profiles and can:
• Be organized into groups
• Have special capabilities
• Have special limitations
9.3.1 User profiles

User profiles contain information that describes a system user and that user's
privileges and limitations when using the system. The profiles also list the objects
that the user owns or is authorized to use. For objects owned by a user, the
profile also contains lists of other users' authorizations to those objects.
9.3.2 Special authorities

All security systems have special user privileges for certain security and system
administration functions. Special authorities allow certain users to administer
AS/400 security and system tasks. There are eight special authorities, which are
not hierarchical:
*ALLOBJ All object authority is granted for accessing any system resource.
*AUDIT Allows the user to perform auditing functions.
*JOBCTL Allows the manipulation of a job and output.
*SAVSYS Used for saving and restoring the system and data without having
explicit authority to object queues and subsystems.
*SECADM Allows the administration of User Profiles and Office.
*SERVICE Allows access to special service functions for problem diagnosis.
*SPLCTL Allows the control of spool functions.
*IOSYSCFG Allows the change of system configuration.
9.3.3 User classes

There are five user classes that are hierarchical in authority. The classes
represent different roles in the IT environment. These are convenient ways to

assign the special authorities listed in the previous section to different types of
users. The five user classes with their default special authorities include:
*SECOFR Security Officer (all levels—*SAVSYS, *ALLOBJ*, *JOBCTL,
*SERVICE, *SPLCTL, *SECADM, *AUDIT, *IOSYSCFG)
*SECADM Security Administrator (at security level 20— *ALLOBJ, *SAVSYS,
*SECADM, *JOBCTL; at security level 30 or higher—*SECADM)
*PGMR Programmer (at security level 20—*ALLOBJ, *SAVSYS, *JOBCTL;
at security level 30 or higher—no special authorities)
*SYSOPR System Operator (at security level 20—*ALLOBJ, *SAVSYS,
*JOBCTL; at security level 30 or higher—*SAVSYS, *JOBCTL)
*USER End User (at security level 20 - *ALLOBJ, *SAVSYS; at security
level 30 or higher—no special authorities)
A user class also affects what options are shown on the system menus. A user
with higher authorities sees more of the system menu options. A user with fewer
authorities only sees the menu choices allowed by the user class. A user may be
given any of the previously mentioned special authorities regardless of user
class. Letting the special authorities be assigned automatically to match the user
class is a convenient way to get started.
Special authorities can be assigned specifically by the security officer or security

administrator when one of the standard user classes does not have the desired
combination of authorities.
9.3.4 Group profiles

A user profile may be linked to a group profile. This allows all the members of the
group to share common attributes, common access to selected objects, and
common ownership of objects. A user is not required to be a member of a group.
A user may be a member of up to 16 different groups. Group profiles are used to
organize users along job functions. The profiles also simplify the assignment and
administration of object authorities by authorizing users through a smaller
number of group entries. When designing groups, it is important that the group
ownership concepts are well understood. It is also important that good naming
conventions are used.
A group profile is implemented as a user profile. It is created just like a user

profile. When granting authority, the AS/400 system does not treat groups any
differently than user profiles. For easy management, it is better that user and
group profiles be used as separate entities. One way to enforce this is to set the
group profile password to *NONE. This prevents signon using a group profile.
9.3.5 Limited capability

A user may be assigned limited capability. This is done when creating or
changing a user profile. Limited capability, when used with an appropriate initial
program or initial menu, can restrict a user to a desired subset of the system's
functions. Some local programming is necessary to accomplish this.
Limited capability (LMTCPB keyword of the CRTUSRPRF or CHGUSRPRF commands)

may be set to no, partial, or full. The selected value affects the initial program,
initial menu, current library, current attention program (associated with the
attention key on the terminal), and access to general system commands.
Security 161
9.4 AS/400 object protection
Since all AS/400 data structures (system and user) are objects, the security
system is primarily concerned with protecting objects. All objects have some
common structures in their control blocks (invisible to the normal user). This
allows a unified approach to security, since all objects interface the same way to
the security routines.
9.4.1 Authorities
In AS/400 terminology, an authority is the permission to access an object. The
object owner and the security officer (or other *ALLOBJ users) can grant or
revoke authority to an object. It is important to understand the difference between
authority to an object and authority to the data in the object. Operations such as
moving, renaming, saving, or deleting apply to the object as such. It is possible to
have authority for these operations without having access to the data stored in
the object. Likewise, one can have full access (read, write, update, delete,
execute) to the data in an object without having full authority to manipulate the
entire object.
Figure 98 shows the relationship between the object rights and the data rights.
O b je c t R ig h ts
*O B JO P R (O b je c t O p e r a tio n a l)
*O B JM G T ( O b je c t M a n a g e m e n t)
*O B J E X IS T (O b je c t E x is te n c e )
O b je c t (A u th o r iz a tio n L is t M a n a g e m e n t)
*A U T L M G T
A u th o rity * O B J A LT E R ( O b je c t A lte r)
*O B J R E F ( O b je c t R e fe re n c e )
D a ta R ig h ts
*R E A D ( R e a d D a ta )
*AD D (A d d D a ta )
*U P D (U p d a te D a ta )
* D LT (D e le te D a ta )
*E X E C U T E (R u n a P ro g ra m )
Figure 98. Object authority elements
The following authorities are independent (not hierarchical). For some operations,
a combination of authorities is required:
*OBJOPR The object operational authority controls the use of an object and
the ability to look at the description of the object. It is needed to
open a file and, therefore, usually assigned in combination with
the desired data rights.
*OBJMGT The object management authority controls the move, rename,
and change attribute functions for the object, and the grant and
revoke authority functions for other users or groups.
*OBJEXIST The object existence authority controls the delete, save, restore,
or transfer ownership operations of an object.

*AUTLMGT This authority is needed to manage the contents of an
authorization list associated with the object. This is a specialized
security authorization that is not usually grouped with the other
seven object authorities.
*OBJREF This authority is needed to specify a database file as the first
level in a referential constraint.
*READ Controls the ability to read data from the object.
*ADD Controls the ability to insert a new entry (such as a new record in
a file) into the object.
*UPDATE Controls the ability to modify existing entries in the object.
*DELETE Controls the ability to remove existing entries (for example,
records) in the object. Deleting the entire object requires
*OBJEXIST authority.
*EXECUTE Controls the ability to run a program or service program, and to
locate an object in a library or a directory.
Some common combinations of authorities were given special names as an

abbreviated form. For example, *USE is the combination of *OBJOPR, *READ,
and *EXECUTE. Some of the common combinations include:
*ALL Allows unlimited access to the object and its data.
*CHANGE Allows unlimited access to the data in the object.
*USE Allows data in the object to be read.
*EXCLUDE Allows no access to the object or its data.
9.4.2 *PUBLIC authority

Public authority is the default authority for an object. It is used if users do not
have any specific (private) authority to an object, are not on the authorization list
(if one is specified) for the object, or their groups have no specific authority to the
object.
9.4.3 Authorization lists

An authorization list is an important and commonly used security structure. It is
used to authorize a user or a group of users to different types of objects (such as
files or programs) secured by the authorization list.
An object may have only one authorization list associated with it. An authorization
list may secure more than one object. A user can appear on many different
authorization lists. Authorization lists are not affected when objects secured by
the authorization list are deleted. If an object is deleted and then restored to the
same system, it is automatically linked to an existing authorization list for the
object. This is an important advantage of authorization lists.
9.4.4 Adopted authority

Certain programs or commands called by a user may require a higher level of
authority (for the duration of the command) than is normally available to that user.
Adopted authority provides a means for handling this situation. Adopted authority
allows a user to temporarily gain the authority of the owner of a program (in
addition to the user's own authorities) while that program is running. This
Security 163
provides a method to give a user additional access to objects, without requiring
direct authority to objects.
9.4.5 Audit journal

The Security Audit Journal is a facility that allows security-related events to be
logged in a controlled way that cannot be bypassed. The security auditing
function is managed by the System Values QAUDCTL and QAUDLVL. If you want
to turn on auditing for the first time, it may be helpful to use the Change Security
Auditing (CHGSECAUD) command. For example, the following events may be logged:
• Authorization failures
• Object creations
• Object deletions
• Changes to jobs
• Move or rename of objects
• Changes to system distribution directory or office mail actions
• Obtaining authority from programs that adopt
• System security violations
• Printing actions, both spooled and direct print
• Actions on spooled file data
• Restore operations
• Changes to user profiles, system values, or network attributes
• Use of service tools
• System management functions
• Users' access to audited objects
• CL command strings
Information from the audit journal can be viewed or printed using the command
Display Audit Journal Entries (DSPAUDJRNE) command. Another method is to go to
the Security menu by entering GO SECTOOLS on the command line and selecting
option 22.
9.5 eBPCS and security

eBPCS security, which is controlled through the SYS600 program, allows you to
maintain user security profiles, create audit reports for all changes made to
security profiles, and update the menu authority records.
Both Second Generation Client/Server and Mixed-Mode provide the ability to

manage security. You can maintain authorities for each warehouse, company, and
transaction. You can also assign user security profiles to a group security profile,
which provides ease of maintenance for large groups of similar users.
Each call a user makes to an eBPCS program, whether through a menu or from a
command line, passes through a security checking program (SYS610B) that
validates the user's authority to that program as configured within SYS600. If
authorization is not allowed for that user and program combination, a message
displays on the panel and no processing is allowed.

BPCS Security Maintenance (SYS600) Application Screen Navigation
Summary
ENTER
BPCS
Sign-on
F3 F3
F3
SYS500-01 <ENTER> SYS500-06 SYS500-06
Logo Panel BPCS System
Main Menu Functions Menu
Select 1 or SYS600,
and <ENTER>
Select 1=Create,
2=Revise,
3=Copy,
4=Delete,
or 5=Display F3
and Valid User Profile, SYS600D1-01 Filter Panel
SYS600D2-01
and <ENTER> F13
Security Master Security Master Filter
F3
Maintenance Selection Options
<ENTER>
<ENTER> Select 1=All
SYS600D2-02 SYS600D2-03 Records
<ENTER> or 2=Active
Security Master Security Master Records Only
F3
Maintenance Maintenance and <ENTER>
F3
Figure 99. eBPCS security flow
9.5.1 Controlling access to eBPCS

Access to the SYS600 program is available only if users are granted eBPCS
security officer status within their own user security profile. The eBPCS security
officer can add, change, or delete user security profiles and maintain
authorization for any user in his environment.
eBPCS has three levels of control which are discussed later in this chapter:
• Product access control: This is the highest level at which access control
may be assigned. It is used to limit access to the eBPCS products for
individual users.
• Program access control : This level is optional and is used to limit access to
programs within the eBPCS products for individual users.
• Function/action access control: This is used to limit access to actions or
functions performed within the e BPCS applications for a group of users.
Security 165
9.5.2 AS/400 security access
Before creating a user within eBPCS, a valid AS/400 User Profile must exist. A
standard eBPCS user should be created with the parameters shown in Table 25.
Table 25. Standard eBPCS user profile
Field Input Description
User Profile BPCSMM User name and initial
User Password *USRPRF Default to user name
Set Password to expired *YES Change password at first sign on
Special Authority *JOBCTL Job control
Group Profile SSA SSA group
Owner *GRPPRF SSA owns all objects created
Initial program to call BPCSMENU BPCS initial menu program
Library BPCSUSR Where to find BPCSMENU
Initial Menu *SIGNOFF No default menu
Limit Capabilities *YES No command line access
Text Description BPCS USER Description line for text
9.5.3 Concepts of eBPCS security

There are many ways in which to secure an application on the AS/400 system.
OS/400 has a complex security set-up which can be applied to each and every
object on the system. Using object level security (for example, each user is
authorized to every object to which they require access) is time consuming, a
maintenance nightmare, and expensive in terms of performance. Even using
Group Profiles to secure access can be as bad as individual profiles.
SSA recommends a simplistic solution to securing the application. This solution

works for both Mixed-Mode and Second Generation Client/Server. It follows the
five golden rules:
• All eBPCS objects are owned by a Group Profile (SSA).
• All users belong to that Group Profile.
• Users do not have access to the command entry line.
• All access is through the eBPCS Menu System.
• eBPCS security is implemented.
Note: If access is required via an ODBC application, extra security must be put in
place.
The first four options are controlled by the AS/400 User Profile as described
above. The fifth rule is explained in the remainder of this chapter.

9.5.4 Implementing standard eBPCS security
As mentioned at the beginning of this chapter, there are three main levels of
eBPCS security:
• Product access control
• Program access control
• Function/action access control
Before any level of security can be given, an eBPCS User Profile must be
created. This is done through a Mixed-Mode menu option or by selecting options
through a Second Generation panel menu. In the example used here, the eBPCS
User Profile is created using the Second Generation Client/Server product.
This is accessed by selecting Cross-Product Applications, System Parameters,

then clicking on the BPCS Security Maintenance icon (Figure 100).
Figure 100. System Parameters display
Having clicked this icon, you see the main SYS600 panel (Figure 101), which
allows the addition, maintenance, and deletion of eBPCS User Profiles.
Figure 101. Security Master Selection
By typing in the new user profile name and pressing file create, the panel shown
in Figure 102 on page 168 is displayed. Here, you can create the new user.
Security 167
Figure 102. Add User Profile dialog box
9.5.4.1 Product access control

The Security Maintenance Master panel (Figure 102) has two main parts. The top
part of the screen defines the level of the user, the default language to be used,
grant or deny access to all products, allow access to the Attention Key
Processing program and to which group the user belongs. The group is discussed
in 9.5.4.3, “Function/action access control” on page 171.
Figure 103. Security Master Maintenance - Products A
Security type
There are five allowable options for Security Type, although e BPCS currently only
uses the first two:
S eBPCS Security Officer. The eBPCS Security Officer has access to all
eBPCS products, companies, and warehouses, and has the authority to
maintain all eBPCS users in the same environment.
U eBPCS User. The eBPCS User has access to eBPCS as defined by the
Security Officer.
P Programmer
D Database Administrator
O Operator
Default language
Three blank characters in this field are the default for English. Other codes are
included with the purchase of other language objects. When the user signs onto
eBPCS, this field is combined with the language library mask (maintained in
SYS041D) and becomes the name of the language library. This library is then

placed at the top of the library list for the job to use the message file in the
associated language to display all screen or panel literals.
Attention Key processing

This turns on or off the ability to use the eBPCS AS/400 Attention Key Processing
Program.
All Products flag

The flag to authorize All Products (1=Authorized, 0=Not) works in conjunction
with the lower part of the screen.
The lower part of the screen lists all of the eBPCS products using their three letter
code and description. Next to each product is a code that can be set to 1 or 0.
Depending how the All Products Flag is set, this code has a different meaning.
• If the All Products flag is set on (for example, Authorized), a 1 next to a
product authorizes that product. If a zero is next to a product it means that the
product is excluded.
• If the All Products flag is off (for example, Not Authorized), a zero next to the
product authorizes just that product.
This provides a quick way to authorize or restrict users to a range of products.
9.5.4.2 Program access control

Having granted or denied access to each of the products within eBPCS the next
step is to administer security at a program level if so desired. Each eBPCS
program belongs to a product. The same principle applies at this level as it does
at the product access level. If access has been granted at the product level, then
all of the programs referenced in that product are automatically authorized.
When a new program is written, a program object must be created before eBPCS
security can control access to it. This is done using eBPCS Object Security
Maintenance (Figure 104).
Figure 104. eBPCS Object Security Maintenance
Security 169
The object name and type, along with the owning product, are added to the ZSO
file using the maintenance screen (Figure 105).
Figure 105. Adding a new object security record
As long as the program is referenced in the eBPCS Object Security file, it can
now be controlled via the security maintenance program. The panel in Figure 106
is displayed after the Product Level Maintenance screen.
Figure 106. Security Master Maintenance - Program Object Name
On panel shown in Figure 106, access to each program can be granted or denied.
If the product was granted on the previous screen, each of the programs can be
denied here if necessary. Similarly, if the product was denied, it is possible to
grant access for just one program (for example, inquiry may be allowed, but no
transaction updates).
This section also allows the Security Officer to grant and deny access by
Company, Warehouse, and Transaction Effect Codes.

9.5.4.3 Function/action access control
The lowest level of security allows some of the functions and actions within a
program to be controlled. The Group Option Maintenance panel allows you to
grant or deny access by user group to these functions and actions.
Figure 107. Group Maintenance options
Security 171
Chapter 10. eBPCS work management
Work management on the AS/400 system is the method used to manage system
resources to achieve optimum throughput. The AS/400 system contains many
objects that interact with each other and applications to process information
efficiently. When the Operating System/400 (OS/400) licensed program is
installed, it includes a work management environment that supports interactive
and batch work.
An understanding of the basic concepts of work management is an important

prerequisite to understanding how the eBPCS computing software runs on the
AS/400 platform. By its nature, eBPCS is designed to operate in a large number
of operations environments and business climates.
A basic understanding of the e BPCS operating environment is essential to

complete the configuration tasks successfully for your eBPCS implementation.
This chapter discusses AS/400 work management concepts that affect job flow
through the system. However, it is not the intent of this chapter to cover all
aspects of the subject. Various education courses are available for a greater
understanding of the subject. You can also refer to Chapter 17, "Performance
Management" in OS/400 Work Management, SC41-5306, which discusses some
of these concepts as they relate to system performance.
This document references the OS/400 Work Management , SC41-5306, and

OS/400 Performance Tools , SC41-5340. You should keep both of these manuals
available for reference during tuning exercises.
10.1 Memory management concepts

Main storage, or memory, is one of the key factors of performance on the AS/400
system. Defining the strategy for allocating main storage is one of the most
important steps in optimizing performance.
10.1.1 Storage pool configuration

It is important to segregate memory for different types of users. A batch job,
because it runs continuously, will "page in" the program and device file objects
that are referenced, as well as each block of the database that is referenced. A
task that issues constant reads to a number of database files can produce the
need for an almost infinite amount of main storage. In response, AS/400 storage
management purges the least recently used pages from memory to make room
for the next request.
If an interactive task has pages in memory, the most frequent reference possible
is every few seconds. If a batch job is allowed to compete with interactive tasks,
the interactive job replaces some of the batch job's pages on disk each time the
enter key is depressed by the interactive user. Therefore, interactive and batch
jobs should not be run in the same memory pool.
A machine with a dedicated pool for interactive users can also exhibit this page
replacing behavior if the amount of main storage is insufficient. To research this
condition, reference the Work with System Status (WRKSYSSTS) command or
System Report from the performance tools. Find the row and column with the

value for Synchronous non-database reads (NDBR). This value represents the
non-productive I/O associated with interactive processing on average. This type
of I/O represents a significant component of interactive response time. The
relevant optimum paging rates for the different AS/400 models and version of
OS/400 can be found in the IBM Performance Manuals supplied with each
release.
A large percentage of AS/400 performance problems today are a result of

insufficient memory. Faults per second are one measure and non-database reads
per transaction are another measure.
If you have several critical interactive tasks that require precedence at the
expense of all others, you may wish to further divide the memory pools. This
usually has diminishing returns. For example, you may want each remote plant to
reside in a different subsystem for control purposes, but share the memory. It is
possible to combine all interactive storage pools into one pool so that the system
manages this storage and, in concept, optimizes its use.
For more a detailed discussion of pool configuration, refer to the OS/400 Work
Management, SC41-5306, and Chapter 11, “Performance tuning and
management” on page 191, in this redbook.
10.1.2 Expert Cache

The Expert Cache facility is turned on by specifying *CALC on the WRKSYSSTS
screen, where *FIXED is the default. This usually provides significant
performance benefits as it results in better I/O management. The *CALC setting
should be reserved for memory pools that perform batch workloads.
The paging option determines whether the system should dynamically adjust the
paging characteristics of the storage pool for optimum performance. This option
is only available on shared pools and not on private pools.
10.1.3 Time slice end system value

If set to *BASE, the system value QTSEPOOL dynamically moves any job which
reaches the end of its designated Time Slice into the *BASE pool. If this system
value is set to *BASE, and there is insufficient memory allocated to it, the entire
system can be degraded. Since many of the system transitions are performed in
*BASE, it is best to remove as much application work from here as possible.
10.1.4 Dedicated night time or weekend processing

Batch throughput on the AS/400 system is highly sensitive to the size of the main
storage pool in which it is running. To test this assertion, if you have a nightly
batch job that has about the same volume from night to night, implement the
changes described in the following paragraphs and observe the results.
First, run the job in the standard batch pool. On a subsequent night, collapse the
interactive pool (if it is not being used) into the batch pool to form the largest
storage pool possible.
To observe the results, you can compare the job logs or ideally, you can run the
performance monitor during the tests. As long as you are confident that the
amount of work each job accomplished is about the same, you can compare the

run times of each job. You should expect a faster execution and a lower number
of I/Os with the larger main storage allocation and a higher CPU utilization.
In summary, for dedicated nighttime or weekend processing, additional main

storage always helps. We advise that you merge the memory from unused pools,
such as interactive, with the batch pools. Often the interactive load is just
operations personnel where response time is not critical. This additional memory
allows more code and database records to reside in main storage, which results
in more efficient use of the CPU resource and reducing run times.
10.1.5 Isolating main storage for each batch thread

Multiple batch pools should be considered. For the same reason, interactive and
batch jobs should not be placed in the same pool. The desired result of isolating
batch threads is to minimize non-productive I/O. Non-productive I/O (also
referred to as non-database) has been stressed several times as the key area to
be managed on the AS/400 system. This is critical is when you realize that it is
much faster to access information if it is already located in main storage as
opposed to retrieving it from disk.
For example, there is little in common between a BPCS production thread and a
RPG compile. By setting up dedicated main storage pools, these batch jobs will
not "steal" pages from the other task, which causes non-productive I/O as the
alternative task re-enters an activity level. This strategy should be used only if the
threads are almost continuously used. For more details, review the OS/400
Performance Tools, SC41-5340.
10.1.6 Machine pool faulting

A common area that is overlooked by many data centers is the size of the
machine pool. This can be observed by using the WRKSYSSTS command or by
running the performance monitor. The optimum value for faulting for each
processor can be found in the OS/400 Work Management, SC41-5306.
If it is found that, on average over a five-minute period, the faulting rate is greater
than the recommended level, you need to increase the amount of main storage in
this pool. To do this, modify the system value QMCHPOOL, or change the figure
on the WRKSYSSTS screen. Changes should normally be done in increments of
10% until the desired result is achieved.
For more information on this topic, review OS/400 Performance Tools ,

SC41-5340, and OS/400 Work Management , SC41- 5306.
10.1.7 Activity levels

An activity level on the AS/400 system refers to a design construct that regulates
the volume of activity in each main storage pool. It reflects the number of users or
jobs that should get CPU time at any one given moment (such as the number of
users who may press Enter at the exact same time) in a given memory pool. This
is not the same as the total number of users or jobs that are allowed to run in the
memory pool.
In a system where main storage over commitment is an issue, the appropriate

activity level setting only allows the optimum number of tasks to occupy main
storage at any given item. In other words, this feature is designed to get jobs in,
eBPCS work management 175

get them done, and then get them out. If this parameter is poorly adjusted on a
machine that is over-committed, the potential for thrashing exists. In addition, on
larger sizes of AS/400 systems with plenty of memory, if the activity level is too
high, the CPU tends to wander. By this, we mean that too many jobs will run at
the same time, and overall response time will be unstable.
Reducing the activity level in this environment forces the CPU to focus on a
smaller set of tasks and pushes those tasks to the end of a transaction faster.
Although there may be some small delay in a wait state for an activity level to
come open, this is usually less than the price of a higher multi-programming level.
A more detailed discussion of activity levels can be found in the OS/400 Work
Management, SC41-5306, and OS/400 Performance Tools, SC41-5340.
10.1.8 Purge parameter characteristics

The purge characteristic determines how a task's process access group (PAG)
would be paged in and out of main storage. If purge (*YES) is specified, a job's
PAG is transferred into main storage when this task enters an activity level. It is
then written out to DASD when this task leaves its activity level. This is
considered the right approach in a limited memory environment.
Purge (*NO) allows a job's PAG to remain in main storage until it is re-used. Or,
storage management determines by least recently used page purging that these
pages need to be used by another task and are written to DASD. This setting
works well in a memory-rich environment. By specifying purge (*YES) on the
class associated with a given subsystem, this relieves you of the decision. The
system decides if Purge (*NO) is possible and implements this by itself.
10.1.9 Job accounting

Consider using job accounting to monitor how functional areas and individuals
are using system resources. For example, as a management tool, the data in
Table 26 and Table 27 on page 177 was derived from the system's job accounting
journal.
Table 26. Summary of system utilization for the week of xx/xx/xx
Functional area (%) CPU resource (%) Disk resource
Accounting 5 15
Order Entry & Billing 35 10
Manufacturing Planning 20 15
Manufacturing Execution 5 5
M.I.S. 20 15
Executive Information Systems 5 20
Customer Service 10 20

Table 27. Interactive job breakdown by user
User Job Response Enter Date Time Aux. I/O per

name time keys active transactions
User-A DSP34 1.75 502 xx/xx/xx 5.6 27
User-Z DSP132 1.09 986 xx/xx/xx 7.9 15
Job accounting is a low-level system function that does not impose material
system overhead and can be automated to produce weekly usage reports with no
manual intervention. See OS/400 Work Management , SC41-5306.
10.1.10 System values

Several system values have already been discussed, but others can be modified
for their initial default settings to improve performance. This is especially useful in
environments where heavy communications is the norm. The following list
contains system values that typically exhibit performance leverage potential.
Use the Work with System Values (WRKSYSVAL) command to display, and if
necessary, change the following system values. All available system values are
arranged by the types or categories that appear on the Work with System Values
display:
• QABNORMSW: This value tells how the previous system end terminated. If
the value is equal to 1, the machine should be manually IPLed.
• QACTJOB: This value tells the system how many active jobs it should allow in
its internal tables. This should be set to just above the figure that you expect
to be the maximum number of jobs active at any one time. This includes all
system jobs as well as user invoked jobs. A guide to this number can be taken
from the Work with Active Jobs (WRKACTJOB) screen. The IBM-supplied
default is 20, which is generally too low.
• QADLACTJ: This is the number by which to increment QACTJOB when it is
exceeded. The default is 10, which is probably good unless you have a large
system. Both too low and too high values cause performance problems.
• QADLSPLA: This value provides additional storage to extend the Spooling
Control Block value. The default is 2048 (bytes). If you have a lot of spooling,
you should increase this value to 4096.
• QADLTOTJ: As for QADLACTJOB, this value is used to increment QTOTJOB.
See QTOTJOB later in this list.
• QBASACTLVL: This value defines the *BASE storage activity level. This
adjustment should be made in the Work with System Status (WRKSYSSTS)
page in conjunction with the memory pool distribution.
• QBASPOOL : This value defines the lower limit for the *BASE pool size.
Ensure this value is representative of the system requirements.
• QCENTURY: Defines the base century of the AS/400 system:
– 0 indicates 1928 through 1999
– 1 indicates 2000 through 2053
• QCMNRCYLMT: This is the communications recovery limit. It defines the
number of recovery attempts made by the system. The recommended value is
for you to set this to 3, unless communications recovery is a problem on your

system. Then, this needs to be increased as a temporary workaround while
the network problem is diagnosed.
• QDBRCVYWT: This is the database recovery wait indicator. For use with
BPCS, the recommended setting is 0 - Do not wait.
• QDYNPTYSCD: This is the dynamic priority scheduler. Set it to 1 - Turned on.
The dynamic scheduler is designed to manage the AS/400 system once CPU
utilization hits a constant 90+%. The system adjusts job priorities of interactive
jobs to keep the system running at peak efficiency with the restricted available
resources.
• QJOBMSGQFL: This is the job message queue full action. Set it to *WRAP. The
job message queue starts to write records at the top of the log when the
maximum log size is reached. The *WRAP and *PRTWRAP values prevent
jobs from ending abnormally when the job's message queue becomes full.
*PRTWRAP creates multiple job log spooled files for the same job. This works
in conjunction with QJOBMSGQMX, which sets the maximum size for the
message queue.
• QPFRADJ: When using BPCS, this value should be set to 0 - Performance
adjust off. Dynamic performance adjustment does not work well with the way
that BPCS jobs run on the system.
• QPWDMAXLEN: The maximum password length should be set to 8. See
BMR36959 for further details. When this BMR becomes available, this BPCS
restriction will be lifted and the password length allowed will become 10.
• QPRBHLDITV: The default to keep problem logs is 30. Many of the logs are
related to line degradation and tape errors. It is better to have a lower number.
You still have to specify a number on the DLTPRB command.
• QRCLSPLSTG : Either set this value to none and run the regular RCLSPLSTG
jobs, or set it to a low value (for example, less than 7).
• QRMTSIGN: This value limits the level of security access the AS/400 system
allows to remote users. It is not recommended for security reasons to set this
value to *SAMEPRF or *VERIFY. These settings do not provide protection for
sensitive data. If you wish to allow remote users access to your system, we
recommend that you use *FRCSIGNON.
• QSECURITY: eBPCS is verified to run at security level 40 or lower. The value
should be set to the client's security needs.
• QTOTJOB: This value tells the system how many jobs, in total, it should allow
in its internal tables. This should be set to just above the figure you expect to
be the maximum number of jobs active at any one time. This includes all
system jobs, active user invoked jobs, and probably most importantly, all jobs
that still have output waiting in output queues. A job does not leave the system
until all spooled files have been printed or deleted. A guide to this number can
be taken from the WRKSYSSTS screen. The IBM shipped default is 30, which
is usually not sufficient.
• QTSEPOOL: This value dynamically moves jobs into the Base pool when they
reach Time Slice End. If your system is memory poor, set this value to *NONE to
avoid stealing memory from the machine pool. Otherwise, set it to *BASE and
ensure there is enough memory allocated in the *BASE pool.
If you have changed QACTJOB, or QTOTJOB, the changes do not take effect
until the next IPL.

• QQRYDEGREE : This value sets the degree of parallelism for query
processing. Set it to *IO if SMP (symmetric multiprocessing) is not installed.
Set it to *OPTIMIZE if SMP is installed. If SMP is installed, you may also use the
*MAX setting. However, proceed with caution since this setting can be
resource intensive. *MAX requires sufficient memory. Also note that BPCS
programs containing SQL statements should be compiled with the option of
ALWCPYDTA (*OPTIMIZE) to take advantage of I/O parallelism for queries (the
setting is viewed via DSPPGM). See BMR 53078 for further details.
10.2 Basic memory configuration

The recommended configuration of memory is different for Mixed-Mode and
Client/Server versions of eBPCS. This section discusses each configuration.
Both Mixed-Mode and Client/Server share the same First Generation (DFS)
(OLM, CEA) Client/Server GUI requirements.
10.2.1 Mixed-Mode green screen

As in most AS/400 systems, the green-screen users reside in the interactive
memory pool. This would typically be in the QINTER subsystem that would use
the *INTERACT memory pool. Some installations may decide to split various
groups of users into different subsystems by region, country, or factory. They
should still typically use the *INTERACT memory pool.
As a rule, BPCS green-screen active users each should be allocated

approximately 5 MB of memory. However, this does not mean that if there are 100
users attached to the system, you need 500 MB of memory allocated to the
*INTERACT pool. As a general rule, 5 MB should be allocated to each of the
activity levels assigned to the pool. In turn, the number of activity levels should be
set to the number of truly active users. Truly active does not indicate users who
have merely signed onto the system, but instead refers to users who are running
processes that request CPU time. It is a good rule to set the activity level to one
third of the attached users as a starting position, and then, through normal
AS/400 fine tuning techniques, adjust this number to the optimum level.
10.2.2 Traditional batch work

Interactive jobs will submit jobs into the batch job queues defined within BPCS.
The standard job queue is QBATCH. By default, this is connected to the QBATCH
subsystem, which uses memory resource from the *BASE memory pool. SSA
recommends that the jobs running in this and any other batch subsystems you
may create should be run from a different pool than *BASE.
Typically this is one of the shared memory pools supplied on the AS/400 system
(for example, *SHRPOOL1). If more than one batch subsystem is used, the
resources of the shared pool are shared between them. Activity levels should
equal the total number of concurrent active jobs allowed to be active. The activity
level is set at subsystem level for private pools, and at the pool level for shared
pools (CHGSHRPOOL). To allocate the memory, use a guideline of 20 MB of
memory for each concurrent active batch job. The actual memory and activity
levels may need to be adjusted as the transaction levels vary.

10.2.3 First Generation Client/Server configuration
The First Generation Client/Server products (DFS or fat client includes the OLM
and CEA products in eBPCS 6.1.00) in the Mixed-Mode or Client/Server
environment require a little more planning. The preferred connection mode for
performance reasons is TCP/IP, although Mixed-Mode users have a choice to use
APPC. Follow the installation instructions for Mixed-Mode to create a subsystem
to run all of the client jobs. The installation default for Mixed-Mode is to run these
jobs through QCMN, but this is configurable. These Client/Server jobs are
represented on the AS/400 system as batch-type jobs. However, they are, in
effect, interactive jobs, since the PC user requires a good response time, and
thus should have the class attributes of normal interactive jobs. They should not
be grouped with the green-screen interactive jobs. In a Full Client/Server, the
default is to run these jobs in the same subsystem with the Second Generation
Client/Server jobs. You can change the TCPIPJOBD to point these to another
JOBQ job description if required.
When using the TCP/IP connection protocol, the server portion of the
Client/Server DFS job is controlled by a daemon called ALAUNCH. This daemon
is submitted into the subsystem created for the client jobs and waits to be
contacted by the client. When a PC client makes the initial connection, the
ALAUNCH daemon submits another copy of itself to sit and wait for the next
client. This job runs under the job name of SSATCP. The original job now controls
the program stack for the Client/Server job.
Each time a DFS icon is clicked from the BPCS Session Manager, a new instance
of the SSATCP job is started. This means that a user who has opened Currency
Translation and also opened Events Processing in CEA will have two SSATCP
sessions on the AS/400 system.
From this example, you can see that it is possible to have many active jobs
running at any one time. You have to allow enough memory and activity levels in
the subsystem to manage this.
After following the eBPCS installation instructions, identify the subsystem where
you want to run your DFS jobs for the CEA and OLM products. Ensure that
TCPIPJOBD has a JOBQ listed that is a valid entry in the subsystem that you
want (change this if required). The memory should be allocated to the subsystem
using the following assumption. The subsystem requires a minimum of 40 MB,
plus an additional 8 MB of memory for each active session.
Consider this example:

• A company has 15 CEA users. At any one time during the working day, the
CEA users have two sessions open, but only 10 of the users are ever actually
doing anything at the same time. Although the user has two sessions open, it
would be unusual that they would exercise both sessions at the same time.
Total number of sessions to be calculated is 10.
If the user is not an average user, and would actually run both sessions
together, then both sessions would have to be catered for.
• The company also has two OLM users. OLM is no different from CEA. Lets
assume that one user is always active.
This gives a total of 11 active users. Given the calculation above, this would
result in 128 MB of memory allocated to the subsystem.

The activity level should be set at the number of active sessions expected (for
example, the number of SSATCP jobs that will actively request CPU
attention).
10.2.4 Order Entry batch posting

When a user chooses to accept an order as complete and wants to post it, there
are several different ways to do this:
• The order can be posted interactively, which locks the session until the post is
complete. This can be a lengthy process and slow the user down. However,
some companies want to be sure that the order is posted before the user
continues to the next order.
• The posting can be submitted to run in batch. This unlocks the session quickly,
but the posting can sit in a job queue for a short amount of time before being
processed. The width of the queue can be varied to control the throughput of
the Order Entry posting jobs.
For the first option, Interactive posting, there are no further configuration and
tuning options. The posting takes place as part of the job stack for the Order
Entry session.
To post the orders in batch, another subsystem can be added to the AS/400
system called something such as ORDERPOST and can be used as a way to
separate memory into a separate pool to run the order posting jobs.
A batch job queue should be added to this subsystem. It is typically named

ORDERPOST. The job queue entry in the subsystem should state that a
maximum of two to three concurrent jobs be active at any one time. This number
can vary, but tests have shown that two to three jobs are an optimum
configuration. The job description ORDERPOST in the BPCS User library should
be changed to use the ORDERPOST job queue. Also, be certain that a routing
entry exists in the subsystem for QCMD *ANY.
When a BPCS user's session is configured for batch posting, BPCS submits the
batch jobs using the ORDERPOST job description. This job description is used to
resolve the JOBQ, and the job now uses the customized job queue and
subsystem.
10.2.4.1 CEA posting batch settings

Depending on the settings used in the ACP (accounts payable) and ACR
(accounts receivable) products, journal updates can be performed immediately in
batch or saved and run all together in an "out of hours" batch run. If running
immediately in batch, it is beneficial to set up a specific subsystem, routing entry,
and job queue for this purpose. This is commonly called CEAPOST by many
users since this is the function that the CEA500BN jobs perform.
By changing the settings in the Server Maintenance panel for CEA500B in the
Open Enterprise Architecture panel, and altering the QCPRJOBD job description,
these jobs can be redirected to the new job queue and subsystem. We
recommend that the maximum active jobs at any one time should be set to 2, and
5 MB of memory allocated to each job in the subsystem.
To reach the OEA server maintenance screen, in a BPCS Mixed-Mode

environment you can request the OEA menu (OEAMNU) from the BPCS main

menu screen. You may have to go into BPCS Security Objects Maintenance, and
revise the OEAMNU CLP to say Menu Object 1 instead of 0, before bringing up
the panel. Or, you can call it from a command line by using CALL OEAMNU from
within a BPCS environment. It is a good idea to restrict this menu from most
BPCS users via SYS600, since only system administrators should use these
menu options.
From Full Client/Server, order BMR38176 to obtain the required views in the
Cross Product Applications container for the OEAMNU icon and to reset the
BPCS Security Objects so that the OEAMNU CLP is a valid menu object. The
OEA menu container is shown in Figure 108.
Figure 108. OEA menu container in Full Client/Server
Once inside the OEA container or menu, choose Server Maintenance to enter
the panels, and choose to revise CEA500B. The green-screen version is shown
in Figure 109.
CPR135D2 ******* BPCS 6.0.04 Environment *******

Revise Server Activity Maintenance SMITHG 18:01:13
Server CEA500B
Server Status Active
Trigger Queue Count 0
Processing 1 (0=Batch/Open, 1=Interactive/Open, 2=Batch/Shutdown)
Job Description QCPRJOBD
Job Queue CEAPOST
Batch Log 0 (0=No Create, 1=Create)
Recoverable Server 0 (0=No, 1=Yes)
Figure 109. CEA batch posting parameters

The first field defaults to the QCPRJOBD job description, which is shipped with
BPCS. The second field should be changed to match the JOBQ associated with
the subsystem where you want the jobs to run, such as CEAPOST if this is the
name you have chosen. This setting should also match the JOBQ listed in the
QCPRJOBD job description.
10.2.5 Second Generation Client/Server configuration

The Second Generation Client/Server products in eBPCS are designed to install
to a separate subsystem as part of the eBPCS standard installation process. The
Client/Server messaging is managed by a job called the OMS (NEWI) daemon,
which runs in the subsystem you defined on the BPCS installation panel (Figure
110).
Note: We recommend that the default value of SUBSYSN be changed to a

meaningful name.
INSTBPCS-01 SSA
Install BPCS Libraries
BPCS Data Files Library ... BPCSF__ BPCS C/S User Library... BPCSUSO_
BPCS Object Library ....... BPCSO__ DOCA User Library....... DOCALIB
BPCS Source Library BPCSS__ BPCS TCP/IP Library... . TCLILIB_
BPCS PTF Library .......... BPCSPTF NEWI Library............ NEWILIB_
User Data Files Library ... BPCSUSRF C/S Subsystem Name...... SUBSYSN_
User SRC/OBJ Library ...... BPCSUSR
Language Library Mask ..... BPCS Restore BPCS Source..... Y (Y/" ")
Auxiliary Storage Pool .... 1_____ Restore from Device..... OPT01
Enter NEW User Profile..... NEWPROFL
F3=Exit F5=Refresh F12=Cancel
Figure 110. Installation display
The display shown in Figure 110 is from the eBPCS standard installation
program. The subsystem SUBSYSN will be created to run the Second Generation
Client/Server jobs. The subsystem name is changeable on the screen.
The installation program creates the subsystem in the *BASE Pool ID of the
AS/400 system by default. For optimal performance, a separate *SHRPOOL
should be created to allow the jobs to run without memory contention.
The guidelines for calculating the activity level and pool size for the Second
Generation Client/Server subsystem are as follows:
• Number of active users in the subsystem_____ X .25 = ___ Activity Level
• Activity Level ____ X 6MB per user + 40MB = ____ Minimum Pool size
Consider this example:

• A client has 100 expected eBPCS Client/Server users.
• Activity Level = 25 or (100 X .25)
• Minimum Memory = 190MB or ((25 x 6) + 40)
The formulas given here are for you to develop a basic guideline for configuring
the system. The actual activity and memory levels may need tuning depending on
the transaction activity of the user community and the available AS/400
resources.

10.3 Program security
Remove any private authority on objects. Private authorities impact security
lookups that reflect in higher CPU utilization. As recommended by SSA, eBPCS
assigns all objects to a single user profile (called a group profile). A useful
approach is to assign all production user profiles to be members of this group
user profile. This means that they all inherit the group profile's authority at
minimal system overhead. On this basis, each production user has initial access
with the minimum amount of system overhead. If certain users are to be further
restricted, eBPCS application level security can be used by accessing the system
menu.
10.4 End-user queries

Review user created Query/400 or other proprietary queries for inadequate or
poorly created file access and processing selection criteria. Ensure that these
queries use the appropriate logical files. If a query is used regularly, consider
having it written in a high-level programming language. In addition, queries
should be strictly limited to batch.
10.5 Disk utilization

The AS/400 system performs best when disk utilization is modest. As a general
rule, the utilization percentage should reside below 70%. When utilization
increases beyond the threshold, the system progressively spends more time
looking for unused space to place the data (as well as searching for the stored
data when it is needed). This consumes unnecessary time and generally slows
down all activities. A simple solution is to merely acquire more capacity, but that
action does not address the root cause.
10.5.1 Deleted records

eBPCS typically makes use of the soft delete concept (for example, mark a
record as deleted, but allow reactivation). Since soft deleted records are not
deleted as far as OS/400 is concerned, many eBPCS files continue to grow until
some of the reorganization and purge routines are run.
Other parts of the product physically delete records. A flag that is set on the
physical file indicates if a new record can reuse the space used by a physically
deleted record. Most files in eBPCS have this flag set to yes , which makes the
best use of the DASD available. However, some eBPCS files, and possibly
customer additions or amendments, may be set to not reuse this space. Use the
Display Physical File Description (DSPFD) command to ascertain if any files
contain a large percentage of deleted records. If so, then run the Reorganize
Physical File Member (RGZPFM) command to remove the deleted records. Then,
review the setting of the reuse flag.
The RGZPFM command requires exclusive allocation of the file in addition to

significant system resources. There should be no users or batch jobs running in
BPCS when these are performed, or BPCS programs could end abnormally. Each
logical file, or access path over the data, increases the system resources and
time required. For relatively small files (under 50,000 records), this process can
occur without displacing production run time.

In a 24-hour shop with very large files, or in an environment where files have not
been reorganized for some time, deleted records can account for a non-trivial
amount of DASD. They can also present an operational challenge when
reorganization is required. In these situations, many sites have submitted
predefined RGZPFM batch commands to a job scheduler such as IBM's
Operations Assistant or Help System's ROBOT. ROBOT is one of many
third-party products cited here as an example. No recommendation is expressed
or implied. At smaller sites, the same effect can be accomplished by executing a
library-wide RGZPFM CL command for each data file oriented library on a
weekend night.
10.5.2 Job logs

A job log is a spooled file that is optionally created by the operating system at the
completion of a job. This feature is controlled by the LOG parameter on the job
description specified for each task. A value of *NOLIST will not create a spooled
file at job termination if the job ends normally. If it is not properly monitored, they
gradually accumulate on the system and literally fill up DASD.
Properly setting Message Level logging is the easiest way to control the amount
of storage that is absorbed. The above strategy, although operationally efficient,
masks what some people believe to be a valuable tool. For auditing or problem
determination, job logs are considered worthy of the overhead. Job logs give a
record of when it started, finished, and any error messages received. They also
indicate which programs sent and received the errors. If the Log CL command is
set to *YES, it logs any CL commands run during the job. Many users keep job
logs for two to five days for all jobs, However job logs are generally useful when
debugging a problem, and at other times are rarely used. We recommend that, in
general, the logging should be set to *NOLIST for BPCS jobs, unless you need to
change this setting temporarily for problem analysis.
The degree of detail (and value) in each job log can be controlled by the logging
level attributes of each job. As mentioned earlier, these attributes are inherited
from the job description specified at job initiation. As a general guideline, we
recommend that you use a logging level of LOG(4 00 *NOLIST) and LOGCLPGM(*NO).
This can be changed for all job descriptions in a library by running the following
command:
CHGJOBD JOBD(*ALL/xxx) LOG(4 00 *NOLIST) LOGCLPGM(*NO)
Here, xxx is replaced by the BPCS User library name, for example, V61
BPCSUSR.
If an automated approach for removing of old job logs is desired, the Operational
Assistant is an ideal solution. Using a simple command, all logs older than X
number of days can automatically be purged. Between this command, the logging
level, and the *NOLIST option, the site manager can effectively control this area
with minimal manual intervention.
Other utilities, such as Backup Recovery and Media Services (BRMS) can be
used to archive spooled files to media offline, which allows them to later be
restored to the system and read when required. This is ideal for taking care of
other spooled output in BPCS such as audit trails and reports that are required for
historical purposes, but which use up valuable system resources by remaining
online.

10.5.3 System journals
Journals store before and after image copies of records in files as they are
updated by the system. These images are extremely useful in systems audit and
error recovery situations, but they consume resources. Some embedded AS/400
functions use journals, and applications can use them as well. eBPCS, as
delivered, does not initialize journaling. Journaling can be initialized at the site's
direction. See 15.3, “eBPCS and journaling” on page 291, for more information on
configuring journaling and eBPCS.
The following two object types are used for journaling:

• Journals
• Journal receivers
The data (record image) is stored in the receivers (they "receive" the data). The
administrative detail is kept in the journal. This includes the name of the current
(attached) receiver, the status of the receiver, the files being journaled, etc.
The OS/400 operating system uses the system journals and receivers shown in
Table 28.
Table 28. System journals and journal receivers
Journal Journal receiver
QAOSDIAJRN QASDIxxxx for DIA files (Office, PC Support)
QDSNX QDSNXxxxx for DSNX logs
QSNADS QSNADSxxxx for SNADS files
QSXJRN QSXJRNxxxx for problem files
QZCAGJRN QZCAJRNR for job accounting
QOARCV QOARCVxxxx for Operational Assistant
The journals are in library QUSRSYS.
The QOARCVxxxx journal is generated by licensed program Operational

Assistant and has to be managed manually. Many of these journals can be
maintained by using the IBM Operational Assistant (as well as other operations
management products).
10.5.4 System history logs and problem logs

History (QHST) logs can consume a lot of disk space if they are not periodically
reviewed. You should delete the old QHST files on a frequent basis (for example,
weekly). You can implement the following procedure:
1. Save the QHST files to tape. Enter this command:
SAVOBJ(QHST*) LIB(QSYS) DEV(TAP) OBJTYPE(*FILE)
2. Use the WRKF command as shown here:
WRKF(QHST*)
3. Delete all QHST files apart from the one that is currently in use (the last one
displayed on the screen) by selecting option 4 in front of the QHST files.

Again, the Operational Assistant can be used to control this process. However,
this is done in conjunction with the system journal receivers, which you may want
to treat as a separate issue. Another disadvantage is that the QHST files are not
saved to tape. It may occur that, for example, IBM (or yourself) wants to extract
information from the old QHST files to investigate a problem.
Problems identified by the AS/400 System are recorded in the problem log. If it is
not managed regularly, this log can grow quite large in size. Clearing problems
from the problem log can be done on a monthly basis, for example. After deleting
old problems, you should purge the deleted records from the related system
database files with the RGZPFM command. You can implement the following
procedure:
1. DLTPRB STATUS(*ALL) DAYS(30)
2. RGZPFM FILE(QUSRSYS/QASXCALL)
3. RGZPFM FILE(QUSRSYS/QASXEVT)
4. RGZPFM FILE(QUSRSYS/QASXFRU)
5. RGZPFM FILE(QUSRSYS/QASXNOTE)
6. RGZPFM FILE(QUSRSYS/QASXPROB)
7. RGZPFM FILE(QUSRSYS/QASXPTF)
8. RGZPFM FILE(QUSRSYS/QASXSYMP)
The size of each of these system files is set by an installation system value.
These default settings have historically been adequate to hold one or two days of
system history (QHST), and two to four weeks of "problems". If your site has
unusual problems or logging, this shows up in more frequent creation of these
files. These files are created with names that represent their date of creation (for
example, QHST94001A). If you see non-A prefixes, there may be something
inside the logs that points to another problem.
10.5.5 User and device message queues

Although message queues are generally not a problem, they can become large in
size if users are not trained to clear their old messages. The QSYSOPR message
queue, in particular, should be frequently cleared by the operator. The message
queues can be displayed via the Work with Message Queue (WRKMSGQ)
command as shown here:
WRKMSGQ (*ALL)
This command displays all queues in order based on your library list and
authorization profile. You can then enter 4 in the action column to delete the
entire message queue object. Or, enter 14 to clear the message queue entries,
but leave the queue itself. This type of cleanup is also an option for the
Operational Assistant.
10.5.6 IPL
We generally consider it good practice to IPL the machine with the Restart option
on a regular basis, for example, weekly or monthly, depending on work
schedules:
PWRDWNSYS RESTART(*YES)

An IPL can have favorable effects on performance. Internal queues and tables
are initialized. Job structures are created and made available for use, as well as a
number of other operating system cleanup tasks.
10.5.7 Reclaim spool storage

Most sites still produce considerable spooled output that remains on the system
rather than be physically output (and then deleted from the disk subsystems). In
the past, spool storage was something that was evaluated as part of the IPL
process. A system value (QRCLSPLSTG) now provides automatic removal of
empty spool members. This system value is the number of days an empty
member is to remain on the system before it is deleted. The second option is to
manually use the Reclaim Spool Storage (RCLSPLSTG) CL command.
Empty spooled file members occur due to the way printed output is handled by
the AS/400 system. When a report is created, it is copied into a physical file in the
QSPL library. After the report is finished printing, this area of storage is made
available for future spooled output. The intent of this strategy is to minimize the
cost of producing spooled output. If an extent had to be created each time a
spooled file was generated, this would be more costly. As the design works today,
most of the time, spooled output is simply copied into existing physical file space.
The exposure with this scheme is that after an extreme peak in spooled output,
even though the reports have been deleted, the physical file space remains. By
issuing the CHGSYSVAL QRCLSPLSTG '3' command, all spool storage that has not
been occupied in the last three days is automatically removed. IBM recommends
that you set the system value to *NOMAX and then run the RCLSPLSTG command
frequently (for example, each business day). If this is inconvenient, the system
value should be set to somewhere between three and five.
A more resource-intensive situation is retaining spooled files online. Reports can

consume considerable space. For example, in one location, such files occupied a
full third of the available disk space. Most sites have learned to either eliminate
reports in the first place, output them to microfiche or optical disk, or police their
users by setting up automatic purge programs that eliminate reports older than X
number of days (typically three to five days).
10.6 BPCS processing options

The BPCS application code has many options available to help configure the
software to match the business needs of a given enterprise. The application flags
can have a dramatic effect on the overall run time of a job. The flags should be
set to match business needs. If certain functionality is not being utilized, the
application flag should be turned off.
10.6.1 Application flag settings

Run the SYS800 option from the menu to properly set each processing option
based on your chosen configuration. For example, if Promotions and Deals is not
required, ensure that the PRO flag is turned off.

10.6.2 BPCS Order Entry tuning
The Order Entry product of BPCS requires special attention when tuning the
AS/400 environment. There are parameters within the product that must be
considered and set according to the business requirements.
10.6.3 MSGID versus MSGCON

If multi-language support is not required, the display files can be changed to use
the keyword MSGCON instead of MSGID. This can be accomplished by
accessing SYS707 from the System menu. The display files to be changed are
identified on an individual basis from this program. Then, the display file and
accessing programs should be recompiled. This reduces the amount of I/O
performed by the program, and can provide some real performance gains. By
using this function, the ability to change the content of the display file becomes
more complex. Therefore, this should only be done when you are sure that you
do not need further changes to the screen layout.
10.6.4 Generic BPCS considerations

This section covers some of the generic performance considerations that affect
BPCS, but currently do not have a specific performance document. Some areas
of eBPCS give the user the ability to secure programs down to function key and
option level. Although this gives the system administrator a greater control over
"who does what", it can result in a performance overhead if a complex set of
options is specified.
The same applies for general security. The more specific options are defined in
the BPCS Security system (SYS600), the greater the performance hit is. If
possible, avoid defining all warehouses, companies, and transaction effect codes
to each user.
Some other general guidelines are:

• Avoid, where possible, Bills of Materials with more than five levels.
• Keep configurator rules to a minimum in the CFG product.
• Keep CEA segments down to reasonable levels. More than seven will start to
impact performance.
• Complex journal and book structures will impact performance.
• The more wildcards that are used in Account and Structure inquiries, the
slower it will perform.
An observable program contains information from the source of the program,

which allows the program to be traced or debugged interactively. This information
is stored along with the executable portion of the program. A program that has no
observable information requires roughly 40% less disk than an observable
program.
The amount of disk space that may be saved varies from program to program.
eBPCS programs, except security programs which are source restricted (BPCS
key validation routines), are shipped with observable information included. By
removing the observability, you also remove the ability to debug that program.
Use the OS/400 Change Program (CHGPGM) command to accomplish this task if
you want to conserve DASD in the BPCS program library.

When many BPCS environments (databases) exist, but all share the same
underlying BPCS object libraries, this set up can perform poorly if the database
sizes vary greatly (such as a full production database and a small subset of
testing data configured to share the same program objects libraries). This is
because SQL access plans potentially can be rebuilt each time the same program
is run over a different sized BPCS database, if the SQL optimizer decides to
access the data differently. Eliminate this overhead by configuring only similarly
sized databases to share BPCS program objects. Make copies of the object
libraries and configure environments to use separate object libraries if database
sizes vary greatly. Ensure that the libraries stay in sync with BPCS fixes by
following good BMR testing procedures.

Chapter 11. Performance tuning and management
BPCS application performance is directly related to the configuration of the
AS/400 system. A solid well thought out AS/400 configuration is necessary to
provide BPCS the resources that it needs to perform well. By nature, BPCS is
designed to operate in a large number of operations environments and business
climates. It can also be tailored to your unique situation. You can install the
default system profile and exercise minimal system parameter settings, or you
can follow the guidelines in this chapter to progressively tune your system. Each
location determines the exact balance between the technician's time to tune (and
retune on an ongoing basis) and the resulting performance gain. The
configuration of the AS/400 system is the foundation for a well-tuned system as
shown in Figure 111.
Figure 111. Performance analysis areas
This document references OS/400 Work Management, SC41-5306, and OS/400

Performance Tools/400, SC41-5340. You should keep both of these manuals
available for reference during tuning exercises.
This guide has been subdivided into logical sections to assist you in your work.
Each section has an initial discussion of the tuning concept, followed by the
techniques themselves. You should quickly scan the entire document before
proceeding to achieve a sense for the entire opportunity.
Then, map out a plan of attack. The first step is usually to establish a base line
profile with which you can measure progress against. Depending on the
organization's skills and desires, the customer may want to exercise this plan on
their own or have SSA assign or recommend a technical professional to assist
them.
11.1 Developing a methodology

This section briefly outlines a methodology to review performance information to
be used with eBPCS application to determine if any performance bottlenecks
exist. This section also discusses various performance tools that are available for
doing this analysis with an AS/400 server.

Understanding the performance problem in customer terms is key to minimizing
the unnecessary analysis of low priority problems or unrealistic customer
expectations, such as an AS/400 20S server model running a global eBPCS
deployment with 2000 users.
The methodology for investigation involves understanding the perceived problem,

including:
• Application function
• Design overview
• Expected response or throughput
• Perceived response or throughput
It is important to understand the problem as perceived by the users. The

expected response time goals need to be established and validated against the
application architecture to ensure that it is achievable. Questions are asked such
as:
• Is the problem system-wide or just for a specific application?
• If it is for a specific application, is the problem just for certain transactions and
not others?
• Does the problem only occur during specific time periods during the workday?
The user's locality to the server is also a consideration in this regard. Line time is
significant if the user is accessing the server through a low bandwidth line or a
heavily utilized line.
Initially, review overall system performance with consideration to the:

• Hardware error log
• System values
• Page faulting
• Activity levels
• Disk arm activity
• Disk space usage
Examine the system to ensure that the system parameters affecting performance
are acceptable and memory pool allocations and activity levels are adjusted to
suit the system. This preliminary review is done by checking the system
interactively. The purpose of this is to avoid getting deeply involved in an
application performance investigation when the problem may be with the setting
of system parameters. That is, it may be a system resource problem, rather than
an application design or implementation problem.
Carry out a detailed system performance or capacity study based on OS/400

Performance Monitor summary data or repetitive usage of system commands,
such as Work with System Status (WRKSYSSTS) and Work with Disk Status
(WRKDSKSTS). Although showing important information, using the commands
requires significant human intervention to gather sufficient data over a meaningful
period of time. Collection of Performance Monitor data and analysis of that data
through the Performance Tools/400 Advisor function and individual printed
reports provides a more a comprehensive set of information. Once the review of
summary level data is complete, you may determine that system-level tuning can
resolve the performance problem. Using the hardware performance guidelines,
you may determine that a faster CPU, more main storage, or faster or additional

disk hardware is required. Analyze the client/server application, in detail, by
collecting detailed information while running the jobs in question. Generally the
faster the resource is, the higher the utilization threshold tolerance is. The slower
the resource is, the lower the threshold tolerance is. If utilization guidelines for
the various resources are exceeded, you need to first resolve these issues. If
performance problems exist and all resource measurements are significantly
below the guidelines, application transaction performance data must be collected
and analyzed by a performance specialist.
Note that Performance Monitor data collects and the Performance Tools/400
Manager feature reports 5250-based interactive response times. Even though
Online Transaction Processing (OLTP) client/server environments are considered
"interactive" from the end user's viewpoint, the AS/400 summary level
performance data does not identify client/server transactions. Therefore, it is not
able to calculate and report "non-interactive response time".
eBPCS, like other client/server ERPs, extensively uses SQL queries. If they are
not optimized for performance, these queries can severely degrade server
performance. Such tools as STRDBMON should be regularly used to analyze
database and SQL performance. Another performance issue is creating the right
number access paths on the AS/400 system. Analyzing the available access
paths through the use of such commands as Display Database Relationships
(DSPDBR), creating the required indexes, and deleting the unnecessary indexes
on a regular basis should be done.
Performance evaluation and review is an ongoing, cyclical process. Always

remember the four key performance steps:
1. Measure
2. Analyze
3. Correct
4. Re measure
For good performance of your system, follow these steps on a regular basis.
11.2 Establishing a base line

You cannot assess how much improvement you have made if you have not
established a measurable base starting point. Establishing this base line also has
the advantage of focusing the team on the key performance issues. For example,
normal online throughput may be acceptable, but the real issue may be specific
end-of-period batch run times. In this situation, spending time improving the
performance profile of online programs would be a poor investment of time and
effort. In turn, average online throughput may be adequate, but certain key
business transactions may have overly long panel-to-panel transitions.
Therefore, the base line serves a key role in establishing a starting point, as well
as a method to determine where the performance investments should be
pursued.
The AS/400 system has a number of basic facilities that can assist you in
establishing this base line. The WRKSYSSTS, WRKACTJOB, and WRKDSKSTS
commands should be reviewed since they provide valuable overall performance
data. They should be executed during typical times of the business-processing
day and re-executed at roughly five and 10-minute intervals to establish a
Performance tuning and management 193

performance profile. These profiles can then be archived for later analysis. If the
processing load varies greatly over the business cycle, separate executions can
be performed to map out the actual profile.
11.3 Platform balancing

The AS/400 system includes a collection of sophisticated system monitors and
operating system tools that can monitor and control the system activity. In turn, as
part of SSA's systems assurance process, we recommend that you have a
reasonably balanced hardware configuration (or platform) based on anticipated
business processing loads. Plans will change as will business requirements
change. What was once a balanced configuration can become unbalanced. In
turn, there are a variety of housekeeping activities that should be performed to
keep the AS/400 system running in peak condition. The purpose of 11.4,
“Capacity guidelines” on page 194, and 11.5, “Performance analysis tools” on
page 196, is to highlight those housekeeping activities that should be reviewed. In
turn, by reviewing these areas in conjunction with baseline data, an out of
balance situation may surface.
The major performance levers observed in past sites are disk utilization,
allocation, and SQL tuning and, most importantly, memory management,
allocation, quantity, and speed. You are encouraged to review 11.4, “Capacity
guidelines” on page 194, and 11.5, “Performance analysis tools” on page 196,
before analyzing BPCS specific profiles since gains made here will have positive
effects across the entire site (as opposed to just the BPCS area).
11.4 Capacity guidelines

This section offers a quick assessment technique that will obtain some key
factors, which can be used when reviewing the rest of this chapter.
Use the WRKSYSSTS command over an elapsed time of 5 to 10 minutes. For

example, enter the command, wait the required time, and press F5. Then print
the screen image for future reference. Key items to look for are (in order):
• % CPU used (upper left corner of display)
• Jobs in system (Total jobs)
• % addresses used (both temporary and permanent)
• % system ASP used (located in upper right and refers to percent of disk
currently in use)
• Total storage (total size of the disk assigned to the AS/400 system).
If the CPU percentage is high most of the time, you may be overtaxing your
machine. If you have a large queue of batch work that has lower priority than
online activities, then the CPU percentage can be into the 90s without being a
problem. If you are optimizing online and have virtually no batch backlog, you
should expect to see percentages of less than 75%.
If the total job count is high, this indicates that spooled output reports are not
being properly cleared. Every active user is a job, as is every subsystem, pass
through job, etc. A large number of jobs, even when they are inactive, can
overtax the system's traffic manager, which leaves less time available for
application work.

If the percentage of temporary addresses is higher than the permanent
addresses (or is in excess of 50%), you have a candidate for clean up. This
usually exists when the system has not been recently IPLed. If you have done an
IPL, there is another problem that merits discussion with an IBM representative.
Again, high address usage overtaxes the system's internal routines and leaves
far less resources available for application work.
If the percent of auxiliary storage (which is the IBM term for disk or DASD) is
higher than 75%, the system, in general, will spend far too much time chasing
around looking for such items as programs, files, etc. Less than 60% implies that
space is not a problem. By using the WRKDSKSTS command, you can visually see
the activity by individual disk drive. In a well-tuned system, the activity should be
evenly balanced. If they are not, you should consider saving and deleting libraries
and then reloading them to spread them out. Unbalanced drives can happen if the
system is installed with permanent objects, such as the BPCS programs, and the
applications are converted to a production environment. After a while, the site
decides to add additional disk (usually for transaction-oriented data files that
have grown) without reloading the entire system. Units 1 and 2 should be
ignored, since they are used for OS/400 and other IBM software.
Next, use the WRKACTJOB command. As with the WRKSYSSTS command, you
should wait 5 to 10 minutes, and then press F5 to see the representative data.
Make a note of the number of active jobs (upper right), and then press the F11
key to see the elapsed data for each activity. You can then move the cursor to
either the Response time column or the CPU usage column and press F16 to
sequence the activities by greatest use first (or slowest response time, in the first
example). This helps locate any problem job that can be investigated by placing a
10 (Display program stack) or 11 (Display locks) in the action code field on the far
left. Jobs in the QCTL subsystem generally run at a priority of 10, with QINTER
jobs at a priority of 20 and QBATCH at a priority of 50 (QSPL at 60 or 50).
Interactive jobs running in pool 2 imply that the QTSEPOOL system value has
been set to *BASE and that they exceeded their time slice, and dynamically
moved to the *BASE pool. They should also be looked into as problem programs.
Watch out for user queries on the WRKACTJOB display. Review user-created
queries for inadequate or poorly created file access and processing selection
criteria. In addition, queries should be strictly limited to batch.
Use the WRKJOBD command to determine the logging level for each active job
description. The logging level guideline is 4 00 *NOLIST, with CL logging set to
*NO.
Once you run these commands over a period of several days, you should be able
to determine your current "normal" production profile or base line. You will also
find a few parameters to adjust. You can quickly adjust them one-by-one and then
re-measure or defer them until you have finished your investigations.
In any event, it is critical that you maintain these base line records to measure
your progress. It is also essential that you record key business factors (for
example, number of orders processed per day) in conjunction with this exercise.
Your business profile will surely change over time since it is historically the single,
largest driver of systems reconfiguration and enhancement.

11.5 Performance analysis tools
The AS/400 operating system contains several analysis tools to allow a thorough
examination of the application and system performance. As with all tools, the
user should have a good understanding of the application and the hardware to
get maximum benefit of the analysis data.
11.5.1 AS/400 performance tools

The following tools can be used for performance analysis:
• AS/400 Performance Tools reports
– Advisor (display or printed output)
– System
– Component
– Transaction Summary (requires Trace *ALL option)
– Transaction Detail (specific jobs only - requires Trace *ALL option)
– Lock Report (requires Trace *ALL option)
• Database Query Optimization Tools such as Database Monitor, Debug
Messages and Print SQL information.
• AS/400 Performance Explorer (PEX) *STATS can be used to find resource
intensive programs/ SQL module for a selected job or for the entire system.
• AS/400 PEX *TRACE can be used to identify I/O intensive objects and
SETOBJACC candidates.
• Job Trace
• For system-wide database analysis, such commands as DSPFD, WRKJRNA,
and DSPDBR may be used.
11.5.2 Client analysis tools

While the eBPCS application does not use ODBC, several of the SSA Portfolio
Partner products use this connection protocol. The AS/400 system provides
several tools to allow analysis at the ODBC and communication socket layer. In
most cases, the collection of the ODBC API trace data results in significant
performance degradation on the client workstation. We recommend that you
collect ODBC API trace information at a time separate from collecting the AS/400
server performance information.
11.5.2.1 ODBC trace

An ODBC trace captures ODBC connection information, ODBC API calls, SQL
statements, and ODBC error messages. An ODBC trace is useful in both error
diagnostics and performance tuning. The trace occurs at a level between the
application and the ODBC driver. Therefore, it is helpful in showing what is being
passed to the ODBC driver from the application. ODBC 3.0 includes its own trace
utility.
To perform an ODBC trace, complete these steps:

1. Click Start->Programs->IBM AS/400 Client Access->ODBC Administrator.
2. Select the Tracing tab, and click Start Tracing Now.
3. Recreate the error.

4. Select the Tracing tab (Figure 112) again. Click Stop Tracing Now to end the
trace. Do not leave the trace running since it will have a severe performance
impact on ODBC jobs.
Figure 112. ODBC Data Source Administrator Tracing tab dialog
11.5.2.2 PC error messages

Record the PC application error message, the Client Access ODBC error
message, and the SQL state. The PC application provides an error message.
Include the exact text and error numbers in the error message. When a printer is
unavailable, the image of the error message can be captured by pressing the
Print Screen key. The Print Screen function copies a bitmap of the current display
to the clipboard. Use your preferred application to access and store the error
bitmap in a folder for future reference.
11.5.2.3 Client Access ODBC error messages

The Microsoft ODBC specification defines a standard, layered error handling
protocol. Error messages include the identity of the error source, the actual error
text, the ODBC SQL State, and the return code. ODBC error messages have the
following format:
[vendor][ODBC-component][data-source] error-message text
The prefixes in brackets identify the vendor that is issuing the error, the ODBC
component involved, and the data source (DBMS). Client Access ODBC uses the
following format to identify errors whose source is the Client Access ODBC driver
or DB2/400:
[IBM][Client Access ODBC Driver (32-bit)][DB2/400 SQL]

Table 29. Prefixes used in Client Access ODBC driver error messages
Prefix Explanation
[IBM] Identifies IBM as the vendor issuing the error. If this value is
something other than IBM, the failure did not occur in IBM
code. An error starting with [Microsoft] [ODBCxxx DLL],
implies the failure was at the MS ODBC driver manager level.
[Client Access ODBC Identifies the Client Access ODBC driver as the component
Driver (32-bit)] reporting the error. When Client Access ODBC reports the
error but the [DB2/400] prefix does not follow, the error
occurred on the PC. The request was never sent to the
AS/400 system.
[DB2/400] Identifies the AS/400 system as the data source. This field,
when included, indicates that the failure originated on the
AS/400 system. The AS/400 job log may contain additional
information for these types of errors.
11.5.2.4 Client Access service packs

Updates to the Client Access ODBC driver are included in the Client Access
service packs. Verify that the latest Client Access service pack is applied on the
PC. Service packs can be ordered through ECS or downloaded from the Client
Access home page on the Web: http://www.as400.ibm.com/clientaccess
11.5.3 Network and communication analysis tools

Network tuning is key to achieving good performance. The network frequently can
be the slowest link in the system. Typically, you can improve the network
performance by reducing the network traffic or by reducing the number of turns
across the WAN network to a minimum.
Communications trace is an AS/400 communication analysis tool available from

IBM. Sniffer and other vendor tools such as Optimal, CACI, and MIL3 are
available.
11.5.3.1 AS/400 communications trace

The OS/400 communications trace facility is an important tool for isolating both
performance problems and error conditions. It traces and formats any
communications type that has a line description (for example, Token-Ring,
Ethernet, and SDLC).
AS/400 communications traces are helpful in diagnosing where a performance

delay is occurring. Use the timestamp and the eye-catcher fields to measure how
long the AS/400 takes to process a request.
Communications traces also capture the data stream being passed between
Client Access ODBC and the AS/400 database host server. IBM Support can
break down this data stream to see what is being passed between the PC and the
AS/400 system, including the SQL conversation and SQL statements, data
definitions, and errors.

Collecting a trace
Complete the following steps to perform a communications trace data collection:
1. On the OS/400 command line, type the STRSST command. Your user profile
should have all object authority.
2. Select Option 1 (Start a Service Tool), and press the Enter key.
3. Select Option 3 (Work with Communications Trace), and press the Enter key.
4. If the name of the line you want to trace is under the Configuration Object
field, type 8 in the Opt field. Press the Enter key to access the Start Trace
display. If the name is not there, press F6 to access the Start Trace field.
5. Type the following code:
Configuration object..... (line description name)
Trace description........ (Optional)
Buffer size.............. (6 or 7, the maximum size available)
Leave the other fields with the default values.
6. Press the Enter key.
7. V4R1 and later releases prompt for Trace options:
Configuration object............SITETRN
Type .....................................LINE
Select one of the following options:
• All data (no filtering)
• Remote controller data
• Remote MAC address data
• Remote SAP data
• Local SAP data
• IP protocol number
• IP address data
If the trace runs for a long time, such as when working with intermittent
problems, Select the appropriate filtering option to reduce the amount of data
collected. Use option 2 for SNA connections or option 7 for TCP/IP. Enter the
controller name or IP address. Press the Enter key to return to the Work with
Communications Traces display.
Note: The trace is now active.
8. Re-create the problem to be traced.
Ending a trace
To end the communications trace, from the Work with Communications Trace
display, select Option 2 (Stop trace). Press the Enter key.
Formatting and printing a communications trace report

From the Work with Communications Trace display, perform the following steps:
1. Select Option 6 (Format and print trace), and press the Enter key.
2. Format the trace. SNA connections are usually formatted as shown in the
following example. You must know the controller name of the PC.
Controller.................. name of the PC controller)
Data representation.........2 1=ASCII, 2=EBCDIC, 3=*CALC
Format RR, RNR commands.....N Y=Yes, N=No
Format SNA data only........Y Y=Yes, N=No

TCP/IP and AnyNet connections are usually formatted as shown here. You
need to know the IP address of the PC.
Data representation . . . . . 3 1=ASCII, 2=EBCDIC, 3=*CALC
Format Broadcast data . . . . N Y=Yes, N=No
Format TCP/IP data only . . . Y Y=Yes, N=No
Enter your choices, and press Enter.
IP address . . . . . . . . . . (The IP address for the PC)
IPX/SPX connections are usually formatted as follows.
Data representation . . . . . 3 1=ASCII, 2=EBCDIC,3=*CALC
Format Broadcast data . . . . N Y=Yes, N=No
Format IPX data only . . . . Y Y=Yes, N=No
Leave the other fields with the default values.
3. Press the Enter key, and wait for the Format of trace data complete message.
This produces a spooled file owned by the emulation session's job.
4. Press F3 three times to reach the Exit System Service Tools display.
5. Press the Enter key to end the STRSST command.
6. Type the WRKSPLF command, and press the F18 key (Bottom) to locate the
formatted traces.
The spooled files should have the file name QPCSMPRT with User set to the user
profile that ran the trace. Send the trace as requested by IBM Service.
11.5.3.2 Sniffer
A network sniffer is a non-invasive device that captures all the traffic on a
communications facility. It is good at analyzing and diagnosing lower level
communications protocols. For example, it allows you to determine whether there
are hardware related problems or addressing problems, or to track the number of
retransmissions at the transport layer. All of these issues can affect performance
across the network. It can also be used for helping to isolate performance issues
within applications. Sniffers basically produce raw data that can be analyzed
either by the sniffer itself or by another tool. The network software tools usually
have some degree of sniffing capability built in.
11.5.3.3 Other network analysis tools

Optimal Networks is a one-to-one relationship network analysis tool that
specializes at the application layer. It enables you to quickly visualize response
time performance, client/server database access, communication threads, and to
perform such functions as response time predictions under various LAN and
WAN topologies. For information about this product, visit the Web site:
http://www.optimal.com
CACI is a one-to-many network analysis tools with in-depth information on

communications performance. For information about this product, visit the Web
site: http://www.caci.com
MIL3 is a network planning tool that offers modeling, simulation, and an analysis
of the performance of communications networks, computer systems and
applications, and distributed systems. The models fit together in a hierarchical
fashion. For information about this product, visit the Web site:
http://www.mil3.com

11.6 Application tuning techniques
eBPCS is a highly configurable product. Each organization must carefully review
its intended business flow in light of the software's capabilities and determine
which processing flows most appropriately match its intended business model.
The following sections explain the key performance driver options.
11.6.1 Order Entry performance

eBPCS Order Entry provides a series of application and system tuning options
that can greatly influence response time. All other things being equal,
performance is adversely affected as more optional features are turned on.
The correct balance of function, timing, and performance is unique to each

client's needs and priorities. This guide is intended to help each client understand
and make the right choices for their environment.
11.6.1.1 Batch versus interactive

Order Entry allows Order Posting and Document Printing to be either submitted to
a job queue or synchronously tied to each driving workstation. Order Validation is
the third selectable business function. Its implementation is in process at this
time. Job submission is the default and the suggested mode for each. Retaining
the default requires no effort on the user's part.
Changing an option to run synchronously prevents the user from entering the
next business transaction until the selected function (for example, order posting)
is finished (as opposed to started). This single file processing assures fast user
feedback, but typically reduces overall throughput. Perceived user response time
also usually degrades. If desired, these choices may be set by user profile by
performing the following steps:
1. Call SYS105 - Table Definition Maintenance.
2. Select Table SCMCONFG to configure your profile.
3. Add/Change the Primary Code that matches your profile name.
4. Set User Defined Code 1 for Document Printing.
(0=Submit Job; 1=Run Synchronously)
5. Set User Defined Code 2 for Order Posting.
(0=Submit Job; 1= Run Synchronously)
6. Set User Defined Code 3 for Order Validation.
(0=Submit Job; 1= Run Synchronously)
11.6.2 eBPCS system values

System and file level settings within the software applications provide further
streamlining opportunities to improve performance and still offer the required
level of functionality. They include the values described in the following sections:
11.6.2.1 Order Entry

eBPCS order processing has tremendous new flexibility via order class
configurability. Classes may be created, for example, that skip traditional order
events and print many user-defined documents. As events are skipped and
documents are added, order entry takes on more functionality.

As functionality is added, the tendency is that performance will degrade. When
setting up order class configurations, the client must make an intelligent trade-off
between order entry response time and the number of functions to be performed
within a single event. For example, a post-ship order will move to invoicing
directly after order entry. To accomplish this, order entry must, in effect, perform
the picking and confirmation steps within the first event.
11.6.2.2 Promotions
Within system parameter settings (SYS800/Installed Programs), Promotions and
Deals (PRO) may be turned off if the client does not use it. All BPCS functions
related to the product will be skipped, which improves performance significantly.
Promotions functions also rely on a customer setting. Within Customer

Maintenance (ACR100), a promotion field may be set with the following values:
0 No promotion processing
1 Process line and total promotions only
2 Process bracket promotions only
3 Process line, total, and bracket promotions
Promotions may be set up as auto-assigned or manual. Manual requires that they

must be hand picked at order entry. Manual promotions take significantly longer
to process programmatically, as well as add user wait and key time to the overall
process.
Obviously, if the business functions require manual processing of promotions,

this is unavoidable. If it can be avoided, it will save considerable time.
11.6.2.3 Pricing
Within system parameter settings (SYS800), special (order entry parameters)
and list (promotion and deals parameters) pricing search hierarchies are defined.
In both cases, the search is performed in the sequence defined, and stops when
the first match is found.
Therefore, users should carefully set the search sequence so that the unused
options are last, and the used ones are in the correct priority order. This saves as
many as seven search levels and improves performance significantly.
11.6.2.4 Credit hold

Customer Maintenance (ACR100) also provides the ability to turn Credit
Checking on or off. If the client does not use this functionality in any way, turning
this value to Off (00) improves performance.
Additionally, the client may turn credit checking "On" only in certain events. For
example, a setting of 02 will perform a credit check only during pick release and
free order entry from this step.
11.6.2.5 Margin hold

Customer Maintenance (ACR100) also provides the ability to turn Margin
calculation on or off. If the client does not use this functionality in any way, turning
this value to Off (0) improves performance.

11.6.3 Workstation interface setup considerations
In eBPCS, the concept of a workstation refers to the input device used to provide
data to the program. The devices can range from 5250 "dumb" terminals to PCs
running emulation software or even a hand held unit doing 5250 emulation.
Regardless of the device, proper configuration is important to achieve the level of
functionality and performance required by business.
11.6.3.1 User preferences

Order Entry provides a number of application options that may be set by the user
in the form of User Preferences. These settings are available from the Order
Directory Window within Order Entry (Options/User Preference), and include:
• Display Promotions : The user may choose whether to see order promotions.
Performance is enhanced greatly, and Auto-assign promotions are still applied
if Display Promotions is set to No.
• Batch Pricing : Selecting this option (turning Batch Pricing on) defers pricing
to a subsequent Batch Pricing run. If pricing information is not required at
order entry time, this saves significant validation and posting time.
11.6.3.2 Filters
Order Entry provides a number of filters that can be set by the user to fine tune
the records selected. These settings are available from the Order Directory
Window within Order Entry (Options/ Filters), and include the following options.
Users should set these values to show minimal data sets required to perform their
functions effectively.
• Directory: This option applies to the order directory, and provides the
following choices:
– Customer Number Range
– Salesperson Number Range
– Customer PO (Single value and wildcard search available)
– Item Number (Single value and wildcard search available)
– Max. Records (Enter the maximum number of records to display)
– Show Directory at Startup (Initial build of directory is optional)
– Sort Order (Pick one of four sort orders for display)
• Customer : This option applies to customer prompting, and provides the
following choices:
– Customer Number Range
– Customer Name (Single value and wildcard search available)
– Phone Number (Single value and wildcard search available)
• Item: This option applies to item number lookup, and provides the following
choices:
– Item Number Range
– Description (Single value and wildcard search available)
– Extra Description (Single value and wildcard search available)
– Item Class Range
– All/Allowed (Show all items or those allowed by the item include or exclude
rules)

• Vendor : This applies to vendor lookup, and provides the following choices:
– Vendor Number Range
– Vendor Alpha Search (Single value and wildcard search available)
– Vendor Name (Single value and wildcard search available)
– Phone Number (Single value and wildcard search available)
– Vendor Type Range
System tuning varies drastically according to the size and type of your AS/400
system, the functions performed on the machine, departmental priorities, and
many other factors.
11.6.3.3 Batch order post

After a user accepts a new or updated order, a significant amount of I/O must be
done to completely load the order into all the production files on the server. As a
result, Order Entry spawns a job from the interactive session. This both frees up
the user for the next order and provides an added tuning flexibility. This feature
may be disabled by user profile. The spawned job is technically a batch job, but is
set up to retain many interactive characteristics. It uses a special job description
called ORDERPOST which resides in the BPCS object library. This job
description may be customized to fit your needs, but the default settings submit
the order post to QINTER with the same priority and time slice as regular
interactive jobs. We recommend that you create a separate subsystem with a
corresponding job queue to segregate these jobs from other jobs on the system.
This job queue should be referenced in the ORDERPOST job description. The
class used should be QSYSCLS20, which gives the batch job the attributes of an
interactive job.
A normal batch queue (for example, QBATCH) may be used. However, consider
the possibility that a typical batch configuration may result in extended queue
wait times. The order continues to be marked in use until the post function
completes. Therefore, the order may remain locked for an unreasonable amount
of time.
The maximum number of jobs that can be run from the job queue should be
restricted as much as possible. The more jobs that run, the more competition they
will have with each other. Start with three jobs, and increase to a reasonable
number that will run, but not adversely impact the system.
11.7 Application development options

Several options exist for clients who do application development that can improve
performance. Various compilation techniques and program object management
commands can be used in conjunction with sound application development
techniques. Exercise the options presented in this section with care. The invalid
use of these techniques can lead to reduced performance or data corruption.
11.7.1 BPCS compilation options

It should be noted that all BPCS programs should be generated using AS/SET or
with the BPCS compilation commands. These two methods of compilation use
parameters which are stored specific to the way in that each program should be
compiled.

In particular, for SQLRPG programs, we recommend that they are compiled with
the CLOSQLCSR parameter set to *ENDJOB. This leaves the SQL cursor open for
subsequent operations until the job has finished, rather than when the program
ends. Considerable performance gains can be seen when using this parameter.
All SQLRPG programs in eBPCS are compiled in this manner. The V6.1.00
version of AS/SET must be used when compiling the eBPCS source code. Failure
to use the correct AS/SET version can lead to data corruption and system failure.
11.7.2 Program optimization

The BPCS products on the AS/400 system have been generated into RPG/400
from the AS/SET tool. The Program Optimization attribute can impact
performance of the executing programs.
A program that has been optimized may run more efficiently than a program that
has not been optimized. When a program is compiled using the BPCS or AS/400
commands, you may specify whether the program is to be optimized. Optimizing
a program has its price. In some cases, the time needed to optimize a program
may be twice as long as the time it takes to compile the program. Program
optimization should be done as the last step in the program development.
The Change Program (CHGPGM) command allows you to change the Program
Optimization attribute of a program after it is compiled.
11.7.3 Remove Observability from production programs

Use the Removing Observability option from AS/SET generated programs, once
they are ready for production, to save a substantial amount of disk space. It will
not reduce the size of the executable code that is called into memory. Therefore,
the performance gain will not be significant.
11.7.4 Private authorizations

Objects are privately secured by individually granting users authority to the object
or by attaching an authorization list to the object. An authorization list is a logical
grouping of users and their associated authorities.
Removing individually assigned authority can be accomplished by using the

Revoke Object Authority (RVKOBJAUT) command as shown here:
RVKOBJAUT OBJ(LIB1/*ALL) OBJTYPE(*ALL) AUT(*ALL)
This command should be repeated for all libraries that have objects privately
secured.
Removing authorization list is more difficult. IBM does not allow you to universally
remove authorization list in the same manner or freedom as with individually
granted authority. Therefore, you must programmatically remove authorization
list.
The programmatic solution requires populating a file with all objects on your
system and subsequently determine if they are secured by an authorization list.
The first step in this process is to populate a file with all objects on the system
and drive from that file to determine object authority. The following example
shows a program that populates a file with all object authority:

0001.00 PGM
0002.00 DCLF FILE(ALLOBJ)
0003.00
0004.00 DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*ALL) +
0005.00 OUTPUT(*OUTFILE) OUTFILE(QGPL/ALLOBJ)
0006.00
0007.00 LOOP:
0008.00 RCVF RCDFMT(QLIDOBJD)
0009.00 MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDPGM))
0010.00
0011.00 DSPOBJAUT OBJ(&ODLBNM/&ODOBNM) OBJTYPE(&ODOBTP) +
0012.00 OUTPUT(*OUTFILE) OUTFILE(QGPL/ALLOBJAU)
0013.00
0014.00 GOTO CMDLBL(LOOP)
0015.00
0016.00 ENDPGM: ENDPGM
Another program is required to read all object authority file and find objects
secured by an authorization list. When an object that is secured by an
authorization list is encountered, this program removes the authorization list from
the object.
0001.00 PGM
0002.00
0003.00 DCLF FILE(ALLOBJAU)
0004.00
0005.00 LOOP:
0006.00 RCVF RCDFMT(QSYDSAUT)
0007.00 MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDPGM))
0008.00
0009.00 IF COND(&OAANAM *NE '*NONE') THEN(DO)
0010.00 RVKOBJAUT OBJ(&OANAME/&OALIB) OBJTYPE(&OATYPE) +
0011.00 AUTL(&OAANAM)
0012.00 ENDDO
0013.00
0014.00 GOTO CMDLBL(LOOP)
0015.00
0016.00 ENDPGM: ENDPGM
Remember to clear the ALLOBJ and ALLOBJAU files in QGPL after the task is
complete.
11.8 DB2/400 management

The AS/400 platform has undergone tremendous growth in performance and
flexibility over the last several years. DB2/400 has been at the top of products
that IBM has improved. The world-class performance of the DB2/400 database
engine requires increased management to keep the database access running at
optimal efficiency. The techniques discussed in this section outline some best
practices for managing DB2/400 and some analysis tools to aid in identifying
DB2/400 performance problems.
11.8.1 Access path maintenance

The BPCS products on the AS/400 system use logical files to access data within
the database. This is either specified directly in native database access, or by
dynamically using SQL. A logical file is an access path to the data stored in the

physical files. The access path is maintained when a record is added to, changed
or deleted from the associated physical file. The Access Path Maintenance
attribute of the logical file determines how the access path is maintained. The
following list describes the possible attributes available:
*IMMED The access path is maintained continuously. It is changed each time a
record is added to, changed or deleted from the associated physical
file.
*REBLD The access path is rebuilt when the logical file is opened. It is
continuously maintained until the file is closed.
*DLY The maintenance of the access path is delayed until the logical file is
opened. It is maintained only for the records that are added, changed,
or deleted since the file was last closed.
The default Access Path Maintenance attribute is *IMMED. BPCS logical files use
the default Access Path Maintenance attribute. If an access path is used less
frequently, you may want to change the Access Path Maintenance attribute to
either *REBLD or *DLY. This would allow maintenance of the access path to be at
the time when it is actually needed.
Take great care if changing logical files from the default. Since BPCS uses SQL
for accessing data, it may dynamically choose a logical file that is otherwise not
referenced directly in any code. This may cause an index build during execution
of an SQL statement.
11.8.2 Disk utilization

High disk utilization can have a negative impact on the overall performance of the
AS/400 system. Careful management and good user discipline are key factors in
keeping the AS/400 disk organized and free of unused data. The techniques
provided in the following sections are some of the ways to manage a disk when
using eBPCS on an AS/400 system. Refer to OS/400 Work Management,
SC41-5306, for more disk management techniques.
11.8.2.1 Deleted records

The process of deleting a record involves the marking of a record so that it is
unavailable for use. The AS/400 system allows for record deletion at the
database level. When a record is deleted at the database level, the operating
system marks the record and prevents future accesses to the record. For
purposes of discussion, we call this type of deletion a hard delete. A record may
also be marked as deleted by changing the state of a field within the record. This
field indicates whether the record is active or deleted. This type of deletion is not
recognized by the operating system because it is simply a change in the value of
a field. We call this type of deletion a soft delete. BPCS currently deletes records
using the hard and soft deletion process.
BPCS marks a record as soft deleted by changing the second position of the
Record ID field to the value Z. There are exceptions, such as the Receivable
Detail (RAR) file. In this file, the first position of the Record ID field is used to
indicate a soft delete. By using the soft deletion, a record may be accessed by an
application program or re-activated by changing the Record ID field to its original
state. An example of this process may be found within the master file
maintenance programs. Because the record is only marked, the operating system
does not prevent access to the record. A logical file may be used to include or

exclude these records based on the need for active records or all records within
the application. The inclusion or exclusion may also be handled within the
application program as well.
BPCS also uses the hard deletion process when the record does not need to be
re-activated. Because these records are not accessible, the record does not exist
from the applications programs point of view. An example of this may be found
within the MRP product. The records in the Material Requirements file (KMR) are
deleted using a hard delete.
The space used by a deleted record is unavailable. This applies to both types of
record deletion. To make this space available, the file containing the deleted
records needs to be re-organized. The process used to re-organize the file is
determined by the process used to delete the records within the file.
The reorganization programs are also located for operational convenience on the
System menu. Many sites have set up automatic scheduled executions of these
programs at period end.
11.8.2.2 Reorganizing files with hard deleted records

Files containing hard deleted records may be reorganized using the AS/400
Reorganize Physical File Member (RGZPFM) command. This removes the hard
deleted records from the file, and return the space required to store these
records. BPCS reorganizes some of the files which contain hard deleted records
using the AS/400 command. These are typically done during a month-end or
year-end close program. Some of the files within BPCS that contain hard deleted
records are not be reorganized.
11.8.2.3 Reorganizing files with soft deleted records

Re-organizing soft deleted records is a more difficult process than for hard
deleted records. A record may be soft deleted to prevent further use, but is still
required to remain in the file to support other elements of the database. An
example of this may be the Item Master (IIM) file. You may want to delete the item
record, because it has been discontinued but still retain the record to support the
information in the Item Transaction (ITH) file. BPCS also contains the ability to
indicate the number of days to keep closed or deleted records on specified files.
Removing soft-deleted records (whether since it is based on the days retention

parameter) requires additional programming as there are logical relationships
between files that must be maintained.
11.9 DB2/400 SQL tuning

All SQL DB2/400-based data access on the AS/400 system is governed by the
AS/400 query optimizer. The optimizer evaluates the data, system resources, and
a host of other factors to develop the best plan for processing a given SQL query.
The optimizer then executes the access plan for the given query and returns the
required data.
If the access plan calls for a temporary index build to improve performance, the
optimizer builds the index as part of the query execution. The building of
temporary indexes can be a cause of significant performance degradation, and as
such, is a prime area to review for performance improvements.

This section describes the tools and methodologies involved in analyzing and
improving SQL performance on the AS/400 system. Use care when attempting to
use these tools. Incorrect application of the tools can lead to performance
degradation and reduced end-user satisfaction.
11.9.1 AS/400 database query optimization tools

The DB2/400 database has a sophisticated methodology used in optimization.
With this in mind, certain tools are essential when dealing with analyzing the
optimizer. The tools are needed to know what the queries and SQL you write are
doing, or what the optimizer is doing with them. You need the following tools to
analyze your queries and the optimizer:
• Database Monitor statistics
• Print SQL information
• Query optimizer debug messages
• Change query attributes
11.9.1.1 Database Monitor statistics

Database Monitor statistics log all information and statistics about queries being
run on a particular job or at a system level. The Start Database Monitor
(STRDBMON) command is used to start the monitor and the End Database
Monitor (ENDDBMON) command is used to end it. Database Monitor can also be
started from the Start Performance Monitor (STRPFRMON) command by using
the DBMON parameter.
The monitor can be set for a specific job or all the jobs on the system, with
statistics placed in the output database file specified on the command. Each job
in the system can be monitored concurrently by two monitors. One monitor is for
the specific job, and the other monitor is for all jobs on the system. When
monitored by two monitors and each monitor is logging to a different output file,
monitor records are written to both files. Records in the output database files are
uniquely identified by their record identification number. Some of the database
information that is collected includes:
• System and job name
• SQL statement and sub-select number
• Start and end timestamp
• Estimated processing time
• Total rows in the file queried
• Number of rows selected
• Estimated number of rows selected
• Estimated number of joined rows
• Key fields for advised index
• Total optimization time
• Join type and method
• ODP (Open Data Path) implementation
Running the Database Monitor allows you to answer several key questions
relative to your database. Such questions include:
• How many queries perform dynamic replans?
• How many temporary indexes were created over a particular file?
• Which queries are the most time consuming?
• Which user is running those queries?
• Which queries were implemented using reusable ODPs?

• Does a particular PTF apply to the users?
• Has the implementation of a particular query changed with the application of a
PTF or a new release?
The questions are actually answered by querying the information collected from
running the Database Monitor.
The Database Monitor data is collected in 14 different records (13 records if

*SUMMARY data was collected). Section 1.4.7, "Monitoring Database Query
Performance" in DB2 for AS/400 Database Programming, SC41-5701, gives you
a detailed description of each record type. Before starting to analyze these
records, you may have to create individual logical files for each record type.
Source DDS for each database monitor logical file is given in Section 1.4.7.7 of
DB2 for AS/400 Database Programming , SC41-5701. Create these source files in
a library of your choice (for example, DBMONLF). Then, build logical files for the
collected database monitor data by using these source files. A number of
database monitor examples are provided in Section 1.4.7.5 of the DB2 for AS/400
Database Programming , SC41-5701. You may use these examples or build your
own queries or reports.
Starting Database Monitor

To collect the Database Monitor data, enter STRDBMON and press F4. Specify the
library, file, and member name for the file to collect DBMON data. Also, specify
Type of Records as *SUMMARY, and press Enter.
Start Database Monitor (STRDBMON)
File to receive output . . . . . > DBMON Name

Library . . . . . . . . . . . > DBMONCOLL Name, *LIBL, *CURLIB
Output member options:
Member to receive output . . . > MON10AM Name, *FIRST
Replace or add records . . . . *REPLACE *REPLACE, *ADD
Job name . . . . . . . . . . . . > *ALL Name, *, *ALL
User . . . . . . . . . . . . . Name
Number . . . . . . . . . . . . 000000-999999
Type of records . . . . . . . . *SUMMARY *SUMMARY, *DETAIL
Force record write . . . . . . . *CALC 0-32767, *CALC
Comment . . . . . . . . . . . . Monday morning collection
Bottom
F24=More keys
Figure 113. Start Database Monitor display
The STRDBMON command starts the collection of database performance

statistics for a specific job or all jobs on the system. For monitoring jobs not using
non-SQL queries, use *SUMMARY for Type of records. For the first few iterations, we
recommend data collection for all the jobs. After the database is tuned to a
reasonable level of performance, you may focus on specific SQL queries by
collecting data for specific jobs. The statistics are placed in an output database
file and member specified on the command. If the output file or member does not
exist, one is created based upon the file format definition of model file
QSYS/QAQQDBMN.

You can specify a replace or append option that allows you to clear the member
information before writing records or to append new information to the end of the
existing file.
Ending Database Monitor

To end the Database Monitor, use the ENDDBMON *ALL command if you started it
with *ALL.
Useful tips for Database Monitor analysis

The Database Monitor collects a lot of data in too many records and fields. For
simplicity, this section provides information on the most often used record types
and fields and a set of key database analysis example queries. Most of these
example queries do not even require the creation of logical files.
Most commonly used record types

The most commonly used Database Monitor records types are:
• 1000: SQL summary record
• 3000: Arrival sequence
• 3001: Using existing index
• 3002: Index created
• 3003: Query sort
• 3006: Access path rebuilt
• 3007: Index optimization data
• 3010: Host variable and ODP implementation
The fields QQJOB (Job name), QQUSER (Job user name), QQJNUM (Job
number), and QQTIME (Time that the record was created) are common to all
these record types. Other most commonly used fields for each record type are
shown in the following text.
Commonly used fields and performance analysis examples

This section presents the most commonly used fields for each record type:
• 1000 Record Type : SQL statement summary.
This record type contains basic SQL query information for each SQL query
operation (open, update, close, commit and so on). The commonly used fields
are:
– QQ1000: Prepared text for the SQL statement
– QQC21: Type of SQL operation (OP, FE, CL, UP, IN, DL ...)
– QQI2: Number of rows fetched (only on FE records)
– QQI3: Number of rows updated, inserted, deleted
– QQI5: Refresh counter
– QQI4: Elapsed time for this operation in milliseconds
– QQSTIM: Timestamp for the start of SQL operations
– QQETIM: Timestamp for the end of SQL operation
If you need to identify jobs that need further analysis, you can run the
following query on this record type:
SELECT SUM(QQI4), COUNT(*), QQJOB, QQUSER, QQJNUM
FROM QAPMDBMON
WHERE QQRID = 1000
GROUP BY QQJOB, QQUSER, QQJNUM ORDER BY 1 DESC
To find which SQL operations account for the most run time for selected jobs,
you may run this query:

SELECT SUM(QQI4), COUNT(*), QQC21
FROM QAPMDBMON
WHERE QQRID = 1000 AND QQJNUM = ’job_number’
GROUP BY QQC21 ORDER BY 1 DESC
• 3000 Record type: Arrival sequence (table scan)
This record type points out queries where an entire table is scanned without
using an index. This is generally OK in cases where a large portion of the file
is selected or if file contains a small number of records.
– QQPTFN : File name
– QQPTLN : File library name
– QQTOTR: Number of rows in table (use to determine if table scan is for a
significant number of rows)
– QQRCOD: Reason code (why arrival sequence was chosen)
– QQIDXA: Index advised (Y or N) (If "N", QQI2 and QQIDXD do not contain
data. Index is not advised if an index for these keys already exists.)
– QQI2: Number of primary keys in the QQIDXD field
– QQIDXD: Suggested keys for the index (selection only)
For example, by running the following query, you can list the advised indexes
for all those SQL queries that performed a table scan (selection only):
SELECT QQTLN, QQTFN, QQIDXD
FROM QAPMDBMON WHERE QQRID = 3000
AND QQIDXA = 'Y'
To determine which queries involve arrival sequence, you can use the
following code:
SELECT SUM(QQI4), COUNT(*), QQUCNT, QQ1000
FROM QAPMDBMON WHERE QQJNUM = ’job_number’
AND QQRID = 1000AND QQUCNT IN
(SELECT DISTINCT QQUCNTFROM QAPMDBMON
WHERE QQRID = 3000 AND QQJNUM = ’job_number’)
GROUP BY QQUCNT, QQ1000 ORDER BY 1 DESC
• 3001 Record type: Using existing index
This record type shows the file and index that are used to access the file and
why it was chosen. If the index was chosen for join, additional information is
given to help determine how the file “fits” in the join. The order of 3001 records
indicates the join order chosen by optimizer:
– QQPTFN : File name (*N indicates a temporary results table)
– QQPTLN : File library name (blank if the file name is *N)
– QQIFNM : Name of the selected index (may be *TEMP)
– QQILNM : Index library name (blank if the index name is *TEMP)
– QQRCOD: Reason the index was selected
– QQC21: Join method (NL, MF, HJ)
– QQC22: Join type (IN, PO, EX)
– QQC23: Join operator (EQ, LT, GT, CP and so on)
– QQTOTR: Number of rows in the table
– QQAJN: Estimated number of joined rows from this table
– QQIDXA: Index advised (Y or N)
– QQI2: Number of suggested primary keys in the QQIDXD field
– QQIDXD: Recommended primary and secondary keys for the index on this
table

• 3002 Record type: Index create
This record type contains data on the temporary indexes created for running a
query. The reason for temporary index creation is placed in record type 3007:
– QQPTFN : Table name for which the index is built, Name of *N indicates
temporary results table (3004 record) - index build unavoidable
– QQPTLN : Table library name (blank if file name is *N)
– QQIFNM : Name of index. (Will be blank if index built over entire table; will
contain the index name if the index from an index build occurred.
– QQILNM : Index library name (blank if it is built on an entire table)
– QQRCOD: Reason the index build was done
– QQTOTR: Number of rows in table
– QQRIDX : Number of entries in a temporary index
– QQ1000: Contains join, order by, or group by keys used in an index build
– QQSTIM: Timestamp for the start of index build
– QQETIM: Timestamp for the end of index build
Note: QQETIM minus QQSTIM shows the elapsed time for the index build.
– QQI2: Number of primary selection keys in QQIDXD
– QQIDXD: Suggested primary and secondary keys for index
For example, you may use the following query to determine which indexes are
built most often:
SELECT QQUCNT, QQETIM-QQSTIM, QQPTFN, QQTOTR, QQRIDX, QQRCOD,
QQIDXA, SUBSTR(QQ1000, 1, 100), SUBSTR(QQIDXD, 1, 200)
FROM QAPMDBMON
WHERE QQRID = 3002 AND QQIDXA = 'Y'
ORDER BY 2 DESC
• 3003 Record type: Query sort
– QQSTIM: Timestamp for the start of refill and sort
– QQETIM: Timestamp for the end of refill and sort
– QQRCOD: Reason for choosing a query sort
– QQRSS : Number of rows in a sort space
• 3006 Record type: Access plan rebuild
QQRCOD field lists the reason the replan is occurring
• 3007 Record : Index optimization and selection
This record type shows all indexes that are evaluated for a given file, including
which one (if any) was selected for use in this query and which were selected
not (and why).
– QQPTFN : File name
– QQPTLN : File library name
– QQC11: Optimizer timed out (Y or N)
– QQ1000: Contains the library qualified index names, each with a reason
code
• 3010 Record type: Host variable and ODP implementation
This record type shows the substitution values for the host variables or
parameter markers in the query text:
– QQ1000: Host variable or parameter marker values
– QQI5: Refresh count (use to link to specific query instance)

Note on Index Advisor
Query optimizer analyzes the record selection in the query and determines,
based on the default estimate, if the creation of a permanent index can improve
performance. If a permanent index can be beneficial, it returns the key fields
necessary to create the suggested index. The index advisor information can be
found in debug message CPI432F or in the Database Monitor records
QQQ3000, QQQ3001, and QQQ3002. The main point here is to know that the
intention of creating the suggested index is to improve the performance of the
query.
11.9.1.2 Print SQL information

Print SQL information allows you to print the SQL information contained within a
program, SQL package, or service program. A spooled file is created that
contains SQL statements, the type of access plan used by each statement, and
such commands as CRTSQLxxx used to invoke the SQL precompiler. The output
information is similar to the debug messages.
11.9.1.3 Debug messages

Debug messages issue informational messages to the job log about the
implementation of a query. The messages describe query implementation
methods such as indexes, file join orders, temporary results, access plans, and
Open Data Paths (ODPs).
The messages explain what happened during the query optimization. Questions,
such as why an index was used or not used, or why a temporary result was
required, are explained. It also shows the join order of the files and the index
advised by the optimizer.
One of the most significant steps that can be used when solving any
programming problems is to isolate problem code into smaller units. For example,
if you identified a performance problem with an SQL query (such as through
using the STRDBMON command), you may copy the SQL statement (and the
required host variable definitions) to the test environment and debug the isolated
SQL query.
Note
It is often difficult to determine which server job corresponds to a particular
client. You can write an exit program that can be used with QIBM_QZDA_INIT
to start and stop debug for all the new jobs. Also, remember that if you turned
the joblog to *NOLIST, you will not see any debug messages.
Run the selected SQL statement in the debug mode by using the following
command:
STRDBG UPDPROD(*YES)
By running this command, most of the SQL optimizer messages are displayed in
the job log. The query optimizer provides you with information messages on the
current query processing. Display the job log by using the Display Job Log

(DSPJOBLOG) command to see the optimizer messages. Figure 114 shows the
resulting display.
Display All Messages
Job . . : QPADEV0131 User . . : owuser Number . . . : 610836
Access path built for file QCUSTCDT.

ODP created.
Blocking used for query.
ODP deleted.
ODP created.
ODP deleted.
ODP created.
Connection to relational database RCHASBDS ended.
SQL cursors closed.
Press Enter to continue.
F3=Exit F5=Refresh F12=Cancel F17=Top F18=Bottom
Figure 114. First level text of job log messages
For more information on what the optimizer did, for example, why the access path
was built, analyze the messages using the Help key for the second level text. If
you positioned on the first message as shown in Figure 114, the display shown in
Figure 115 may appear.
Additional Message Information
Message ID . . . . . . : CPI4321 Severity . . . . . . . : 00

Message type . . . . . : Information
Date sent . . . . . . : 02/23/99 Time sent . . . . . . : 09:45:10
Message . . . . : Access path built for file QCUSTCDT.

Cause . . . . . : A temporary access path was built to access records from
member CUSTCDT of file QCUSTCDT in library QIWS for reason code 1. This
process took 0 minutes and .0 seconds. The access path built contains 13
entries. The access path was built using 0 parallel tasks. A zero for the
number of parallel tasks indicates that parallelism was not used. The reason
codes and their meanings follow:
1 - Perform specified ordering/grouping criteria.
2 - Perform specified join criteria.
3 - Perform specified record selection to minimize I/O wait time.
The access path was built using the following key fields. The key fields
and their corresponding sequence (ASCEND or DESCEND) will be shown:
More...
F3=Exit F6=Print F9=Display message details F12=Cancel

F21=Select assistance level
Figure 115. Second level text of job log messages

You can evaluate the structure and performance of the given SQL statement in
your programs by using the informational messages entered in the job log. For a
complete list of optimizer messages and their interpretation, refer to Section 1.4.4
in DB2 for AS/400 Database Programming , SC41-5701.
Predictive Query Governor tip
Before running the SQL statement, you may set the time limit to ZERO for the
parameter QRYTIMLMT in the CHGQRA command. The query optimizer
messages are written to the job log prior to the actual execution of the query.
This way, you can get all the optimizer messages without actually running the
query.
11.9.1.4 Query attributes

A user can change attributes of a query during the execution of a job. Some of
the attributes that can be modified are the query processing time limit, parallel
processing degree, and the number of tasks. The types of attributes that can be
modified are:
• Predictive query governor
• Query parallelism
• Asynchronous job
• Apply CHGQRYA to remote
Important points to remember are that the query time limit is checked against the
estimated elapsed query time before initiating a query. The inquiry message
CPA4259 is displayed and shows the predicted runtime and what operations the
query will perform. A time limit of zero is used to see the optimization messages
without actually running the queries. Debug messages are written to the job log if
the query is canceled.
11.9.1.5 Comparison of optimization analysis methods

Table 30 gives a comparison of the features and optimization tools discussed in
the previous sections.
Table 30. Comparison of optimization analysis methods
PRTSQLINF STRDBG/CHGQRYA STRDBMON
Available without running Only available when the Only available when the
the query (after the access query is run. query is run.
plan is created).
Displayed for all queries in Displayed only for those Displayed only for those
the SQL program, queries that are executed. queries that are executed.
regardless of whether it is
executed.
Information on host Limited information on the All information on host

variable implementation. implementation of host variables, implementation,
variables. and values.
Available only to SQL Available to all query users Available to all query users
users with programs, (OPNQRYF, QUERY/400, (OPNQRYF, QUERY/400,
packages, or service SQL). SQL).
programs.

PRTSQLINF STRDBG/CHGQRYA STRDBMON
Messages printed to a Messages displayed in the Performance records written

spooled file. job log. to a database file.
Easier to tie messages to a Difficult to tie messages to a Uniquely identifies every

query with subqueries or query with subqueries or query.
unions. unions.
11.9.2 Additional DB2/400 optimization techniques

Several features are available from IBM to further tune the SQL data access. The
SMP feature described in the following section is a chargeable feature. The other
options are contained within the OS/400 code.
11.9.2.1 Symmetric Multiprocessing (SMP) feature

The SMP feature provides additional query optimization algorithms for retrieving
data. In addition, the DB2/400 SMP feature provides application transparent
support for parallel query operations on the AS/400 system. The database
manager can automatically activate parallel query processing to engage one or
more system processors (if it is a multi-processor system) to work simultaneously
on a single query. DB2/400 SMP can provide significant performance
improvement when sufficient CPU and memory resources are available on the
AS/400 system. The degree of parallel processing can be set system wide by
setting the system value QQRYDEGREE to one of the following options:
• *MAX : The number of tasks to use most or all CPU resources
• *OPTIMIZE: The number of tasks to use a good share of CPU resources
• *NBRTASKS : The number of tasks not to exceed a specified number
• *IO : I/O parallelism only
• *NONE : No parallelism
The SMP feature can be used only if the DB2 Symmetric Multiprocessing feature
is installed on your AS/400 system. This feature provides the following query
optimization algorithms:
• Parallel table scan
Provides parallel operations for queries requiring a sequential scan of the
entire table. Multiple tasks are used to scan the same table concurrently. Each
task performs selection and column processing on a table partition and returns
selected records to the requester.
• Index only access
Provides performance improvement by extracting a query answer from an
index rather than performing random I/Os against a physical table.
• Parallel key selection
Provides parallel index operations for key selection. Multiple tasks are used to
scan the same index concurrently.
• Parallel key positioning
Multiple tasks are used to perform the key positioning on a partitioned subset
of the key ranges. Only those index entries that are within a selected range
are processed.

• Hashing algorithms
Provides an optimization alternative for group by and some join queries. This
method avoids having to use an index. Therefore, it avoids having to perform
random I/Os to retrieve the results.
• Parallel index build
This can speed up the process of building a temporary index, when the query
optimizer cannot locate an appropriate index. It determines whether to build a
temporary index to execute a particular query. It also speeds up the process of
building permanent indexes, particularly when they are built over large
database files.
• Parallel index maintenance
This is effective only when blocked inserts are performed on the base
database table and at least eight indexes over the table.
• Parallel data loader
This is a new function in V4R3 (also available via PTF on V4R2 and V4R1)
that makes loading AS/400 database tables from external data much simpler
and faster. The data loader can import fixed format, delimited, and byte stream
files. The following PTFs are required for V4R1 and V4R2 releases of OS/400:
– V4R1M0: SF47138 and SF47177 for OS/400
– V4R2M0: SF46911 and SF46976 for OS/400
If AS/400 resources are available (particularly the memory and CPU are not a
constraint), changing the system value QQRYDEGREE to *OPTIMIZE may
provide a better performance for the eBPCS applications. Optionally, you may set
the "multiprocessing degree" for specific jobs by using the CHGQRYA DEGREE
(*OPTIMIZE/*MAX ...) command. For more information on the SMP feature, see
Section 1.4.6 "Controlling Parallel Processing" in DB2 for AS/400 Database
Programming , SC41-5701.
11.9.2.2 Parallel pre-fetch

Parallel pre-fetching of data can be invoked through the CHGQRYA command or
through the use of the QQRYDEGREE *IO system value. This can work even
without the DB2/400 SMP feature installed on the AS/400 system. Pre-fetching
involves the reading of data from multiple disk arms in parallel and reduces any
performance impact resulting from disk arm contention.
However, there is a memory overhead of approximately 1 MB per actuator.

Selecting expert cache for the memory pool is a prerequisite. Also, the increased
availability of data compresses the processing into a shortened elapsed time and
increases the percentage of CPU utilization during execution.
Parallel pre-fetch requires Expert Cache to be turned on.
11.9.2.3 Access path size

AS/400 indexes are defined as either a maximum 4 GB index or a maximum 1 TB
index. The 1 TB index is relatively new and is currently the default used when
new indexes are created. In general, the 4 GB index is a little faster for smaller
non-dynamic tables, and the 1 TB index is better for large dynamic tables.
Another consideration is that the entire table is seized for the insertion of an index
into a 4 GB index. Only the appropriate page is seized while inserting an entry

into a 1 TB index. The new 1 TB indexes have another advantage in that they can
be built in parallel if the system is a multi-processor system. For best
performance, use the 1 TB index. Beginning with V4R1, the default is to use 1 TB
indexes. This does not only optimize the index itself. However, by creating them
in reverse alphabetic sequence, it also causes the primary key to be the first
index considered by the query optimizer. This is because the query optimizer
uses the latest index created as its first index to consider. To see if an index is a
4 GB or 1 TB index, enter the command:
DSPPFD lib/logical file name
Or, enter this command:

DSPPFD lib/*all to list all the files in the library
The following entry shows a 4 GB index:

Access path size .................: ACCPTHSIZ *MAX4GB
This can be changed to MAX1TB by entering the command:

CHGLF logical_file_name ACCPTHSIZ *MAX1TB
Note
When an index type is changed, it is rebuilt. This can result in a long running
process.
11.9.2.4 Access path sharing

If a new index is created that can use an existing access path, it is implicitly
shared automatically by the AS/400 database.

Chapter 12. Logical Partitioning
SSA’s Portfolio Strategy has extended the requirements of the AS/400 system by
adding a series of products to the already comprehensive product suite of
eBPCS. With added Business Intelligence, e-commerce, and links into the Lotus
Domino world, the role of the AS/400 system has become much more complex.
The potential for conflict of interests in processing time has increased as the
information rich database of eBPCS has become more accessible.
SSA, in conjunction with the IBM development laboratories in Rochester,

Minnesota, has performed a series of tests to establish the effectiveness and the
opportunities of Logical Partitioning (LPAR) and eBPCS.
The tests included loading multiple versions of eBPCS in a combination of

Client/Server, with single-byte, and Mixed-Mode with double-byte language
versions into separate partitions. Lotus Domino, running native on the AS/400
system, was used to query and update databases in multiple partitions.
Many of the technical enhancements were also tested. The ability to IPL
individual partitions while others were still active, switching devices between
partitions, different time zones, and the OptiConnect high speed link were all
tested.
SSA sees this addition to the AS/400 functionality as a key factor in a time when
many companies are looking to consolidate their server strategy, and move
toward a shared service center concept. The capability to have multiple partitions
running in the same AS/400 system also falls neatly in line with SSA's Portfolio
Strategy. Business Intelligence, data warehousing, and e-commerce can all affect
the way in which the AS/400 system performs. By separating them out, you can
gain the benefit of the products without the performance overhead affecting your
on-line transaction users. Other benefits of using this new technology, include:
• Centralized computer operations
• Cost of ownership of the AS/400 system
• 24 x 7 operating capabilities
• Data consolidation
• Easy implementation of Business Intelligence
For further information, see the white paper "Configuring your AS/400 and
eBPCS in an LPAR Environment" which is available on the Web at:
http://www.ssaportfolio.com/partners/ibm/as400e.html

Chapter 13. SSA product global support structure
SSA's professionals are continuously improving to better meet the needs of
clients and other users. This chapter provides a "snapshot" of SSA’s operational
structure as it exists at the time of publishing this redbook. New initiatives and
innovations regularly put into place after the publication of this chapter may not
be reflected totally in the content. Check the SSA OGS online Web site for the
most up to date information.
13.1 HelpLine's role in product support

The SSA International HelpLine is a key link in product support. However, it is not
the only venue for support of SSA software. Additional requirements for support
are fulfilled by SSA Consulting and Sales Managers, SSA Education, and SSA
Professional Services organizations (Figure 116). This chapter focuses on the
HelpLine organization, HelpLine tools available for your use, and strategies to
resolve problems and effectively manage program fixes and changes in your
BPCS environment. Specialized services contracted individually from SSA
Professional Services, for example, are not covered in detail. These details vary
with the engagement contract and your specific requirements.
?
Timely response to technical Not educators. Assist OGS
and application issues. subscribers resolve issues.
Certified Consultants International - Consistent global

service for subscribing clients.
Figure 116. HelpLine’s role
13.2 SSA International HelpLine organization overview

The SSA International HelpLine supports clients via use of an on-line Web site
(OGS (OnGoing Support)), e-mail, facsimile, and telephone support.
Each region is staffed with product or technical consultants within their functional
area reporting to their appropriate support manager. All support managers report
to their regional HelpLine Director. A global HelpLine director sets overall
HelpLine policies and practices.

13.3 Purpose of the SSA International HelpLine
HelpLine provides OGS subscribers with timely responses to specific technical
and application issues concerning the installation, implementation, and
day-to-day use of SSA products. In addition, HelpLine consultants are
responsible for documenting information regarding various problems and their
resolutions. As such, incidents identifying divergence of functionality from
documentation or design are categorized according to the level of severity by the
HelpLine professional.
13.4 HelpLine responsibilities and activities

The SSA International HelpLine is responsible for the delivery of these services:
• Provides answers to questions relating to your installation, implementation,
and daily use of software purchased from SSA
• Maintains a record of each call, referred to as an "incident", showing its
progress from initial call to final resolution
• May enter BPCS Modification Requests (BMRs) when software is operating
outside specified parameters
• May request documentation updates in help text and product run or
installation documentation
• May issue product Alerts or Bulletins on OGS OnLine to notify you of specific
product issues which are considered to be of high impact to the SSA
installation base
HelpLine professionals reserve the right to determine whether a problem can be

properly handled by phone, and make recommendations as to how it can best be
handled. This may include, but is not limited to, the initiation of an Electronic
Customer Support (ECS) session or initiation of contact with another HelpLine
such as the IBM HelpLine or a third-party product HelpLine.
In addition, if it is determined that a problem falls outside the scope of the

responsibilities of the SSA HelpLine, you may be directed on a billed basis to
acquire further user education, or the involvement of SSA Professional Services
via contact with the client's SSA Consulting Manager or SSA Engagement
Manager. The HelpLine advises the client if it determines that the issue requires
other personnel to become involved.
The HelpLine service is provided under the terms of the Software License
Agreement between SSA and the client. SSA reserves the right to make changes
to this agreement. These changes may include, but are not limited to, changes in
the hours of HelpLine availability, charges for this service, and the products that
are supported.
13.5 Helpline incident reporting policies and procedures

The Helpline Scope of Operations and Escalation procedures are available on
OGS OnLine (Figure 117 on page 225). This information provides guidelines on
how to best utilize the HelpLine when requesting assistance with BPCS products.

Adherence to these processes and guidelines greatly improves the quality of the
support received from the HelpLine.
HelpLine Policies
and Procedures
on OGS OnLine
Figure 117. HelpLine policies and procedure on OGS OnLine
13.6 Regional HelpLine office locations and languages

The SSA International HelpLine maintains three regional offices around the
world. The Americas office is located at SSA's headquarters in Chicago, Illinois
(USA). The Asia Pacific Japan office is in Sydney, Australia. The Europe Middle
East Africa (EMEA) office is in Frimley, UK.
English is the common language for each Helpline. Additional languages

supported by each HelpLine office are listed in the HelpLine Scope of Operations
document on OGS Online.
13.7 HelpLine availability

The SSA International HelpLine offers subscribing clients telephone support 24
hours a day, five days a week through the availability of regional HelpLine offices
in time zones throughout the world. The following sections describe the support
options available to subscribers under this schedule.
13.7.1 Weekday support policy: Monday through Friday

During regular business hours, Monday through Friday, the Regional HelpLine
offices of the Americas (Chicago, IL), EMEA (UK), and Asia Pacific Japan
(Australia) provide services to subscribing clients in their regions.
When placing a call for emergency support that is needed after regular regional
business hours on Mondays through Thursdays, callers are directed to the
appropriate available SSA HelpLine. A telephone recorded message lists the
name and number of the regional HelpLine office to call.
SSA product global support structure 225

For all HelpLines, if calling after regular business hours (Monday through Friday)
or on weekends, if no other Regional HelpLine is available (for example, because
of a holiday), a recorded phone message directs you to either:
• Leave a name, company, and telephone number where the consultant can
return the call at the start of the next business day.
• Use the emergency numbers provided for support.
You can log a new call or refer to an existing call at a different Regional SSA
HelpLine office during "off hours" for your own region. SSA International
HelpLines share the same call tracking database. Therefore, an existing call can
be viewed, edited, or looked up by any other SSA HelpLine consultant around the
world. Refer to your original call log number so that the prior history is available to
the new consultant.
13.7.2 Weekend support policy: Friday through Sunday and holidays

Weekend support is only available for issuing temporary disaster recovery keys.
Subscribing clients are instructed to dial the emergency pager telephone number.
An SSA technical consultant then contacts the client within one hour.
13.7.2.1 Emergency key support on OGS Online

Emergency pager numbers for disaster recovery temporary key requests are
listed on OGS Online in the HelpLine Scope of Operations document. The are
also available by calling the regular HelpLine support number for your area.
In addition, a new service is available on OGS that allows you to request and
receive a temporary software key online. This service is available for a limit of two
keys. The Web address for emergency online key requests is http://ogs.ssax.com
The main page is shown in Figure 118 on page 227. Select Product
Support->BPCS Key Requests->BPCS Key Request Form. The home page for
key requests also lists the people in each regional finance and administration
office whom you can contact regarding obtaining permanent software keys.

Figure 118. OGS main page
13.7.2.2 Professional services non-key support on weekends

For non-key issues, such as installations and database conversions or "go-live"
support, weekend support may be available on a billed basis through the SSA
Professional Services organization. You must arrange this service in advance
through your SSA Professional Services or Consulting Manager.
13.8 SSA International HelpLine product responsibilities

This listing is not all-inclusive. Regional offices may support other locally
developed SSA products which are specific to one country or region, and which
are not listed here.
Initially direct your query to the area which seems to best fit your question or
problem. If your question is best answered by a different team or a combination of
two teams, the HelpLine consultant will involve the appropriate resources to
answer your question.
13.8.1 Technical teams

The duties of the technical teams are to assist customers in operations that affect
a specific platform upon which BPCS is run. They may also help with aspects of
the BPCS suite of products that affect all applications in BPCS, such as
client/server communications programs and BPCS user security programs. In
addition, the technical teams provide platform-specific knowledge for the product
teams when discussing the particulars of identifying the cause of a BPCS error
since it may manifest on the various platforms upon which BPCS runs.

13.8.1.1 AS/400 technical team
The AS/400 technical team offers support in these areas:
• OS/400 release-specific questions
• SQL questions as they relate to BPCS
• Product installation
• Conversions to new releases
• Source or Action Diagram questions
• ADK AS/SET Development Kernel
• Semantic Messaging Gateways
• ODW Object Development Workbench
• Connections to the BPCS Client/Server
• BPCS security
• BPCS System Parameters Maintenance
• Server run-time software
13.8.1.2 PC technical team

The PC technical team (or the technical team if no separate PC Team exists
locally) offers support in these areas:
• User Vision
• Financial Report Writer Download
• Errors on PC Client screens (non-application related messages)
• BPCS Client run-time software
• Installation of BPCS Client software
• Connections to BPCS Client/Server
• PC setup or configuration issues as they relate to BPCS software
• PC operating system issues as they relate to BPCS software
• ODW Designer questions
13.8.1.3 Open systems technical team

This team handles UNIX and Windows NT server platform-related issues similar
to AS/400 Technical Team responsibilities.
13.8.1.4 EDI team

The EDI team addresses issues regarding:
• Electronic Data Interchange
• Electronic Commerce Manager
13.8.2 Product teams

Product teams are responsible for understanding the setup and proper execution
of the various end-user applications that make up BPCS. For example, people
with backgrounds in accounting, manufacturing management, and other industry
specialties obtain intensive training in their product areas and staff these
HelpLines. They help BPCS users determine if a product is working as expected,
and understand the many ways to set up BPCS applications, and the business
reasons to configure BPCS application in a particular way.
13.8.2.1 Financial team

The Financial team supports these areas:
• Accounts Payable
• Accounts Receivable
• Configurable Ledger

• Configurable Enterprise Accounting
• Financial Reporting
• Costing
• Multi-Currency
• Fixed Assets
• Advanced Remittance Processing
• Credit and Deduction Management
13.8.2.2 Manufacturing team

This team supports:
• Inventory
• Shop Floor Control
• Just In Time Manufacturing
• Material Requirements Planning
• Master Production Scheduling
• Quality Laboratory Management
• Configuration Management
• Capacity Planning
• Material Data Management
13.8.2.3 Minneapolis product team

This team handles plant maintenance support.
13.8.2.4 Supply chain team

The Supply chain team is responsible for:
• Order Entry
• Purchasing
• Outbound Logistics Management
• Inbound Logistics Management
• Billing (Invoicing)
• Promotions and Deals
• Warehouse Management
• Release Management
• Sales Analysis
• Forecasting
13.9 Incident escalation procedures

At any time, if you are not satisfied with the quality of support received, have
issues that require escalation, or find that a resolution is not forthcoming, you
should notify a member of the HelpLine Management team. For best results, SSA
recommends that you contact the support manager who is directly responsible for
the issues in question. Alternatively, you may contact your SSA Engagement
Manager or Consulting Manager if you want to escalate the priority of your
problem beyond the scope of the HelpLine management team.
13.10 When not to use the SSA International HelpLine

The Helpline Scope of Operations is defined in detail in a document on OGS
Online. This document lists fully the information on HelpLine, including your
responsibilities when working with a representative to resolve a software issue.

13.10.1 Examples of questions outside the scope of HelpLine
Questions regarding the following topic areas should be directed to more
appropriate areas of SSA such as the SSA Sales and Marketing Group, SSA
Finance and Administration, or your SSA Consulting Manager. This list is not all
inclusive, but provides examples of some of the topics that fall outside the scope
of HelpLine operations:
• Cost of hardware (contact your sales representative)
• Cost of software (contact your sales representative)
• System sizing requirements (contact SSA or IBM services)
• System performance analysis or tuning requests (contact SSA or IBM
services)
• Project planning or project status updates (contact SSA services)
• Software delivery requests (contact your sales representative) (except for
BMRs, cumulative on your current release or the database conversion utility,
which are provided free of charge under a valid OGS contract)
• Arrangement of SSA Professional Services engagements
• Questions about an SSA Invoice (contact SSA Finance and Administration)
• Permanent or Temporary Software Key Requests (contact SSA Finance and
Administration or your sales representative) (emergency five-day keys are
available from HelpLine only for disaster recovery on weekends)
• Defect in modified software (contact the party responsible for modifications)
• Programming assistance in ADK or ODW design tools, or any programming
language (contact SSA Education or SSA Services)
• Advice on planning the BPCS source or database modifications (contact SSA
services)
• Software products not covered under a support agreement with the SSA
International HelpLine (contact the responsible vendor)
• Product education (contact SSA education coordinators)
13.10.2 Obtaining product knowledge: SSA public education classes

The SSA HelpLine does not provide extensive training to users regarding the
overall operation of BPCS programs or product design tools. SSA maintains
numerous courses on the use and setup of the SSA product line to meet the
educational needs of its clients.
If you require extensive information or training on running or setting up a

particular SSA product, search the SSA Web site to find and register for available
courses. Or, contact your SSA representative for further information.
You can connect to this information from a link on the main SSA Web site, or at
the direct address: http://www.ssaportfolio.com/company/education/
Currently registration is available online for courses offered in North America.

Private and single company courses are also available upon request.
Proper product education is required of all HelpLine users. It is not the role of
HelpLine to replace the responsibility of either clients or affiliates to receive

proper education and training in product application and implementation.
Because time is a premium for all professionals involved, product knowledge
certification is required before SSA Affiliates and SSA Partners can use HelpLine
resources. The Affiliate and Partner certification process is administered by SSA
Global Technical Services.
13.10.3 Obtaining platform knowledge: AS/400 education classes

SSA AS/400 Technical HelpLine does not provide extensive training to users
regarding the operation and setup of your AS/400 system. It does not make
specific recommendations for system tuning or work management settings.
We recommend that if this level of expertise is not available at your site, SSA
Professional Services can be retained to assist you temporarily in such matters
as:
• Installing or upgrading BPCS releases
• Creating new BPCS testing environments
• Tuning the entire system for maximum BPCS performance
• Completing modifications to BPCS programs
We also recommend that someone on site have proper knowledge of AS/400

Operations and Work Management to keep jobs on your system running smoothly
on a daily basis. This way, you can also produce documentation such as user job
logs, job dumps, and other materials that may be requested to resolve a HelpLine
incident.
Additional helpful topics to consider for AS/400 education that relate to running
BPCS would include an understanding of the AS/400 database structure and how
to monitor and configure your system for maximum performance. If you plan to
modify BPCS or implement SMGs, we recommend that you have an
understanding of RPG, SQL, and C programming basics. An basic understanding
of TCP/IP is recommended if you are implementing Client/Server eBPCS.

Chapter 14. Problem determination
This chapter is intended to help you diagnose and manage problems that you
may encounter in running SSA’s eBPCS on the AS/400 system. This chapter
covers the following subjects:
• How to get answers to questions about SSA-developed products
• How to resolve Suspected Defects in SSA-developed products
• How to gather information and documentation regarding a suspected defect
• BMR Change Management - how to best load, manage, test, and integrate
fixes
• Problems with BPCS Extensibility Center (BEC) customized products
• Problems with third-party products that interface with eBPCS
For the purposes of this chapter, SSA-developed products refer to:

• Core eBPCS application products
• Semantic Messaging Gateways (SMGs)
• AS/SET Development Kernel (ADK)
• Object Development Workbench (ODW)
• Plant Maintenance
• Certain third-party product interoperability software
See your SSA Software License Agreement to determine the terms of product
support for your third-party software that connects to eBPCS. Contact your SSA
Professional Consulting Manager if you are unsure of the terms for support.
14.1 Where to begin

If you have a brief question about eBPCS or want to know how to perform a
particular task, there are several sources of information you can use to answer
your question. This section outlines these sources.
14.1.1 OGS Online: SSA's OnGoing Support Web site

OGS has answers to the following types of questions online:
• How do I find the latest product, version, or cumulative is?
• How do I migrate from an older version of BPCS?
• How do I contact the HelpLine?
• How can I find the latest BMRs for my product?
• How do I find out the sunset date for my product?
• What is the status of my company’s open incidents with HelpLine?
• What is the status of the BMR I want to order?
• How do I test the BMRs I received?
• Are there any alerts or bulletins for the product that I am installing tomorrow?
• I am experiencing a problem in my product. Is there a known BMR or
workaround?
• Are there any known issues with my release of BPCS and the new release of
OS/400?
• Are there any education courses available for a particular SSA product in my
area?
• What is the purpose of the BPCS data file?
• What does this error message mean?
• How do I create a testing environment for BPCS? What files do I copy?

• What are the HelpLine policies for giving me assistance?
• Can I use the FTP site to download BMRs?
One easy way to find answers to common (or even some uncommon) questions
is to go to the SSA customer support Web site, OGS Online at:
http://ogs.ssax.com
An On-Going Support contract is required to access this information. If you

purchased support but do not yet have a user ID and password, you can apply for
one online. If you do not have an On-Going Support contract, contact your SSA
Sales Representative.
If your question is about a problem in, or the operation of, a BPCS or related SSA
product, start in the Frequent Product Questions Infobase section. Select this
option as shown in Figure 119.
Figure 119. OGS OnLine
The Frequent product Questions Infobase section contains information gathered

directly from resolved SSA International HelpLine incidents. The HelpLine
consultant has edited the call log into a readable question and answer format.
When searching in the database, there are currently three sections from which to
choose.
Core BPCS products and other related products, such as ODW and SMGs, are in
the section labeled for BPCS. AS/SET questions and answers are logged in the
AS/SET section, and EDI calls are in their own section. You can highlight to
search on one or more of the databases at the same time when entering your
query.

14.1.2 Hints and tips for searching OGS Infobase
Consider these tips when searching OGS Infobase (Figure 120 on page 236):
• The most useful search field to begin using is to enter your search criteria in
the Search Entire Database box.
If you find your search received too many "hits," narrow the search down by
platform (the AS/400 system is stored in the database as "A400"), release, or
product area in question, or use more keywords. For each section, the
question mark (?) gives an example or explanation of the field as it exists in
the SSA database and how to best use it.
• Take time to learn the terminology used by SSA HelpLine.
Learning to use the search utility efficiently may take a bit of time as you get
used to SSA terminology and methods of describing problems. Try using
different combinations of words and different word synonyms if your first
attempts do not result in any hits. This database is entered and maintained by
the entire SSA International HelpLine, including the USA, UK, and Australia.
At times, regional phrasing and spelling are used.
• Avoid being too specific in the query.
Use few words and use the Search Entire Database field for the majority of
your searches. Only narrow down your search by individual fields or add
additional words if you receive too many hits.
• Use wildcards, especially for product names and programs or words that have
plurals.
For example, if you want instructions on creating multiple BPCS environments
or to view known issues about creating them, you would find 38 hits if you
searched on the words "multiple" and the plural "environments". If you search
on "multiple" and the wildcard "environment*", you will find 53 hits on the
subject.
• Understand how the search engine works.
You may enter as many key words as you want. The search engine does not
care what order they are in inside the document. The greater than (>) and the
lesser than (<) signs can be used inside the date fields and are helpful for
finding the most recent information on a subject. Further help information on
how the search engine works is available by pressing the ? (question mark)
button on the search page.
If for any reason you find conflicting information on the OGS page, check the
BPCS version and date of the entry to see if they account for the difference in
information. Or, contact the SSA International HelpLine for clarification.
Occasionally a BMR will change the behavior of a product, making a prior entry
obsolete. The SSA HelpLine removes or updates the outdated entries where
appropriate. Be sure to write down or print out the call log number of the entry in
question.
Problem determination 235

Figure 120. OGS main page
If you do not find an answer for your question in any of the OGS databases, or if
you need clarification about something you read in the OGS database, you
should open an incident with the SSA International HelpLine. State your question
as clearly and concisely as possible so that it may be researched before your call
is returned.
14.1.3 Logging your question using OGS

You can log your question by telephone, fax, or e-mail. You may also use the
OGS Online call logging facility to enter in an incident with the SSA International
HelpLine (Figure 121 on page 237). The e-mail and OGS methods should not be
used for urgent priority 1 matters. However, it is an excellent way to have general
or quick questions answered. You can include as much detail and screen
captures or documentation in your e-mail as you wish.

Figure 121. Product Support
The more information you provide initially, the faster and more accurately your
question can be researched. Your e-mail will be entered into the normal HelpLine
call logging system at SSA. You will receive a return e-mail message that lists
your incident number. An SSA HelpLine consultant will either reply to you by
telephone, facsimile, or e-mail. We recommend that you do not use this method
of communication for urgent matters.
14.2 Questions about modifications to BPCS

HelpLine consultants only handle questions regarding unmodified software. SSA
Professional Services or the BPCS Extensibility Centers (BEC) can assist in
modifying BPCS software for you. They can also assist you with technical help in
understanding BPCS programs to implement a modification project.
Some basic questions about modifications to BPCS (for example, what pitfalls to
watch for when making modifications to programs also used by SMGs) can be
answered by the AS/400 Technical HelpLine. However, direct "how-to"
programming assistance is not given. If your question is outside the scope of the
SSA International HelpLine, you may be requested instead to contact your SSA
Sales Representative or SSA Professional Services Consulting Manager, or the
BPCS Extensibility Center (BEC). These organizations can handle your entire
project or offer technical or product knowledge assistance to your own internal
team doing the modifications.
If you have software that was modified by SSA and purchased a Client System
Support Agreement, you will be directed to the Professional Services team that
handled your extensions. Or, you may be referred to the BPCS Extensibility
Center (BEC) for assistance with resolving any problems using the modifications.

14.3 Methodology for faster software and end-user problem resolution
You may suspect that a problem you are encountering in BPCS or other SSA
software is not a setup or user education issue, but instead a software defect. In
this case, there are several steps you should take before reporting the problem to
the SSA International HelpLine. You can use these same procedures if you want
to find or enter a Modification Request to have e BPCS enhanced.
The flow chart in Figure 122 shows an example of a problem-resolution process

that catches user errors and known problems in the most cost-effective way for
your organization. Details about these steps are presented in the following
sections.
User Encounters
a Problem
or Question
User Contacts the

Company’s Internal
BPCS Coordinator
Problem Yes
A Resolved?
No
Software Hardware or
Software?
Yes Software
Purchased Hardware
from SSA? No
Contact the
Modified Yes Responsible
BPCS? Vendor
No
Read the Run
Read Run No
Instructions, Instructions, A
Help Text Help Text
Yes
Diagnosed the Diagnose the

No
symptoms and checked symptoms and A
OGS Online? check OGS Online
Requires a
Yes BMR?
Call the SSA
International
HelpLine
Yes
Figure 122. Problem resolution process
14.3.1 Internal coordination on site

The chart in Figure 122 illustrates the important initial step of having an internal
BPCS coordinator through which site end-users can direct their problem reports
to SSA. This will assist your company, especially if you have multiple sites, for

example, from having five users all call the SSA HelpLine to report the same
problem or order the same BMR. In addition, problems that involve user
education, incorrect configuration of PCs to reach a given BPCS environment,
and the like can be quickly addressed locally, where the knowledge of the set up
of BPCS at your site is strongest.
The same person or persons can also act as coordinators when rolling out
modifications or fixes to the rest of the organization. They can keep track of which
BMR fixes have been applied to the various BPCS environments you may keep
active on site.
Once you determine that the problem is not a setup or user education issue and
want to address the problem using an outside support structure, you are ready to
proceed to the next step in the process.
14.3.2 Determining product maintenance responsibility

First determine if the product in question is one that SSA sold to you and
supports. The SSA International HelpLine supports all core eBPCS products and
several prior releases of BPCS products, SMGs, ODW, and ADK. A list of
"sunset" dates showing the last support date of various older BPCS releases can
be found on OGS Online in the Products section.
Help for BPCS releases which have been sunset may be available via SSA
Professional Services. If the product is supported by SSA HelpLine, the OGS
Web site and the SSA International HelpLine can be used to help you resolve
your problem.
If the program in question was created by an SSA BEC (BPCS Extensibility

Center), the BEC has an SSA Professional Services contact to maintain that
eBPCS customization. Contact the BEC center where the program was modified
for assistance. If the problem lies between the BEC modification and standard
BPCS software, the BEC can initiate resolution from within the internal SSA
support structure.
If you are unsure who supports the product in question, contact your SSA
Consulting Manager, the SSA International HelpLine, or the outside vendor. They
research the issue and direct you to the appropriate resource.
14.3.3 Third-party modifications to core eBPCS

If the product in question is part of core eBPCS and has been modified by
another vendor, test the program without the modifications to see if the problem is
due to base BPCS logic or the modification itself. For this reason, many modified
sites keep an unchanged (vanilla) version of BPCS available for testing. This is
easily done by putting all modified programs in a separate library that is listed
ahead of the BPCSPTF and base BPCS objects libraries in the library list.
To test without modifications, simply alter the library list to remove the
modifications library and test the issue again. If the modifications themselves are
the cause of the error, contact the vendor or developer who made the
modifications for product maintenance.

If the modifications to BPCS are not the cause of the error, you may continue to
work within the standard SSA support structure, as long as you provide any job
logs, screen prints, or program dumps from the unmodified software version.
14.3.3.1 Determining maintenance for third-party products

Who directly supports a third-party developed product is determined by which
product you own and the support agreement that SSA has agreed upon in regard
to the product. This is defined for you in your SSA Software License Agreement
under which the product was sold. Products are sold under various schedules, for
example: A, B, C or D, which determine who shall provide support for that
product. Your SSA Sales Representative should be able to assist you in
determining the party responsible for supporting the software if you are unsure.
Occasionally an error that shows up initially in a BPCS program can be caused by

third-party software that updates the BPCS database incorrectly. You will often be
directed by the SSA International HelpLine to first test the failing BPCS program
without the vendor software in the configuration to determine if the error is
occurring due to a base BPCS defect or a vendor software defect. Once the clear
source of the problem can be determined, the responsible software vendor needs
to implement the software fix.
14.3.4 Checking the run documentation and help text

Although this may sound self-explanatory, many end users are guilty of making
assumptions about the way a program is designed to work based upon how they
wish it would work. In other cases, a crucial previous set-up step in another area
of BPCS has been skipped and is the source of the perceived error. Be sure to
check the help text and associated run documentation or course materials you
have on site before assuming the software is not working properly.
If you read the documentation and decide the software program in question is
working properly, but you would like to have it changed or extended to offer more
functionality, you may contact the SSA International HelpLine and request that an
Enhancement BMR be entered so that the software can be re-designed or
extended in a future release. You may also request SSA Professional Services to
perform the modification if it is urgently required.
14.3.5 Checking for already known resolutions to the problem on OGS

The fastest way to resolve a given problem is to find out if it is already fixed and
obtain the fix. This section presents several areas on OGS that can assist you in
finding known fixes or workarounds for problems.
14.3.5.1 OGS product support: BMR listings and more

From the same OGS Web page where you can report an incident online (Figure
123 on page 241), there are links to several areas to assist in resolving your
problem before logging an incident. Using these tools, you can determine if there
is a known fix for the problem you are experiencing, or find a listed workaround to
use while the fix is being developed. You can also check to see if a new
cumulative or release exists to which you may consider upgrading.
In addition, there is a listing updated nightly that shows all the most recent BMRs
that have been passed on the previous day. Use this area to proactively acquire
fixes to avoid future problems.

Figure 123. OGS problem resolution
In the Product Support area, you can also browse the HelpLine Scope of
Operations document. This document lists several pieces of information you
should gather before calling the HelpLine. It lists the types of documentation and
information that will assist in faster resolution of your problem.
14.3.5.2 OGS product news and product bulletins

This section is important to read, especially when installing a new release,
cumulative, or product. This section lists urgent known issues that may require
action to resolve (such as ordering the fix or following a workaround).
14.3.5.3 OGS frequently asked questions for your symptoms

The Frequent Product Questions database on OGS lists solutions to problems
that may be perceived initially as a defect, but are in fact setup issues with the
database or software. Workarounds are given in this section. If a specific BMR
also relates to the problem mentioned, it is listed in the answer as well. Search
this section when you do not find a BMR that matches the problem you are
encountering.
14.3.5.4 Tips for searching the BMR database on OGS

The first place you can search is the OGS Online BMR (BPCS Modification
Request) database to see if the problem you are encountering is a known issue.
Enhancement requests are also logged in this same database as priority "E"
BMRs. BMRs are listed in the database the day after they are reported by the
SSA International HelpLine or internal SSA testing. When BMRs are resolved,
they are either closed to a rejection code (explained later in this section) or are
closed with a list of the programs that required changes to resolve the problem. If

programs were altered at your BPCS release level, the BMR may be ordered from
the SSA International HelpLine. Consider these tips:
• Use wildcards for words with plurals and various endings.
For example, if you notice that a program appears to be looping, use the
wildcard (*) to search for "loop*." This brings in all related words such as
"looped," "loops," and "looping."
• First, search in a general way, and then narrow down your search gradually.
When you search on multiple words, the search engine shows you how many
"hits" were returned on each word in your query (Figure 124). Using this
information, you can decide to omit certain search words or add more words to
narrow the results. It is best to start with fewer search words, and then narrow
down only if you receive too many unrelated "hits."
Figure 124. OGS BMR query
• Search on a substring of a program name followed by a wildcard.

Many SSA programs have endings on them. If you believe the problem is
somewhere in the ORD700 order entry job stream, but are not certain which
program could be at fault, try a search on ORD7* to pick up all related
programs, such as ORD700D1, ORD700D2, ORD701B, etc.
• Use the Priority Code field to find Performance BMRs.
Priority code D is always used for performance BMRs, so this is an easy way
to narrow your search. Priority code meanings for all types of BMRs are
covered in detail in 14.3.6.3, “Understanding BMR priority codes” on page
245.

• Search on the title of the main program as shown on the BPCS screen.
The name from the BPCS menu end-user program name and the program
number are generally included in the BMR description (unless the BMR affects
multiple program numbers). These listings are always in English. If you use
another language, check the SSAZ02 or SSAZ03 library in your base release
to find the English translation for your menu or program name if you are
unsure of what to search.
• Do not search the Version Reported field to find BMRs for your release.
For example, the problem may be reported first by a customer on version
6.0.02, but may also affect eBPCS 6.1.00 as well. If you searched only on a
reported version of 6.1.00, you may miss the BMR listing that described your
problem.
• Use the Versions Affected/Corrected field to find complete BMRs on your
release.
This is a good way to search for already completed BMRs by your release
number. If you are on eBPCS, search for with a wildcard for 6100* in this field.
This finds all BMRs completed for your release, whether the problem was first
reported on your release.
If the BMR is not yet completed, you can still find it if the problem was
accepted and analyzed to the point where it is known which versions are
affected by the defect.
This field does not use periods to separate the BPCS release number and
contains two extra numbers to denote the last full cut (patch level) over which
the product was built (for example, appears as 610001, not 6.1.00.01).
• All fixes for eBPCS completed after base release are closed to 610001.
When a Patch Level (representing large database file changes) has been
completed on a BPCS release, the release number to which an object is
closed increments. No Patch Level has been released for eBPCS as of this
writing.
For example, 6.0.04 has never had what is referred to as a Patch Level, and
has only had cumulative levels (which include all programs as of the prior
Patch Level). Similar to eBPCS, all BMRs closed after the 6.0.04 base
release, are closed to version 600401.
In release 6.0.02, the last Patch Level was called F (PLF). All fixes completed
after PLF are closed to release 600207.
In BPCS CD, you can search on BPCD03 to find all fixes done after the last
Patch Level, which was called Release 02.
• When you find a BMR, pay close attention to the Version and Release fields
and the date the BMR was closed.
This way, you can determine if the BMR is built on your release of BPCS, is a
BMR you already have, or is a new BMR that you are missing. In addition to
Patch Levels, SSA also puts out cumulative releases, which include all BMRs
done since the last Patch Level. As of this writing, the last cumulative release
for 6.0.04, for example, was done in July 1999. There has thus far not been a
need for a cumulative release for eBPCS. See Figure 125 on page 244.

Figure 125. OGS BMR details
14.3.6 What to do if you find a BMR that describes your problem

If you find a BMR that describes your problem, check to see if the BMR first
affects your release of BPCS. Second, check to see if the BMR is completed. If
the BMR is not completed, the BMR Priority Code and status of any objects can
give you an idea of the stage of the BMR.
You may also follow the Escalation Procedures for BMRs as documented on OGS
Online to escalate the completion schedule for any accepted BMR. A BMR is not
accepted for development until the developers have analyzed the BMR and
determined that the described problem exists in current code levels.
14.3.6.1 Supported versions for BMRs

SSA corrects construction defects within supported versions of BPCS
Client/Server when reported by any client whose maintenance subscription is
current. Corrections are made to the BPCS Client/Server version under which the
defect was first detected. As soon as possible thereafter, SSA automatically
corrects all subsequent supported versions having the same defect, but makes
no attempt to duplicate or correct the defect on any prior supported version
unless the defect is separately reported.
Be sure to phone the HelpLine to report the problem if you find a BMR that
describes the defect. The version upon which the BMR was completed is higher
than your current version, and your current version is still supported.
SSA publishes the list of supported BPCS versions on OGS OnLine, and
periodically revises the list as business conditions warrant.

14.3.6.2 Inquiring about open BMRs
If you find a BMR on the OGS Web site that does not have a completion date and
does not have a rejection code, the BMR is considered to be "open" and is in an
investigation, coding, or testing stage.
Contact the SSA International HelpLine group representing the product that the
BMR affects. They can tell you if the BMR already has an estimated time of
arrival (ETA) date for delivery, or in which stage the BMR is currently. They can
also inform you of the date upon which the BMR was first entered, and assist with
finding a workaround for any B or D BMRs wherever possible.
If the BMR is accepted, but still open, and is urgently required, you should follow
the BMR Escalation process, which is documented on the OGS Online Web site.
If you are uncertain about whom to call, and do not have an assigned account
manager, contact the SSA Professional Services director in your area or the SSA
International HelpLine.
14.3.6.3 Understanding BMR priority codes

BMR priority codes are a way to qualify the BMR by severity or type of defect.
When searching the database, you can use the Priority Code field to easily find
Performance BMRs, for example, which are all listed as priority D.
If you are being pro-active in ordering preventative BMRs, you may want to run a
query on a product code such as ORD* in the Search Entire Database field.
Then, search for Priority Code A only, to pick up any critical fixes for that product.
Here is a list of priority codes:
A BMR Critical construction defect with no feasible workaround and
represents a consequential bottom-line damage to SSA's customers,
for example: lost sales, temporary staff required to manually operate
the system, and penalties assessed against a business. A hard halt,
endless loop, or a data destroying error are examples of an A BMR.
B BMR Critical construction defect having a practical, temporary work-around.
An alternate way to operate the software without adverse bottom-line
impact yields correct results and does not damage important
information.
C BMR Any construction defect that cannot otherwise be classified into
priorities A, B, D, or G.
D BMR Construction defect that produces response times that exceed
acceptable performance specifications when operated within an SSA
recommendation environment. If the performance defect has no
feasible workaround and represents a consequential bottom-line
damage to SSA's customers, for example: lost sales, temporary staff
required to manually operate the system, or penalties assessed
against a business. The BMR should be escalated similar to an A
BMR.
E BMR Enhancements to the product addressed through design changes that
alter the software's fitness-for-use. E enhancements are forwarded to
product management for consideration in future product versions and
to provide a disposition as to whether the request will be accepted as
a future enhancement or rejected. Enhancements are not typically

included in software upgrades (releases), but are implemented within
a new version of BPCS.
G BMR Errors and omissions in product documentation, including operator run
instructions and help text.
H BMR Represents enhancement requests that were approved for
implementation into future products. The BMR is changed from an E
status to an H status when the BMR is accepted for a future release.
14.3.6.4 Understanding rejection codes for BMRs

If you find a BMR that describes your problem but has a Rejection Code, then the
BMR was not completed for one of several reasons, for example:
• BMRs that are closed as NMR are fixed, but the work was done under a
different BMR number. The SSA HelpLine can identify the BMR that resolves
the problem for you if the Next BMR field does not appear. If this field appears,
then the listed Next BMR is the BMR that should be ordered to resolve the
problem for you.
• If a BMR is closed out as NDU, this means there was a problem. However, it
was caused by either a user misunderstanding of the purpose of the program
or in the setup of BPCS or was missing crucial setup data required for BPCS.
The HelpLine can find the associated education information for the BMR
number that will help you avoid the problem.
• A BMR closed out as NDP means the problem, as described by the client or
HelpLine, could not be duplicated in the current code of the development
environment. No specific BMR was identified as correcting the problem. If you
are currently experiencing a problem described by a BMR closed as NDP,
contact the SSA HelpLine to assist you in determining how to bring yourself up
to the current code levels to avoid the problem.
Here are the BMR closing codes you will most likely encounter:
NDP Cannot duplicate in current code
NDU Education issue
NMR Fixed by another BMR
NRJ Rejected enhancement (E BMRs only). Enhancement will not be
worked on.
NST Product has been sunset and further BMRs will not be considered
14.3.7 Ordering a completed BMR

If you find a completed BMR that describes your problem and was built for your
release of BPCS, you can either phone a BMR request into the SSA International
HelpLine, or enter a request for the BMR via e-mail from the OGS Online Web
site.
Currently fixes are distributed only upon your request. Once a BMR fix is
developed and tested, it appears in P status on OGS and is considered available
for distribution. This can be viewed by accessing the BMR database via OGS
OnLine. You must then determine whether to implement the fix available, retrofit
it, or wait until the next software release. Once you decide to implement or retrofit
any BMR fix, you should request the fix by contacting their Regional HelpLine.

14.3.7.1 Special case considerations for ordering BMRs
There are certain configurations and conditions that you should be especially
aware of when ordering BMRs.
When to order more than one BMR at a time

If you see five BMRs which all affect the same program, you do not need to order
all five BMRs to get all the fixes. Simply order any one of the BMRs, and the BMR
dependency tree pulls in the most current level of the code, which contains all the
other fixes and related programs, plus any co-requisite BMRs.
If you find more than one BMR you want to order, you may request up to 30
BMRs be bundled into one explosion library. This gives you one library containing
all the fixes and co-requisites, and avoids the shipment of duplicate dependent
objects delivered in separate BMR libraries. You must specifically request this
bundling to be done at the time you order the BMRs.
BMR bundling can be especially useful if you group the BMRs into bundle
requests by the products affected. This reduces the number of duplicate objects
you receive when product dependencies are encountered in the BMR build
process. See 14.5, “BMR change management for BPCS version 6.x” on page
260, for further details on how BMRs are packaged and approaches for testing
BMRs.
Mixed-Mode SMG or Mixed Client/Server and Mixed-Mode environment

users
If you are on Mixed-Mode BPCS and are using SMGs or, if you have both Full
Client/Server and Mixed-Mode BPCS object libraries pointing to the same BPCS
files database, be sure to order both the Full Client/Server and Mixed-Mode
versions of any BMR fix.
The Mixed-Mode and Full Client/Server BMR libraries are not interchangeable.
The specific list of Full Client/Server ILE RPG programs that are packaged along
with Mixed-Mode SMGs in the SMGSUPPORT library are included in your SMG
Installation Guide. If any of these objects are affected by your intended BMR or
any object in the resulting BMR dependency tree, those SMGSUPPORT objects
must also be updated for the fix to be used by the SMG interface to BPCS.
Ordering BMRs when you have modifications to BPCS

If you have modifications to BPCS, be sure to order both the Object and the
Source BMR for any BMR you order. The Source BMR delivers the ADK or ODW
Action Diagram definitions for the programs included in the Object BMR
explosion. When speaking to the HelpLine Consultant, request either ODW
source or ADK source when you place your order. If you order source but do not
make a specification, ADK source is assumed.
If you installed SSA BEC modifications to eBPCS or have third-party products

interfacing to eBPCS, you may want to contact those support offices to ensure
that a given new BMR on either the server or client platform does not interfere
with the successful operation of the modified or interoperability code. The SSA
International HelpLine cannot ascertain this information for you. You should save
the list of objects that is supplied with your BMR delivery so that your modification
support persons can determine the effect of the BMR.

Information required when ordering a BMR
BMRs can be placed on the SSA FTP site (ftp.ssax.com) or BMRs for BPCS
version 6.0.02 and up can be saved to CD-ROM or various tape media. Be sure
to provide proper information when entering your BMR request. Not all tape
media formats are supported, so be sure to check with SSA HelpLine before
placing your first BMR order.
The HelpLine needs to know the following information to build your fix:
• BPCS release
• Mixed-Mode or Full Client/Server (or both)
• Source or objects (or both)
• For Source BMRs, ODW, or ADK source
• OS/400 version and release
• Last cumulative applied to BPCS (if applicable)
• BMR numbers
• Shipping address (PO boxes are not allowed)
• Contact name and phone number
• Indicate if you want to download from an FTP site (depends on the BMR size
when finished)
• Media requested (CD-ROM or tape media type). Include this information even
if you prefer FTP, in the case that the BMR built is too large to place on the
site.
A fix will be built for your BPCS release and cumulative level. The fix that is built
is commonly called an "explosion" or a '"BMR tree." This process finds the
affected programs that were fixed in the BMR that you are requesting and also
finds any superseding and co-requisite BMR dependencies. These may include
products that initially appear unrelated to the BMR you originally requested.
BMRs should be applied as a whole, and programs should not be pulled out of
BMRs and separately installed. Doing so can lead to unpredictable program
errors, due to product and program interdependencies.
In many cases, related fixes for the BPCS PC Client software are also required
for a server side BMR. These may be due to the original BMR that you requested
or due to a co-requisite BMR picked up in the explosion process. This fix can also
be placed on the FTP site or on a CD-ROM. In some cases, the fix can also be
sent via e-mail. If you receive both a client and server fix, you should test them
together.
When you receive the BMR, check the QTXTSRC file in the BMR library on the
AS/400 system. This gives you a complete listing of all the BMRs pulled in under
the explosion process and shows you the objects in BPCS that were affected.
You should always test a BMR before putting it into a production environment. If
the fix was for the client PC software only, read the .rpt PC file for a listing of all
PC objects affected by the BMR.
This process is explained further in 14.5, “BMR change management for BPCS
version 6.x” on page 260.
14.3.8 Logging new issues with HelpLine to resolve your problem

If you are unable to find a known BMR or education entry in the Frequent Product
Questions section for the suspected defect, we recommend that you open an
incident with the SSA International HelpLine. The OGS Web site and the

HelpLine Scope of Operations list a number of important pieces of information
you should provide when logging a call.
14.3.8.1 Quantifying the problem with answers to these questions

The more information you can gather to describe the problem, the faster your
problem is likely to be resolved. Similar to investigative journalism, try to answer
the following questions when you gather information at your site before calling the
SSA HelpLine.
Be an investigator: Ask who, what, where, how, and when

Attempt to answer the following questions:
• Who : Who does the problem affect?
Determine if the problem affects one user, all users, or only users set up in
BPCS security in a specific way.
• What: What is the nature of the problem? What BPCS product and BPCS
program number is being used?
Determine the exact error. Consider such examples as: a program abend
(hard-halt), a program that completes but does not produce the expected
results, slower than normal response times, connectivity, or printer problems.
Be as specific as possible, and copy the exact message text if an error
message is seen on screen.
• Where: Where does the problem occur?
Find out if this affects every BPCS environment, testing only, production only,
users on the WAN only. Or, maybe it affects one AS/400 system where BPCS
is installed, but not another AS/400 system and so on.
• When : When did the problem begin?
Determine whether it has always behaved this way or did the behavior change
after applying a BMR or an IBM PTF or after some other event such as a data
refresh into a testing database, or after month end was run.
• How : How is the program being used?
The majority of BPCS programs allow the user to enter or submit a job with a
variety of filters or parameters. If parameters are entered differently, find out if
behavior changes. Consider such examples as running for an open range of
facilities or orders versus running over one facility or order, or running a
program interactively versus submitting the job to batch.
If the problem can be reduced down to a single customer type, order type,
item type etc., note that information when you speak to the HelpLine
consultant.
Provide screen prints of any user input screens or error messages that help
show the sequence of events leading to the problem.
Answering ‘why’
The SSA International HelpLine tries to answer why as in "Why is the software
behaving this way?". Depending on the situation, the HelpLine will provide a fix to
correct the problem and information to avoid (work around) the problem. They
may also enter a BMR to have the problem corrected or provide education
information on how the program is supposed to work or be set up to avoid the
error.

If a problem cannot be resolved by the HelpLine consultant, the consultant will
make recommendations as to how it can best be handled. All serious issues are
taken through the HelpLine escalation process, and the appropriate consulting
manager is notified if required.
14.4 Gathering information and documentation

The SSA International HelpLine uses the same OGS Online database tools that
are available to you in order to research your problem, including the BMR and
Frequent Product Questions databases. In addition, the SSA HelpLine relies on
past call logs in their "raw" unedited format, fellow team members, and
programming development contacts to research your issue.
You may be asked to provide documentation such as BPCS setup information,

screen prints, job logs, program dumps, job traces, DBMON files, or other
information to the consultant. This information is all used to research the cause of
the error. The faster it is made available to the HelpLine consultant, the more
quickly your problem can be resolved.
In severe cases where a clear cause cannot be determined via normal support
channels, the SSA HelpLine may request a dial-in to your AS/400 system or PC
Network to observe the problem via Electronic Customer Support. In such a case
you need to have on file with SSA a legal form called the ECS Contract, which
allows the SSA HelpLine to perform this task. The HelpLine Customer Service
Representative will provide the form to you via facsimile if one is not already on
file. This form is also available on OGS OnLine in the HelpLine Scope of
Operations.
There are specific guidelines that the consultant must follow while logged onto
your system. These guidelines are documented in the HelpLine Scope of
Operations on OGS OnLine. For example, the HelpLine Consultant is not allowed
to alter any data or settings while on your system. If such action is required to
resolve the problem, you are told of the changes being recommended and asked
to implement the changes at a time that will not inconvenience your end-users.
You should always back up any related BPCS files prior to performing any
modifications of your data or system settings.
14.4.1 Identifying eBPCS Client/Server jobs on the AS/400 system

Often times, the SSA HelpLine will request you to provide a job log of the
program that is receiving an error. Even if no blatant error appears in the log, it is
actually often the vital key to resolving a problem.
The job log lets a consultant view key messages that may otherwise have been
overlooked. Such messages may show abnormal program flow before the main
error has occurred or before the program ends normally.
The job log also reveals the program that has sent the error message, if any, and
allows the consultant to research BMRs on that specific program.
The job log lists the program names and libraries in which they reside to help the
consultant understand the configuration of the environment where the problem
exists.

Sometimes when running client/server programs from a GUI session, it is difficult
to find a job log or to know where to look for the job in question. They do not
appear as the standard green-screen jobs with which most system operators are
familiar (Figure 126).

V6CSSUBS QSYS SBS .0 DEQW
AC0A80D62 SMITH BCH .5 PGM-NWICSTUB RUN
AC0A80D93 JONES BCH 2.2 PGM-NWICSTUB TIMW
A0A016869 LOPEZ BCH .6 PGM-NWICSTUB TIMW
NWI JONES BCH .0 PGM-NWICSTB2 SELW
NWI SMITH BCH .0 PGM-NWICSTB2 SELW
NWI LOPEZ BCH .0 PGM-NWICSTB2 SELW
NWID DAEMON BCH .0 PGM-NWID TIMW
SSATCP DAEMON BCH .0 PGM-ALAUNCH TIMW
SSATCP DAEMON BCH .9 PGM-ALAUNCH RUN
5 SSATCP DAEMON BCH .8 PGM-ALAUNCH TIMW
SSATCP DAEMON BCH .0 PGM-ALAUNCH TIMW
Figure 126. WRKACTJOB in a BPCS Client/Server environment
14.4.2 Determining if you are using a First or Second Generation BPCS

GUI jobs in e BPCS or any version 6.x BPCS release that are running under
TCP/IP will run under either an ALAUNCH job or a NEWICSTUB function name
when viewed from a WRKACTJOB screen. Knowing which daemon is running
your underlying client/server job is important when you need to gather debugging
information. Configurations are different for First or Second generation jobs. This
is another clue your HelpLine consultant often needs to use to determine the
cause of the problem.
If you have Full Client/Server BPCS, both First and Second Generation GUI
applications will run.
First Generation jobs run under the DFS ALAUNCH daemon. In eBPCS only,
OLM and CEA applications are DFS. In prior BPCS versions, COM is also DFS.
Second Generation jobs run under the OMS daemon. In eBPCS, all other
applications run under OMS. In Mixed-Mode BPCS, these same applications are
driven from green-screen menu interfaces.
14.4.3 First Generation DFS jobs: SSATCP and PGM-ALAUNCH

Jobs listed under job name SSATCP and showing the PGM-ALAUNCH function
are the result of starting a First Generation DFS BPCS program. In eBPCS, these
are programs under OLM or CEA only. The jobs run under the name of the user
who started the daemon program. The actual application is under this job. You
can display the job log or the job's call stack to determine which BPCS
application has been invoked.
If a regular BPCS application is not in the call stack, then the job is likely a waiting
daemon that is listening for an incoming PC start request.
These jobs are found in both Mixed-Mode or Full Client/Server BPCS

installations.

In Mixed-Mode BPCS, if a user is connecting via APPC, the job will not run under
the daemon, and will instead appear in the subsystem where APPC is configured
to run (typically QCMN). This job will run under the name of the user who is
running BPCS.
To identify a First Generation ALAUNCH user, use the WRKACTJOB command.

Select option 5 to display the job, and option 1 to view the real user listed under
the Current user profile parameter (Figure 127).
Display Job Status Attributes
Job: SSATCP User: DAEMON Number: 049255
Status of job . . . . . . . . . . . . . . . : ACTIVE

Current user profile . . . . . . . . . . . : JONES
Entered system:
Date . . . . . . . . . . . . . . . . . . : 08/11/99
Time . . . . . . . . . . . . . . . . . . : 16:01:44
Started:
Date . . . . . . . . . . . . . . . . . . : 08/11/99
Time . . . . . . . . . . . . . . . . . . : 16:01:44
Subsystem . . . . . . . . . . . . . . . . . : V61CSSUBS
Subsystem pool ID . . . . . . . . . . . . : 2
Submitted by:
Job . . . . . . . . . . . . . . . . . . . : SSATCP
User . . . . . . . . . . . . . . . . . . : DAEMON
Number . . . . . . . . . . . . . . . . . : 049245
Type of job . . . . . . . . . . . . . . . . : BATCH
More...
F3=Exit F5=Refresh F12=Cancel F16=Job menu
Figure 127. Option 1 from the Work With Job display for an SSATCP job
14.4.3.1 How DFS daemons submit jobs

In First Generation DFS, the waiting daemon job runs the next DFS user who logs
into BPCS. The job that the user grabs then submits a new instance of the
daemon job (ALAUNCH) to wait for the next incoming connection.
14.4.3.2 Creating a job log in First Generation DFS

To create a job log, either change the job of a waiting daemon using option 2 from
a WRKACTJOB screen or change the TCPIPJOBD in the BPCSTCP library to
allow job logs to be created. Set the following parameters for Message logging:
• Level: 4
• Severity: 00
• Text: *SECLVL
• Log CL: *YES
This produces the most detailed job log that is available (Figure 128 on page
253).

Change Job Description (CHGJOBD)
Message logging: LOG

Level . . . . . . . . . . . . 4
Severity . . . . . . . . . . . 00
Text . . . . . . . . . . . . . *SECLVL
Log CL program commands . . . . LOGCLPGM *YES
Inquiry message reply . . . . . INQMSGRPY *RQD
Hold on job queue . . . . . . . HOLD *NO
Job date . . . . . . . . . . . . DATE *SYSVAL
Job switches . . . . . . . . . . SWS 00000000
Device recovery action . . . . . DEVRCYACN *SYSVAL
Time slice end pool . . . . . . TSEPOOL *SYSVAL
Job message queue maximum size JOBMSGQMX *SYSVAL
Job message queue full action . JOBMSGQFL *SYSVAL
Allow multiple threads . . . . . ALWMLTTHD *NO
Figure 128. Job description settings to produce a detailed job log
14.4.3.3 Debugging a BPCS application running under a DFS job

DFS jobs are essentially batch jobs. To trap the job before it starts, follow these
steps:
1. Start a new ALAUNCH daemon to a port reserved for your debugging use that
no one else on the system is using. You need special authorities to start a
daemon. See your eBPCS Installation instructions for details on the
authorities required. You can use the NETSTAT command to find which ports are
in use already.
2. Run the Start Server Job (STRSRVJOB) command to this new daemon job that
you submitted. Start any debugging utilities or job traces.
3. Change your PC workstation settings to use the new port number and connect
to the daemon. Your job will run under the same job number as the daemon
job that was started in step 1.
4. Produce the error and collect the trace or debugging information.
14.4.4 Second Generation OMS: NWI and PGM-NWICSTUB

Jobs listed under job name NWI and function PGM-NWICSTUB are the result of
starting any Second Generation OMS BPCS program. In eBPCS, these are the
majority of applications available and are listed in Start->Programs under the
red Second Generation icon.
These jobs are only found in Full Client/Server BPCS installations. They are not
found when using Mixed-Mode BPCS. In Mixed-Mode BPCS, these same
applications are implemented as green-screen menu options. You can identify the
BPCS application being run by displaying the job log or the job call stack while it
is running.
Users in Second Generation can be readily identified by name once a BPCS

application has been started.

14.4.4.1 Debugging tips and OMS Worlds
Worlds are processes (jobs) that broker messages between the client and the
server side programs. Worlds are the launching pads from which BPCS Clients
request applications to initiate on the server. Each World can have up to five open
BPCS applications talking to it. If you are having problems with your initial
connection to OMS applications, this is the job and job log with which to start.
Figure 129. PC client screen when the World has launched on the server
When a World is started on the server, from the PC, you will see the main BPCS
application selection screen (Figure 129), from which you can launch various
end-user applications. Clicking around on icons on the display bring up various
BPCS "containers" holding program icons to choose, some of which are
additional containers.
Once you click on an application and get the message Starting Program Please
Wait, OMS initiates a new NEWICSTUB server job for the user.
If you encounter a problem after an OMS application is already started, the World
job log (Figure 130) will not contain the data showing your problem. However, it
will show you the name and job number assigned to the application that was
launched from the World. This can be used to find your application job if you
cannot see it from a WRKACTJOB screen (such as an abended job).
System: TEST400
Job . . : NWID User . . : DAEMON Number . . : 672544
>> CALL PGM(NEWI2/NWID) PARM('-port' '9007' '-nwidcfg' '*LIBL/NWIDCFG(SYSTEM)'
'-usrcfg' '*NOUSRCFG' '-ccsid' '00000065535' '-jobd' 'NEWI2/NWIJOBD' '-s bmjob'
'1' '-prtdev' '*JOBD' '-outq' '*JOBD' '-sbmusr' 'DAEMON' '-libl' 'NEWI2 QGPL')
Job 672551/DAEMON/NWID submitted to job queue NEWIJOBQ in library QSYS.
Library list changed.
Ownership of object FILELIST in QTEMP type *USRSPC changed.
Ownership of object MBRLIST in QTEMP type *USRSPC changed.
Job 672552/SRIRANK/A0A016E7F submitted to job queue NEWIJOBQ in
library QGPL.
Figure 130. Job log from an OMS 2.4.1 World launching a BPCS application

14.4.4.2 OMS versions and OPS client compatibility
OMS has version release control separate from the BPCS version. Typically your
OMS version is upgraded when applying a BPCS cumulative.
To check the version of OMS you are using, use the following command:
DSPSRVPGM (NEWI/NEWIE2E) DETAIL(*COPYRIGHT)
Here, NEWI is the name of your OMS library as installed on your system.
OMS also has a client PC-side piece referred to as OPS. Your OMS and OPS
versions must be compatible to run BPCS successfully. OPS versions included
with PC Client software prior to the 6.0.04 April 1998 cumulative or the base
eBPCS release will not run unless the server version of OMS is at 2.4.1 or higher.
14.4.4.3 Characteristics of OMS version 2.4.1 and prior OMS versions

OMS 2.4.1 was delivered with base eBPCS and 6.0.04 April BPCS. Jobs listed as
job name NWID and function NWID are either a listening OMS daemon job. Or,
they may represent an OMS Version 2.4.1 user who has logged into the BPCS
World (application launcher).
If the job is in SELW status, this represents a user logged into a BPCS World.
Use the WRKACTJOB command. Then, select option 5 and option 1 to see the BPCS
user who logged on. If the job is in TIMW status, it is a daemon listening for a new
PC logon request.
When a user selects a second generation job to start from the PC, a new
PGM-NWICSTUB job is submitted from the World to run the application for the
user. This new job runs under the job description NEWIJOBD in the OMS library.
This job description can be changed to produce a job log when required. No job
logs are produced, which is the default. The new job runs under the name of the
BPCS user.
14.4.4.4 Characteristics of OMS version 2.4.2

The job name NWI and function PGM-NWICSTUB2 jobs are initiated from OMS
version 2.4.2. They represent a user logged into the BPCS World application
launcher. Unlike OMS Version 2.4.1, this appears to show the name of the user
profile who logged into BPCS. OMS 2.4.2 also allows you to configure your OMS
Worlds to run under a separate JOBQ from your OMS NEWICSTUB jobs running
the BPCS applications.
When a user selects a second generation job to start from the launcher, a new
PGM-NWICSTUB job is submitted to run the application for the user. This job
runs under the job description of the AS/400 user profile. Alter this job description
to change whether a job log is produced. The new job runs under the name of the
BPCS user.
See BMR51795, which relates to the job description that is used by OMS Version
2.4.2.
14.4.4.5 How OMS daemons submit jobs

In Second Generation OMS, the waiting daemon job remains as a constant job
number. The waiting daemon job submits a World job to start whenever a new
user enters BPCS.

Once the user logs into BPCS and the World is started for that user, all
applications that the user launches will be submitted out of the World job.
Communications between the PC and server applications are brokered through
the World.
When debugging a problem with an initial user logon, watch the OMS daemon job
for any error messages about the connection or starting the World. If a World is
successfully submitted, turn your attention to the World job for debugging. If the
application successfully starts from inside the World job, check the NEWICSTUB
job for details.
14.4.4.6 Creating a job log in OMS Second Generation

To create a job log for a user log on problem, change the NEWIJOBD in the OMS
(NEWI) library to allow job logs to be created. Set the Message logging
parameters as shown here:
• Level: 4
• Severity: 00
• Text: *SECLVL
• Log CL: *YES
This produces the most detailed job log available.
If you are using OMS Version 2.4.1, this also produces job logs for all subsequent
points in the job launching process.
If you are using OMS Version 2.4.2, unless you have BMR51795, the job log for
the application launched by the user is controlled by the settings for Message
Level Logging on the job description of the AS/400 user profile who is logging into
BPCS.
14.4.4.7 Debugging a BPCS application running under an OMS job

OMS jobs are essentially batch jobs to the AS/400 system. Trapping the job
before it starts requires the authority to start an OMS daemon. If you do not have
sufficient authority, you will receive an error message. Authorities required are
discussed in the Installation Instructions for eBPCS. Complete these steps:
1. Sign on to a green-screen session and change your job by using the CHGJOB
command to ensure your Message Level Logging is set to the highest levels.
Start a single-instance OMS daemon interactively to an unused port number
using the BPCS STRNWID command. Use the NETSTAT command to view ports
currently in use on your system.
Interactive daemons do not persist, and will end after one use.
In the command prompt, make sure the SBMJOB parameter is set to *NO. A
screen appears like the example shown in Figure 131 on page 257.

Start Newi Daemon (STRNWID)
TYPE CHOICES, PRESS ENTER.
Service port . . . . . . . . . . > 7878

NWID configuration file . . . . NWIDCFG Name
Library . . . . . . . . . . . *LIBL Name, *LIBL
Member . . . . . . . . . . . . *FIRST Name, *FIRST
User configuration file . . . . *NONE Name, *NONE
Library . . . . . . . . . . . *LIBL Name, *LIBL
Member . . . . . . . . . . . . *USRPRF Name, *USRPRF
Submit job to batch . . . . . . > *NO *NO, *YES
BOTTOM
F3=EXIT F4=PROMPT F5=REFRESH F12=CANCEL F13=HOWTOUSETHISDISPLAY F24=MOREKEYS
Newi daemon started interactively. Waiting on port 7878...
Figure 131. Start Newi Daemon (STRNWID)
2. From your PC workstation settings, change your PC to use the special Service
Port number with the interactive daemon. Do not alter other settings.
3. Initiate the PC task in BPCS to connect to OMS. Bring up only the World
(application launcher) and do not select the icon to start the application yet.
4. To run debug over an OMS BPCS application, start a new green-screen
session. Put the NEWIJOBQ or the job queue you are using for OMS jobs on
HOLD. Use the WRKJOBQ command, and select option 3 to perform this task.
5. On the PC, select the icon to start the application.
6. Start the service job by using the STRSRVJOB command and any debugging
utilities or job traces to the job sitting in the NEWIJOBQ.
7. Release the JOBQ from a WRKJOBQ screen. Perform the actions in the
application to recreate the problem. Collect the trace or debugging information
from your second green-screen session.
When you exit BPCS on the PC, the interactive session running the BPCS
daemon will end, as this daemon can only be used one time.
14.4.4.8 Other tips when collecting documentation

Consider these tips when collecting documentation:
• AS/400 message queues to check
If you receive an error during a BPCS installation, it is important to view the
QSYSOPR message queue to see if any messages were sent there. Media
errors often generate messages to the QSYSOPR.
• AS/400 message IDs and BPCS message IDs
It is important to note the exact AS/400 or BPCS message ID in the job log
when speaking to the HelpLine. All errors are not equal. There is a big
difference between saying "I am getting some error message," and saying "I
am getting a CPF4102 error when I start this application." The exact message
ID allows the consultant to view prior calls on the same application or error
combination.

• With a message ID and the exact message text, the HelpLine can look up
previous calls on the same error message and can also search the AS/400
Help text for further information about that particular kind of failure.
• The message ID can be found interactively by pressing F1 on the message as
it appears on your green-screen session. For GUI sessions, you need to view
the job log to find the message ID and second level text.
• If you receive an error that allows you to produce an RPG program dump,
choose option D. Do not send the SSA International HelpLine a type S system
formatted dump.
• Use e-mail whenever possible to transmit long program dumps or job logs.
This saves trees, and it is easier to read and find specific text for error
messages in a word processing program. Fax transmissions of small text are
often illegible.
• A picture is worth a thousand words. BPCS application setups can be
complex. Without the proper setup, HelpLine is unable to reproduce or
research your problem. Include screen captures of system parameter settings
or application parameter settings and user navigation choices. This is
especially important where documenting an application error where the
application may be configured in multiple ways.
14.4.5 Identifying problems that fall between BPCS and OS/400

Occasionally you may encounter a problem that cannot easily be classified as
being caused by BPCS or by OS/400, or this possibility may arise after some
analysis of a given problem. If you are unsure about which HelpLine to contact,
search both the OGS Web site and the IBM support Web site
(http://as400service.rochester.ibm.com) for your problem description.
IBM APARs mention BPCS by name where appropriate to the problem

description. Therefore, you can search on the word "BPCS" when searching the
APAR or PTF cover letter databases on the IBM support site. Then, you will find
descriptions of OS/400 problems which first were reported in BPCS software.
In the OGS Online system, if the release of OS/400 is a factor in a BPCS

problem, this is documented in either the BMR description or a Frequent Product
Question entry. Generally the SSA standard is to refer to the OS/400 release as
VnRn, where "n" is the version or release number. If a PTF or APAR is known to
resolve the problem, it is also mentioned by name.
14.4.5.1 Informational APAR II11801

In addition, check Informational APAR II11801 for known PTFs that are required
to run BPCS on the AS/400 system. APAR II11801 is maintained by the IBM
HelpLine with input from the SSA HelpLine. It is used to track PTF fixes or other
information that pertains directly to using BPCS and related SSA products on a
given OS/400 release. Currently this APAR tracks information for V4R2, V4R3,
and V4R4 of OS/400. Information is added as it becomes available.
The SSA OGS Frequent Product Questions database also references an APAR
or PTF number to resolve a given OS/400 problem that manifests in a BPCS
program.

14.4.5.2 Cooperation between SSA technical team and IBM HelpLine
The AS/400 Technical Team of the SSA International HelpLine also has the
capability to work with the IBM HelpLine on incidents that falls in between the
software and the operating system. Such problems may not be readily
determined if they are in the OS/400 code or in BPCS code.
Contract required for both SSA and IBM support

For this information sharing to take place between the HelpLines, you need both
an AS/400 support contract and an SSA OGS support contract. A shared
Web-enabled problem database and telephone conferencing are available for
problem solving between these two HelpLines.
How SSA and IBM HelpLine cooperation is initiated

The cooperation between both HelpLines is initiated generally by one of the
HelpLines while working on a problem you reported. However, if you feel your
incident may require this cooperation up front, contact the AS/400 Technical team
of the SSA International HelpLine to initiate the process. If the SSA HelpLine has
received prior calls on the same problem in BPCS, they may be able to point you
to the resolution.
The SSA HelpLine consultant can remain on the line while you contact IBM to
open a Problem Management Record (PMR) with that HelpLine. If the IBM
HelpLine contacts SSA, SSA requests that you open an SSA HelpLine incident as
well for their internal tracking purposes. The IBM HelpLine cannot open an
incident directly with the SSA HelpLine, and similarly the SSA HelpLine cannot
open a PMR directly with IBM.
In some cases, an SSA Application Team consultant may get your call first and
bring the problem to the SSA AS/400 Technical Team for further assistance. If the
SSA AS/400 Technical Team consultant feels consultation between IBM and SSA
is required to resolve your problem, they may request that you open a PMR with
the IBM HelpLine so that both HelpLines can work on your problem.
14.4.5.3 Who will deliver the fix and how do I escalate the problem?
Once the cause of the root of the problem is identified, the software vendor who
will repair the problem takes responsibility for your problem and the delivery of
any program fix.
For example, if the problem is determined to lie in the BPCS software, a BMR
may be entered at SSA, and your IBM PMR will be closed out. If the problem lies
in some part of the operating system, an APAR may be opened by IBM and your
SSA Incident will be closed out.
Generally speaking, each HelpLine tracks their call log records, including such
information as the SSA BMR or IBM APAR number used to resolve the problem,
so that future calls to either HelpLine on the same problem description can be
resolved more quickly.
If you feel your problem is not being resolved to your satisfaction, and a clear
cause has not yet been determined, follow the escalation procedures available to
you from within each companies' support structure. If the clear cause is
determined, and a fix request such as an APAR or BMR is already entered, follow
the escalation procedures for the responsible software vendor under which the
problem report or modification request was entered.

14.5 BMR change management for BPCS version 6.x
This section provides suggested methods for system administrators to manage
and test BPCS Modification Requests (BMRs) in a BPCS Version 6.x
environment. This is not the only way to manage or test BPCS BMRs. However,
the SSA HelpLine finds this method to be prudent and useful to most clients.
14.5.1 What a BMR is

It is helpful first of all to understand what a BMR actually is. When you order a
BMR from the HelpLine, if the BMR is for the AS/400 server, a program called a
BMR Explosion is run to pull the necessary objects into a library for you. You may
request a BMR made of only program objects, of AS/SET source code, or both
the source and object. If you choose both, then two separate BMR libraries are
built: one with the program objects and one with the action diagrams for AS/SET.
14.5.1.1 Source BMRs

Source BMRs are generally requested when clients have modifications to some
BPCS programs and need to retro-fit BMR changes into their own modifications.
You may also request ODW source if you have the ODW tool. In this case, PC
files will be built based on the AS/400 object report. You may request client/server
objects along with the ODW source files. The ODW files will be delivered via
e-mail or an FTP site. You can use the Application Set transfer facility in ODW to
move the source into the Windows NT repository.
In a source BMR, you may also receive CL programs beginning with ADDLI or
ADDMSG. You need to run these CL programs need with your BPCS files library
in your library list. They update your message files with new screen literals or
messages.
Source BMRs must be compiled into program objects and moved into a
configured testing environment before the fix can have an effect.
14.5.1.2 Object BMRs

Object BMRs include the program objects only, and no source code. They also
contain ADDLI or ADDMSG programs to add new messages or screen text to
your BPCS message files. Be sure to run these programs over any BPCSF library
that you want to update with the new messages. Failure to run these programs
can lead to errors in BPCS, for example, when trying to load the missing
message to your screen.
Object BMRs should be loaded into your BPCSPTF or BMR testing library to test
the fix.
14.5.1.3 Value of the last BPCS cumulative when ordering a BMR

This BMR Explosion program puts the latest code for the programs covered in the
BMR description, plus any subsequent dependent BMRs, into one library for you.
It pulls dependencies from as far back as the last BPCS cumulative release you
applied.
Often, if you order two different BMRs for the same product, you may find that
some of the same programs appear in each BMR library due to product
dependency trees that develop when fixes are completed. This is unavoidable
from a packaging perspective.

14.5.1.4 Single-level BMRs: What they are and when to use them
If you are making modifications to BPCS programs in AS/SET or ODW and
require only the latest copy of a single program for this purpose, you may request
a single-level BMR from the HelpLine. However, this will not pull in any
co-requisite fixes for other programs. It can result in program errors if you do not
account for the missing dependent code.
The HelpLine cannot be responsible for program errors resulting from missing
program dependencies. For this reason, we usually recommend that you get the
full BMR explosion, and pull the required programs you wish to modify. If you find
that you require a dependent program, it is already in the package for you.
14.5.1.5 How a BMR library differs from an IBM PTF

As a point of comparison, BMRs are different from AS/400 PTF numbers, which
represent a frozen point in code. At SSA, the BMR number is used as a reference
to pull in the programs required to obtain the particular fix that you are seeking.
Superseding fixes (changes to the same code since the BMR was completed) are
handled by simply pulling in the program code as it exists on the day of the BMR
explosion. Then, a dependency tree is built backwards to pull in all related
dependent fixes into the library. The fix library is named after the BMR number
you initially ordered, but also contains any BMRs that are pre- or co-requisite to
the BMR you ordered.
PTFs from IBM, on the other hand, are specific numbers that represent a specific
level of code for a given set of programs. If you order a PTF that has been
superseded, the superseding fix and additional co-requisite fixes may be shipped
instead of, or along with, your original request. In this case, you receive multiple
PTF numbers. With an SSA BMR, the multiple dependent fixes are delivered in
one library.
PTFs must be applied using the GO PTF process. Once they are applied, they
affect the entire system. SSA BMRs must be inserted into a configured
environment and tested with your BPCS configuration before being put into a
production environment. There are several ways to do this.
For an IBM fix, the PTF number is related specifically to a particular point in the
life of a program object when the PTF is delivered to you. For an SSA fix, the
BMR number as listed on OGS represents a particular point in the life of a
program. However, a BMR Library, once built for delivery to a customer, contains
contents that vary, depending on the date of the BMR explosion that builds the
library.
The date of the explosion is always more important than the BMR number on the
library when considering the order for loading fixes into your environment. The
delivered BMR library is a vehicle to deliver a set of dependent fixes, and should
not be construed to represent a frozen point in code. In fact, if you order several
BMRs at once from the HelpLine, they can be bundled into one library (if you
request it). This library will be named for your HelpLine incident number, rather
than any given BMR number.
14.5.2 Where to find the listing of BMRs pulled into your explosion build
Since a BMR number listed in a BMR build library does not fully describe the
library contents once the explosion program has completed, a report is included

with each BMR to describe the contents more fully. These fixes can be found by
looking at the QTXTSRC member in your BMR explosion library using the Start
PDM (STRPDM) command. Every SSA BMR built with a dependency explosion
includes this report. The report lists program object names and BMR numbers in
three sections from different relational views. You can see a list of the included
BMRs by BMR number, a list of the total program objects in the BMR library, and
a list showing each program object along with all the BMR numbers, which affect
that particular object.
14.5.2.1 QTXTSRC BMR report practical example

Consider this example. One program such as ACR500 may have changed three
times under three BMRs between the time of your cumulative and today's date.
ACR500 may be in the BMR number you ordered, or may have been in a BMR
identified as a dependency on the BMR that you ordered.
In the report, you will see ACR500 in two places. It appears on the list of all
included programs, and it is also listed separately with the three BMR numbers
that affect that ACR500 program listed immediately below the program name.
The BMR numbers appear in many places. You will see those same three BMRs
listed once by themselves in the list of total BMRs pulled in by the explosion. And,
you will find the BMR numbers listed under each object that a given BMR affects.
You will receive one ACR500 object, which contains the changes made under all
three fixes. Plus, you receive all the other objects that have code changes, which
depend on that fix.
14.5.2.2 How time can change the way a BMR number explodes
Because of BMR dependencies (co-requisites), a particular BMR number 123, if
ordered three weeks ago, may contain fewer fixes than the exact same BMR
number if ordered today. In the subsequent three weeks, several new BMRs may
have been completed that affect some of the same program objects, and which
also fix additional related programs. This would expand the dependency tree out
wider.
If someone requests the BMR123 after the three weeks time, that user would
receive more objects than the person who ordered BMR123 three weeks
previously.
This also explains why two completely different BMR numbers that affect the
same basic BPCS programs often explode out to build the exact same set of
program objects. The dependency tree builds out to identical sets of fixes. In the
QTXTSRC report, you could see that the same pre- and co-requisite BMR
numbers were identified and pulled the required objects.
14.5.2.3 The CLT platform in a BMR listing

Most of the BMR reports you see will be listed under the platform AS400. The
BMR report also lists a platform called CLT if any client PC fixes are required.
Ensure that you received a matching client fix for any server fixes you receive.
These are often delivered via e-mail or the FTP site, but can also be placed onto
CD-ROM media. They are self-extracting executable files, which automatically
load the code onto the PC. These must be applied to all PCs in the affected
environment.

Occasionally there is a fix that affects only the client PC. In this case, you receive
the PC fix alone. The client PC fixes contain a .rpt file, which also lists all PC
objects affected by the BMR. This is installed into your BPCSCS directory when
the BMR loads. Using Windows Explorer, you can compare the object dates if
there is any question as to whether one BMR supersedes another on the client
PC.
14.5.3 What to do with a BMR: Testing your software fix

This section assumes that you have already received a BMR either via the FTP
site, tape media, or CD-ROM. It also assumes that you followed the instructions
provided with your BMR to restore it onto your AS/400 server into a separate
BMR library and onto any PCs that require the fix and will be part of the test.
14.5.3.1 Compiling all source code

If you received only a source BMR, you first need to follow the BMR instructions
to load the code into AS/SET or ODW and compile it into objects. Compile all the
code, not just one or two programs. Otherwise, you will likely miss the dependent
fixes.
You can also check the source or AS/SET comments of dependent programs to
see if any changes were made since the last time a BMR was received for that
same object to determine if it needs to be recompiled. Completed BMRs are
listed in the comments section of the generated source, or in the comments
section of ADK or ODW.
14.5.3.2 Retro-fit your modifications into the BMR

If your BPCS environment is modified, you incorporated the BMR changes into
any modified code and re-compiled any of your modifications. Then, you placed
these objects back into the BMR library with the other dependent BMR objects.
You also want to keep an unchanged (vanilla) version of the BPCS fix. If there is
a problem, you can determine if the modification or base BPCS is at fault.
14.5.3.3 Keeping the entire BMR library intact when testing

Ideally, you test this BMR before placing it into your production environment. To
ensure an easy way to back off the fix if required, we recommend that, for testing
purposes, the BMR object library stay and that no programs be separated.
We recommend that you do not pick and pull objects from a BMR that you feel are
the cause of your problem. This can lead to errors, which cannot be reproduced
by HelpLine because of the partially back-leveled state of the code when this is
done. Any extra space used by duplicate objects is handled after the testing is
complete. This is described further in 14.5.6, “Moving the approved BMR to
production” on page 268.
14.5.3.4 Configuring your test environment to use the new fixes

Depending whether you are using Mixed-Mode or Full Client/Server, you have to
make several changes ensure the new code is used.

Changes that affect the entire testing environment
You need to make these changes in the order shown here:
1. Alter the INLIBL data areas in test environments to contain the new library
before any other BPCS object libraries, such as BPCSPTF (for tested and
approved fixes) and BPCSO (for base BPCS objects).
2. The INLIBL data area is found in the BPCSUSR (BPCS User) library and in
Full Client/Server. There is an additional INLIBL data area in the BPCSUSO
(User Object) library. Use the Change Date Area (CHGDTAARA) command to
change this value.
3. In BPCSUSR (and USO library in Full Client/Server), change the batch job
descriptions for the JOBDs called BPCS and ORDERPOST to include this
new library.
4. At the same time, apply the client PC fix, if any, to the testing PCs. Users
should then exit, reboot the PC, and re-enter BPCS to pick up the changes.
These changes will affect every person who signs on to that environment.
Changes that affect a subset of users in the environment

A smaller test group can be accomplished by configuring a new environment over
the same database:
1. Create a new BPCSUSR (and in Full Client/Server, a new USO library) to
address the same database (BPCSF).
2. Add this new BMR library to the front of the INLIBL data area in the new USR
(and USO libraries in Full Client/Server).
3. Update the BPCS and ORDERPOST JOBDs in the new libraries.
4. Update the BPCSMENU program in the USR (and USO library in Full
Client/Server) with the new library names. Then, recompile it.
5. Start a new ALAUNCH (DFS) daemon to a separate port number. Update the
PC workstation settings with the new USR library name and new port number.
6. Update the NWICFG file in the Full Client/Server NEWI library with the new
USO environment listing to choose for the BMR test. Only users choosing the
test environment receive the updated programs.
7. Change the PC workstation settings to the new BPCSUSR library and apply
the PC fix (if any) to the desired PCs. If the BPCSUSR library name is not
changed, the DFS applications will not get the new library list.
With this method, only users signing in with the new USR library on their PC
settings or who choose the new USO environment in Second Generation get the
updated library list containing the BMR.
Where to find details on environment configurations

Further details on creating duplicate environments can be found in the appendix
of the eBPCS 6.1.00 installation instructions for Mixed-Mode or Client/Server.
These can be downloaded from the OGS Online support Web site. If you are on
any version 6.0.x BPCS release, these instructions contain details you can use to
create extra environments.

Testing all affected applications
Testing should be done on every application affected by the fixes included in the
BMR. Which applications to test can be determined from reading the list of
objects included in the QTXTSRC report in the BMR library.
Be sure to test the applications as you use BPCS and configure them exactly as
the application is set up in the "live" environment. Often users refresh the testing
database on occasion with a copy of a recent save of some live data. Details in
the eBPCS Installation guide explain what to watch for when refreshing your
database with new data.
We recommend that you do not "pick and pull" various programs out of the BMR
library to test the applications separately. More problems can develop due to
missing dependent fixes.
14.5.3.5 Modifications to BPCS and testing BMRs

If you have your own modifications to BPCS programs, we recommend that you
display the BMR library to a print file (DSPLIB OUTPUT(*PRINT)). You can scan the
listing by hand or copy the print file into a physical file (CPYSPLF) to run a query
on the library. Look for any included BPCS programs that you have modified.
View the last BMR completed on the program in question. Compare the source to
ascertain if the fix is one you received in a prior explosion or if it is one you need
to retro-fit into your current modified program.
You should also order a source BMR for the same BMR so that the program
source is available to you.
If programs you modified are identified as being changed in the BMR, it is your
responsibility to pull those programs out. Then, you must either retrofit your
changes into the BMR source, or place the BMR changes into your source,
depending on which is easier to manage.
Once you have completed your modifications into the BMR, you can place your
modified programs back into the BMR library.
We still recommend that you test the group of programs together with your
modifications. There may be dependencies in other areas where your
modifications have no effect.
To find all the lines changed in a given BMR, you can scan the source comments
for the BMR number. Lines that are deleted and added by SSA programmers are
always marked by comments that include the BMR number.
The importance of keeping an unchanged (vanilla) copy of the fix

When modifications exist, it is useful to test the BMR object in its unchanged SSA
version before incorporating your modifications, depending on the extent of the
modifications.
This way, you can ensure the fix works properly to resolve the reported problem,
before your modifications are incorporated. This makes subsequent problems
easier to identify if some of your modifications cause a problem when combined
with any fix in the program code.

14.5.4 Testing multiple BMRs: Five new BMRs in two weeks
There are a few ways to approach this problem. The route you decide to take
depends on the severity of the problem and the requirement for getting it into a
production environment quickly versus any other BMR you already are testing.
14.5.4.1 Comparing objects inside the BMR libraries

If you receive several BMRs in one week, run the Display Library (DSPLIB)
command on each and check for duplicate objects. Chances are that there are
several of the same objects. In this case, if you wish, you can combine all the
BMRs into one library for a suite of thorough testing. Or, you can leave them
separated by functional areas if the duplicate objects are few. This is a business
decision that will depend on many factors such as the size of your site, the
number of users that are affected, and if one BMR fixes a severe urgent problem,
for example, but another BMR is for a minor issue with a good workaround.
14.5.4.2 Combining BMRs and testing them together

The SSA HelpLine recommends that all BMRs be combined to ensure that the
newest objects are restored over the older ones. This way, one thorough set of
tests can be done, and all fixes can be brought at once into production whenever
possible. At the largest of sites, it is best to designate only one or two people to
control the environments and the BMRs to ensure that BMRs are applied in the
proper order and are tested thoroughly.
14.5.4.3 Pitfalls of not combining BMRs when testing

The problems that can occur from leaving several BMRs containing some of the
same programs in separate BMR libraries are illustrated by the following
example:
Note
BMR numbers used here are, for example, purposes only and do not represent
actual fix numbers.
• BMR423 contains program ORD500, with a source file change date of 1/1/99.
the program was downloaded for a problem in Order processing.
• BMR416 contains ORD500, along with many PUR programs. This BMR was
exploded a week later for a problem in a Purchasing program. In the time
between the two BMR orders, a new BMR was completed for ORD500.
ORD500 now has a source file change date of 1/7/99.
Note: The source file change date can be viewed by using the Display Program
(DSPPGM) command.
A decision is made to test and keep the two BMRs separated. Your PUR testers
approve BMR416 quickly and recommend it go into production. ORD500 now has
a source file change date of 1/7/99 in your production environment.
A week later, the ORD testers decide that BMR423 (containing the older ORD500
program dated 1/1/99) is also good. They ask you to move BMR423 into
production.

Accidental back-leveling of program code
You have now back-leveled your code for ORD500. The older version of the
program (1/1/99) is now being used because BMR423 contained ORD500 from a
week prior to when BMR416 was run by HelpLine. This back-leveling of code can
cause odd errors because some dependent code is at a newer date, and some
code is at an older date. Errors caused by partially back-leveled code can be
extremely difficult to diagnose because they do not behave exactly as the first or
second BMR description, and may seem to be an entirely new problem.
Correcting the accidental back-leveling of code

To correct such a situation, you need to re-apply the fix with the newest date,
BMR416, to the production environment to overwrite the older code for ORD500
with the newer code for ORD500. You would not lose any additional fixes in
BMR423 by doing this.
If BMR423 and BMR416 were combined instead into one testing library from the
start (with the newer BMR restored over the top of the older one so that new
objects replaced older ones of the same name) and both groups tested the BMR
simultaneously, this problem would be avoided.
14.5.4.4 Importance of keeping track of BMRs at your site

Regardless of the method you choose to test your BMRs, it is important to keep
track of which BMR libraries were built first by HelpLine as you receive BMRs.
For example, if ORD700 appears in three BMRs, it may be that one of those
ORD700 programs is newer than the other two, because a BMR was passed on
ORD700 in between the days in which the three BMR explosions were run at
SSA. For this reason, when incorporating the BMRs into production, you need to
be careful to restore the libraries over each other in the order of oldest to newest
by date. The newest version of any duplicate program must always stays on top.
Using the source file change date to compare program objects

A more manual method to move BMR objects around involves comparing the
Source file change date/time of the program objects that are duplicated. Then,
retain only the newest version of each object.
Do not use the Creation Date parameter to compare the newness of the program
objects! The Source file change date is more important. This date can be viewed
by using Programming Development Manager (PDM) or the DSPPGM command.
This parameter shows the date the source file was last changed for that program.
Using this method, you can manually remove duplicate older programs so that
only the most recent program remained.
For ILE RPG programs, press Enter several times on the DSPPGM screen
(Figure 132 on page 268) to see the program modules. Select option 5 to view the
source change date/time on each module.

Display Program Information
Program . . . . . . : ORD701B Library . . . . . . : VER60RLO04

Owner . . . . . . . : SSA
Program attribute . : RPG
Program creation information:

Program creation date/time . . . . . . . . : 10/05/99 11:51:22
Type of program . . . . . . . . . . . . . : OPM
Source file . . . . . . . . . . . . . . . : QRPGSRC
Library . . . . . . . . . . . . . . . . : V604BPCSWK
Source member . . . . . . . . . . . . . . . : ORD701B
Source file change date/time . . . . . . . : 09/09/99 11:48:36
Observable information . . . . . . . . . . : *ALL
User profile . . . . . . . . . . . . . . . : *USER
Use adopted authority . . . . . . . . . . . : *YES
Fix decimal data . . . . . . . . . . . . . : *NO
Text description . . . . . . . . . . . . . : ORD701B-Order Posting Batch
More...
Figure 132. Display Program Information (DSPPGM)
14.5.5 What to do if problems still exist after a BMR is applied

A programmer can only modify current versions of programs, and cannot work
backwards on a fix. For this reason, we recommend that you always go forward
and stay current with fixes. SSA tests fixes when they are completed, but
occasionally a BMR will not perform as expected because of an unaccountable
difference between the SSA testing environment and your environment. In such a
case, we will work with you to correct any remaining problems as quickly as
possible.
If the current problem is not severe, we recommend that you apply the changes
and proceed with reporting the remaining problem to the SSA HelpLine. Follow
the procedures (listed in this chapter) to apply the BMR to your environment.
If the current problem is severe, contact the SSA HelpLine and report the
problem. In this case, avoid applying the fix to your environment, or remove a
prior fix until an additional BMR is completed to correct the entire problem.
14.5.6 Moving the approved BMR to production

Once testing is complete, you can move an approved BMR into the production
environment. Follow these steps:
1. Back up your environment libraries, in case a problem should arise in this
procedure. You need to go back to a known good point.
2. Ask users in BPCS to temporarily exit the environment. Ensure that all batch
jobs using programs you will be moving into production have finished running.
3. Identify or create a save file containing the tested BMR library.
a. Find the original tape media or CD-ROM or FTP BMR save file that was
restored to your system (if you are dealing with only a single BMR) when
you first loaded the BMR.

b. If the save file has since been deleted, you have combined several BMRs
into one testing library, or you have placed modifications into the testing
library, you can create a new SAVF to restore from.
i. Create an empty save file called something such as BMRSAV. Use the
following command:
CRTSAVF FILE(QGPL/BMRSAV)
ii. Run this command:
SAVLIB (TESTBMRxxx) DEV(*SAVF) SAVF(QGPL/BMRSAV)
This saves the existing BMR test library (TESTBMRxxx) into the new
save file. When running the RSTLIB command that follows, use the new
save file name (BMRSAV).
4. Restore the test BMR library from the SAVF into BPCSPTF or the library you
use in your environment for holding approved BMRs. In the following example,
there is an original save file, which was restored from media, in QGPL. In this
example, the save file is called C64456789R. It contains the BMR that was
tested and approved.
Press F4 on the RSTLIB display. Then, press F10 and F9 to bring up all
parameters. Change MBROPT to *ALL and ALWOBJDIF to *ALL. Change the
RSTLIB parameter to the name of your fix library (BPCSPTF) in your
production environment. This ensures that older objects of the same name are
overwritten by the newer code.
Restore Library (RSTLIB)
Saved library . . . . . . . . . SAVLIB > C64456789R

Device . . . . . . . . . . . . . DEV > *SAVF
+ for more values
Save file . . . . . . . . . . . SAVF > C64456789R
Library . . . . . . . . . . . > QGPL
Data base member option . . . . MBROPT > *ALL

Allow object differences . . . . ALWOBJDIF > *ALL
Restore to library . . . . . . . RSTLIB > BPCSPTF
Figure 133. Restore Library
14.5.6.1 Advantages of using the RSTLIB method to move BMRs

The RSTLIB command is easy to use to move BMRs because you do not have to
copy individual objects. Every duplicate program is automatically overwritten with
the newer object level.
This does not require manual analysis, but does require that you are certain that
the objects in the BMR library are indeed newer than anything previously applied
to the BPCSPTF library. Keeping good track of BMR libraries received and
following organized testing practices ensures the integrity of your BPCS objects
libraries.

If this process is followed, the library lists and JOBDs in the production
environment will not need to be altered. Then, the change will take place upon
next execution of any changed programs.
Whenever dealing with a production environment, ensure that you have a good
backup of your environment before the restore is done. This is especially helpful
in case an unforeseen problem arises and you need to go back to the old setup.

Chapter 15. Tips and techniques
The information covered in this chapter is valid and relevant for eBPCS
implementations. The following topics are addressed:
• Configuring Mixed-Mode and Second Generation Client/Server eBPCS
environments to share the same database
• BPCS Client installation and management
• eBPCS and journaling
15.1 Same database for Mixed-Mode and Second Generation Client/Server

In this section, we show you the process for configuring Mixed-Mode and Second
Generation Client/Server eBPCS environments to share the same database.
15.1.1 Preliminary requirements

This configuration requires that both BPCS Mixed Mode and Client/Server have
been installed at the same version and release. If not, the procedure outlined in
this document will not work properly. There are database variations between
different versions of BPCS that prevent them from successfully functioning
together.
It is also necessary that the Mixed-Mode and Client/Server environments be at

the same cumulative and BMR levels so that the same versions of programs are
running in each object library and producing identical results. If not, it would be
possible for the same program to behave differently between the environments.
Some BPCS cumulative also contain database changes. Such changes may
cause program errors if the program objects accessing the database are not
expecting the same fields or field lengths that the BPCSF library contains.
A further consequence of linking Mixed Mode and Client/Server is that any future
BMR explosion requests have to be made for both Mixed Mode and Client/Server.
The BMRs need to be applied to both environments at the same time once BMR
testing is completed. Both versions of the program fix must be explicitly
requested from the SSA International HelpLine every time you order a new BMR.
All people in the organization who order BMRs from SSA must be made aware of
this important maintenance consideration so that BMRs are properly requested
and delivered.
You should know and understand the configuration of your current BPCS
environment and the newly installed release of BPCS before you update any data
areas or job descriptions. If you do not understand your current configuration and
library list, we recommend that you retain SSA Professional Services to perform
these tasks. Failure to properly execute these instructions can result in the
inability to access a given BPCS environment.
These instructions are written with the default installed configuration of BPCS in
mind, without any modifications to BPCS or the BPCS menu structure. You may
have modified or changed the way you access BPCS in your environment or have
modified SYS500B or BPCSMENU programs. In such a case, you should
understand these alterations and adjust these instructions accordingly to fit your
environment. You are responsible for testing and understanding your own

modifications before implementing this arrangement into a production
environment.
Second generation GUI applications will receive such errors in the client PC
software panels as Out of Sequence Error from Newi if severe modifications were
made to the BPCS priming data security files, such as BPCS Security Objects or
if any of the default BPCS menus were added or re-arranged. Customized
green-screen menus are the largest cause of this error.
If you want to retain the menu modifications you made for green-screen users, we
recommend that you copy this subset of security files into the BPCSUSR library
which is used to access the green screen environment. you must also retain the
unchanged (vanilla) priming data that shipped with BPCS for security objects in
the BPCSF library so that second generation OMS applications do not use the
modified files. These files are listed in the BPCS priming data tables for your
release of BPCS. The files and tables are available on the OGS Web site at:
http://ogs.ssax.com or from the SSA International Helpline.
Back up your existing BPCS environment to tape or to a save file by using a

series of SAVLIB commands so that you can return to an original configuration if
there are any problems after configuring the new environments.
The BPCS environment containing the libraries being updated should be in a

"quiet" state. No users should be logged into BPCS in that environment, all batch
jobs should have finished processing, and any BPCS daemon jobs to allow
access to that environment should have been ended. This prevents errors with
jobs getting an incorrect library list during the update process.
You should have access to a user profile with *ALLOBJ authority so that updates
to the BPCS data areas and job descriptions can be made.
You can load and use the client PC software for Full Client/Server BPCS to
access either environment, since this contains all the software needed to access
either a Mixed-Mode or a Client/Server BPCS configuration. The Mixed-Mode PC
software contains a subset of the client software, which does not have the ability
to connect to the OMS applications on the server. You should un-install any
Mixed-Mode PC software, and replace it with the Full Client/Server version, for
any users who need to access the OMS GUI applications.
15.1.1.1 Overview of the steps to be performed

These steps are explained in greater detail in the sections that follow:
1. Determine which files library you will retain, either the Mixed-Mode or
Client/Server database.
2. Update information in the required user libraries for all environments that will
point to this database.
3. Update the ALAUNCH daemon job scheduled entry (or whatever is used to
auto-start the daemon jobs) and TCPIPJOBD so that INLLIBL contains new
BPCS database if necessary.
4. Discard one of the redundant DFS (First Generation BPCS)-associated user
libraries.
5. Discard the Mixed-Mode BPCSUSR library if APPC is not used.
6. Check your subsystem configurations.

7. Update or install any new client PC software
8. Test the new combined environment via access from each green screen, first
generation GUI and second generation GUI. Ensure that the correct database
is being used.
15.1.2 Linking the environments to one database

Choose the database you will retain (BPCSF). The Mixed Mode and Client/Server
installations will each create a BPCS database (one for the Mixed Mode
installation and one for the Client/Server installation). If this is a completely new
installation, decide which one will be used for the linked environment. If you have
already been in production or advanced testing using BPCS on either
Mixed-Mode or Client/Server, choose the database files library that contains the
most current data.
If you need to combine two production databases (which each contain valid
application data) into one database, this is beyond the scope of this document. In
such a case, we strongly recommend that you retain SSA Professional Services.
The solution to this problem will vary greatly from customer to customer
depending on the factors in the set up of your business and which applications in
BPCS are being used. The solution will also depend on system wide parameter
settings on your BPCS applications (business rules).
15.1.2.1 Updating the data areas and job descriptions

Using the chosen BPCS database name, review and update the Client/Server or
Mixed-Mode user libraries that you retain. Replace the BPCS database name in
the following data areas and job descriptions. You have to update at least one
user library. Follow either option, depending on your configuration.
• If you have chosen to retain a BPCSF database which was originally used in a
Mixed-Mode BPCS installation, follow these steps:
1. Update the Client/Server environment library BPCSUSO.
2. You can potentially delete (see the note following Figure 135 on page 274)
the BPCSUSR library in both Mixed Mode and Client/Server and also the
BPCSTCP library in Client/Server.
3. Update the SSASYS2 data area in the BPCSF library in position 28 to point
to BPCSUST (or any user library that has an INLIBL data area describing
an environment containing a Mixed-Mode library list). See Figure 134.
Data area . . . . . . . : SSASYS2

Library . . . . . . . : V61SYSTSTF
Type . . . . . . . . . : *CHAR
Length . . . . . . . . : 1024
Text . . . . . . . . . : BPCS System Control Data Area - Part 2
Value
Offset *...+....1....+....2....+....3....+....4....+....5
0 'BPCS BPCSUST AS0'
50 '6.01.00V60BPCS V060100N '
100 ' '
Figure 134. Mixed-Mode data area
Tips and techniques 273

4. Retain the BPCSUST from Mixed Mode to build library lists for both DFS
(via TCP/IP) and green-screen BPCS applications.
A library named BPCSUSR (by default) is delivered with Mixed Mode and
Client/Server BPCS. The BPCSUSR delivered in Mixed Mode was originally
designed for APPC communications with DFS. In most cases, this library can
be deleted. APPC access is slower, so this protocol is not recommended.
However it may be a necessity in some networks to retain this library for at
least some subset of users.
If you need to retain this library, you do not have to modify the library. This
Mixed-Mode library can then also be used to access green-screen
applications and keep any modified green-screen files for custom BPCS
menus. If some users also want to get to DFS applications via TCP/IP, you
need to retain the BPCSUST library as well.
• If you have chosen to retain a BPCSF database originally used for a
Client/Server BPCS installation, follow these steps:
1. Update the Mixed-Mode environment library BPCSUST. This library
arranges the library list to access the same DFS applications as does your
BPCSUSR library in Client/Server BPCS does. SSA recommends that you
keep the BPCSUST library and remove the BPCSUSR library from both the
Mixed-Mode and Client/Server installation environments (see the note
following Figure 135 for information on the Mixed-Mode BPCSUSR library).
2. Update the SSASYS2 data area in the BPCSF library in position 28 to point
to BPCSUST (or any user library that has an INLIBL data area describing
an environment containing a Mixed-Mode library list). See Figure 135.
Data area . . . . . . . : SSASYS2

Library . . . . . . . : V61SYSTSTF
Type . . . . . . . . . : *CHAR
Length . . . . . . . . : 1024
Text . . . . . . . . . : BPCS System Control Data Area - Part 2
Value
Offset *...+....1....+....2....+....3....+....4....+....5
0 'BPCS BPCSUST AS0'
50 '6.01.00V60BPCS V060100N '
100 ' '
Figure 135. Client/Server data area
3. You can potentially delete (see the following note) the BPCSUSR library in
both Mixed Mode and Client/Server and also the BPCSTCP library in
Client/Server.
4. Retain the BPCSUST from Mixed Mode to build library lists for both DFS
(via TCP/IP) and green-screen BPCS applications.

Note
A BPCSUSR library is also delivered with Mixed-Mode BPCS and was
originally designed for APPC communications with DFS. This library can be
deleted, unless you wish to retain it to maintain APPC communications to DFS.
APPC access is slower, so this is not recommended.
However, it may be a necessity in some networks to retain this library. If you

need to retain this library, you need to update this library as follows. This library
can also be used to access green-screen files, and keep modified green
screen files for custom BPCS menus, etc.
15.1.2.2 What to alter inside the user libraries

Inside the user libraries you will be keeping, make the following alterations:
• Update the INLIBL data area by replacing the old database library (BPCSF)
name with the one you have chosen to keep and share. Use the Change Data
Area (CHGDTAARA) command to complete this task in each library you need to
change.
• Ensure that any user libraries that will be used to point to DFS applications or
green-screen applications have INLIBL data areas and JOBDs with the
BPCSMMO and BPCSMMPTF listed as the object libraries. For green-screen
applications, this is especially important since the client/server objects cannot
be used to create a green-screen display file. Plus, errors can result in your
applications.
• Update the BPCS, ORDERPOST, etc. job descriptions in the user libraries by
replacing the old database library name in the Initial Library List (INLLIBL)
parameter with the one you chose to keep and share. To find all job
descriptions in any given user library, run the command:
WRKJOBD (libname/*ALL)
Here, libname is the name of the user library you are updating. Use option 2
from this screen to update the job description. Press F10 to show all the
parameters.
15.1.2.3 Library list for each installation of BPCS

When you are done, you have the following user libraries at a minimum to access
the BPCS database from either Mixed-Mode or Client/Server applications on a
GUI or green screen. With these libraries and TCP/IP, you can access BPCS
applications from GUI or green screen.
• BPCSUSR or BPCSUST with a library list reflecting the BPCSMMO and
BPCSMMPTF libraries. Either configuration will work, but the differences are
listed here with a print screen of the INLIBL data area that would exist in each.
– The BPCSUST is delivered in MM BPCS (Figure 136 on page 276). This
library can be used to build the library list for green-screen applications by
calling BPCSMENU and to build the library list for DFS applications in GUI
by putting this library in the Workstation Settings User Library parameter in
your BPCS PC Session Manager software. In general, we recommend that
the BPCSUST be used to access DFS and the Mixed-Mode green screen.
This library also contains the TCP/IP communications objects, such as the
ALAUNCH program, used in DFS TCP/IP communications.

Data area . . . . . . . : INLIBL
Library . . . . . . . : BPCSUST
Type . . . . . . . . . : *CHAR
Length . . . . . . . . : 396
Text . . . . . . . . . : Initial Library List for BPCSMENU
Value
Offset *...+....1....+....2....+....3....+....4....+....5
0 'BPCSUSF BPCSUST BPCSF BPCSMMPTF BPCSMMO '
50 ' '
Figure 136. INLIBL data area - Mixed Mode (1)
– The BPCSUSR library is delivered in Client/Server BPCS (Figure 137).

This library can be used similarly to the BPCSUST library. However, an
additional library containing TCP/IP communications objects such as
ALAUNCH, called the BPCSTCP library, are also required on the system.
They should be listed first in the INLIBL data area in the BPCSUSR library.
In Mixed-Mode BPCS, these two libraries are combined into the single
BPCSUST library. Since this library structure is delivered with Client/Server
BPCS, you have to alter the data areas in this library to also point to the
BPCSMMO and BPCSMMPTF libraries instead of the BPCSCSO and
BPCSCSPTF libraries.

Library . . . . . . . : BPCSUSR
Type . . . . . . . . . : *CHAR
Length . . . . . . . . : 396
Value
Offset *...+....1....+....2....+....3....+....4....+....5
0 'BPCSUSF BPCSTCP BPCSUSR BPCSF BPCSMMPTF BPCSMMO '
50 ' '
Figure 137. INLIBL data area - Mixed Mode (2)
• BPCSUSO with a library list reflecting the BPCSCSO and BPCSCSPTF

objects libraries (Figure 138). This library is used to access the OMS GUI
applications and cannot be used to access any other applications. This is also
the only library with an INLIBL data area that should make any reference to
the NEWI or DOCA libraries.

Library . . . . . . . : BPCSUSO
Type . . . . . . . . . : *CHAR
Length . . . . . . . . : 396
Value
Offset *...+....1....+....2....+....3....+....4....+....5
0 'BPCSUSRF BPCSUSO NEWI DOCA BPCSF BPCSCSPTF BPCSCSO'
50 ' '
Figure 138. INLIBL data area - Client/Server

15.1.3 Environment setup for DFS applications
DFS applications in BPCS exist in either Mixed-Mode or Client/Server
environments as GUI panels. They can only be accessed from the PC GUI
panels, and can never be accessed from a green-screen environment.
Since both Client/Server and Mixed Mode contain ways to access these
applications (via user library data areas called INLIBL), you ideally only need to
keep and maintain one of these library configurations. The exception comes
when you want both APPC and TCP/IP access to DFS GUI applications (such as
one set of users who do not have access to the TCP/IP network).
To set up the library list, the INLIBL data area is retrieved (RTVDTAARA) from the
library that is listed in the User Library parameter of the client PC software
Session Manager Workstation Settings panel. Be sure to update the client PC to
contain the correct library name.
If you are using APPC to connect to these applications, you would use your
Mixed-Mode BPCSUSR library to access the environment and need to retain this
library. Otherwise, you can configure green-screen access to use the TCP/IP
DFS setup, and remove BPCSUSR from Mixed Mode. Avoid using APPC if
possible for performance benefits of TCP/IP. Since TCP/IP is required to run OPS
(Second Generation) applications, it should also be available to access DFS for
most users.
If you are using TCP/IP to connect to the DFS applications, you can choose to
retain either the Mixed-Mode library BPCSUST (preferred) or both BPCSUSR
and BPCSTCP Client/Server libraries. These libraries contain the INLIBL data
area to set up the environment library list and have the TCP/IP communications
objects including the ALAUNCH program.
In Mixed-Mode BPCS, the TCP/IP communications programs and the INLIBL

data area and BPCSMENU program etc. generally were combined into one
library called BPCSUST. In Client/Server BPCS, the TCP/IP communications
programs were always delivered in a library called BPCSTCP. This was
referenced first in the INLIBL data area of the Client/Server BPCSUSR library to
access DFS applications. Thus, the Mixed-Mode BPCSUST and Client/Server
BPCSUSR/BPCSTCP libraries perform the same functions to get to DFS via
TCP/IP. We recommend that you eliminate BPCSUSR and BPCSTCP for the
simplicity of keeping just one library updated (BPCSUST). However, you may
choose to keep either the Mixed-Mode or Client/Server way of accessing DFS
applications.
If you have Mixed-Mode BPCS Version 6.0.02 installed, this is the release where
TCP/IP communications for DFS were first introduced via a separate installation
tape called MMTCP. In this release, the Mixed-Mode DFS user library also
contains the TCP/IP components. Usually this user library ends with UST or TCP,
but may be renamed during installation. If the ALAUNCH program and
BPCSMENU program both exist in the Mixed-Mode DFS user library, the libraries
were combined. The ALAUNCH program is used to start the TCPIP daemon for
DFS connections. If the ALAUNCH object is missing from the DFS user library,
look for a separate TCP/IP library on the system (called BPCSTCPIP on the
MMTCP installation media, but possibly renamed during installation). The
separate Mixed-Mode TCP/IP library is found only in 6.0.02 installations.

You can assume that a library on the system containing the ALAUNCH program
also contains the rest of the TCP/IP communications components unless this was
altered by someone on site. There is no business reason to alter the TCP/IP
communications library contents. If you cannot figure out which DFS libraries are
which on your system, use the WRKOBJ (*ALL/ALAUNCH) command to look for the
ALAUNCH program in all libraries on your system. If the library also contains the
BPCSMENU program, then the library is a combined TCP/IP and user library. If it
does not contain BPCSMENU, it is a library only containing the TCP/IP
communications objects.
In Client/Server BPCS, the TCP/IP communications library was always kept

separately and called BPCSTCP by default. The Client/Server BPCSUSR library
has the BPCSTCP library first in the INLIBL data area. APPC communications
were not used by Client/Server customers, since the NEWI Second Generation
applications were built only to work with TCP/IP.
You should choose to keep either the BPCSUST library from Mixed Mode and
update it with the proper information, or keep the BPCSTCP and BPCSUSR
libraries from Client/Server and update the information required in these libraries.
DFS can be accessed from any user library that does not have NEWI and DOCA
in the library list. The library list can point to either the BPCSMMO and
BPCSMMPTF or the BPCSCSO and BPCSCSPTF objects and be successful for
DFS. However, since this user library is generally also used for green screen, it is
usually best to point to the Mixed-Mode object libraries, rather than the
Client/Server object libraries. If you plan to use TCP/IP communications, the
TCP/IP communications objects must be inside the user library itself or must be
inside a library that is first in the INLIBL data area from which the library list which
is built.
If you want to access DFS from both APPC and TCP/IP (generally done for users
at locations where TCP/IP is not installed), you have to retain two DFS user
libraries. One library is with the TCP/IP communications objects in the INLIBL
data area library list (such as BPCSUSR from Mixed Mode and BPCSUST from
Mixed Mode; or BPCSUSR from Mixed Mode and BPCSUSR from Client/Server
along with BPCSTCP from Client/Server). The other library is without.
15.1.4 Environment setup for green-screen applications

For green-screen access to BPCS programs, any user library containing the
BPCSMMO and BPCSMMPTF libraries, and without NEWI and DOCA in the
INLIBL data area, can be used to access the BPCS green-screen environment.
To access the green screen, enter CALL BPCSMENU from the proper user library. This
can also be set up as a menu option for your users. The TCP/IP communications
objects are not used by a green screen, nor are the APPC DFS communications
objects. Whether these objects are in the library has no affect when accessing
green-screen BPCS menus and programs. The BPCSUST Mixed-Mode library,
the Client/Server BPCSUSR library (if the INLIBL is changed to point to
BPCSMMO and BPCSMMPTF), or the Mixed-Mode BPCSUSR library can be
used to gain access to the green-screen menus.
The same BPCS programs that you can see in the green-screen menus are the
programs accessed from the Second Generation GUI panels in Client/Server

BPCS and use the OMS communications programs in the NEWI and DOCA
libraries.
First Generation (DFS) applications can never be accessed from green screens.
In BPCS 6.1.00, these applications are CEA and OLM. In 6.0.04 and lower, this
also includes COM. However, in 6.0.04 BPCS a separate green-screen COM
program is available (which has no GUI equivalent and must be ordered
separately).
15.1.5 Environment setup for OMS applications

Second Generation (OMS) GUI panels in the client PC software can only be
accessed via the BPCSUSO library. The INLIBL data area in the BPCSUSO
library must contain the NEWI and DOCA communications libraries and the
BPCSCSO and BPCSCSPTF object libraries.
The BPCSUSO library name is never entered on the client PC Session Manager
Workstation Settings screen. Instead, the correct BPCSUSO library to use in the
CALL to BPCSMENU is listed in a configuration file in the NEWI library. See the
installation instructions for Client/Server BPCS for further details. Then, the
library qualified INLIBL data area listed in the BPCSMENU program is retrieved
and used to update the library list for the job.
15.1.6 Consideration for NLVs and DFS green-screen user libraries

If you plan to install National Language Versions (NLVs) of BPCS and want to use
more than one language for BPCS users, you need to configure and maintain
user libraries slightly differently. You can use one green-screen access library, but
must have separate DFS user libraries for each language you add. A DFS user
library needs to be duplicated for each language and a unique ALAUNCH
daemon needs to be configured for each. In green-screen access, the BPCS
Language Library Mask can be used to change the library list for languages. This
feature does not exist in the DFS applications because they require a language
version of the ASCII to EBCDIC translation tables be used in the user library.
If you are installing NLVs, you may want to consider using the Mixed-Mode
BPCSUSR library for your green-screen access library, and then use the
Language Library Mask feature to control the language that is presented to the
BPCS screens. Then, you can duplicate user libraries used for DFS (whether
they are APPC or TCP/IP) access and use those INLIBL data areas to set up the
library list for the NLV DFS configurations. The NLV DFS user library name is the
library that would be put in the PC software Session Manager Workstation
Settings parameter for the BPCS User Library name.
15.1.7 Subsystem and job queue configuration

Use the following notes when considering which subsystems, job queues, and
routing entries you may need to update when combining the two releases to run
over one database. Keep software performance in mind when making these
choices.
15.1.7.1 Mixed-Mode BPCS subsystem and job routing notes

When BPCS Mixed-Mode installs, no special subsystem is created for BPCS
jobs.

Green-screen BPCS runs under QINTER (the interactive subsystem) by default.
Batch jobs run under QBATCH by default or run under the job queue set in your
System Control Data area or Workstation Data area.
DFS applications accessed via APPC run in QCMN. This cannot be altered
unless you change the way APPC jobs are submitted on your system.
As most users do, if you decide to use TCP/IP for DFS communications, you are
directed to create a BPCSTCPIP JOBQ in QGPL. Then, you create a Routing
Entry to manipulate any existing subsystem to use this JOBQ to run the BPCS
DFS jobs running under TCP/IP. The ALAUNCH daemon job uses this job queue
name when submitting jobs.
When COM 6.0.04 is set to batch post, batch validate, or batch price orders, the
ORDERPOST job description is used to submit the job. This can be manipulated
to use any job queue that you require.
15.1.7.2 Full Client/Server BPCS subsystem and job routing notes

When BPCS Client/Server installs, it creates a BPCS default subsystem (named
whatever you choose on the install panel) and a BPCSTCPIP JOBQ and a
NEWIJOBQ in QSYS.
The installation instructions (starting at 6.1.00) recommend that you change

these JOBQ descriptions to exist in QGPL instead of the installation default of
QSYS. This way, future OS/400 system upgrades do not overwrite these
important job queues. Be sure to look for duplicate BPCSTCPIP job queues in
QSYS and eliminate any duplicates (this may happen when you install both
releases).
You can ensure all GUI BPCS jobs use the BPCS subsystem installed by
Client/Server BPCS by checking the following settings in the BPCS Client/Server
subsystem. Run the Work with Subsystem Description (WRKSBSD) command, and
choose to view the BPCS Client/Server subsystem.
Note: Make sure that the NEWIJOBQ and BPCSTCPIP job queues are listed as
Job Queue entries for the subsystem and that Max Active is set to *NOMAX
(Figure 139).
Display Job Queue Entries
Subsystem description: SUBSYSN Status: ACTIVE
Seq Job Max ---------Max by Priority----------

Nbr Queue Library Active 1 2 3 4 5 6 7 8 9
10 NEWIJOBQ QGPL *NOMAX * * * * * * * * *
20 BPCSTCPIP QGPL *NOMAX * * * * * * * * *
Figure 139. Display Job Queue Entries
Make sure a routing entry exists in the subsystem for QCMD (Figure 140 on page
281). Using option 5 to display details, the default value for Class should be a
class that runs at an interactive performance level, such as the IBM-supplied
QSYSCLS20. The value for the Pool should be a pool that is configured to the
subsystem and contains enough memory to run the user jobs for BPCS GUI
sessions. This value will vary depending on your AS/400 configuration. However,

in general, *BASE is not the recommended pool to use because it takes memory
from the OS/400 system functions.
Display Routing Entries
Subsystem description: SUBSYSN Status: ACTIVE

5=Display details
Start
Opt Seq Nbr Program Library Compare Value Pos
10 QCMD QSYS *ANY
Figure 140. Display Routing Entries
15.1.7.3 Work management in a combined environment

Once you decide which subsystem you will use to run your BPCS jobs, be sure to
check for and remove job queue entries (JOBQE) in the old subsystems such as
QBATCH or QCMN, where BPCS was previously running. Use the WRKSBSD
command to check for such entries. Then, use the Remove JOBQE (RMVJOBQE)
command to remove entries for BPCSTCPIP and NEWIJOBQ in subsystems
where you do not want BPCS jobs to run.
Be sure your system start up job (QSTRUP by default) starts your BPCS
subsystem if you want users to log into BCPS GUI sessions after an IPL or
backup completes. Also, if you changed any parameters for starting BPCS
daemons by changing the library names you are using, be sure to update any
automatic startup jobs that you configured.
If you run BPCS jobs outside of the BPCS environment, make sure any outside
job descriptions used to run your jobs contain the proper Initial Library List
(INLLIBL) with an updated BPCSF library name.
15.1.8 Updating the client PC software

Full Client/Server PC software can be used for accessing either DFS or OMS
applications. If you are installing Full Client/Server PC software on a machine
that has a Mixed-Mode version of the software, we recommend that you first
un-install the prior release of BPCS before installing the new version.
For users who never require GUI OMS applications, a Mixed-Mode version of the
client PC software can be kept and used. It uses less space on the PC than the
Full Client/Server BPCS version.
Direct users to update the Session Manager Workstation Settings screen if

required. The proper BPCS files library name and BPCS user library must be
listed. If you are installing Client/Server BPCS for the first time, refer to the BPCS
installation instructions for Client/Server when filling out the new parameters on
this screen.
The port number and service number may require an update if the daemons were
started to new port numbers.
Ensure that you restart the BPCS OMS and ALAUNCH (if used) daemons before
attempting to re-connect to BPCS with the PC software.

15.1.9 Testing the configuration
To test the configuration, follow these steps:
1. Use the CALL BPCSMENU command or the menu option you configured in your
environment to ensure that green-screen access works normally. When in
green-screen BPCS, start several applications. Then, from inside, press F21
to access a command line. Display your library list to ensure that the proper
database is listed for the BPCS data files. Submit several batch jobs, and
ensure that the batch jobs retain the proper job descriptions and library lists.
2. Sign on to CEA or OLM to test the GUI first generation connection. Ensure
that the Database Refresh that is running is loading table data from the correct
BPCSF library (this is retrieved from the library listed the PC Workstation
Settings Database parameter). Find your job on the AS/400 system (running
under ALAUNCH or in the QCMN subsystem). Use option 5 (Display the job's
library list) from the WRKACTJOB display to ensure it contains the correct
BPCSF library.
3. Sign on to Second Generation BPCS using the red PC icon. Access a
Manufacturing program or System Parameters in the Special Functions menu
or any other program that runs from the OMS daemon. Once the application is
started, find it on the AS/400 system in the WRKACTJOB display. As in step 2,
display the job's library list to be sure it has the correct BPCSF library.
4. If you run BPCS programs outside the BPCS environment, test submission of
program to ensure that it has the proper library list when it starts. Update any
outside job descriptions you use to contain the correct database library name.
15.1.10 Naming conventions used

The following naming conventions apply to 15.1, “Same database for Mixed-Mode
and Second Generation Client/Server” on page 271:
DFS Stands for Distributed Function Services. This is the
communication technology used for the first set of BPCS
applications developed as a Client/Server GUI. These applications
are delivered in Mixed-Mode BPCS and also are in Client/Server
BPCS. They use the ALAUNCH daemon to communicate between
the PC and server if they run over TCP/IP.
OMS Stands for Object Messaging Service. This is the communication
technology used for the second set of BPCS applications
developed as a Client/Server GUI. OMS only exists in Full
Client/Server BPCS. The OMS library is also known as the NEWI
library. OMS also uses the DOCA library for communications.
These applications use the NEWI daemon to communicate
between the PC and server. In Mixed-Mode BPCS, these same
applications are green screen.
BPCSUSR and BPCSUSO
Used as default names for the Full Client/Server user libraries
containing the INLIBL data areas and BPCSMENU programs.
BPCSUSR contains the INLIBL used by DFS, and BPCSUSO
contains the INLIBL used by OMS.
BPCSUSR Also refers to the Mixed-Mode user library containing the INLIBL
data area and BPCSMENU program. This library has the same
objects inside of it as does the library called BPCSUSR which is

delivered with Full Client/Server BPCS. In Mixed-Mode, this library
is used to set up the library list for APPC communications with
DFS or can be used by green-screen users to set up the library
list. If TCP/IP is used for communications, this library is
unnecessary since the BPCSUST library can be used for both.
BPCSUST Used as a default name for the Mixed-Mode user library containing
the INLIBL data area and TCP/IP connectivity programs such as
ALAUNCH. This is used to set up the library list for TCP/IP
communications to DFS and can be used by green-screen users
as well.
BPCSTCP Used as a default name for the Full Client/Server library containing
TCP/IP connectivity programs such as ALAUNCH, but does not
contain an INLIBL data area or BPCSMENU program. It is not
used to set up any library lists. This library name must first be in
the library list in when connecting to DFS. In Full Client/Server, this
is set in the INLIBL data area in the BPCSUSR library.
BPCSMMO The default name of the Mixed-Mode BPCS base object library.
BPCSCSO The default name of the Full Client/Server BPCS base object
library.
BPCSMMPTF The default name of the Mixed-Mode BPCS cumulative fix library.
BPCSCSPTF The default name of the Full Client/Server BPCS cumulative fix
library.
BPCSF The default name of the BPCS files library (database) that you are
using.
BPCSUSF The default name of the BPCS library into which you can place
modified files or programs. You may use this library actively in your
environment.
There may be additional libraries in your environment, such as SPM libraries,

BMR libraries, and modification libraries that are not mentioned in this document,
but are valid to be contained in your library list.
15.2 BPCS client installation and management

This section discusses how the AS/400 server can be used to simplify the
installation and management of the BPCS client software. This includes using the
AS/400 system as the source for the initial installation of the BPCS client and as
the source for installing fixes or updates to the BPCS client (BMRs).
This section assumes that the AS/400 system used is running OS/400 Version 4
Release 2 (V4R2) or later, since it utilizes AS/400 NetServer support, which was
first available in V4R2. AS/400 NetServer allows for windows clients (Windows
98, Windows 95, and Windows NT) to access the AS/400 as a file server directly,
without any prerequisite software on the client.
Note: Users wishing to perform the same functions with AS/400 servers that are
running an older release of OS/400, such as V3R2, V3R7, or V4R1, can adopt the
same strategy and processes by installing Client Access on each of the client
PCs.

15.2.1 AS/400 NetServer setup
The following Web-site for the AS/400 NetServer support offers a good general
source of information on setting up and managing the AS/400 NetServer. This
site should be used for how to and other information:
http://www.as400.ibm.com/netserver
AS/400 NetServer is integrated in OS/400 starting with V4R2. AS/400 NetServer

supports the Server Message Block (SMB) protocol through the use of
Transmission Control Protocol/Internet Protocol (TCP/IP) on the AS/400 system.
This communication allows clients to access directories in the AS/400 integrated
file system and use the file and print-sharing functions that are included in their
operating systems (for example, Windows Network Neighborhood) to access the
AS/400 NetServer. You can configure AS/400 NetServer properties and the
properties of AS/400 NetServer file and print shares with Operations Navigator
(which is preferred). There are examples in here of a NetServer configuration and
share configuration with AS/400 commands. However, you will find it much easier
to use Operations Navigator to perform the same tasks using the graphical user
interface.
The following section briefly describe the basic steps for setting up the AS/400
NetServer and getting it running, so that clients can connect to the AS/400
system for file serving to help with installation and management of the BPCS
client software. Users that already configured AS/400 NetServer support and
already set up the clients in their network to access the AS/400 NetServer can
skip the rest of this section.
15.2.1.1 AS/400 setup

Complete these steps to setup the AS/400 system:
1. TCP/IP support
Verify that TCP/IP support is configured on your AS/400 system. You must
have at least one external TCP/IP interface configured and active to use
AS/400 NetServer. Use the Configure TCP/IP (CFGTCP) command to check or
modify interfaces and routes, set up a host table and domain name services,
etc. Once the configuration is complete, use the Start TCP/IP (STRTCP)
command to activate the support.
2. QSERVER subsystem
The QSERVER subsystem must be started. Confirm that it is started using the
Work with Subsystems (WRKSBS) command. If the QSERVER subsystem is not
started, use the Start Subsystem (STRSBS QSERVER) command.
3. NetServer name and domain
Verify that the AS/400 NetServer server name is unique on the network and
that the AS/400 NetServer is in the same domain (work group) as the majority
of the clients accessing the AS/400 file and print services. You must have
*IOSYSCFG authority to modify any part of the AS/400 NetServer
configuration. To change the AS/400 NetServer default server and domain
name, use the following command statement:
CALL QZLSCHSN PARM(server-name domain-name 'text description' X'00000000')
Once the name is changed, add it to the Domain Name Service (DNS) or
Windows Internet Name Service (WINS) if one is used at your location.

Note: Client Access/400 and AS/400 NetServer should not use the same
name for the server. The name may be recognized by both, and the first one to
retrieve the name wins it, which leads to inconsistent results seen by the
client. We recommend that the AS/400 NetServer use a different name in the
network by using a "Q" plus the system name. For example, QAS400A would
be used for the AS/400 NetServer on an AS/400 system with the name
AS400A. If Client Access is not being used, the AS/400 NetServer name can
be the same as the system name. To display the current value of the AS/400
system name (Client Access/400 name), use the Display Network Attributes
(DSPNETA) command.
4. Guest AS/400 NetServer user profile
Guest support is needed for those AS/400 NetServer users requiring only file
and print sharing support that do not have an AS/400 user profile. If you leave
this field blank, unknown users will not have access to AS/400 resources
through AS/400 NetServer. You must have *IOSYSCFG and *SECADM
authority to modify AS/400 NetServer guest support. To modify the AS/400
NetServer guest support, use the following command statement:
CALL QZLSCHSG (guest-user-profile x'00000000')
Note
The guest user profile should have a password if it is being used for print
sharing, and must not have any special authority. AS/400 NetServer does
not automatically configure guest support. Initially, users without AS/400
user profiles are not able to access AS/400 NetServer.
5. Starting and ending AS/400 NetServer

Any configuration changes made to AS/400 NetServer, with the exception of
share and session administration, do not take effect until you stop and then
start the server. You must have *IOSYSCFG authority to use the following
commands to end and start AS/400 NetServer:
CALL QZLSENDS PARM(X'00000000')
CALL QZLSSTRS PARM('0' X'00000000')

6. Determining if AS/400 NetServer is running
Use the Work with Active Job (WRKACTJOB) command to verify that there is a
QZLSSERVER job running under the QSERVER subsystem. If the
QZLSSERVER job is not active, you must start AS/400 NetServer.
7. AS/400 NetServer connections
Using the Work with TCP/IP Network Status (NETSTAT *CNN) command, you
should see the following entries. If these connections do not exist, stop and
restart AS/400 NetServer.
* * netbios > 001:27:44 Listen
* * netbios > 000:00:01 *UDP
* * netbios > 000:00:00 *UDP
* * netbios > 000:30:57 Listen

15.2.1.2 PC setup
Follow these steps to set up the PC:
1. Windows networking support for Windows 95
Select Settings->Control Panel->Network->Configuration from the Start
button. Verify that you have Client for Microsoft Networks and TCP/IP added
and configured. Then, select the Identification tab. Verify that you have a
unique computer name on the network and a valid workgroup name
configured (preferably the same name as the AS/400 NetServer).
2. Windows networking support for Windows NT
Select Settings->Control->Panel->Network->Identification from the Start
button. Verify that you have a unique computer name on the network and a
valid workgroup name configured (preferably the same name as the AS/400
NetServer). Then, select the Protocols tab. Verify that the TCP/IP protocol
has been added and is configured properly.
3. Check TCP/IP support
Test the support by Pinging the AS/400 system from a DOS window as follows:
PING AS/400-NetServer-server-name
If the PING successfully resolves the name of the AS/400 NetServer, your
setup is complete.
Note
Use the following steps in cases when your PC client is unable to resolve
the name of the AS/400 NetServer to a valid IP address.
4. Resolving AS/400 NetServer name

Add an entry for the AS/400 NetServer to a Domain Name Server (DNS) or the
PC's local LMHOSTS. Or, set up a Windows Internet Name Server (WINS) to
resolve the AS/400 NetServer server name. The fastest solution is to add an
entry to the LMHOSTS file located in the \windows directory on a Windows 95
PC, or the \winnt\system32\drivers\etc directory on a Windows NT PC. If you
cannot find an LMHOSTS file in the specified directory, it may not have been
created yet. In such a case, you can rename the file MHOSTS.SAM in that
same directory to LMHOSTS. Add a line with the following format to the
LMHOSTS file:
TCP/IP-address AS/400-NetServer-server-name #PRE
For the TCP/IP address, you should use the TCP/IP address of the AS/400
server. This can be found by using the NETSTAT command and selecting option
1 on the AS/400 server. For example, if the name of the AS/400 NetServer is
QIBMAS400 and the TCP/IP address of the AS/400 is 9.5.10.1, you would add
the following line to the LMHOSTS file:
9.5.10.1 QIBMAS400 #PRE
5. Finding AS/400 NetServer and shared resources
AS/400 NetServer may appear in the Windows Network Neighborhood, but
this depends on your network TCP/IP configuration. Find Computer is more
likely to work in all environments. To display AS/400 NetServer shares,
double-click on AS/400 NetServer accessed through either Find Computer or

Windows Network Neighborhood. Remember that Windows Network
Neighborhood is also available through Windows Explorer, so AS/400
NetServer shares can be explored as well. Unless guest access has been
setup for AS/400 NetServer, users need a user ID and password to access
resources via NetServer. Under Windows 95, the user ID used will be the
same as the user ID used to start Windows.
15.2.2 BPCS client initial installation

To perform the initial client installation of BPCS using the AS/400 system, you
need to get a copy of the BPCS client CD-ROM to reside on the AS/400 system
and then create a share that PC clients can use in place of the CD-ROM to
perform the installation. This has the advantage of not requiring each PC client to
have a CD-ROM device, not requiring users to manage distribution of a single
CD-ROM, etc. Since an installation of the BPCS client using the AS/400 system
may cause all data transfers from the CD-ROM image to the client PC to be
performed across the network, consider the impact of this data on your network.
You may want to limit the number of users that can attach to and install from the
AS/400 server at one time or otherwise limit the impact.
The first step is to decide on a location for storing the copy of the BPCS client
CD-ROM image on your AS/400 system. We recommend that you store the
CD-ROM image in a directory within the AS/400 integrated file system (IFS). The
AS/400 IFS is similar to the directory structure found on PC and UNIX machines,
which have a hierarchical file system with a root ("/") as the top of the structure.
Such commands as create directory (crtdir), copy (cpy), remove dir (rmvdir), and
delete (del) allow you to work with the structure and objects stored in the IFS. A
possible strategy for managing the BPCS client CD-ROM image would be to
create a root directory called BPCS. Then, have subdirectories for each BPCS
client CD-ROM version to which you need to provide access. The following
examples use this approach. These examples can perform the setup on the
AS/400 system using AS/400 commands. However, you can perform the same
process through a client PC with Windows Explorer if it is attached to the AS/400
IFS through a share.
15.2.2.1 CD-ROM image setup on the AS/400 system

Complete these steps to set up a CD-ROM image on the AS/400 system:
1. Create the necessary directory within the AS/400 IFS. In our example, we will
set up a directory structure to allow both the BPCS 6.0.04 Full Client/Server
CD-ROM image and the eBPCS 6.1 Full Client/Server CD-ROM image to be
stored on the AS/400 system for users to access. The main directory is named
BPCS. The two subdirectories are created with the names V604CSCD and
V610CSCD.
CRTDIR DIR('/BPCS') DTAAUT(*RX) OBJAUT(*NONE)
CRTDIR DIR('/BPCS/V604CSCD') DTAAUT(*RX) OBJAUT(*NONE)
CRTDIR DIR('/BPCS/V610CSCD') DTAAUT(*RX) OBJAUT(*NONE)
2. Copy the CD-ROM images into the AS/400 IFS. Start by placing the BPCS
client CD-ROM in the AS/400 CD-ROM drive. You can use the command
wrklnk /qopt to see the layout of the files and directories on the CD-ROM if
necessary. You need to determine which files and subdirectories on the
CD-ROM are necessary for client installations. The following example copies
all files on the CD-ROM. Note that part of the path for the CD-ROM on the

copy statement uses the volume name of the CD-ROM (64FEBCS, in the
example).
CPY OBJ('/qopt/64FEBCS/*') TODIR('/BPCS/V604CSCD')
CPY OBJ('/qopt/V61CLNTCS/*') TODIR('/BPCS/V610CSCD')
3. Define an AS/400 NetServer share. For users to access the CD-ROM images
that have now been copied to the IFS, an AS/400 NetServer share needs to be
defined. The share basically provides a name that clients use to attach to the
AS/400 system. The share points to the directory containing the data you want
them to access. In this case, we define one share named BPCSCD, which
points to the /BPCS directory and allows them to access either of the two
CD-ROM images. You could also define two shares and point each to the
specific CD-ROM image:
CALL QZLSADFS PARM(BPCSCD '/BPCS' x'00000005' x'00000000'
'BPCS Client CD-ROM Share' x'00000001' x'ffffffff' x'00000000')
The parameters on the call have the following meanings:
• BPCSCD — Share name
• '/BPCS' — Path name for the directory to which the share maps
• x'00000005' — Length of the path name in parameter two
• x'00000000' — CCSID encoding of path name (0 indicates same as job)
• 'BPCS Client CD-ROM Share' — Text description for the share
• x'00000001' — Permissions (2 indicates read-write; 1 indicates read-only)
• x'ffffffff' — Maximum number of users (-1 indicates no max)
• x'00000000' — Used in place of error code structure
15.2.2.2 Installing BPCS on the PC client

Complete these steps to install BPCS on the client PC:
1. Map a network drive to the BPCS CD-ROM share. On the client PC, you now
want to map a network drive to the new share. You can do this by right-clicking
on Network Neighborhood and selecting Map Network Drive. Select a free
drive letter. For the path, enter:
\\AS400-NetServer-Name\share-name
2. Here, AS400-NetServer-Name is the name of the AS/400 NetServer (QIBMAS400
in our earlier example) and share-name is the name of the share you added
for the location of the CD-ROM images (BPCSCD in our earlier example). You
may be prompted to enter a password. Then, you should see a window
showing the directories for the newly mapped network drive.
3. Start the BPCS client installation. You can now navigate on the network drive
to find the CD-ROM image you want to use for the installation. Double-click on
the setup.exe icon, which starts the installation. From this point on, the
installation proceeds just like you are using a CD-ROM on the PC. Once the
installation completes, you can disconnect the network drive. This frees up
your connection to the share in case the number of users has been limited.
15.2.3 BPCS client fix installation and management

To automate the distribution of fixes for the BPCS client to individual PCs using
the AS/400 system, you use some of the same concepts as used when doing the
initial client installation off the AS/400 system. Namely, you need to define a
process for storing the client fixes on the AS/400 system, create a share that PC
clients can use to access the fixes, and finally define and create a strategy for

automating the installation in some way. Distributing and managing BPCS client
fixes this way has the advantage of not requiring each PC to pass around or
manage the fixes on some other media. Much like you considered the impact to
your network for installing BPCS client initially from the AS/400 server, do the
same for installing fixes. You may want to limit the number of users that can
attach to and install from the AS/400 server at one time or otherwise limit the
impact.
The first step is to decide on a location and directory structure for storing the
BPCS client fixes on the AS/400 system. We recommend that you use the
AS/400 integrated file system (IFS) for storing these files. The directory structure
should define different directories for different versions of the BPCS client. The
approach we are going to use creates a master IFS directory named BPCSFix.
Then, we will have subdirectories for each version of the BPCS client that needs
to be supported. The following examples perform the setup on the AS/400 system
using AS/400 commands. You can perform the same process through a client PC
with Windows Explorer if it is attached to the AS/400 IFS through a share.
15.2.3.1 BPCS client fix setup on the AS/400 system

Complete the following steps:
1. Create the necessary directory within the AS/400 IFS. In our example, we set
up a directory structure to allow fixes for both the BPCS 6.0.04 Full
Client/Server client and the eBPCS 6.1 Full Client/Server client to be stored
on the AS/400 system for users to access fixes. The main directory is named
BPCSFix. The two subdirectories are created with the names V604CSFix and
V610CSFix.
CRTDIR DIR('/BPCSFix') DTAAUT(*RX) OBJAUT(*NONE)
CRTDIR DIR('/BPCSFix/V604CSFix') DTAAUT(*RX) OBJAUT(*NONE)
CRTDIR DIR('/BPCSFix/V610CSFix') DTAAUT(*RX) OBJAUT(*NONE)
2. Define an AS/400 NetServer share. For users to access the client fixes that
have now been created in the IFS, an AS/400 NetServer share needs to be
defined. The share basically provides a name that clients use to attach to the
AS/400 system. The share points to the directory containing the data you want
them to access. In this case, we define one share named BPCSFix, which
points to the /BPCSFix directory and allows them to access either of the two
BPCS client fix directories. You can also define two shares and point each to
the specific BPCS client fix directory.
CALL QZLSADFS PARM(BPCSFIX '/BPCSFix' x'00000008' x'00000000'
’BPCS Client Fixes Share' x'00000001' x'ffffffff' x'00000000')
The parameters on the call have the following meaning:
• BPCSFIX — Share name
• '/BPCSFix' — Path name for the directory to which the share maps
• x'00000008' — Length of the path name in parameter two
• x'00000000' — CCSID encoding of path name (0 indicates same as job)
• 'BPCS Client Fixes Share' — Text description for the share
• x'00000001' — Permissions (2 indicates read-write; 1 indicates read-only)
• x'ffffffff' — Maximum number of users (-1 indicates no max)
• x'00000000' — Used in place of an error code structure
3. Copy the contents of the BPCS client fix (BMR) into the AS/400 IFS. The
source of the copy is up to you. If you have a CD-ROM, you can place the
CD-ROM in the AS/400 CD-ROM drive or you can copy the contents from the

PC hard file. The following example copies all files from a client PC hard drive
(D: drive) to the AS/400 system that is mapped as drive X. If you want to
further isolate each BMR you can create a directory for each, one instead of
copying all BMR files to the same directory:
copy d:\bmrx6446160r.* x:\BPCSFix\V604CSFix\*.*
dir x:\BPCSFix\V604CSFix\*.*
At this point, the fixes for the BPCS client are on the AS/400 system and can
be accessed by each client PC. A non-automated approach to installing the
fixes is to have each client simply attach to the share that contains the fixes
and install the fixes on their PC from the AS/400 network server. An e-mail or
memo can be distributed to information users of the name of the fix to install.
An automated approach can also be setup that would connect to the AS/400
system each time the PC starts. It would find the new fix on the AS/400
system and automatically download the fix to the client PC, at which time the
user could install the fix off their local hard drive. The following steps and
examples take you through each of these options.
15.2.3.2 Installation on the PC client

1. Map a network drive to the BPCS fixes share. On the client PC, map a network
drive to the new share. You can do this by right-clicking on Network
Neighborhood and selecting Map Network Drive. Select a free drive letter.
For the path, you should enter:
\\AS400-NetServer-Name\share-name
Here, AS400-NetServer-Name is the name of the AS/400 NetServer
(QIBMAS400, in our earlier example), and share-name is the name of the share
you added for the location of the BPCS client fixes (BPCSFix, in our earlier
example). You may be prompted to enter a password. You should then see a
window showing the directories for the newly mapped network drive.
2. Start the BPCS client installation. You can now navigate on the network drive
to find the BPCS client fix you want to use for the installation and double-click
on the install icon for the particular BMR that will start the installation. From
this point on the installation proceeds just like you are using a local file or
CD-ROM on the PC. Once the installation completes, you can disconnect the
network drive. This frees up your connection to the share in case the number
of users has been limited.
15.2.3.3 Transferring fixes to the PC client

1. This function uses the Client Access/400 Directory Update function. This
function of Client Access/400 is available for no charge. To use this function,
you first need to install the Client Access/400 for Windows 95/NT or Client
Access/400 Express for Windows 95/NT product on the AS/400 system and
on each client PC. For more information or assistance with installing Client
Access/400, see the Web site at: http://www.as400.ibm.com/clientaccess/
2. Create a package file on the AS/400 system in the same IFS directory that
contains the fixes (files) you want to download to each user's PC. The
package file should have an extension of .pkgf and has a format similar to this:
PKGF BPCS Client Fixes
MBRF BMRX6446160R.exe

MBRF BMRX6446160R.txt
MBRF BMRX6446160R.rpt
The first line gives a description of the package file. Each line that follows
names a particular file that you want distributed to client PCs as part of the
directory update process. In this example, the three files shipped as part of the
BMR are named. As you add additional fixes, you need to update the package
file to list the additional files to be distributed to client PCs. If you only want to
distribute the .exe files, you can also do that.
3. Setup the directory update function on the client PC by double-clicking on the
Directory Update icon in the Client Access application group window. Select
File->New to add a new directory update entry. Enter a description (for
example, BPCS Client Fixes Update). For the source path, specify the path to
the directory containing the updates (and package file) on the AS/400 system.
Using our examples, the path would be something like the following example:
\\QIBMAS400\BPCSFix\V604CSFix
For the target path, specify the path on the PC client to where you want the
fixes to be copied, for example d:\bpcsfixes. Select the option to update using
package files, and click the Details button. File the package file you created
earlier in the available list, and select it. Then, click Add to use the package
file. Select OK to close the details window. On the Option tab, select to
include subdirectories and allow older files to replace newer files. Select OK to
complete the process.
4. Check that the new directory update entry works by starting the update to test
it. The files indicated by the package file should be copied from the AS/400
system to the client PC and placed in the target directory. Once this process is
known to work, you can add the Start directory update process to your
Windows 95 or NT startup. For each boot of the PC, any new files added to
the BPCS fix directory on the AS/400 system will be transferred to the PC
during startup.
15.3 eBPCS and journaling

The following list contains some of the recommendations to improve or maximize
performance for journaling on the AS/400 system. A considerable amount of
information on how to setup and manage AS/400 journals can be found in the
OS/400 Backup and Recovery Guide, SC41-5304.
• Put journal receivers in an ASP that is not using RAID-protected disk drives.
This gives the best I/O response time for physical writes to the journal. Since
writes to journal receivers are always done directly to disk and not to main
memory, setting up a user ASP with a dedicated set of disk drives will
eliminates I/O contention with other system operations. Using mirroring on the
user ASP containing the journal receivers provides protection without
increasing the number of I/Os.
• The more jobs writing to the journal, the better they perform.
There are many optimizations that the system uses to minimize the actual
number of physical disk I/Os to the journal receiver. However, if there is only a
single job feeding entries to the journal, most of these optimizations cannot be
used. The overall number of journal I/Os and the overall response time impact
is lessened as more jobs are concurrently depositing entries to the journal. In

a simplistic explanation, entries are effectively bundled together from different
jobs to make a single write to the journal. Therefore, multi-threaded job
queues or more users actually make the journaling have less impact on the
system.
• Remove the internal journal entries.
When creating the journal, setting the parameter RCVSIZOPT to
*RMVINTENT has an effect on the number of I/Os that are required to do the
journal deposits. Indicating to remove the internal journal entries that are
generated for recovery purposes only after those entries are no longer needed
effectively causes more I/Os to be performed to accomplish the Journaling
function. The journal entries to be removed are written in a different location
from the journal entries that will remain in the journal receiver, thus, requiring
extra I/Os. However, this is a trade-off between the growth of journal receivers
versus extra I/Os. If the system is not I/O bound, this can be a good choice to
minimize the growth of journal receivers. Keep in mind, that the majority of the
internal entries generated for recovery are for access path protection. Access
path protection is either put into effect explicitly for files by using the Start
Journal Access Path (STRJRNAP) command or by the values as specified on the
Edit Recovery for Access Path (EDTRCYAP) command that specify the implicit
access path protection policies for the system.
• File Open and File Close journal entries.
Consider specifying OMTJRNE(*OPNCLO) when staring journaling for the physical
files. This does not journal the open and close entries for the files, which can
become numerous and cumbersome to look at if there is a lot of read and
query activity against the files. This is not going to greatly impact
performance. Unless the open and close entries are needed for auditing
purposes, their use is minimal in a production environment. The system does
not need them for its data recovery purposes.

Appendix A. TCP/IP basic installation and configurations
This appendix describes the installation and the process of configuring
Transmission Control Protocol/Internet Protocol (TCP/IP) on the AS/400 system.
If you want extensive knowledge about TCP/IP on the AS/400 platform, refer to
the manuals OS/400 TCP/IP Configuration and Reference , SC41-5420, and
TCP/IP Fastpath Setup, SC41-5430.
Note: You should configure TCP/IP prior to installing the SSA eBPCS
Client/Server. During the eBPCS Client/Server installation process, there are also
some additional TCP/IP configuration tasks.
A.1 TCP/IP servers and services

The TCP/IP communications protocol function is packaged with OS/400 and also
as a separate licensed program product (LPP) called AS/400 TCP/IP Connectivity
Utilities/400 (5769-TC1). Together these include:
• GUI configuration support
• BOOTP (Bootstrap Protocol)
• DHCP (Dynamic Host Configuration Protocol)
• DNS (Domain Name System)
• FTP (File Transfer Protocol)
• Anonymous FTP (File Transfer Protocol)
• HTML (Hypertext Markup Language)
• Internet Connection Server (HTTP)
• Internet Connection Secure Server (ICSS)
• NFS (Network File System)
• IP over Twinax
• LPD (Line Printer Daemon)
• LPR (Line Printer Requester)
• NETSTAT (Network Status)
• PING (Packet InterNet Groper)
• POP (Post Office Protocol) Version 3
• PPP (Point-to-Point Protocol)
• REXEC (Remote Execution)
• Remote IPL support
• RIPv2 (Routing Information Protocol)
• RouteD (Route Daemon)
• SLIP (Serial Line Internet Protocol)
• SMTP (Simple Mail Transfer Protocol)
• SNMP (Simple Network Management Protocol)
• TELNET (Teletypewriter Network)
• TFTP (Trivial File Transfer Protocol)
• 5250/HTML WSG (Workstation Gateway)
• Sockets API
A.2 Network environment

You can connect many types of networks with TCP/IP by simply configuring the
proper type of line. The AS/400 system supports different types of network
environments such as:

• Ethernet Networks
• Token-Ring Networks
• Asynchronous Transfer Mode (ATM) Networks
• Frame-relay Networks
• Wireless Networks
• X.25 (PVC and SVC)
• X.25 over ISDN
• Distributed Data Interface Networks
You must configure the proper communications line based on the hardware you
installed on the AS/400 system.
A.3 Installing TCP/IP core applications on the AS/400 system

Installing Transmission Control Protocol/Internet Protocol (TCP/IP) on your
AS/400 system allows you to connect an AS/400 system to a network.
To install TCP/IP on your AS/400 system, follow these steps:

1. Insert your installation media for TCP/IP into your AS/400 system. If your
installation media is a CD-ROM, insert it into your optical device. If your
installation media is a tape, insert it into your tape drive.
2. Type Go LICPGM on a command line and press Enter to access the Work with
Licensed Programs display (Figure 141). Type option 11 (install licensed
programs) in the command line. Press Enter on the Work with Licensed
Programs menu to see a list of licensed programs and optional parts of
licensed programs (Figure 142 on page 295).
LICPGM Work with Licensed Programs
Manual Install
1. Install all
Preparation
5. Prepare for install
Licensed Programs
10. Display installed licensed programs
11. Install licensed programs
12. Delete licensed programs
13. Save licensed programs
More...
===> 11

Figure 141. LICPGM menu
3. Type 1 in the option column (Figure 142) next to the licensed programs you
want to install from the Install Licensed Programs menu. Press Enter.

Install Licensed Programs

1=Install
Licensed Installed
Option Program Status Description
5769SV3 ADSTAR Distributed Storage Manager for AS/400
1 5769TC1 TCP/IP Connectivity Utilities for AS/400
5716VG1 VisualGen Host Services for AS/400
More...
F3=Exit F11=Display release F12=Cancel F19=Display trademarks
Figure 142. Installed License Programs
Select TCP/IP Connectivity Utilities for AS/400 (5769-TC1). The AS/400

TCP/IP functions are divided between the operating system and the TCP/IP
Connectivity Utilities for AS/400 Licensed Programs. The TCP/IP Utilities
Licensed Program is shipped with OS/400 at no additional charge, and it must
be installed separately.
Other licensed programs that you may want to install include:
• 5769-XW1 - Client Access for Windows: This provides Operations
Navigator support that is used to configure some of the TCP/IP
components, PC5250 emulation, data transfer, and printer emulation.
• 5769-SS1 option 3 - (OS/400 - Extended Base Directory Support): To
provide directory support for such functions as DHCP.
• 5769-SS1 option 31 - (OS/400 - Domain Name System): To map host
names to IP addresses.
• 5769-SS1 option 32 - (OS/400 - Directory Services): To provide LDAP
support.
• 5769-SS1 option 34 - (OS/400 - Digital Certificate Manager): If you plan
to use SSL (Secure Socket Layer) support.
• 5769-DG1 (IBM HTTP Server for AS/400): Provides an AS/400 Web
Server.
The Confirm Install of Licensed Programs display (Figure 143) shows the
licensed program you selected to install. Press Enter to confirm.
Confirm Install of Licensed Programs
Press Enter to confirm your choices for 1=Install.

Press F12 to return to change your choices.
Licensed Installed
1 5769TC1 TCP/IP Connectivity Utilities for AS/400
Bottom
F11=Display release F12=Cancel
Figure 143. Confirm Installation selection
TCP/IP basic installation and configurations 295

4. Complete the following choices on the Install Options display (Figure 144):
• Installation Device
– Type OPT01 if installing from a CD-ROM device.
– Type TAP01 if installing from a tape device.
• Objects to install
This option allows you to install both programs and language objects, only
programs, or only language objects. Type 1 for Programs and language
objects.
• Automatic IPL
This option determines if the system automatically starts when the
installation process has completed successfully. Type N for "no." Press
Enter.
Install Options
Installation device . . . OPT01 Name
Objects to install . . . . 1 1=Programs and language objects

2=Programs
3=Language objects
Automatic IPL . . . . . . N Y=Yes

N=No
F3=Exit F12=Cancel
Figure 144. Specify installation options
When TCP/IP successfully installs, either the Work with Licensed Programs
menu or the Sign On display appears.
5. An Installed Status of *COMPATIBLE on the Installed Licensed Programs menu
(Figure 145 on page 297) shows that the product is installed.
Note
After the installation of software, the most current PTF package should be
installed.


1=Install
Licensed Installed
5769SV3 ADSTAR Distributed Storage Manager for AS/400
5769TC1 *COMPATIBLE TCP/IP Connectivity Utilities for AS/400
5716VG1 VisualGen Host Services for AS/400
More...
F3=Exit F11=Display release F12=Cancel F19=Display trademarks
Figure 145. Install Licensed Programs - TCP/IP connectivity utilities
6. Select option 50 (Display log for messages) on the Work with Licensed
Programs menu (Figure 141 on page 294) to verify that you have installed the
licensed program successfully. If an error occurs, you see the message Work
with licensed program function not complete on the bottom of the Work with
Licensed Programs menu.
After the latest PTFs are installed, you are ready to configure TCP/IP on your
AS/400 system.
A.4 TCP/IP configuration using a command line interface

This section shows you how to configure a basic TCP/IP connection using a
command line interface. You need at least one workstation connected to the
AS/400 system to do this. The configuration process is complete once you
perform a PING successfully on the AS/400 system. If you need more
information, see TCP/IP Fastpath Setup, SC41-5430.
A.4.1 Scenario
Here is a simple Ethernet network to show you how to configure TCP/IP. In Figure
146, you see an Ethernet network with one AS/400 system and one personal
computer. The configuration is shown from the AS/400 system perspective.
AS/400
PC
IP Address 9.4.73.129 IP Address 9.4.73.130
Network Address: 9.4.73.128

Figure 146. Ethernet network example

A.4.1.1 Collecting the network parameters
You need to know the addresses and subnet mask of your AS/400 system, router,
and gateway. You also need your local domain name and the host name of your
AS/400 system. In this scenario, we used the following information:
• Network address: 9.4.73.128
• Subnet mask: 255.255.255.128
• Domain name: SYSNAM123.IBM.COM
• AS/400 host Internet address/name: 9.4.73.129/SYSNAMA
Note
If you are the network administrator and you never plan to attach your network
to the Internet, we suggest that you use an address such as 128.1 for your
TCP/IP network and 128.1.0.1 for your first TCP/IP host. The subnet mask
would be 255.255.0.0.
A.4.1.2 Signing on to the AS/400 system

Sign on the AS/400 system as user QSECOFR (or another user with the special
authority of *IOSYSCFG).
Note
System configuration (*IOSYSCFG) special authority gives the user the ability
to change how the system is configured. This may include, for example, adding
or removing communications configuration information, working with TCP/IP
servers, and configuring the Internet Connection Server (ICS).
A.4.1.3 Creating a line description

In this scenario, use an Ethernet line. To see other types of lines, refer to
Appendix A, "Configuring a Physical Line for TCP/IP Communications" in OS/400
TCP/IP Configuration and Reference, SC41-5420.
You need to know the resource name and decide the line name. To do this,
perform the following steps:
1. The resource name is the AS/400 system name for the adapter card. To obtain
the resource name, enter the Work with Hardware Resources (WRKHDWRSC)
command and specify the communications resources as shown here:
WRKHDWRSC TYPE(*CMN)
When you press Enter, the display shown in Figure 147 on page 299 appears.

Work with Communication Resources

5=Work with configuration descriptions 7=Display resource detail
Opt Resource Type Status Text
CC13 2629 Operational Comm Processor

LIN20 6181 Operational LAN Adapter
CMN24 6181 Operational Ethernet Port
CMN25 6149 Operational Token-Ring Port
LIN28 2699 Operational Comm Adapter
CMN29 2699 Operational V.24 Port
CMN30 2699 Operational Comm Port
CC14 6617 Operational File Server IOP
CMN32 2723 Operational Ethernet Port
CMN33 2724 Operational Token-Ring Port
More...
F3=Exit F5=Refresh F6=Print F12=Cancel
Figure 147. Work with Communication Resources display
2. Choose the proper resource name from the display, and decide the name of
the line for the line description.
3. To create a line description, enter the Create Line Description (Ethernet)
(CRTLINETH) command.
Fill in the line name and resource name, and press Enter. The display shown
in Figure 148 on page 300 appears. In this example, the resource name is
CMN24, and the line name is LINETH01.
Note: Step 2 and step 3 can also be done in the following way:
Type option 5 (Work with configuration descriptions) in the Opt field as shown
in Figure 148 on page 300. Then, the Work with Configuration Descriptions
display appears. In this display, type option 1 (Create) in the Opt field. The
display shown in Figure 148 appears.

Create Line Desc (Ethernet) (CRTLINETH)
Line description . . . . . . . . > LINETH01 Name

Resource name . . . . . . . . . > CMN24 Name, *NWID, *NWSD
Online at IPL . . . . . . . . . *YES *YES, *NO
Vary on wait . . . . . . . . . . *NOWAIT *NOWAIT, 15-180 seconds
Local adapter address . . . . . *ADPT 020000000000-7EFFFFFFFFFF...
Exchange identifier . . . . . . *SYSGEN 05600000-056FFFFF, *SYSGEN
Ethernet standard . . . . . . . *ALL *ETHV2, *IEEE8023, *ALL
Line speed . . . . . . . . . . . 10M Character value, 10M, 100M...
Duplex . . . . . . . . . . . . . *FULL Character value, *HALF...
SSAP list:
Source service access point . *SYSGEN 02-FE, *SYSGEN
SSAP maximum frame . . . . . . *MAXFRAME, 265-1496, 265...
SSAP type . . . . . . . . . . *CALC, *NONSNA, *SNA, *HPR
+ for more values
Text 'description' . . . . . . . *BLANK
More...
F24=More keys
Figure 148. Create Line Description (Ethernet) display
Ensure that the modes and line speed for the Ethernet line are matched correctly,
for example, if a switch is set to full duplex, and the AS/400 system is set to full
duplex.
A.4.2 Creating a TCP/IP interface

You need the IP and subnet mask addresses to create a TCP/IP interface.
Perform the following steps:
1. Go to the CFGTCP menu, and choose option 1 (Work with TCP/IP Interfaces).
The display shown in Figure 149 appears.


127.0.0.1 255.0.0.0 *LOOPBACK *NONE
More...
F3=Exit F5=Refresh F6=Print list F10=Work with IP over SNA interfaces
F11=Display interface status F12=Cancel F17=Top F18=Bottom
Figure 149. CFGTCP menu display - Work with TCP/IP Interfaces
2. Select option 1 (Add) to add a TCP/IP interface to the table, and press Enter.
The display shown in Figure 150 on page 301 appears.

Add TCP/IP Interface (ADDTCPIFC)
Internet address . . . . . . . . > '9.4.73.129'

Line description . . . . . . . . lineth01 Name, *LOOPBACK
Subnet mask . . . . . . . . . . 255.255.255.128
Associated local interface . . . *NONE
Type of service . . . . . . . . *NORMAL *MINDELAY, *MAXTHRPUT...
Maximum transmission unit . . . *LIND 576-16388, *LIND
Autostart . . . . . . . . . . . *YES *YES, *NO
PVC logical channel identifier 001-FFF
+ for more values
X.25 idle circuit timeout . . . 60 1-600
X.25 maximum virtual circuits . 64 0-64
X.25 DDN interface . . . . . . . *NO *YES, *NO
TRLAN bit sequencing . . . . . . *MSB *MSB, *LSB
Bottom
F24=More keys
Figure 150. Add TCP/IP Interface (ADDTCPIFC) display
3. Type in the Internet address, line description, and subnet mask. After pressing
Enter, the Work with TCP/IP Interface display appears as shown in Figure 151.
Note the message at the bottom that states TCP/IP interface was added
successfully.
Type options, press Enter


9.47.73.129 255.255.255.128 LINETH01 *ELAN

127.0.0.1 255.0.0.0 *LOOPBACK *NONE
More...
F3=Exit F5=Refresh F6=Print list F10=Work with IP over SNA interfaces
F11=Display interface status F12=Cancel F17=Top F18=Bottom
TCP/IP interface added successfully.
Figure 151. CFGTCP menu display - Work with TCP/IP Interfaces
A.4.3 Creating a TCP/IP host table entry

A host table entry allows you to associate a host name (for example, SYSNAMA)
to an Internet address (for example, 9.47.73.129). To do this, perform the
following tasks:
1. Select option 10 (Work with TCP/IP host table entries) on the CFGTCP menu,
and press Enter. The display shown in Figure 152 on page 302 appears.


Internet Host
Opt Address Name
127.0.0.1 LOOPBACK
Bottom
F3=Exit F5=Refresh F6=Print list F12=Cancel F17=Position to
Figure 152. CFGTCP menu display - Work with TCP/IP Host Table Entries
2. Select option 1 (Add) to add one entry to the table. The Add a TCP/IP Host
table entry display should appear. This is shown in Figure 153.
Add TCP/IP Host Table Entry (ADDTCPHTE)
Internet address . . . . . . . . > 9.4.7.129

Host names:
Name . . . . . . . . . . . . . > SYSNAMA
Name . . . . . . . . . . . . . > SYSNAMA.SYSNAM123.IBM.COM

Text 'description' . . . . . . . 'Entry for AS/400 (SYSNAMA) '
Bottom
F24=More keys
Figure 153. Add TCP/IP Host Table Entry (ADDTCPHTE) display
3. This display provides fields for the Internet address, associated host name,
and an optional text description. Type in the values. After pressing Enter, the
Work with TCP/IP Host Table Entries appears as shown in Figure 154.

Internet Host
Opt Address Name
9.4.73.129 SYSNAMA
SYSNAMA.SYSNAM123.IBM.COM
127.0.0.1 LOOPBACK
F3=Exit F5=Refresh F6=Print list F12=Cancel F17=Position to
Figure 154. CFGTCP menu display - Work with TCP/IP Host Table Entries
For the information on how to configure a TCP/IP route, refer to A.6.2, “Route
configuration” on page 331.

A.4.4 Configuring a local domain and host name
The local host and domain name are used to identify the AS/400 system within
the TCP/IP domain in which it is located. POP and SMTP mail servers require
that the local host and domain name be configured.
To define the local host and domain name for AS/400 machine, select option 12
(Change TCP/IP domain information) from the CFGTCP menu. The display
shown in Figure 155 appears.
Change TCP/IP Domain (CHGTCPDMN)
Host name . . . . . . . . . . . 'SYSNAMA'
Domain name . . . . . . . . . . 'SYSNAM123.IBM.COM'
Host name search priority . . . *LOCAL *REMOTE, *LOCAL, *SAME

Internet address . . . '9.4.73.129'
Port . . . . . . . . . . . . . . 53 1-65535, *SAME

Protocol . . . . . . . . . . . . *UDP *UDP, *TCP, *SAME
More...
Figure 155. Change TCP/IP Domain (CHGTCPDMN) display
In this example, 9.4.73.129 is the IP address of DNS server.
For more information about the local host name and domain name, see AS/400
TCP/IP Configuration and Reference, SC41-5420.
A.4.5 Starting TCP/IP

Before any TCP/IP services are available, TCP/IP processing must be initialized
and activated. Complete these steps to start TCP/IP:
1. Select option 3 (Start TCP/IP) from the TCP/IP Administration menu using the
command:
GO TCPADM
You can also choose to enter the Start TCP (STRTCP) command. Both
commands initialize and activate TCP/IP processing. They also start the
TCP/IP interface control job, which starts all interfaces with an AUTOSTART
value set to *YES. It starts the TCP/IP server jobs.
2. Allow a few moments for TCP/IP to start. Then, enter the command:
WRKACTJOB SBS(QSYSWRK) JOB(QT*)
The job QTCPIP should appear as shown in Figure 156 on page 304. After
this job is started, you can proceed with TCP/IP connection verification.

Work with Active Jobs
CPU %: 2.2 Elapsed time: 00:01:21 Active jobs: 219

2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...
QTCPIP QTCP BCH .0 DEQW

QTFTP01357 QTCP BCH .0 CMD-CHGJOB ICFW
QTGTELNETS QTCP BCH .0 DEQA
QTMSNMP QTCP BCH .0 PGM-QTOSMAIN DEQW
QTSMTPSRVR QTCP BCH .0 PGM-QTMSSRCP SELW
QTWSG02808 QTMTWSG BCH .0 TIMW
Bottom
Parameters or command
===>
F3=Exit F4=Prompt F5=Refresh F10=Restart statistics
F11=Display elapsed data F12=Cancel F14=Include F24=More keys
Figure 156. Work with Active Jobs display - QTCPIP job
Messages indicating that TCP/IP has been started are also sent to the QTCP and
QSYSOPR message queues. To check for the successful start of TCP/IP, enter
either of these commands:
DSPMSG QSYSOPR
DSPMSG QTCP
If the QTCPIP job does not start, look for spooled job logs. Generally, the user for
these job logs is QTCP. Use the Work with Spooled Files (WRKSPLF) command, and
specify QTCP for the user to find the logs:
WRKSPLF QTCP
A.4.6 Stopping TCP/IP

Stopping TCP/IP ends all TCP/IP processing, all active TCP/IP interfaces, and all
TCP/IP connections on the AS/400 system with which you are working. Unless
you specified ENDSVR (*NO), all TCP/IP server jobs for agents that are currently
active in the QSYSWRK subsystem are ended. There are two possible values
when stopping TCP/IP: controlled and immediately. There are two ways to stop
TCP/IP using the CL interface:
• Enter ENDTCP, and press F4 .
• Type GO TCPADM, and select option 4 (End TCP/IP).
To stop TCP/IP from the TCP/IP Administration menu, perform the following
steps:
1. Type GO TCPADM from the AS/400 Main menu. The TCP/IP Administration menu
is displayed (Figure 157 on page 305).

TCPADM TCP/IP Administration
1. Configure TCP/IP
2. Configure TCP/IP applications
3. Start TCP/IP
4. End TCP/IP
5. Start TCP/IP servers
6. End TCP/IP servers
7. Work with TCP/IP network status
8. Verify TCP/IP connection
9. Start TCP/IP FTP session
10. Start TCP/IP TELNET session
11. Send TCP/IP spooled file
20. Work with TCP/IP jobs in QSYSWRK subsystem
===> 4
F3=Exit F4=Prompt F9=Retrieve F12=Cancel

(C) COPYRIGHT IBM CORP. 1980, 1998.
Figure 157. TCP/IP Administration
2. Select option 4 (End TCP/IP), and press Enter. The End TCP/IP display is
shown (Figure 158).
End TCP/IP (ENDTCP)
How to end . . . . . . . . . . . *IMMED *IMMED, *CNTRLD
End application servers . . . . *YES *YES, *NO

Bottom
F24=More keys
Figure 158. End TCP/IP (ENDTCP)
Note: There is no confirmation display shown when ENDTCP is entered. The

ENDTCP command must be used with caution. When it is used, it ends all
TCP/IP processing on the AS/400 system on which you are working.
3. To individually stop a TCP/IP server, use the ENDTCPSVR command, and press
F4. The End TCP/IP Server display is shown in Figure 159 on page 306.

End TCP/IP Server (ENDTCPSVR)
Server application . . . . . . . *ALL *ALL, *SNMP, *ROUTED...

+ for more values
Bottom
F24=More keys
Figure 159. End TCP/IP Server (ENDTCPSVR) display
A.4.7 Verifying the TCP/IP connection

Use the PING command to verify the TCP/IP configuration. Perform the following
steps:
1. To test the TCP/IP code without sending anything out of the Ethernet adapter,
specify the special host name LOOPBACK:
PING LOOPBACK
The display shown in Figure 160 should appear.
Command Entry
Request level: 7
Previous commands and messages:
> ping loopback
Verifying connection to host system LOOPBACK at address 127.0.0.1.
PING request 1 from 127.0.0.1 took 57 ms. 256 bytes. TTL 64.
Round-trip (in milliseconds) min/avg/max = 0/11/57
Connection verification statistics: 5 of 5 successful (100 %).
Bottom
Type command, press Enter.
===>
F3=Exit F4=Prompt F9=Retrieve F10=Include detailed messages

F11=Display full F12=Cancel F13=Information Assistant F24=More keys
Figure 160. PING LOOPBACK display - Successful ping messages
2. To test the TCP/IP code, the Ethernet adapter, and the Ethernet LAN, specify
the Internet address of the local adapter as defined in the host table:
PING RMTSYS(*INTNETADR) INTNETADR('9.4.73.129')
Or, enter:
PING RMTSYS(SYSNAMA)
TCP/IP sends data to the Ethernet adapter, and instructs the adapter to send
the data to its own Ethernet address. If you have the correct configuration, the
display shown in Figure 161 on page 307 appears.

Command Entry
Request level: 4
> ping rchasm02
Verifying connection to host system RCHASM02.rchland.ibm.com at address
9.5.69.211.
Round-trip (in milliseconds) min/avg/max = 9/17/34
Bottom
===>

Figure 161. PING RMTSYS display - Successful ping messages
If the PING execution ends unsuccessfully, the display shown in Figure 162
appears.
Command Entry
Request level: 5
> PING '194.140.3.1'
Verifying connection to host system 194.140.3.1.
No response from host within 1 seconds for connection verification 1.
Bottom
===>

Figure 162. PING RMTSYS—Unsuccessful ping messages
If you received unsuccessful PING messages, you should attempt the following
tasks:
1. Check your configuration steps on the local system.
2. Check the configuration at the remote system.
3. Make sure the remote system is not powered down or TCP/IP is up and
running.
If you have other error messages, see Appendix E, "TCP/IP Problem Analysis" in
OS/400 TCP/IP Configuration and Reference , SC41-5420.

A.5 TCP/IP configuration using Operations Navigator
You can configure and work with TCP/IP through Operations Navigator or through
the command line interface. For some functions, the entire configuration must be
done through Operations Navigator, while other functions can only be configured
through the command line interface.
This section covers how to perform the following tasks for TCP/IP using
Operations Navigator:
• Accessing a basic TCP/IP configuration
• Configuring a TCP/IP interface
• Configuring the domain and host name for TCP/IP
• Configuring host table entries for TCP/IP
• Configuring a TCP/IP route
• Starting and stopping TCP/IP
• Verifying a TCP/IP connection (ping)
A.5.1 Accessing the TCP/IP configuration

AS/400 Operations Navigator is a powerful graphical interface for Windows 95,
Windows 98, and Windows NT clients. To use Operations Navigator, you must
have Client Access installed on your Windows 95, Windows 98, or Windows NT
PC and have a connection to the AS/400 system that you want to configure.
TCP/IP allows you to connect an AS/400 system to a network. To reach the point
where you can configure TCP/IP for your AS/400 system using Operations
Navigator, perform the following steps:
1. Start Operations Navigator by clicking Start->Programs->IBM AS400 Client
Access->AS/400 Operations Navigator. The AS/400 Operations Navigator
window appears (Figure 163 on page 309).
2. Double-click on the AS/400 Systems icon (A). It gives you a list of all the
AS/400 systems that you can access.
3. Double-click the AS/400 system (AS1) (B) that you want to configure.
4. Double-click Network (C).
5. Double-click Protocols (D).
6. Right-click TCP/IP (E ) in the right panel to see the context menu (Figure 163
on page 309).

Figure 163. Operations Navigator protocols
You are now ready to start your configuration process.
A.5.2 Configuring a line for TCP/IP

The communication objects for AS/400 TCP/IP are the line descriptions,
controller descriptions, and device descriptions. Operations Navigator allows you
to you configure a line for an Ethernet or a Token-Ring network adapter. When
TCP/IP starts the line, the controller and device descriptions are automatically
varied on. If the controller and device descriptions do not exist, TCP/IP
automatically creates them.
The procedure to create a line and to add TCP/IP support to it and the procedure
to add TCP/IP support to an existing line are similar. In this section, we show a
combination of both procedures with notes to point out where the differences
occur.
The configuration wizard takes you through the steps that are needed to
configure a line for TCP/IP for the AS/400 system. To use the configuration
wizard, perform the following steps:
1. Access the TCP/IP context menu using the steps in A.5.1, “Accessing the
TCP/IP configuration” on page 308.
2. Select New Interface from the context menu (Figure 163). Depending on your
version and release, you may see a selection menu for Local Area Network,
Wide Area Network, and Circuitless. Click Local Area Network . You should
now see the first window of the TCP/IP wizard interface. Click Next. The New
TCP/IP Interface Type window appears (Figure 164 on page 310).

Figure 164. Selecting the interface type
3. Select the type of connection you will define for TCP/IP (Ethernet,
Token ring). In our example, we selected Ethernet. If you select Token-ring,
you may see some different parameters to define. Click Next. The New
TCP/IP Interface Resource window appears (Figure 165).
Figure 165. Selecting the hardware resource
4. The New TCP/IP Interface Resource window shows all the hardware on your
system that matches your type selection. In our example, we have one

Ethernet adapter (CMN04). You should use the buttons on the window to
determine the location of the adapter. You can also use the buttons to list
communication lines that are currently defined. Right-click on the hardware
resource you want to configure. Click Next. The Choosing a Line window
appears (Figure 166) if a line is already defined for the hardware resource you
selected. Go to the next step. The Creating a New Line Description window
appears (Figure 167 on page 312) if there are not any lines defined using the
selected resource. Go to step 6.
Figure 166. Choosing a Line
5. To configure a TCP/IP interface on an existing line, click Use an existing line,

and select the line to use from the list provided. Click Next. Then go to step 8.
To create a new line, click Create a new line, and click Next. Then, continue
with step 6.

Figure 167. Creating a New Line Description
6. Enter a name and a description for the new line. Select the appropriate values
for Duplex and Authority based on your environment. The Help button
provides additional information to assist you in determining your correct
values. The Duplex value is based on the type of network hardware you are
using to construct your physical LAN. Click Next. The Ethernet Line
Characteristics window appears (Figure 168).
Figure 168. Ethernet Line Characteristics
7. Select the speed at which your LAN is running. Select the protocol standards
that you want to support on this adapter. Click Next. The TCP/IP Interface
Settings window appears (Figure 169 on page 313).

Figure 169. TCP/IP Interface Settings
8. The TCP/IP Interface Settings window (Figure 169) allows you to assign an IP
address to your network adapter. Type the IP address, the interface name (we
used line name), and the subnet mask for this IP address.
For the IP address and Subnet mask parameter, specify the value provided by
the LAN administrator or Internet Service Provider (ISP). For the IP address
and subnet mask, the system and does a "logical AND" to determine the
network and host values displayed in the window. The subnet mask and the IP
address enable IP protocol to determine where to send the data it receives.
Network name specifies the name of the network for which you are defining
interfaces and routes for the given network address.
The Maximum transmission unit (MTU) specifies the maximum size (in bytes)
of IP datagram that you can send on this interface. The maximum size
specified for a particular route should not be larger than the smallest MTU that
is supported by any router or gateway in that route. If the MTU size is larger
than the smallest MTU in the route, the router with the small MTU will
fragment the packet. This can increase the traffic on the segment and lead to
performance degradation. The Help button provides additional information
about MTU.
After you specify all the values, click Next. The TCP/IP Routing window
appears (Figure 170 on page 314).

Figure 170. TCP/IP Routing
9. The window in Figure 170 is where you list the gateways to which this route
directly connects. A gateway is a piece of hardware that connects two or more
network segments. It is often called a router. You can define up to three
gateway addresses. If your AS/400 system is only attached to a single
network, you do not need to specify any gateway addresses. This is also
where you specify additional routing information for this interface. This may be
used for load balancing or to define multiple routes for backup purposes. Click
the Yes button to configure additional route information. Click Next. The
TCP/IP Routing window (Figure 171) appears.
Figure 171. TCP/IP Routing additional information

10.The TCP/IP routing additional information window allows you to specify if
these routes should be published to the network using RIP1 or RIP2. You can
also define default routes, network routes, and routes to a specific host. Click
on the appropriate button to add the required routes. In this example, we
clicked on Add default route. The Add Default Route window (Figure 172)
appears.
Figure 172. Add Default Route
11.Each of the Add route windows has an Advanced button. Specify the gateway
address. Click the Advanced button. The Advanced Routing Settings (Figure
173) window appears.
Figure 173. Advanced Routing Settings
12.The Advanced Routing Settings window allows you to specify information

about the route. If you leave Route precedence set to 5, route selection will
work as it has always worked. If you set Route precedence to a value of less
than 5, this route will not be a preferred route to the destination network. If the
route precedence is set to a value greater than 5, the route will be considered
as a preferred route to the destination network. Or, you may have multiple
interfaces defined to the same network and multiple routes defined using the
interfaces, and the route precedence of these routes are set to the same value
greater than 5. In this case, the TCP/IP traffic will be balanced across all the
interfaces with routes defined.
Set the values that you need, and click OK. If you do not need to set any
advanced values, click Cancel .

When you have added all the route information you need, click OK until the
TCP/IP Routing window (Figure 171 on page 314) appears. Click Next. The
Servers to be Started window (Figure 174) appears.
Figure 174. Defining servers to start when TCP/IP is started
13. From the Servers to be Started window (Figure 174), select all the currently
installed servers that you want to start automatically when TCP/IP starts. If
you want to have a particular server automatically started when TCP/IP starts,
check the corresponding check box. If you have BOOTP, DHCP, and
BOOTP/DHCP servers, only one of them can be checked. After you select all
the servers to start, click Next. The Start TCP/IP Interface window (Figure
175) appears.
Figure 175. Interface start options

14.From the Start TCP/IP Interface window, you identify whether you want this
TCP/IP interface started whenever you start TCP/IP and whether you want
this TCP/IP interface to start now. If you choose to start the TCP/IP interface
here, the interface begins testing when you click Next. After a successful test,
the New TCP/IP Interface Summary window (Figure 176) appears.
Figure 176. New TCP/IP Interface Summary
15.Verify that all the information displayed is correct. If you need to make
changes, click Back to return to the correct window and make your changes. If
all the values are correct, click Finish.
You have now defined a TCP/IP interface using Operations Navigator.
A.5.3 Changing TCP/IP properties

The TCP/IP attributes of the AS/400 system are accessible from Operations
Navigator using the properties selection of the context menu. To use the
Operations Navigator, perform the following steps:
1. Access the TCP/IP context menu using the steps explained in A.5.1,
“Accessing the TCP/IP configuration” on page 308.
2. Select Properties (E) from the context menu to make detailed changes to the
configuration of your TCP/IP interface. Figure 177 on page 318 shows the
TCP/IP Properties window. Click the Host Domain Information tab to specify
the host domain information for your AS/400 TCP/IP communication. Specify
the host name, the domain name, and up to three domain name servers. You
can also specify the search order and set advanced TCP/IP settings. Note the
explanation provided here for the following fields:
• Host name
Specifies the name for the AS/400 system. You may not always remember
a host by its IP address, but you may find it easier to remember hosts by a
name. The host name can be combined with the domain name to make a
fully qualified name.

• Domain name
The domain name is a descriptive label for your organization such as
your_workplace.com. The two parts of the local domain name are the local
domain name and the local host.
• Domain name servers
List the IP address for up to three domain servers. The system uses the
domain servers in the order that you list them. The domain name servers
performs host name resolution by translating the host name into an IP
address.
• Search order
Specifies whether you want the local host table searched before the
domain name server. Figure 177 shows the Host Domain Information
dialog.
Figure 177. Host Domain Information
3. Click Advanced to set additional DNS values. The Advanced Host Domain
Information window (Figure 178 on page 319) appears. The default values
shown work in most environments. If you have intermittent trouble resolving
names to IP addresses, you may want to increase the number of attempts and
the interval between attempts. If these values are set too high, you may
experience a long wait time before an unknown host message is displayed.

Figure 178. Advanced Host Domain Information settings
4. Click the Host Table tab to add and remove host table entries. If you are using
the Domain Name System (DNS), you do not necessarily need to add entries
here. Figure 179 shows the Host Table dialog.
Figure 179. Host Table
5. Click the Settings tab to specify IP datagram forwarding, to select a TCP

urgent pointer convention, and to enter a TCP keep-alive time. You can also
use the settings page to log protocol errors, enable IP source routing, and
enter a buffer size, time-out, and other values.

IP forwarding specifies whether you want the IP layer to forward IP datagrams
between different networks. This specifies whether the IP layer acts as a
gateway (router). It allows the AS/400 system to pass IP datagrams that come
in one adapter to another adapter.
The TCP keep-alive field specifies the amount of time, in minutes, that TCP
waits before sending a probe to the other side of a connection. TCP sends the
probe when the connection is otherwise idle, even when there is no data to be
sent. Figure 180 shows the Settings dialog.
Figure 180. TCP/IP Settings
6. Click the Port Restrictions tab to limit port use to a user profile name. If you
want to restrict a single port, you must specify the same starting and ending
port number. Figure 181 on page 321 shows the Port Restrictions dialog.

Figure 181. Port Restrictions
7. Click the Servers to Start tab to select the currently installed servers that you
want to start automatically when TCP/IP starts. Check the corresponding
servers check box. If you have BOOTP, DHCP, and BOOTP/DHCP servers,
only one of them can be checked. Figure 182 shows the Servers to Start
dialog.
Figure 182. Servers to Start

8. Click the SOCKS tab to define the TCP client connection to internal secure
networks and to less secure networks. You can define a direct connection to
servers in the internal secure network. Users must have *IOSYSCFG special
authority to change information on this dialog. Figure 183 shows the SOCKS
dialog.
Figure 183. SOCKS
9. After completing changes to the TCP/IP Properties Dialog, click OK to save

the configuration file and close the window.
A.5.4 Configuring host table entries

You must configure host table entries for TCP/IP if you want the users of your
AS/400 system to use easily remembered names rather than IP addresses. If you
are using the Domain Name System (DNS), you do not need to configure host
table entries.
The host table provides the advantage of not having to remember actual Internet
addresses for systems in the network. The host table accomplishes this task by
mapping Internet addresses to TCP/IP host names. The local host table on your
AS/400 system contains a list of the Internet addresses and related host names
for your network.
Before you begin configuring your host table entries for TCP/IP, you need to know
the IP addresses of your hosts. You also need the to know the host names and
descriptions of the hosts that you want to include in the host table.
To configure host table entries for TCP/IP using Operations Navigator, perform
the following steps:
1. Select the appropriate TCP/IP window as follows:
a. Start Operations Navigator by clicking Start ->Programs->IBM Client
Access->AS/400 Operations Navigator. The AS/400 Operations
Navigator window appears (Figure 184 on page 323).
b. Double-click the AS/400 Systems icon (A). A list of all the AS/400 systems
should appear that can be configured.

c. Double-click the AS/400 system you want to configure (B).
d. Double-click Network (C).
e. Double-click Protocols (D).
f. Right-click TCP/IP to open a context menu (E ).
2. Select Properties from the context menu (F). Figure 184 shows the context
menu Properties option.
Figure 184. Context menu - Properties option
3. Click the Host Table (A) tab as shown in Figure 185.

4. Click the Add (B) button to specify the IP address, hostname, and description
of the host that you want to include in the host table. Figure 185 shows the
TCP/IP Host Table entry dialog.
Figure 185. TCP/IP Host Table entry

5. Click OK (C) to save the configuration file and close the window.
A.5.5 Configuring the domain and host name

You must configure the local domain and host name if you use a remote name
server that requires a full domain to resolve an IP address. The local domain
name is information that is provided by:
• The network provider
• The local network administrator
This is a "true" intranet if the name is created by the customer.
Within TCP/IP, the primary name associated with your system can have more
than one name (your system can have more than one name). It is called your
local domain and host name. This is important if you later want to set up e-mail,
LPR, and ANYNET. They require the local domain and host name. File transfer
and Simple Network Management Protocol use these names, but do not require
them.
To configure a local domain and host name for TCP/IP, perform the following
steps:
a. Start Operations Navigator be clicking Start->Programs->IBM Client
Access->AS/400 operations Navigator.
b. Double-click your AS/400 Systems icon (A). It should give you a list of all
the AS/400 systems that you can configure.
c. Double-click the AS/400 system for which you want to configure a domain
and host name (B).
d. Double-click Network (C).
e. Double-click Protocols (D).
f. Right-click TCP/IP to open a context menu (E ).
g. Select Properties from the context menu (F). Figure 186 on page 325
shows the context menu Properties option.

Figure 186. Context menu - Properties option
h. Click the Host Domain Information tab (A) as shown in Figure 187.
Figure 187. Host Domain Information
2. Specify your host name (B) and domain name (C). You can also select the
search order (D), set advanced TCP/IP settings, and specify up to three
domain name servers.
3. Click OK to save the configuration file.

A.5.6 Configuring a TCP/IP route
A network can consist of many interconnected networks. A route must be defined
for your system to communicate with a system on another network. If you want to
reach remote networks, you need to configure a TCP/IP route for your AS/400
system.
A TCP/IP interface must be defined before defining a route. A TCP/IP interface

implicitly defines a direct route. This is because interfaces define a route to a
network to which the AS/400 system is directly connected. Routes added using
the AS/400 route commands are called indirect routes because they define a
route to a network to which the AS/400 system is not connected to directly.
The NextHop Internet address for a route definition must exist on a network to
which one or more TCP/IP interfaces are connected. The NextHop Internet
address usually defines a router or gateway.
Specify the IP address of the router as the default routing entry on the AS/400
system (next hop). This tells the AS/400 system to look for this router if it cannot
find a TCP/IP address on its own local network. If you do not configure a TCP/IP
route, your AS/400 system cannot reach systems that are on other networks. You
may also want to configure a TCP/IP route to give TCP/IP clients access to your
AS/400 system.
You do not need to manually configure the routes that tell TCP/IP how to reach
the local networks. AS/400 TCP/IP generates these routes automatically from the
configuration information for the interfaces every time that TCP/IP starts. Any
changes that you make to the routing information take effect immediately.
To configure a TCP/IP route, perform the following steps:

a. Double-click your AS/400 System icon (A). It should give you a list of all
the AS/400 systems that you are configuring.
b. Double click the AS/400 system that you want to configure a TCP/IP route
for (B).
c. Double-click Network (C).
d. Double-click Protocols (D).
e. Right-click TCP/IP to open a context menu (E ). Select New Interface (F).
Figure 188 on page 327 shows the context menu New Interface option.

Figure 188. Context menu - New Interface option
2. Follow the wizard’s instruction to configure your TCP/IP route. Figure 189
shows the first window of the TCP/IP Interface wizard.
Figure 189. TCP/IP Interface wizard
A.5.7 Starting and stopping TCP/IP

Starting TCP/IP initializes and activates the TCP/IP process, starts the TCP/IP
interfaces, and starts the TCP/IP server jobs. TCP/IP must be started before any
TCP/IP process can be performed on the AS/400 system. Starting TCP/IP only
starts the TCP/IP application jobs that have the AUTOSTART configuration
attribute value of *Yes. After starting TCP/IP, the QTCPIP job in the QSYSWRK
subsystem is started. The QTCPIP job is used for activating and deactivating
TCP/IP interfaces.

When TCP/IP or ANYNET is already active, use the Start TCP/IP Server
(STRTCPSVR) command to start additional TCP/IP application servers.
A.5.7.1 Starting TCP/IP

To start TCP/IP, follow this process:
a. Double-click on the AS/400 Systems icon (A) in the Operations Navigator
tree to give you a list of the AS/400 systems that you are configuring.
b. Double-click the AS/400 system that you want to start TCP/IP processing
(B).
d. Double-click Protocol (D).
e. Right-click TCP/IP to open the context menu (E).
2. Select Start (F ) to initialize and activate TCP/IP processing, start TCP/IP
interfaces, and start TCP/IP server jobs. Figure 190 shows the context menu
to start TCP/IP and the Start TCP/IP dialog.
Figure 190. Start TCP/IP
A.5.7.2 Stopping TCP/IP

Stopping TCP/IP ends all TCP/IP processing, all active TCP/IP interfaces, and all
TCP/IP connections on the AS/400 system on which you are working. Unless
ENDSVR (*NO) is specified, all TCP/IP server jobs for agents that are currently
active in QSYSWRK subsystem are ended. There is no confirmation display
shown when stopping TCP/IP, so this should be done with caution. There are two
possible values when stopping TCP/IP: controlled and immediately. Follow these
steps to stop TCP/IP by using Operations Navigator:

1. Perform the following steps:
a. Double-click on the AS/400 Systems icon (A) in the Operations Navigator
tree to give you a list of the AS/400 systems that you are configuring.
b. Double-click the AS/400 system that you want to stop TCP/IP processing
(B).
d. Double-click Protocols (D).
e. Right-click on TCP/IP to open a context menu (E).
2. Select Stop (F ).
3. Select Controlled or Immediately (G). Figure 191 shows the Stop TCP/IP
dialog.
Figure 191. Stop TCP/IP
A.5.8 Verifying a TCP/IP connection (ping)

Verifying a network connection (ping) function is one of the best problem
determination tools around for quick diagnosis of a problem in your TCP/IP
network. Ping tests the TCP/IP connection between a system and the remote
system specified on the remote system parameter. It tells you if you can see the
host to which you are trying to connect.
When you ping a machine, you send an Internet Control Message Protocol
(ICMP) echo request to that machine. A successful reply means that the
network’s primary transport and communication systems are functioning properly.
To ping a machine using Operations Navigator, perform the following steps:

1. Double-click the AS/400 Systems icon (A). You should see a list of all the
AS/400 systems that you can configure.

2. Double-click Network (B).
3. Double-click Protocols (C).
4. Select TCP/IP (D).
5. Right-click on TCP/IP to open context menu (E).
6. Select Utilities (F).
7. Select Ping (G). Figure 192 shows the Ping dialog.
Figure 192. Ping from Operations Navigator
8. As shown in Figure 193, type the IP address or host name of the interface of
the host to which you want to test connectivity. Then, click Ping Now. The
results of the ping are displayed. Figure 193 shows the Ping from dialog.
Figure 193. Ping

A.6 Connecting through a gateway or different network
If you have to connect with a remote host in a different network or subnetwork to
the local host (or you use a gateway), it is necessary to configure a route. For
example, suppose someone using a PC is attempting to use the Telnet
application to start a remote terminal session on this AS/400 system. Obviously,
the application on the PC must know the route or path to reach the AS/400
system. However, your AS/400 system must also be able to determine the route
back to the PC. If the PC and your AS/400 system are not on the same network, a
routing entry must exist both on the PC and on the AS/400 system.
A TCP/IP interface must be defined before defining a route. A TCP/IP interface

implicitly defines a direct route. This is because interfaces define a route to a
network to which the AS/400 system is directly connected. Routes added using
the route commands are called indirect routes because they define a route to a
network to which the AS/400 system is not connected to directly. The NEXTHOP
Internet address for a route definition must exist on a network to which one or
more TCP/IP interfaces are connected. The NEXTHOP Internet address usually
defines a router or gateway. Use the Work with TCP/IP Route Entries display to
add route information or to display, change, print, or remove route information.
A.6.1 Scenario
In this scenario, there are two Ethernet networks. We want to connect our first
network to the second one. We need a route to know how to go to the 9.5.7.128
network.
AS/400 (SYSNAMA) PC

Router
9.4.73.193
Router 9.5.7.194
PC PC
Figure 194. Two Ethernet LANs connected with routers example
A.6.2 Route configuration

To configure a TCP/IP route, perform the following steps:
1. Select option 2 (Work with TCP/IP routes) from the CFGTCP menu, and press
Enter. The display shown in Figure 195 on page 332 appears.

Work with TCP/IP Routes

1=Add 2=Change 4=Remove 5=Display
Route Subnet Next Preferred

Opt Destination Mask Hop Interface
*DFTROUTE *NONE 9.4.73.193 *NONE
Bottom
F3=Exit F5=Refresh F6=Print list F11=Display type of service
F12=Cancel F17=Top F18=Bottom
Figure 195. CFGTCP menu display - Work with TCP/IP Routes
2. Select option 1 (Add) to add an entry to the TCP/IP routes. The display shown
in Figure 196 appears.
Add TCP/IP Route (ADDTCPRTE)
Route destination . . . . . . . > 9.5.7.128 *Note 1

Subnet mask . . . . . . . . . . > '255.255.255.128'
Type of service . . . . . . . . *NORMAL *MINDELAY, *MAXTHRPUT...
Next hop . . . . . . . . . . . . > '9.4.73.193'
Preferred binding interface . . *NONE
Maximum transmission unit . . . *IFC 576-16388, *IFC
Route metric . . . . . . . . . . 1 1-16
Route redistribution . . . . . . *NO *NO, *YES
Duplicate route priority . . . . 5 1-10
Bottom
F24=More keys
Figure 196. Add TCP/IP Route (ADDTCPRTE) display
Although there are five parameter values to define a route, you only need to
type three of them and assume the others. These values are:
• The route destination: 9.5.7.128
• The subnet mask: 255.255.255.128
• The Internet address of the next system on the route, Next Hop: 9.4.73.193
Note 1: Depending on your configuration, the last route destination octet may
need to be a "1".
A.7 Starting an FTP session

FTP provides the functions of transferring files between two TCP/IP hosts. Since
FTP is built on the services of TCP, it provides a reliable end-to-end connection
during the file transfer operation. Security is provided by normal user ID and
password authentication. You can start FTP from a workstation by using the
following command:
FTP HOSTNAME

Hostname is the AS/400 remote system. Once the session is connected and you do
not type something within five minutes, the session is closed by the AS/400
system. You have to repeat the FTP command to re-start the connection.
To change the amount of time you can stay in a session without typing, use the
following steps:
1. From the CFGTCP menu, select option 20 (Configure TCP/IP applications),
and press Enter. The display in Figure 197 appears.
Configure TCP/IP Applications
1. Configure SNMP agent

2. Configure RouteD
3. Change Trivial FTP Attributes
4. Configure BOOTP
5. Change DDM TCP attributes
6. Change DHCP attributes
10. Change FTP attributes

11. Configure TELNET
12. Configure SMTP
13. Change LPD attributes
14. Configure HTTP
15. Configure workstation gateway
16. Change POP attributes
More...
===> 10
F3=Exit F4=Prompt F9=Retrieve F12=Cancel
Figure 197. CFGTCP menu display - Configure TCP/IP Applications
2. Select option 10 (Change FTP attributes), and press Enter. The display shown
in Figure 198 on page 334 appears.

Change FTP Attributes (CHGFTPA)
Autostart servers . . . . . . . *YES *YES, *NO, *SAME

Number of initial servers . . . 3 1-20, *SAME, *DFT
Inactivity timeout . . . . . . . 600 0-2147483647, *SAME, *DFT
Coded character set identifier 00819 1-65533, *SAME, *DFT
Server mapping tables:
Outgoing EBCDIC/ASCII table . *CCSID Name, *SAME, *CCSID, *DFT
Incoming ASCII/EBCDIC table . *CCSID Name, *SAME, *CCSID, *DFT

Bottom
F24=More keys
Figure 198. Change FTP Attributes (CHGFTPA) display
3. Change the inactivity time-out parameter to the desired elapsed time (for
example, from 300 (5 minutes) to 600 (10 minutes)) to disconnect the session
(in seconds). Press Enter.

Appendix B. AS/400 Client Access Express for Windows
This appendix describes the basic functions of the AS/400 Client Access Express
for Windows. It also explains briefly how to install the Client Access Express for
Windows on the AS/400 system and the client software on the PCs. For complete
documentation on setting up, installing, and configuring Client Access Express,
see Client Access Express for Windows - Setup, SC41-5507, and AS/400 Client
Access Express for Windows: Implementing V4R4M0, SG24-5191.
Note: You may configure Client Access/400 connections from the client PC to the
AS/400 server prior to installing eBPCS Client/Server.
B.1 Client Access Express for Windows (5769-XE1)

AS/400 Client Access continues to provide industry-leading PC-to-AS/400
connectivity solutions by adding yet another client option for Windows users. This
new 32-bit Windows client, called AS/400 Client Access Express for Windows, is
designed to take advantage of the latest technologies in both the AS/400 system
and Microsoft operating systems. Client Access Express for Windows is a
member of the Client Access family, which provides PC-to-AS/400 connectivity
solutions for a variety of PC operating systems (Windows 95, Windows 98, and
Windows NT).
B.1.1 Client Access Express for Windows functions

These are the major functions of the Client Access Express:
• Installation and migration
Client Access Express for Windows can be installed on Windows 95, Windows
98, or Windows NT 4.0 PCs. Client Access Express for Windows also
migrates certain client configuration information from some previous Client
Access products.
• TCP/IP and dial-up connectivity
Easy access to TCP/IP connectivity from each of its functions is one of the
improvements in Client Access Express for Windows. It offers increased
flexibility by integrating the management of the Client Access user ID and
password with that of the Windows operating system. Note that only TCP/IP
connectivity is supported by Client Access Express client.
• TCP/IP Secure Sockets Layer
The Express Client uses the TCP/IP Secure Sockets Layer Version 3.0 to
encrypt the user ID and password, as well as any other information being sent
between the AS/400 system and the desktop. You can choose what is
encrypted, for example, you may wish to encrypt data being transmitted by
Data Transfer but find it unnecessary to encrypt data being sent to your PC
printer using 5250 printer emulation.
• AS/400 NetServer
AS/400 NetServer enables an AS/400 system to act as a file and print server
in a Windows network. AS/400 NetServer has been a function of the base of
OS/400 since Version 4 Release 2. Although AS/400 NetServer is not part of

Client Access Express for Windows, it is used to replace the network drive and
network printer functions that are part of Client Access for Windows 95/NT.
• AS/400 Operations Navigator
AS/400 Operations Navigator is a graphical user interface (GUI) that provides
administrators and operators with an explorer-like view of the AS/400
resources. With the addition of the Management Central function, you can now
manage multiple AS/400 systems using Operations Navigator.
• Display and print emulation
Client Access Express PC5250 is equipped with useful functions that help you
work with AS/400 display and print emulation sessions. Many enhancements
are added into this release to deliver improved connectivity, efficiency,
usability, manageability, and flexibility to those who work with the AS/400
system using the green-screen environment.
• AFP Workbench Viewer
This tool helps you work with many kinds of print output and PC files. It helps
you display a WYSIWYG (What You See Is What You Get) view of the AS/400
output and PC files, navigate through them, view many popular PC graphic
formats, and create and share AFP resources for AS/400 and PC printing
jobs.
• Data Transfer
Data Transfer allows data to be transferred between the AS/400 system and
the PC based on the SQL engine. Wizards are included in the Data Transfer
application and allow users to create, run, and save transfer requests easily.
In the Express client, new functions, such as an Auto-run transfer request,
have been added to the Data Transfer application.
• Middleware for client/server applications
Client Access Express delivers many middleware components (ODBC driver,
ActiveX automation objects, PC5250 API, and so on) that contain popular
programming interfaces for you to use when developing client/server
applications. You can use your development tool of choice to work with the
AS/400 server effectively and efficiently.
• Software maintenance
The Express client is maintained automatically with the Check Service Level
function. Several options allow you to set when and how those updates will be
performed. It also introduces a new function, which distributes any kind of PC
application with the support of add-ins. You can add your applications in the
Express Client installation process. An add-in can consist of files, user-written
programs, or product setup programs. Once installed, the add-ins are
maintained as an Express client component by the Check Service Level.
• Administering Client Access Express for Windows
Client Access Express for Windows provides you with tools for administering
the Express client. For example, you can import or export AS/400 connections
or backup and restore Express client configurations.
The Express client takes full advantage of System Policy. Each time a PC is
started, system policies can be downloaded from a server to the PC and
enforced through policies defined by an administrator. Many templates are
provided to offer outstanding granularity in the functions that an administrator

can control. The users can be limited in areas, such as the number of 5250
sessions started, and prevented from creating a new file. However, they can
be allowed to append data to an existing file, but prevented from installing an
Operations Navigator subcomponent.
When an Express client user connects to an AS/400 system, Application
Administration checks the AS/400 user profile to determine which functions
can be used. An AS/400 administrator defines a security setting to allow or
deny users or groups of users access to Operations Navigator, PC5250, Data
Transfer, ODBC, OLE DB, and Remote Command functions.
• Remote program call
An AS/400 system can run a command on a PC that has Client Access
Express for Windows installed. A PC can start a remote command on an
AS/400 system.
• Operations Console
Operations Console allows you to emulate the AS/400 console and the
AS/400 control panel on a PC. Operations Console actually consists of two
independent functions: the console emulation and the control panel. One can
be used without the other. Console emulation is available for OS/400 V4R3
and later. Operations Console can be used locally or remotely.
B.1.2 Client Access for Windows Family (5769-XW1)

This family focuses on client solutions that run on Microsoft Windows operating
systems. This family is the recommended PC-to-AS/400 connectivity solution for
customers who have Windows PCs.
The Client Access for Windows Family includes the following clients:
• Client Access Express for Windows
• Client Access for Windows 95/NT
• Client Access Enhanced for Windows 3.1
Please refer to Sections A.1 and A.2 in AS/400 Client Access Express for
Windows: Implementing V4R4M0, SG24-5191, for further information on the
functional differences between Client Access for Windows 95/NT and Client
Access Express.
B.1.3 Client Access Base Family (5769-XY1)

This product contains a collection of the original clients previously delivered. This
family is maintained and supported at the level of functionality that each client
currently contains. This family is recommended for customers who need OS/2 or
DOS desktop connectivity. It is also beneficial for 16-bit Windows users who wish
to continue using the RUMBA/400 emulator on desktops and do not foresee
needing any of the 16-bit Windows product enhancements provided in the Client
Access for Windows Family. The Client Access Base Family includes the
following clients:
• Client Access for Windows 3.1
• Client Access Optimized for OS/2
• Client Access for OS/2
• Client Access for DOS with Extended Memory
AS/400 Client Access Express for Windows 337

B.1.4 AS/400 Client Access Extended Family
This family features products developed by other companies, which contain
Client Access technologies. The AS/400 Client Access Extended Family product
consists of the MacMidrange Client and the UNIX OS Client.
B.1.5 Obtaining Client Access Express for Windows

Customers who acquire OS/400 Version 4 Release 4 are shipped with the Client
Access Express for Windows client. You can also obtain this client in the following
situations:
• New customers ordering Client Access for Windows Family (5769-XW1)
• OS/400 upgrade to OS/400 V4R2 or later releases
• New order of feature 2640 for 5755-AS5 for a system already at V4R2 or later
B.1.6 License information

AS/400 Client Access Express for Windows (5769-XE1) is a licensed program
product that is supported only on an AS/400 system running OS/400 V4R2 or
later. Some components require an AS/400 Client Access for Windows family
(5769-XW1) license before you can use them.
Only the following components require a Client Access Express license:

• PC5250 Display and Printer Emulator
• Data Transfer
B.2 Installing Client Access Express on the AS/400 system

On V4R4 AS/400 systems, Client Access Express for Windows (5769-XE1) can
be installed from the Work with Licensed Programs (GO LICPGM) menu. On
V4R2 and V4R3 AS/400 systems, this is accomplished by using the Restore
Licensed Program (RSTLICPGM) command. Client Access Express for Windows
must be installed to facilitate the loading of Service Pack Program Temporary
Fixes (PTFs) on the AS/400 system. This makes it possible to install both the
base code and service packs onto PCs from the AS/400 system. The installation
of the product can be verified by using the Display Software Resources
(DSPSFWRSC) command.
Depending on what functions of Client Access Express for Windows are to be

used, there are other licensed program products (LPP) that need to be installed
on the AS/400 system. All functions of the product require that the Host Servers
(5769-SS1 option 12) portion of OS/400, as well as the TCP/IP Connectivity
Utilities (5769-TC1), must be installed on the AS/400 system. This is because
TCP/IP is the only connection protocol supported. If licensed functions of Client
Access Express for Windows are going to be used, the Client Access/400
Windows Family Base (5769-XW1) must be installed on the AS/400 system and
have licenses available.
To install Client Access Express for Windows, perform the following steps:
1. Sign on to the AS/400 system as QSECOFR (or any other user with *SECOFR
authority).

2. Load the software installation CD-ROM, and type GO LICPGM on an AS/400
command line. The Work with Licensed Programs screen appears (Figure
199).
LICPGM Work with Licensed Programs
Manual Install
1. Install all
Preparation
5. Prepare for install
Licensed Programs
10. Display installed licensed programs
11. Install licensed programs
12. Delete licensed programs
13. Save licensed programs
More...
===> 11

Figure 199. Work with Licensed Programs
3. Select option 11 to obtain the display shown in Figure 200.

1=Install
Licensed Product
Option Program Option Description
5769WP1 3 OfficeVision - Mail

5769XD1 *BASE Client Access/400 Optimized for Windows
5769XE1 *BASE Client Access/400 Express for Windows
5769XW1 *BASE Client Access/400 Windows Family Base
5769XY1 *BASE Client Access Base Family
5769XZ1 *BASE OS/2 Warp Server for AS400 (WS400)
Bottom
F3=Exit F11=Display status/release F12=Cancel F19=Display trademarks
Figure 200. Install Licensed Programs
4. Locate the entry for the 5769XE1 licensed program, and select option 1 to
perform the installation.
5. Upon completion of the licensed program installation, issue the Check Product
Option (CHKPRDOPT) command to verify that the installation was successful:
CHKPRDOPT PRDID(5769XE1)

The command returns messages detailing the status of the product
installation.
Installation of the licensed program product (LPP) can also be verified with the
DSPSFWRSC command. Using this method, the display in Figure 201 appears.
Display Software Resources
Resource
ID Option Feature Description
5769TC1 *BASE 2924 AS/400 TCP/IP Connectivity Utilities/400
5769WP1 *BASE 5050 OfficeVision for AS/400
5769WP1 *BASE 2924 OfficeVision for AS/400
5769WP1 1 5050 OfficeVision - Text Search Services
5769WP1 1 2924 OfficeVision - Text Search Services
5769WP1 2 5050 OfficeVision - Calendar
5769WP1 2 2924 OfficeVision - Calendar
5769WP1 3 5050 OfficeVision - Mail
5769WP1 3 2924 OfficeVision - Mail
5769XE1 *BASE 5050 Client Access/400 Express for Windows
5769XE1 *BASE 2924 Client Access/400 Express for Windows
5769XW1 *BASE 5050 Client Access/400 Windows Family Base
5769XW1 *BASE 2924 Client Access/400 Windows Family Base
5769XY1 *BASE 5050 Client Access Base Family
More...
F3=Exit F11=Display libraries/releases F12=Cancel

F19=Display trademarks
Figure 201. Display Software Resources
Note: The LPP must be installed to apply Service Pack PTFs on the AS/400
system.
6. Before attempting to configure Client Access connections from workstations,
ensure that you have the OS/400 Host Servers feature installed (Figure 202 on
page 341).

Display Software Resources
Resource
ID Option Feature Description
5769999 *BASE 5050 AS/400 Licensed Internal Code
5769SS1 *BASE 5050 Operating System/400
5769SS1 *BASE 2924 Operating System/400
5769SS1 1 5050 OS/400 - Extended Base Support
5769SS1 1 2924 OS/400 - Extended Base Support
5769SS1 2 5050 OS/400 - Online Information
5769SS1 2 2924 OS/400 - Online Information
5769SS1 3 5050 OS/400 - Extended Base Directory Support
5769SS1 3 2924 OS/400 - Extended Base Directory Support
5769SS1 8 5050 OS/400 - AFP Compatibility Fonts
5769SS1 9 5050 OS/400 - *PRV CL Compiler Support
5769SS1 9 2924 OS/400 - *PRV CL Compiler Support
5769SS1 12 5050 OS/400 - Host Servers
5769SS1 12 2924 OS/400 - Host Servers
More...
F3=Exit F11=Display libraries/releases F12=Cancel

F19=Display trademarks
Figure 202. Display Software Resources
B.3 Installing Client Access Express on the PC

Client Access Express for Windows installs onto the PC by using an installation
wizard in a similar fashion to most other Windows application installations. The
following sections discuss some of the different installation sources for the
product and types of installations that the installation wizard offers, as well as a
description of the installation process.
B.3.1 Installation sources

Client Access Express for Windows can be installed from several different
sources.
B.3.1.1 CD-ROM
The PC installation code for Client Access Express for Windows is distributed on
the Client Access/400 for Windows Family CD. The Client Access Enhanced for
Windows 3.1 and Client Access for Windows 95/NT products are also distributed
on this same CD. The Client Access Express for Windows setup application is
found in the directory x:\Express (where x is the letter of the CD-ROM drive that is
used).
B.3.1.2 Mapped network drive

For enterprises that already have a PC Local Area Network (LAN) setup, many
find it more convenient to make the Client Access Express for Windows
installation code available from a central network location. This can be
accomplished by copying the Client Access Express for Windows install image
from the CD directly to the network share. Another option is to share the CD-ROM
drive of a CD carousel and place the Client Access/400 for Windows Family CD
in the shared drive. In either case, the PC, where the Client Access Express for
Windows product is to be installed, needs a network drive mapped to the source

directory on the network where the Client Access Express for Windows install
image is located. Then, the setup application is run from that mapped network
drive.
B.3.1.3 AS/400 NetServer share

When the Client Access Express for Windows (5769-XE1) LPP is installed on the
AS/400 system, the PC side install image for the product is stored in the AS/400
system’s integrated file system (IFS). The install image is stored in the directory
\QIBM\ProdData\CA400\Express\Install\Image. The LPP installation of Client
Access Express for Windows (5769XE1) automatically creates a share for \QIBM.
PCs using normal Windows networking support can map a network drive to the
AS/400 IFS and install Client Access Express for Windows from there.
Note
We recommend that you use a mapped network drive to the AS/400 NetServer
share as the source directory for installing Client Access Express for Windows
onto a PC. Some of the reasons why we make this recommendation are:
• It is more convenient than using the CD-ROM.
• It allows access to install Secured Sockets Layer (SSL), any available
secondary languages, user add-ins, and any Operations Navigator plug-ins
that may be available on the AS/400 system.
Doing the initial installation from here also sets the default source directories
for the Check Service Pack Level, Upgrade, and Reinstall functions of Client
Access Express for Windows. This type of installation may not work correctly
due to slow or unreliable network communications causing the installation to
time out or fail. In this case, install Client Access Express for Windows from the
Client Access/400 for Windows Family CD as described in B.3.1.1, “CD-ROM”
on page 341.
B.3.2 Installation types

The Client Access Express for Windows installation program offers four basic
installation types:
• Typical
• PC5250 user
• Custom
• Full
B.3.2.1 Typical installation

This installation provides the functions needed by most Client Access Express for
Windows end users. The following components are installed when this type of
installation is selected:
• Express Required Programs
• Express Optional Components
– Directory Update
– Incoming Remote Command
– MAPI
– Client Access Express Online User’s Guide

• Data Access
– Data Transfer
• Data Transfer Base Support
• Data Transfer Excel add-in
– ODBC
– OLE DB Provider
– Operation Navigator Base Support
– Basic Operations
• Printer Drivers (Windows NT only)
– AFP Printer Driver
– SCS Printer Driver
• 5250 Display and Printer Emulation
– PC5250 base support (defaults to the version based on the code page of
the PC)
– Standard PC5250 PDF/PDT files (one for each language)
– PC5250 fonts (only for single byte languages)
The typical installation requires approximately 60 MB of hard disk space.
B.3.2.2 PC5250 user installation

This installation is designed for users who desire to use the PC5250 Display and
Printer Emulation function of Client Access Express for Windows. The following
components are installed when this type of installation is selected:
– PC5250 Base Support (defaults to the version based on the code page of
the PC)
– Standard PC5250 PDF/PDT Files (one for each language)
– PC5250 Fonts (only for single-byte languages)
The PC5250 installation requires approximately 35 MB of hard disk space.
B.3.2.3 Custom installation

Custom installation allows the end user to decide exactly what functions of Client
Access Express for Windows to install on the PC. The Express Required
Programs option is necessary for most of the functions to work, with the following
exceptions:
• Client Access Express Online User’s Guide
• AS/400 Java Toolbox
• AS/400 Operations Console
• Client Access Express Toolkit (Headers, Libraries, and Documentation)
B.3.2.4 Full installation

The Full installation option automatically installs every function available to be
installed from the Client Access Express for Windows source directory. Certain
functions, for example the Secure Sockets Layer (SSL) support for Client Access
Express for Windows, are only available for installation if the source directory is

the AS/400 system’s QIBM share. The following functions are installed by this
installation type:
• Express Optional Components
– Directory Update
– Incoming Remote Command
– MAPI
– Client Access Express Online User’s Guide
• Data Access
– Data Transfer
• Data Transfer Base Support
• Data Transfer Excel add-in
• Data Transfer WK4 file support
– ODBC
– OLE DB Provider
– Operation Navigator Base Support
– Basic Operations
– Job Management
– System Configuration
– Network
– Security
– Users and Groups
– Database
– File Systems
– Multimedia
– Backup
– Application Development
– Management Central
– Application Administration
• Printer Drivers
– AFP Printer Driver
– SCS Printer Driver
• AS/400 Operations Console
• Secured Sockets Layer (SSL) (if the source directory is the AS/400 system,
and the product 5769CEn is installed)
– 128-bit, 56-bit, or 40-bit encryption
• Client Access Express Toolkit
– Headers, Libraries, and Documentation
– Visual Basic Wizards
• AS/400 Java Toolbox
– PC5250 Base Support (defaults to the version based on the code page of
the PC)

– Standard PC5250 PDF/PDT Files (one for each language)
– PC5250 Fonts (only for single byte languages)
This type of installation requires approximately 105 MB of hard disk space on the
PC.
B.3.3 Installation process

This section describes a brief installation process. Be sure the protocol you want
to use for Client Access Express for Windows is correctly configured. To initiate
the installation process, follow these steps:
1. Run the Setup.exe application from the source directory where the Client
Access Express for Windows install image is located.
This can be accomplished in several ways:
• Running Setup.exe from a mapped network drive through a Windows
Explorer interface
• Through the Windows Start or Run command
• Through the Add/Remove Programs wizard in the Windows Control Panel
2. The installation wizard loads, at which time the Welcome display is shown.
Click the Next button to continue the installation process. Be sure to follow the
recommendation listed here and close all other Windows programs. If you
select the Cancel button, the installation process is aborted. This can be done
here or throughout the rest of the wizard.
3. The licensing information for the Client Access Express for Windows product
is now displayed. Read the information presented. Once you understand when
an OS/400 or Client Access license is required, click the Yes button to
continue the installation wizard. If you select the No button, the installation
process ends. Here, and through the rest of the installation wizard, click the
Back button to return to the previous display in the wizard so you can make
any changes if needed.
4. Select the type of installation. The type of installation you choose to perform
determines which components are installed, and whether a 5769-XW1 license
is required:
• Typical : The typical installation choice includes components that require a
license.
• PC5250 User : Designed for users who desire to use the PC5250 Display
and Printer Emulation function of Client Access Express for Windows.
• Custom: Custom installation allows the end user to decide exactly what
functions of Client Access Express for Windows to install on the PC.
Whether a license is required depends on the components you select.
Components that require a license are identified.
• Full: The Full installation option automatically installs every function
available to be installed from the Client Access Express for Windows
source directory.
At this stage, you are given the opportunity to specify an alternative destination
directory to the default into which to install the Client Access Express for
Windows, which components of Client Access Express for Windows to install,
and the Windows program group to install. You have the option to go back and

change your selection if necessary. When you are satisfied with your selection,
you may continue the installation process.
Once the installation is complete, you are given the options to view the Readme
file. We recommend that you view this file when you first install the client since it
may contain important last-minute information.
The next panel asks you to restart your computer. We recommend that you select
this option at this point rather than waiting until later. This ensures that the final
steps in the setup process are completed before you try using any Client Access
Express functions.
Note
If you install Client Access Express for Windows onto a Windows NT 4.0 TSE
server, the installation process differs somewhat from the process outlined
previously. Refer to Chapter 14 of AS/400 Client Access Express for Windows:
Implementing V4R4M0 , SG24-5191, for further information.
B.3.4 Silent installation

Client Access Express for Windows supports a silent installation of the product. A
silent installation reads the responses to the normal installation wizard prompts
from a response file, which eliminates the need for user interaction. This makes it
easier for less experienced users to install Client Access Express for Windows on
the PC, and makes sure that all users have the same client functions installed on
the PC. First, the silent installation process requires recording the response file.
Then, it runs the silent installation. Finally, it checks the log file for any pertinent
information. For further information, refer to Chapter 2 of AS/400 Client Access
Express for Windows: Implementing V4R4M0, SG24-5191.
B.3.5 Selected setup

After Client Access Express for Windows is installed on the PC, the Selective
Setup function allows the user to add or remove individual components of the
product. The Selective Setup program is run by selecting Programs->IBM AS400
Client Access Express->Selective Setup from the Windows Start menu. It can
also be run from the Client Access Express Setup that is displayed when the
Add/Remove button is selected within the Windows Add/Remove Programs utility.
B.3.6 Creating a custom install image

Administrators may want to control which Client Access Express for Windows
functions their users can install on their PCs. One way they can do this is by
creating a custom install image. One of the enhancements of the Client Access
Express for Windows product is the increased modularity of the installation of the
product. This modularity is aided because the install image for each component is
stored in its own *.CAB file. This also allows the ability to create a custom install
image.
To create a custom install image, follow this process:

1. Copy the Client Access Express for Windows install image into a location
where you can work with it. The default install image is located on the AS/400
system in the directory \QIBM\ProdData\CA400\Express\Install\Image.

2. Once you have this second copy of the install image, begin planning what
functions you do not want to be available for installation.
3. Once you decide which components to remove from the custom install image,
delete the associated *.CAB files from the image. If you do not want a
component to be available for installation, delete its associated files from the
install image directory. By deleting the files, you create a custom install image.
This image can be distributed to the PCs for installation. We recommend that
you do not copy this custom install image back to the AS/400 source directory,
so an original image is still available.
B.3.7 Reinstallation
Client Access Express for Windows offers a Reinstall function. If an event causes
the Client Access code to become damaged, you can use the Reinstall function to
completely reload the entire product. Reinstall is accomplished using the release
upgrade mechanism of the product. Doing this preserves all of the configurations
that are already defined with the client. This only reloads Client Access code and
registry information. If the problem you are experiencing is caused by an error in
the operating system, for example, using this Reinstall function does not resolve
problem. Follow this process:
1. To begin the reinstallation process, open the Windows Add/Remove
Programs utility from the Windows Control Panel.
2. Highlight IBM AS/400 Client Access Express for Windows, and click the
Add/Remove button.
3. This brings up Client Access Express Setup, as shown in Figure 203. Select
the Reinstall option, and click the Next button.
Figure 203. Client Access Express Setup
This initiates the Upgrade Client Access Express process, the beginning of
which is shown in Figure 204 on page 348. In this case, the source directory is
at the same code level of Client Access Express for Windows as that which is
installed on the PC. This window states that it accomplishes the re-installation

by upgrading from V4R4M0 to V4R4M0. If the code level in the source
directory changed since the product was installed on the PC, an actual
upgrade takes place.
Figure 204. Upgrade Client Access Express for reinstallation
The upgrade process displays a dialog reminding the user of the licensing
requirement of Client Access Express for Windows, which is followed by the
window shown in Figure 205 on page 349. This prompts the user for the type
of upgrade they want to perform. The options are either Basic or Selective.
The Basic Upgrade option upgrades the same components of Client Access
Express for Windows that are currently installed on the PC. The Selective
Upgrade option offers the ability to select components to be removed or added
as part of this process.

Figure 205. Type of Upgrade selection
As shown in Figure 206, the user is now informed of which components of

Client Access Express for Windows will be upgraded.
4. Continue the process by clicking the Next button.
Figure 206. Start Upgrade settings
After all the components are upgraded, Client Access Express for Windows is
now reinstalled on the PC. The upgrade process offers the options to view the
Readme file and to add the program shortcut for Client Access Express for
Windows to the desktop again.

5. To complete the re-installation, click the Finish button on the last dialog
display. The PC reboots.
B.4 Uninstalling Client Access Express from the PC

To uninstall Client Access Express for Windows from the PC, use the Windows
Add/Remove Programs utility. This is located in the Windows Control Panel.
Perform the following tasks:
1. When you open the Windows Add/Remove Programs utility, select IBM AS400
Client Access Express for Windows.
2. Click the Add/Remove button at the bottom of the window.
3. Select the Uninstall option from the Setup window, and select the Next
button. A warning appears and asks you to close all other Windows programs.
4. A display appears that lists the components of Client Access Express for
Windows that are installed and are to be uninstalled. Click the Uninstall
button to start the process of removing the files and registry entries.
After that process is finished, the uninstall is completed by rebooting the PC as

prompted.
B.5 Service Packs

A PTF consists of a single module or multiple modules that replace defective
code or bring enhancements to the licensed program. With the other clients
(except Client Access for Windows 95/NT), several PTFs were installed and an
index file (QPTFIDX) was maintained to check for updates whenever the update
function was running. The main disadvantage of this method is that there was a
large number of combinations of code possible that made the support difficult.
Indeed, when PTFs are available individually, there is no guarantee that
customers will apply all the necessary PTFs.
Instead of rolling out many single PTFs, the Windows 32-bit clients (Client Access
for Windows 95/NT and Client Access Express for Windows) merge several PTFs
into a single PTF that we call a Service Pack . Having a single level of code makes
the support more effective and easier to administer. With the Service Pack
structure, it can more quickly be determined if the fix that a customer requires is
in the last Service Pack that they applied.
On the other hand, a potential disadvantage is that the Service Pack may be too
large to be downloaded through the traditional Electronic Customer Support
(ECS) mechanism. A new method of delivering PTFs through the Internet
removes this disadvantage. The new AS/400 Internet PTF Downloads (iPTF)
facility allows you to select, order, and download AS/400 PTFs over the Internet.
Before you can order PTFs over the Internet and to use the AS/400 Technical
Support site, you must register on the Web at (see Figure 207 on page 351):
http://as400service.rochester.ibm.com/supporthome.nsf/home/Internet+PTF+
Downloads
Or, go to http://as400service.rochester.ibm.com and click Fixes Drivers and

Updates.

Figure 207. iPTF Web site
There are two forms of Service Packs, each of which is delivered differently.
These include:
• AS400 form: Even if it is called a Service Pack, it looks like others PTFs. You
can get it from a cumulative package, an order you place through ECS, or
directly from the iPTF facility. As with other PTFs, you have to load and apply
it on your AS/400 system. For more information on PTFs, see 5.5 "What are
PTFs and Why Do I Need Them?" in AS/400 Basic System Operation,
Administration, and Problem Handling, SC41-5206. After applying the Service
Pack, the install image files are placed in the directory:
\QIBM\ProdData\CA400\Express\Service\Image.
• PC form: The Service Pack is an executable file that you have to download
from an FTP server. For your convenience, you can find a Service Packs link
on the Client Access home Web page. This executable file is a self-extracting
file that explodes the install image files in the directory where it was launched.
Regardless of the form, the Service Pack is identified by the same name (SP + a
5-digit number) and creates a directory with the same install image files in it.
Tip
You can be notified when a new Service Pack is available by filling in the
Service Pack Notification Form available in the Service Packs link on the Client
Access home Web page at: http://www.as400.ibm.com/clientaccess/

Appendix C. AS/400 Operations Navigator
AS/400 Operations Navigator is a graphical user interface (GUI) that provides
end users with an Explorer-type view of the AS/400 resources. It is designed to
fully integrate with the client desktop in the Windows environment. This is an
advantage for administrators and for end users who do not have an extensive
knowledge of the AS/400 Control Language commands. This appendix covers the
functions that Operations Navigator offers in Client Access Express.
C.1 New packaging of Operations Navigator

Since V3R2M0 Client Access of Windows 95/NT, AS/400 Operations Navigator
has been packaged into separately installable sub-components as shown in
Figure 208. If you use the typical installation options, the options installed are:
• Operations Navigator Base Support
• Basic Operations (messages, printer output, and printers)
To install additional sub-components, you need to use the Custom option when
you first install Client Access. If you already installed Client Access on your PC,
use the Selective Setup to install the additional sub-components.
Figure 208. AS/400 Operations Navigator - Component Selection window
The available sub-components are:

• Operations Navigator Base Support: This sub-component provides the base
support for the AS/400 Operations Navigator.
• Basic Operations: The Basic Operations sub-component includes functions
that allow you to work with messages, printer output (spooled files), and
printers on the AS/400 system. You can also allow printers to be shared with
Windows clients in your network through AS/400 NetServer.

• Job Management: The management of user and server jobs on the AS/400
system is provided by this sub-component.
• System Configuration: You need to install this sub-component to view the
existing hardware (including the operational status of the hardware resources)
and software (including the version and release level) installed on your current
AS/400 system.
• Network: Selecting this sub-component provides you with networking
functions such as working with the AS/400 TCP/IP configuration, configuring
new communications interfaces using wizards, working with the TCP/IP
servers, and so on.
• Security: You can secure your AS/400 system by going through a security
wizard provided by this option. It also allows you to configure security and
auditing system values.
• Users and Groups: This option provides the ability to administer users and
groups on the AS/400 system. You can create, delete, copy, or change the
user and group properties.
• Database: Database functions include the ability to create, edit, and display
database tables, create views of data, create and run SQL scripts, and
monitor SQL performance. You can also create and manage other database
objects such as journals, aliases, procedures, and user-defined functions and
data types.
• File Systems : The File Systems folder in the navigation tree allows you to
display and manage the AS/400 file system. You can set permissions on the
file system objects. It also includes the ability to create and manage AS/400
NetServer file shares.
• Multimedia: If you are using the Ultimedia System Facilities (USF) application
on your AS/400 system, this function provides you with the capability to store
and share multimedia data such as audio and video objects.
• Backup : The scheduling of backup tasks on the AS/400 system can be done
by using the Backup function in Operations Navigator. Daily, weekly or
monthly backup policies are changed easily by using the properties pages.
• Application Development: Using the Application Development function, you
can work with interprocess communication, kernel message queues, and so
on.
• Management Central : Management Central comprises a suite of systems
management functions that allow AS/400 administrators to manage multiple
systems more efficiently. Examples of the functions include system
monitoring, running remote commands, managing and distributing software
fixes (PTFs), file system object packaging and distribution, performance data
collection, and scheduling of Management Central tasks.
• Application Administration : AS/400 administrators can control the
availability of functions in the Operations Navigator using the Application
Administration tool. You can restrict specific functions from use by individuals
or groups of users. Client Access applications, such as Data Transfer, can
also be restricted using Application Administration.
It is important to note here that the functions available in Operations Navigator

vary between different release levels of Operating System/400. For example, the
Server Job item under the Job Management function is only available in Version 4

Release 4 of Operating System/400. To determine the functions supported by
your current version of Operating System/400, refer to Appendix A of AS/400
Client Access Express for Windows: Implementing V4R4M0 , SG24-5191.
C.2 Using Operations Navigator

As you compare your screens with ours, you may find some of the functions
missing from your Operations Navigator hierarchy tree. The most likely reason,
which we mentioned earlier, is that the function is not supported by your current
Operating System/400 release level. There are other reasons that may cause a
function or item to be missing from the hierarchical tree. They are:
• The item is not selected during the installation. As mentioned earlier, the
functions in Operations Navigator are packaged into different
sub-components. Perform a selective installation if the item is not installed.
• The function is restricted by Application Administration. AS/400 administrators
can control functions or applications available to users and groups on a
specific AS/400 system.
• The function does not support a Secure Socket Layer (SSL) connection. Some
functions in Operations Navigator do not support SSL connection. Ultimedia
System Facilities (USF) is an example of such a function.
In this section, only some useful functions of Operations Navigator are explained.
For an explanation on Operations Navigator, refer to Chapter 6 of AS/400 Client
Access Express for Windows: Implementing V4R4M0, SG24-5191.
C.2.1 Managing AS/400 Connections

The standalone AS/400 Connections display in the older releases of the Client
Access for Windows 95/NT is now integrated into the Operations Navigator. This
eliminates the need for the AS/400 administrator or operator to launch a separate
application to work with the AS/400 connections.
There are two ways to create a new environment or to add a new AS/400
connection to the existing environment. In the first method, select the default
environment known as My AS/400 Connection located on the left side of the
Operations Navigator window. Then, right-click, and select Add AS/400
connection or Environments in the context menu that appears. The other
method is to use the option under the File menu.
You do not need to specifically add an AS/400 connection in Operations

Navigator. In the Express Client, an AS/400 connection is automatically created
when you use a Client Access application. For example, if you are using the
PC5250 to connect to an AS/400 system, and you already configured the
connection in the PC5250 application, this connection is automatically available
to other applications provided by the Express Client.
AS/400 Operations Navigator 355

Figure 209. AS/400 system context menu
When you highlight your AS/400 system and right-click, a context menu appears,
as shown in Figure 209. The actions in the context menu vary depending on the
authority of the user that signed on. Apart from authority, actions in the context
menu also depend on the availability of the function in Operations Navigator.
Therefore, your context menu may not be exactly the same as the one shown in
Figure 209.
C.2.1.1 Collection Services

The Collection Services action allows you to collect performance data for your
AS/400 system. It is only available when Management Central is installed on your
PC. When you start a collection service, the Start Collection Services task is
created in the Task Activity under the Management Central navigation tree. The
options provided are described in the following sections.
Start Collecting
To start the performance data collection, select Start Collecting from the context
menu. This triggers the Start Collection Services dialog box as shown in Figure
210 on page 357.
In the General page of the dialog box, you can specify the location to store the
collected performance data. By default, the collections are stored in the
Performance Data library (QPFRDATA). You can change the location by entering
the path of the library directly into the field or by using the Browse button to
search for the library on the AS/400 system.
Collections can be cycled by setting the two fields under the Cycling portion. For
example, if you set the Time to synchronize cycle to 12:00 AM and the Frequency
to cycle collections to six hours, the first cycle begins at 6:00 AM. Subsequent
cycles continue every six hours. A collection that is started on the AS/400 system
can be cycled by enabling the Cycle collection if already started option.

Figure 210. General page
The Default collection interval specifies the interval of the collection for
categories that do not have a specific collection interval defined in the Data to
Collect page. You can determine how long you want to keep the collected data on
the AS/400 system by specifying the retention period in terms of hours or days.
Select Permanent if you do not wish to delete the collected data from the AS/400
system. Enable the Create database files during collection option if you want
the system to generate database files automatically for the collection.
The Data to Collect page, see Figure 211 on page 358, shows what information is
collected. A collection profile determines what data is collected and the collection
frequency for each category. You can select any of the IBM-supplied profiles
(Standard, Minimum or Standard plus protocol), or you can create your collection
profile by selecting Custom.
When Custom is selected, you can easily define the categories of data for
collection by selecting them from the Available categories list and clicking the
Add button to add them into the Categories to collect list. At any time, you can
exclude an item from the Categories to collect list by using the Remove button.

Figure 211. Data to Collect page
Stop Collecting
When you select the Stop Collecting option, the window shown in Figure 212
appears and displays a list of the AS/400 systems with Collection Services
started. To stop the collection, select the desired AS/400 system, and click OK.
Figure 212. Stop Collection Services window
Status
To check whether Collection Services is started on a specific AS/400 system,
select Collection Services->Status. This brings up a window similar to the one
shown in Figure 213 on page 359. Use the Refresh button to update the window
when necessary.

Figure 213. Collection Services Status
C.2.1.2 Inventory
The Inventory action provides you with the capability to collect a list of hardware
resources, software products, and fixes on the AS/400 system. When you select
Inventory->Collect, a window appears as shown in Figure 214 and allows you to
specify the type of inventory (Hardware, Software, or Fixes) to collect. Note that if
you select Fixes inventory, the Software inventory is automatically selected.
Click OK if you want the inventory collection to begin immediately. The Schedule
button invokes the Management Central Scheduler where you can specify the
date, time, and frequency for the collection.
Figure 214. Collect Inventory
Other options available under the Inventory action include the Search function,
which allows you to search for a specific item in the Hardware, Software, or Fixes
inventory. You can also use the Export function to save the inventory into a PC
file with formats such as HTML (HyperText Markup Language), CSV (Comma
Separated Variable), XLS (Microsoft Excel 97), or TXT (Text).

C.2.1.3 Fixes (PTFs)
The Fixes function consists of the following actions:
• The Compare and Update action provides a wizard, which assists you in
comparing the fix levels between a model system and one or more target
systems. The comparison results display the fixes that are missing from each
of the target systems.
• You can easily install fixes on the AS/400 system by going through the
Installation wizard, which prompts you for the details of the fixes to be
installed. Note that this option allows you to install fixes on more than one
AS/400 system.
• Use the Clean up option to delete save files and cover letters for specific fixes
or all fixes.
• The Advanced option includes actions such as Cancel Actions, Uninstall, and
Install Permanently. Select Cancel Actions if you want to cancel the restart
action such as install or uninstall fixes at the next restart of the AS/400
system. For both the Uninstall and Install Permanently options, a wizard walks
you through the entire process.
C.2.1.4 Run Command

The Run Command dialog box appears when you select this option from the
AS/400 context menu. Under the General page, you can issue a command that
can be used in the AS/400 batch environment and click the Check Syntax button
for verification. You can also select the command from a list of commands that
you previously ran using the Run Command option. To do so, click the Previous
Commands button.
Select OK to run the command. A task is created. To view the status of the task,
select Task Activity under the Management Central hierarchical tree. Highlight
the task, right-click, and select Status from the context menu.
Figure 215. Run Command dialog box
The Options page (Figure 215) allows you to define how you want to handle the
job log and inquiry messages for the command. By default, the system does not
keep a job log unless the command failed.

C.3 Operations Navigator functions
This section briefly explains the following Operations Navigator functions:
• Basic Operations
• Job Management
• Configuration and Service
• Network
• Security
• Users and Groups
• Database
• File Systems
• Multimedia
• Backup
• Application Development
C.3.1 Basic Operations

The Basic Operations function consists of three sub-functions as shown in Figure
216. These sub-functions enable you to work with messages, printer outputs
(spooled files), and printers on a specific AS/400 system.
Figure 216. Basic Operations function
C.3.1.1 Messages
The AS/400 Send Message (SNDMSG) command is now available in a GUI
format. To trigger the send message dialog box, right-click on Messages under
the Basic Operations hierarchy tree. Select Send Message from the pop-up
menu. The Send Message dialog box appears as shown in Figure 217 on page
362.

Figure 217. Send Message dialog box
C.3.1.2 Printer Output

The Printer Output function refers to spooled files on the AS/400 system. By
default, the spooled files that belong to the user who signed on to the specific
AS/400 system are displayed. The Printer Output list includes such information
as:
• The Output name, which is equivalent to the spooled file name
• User-specified data that describes the contents of the spooled file
• The User to whom the spooled file belongs
• The Status of the spooled file such as Ready, Held, and so on
• The writer name shown under the Printer column if the spooled file is
associated with a writer
• Pages per copy, which defines the total number of pages of the spooled file
• Copies left, which shows the number of copies to be printed
• Time created, which refers to the spooled file creation time
• Date created, which refers to the spooled file creation date
As in the previous releases, when you double-click the spooled file, the AFP
viewer is launched to display the contents of the spooled file. Dragging and
dropping printer output is also possible. For example, you can drag a printer
output from one printer to another printer on the same AS/400 system. If you
have two or more AS/400 systems in your network, where TCP/IP is configured
and LPR/LPD is working, you can even drag and drop your printer output from
one AS/400 system to a printer on another AS/400 system.

When you drag and drop a printer output to the PC desktop, the text data of the
output file is copied to the PC and a desktop icon is created. This enables you to
edit the contents of the printer output by using a PC application such as WordPad
or a Lotus 123 spreadsheet. The following example illustrates the process of
modifying the printer output using the Notepad application on the PC:
1. Select Printer Output under the Basic Operations hierarchical tree.
2. Highlight the desired output file. Drag and drop the output file to any open area
of the desktop. A desktop icon (Figure 218) is created for the output file.
Figure 218. Printer Output desktop icon
3. Open the Notepad application by selecting the Start button. Follow the path
Programs->Accessories->Notepad .
4. Select Open under the File menu. Select the output file (normally the printer
output file name followed by the job number, for example, QPJOBLOG008092.txt)
under Desktop, and click the Open button.
You can now edit the contents of the file. When you are finished, you can choose
to print the file to a local printer, save it back to the desktop, or save it to another
location, such as a floppy diskette. An example of a modified printer output file
(note the last line of the file contents) is shown in Figure 219.
Figure 219. Modifying Printer Output
C.3.1.3 Printers
The Printers sub-function allows you perform a variety of tasks such as working
with a printer output queue, starting or stopping, holding or releasing a printer,
and so on. In Figure 220 on page 364, the printer with the hand symbol indicates
that it is printer shared by AS/400 NetServer. The Printer sub-function has been
enhanced to include AS/400 NetServer printer shares. You can even create a
new printer share by selecting Sharing->New Share from the context menu of a
printer.

Figure 220. Working with printers
C.3.2 Job Management

Job Management is broken down into two main items: jobs and server jobs
(Figure 221). These terms are defined in the following list:
Figure 221. Job Management function
Jobs The Jobs function allows you to work with the AS/400 jobs. It provides a
combination of the functions available in the Work with Active Jobs
(WRKACTJOB) and Work with User Jobs (WRKUSRJOB) commands.
Server Jobs
the Server Jobs function displays a list of jobs that are part of a specific
AS/400 server application. An example of a server job is the AS/400
NetServer. You can easily see who is currently using the server application
by looking under the Current User column.
You can tailor the jobs display to meet your requirements. For example, you can
sort the jobs according to job name by clicking on the column heading. You can
also specifically view a user’s job. To do so, highlight the Server Job item in the
hierarchy tree (Figure 222 on page 365). Select Include from the Options menu.

Figure 222. Server Jobs management
The Include dialog box appears. Click on the button next to the User field. This
brings up another dialog box similar to the one in Figure 223. Select User and
type in the name of the user profile. The Server Jobs list is automatically
refreshed to show the jobs associated with the user profile that you specify.
Figure 223. Include option dialog box for Server Job management
Highlight one of the jobs, and right-click. The context menu appears, which allows
you to perform such actions on the job as:
• Display the printer output
• Display the job log
• Reply to messages
• Hold the job

• Release the job
• Move the job
• Delete the job
• Display the properties of the job
C.3.3 Configuration and Service

The Configuration and Service function allows AS/400 administrators to view the
list of hardware and software installed on the current AS/400 system. It is broken
down into two major components as shown in Figure 224:
• Hardware Inventory
• Software Inventory
You may have additional components such as Fixes Inventory and Collection
Services under the navigation tree of Configuration and Services. These two
components are available if you have Management Central installed on your PC.
In this section, we do not cover these two components. However, you may want
to refer to C.2.1, “Managing AS/400 Connections” on page 355, where both the
Collection Services and Fixes functions are briefly discussed.
Figure 224. Configuration and Service Function
C.3.3.1 Hardware Inventory

The Hardware Inventory corresponds to the AS/400 Display Hardware Resources
(DSPHDWRSC) command. It shows a list of the hardware with its operational
status. In the DSPHDWRSC command, you are required to specify the type of
hardware resource that you want to display. Similar options apply in Operations
Navigator. You can view the hardware installed according to the following
categories:
• All hardware
• Communications
• System adapters
• LAN resources
• Workstation resources
• Processor information
• Storage devices
Additional information, such as physical location and logical address of the

individual hardware, can be displayed by selecting the Properties option from the
context menu as shown in Figure 225 on page 367.

Figure 225. Hardware Inventory list
C.3.3.2 Software Inventory

You can view the software resources on a specific AS/400 system by selecting
Software Inventory under the Configuration and Service hierarchical tree. You
can choose to view a list of all products, installed products or supported products.
This corresponds to the AS/400 Display Software Resources (DSPSFWRSC)
command.
C.3.4 Network
AS/400 Operations Navigator provides support for many Network functions
(Figure 226 on page 368). It supports such functions as working with your AS/400
TCP/IP configuration, configuration wizards for new communication interfaces,
setting up IP filters, managing AS/400 network servers, IBM Network Station
configuration, and so on.

Figure 226. Network function
C.3.4.1 Protocols
Basic TCP/IP functions are provided under the Protocols function. You can start
or stop TCP/IP on the AS/400 system, configure TCP/IP, and so on. Select
TCP/IP under the Protocols navigation tree. Right-click, and the context menu
appears as shown in Figure 227.
Figure 227. TCP/IP actions
The available actions include:

• Interfaces: Displays the status of the TCP/IP interfaces currently configured
on the AS/400 system. You can open, delete, start, or stop an interface by
selecting it from the list and clicking the relevant buttons.
• New Interface: Allows you to create a new TCP/IP interface for a local area
network (LAN), wide area network (WAN), or circuitless connection, with the
help of wizards.
• Start: Allows you to start TCP/IP on the specific AS/400 system immediately.
• Stop : Allows you to stop TCP/IP in a controlled or immediate manner.
• Ping (from Utilities in the context menu): Allows you to verify a TCP/IP
connection. Doing so brings up a Ping dialog box.

• Properties (from the context menu): Displays the TCP/IP Properties window
(Figure 228). From this window, you can change the Host Domain Information,
add or remove entries from the Host Table, set Port Restrictions, and so on.
Figure 228. TCP/IP Properties window
C.3.4.2 Servers
The Servers function allows you to configure and manage both the TCP/IP and
Client Access servers. For example, you can easily start or stop the AS/400
system by selecting the relevant action from the context menu as shown in Figure
229 on page 370. The list displayed also shows the status of the servers.
Configuration wizards are included for TCP/IP servers such as Dynamic Host
Configuration Protocol (DHCP), Domain Name Server (DNS), Directory Services,
and so on. The Properties action in the context menu also allows you to specify
options such as automatically starting the server when TCP/IP on the AS/400
system is started. More information about these topics can be found in AS/400
TCP/IP Autoconfiguration: DNS and DHCP Support, SG24-5147.

Figure 229. AS/400 NetServer context menu
Since V4R2M0, the Client Access host servers automatically start when TCP/IP
is started. You can change this default setting by unchecking the Start when
TCP/IP is started option in the Properties page of the individual Client Access
host servers. For such servers as Net Print and Sign On, you can even specify in
which subsystems you want the server jobs to run.
You can view a list of jobs associated with a specific server. For example, to view
the TELNET server jobs, select TELNET from the TCP/IP Servers list.
Right-click, and select Server Jobs from the context menu. This brings up a
separate window with a list of all jobs that belong to the TELNET server.
C.3.4.3 Internet
When you select the Internet function, a list of functions associated with Internet
applications are displayed as shown in Figure 230.
Figure 230. Internet functions
Note that the list of functions in your Operations Navigator may differ from the
one shown in Figure 230. Applications, such as Firewall and IBM HTTP Server for

AS/400, appear only if the relevant licensed program product is installed on your
AS/400 system.
Using the Internet functions, you can configure and manage an Internet
application server from the Web browser. For example, double-clicking the IBM
HTTP Server for AS/400 brings up the configuration Web page as shown Figure
231 (assuming that the HTTP Admin server is started). By default, the Web page
is opened using your Windows default browser. You can change the browser to
use by selecting Properties from the context menu of each application.
Figure 231. IBM HTTP Server for AS/400 Web browser configuration
C.3.5 Security
Implementation of security on the AS/400 system is made easy with the help of
the security configuration wizard. To initiate the security wizard, select Security
from the navigation tree. Right-click, and select Configure from the context
menu. The security wizard asks you a set of questions. Based on your answers to
those questions, it generates a set of security recommendations such as those
shown in Figure 232 on page 372 for your AS/400 system.
The wizard also generates two separate reports, one each for the administrator
and the user, that explain the recommendations in detail. At the end of the wizard,
you can apply the security recommendations to the AS/400 system immediately,
or save the recommendations and apply them later.

Figure 232. Summary of security recommendations
Apart from the security wizard, the security function includes options, such as
Authorization Lists and Policies, as shown in Figure 233.
Figure 233. Security function
When you select Authorization Lists under the Security navigation tree, a list of
the existing authorization lists on the AS/400 system appears in the right-hand
panel of the Operations Navigator window as shown in Figure 234 on page 373.

Figure 234. Create authorization list
You can create a new authorization list by selecting New Authorization List from
the context menu. You can also change the permission settings in an existing
authorization list by double-clicking it. This brings up a window similar to the one
shown in Figure 235, which allows you to add or remove users from the list, view
the objects secured by the list, and so on.
Figure 235. Authorization list details
The Policies function is categorized into Audit Policy and Security Policy. You use
the Audit Policy to set system-level auditing control. Double-click Audit Policy to

bring up the Audit Policy Properties window as shown in Figure 236. The System
page allows you to activate auditing of specific actions such as object creation or
deletion, authority adoption in program, and so on. Details of each action are
available in the online help.
You can also turn on object auditing to keep track of all users who access the
object or all objects accessed by a particular user by selecting the Activate object
auditing option. Under the New Objects page, you can specify default auditing for
newly created objects by selecting any one of the options listed.
Figure 236. Audit Policy Properties
The Security Policy Properties window is shown in Figure 237 on page 375.
Configuration and management of security-related system values are made easy
with the help of a graphical user interface. The online help also provides detailed
information on each of the security settings.

Figure 237. Security Policy Properties
C.3.6 Users and Groups

The Users and Groups function (Figure 238) allows you to view and work with All
Users on the AS/400 system, Groups available on the system, or Users Not in a
Group. You can drag and drop users into the groups, and create the same user
profile on another AS/400 system by dragging and dropping the user into the
target system.
Figure 238. Users and Groups function
If you highlight a user from the list, right-click, and select New Based On, you
can create a new user based on the existing user profiles that you selected. This
is shown in Figure 239 on page 376. Using the Personal button, you can enter
system distribution directory data for the user. Using the Networks button, you
can register the user in Lotus Domino (if Lotus Domino for AS/400 software is
installed and configured on your AS/400 system).

Figure 239. Create a new user based on an existing user profile
C.3.7 Database
Creation and management of AS/400 databases are made easier by using the
Database function (Figure 240) in Operations Navigator.
Figure 240. Database function
The available options under the Database navigation tree are Libraries, ODBC
Data Sources, and SQL Performance Monitors. When you select Libraries, a list
of libraries in the user portion of your AS/400 library list is displayed. To add

additional libraries for display, select Libraries. Right-click, and select Select
Libraries to Display. Doing this brings up a window similar to the one in Figure
241.
Figure 241. Database libraries selection
You can either enter the name of the library, or select the library from the list and
click Add. Be aware that the selected libraries are only temporarily added. If you
want to permanently add the libraries, you need to change the user portion of
your library list on the AS/400 system (System Value QUSRLIBL).
The context menu of Libraries also allows you to create a new library. You can
choose to create the library as an SQL collection. An SQL collection consists of a
library, a journal, a journal receiver, a catalog, and optionally a data dictionary.
You can also specify to create the library in another Auxiliary Storage Pool (ASP).
To create a new table, select the library. Right-click, and select New->Table. To
work with an existing table, right-click the selected table, and choose the
appropriate action from the context menu. For example, you can add or remove
columns in existing tables by selecting the Properties action. The Quick View
action allows you to easily view the data in a table. You can even edit the data by
double-clicking the table.
You can create, run, edit, debug, and save SQL statements by selecting Run SQL
Scripts from the Database context menu. If you are not familiar with SQL
statements, you can insert and modify an SQL statement example. To do so,
ensure that the SQL Statement Examples option under View menu is selected
(with a check mark on the left). Then, select the desired statement from the
drop-down list as shown in Figure 242 on page 378, and click the Insert button.

Figure 242. Run SQL Scripts
The Database function also includes the capability to monitor SQL performance.
To create an SQL performance monitor, select SQL Performance Monitors.
Right-click, and select New.
You can perform other tasks such as:

• Create, delete, and display the properties of a view.
• Create, delete, and change journal properties. Start and end table journaling,
add, remove, activate, and deactivate remote journals.
• Create indexes from the Properties window of a table.
• Create, delete, and display the properties of a type.
• Create, delete, and display the properties for external procedures and
functions, SQL procedures and functions, and sourced User Defined
Functions (UDFs).
C.3.8 Integrated File System

The integrated file system (IFS) function in the Operations Navigator consists of
the IFS as well as File Shares (Figure 243 on page 379). The IFS allows you to
work with the files and folders on the AS/400 system. The folders in the IFS are
displayed in a hierarchical directory structure similar to the Windows Explorer
view. You can easily create, rename, delete, drag, and drop folders within and
between AS/400 systems and the PC desktop. Examples of manipulating files
and folders in the IFS are included later in this section.
File Shares shows the AS/400 NetServer file shares. The Open AS/400
NetServer option in the File Share context menu opens up a separate window,
which allows you to work with the AS/400 NetServer. For additional information
on NetServer, refer to C.3.9, “AS/400 NetServer” on page 384.

Figure 243. File Systems function
The available file systems are:

• NFS : This represents the Network File System, which provides the user with
access to data and objects stored on a remote NFS server. An NFS server can
export a network file system, which the NFS clients can mount dynamically.
• QDLS : The document library services file system provides access to
documents and folders on the AS/400 system.
• QFileSvr.400: This file system provides access to other file systems that
reside on remote AS/400 systems.
• QLANSrv: The OS/2 Warp Server for AS/400 file system provides access to
the same directories and files that are accessible through the OS/2 Warp
Server for AS/400 licensed program. Users of the OS/2 Warp Server for
AS/400 applications can use the same data as the clients of an OS/2 Warp
Server.
• QNetWare: The NetWare file system provides access to local or remote data
objects that are stored on a server that runs Novell NetWare 4.10 or 4.11. It
also provides access to standalone PC servers running Novell NetWare 3.12,
4.10, 4.11, or 5.0.
• QNTC: This is the file system for Windows NT Server. You can access data
and objects that are stored on a server running Windows NT 4.0 or higher. It
includes the accessing of data on a Windows NT Server that is running on an
Integrated Netfinity Server.
• QOpenSys : The Open Systems file system is compatible with the UNIX-based
open system standards such as POSIX and XPG.
• QOPT: This is the Optical file system that provides access to stream data
stored on an optical media.
• QSYS.LIB: This is the library file system that supports the AS/400 library
structure by providing access to AS/400 database files and all other object
types that the library supports or manages.
• "root" : This is the most basic file system. It has the characteristics of the Disk
Operating System (DOS) and the OS/2 file systems.
• UDFS : This is a User Defined File System, which resides on the Auxiliary
Storage Pool (ASP) of the user’s choice.

Note
Some of the file systems mentioned in the previous list are not a standard part
of Operating System/400. For example, the QLANSrv file system is only
available when the OS/2 Warp Server for AS/400 licensed program is installed
on the AS/400 system.
C.3.8.1 Creating, sharing, renaming, and deleting folders

The following example goes through these procedures:
• Creating a new folder
• Copying files into the folder
• Renaming the folder
• Sharing the folder
• Deleting the folder
• Dragging and dropping files and folders
• Setting up and editing permissions of file system objects
C.3.8.2 Creating a new folder

You can create a new folder in any of the file systems as long as you are
authorized to it. In this section, we create a folder under the root directory.
Perform the following steps:
1. Expand the hierarchy tree of the File Systems function.
2. Select Integrated File System. A list of the available file systems is displayed
as shown in Figure 244.
Figure 244. File systems management
3. Highlight the Root file system, and right click.

4. Select New Folder. A dialog box similar to the one shown in Figure 245 on
page 381 appears.

Figure 245. New Folder dialog box
5. Enter the name of the new folder, and click OK.
The list is automatically refreshed to include the newly created folder. You can
find your folder located at the end of the list.
C.3.8.3 Copying files into the folder

Now that you created the folder, you can start copying files into it by performing
these steps:
1. Open the Windows Explorer. Select the files to be copied. Right-click, and
select Copy from the context menu as shown in Figure 246.
Figure 246. Copying files in Windows Explorer
2. Select your folder in the hierarchical tree root, and click the Paste button
(Figure 247 on page 382). The AS/400 Operations Navigator - Copying
window appears and displays the copy process of the files.
Once the copy completes, the list is refreshed automatically.

Figure 247. Copying files into a folder using the Paste button
You can also copy files within the AS/400 file system. For example, you can
create a new folder in the root file system and copy the installation files of Client
Access Express from the QCA400 folder to your new folder.
C.3.8.4 Renaming the folder

In some cases, you may want to rename a folder in the IFS. To rename a folder in
the emulation environment, you issue the Rename Object (RNM) command. Then,
you may use the Work with Objects Link (WRKLNK) command to check that the
folder is renamed correctly.
In Operations Navigator, to rename a folder in the file system, simply highlight it.
Right-click, and select Rename from the context menu. This triggers a dialog box
similar to one shown in Figure 248. Enter a new name for the folder, and click OK.
If you specify the same name as another folder, you receive an error message
informing you that the folder already exists.
Figure 248. Renaming a folder in the file system
C.3.8.5 Sharing the folder

You can share a folder in the AS/400 file system using the AS/400 NetServer File
Shares capability. A file share is a unique name assigned to the shared folder in
the IFS directory that allows remote users or applications to access it. To share a
file or folder, highlight it, right-click, and select Sharing from the context menu.

You can also create a new file share using the New Share button (Figure 249) on
the toolbar.
Figure 249. New share button
The ability to create a file share depends on the authority of the user profile used
to sign on to the AS/400 system. The user must at least have the *IOSYSCFG
special authority granted in the user profile. When the file share is defined as
read only, the AS/400 directory permission is used to determine the accessibility
of a file share to a user. If the file share is set to Read/Write, both the authority in
the AS/400 user profile and the directory permission apply.
C.3.8.6 Deleting the folder

To delete a folder, select the folder, right-click, and select Delete. You can also
use the Delete button located on the toolbar to delete a folder (Figure 250).
Figure 250. Delete button
C.3.8.7 Dragging and dropping files and folders

You can easily drag and drop objects in the file system within one AS/400 system
to another AS/400 system or even to the PC desktop. For example, to drag a
folder from the root to the PC desktop, simply click on the folder. Drag and drop it
in any open area on the desktop.
Unlike a shortcut, when you drag and drop an object from the file system to the
PC desktop, the contents of the file or folder are duplicated.
C.3.8.8 Setting up and editing permissions of files system objects

Permissions can be set on the file system objects to restrict users from accessing
them. You can view or change the current permission settings of a file or folder by
selecting Permissions from the context menu. The Permission dialog box, shown
in Figure 251 on page 384, is displayed.

Figure 251. Setting permissions for file system objects
C.3.9 AS/400 NetServer

AS/400 NetServer enables an AS/400 system to provide file and print serving in a
Windows network without needing to install additional hardware or software on
the AS/400 system. AS/400 NetServer uses the Server Message Block (SMB)
protocol to communicate with the network.
The directories that are shared by AS/400 NetServer reside in the integrated file
system (IFS) on the AS/400 system. They are protected by AS/400 security. They
can be saved with normal AS/400 methods during normal AS/400 save
operations. There is no need for additional backup programs or backup
strategies. This makes AS/400 NetServer an ideal platform for file and print
serving needs even without Client Access Express being involved.
The process of sharing directories and printer output queues with AS/400
NetServer is similar to the way you share resources with Windows 95, Windows
98, and Windows NT.
To open AS/400 NetServer in Operations Navigator, double-click the options

Network->Servers->TCP/IP->AS/400 NetServer. This opens up a new window
as shown in Figure 252 on page 385.
If you double-click on Shared Objects, Operations Navigator shows all configured

shares for directories and output queues. Even if you have never used AS/400
NetServer before, some shared objects are already in the list. This list includes
shares for the QIBM directory, which contains installable code for Client Access
Express for Windows, and the QCA400 directory where the installable code of the
other Client Access clients is stored. These shares can be used to install a
version of Client Access to a PC by using a network drive rather than diskettes or
a CD-ROM.

Figure 252. New file share
Right-click on Shared Objects, and select New->File from the pop-up menu.
This opens another window.
Figure 253. Creating a file share
In the display shown in Figure 253, you give the share a Share name by which it
will be known in the network. Access can be Read only or Read/Write.
If the share is defined as Read/Write, normal AS/400 security is in effect, and the
authority of the AS/400 user profile and the permissions set for the AS/400
directory are used.
If a share is set to Read Only, it does not matter how high the authority of the user
accessing the shared directory is or what permissions are set for the directory for
this share. Only read access is allowed. Files in this directory cannot be altered,
moved, or deleted. If AS/400 permissions do not allow a user to even view files in
that directory, that is not possible either.
Maximum number of users allows you to limit the number of users that can
concurrently use the share.

Path name is the path to the shared directory or library. You can enter the path
directly, or you can click the Browse... button to obtain a list of the IFS where you
can select the path (Figure 254).
Figure 254. Browsing the IFS
You can select a top-level directory or click on the plus (+) sign in front of a
directory name to reach a deeper level. You can select folders under QDLS only if
your user profile is added to the System Distribution Directory on the AS/400
system. Likewise, a share for QDLS can only be used by users who are in the
System Distribution Directory. You can select QSYS.LIB, libraries under
QSYS.LIB, and files (physical and logical) in a library to be shared.
If you share an AS/400 physical or logical file that contains several file members,
it appears on the PC client as a directory containing files. The files displayed on
the PC are actually the AS/400 file members.
Remember that you have to explicitly share a directory or library on the AS/400
system to make it available through AS/400 NetServer. Unlike the Network Drive
of Client Access for Windows 95/NT, the entire IFS including QSYS.LIB is not
visible to all clients, only those objects that are shared.
Highlight the directory to be shared, and click OK. This brings you back to the
display in Figure 253 on page 385.
The Text Conversion tab of this notebook is only available with AS/400 NetServer
Version 4 Release 4 and higher. If you click on the Text Conversion tab, you see
the display shown in Figure 255 on page 387.

Figure 255. Text Conversion
On this display, you can specify AS/400 file types that are automatically
converted from EBCDIC to ASCII and vice versa. With text conversion enabled,
AS/400 EBCDIC data is automatically translated to ASCII when it is transmitted to
the PC to be viewed, for example, in Windows Notepad.
Text conversion is disabled when the option Allow file text conversion is
unchecked. The Code page parameter defines the ASCII code page used for
converting data for this share.
The text conversion is triggered by file extensions. For example, an AS/400 file
member is displayed in the Network Neighborhood with the file extension MBR.
To enable automatic text conversion for file members, you have to type the letters
MBR in the entry field and click the Add button next to it.
Click OK to complete the configuration.
Once a file share is defined, you can right-click on its name to get a context menu
with all the options available for that share (Figure 256 on page 388).

Figure 256. AS/400 NetServer share context menu
You can change the Properties of the share and the Permissions for the AS/400
directory. For example, you can change the file share property from Read/Write to
Read only access. And you can stop sharing the resource. Be careful if you do
that. There is no confirmation for this action. Once sharing is stopped, the share
is removed from the list. This removes the share permanently, but not the directory.
To remove the directory itself, select this path in Operations Navigator File
Systems->Integrated File System->Root .
The second method of sharing directories is from within the File Systems function
in Operations Navigator. There is a sub-function called Integrated File System .
This approach has the advantage that you are already exploring the file system
and can decide which parts to share, as opposed to other methods where you
need to know in advance what you want to share.

Figure 257. Creating a share from file systems
The procedure to share a directory is identical to the other method using the
AS/400 NetServer function of Operations Navigator.
Notice in Figure 257 that some of the directories (for example, QIBM) have a
hand symbol, which indicates that they are shared.
C.3.10 Backup
You can schedule daily, weekly, or monthly backup on the AS/400 system using
the Backup function in Operations Navigator. The Properties page of the three
backup policies allows you to define options such as the type of data to save, the
date and time to run the backup job, the backup media, and so on.

Figure 258. Monthly backup properties
C.4 Function Availability

As discussed in C.2, “Using Operations Navigator” on page 355, the availability of
functions in Operations Navigator depends on a few factors. Function Availability
helps you to determine the real reason why a function is missing from the
Operations Navigator tree. To display the dialog box for Function Availability, on
the Operations Navigator menu bar, select View->Function Availability.

Figure 259. Function Availability dialog box
The Function Availability dialog box, in Figure 259, shows the Operations
Navigator tree hierarchy elements for all configured AS/400 connections, and the
explicit reasons why any of the elements are hidden. An element in the
Operations Navigator can be hidden due to one of the following rational:
• Optional installable: Several functions of Operations Navigator are changed
to optional installable items in the Express Client. There is a possibility that
the particular function is not installed and, therefore, not shown. It is also
possible that a function is not available due to a corresponding Operations
Navigator subcomponent that is not installed.
• OS/400 release level: The availability of each Operations Navigator functions
depends on the current AS/400 Operating System level. Certain functions,
such as Management Central, requires an OS/400 release of V4R3 and
above.
• Application Administration restriction: Since the Application Administration
has the ability to deny users or groups from certain functions in Operations
Navigator, the items in a particular tree hierarchy can be hidden.
• Client Access policies: You can use the Client Access Policies to restrict
users from using the Operations Navigator entirely.
• Secure Socket Layer (SSL): With the SSL enabled in the Express Client, you
can now communicate using SSL. If you are using SSL to connect to the
AS/400 system, other functions that do not support SSL are not shown.
• Third-party Plug-in self-imposed restriction : If you have any third-party
plug-ins installed, the functions can be restricted by the product itself.
If a function is restricted in Operations Navigator, the sub-functions are also

restricted. For example, if Basic Operations is restricted, the Messages, Printer
Output, and Printers are also restricted.

Appendix D. Complementary products
Depending on the environment supported, some or all of the products listed are
needed. This appendix lists the supplementary and complementary products for
both the SSA eBPCS environment and the AS/400 system.
D.1 AS/400 licensed program products and features

The AS/400 system has supplementary products called licensed program
products (LPP). These products can be a feature to a licensed product or a
licensed product in itself. Most of these features or licensed program products are
chargeable. The cost of these products can be charged by the processor group or
by the number of concurrent uses or users.
Pricing of these products is not shown. These licensed program products should
be discussed with your eBPCS software and hardware providers for the
environment supported.
D.1.1 AS/400 Operating System (OS/400) features

As stated before, these features are add-ons to the operating system. Some or all
may be needed for the eBPCS environment supported.
D.1.1.1 Chargeable
The chargeable items include:
• Print Services Facility/400 (PSF/400) (Feature Code 2691)
• DB2 Symmetric Multiprocessing for AS/400 (Feature Code 2698)
• DB2 Multisystem for OS/400 (Feature Code 2699)
• OptiConnect for AS/400 (Feature Code 2642)
• Media and Storage Extensions (Feature Code 2619, prerequisite feature for
using BRMS/400)
D.1.1.2 Nonchargeable
The following programs are all part of OS/400 and all ship with OS/400
(5769-SS1). They do not need to be ordered separately. However, they all appear
within the AS/400 Software Resources and Licensed Program menus as separate
products:
• 5769-JC1 Java Tool Box for AS/400 (Feature Code 2585)
• 5769-JV1 IBM VisualAge for Java (Feature Code 2586)
• 5769-PM1 Performance Management/400 (Feature Code 2556)
• 5769-TC1 IBM TCP/IP Connectivity Utility (Feature Code 2529)
• AS/400 Integration with Windows NT Server (Version 4) (Feature Code 2692)
• Client Access Express for Windows (Feature Code 2603)
Included in Client Access Express for Windows are Operations Navigator,
Operations Console, and all functions of the Client Access for Windows
licensed program (5769-XW1), except:
– PC5250 emulation
– Printer emulation
– Data transfer

However, the only ones that may be of interest for an eBPCS environment are
listed. The feature codes or licensed program product numbers may change as
the operating system or program product is enhanced.
D.1.2 AS/400 licensed program products

These licensed program products are not necessary, but allow better
management and operation of the AS/400 system and the eBPCS environment.
These licensed program products include:
• 5798-AF3 AFP PrintSuite for OS/400
• 5769-BR1 Business Recovery and Media Services (BRMS/400)
• 5769-AF1 AFP Utilities for AS/400
• 5769-CX2 ILE C for AS/400
• 5769-FNT AFP Fonts for AS/400
• 5769-MG1 Managed Systems Services AS/400
• 5769-PT1 Performance Tools/400
• 5769-PW1 Application Development Toolset for AS/400
• 5769-ST1 DB2 Query Manager and SQL Development Kit for AS/400
• 5769-XW1 AS/400 Client Access Family for Windows
For additional information and a detailed description of these features and

licensed program products, refer to the IBM AS/400 System Handbook,
GA19-5486.
D.2 SSA partner products

The SSA Portfolio strategy delivers individualized systems that provide a
market-defining competitive advantage by leveraging industry-specific,
best-practice models and extensions of business processes across applications.
The current list of solutions can be found at:

http://www.ssaportfolio.com/solutions.html

Appendix E. AS/400 advanced technology
With the announcement of V4R2 and the additional functions provided by V4R3
and V4R4, the AS/400 system offers important new capabilities in key areas such
as Java, Web serving, Lotus Domino, integration with Windows NT, managed
availability, database, and Business Intelligence solutions. The AS/400 system
also continues to be a strong performer in such growing areas as data
warehousing and the Internet.
E.1 Java
Java is a key application development environment for the AS/400 system. As
Java technology evolves from Sun, the AS/400 system takes advantage of the
new functions and features of this environment.
The AS/400 Developer Kit for Java supports Sun's Java 2. With the concurrent
Java support shipped as part of the V4R4 AS/400 Developer Kit for Java, you can
install Java 2 on systems where JDK 1.1.6 or 1.17 are already installed. A Java
Virtual Machine (JVM), which resides below the Technology Independent
Machine Interface (TIMI), enables fast interpretation and execution of Java code
on the AS/400 system. In addition, a type of static compiler is available called a
class transformer, which generates RISC machine code from Java byte codes.
This Java transformer enables the direct execution of Java on the AS/400 system
without the overhead of interpretation.
High-performance Garbage Collection is provided by OS/400 to improve the

performance and the scalability of Java. An advanced garbage collection
algorithm allows Java to scale to the large numbers of objects expected when
running enterprise applications on the server. Over time, Java will become even
more integrated with and tuned for OS/400 to meet the requirements of
performance and scalability on the server without compromising the
cross-platform portability of the rich language.
Other technology included in the AS/400 Developer Kit for Java allows GUI
applications to run on the AS/400 system without modification. This support is
called Remote AWT (Abstract Windowing Toolkit). It intercepts GUI requests
coming from a Java program and re-routes the requests to an attached
workstation running its own Java Virtual Machine (JVM). The workstation
interprets and displays the java.awt graphical components. This allows server
programs, which have graphical interfaces for configuration or tuning, to run on
the AS/400 system without modification.
The OS/400's unique single-level-store architecture is also exploited to give Java

objects on the AS/400 system an advantage that is not available on any other
platform. Java objects on the AS/400 system can be full-fledged system objects
that allow them to be persistent, shared, secure, backed up, and restored. This
allows the AS/400 system to offer persistent Java objects with performance and
support that is unparalleled in the industry. The AS/400 single-level-store
technology permits Java objects to be stored in their object form without the
performance and maintenance overhead of two-level-store operating systems.
Java Deployment Tools provided in V4R4 are aimed at simplifying the

deployment, management, and tuning of Java applications on the AS/400

system. IBM has tested InstallShield's Java Edition product. InstallShield allows
Java application developers to create packages that will install natively on the
AS/400 system. It is the common method used to package and install
applications on other platforms, such as Windows NT. InstallShield on AS/400
makes it easier to port applications to the AS/400 system that are currently
targeted for other platforms. A number of Qshell enhancements and utilities are
provided to support the zipping or unzipping of Java packages. To aid in
performance analysis and tuning of Java applications on the AS/400 system,
support is provided to convert data collected by Performance Explorer into
standard formats used by popular Java performance analysis tools such as
Javation and Hyperprof.
The AS/400 Toolbox for Java is available. Java applets and applications that
access AS/400 programs and data from client workstations (or a Java-enabled
server) can be written using the AS/400 Toolbox for Java. Java classes on the
client can be used to access existing AS/400 applications and data using
low-level APIs. This provides easy entry into Java development while leveraging
what already exists on the AS/400 system today.
With V4R4, the AS/400 Toolbox for Java is enhanced to support the Java
Database Connection (JDBC) 2.0 specification. Support is also added for the
Secure Sockets Layer (SSL) specification so that data between the workstation
and the AS/400 system can be encrypted and the server can be authenticated.
The AS/400 Toolbox for Java in V4R4 also includes an improved application
development environment through the introduction of a new set of tools for
building graphical panels:
• A User Interface Framework has been defined that automatically handles the
exchange of data.
• Developers use data beans that are bound to panel components using tags
that are defined by the Panel Definition Markup Language (PDML).
• The framework can also provide a platform and technology independent
representation of graphical panels based on the Extensible Markup Language
(XML). A pure Java framework for interpreting the XML and constructing user
interface panels based on Java Foundation Classes (JFC) is also provided.
• A resource script converter is provided that converts Windows dialogs to
equivalent Java panels defined in XML.
• A graphical user interface (GUI) builder tool is provided to develop Java GUIs.
This is a WYSIWYG GUI editor tool.
• The ability to call AS/400 programs is provided through a Program Call
Markup Language (PCML) interface that defines the required parameters,
structures, and field relationships.
E.2 Web serving

The IBM HTTP Server for AS/400 makes participating in the world of the Internet
and intranets easy. This product combines the basic functions of a Web server
with expanded functionality that allows for greater flexibility in establishing a Web
presence. HTTP Server performs a variety of functions:

• Acts as a repository for Web pages created with HTML
• Handles the transfer of documents requested from a browser with HTTP
• Supports SSL security protocols for data encryption and server certificate
authorization (HTTPS) when combined with one of the Cryptographic Access
Provider Licensed Programs
• Client authentication using SSL Version 3 through the support of digital
certificates
• Allows Web serving from multiple IP addresses on a single HTTP Server
• Provides an application interface with a Common Gateway Interface (CGI)
• The ability to recognize and present different documents based on the Web
browser used through automatic browser detection
• Allows control of access and error logs
• Provides easy-to-use HTML forms for configuring and administering the server
• Allows multiple servers within the same AS/400 system to balance workload,
content, production, and testing
• Allows you to restrict access based on user name and password, or the
address of the requester
• Support for server APIs that allow the user to extend or customize how the
HTTP Server handles client requests
• Integrates AS/400 security into the Web
• Socks support and SSL Tunneling to improve performance when a proxy
server is used
• Adds performance enhancements, and you have the functionality and security
that your business needs
• SNMP Subagent support, which allows Web server statistics to be forwarded
to a SNMP network manager upon request
• Enhanced log reporting, which provides the ability to define, generate, view,
and maintain reports using a graphical interface based on report templates
• Support of the new standard Extended Log File Format has been included to
allow more data to be saved in the access log files (More control over the data
stored in these files is also provided.)
• Web server error logs now contain messages in the customer’s language of
choice
• New APIs are provided that allow third-party management tools to query the
value of certain configurations directives, as well as the Web server’s mapping
rules for a URL
V4R4 provides performance improvements in the AS/400 HTTP Server through

the ability to dynamically cache HTML files in memory so that subsequent
requests for the same file can be handled without the need for a file I/O. Support
for multi-thread CGI programs can also provide improved performance of the
HTML server with V4R4.
V4R4 provides support for Lightweight Directory Access Protocol (LDAP) in the
HTTP Server, which defines a protocol to access directory services on a network.
AS/400 advanced technology 397

A new Domino plug-in is also provided that allows the HTTP Server to access
documents stored in Notes.
AS/400 system Web serving capabilities include support for the IBM WebSphere
family. There are several components in the WebSphere family:
• The IBM WebSphere Application Server provides a framework for consistent,
architected linkage between the HTTP requests and business data and logic.
IBM WebSphere Application Server is intended for organizations that want to
take advantage of the productivity, performance advantage, and portability
that Java provides for dynamic Web sites. It includes:
– Java runtime support for server-side Java servlets
– Industry-standard object-request brokers to handle requests for data and
other services for client/server applications
– High-performance connectors to many common backend databases to
reduce the coding effort required to link dynamic Web pages to real
line-of-business data
– Application services for session and state management
• The IBM WebSphere Studio, a set of PC-based tools to help developers
create WebSphere applications. The tools currently in the WebSphere Studio
are:
– Web Development Workbench: A Web site project organizer and launch
platform.
– Servlet generation wizards : For building Java servlets to access JDBC
databases and JavaBean components.
– VisualAge for Java, Professional Edition V2.0: The IBM award-winning
Java application development environment for building Java applications,
applets, servlets, and JavaBean components.
– NetObjects Fusion : Allows Web-site developers to design and produce an
entire Web site, including individual pages and all links. It features
automated site building, automatic link management, remote database
access, and design and publishing capabilities.
– NetObjects BeanBuilder : The visual authoring tool for combining
JavaBeans and Java applets. BeanBuilder allows individuals overseeing
the content of online business processes to create more compelling, highly
interactive Web sites with revolutionary ease-of-use.
– NetObjects ScriptBuilder : Combines a text-based script editor and
development tools for creating and editing HTML, script, and Java Server
pages.
IBM Net.Data allows the creation of interactive Web applications with "macros" to
add logic, variables, program calls, and report writing to HTML. These macros
combine the simplicity of HTML with the dynamic functionality of CGI programs,
which makes it easy to add live data to static Web pages. Live data includes
information stored in DB2 for AS/400 (locally or remotely), databases on other
systems, REXX programs, C and C++ programs, programs in other AS/400
languages (such as CL, RPG, and COBOL), and other sources.
Web serving capabilities of the AS/400 system have also been extended with a
powerful, full-text search engine through the implementation of NetQuestion in

OS/400 Version 4 Release 3. NetQuestion provides the tools to build a
centralized Internet search service. NetQuestion can index both plain text and
text with HTML markup and provides CGI scripts and HTML forms for searching
and administration.
Net.Commerce provides an easy-to-use design tool to help create appealing

screens or pages to showcase a store and its products. It is even possible to
include special effects such as three-dimensional graphics, animation, sound,
and Java applets.
Net.Commerce also contains task macros and application program interface

(API) functions that manage shopping tasks automatically. Net.Commerce
supplies Web pages for a shopping cart, registration forms, and order forms that
can be customized to create a unique look and feel for each business.
It is also possible to implement simple or complex pricing schedules with ease by

assigning priority values and effective dates. Several product prices for sales and
for preferred shoppers can also be assigned.
With the sophisticated shipping functions of Net.Commerce, a wide variety of

carriers and cost calculations can be defined. Switching shipping carriers or
applying a new rate is as simple as changing a shipping code in the database.
The entire inventory is updated. Shoppers are also allowed to choose different
shipping methods and rates for items they order. The API functions in
Net.Commerce can be used to define and apply various tax rates.
Other features of Net.Commerce include the ability to lock the database from
unauthorized tampering and provide a password to only selected individuals.
Shoppers protect their information by using a logon ID and password when they
register. User data, such as credit card information, is protected through Secure
Sockets Layer (SSL) encryption.
Net.Commerce provides an Administrator function to build and manage an

electronic store or mall. The Administrator can easily enter store and product
information and tailor product displays to suit merchandising requirements.
Changes appear automatically on the Web.
The Net.Commerce Administrator contains two data management applications:

• Site Manager : Creates and manages commercial Web sites
• Store Manager : Develops and manages an on-line catalog and uses simple
on-line forms to manage such information as shipping options, shopper
groups, and customer numbers
It also contains a Web-page design tool called Template Designer. The

Java-based Template Designer in Net.Commerce is used to design Web pages. It
is possible to create static or dynamic Web pages that display up-to-date data
that is linked to a DB2/400 database. Template Designer's graphic look,
drag-and-drop capabilities, and quick testing functionality help create and test
your pages. The design is laid out on a reusable template. Different templates
can be created for different types of pages (for example, one template for
regularly priced products, and another for products on sale). Template Designer
can also be used to create a home page for a store or mall, category pages,
product pages, and unique pages for members of shopper groups.

E.3 Lotus Domino
Lotus Domino is the world's leading workflow, messaging, groupware, and Web
software. Lotus Domino enables you to communicate with colleagues, collaborate
in teams, and coordinate strategic business processes on and off the Web.
Powerful, flexible communication

Lotus Domino gives you the power you need to communicate within and beyond
your organization. If you need to communicate with suppliers, customers, and
partners at other companies that use different e-mail systems, or reach them
using the Internet, Lotus Domino makes it easy. Mobile Notes users can take
their desktop along with them, and transform airports, hotels, and cars into work
spaces complete with up-to-the-minute information. The Lotus Domino family
also includes sophisticated client server e-mail, based on the market leading
cc:Mail user interface. Lotus Domino applications can be accessed from any Web
browser that extends the openness and flexibility of your network.
World-class collaboration and coordination

Lotus Domino goes beyond traditional e-mail and groupware. With Lotus Domino,
you can collaborate with team members using a local area network, wide area
network, or the Internet. With the unique ability of Lotus Domino to integrate
structured and unstructured information into coherent databases, you can
organize and coordinate the most complex business processes.
Rapid application development

Lotus Domino allows you to create custom business applications that coordinate
everyday business processes from start to finish to achieve results such as
improved customer service, improved sales force productivity, and faster
time-to-market for products. Lotus Domino customers consistently find significant
payback on their Lotus Notes investment whether they enable their Lotus Domino
applications for the Web.
Portability and interoperability

Lotus Domino is a server product that runs on a variety of platforms and provides
easy-to-manage interoperability in a heterogeneous network. With the
sophisticated replication capability of Domino, applications are easily distributed
to multiple Domino servers in your enterprise, and just as easily deployed to end
users. Replication also simplifies the job of deploying application changes. Lotus
Domino applications are also available to any Notes client (such as Windows 95,
Windows 98, Windows 3.1, OS/2, Windows NT, and Macintosh). Lotus Domino
version 4.5 and later releases are fully Internet-ready. You can access Lotus
Domino server functions from either a Lotus Notes client on your workstation or a
browser (including a browser on a Network Station).
Domino for AS/400

Domino for AS/400 is the Lotus Domino server product running on a 64-bit
AS/400 RISC processor. It requires OS/400 V4R2 or later. Domino for AS/400
provides all the functionality of the Lotus Domino server that runs on other
platforms and more.
Domino for AS/400 is an application that is packaged, distributed, and supported

by Lotus Development Corporation. You may purchase Domino for AS/400 from a
Lotus distributor, just as you would buy the Domino server product for any other
platform. Beginning August 20, 1999, you may also purchase the Lotus Domino

Enterprise Server for AS/400 (5769-LNT) as a licensed program product from
IBM. At the same time, the Lotus Enterprise Integrator (5769-LNP), which was
formerly called NotesPump, was also made available as a licensed program
product for purchase from IBM. The AS/400 system continues to be purchased
through IBM AS/400 channels.
With V4R4, the OV/400 Migration to Domino for AS/400 licensed program allows
the migration of users, groups, mail, calendars, and folders to Domino from
OV/400. The Lotus Calendar Connector for OfficeVision (LCCOV) allows
free-time search and the distribution of meeting notices between Domino and
OfficeVision/400.
Unmatched scalability
Within a single architecture, the AS/400 system spans a vast performance
spectrum. The smallest Domino for AS/400 server may have less than a dozen
users. The largest AS/400 system is capable of accommodating more than
10,000 mail users on a single footprint.
The breakthrough price performance of the AS/400e servers and OS/400 V4R2
or later means that AS/400 configurations can support this broad range of Lotus
Domino users in a cost-effective manner.
World-class reliability and availability

With more than 550,000 systems shipped worldwide, the AS/400 system has
earned a reputation as a reliable, undemanding workhorse. AS/400 users expect
their system to be consistently available, night and day, and the AS/400 system
does not disappoint. Domino for AS/400 takes advantage of the reliability and
availability features of the AS/400 system, such as RAID5, mirrored disk units,
and integrated backup capability. Each Lotus Domino server runs as an OS/400
application in its own subsystem. The unique architecture of OS/400 makes it
safe to run your Lotus Domino server and your mission-critical business
applications on the same AS/400 system.
Powerful integration
Domino for AS/400 includes integration between Lotus Domino databases and
DB2/400 databases. Both real-time and scheduled integration of databases is
available to meet a variety of application needs.
Automatic synchronization between the Domino Public Address Book and the
AS/400 System Distribution Directory provides a powerful, integrated mail server
for organizations with multiple e-mail products, including OfficeVision/400, POP3,
JustMail, and Internet mail.
The Lotus Enterprise Integrator option to synchronize authorizations between

DB2/400 databases and Domino databases is platform exclusive.
Proven security
Integrated, flexible security is a long-standing strength of both Domino and the
AS/400 system. Recently, the AS/400 reputation for security was enhanced with
the introduction of Firewall for AS/400, which runs on an AS/400 Integrated PC
Server. When you consider connecting to the Internet, Domino for AS/400 and
the Firewall for AS/400 combine function, reliability, and value.

E.4 Integration with Windows NT Server
Currently, most companies deploy PC servers by function or service, with each
server dedicated and tuned to an individual application such as file, print, or Web
serving.
Consolidating multiple Windows NT Servers inside an AS/400e server keeps

each of your Intel-based servers separate, but houses and manages them
together in a single system.
Advantages of server consolidation on an AS/40 system

Server consolidation on the AS/400 system allows you to:
• Consolidate PC server hardware and operations so you can run up to 16
Windows NT servers in a single AS/400 system.
• Increase business recovery protection with high-speed backup of the
combined AS/400e server and Windows NT systems.
• Improve server uptime and error recovery using highly reliable AS/400 disk
drives with RAID-5 and mirroring options. You can use a spare Integrated
Netfinity Server to replace a failed server without reloading Windows NT.
• Maximize I/O investments by balancing AS/400e server and NT disk
resources from a single pool. Switch user data disks between servers. Share
the AS/400 tape and CD-ROM drives.
AS/400 integration with the Windows NT Server

AS/400 Integration with the Windows NT Server is a nonchargeable feature of
OS/400. This feature provides the device drivers to enable Windows NT Server to
run on the AS/400 Integrated Netfinity Server and to share AS/400 disk, tape, and
CD-ROM drives. It also provides a variety of utilities, including integrated user
administration.
Windows NT server requirements

The AS/400 Integrated Netfinity Server is certified to run Microsoft Windows NT
Server 4.0. A standard CD-ROM licensed copy should be purchased separately
(with the required client licenses) from any Microsoft reseller.
AS/400 Integrated Netfinity Server

The AS/400 Integrated Netfinity Server combines the power of an Intel Pentium II
processor with the high reliability and availability of AS/400e servers.
The AS/400 Integrated Netfinity Server is available on all AS/400 64-bit RISC
models in either PCI bus or SPD bus versions. Integrated Netfinity Servers are
considered features of the AS/400 system and are covered by the AS/400 system
warranty and maintenance contract. A standard PC display, keyboard, and
mouse must be attached to the AS/400 Integrated Netfinity Server.
E.5 Extended Adaptive Cache

Extended Adaptive Cache is an advanced read cache technology that improves
both the I/O subsystem and system response times by reducing the number of
physical I/O requests that are read from disk. Extended Adaptive Cache operates
at the disk subsystem controller level, and does not affect the AS/400 system
processor. The management of the cache is performed automatically within the

I/O adapter, and is designed to cache data by using a predictive algorithm. The
algorithm considers how recently and how frequently the host has accessed a
predetermined range of data.
The design of Extended Adaptive Cache is based on specific data management

strategies of the AS/400 system. Whether the disks are device parity protected,
mirrored, or unprotected, the data stored on the disks has a tendency to occur in
bands. This means that there are physically contiguous areas of disk storage that
fall under one of the following categories:
• Areas where the data is actively read
• Areas of data that are both actively read from and written to
• Areas that are frequently written to
• Areas of storage that are not frequently accessed
This "banding" of data is accounted for in the Extended Adaptive Cache design.
The goal is to cache bands characterized as read or write and read-only. A band
that is characterized as write-only, while cached in the storage subsystem write
cache, remains largely unaffected by Extended Adaptive Cache. Extended
Adaptive Cache is designed to not harm the performance of large blocks of data
that are either sequentially written or sequentially read. In this case, the pre-fetch
capability of the disks, as well as other caches in the system, ensures a quick
response time.
Use of Extended Adaptive Cache improves the performance of database-read

actions, and all read actions. This includes read actions that are generated by
other system components such as the Integrated Netfinity Server. It also works
effectively in storage subsystems that have device parity protection or mirroring.
E.5.1 Planning for Extended Adaptive Cache

As is the general case with caches, the system configuration and workload
influence the effectiveness of Extended Adaptive Cache. Extended Adaptive
Cache, functioning at the storage subsystem level, caches data for the set of
disks that are within that specific subsystem. Therefore, it is logical to add
Extended Adaptive Cache to the most active and performance-critical storage
subsystems within the system. For example, Extended Adaptive Cache is not
designed to work with compressed user ASPs. This is because accessible
cost-effective storage is the typical goal for compressed disks, as opposed to
lightening-fast performance.
The larger the area of disk storage is that is actively receiving I/O requests, the
more selective Extended Adaptive Cache is about when to bring new data into
cache. This adaptive ability allows Extended Adaptive Cache to be effective on
many workload types and sizes. The overall cache effectiveness is best
understood from this perspective by using Extended Adaptive Cache Simulator.
E.5.2 Extended Adaptive Cache Simulator

Extended Adaptive Cache Simulator is a performance tool that provides
estimates of DASD I/O response time improvements and prediction of the
number of disk reads that can be saved through the use of Extended Adaptive
Cache operations. This determination is based on your system configuration and
application environment.

Visit the AS/400 Information Center Web site at:
http://publib.boulder.ibm.com/html/as400/infocenter.html
Click on System Administration and Maintenance for further information about

how this performance data will specifically benefit your overall system.
E.6 Managed availability

The AS/400 system offers managed availability to ensure that it is ready to do
business when you are. Hallmarks of AS/400 availability have included redundant
internal hardware features, such as RAID-5 and mirroring. The robustness and
stability of OS/400 extends into its multiple, subsystems support (batch,
interactive, multi-language, applications) demonstrating the AS/400 ability to
meet your business requirements when needed.
Prior to V4R4, the AS/400 system offered multi-system coupling that provided
peer or tiered node clusters, constructed by ISVs using distributed data
management and journaling. The customer separately managed the systems in
the cluster. Database replication was provided by high-availability business
partner solutions.
V4R4 introduces AS/400 Logical Partitioning (LPAR), which enhances the role of
the AS/400 system as a consolidated server. With LPAR, companies have both
the power and flexibility to address multiple system requirements in a single
machine. LPAR is of value to customers that need server consolidation, business
unit consolidation, mixed production, and test environment, as well as integrated
clusters.
AS/400 clustering is taking a major step forward with the introduction of Cluster
Resource Services as part of OS/400 V4R4 (APIs). The complexity of managing
systems in a cluster and keeping track of data and applications is now handled by
OS/400 V4R4. Protecting your business from unplanned and planned outages, as
well as site loss disasters, is easier than ever before. Cluster management and
enhanced data resilience applications, both provided by high-availability business
partners, complete the total solution.
E.7 Business Intelligence solutions

Business Intelligence (BI) turns corporate data into meaningful business
information. It can help you understand business trends and make better
forecasting decisions. It can be used to bring better products to market in a more
timely manner. It can be used to analyze daily sales information and make snap
decisions that can significantly impact your company's performance. Business
Intelligence provides a means to become familiar with who your customers are.
BI turn corporate data into decision support information. BI solutions have

become much more affordable due to new innovations in software and hardware.
One of these key technologies is data warehousing. Data warehouses provide
the plumbing for BI applications. The advent of data warehouse technology and
industry-specific BI applications have made implementations meaningful and cost
effective.

E.7.1 AS/400 enabling technology
The AS/400 system offers the only hardware and software enabled for 64-bit
relational database processing. The AS/400 system has been optimized for a BI
environment with customized hardware (AS/400 servers), and optimized software
(DB2/400, SMP for DB2/400, DB2 Multi-System, and Data Propagator
Relational). These hardware and software functions combine to make a powerful
Business Intelligence server which is easy to install, manage, and use.
With the AS/400 open interfaces, hundreds of tools can be used to provide BI
solutions that access DB2/400 data transparently. Such tools include desktop
analysis tools (business objects, for example) and sophisticated
multi-dimensional analysis (commonly referred to as OLAP) tools (Essbase/400,
for example) with no special programming required.
SMP for DB2/400 provides parallel query processing. This allows multiple
processors in one AS/400 system to collectively work on a single query and can
improve query performance by as much as 400%. DB2 Multi-System support
provides clustering for the AS/400 system and allows up to 32 AS/400 systems to
be "clustered" together into a single system. This clustering provides almost
unlimited scalability and unparalleled performance for AS/400 customers. The
combination of all of these advanced features has dramatically improved AS/400
performance so much. And, customers using UNIX systems, PC servers, and
even large, specialized parallel servers have converted from these machines to
the AS/400 system for a fraction of the cost.
Data replication is an important technology to facilitate the automated loading of

data warehouses while cleaning or summarizing data for integrity and
performance purposes. DataPropagator/400 provides asynchronous data
movement between OLTP systems and Business Intelligence systems. Data
Propagator allows fields to be summarized, derived, or aggregated into the data
elements necessary in your data warehouse.
Data Mining is a Business Intelligence application that uses mathematical

algorithms to scan potentially large amounts of data to find the golden nuggets of
information. Intelligent Miner for AS/400 provides the most advanced data mining
application for AS/400 customers. It offers optimized computer models to
"discover" data relationships previously unknown. The models include algorithms
for clustering, information classification, predictions, associations, sequential
pattern recognition, and time sequence patterns. This analysis provides
executives with insight that can truly be a competitive advantage.
E.7.2 Business Intelligence solutions

Industry-specific BI solutions allow customers to implement off-the-shelf industry
applications that are designed for their business. These applications provide a
range of functions that are specific to an industry and generally provide users
with instant functional application templates that can be customized to meet each
businesses unique needs.
E.7.3 Business Intelligence tools and applications

Virtually every major BI tool is supported on the AS/400 system. That includes
tools such as Data Mirror and ETI Extract for moving and cleansing data, tools for
organizing data into a multi-dimensional and relational format such as
Essbase/400 and DataTracker. It also supports such multi-dimensional analysis

tools as Analyzer, Business Objects, and Cognos Powerplay. These tools allow
customers unlimited flexibility in building their own BI applications. They also
allow applications to use AS/400 and non-AS/400 data.
There are many technical advantages of using the AS/400 system for your
Business Intelligence server. The main reason why customers choose the AS/400
system is the combination of its power and simplicity. The AS/400 system
provides a full range of tools, applications, and hardware in a single integrated
platform that helps to make rapid implementation a reality. Large and small
businesses alike agree that this is the ideal Business Intelligence server.
The AS/400 system provides outstanding database technology that supports

rapid access to large amounts of data. The AS/400 system supports a wide range
of BI solutions including small departmental applications, and large BI
environments. The benefits of this application are measured by the more
informed decisions that can be made as a result of having better information, and
information in a format to support the decision-making processes of a company.
E.8 e-business
Success in business today depends on one thing: meeting customer needs,
which are unique to each organization. To meet those needs, the best option is a
computer built to do business the way each organization does. That means a
server that is flexible, versatile, and can deliver customized solutions, all in a
cost-effective manner.
The AS/400 system has always been designed for business. By tightly integrating
hardware, software, middleware, and the operating system. The AS/400 system
provides a combination of power and flexibility that organizations can rely on to
help them in their business. This design also makes it possible for the AS/400
system to help ensure that they move with technology as it changes.
e-businesses require hardware and software solutions with cost-effective

computing power. However, more importantly, they need solutions that scale well
as workloads grow larger and more complex. To scale well means the computer
system grows in capacity to accommodate business growth without changing the
customer's applications, hardware, or system software investment. The AS/400
has always been known for its scalability and meeting the needs of a dozen to
several thousand users with the same architecture and operating system.
E.8.1 Characteristics of a successful e-business

IBM has effectively branded and marketed the term e-business. The market is
beginning to have a general sense of what e-business means. But an expanded
explanation with better examples is necessary. The topics that follow describe the
defining actions of tomorrow's successful e-business:
• Fully exploiting the latest IT tools and techniques
• Delivering a broad spectrum of applications
• Reaching a broad spectrum of users
These defining actions sound familiar to anyone who knows the fundamentals of
using information technology (IT) to achieve competitive advantage. e-business
does not change the fundamental rules, but represents a dramatic shift in a
typical company’s ability to cost-effectively exploit IT on a broad scale. Simply

stated, a wide range of affordable tools is now available to enable even the
smallest organization to conduct business electronically on a worldwide scale.
This allows them to achieve a competitive advantage in a cost effective manner.
E.8.1.1 Fully exploiting the latest IT tools and techniques

One of the most exciting aspects of the e-business dream is the broad range of
applications that businesses can deliver. Keep in mind that this range of
applications builds on and extends the existing line-of-business (LOB)
applications of an organization. Sometimes, these LOB applications are treated
with less respect than they deserve and are described with somewhat negative
terms (such as legacy applications ) simply because they are not flashy and
glamorous. This is particularly true for AS/400 installed customers because the
majority of their line-of-business applications still present text-based green
screens instead of a GUI.
An e-business needs to be properly positioned to respond quickly to new

opportunities, shifts in the market, and peaks in demand for electronic services.
Every organization that is looking at e-business both hopes for and fears the
problem of exponential growth and an overwhelming response to its e-presence.
To be properly positioned, both respond to drag-and-drop and point-and-click
graphical screens and integrate existing LOB applications that provide strong,
business critical functions and data.
For the AS/400 system in particular, a large portfolio of robust LOB applications
provides a strong base for building e-business solutions by extending and
enhancing those applications with an entirely new range of options.
E.8.1.2 Delivering a broad spectrum of applications

The IT world is witnessing an explosion of new application possibilities centered
around groupware, e-business, and the Web. Here are some examples:
• Static Web sites: For many organizations, the Web provides a cost-effective
method for publishing and distributing information to the world. Web sites for
manufacturers and distributors, for example, typically include product catalogs
with specifications, price lists, and pictures. They can present a positive,
memorable image for the organization and can be updated regularly at a
fraction of the cost to update printed product catalogs. Intranets (networks
within an organization) can use the same Web technology to "publish and
distribute" policy information, human resource practices, and company
newsletters, for example. These types of sites are called static (they seldom
change and a good Web site is updated frequently) because the contents of
the Web pages do not change based on user interaction. The information is
view-only, not dynamic.
• E-mail: The use of e-mail within organizations and across organizational
boundaries has mushroomed in recent years. A richly featured e-mail system
provides fast distribution of information, such as text messages, documents,
spreadsheets, and images. A static Web site is often called pull technology.
Customers need to make the effort to visit the Web site and pull information.
E-mail is one method for providing the push counterpart. e-businesses can
push information to their customers or subscribers. The push may be a teaser
("Visit our Web site for this month’s exciting new product announcements") or
it may be more comprehensive. e-businesses also use e-mail, for example, to
acknowledge orders and to provide customer service.

• Bulletin boards and newsgroups: These Web applications draw their names
from counterparts outside of cyber space. Think of a bulletin board on a
college campus. It has many postings of interest to the students and
professors who travel that hallway: seminar schedules, job postings,
advertisements for professional journals, schedules of departmental events,
and so on. Anyone can tack up a notice for all to view. And the department
probably publishes a newsletter with contributions from the department
members. Now extend that to the world and to the Web, and you have the
concept of bulletin boards and newsgroups. Bulletin boards and newsgroups
can use both push and pull techniques. In this case, you often subscribe to a
bulletin board or newsgroup and receive an e-mail notification when new items
are posted in your interest area.
• Document management: In the arena of LOB applications, IT has long
understood the advantage (even the necessity) of storing data once, but
retrieving and displaying it in multiple ways. With e-business, this need
expands to storing data electronically and to storing unstructured information
(such as documents, spreadsheets, images, audio, and video) electronically.
This requirement goes far beyond the traditional file serving that is part of a
PC network to a robust system for archiving, indexing, and retrieving diverse
documents (where the term document is used in the broadest sense). Lotus
Notes and Domino, with its ability to organize, store, and retrieve both
structured and unstructured information, is a good example of document
management capability.
• Value-add, Web-enabled applications: From the perspective of traditional
AS/400 applications, you may think of a value-add, Web-enabled application
as extending your "inquiry" applications to the Web. These applications
typically give the world, or some subset of the world, the ability to view
information from your LOB databases directly. Transport and distribution
companies, such as United Parcel and DHL, are often-cited examples in this
arena. Their Web sites offer customers the ability to track packages on their
journey from the point of origin to their destination.
This type of application provides value to the customer and differentiates the
e-business from its competitors. In addition, it can reduce costs by reducing
the volume of calls to the customer service organization. Usually, this type of
application simply provides a new way of accessing and displaying information
that is already being captured and stored for the LOB applications.
Obviously, this type of application, which integrates Web pages, forms, and
LOB databases, is more challenging than a static Web site. It is more difficult
to develop, and it must meet the same demands as your LOB applications,
such as security, integrity, reliability. The application provides competitive
advantage only if it's available, up-to-date, responsive, and easy to use.
Otherwise, your customers will pick up the phone (at best) or go to your
competitors (at worst).
• e-Commerce: e-Commerce (a subset of the function implied by e-business)
goes one step beyond value-add, Web-enabled applications by exchanging
"value" rather than simply exchanging information (not that information is not
valuable). In an e-commerce transaction, one or both parties commit
electronically to the delivery of a product or a service for a payment. Both
parties accept the transaction as binding. In effect, an e-commerce transaction
ultimately creates a flow of money and has the force of a letter or contract with
a binding signature.

Today, e-commerce applications typically exist in two basic forms:
loosely-coupled and tightly integrated. With the loosely-coupled approach, a
customer electronically requests a product or service by filling in a form on the
Web site. The information from that transaction is captured and entered into
the back-end LOB system (often manual). This approach is not that different
from having a customer fax an order. The tightly integrated e-commerce
application interacts directly with the backend application during the
transaction. For example, the application checks stock availability and credit
limits immediately, online. In other words, it behaves much like a typical,
integrated, and online LOB application on the AS/400 system.
Clearly, a robust, integrated e-commerce application places demands that go
beyond the already strenuous demands of mission-critical LOB applications.
Security, availability, and auditablity become critical. In addition, the
application (and the supporting infrastructure) must be able to respond to
unpredictable fluctuations in transaction rates. It demands a premier server
and premier tools, which the AS/400 system provides.
E.8.1.3 Reaching a broad spectrum of users

The network infrastructure and the inexpensive, pervasive tool of the Web (the
browser) enable e-business to reach out globally to a variety of users around the
globe, as:
• On-site: This group of users is housed in the same location as the system.
• Off-site, internal : This group of users is part of the organization, but the users
themselves are in remote offices.
• Mobile, internal: This group of users is part of the organization, but these
users work at multiple locations. A travelling sales force is a classic example
of mobile users.
• Suppliers and customers: e-business can bring to maturity the electronic
interaction between an organization and its suppliers and customers. For
years, forward-looking organizations have realized the value of having
information flow electronically between their systems and the systems of their
suppliers and customers. Electronic Data Interchange (EDI) represents a
significant step in this direction.
• Opinion-shapers and consultants: It seems that for every set of products or
services, there is a consultant or pundit ready to evaluate and recommend for
or against it. Increasingly, these opinion-shapers and consultants rely on the
Web for much of their information gathering. For an organization to have a
visible, positive image with the consultants of the future, the organization must
have a Web presence.
• A greatly expanded potential market: The reported number of Internet users
seems to grow exponentially. A commonly-quoted figure today is 50 million
worldwide. This represents a vast market that the savvy e-business can reach
economically. Appropriate products for this marketplace are not limited to
branded, retail consumer products. Many makers of niche products are using
the Web to expand their customer list in the wholesale world.
E.8.2 Integration of e-business tools

Today, no single e-business tool available for the AS/400 system (or any other
platform) addresses the entire spectrum of potential e-business users and
applications. It is a vast and rapidly evolving area.

IBM, Lotus, and IBM partners are working toward a set of coherent, integrated
solutions that extend the AS/400 value proposition: simplicity through integration.
By making it feasible but desirable to integrate multiple e-business applications
on a single physical computer system, the AS/400 system reduces both the cost
and complexity of deploying and managing e-business solutions. As our AS/400
customers move to address the entire range of applications, we will work to
provide frameworks and design guidance in these areas:
• Linkage between different e-business offerings : For example, how do you tie
unique or high-priority orders entered electronically through a Net.Commerce
application to workflow notification and e-mail order acknowledgment
applications in Domino?
• Linkage between e-business solutions and LOB applications : For example,
how do orders entered through a Net.Commerce application flow to your
back-end order entry and invoicing system?
E.9 Summary
The AS/400 system has the most brilliant architecture found on any business
computing system. There are many examples of where the AS/400 system's
architecture has delivered on its promise of making the most advanced
technology readily and continuously available to its customers. The AS/400
system has enabled its customers to integrate diverse environments (such as
Microsoft Windows NT and Lotus Domino) into the AS/400 system. All customer
solutions require a range of hardware and software products from a variety of
vendors. The AS/400 system, through integrating these mixed environments,
simplifies the task of managing them.
The AS/400 system’s future-oriented architecture has enabled us to take

rapidly-changing hardware and software technologies in stride. This same,
flexible architecture will continue to serve us well in enabling our customers to
continue deploying the latest technologies, while causing the minimum possible
disruption to their work.

Appendix F. eBPCS supported languages
The following tables highlight the supported languages in eBPCS.
Table 31. Languages by country name
Language name Country Country name AS/400 code page (SBCS) local
ID settings for Client Access/400
(accented)
UK English (English) ENG United Kingdom 285
US English (English) ENU United States 37
Tier-1
Brazilian Portuguese PTB Brazil 256
Dutch (Nederlands) NLD Netherlands 37
French (Français) FRA France 297
German (Deutsch) DEU Germany 273
Italian (Italiano) ITA Italy 280
Japanese Katakana (Nihongo) (DBCS) JPN Japan 1027
Japanese Katakana (alternate) (DBCS) JPN Japan 290
Korean (Choson-o; Hanguk-o) (DBCS) KOR Republic of Korea 833
Portuguese (Portuguese) PTG Portugal 37
Simplified Chinese (DBCS) CHS People's Republic of China 836
Spanish (Espanol) ESP Spain 284
Traditional Chinese (Zhongwen) (DBCS) CHT Republic of China 37
Tier-2
Arabic (Arabi) ARA Arab Area 420
Bulgarian BGR Bulgaria 1025
Croatian (Hrvatski) HRV Croatia 870
Czech (Cesky) CSY Czech Republic 870
Danish (Dansk) DAN Denmark 277
Finnish (Suomi) FIN Finland 278
Greek (Ellinika) ELL Greece 875
Hebrew (Ivrith) HEB Israel 424
Hungarian (Magyar) HUN Hungary 870
Norwegian (Norsk) NOR Norway 277
Polish (Polski) PLK Poland 870
Romanian (Romana) ROM Romania 870
Russian (Russkij) RUS Russia 1025
Slovakian (Slovensky) SKY Slovakia 870
Slovenian (Slovenski) SLO Slovenia 870

Language name Country Country name AS/400 code page (SBCS) local
ID settings for Client Access/400
(accented)
Swedish (Svenska) SVE Sweden 278
Turkish (Turkce) TRK Turkey 1026
Table 32. Language by AS/400 code page (SBCS)
Language name AS/400 code page (SBCS) - MNCS AS/400 code ASCII Windows
settings for Client Access/400 page (DBCS) code page
(unaccented)
UK English (English) 500 1252
US English (English) 37 1252
Tier-1
Brazilian Portuguese 256 1252
Dutch (Nederlands) 500 1252
French (Français) 500 1252
German (Deutsch) 500 1252
Italian (Italiano) 500 1252
Japanese Katakana (Nihongo) (DBCS) 1027 300 932
Japanese Katakana (alternate) (DBCS) 290 300 932
Korean (Choson-o; Hanguk-o) (DBCS) 833 834 949
Portuguese (Portugues) 500 1252
Simplified Chinese (DBCS) 836 837 936
Spanish (Espanol) 500 1252
Traditional Chinese (Zhongwen) (DBCS) 37 835 950
Tier-2
Arabic (Arabi) NA 1256
Bulgarian NA 1251
Croatian (Hrvatski) NA 1250
Czech (Cesky) NA 1250
Danish (Dansk) NA 1257
Finnish (Suomi) NA 1257
Greek (Ellinika) NA 1253
Hebrew (Ivrith) NA 1255
Hungarian (Magyar) NA 1250
Norwegian (Norsk) NA 1257
Polish (Polski) NA 1250
Romanian (Romana) NA 1250

Language name AS/400 code page (SBCS) - MNCS AS/400 code ASCII Windows
settings for Client Access/400 page (DBCS) code page
(unaccented)
Russian (Russkij) NA 1251
Slovakian (Slovensky) NA 1250
Slovenian (Slovenski) NA 1250
Swedish (Svenska) NA 1257
Turkish (Turkce) NA 1254
Table 33. Language by AS/400 CCSID
Language name AS/400 QCCSID Character NLSEXXX.TBL converts

CCSID set required local setting for CA/400
(AS/400 - OPS)
UK English (English) 285 65535 697 NLSE285/500
US English (English) 37 65535 697
Tier-1
Brazilian Portuguese 256 65535 697 NLSE256/500
Dutch (Nederlands) 37 65535 697 NLSE037/500
French (Français) 297 65535 697 NLSE297/500
German (Deutsch) 273 65535 697 NLSE273/500
Italian (Italiano) 280 65535 697 NLSE280/500
Japanese Katakana (Nihongo) (DBCS) 5035 65535 1172 NLSE1027/300
Japanese Katakana (alternate) (DBCS) 5026 65535 1172 NLSE290/300
Korean (Choson-o; Hanguk-o) (DBCS) 933 65535 337 NLSE833/834
Portuguese (Portugues) 37 65535 697 NLSE037/500
Simplified Chinese (DBCS) 935 65535 697 NLSE836/837
Spanish (Espanol) 284 65535 697 NLSE284/500
Traditional Chinese (Zhongwen) (DBCS) 937 65535 697 NLSE037/835
Tier-2
Arabic (Arabi) 420 65535 697 NLSE420
Bulgarian 1025 65535 697 NLSE1025
Croatian (Hrvatski) 870 65535 697 NLSE870
Czech (Cesky) 870 65535 697 NLSE870
Danish (Dansk) 277 65535 697 NLSE277
Finnish (Suomi) 278 65535 697 NLSE278
Greek (Ellinika) 423 65535 697 NLSE875
Hebrew (Ivrith) 424 65535 697 NLSE424
Hungarian (Magyar) 870 65535 697 NLSE870
eBPCS supported languages 413

Language name AS/400 QCCSID Character NLSEXXX.TBL converts
CCSID set required local setting for CA/400
(AS/400 - OPS)
Norwegian (Norsk) 277 65535 697 NLSE277
Polish (Polski) 870 65535 697 NLSE870
Romanian (Romana) 870 65535 697 NLSE870
Russian (Russkij) 1025 65535 697 NLSE1025
Slovakian (Slovensky) 870 65535 697 NLSE870
Slovenian (Slovenski) 870 65535 697 NLSE870
Swedish (Svenska) 278 65535 697 NLSE278
Turkish (Turkce) 1026 65535 697 NLSE1026
Table 34. Language and ETOA table mapping
Language name ETOA table mapping

from -> to (use reverse direction for ATOE
mapping)
UK English (English) 285->1252
US English (English)
Tier-1
Brazilian Portuguese 256->1252
Dutch (Nederlands) 37->1252
French (Français) 297->1252
German (Deutsch) 273->1252
Italian (Italiano) 280->1252
Japanese Katakana (Nihongo) (DBCS) 1027->932 & 300->932
Japanese Katakana (alternate) (DBCS) 290->932 & 300->932
Korean (Choson-o; Hanguk-o) (DBCS) 833->949
Portuguese (Portugues) 37->1252
Simplified Chinese (DBCS) 836->936
Spanish (Espanol) 284->1252
Traditional Chinese (Zhongwen) (DBCS) 37->950
Tier-2
Arabic (Arabi) 420->1256
Bulgarian 1025->1251
Croatian (Hrvatski) 870->1250
Czech (Cesky) 870->1250
Danish (Dansk) 277->1257
Finnish (Suomi) 278->1257

Language name ETOA table mapping
from -> to (use reverse direction for ATOE
mapping)
Greek (Ellinika) 875->1253
Hebrew (Ivrith) 424->1255
Hungarian (Magyar) 870->1250
Norwegian (Norsk) 277->1257
Polish (Polski) 870->1250
Romanian (Romana) 870->1250
Russian (Russkij) 1025->1251
Slovakian (Slovensky) 870->1250
Slovenian (Slovenski) 870->1250
Swedish (Svenska) 278->1257
Turkish (Turkce) 1026->1254
eBPCS supported languages 415

Appendix G. Special notices
This publication is intended to help customers, eBPCS consultants, business
partners, and IBM specialists who are implementing SSA’s eBPCS on the
AS/400e system. The information in this publication is not intended as the
specification of any programming interfaces that are provided by SSA’s eBPCS
and OS/400. See the PUBLICATION section of SSA’s eBPCS and AS/400 for
more information about what publications are considered to be product
documentation.
References in this publication to IBM products, programs or services do not imply

that IBM intends to make these available in all countries in which IBM operates.
Any reference to an IBM product, program, or service is not intended to state or
imply that only IBM's product, program, or service may be used. Any functionally
equivalent program that does not infringe any of IBM's intellectual property rights
may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The information contained in this document has not been submitted to any formal
IBM test and is distributed AS IS. The information about non-IBM ("vendor")
products in this manual has been supplied by the vendor and IBM assumes no
responsibility for its accuracy or completeness. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these
techniques to their own environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
Any performance data contained in this document was determined in a controlled

environment, and therefore, the results that may be obtained in other operating
environments may vary significantly. Users of this document should verify the
applicable data for their specific environment.

Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of including
these reference numbers is to alert IBM customers to specific information relative
to the implementation of the PTF when it becomes available to each customer
according to the normal IBM PTF distribution process.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
ADSTAR Advanced Function Presentation
Advanced Function Printing Advanced Peer-to-Peer Networking
AFCCU AFP
AIX AnyNet
Application System/400 APPN
AS/400 AS/400e
AT BookManager
CICS Common User Access
CT CUA
Database 2 OS/400 DataPropagator
DB2 DB2/400
Distributed Relational Database DRDA
Architecture
IBM  IBMLink
IMS InfoPrint
Integrated Language Environment Intelligent Miner
Intelligent Printer Data Stream IPDS
Language Environment LPDA
MQ Net.Commerce
Net.Data Netfinity
NetView Network Station
OfficeVision OfficeVision/400
Operating System/400 OS/2
OS/400 Power PC
Power PC AS Print Services Facility
RISC System/6000 RPG/400
RS/6000 S/390
Service Director SP
SP1 System/370
SQL/400 VisualAge
VisualGen WebSphere
XT 400
The following terms are trademarks of other companies:
Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.

Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli,
and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems
Inc., an IBM company, in the United States, other countries, or both. In Denmark,
Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.
C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United States

and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel

Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries licensed
exclusively through The Open Group.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
Other company, product, and service names may be trademarks or service marks
of others.
Special notices 419

Appendix H. Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
H.1 IBM Redbooks publications

For information on ordering these ITSO publications see “How to get IBM
Redbooks” on page 427.
• AS/400 System Handbook , GA19-5486
• AS/400 Printing V, SG24-2160
• The System Administrator’s Companion to AS/400 Availability and Recovery,
SG24-2161
• AS/400 - Implementing Windows NT on the Integrated Netfinity Server,
SG24-2164
• AS/400 Performance Management V3R6/V3R7, SG24-4735
• Inside AS/400 Client Access for Windows 95/NT V3R1M2, SG24-4748
• AS/400 Performance Explorer Tips and Techniques, SG24-4781
• AS/400 TCP/IP Autoconfiguration: DDS and DHCP Support, SG24-5147
• AS/400 Client Access Express for Windows: Implementing V4R4M0 ,
SG24-5191
H.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title Collection Kit
Number
System/390 Redbooks Collection SK2T-2177
Networking and Systems Management Redbooks Collection SK2T-6022
Transaction Processing and Data Management Redbooks Collection SK2T-8038
Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
AS/400 Redbooks Collection SK2T-2849
Netfinity Hardware and Software Redbooks Collection SK2T-8046
RS/6000 Redbooks Collection (BkMgr Format) SK2T-8040
RS/6000 Redbooks Collection (PDF Format) SK2T-8043
Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
H.3 Other resources

These publications are also relevant as further information sources:
• Soltis, Frank G. 1999. Logical Partitioning: Divide and Conquer. NEWS/400.
January edition.
• Client Access for Windows 95/NT - Setup, SC41-3512
• Client Access for Windows 95/NT ODBC User's Guide, SC41-3535

• AS/400 Hierarchical Storage Management , SC41-4450
• Backup Recovery and Media Services, SC41-5345
• AS/400 Local Device Configuration , SC41-5121
• AS/400 Basic System Operation, Administration, and Problem Handling,
SC41-5206
• DB2 for AS/400 Query Manager Use, SC41-5212
• Security - Reference, SC41-5302
• Backup and Recovery, SC41-5304
• OS/400 Work Management, SC41-5306
• OS/400 Performance Tools/400, SC41-5340
• Backup Recovery and Media Services for AS/400, SC41-5345
• Remote Work Station Support, SC41-5402
• TCP/IP Configuration and Reference, SC41-5420
• TCP/IP Fastpath Setup, SC41-5430
• Client Access Express for Windows - Setup, SC41-5507
• DB2 for AS/400 SQL Programming, SC41-5611
• DB2 for AS/400 SQL Reference Guide, SC41-5612
• DB2 for AS/400 Database Programming, SC41-5701
• DB2 for AS/400 Query Management Programming, SC41-5703
• DB2 Multisystem on AS/400, SC41-5705
• Data Management, SC41-5710
• Integrated File System Introduction, SC41-5711
• DDS Reference, SC41-5712
• Printer Device Programming, SC41-5713
• CL Reference, SC41-5722
• AS/400 Client Access Host Servers, SC41-5740
• System API Programming , SC41-5800
• System API Reference, SC41-5801
• DB2 for AS/400 SQL Call Level Interface, SC41-5806
These SSA’s eBPCS publications are also relevant as further information

sources. They may be obtained by attending SSA’s training courses. For more
information, see: http://www.ssax.com
H.4 Referenced Web sites

• SSA's home page: http://www.ssaportfolio.com/
• About SSA: http://www.ssaportfolio.com/company/
• SSA's Education offerings, schedules, and on-line registration:
http://www.ssaportfolio.com/company/education/
• SSA's online magazine: http://www.ssaportfolio.com/company/livewire.html

• SSA's eBPCS product: http://www.ssaportfolio.com/product/
• Details of SSA's software and hardware partners and their products:
http://www.ssaportfolio.com/partners/
• SSA's Portfolio Solutions: http://www.ssaportfolio.com/solutions.html
• Information regarding sizing AS/400 for eBPCS:
http://www.ssaportfolio.com/partners/ibm/sizing.html
• AS/400 and eBPCS information, including the White Paper "Configuring your
AS/400 and eBPCS in an LPAR environment":
http://www.ssaportfolio.com/partners/ibm/as400e.html
• Information on SSA's affiliate programs:
http://www.ssaportfolio.com/affiliates/index.html
• SSA's Professional Services organization:
http://www.ssaportfolio.com/services/
• Information aimed at the existing eBPCS user: http://www.bpcsusers.com/
• OnLine is the premier global support Web site for System Software
Associates, Inc. This is a secure Web site. You will need a User Name and
Password to Login: http://ogs.ssax.com/
• Conversion instructions:
http://ogs.ssax.com/clients/support/Tech_Requirements/Conversion.zip
• The IBM home page: http://www.ibm.com
• Home Page of the AS/400 system: http://www.as400.ibm.com
• The Client Access home page: http://www.as400.ibm.com/clientaccess
• To access Information Center and Online Library in the language you want. A
download of the AS/400 manuals in PDF file format is also provided:
http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm
• AS/400 NetServer home page: http://www.as400.ibm.com/netserver
• Operations Navigator information:
http://www.as400.ibm.com/tstudio/opsnav/opnav.htm
• Location for AFP printer drivers for Windows on the IBM Printing Company’s
home page: http://www.printers.ibm.com/driver.html
• The AS/400 Information Center; a quick and easy way to find AS/400 technical
information in one place: http://www.as400.ibm.com/infocenter
• IBM home page for 5250 Emulation software and hardware:
http://www.networking.ibm.com/525/525home.html
• AS/400 Worldwide Technical Support home page. From here, you can link to
Tech Info & Databases and then to Software Knowledge Base, and
Software Problems — APARS: http://www.as400service.ibm.com/
• An AS/400 specific search: http://www.search400.com
• AS/400 Worldwide Technical Support:
http://as400service.rochester.ibm.com/as400/service.html
• Before you can order PTFs over the Internet and use the AS/400 technical
support site, you must register on the Web at the NEW AS/400 PTF ordering
facility: http://as400service.rochester.ibm.com/supporthome.nsf/home/
Internet+PTF+Downloads
Related publications 423

• AS/400 software support knowledge base:
http://as400service.rochester.ibm.com/as4sde/slkbase.nsf/slkbase
• AS/400 Partners in Development: http://www.as400.ibm.com/developer
• AS/400 Support Line:
http://as400service.rochester.ibm.com/as400/rmtserv/opsupport.html
• AS/400 Consult Line:
http://service.software.ibm.com/as400.us/go?/consultline/index.html
• AS/400 Customer Benchmark Center:
http://www.as400.ibm.com/developer/cbc/index.html
• IBMLink Worldwide IBM Products and Service information:
http://www2.ibmlink.ibm.com
• IBM AS/400 Information Center, Online Library, and Technical Studio:
http://as400bks.rochester.ibm.com
• IBM AS/400 euro home page: http://www.as400.ibm.com/euro
• An IBM Web site specializing in information, direction and management tips
regarding logical partitions for an AS/400 system:
http://www.as400.ibm.com/lpar
• An IBM Web site with information regarding BRMS and HSM storage
solutions: http://www.as400.ibm.com/hsmcomp
• Various Internet PTF configurations and setup information are available at the
IBM AS/400 technical support Web site:
http://as400service.rochester.ibm.com
• IBM AS/400 Integration of Windows NT Server: http://www.as400.ibm.com/nt
• ITSO information (Internet): http://www.redbooks.ibm.com/itso.html
• ITSO information (IBM Intranet): http://w3.itso.ibm.com
• Domino on AS/400 PID: http://www.as400.ibm.com/developer/domino/
• Domino home page: http://www.notes.net
• Lotus home page: http://www.lotus.com
• Lotus Customer Support: http://www.support.lotus.com
• The Optimal Networks Corp. home page: http://www.optimal.com
• The CACI International Inc. home page, with information reagarding the CACI
one-to-many network analysis tool: http://www.caci.com
• The Third Millennium Technologies (Mil3) home page, with informtion
regarding the Mil3 network planning tool: http://www.mil3.com
• 29th Street Press (order redbooks): http://www.29thstreetpress.com/
• Midrange (order redbooks on Web): http://www.midrange.com
• Computer Literacy (order redbooks on Web): http://www.computerliteracy.com
/documentation/redbooks/
• Domino Power Magazine: http://www.dominopower.com/
• News/400 Magazine: http://www.news400.com/

• 64-bit AS/400 Computing article:
http://iws.as400.ibm.com/WHPAPR/64simple.htm
• The AS/400 News Source Midrange Systems:
http://www.midrangesystems.com/
Related publications 425

How to get IBM Redbooks
This section explains how both customers and IBM employees can find out about IBM Redbooks, redpieces, and
CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
• Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site. Also read
redpieces and download additional materials (code samples or diskette/CD-ROM images) from this Redbooks
site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few chapters will
be published this way. The intent is to get the information out much quicker than the formal publishing process
allows.
• E-mail Orders
Send orders by e-mail including information from the IBM Redbooks fax order form to:
e-mail address
In United States usib6fpl@ibmmail.com
Outside North America Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
• Telephone Orders
United States (toll free) 1-800-879-2755
Canada (toll free) 1-800-IBM-4YOU
Outside North America Country coordinator phone number is in the “How to Order” section at
this site:
• Fax Orders
United States (toll free) 1-800-445-9269
Canada 1-403-267-4455
Outside North America Fax phone number is in the “How to Order” section at this site:
This information was current at the time of publication, but is continually subject to change. The latest information
may be found at the Redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and Redbooks by accessing the IBM
Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials
repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical
professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for
redbook, residency, and workshop announcements.

IBM Redbooks fax order form
Please send me the following:
Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
Invoice to customer number
Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.

Glossary
ADK Application Development Kernel CEA Configurable Enterprise Accounting
ADSM ADSTAR Distributed Storage Manager CGI Common Gateway Interface
AFP Advanced Function Presentation, Advanced CISC Complex Instruction Set Computing
Function Printing
CL Control Language
AFPDS Advanced Function Printing Data Stream
client/server A relationship between processes
ALE Application Link Enabling running on separate machines. The server process is
APA All Points Addressable a provider of software services. The client is a
consumer of those services. Provides a clean
APAR Authorized Program Analysis Report separation of function based on the idea of service. A
API Application Program Interface server can service many clients at the same time and
regulate their access to shared resources. There is a
APPC Advanced Program to Program Communication many-to-one relationship between clients and a server,
APPN Advanced Peer-to-Peer Networking respectively. Clients always initiate the dialog by
requesting a service. Servers passively wait for
ARP Address Resolution Protocol requests from clients.
AS/400 Application System/400 CLP Control Language Program
ASCII American National Standard Code for CPM Continuously Powered Main Storage
Information Interchange
CPW Commercial Processing Workload
ASP Auxiliary Storage Pool
CUA Common User Access
ATM Asynchronous Transfer Mode
DAL Data Access Layer
AWT Abstract Windowing Toolkit
DASD Direct Access Storage Device
batch job A task or group of tasks you submit for
processing that the system treats as a single unit data mart Department-level decision support
during processing, for example, printing reports and databases. Usually draw their data from an enterprise
purging files. The computer system performs a batch data warehouse that serves as a source of
job with little or no user interaction. consolidated and reconciled data from around the
organization. Data marts can be either relational or
batch processing A method by which the system multidimensional databases.
selects jobs from the job queue, processes them, and
sends output to the out queue. Contrast with data warehouse Database used for reconciling and
interactive processing. consolidating data from multiple databases before it is
distributed to data marts for department-level decision
BBU Battery Backup Unit support queries and reports. The data warehouse is
BEC BPCS Extensibility Center generally a large relational database residing on a
dedicated server between operational databases and
BI Business Intelligence
the data marts.
BLOB Binary large objects. A DB2/400 data type
data warehousing Involves off-loading operational
which represents a large stream of binary data treated
data sources to target databases that will be used
as a single object.
exclusively for decision support (reports and queries).
BMR BPCS Modification Request There are a range of decision support environments,
including duplicated database, enhanced analysis
BPCS Generic term for all releases of the SSA
databases, and enterprise data warehouses.
software
database A continuously updated collection of all
BRMS Business Recovery and Media Services
information that a system uses and stores. Make it
browser A client application that translates possible to create, store, index, and cross-reference
information sent by the World Wide Web. A client must information online.
use a browser to receive, manipulate, and display
database administrator (DBA) The person whose job
World Wide Web information on the desktop. Also
is to administer a Database Management System
known as a Web browser.
(DBMS). There is less need for this task on the AS/400
CASE Computer Aided Software Engineering system due to the integrated nature of DB2/400.
CBO Cooperative Business Object database driver Software that connects an application
CBT Computer Based Training to a specific database management system.

database server A server that stores data. Does not source data, or when historical data is necessary for
have eBPCS logic. trend analysis or regulatory reporting. See also
duplicated database and enterprise data warehouse.
datagram Self-contained packets of information that
are forwarded by routers based on their address and enterprise data warehouse A complex solution that
the routing table information contained in the routers. involves data from many areas of the enterprise. This
environment requires a large relational database (the
DBA See database administrator.
data warehouse) that is a central repository of
DCE See distributed computing environment. enterprise data, which is clean, reconciled, and
DDL Database Definition Language consolidated. From this repository, data marts retrieve
data to provide department-level decisions. See also
DDM Distributed Data Management duplicated database and enhanced analysis database.
DDS Data Description Specification enterprise server A database server and logic server.
DFS Distributed Function Services Also referred to as host. See database server.
DHCP Dynamic Host Configuration Protocol ERP Enterprise Resource Planning
distributed computing environment (DCE) A set of FDDI Fiber Distributed Data Interface
integrated software services that allows software firewall A set of technologies that allows an enterprise
running on multiple computers to perform in a manner to test, filter, and route all incoming messages. Are
that is seamless and transparent to the end-users. used to keep an enterprise secure.
DCE provides security, directory, time, remote
procedure calls, and files across computers running on Fourth-Generation Language (4GL) A type of
a network. computer language that accepts system requirements
as input and generates a program to meet those
DLL See dynamic link library. requirements as output. These are useful primary for
DML Data Manipulation Language well-understood procedures such as the generation of
menus, forms, and reports. Structured Query
DSS Decision Support System Language is an example of a 4GL.
DST Dedicated Service Tools FTP File Transfer Protocol
duplicated database A decision support database graphical user interface (GUI) Pronounced "gooey".
that contains a straightforward copy of operational Computer interface that is graphically based as
data. Advantages involve improved performance for opposed to being character-based. An example of a
both operational and reporting environments. See also character-based interface is that of the AS/400
enhanced analysis database and enterprise data system. An example of a GUI is Microsoft Windows.
warehouse. Graphically-based interfaces allow pictures and other
dynamic link library (DLL) A set of program modules graphic images to be used to give people clues on how
that are designed to be invoked from executable files to operate the computer.
when the executable files are run, without having to be GUI See graphical user interface.
linked to the executable files. Typically contain
commonly used functions. HA High Availability
EAI Enterprise Application Integrator HLMI High Level Machine Interface
EBCDIC Extended Binary Coded Decimal Interchange host In the centralized computer model, a large
Code timesharing computer system that terminals
communicate with and rely on for processing.
e BPCS V6.1 of SSA's BPCS software Contrasts with client/server in that those users work at
EC Electronic Commerce computers that perform much of their own processing
and access servers that provide services such as file
ECM Electronic Commerce Manager management, security, and printer management.
ECS Electronic Customer Support HR Human Resources
EDI Electronic Data Interchange HTML See Hypertext Markup Language.
EIS Executive Information System Hypertext Markup Language (HTML) A markup
enhanced analysis database A database containing language used to specify the logical structure of a
a subset of operational data. The data on the document rather than the physical layout. Specifying a
enhanced analysis database performs calculations logical structure makes any HTML document platform
and provides summary data to speed the generation of independent. You can view an HTML document on any
reports and query response times. This solution is desktop capable of supporting a browser. HTML can
appropriate when external data must be added to

include active links to other HTML documents Java Internet executable language that, like C, is
anywhere on the Internet or on intranet sites. designed to be highly portable across platforms. This
programming language was developed by Sun
IBM International Business Machines Corporation
Microsystems. Applets or Java applications can be
IFS Integrated File System accessed from a Web browser and executed at the
IGS IBM Global Services client, provided that the operating system or browser is
Java-enabled (Java is often described as a
ILE Integrated Language Environment scaled-down C++). Java applications are platform
index Represents both an ordering of values and a independent.
uniqueness of values that provide efficient access to Java Database Connectivity (JDBC) An application
data in rows of a table. Is made up of one or more programming interface (API) for Java for connecting to
columns in the table. and using databases. The standard way to access
INS IBM Netfinity Server Java databases, as set by Sun Microsystems. Allows
you to use any JDBC driver database.
interactive processing Processing actions that occur
in response to commands you enter directly into the JDBC See Java Database Connectivity.
system. During interactive processing, you are in JFC Java Foundation Classes
direct communication with the system, and it may
prompt you for additional information while processing job queue A group of jobs waiting to be batch
your request. Contrasts with batch processing. See processed. See also batch processing.
also online. JVM Java Virtual Machine
interface A link between two or more computer KEY A column or combination of columns that identify
systems that allows these systems to send information one or more records in a database table.
to and receive information from one another.
LAN Local Area Network
Internet Worldwide constellation of servers,
LAPD Link Access Procedure for D-channel of ISDN
applications, and information available to a desktop
client through a phone line or other type of remote LF Logical File
access.
LIC Licensed Internal Code
Internet Protocol (IP) Connectionless communication
LPAR Logical Partitioning
protocol that by itself provides a datagram service.
Every node on a TCP/IP network requires an address LPD Line Printer Daemon
that identifies both a network and a local host or node LPO Licensed Program Offering
on the network. In most cases, the network
administrator sets up these addresses when installing LPQ Line Printer Queue
new workstations. In some cases, however, it is LPR Line Printer Requester
possible for a workstation, when booting up, to query a
server for a dynamically assigned address. See LUW Logical Unit of Work
datagram. MAPI See Messaging Application Programming
interoperability Ability of different computer systems, Interface.
networks, operating systems, and applications to work menu A menu that displays numbered selections.
together and share information. Each of these selections represents a program or
intranet Small version of the Internet usually confined another menu. To access a selection from a menu,
to one company or organization. An intranet uses the type the selection number and then press Enter.
functionality of the Internet and places it at the Messaging Application Programming Interface
disposal of a single enterprise. (MAPI) An architecture that defines the components of
IOP Input/Output Processor a messaging system and how they behave. Defines
the interface between the messaging system and the
IP See Internet Protocol. components.
IPCS Integrated PC Server MI Machine Interface
IPDS Intelligent Printer Data Stream middleware A general term that covers all distributed
IPX Internetwork Packet eXchange software needed to support interactions between
clients and servers. Think of it as the software that is in
ISDN Integrated Services Digital Network the middle of the client/server system or the "glue” that
ISV Independent Software Vendor lets the client obtain a service from a server.
ITSO International Technical Support Organization MTU Maximum Transmission Unit
431
multi-tier architecture Client/server architecture that ODW Object Development Workbench
allows multiple levels of processing. A tier defines the
OGS On Going Support - SSA Maintenance
number of computers that can be used to complete
some defined task. OLAP On-line Analytical Processing
NEP Never Ending Program OLE See object linking and embedding.
network computer As opposed to the personal OLM Outbound Logistics Management
computer, the network computer offers (in theory) a OLTP On-line Transaction Processing
lower cost of purchase and ownership and less
complexity. Basically, it is a scaled-down PC (very little OMS Object Messaging Server; Object Messaging
memory or disk space) that can be used to access System
network-based applications (Java applets, ActiveX online Computer functions over which the system has
controls) through a network browser. continuous control.
network computing Often referred to as the next OO Object-Oriented
phase of computing after client/server. While its exact
definition remains obscure, it generally encompasses OOT See object-oriented technology.
issues such as transparent access to computing open database connectivity (ODBC) Defines a
resources, browser-style front-ends, platform standard interface for different technologies to process
independence, and other similar concepts. data between applications and different data sources.
NFS Network File System Interface is made up of a set of function calls, methods
of connectivity, and representation of data types that
NIC Network Interface Card define access to data sources.
NLS National Language Support open systems interconnection (OSI) Model
NPT Non-programmable Terminal developed by the International Standards Organization
(ISO) in the early 1980s. It defines protocols and
object-based technology (OBT) Technology that standards for the interconnection of computers and
supports some of the main principles of object-oriented network equipment.
technology: classes, polymorphism, inheritance, or
encapsulation. OPM Original Program Model
object embedding When an object is embedded in OPS Object Presentation Services

another document, an association is maintained ORB Object Request Broker
between the object and the application that created it.
However, any changes made to the object are also OS/400 Operating System/400
only kept in the compound document. See also object OSC OptiConnect Services Center
linking.
output Information that the computer transfers from
object linking When an object is linked to another internal storage to an external device, such as a
document, a reference is created with the file the printer or a computer form.
object is stored in, as well as with the application that
created it. When the object is modified, either from the output queue See print queue.
compound document or directly through the file in PAG Process Access Group
which it is saved, the change is reflected in that
PCF Product Configurator
application as well as anywhere it has been linked.
See also object embedding. PCL Printer Control Language
object linking and embedding (OLE) A way to PCML Program Call Markup Language
integrate objects from diverse applications, such as
PDML Panel Definition Markup Language
graphics, charts, spreadsheets, text, or an audio clip
from a sound program. See also object embedding and PEX Performance Explorer
object linking. PF Physical File
object-oriented technology (OOT) Brings software PID Process Identifier
development past procedural programming into a
world of reusable programming that simplifies PING Packet InterNet Groper
development of applications. Object orientation is platform independence A benefit of open systems
based on the following principles: classes, and Configurable Network Computing. Applications
polymorphism, inheritance, and encapsulation. that are composed of a single code base can be run
OBT See object-based technology. across a TCP/IP network consisting of various server
platforms and SQL databases.
ODBC See open database connectivity.
PMR Problem Management Record

POP Post Office Protocol SDK Software Developers Kit
portability Allows the same application to run on SDLC Synchronous Data Link Control
different operating systems and hardware platforms.
SDO Semantic Data Object
POSIX Portable Operating System Interface
SDS Semantic Data Services
PPDS Personal Printer Data Stream
server Provides the essential functions for furnishings
PPP Point-to-Point Protocol services to network users (or clients) and provides
management functions for network administrators.
primary key A column or combination of columns that
Some of these functions are: 1) Storage of operating
uniquely identifies each row in a table.
system program modules, utilities, and commands, 2)
print queue A list of tables, such as reports, that you Storage of user programs and data 3) Management
have submitted to be written to an output Configurable functions for the file system, 4) Management functions
Network Computing Implementation device, such as a for security and user access, 5) Network monitoring
printer. The computer spools the tables until it writes and management components, 6) Data protection
them. After the computer writes the table, the system functions for fault tolerance.
removes the table identifier from the list.
It may not be possible for one server to support all
program temporary fix (PTF) Representation of users with the required services. Dedicated servers
changes to IBM software that your organization that handle specific tasks, such as those listed here,
receives on magnetic tapes or diskettes. are also common: 1) Backup and archive servers, 2)
PRPQ Programming Request for Price Quotation Application server, 3) Database server, 4) Fax server,
5) Print Server, 6)Electronic mail server, 7) Directory
PSF Print Services Facility services server
PSP Preventive Service Planning servlet Provides a Java-based solution used to
PTF See Program Temporary Fix. address the problems currently associated with doing
server-side programming, including inextensible
QBE Query by Example scripting solutions. An object that conforms to a
QM Queuing Multiplier specific interface that can be plugged into a
Java-based server. Is to the server-side what applets
QSH Qshell are to the client side.
OSI Open Systems Interconnection SEU Source Entry Utility
RAID Redundant Array of Independent Disks SLIC System Licensed Internal Code
RDBMS Relational Database Management System SLS Single Level Storage
redundancy Storing exact copies of data in multiple SMAPP System Managed Access Path Protection
databases.
SMB System Message Block
relationship Links tables together and facilitates
joining business views for use in an application or SMG Semantic Message Gateway
report. Relationships are created based on indexes. SMP Symmetric Multiprocessing Processor
RFS Remote File System SMTP Simple Mail Transfer Protocol
RIP Routing Information Protocol SNA Systems Network Architecture
RISC Reduced Instruction Set Computing SNMP Simple Network Management Protocol
RPC Remote Procedure Call software Operating system and application programs
run To cause the computer system to perform a that tell the computer how and what tasks to perform.
routine, process a batch of transactions, or carry out spool The function by which the system stores
computer program instructions. generated output to await printing and processing.
SAA Systems Application Architecture spooled table A holding file for output data waiting to
scalability Allows software, architecture, network, or be printed or input data waiting to be processed.
hardware growth that will support software as it grows SPX Sequenced Packet eXchange
in size or resource requirements. The ability to reach
higher levels of performance by adding SQL See Structured Query Language.
microprocessors. SSL Secure Sockets Layer
SCS SNA Character String SST System Service Tools
SD Solution Developers
433
static text Short, descriptive text that appears next to Uniform Resource Locator (URL) Names the
a control variable or field. When the variable or field is address of a document on the Internet or an intranet.
enabled, the static text is black. When the variable or
UPS Uninterruptible Power Supply
field is disabled, the static text is gray.
URL See Universal Resource Locator.
Structured Query Language (SQL) A fourth
generation language used as an industry standard for user defined codes (UDC) Codes within software that
relational database access. Can be used to create users can define, relate to code descriptions, and
databases and to retrieve, add, modify, or delete data assign valid values. Sometimes user defined codes
from databases. Is not a complete programming are referred to as a generic code table. Examples of
language because it does not contain control flow such codes are unit-of-measure codes, state names,
logic. and employee type codes.
table A two-dimensional entity made up of rows and VLF View Layout File
columns. All physical data in a database are stored in WAN Wide Area Network
tables. A row in a table contains a record of related
information. An example is a record in an Employee Web client Any workstation that contains an Internet
table containing the Name, Address, Phone Number, browser. Communicates with the Web server for
Age, and Salary of an employee. Name is an example eBPCS data.
of a column in the employee table. Web server Any workstation that contains the IServer
TCP/IP See Transmission Control Protocol/Internet service, SQL server, Java menus and applications,
Protocol. and Internet middleware. Receives data from the Web
client, and passes the request to the enterprise server.
TCP/IP services port Used by a particular server When the enterprise server processes the information,
application to provide the service that the server is it sends it back to the Web server, and the Web server
designed to provide. The port number must be readily sends it back to the Web client.
known so that an application programmer can request
it by name. workflow According to the Workflow Management
Coalition, workflow means “the automation of a
TDQ Task Dispatching Queue business process, in whole or part, during which
TDR Transaction Data Repository documents, information, or tasks are passed from one
participant to another for action, according to a set of
TELNET Teletypewriter Network
procedural rules.”
TFTP trivial File Transfer Protocol
World Wide Web Part of the Internet that can transmit
Third-Generation Language (3GL) Programming text, graphics, audio, and video. The World Wide Web
language that requires detailed information about how allows clients to launch local or remote applications.
to complete a task. Examples of 3GLs are COBOL, C,
WSG Workstation Gateway
Pascal, and FORTRAN.
WWW See World Wide Web.
TIMI Technology Independent Machine Interface
XMA Extended Middleware Architecture
transaction processing A term used to describe the
process of defining the beginning of a group of XML Extensible Markup Language
database updates and their eventual commitment or XPG X/OPEN Portability Guide
rollback. The purpose of using transaction processing
is to ensure integrity of the database at the application
document level.
Transmission Control Protocol/Internet Protocol
(TCP/IP) The original TCP protocol was developed as
a way to interconnect networks using many different
types of transmission methods. TCP provides a way to
establish a connection between end systems for the
reliable delivery of messages and data.
trigger Allows you to attach default processing to a
data item in the data dictionary. When that data item is
used on an application or report, the trigger is invoked
by an event associated with the data item.
UDB Universal Database
UDC See user defined codes.
UDFS User-Defined File System

Index
64-bit 6, 62
Symbols
#2741 74
#2748 74
A
access control 165, 168, 169, 171
#6533 74
access path 67
#9754 74
access path sharing 219
*ADD 163
access path size 218
*AFPDS 121
action 165, 171
*AFPDSLINE 122
action access control 171
*ALLOBJ 160, 162
action diagramming 46
*AUDIT 160
address 75
*AUTLMGT 163
ADK 33, 34
*DELETE 163
adopted authority 163
*EXECUTE 163
Advanced Function Printing 71
*HPPJLDRV 119
Advanced Function Printing Data Stream 121
*IBMPJLDRV 119
AFP 71
*IOSYSCFG 160, 298
AFPDS line data stream 122
*IPDS 121
ALAUNCH 13
*JOBCTL 160
APAR 87
*LINE 121
Application Development Kernel 33
*OBJEXIST 162
application set 52
*OBJMGT 162
AS/400 80
*OBJOPR 162
AS/400 Integration with Windows NT Server 393
*OBJREF 163
AS/SET 33
*PGMR 161
ASCII data stream 122
*PUBLIC 163
ASCII printers 119
*READ 163
ASP 76
*SAVSYS 160
Asynchronous 7
*SCS 121
Asynchronous Transfer Mode 294
*SECADM 160, 161
ATM 7, 294
*SECOFR 161
Audit Journal 164
*SERVICE 160
authority management 76
*SPLCTL 160
authorization 77
*SQL 110
authorization list 163
*SYS 110
Auxiliary Storage Pool 76
*SYSOPR 161
availability 402, 404
*UPDATE 163
*USER 161
*USERASCII 122 B
backup 71, 389
Backup and Recovery Media Services for AS/400 74
Numerics batch program 46, 54
5763-JC1 393
Battery Backup Unit 6
5769-AF1 394
BBU 6
5769-BR1 74, 394
BI 404
5769-CX2 394
Binary Large Object 69, 114
5769-FNT 394
Binary Synchronous 7
5769-JV1 393
BLOB 69, 114
5769-MG1 394
bottom-up 40
5769-PM1 393
BPCS 90
5769-PT1 394
BPCS Files libraries 92
5769-PW1 394
BPCSF 12
5769-ST1 108, 394
BPCSMENU 16
5769-TC1 393
BPCSO 12
5769-XE1 335, 338
BPCSUSR 12
5769-XW1 337, 345, 394
BRMS 74
5769-XY1 337
BRMS/400 393
5798-AF3 394
Business Intelligence 404

byte-string 66 D
DASD 6, 75
C Data Description Specifications 67
CACI 200 data field 67
CASE 33 data management 70
catalog table 113 Data Model 39, 53
CCSID 97 Data Modeling 39, 40
CEA 11, 83 data stream 121
CFGTCP 301, 303, 331, 333 database 7, 104, 376
Change Query Attributes (CHGQRYA) command 218 file 70, 104
changing query attributes 218 database definition 52
CHECKEMI 24, 29 DATALINK 69
checklist 98 datalink 115
CHGQRYA (Change Query Attributes) command 216, DB2 for AS/400 67
218 DB2 Multisystem 109
CHGSECAUD command 164 DB2 Symmetric Multiprocessing 109
CHGUSRPRF command 161 DB2 UDB 114
CISC 62 DB2 Universal Database 7, 68, 114
Client Access 119 DB2 Universal Database for AS/400 7
Client/Server eBPCS 11 DB2/400 67, 103
Cluster Resource Services 404 DBMS 103
clustering 72, 404 DDL 111, 112
CMDWTR (Command Writer) command 153 DDM 104
CNV900C 99 DDS 67, 70
CNV940C 99 delete share 388
CNVBLDFC 99 development toolset 33
CNVCONVER 99 Device file 104
CNVCREATEC 99 DFS 11
CNVINSTALL 99 DFTRDBCOL 110, 111
collection 110 Direct Access Storage Device 6
collection services 356 disk fragmentation 76
column 52, 67, 110 disk space 75
command 98 display file 70
Command Writer (CMDWTR) command 153 display program 42
command, CL Distributed Function Services 11
Change Query Attributes (CHGQRYA) 218 DML 111, 112
CHGQRYA (Change Query Attributes) 218 domain name 298
compile 70 Domino 8
Computer Aided Software Engineering 33 Domino for AS/400 400
Configurable Enterprise Accounting 11 drag and drop 383
configure TCP/IP 297 DRDA 68
connect as 142 driver program 100
connections 355 DSPAUDJRNE 164
container 26, 54 DSPSFWRSC 340
Continuously Powered Mainstorage 6 Dynamic SQL 112
conversion 98, 99, 100
conversion process 91, 95 E
CONVERT 98 EAC (Extended Adaptive Cache) 402
CONVERT command 98 eBPCS 33, 79, 164, 167
CONVERTC 98 eBPCS security 168
CPM 6 eBPCS user 168
CPR program 13 e-business 406
create 105, 377 ECS 72
table 105, 377 Electronic Customer Support 72
CRTLINETH 299 EMI 22
CRTOUTQ 119 EMI Adapter 23
CRTSQLPKG 110 Enterprise Resource Planning 63
CRTUSRPRF command 161 ERP 63
custom install image 346 Ethernet 7, 294

EVI 68 inactivity time-out 334
Expert Cache 74, 218 inbound message 21
Extended Adaptive Cache (EAC) 402 Information Schema 113
Extensible Markup Language 396 initial program load (IPL) 153
External Messaging Client Library 24 installation source
External Messaging Interface 22 CD 341
externally described file 70 mapped network drive 341
installation types 342
custom 343
F full 343, 345
fat client 11 PC5250 343, 345
FDDI 7 typical 342
field 110 installation, silent 346
field reference 41 integrated file system 70, 106
file serving 384 Integrated File System (IFS) 384
file type 104 Integrated File Systems 106, 378
First Generation Client/Server 11 Integrated Hardware Disk Compression 74
First Generatrion architecture 13 Integrated PC Server 411
Fixes function 360 integration 5, 6
flow 99 Intelligent Printer Data Stream 121
folder 380 inventory 359
create 380 IPDS printers 118
delete 383 IPL (initial program load) 153
rename 382 ISDN 7
Frame-relay 294
FTP 332
function 165 J
function access control 171 Java Database Connection 396
function availability 390 Java Foundation Classes 396
Java Virtual Machine 8
JDBC 396
G JFC 396
gethostbyname 90 job 71
global object 54 management 71
global repository 37 JVM 8
GO LICPGM 339
GO TCPADM 303
group profile 161 K
keyed logical file 67
H
hard delete 207 L
hardware inventory 366 label 26
hierarchical directory structure 71 LAN 149
Hierarchical Storage Management 74 Large object 114
host name 298 layered architecture 5
host print transform 122, 146 library 100, 105, 110, 377
host table 301 LIC 62
HPT 122 Licensed Internal Code 62
HSM 74 Licensed Program Products 393
HTTP Server 396 licensed programs 5
limited capability (LMTCPB) 161
Line data stream 121
I line printer daemon (LPD) 124
I/O architecture 63 line printer requester (LPR) 124
IBM Net.Data 398 LMTCPB 161
ICF file 104 LOB 69, 114
IDLC 7 logical file 67, 110
IEEE 802.3 7 logical partitioning 65, 71, 404
IEEE 802.5 and 802.2 7 LOOPBACK 306
IFS 70, 106 LPAR 65, 71, 404
II11801 87
437
LPD (line printer daemon) 124 output queue 119
LPD printer daemon 149
LPR (line printer requester) 124
LPR printer daemon 149 P
package 110
Panel Definition Markup Language 396
M password 72
Machine Interface 62 PDML 396
Management Central 354 PDT 119, 146
mapping a network drive 141 performance 8
menu 38 physical file 67, 110
message file 55 POP 303
message flow 20 print 71
methodology 79 print serving 384
MI 62 printer 71
Microsoft Windows 8 Printer Definition Table 119, 146
migration 90 printer drivers 143
MIL3 200 printer emulation 145
mirroring 6 printer file 70, 120
Mixed-Mode 11 printer management 71
Printer menu 157
printer sharing 146
N printer writer 123, 153
National Language Support 72 printing configuration 117
Net.Commerce 399 problem management 72
NetQuestion 399 process 56, 59
NetServer 134, 384 product 165, 168
command line 144 product access control 168
finding shares 139 program 165, 169
network 341 program access control 169
network sniffer 200 Program Temporary Fix 72
NEWI library 89 PRTSQLINF 216
NEXTHOP 331 PSF/400 393
NFS 107, 379 PTF 72, 75, 360
NLS 72
Q
O QAUDCTL 164
object 76 QAUDLVL 164
Object Development Workbench 33, 50 QAUTOCFG 119
Object Messaging Server 11 QAUTOCFG value 119
Object Messaging System 89 QAUTORMT 119
Object Presentation Service 11, 13, 14, 53 QAUTOVRT 119
Object Request Broker 13 QDLS 107, 379
Objects 66 QFileSvr.400 107, 379
ODW 33, 50, 51, 56, 59 QJOBMSGQFL 98
OLM 11 QLANSrv 107, 379
OMS 11, 13 QNetWare 107, 379
OMS library 89 QNTC 107, 379
Open Data Path 214 QOpenSys 107, 379
operating system 62 QOPT 107, 379
Operations Navigator 353 QSECOFR 298
using 355 QSQCHKS 109
OPS 11, 13, 14, 53 QSQPRCED 109
Optimal Networks 200 QSTRPRTWTR 153
Optimization Process 216 QSYS.LIB 107, 379
ORB 13 QTCP 304
OS/400 Host Server 340 QTCPIP 303
outbound error message 22 query attribute 216
Outbound Logistics Management 11 changing 218
outbound notification 21

R SMAPP 74
RAID-5 6 SMG 17
RAR 207 SMP 109, 217
README file 87 SMTP 303
record 67, 110 SNA Character String 121
reinstallation 347 SNDTCPSPLF (Send TCP/IP Spool File) command 124
relational database 67 soft delete 207
remote system printing 124 software inventory 367
remote writer 124 special authority 160
report program 44 spooled file 120
repository 37, 38, 51 SQL 67, 108
requirement 88 SQL Call Level Interface 109
resource name 299 SQL index 68
RISC 62 SQL package 110
root 28, 107, 379 SQL terminology 110
root SDO 28 SQL view 67
route 331 SSA millennium tool 94
row 110 SSA Portfolio 1
SSA Portfolio strategy 1
SSA profile 1
S Start Printer Writer (STRPRTWTR) command 153
Save file 104 Start Remote Writer (STRRMTWTR) command 124, 153
scalability 8 stop sharing 388
SDLC 7 storage management 75
SDO 18, 25, 26, 28 Store Manager 399
SDS 19 STRDBG 216
Second Generation architecture 13 STRDBMON 209, 216
Second Generation Client/Server 11 stream files 71
security 76, 164, 371 string table 56
security levels 159 STRPRTWTR (Start Printer Writer) command 148, 153
security officer 168 STRRMTWTR (Start Remote Writer) command 124, 153,
security type 168 155
selective setup 346 STRTCP 303
operations navigator 353 Structured Query Language 67
Semantic Data Object 18, 25 subnet mask 298, 332
Semantic Data Service 19 SUBSTR function 114
semantic message 18 subsystem 77
Semantic Messaging Gateway 17 Symmetric Multiprocessing 109
send message 361 Synchronous Data Link Control 7
Send TCP/IP Spool File (SNDTCPSPLF) command 124 SYS600 program 164
server AS/400 tuning, parallel pre-fetch 218 system concepts and architecture
Server Message Block 384 logical partitioning (LPAR) 65
servers 369 single level storage (SLS) 64
Service Director 73 System Handbook 394
Service Pack 350 system management 71
service pack 350 system values 160
session 80
Session Manager Workstation Setting 12
share T
delete 388 T1/E1/J1 and Fractional T1 7
stop 388 table 53, 67, 110
share name 136 TCP/IP 293
shared objects 384 CFGTCP 300
silent installation 346 domain name 303
single level storage (SLS) 75 Host Table Entry 301
single-level storage 64 interface 300, 331
Site Manager 399 PING 306
sizing 79, 80, 88 TCP/IP route 331
sizing center 85 TCP/IP Connectivity Utilities/400 293
SLS (single level storage) 75 TDR 13
Technology Independent Machine Interface 5, 62
439
Telnet 119
Template Designer 399
thin client 11
TIMI 5, 62
Token-Ring 7, 294
top-down 40
Transmission Control Protocol/Internet Protocol 293
type 26
types of SQL statements 111
U
UDB 69, 114
UDFS 107, 379
uninstalling Client Access Express 350
Uninterruptible Power Supply 6
UNIX 5, 70
UPS 6
user ID 72
user management 72
user profile 77, 160, 167
V
V4R4 71, 396
value 26
view 110
virtual address 75
Virtual Printer Device 151
W
WAN 149
WDKCOM 13
Web serving 396
Wireless Network 294
Work with Output Queues (WRKOUTQ) command 156
workload 83
workload definition 83
World 22
WRKHDWRSC 298
WRKOUTQ (Work with Output Queues) command 156
WRKSPLF 304
WRKSYSVAL command 119
X
X.21 7
X.25 7, 294
XML 396

IBM Redbooks evaluation
Implementing SSA’s eBPCS on the AS/400 System
SG24-5410-00
Your feedback is very important to help us maintain the quality of IBM Redbooks. Please complete this
questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?

_ Customer _ Business Partner _ Solution Developer _ IBM employee
_ None of the above
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction __________
Please answer the following questions:
Was this redbook published in time for your needs? Yes___ No___
If no, please explain:
What other Redbooks would you like to see published?
Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

Implementing SSA’s eBPCS on the AS/400 System SG24-5410-00
Printed in the U.S.A.
SG24-5410-00

sg245410 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

sg245410 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Implementing SSA’s eBPCS

on the AS/400 System

Jaejin Ahn, Nick Camino, Peter Greenfield, Genyphyr Novak

International Technical Support Organization

Implementing SSA’s eBPCS

First Edition (December 1999)

Comments may be addressed to:

© Copyright International Business Machines Corporation 1999. All rights reserved.

Chapter 1. Introduction to SSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Chapter 2. AS/400 introduction . . . . . .. . . . . .. . . . .. . . . . .. . . . . .. . . . . .5

Chapter 3. eBPCS architecture and products . . . . . .. . . . . .. . . . . .. . . . .11

Chapter 4. AS/400 architecture . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . .61

© Copyright IBM Corp. 1999 iii

Chapter 5. eBPCS sizing . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .. . 79

Chapter 6. Installation or migration to eBPCS V6.1.00 . . . . . . . . . . . . . . . 87

Chapter 7. Database and the integrated file system (IFS) . . . . .. . . . . .. 103

iv Implementing SSA’s eBPCS on the AS/400 System

Chapter 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . .159

Chapter 10. eBPCS work management . . . . . . . . . . . . . . . . .. . . . . .. . . .173

Chapter 11. Performance tuning and management . . . . . . . . .. . . . . .. 191

Chapter 12. Logical Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Chapter 13. SSA product global support structure . . . . . . . . . . . . . . . . . 223

vi Implementing SSA’s eBPCS on the AS/400 System

Chapter 14. Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Chapter 15. Tips and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271

Appendix A. TCP/IP basic installation and configurations . . . . . . . . . . . . 293

Appendix B. AS/400 Client Access Express for Windows . . . . . . . . . . . . . 335

viii Implementing SSA’s eBPCS on the AS/400 System

Appendix C. AS/400 Operations Navigator . . . . . . . . . . . . . . . . . . . . . . . . . 353

Appendix D. Complementary products. . . . . . . . . . . . . . . . ...... ....... 393

Appendix E. AS/400 advanced technology. . . . . . . . . . . . . . . . . . . . . . . . . . 395

Appendix F. eBPCS supported languages . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Appendix G. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Appendix H. Related publications . . . . . . . ...... ....... ...... ....... 421

IBM Redbooks evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

x Implementing SSA’s eBPCS on the AS/400 System

© Copyright IBM Corp. 1999 xi

xii Implementing SSA’s eBPCS on the AS/400 System

xiv Implementing SSA’s eBPCS on the AS/400 System

© Copyright IBM Corp. 1999 xvii

In this redbook, you explore the following topics:

The team that wrote this redbook

Peter Greenfield is an AS/400 specialist currently working for SSA in the

Genyphyr Novak is an AS/400 specialist currently working for SSA as a System

© Copyright IBM Corp. 1999 xix

Nick Camino is the Global Technology Manager at SSA, specializing in the

We want our Redbooks to be as helpful as possible. Please send us your

xx Implementing SSA’s eBPCS on the AS/400 System

1.1 SSA profile

North America Latin America Europe, Middle Asia Pacific

5 SSA principal 4 SSA principal 8 SSA principal 9 SSA principal

4 affiliate offices 4 affiliate offices 8 affiliate offices 12 affiliate offices

9 support centers 8 support centers 16 support centers 21 support centers

1.2 SSA Portfolio strategy

© Copyright IBM Corp. 1999 1

1.3 eBPCS backbone

Leveraging SSA's domain experience in multi-mode manufacturing and supply

eBPCS is available on these platforms: IBM AS/400, UNIX HP 9000 with an

2 Implementing SSA’s eBPCS on the AS/400 System

eBPCS is provided in 25 languages, which are split into two-tiers. Tier-1

1.5 eBPCS for the AS/400 system

2.1 AS/400 success factors

Figure 1. AS/400 success factors