ibm.com/redbooks
IBM
Advanced Functions
and Administration
on DB2 Universal Database for iSeries
Hernando Bedoya
Daniel Lema
Vijay Marwaha
Dave Squires
Mark Walas
Learn about referential integrity
and constraints
See how Database Navigator
maps your database
Discover the secrets of
Visual Explain
International Technical Support Organization
Advanced Functions and Administration
on DB2 Universal Database for iSeries
December 2001
SG24-4249-03
© Copyright International Business Machines Corporation 1994, 1997, 2000, 2001. 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.
Fourth Edition (December 2001)
This edition applies to Version 5, Release 1 of OS/400, Program Number 5722-SS1.
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.
Take Note! Before using this information and the product it supports, be sure to read the general
information in “Special notices” on page 345.
© Copyright IBM Corp. 1994, 1997, 2000, 2001 iii
Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Special notice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
IBM trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Part 1. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introducing DB2 UDB for iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 An integrated relational database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 DB2 UDB for iSeries: An overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 DB2 UDB for iSeries basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 DB2 UDB for iSeries advanced functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 DB2 Universal Database for iSeries sample schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 2. Using the advanced functions: An Order Entry application. . . . . . . . . . . . 11
2.1 Introduction to the Order Entry application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Order Entry application overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Order Entry database overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 DB2 UDB for iSeries advanced functions in the Order Entry database . . . . . . . . . . . . 17
2.4.1 Referential integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Two-phase commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Part 2. Advanced functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 3. Referential integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Referential integrity concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Defining a referential integrity relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Constraint prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Journaling and commitment control requirements . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3 Referential integrity and access paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Creating a referential constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Primary key and unique constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 Referential constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Another example: Order Entry scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 Self-referencing constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Constraints enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Locking considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 Referential integrity rules ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.3 A CASCADE example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Journaling and commitment control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.1 Referential integrity journal entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.2 Applying journal changes and referential integrity . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7 Referential integrity application impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.1 Referential integrity I/O messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.2 Handling referential integrity messages in applications . . . . . . . . . . . . . . . . . . . . 51
iv Advanced Functions and Administration on DB2 Universal Database for iSeries
3.8 Referential integrity constraint management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.1 Constraint states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.2 Check pending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.3 Constraint commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.4 Removing a constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.8.5 Save and restore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.8.6 Restore and journal apply: An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8.7 Displaying constraint information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 4. Check constraint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1 Domain or table constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.2 Referential integrity constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.3 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 DB2 UDB for iSeries check constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 Defining a check constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5 Check constraint integration into applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.1 Check constraint I/O messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.2 Check constraint application messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6 Check constraint management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6.1 Check constraint states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6.2 Save and restore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.7 Tips and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 5. DRDA and two-phase commitment control . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1 Introduction to DRDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.1 DRDA architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.2 SQL as a common DRDA database access language . . . . . . . . . . . . . . . . . . . . . 84
5.1.3 Application requester and application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.4 Unit of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.5 Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Comparing DRDA-1 and DRDA-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3 DRDA-2 connection management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3.1 Connection management methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2 Connection states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.4 Two-phase commitment control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.1 Synchronization Point Manager (SPM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5 DB2 UDB for iSeries SQL support for connection management. . . . . . . . . . . . . . . . . . 92
5.5.1 Example of an application flow using DRDA-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6 DRDA-1 and DRDA-2 coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 Recovery from failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7.1 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7.2 Automatic recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7.3 Manual recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.8 Application design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.8.1 Moving from DRDA-1 to DRDA-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.9 DRDA-2 program examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.9.1 Order Entry main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.9.2 Deleting an order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.9.3 Inserting the detail rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.10 DRDA over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.10.1 Configuring DRDA over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Contents v
5.10.2 Examples of using DRDA over TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.10.3 Troubleshooting DRDA over TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.11 DB2 Connect access to an iSeries server via TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . 120
5.11.1 On the iSeries server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.11.2 On the workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.11.3 Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Chapter 6. DB2 Import and Export utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.2 DB2 UDB for iSeries Import utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.2.1 CPYFRMIMPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.2.2 Data load example (file definition file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.3 Data load example (Data Definition Language) . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.2.4 Parallel data loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.3 DB2 UDB for iSeries Export utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3.1 CPYTOIMPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3.2 Creating the import file (TOFILE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.3 Exporting the TOFILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.3.4 Creating the import file (STMF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.3.5 Exporting the STMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.4 Moving data from DB2 UDB 7.2 to DB2 UDB for iSeries . . . . . . . . . . . . . . . . . . . . . . 149
6.4.1 First approach: Using the Export and Import utilities . . . . . . . . . . . . . . . . . . . . . 149
6.4.2 Second approach: Using Export and CPYFRMIMPF . . . . . . . . . . . . . . . . . . . . . 152
6.5 Moving data from DB2 UDB for iSeries into DB2 UDB 7.2 . . . . . . . . . . . . . . . . . . . . . 152
6.5.1 Using the Import and Export utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
6.5.2 Using the CPYTOIMPF command and the Import utility. . . . . . . . . . . . . . . . . . . 153
Part 3. Database administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Chapter 7. Database administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.1 Database overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.1.1 New in V5R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.2 DB2 Universal Database for iSeries through Operations Navigator overview . . . . . . 161
7.2.1 Database functions overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.2.2 Database library functions overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.2.3 Creating an OS/400 library or collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.2.4 Library-based functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.2.5 Object-based functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.3 Run SQL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.3.1 ODBC and JDBC connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3.2 Running a CL command under SQL script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.3.3 Run SQL Scripts example using a VPN journal . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.3.4 Run SQL Scripts Run options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.3.5 DDM/DRDA Run SQL Script configuration summary . . . . . . . . . . . . . . . . . . . . . 216
7.4 Change Query Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.5 Current SQL for a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.6 SQL Performance Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.6.1 Starting the SQL Performance Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
7.6.2 Reviewing the SQL Performance Monitor results . . . . . . . . . . . . . . . . . . . . . . . . 226
7.6.3 Importing data collected with Database Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 233
Chapter 8. Database Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8.1.1 System requirements and planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
vi Advanced Functions and Administration on DB2 Universal Database for iSeries
8.2 Finding Database Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8.3 Finding database relationships prior to V5R1M0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
8.4 Database Navigator maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8.5 The Database Navigator map interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.5.1 Objects to Display window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
8.5.2 Database Navigator map display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
8.6 Available options on each active icon on a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
8.6.1 Table options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
8.6.2 Index options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.6.3 Constraint options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
8.6.4 View options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
8.6.5 Journal options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.6.6 Journal receiver options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.7 Creating a Database Navigator map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
8.7.1 Adding new objects to a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
8.7.2 Changing the objects to include in a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
8.7.3 Changing object placement and arranging object in a map . . . . . . . . . . . . . . . . 265
8.7.4 Creating a user-defined relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
8.8 The Database Navigator map icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Chapter 9. Reverse engineering and Generate SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.1.1 System requirements and planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.1.2 Generate SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.2 Generating SQL from the library in Operations Navigator. . . . . . . . . . . . . . . . . . . . . . 276
9.2.1 Generating SQL to PC and data source files on the iSeries server . . . . . . . . . . 281
9.2.2 Generating SQL from the Database Navigator map . . . . . . . . . . . . . . . . . . . . . . 289
9.2.3 Generating SQL from DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Chapter 10. Visual Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
10.1 A brief history of the database and SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
10.2 Database tuning so far . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
10.2.1 Query optimizer debug messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
10.2.2 Database Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.2.3 The PRTSQLINF command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.2.4 Iterative approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.3 Introducing Visual Explain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.3.1 What is Visual Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.3.2 Finding Visual Explain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
10.3.3 Data access methods and operations supported . . . . . . . . . . . . . . . . . . . . . . . 305
10.4 Using Visual Explain with the SQL Script Center . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.4.1 The SQL Script Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.4.2 Visual Explain Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.4.3 Run and Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.5 Navigating Visual Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.5.1 Menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
10.5.2 Action menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
10.5.3 Controlling diagram level of detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.5.4 Displaying the query environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.5.5 Visual Explain query attributes and values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.6 Using Visual Explain with Database Monitor data. . . . . . . . . . . . . . . . . . . . . . . . . . . 318
10.7 Non-SQL interface considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
10.7.1 Query/400 and Visual Explain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Contents vii
10.7.2 The Visual Explain icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
10.8 SQL performance analysis using Visual Explain. . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.8.1 Database performance analysis methodology . . . . . . . . . . . . . . . . . . . . . . . . . 323
Appendix A. Order Entry application: Detailed flow . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Program flow for the Insert Order Header program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Program description for the Insert Order Header program . . . . . . . . . . . . . . . . . . . . . . 330
Program flow for the Insert Order Detail program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Program description for Insert Order Detail program . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Program flow for the Finalize Order program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Program description for the Finalize Order program. . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Appendix B. Referential integrity: Error handling example . . . . . . . . . . . . . . . . . . . . 337
Program code: Order Header entry program – T4249CINS. . . . . . . . . . . . . . . . . . . . . . . . 338
Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
System requirements for downloading the Web material . . . . . . . . . . . . . . . . . . . . . . . 341
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
viii Advanced Functions and Administration on DB2 Universal Database for iSeries
© Copyright IBM Corp. 1994, 1997, 2000, 2001 ix
Preface
Dive into the details of DB2 Universal Database (UDB) for iSeries advanced functions and
database administration. This IBM Redbook aims to equip programmers, analysts, and
database administrators with all the skills and tools necessary to take advantage of the
powerful features of the DB2 Universal Database for iSeries relational database system. It
provides suggestions, guidelines, and practical examples about when and how to effectively
use DB2 Universal Database for iSeries.
This redbook contains information that you may not find anywhere else, including
programming techniques for the following functions:
Referential integrity and check constraints
DRDA over SNA, DRDA over TCP/IP, and two-phase commit
DB2 Connect
Import and Export utilities
This redbook also offers a detailed explanation of the new database administration features
that are available with Operations Navigator in V5R1. Among the tools, you will find:
Database Navigator
Reverse engineering and Generate SQL
Visual Explain
Database administration using Operations Navigator
This redbook is a follow-on from the previous redbook DB2 UDB for AS/400 Advanced
Database Functions, SG24-4249-02. With the focus on advanced functions and
administration in this fourth edition of the book, we moved the information about stored
procedures and triggers into a new redbook – Stored Procedures and Triggers on DB2
Universal Database for iSeries, SG24-6503.
Prior to reading this redbook, you should have some knowledge of the relational database
technology and application development environment on the IBM ~ iSeries server.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world working at the
International Technical Support Organization (ITSO) Rochester Center.
Hernando Bedoya is an IT Specialist at the IBM ITSO, in Rochester, Minnesota. He writes
extensively and teaches IBM classes worldwide in all areas of DB2 UDB for iSeries. Before
joining the ITSO more than one year ago, he worked for IBM Colombia as an AS/400 IT
Specialist doing presales support for the Andean countries. He has 16 years experience in
the computing field and has taught database classes in Colombian universities. He holds a
Masters Degree in computer science from EAFIT, Colombia. His areas of expertise are
database technology, application development, and data warehousing.
Daniel Lema is an IT Architect at IBM Andean with 13 years of experience. Some of his
projects include working with Business Intelligence, ERP implementation, and outsourcing.
Previously, he worked as a Sales Specialist for the Midrange Server Product Unit (formerly
the AS/400 Product Unit) helping customers and sales people in designing AS/400- and
DB2/400-based solutions. He is a lecturer in Information Management and Information
x Advanced Functions and Administration on DB2 Universal Database for iSeries
Technology Planning in the Graduate School at EAFIT University and other colombian
universities. He is also an Information Systems Engineer and working on his project degree
for getting his Applied Mathematics Master Degree at EAFIT University in which he has
already finished the academic activities.
Vijay Marwaha is an IT Specialist with IBM Global Services - Business Innovation Services,
in Cranford, New Jersey. He has 30 years experience in the computing field. He has worked
with the System/38, AS/400, and iSeries for the last 16 years. His areas of expertise are
database design, application design, and development for performance, data warehousing,
and availability. He is also a chemical engineer and holds an MBA from the Indian Institute of
Management Calcutta.
David F Squires is an IT Specialist at the Technical Support center in the UK. He is a Level 2
Operations Specialist who deals with database and Main Storage issues. He has been
working with the AS/400 system since it was announced back in 1988 and continues to work
with the iSeries server today. He has more than 15 years experience in the computing field.
Mark Walas is the Technical Director of Sierra Training Services Limited in England. Sierra
Training is a leading iSeries and AS/400 education provider in the United Kingdom. He is
currently responsible for the education strategy and course development of Sierra Training
Services. He teaches iSeries and AS/400 courses extensively. He has 23 years of experience
in the computing field.
This redbook is based on the projects conducted in 1994, 1997, and 2000 by the ITSO
Rochester Center.
The advisor of the first edition of this redbook was:
Michele Chilanti
ITSO, Rochester Center
The authors of the first edition of this redbook in 1994 were:
Thelma Bruzadin, ITEC Brazil
Teresa Kan, IBM Rochester
Oh Sun Kang, IBM Korea
Alex Metzler, IBM Switzerland
Kent Milligan, IBM Rochester
Clarice Rosa, IBM Italy
The advisor of the second and third editions of this redbook was:
Jarek Miszczyk
ITSO, Rochester Center
The authors of the second edition of this redbook in 1997 were:
Hernando Bedoya, IBM Colombia
Deepak Pai, IBM India
The authors of the third edition of this redbook in 2000 were:
Christophe Delponte, IBM Belguim
Roger H. Y. Leung, IBM Hong Kong
Suparna Murthy, IBM India
Preface xi
Thanks to the following people for their invaluable contributions to this project:
Mark Anderson
Christopher Brandt
Michael Cain
Jim Cook
John Eberhard
Jim Flanagan
Mietek Konczyk
Kent Milligan
Kathy Passe
Tom Schrieber
IBM Rochester
Cintia Marques
IBM Brazil
Simona Pachiarini
IBM Italy
Andrew Fellows
IBM UK
Special notice
This publication is intended to help programmers, analysts, and database administrators to
implement DB2 UDB for iSeries. The information in this publication is not intended as the
specification of any programming interfaces that are provided by DB2 UDB for iSeries. See
the PUBLICATIONS section of the IBM Programming Announcement for DB2 UDB for iSeries
for more information about what publications are considered to be product documentation.
IBM trademarks
The following terms are trademarks of the International Business Machines Corporation in the
United States and/or other countries:
e (logo)®
IBM ®
AFP™
AIX®
APPN®
AS/400®
CICS®
COBOL/400®
DataPropagator™
DB2®
DB2 Connect™
DB2 Universal Database™
Distributed Relational Database Architecture™
DPI®
DRDA®
GDDM®
Informix™
iSeries™
MORE™
Redbooks™
Redbooks Logo
MVS™
Operating System/400®
OS/2®
OS/390®
OS/400®
PartnerWorld®
Perform™
RPG/400®
SAA®
S/390®
Sequent®
SP™
SP1®
SP2®
System/36™
TME®
Notes®
xii Advanced Functions and Administration on DB2 Universal Database for iSeries
Comments welcome
Your comments are important to us!
We want our IBM Redbooks to be as helpful as possible. Send us your comments about this
or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to the address on page ii.
© Copyright IBM Corp. 1994, 1997, 2000, 2001 1
Part 1 Background
This part introduces the basics concepts of DB2 Universal Database for iSeries. It provides a
description of the Order Entry application used to illustrate the use of the advanced features
used in DB2 Universal Database for iSeries. Plus, it describes the sample database provided
in DB2 Universal Database for iSeries in V5R1.
Part 1
2 Advanced Functions and Administration on DB2 Universal Database for iSeries
© Copyright IBM Corp. 1994, 1997, 2000, 2001 3
Chapter 1. Introducing DB2 UDB for iSeries
This chapter includes:
A general introduction to DB2 UDB for iSeries
An overview on the contents in this redbook
A definition of the sample schema provided in V5R1
1
4 Advanced Functions and Administration on DB2 Universal Database for iSeries
1.1 An integrated relational database
Integration has been one of the major elements of differentiation of the iSeries server platform
in the information technology marketplace. The advantages and drawbacks of fully integrated
systems have been the subject of endless disputes in the last few years. The success of the
iSeries server indicates that integration is still considered one of the premier advantages of
this platform. Security, communications, data management, backup and recovery. All of these
vital components have been designed in an integrated way on the iSeries server. They work
according to a common logic with a common end-user interface. They fit together perfectly,
since all of them are part of the same software—the Operating System/400 (OS/400).
The integrated relational database manager has always been one of the most significant
facilities that the iSeries server provides to users. Relying on a database manager integrated
into the operating system means that virtually all the user data on the iSeries server is stored
in a relational database and that the access to the database is implemented by the operating
system itself. Some database functions are implemented at a low level in the iSeries server
architecture, while some are even performed by the hardware.
A recent survey pointed out that a significant percentage of iSeries server customers do not
even know that all of their business data is stored in a relational database. This might sound
strange if you think that we consider the integrated database as one of the main technological
advantages of the iSeries server platform. On the other hand, this means that thousands of
customers use, manage, back up, and restore a relational database every day without even
knowing that they have it installed on their system. This level of transparency has been made
possible by the integration and by the undisputed ease of use of this platform. These have
been key elements of the success of the iSeries server database system in the marketplace.
During the last couple of years, each new release of OS/400 has enhanced DB2 UDB for
iSeries with a dramatic set of new functions. As a result of these enhancements, the iSeries
server has become one of the most functionally rich relational platforms in the industry.
DB2 UDB for iSeries is a member of the DB2 UDB family of products, which also includes
DB2 for OS/390 and DB2 Universal Database. The DB2 UDB family is the IBM proposal in the
marketplace of relational database systems and guarantees a high degree of application
portability and a sophisticated level of interoperability among the various platforms that are
participating in the family.
1.2 DB2 UDB for iSeries: An overview
This section provides a quick overview of the major features of DB2 Universal Database for
iSeries. A full description of the functions that are mentioned in this section can be found in
several IBM manuals, for example:
Database Programming, SC41-5701
DDS Reference, SC41-5712
SQL Reference, SC41-5612
Chapter 1. Introducing DB2 UDB for iSeries 5
1.2.1 DB2 UDB for iSeries basics
As previously mentioned, the major distinguishing characteristic of the iSeries server
database manager is that it is part of the operating system. In practice, this means that the
large majority of your iSeries server data is stored in the relational database. Although the
iSeries server also implements other file systems in its design, the relational database on the
iSeries server is the most commonly used by the customers. Your relational data is stored in
the database, plus typical non-relational information, such as the source of your application
programs.
Physical files and tables
Data on the iSeries server is stored in objects called physical files. Physical files consist of a
set of records with a predefined layout. Defining the record layout means that you define the
data structure of the physical file in terms of the length and the type of data fields that
participate in that particular layout.
These definitions can be made through the native data definition language of DB2 UDB for
iSeries, called Data Description Specifications (DDS). If you are familiar with other relational
database platforms, you are aware that the most common way to define the structure of a
relational database is by using the data definition statements provided by the Structured
Query Language (SQL). This is also possible on the iSeries server. The SQL terminology can
be mapped to the native DB2 UDB for iSeries terminology for relational objects. An SQL table
is equivalent to a DDS defined physical file. We use both terms interchangeably in this book.
Similarly, table rows equate to physical file records for DB2 UDB for iSeries, and SQL
columns are a synonym for record fields.
Logical files, SQL views, and SQL indexes
By using DDS, you can define logical files on your physical files or tables. Logical files
provide a different view of the physical data, allowing columns subsetting, record selection,
joining multiple database files, and so on. They can also provide physical files with an access
path when you define a keyed logical file. Access paths can be used by application programs
to access records directly by key or for ensuring uniqueness.
On the SQL side, there are similar concepts. 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 UDB for iSeries, and they cannot be
considered to exactly coincide.
“Database file” refers to any DB2 UDB for iSeries file, such as a logical or physical file, an
SQL table, or view. Any database files can be used by applications for accessing DB2 UDB
for iSeries data.
DB2 UDB for iSeries in a distributed environment
It is becoming more and more common for companies and businesses to organize their
computing environment in a distributed way. The need to access remote data is constantly
growing. DB2 UDB for iSeries provides several options for operating with remote platforms,
both homogeneous and heterogeneous.
The Distributed Data Management (DDM) architecture is the basis for distributed file access.
You can create a DDM file on your iSeries server and have it direct your data access requests
to a remote database file. This remote file can be another DB2 UDB for iSeries database file
or a Customer Information Control System (CICS) managed data file residing on a host
platform. Only native data access is allowed for DDM files.
6 Advanced Functions and Administration on DB2 Universal Database for iSeries
On top of the DDM architecture, IBM has created the Distributed Relational Database
Architecture (DRDA). DRDA defines the protocol by which an SQL application can access
remote tables and data. DB2 UDB for iSeries participates in this architecture, as do all the
products of the DB2 Family. This means that your DB2 UDB for iSeries database can be
accessed by any SQL application running on another iSeries server or on DB2 for OS/390,
DB2 Universal Database, or DB2 for VM. A DB2 UDB for iSeries application with embedded
SQL can access relational data stored in a DB2 for OS/390, DB2 for VM, or on another
iSeries server. The DRDA architecture is implemented directly into OS/400.
IBM has also licensed DRDA to many other companies, such as Informix Software Inc.,
Ingres Corporation, and Oracle Corporation.
The iSeries server provides several other interfaces for client platforms to access DB2 UDB
for iSeries data. Client Access for iSeries is a rich product that allows broad interoperability
between a PC client and the iSeries server. For database access, Client Access for iSeries
provides the PC with:
A sophisticated file transfer function that allows subsetting of rows and columns
Remote SQL APIs that you can embed in your PC programs to access data stored in DB2
UDB for iSeries tables
An Open Database Connectivity (ODBC) interface to DB2 UDB for iSeries data that allows
applications that use this protocol to access the iSeries server database
Terminology
Since the AS/400 system (which today is the iSeries server) was developed before SQL was
widely-used, OS/400 uses different terminology than what SQL uses to refer to database
objects. The terms and its SQL equivalent are found in Table 1-1. The terms have been
interchanged throughout the book.
Table 1-1 SQL and OS/400 term cross reference
1.2.2 DB2 UDB for iSeries advanced functions
The main purpose of this redbook is to describe, in detail and with practical examples, the rich
set of functions that have been implemented in DB2 UDB for iSeries. This section provides a
quick overview of the most important advanced features.
SQL term iSeries term
Table Physical file
View Non-keyed logical file
Index Keyed logical file
Column Field
Row Record
Schema Library, collection
Log Journal
Isolation level Commitment control level
Chapter 1. Introducing DB2 UDB for iSeries 7
Referential integrity
Referential integrity is a set of mechanisms by which a database manager enforces some
common integrity rules among database tables. An example of a referential integrity rule is a
customer master table and an invoice table. You do not want invoices related to non-existing
customers (every invoice must reference a valid customer). As a consequence of this rule, it
makes sense that, if somebody attempts to delete a customer with outstanding invoices, the
delete operation is rejected. Without referential integrity implementation, the only way to
ensure that these rules are enforced is by writing appropriate routines in the applications.
With referential integrity, this kind of rule can be implemented directly into the database. Once
the rules are defined, DB2 UDB for iSeries automatically enforces them for the users.
Check constraint
Check constraints are validity checks that can be placed on fields of database physical files
and columns of SQL tables. It ensures that the value being entered in a column of a table
belongs to the set of valid values defined for that column. For example, you may specify that
the “legal” values for an employee evaluation field are defined as an integer, such as 2, 3, 4,
or 5. Without the check constraint, a user can enter any integer value into such a column. To
ensure that the actual value entered is as specified, you must use a trigger or code the rule in
your application.
DRDA and two-phase commit
DRDA is the architecture that meets the needs of application programs requiring access to
distributed relational data. This access requires connectivity to and among relational
database managers. The database managers can run in like or unlike operating environments
and communicate and operate with each other in a way that allows them to execute SQL
statements on another computer system. There are several degrees of distribution of
database management system functions. DB2 UDB for iSeries currently supports the
following levels of distribution:
Remote unit of work
With a remote unit of work, an application program executing in one system can access
data at a remote system using SQL. A remote unit of work supports access to one
database system within a unit of work (transaction). If the application needs to interact with
another remote database, it has to commit or rollback the current transaction, stop the
current connection, and start a new connection.
Distributed unit of work
With a distributed unit of work, within one unit of work, an application executing in one
system can direct SQL requests to multiple remote database systems. When the
application is ready to commit the work, it initiates the commit, and commitment
coordination is provided by a synchronization point manager. Whether an application can
update multiple databases in one unit of work depends on the two-phase commit protocol
support between the application's location and the remote systems.
Procedures and triggers
Stored procedures and triggers used to be part of the original book. Due to their importance
we have decided to move them to the new redbook Stored Procedures and Triggers on DB2
Universal Database for iSeries, SG24-6503.
The first part of this book discusses, in detail, referential integrity, check constraints, and
DRDA and two-phase commit.
8 Advanced Functions and Administration on DB2 Universal Database for iSeries
1.3 DB2 Universal Database for iSeries sample schema
Within the code of OS/400 V5R1M0, there is a stored procedure that creates a fully
functioning database. This database contains tables, indexes, views, aliases, and constraints.
It also contains data within these objects. This database is used in this book to illustrate the
new Database Navigator functions announced with Operations Navigator V5R1M0.
This database also helps with problem determination since the program is shipped with the
OS/400 V5R1M0 code. By calling a simple program, you can create a duplicate of this
database on any system running V5R1M0. This enables customers and support staff to work
on the same database for problem determination.
This database can also be used as a learning tool to explain the various functions available at
V5R1M0 with Database Navigator. Furthermore, it provides a method for teaching
applications programmers or new database administrators how relationships can be built on
the iSeries server between tables, schemas, indexes, etc.
Working on the same database provides the ability for customers around the world to see the
new functionality at V5R1M0. It also simplifies the setup environment for the workshops that
are created in the future for use by customers.
You create the database by issuing the following SQL statement:
CALL QSYS.CREATE_SQL_SAMPLE('SAMPLEDBXX')
This statement can be found in the pull-down box of the Run SQL Script window example
shown in Figure 1-1.
Figure 1-1 Example display showing the schema CREATE statement
Note: The schema name needs to be in uppercase. This sample schema will also be used in
future DB2 Universal Database for iSeries documentation.
Chapter 1. Introducing DB2 UDB for iSeries 9
As a group, the tables include information that describes employees, departments, projects,
and activities. This information makes up a sample database demonstrating some of the
features of DB2 Universal Database for iSeries. An entity-relationship (ER) diagram of the
database is shown in Figure 1-2.
Figure 1-2 Sample schema: Entity-relationship diagram
The tables are:
Department Table (DEPARTMENT)
Employee Table (EMPLOYEE)
Employee Photo Table (EMP_PHOTO)
Employee Resume Table (EMP_RESUME)
Employee to Project Activity Table (EMPPROJACT)
Project Table (PROJECT)
Project Activity Table (PROJACT)
Activity Table (ACT)
Class Schedule Table (CL_SCHED)
In Tray Table (IN_TRAY)
Indexes, aliases, and views are created for many of these tables. The view definitions are not
included here. There are three other tables created that are not related to the first set:
Organization Table (ORG)
Staff Table (STAFF)
Sales Table (SALES)
Note: Some of the examples in this book use the sample database that was just described.
10 Advanced Functions and Administration on DB2 Universal Database for iSeries
© Copyright IBM Corp. 1994, 1997, 2000, 2001 11
Chapter 2. Using the advanced functions:
An Order Entry application
This chapter provides:
A description of the Order Entry scenario
The database structure
The logical flow of each application component
A highlight of the advanced functions used in this application
2
12 Advanced Functions and Administration on DB2 Universal Database for iSeries
2.1 Introduction to the Order Entry application
This chapter describes how a simple Order Entry application can take advantage of the
advanced functions that are available with DB2 UDB for iSeries. It provides a description of
the complete application, in terms of logical flow and database structure. The actual
implementation of this application can be found in the specific chapters where we exploit this
application scenario to show you how to use the DB2 UDB for iSeries functions.
By presenting an application scenario, we intend to show how the advanced DB2 UDB for
iSeries functions can be applied to a real-life environment and the technical implications of
using those functions. For this reason, the application may appear simplistic in some respects
(for example, the user interface or some design choices). We present a simple,
easy-to-understand scenario that includes most of the aspects we discuss throughout this
redbook.
We chose to develop the various components of the application using different programming
languages to show how the various languages can interact with the DB2 UDB for iSeries
functions.
As mentioned previously, the stored procedures and triggers moved to a separate redbook
called Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503.
2.2 Order Entry application overview
The Order Entry application shown in Figure 2-1 represents a simple solution for an office
stationery wholesaler.
Chapter 2. Using the advanced functions: An Order Entry application 13
Figure 2-1 Application overview: Interaction of DB2 UDB for iSeries functions
This application has the following characteristics:
The wholesale company runs a main office and several branch offices.
A requirement of the branch offices is their autonomy and independence from the main
office.
Data is, therefore, stored in a distributed relational database. Information about customers
and orders is stored at the branch office, where the central system keeps information
about the stock and suppliers.
A main requirement of this company is the logical consistency of the database. All orders,
for example, must be related to a customer, and all the products in the inventory must be
related to a supplier. This is why we need to use referential integrity in this database. See
3.4.3, “Another example: Order Entry scenario” on page 32, which describes how
referential integrity can be configured for this particular scenario.
The sales representative contacts the customer over the telephone. Each sales
representative is assigned a pool of customers. According to the policy of the sales
division of this company, a sales representative is allowed to place orders only for a
customer of their pool. This policy is needed to guarantee a fair distribution of the
commissions on the sales representative’s turnover. This requirement can be effectively
enforced by means of a trigger program that automatically checks the relationship
between a customer and the sales representative when the order is placed. This is
addressed in Stored Procedures and Triggers on DB2 Universal Database for iSeries,
SG24-6503.
Insert Order
Header
Insert Order
Detail
Finalize
Order
RI Remote
SP Remote
2
P
C
Remote System
(Head Office)
Local System
(Branch Office)
Order
Detail
Order
Header
Sales/
Customer
Restart
TRI
Update
INV
Customer
Supplier
Stock
RI
RI
TRI
RI
LEGEND
RI REFERRAL INTEGRITY
CONSTRAINT
TRI TRIGGER
2PC
SP STORED PROCEDURE
TWO PHASE COMMIT
14 Advanced Functions and Administration on DB2 Universal Database for iSeries
In placing an order, the sales representative first introduces some general data, such as
the order date, the customer code, and so on. This process generates a row in the Order
Header table.
The sales representative then inserts one or more items for that specific order. If the
specific item is out of stock, we want the application to look in the inventory for an
alternative article. The inventory is organized in categories of products and, on this basis,
the application performs a search. Since the inventory table is located remotely, we use a
DRDA(*) connection between the systems. In addition, since the process of searching the
inventory may involve many accesses to the remote database, a stored procedure is
called to carry out this task.
When the item or a replacement has been found, the inventory is updated, and a row is
inserted in the local order detail table.
At this point, we want to release the inventory row to allow other people to place a new
order for the same product. We commit the transaction at this time. DB2 UDB for iSeries
ensures the consistency of the local and remote databases, thanks to the two-phase
commitment control support.
When all order items have been entered, the order is finished and a finalizing order
program is called. This program can:
– Add the total amount of the order to the Customer table to reflect the customers'
turnover
– Update the total revenue produced by the sales representative on this customer
– Update the total amount of the order in the Order Header table
An update event of the Order Header table starts another trigger program that writes the
invoice immediately at the branch office.
As we mentioned, the “atomic” logical transaction is completed when a single item in the
order has been inserted to reduce the locking exposures. If the system or the job fails, we
must be able to detect incomplete orders. This can be done when the user restarts the
application. A simple restart procedure will check for orders having the total equal to zero
(not “finalized”). These orders are deleted and the stock quantity of all the items is
increased by the amount that we had reserved during the order placement. We can also
present a choice menu to the user, asking whether the incomplete orders should be
finalized.
2.3 Order Entry database overview
The Order Entry application is based on a distributed database. Each branch office location
keeps all the data related to its own customers in its local database. The information
concerning the items available in the warehouse is stored in the remote database at the head
office.
The local database consists of these physical files/tables:
CUSTOMER table: Contains the information related to the customers
ORDERHDR table: With the data related to where the Order items are stored
ORDERDTL table: Where each row represents a Detail of an Order
SALESCUS table: Keeps the relationship between a sales representative and the
customers for whom that sales representative is authorized to place orders
Chapter 2. Using the advanced functions: An Order Entry application 15
The central database consists of two tables:
STOCK table: Contains information about the contents of the warehouse
SUPPLIER table: Contains information related to the suppliers
Table 2-1 through Table 2-7 on page 16 show the record layouts for the files of both local and
central databases.
Table 2-1 CUSTOMER table
Table 2-2 ORDERHDR table
Table 2-3 ORDERHDR table
Field name Alias Type Description
CUSTOMER_NUMBER CUSBR CHAR(20) Customer number
CUSTOMER_NAME CUSNAM CHAR(20) Customer name
CUSTOMER_TELEPHONE CUSTEL CHAR(15) Customer phone
number
CUSTOMER_FAX CUSFAX CHAR(15) Customer fax number
CUSTOMER_ADDRESS CUSADR CHAR(20) Customer address
CUSTOMER_CITY CUSCTY CHAR(20) Customer city
CUSTOMER_ZIP CUSZIP CHAR(5) Customer ZIP code
CUSTOMER_CRED_LIM CUSCRD DEC(11,2) Customer credit limit
CUSTOMER_TOT_AMT CUSTOT DEC(11,2) Customer total amount
Field name Alias Type Description
ORDER_NUMBER ORHNBR CHAR(5) Order number
CUSTOMER_NUMBER CUSBR CHAR(5) Customer number
ORDER_DATE ORHTE DATE Order date
ORDER_DELIVERY ORHDLY DATE Order delivery date
ORDER_TOTAL ORHTOT DEC(11,2) Order total
ORDER_SALESREP SRNBR CHAR(10) Sales Rep. number
Field name Alias Type Description
ORDER_NUMBER ORHNBR CHAR(5 Order number
PRODUCT_NUMBER PRDNBR CHAR(5) Product number
ORDERDTL_QUANTITY ORDQTY DEC(5,0) Order detail quantity
ORDERDTL_TOTAL ORDTOT DEC(9,2) Order detail total
16 Advanced Functions and Administration on DB2 Universal Database for iSeries
Table 2-4 SALESCUS table
Table 2-5 SUPPLIER table
Table 2-6 STOCK table
Table 2-7 STOCKPIC table
Field name Alias Type Description
SALESREP_NUMBER SRNBR CHAR(10) Sales Rep. number
CUSTOMER_NUMBER CUSBR CHAR(5) Customer number
SALES_AMOUNT SRAMT DEC(11,2) Sales rep. total amount
for this customer
Field name Alias Type Description
SUPPLIER_NUMBER SPLNBR CHAR(5) Supplier number
SUPPLIER_NAME SPLNAM CHAR(20) Supplier name
SUPPLIER_TELEPHONE SPLTEL CHAR(15) Supplier phone number
SUPPLIER FAX SPLFAX CHAR(15) Supplier fax number
SUPPLIER ADDRESS SPLADR CHAR(20) Supplier address
SUPPLIER_CITY SPLCTY CHAR(20) Supplier city
SUPPLIER_ZIP SPLZIP CHAR(5) Suppler ZIP code
Field name Alias Type Description
PRODUCT_NUMBER PRDNBR CHAR(5) Product number
PRODUCT_DESC PRDDES CHAR(20) Product description
PRODUCT_PRICE PRDPRC DEC(7,2) Product unit price
PRODUCT_AVAIL_QTY PRDPRC DEC(5,0) Product available quantity
SUPPLIER_NUMBER SPLNBR CHAr(4) Supplier number
PRODUCT_CATEGORY PRDCAT CHAR(4) Product category
PROD_MIN_STOCK_QTY PRDQTM DED(5,0) Product minimum stock quantity
Field name Alias Type Description
PRODUCT_NUMBER PRDNBR CHAR(5) Product number
PRODUCT_PICTURE PRDPIC BLOB Product picture
Chapter 2. Using the advanced functions: An Order Entry application 17
2.4 DB2 UDB for iSeries advanced functions in the Order Entry
database
Figure 2-2 shows the Order Entry database structure and how the advanced database
functions have been implemented.
Figure 2-2 Order Entry application database structure
As stated in the overview of this chapter, the main objective of presenting this application
scenario along with this specific database design is to show how the functions provided by
DB2 UDB for iSeries can be used and how they can work together in a single application.
Let's analyze Figure 2-2 from each function standpoint.
2.4.1 Referential integrity
On both the local and the remote system, the physical files/tables previously described
represent entities tied to each other by logic and business relationships:
Relationships among the CUSTOMER, ORDERHDR, and SALESCUS tables:
We want every order to refer to an existing customer, and we want to prevent anybody
from deleting a customer that has related orders. Similarly, each sales representative must
be in charge of existing customers, so that each sales representative in the SALESCUS
file must be associated to a customer code that exists in the CUSTOMER table.
LOCAL SYSTEM
REMOTE SYSTEM
TWO PHASE COMMIT
SUPPLIER SPLNBR
PK
STOCK PRDNBR SPLNBR
PK
FK
LEGEND: PK - PRIMARY KEY
FK - FOREIGN KEY
STORED
PROCEDURE
CUSTOMER
SALESREP SRNBR CUSNBR
CUSNBR
PK
Update
Trigger
ORHNBR CUSNBR
PK
FK
Update
Trigger
Insert
Trigger
ORHNBR PRDNBR
ORDERHDR
ORDERDTL
PK
FK
18 Advanced Functions and Administration on DB2 Universal Database for iSeries
These two relationships are described in Figure 2-2, where the referential integrity
network for our database is explained.
Relationship between the ORDERHDR and ORDERDTL tables:
We require that every detail item in the Order Detail table be related to an existing header
in the Order Header table. Additionally, when an order has to be removed, we want the
detail information to be deleted as well. This business rule is translated into the arrow
linking the ORHNBR column in ORDERDTL to the same column in the ORDERHDR table.
Relationship between the STOCK and SUPPLIER tables:
At the remote side, we have a business relationship between the STOCK and SUPPLIER
tables. We need to know who provides us with each of our products, so we do not want to
keep an item in the STOCK table if its supplier is not present in the SUPPLIER table. For
the same reason, we cannot allow the deletion of a supplier as long as we have a product
provided by that supplier stored in the STOCK table. This business rule is represented by
the arrow linking the SPLNBR column in the STOCK file to the same one in the
SUPPLIER table.
We want these relationships to be enforced at any time, even when data is changed through
interfaces, such as Interactive SQL or Data File Utility (DFU). For this reason, this scenario
provides a good example of referential integrity implementation.
As described in 3.2, “Referential integrity concepts” on page 22, these relationships can
easily be translated into a proper referential integrity constraint. Once these constraints are
defined, DB2 UDB for iSeries automatically keeps our data consistent with the business rules,
regardless of the kind of interface is used to change the contents of the database. Application
programmers do not need to implement any integrity checking in their applications, which
provides benefits in terms of ease of development and maintenance.
2.4.2 Two-phase commit
The company database is distributed between a central site, where the STOCK and
SUPPLIER table are located, and several remote branch offices. The warehouse is located at
the central site and is centrally managed there.
On the other hand, the information related to the customers and orders is independently
managed at each branch office.
Consequently, our application will access both the local and the remote database. In a single
unit of work, the application updates both the STOCK table on the remote side and the
ORDERDTL table at the local side.
DRDA-2 and two-phase commit guarantee the consistency of the entire database, even after
system failures. See Chapter 5, “DRDA and two-phase commitment control” on page 83, for a
complete discussion of DRDA-2 and two-phase commit.
© Copyright IBM Corp. 1994, 1997, 2000, 2001 19
Part 2 Advanced
functions
This part describes, in detail and with practical examples, the rich set of functions that have
been implemented in DB2 UDB for iSeries. Among the most important advanced features,
you will find:
Referential integrity
Check constraints
DRDA and two-phase commit
Import and Export utilities
Part 2
20 Advanced Functions and Administration on DB2 Universal Database for iSeries
© Copyright IBM Corp. 1994, 1997, 2000, 2001 21
Chapter 3. Referential integrity
This chapter discusses:
Referential integrity concepts
Defining referential integrity relationships
Creating referential integrity constraints
Constraint enforcement
Application impacts of referential integrity
Constraint management
3
22 Advanced Functions and Administration on DB2 Universal Database for iSeries
3.1 Introduction
Referential integrity deals with relationships between data values in a relational database.
These data relationships are usually closely tied with business rules. For example, every part
order must reference a valid customer. In DB2 UDB for iSeries, once these relationships and
rules are defined to the database manager, the system automatically ensures that they are
enforced at all times, regardless of the interface used to change the data (an application, the
Data File Utility, Interactive SQL, and so on).
For example, in the Order Entry database described in 2.3, “Order Entry database overview”
on page 14, all the records in the Order file should have a customer number matching an
existing customer in the Customer file. Moreover, a customer should not be removed when it
has existing orders in the database. These are the types of data relationships that benefit
from referential integrity.
In a referential integrity environment, such relationships or business rules are defined to the
DB2 UDB for iSeries with referential constraints. DB2 UDB for iSeries supports both a native
and an SQL interface for associating constraints with your database files.
Before referential integrity was available in DB2 UDB for iSeries, application programmers
were responsible for enforcing these types of relationships in their programs. This
programming effort is no longer needed now that the referential integrity support has been
implemented in DB2 UDB for iSeries. Database management system (DBMS)-supported
referential integrity provides greater application development productivity since programmers
now have less code to write, test, and maintain. The integrity enforcement is done
automatically by DB2 UDB for iSeries.
Application integrity enforcement also had no protection against data changes made through
other interfaces, such as an interactive PC user. The constraints are now enforced in all
environments resulting in greater data integrity and consistency, leaving less room for user
error.
Referential integrity may also improve your application performance because the integrity
checks performed by DB2 UDB for iSeries are more efficient than those done in an
application program. The DBMS can use more efficient methods for enforcing these
relationships at a lower level in the system that eliminates a majority of the overhead
associated with application-level enforcement.
3.2 Referential integrity concepts
In DB2 UDB for iSeries, the following table (physical file) constraints have been introduced:
Unique constraints
Primary key constraints
Referential constraints
Check constraints
You can find a detailed definition of these constraints in Database Programming, SC41-5701,
and SQL Reference, SC41-5612. This section provides the concepts and the basic definitions
that are necessary for referential integrity. The terms table and physical file constraints refer
to the same database definitions.
Chapter 3. Referential integrity 23
Unique constraint
A unique constraint is the rule that identifies a unique key in a database file. A unique key is a
field or a set of fields in a physical file that must be unique, ascending, and can contain
null-capable fields.
Primary key constraint
A primary key constraint identifies a primary key in a database file. A primary key is a field or
a set of fields in a physical file that must be unique, ascending, and cannot contain
null-capable fields.
Parent key
A parent key is a field or a set of fields in a physical file that must be unique, ascending, and
contain null values. Both a primary and unique key can be the parent key in a referential
constraint.
Foreign key
A foreign key is a field or a set of fields in a physical file whose value, if not null, must match a
value of the parent key in the related referential constraint. The value of a foreign key is null if
at least one of the key fields is null.
Referential constraint
A referential constraint is the file attribute that causes the database to enforce referential
integrity for the defined relationship.
Referential integrity
Referential integrity is the state of a database in which the values of the foreign keys are valid.
That is, each non-null foreign key value has a matching parent key value.
Parent file
The parent file contains the parent key in a referential constraint.
Dependent file
The dependent file contains the foreign key in a referential constraint.
Referential constraint rules
The referential constraint definitions also include delete and update rules that define which
actions should be taken by the DBMS when a parent key value is updated or deleted.
Delete rule
A delete rule is applied when a row in the parent file is deleted. A record is deleted from
the parent file. Its parent key has matching foreign key values in the dependent file with:
– A CASCADE rule: The system also deletes all of the matching records in the
dependent file.
– A SET NULL rule: The system sets all null-capable fields in the matching foreign keys
to null. The foreign key fields that are not null-capable are not updated.
Note: A new function was added in V4R2M0 that allows a primary key constraint to be
defined where one or more columns in the key allow NULL values. When this condition is
detected, a check constraint is implicitly added to the file to ensure that the column will not
contain NULL values. This means that this check constraint will prevent any NULL values
from being inserted into columns defined for the primary key.
24 Advanced Functions and Administration on DB2 Universal Database for iSeries
– A SET DEFAULT rule: The system sets the matching foreign key values to their
corresponding default value. This default foreign key value must also have a matching
parent key value.
– A RESTRICT rule: If at least one dependent record exists, the system prevents the
parent key deletion. An exception is returned.
– A NO ACTION rule: This is similar to the restrict rule. However, enforcement is delayed
until the logical end of the operation. If the operation results in a violation, the system
prevents the parent key deletion and returns an exception to the user.
Update rule
An update rule is applied when a parent key is updated. An update is issued for a parent
key value that is matching some foreign keys in the dependent file with:
– A RESTRICT rule: If at least one dependent record exists, the system prevents the
parent key update. An exception is returned.
– A NO ACTION rule: This is the same as the Restrict rule. However, enforcement is
delayed until the logical end of the operation. If the operation results in a violation, the
system prevents the parent key update and returns an exception to the user.
Check constraint
Check constraint ensures that users authorized to change a column's value use only
values that are valid for that column.
Referential cycle or cyclic constraints
A set of referential constraints forms a referential cycle if any file in the chain depends on
itself. A simple example of a referential cycle is given by self-referencing constraints
(referential constraints that have a primary and foreign key in the same file). See 3.4.4,
“Self-referencing constraints” on page 34, for further discussion and an example.
Check pending
This is the state of a referential constraint when potential mismatches exist between foreign
and parent keys for a constraint relationship.
3.3 Defining a referential integrity relationship
This section describes the considerations that you should take into account when setting up a
referential integrity relationship:
Prerequisites for a referential integrity constraint
Journaling and commitment control requirements for referential integrity constraints
Referential integrity access path considerations
Verifying the current integrity of your database
3.3.1 Constraint prerequisites
You can find a full description of the prerequisites and limitations on the database files and
the constraints themselves in Database Programming, SC41-5701. The basic requirement is
that your parent key and foreign key must have matching field attributes and definitions. This
section also points out some other considerations.
Chapter 3. Referential integrity 25
When defining a referential constraint, the foreign key and parent key null attributes do not
have to exactly match. When a foreign key contains null-capable fields, DB2 UDB for iSeries
treats the entire foreign key value as null whenever any of the foreign key fields is null. This
behavior is defined in the standards as a match option of no match. Currently, this is the only
match option supported by DB2 UDB for iSeries. The null foreign key behavior is important
because referential integrity only ensures that non-null foreign keys have a matching parent
key value.
You will experience better performance when your foreign key fields and parent key fields
have identical null attributes. In fact, the non-null field attributes deliver the best performance.
Ideally, your parent and foreign key fields should be fairly stable, something similar to a
person's social security number. This is due to the fact that, to guarantee integrity, the system
must verify referential integrity each time your parent and foreign key values change.
Therefore, the less your foreign and parent keys change, the less time the DBMS spends
verifying referential integrity.
3.3.2 Journaling and commitment control requirements
When a referential constraint is defined with a delete or update rule other than RESTRICT,
the system has to perform some actions on the corresponding foreign keys each time a delete
or an update of the parent key takes place. For a delete case, for example, it deletes the
matching dependent records when the delete rule is CASCADE. The DBMS must ensure that
the parent key record and all matching dependent records are deleted. All of these record
deletions must be considered as one logical operation.
To ensure the atomicity of this operation, the system requires journaling and commitment
control in some cases. If the delete or update rule is other than RESTRICT, both the parent
and the dependent files must be journaled. In addition, the parent and dependent file must be
journaled to the same journal receiver. See 3.6, “Journaling and commitment control” on
page 43, for further discussion.
Since the restrict and no action rules cause similar rule enforcement, the restrict rule provides
better performance since journaling and commit are not required.
3.3.3 Referential integrity and access paths
DB2 UDB for iSeries uses access paths (or indexes) to perform the referential constraint
enforcement as efficiently as possible. The DBMS, however, does not require its own access
path for this enforcement. When a constraint is added to a physical file, the system first tries
to share an existing path. If one cannot be shared, a new access path is created. This sharing
is similar to the sharing performed for logical files today.
When a constraint is added to a physical file and an access path matching the constraint
criteria exists, this access path is shared, and the ownership of the access path itself is
transferred to the physical file. Similarly, if a logical file access path is shared, access path
ownership is transferred from the logical file to the physical file. If an existing access path
cannot be shared, a new one is created and owned by the physical file. The user does not
have direct access to this newly created access path.
Similarly, when a logical file or an SQL index is created on a physical file with existing
constraints, the system tries to share the constraint access paths. See Database
Programming, SC41-5701, for detailed information about access path sharing.
26 Advanced Functions and Administration on DB2 Universal Database for iSeries
If the existing access path has more than one key field, the constraint only shares that access
path if they are defined with the same key fields in the same sequence. Partial sharing is not
allowed. If the existing access path has been created over FLD1, FLD2, and FLD3, when you
create a constraint, that access path is shared only if the key of the constraint exactly
matches FLD1, FLD2, and FLD3. If, for example, the constraint is defined over just FLD1 and
FLD2, the system has to build a new access path.
When an SQL index or logical file is deleted and the associated access path is shared by a
constraint, the actual access path is left, and ownership remains with the associated physical
file. Similarly, when a file constraint is removed and the access path is being shared,
ownership is transferred back to the corresponding logical file or SQL index. If the constraint
is not sharing an access path, both the constraint and the associated access path are
removed.
Physical file constraints are not separate objects, such as logical files and SQL indexes.
Referential integrity constraints and their associated access paths are part of the file
description. In fact, when a physical file is saved, the system also saves all the constraints
and their associated access paths that have been defined for that file.
On the contrary, when you save a physical file that has related logical files, the user is
responsible for saving these logical files. For this reason, when a unique keyed access path is
required, define a unique constraint instead of a logical file or an SQL index.
Since they provide a keyed access path, physical file constraints are similar to logical files. If
you run an SQL query on a file with constraints defined over it, the query optimizer evaluates
all the access paths available: logical files, SQL indexes, and constraint access paths (see the
example in Figure 3-1).
For example, consider the ORDERDTL file in the Order Entry database. This file has a
primary key constraint defined on the ORHNBR and PRDNBR fields, and a referential
constraint with foreign key ORHNBR and parent key ORHNBR in the ORDERHDR file. We
may create an SQL index ORDDTLIDX with the key fields ORHNBR and PRDNBR:
CREATE INDEX ORDENTL/ORDDTLIDX
ON ORDENTL/ORDERDTL
(ORDER_NUMBER, PRODUCT_NUMBER)
In this case, we find the following message in the job log:
CPI3210: File ORDDTLIDX in ORDENTL shares access path.
The second-level text specifies that the logical owner of the access path is member
ORDERDTL in the ORDENTL/ORDERDTL file.
On the other hand, you may create the ORDERDTL file without a primary key constraint and
create a unique logical file over ORDER_NUMBER and PRODUCT_NUMBER. Afterwards, if
you add a referential constraint over the same fields (see 3.4, “Creating a referential
constraint” on page 28), you receive the following message:
CPI3210: File ORDERDTL in ORDENTL shares access path.
The second-level text specifies that the logical owner of the access path is member
ORDERDTL in the ORDENTL/ORDERDTL file. The system shares the existing access path
built when the logical file was created, but the ownership of the access path itself is
transferred to the physical file ORDERDTL.
If you update a record in ORDERDTL, the message shown in Figure 3-1 appears in the job
log.
Chapter 3. Referential integrity 27
Figure 3-1 SQL optimizer uses constraint access paths
The second-level text for the message (shown in bold) is shown in Figure 3-2.
Figure 3-2 Physical file constraints evaluated by the optimizer
Display All Messages
System: SYSTEM03
Job . . : P23KRZ75D User . . : ITSCID07 Number . . . : 003869
4 > DSPJOB
ODP created.
Blocking used for query.
All access paths were considered for file ORDERDTL.
Additional access path reason codes were used.
Arrival sequence access was used for file ORDERDTL.
ODP created.
ODP deleted.
1 rows updated in ORDERDTL in ORDENTL.
More...
Press Enter to continue.
F3=Exit F5=Refresh F12=Cancel F17=Top F18=Bottom
Additional Message Information
Message ID . . . . . . : CPI432C Severity . . . . . . . : 00
Message type . . . . . : Information
Date sent . . . . . . : 05/19/01 Time sent . . . . . . : 19:20:08
Message . . . . : All access paths were considered for file ORDERDTL.
Cause . . . . . : The OS/400 Query optimizer considered all access paths
built over member ORDERDTL of file ORDERDTL in library ORDENTL.
The list below shows the access paths considered. If file ORDERDTL in
library ORDENTL is a logical file then the access paths specified are actually
built over member ORDERDTL of physical file ORDERDTL in library ORDENTL.
Following each access path name in the list is a reason code which
explains why the access path was not used. A reason code of 0 indicates
that the access path was used to implement the query.
ORDENTL/ORDERDTL 4, ORDENTL/ORDDTL_HORD
The reason codes and their meanings follow:
1 - Access path was not in a valid state. The system invalidated the
access path.
2 - Access path was not in a valid state. The user requested that the
access path be rebuilt.
3 - Access path is a temporary access path (resides in library QTEMP) and
was not specified as the file to be queried.
4 - The cost to use this access path, as determined by the optimizer, was
higher than the cost associated with the chosen access method.
More...
Press Enter to continue.
F3=Exit F6=Print F9=Display message details F12=Cancel
F21=Select assistance level
28 Advanced Functions and Administration on DB2 Universal Database for iSeries
As highlighted in bold in Figure 3-2, ORDENTL/ORDERDTL is the access path shared by the
primary key and the SQL index ORDDTLIDX. ORDENTL/ORDDTL_HORD is the access path
created for the referential constraint ORDDTL_HORD.
File availability
When adding a referential constraint, the DBMS exclusively locks the file and access paths
involved. The system must then verify that every foreign key value is valid. This add and
verification process can take as little as several seconds or minutes to complete. When the
existing files contain a large number of records (hundreds of millions), this process can
possibly run for hours. The add process is much quicker when the constraint access paths are
shared instead of building them from scratch. Consider the impact on file availability before
you create a constraint during normal system activity.
Referential integrity verification queries
Before you create referential constraints over existing files, you may want to check if any
mismatches exist between your candidate parent and foreign keys. Unmatched (or orphan)
foreign key values can be determined with one of the following queries. In these queries,
DEPFILE is the dependent file with a foreign key consisting of FKEYFLD, while PARFILE and
PKEYFLD are the parent file and parent key:
SELECT * FROM mylib/DEPFILE
WHERE FKEYFLD NOT IN
(SELECT PKEYFLD FROM mylib/PARFILE)
or
OPNQRYF FILE((mylib/DEPFILE) (mylib/PARFILE))
FORMAT(MYLIB/DEPFILE)
JFLD((DEPFILE/FKEYFLD PARFILE/PKEYFLD))
JDFTVAL(*ONLYDFT)
In most cases, the queries take longer to run than the system verification process performed
during the execution of the Add Physical File Constraint (ADDPFCST) or Change Physical
File Constraint (CHGPFCST) commands. Be careful with the verification queries on large
files. This may be a good place for using DB2 UDB for iSeries Query Governor (CHGQRYA).
3.4 Creating a referential constraint
This section discusses the interfaces and commands that you can use to add a referential
constraint and create a referential integrity network. A referential integrity network is a set of
physical files linked by referential constraints. We also use the term cascade network to
indicate a referential integrity network where the constraints are linked by delete cascade
rules.
Two interfaces are available for creating physical file (or table) constraints:
The native interface that supplies the new CL command, Add Physical File Constraint
(ADDPFCST), to add a physical file constraint to a database file
The SQL interface that provides:
– CREATE TABLE statement: Has been enhanced with the CONSTRAINT clause that
allows a table constraint to be added when creating a table.
– ALTER TABLE statement: Allows a table constraint to be added to an existing table
with the ADD clause.
Chapter 3. Referential integrity 29
Either interface can be used to define a constraint over physical files or SQL tables. However,
only SQL supports a constraint definition at table creation time.
3.4.1 Primary key and unique constraints
The first step in creating a referential constraint is to identify the parent key. You can use a
unique or primary key constraint to identify the parent key.
Only one primary key constraint can be associated with a physical file. However, you can
define multiple unique constraints over the same file. When a primary key constraint is added
to a physical file, the associated access path becomes the primary access path of the file (for
example, the access path used to access the file when the OPNDBF command is issued).
If you want to define a primary key or a unique constraint over your CUSTOMER file with
customer number (CUSNBR) as the parent key, you have several options from which you can
choose.
At creation time, you can define the primary key or unique constraint on the SQL CREATE
TABLE statement:
CREATE TABLE mylib/CUSTOMER
(CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR (5) NOT NULL ,
............ other fields ........... ,
CONSTRAINT customer_key
PRIMARY KEY (CUSNBR))
Or, similarly, you can define:
CREATE TABLE mylib/CUSTOMER
(CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR (5) NOT NULL ,
............ other fields ........... ,
CONSTRAINT customer_key
UNIQUE (CUSNBR))
You can also easily add constraints to existing files. In this case, the existing records must not
contain any duplicate values for the unique or primary key fields. If the system finds duplicate
values, the constraint is not added, and an error message is returned.
With the native interface, you must issue the ADDPFCST command with the following
parameters:
ADDPFCST FILE(mylib/CUSTOMER) or ADDPFCST FILE(mylib/CUSTOMER)
TYPE(*PRIKEY) TYPE(*UNQCST)
KEY(CUSNBR) KEY(CUSNBR)
CST(customer_key) CST(customer_key)
With SQL, the equivalent action takes place with the following two ALTER TABLE statements:
ALTER TABLE mylib/CUSTOMER or ALTER TABLE mylib/CUSTOMER
ADD CONSTRAINT customer_key ADD CONSTRAINT customer_key
PRIMARY KEY (CUSNBR) UNIQUE (CUSNBR)
Note: In DB2 UDB for iSeries, the SQL interfaces allow you to specify a column-name
longer than 10 characters. If the column-name is longer than 10 characters, a
system-column name is automatically generated. The SQL constraint interface supports
both the column-name and the system-column-name. In contrast, only the
system-column-name can be specified when using the native interface for constraint
processing. See the SQL Reference, SC41-5612, for further information.
30 Advanced Functions and Administration on DB2 Universal Database for iSeries
If the physical file that was created is uniquely-keyed (with DDS), the associated access path
is the primary access path and a potential parent key. In this case, a primary key constraint
can be created over this file only when its fields match those of the file's primary access path.
A unique constraint can be defined over any set of fields in the file capable of being a unique
key.
If a physical file was not created as a unique-keyed file, a user cannot add any primary key
constraint to the file. Only unique constraints can be added.
If the parent file does not have an existing keyed access path that can be shared for the
primary key or unique constraint, the system creates one constraint.
3.4.2 Referential constraint
Now consider the Order Entry Database structure and the business rule existing between
CUSTOMER and ORDERHDR files as described in 2.4.1, “Referential integrity” on page 17.
In that scenario, note these points:
A user does not want anyone to create an order for a customer that does not exist in the
database. This means that we want to prevent anyone from inserting a new record in the
ORDERHDR file if its corresponding Customer Number (CUSNBR) is not in the
CUSTOMER file. This rule can be translated into a referential integrity constraint between
CUSTOMER (parent file) and ORDERHDR (dependent file), where CUSNBR in
CUSTOMER is the parent key and CUSNBR in ORDERHDR the foreign key.
In addition, the user wants to prevent updates or removals of a customer in the
CUSTOMER file when outstanding orders exist in the ORDERHDR file for this customer.
To ensure this data relationship, the delete and update rule should be set to RESTRICT or
NOACTION. Both the delete and update rules use RESTRICT for this particular example.
Using SQL, the constraint can be defined when we create the ORDERHDR table:
CREATE TABLE mylib/ORDERHDR
(ORDER_NUMBER FOR COLUMN ORHNBR CHAR (5) NOT NULL ,
CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR (5) NOT NULL ,
........ other fields ............. ,
CONSTRAINT orderhdr_cnbr
FOREIGN KEY (CUSNBR)
REFERENCES mylib/CUSTOMER (CUSNBR)
ON DELETE RESTRICT
ON UPDATE RESTRICT)
Otherwise, if the ORDERHDR file already exists, use a native interface:
ADDPFCST FILE(mylib/ORDERHDR)
TYPE(*REFCST)
KEY(CUSNBR)
CST(orderhdr_cnbr)
PRNFILE(mylib/CUSTOMER)
PRNKEY(CUSNBR)
DLTRULE(*RESTRICT)
UPDRULE(*RESTRICT)
Or, use the SQL interface:
ALTER TABLE mylib/ORDERHDR
ADD CONSTRAINT orderhdr_cnbr
FOREIGN KEY (CUSNBR)
REFERENCES mylib/CUSTOMER (CUSNBR)
ON DELETE RESTRICT
ON UPDATE RESTRICT
Chapter 3. Referential integrity 31
During the creation of this referential constraint, the DBMS first tries to share an existing
access path for the foreign key. If one cannot be shared, the DBMS creates an access path.
Once the foreign key access path is identified, DB2 UDB for iSeries then verifies that every
non-null foreign key value has a matching parent key.
If the system finds invalid foreign key values during the creation of the referential constraint,
the constraint is still added to the file. The DBMS also automatically disables the referential
constraint and marks the relationship as check pending. However, if invalid foreign key values
are found during constraint creation through the SQL interface, the constraint is not added to
the file.
Implicit creation of a primary key constraint
DB2 UDB for iSeries allows you, in some cases, to define a referential constraint on a
dependent file even if there is no primary or unique key constraint defined on the parent file.
In these cases, a primary key constraint with a system-generated name is implicitly added to
the parent file. A requirement for the implicit creation of the primary key constraint is that the
fields of the parent file, chosen as parent key fields, satisfy the conditions for parent keys:
unique and not null-capable. They must also exactly match the attributes of the foreign key.
Figure 3-3 shows a situation where an implicit primary key constraint is being created.
Figure 3-3 Implicit creation of a primary key constraint
In the scenario previously described, the ADDPFCST statement generates two constraints:
MYCST, which is the referential constraint for the DEPENDF file
A system-generated constraint that is a primary key constraint on the PARENTF file
This option is available only by using the ADDPFCST command. No implicit primary key is
ever created by a CREATE TABLE or ALTER TABLE specifying a FOREIGN KEY constraint.
F1 F2
DEPENDF
CREATE TABLE mycoll/dependf
(F1 char(10) NOT NULL
(F2 char(15), ........)
A B .....
PARENTF
CREATE TABLE mycoll/parentf
(A char(10) NOT NULL,
(B char(15) NOT NULL,....
ADDPFCST FILE(MYCOLL/DEPENDF
TYPE(*REFCST)
KEY(F1)
CST(MYCST)
PRNFILE(MYCOLL/PARENTF
PRNKEY(A)
DLTRULE(*RESTRICT)
UPDRULE(*RESTRICT)
.....
32 Advanced Functions and Administration on DB2 Universal Database for iSeries
Multiple constraints
You can add multiple constraints to a physical file in a single step by using the SQL CREATE
TABLE statement, for example:
CREATE TABLE mylib/ORDERHDR
(ORDER_NUMBER FOR COLUMN ORHNBR CHAR (5) NOT NULL ,
CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR (5) NOT NULL ,
........ other fields ............. ,
CONSTRAINT orderhdr_key
PRIMARY KEY (ORHNBR)
CONSTRAINT orderhdr_cnbr
FOREIGN KEY (CUSNBR)
REFERENCES mylib/CUSTOMER (CUSNBR)
ON DELETE RESTRICT
ON UPDATE RESTRICT)
This statement creates an ORDERHDR file with an ORHNBR field as the primary key and
CUSNBR as the foreign key in a referential constraint having CUSNBR in the CUSTOMER file
as a parent key and both the delete and the update rules set to RESTRICT.
3.4.3 Another example: Order Entry scenario
You now set up the referential integrity network for the Order Entry database. All the business
rules described in 2.4.1, “Referential integrity” on page 17, can be translated into physical file
constraints.
Key fields definition:
– Customer_Number (CUSNBR) must be unique in the CUSTOMER file.
– Order_Number (ORHNBR) must be unique in the ORDERHDR file.
– Order_Number plus Product_Number (ORHNBR plus PRDNBR) must be unique in the
ORDERDTL file.
– SalesRep_Number plus Customer_Number (SRNBR plus CUSNBR) must be unique
in the SALESCUS file.
– Supplier_Number (SPLNBR) must be unique in the SUPPLIER file.
– Product_Number (PRDNBR) must be unique in the STOCK file.
Each of these identifies the primary access path and can potentially be defined as a
parent key.
An order should not be inserted into the ORDERHDR file unless it references an existing
customer in the CUSTOMER file. This relationship identifies a referential constraint
between ORDERHDR and the CUSTOMER file. A customer should not be deleted or have
their customer number changed when outstanding orders for this customer exist in the
ORDERHDR file. This relationship can be enforced with the delete and update rules set to
RESTRICT.
An order detail entry should not be inserted into the ORDERDTL file without referencing a
valid order number in the ORDERHDR file. This relationship identifies a referential
constraint between the ORDERDTL and ORDERHDR files. When an order is deleted, all
of its order detail rows have to be deleted. An order number should not be updated when it
has existing detail rows in the ORDERDTL file. This leads to choosing a delete rule of
CASCADE and an update rule of RESTRICT.
A sales representative should not be inserted in the SALESCUS file until the associated
customer exists in the CUSTOMER file. This identifies a referential constraint between the
SALESCUS and CUSTOMER files. When a customer is removed, the corresponding
sales representative information should be removed. Again, the customer number cannot
Chapter 3. Referential integrity 33
be changed if it is referenced by records in the SALESCUS. Therefore, the update rule
should be RESTRICT, and the delete rule should be CASCADE.
Let's focus on the local database (the CUSTOMER, ORDERHDR, ORDERDTL, and
SALESREP files) as shown in Figure 3-4.
Figure 3-4 Order Entry referential integrity network
To define referential constraints, the parent key has to exist before creating the referential
constraint. Follow this process:
1. Create the CUSTOMER file with a primary constraint on CUSNBR:
ADDPFCST FILE(mylib/CUSTOMER) TYPE(*PRIKEY)
KEY(CUSNBR)
CST(CustKey)
2. Create the SALESCUS file with:
– A unique constraint on SRNBR, plus CUSNBR:
ADDPFCST FILE(mylib/SALECUS) TYPE(*UNQCST)
KEY((CUSNBR SRNBR))
CST(SalesCusKey)
– A referential constraint with CUSNBR as a foreign key and CUSTOMER as a parent
file:
ADDPFCST FILE(mylib/SALECUS) TYPE(*REFCST)
KEY(CUSNBR)CST(SalesCusCNbr)
PRNFILE(mylib/CUSTOMER)
PRNKEY(*PRIKEY)
DLTRULE(*CASCADE)
UPDRULE(*RESTRICT)
3. Create the ORDERHDR file with:
– A primary constraint on ORHNBR:
ADDPFCST FILE(mylib/ORDERHDR) TYPE(*PRIKEY)
KEY(ORHNBR)
CST(OrderHKey)
– A referential constraint with CUSNBR as a foreign key and CUSTOMER as a parent
file:
ADDPFCST FILE(mylib/ORDERHDR) TYPE(*REFCST)
KEY(CUSNBR) CST(OrderHdrCNbr)
ORDERDTL
delete CASCADE
update RESTRICT
CUSTOMER
SALESCUS ORDERHDR
delete CASCADE
update RESTRICT
delete CASCADE
update RESTRICT
34 Advanced Functions and Administration on DB2 Universal Database for iSeries
PRNFILE(mylib/CUSTOMER) PRNKEY(*PRIKEY)
DLTRULE(*RESTRICT) UPDRULE(*RESTRICT)
4. Create ORDERDTL file with:
A referential constraint with ORHNBR as a foreign key and ORDERHDR as a parent file:
ADDPFCST FILE(mylib/ORDERDTL) TYPE(*REFCST)
KEY(ORHNBR)CST(OrderHdrNum)
PRNFILE(mylib/ORDERHDR) PRNKEY(ORHNBR)
DLTRULE(*CASCADE) UPDRULE(*RESTRICT)
Here is an example of the SALESCUS file using the SQL Create Table interface:
CREATE TABLE ordentl/SALESCUST
(SALESREP_NUMBER FOR COLUMN SRNBR CHAR(10) NOT NULL,
CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR(5) NOT NULL,
SALES_AMOUNT FOR COLUMN SRAMT DEC(11,2) NOT NULL WITH DEFAULT,
CONSTRAINT salescus_key PRIMARY KEY (SRNBR, CUSNBR),
CONSTRAINT salescus_cnbr FOREIGN KEY (CUSNBR)
REFERENCES ordentl/CUSTOMER (CUSNBR)
ON DELETE CASCADE ON UPDATE RESTRICT)
3.4.4 Self-referencing constraints
A self-referencing constraint is a referential constraint that have a primary and foreign key in
the same physical file. You can use these constraints when you want to enforce a hierarchical
structure on your data because a self-referential constraint implements a tree-relationship
among the records of your file where the root of the tree has a null foreign key value.
When adding data to a file with a self-referential constraint, you have to follow a precise
sequence. You need to start by inserting the “root” value.
For example, in a company, the EMPLOYEE file contains all the employees;
Employee_Number (EMPNO) is the primary key of the file. On the other hand, the manager of
an employee must also be an employee and has to be the parent key of their associated
employee records in the same file.
In this case, you need to define a referential constraint with MGRID as a foreign key and
EMPNO as a parent key. EMPLOYEE is both a parent and a dependent file:
CREATE TABLE TEST/EMPLOYEE (EMPID INT NOT NULL WITH DEFAULT ,
NAME CHAR(30) NOT NULL WITH DEFAULT ,
MGRID INT ,
DEPTNO INT ,
POSITION CHAR(30) NOT NULL WITH DEFAULT ,
CONSTRAINT employee_key
PRIMARY KEY (EMPID),
CONSTRAINT employee_mgr
FOREIGN KEY (MGRID)
REFERENCES test/EMPLOYEE (EMPID)
ON DELETE SET NULL
ON UPDATE RESTRICT)
In the EMPLOYEE file example, you can only insert an employee record if the corresponding
manager has already been inserted. Therefore, the first record to insert is for the Chief
Executive Officer. This record's foreign key value is NULL. Afterwards, your insertions follow
each branch of the hierarchy down to the lowest level.
Chapter 3. Referential integrity 35
3.5 Constraints enforcement
The enforcement of referential constraints is performed during any update or deletion of
parent records and any time a dependent record is updated or deleted.
3.5.1 Locking considerations
The DBMS uses different locks on the parent and dependent rows when enforcing referential
constraints. The lock type depends on the type of enforcement being performed and the
delete and update rules.
Foreign key enforcement
The sequence for inserting a dependent row or updating a foreign key value to a non-null
value is:
A shared lock (*SHRUPD) is obtained on the dependent file and file member.
An update lock is obtained on the dependent record being inserted or updated.
A read lock is established on the matching record of the parent file, if it exists.
If a matching parent key value does not exist, a referential constraint violation is signaled
(CPF502D), and the requested operation is rolled back. All locks are released at the end of
the operation.
NOACTION and RESTRICT rule enforcement
NOACTION and RESTRICT rule enforcement do not require any data changes to the
matching dependent records. The DBMS immediately performs RESTRICT enforcement.
NOACTION enforcement is delayed until the logical end of the operation (see the example in
Figure 3-7 on page 38).
The sequence for updating or deleting a parent key value with a NOACTION or RESTRICT
rule is:
1. A shared lock (*SHRUPD) is obtained on the parent file and file member.
2. An update lock is obtained on the parent record being deleted or updated.
3. A read lock is established on the first matching record in the dependent file, if any.
If a matching foreign key value exists, a referential constraint violation is signaled (CPF503A),
and the requested operation is rolled back. All locks are released at the end of the operation.
CASCADE, SET NULL, and SET DEFAULT rules
When the delete rule is CASCADE, SET NULL, or SET DEFAULT, deleting a parent record
that has matching rows in the dependent file causes delete or update operations on the
matching dependent rows.
The sequence for deleting a parent key value with CASCADE, SET NULL, or SET DEFAULT
rules is:
A shared lock (*SHRUPD) is obtained on the parent file and file member.
An update lock is obtained on the parent record being deleted.
A shared lock (*SHRUPD) is obtained only on the dependent file member. The system
also logically opens and allocates the dependent file at this time.
All matching dependent records (if any) are allocated exclusively with an update lock, and
the corresponding update or delete operation is executed.
36 Advanced Functions and Administration on DB2 Universal Database for iSeries
These locks are released at the end of the logical operation or the next explicit user commit.
The DBMS does not logically close and de-allocate the dependent file until the parent file is
closed. Therefore, other system functions, such as CLRPFM, that need exclusive access to a
file cannot work on the dependent file until the parent file is closed.
If the system is unable to obtain the required locks, constraint enforcement cannot be
performed and the requested operation is not allowed. This may happen, for example, when
you have just deleted a parent row with a parent key value of “X” and DB2 UDB for iSeries is
trying to “cascade” that deletion to the dependent file. However, another job is actually
updating the dependent row that has a foreign key value of “X” at the same time. Therefore,
the DBMS cannot obtain the required locks for a cascade rule. The parent row delete request
is not allowed, and the following error message is returned indicating that constraint
enforcement cannot be performed:
CPF502E: Referential constraints could not be validated for member...
See 3.7.1, “Referential integrity I/O messages” on page 50, for further discussion on the new
CPF messages associated with referential integrity.
3.5.2 Referential integrity rules ordering
When a physical file is the parent file for more than one referential constraint and these
constraints have different delete rules, the DBMS sequences the rules as follows:
1. The RESTRICT rule is applied first. Therefore, if at least one of the constraints has the
delete rule RESTRICT, the deletion is prevented, and none of the dependent records are
updated or deleted.
2. CASCADE rule
3. SET NULL rule
4. SET DEFAULT rule
5. NOACTION rule
If you have a cascade network, deleting a record in the parent file causes the deletion of all
the matching records in the dependent file. If the dependent file is itself a parent file in another
referential constraint, the deletion might propagate actions to the lower level and so on. If any
failure occurs, the system rolls back all the changes.
On the other hand, when you mix different delete rules in your referential integrity network,
you can delete a parent record. This is true only if no dependent file involved is a parent in a
referential constraint that has the delete rule RESTRICT or NOACTION, or none of the
records being deleted has any dependent record. Figure 3-5 shows this situation.
Chapter 3. Referential integrity 37
Figure 3-5 Delete propagation in a referential integrity network
In the referential integrity network shown in Figure 3-5, a delete operation on PF01 causes:
A deletion of the dependent records in PF11. Each of these deletions, in turn, issues:
– Updating the related dependent records in PF21, and setting the foreign key values to
NULL.
– Deleting all of the related dependent records in the PF22 file.
By deleting the dependent records in PF12, each of these deletions, in turn, causes:
– Updating the related dependent records in PF24, and setting the foreign key values to
their default values.
– But, for the constraint existing between PF12 and PF23, the delete rule is RESTRICT.
Therefore, if the records that are about to be deleted in PF12 have dependent records
in PF23, their deletion is prevented. In turn, since it cannot delete all the records in the
PF12 file, the system prevents even the deletion of the original record in PF01.
In this example, note these points:
The delete operation from PF01 is executed.
The cascaded deletions to PF11 and PF12 are performed. As soon as the records are
deleted from PF12, the RESTRICT rule is enforced.
The system issues an error message and rolls back the previous deletions, ending the
implicit commitment control cycle.
On the contrary, if you do not have a RESTRICT or NOACTION rule when the user or an
application issues a delete on PF01, as shown in Figure 3-6, the following actions occur:
The delete from PF01 is executed.
The cascaded deletions to PF11 and PF12 are performed.
The cascaded deletions to PF22 are performed.
The SET NULL rule on PF21 is executed.
The SET DEFAULT rule on PF24 is handled.
If any failure occurs, the system rolls back all the changes.
PF01
PF21 PF22
PF11
PF23 PF24
PF12
CASCADE CASCADE
SETNULL RESTRICT CASCADE SET DEFAULT
38 Advanced Functions and Administration on DB2 Universal Database for iSeries
Figure 3-6 Delete propagation in a referential integrity network
Whether you use a RESTRICT rule or a NOACTION rule broadly depends on your application
environment needs and whether you intend to add database triggers to your database. Even
if you do not intend to define any trigger on your database, you may still want to differentiate
between RESTRICT and NOACTION, especially if the parent key in the referential integrity
relationship is subject to operations that affect multiple rows, such as an SQL UPDATE
statement.
Note: For a discussion on how DB2 UDB for iSeries sequences the referential integrity rules
and the execution of trigger programs, refer to Stored Procedures and Triggers on DB2
Universal Database for iSeries, SG24-6503.
Consider the example shown in Figure 3-7.
Figure 3-7 Impact of RESTRICT versus NOACTION
If you want to update your PRICETABLE and lower all the prices by five dollars, you may use
the following SQL statement:
UPDATE PRICETABLE SET PRICE = PRICE - 5.00
The statement runs successfully if the referential integrity rule for the constraint shown in
Figure 3-7 is NOACTION. After the first record is updated, a parent key value of $10.00 no
longer exists for the INVENTORY file. However, a NOACTION rule allows the enforcement to
be delayed until after all the rows have been updated. At this point, a parent key value of
$10.00 exists and no constraint violation is signaled.
PF01
PF21 PF22
PF11
PF24
PF12
CASCADE CASCADE
SETNULL CASCADE SET DEFAULT
Cheap 10.00
Bargain 15.00
Expensive 20.00
Outrageous 25.00
PRICELINE
Category Price
5530 15.00
4353 10.00
1233 20.00
8163 15.00
9934 20.00
ItemNo Price Description
INVENTORY
FK
PK
Chapter 3. Referential integrity 39
3.5.3 A CASCADE example
A database contains the following files:
ORDERH: Contains the Order Headers
DETAIL: Contains the items of any order
FEATURE: Contains all the features associated with the products in the DETAIL file
In this case, a record cannot be inserted in FEATURE if the related product is not in the
DETAIL file. Likewise, you cannot insert an order item in DETAIL if the related order header is
not in ORDERH.
On the other hand, when you delete an order, you should remove all the related items and all
the corresponding features from the database. For this reason, you need to define two
referential constraints:
The first one between FEATURE and DETAIL
The second one between DETAIL and ORDERH
For both constraints, the delete rule must be CASCADE. The update rule can be either
RESTRICT or NOACTION.
Now, create the tables that were previously described:
CREATE TABLE TEST/ORDERH
(ORDER_NUMBER FOR COLUMN ORHNBR CHAR (5) NOT NULL,
CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR (5) NOT NULL,
ORDER_INS_DATE FOR COLUMN ORHDTE DATE NOT NULL,
ORDER_DELIV_DATE FOR COLUMN ORHDLY DATE NOT NULL,
ORDER_TOTAL FOR COLUMN ORHTOT DEC(11,2) NOT NULL WITH DEFAULT 0,
CONSTRAINT ORDERH_KEY PRIMARY KEY (ORHNBR))
CREATE TABLE TEST/DETAIL
(ORDER_NUMBER FOR COLUMN ORHNBR CHAR (5) NOT NULL,
PRODUCT_NUMBER FOR COLUMN PRDNBR CHAR (5) NOT NULL,
PRODUCT_QUANTITY FOR COLUMN PRDQTY DEC (5, 0) NOT NULL,
PRODUCT_TOTAL FOR COLUMN PRDTOT DEC (9, 2) NOT NULL,
CONSTRAINT DETAIL_KEY PRIMARY KEY (ORHNBR, PRDNBR),
CONSTRAINT DETAIL_ORD FOREIGN KEY (ORHNBR)
REFERENCES TEST/ORDERH (ORHNBR)
ON DELETE CASCADE ON UPDATE RESTRICT)
CREATE TABLE TEST/FEATURE
(ORDER_NUMBER FOR COLUMN ORHNBR CHAR (5) NOT NULL,
PRODUCT_NUMBER FOR COLUMN PRDNBR CHAR (5) NOT NULL,
FEATURE_NUMBER FOR COLUMN FTRNBR CHAR (5) NOT NULL,
FEATURE_QUANTITY FOR COLUMN FTRQTY DEC(5,0) NOT NULL,
FEATURE_TOTAL FOR COLUMN FTRTOT DEC(9,2) NOT NULL,
CONSTRAINT FTR_KEY PRIMARY KEY (ORHNBR, PRDNBR, FTRNBR),
CONSTRAINT FTR_PRD FOREIGN KEY (ORHNBR, PRDNBR)
REFERENCES TEST/DETAIL (ORHNBR,PRDNBR)
ON DELETE CASCADE ON UPDATE RESTRICT)
If TEST is not an SQL collection, you must explicitly start journaling the files to the same
journal. The following commands create the journal and journal receiver and start journaling
for ORDERH, DETAIL, and FEATURE:
40 Advanced Functions and Administration on DB2 Universal Database for iSeries
CRTJRNRCV JRNRCV(mylib/JRNRCV)
CRTJRN JRN(mylib/JRN) JRNRCV(mylib/JRNRCV)
MNGRCV(*SYSTEM) DLTRCV(*YES)
STRJRNPF FILE(TEST/ORDERH
TEST/DETAIL
TEST/FEATURE)
JRN(mylib/JRN)
You can insert a complete order interactively or through an application according to the
following logic sequence:
1. Insert the order data into ORDERH.
2. Insert a product into DETAIL. If this item has features, insert the related features into
FEATURE.
3. Repeat this point down to the last order item.
If any error occurs during this process, issue a ROLLBACK. If all the operations end
successfully, you may COMMIT the inserts.
For example, you may insert the order data shown in Figure 3-10 on page 43.
If you try to insert a dependent record before you insert the related parent record, the system
cannot perform the insertion, and an error message is issued. In our example, the following
insert statement may be performed before you insert the corresponding order header data in
ORDERH:
INSERT INTO TEST/DETAIL VALUES ('77120', '00200', 5, 500)
In this case, the system issues the message:
CPF502D: Referential constraint violation on member DETAIL.
The second-level text explains that you cannot insert that record because it does not match
any parent key (Figure 3-8).
Chapter 3. Referential integrity 41
Figure 3-8 Inserting a foreign key that does not match any parent key value
Likewise, you may try to update a row in DETAIL having matching records in FEATURE, for
example:
UPDATE TEST/DETAIL SET PRDNBR = '99999'
WHERE PRDNBR = '00420'
In this case, the system issues the following message:
CPF503A: Referential constraint violation on member DETAIL.
The second-level text explains that you cannot update that product number because it has
depending features (Figure 3-9).
Additional Message Information
Message ID . . . . . . : CPF502D Severity . . . . . . . : 30
Message type . . . . . : Notify
Date sent . . . . . . : 06/05/01 Time sent . . . . . . : 18:11:17
Message . . . . : Referential constraint violation on member DETAIL.
Cause . . . . . : The operation being performed on member DETAIL file
DETAIL in library TEST failed. Constraint DETAIL_ORD prevents record number
0 from being inserted or updated in member DETAIL of dependent file DETAIL
in library TEST because a matching key value was not found in member ORDERH
of parent file ORDERH in library TEST. If the record number is zero, then
the error occurred on an insert operation. The constraint rule is 1. The
constraint rules are:
1 -- *RESTRICT
2 -- *NOACTION
Recovery . . . : Either specify a different file, change the file, or
change the program. Then try your request again.
More...
Press Enter to continue.
F3=Exit F6=Print F9=Display message details F12=Cancel
F21=Select assistance level
42 Advanced Functions and Administration on DB2 Universal Database for iSeries
Figure 3-9 Updating a parent key that has matching foreign keys
Figure 3-10 shows how deleting from one of the files propagates to the dependent files. For
example, the deletion of product number 00420 from DETAIL issues the deletion of three
records in FEATURE. Deleting order number 77120 causes the deletion of three records in
DETAIL. Each of these propagates the deletion to its matching records in FEATURE. With a
single statement, all the matching rows in the cascade network are deleted:
DELETE FROM TEST/ORDERH
Here, ORHNBR = '77120'.
Additional Message Information
Message ID . . . . . . : CPF503A Severity . . . . . . . : 30
Message type . . . . . : Sender copy
Date sent . . . . . . : 06/05/01 Time sent . . . . . . : 18:27:26
Message . . . . : Referential constraint violation on member DETAIL.
Cause . . . . . : The operation being performed on member DETAIL file
DETAIL in library TEST failed. Constraint FTR_PRD prevents record number 3
from being deleted or updated in member DETAIL of parent file DETAIL in
library TEST because a matching key value exists in member FEATURE of
dependent file FEATURE in library TEST. The constraint rule is 1. The
constraint rules are:
1 -- *RESTRICT
2 -- *NOACTION
Recovery . . . : Either specify a different file, change the file, or
change the program. Then try your request again.
Possible choices for replying to message . . . . . . . . . . . . . . . :
More...
Press Enter to continue.
F3=Exit F6=Print F9=Display message details F12=Cancel
F21=Select assistance level
Chapter 3. Referential integrity 43
Figure 3-10 Example of a cascade network
In a cascade network with multiple levels, DB2 UDB for iSeries implements what is called the
breadth cascade as opposed to the depth cascade implemented elsewhere. In the scenario
described in Figure 3-10, DB2 UDB for iSeries deletes the record from the Order Header file
first. Then, it deletes all the records from the DETAIL file, and then, all the records from the
FEATURE file.
3.6 Journaling and commitment control
As stated in 3.3.2, “Journaling and commitment control requirements” on page 25, if a
referential integrity network has update and delete rules other than RESTRICT, the DBMS
requires journaling and commitment control. Again, this requirement helps DB2 UDB for
iSeries ensure the atomicity of operations that change or delete multiple records due to
referential constraints. Either all or none of the record operations must complete.
For example, you may delete a record that activates a chain of cascaded deletes. If some
failure occurs during the cascade process before the DBMS can delete all the dependent
records, all the records deleted so far are undeleted and the parent and dependent files are
returned to their previous state. Journaling and commitment control enable the DBMS to
ensure this type of transaction atomicity.
Both the parent and dependent files must be journaled and journaled to the same receiver.
Technically, only the parent file needs to be journaled for NO ACTION rules. In addition, the
user is responsible for starting the journaling of their physical files.
ORHNBR CUSNBR ORHDTE ORHDTY ORHTOT
77120 00123 1994-05-31 1994-06-30 1300
ORDERH
ORHNBR PRDNBR PRDQTY PRDTOT
77120
77120
77120
00200
00420
00500
5
10
8
500
400
400
DETAIL FK
PK
ORHNBR PRDNBR FTRNBR FTRQTY FTRTOT
77120
77120
77120
77120
77120
77120
00500
00500
00420
00420
00420
00200
GK004
RF321
QQ997
QQ001
RD441
YH532
1
1
1
2
1
2
50
20
60
40
10
80
FEATURE
PK
FK
44 Advanced Functions and Administration on DB2 Universal Database for iSeries
However, the user can use system change journal management when setting up the
journaling environment to offload journal management responsibilities to the system. If
MNGRCV(*SYSTEM) and DLTRCV(*YES) are specified on the CRTJRN or CHGJRN
commands, the system automatically manages the attachment of a new journal receiver and
deletes the old receiver after the new one has been attached. Therefore, the user can choose
to start journaling and let the system take care of the management work.
In contrast, the system implicitly starts a commitment control cycle for the user if the delete or
update rule requires commitment control whenever the current application or user is running
with no commitment control.
This implicit commitment control cycle is transparent to the user and application program. If
any failure occurs before the update or delete operation has been carried out by the system,
all the changes related to the database operation are rolled back automatically. Other
changes previously made by the application are not affected by this automatic rollback.
Let's consider the example shown in Figure 3-11, where the application working on those files
is not using commitment control.
Figure 3-11 System-started commitment control cycle
When the DELETE operation is performed, DB2 UDB for iSeries activates an implicit
commitment control cycle 2. If a failure occurs in 3, the records that were removed are placed
back into the files. Any changes in 1 are not affected by an automatic rollback.
Figure 3-12 shows the same scenario as previously described, but with a native RPG ILE
program handling the delete cascade.
UPDATE ..... 1 remove 77120 from ORDERH
INSERT ..... 1 remove 00200 from DETAIL
DELETE FROM TEST/ORDERH remove 00420 from DETAIL
WHERE ORHNBR = '77120' ......
remove GK004 from FEATURE
2
remove RF321 from FEATURE
......
remove RD441 from FEATURE
remove YH532 from FEATURE
3
Automatic Rollback
Chapter 3. Referential integrity 45
Figure 3-12 A native application and a delete cascade
3.6.1 Referential integrity journal entries
A new attribute has been added to the journal entries to identify which journal entries were
created as a result of referential constraint enforcement. The term side-effect journal entries
is used in this discussion to refer to these new entries.
This side-effect information is identified by the new Ref Constraint (Yes/No) parameter in the
Display Journal Entry Details display. If a record is deleted from a dependent file directly, the
change is recorded into the journal with an entry specifying Ref Constraint is No. If the same
record is deleted by DB2 UDB for iSeries as the result of enforcing a Delete CASCADE rule,
the system records a side-effect journal entry having Ref Constraint set to Yes.
If you consider the example in Figure 3-10 on page 43, when you delete a record from
ORDERH, the system automatically removes all the related products and, for each product,
all the corresponding features. When you remove order 77120, the system logs the journal
entries shown in Figure 3-13:
DELETE FROM TEST/ORDERH
Here, ORHNBR = '77120'.
FORDERH UF A E K DISK
FAnother UF E K DISK COMMIT
...
C UPDATE AnotherFmt 1
...
C WRITE ORDERH recordstr 1
...
...
C MOVEL '77120' keyval
C keyval DELETE ORDERH 99
remove 77120 from ORDERH
remove 00200 from DETAIL
remove 00420 from DETAIL
......
2 remove GK004 from FEATURE 3
remove RF321 from FEATURE
......
remove RD441 from FEATURE
remove YH532 from FEATURE
...
46 Advanced Functions and Administration on DB2 Universal Database for iSeries
Figure 3-13 Journal entries after deleting a parent record
Referring to Figure 3-13, OP means Open Member, CL is Close Member, and DL means
Delete Record. The BC entry corresponds to a Start Commitment Control operation, and the
SC entry is a Start of Commit cycle (the delete action was performed with Commitment
Control level *CHG).
After the parent file is opened and the commitment control cycle is started, an application first
deletes the parent record (Entry# - 2309). The DBMS then gains control and enforces the
associated delete CASCADE rules, causing all the matching rows in the dependent file (all
the products) and eventually all the features related to the products to be deleted. Side-effect
journal entries (2311 through 2320) are logged as a result of the constraint enforcement
performed by DB2 UDB for iSeries.
If you use option 5 on the DL entry for the ORDERH file, the complete entry for the explicit
parent key delete is shown in Figure 3-14.
Display Journal Entries
Journal . . . . . . : QSQJRN Library . . . . . . : TEST
Type options, press Enter.
5=Display entire entry
Opt Sequence Code Type Object Library Job Time
2304 F OP ORDERH TEST P23KRZ75D 22:37:02
2305 C BC P23KRZ75D 22:37:03
2306 C SC P23KRZ75D 22:37:03
2309 R DL ORDERH TEST P23KRZ75D 22:37:03
2311 R DL DETAIL TEST P23KRZ75D 22:37:04
2312 R DL DETAIL TEST P23KRZ75D 22:37:04
2313 R DL DETAIL TEST P23KRZ75D 22:37:04
2315 R DL FEATURE TEST P23KRZ75D 22:37:05
2316 R DL FEATURE TEST P23KRZ75D 22:37:05
2317 R DL FEATURE TEST P23KRZ75D 22:37:05
2318 R DL FEATURE TEST P23KRZ75D 22:37:05
2319 R DL FEATURE TEST P23KRZ75D 22:37:05
2320 R DL FEATURE TEST P23KRZ75D 22:37:05
2322 F CL ORDERH TEST P23KRZ75D 22:37:05
2323 C EC P23KRZ75D 22:37:06
Note: Until the parent file is closed (entry 2322) in this delete cascade operation, you
cannot run the Change Journal (CHGJRN) command on this journal. This is due to the fact
that the system requires all of the files involved in this logical transaction to be closed so
that a synchronization point can be established for this journal. After this synchronization
point is established, the system de-allocates the journal, making it available to any system
function.
Chapter 3. Referential integrity 47
Figure 3-14 Journal entry information for a delete cascade operation
The corresponding entry details are shown in Figure 3-15.
Figure 3-15 Application-related journal entry
As shown in bold in Figure 3-15, the system reports that this delete operation was not the
result of referential constraint enforcement.
Display Journal Entry
Object . . . . . . . : ORDERH Library . . . . . . : TEST
Member . . . . . . . : ORDERH Sequence . . . . . . : 2309
Code . . . . . . . . : R - Operation on specific record
Type . . . . . . . . : DL - Record deleted
Entry specific data
Column *...+....1....+....2....+....3....+....4....+....5
00001 '77120001232001-05-312001-06-30 '
Bottom
Press Enter to continue.
F3=Exit F6=Display only entry specific data
F10=Display only entry details F12=Cancel F24=More keys
Display Journal Entry Details
Journal . . . . . . : QSQJRN Library . . . . . . : TEST
Sequence . . . . . . : 2309
Code . . . . . . . . : R - Operation on specific record
Type . . . . . . . . : DL - Record deleted
Object . . . . . . . : ORDERT Library . . . . . . : TEST
Member . . . . . . . : ORDERT Flag . . . . . . . . : 1
Date . . . . . . . . : 06/07/01 Time . . . . . . . . : 22:37:03
Count/RRN . . . . . : 2 Program . . . . . . : QCMD
Job . . . . . . . . : 005547/ITSCID07/P23KRZ75D
User profile . . . . : USERID07 Ref Constraint . . . : No
Commit cycle ID . . : 2306 Trigger . . . . . . : No
Press Enter to continue.
F3=Exit F10=Display entry F12=Cancel F14=Display previous entry
F15=Display only entry specific data
48 Advanced Functions and Administration on DB2 Universal Database for iSeries
In contrast, the side-effect entry details all specify Ref Constraint as yes. For example, the
complete entry 2311 is shown in Figure 3-16.
Figure 3-16 Journal entry information for a dependent record
This deletes product 00420. The corresponding detailed information is shown in Figure 3-17.
Figure 3-17 Journal entry details for a referential integrity side-effect journal entry
Display Journal Entry
Object . . . . . . . : DETAIL Library . . . . . . : TEST
Member . . . . . . . : DETAIL Sequence . . . . . . : 2311
Code . . . . . . . . : R - Operation on specific record
Type . . . . . . . . : DL - Record deleted
Entry specific data
Column *...+....1....+....2....+....3....+....4....+....5
00001 '7712000420 '
Bottom
Press Enter to continue.
F3=Exit F6=Display only entry specific data
F10=Display only entry details F12=Cancel F24=More keys
Display Journal Entry Details
Journal . . . . . . : QSQJRN Library . . . . . . : TEST
Sequence . . . . . . : 2311
Code . . . . . . . . : R - Operation on specific record
Type . . . . . . . . : DL - Record deleted
Object . . . . . . . : DETAIL Library . . . . . . : TEST
Member . . . . . . . : DETAIL Flag . . . . . . . . : 1
Date . . . . . . . . : 06/07/01 Time . . . . . . . . : 22:37:04
Count/RRN . . . . . : 3 Program . . . . . . : QCMD
Job . . . . . . . . : 005547/ITSCID07/P23KRZ75D
User profile . . . . : USERID07 Ref Constraint . . . : Yes
Commit cycle ID . . : 2306 Trigger . . . . . . : No
Press Enter to continue.
F3=Exit F10=Display entry F12=Cancel F14=Display previous entry
F15=Display only entry specific data
Chapter 3. Referential integrity 49
Notice that the field marked in bold in Figure 3-17 means that this delete operation was
performed by the DBMS due to referential constraint enforcement.
3.6.2 Applying journal changes and referential integrity
When you apply or remove journal changes, DB2 UDB for iSeries does not allow referential
constraints to prevent the recovery of your database files. Although each apply or remove
change is allowed, the associated referential constraints are constantly verified to prevent you
from violating the referential integrity of your database. If the journal change violates
referential integrity, the constraint is marked as check pending, and the system continues on
to the next journal entry. See the check pending discussion in 3.8.1, “Constraint states” on
page 52.
Moreover, during the process of applying or removing journal changes, update and delete
rules are ignored. If you have a cascade delete rule, for example, removing a record from the
parent file does not remove any of the dependent records. This is because the dependent
record changes are also recorded in your journal with the side-effect journal entries discussed
in 3.6.1, “Referential integrity journal entries” on page 45. These entries can be applied as
well.
This design allows you to use the journal entries to recover your database files to a known
state without violating the integrity of your database.
To avoid check pending situations, you must apply or remove journal changes on all files in
your referential integrity network to ensure that your related parent and dependent files are
recovered to the same data level.
Consider the example in Figure 3-10 on page 43. If you experience a data loss, you may need
to restore all the files in the referential integrity network. When you apply the journal changes,
include all the files involved in the referential integrity network:
APYJRNCHG JRN(TEST/QSQJRN)
FILE((*ALL))
CMTBDY(*YES)
This way, you are protected from check pending conditions and from data inconsistencies.
On the other hand, if you apply the journal entries only to ORDERH, order 77120 is deleted,
but all the related products are still in the database. The system allows you to apply the
journal changes with the following command:
APYJRNCHG JRN(TEST/QSQJRN)
FILE((TEST/ORDERH))
CMTBDY(*YES)
The DETAIL_ORD constraint (between ORDERH and DETAIL) is found in the established or
enabled state, with a check pending status of YES. To bring the two files back to the same
data level, you may also apply the journal changes to the other files in the network. Consider
our example, DETAIL and FEATURE:
APYJRNCHG JRN(TEST/QSQJRN)
FILE((TEST/DETAIL) (TEST/FEATURE))
CMTBDY(*YES)
At this point, you have to re-enable the constraints so that the system can re-verify this
relationship.
50 Advanced Functions and Administration on DB2 Universal Database for iSeries
Figure 3-18 summarizes the database changes that can cause a check pending condition
(marked with CP) when they are applied through an Apply Journal Changes (APYJRNCHG)
command only to a parent or only to a dependent file and, similarly, when they are removed
from some, but not all, of the network files.
Figure 3-18 Check pending after APYJRNCHG
Always apply or remove journal entries within commit boundaries, starting from the beginning
of a logical unit of work down to the end of a logical unit of work, because the system
guarantees the data consistency within the commit boundaries. Therefore, when you apply
journal changes, set the CMTBDY value to *YES in the APYJRNCHG command.
3.7 Referential integrity application impact
Before referential integrity is implemented, referential integrity validations must be performed
by the application program. Now you can let DB2 UDB for iSeries ensure your data integrity
through the referential integrity constraints.
As mentioned earlier, using referential integrity may improve your application performance.
The integrity checks are much more efficient and quicker when performed at the operating
system level rather than by an application.
However, once a programmer has defined referential constraints to the DBMS, the existing
integrity checks should be removed from the application program. Otherwise, the application
performance will degrade because the same checking is being performed twice (at the
application level and at the system level).
The application programmer must also consider the fact that, once the referential integrity
constraints are defined to the DBMS, referential integrity enforcement is performed at all
times on all interfaces. If you have applications that only need the data to be consistent at
specific points in time or applications where the inconsistency is accepted because another
program will correct it, DBMS referential constraints may prevent these applications from
running smoothly. A programmer must verify that the DBMS-supported referential integrity
matches the integrity and business rules currently enforced by their applications.
3.7.1 Referential integrity I/O messages
Several new error messages have been defined to handle the errors occurring during
referential integrity enforcement. Instead of coding integrity checks into your application
programs, coding is now needed to handle the new referential integrity error conditions that
can be raised by DB2 UDB for iSeries during referential constraint enforcement.
APY RMV
Insert CP - -
Update CP CP
Delete - - CP
On dependent files
APY RMV
Insert - - CP
Update CP CP
Delete CP - -
On parent files
Chapter 3. Referential integrity 51
Notify messages
There are three new notify messages for referential integrity errors:
CPF502D: Referential constraint violation member
ibm.com/redbooks
IBM AS/400
Printing V
Alain Badan
Simon Hodkin
Jacques Hofstetter
Gerhard Kutschera
Bill Shaffer
Whit Smith
A primer on AS/400 printing in today’s
networked environment
Configuration, performance, problem
determination, enhancements
In-depth education on AFP
and ASCII printing
International Technical Support Organization SG24-2160-01
IBM AS/400 Printing V
October 2000
© Copyright International Business Machines Corporation 1998, 2000. 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.
Second Edition (October 2000)
The document was created or updated on June 12, 2001.
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.
Before using this information and the product it supports, be sure to read the general information in Appendix L,
“Special notices” on page 407.
Take Note!
© Copyright IBM Corp. 2000 iii
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Chapter 1. Printing on the AS/400 system. . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.1 Output queues: Spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.2 Data streams supported on the AS/400 system. . . . . . . . . . . . . . . . . . . . . .3
1.3 Printer writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.3.1 Print writer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
1.3.2 Print Services Facility/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.3.3 Host print transform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
1.3.4 Image print transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
1.4 AS/400 printer attachment methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
1.4.1 Printers attached to AS/400 workstation controllers or IBM 5x94. . . .15
1.4.2 IPDS printers LAN-attached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
1.4.3 ASCII printers attached to displays . . . . . . . . . . . . . . . . . . . . . . . . . .17
1.4.4 ASCII printers attached to PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
1.4.5 ASCII printers LAN-attached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
1.4.6 Printers attached to PSF Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
1.4.7 Printers attached to PSF/2 DPF . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
1.5 Remote system printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
1.6 Printing SCS, IPDS, AFPDS, and USERASCII spooled files . . . . . . . . . . .23
1.6.1 SCS spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
1.6.2 IPDS spooled files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
1.6.3 AFPDS spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
1.6.4 USERASCII spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
1.6.5 USERASCII spooled files with image print transform. . . . . . . . . . . . .26
1.7 Implementing a printing concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
1.7.1 Print criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
1.7.2 Print output requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
1.7.3 Printer file device type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
1.7.4 Writer supporting printer file device type . . . . . . . . . . . . . . . . . . . . . .28
1.7.5 Printer requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
1.7.6 Types of printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
1.7.7 Printer attachment methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
1.7.8 What must be considered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Chapter 2. Advanced Function Presentation. . . . . . . . . . . . . . . . . . . . . . . .35
2.1 Overview of AFP on the AS/400 system . . . . . . . . . . . . . . . . . . . . . . . . . .35
2.1.1 What AFP is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
2.1.2 AS/400 AFP model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
2.1.3 APU print model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
2.1.4 PFU print model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
2.1.5 Page and form definitions print model . . . . . . . . . . . . . . . . . . . . . . . .41
2.1.6 AFP toolbox print model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
2.2 AFP resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
2.2.1 Creating AFP resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
2.2.2 OEM products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
2.3 AFP Utilities/400 V4R2 enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . .45
2.3.1 View electronic form on PC (Overlay Utility) . . . . . . . . . . . . . . . . . . .45
2.3.2 Print Format Utility ‘Omit Back Side Page Layout’ . . . . . . . . . . . . . . .47
iv IBM AS/400 Printing V
2.3.3 Element repeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.4 Form definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.5 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.6 Printer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.7 Host outline font support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4 Advanced Print Utility (APU) enhancements . . . . . . . . . . . . . . . . . . . . . . 49
2.4.1 Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.2 Multiple Text Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.3 Outline font support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.4 Advanced Print Utility (APU) monitor enhancement . . . . . . . . . . . . . 52
2.4.5 Print engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 3. Enhancing your output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.1 How your print output could look . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.2 Using Advanced Print Utility (APU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.1 APU environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.2 Setting up APU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.3 Creating the print definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.4 Working with the print definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.5 Testing the print definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.6 Printing using the APU monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.3 Using the Page Printer Formatting Aid. . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.1 Creating a source physical file for form and page definitions . . . . . . 82
3.3.2 Compiling the form and page definitions . . . . . . . . . . . . . . . . . . . . . 84
3.3.3 Printing with the form and page definitions. . . . . . . . . . . . . . . . . . . . 86
3.3.4 Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4 APU versus PPFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chapter 4. Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1 Where fonts are stored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.1 Printer-resident fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.2 Host-resident fonts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2 How fonts are selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.1 Characters per inch (CPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Which fonts are available. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.1 Fonts supplied at no charge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.2 240-pel fonts available at a charge . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3.3 300-pel fonts available at a charge . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.4 How fonts are installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.1 Making the fonts available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.5 Outline fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5.1 Downloading host-resident outline fonts. . . . . . . . . . . . . . . . . . . . . 100
4.5.2 Why use an outline font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.5.3 Scalable fonts for MULTIUP and COR . . . . . . . . . . . . . . . . . . . . . . 101
4.6 Font substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6.1 Suppressing font substitution messages . . . . . . . . . . . . . . . . . . . . 102
4.7 Font table customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.7.1 Creating the font tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.7.2 Adding a font table entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.7.3 Other font table commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.7.4 Customer-defined font ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.8 Disabling resident font support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.9 Using a resource library list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
v
4.10 Font capturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
4.10.1 Font resources eligible for capture . . . . . . . . . . . . . . . . . . . . . . . .108
4.10.2 Marking a font resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
4.10.3 Defining the printer for font capture . . . . . . . . . . . . . . . . . . . . . . . .110
4.10.4 Considerations for font capture . . . . . . . . . . . . . . . . . . . . . . . . . . .110
4.11 Creating AFP fonts with Type Transformer . . . . . . . . . . . . . . . . . . . . . .110
Chapter 5. The IBM AFP Printer Driver . . . . . . . . . . . . . . . . . . . . . . . . . . .117
5.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
5.1.1 Why use the AFP Printer Driver. . . . . . . . . . . . . . . . . . . . . . . . . . . .117
5.2 Installing the AFP Printer Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
5.2.1 Installation from the World Wide Web . . . . . . . . . . . . . . . . . . . . . . .121
5.3 Creating an overlay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
5.4 Creating a page segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
5.5 Text versus image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
5.6 Other AFP Printer Driver tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
5.6.1 Using the Images dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
5.6.2 File transfer of AFP resources using FTP . . . . . . . . . . . . . . . . . . . .130
5.6.3 Problem solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
5.6.4 Performance of the AFP Printer Driver . . . . . . . . . . . . . . . . . . . . . .134
5.6.5 Creating AFP documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Chapter 6. Host print transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
6.1 Host print transform overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
6.2 Host print transform enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
6.3 Host print transform process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
6.4 Enabling host print transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
6.5 SCS to ASCII transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
6.6 AFPDS to ASCII transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
6.6.1 Mapping mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
6.6.2 Raster mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
6.6.3 Processing AFP resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
6.6.4 Processing AFPDS barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
6.6.5 How AFPDS to ASCII transform handles a no-print border . . . . . . .149
6.6.6 AFPDS to TIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
6.6.7 Transform spooled file and write to folder . . . . . . . . . . . . . . . . . . . .150
6.6.8 AFPDS to ASCII transform limitations . . . . . . . . . . . . . . . . . . . . . . .150
6.7 Host print transform customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
6.8 New and enhanced tags for WSCST objects. . . . . . . . . . . . . . . . . . . . . .152
6.9 New MFRTYPMDL special values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
6.10 DBCS support in host print transform . . . . . . . . . . . . . . . . . . . . . . . . . .156
6.10.1 DBCS SCS to ASCII transform . . . . . . . . . . . . . . . . . . . . . . . . . . .156
6.10.2 DBCS AFPDS to ASCII transform . . . . . . . . . . . . . . . . . . . . . . . . .157
6.10.3 New tags and supported data streams for DBCS. . . . . . . . . . . . . .157
Chapter 7. Image print transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
7.1 Image print transform function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
7.2 Why use image print transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
7.3 Image print transform process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
7.3.1 Where output attributes are derived . . . . . . . . . . . . . . . . . . . . . . . .165
7.4 Printing with the image print transform function. . . . . . . . . . . . . . . . . . . .165
7.4.1 Printing to an ASCII printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
7.4.2 Printing to an IPDS printer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
7.4.3 Sending the spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
vi IBM AS/400 Printing V
7.5 Image configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.5.1 Values of image configuration objects . . . . . . . . . . . . . . . . . . . . . . 166
7.6 Printing with the convert image API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.7 Converting PostScript data streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.7.1 Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.7.2 User-supplied fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.7.3 Font substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.8 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Chapter 8. Remote system printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.1 Remote system printing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.2 AS/400 system and TCP/IP LPR-LPD printing . . . . . . . . . . . . . . . . . . . . 172
8.2.1 Creating the output queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
8.2.2 Destination options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.2.3 Separator pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.2.4 ‘Load Letter’ message on the printer . . . . . . . . . . . . . . . . . . . . . . . 179
8.3 AS/400 and NetWare printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.3.1 Preparing for remote system printing . . . . . . . . . . . . . . . . . . . . . . . 182
8.3.2 Creating an output queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Chapter 9. Client Access/400 printing . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.1 Client Access/400 printing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.2 Client Access/400 Network Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
9.2.1 Configuring an AS/400 printer to Windows 95 . . . . . . . . . . . . . . . . 186
9.2.2 Network printer setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.2.3 AS/400 print profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.2.4 Considerations on Client Access/400 Network Printing . . . . . . . . . 193
9.3 Printing AS/400 output on a PC printer . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.3.1 Configuring a printer emulation session . . . . . . . . . . . . . . . . . . . . . 194
9.3.2 Modifying and using a printer definition table (PDT) . . . . . . . . . . . . 200
Chapter 10. IBM AS/400 network printers . . . . . . . . . . . . . . . . . . . . . . . . 205
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
10.2 Configuration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
10.2.1 Example 1: LAN-attached IPDS printer . . . . . . . . . . . . . . . . . . . . 206
10.2.2 Example 2: Dual-configuration printer . . . . . . . . . . . . . . . . . . . . . 207
10.2.3 Example 3: Shared dual-configuration printer . . . . . . . . . . . . . . . 207
10.2.4 Example 4: Shared multi-purpose printer . . . . . . . . . . . . . . . . . . . 208
10.3 Printer setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.3.1 Printer menu details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.3.2 Recommended PTF levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
10.3.3 Microcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
10.3.4 Tray and bin selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
10.4 Attachment information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.4.1 Network Printer Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.5 Output presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.5.1 IPDS, AFP=*YES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.5.2 IPDS, AFP=*NO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.5.3 SCS mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
10.5.4 Using the QPRTVALS data area . . . . . . . . . . . . . . . . . . . . . . . . . 217
10.5.5 Using the IPDS menu PAGE setting. . . . . . . . . . . . . . . . . . . . . . . 218
10.5.6 Edge-to-edge printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
vii
Chapter 11. Configuring LAN-attached printers . . . . . . . . . . . . . . . . . . . .223
11.1 Configuring LAN-attached IPDS printers . . . . . . . . . . . . . . . . . . . . . . . .223
11.1.1 Configuring LAN-attached IPDS printers on V3R2. . . . . . . . . . . . .224
11.1.2 Configuring LAN-attached IPDS printers on V3R7 and later . . . . .230
11.1.3 TCP/IP BOOT service for V4R1 and later . . . . . . . . . . . . . . . . . . .237
11.2 Configuring LAN-attached ASCII printers . . . . . . . . . . . . . . . . . . . . . . .238
11.2.1 Configuring LAN-attached ASCII printers using LexLink . . . . . . . .238
11.2.2 Configuring LAN-attached ASCII printers using PJL drivers. . . . . .241
11.2.3 Configuring LAN-attached ASCII printers using SNMP drivers. . . .246
Chapter 12. Problem determination techniques . . . . . . . . . . . . . . . . . . . .253
12.1 Communication, connection, and configuration problems . . . . . . . . . . .253
12.1.1 Setting up a TCP/IP network on the AS/400 system . . . . . . . . . . .253
12.1.2 SSAP values in the line description . . . . . . . . . . . . . . . . . . . . . . . .253
12.1.3 Pinging the TCP/IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
12.1.4 Port number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
12.1.5 Print Job Language (PJL) support . . . . . . . . . . . . . . . . . . . . . . . . .255
12.1.6 Message PQT3603 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
12.1.7 Configuring LAN-attached IPDS printers . . . . . . . . . . . . . . . . . . . .257
12.1.8 Configuring for remote system printing . . . . . . . . . . . . . . . . . . . . .258
12.1.9 Remote printer queue names . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
12.2 Printer-writer-related problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
12.2.1 Print writer ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
12.2.2 Spooled files remain in RDY status . . . . . . . . . . . . . . . . . . . . . . . .260
12.2.3 Spooled file remains in PND status . . . . . . . . . . . . . . . . . . . . . . . .261
12.2.4 Ending the writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
12.2.5 Spooled file status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
12.2.6 Output queue status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
12.2.7 AFCCU printers: Minimize delay when stopping and starting. . . . .264
12.2.8 QSTRUP execution during IPL . . . . . . . . . . . . . . . . . . . . . . . . . . .264
12.3 Where your print output goes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
12.4 Spooled file goes to hold status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
12.4.1 Writer cannot re-direct the spooled file . . . . . . . . . . . . . . . . . . . . .267
12.4.2 Message PQT3630 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
12.4.3 Fidelity parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
12.5 Copying spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
12.6 Problem with output presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
12.6.1 Physical page: Logical page . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
12.6.2 Printer setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
12.6.3 Computer Output Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
12.6.4 A3 page support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
12.7 Font problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
12.7.1 Problems with shading at different resolutions. . . . . . . . . . . . . . . .276
12.8 Drawer and paper path selection problems . . . . . . . . . . . . . . . . . . . . . .276
12.8.1 IBM 4247 paper path selection . . . . . . . . . . . . . . . . . . . . . . . . . . .276
12.9 Printing on ASCII printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
12.10 Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Appendix A. PSF/400 performance factors . . . . . . . . . . . . . . . . . . . . . . . . . 279
A.1 AS/400 system storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
A.2 Data stream type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
A.2.1 IPDS pass through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
A.2.2 Printer device description parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 282
viii IBM AS/400 Printing V
A.3 AFP resource retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
A.3.1 Clear memory for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
A.4 Font types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
A.4.1 Using GDDM fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
A.5 Library list searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
A.6 Creating efficient AFP resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
A.7 Other factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
A.7.1 PSF configuration object parameters. . . . . . . . . . . . . . . . . . . . . . . . . . .285
A.7.2 Printer file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
A.7.3 Printer settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
Appendix B. Data Description Specifications (DDS) formatting . . . . . . . .287
B.1 DDS functionality example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
B.2 Super Sun Seeds invoicing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Appendix C. Print openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
C.1 Additional functions provided on the printer file . . . . . . . . . . . . . . . . . . . . . . .304
C.2 Additional functions provided on the PRTDEVD commands . . . . . . . . . . . . .304
C.3 Additional functions provided on the output queue commands . . . . . . . . . . .305
C.4 Additional functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
C.5 Print openness: New APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Appendix D. Network Station printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
D.1 Printing from OS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
D.1.1 AS/400 Network Station printer driver . . . . . . . . . . . . . . . . . . . . . . . . . .309
D.1.2 Creating printer device descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . .309
D.2 Local printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
D.2.1 5250 screen copy to a local printer . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
D.2.2 Printing from Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
Appendix E. Printer summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313
Appendix F. PSF/400 performance results . . . . . . . . . . . . . . . . . . . . . . . . . .317
F.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
F.1.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
F.1.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
F.2 Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
F.3 Performance cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
F.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
F.4.1 PSF/400 V4R2 with Network Printer 24 . . . . . . . . . . . . . . . . . . . . . . . . .322
F.4.2 PSF/400 V4R2 with IP60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
F.4.3 PSF/400 V4R2 with IP4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
F.4.4 Comparison: Printing rates using PSF/400 V4R2 on Model 510/2144 .326
F.4.5 Comparison of processor requirements . . . . . . . . . . . . . . . . . . . . . . . . .328
F.4.6 Predictions of processor utilizations at printing speeds . . . . . . . . . . . . .329
F.4.7 Print While Convert (PWC)=Yes compared to PWC=NO . . . . . . . . . . .331
F.5 Application of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
F.6 Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Appendix G. Advanced Print Utility implementation case study. . . . . . . .343
G.1 Ordering printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
G.1.1 Low-end printer: IBM Network Printer 12 . . . . . . . . . . . . . . . . . . . . . . .343
G.1.2 Departmental printer: IBM Infoprint 21 . . . . . . . . . . . . . . . . . . . . . . . . .343
G.1.3 AS/400 production printer and PC LAN departmental printer . . . . . . . .344
ix
G.2 Ordering and obtaining software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
G.2.1 Checking whether the software is already installed . . . . . . . . . . . . . . . 345
G.3 Installing the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
G.3.1 PSF/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
G.3.2 AFP Utilities/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
G.3.3 AFP Font Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
G.3.4 Advanced Print Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
G.3.5 Additional steps that may be required . . . . . . . . . . . . . . . . . . . . . . . . . 350
G.4 Designing electronic documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
G.4.1 Which fonts to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
G.5 Creating the resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
G.6 Building and testing APU print definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . 354
G.6.1 Other common problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
G.6.2 Viewing APU output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
G.7 Automatically starting the APU Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
G.7.1 Creating a separate APU subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 358
G.7.2 Modifying QBATCH to allow multiple jobs to run . . . . . . . . . . . . . . . . . 360
G.8 Using APU for production printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
G.8.1 Using APU Monitor Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
G.9 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
G.9.1 Documenting APU component names . . . . . . . . . . . . . . . . . . . . . . . . . 365
G.9.2 Where APU print components are stored. . . . . . . . . . . . . . . . . . . . . . . 366
Appendix H. AS/400 to AIX printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
H.1 TCP/IP versus SNA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
H.1.1 Sending spooled files using TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
H.1.2 PSF Direct. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
H.2 AS/400 spooled file data streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
H.2.1 *SCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
H.2.2 OV/400 and Final Form Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
H.2.3 *AFPDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
H.2.4 *IPDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
H.2.5 *LINE or *AFPDSLINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
H.2.6 *USERASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
H.3 Automating the process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
H.3.1 Default Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
H.3.2 Destination options in the remote output queue . . . . . . . . . . . . . . . . . . 377
H.3.3 Output queue monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
H.4 Special considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
H.4.1 Processing line AS/400 SCS files as ‘flat ASCII’ . . . . . . . . . . . . . . . . . 378
H.4.2 Sample page and form definition for STD132. . . . . . . . . . . . . . . . . . . . 379
H.4.3 Parmdd file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
H.4.4 Destination Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
H.4.5 Output from the AS/400 query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
H.4.6 Transferring resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
H.4.7 Large spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
H.5 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
H.5.1 One printer, all AFPDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
H.5.2 One printer, four document types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
H.5.3 70 printers, 12 applications, SCS spooled files. . . . . . . . . . . . . . . . . . . 384
H.5.4 Multiple printers, many data streams . . . . . . . . . . . . . . . . . . . . . . . . . . 384
H.6 Sending AS/400 spooled files to OnDemand for UNIX. . . . . . . . . . . . . . . . . 385
H.6.1 AS/400 side tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
x IBM AS/400 Printing V
H.6.2 AIX side tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385
H.7 AS/400 printing to an Infoprint Manager for Windows NT or 2000 server . . .385
H.7.1 Hypothetical case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386
H.8 Additional references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387
Appendix I. Infoprint 2000 printing considerations . . . . . . . . . . . . . . . . . . .389
I.1 Print file considerations and HPT formatting . . . . . . . . . . . . . . . . . . . . . . . . . .389
I.2 Infoprint Manager and other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
I.2.1 Another application solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .392
I.2.2 Operator considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393
Appendix J. Printing enhancements in recent OS/400 releases . . . . . . . .395
J.1 Version 4 Release 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
J.1.1 SNMP ASCII printer driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
J.1.2 SNMP driver for Infoprint 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
J.1.3 PSF/400 printer ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
J.1.4 AFP Font Collection bundled with PSF/400 . . . . . . . . . . . . . . . . . . . . . .396
J.1.5 Type Transformer for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
J.1.6 AFP/IPDS support for OneWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
J.2 Version 4 Release 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
J.2.1 Simplex/duplex mode switching DDS. . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.2 Force new sheet DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.3 Output bin DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.4 Insert DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.5 Z-fold DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.6 Overlay rotation DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.7 Constant back overlay in the printer file . . . . . . . . . . . . . . . . . . . . . . . . .397
J.2.8 Print finishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
J.2.9 AS/400 font management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
J.2.10 Advanced Function Printing Utilities (AFPU) enhancements . . . . . . . .398
J.2.11 Content Manager OnDemand for AS/400 . . . . . . . . . . . . . . . . . . . . . .398
J.3 OS/400 Version 4 Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
J.3.1 Integration of AFP Workbench into Client Access/400. . . . . . . . . . . . . .399
J.3.2 Indexing keyword in DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
J.3.3 Support for line data enhanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
J.3.4 Automatic resolution enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
J.3.5 Font performance improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
J.3.6 Sizing and rotating page segments . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
J.3.7 Enhanced PostScript transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
J.3.8 IPDS pass through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
J.3.9 AFP Font Collection with Euro, expanded languages . . . . . . . . . . . . . .400
J.3.10 AFP PrintSuite for AS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401
J.4 OS/400 Version 4 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401
J.4.1 OS/400 Image Print Transform Services . . . . . . . . . . . . . . . . . . . . . . . .401
J.4.2 Support for outline fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402
J.4.3 Font capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402
J.4.4 Cut-sheet emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402
J.4.5 Finishing support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403
J.4.6 TCP/IP configuration enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . .403
J.4.7 Font substition messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403
J.4.8 AFP Utilities for V4R2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403
Appendix K. Using the additional material . . . . . . . . . . . . . . . . . . . . . . . . . .405
K.1 Locating the additional material on the Internet . . . . . . . . . . . . . . . . . . . . . . .405
xi
K.2 Using the Web material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
K.2.1 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Appendix L. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Appendix M. Related publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
M.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
M.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
M.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
M.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .415
IBM Redbooks fax order form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417
IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
xii IBM AS/400 Printing V
© Copyright IBM Corp. 2000 xiii
Preface
This IBM Redbook describes how to use printing functions on the AS/400 system.
It supplements the standard reference documents on AS/400 printing by
providing more specific “how to” information, such as diagrams, programming
samples, and working examples. It addresses the printing function found in
OS/400, Print Services Facility/400 (PSF/400), Advanced Print Utility, Page
Printer Formatting Aid, AFP Font Collection, and other print-enabling software.
The original edition applied to Version 3 Release 2 for CISC systems and Version
4 Release 2 for RISC systems. This second edition includes information about
the new functions that are available in releases up to and including Version 4
Release 5.
This document is intended for customers, business partners, and IBM systems
specialists who need to understand the fundamentals of printing on the AS/400
system. It is designed to help you develop or advise others concerning the design
and development of AS/400 printing applications.
This document is not intended to replace existing AS/400 printing publications,
but rather to expand on them by providing detailed information and examples.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Rochester Center.
Alain Badan is an Advisory IT Specialist in Switzerland. His areas of expertise
include AS/400 printing and AS/400 Facsimile Support/400. Alain has written
other redbooks on AS/400 Printing and Facsimile Support/400.
Simon Hodkin is a Senior IT Specialist in the U.K. Printing Systems Business.
He has worked at IBM for 12 years. He has devised and run classes on printer
connectivity and AFP. During the last three years, Simon has designed and
implemented AS/400 printing solutions for major U.K. customers.
Jacques Hofstetter is a Systems Engineer in Switzerland. He has 10 years of
experience in AS/400 printing, and has worked at IBM for 15 years. His areas of
expertise include Advanced Function Presentation and AS/400 printing.
Gerhard Kutschera is a Systems Engineer Specialist in Austria. He has 11 years
of experience with the AS/400 system, and has worked at IBM for 21 years. His
areas of expertise include printing on the AS/400 system and AFP printing on
RS/6000. Gerhard has also written another redbook on OfficeVision/400 printing.
Whit Smith is an Education Specialist in the U.S. He has worked at IBM for eight
years, after several years as an IBM customer. He holds a degree in Computer
Science from the University of Texas. His areas of expertise include
Communications, Application Development, and System Management.
The October 2000 revision of the IBM AS/400 Printing V redbook was a result of
the contributions of:
xiv IBM AS/400 Printing V
Mike McDonald
Bill Shaffer
IBM Boulder
Roger Drolet
Mira Shnier
IBM Canada
Simon Hodkin
IBM United Kingdom
Thanks to the following people for their invaluable contributions to the first edition
of this redbook:
Nick Hutt
ITSO Rochester
Russ Dickson
Ken Dittrich
Karl Hanson
Dave Murray
Ted Tiemens
Kevin Vette
IBM Rochester
Tim Aden
Jack Klarfeld
Bruce Lahman
Robert Muir
Brian Pendleton
Dale Pirie
Bill Shaffer
Bob Stutzman
Nancy Wood
IBM Boulder
Eddy Gauthier
IBM Belgium
Mira Shnier
IBM Canada
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 review” on page 425 to the
fax number shown on the form.
• Use the online evaluation form found at ibm.com/redbooks
• Send your comments in an Internet note to redbook@us.ibm.com
© Copyright IBM Corp. 2000 1
Chapter 1. Printing on the AS/400 system
We can define and view printing in a simplified manner: something to print, a
program to pass the information to a printer, and a printer (and some paper).
The same sentence translated into AS/400 printing terminology results in: An
application creates a spooled file; the data is from the application and 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 print writer program then passes the spooled file to the printer to
print it. The print writer also takes information from the printer device description.
Figure 1 shows the basic AS/400 printing elements.
Figure 1. Basic AS/400 printing elements
The objectives of this chapter are to explain how printing works and to show all
the printing possibilities with AS/400 systems.
1.1 Output queues: Spooled files
The spooled files stored in output queues can have different origins and different
formats (data streams) (Figure 2 on page 2), for example:
• Spooled files can be created on the AS/400 system by an application, by
OfficeVision/400, or just by a print screen.
• With Client Access/400, the network printing function (previously named
virtual printing) can direct PC output to an AS/400 output queue.
• You may also receive spooled files from host systems (IBM S/390), RISC
systems (IBM RS/6000), or OEM systems.
Application
Output Queue
Print Writer
Printer
Printer Device
Description
Printer File
2 IBM AS/400 Printing V
Figure 2. AS/400 spooled files
On the AS/400 system, many commands are available for controlling printing
activities. Some of the commands are:
WRKSPLF The Work with Spooled Files display shows all (or a specific
portion) of the spooled files that are currently on the system. The
display includes information such as file and user names, device
or queue names, status, and total pages.
From this display, options are available to send, view, and
change the attributes and hold, delete, display, and release the
spooled files.
Function keys are also available to change the assistance level,
select another view, or to display all the printers configured to
the system with the status of their associated print writers.
WRKOUTQ The Work with Output Queue display shows all the files on the
specified queue. The display includes information such as file
and user names, status, total pages, and number of copies.
From this display, you can select an option to send, view, and
change the attributes as well as hold, delete, display, and
release the spooled files.
Function keys are also available to change the assistance level,
select another view, display information on the writer associated
with the output queue, or display all the printers configured to the
system with the status of their associated print writers.
WRKSPLFA The Work with Spooled File Attributes command shows the
current attributes of the specified spooled file. It is possible to
obtain the same display by selecting option 8 (Attributes) from
the Work with Spooled Files or Work with Output Queue display.
The spooled file attributes are information concerning a spooled
file such as status, output queue, printer device type, page size,
font, rotation, character identifier, and number of copies.
CHSPLFA The Change Spooled File Attributes command allows you to
change the attributes of a spooled file while it is on an output
AS/400
Applications Office Vision/400 Remote Systems
AS/400, S/390
CA/400
Network Printing
Ouput Queue
Spooled File
Spooled File
Chapter 1. Printing on the AS/400 system 3
queue. The same display is received by selecting option 2
(Change) in the Work with Spooled Files or Work with Output
Queue display.
Depending on the spooled file printer device type (or data
stream), you may be able to change some of the attributes. For
example, you can change the overlay if the printer file has a
device type *SCS, but you cannot if it is *AFPDS. This is
because the overlay is referenced in the spooled file data and
not as an attribute for *AFPDS.
STRPRTWTR The Start Print Writer command starts a spooling writer to the
specified printer. This command specifies the name of the
printer, the names of the output queue and message queue
used, and the name of the writer.
ENDWTR The End Writer command ends the specified spooling writer and
makes this associated output device available to the system.
The writer can be ended immediately or in a controlled manner.
WRKCFGSTS The Work with Configuration Status command is used to display
and to work with configuration status functions. A command
parameter allows you to specify the type of description for which
you want the status to be shown. For example, for printer
descriptions, select *DEV (devices), and also specify the
configuration description name, a generic name, or *ALL.
Options on the Work with Configuration Status display allow you
to vary on or off the device and display or change the device
description.
For detailed information on these commands and on printer files, see AS/400
Printer Device Programming. Refer to M.3, “Other resources” on page 411, for the
form number based on the version and release level of the OS/400.
1.2 Data streams supported on the AS/400 system
The printed output is the result of the interaction between the printer itself and the
controlling software.
Because there are different requirements for print output and different types of
printers (line mode, page mode), there is also different software (data streams)
(Figure 3 on page 4).
4 IBM AS/400 Printing V
Figure 3. Data stream
The AS/400 system supports different data streams and can automatically create
the majority of them. The Printer device type parameter (Figure 4) in the printer
file determines the type of data stream to be created.
Figure 4. 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):
Used to control line mode printers and has a relatively simple structure. The
Data Description Specifications (DDS) FONT keyword is not supported. The
font specified in the printer file or the printer default font is used.
An extension of SCS, FFT-DCA (Final-Form Text Document Architecture) is
used within the AS/400 Office environment.
• *IPDS (Intelligent Printer Data Stream):
A host-to-printer data stream used for AFP subsystems. It provides an
attachment-independent interface for controlling and managing
Ouput Queue
Spooled File
Printer File
Print Writer
Printer
AS/400
Applications
Data Stream
Data Stream
Create Printer File (CRTPRTF)
Type choices, press Enter.
File . . . . . . . . . . . . . . > MYPRTF Name
Library . . . . . . . . . . . > MYLIB 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
F13=How to use this display F24=More keys
Chapter 1. Printing on the AS/400 system 5
all-point-addressable (APA) printers. It supports interactive, two-way dialog
between the print driver and the printer (printer information, cooperative
recovery, and resources management).
Note: The AS/400 generated IPDS is a subset of the full IPDS. For detailed
information, see 1.3, “Printer writer” on page 6.
• *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. The printer file device type parameter was enhanced in V3R2 and
V3R7 (and later) with a new value *LINE.
• *AFPDSLINE: AFPDS line (also called Mixed) 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.
Programmers must specify AFP structured fields in applications. The printer
file device type parameter was enhanced in V3R2 and V3R7 (and later) with a
new value *AFPDSLINE.
• *USERASCII: ASCII data stream:
There is no formal structure controlling the use of the American National
Standard Code for Information Interchange (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.
To create a spooled file in *USERASCII on the AS/400 system, programmers
must specify ASCII escape sequences in applications using the transparency
mode. We do not recommend this approach because the escape sequences
required in the application depend on the type of printer.
A *USERASCII spooled file can contain any form of ASCII printer data stream
(for example, PCL5, PPDS, or PostScript).
Spooled files can also be received from other systems:
• From another AS/400 system, you can receive spooled files in SCS, IPDS,
LINE, AFPDSLINE, AFPDS, or USERASCII data streams.
• If the spooled file is from a System/390, LINE, AFPDSLINE, and AFPDS are
supported. By using object distribution (SNADS), the spooled file is placed
directly in an AS/400 output queue.
• From a PC running Client Access/400 network printing, you can receive
spooled files in SCS, AFPDS, or USERASCII.
• From a RISC system (RS/6000), you may receive spooled files in AFPDS or
USERASCII.
• From an Other Equipment Manufacturer (OEM) system, spooled files are
normally received in USERASCII.
6 IBM AS/400 Printing V
A spooled file stored in an AS/400 output queue can be in different data streams.
On the other end, many printers support only one data stream (for example SCS,
IPDS, or ASCII PCL5). Some others (for example, the IBM Infoprint 20, 21, 32, and
40) support IPDS, PCL, and Postscript. Figure 5 shows data streams and printer
devices.
Figure 5. Data streams and printer devices
On the AS/400 system, the print writer can convert some of the data streams to
others. The following section explains the possible conversions.
1.3 Printer writer
The printer writer program is a system-supplied program. This program takes the
spooled file from an output queue and sends it to a printer. The printer writer
handles spooled files by using one of the following options:
• Print Writer
• Print Services Facility/400 (PSF/400)
• Host print transform
Each of these writer options supports different data streams and printer types.
They can also perform certain data stream conversions.
Figure 6 shows the three options with the supported input data streams, the
resulting data streams, and the required printer types.
AS/400
Applications
Print Writer
IPDS Printer
AFP(*YES)
ASCII
Printer
Spool
S/390 CA/400
Network Printing
LINE
AFPDSLINE
LINE
AFPDS
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
IPDS Printer
AFP(*NO)
SCS
Printer
SCS
IPDS IPDS
ASCII
Chapter 1. Printing on the AS/400 system 7
Figure 6. Printer writer and data streams
The IPDS data stream generated by the AS/400 system (when the printer file
device type parameter is set to *IPDS) is not the full IPDS data stream. Many
functions are not included in this subset, including the use of external resources
such as fonts or page segments.
The IPDS data stream generated by Print Services Facility/400 (PSF/400)
includes the full IPDS set of commands and supports a two-way dialog between
PSF/400 and the printer (Figure 7).
Figure 7. AS/400 generated IPDS: Full IPDS
IPDS Printer
AFP(*YES)
ASCII
Printer
Spool
AS/400
Applications S/390 CA/400
Network Printing
LINE
AFPDSLINE
LINE
AFPDS
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
IPDS Printer
AFP(*NO) SCS
Printer
IPDS IPDS
ASCII
Emulator
ASCII
Printer
Print
Writer
Print Writer
ASCII
Print Services
Facility/400
Host Print
Transform
SCS
AFPDS
USERASCII
SCS
ASCII
LINE
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
SCS
Spool
IPDS Printer
AFP(*YES)
Spool
AS/400
Applications
LINE
AFPDSLINE
SCS
IPDS
AFPDS
IPDS Printer
AFP(*NO)
IPDS
IPDS
Print
Writer
Print Writer Print Services
Facility/400
LINE
AFPDSLINE
SCS
IPDS
AFPDS
Spool
SCS
IPDS
8 IBM AS/400 Printing V
The AS/400-generated IPDS is supported by the print writer or transformed to full
IPDS by PSF/400. AS/400-generated IPDS cannot be transformed to an ASCII
data stream and can only be sent to another AS/400 system. For more
information, see 1.6.2, “IPDS spooled files” on page 24. Because of these
restrictions, we recommend using device type *AFPDS in place of *IPDS in the
printer file to allow portability, more conversion possibilities, and full IPDS
support.
1.3.1 Print writer
The print writer (Figure 8) is used when the target printers are SCS, IPDS
configured with the Advanced Function Printing (AFP) parameter set to *NO, or
ASCII using an emulator.
Figure 8. Print writer
When printing using the print writer, you have to consider these points:
• If the spooled file data stream is SCS and the target printer is an IPDS
AFP(*NO) printer, the data stream is transformed by the print writer into IPDS.
• If the spooled file data stream is IPDS, AFPDS, or AFPDSLINE and the target
printer is SCS or ASCII using an emulator, an error message is returned.
• If the spooled file data stream is AFPDS or AFPDSLINE and the target printer
is IPDS AFP(*NO), an error message is returned.
• If the spooled file data stream is LINE and refers to a PAGDFN (page
definition) and the target printer is SCS or IPDS AFP(*NO), an error message
is returned.
• If the spooled file data stream is LINE and refers to FORMDF (form definition)
but no PAGDFN (page definition) and the target printer is SCS or IPDS
AFP(*NO), the spooled file will print, but the FORMDF parameter is ignored.
ASCII
Printer
Spool
AS/400
Applications
CA/400
Network Printing
LINE
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
IPDS Printer
AFP(*NO)
SCS
Printer
IPDS
ASCII
Emulator
Print Writer
Print Writer
SCS
USERASCII
SCS
AFPDS
USERASCII
SCS
Spool
Chapter 1. Printing on the AS/400 system 9
• If the spooled file data stream is USERASCII, the target printer must be an
ASCII printer using an emulator.
• If the target printer is an ASCII printer using an emulator, only SCS and
USERASCII spooled files are supported.
Note: The USERASCII spooled files must be in an ASCII printer data stream
supported by the target printer (for example, PCL5, PPDS, or PostScript).
• There is no support for overlays, page segments, or downloaded fonts.
• Barcodes are supported only on IPDS printers (even configured AFP(*NO)).
• An image can only be printed from OfficeVision/400 and the target printer
must be IPDS (even configured AFP(*NO)).
1.3.2 Print Services Facility/400
Implementation of the AFP print subsystem was added to OS/400 in V1R2 (1989)
as an integrated component of the operating system. OS/400 Version 2 was
enhanced in subsequent releases to provide AFP print subsystem support similar
to that in S/390. From OS/400 Version 2, there are two separate printing
subsystems in the operating system. OS/400 native print support (print writer)
continues to support line printers and a subset of IBM IPDS printers and print
functions. Full support for all IPDS printers is provided by the integrated AFP
printing subsystem. Which printing subsystem is used to process application
output is determined by the device description of the target printer. Only printers
defined as IPDS AFP=*YES are controlled by the AFP printing subsystem.
Beginning with OS/400 V3R1, the AFP printing subsystem is a separately
orderable feature of OS/400 called Print Services Facility/400.
This feature is licensed according to the speed in impressions per minute (IPM) of
the fastest AFP printer used on the system. The number of AFP printers on the
system is not relevant, only the speed of the fastest printer. There is also a
separate feature for Facsimile Support/400. The four PSF/400 features are:
• PSF/400 Facsimile Support Only
• PSF/400 1-28 IPM Printer Support
• PSF/400 1-45 IPM Printer Support
• PSF/400 Anyspeed Printer Support
1.3.2.1 When PSF/400 is required
Print Services Facility/400 is required when the AS/400 system must support AFP
page functionality or IPDS print management. In simple terms, this is whenever
the device type in the printer description is *AFPDS. *AFPDS must be specified in
the printer device description in the following situations:
• Any time you are printing to a LAN-attached IPDS printer
• Any time you are printing to an Advanced Function Common Control Unit
(AFCCU) printer
• Any time you require AFP resource management, for example download and
management of fonts, images, overlays, and graphic resources
• Printing to IPDS or ASCII printers attached to Print Services Facility/2
• Printing any AFPDS or line data spooled file to an IPDS printer
• Using Facsimile Support/400 to send faxes
10 IBM AS/400 Printing V
Note: PSF/400 is not required when using the IBM 7852-400 modem as a fax
controller.
Examples of AFCCU printers include:
• IBM 3130 Advanced Function Printer
• IBM 3160 Advanced Function Printer
• IBM Infoprint 60 Advanced Function Printer
• IBM Infoprint 62 Advanced Function Printer
• IBM Infoprint 3000 Advanced Printing System
• IBM Infoprint 4000 Advanced Printing System
• Older IBM AFCCU printers, such as the 3820, 3825, 3827, 3828, 3835, 3900,
and 3935
The following IPDS printers can be supported without PSF/400 (but PSF/400 may
be desirable):
• IBM 4230 Impact Matrix Printer
• IBM 4247 Multiform Impact Printer
• IBM 6400 Line Matrix Printer
• IBM Network Printer (4312)
• IBM Network Printer 17 (4317)
• IBM Infoprint 20 (4320)
• IBM Infoprint 21 (4321)
• IBM Network Printer 24 (4324)
• IBM Infoprint 32 (4332)
• IBM Infoprint 40 (4332)
• Older IBM AS/400 laser printers, such as the 4028, 3112, 3116, 3912, 3916,
and 3930 printers
Note: If any of the printers listed here are LAN-attached or require AFP
functionality (for example: resource management), PSF/400 changes from
optional to required.
1.3.2.2 The Print Services Facility/400 process
PSF/400 provides data stream transforms and AFP print resource management
to ensure that applications and their AFP resources print consistently on all
printers managed by PSF/400. PSF/400 can transform and print the following
data streams on the AS/400 system:
• AFPDS
• SCS
• IPDS
• LINE
• AFPDSLINE
Note: In V4R2 with the image print function, Tag Image File Format (TIFF),
Graphics Interchange Format (GIF), OS/2 and Windows Bitmap (BMP), and
PostScript level 1 data streams can also be transformed to be printed on IPDS
printers. For an overview on the image print transform, see 1.3.4, “Image print
transform” on page 14. For detailed information, see Chapter 7, “Image print
transform” on page 161. The Print Services Facility/400 process is shown in
Figure 9.
Chapter 1. Printing on the AS/400 system 11
Figure 9. Print Services Facility/400 process
PSF/400 combines application output with print resources such as electronic
forms, fonts, page segments, and formatting definitions that are either included
inline with the print output or in the AS/400 system libraries. PSF/400 then
creates IPDS output for the target IPDS printer configured AFP(*YES).
PSF/400 includes two tasks: the print writer task and the print driver task. The
print writer is responsible for the data stream conversion, and the print driver task
manages the AFP resources and passes the data to the printer.
Printer files and data description specifications are the user and application
program interfaces for print formatting on the AS/400 system, and are included
with the operating system. Access to some AFP capabilities, such as electronic
forms (overlays), downloading fonts to a printer from host font libraries (including
image page segments in a document), and others, have been incorporated into
these familiar AS/400 print interfaces for users and application programs.
For more information on Advanced Function Presentation (AFP), see Chapter 2,
“Advanced Function Presentation” on page 35. To enhance an existing
application producing output in SCS data stream to AFP, see Chapter 3,
“Enhancing your output” on page 67.
1.3.2.3 Is PSF/400 installed
To check if the Print Services Facility is installed on your system, type GO LICPGM
on any command line. The display shown in Figure 10 on page 12 appears.
Print Request
Queue
Spool
LINE
AFPDSLINE
SCS
IPDS
AFPDS
Print Writer
Data Stream
Converter
IPDS
IPDS
Print Driver AFP
Resources
Print
Writer
Task
Print
Writer
Task
IPDS Printer
AFP(*YES)
12 IBM AS/400 Printing V
Figure 10. Work with Licensed Programs
Select option 10 (Display installed licensed program), and press the Enter key.
The display shown in Figure 11 appears.
Figure 11. Display Installed Licensed Programs
To see the entry for the Print Services Facility, you may have to page down (press
the Page Down key).
Note: For V3R1 and V3R2, the licensed program number is 5763-SS1; for V3R6
and V3R7, the licensed program number is 5716-SS1; and for V4R1 and V4R2,
the licensed program number is 5769-SS1.
If the Print Services Facility feature is not present, you must install it. If you have
not purchased the PSF/400 feature, contact your IBM representative.
LICPGM Work with Licensed Programs
System: SYS00005
Select one of the following:
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
Selection or command
===> 10
F3=Exit F4=Prompt F9=Retrieve F12=Cancel F13=Information Assistant
F16=AS/400 Main menu
(C) COPYRIGHT IBM CORP. 1980, 1998.
Display Installed Licensed Programs
System: SYS00005
Licensed Installed
Program Status Description
5769SS1 *COMPATIBLE OS/400 - Library QGPL
5769SS1 *COMPATIBLE OS/400 - Library QUSRSYS
5769SS1 *COMPATIBLE Operating System/400
5769SS1 *COMPATIBLE OS/400 - Extended Base Support
5769SS1 *COMPATIBLE OS/400 - Online Information
....... ........... ...... . .......................
5769SS1 *COMPATIBLE OS/400 - AFP Compatibility Fonts
5769SS1 *COMPATIBLE OS/400 - *PRV CL Compiler Support
5769SS1 *COMPATIBLE OS/400 - Common Programming APIs Toolkit
5769SS1 *COMPATIBLE OS/400 - Print Services Facility
5769SS1 *COMPATIBLE OS/400 - Media and Storage Extensions
5769SS1 *COMPATIBLE OS/400 - SOMobjects
5769SS1 *COMPATIBLE OS/400 - Advanced 36
5769SS1 *COMPATIBLE OS/400 - Locale Source Library
More...
Chapter 1. Printing on the AS/400 system 13
Note: Beginning with OS/400 V4R4, license management of PSF/400 (as with all
major OS/400 software) is via license keys. The stacked CD shipped with the
release includes PSF/400. PSF/400 can be installed for a trial period of up to 70
days. This trial period begins when you start the first print writer defined as
AFP(*YES). At the end of the 70-day period, PSF/400 will stop functioning
(unless the license key has been installed).
1.3.3 Host print transform
The host print transform function allows SCS-to-ASCII and AFPDS-to-ASCII
conversion to take place on the AS/400 system instead of by the emulators. SCS
or AFPDS spooled files converted to ASCII data stream can be directed to ASCII
printers.
Note: In V4R2 with the image print function, Tag Image File Format (TIFF),
Graphics Interchange Format (GIF), OS/2 and Windows Bitmap (BMP), and
PostScript level 1 data streams can also be transformed to be printed on ASCII
printers. For an overview of image print transform, see 1.3.4, “Image print
transform” on page 14. For detailed information, see Chapter 7, “Image print
transform” on page 161.
Host print transform converts the SCS data stream or the AFPDS data stream
just before it is sent to the ASCII printer. The spooled file contains SCS data or
AFPDS data and not the converted ASCII data.
AFP resources (such as character sets, overlays, and page segments)
referenced in AFPDS spooled files are converted into ASCII data streams and
passed to the ASCII printer.
Figure 12 shows the host print transform process.
Figure 12. Host print transform process
ASCII printers support several different compositions of ASCII data streams. The
host print transform function generates an ASCII printer data stream for a number
Application
Manufacturer
Type and Model
ASCII
Printer
ASCII
Printer File
Host Print
Transform
SCS or AFPDS
Spool
AFP
Resources
DEVTYPE
*SCS or AFPDS
14 IBM AS/400 Printing V
of IBM and non-IBM printers. To generate the different ASCII data streams, the
host print transform function uses AS/400 system objects that describe
characteristics of a particular printer. These objects are called Work Station
Customizing Objects (WSCST), and it is possible to customize them.
For more information on host print transform, see Chapter 6, “Host print
transform” on page 137.
1.3.4 Image print transform
Image print transform is an OS/400 function (Figure 13) included in Version 4.0
Release 2.0 that is capable of converting image or PostScript data streams into
AFPDS and ASCII printer data streams. The conversion take place on the AS/400
system, which means the data stream is independent of any printer emulators or
hardware connections.
Figure 13. Image print transform function
Depending on the image configuration parameter in the printer device description
and the spooled file data stream, Print Services Facility/400 or host print
transform passes the spooled file to the image transform function.
The image print transform function converts image or print data from one format
into another. The image print transform function can convert the following data
streams:
• Tag Image File Format (TIFF)
• Graphics Interchange Format (GIF)
• OS/2 and Windows Bitmap (BMP)
• PostScript Level 1
CA/400
Network Printing
IBM Network
Station
Spool
PostScript(PS)
TIFF
GIF
BMP
Image Print
Transform
Print Services
Facility/400
Host Print
Transform PS
PCL
IPDS AFPDS
IPDS Printer
AFP(*YES)
ASCII
Printer
PostScript(PS)
TIFF
GIF
BMP
PS
PCL
AFPDS
Chapter 1. Printing on the AS/400 system 15
The image print transform function can generate the following data streams:
• Advanced Function Print Data Stream (AFPDS)
• Hewlett-Packard Printer Control Language (PCL)
• PostScript Level 1
For detailed information on image print transform, see Chapter 7, “Image print
transform” on page 161.
1.4 AS/400 printer attachment methods
This topic shows the different printer attachment methods on the AS/400 system
depending on the type of printer, and gives information on the type of writer
needed (print writer, PSF/400, or host print transform). The following attachment
methods are discussed:
• Printers attached to a workstation controller or to an IBM 5x94 (Remote
Control Unit)
• IPDS printers LAN attached
• ASCII printers attached to displays
• ASCII printers attached to PCs
• ASCII printers LAN attached
• Printers attached using PSF Direct
• Printers attached using PSF/2 DFP (Distributed Print Function)
Note: This topic only includes a discussion about printers directly attached and
controlled by an AS/400 system, or in other words, 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 1.5, “Remote system printing” on
page 22.
For information on printing SCS, IPDS, AFPDS, or USERASCII spooled files on
the different attachment methods, see 1.6, “Printing SCS, IPDS, AFPDS, and
USERASCII spooled files” on page 23. For information on IBM printers, see
Appendix E, “Printer summary” on page 313.
1.4.1 Printers attached to AS/400 workstation controllers or IBM 5x94
Several IBM printers (line (SCS) or IPDS) can be attached directly to AS/400
workstation controllers by twinax cable. The same printers can also be attached
by twinax to a Remote Control Unit IBM 5x94 (Figure 14 on page 16).
16 IBM AS/400 Printing V
Figure 14. Printers attached to workstation controller or IBM 5x94
Note these considerations:
• Use the same functions if the printer is attached to a workstation controller or
IBM 5x94.
Note: IPDS printer are not fully supported on IBM 5294.
• If any IPDS printer is configured with the parameter AFP set to *YES, PSF/400
is required on the system.
• Some twinax attached IPDS printers must be configured AFP(*YES) (for
example, an IBM 3130).
1.4.2 IPDS printers LAN-attached
Any IPDS printers with an IBM AFCCU (Advanced Function Common Control Unit)
can be networked-attached to an AS/400 (for example, IBM Infoprint 60, Infoprint 70,
Infoprint 62, Infoprint 2000, Infoprint 3000, and Infoprint 4000). These printers
support one or more of the following attachments: SNA Token-Ring, SDLC,
TCP/IP Token-Ring, and TCP/IP Ethernet.
IBM workgroup printers with the appropriate Network Interface Card (NIC) are
supported. These printers include:
• IBM Network Printer 12 (4312)
• IBM Network Printer 17 (4317)
• IBM Infoprint 20 (4320)
• IBM Infoprint 21 (4321)
• IBM Network Printer 24 (4324)
• IBM Infoprint 32 (4332)
• IBM Infoprint 40 (4332)
For more information on IBM workgroup printers, see Chapter 10, “IBM AS/400
network printers” on page 205.
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.
The two-way dialog between the AS/400 system and the printer facilitated by
IPDS enables the same general level of print functionality, print management,
IPDS Printer
AFP(*YES)
IPDS Printer
AFP(*NO)
SCS
Printer
AS/400
WSC
IPDS Printer
AFP(*NO)
IPDS Printer
AFP(*YES)
SCS
Printer
5x94
Chapter 1. Printing on the AS/400 system 17
and error recoverability for LAN/WAN-attached IPDS printers as is found in
direct-attached (twinax) IPDS printers.
The capability of IPDS to “bridge” the network connection is especially important
with TCP/IP attachment. Standard print support over TCP/IP (using LPR to LPD)
is a one-way send of the spooled file, with limited support of print functions and
no error recovery.
Note: For detailed information on IPDS LAN-attached printers configuration, see
11.1, “Configuring LAN-attached IPDS printers” on page 223.
Figure 15. IPDS printers LAN-attached
Note these considerations:
• Any IPDS printer LAN attached to an AS/400 system (Figure 15) must be
configured with the AFP parameter set to *YES; PSF/400 is required on the
system.
• IPDS printers with an AFCCU and IBM network printers can be shared among
different systems. The previous limit of three systems sharing an AFCCU
TCP/IP-attached printer is removed by an enhancement provided by PTFs: on
V3R2 (PTF SF42745), V3R7 (PTF SF42655), and V4R1 (PTF SF43250). This
enhancement is part of the base code for V4R2.
• The IPDS printers IBM 4224 and 4234 are not supported.
1.4.3 ASCII printers attached to displays
The IBM InfoWindow displays 3477, 3486, 3487, 3488, and 3489 can be locally
attached to the AS/400 system or remotely attached using an IBM 5x94 control
unit through twinax cable. The InfoWindow displays have a printer port that can
support the attachment of an ASCII printer (Figure 16 on page 18).
AS/400
IPDS Printer
AFP(*YES)
IPDS Printer
AFP(*YES)
I-Data
7913
18 IBM AS/400 Printing V
Figure 16. ASCII printers attached to displays
Note these considerations:
• Using display emulation, only SCS or USERASCII data streams are
supported.
• Using host print transform, SCS, AFPDS, and USERASCII data streams are
supported.
• USERASCII must be in the ASCII printer data stream of the target printer (for
example, PCL5 or PPDS).
• If host print transform is used with AFPDS spooled files, the ASCII printer
must support one of the following data streams: PCL4 or 5 (HP Laser and
InkJet printers, IBM 4039, IBM Network Printers) or PPDS levels 3 and 4 (IBM
4019, 4029).
• PSF/400 is not required when printing AFPDS spooled files with host print
transform.
• IPDS spooled files are not supported by 5250 emulation or host print
transform.
1.4.4 ASCII printers attached to PCs
All ASCII printers can be connected to a PC using the standard parallel or serial
port (Figure 17). 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
AS/400
WSC
5x94
ASCII
Printer
ASCII
Printer InfoWindow
Display
InfoWindow
Display
Chapter 1. Printing on the AS/400 system 19
Figure 17. ASCII printers attached to personal computers
Consider these points:
• Using the PC5250 transform based on PDT, only SCS and USERASCII data
streams are supported. PDT tables can be customized.
• Using the PC5250 transform based on the Windows 95/NT printer driver, only
SCS and USERASCII data streams are supported. No customization is
possible.
• Using host print transform, SCS, AFPDS, and USERASCII data streams are
supported. Customization is possible.
• USERASCII must be in the ASCII printer data stream of the target printer (for
example, PCL5 or PPDS).
• If host print transform is used with AFPDS spooled files, the ASCII printer
must support one of the following data streams: PCL4 or 5 (HP LaserJet and
InkJet printers, IBM 4039, IBM Network Printers) or PPDS levels 3 and 4 (IBM
4019, 4029).
• PSF/400 is not required when printing AFPDS spooled files with host print
transform.
• IPDS spooled files are not supported by the PC5250 transform based on a
PDT or on a Windows printer driver, and by host print transform.
For detailed information, see Chapter 9, “Client Access/400 printing” on page
185.
1.4.5 ASCII printers LAN-attached
ASCII printers may be attached on the network using Token-Ring or Ethernet
connections (Figure 18 on page 20). For print writer support, there are three
ASCII print drivers.
• Line Printer Requester (LPR). These are also known as remote output queue.
• PJL printer drivers. These drivers were released at OS/400 V3R7. The
*IBMPJLDRV system driver supports HP printers.
• SNMP printer driver. This driver was released at V4R5. It is available for the
IBM Infoprint 21 printer at V4R3 and V4R4 (via a PTF).
Note: The PJL and SNMP printer drivers are not available on CISC AS/400
systems (V3R2 and earlier).
AS/400
PC
DOS
PC
Windows
PC
OS/2
ASCII
Printer
ASCII
Printer
ASCII
Printer
20 IBM AS/400 Printing V
For more information on the configuration of ASCII LAN-attached printers, see
11.2, “Configuring LAN-attached ASCII printers” on page 238.
Figure 18. ASCII printers LAN-attached
Consider these points:
• As host print transform is used, SCS, AFPDS, and USERASCII data streams
are supported.
• USERASCII must be in the ASCII printer data stream of the target printer (for
example, PCL5 or PPDS).
• If host print transform is used with AFPDS spooled files, the ASCII printer
must support one of the following data streams: PCL4 or 5 (HP LaserJet and
InkJet printers, IBM 4039, IBM Network Printers) or PPDS levels 3 and 4 (IBM
4019, 4029).
• PSF/400 is not required when printing AFPDS spooled files with host print
transform.
• IPDS spooled files are not supported by host print transform.
• If the new drivers are used, the printer must support Printer Job Language
(PJL). PJL is not supported by all PCL ASCII printers (for example, not
supported by IBM 4029 and HPIII).
• ASCII printers LAN-attached can be shared between different systems (for
example, an AS/400 system and a PC print server).
• Using a LAN-attached ASCII printer removes the limitations of an ASCII
printer connected using a TCP/IP LPR-LPD connection (for example, default
page format and page range to print).
Note: If your ASCII printer supports PJL and is actually connected with a
remote output queue (TCP/IP LPR-LPD), we recommend that you connect it
directly to the AS/400 system with the PJL drivers.
1.4.6 Printers attached to PSF Direct
PSF Direct support is provided by Print Services Facility/2 (PSF/2) and Print
Services Facility/6000 (PSF/6000) (Figure 19). PSF Direct for OS/2 allows a
maximum of 16 printers simultaneously. With PSF Direct attached printers, the
control of the print remains on the AS/400 system, which means PSF Direct
notifies the AS/400 system with any message (print completed, error messages,
and so on).
AS/400
Marknet XLs
ASCII Printer
INA card
ASCII
Printer
ASCII Printer
IBM NP Lan
ASCI Printer
HP JetDirect
Chapter 1. Printing on the AS/400 system 21
Figure 19. Printers attached to PSF Direct
Note these considerations:
• PSF/400 is required on the AS/400 system.
• PSF Direct allows the use of printer resident fonts.
• PSF Direct supports all the IBM IPDS laser printers, the IBM 4230, 6400 IPDS
impact printers, and any PCL or PPDS compatible ASCII printers.
If the target printer is an ASCII printer, PSF Direct converts the IPDS data
stream (received from PSF/400) into an ASCII data stream (in fact, it creates
an image).
1.4.7 Printers attached to PSF/2 DPF
The PSF Distributed Print Function (DPF) is provided by Print Services Facility/2
(PSF/2). PSF/2 DPF allows up to 10 printers simultaneously. With PSF/2 DPF
attached printers, print control is done by PSF/2 (Figure 20). The AS/400 system
is not notified of any printer related messages (print completed, error messages,
and so on).
PSF/400 transfers the spooled files to a queue on the PSF/2 system. When this
transfer is done successfully, the PSF/2 returns an acknowledgment to the
AS/400 system, and the spooled file is removed from the AS/400 output queue.
Then PSF/2 takes control of the spooled file until it is printed.
Figure 20. Printers attached to PSF/2 DPF
AS/400
ASCII
Printer
IPDS Printer
AFP(*YES)
PSF
Direct
AS/400
ASCII
Printer
IPDS Printer
AFP(*YES)
PSF/2
DPF
22 IBM AS/400 Printing V
Note these considerations:
• PSF/400 is required on the AS/400 system.
• There is a time delay due to double spooling. PSF/2 does not start to print the
spooled file until it has been completely received from the AS/400 system.
This is particularly noticeable for large spooled files.
• PSF DPF does not use printer resident fonts, only fonts downloaded from the
AS/400 system.
• PSF DPF supports all the IBM IPDS laser printers and any PCL or PPDS
compatible ASCII printers.
If the target printer is an ASCII printer, PSF DPF converts the IPDS data
stream (received from PSF/400) into an ASCII data stream (in fact, creates an
image).
• IBM IPDS impact printers are not supported (for example, IBM 4230 and IBM
6400).
1.5 Remote system printing
Remote system printing (Figure 21) 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.
Figure 21. Remote system printing
Note these considerations:
• If the spooled file is *AFPDS, *LINE, or *AFPDSLINE, PSF/400 is only needed
on the target system.
• Host print transform is only supported if the connection type parameter is set
to *IP, *IPX, or *USRDFN.
AS/400 Output
Queue
AS/400
NetWare4 Other
ASCII
Printer
ASCII
Printer
ASCII
Printer
ASCII
Printer
ASCII
Printer NetWare3
SCS or IPDS
Printer
Printer
IPDS
Printer PSF/2
S/390 LINE or IPDS
Printer
Chapter 1. Printing on the AS/400 system 23
• If host print transform is used, SCS, AFPDS, and USERASCII data streams
are supported.
• USERASCII must be in the ASCII printer data stream of the target printer (for
example, PCL5 or PPDS). TIFF, BMP, GIF, and PostScript level 1 are
supported if using the image print transform function.
For more information on remote system printing, see Chapter 8, “Remote system
printing” on page 171.
1.6 Printing SCS, IPDS, AFPDS, and USERASCII spooled files
This topic discusses printing SCS, IPDS, AFPDS, and USERASCII spooled files
to printers attached to the AS/400 system or on the network by using remote
system printing.
Note: For detailed information on the attachment methods, see 1.4, “AS/400
printer attachment methods” on page 15. For printing on the network, see 1.5,
“Remote system printing” on page 22.
1.6.1 SCS spooled files
You can print SCS spooled files on:
• SCS or IPDS printers directly attached to a workstation controller, LAN, or IBM
5x94 (remote workstation controller):
If the target printer is an IPDS printer configured with AFP(*YES), PSF/400 is
required on the system.
If the spooled file refers to an overlay (in the printer file), the target printer
must be an IPDS printer configured with AFP(*YES). In this case, PSF/400 is
required on the system.
If the target printer is SCS or IPDS AFP(*NO), the overlay parameter is
ignored.
• ASCII printers by using an emulator or host print transform:
If the spooled file refers to an overlay, this parameter is ignored.
• PSF Direct attached printers:
PSF/400 is always required with PSF Direct attached printers.
• PSF/2 DPF printers:
PSF/400 is always required with PSF/2 DPF attached printers. Host resident
fonts must also be available on the AS/400 system because PSF/2 DPF does
not use printer resident fonts.
• Network with destination type OS400 or OS400V2:
If the spooled file refers to an overlay, this parameter is passed to the remote
AS/400 system. In this case, PSF/400 is only needed on the remote system.
The overlay must be available on the target system and found in the library
list.
• Network with destination type S390:
The SCS spooled file is converted to a form of LINE data.
24 IBM AS/400 Printing V
If the spooled file refers to an overlay, this parameter is not passed to the
S/390.
• Network with destination type PSF2:
The SCS spooled file must be converted to ASCII since PSF/2 does not
support SCS data stream. This can be done by specifying Host Print
Transform(*YES) in the remote output queue definition.
If the spooled file refers to an overlay, this parameter is not passed to PSF/2.
• Network with destination type OTHER:
The SCS spooled file must be converted to ASCII since we mainly address an
ASCII printer with a TCP/IP line printer daemon (LPD) attachment. This can
be done by specifying Host Print Transform(*YES) in the remote output queue
definition.
If the spooled file refers to an overlay, this parameter is not passed to the
remote system.
1.6.2 IPDS spooled files
You can print AS/400-generated IPDS spooled files on:
• IPDS printers directly attached to a workstation controller, LAN, or IBM 5x94
(remote workstation controller):
If the target printer is an IPDS printer configured with AFP(*YES), PSF/400 is
required on the system.
If the spooled file refers to an overlay (in the printer file), the target printer
must be an IPDS printer configured with AFP(*YES). In this case, PSF/400 is
required on the system.
If the target printer is IPDS AFP(*NO), the overlay parameter is ignored.
• PSF Direct attached printers:
PSF/400 is always required with PSF Direct attached printers.
• PSF/2 DPF attached printers:
PSF/400 is always required with PSF/2 DPF attached printers. Host resident
fonts must also be available on the AS/400 system because PSF/2 DPF does
not use printer resident fonts.
• Network with destination type OS400 or OS400V2:
If the spooled file refers to an overlay, this parameter is passed to the remote
AS/400 system. In this case, PSF/400 is only needed on the remote system.
The overlay must be available on the target system and found in the library
list.
• Network with destination type S390:
The IPDS spooled file is converted to a form of LINE data only if no special
device requirements are present (see the spooled file attributes). If special
device requirements are present (normally they are with an IPDS spooled file),
the spooled file cannot be transferred to the S/390.
If the spooled file refers to an overlay, this parameter is not passed to the
S/390.
The following types of printing are not supported:
Chapter 1. Printing on the AS/400 system 25
• Printing on a ASCII printers using an emulator or host print transform
• Printing on a network with destination type PSF2
• Printing on a network with destination type OTHER
1.6.3 AFPDS spooled files
You can print AFPDS spooled files on:
• IPDS AFP(YES) printers directly attached to a workstation controller, LAN, or
IBM 5x94 (remote workstation controller):
PSF/400 is required on the system.
• ASCII printers by using host print transform:
PSF/400 is not required on the system.
• PSF Direct attached printers:
PSF/400 is always required with PSF Direct attached printers.
• PSF/2 DPF attached printers:
PSF/400 is always required with PSF/2 DPF attached printers. Host residents
fonts must also be available on the AS/400 system because PSF/2 DPF does
not use printer resident fonts.
• Network with destination type OS400 or OS400V2:
If the spooled file refers to AFP resources, this information is passed to the
remote AS/400 system. In this case, PSF/400 is only needed on the remote
system. The AFP resources must be available on the target system and found
in the library list.
• Network with destination type S390:
If the spooled file refers to AFP resources, this information is passed to the
remote System/390. The AFP resources must be available on the target
system.
• Network with destination type PSF2:
If the spooled file refers to AFP resources, this information is passed to the
remote PSF/2 system. The AFP resources must be available on the target
system.
• Network with destination type OTHER:
The AFPDS spooled file must be converted to ASCII since we mainly address
an ASCII printer with a TCP/IP line printer daemon (LPD) attachment. This
can be done by specifying Host Print Transform(*YES) in the remote output
queue definition. The ASCII printer must support one of the following data
streams: PCL4/5 or PPDS levels 3 or 4.
Printing on ASCII printers using an emulator is not supported.
1.6.4 USERASCII spooled files
Spooled files with a device type *USERASCII can contain any type of ASCII
printer data stream (for example, PCL5, PPDS, or PostScript). The writer
program just passes the spooled file to the target printer. The spooled file is not
checked for validity.
26 IBM AS/400 Printing V
Note: The following considerations do not address using the image print
transform function (V4R2) on the AS/400 system. For printing USERASCII
spooled files with the image print transform function (V4R2), see 1.6.4,
“USERASCII spooled files” on page 25.
You can print *USERASCII spooled files on:
• ASCII printers using an emulator or host print transform
• A network with destination OS400 or OS400V2
• A network with destination PSF2
• A network with destination OTHER
The following types of a printing are not supported:
• Printing on SCS or IPDS printers attached to a workstation controller, LAN, or
IBM 5x94 (remote workstation controller)
• Printing on PSF Direct attached printers
• Printing on PSF DPF attached printers
1.6.5 USERASCII spooled files with image print transform
The image print transform function allows you to print USERASCII spooled files in
the TIFF, GIF, BMP, or PostScript Level 1 format on IPDS AFP(*YES) printers or
ASCII printers. For an overview of image print transform, see 1.3.4, “Image print
transform” on page 14. For detailed information, see Chapter 7, “Image print
transform” on page 161.
You can print *USERASCII in TIFF, GIF, BMP, or PostScript Level 1 spooled files
on:
• IPDS AFP(*YES) printers attached to a workstation controller, LAN, or IBM
5x94 (remote workstation controller):
PSF/400 is required on the system.
• ASCII printers using host print transform.
• Printing on PSF Direct attached printers:
PSF/400 is always required with PSF Direct attached printers.
• Printing on PSF DPF attached printers:
PSF/400 is always required with PSF DPF attached printers.
• A network with destination OS400 or OS400V2
• A network with destination PSF2
• A network with destination OTHER
These types of printing are not supported:
• Printing on SCS or IPDS AFP(*NO) printers attached to a workstation
controller, LAN, or IBM 5x94 (remote workstation controller)
• ASCII printers using an emulator
• Printing on a network with destination S390
Chapter 1. Printing on the AS/400 system 27
1.7 Implementing a printing concept
When designing any printing solution, you must have the correct printer types to
fit the printing requirements. Consider the following list in order of priority:
1. Print criticality
2. Print output requirements
3. Printer file device type
4. Writer supporting spooled files data streams
5. Printer requirements
6. Type of printers
7. Printer attachment methods
Note: We refer to each of these points as steps in the following sections.
This section also discusses using PSF/400 and IPDS printers versus host print
transform and ASCII printers, and how to enhance your output presentation.
1.7.1 Print criticality
The importance of a given print application to the organization, or print criticality,
influences the design of the printing solution, at least for that application. Print
criticality can be a measure of the importance of the document or the print
volumes, or a combination of the two. A low volume application, such as check
printing, may be critical because of the precise need to control the print process.
With most production applications—volumes over 60 impressions per minute, the
individual documents may be less critical, but the performance and stability of the
entire process is key. The higher the critical nature is of the print application, the
more important the fundamentals are of the printing process. These include:
• Precise control over the printing process
• Assurance that what is directed to be printed is printed, with adequate print
management to respond and resolve error situations
• Control over performance factors
1.7.2 Print output requirements
The print output requirements include which type of documents have to be printed
and their contents. Documents can be simple lists. Some documents may require
barcodes, overlays, logos (images), or different fonts. Also consider documents
that are received from Client Access/400 or other systems.
Examples of typical spooled files in an AS/400 environment are:
• Simple lists
• Documents including different fonts (for example, a Courier and an OCR font)
• Documents with barcodes
• Documents with overlays and page segments (logos, images)
• OfficeVision/400 documents
• PC documents (Lotus AmiPro or Freelance, MS Word)
1.7.3 Printer file device type
According to the print output requirements that you define (step 2), the Printer file
device type parameter (DEVTYPE) can be determined. The device type
parameter is used to create the spooled file in the desired data stream. For more
28 IBM AS/400 Printing V
information on data streams, see 1.2, “Data streams supported on the AS/400
system” on page 3.
Considering the example of the typical spooled files in an AS/400 environment
(step 2), the device type parameter can be:
• SCS for simple lists:
Simple lists are normally printed using one font (often the default font from the
printer file or printer device).
• IPDS or AFPDS for documents including different fonts (for example, Courier
and an OCR font):
Referencing a font can be done by using the FONT DDS (data description
specification) keyword if the device type parameter is IPDS or AFPDS (not
supported if SCS), or by using the FNTCHRSET (Font Character Set) DDS
keyword. This keyword is only supported if the device type is AFPDS.
• IPDS or AFPDS for documents with barcodes:
Barcodes are created by using the BARCODE DDS keyword. This keyword is
only supported if the device type is IPDS or AFPDS.
• SCS, IPDS, or AFPDS for documents with overlays and page segments
(logos, images):
An overlay, which either includes page segments or does not include them,
can be referenced in the printer file (FRONTOVL and BACKOVL parameters)
if the data type is SCS, IPDS, or AFPDS.
The DDS keywords OVERLAY and PAGSEG can only be used if the device
type is AFPDS.
• SCS for OfficeVision/400 documents:
The device type for OfficeVision documents is always SCS. An overlay can be
associated with an OfficeVision/400 document. It must be referenced in the
printer file (FRONTOVL and BACKOVL parameters).
• AFPDS or USERASCII for PC documents (Lotus AmiPro or Freelance,
Microsoft Word):
Using the network printing function from Client Access/400, PC application
outputs can be directed to an AS/400 output queue. The target printer
determines the data stream to use. Output from PC applications is supported
in USERASCII (ASCII data stream determined by the printer driver used) or in
AFPDS (in this case, the AFP driver is used).
1.7.4 Writer supporting printer file device type
The print writer used to pass the spooled file to the printer can be one of the
following types:
• Print writer
• Print Services Facility/400 (PSF/400)
• Host print transform
As you can see in Figure 22, each of these options supports different data
streams and can make various data stream conversions.
Chapter 1. Printing on the AS/400 system 29
Figure 22. AS/400 print writer and data streams
For detailed information on the printer writer, see 1.3, “Printer writer” on page 6.
Depending on the print output requirements that you define (step 2) and the
device type required for the different spooled files (step 3), you can determine the
type of writer to use. Consider the following facts:
• SCS is supported by all three options.
• IPDS is supported by the print writer and PSF/400.
• AFPDS is supported by PSF/400 and host print transform.
• Since overlay and page segments are part of the requirements, only PSF/400
and host print transform can support them.
PSF/400 supports an overlay referenced in the printer file with an SCS, IPDS,
or AFPDS spooled file, and overlays and page segments referenced with the
DDS keywords OVL and PAGSEG when the spooled file is AFPDS.
Host print transform supports an overlay referenced in the printer file only
when the spooled file is AFPDS, and overlays and page segments referenced
with the DDS keywords OVL and PAGSEG when the spooled file is AFPDS.
Note: Overlays referenced in the printer file with a spooled file in SCS are not
supported by host print transform.
• PC documents (Lotus AmiPro or Freelance, Microsoft Word) in AFPDS can be
supported by PSF/400 or host print transform. If the documents are in
USERASCII, they can only be supported by host print transform or the print
writer and an emulator.
From this analysis, you can conclude that Print Services Facility/400 can be used
for all of the document type parts of the requirements, but that host print
transform can also be used with the exception of any overlay referenced in a
printer file with an SCS spooled file.
AS/400
Applications Office Vision/400 Remote Systems
AS/400, S/390
CA/400
Network Printing
Spool
IPDS IPDS Emulator
ASCII
SCS
ASCII
Print Writer Print Services
Facility/400
Host Print
Transform
SCS
AFPDS
USERASCII
LINE
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
SCS
Print Writer
30 IBM AS/400 Printing V
1.7.5 Printer requirements
The printer requirements help in selecting the correct printer types. The following
information must be available:
• Centralized, departmental, or end-user printing
• Print volume
• Type of forms (continuous, page)
• Laser printer or impact printer (or both)
• Print on other systems (remote system printing)
For many AS/400 system environments, you can consider:
• Centralized printing for some applications, high volume, and large spooled
files.
• End-user printing, low volume, some output from the same application
producing large spooled files. For some end users, this mainly includes
documents from PC applications.
• Type of form is page, same format and paper desired for all the printers.
• Laser printer, presentation quality requested.
• One department uses PC applications (Office) intensively.
From this information, you can conclude that you must have a laser printer for
high volume and large spooled files (and eventually a backup printer) and laser
printers for the end users. A PC print server can also be considered for one
department.
1.7.6 Types of printers
For step 4, writer supporting spooled files data streams, the conclusion is that
Print Services Facility/400 can support all the print requirements and host print
transform can support most of them.
For step 5, printer requirements, the conclusion is that a laser printer for large
volume, laser printers for end users, and a PC print server can be considered.
Figure 23 shows the printer types supported according to the writer option.
Chapter 1. Printing on the AS/400 system 31
Figure 23. AS/400 print writer and printer types
PSF/400 can support production IPDS printers with speeds from 110 to 1002
impressions per minute (Infoprint 2000, Infoprint 3000, and Infoprint 4000). Lower
volume centralized or departmental print can be handled by Infoprint 70 (cut sheet),
Infoprint 62 (continuous forms), and Infoprint 60 (cut sheet).
For end-user printing, PSF/400 or host print transform can be used as both
support the AFPDS data stream. As one department uses PC applications
intensively and to avoid too many conversions, these spooled files can be passed
as USERASCII to the AS/400 system or directed to a PC print server.
A good choice for network deployment is shared network printers, such as
Infoprint 20, Infoprint 21, Infoprint 32, and Infoprint 40. These printers support
multiple concurrent print writer sessions across AS/400 and other network clients
or servers. They can be defined to the AS/400 system as both IPDS printers or
ASCII (PCL) printers. Two device descriptions, one AFP and one ASCII, can be
created for the same printer on the AS/400 system.
Note: In V3R2, a remote output queue must be used if the printer is LAN attached
because the PJL driver is not available.
If a PC print server is used, this print server can be connected to an IBM Network
Printer (used as an ASCII printer). The PC print server and the AS/400 system
share the printer.
If host print transform is used for the end-user printer, any ASCII laser printer can
be used. The same printer can also be used with the PC print server.
For considerations on PSF/400 and IPDS printers versus host print transform and
ASCII printers, see 1.7.8.1, “PSF/400 IPDS printers versus HPT ASCII printers”
on page 32.
IPDS Printer
AFP(*YES)
ASCII
Printer
IPDS Printer
AFP(*NO) SCS
Printer
IPDS IPDS
ASCII
Emulator
ASCII
Printer
Print
Writer
ASCII
SCS
ASCII
Print Writer Print Services
Facility/400
Host Print
Transform
SCS
AFPDS
USERASCII
LINE
AFPDSLINE
SCS
IPDS
AFPDS
SCS
AFPDS
USERASCII
SCS
Print
Writer
32 IBM AS/400 Printing V
1.7.7 Printer attachment methods
On the AS/400 system, there are many different ways in which printers can be
attached. For detailed information, see 1.4, “AS/400 printer attachment methods”
on page 15. The LAN connection allows printer sharing for both IPDS and ASCII
printers (both IPDS and ASCII printers can be LAN-attached).
1.7.8 What must be considered
When deciding what printing solution to implement, consider:
• PSF/400 and IPDS printers versus host print transform (HPT) and ASCII
printers
• How to enhance your output presentation
1.7.8.1 PSF/400 IPDS printers versus HPT ASCII printers
Host print transform cannot be considered for high print volume and higher print
speeds. Depending on the print criticality (see 1.7.1, “Print criticality” on page
27), using PSF/400 and IPDS printers is the recommended choice.
In the discussion about Print Services Facility/400 and IPDS printers versus host
print transform and ASCII printers for low print volume (end-user printing),
consider the following points:
• Performance:
Performance considerations are magnified at higher print speeds. Where use
of ASCII printers with host print transform may be acceptable at entry print
speeds (6 to 20 impressions per minute), the transform workload and data
stream inefficiencies will have a significant impact at higher print speeds. IBM
IPDS printers currently extend to 1002 impressions per minute (IBM Infoprint
4000).
Host print transform (HPT) uses more AS/400 resources, specifically when
working with the AFPDS-to-ASCII transform. This is due to the AFP resources
handling and remapping.
When using AFP resources, PSF/400 uses resource retention on the printer.
With this function, the AFP resources, overlays, page segments, and fonts
remain on the printer from job to job and are only deleted when the writer is
ended.
Note: In V4R2, some IPDS printers can keep downloaded fonts even if the
writer is ended and the printer is powered off.
Host print transform clears the downloaded AFP resources at the end of each
print job (that is, when you print three spooled files referencing the same
overlay, the overlay is downloaded three times). This can be costly for
communication lines and can cause poor performance.
• Recoverability:
PSF/400 has a two-way dialog with the IPDS printer. The printer can report
positive acknowledgement or negative acknowledgment to PSF/400. When a
spooled file is printed on an IPDS printer, the spooled file remains in the
AS/400 output queue until the printer has finished printing it, and the last page
is safely in the output bin. At this time, the printer sends a positive
acknowledgement to PSF/400, and the spooled file is deleted from the output
Chapter 1. Printing on the AS/400 system 33
queue. Even if the printer is powered off (normal recovery procedure for some
end users...), the spooled file remains available on the AS/400 system.
ASCII printers do not have any dialog with the AS/400 system, which means
they cannot report back any information. When the transfer of the spooled file
to the ASCII printer is done, the spooled file is deleted from the output queue.
If for any reason the ASCII printer is powered off, the spooled file (or more
than one) is (or are) lost.
To circumvent this risk, the SAVE parameter can be set to “*YES” in the printer
file. With this circumvention, extra work is necessary to clean up the output
queue.
• Fidelity:
PSF/400 does not need special customization. The IPDS printer
characteristics (paper loaded, resident fonts and codes pages, drawers and
bins information, available IPDS towers, resolution, and so on) are passed
from the printer to PSF/400 every time a print writer starts. With this
information, PSF/400 can build the IPDS data stream according to the printer
specifications. Thus, PSF/400 supports all printer file parameters.
PSF/400 allows you to control what is done if it encounters certain formatting
difficulties. With the FIDELITY(*CONTENT), PSF/400 tries to print as much as
it can and sends a message to the operator if there are any problems. With
FIDELITY(*ABSOLUTE), the writer holds the spooled file and does not print it
if PSF/400 is unable to print it exactly as requested.
Host print transform uses a manufacturer type and model table to convert SCS
or AFPDS to ASCII. These tables are available on the OS/400 for many ASCII
printers. Accordingly (for example, the fonts, drawers, and print positions used
in the application, or to handle the unprintable border present on almost all
ASCII printers), a customization of the transform table may be required.
Customizing an ASCII printer may involve a trial-and-error process. For more
information on customizing HPT tables, see 6.7, “Host print transform
customization” on page 151.
• Currency:
Support and testing for IBM AS/400 printers is built into each OS/400 and
PSF/400 release. This support includes new printer features and generally
works with the printer as a native printer device, not as a printer emulating an
older printer. Support is implemented in standard AS/400 interfaces such as
printer files and DDS.
ASCII printers supported by host print transform do not go through this
development and integration process, resulting in certain functions or features
being unsupported. Customization of the transform table may address this, but
only if it is a function already supported by SCS and AFP print support.
1.7.8.2 Enhancing your output presentation
Central to the implementation of a new print solution are changes in the
presentation output. There are many different approaches to enhancing an
application's printed output, including:
34 IBM AS/400 Printing V
• Any application producing SCS output can be enhanced without application
changes by:
– Adding an overlay (for example, by specifying an overlay name in the
FRONTOVL parameter of the printer file). For more information, see
Chapter 2, “Advanced Function Presentation” on page 35.
– Changing the complete document presentation (field positions, fonts,
barcoding, copies, and so on) by using Advanced Print Utility (APU), part of
PrintSuite for AS/400. For more information, see Chapter 3, “Enhancing
your output” on page 67.
– Changing the complete document presentation by using page and form
definitions. For more information, see Chapter 3, “Enhancing your output”
on page 67.
• Any application currently producing SCS or IPDS output can be changed to
AFPDS and can take advantage of the AFPDS DDS keywords. AFPDS DDS
keywords, such as OVERLAY, PAGSEG, FNTCHRSET, BOX, and LINE, are
part of the AS/400 printer file. Since using the printer file DDS is integrated
with the application program, changes may be required to the application
program. For more information, see Chapter 2, “Advanced Function
Presentation” on page 35.
© Copyright IBM Corp. 2000 35
Chapter 2. Advanced Function Presentation
The Advanced Function Presentation (AFP) architecture has been supported on
the AS/400 system since Version 2.0 Release 1.0. Significant new capabilities
have been added with each new release, resulting in a comprehensive document
and printing system.
The architecture was formerly known as Advanced Function Printing, but its
capabilities now include viewing, faxing, and archival/retrieval solutions
(therefore, the change of name; AFP manages the presentation of information).
This chapter provides an overview of AFP implementation on the AS/400 system
and describes several different models used to produce AFP printing solutions.
2.1 Overview of AFP on the AS/400 system
It is important to define some terms before we describe the AS/400 AFP model.
We start by explaining what AFP is.
2.1.1 What AFP is
Advanced Function Presentation is an architecture using a wide range of
functions to provide capabilities such as print formatting, viewing, and archiving.
Three components in the AFP architecture are:
• AFP data stream (AFPDS)
• AFP resources (overlay, page segment, fonts, formatting definitions)
• Print management (Print Services Facility (PSF))
The AFP architecture may also be referred to as MO:DCA-P (Mixed Object
Document Content Architecture for Presentation).
Several data streams are supported in the AFP architecture:
• AFPDS
• LINE
• AFPDSLINE (mixed data)
Intelligent Printer Data Stream (IPDS) is not strictly part of the AFP architecture,
but is closely associated with it. IPDS is the formatted, printer-specific data
stream actually sent to the print device.
2.1.2 AS/400 AFP model
Basically, whatever you print on the AS/400 system uses a printer file. Printer
files determine how the system handles output from application programs. Printer
files fit into one of two groups:
36 IBM AS/400 Printing V
• 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 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 delivered with
OS/400 and many vendor application packages use these simple printer files.
An example is QPDSPLIB—the OS/400-supplied printer file used to define
how pages of a library printout will appear. Although the font, print orientation,
and other attributes may be modified by changing the printer file, the
appearance of individual pages cannot be modified.
• Externally-described printer files:
These printer files have formatting defined using Data Description
Specifications (DDS) external to the application program. Some of the
attributes of the printer file apply to the entire data as before, while the DDS
can override or enhance these options for individual records or fields (for
example, a single field can be printed as a barcode).
All the document elements of AFP (for example, overlays, page segments,
fonts, barcodes, lines, and boxes) are supported by DDS keywords. Using
these keywords to lay out pages is the standard, integrated method of defining
application output on the AS/400 system. With Version 3.0, each of these
keywords has been made dynamic. This means that both characteristics (for
example, overlay name) and page placement (position) can be passed
dynamically (as a program variable) from the application program. This
enables pages of output to be precisely customized based on application data.
Figure 24 shows how the printer file fits into the AFP printing process. Each
step in the process is explained in the notes following the figure.
Figure 24. Printer file model
DDS Print program 1
4
2
5
PSF
Printer
File
3
7
6
Overlay
Fonts
Page and
Form
Definitions
Page
Segments
Spool
Chapter 2. Advanced Function Presentation 37
Now that you understand the basic AFP print process on the AS/400 system, let’s
look at how certain AFP application enablers are used on the system.
2.1.3 APU print model
Advanced Print Utility (APU) provides the capability to modify the appearance of
an SCS spooled file without any application modifications. APU can be used
when access or skills to modify application source code is not available. In
addition, APU can be used when it is desirable to separate complex page
formatting from the application program.
The user can manipulate the data appearance on any AS/400 workstation or PC
5250 session. The collection of the data modification is saved in a new object (the
APU Print Definition) containing the new formatting information. The print
definition is used by the APU print engine to create a new spooled file. The print
definition may be applied interactively, or as part of a Control Language (CL)
program. It may also be applied automatically using the APU monitor function
supplied with APU. This is described in the notes following Figure 25 on page 38.
1 The application program is invoked by the user to print data from the AS/400
system and to produce a spooled file.
2 The printer file parameters are used to format the data. Data Description
Specifications (DDS) are optionally used to improve the appearance of the
data.
3 The spooled file contains the data from the program with the appropriate
formatting instructions as defined in the printer file. External resources, such
as fonts or overlays, are not embedded in the spooled file. Only references
to them are embedded.
4 The AFP resources are added to the print process at print time by PSF/400.
5 PSF/400 sends the print data and the resources to the printer.
6 PSF/400 manages all the printer tasks such as printer characteristics,
resources management, and error recovery.
7 IPDS printers communicate with the system to provide information about the
printer and the status of the print job.
Notes
38 IBM AS/400 Printing V
Figure 25. APU print model
Print program
1
4
2
5
PSF
Printer
File
3
6
Spool Spool
Spool
Spool
Spool Spool
Spool
Spool
Overlay
Fonts
Page and
Form
Definitions
Page
Segments
APU
Monitor
APU
Print
Engine
APU
Definitions
Chapter 2. Advanced Function Presentation 39
Advanced Print Utility (APU) is one of the components of PrintSuite/400 with the
following licensed program numbers:
• 5798-AF2 for OS/400 V3R2
• 5798-AF3 for OS/400 V3R7 through V4R5
The PrintSuite/400 components can be ordered independently of each other.
Note: APU and PrintSuite/400 are not available for OS/400 V3R1 or V3R6.
2.1.4 PFU print model
Print Format Utility (PFU) (Figure 26 on page 40) is a part of AFP Utilities/400
(AFPU). PFU allows customers to print database file data as an AFP formatted
report without any programming. A popular use of PFU is to easily define a
multi-up label application using various graphical elements, barcodes, and a
variety of fonts.
Where overlays and page segments are AS/400 objects used for AFP printing,
Print Format Definitions (PFDs) are members of specialized database files
created with AFPU. With PFDs, you can define record layouts containing variable
data from a database file and page layouts containing fixed data (text, boxes,
lines, barcodes, graphics, and page segments). The AFP Utilities/400 licensed
program is required on each system used to define or print with PFDs.
PFU is a part of the AFP Utilities/400 and cannot be ordered separately. AFP
Utilities/400 has the order number 5769-AF1 for OS/400 V4.
1 The application program produces an SCS spooled file on the output queue.
2 Any output queue may be used. However, the monitor cannot capture the
spooled file if a print writer is attached to this output queue.
3 The users have to define which output queues are monitored. The monitor
supervises all entries in the monitored output queues and invokes the APU
print engine as soon as the spooled file entries match the print definition
requirement.
4 At this time, the information contained in the APU print definition is used by
the print engine to write a new AFP spooled file.
5 The new spooled files are placed in an output queue according to the
monitor definition. This process is explained in more detail in 2.4.4,
“Advanced Print Utility (APU) monitor enhancement” on page 52.
6 The AFP resources are added to the print process at print time by PSF/400.
It then sends the print data and the resources to the printer.
Notes
40 IBM AS/400 Printing V
Figure 26. Print Format Utility print model
1
4
2
PSF
3
Overlay
Fonts
Page and
Form
Definitions
Page
Segments
Spool
Data
Base
PFD
Definition
Print Format Utility
1 After the PFD definition is created, you can invoke the print process
manually in PFU or use the Print PFD Data (PRTPFDDTA) command, which
is part of AFP Utilities/400.
2 PFU extracts the database data using the PFD definition and provides an
AFPDS spooled file.
3 After the AFPDS spooled file is placed in the output queue, the regular print
process applies.
4 The AFP resources are added to the print process at print time by PSF/400.
It then sends the print data and the resources to the printer.
Notes
Chapter 2. Advanced Function Presentation 41
2.1.5 Page and form definitions print model
Page and form definitions are standard AFP resources that separate page
formatting from application program logic. Page and form definitions are
developed in a source programming language that determines how the existing
fields and lines of application output will be changed and composed into full AFP
pages. With Version 3.0 Release 2.0 and Version 3.7 Release 7.0 and later, page
and form definitions can be specified directly in the printer file.
A new compiler, Page Printer Formatting Aid (PPFA)—one of the four AFP
PrintSuite products, is available to compile page and form definition source
modules into AS/400 objects. Page and form definition object modules can also
be transferred from other systems or be created with PC design tools.
Figure 27 illustrates how page and form definitions change the standard AS/400
printing process.
Figure 27. Page and form definition print model
1
4
PSF
3
Overlay
Fonts
Page and
Form
Definitions
Page
Segments
Line
Data
Print program
Printer
File FormDef/PageDef
Parameter 2
1 The application print program uses a printer file similar to all other AS/400
print processes.
2 The DEVTYPE parameter (DEVTYPE *LINE) and the names of the page
definition and form definition have to be set at the printer file level.
3 A spooled file containing line data is produced (this spooled file cannot be
displayed).
4 PSF performs the formatting using the page definition and form definition
and sends the IPDS data stream to the printer with the AFP resources when
needed.
Notes
42 IBM AS/400 Printing V
2.1.6 AFP toolbox print model
The AFP toolbox (Figure 28) is part of PrintSuite/400. It is a collection of
application program interfaces (APIs) for programmers. AFP toolbox allows
developers to produce an AFP data stream while programming in the ILE C,
COBOL, or RPG languages.
Figure 28. AFP Toolbox print model
2.2 AFP resources
AFP resources are elements that PSF can use at print time. The resources are
referenced in the spool, not included in the spooled file themselves. The following
resources are part of the AFP architecture:
1
PSF
3 Overlay
Fonts
Page and
Form
Definitions
Page
Segments
Spool
PRTAFPDTA
Program
using
Toolbox APIs
2
Data
1 The application program writes an AFPDS data stream in a physical file.
2 The PRTAFPDTA command places the AFPDS as a spooled file in the
output queue.
3 The AFP resources are added to the print process at print time by PSF/400.
It then sends the print data and the resources to the printer.
Notes
Chapter 2. Advanced Function Presentation 43
• Overlays: A collection of predefined data such as lines, text, boxes, barcodes,
images, or graphics. All of these elements build an electronic form that can be
merged with the application data at print time. Some elements of the overlay,
such as images (in this case, page segments) and graphics, are not in the
overlay, but are an external resource of the overlay.
• Page segments: Objects that contain images or text information. Page
segments can be referenced in an overlay or can be referenced directly from
an application. Page segments and all other AFP resources are compatible
across system platforms with AFP support.
• Fonts: A set of graphic characters of a given size and style. There are
different types of font objects on the AS/400 system. Most applications can
use fonts with the AS/400 system as printer-resident fonts (Font ID), a code
page and character set, or as a coded font. See Chapter 4, “Fonts” on page
89, for detailed information.
• Form definitions: AFP resources; specify how the printer controls the
processing of a sheet of paper. A form definition can be specified in the printer
file. More information about form definitions is available in Chapter 3,
“Enhancing your output” on page 67.
• Page definitions: AFP resources that contain a set of formatting controls to
specify how you want data positioned on the page. This includes controls for
the number of lines per printed sheet, font selection, print direction, and
mapping fields in the data to positions on the paper. A page definition can be
specified at the printer file level.
2.2.1 Creating AFP resources
The overlay design method is different from one product to another. For AFP
overlays, there are overlay generators on each platform. AFP Utilities/400 on the
AS/400 system or the IBM AFP Printer Driver are the most popular methods. All
AFP overlays are compatible across the different platforms and can be used on
the AS/400 system. Several software products with a graphical interface are
available and provide What You See Is What You Get (WYSIWYG) design of the
different AFP resources.
2.2.1.1 Creating overlays and page segments with AFP Utilities/400
AFP Utilities/400 allows you to create overlays and page segments. You can also
print data from a database file as an AFP formatted report (using the Print Format
Utility).
• The Overlay Utility uses the standard OS/400 interface, and allows you to
create an overlay. The Overlay design function includes text, barcode, lines,
boxes, shading, page segments, and graphics.
• The Resource Management Utility enables you to create page segments.
Most page segments are images from a PC program or from a scanning
process. Several steps must be performed before a page segment object is
available for the print process. Figure 29 on page 44 shows the process with
the image in Image Object Content Architecture (IOCA) (part of the AFP
architecture) format using AFPU.
44 IBM AS/400 Printing V
Figure 29. Image process with IOCA image
Page Segment
AFPU
IOCA
Image
Converter
Image File
Tiff, PCX, etc.
Scanner
8
5
7
6
4
3
2
1
1 Scan an image with a PC-based program. Common image formats are
TIFF, GIF, and PCX.
2 Scanned image may be edited with appropriate software to provide better
results.
3 An image processing program with support for the IOCA image format is
required. Many image processing programs can read many different
formats and convert the image to another format. Another way is to place
the image in a PC application and use the AFP driver to create a page
segment, thereby bypassing step 6. For more information, see 5.4,
“Creating a page segment” on page 126.
4 The image must be in IOCA format.
5 Send or copy the image to the shared folder or network drive.
6 Option 21 of AFPU allows you to create page segments of different sizes
and orientations directly from the IOCA image.
7 A page segment object is now available in a library.
8 The page segment can be referenced in the DDS printer file.
Notes
Chapter 2. Advanced Function Presentation 45
2.2.1.2 Creating an overlay or page segment with the AFP driver
The AFP driver allows you to create AFP resources, overlays, and page
segments from any graphical PC application such as Lotus WordPro, 123, or
Freelance, or Microsoft Word. For more information, see 5.4, “Creating a page
segment” on page 126.
2.2.2 OEM products
There are many non-IBM choices for form creation for AFP. These range from
products that provide for form, font, and image editing to composition systems
(for example, DOC/1 and Custom Statement Formatter) that include a form editor
as part of the overall product.
2.3 AFP Utilities/400 V4R2 enhancements
The following new enhancements are provided in Version 4.0 Release 2.0:
• View Electronic Form on the PC (Overlay Utility)
• Omit Back Side Page Layout (Print Format Utility)
• Element Repeat (Print Format Utility)
• Form Definition (Print Format Utility)
• Tutorial
• Printer Type Enhancement
• Host Outline Font Support
2.3.1 View electronic form on PC (Overlay Utility)
The Overlay Utility can now dynamically call the Client Access/400 (CA/400) AFP
Viewer to view electronic forms on a PC window as they are being designed. The
Overlay Utility creates a temporary overlay that can be accessed by the AFP
Viewer. This provides a WYSIWYG view of the overlay to the user. The
workstation must be a PC attached to the AS/400 system, running Client Access
for Windows 95/NT V3R1M3 or later. The Client Access AFP Workbench Viewer
must be installed. The user ID specified in the Client Access configuration to
access the AS/400 system must be the same as the user ID used to sign on to
the AS/400 session or have all object authority. If not, message CPF2189: “Not
authorized to object...” is returned.
Figure 30 on page 46 shows the Overlay Utility within AFP Utilities/400. A box
and two page segments are placed in the overlay.
46 IBM AS/400 Printing V
Figure 30. Overlay utility from AFPU
When the *VIEW command is typed in the Control field at the top of the display,
the AFP Viewer is invoked as soon as you press the Enter key.
Figure 31 shows the AFP viewer display and the overlay.
Figure 31. AFP viewer window displaying the overlay
Design Overlay Columns: 1- 74
Control . . *VIEW Source overlay . . . . . VIEW
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....
001
002
003
004
005
006 *B001 --------------------+
007 : :
008 : :
009 : :
010 : :
011 : :
012 : :
013 +-------------------------+
014
015
016
017 *S002 *S003
More...
F3=Exit F6=Text F9=Line F10=Box
F11=Bar code F21=Element edit F22=Block edit F24=More keys
Chapter 2. Advanced Function Presentation 47
Note: The AFP viewer cannot display a barcode in Bar Code Object Content
Architecture (BCOCA) format. The AFP Utilities/400 can produce a barcode in
two different ways:
• Barcode for IPDS printer with BCOCA support
• Barcode for IPDS printer without BCOCA support, using Presentation Text
Object Content Architecture (PTOCA) support. That is, the barcode lines are
drawn as text.
If you want to display a barcode with the AFP Viewer, you can change the printer
type in the overlay specifications to a printer type that does not support BCOCA.
The online help for the printer type field provides a list of which printer types do
and do not support BCOCA.
2.3.2 Print Format Utility ‘Omit Back Side Page Layout’
This option allows you to specify a back side overlay to be printed without the
page layout and database data. Effectively, a blank page is inserted into the
application data, and the back side overlay is printed on this page (Figure 32).
Figure 32. PFU omit back side page layout
2.3.3 Element repeat
Element repeat provides a function to duplicate elements multiple times by
pressing a function key and specifying the number of repetitions. The distance
from the first element to the next one must be defined for both the across and
down directions.
2.3.4 Form definition
A form definition can be selected to print a print format definition. This allows a
user with a continuous forms printer to specify the form definition that AFPU
uses. AFPU uses the form length and width specified in the PFD definition.
Define Printout Specifications
Type choices, press Enter.
Copies . . . . . . . . . . . . . . 1 1-255
Print fidelity . . . . . . . . . . *CONTENT *CONTENT, *ABSOLUTE
Print quality . . . . . . . . . . *STD *STD, *DRAFT, *NLQ
Duplex . . . . . . . . . . . . . . Y Y=Yes, N=No
Omit back side page layout . . . . Y Y=Yes, N=No
Form type . . . . . . . . . . . . *STD Character value, *STD
Source drawer . . . . . . . . . . 1 1-255, *E1, *CUT
Front side overlay:
Overlay . . . . . . . . . . . . *NONE Name, *NONE, F4 for list
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Offset across . . . . . . . . . .00 0.00-22.75
Offset down . . . . . . . . . . .00 0.00-22.75
Back side overlay:
Overlay . . . . . . . . . . . . BACKOVL Name, *NONE, F4 for list
Library . . . . . . . . . . . QGPL Name, *LIBL, *CURLIB
Offset across . . . . . . . . . .00 0.00-22.75
Offset down . . . . . . . . . . .00 0.00-22.75
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel
48 IBM AS/400 Printing V
2.3.5 Tutorial
The tutorial is a collection of examples such as overlays, print format definitions,
and database files. The new examples can serve as a tutorial for beginning and
experienced users. To print the tutorial, type STRAFPU and press Enter. Then, from
the AFP Utilities/400 menu, select option 14, and press Enter twice.
2.3.6 Printer type
The printer type list has been updated with new printer types. This allows the user
to choose the printer or the resolution of the printer.
2.3.7 Host outline font support
AFPU was able, in the past, to use a resident printer outline font. Support for
host-resident outline fonts is now part of AFPU. The user can select an outline
font stored on the AS/400 system. The font is downloaded to the printer at print
time. See 4.5.1, “Downloading host-resident outline fonts” on page 100, for more
information.
Figure 33 shows an additional field for the point size selection. The user can use
the Prompt key to show the available font list.
Figure 33. Change Source Overlay Font display
You can select the outline font. No point size information is available for this type
of font. The size is determined for you on the Change Source Overlay Font
display. The same outline font is used for all sizes. You can now reduce the
number of resources needed for an overlay or job (Figure 34).
Change Source Overlay Font
Font number . . . . . . . . : 1
Font type . . . . . . . . . : 3 Code page and font character set
Type choices, press Enter.
Code page . . . . . . . . . T1V10037 Name, F4 for list
Font character set . . . . . CZH200 Name, F4 for list
Point size . . . . . . . . . 1 0.1-999.9, *NONE
Text 'description' . . . . . HELVETICA LATIN1-roman med
F12=Cancel
Chapter 2. Advanced Function Presentation 49
Figure 34. Select Font Character Set display
2.4 Advanced Print Utility (APU) enhancements
Advanced Print Utility (APU) provides an easy way to modify the appearance of
spooled data. You can display the spooled data and move the cursor to define an
action on this data portion. The new function is now part of APU and versions of
APU at V3R2, V3R7, and V4R1 can be refreshed with the same functions. The
customer must re-order APU and will receive the refresh version free of charge.
The most important function is a new monitor that provides an excellent
integration of APU. The following new functions are discussed in this chapter:
• Duplex
• Multiple text
• Outline font
• APU monitor enhancement
2.4.1 Duplex
In the first version, APU was able to place an overlay at the back of the paper
sheet. This allowed the user to take advantage of the duplex option of the printer
to place a constant electronic form. Variable data could not be printed on the back
side of the paper. The new APU duplex option (Figure 35 on page 50) allows you
to print data at the front and at the back of the paper sheet to take full advantage
of the printer duplex option.
Select Font Character Set
Position to . . . . . . . Starting characters
Type option, press Enter.
1=Select
Font
Character
Opt Set Library Text
C02079B0 QFNTCPL PROPTR EMUL 6 CPI ROMAN BOLD ULTRA-EXP 9-PT
C02079G0 QFNTCPL PROPTR EMUL 9 PT ROMAN BOLD ULTRA-EXP 9-PT
C02079L0 QFNTCPL PROPTR EMUL 5 CPI SMALL ROMAN BOLD ULTRA-EXP 4-PT
CZH200 QFNTOLNLA1 HELVETICA LATIN1-roman med
CZH300 QFNTOLNLA1 HELVETICA LATIN1-italic med
CZH400 QFNTOLNLA1 HELVETICA LATIN1-roman bold
CZH500 QFNTOLNLA1 HELVETICA LATIN1-italic bold
CZN200 QFNTOLNLA1 TIMES NEW ROMAN LATIN1-roman med
CZN300 QFNTOLNLA1 TIMES NEW ROMAN LATIN1-italic med
CZN400 QFNTOLNLA1 TIMES NEW ROMAN LATIN1-roman bold
CZN500 QFNTOLNLA1 TIMES NEW ROMAN LATIN1-italic bold
F5=Refresh F12=Cancel
50 IBM AS/400 Printing V
Figure 35. APU duplex display
Consider these points:
• If duplex printing is enabled, the Back Overlay field must contain the value
*NONE because it cannot print a constant back overlay.
• If more than one copy (original page) is required in a page format, duplex
printing is not possible because there are never two consecutive pages of the
same “copy”.
2.4.2 Multiple Text Mapping
APU allows you to define or select a part of a line in the spooled file and map it as
a field. You can change the attribute of this mapped area and define a position.
APU calculates the actual position automatically. You can change the value to
define a new print position. Multiple Text Mapping allows you to place the same
mapped data up to four times.
An example is if your customer document includes a five-line address. You can
print the address a first time, and also print it (or a part) again on the same sheet
of paper four subsequent times.
The Edit Text Mapping display was modified and shows which entry is actually the
Multiple Text entry (Figure 36).
SET PAGE LAYOUT OPTIONS
Print Definition. . .: SAMPLE Page Format. . . . : *DEFAULT
Library. . . . . . . : MYLIB Copy. . . . . . . . : *ORIGINAL
Type choices, press Enter.
Input drawer. . . . . *DEFAULT *DEFAULT, 2, 3, 4
Default line increment *PRTDEF *INCH *PRTDEF, *INPUT, Value
Default Column inc. . . *PRTDEF *INCH *PRTDEF, *INPUT, Va lue
Page length. . . . , . "PRTDEF "INCH *PRTDEF, *INPUT, Value
Page width . . . . *PRTDEF *INCH *PRTDEF, *INPUT, Value
Top margin (down). . "PRTDEF *INCH *PRTDEF, 0, Value
Left margin (across)'. *PRTDEF *INCH *PRTDEF, 0, Value
Page orientation... *PRTDEF *PRTDEF, *INPUT, 0, 90...
Duplex printing.... 1=Yes, 2=Tumble
Back Overlay..... *NONE *NONE, Name, F4 for list
Position across... *INCH 0, Value
Position down.... *INCH 0, Value
F3=Exit F4=Prompt F12=Cancel F22=Set Units
Chapter 2. Advanced Function Presentation 51
Figure 36. Multiple Text (Part 1 of 2)
Figure 37 shows the second target. All attributes, position, font, rotation, and
color may be different from one target to the other one.
Figure 37. APU Multiple Text (Part 2 of 2)
Note these restrictions:
• The Length field may only be changed on the first target and is protected when
the second, third, or fourth target is shown.
• The F15=Repeat function key is not enabled if more than one target is
specified.
• The F22=Set Units function key is only enabled when the first target is shown
and is hidden when the second, third, or fourth target is shown.
• The F16=Delete function key deletes the entire mapping when the first target
is shown. When pressed at the second, third, or fourth target, the additional
target is removed, but at least the first mapping is still there.
Edit Text Mapping
Type Choices, press Enter.
From Row / Column : 20 / 15
Mapping . . . : 1 / 2
Length . . . . . : 8
Position across . : 15 *COL Value
Position down . . : 20 *ROW Value
Font Family . . . : *PRTDEF *PRTDEF, Value F4 for list
Point Size. . . : *CALC, Value
Bold . . . . . : 1=Yes
Italic. . . . . : 1=Yes
Rotation. . . . . : *DEFAULT *DEFAULT, 0, 90,180, 270
Color . . . . . . : *PRTDEF *PRTDEF, Value F4 for list
F4=Prompt F12=Cancel
F16=Delete F22=Set units More...
Type Choices, press Enter.
From Row / Column : 20 / 15
Mapping . . . : 2 / 2
Length . . . . . : 8
Position across . : 31 *COL Value
Position down . . : 67 *ROW Value
Font Family . . . : *PRTDEF *PRTDEF, Value F4 for list
Point Size. . . : *CALC, Value
Bold . . . . . : 1=Yes
Italic. . . . . : 1=Yes
Rotation. . . . . : *DEFAULT *DEFAULT, 0, 90, 180, 270
Color . . . . . . : *PRTDEF *PRTDEF, Value F4 for list
Bottom
F4=Prompt F12=Cancel
F16=Remove additional target
52 IBM AS/400 Printing V
2.4.3 Outline font support
The AS/400 system can download an outline font to IPDS printers. The new
version of APU takes advantage of this technology and simplifies the font
handling.
After the outline fonts are installed (see 4.4, “How fonts are installed” on page
96), the font database must be updated using the following command:
CALL QAPU/QYPUSYNC
Now you can select an outline font from the Work with Font display (Figure 38).
Figure 38. AFP outline fonts in APU
2.4.4 Advanced Print Utility (APU) monitor enhancement
The APU monitor (Figure 39) is part of APU and provides a good way to integrate
the APU print definition in your environment. The first version of the monitor was
limited in its capabilities. The new monitor provides a major enhancement of APU
with a lot of new functions and removes restrictions such as:
• Spooled file name and APU print definition had to be the same.
• The SCS spooled file was set in the hold status only.
• All APU spooled files were placed in one unique output queue.
An APU print definition is required to use the monitor. An example of how to
provide a print definition is presented in 3.2.3, “Creating the print definition” on
page 72.
The user can now define which elements are relevant for the spooled file
selection and what happens to the original SCS spool after APU processing.
They can also take more control of the processing themselves. All of these
parameters are grouped in an Action.
When the monitor finds an action that corresponds with “Selection for input
spooled file” (first action sequence), all other sequences from the same action are
applied. The action sequences are:
Work with Fonts
Domain . . . . . . . . : *ALL *USR, *SYS, *ALL
Type Options, press Enter.
1=Add 2=Change 4=Delete 5=Details
Font
Opt Font family Size Style char. set Code page Domai
TIMES NEW ROMAN 30 Bold-Italic C0N500T0 *DEFAULT *SYS
TIMES NEW ROMAN 36 Normal C0N200Z0 *DEFAULT *SYS
TIMES NEW ROMAN 36 Italic C0N300Z0 *DEFAULT *SYS
TIMES NEW ROMAN 36 Bold C0N400Z0 *DEFAULT *SYS
TIMES NEW ROMAN 36 Bold-Italic C0N500Z0 *DEFAULT *SYS
TIMES NEW ROMAN Outl *V Normal CZN200 *DEFAULT *SYS
TIMES NEW ROMAN Outl *V Italic CZN300 *DEFAULT *SYS
TIMES NEW ROMAN Outl *V Bold CZN400 *DEFAULT *SYS
TIMES NEW ROMAN Outl *V Bold-Italic CZN500 *DEFAULT *SYS
F3=Exit F5=Refresh F12=Cancel
Chapter 2. Advanced Function Presentation 53
• Selection for input spooled file
• Action for input spooled file
• Actions for output spooled file
Figure 39. APU monitor
2.4.4.1 Monitor example
Imagine the following customer environment:
Three different output types are provided in three different output queues
(OUTQs). Two printers are available, and we want to set the monitor with the
following requirements:
• System output (QSYSPRT) must not use an APU print definition.
• All jobs in OUTQ1 must be sent to PRT01.
• All jobs in OUTQ2 and OUTQ3 must be sent to PRT02.
• Application jobs APP01 and APP02 must be sent with a print definition
“SAMPLE” applied.
Spool Spool
Spool
Spool
Spool Spool
Spool
Spool
1
Action Input
selection
Input
action
Output
action
Action 1 3 4 5
Action 2
Action 3
Action...
2
6
1 The monitor is invoked each time a spooled file arrives in a monitored
output queue or if the spooled file status in a monitored queue changes to
*RDY. Spooled files with other status codes are not processed.
2 The monitor checks the input selection from each action rule in a sequential
manner.
3 As soon as a spooled file matches the action input selection, the input and
output actions are performed. The following actions are ignored. The
examples later in this chapter describe how you can create monitor actions.
4 The input action is applied after the selection matches a spooled file. The
action can be different according to whether APU can complete the job
successfully.
5 The user can define up to 16 output actions. This allows you, for example,
to use several different APU print definitions for the same spooled file.
6 One or more spooled files are placed in one or more output queues.
Notes
54 IBM AS/400 Printing V
• The application's original spooled files must be placed in the OUTQ “SAVE”.
• The original QSYSPRT spooled files must be deleted.
Figure 40 shows the original spooled files before monitoring. The numbers in the
figure are used to identify the spool and actions across the different figures of this
example.
Figure 40. APU monitor example: Before processing
• Monitor actions example
In the example, we define two groups of spooled files: the application spooled
files and the QSYSPRT spooled files. Only the application spooled files need
an APU print definition. In this case, we want to define the actions for the
application spooled files first and then the action for the QSYSPRT spooled
files. We can say that all spooled files that are not eligible for APU are moved
following the QSYSPRT spooled file actions.
Figure 40 shows which parameters must be defined for each action in the
order of the action. The monitor uses the Input selection parameters of the
first action to identify whether the spool and selection match. If the input
selection parameters do not match the spooled file, the monitor takes the next
PRT01 PRT02
OUTQ1 OUTQ2 OUTQ3 SAVE
A B
B
1 2 4
C
C B
A
3
QSYSPRT (QSYSPRT) = A
APPLICATION (APP01) = B
APPLICATION (APP02) = C
1 All QSYSPRT spooled files from OUTQ1 must be moved to OUTQ PRT01.
2 All QSYSPRT spooled files from all other OUTQs must be moved to OUTQ
PRT02.
3 A print definition is applied to all application spooled files coming into
OUTQ1. A new APU spooled file (result of the APU processing) is placed in
the output queue PRT01. The original SCS spooled file is moved into OUTQ
SAVE.
4 A print definition is applied to all application spooled files coming into all
other OUTQs. A new APU spooled file (a result of the APU processing) is
placed in the output queue PRT02 for each original spooled file. The original
SCS spooled file is moved into OUTQ SAVE.
Notes
Chapter 2. Advanced Function Presentation 55
action. As soon as the input selection parameters match the spooled file, all
action sequences, such as “Input action” and “Output actions” proceed.
The numbers in Table 1 correspond with Figure 40.
Table 1. APU monitor: Action example
Many other options are possible for each action. You can decide, for example,
to delete the original spooled files after processing or hold the spooled files.
These options are described later in this section.
• Example for output queue after processing
In Figure 41 on page 56, you can see that the two QSYSPRT spooled files (A)
are in the correct output queues, and all original application spooled files are
in output queue SAVE. The new AFPDS spooled files (outcome from APU
processing) are placed in the output queues PRT01 and PRT02, depending on
where the original was.
Action Input selection Input action Output action
Action for spool 3 File = APP*
OUTQ = Outq1
Success = *outq
OUTQ = SAVE
Failure = *hold
Prtdef = Sample
OUTQ = PRT01
Action for spool 4 File = APP*
OUTQ = *all
Success = *outq
OUTQ = SAVE
Failure = *hold
Prtdef = Sample
OUTQ = PRT02
Action for spool 1 File =*all
OUTQ = Outq1
Success = *outq
OUTQ = PRT01
Failure = *hold
Prtdef = *none
Action for spool 2 File = *all
OUTQ = *all
Success = *outq
OUTQ = PRT02
Failure = *hold
Prtdef = *none
3 Action for the application spooled files in OUTQ1
4 Action for all other application spooled files in all monitored OUTQs
1 Action for all other spooled files in OUTQ1
2 Action for all other spooled files in all other OUTQs
Notes
56 IBM AS/400 Printing V
Figure 41. APU monitor example: After processing
If processing for one spooled file fails, the original spooled file stays in the
output queue in *HOLD status following the FAILURE parameter.
2.4.4.2 Using the APU monitor
The following sections can help you set up the APU monitor in your environment.
Several configuration steps are needed:
1. Specify the queues to be monitored.
2. Configure the APU monitor.
3. Start the APU monitor.
4. Stop the APU monitor.
A minimum of one action must be defined for the monitor. All *DEFAULT
parameters can be used. This action provides compatibility with the first monitor.
The APU main menu is shown in Figure 42.
PRT01 PRT02
OUTQ1 OUTQ2 OUTQ3 SAVE
1 2
4
C
B
3
QSYSPRT (QSYSPRT) = A
APPLICATION (APP01) = B
APPLICATION (APP02) = C
B
B C
B A
B C A
C B
3 4
1 The QSYSPRT spooled file from OUTQ1 is in the output queue PRT01.
2 All QSYSPRT spooled files from the other OUTQs are in the output
queue PTR02.
3 The original application SCS spooled files from OUTQ1 are in the output
queue SAVE. New AFPDS spooled files have been placed in the output
queue PRT01. This new spooled file is the result from APU after applying
the print definition.
4 All other original application SCS spooled files from all other OUTQs are
placed in the output queue SAVE. New AFPDS spooled files have been
placed in the output queue PRT02. These new spooled files are the
result from APU after applying the print definition.
Notes
Chapter 2. Advanced Function Presentation 57
Figure 42. APU main menu
2.4.4.3 Specifying the queues to be monitored
The first task is to define which OUTQs must be monitored. The Work with APU
Monitor window is shown in Figure 43. Now you can add or remove OUTQs in the
list. You need to add only the queue where the spooled file action is performed
with an APU print definition. If a spooled file comes in other OUTQs, no action is
performed from the APU monitor. After all queues are added, you need to
configure the APU monitor actions.
Figure 43. Work with APU Monitor
2.4.4.4 Configuring the APU monitor action
This section describes each part of a monitor action. Each action has the
following three parts:
APU IBM Advanced Print Utility
Select one of the following:
Build and Test APU Print Definitions
1. Work with Print Definitions
2. Work with Spooled Files
Run APU in Batch Mode
3. Work with APU Monitor
4. Start APU Monitor
5. End APU Monitor
Configure APU
6. Set APU Defaults
7. Work with Fonts
8. Configure APU Monitor Action
Selection or command
===>
Work with APU Monitor
APU Monitor status . : Active The output queues in the list are
currently monitored by APU
Type options, press Enter.
1=Add 4=Remove
Output
Opt queue Library Text
__
OUTQ1 QGPL Input OUTQ1
OUTQ2 QGPL Input OUTQ2
OUTQ3 QGPL Input OUTQ3
F3=Exit F5=Refresh F12=Cancel
58 IBM AS/400 Printing V
• Selection for input spooled file
• Action for input spooled file
• Action for output spooled file
The Configure APU Monitor Action display (Figure 44) allows you to create,
change, copy, and delete actions. Each action is performed in the sequence
shown on the display by the APU print engine.
Note: If you want the monitor to work in a similar manner to the first version, a
minimum of one action must be defined for the monitor. All *DEFAULT parameters
can be used. This action only provides compatibility with the first monitor. You
must use Option 1 (Add), but you do not need to define an entry. You must give a
sequence number (for example, 10) and text (for example, “Action for
compatibility mode”). Press Enter, and the action is created.
Figure 44. Configure APU Monitor Action display
The F22 key can be used to renumber the entries automatically. The renumbering
uses an increment of 10 unless the number of records is greater than 999. In this
case, the increment is calculated depending on the number of records.
At run time, the monitor retrieves the SCS spooled file attributes and tries to find
a matching entry. The monitor evaluates the entries in the order of the
user-entered sequence numbers. As soon as the monitor finds a match, it
processes the spooled file according to the rest of the action information.
If it does not find a match in the table, the spooled file cannot be processed, a
message is sent to the monitor's job log, and the spooled file stays in the OUTQ.
2.4.4.5 Creating an action group entry
As soon you create or modify an action, the screen shown in Figure 45 appears.
You can select one or more action entries. The print engine performs all three
entries for each action.
Configure APU Monitor Action
Type options, press Enter.
1=Create 2=Change 3=Copy 4=Delete
Opt Sequence Text
_1
10 Qsysprt spool in OUTQ1
20 Qsysprt spool in all other OUTQ's
30 QPJOB spool in OUTQ1
40 QPJOB spool in all other OUTQ's
50 All other spool in OUTQ1
60 All other spool in all other OUTQ's
F3=Exit F5=Refresh F12=Cancel F22=Renumber Sequence
Chapter 2. Advanced Function Presentation 59
Figure 45. Selecting one or more action entries
2.4.4.6 Defining selection criteria for the input spooled file
The first display (Figure 46) is used to define selection criteria for the input
spooled file. In other words, this display is used to select the SCS spooled file that
is processed as input. From this display, the user can decide which spooled file
attributes the monitor should use to match an SCS spooled file.
When the APU Monitor is running, it looks for a file or files with the attributes that
are provided on this display. If APU finds a match between the attributes you
enter here and an input spooled file, it processes both entries: Action for Input
Spooled File and Action for Output Spooled File.
Figure 46. Define Selection for Input Spooled File display
Create Action Entry
Type choices, press Enter.
Sequence . . . . . . . 10 Number
Text . . . . . . . . . QSYSPRT spool in OUTQ1
Type options, press Enter.
1=Select
Opt Function
1 Define selection for input spooled file
1 Define action for input spooled file
1 Define action for output spooled file
F12=Cancel
Define Selection for Input Spooled File
Sequence . . . . . . : 30
Text . . . . . . . . : QPJOB spool in OUTQ1
Type choices, press Enter.
File . . . . . . . . . QPJOB* Name, Generic*, *ALL
Output queue . . . . . OUTQ1 Name, Generic*, *ALL
Library . . . . . . . *LIBL Name, *LIBL
User . . . . . . . . . *ALL User, Generic*, *ALL
User Data . . . . . . . *ALL User Data, Generic*, *ALL
Form Type . . . . . . . *ALL Form Type, Generic*, *ALL
Program . . . . . . . . *ALL Name, Generic*, *ALL
Library . . . . . . . Name, *LIBL
F12=Cancel
60 IBM AS/400 Printing V
The following values can be used by APU to select the input spooled file:
• Spooled file name: Can be a specific name, a generic name, or *ALL.
• Output queue: Can be a specific output queue, a generic name, or *ALL.
• User: Can be a specific user, a generic set, or *ALL.
• User Data: Can be a specific entry in the user data field, generic data, or
*ALL.
• Form Type: Can be a specific form, a generic form, or *ALL.
• Program name: Can be a specific program, a generic program, or *ALL.
2.4.4.7 Defining the action for an input spooled file
With the next entry (Figure 47), a user can define the action for an input spooled
file. This allows a user to tell the monitor what to do with the original SCS spooled
file after the monitor processes the spooled file.
The user can give instructions to hold, delete, do nothing, or move the SCS
spooled file to another output queue. These instructions can be defined differently
depending on whether it is a successful completion or a failed completion from
the processing.
Figure 47. Define Action for Input Spooled File display
APU moves the input spooled file to the output queue defined in the Success or
Failure fields, depending on the result. It places the file in one of the four status
conditions that were previously shown.
2.4.4.8 Defining action for output spooled file example
The user can enter information on two displays (which make up an action group)
that describes the tasks to be performed by the print engine. The user can define
between one and 16 entries for the output spooled file, so it is possible to run
several print definitions for one unique SCS spooled file.
We can take the first example of the APU monitor and add the following additional
requirements.
Define Action for Input Spooled File
Sequence . . . . . . : 30
Text . . . . . . . . : QPJOB spool in OUTQ1
Type choices for input spooled file after successful
or failed processing respectively, press Enter.
Success . . . . . . . . *OUTQ *NONE, *HOLD, *DELETE, *OUTQ
Output queue . . . . OUT1 Name
Library . . . . . . *LIBL Name, *LIBL
Failure . . . . . . . . *HOLD *NONE, *HOLD, *DELETE, *OUTQ
Output queue . . . . Name
Library . . . . . . Name, *LIBL
F12=Cancel
Chapter 2. Advanced Function Presentation 61
Imagine that there is a second location (Paris). Now we must identify which
document is for the local system and which one is for the other location. This is
possible with the conditional option in the print definition. The user must define
two different print definitions. Each uses conditional processing to select which
document is in the new spooled file (each print definition produces one spooled
file).
For the monitor, the user must define two actions for output spooled files. Each
action refers to one of the print definitions. At run time, the print engine runs both
print definitions with a different output queue for each.
Table 2 shows the same example with the additional output actions.
Table 2. Action example
Figure 48 on page 62 shows how the actions have been executed from the
monitor. Due to the conditional processing of the print definition, the application
spooled file has been split between the local and Paris output queues. The white
spooled file represents that only the location dependent data is present.
Action Input selection Input action Output action 1/2 Ouput action 2/2
Action for spool 3 File = APP*
OUTQ = Outq1
Success = *outq
OUTQ = SAVE
Failure = *hold
Prtdef = Sample
OUTQ = PRT01
Prtdef = Sample2
OUTQ = REMLOC 5
Action for spool 4 File = APP*
OUTQ = *all
Success = *outq
OUTQ = SAVE
Failure = *hold
Prtdef = Sample
OUTQ = PRT02
Prtdef = Sample2
OUTQ = REMLOC 6
Action for spool 1 File =*all
OUTQ = Outq1
Success = *outq
OUTQ = PRT01
Failure = *hold
Prtdef = *none
Action for spool 2 File = *all
OUTQ = *all
Success = *outq
OUTQ = PRT02
Failure = *hold
Prtdef = *none
3 Action for the application spooled files in OUTQ1. An additional output
action sequence is added.
5 A second print definition is applied with a different output queue.
4 Action for all other application spooled files in all monitored OUTQs.
6 An additional output section sequence is added. A second print definition is
applied with a different output queue.
1 Action for all other spooled files in OUTQ1.
2 Action for all other spooled files in all other OUTQs.
Note: If an empty or incorrect output action is provided, the action for the Input
SCS spooled file follows the failed procedure.
Notes
62 IBM AS/400 Printing V
Figure 48. Spooled file location after processing
2.4.4.9 Defining an action for the output spooled file
On the Define Action for Output Spooled File display (Figure 49), specify the
name, library, and user-defined parameters for the program to be called by APU
before, during, or after processing.
PRT01 PARIS PRT02
OUTQ1 OUTQ2 OUTQ3 SAVE
1 5
4
C
B
3
QSYSPRT (QSYSPRT) = A
APPLICATION (APP01) = B
APPLICATION (APP02) = C
B
B C
B A
B C B
C B
3 6
B
C
C B
A
2 4
1 The QSYSPRT spooled files from OUTQ1 are in PRT01 OUTQ.
2 All QSYSPRT spooled files from the other OUTQs are in PRT02 OUTQ.
3 All original application spooled files from OUT1 are placed in OUTQ SAVE
after processing. A new AFPS spooled file has been placed in PRT01 for
each spooled file formatted with the print definition “SAMPLE”.
5 A second AFPDS spooled file formatted with the print definition “SAMPLE2”
has been placed in the output queue “REMLOC” for each spooled file.
4 All other original application spooled files from all other OUTQs are placed in
OUTQ SAVE after processing. A new AFPDS spooled file has been placed in
PRT02 for each spooled file formatted with the print definition “SAMPLE”.
6 A second AFPDS spooled file formatted with the print definition “SAMPLE2”
has been placed in the output queue “REMLOC” for each spooled file.
Notes
Chapter 2. Advanced Function Presentation 63
Figure 49. Define Action for Output Spooled File display
The parameters are explained here:
• User exit before: The User exit before field contains the name, library, and
user-defined parameters for the program to be called by the print engine
before it starts to initialize the APU environment.
• Print definition: These lines contain values for the library where the print
definition is stored and for the run option. The following values can be entered
for the run option. If you specify *NONE on the print definition field, any value
you place here is ignored.
– *NORMAL: This is the default value that instructs the print engine to
perform all print engine phases. If this is the first or only action group
defined in this entry, *NORMAL is the only valid value for that field.
Therefore, on the first action group, this field may not be changed. A
complete overview of the print engine phases is provided in 2.4.5, “Print
engine” on page 66.
– *NOCOPY: If the user wants to apply different print definitions with the
same spooled file, this value instructs the print engine to skip the CPYSPL
phase, or to reuse the already prepared input spooled file database
instead. All other phases are performed normally. This value is only valid if
specified in the second or later action group.
– *REPRINT: If the user wants to apply the same print definition multiple
times to the same spooled file, this value instructs the print engine to skip
the CPYSPL, EXTMID, and GENAFP phases. It re-uses the already
prepared output AFPDS database instead. This value is only valid if it is
specified in the second or later action group.
Note: It is important to understand the run option. The run option allows you to
reduce the number of processing steps. This can influence the performance.
Define Action for Output Spooled File
Sequence . . . . . . : 30
Text . . . . . . . . : QPJOB spool in OUTQ1
Action . . . . . . . : 1 / 1
Panel . . . . . . . . : 1 / 2
Type choices, press Enter.
User exit before . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Print Definition . . . SAMPLE Name, *SPOOLFILE, *NONE
Library . . . . . . . *PRTDEFLIB Name, *PRTDEFLIB, *LIBL
Run option . . . . . *NORMAL *NORMAL, *NOCOPY, *REPRI
User exit middle . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Output device . . . . . *JOB Name, *JOB
Output queue . . . . . PRT01 Name, *DEV, *SPOOLFILE
Library . . . . . . . *LIBL Name, *LIBL
F12=Cancel F15=Next action
64 IBM AS/400 Printing V
• User exit middle: This field contains the name, library, and user-defined
parameters for the program to be called by the print engine after the input
spooled file has been copied to the database.
• Output device: Specify the name of the device on which the spooled file is to
be printed. The value *JOB causes APU to place the output spooled file in the
output queue of the current device.
• Output queue: Contains the name of the output queue where the spooled file
is to be placed. *SPOOLFILE tells APU to place the output file in the same
output queue where the input spooled file was found. *DEV has APU place the
file into the output queue of the device specified in the Output device field.
Figure 50. Define Action for Output Spooled File display
The display shown in Figure 50 is used to specify what is to be done after
processing a file:
• File: The File field is the name of the output spooled file. *PRTDEF is used if
you want the output spooled file to have the same name as the print definition.
*SPOOLFILE is used if you want the output spooled file to have the same
name as the input spooled file.
• User data: The user data field specifies the character string that is attached to
the output file. *PRTDEF tells APU to set the value of this field to the name of
the processed print definition. *SPOOLFILE tells APU to set this character
string value to the data string of the input spooled file.
• Form Type: The Form Type field names the form type of the output spooled
file. *PRTDEF tells APU to set the form type to the name of the processed
print definition. *SPOOLFILE sets the form type of the output file to the form of
the input file.
• Hold: The Hold field holds a value specifying the status that the output
spooled file is to have. *NO sets the value to READY; *YES sets the value to
HELD.
Define Action for Output Spooled File
Sequence . . . . . . : 30
Text . . . . . . . . : QPJOB spool in OUTQ1
Action . . . . . . . : 1 / 1
Panel . . . . . . . . : 2 / 2
Type choices, press Enter.
File . . . . . . . . . *SPOOLFILE Name, *PRTDEF, *SPOOLFILE
User Data . . . . . . . *SPOOLFILE User Data, *PRTDEF, *SPOOLFILE
Form Type . . . . . . . *SPOOLFILE Form Type, *PRTDEF, *SPOOLFILE
Hold . . . . . . . . . *NO *YES, *NO
Save . . . . . . . . . *NO *YES, *NO, SPOOLFILE
Output bin . . . . . . *DEVD 1-65536, *DEVD, *SPOOLFILE
User exit after . . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
F12=Cancel F15=Next action
Chapter 2. Advanced Function Presentation 65
• Save: The Save field specifies what happens to the output spooled file. *NO
does not save the file; *YES saves the file. *SPOOLFILE performs the same
action to the output spooled file as was done to the input spooled file.
• Output bin: The Output bin field identifies the output bin of the printer. *DEVD
sends the output to the bin that is specified as the printer device default.
*SPOOLFILE is used to specify the output bin of the input spooled file.
• User exit after: The User exit after field contains the name, library, and
user-defined parameter for the program to be called by APU after the output
spooled file has been created.
2.4.4.10 Applying a print definition manually or with a command
Option 2 of the APU main menu allows you to apply a print definition to a spooled
file manually. All parameters are adapted following the new monitor capability.
The APYPRTDEF command has the same capability.
2.4.4.11 Starting the APU monitor
The display shown in Figure 51 allows you to start one monitor and display the
number of monitors that are already started.
Figure 51. Start APU monitor display
Type the names of the job description and the library where it is stored. Then,
press Enter to start the monitor. After you press Enter, you return to the Main
menu. A message telling you that the APU Monitor is started is shown on the
bottom of the display.
2.4.4.12 Stopping the APU monitor
To stop the APU Monitor, return to the APU main menu, and select Option 5 (End
APU Monitor).
Note these considerations:
• The maximum number of entries is 9999.
• The maximum number of output action groups per entry is 16.
APU IBM Advanced Print Utility
Select one of the following:
Build and Test APU Print Definitions
_________________________________________________________________________
| Start APU Monitor |
| |
| Number of active monitor jobs . . . . . . . . . . . . . . . . . : 0|
| Number of monitor jobs in job queue(s) . . . . . . . . . . . . : 0|
| |
| Type choices, press Enter. |
| |
| Job description . . . . . . . QYPUJOBD Name |
| Library . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB |
|_________________________________________________________________________|
F12=Cancel
===>
66 IBM AS/400 Printing V
2.4.5 Print engine
The following steps refer to phases of the APU print engine. They include a table
of mnemonics for the current and new phases of the engine. The current release
of the engine uses four phases, which are indicated at run time using status
messages. The new release will have eight phases, which will be indicated in a
similar way at run time.
1. Call the user exit program “before”:
CURRENT: not available
NEW: EXTBEF (*** --- --- --- --- --- --- ---)
2. Set up the internal environment:
CURRENT: INZENV (*** --- --- ---)
NEW: INZENV (=== *** --- --- --- --- --- ---)
3. Create an internal spooled file database using the Copy Spooled File
(CPYSPLF) command:
CURRENT: CPYSPL (--- *** --- ---)
NEW: CPYSPL (=== === *** --- --- --- --- ---)
4. Call the user exit program “middle”:
CURRENT: not available
NEW: EXTMID (=== === === *** --- --- --- ---)
5. Process the input and create an AFPDS output database:
CURRENT: GENAFP (--- --- *** ---)
NEW: GENAFP (=== === === === *** --- --- ---)
6. Convert the database to a spooled file using the Print AFP Data
(PRTAFPDTA) command:
CURRENT: PRTAFP (--- --- --- ***)
NEW: PRTAFP (=== === === === === *** --- ---)
7. Call the user exit program “after”:
CURRENT: not available
NEW: EXTAFT (=== === === === === === *** ---)
8. Perform a post-processing action on the SCS input spooled file:
CURRENT: not available
NEW: INPACT (=== === === === === === === ***)
© Copyright IBM Corp. 2000 67
Chapter 3. Enhancing your output
This chapter demonstrates how you can transform a standard AS/400 spooled file
and enhance the output without any application modifications. The following print
applications are used in this chapter:
• Advanced Print Utility (APU)
• Page Printer Formatting Aid (PPFA)
APU and PPFA are part of the AFP PrintSuite for AS/400 family of print products
that enable existing applications to take advantage of Advanced Function
Presentation (AFP). In this chapter, we show a simple example of output
enhancement. Both AFP and PPFA can provide far more complex formatting.
Figure 52 shows a typical output from a standard AS/400 SCS spooled file. Using
plain paper and the Courier font results in a dull document appearance.
Figure 52. Output from a standard SCS spooled file
68 IBM AS/400 Printing V
3.1 How your print output could look
Taking advantage of a laser printer and either APU or PPFA, we can produce a
more attractive document (Figure 53).
Figure 53. Enhanced output
Only a few changes have been made to enhance the page presentation:
• A Gothic font was used instead of Courier 10.
• A Helvetica 14-point font was used for the invoice number.
• An overlay was used comprised of:
– Lines
– Boxes
– Logo
Chapter 3. Enhancing your output 69
3.2 Using Advanced Print Utility (APU)
APU provides the easiest way to modify the presentation output of an existing
application, without changing that application. You can display your spooled file
on the screen and modify the appearance of the data. No DDS changes or
programming is required. You only need to know your application output and be
familiar with the AS/400 system. This section describes a simple example with
APU.
3.2.1 APU environment
APU produces AFPDS spooled files from your original SCS spooled file. These
may be printed on IPDS printers, and on ASCII printers using host print
transform. For more information, see Chapter 6, “Host print transform” on page
137. Table 3 shows which components are required.
Table 3. Component requirement for APU
3.2.2 Setting up APU
After APU and all the required components are installed, you must set the APU
default parameters and synchronize the font database.
3.2.2.1 Fonts
APU does not use printer resident fonts. Instead, it uses AS/400-resident fonts
(character sets) in either raster or outline format. See Chapter 4, “Fonts” on page
Components IPDS printer HPT attached printer
1 APU YES YES
2 PSF/400 YES NO
3 IBM AFP Font Collection Recommended Recommended
4 IBM AFP Printer Driver Recommended Recommended
1 APU is part of PrintSuite/400 and must be installed on each system to
create or apply an APU print definition.
2 PSF/400 is required using an IPDS printer configured as AFP=*YES.
PSF/400 is not required for ASCII printer using host print transform (HPT).
3 APU uses downloaded fonts in AFP Raster or Outline format. The
QFNTCPL library is supplied with OS/400 but contains fonts in 240-pel
resolution. If the printer uses 300-pel resolution, font substitution occurs.
The IBM AFP Font Collection contains additional fonts in both resolutions
(see 4.3, “Which fonts are available” on page 93).
Note: Pel is an abbreviation for picture element or pixel
4 APU provides you with the ability to draw lines and boxes. For greater
functionality, you can use a tool, such as the AFP driver, to create an
electronic form (overlay). For more information about the AFP driver, see
Chapter 5, “The IBM AFP Printer Driver” on page 117.
Notes
70 IBM AS/400 Printing V
89, for additional information about AFP fonts and how PSF/400 provides font
management. Follow this process for using fonts:
1. After all your font libraries are installed, you must add them to your library list
by using the ADDLIBLE command. Alternatively, you can change the
QUSRLIBL system value to reference them.
2. The following command synchronizes the font database:
CALL QAPU/QYPUSYNC
3. This identifies the system fonts to APU. When the database is synchronized,
type the following command to access the APU menu:
GO QAPU/APU
The display shown in Figure 54 appears.
Figure 54. APU main menu
4. Display the font list using option 7 (Work with Fonts) on the APU menu. Figure
55 shows the Work with Fonts display. Note that the Domain parameter must
be changed to *ALL if you want to see all the fonts that are available to APU.
APU IBM Advanced Print Utility
Select one of the following:
Build and Test APU Print Definitions
1. Work with Print Definitions
2. Work with Spooled Files
Run APU in Batch Mode
3. Work with APU Monitor
4. Start APU Monitor
5. End APU Monitor
Configure APU
6. Set APU Defaults
7. Work with Fonts
8. Configure APU Monitor Action
Selection or command
===>
F3=Exit F4=Prompt F9=Retrieve F12=Cancel F16=System main menu
F23=Set initial menu
Chapter 3. Enhancing your output 71
Figure 55. APU font list
3.2.2.2 APU default setup
To setup the APU default, follow this process:
1. The Set APU Defaults display is shown when you select option 6 on the main
APU menu. These defaults are used to set the print definition attributes at
creation time. You cannot create a print definition if no defaults are provided.
2. Before you set or change any parameters, check that all your font resource
libraries are in your library list. Otherwise, you will not have all the fonts or
code pages available for selection.
An example is shown in Figure 56.
Figure 56. APU default
Work with Fonts
Domain . . . . . . . . : *ALL *USR, *SYS, *ALL
Type Options, press Enter.
1=Add 2=Change 4=Delete 5=Details
Font
Opt Font family Size Style char. set Code page Domai
GOTHIC UPPER 6 Normal C0L00GSC T1000893 *SYS
GOTHIC UPPER 6 Normal C0L00GUC *DEFAULT *SYS
GOTHIC UPPER 8 Normal C0L0GU15 *DEFAULT *SYS
GOTHIC UPPER 10 Normal C0L0GU12 *DEFAULT *SYS
GOTHIC UPPER 12 Normal C0L0GU10 T1L00FMT *SYS
GOTHIC13 9 Normal C0D0GT13 *DEFAULT *SYS
HELVETICA 6 Normal C0H20060 *DEFAULT *SYS
HELVETICA 6 Italic C0H30060 *DEFAULT *SYS
HELVETICA 6 Bold C0H40060 *DEFAULT *SYS
HELVETICA 6 Bold-Italic C0H50060 *DEFAULT *SYS
HELVETICA 7 Normal C0H20070 *DEFAULT *SYS
HELVETICA 7 Italic C0H30070 *DEFAULT *SYS
F3=Exit F5=Refresh F12=Cancel
Set APU Defaults
Type choices, press Enter.
Unit of measure . . . . *INCH *INCH, *CM, *ROWCOL, *UNITS
Decimal point character . . or ,
Font family . . . . . . COURIER COMP Value F4 for List
Color . . . . . . . . . *DEFAULT *DEFAULT, Value F4 for List
Definition library . . APUDEF Name
Code Page . . . . . . . T1V10037 Name F4 for List
Addl. resource libs. . AFPRSC Name
Name
Name
Name
Job description . . . . QYPUJOBD Name
Library . . . . . . . *LIBL Name, *LIBL
F3=Exit F4=Prompt F12=Cancel
72 IBM AS/400 Printing V
3. Choose a Font family as the default font by pressing F4 for a list.
4. We recommend that you create a separate library in which to store your print
definitions. In the example, this is called APUDEF.
5. The code page depends on the language of your country. The system value
QCHRID gives the character ID and code page of your system. The “Printer
Resident to Host Resident Code Page Mapping” table in Appendix D of Printer
Device Programming, SC41-5713, provides a conversion table between the
system code page and the AFP code page. The system code page in this
example is 37, and the AFP code page needed for APU is T1V10037.
6. In the Additional resource libraries parameter, type the name of the library or
libraries containing your overlays and page segments. APU can only use the
resources placed in these libraries.
3.2.3 Creating the print definition
To create the print definition, follow these steps:
1. Select option 1 from the APU menu to access the display as shown in Figure
57.
Figure 57. Work with Print Definitions display
2. Create a print definition by selecting option 1. The Create a Print Definition
display is shown in Figure 58.
3. Type a name and descriptive text. Press Enter to finish creating the print
definition.
Work with Print Definitions
Library . . . . . . . . APUDEF Name, *CURLIB
Type options, press Enter.
1=Create 2=Change 3=Copy 4=Delete 5=Display contents
6=Print contents 7=Rename 10=Define 12=Work with
Opt Name Text
1_ _________
F3=Exit F5=Refresh F12=Cancel
Chapter 3. Enhancing your output 73
Figure 58. Create a Print Definition
4. After the print definition is created, the Work with Print Definition display is
shown again. Type option 10 to access “Define a Print Definition”.
5. Select a sample spooled file by taking the appropriate option. This must be an
SCS spooled file of the type you want to modify.
6. Select Set Print Definition Attributes (Figure 59).
Figure 59. Set Print Definition Attributes (Part 1 of 2)
Note: The *INPUT value means that APU can read the SCS spooled file
attributes. Many spooled files do not have the expected attributes. For
example, if the width is 132 and length 66, APU interprets this as landscape
orientation. You can set the required page size information in each supported
value (inches, cm, and so on). If you change the Unit of Measure, APU can
recalculate the values in the appropriate units. In this example, we have
overwritten the page length and width values with length=70 and width=82.
7. Press Page Down or Page Forward on your keyboard to access the display
shown in Figure 60 on page 74.
Create a Print Definition
Type choices, press Enter.
Print Definition . . . ENHANCE Name
Library . . . . . . . APUDEF Name, *CURLIB
Multiple page Formats . *NO *YES, *NO
Text . . . . . . . . . Sample APU Print Definition to enhance output
F12=Cancel
Set Print Definition Attributes
Print Definition . . : ENHANCE
Library . . . . . . : APUDEF
Type choices, press Enter.
Unit of Measure . . . . *CM *INCH, *CM, *ROWCOL, *UNITS
Default line increment *INPUT *UNITS *INPUT, Value
Default column inc. . . *INPUT *UNITS *INPUT, Value
Page length . . . . . . 70 *ROW *INPUT, Value
Page width . . . . . . 82 *COL *INPUT, Value
Top margin (down) . . . 0 *ROW 0, Value
Left margin (across) . 0 *COL 0, Value
Page orientation . . . *INPUT *INPUT, 0, 90, 180, 270
Apply field attributes 1=Yes
F3=Exit F12=Cancel F22=Set Units
74 IBM AS/400 Printing V
Figure 60. Set Print Definition Attributes (Part 2 of 2)
8. In this example, we pressed F4 next to the Default font family field and
selected a monospaced font. Press Enter to complete the “Define a Print
Definition” part.
The Gothic font is the default font in your Print Definition. You can select
different fonts for parts of the document, which are described in the “Map Text”
step later in this section.
9. Press Enter to complete, and press F3 to save and exit.
3.2.4 Working with the print definition
This section shows an example where the appearance of the spooled file data is
modified, and some new elements are added. The following steps are described
in this section:
• Work with Copies
• Define the Copy
Follow these steps:
1. On the Work with Print Definitions display, type 12 next to your Print Definition.
The display shown in Figure 61 appears.
Set Print Definition Attributes
Print Definition . . : ENHANCE
Library . . . . . . : APUDEF
Type choices, press Enter.
Default font family . . GOTHIC COMP *APUDFT, Value F4 for List
Point size . . . . . 12 *CALC, Value
Bold . . . . . . . . 1=Yes
Italic . . . . . . . 1=Yes
Default Color . . . . . *APUDFT *APUDFT, Value F4 for List
Addl. resource libs. . OVERLAY Name
Name
Name
Name
F3=Exit F4=Prompt F12=Cancel
Chapter 3. Enhancing your output 75
Figure 61. Work with Copies
APU provides the *ORIGINAL copy. In the following section, you can modify
the presentation of the data in this *ORIGINAL copy. You can then select
option 3 if you want to duplicate the data (create a second copy), followed by
option 10 to modify the data appearance of the second copy. Typically you
might create the original copy to your exact requirements, and then make a
copy of the Copy. Change some characteristic slightly (for example, have a
different input drawer selected) so the second copy is printed on a different
paper type (punched hole or colored paper, for example).
Do not make a copy of a Copy until you are completely satisfied with the
appearance of your *ORIGINAL copy. Otherwise, you may make the same
changes multiple times.
2. After you select option 10, several functions are available. Select the functions
shown in Figure 62 on page 76.
Work with Copies
Print Definition . . : ENHANCE Page Format . . . . . : *DEFAULT
Library . . . . . . : APUDEF
Type options, press Enter.
1=Create 2=Change 3=Copy 4=Delete 7=Rename
10=Define
Opt Name Text
10 *ORIGINAL Original (first copy)
F3=Exit F5=Refresh F12=Cancel
76 IBM AS/400 Printing V
Figure 62. Define a Copy
Note: Only some APU options are described here. More information about
functions, such as data mapping and conditional processing, are available in
the AS/400 APU User's Guide, S544-5351, or in AS/400 Guide to AFP and
PSF, S544-5319.
APU can also add such elements as boxes, lines, constant text and barcodes,
page segments, and overlays. Only the options in bold are partially described
in the following section.
The following sections show the displays for all selected options, and do not
show the Define a Copy display after each step.
3. Press Enter, and the first selected option display is shown. APU permits a
different format for each copy. Change the drawer parameter on the Set Page
Layout Options display to select another paper source for one of your copies
(see Figure 63).
Define a Copy
Print Definition . . : ENHANCE Page Format . . . . . : *DEFAULT
Library . . . . . . : APUDEF Copy . . . . . . . . : *ORIGINAL
Type options, press Enter.
1=Select
Opt Function
Select a sample spooled file
1 Set page layout options
1 Define field mapping
Define constants
Define boxes
Define page segments
1 Define overlays
F3=Exit F12=Cancel
Chapter 3. Enhancing your output 77
Figure 63. Set Page Layout Options
4. After you press Enter, the next option is shown. The Define Field Mapping
display (Figure 64) shows the content of our SCS spooled file. APU maintains
the correct line spacing of the spooled file.
Figure 64. Define Field Mapping
5. In this example, we change the font of the INVOICE NR. field. Place the cursor
on the I of INVOICE, and press PF14. The rest of the line appears in reverse
Set Page Layout Options
Print Definition . . . ENHANCE Page Format . . . . . : *DEFAULT
Library . . . . . . . APUDEF Copy . . . . . . . . : *ORIGINAL
Type choices, press Enter.
Input drawer . . . . . 2 *DEFAULT, 1, 2, 3, 4
Default line increment *PRTDEF *CM *PRTDEF, *INPUT, Value
Default Column inc. . . *PRTDEF *CM *PRTDEF, *INPUT, Value
Page length . . . . . . *PRTDEF *CM *PRTDEF, *INPUT, Value
Page width . . . . . . *PRTDEF *CM *PRTDEF, *INPUT, Value
Top margin (down) . . . *PRTDEF *CM *PRTDEF, 0, Value
Left margin (across) . *PRTDEF *CM *PRTDEF, 0, Value
Page orientation . . . *PRTDEF *PRTDEF, *INPUT, 0, 90...
Duplex printing . . . . 1=Yes, 2=Tumble
Back overlay . . . . . *NONE *NONE, Name F4 for list
Position across . . . *CM 0, Value
Position down . . . . *CM 0, Value
F3=Exit F4=Prompt F12=Cancel F22=Set Units
Define Field Mapping
Spooled file . . . . : ENHANCE Page/Line . . . . . . : 1/1
Control . . . . . . . . Columns . . . . . . . : 1 - 78
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
Cedric & Marc Ltd,
64 Dream Avenue
Doerfli CO 80301
Phone 012 008 1988
Fax 006 001 1992
INVOICE NR. 123456
Kaffee H. Goodlooks
Customer Nr. 778899 No return Avenue 12
More...
F3=Exit F11=Hide mapping F12=Cancel F13=27x132 Mode
F14=Start field F15=End field F16=Delete range F24=More keys
78 IBM AS/400 Printing V
video. Move the cursor to the place where your invoice number stops and
press PF15.
6. Select the function to Map as Text in the pop-up window (not shown). The
Map Text display appears as shown in Figure 65.
Figure 65. Map Text
7. Move your cursor to the Font family field, and press the PF4 key. Select a font
from the list (Helvetica 14 point was used for this example). Press Enter to
return to the Define Field Mapping display.
You do not need to define field mappings for the complete page. APU will print
all the remaining data according to the default values in the Print Definition
Attributes.
You can add fixed elements such as lines, boxes (no shading), constant text,
and barcodes in APU. No additional software is required.
Page segments and overlays must be created with an appropriate tool, such
as the AFP driver, or by using AFP Utilities/400. See Chapter 2, “Advanced
Function Presentation” on page 35, for information on using these resources
and Chapter 5, “The IBM AFP Printer Driver” on page 117, to create an
overlay with the AFP driver.
8. You can place overlays using the display shown in Figure 66.
Map Text
Type choices, press Enter.
From Row / Column : 5 / 9
Mapping . . . . . : 1 / 1
Length . . . . . . 31
Position across . . 2.032 *CM Value
Position down . . . 2.117 *CM Value
Font family . . . . *PRTDEF *PRTDEF, Value F4 for list
Point size . . . *CALC, Value
Bold . . . . . . 1=Yes
Italic . . . . . 1=Yes
Rotation . . . . . *DEFAULT *DEFAULT, 0, 90, 180, 270
Color . . . . . . . *PRTDEF *PRTDEF, Value F4 for list
More...
F4=Prompt F12=Cancel
F22=Set Units
Chapter 3. Enhancing your output 79
Figure 66. Define Overlay Positioning: Initial display
9. Select 1, and enter the overlay name. Press F4 as a prompt, if required.
10.Press PF12 to complete your Print Definition, and type 1 to save it on the
confirmation display.
3.2.5 Testing the print definition
To test the print definition, follow this process:
1. To test the new Print definition with our spooled file interactively, go to the APU
main menu, and select option 2 (Work with Spooled Files).
2. A list of SCS spooled files is displayed. Select an appropriate spooled file (one
with data in the same layout as your sample spooled file) by typing 1 next to it.
You can change the output queue and the user to narrow the search if
necessary. The display is shown in Figure 67.
Figure 67. Apply Print Definition (APYPRTDEF)
Define Overlay Positioning
Print Definition . . : ENHANCE Page Format . . . . . : *DEFAULT
Library . . . . . . : APUDEF Copy . . . . . . . . : *ORIGINAL
Type options, press Enter.
1=Create 2=Change 3=Copy 4=Delete
Position Position Unit of
Opt across down measure Overlay
1 *CM
(There are no overlay positioning defined)
F3=Exit F5=Refresh F12=Cancel
Apply Print Definition (APYPRTDEF)
Type choices, press Enter.
Input Spooled File . . . . . . . > ENHANCE Name
Job name . . . . . . . . . . . . > PRT_ORDER Name, *
User . . . . . . . . . . . . . > CEDRIC Name
Number . . . . . . . . . . . . > 023810 000000-999999
Spooled file number . . . . . . > 3 1-9999, *ONLY, *LAST
Print Definition . . . . . . . . *SPOOLFILE Name, *NONE, *SPOOLFILE
Library Name . . . . . . . . . *PRTDEFLIB Name, *PRTDEFLIB, *LIBL
Run option . . . . . . . . . . . *NORMAL *NORMAL, *NOCOPY, *REPRINT
Post processing SUCCESS:
Input Spooled File . . . . . . *HOLD *HOLD, *NONE, *DELETE, *OUTQ
Output queue . . . . . . . . . Name
Library Name . . . . . . . . Name, *LIBL
Post processing FAILURE:
Input Spooled File . . . . . . *HOLD *HOLD, *NONE, *DELETE, *OUTQ
Output queue . . . . . . . . . Name
Library Name . . . . . . . . Name, *LIBL
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display .
F24=More keys
80 IBM AS/400 Printing V
3. Type the print definition name, and press Enter. The new AFP spooled file is
created and the SCS spooled file is held on the output queue with a status of
HLD. The creation of the AFP spooled file is indicated by a series of lines and
asterisks at the bottom of the display (moving from left to right). The particular
phases are described in 2.4.5, “Print engine” on page 66.
3.2.6 Printing using the APU monitor
Once you test your APU print definitions interactively, you may want to use them
in batch mode for production printing. The APU monitor is a facility included with
APU that can monitor output queues, apply print definitions, and send the
resulting AFP spooled files to other output queues, all without intervention.
It is an extremely powerful part of APU, and its capabilities are extensive. Two
versions of the APU monitor are available. The latest monitor is set up using
option 8 on the main APU menu.
3.2.6.1 Printing using the first version of the monitor
Follow these steps:
1. Type 3 on the APU menu and add the output queue to be monitored. Use an
output queue without a printer writer started to it if possible.
2. Type 4 on the APU menu to start the monitor.
3. The print definition name must match the spooled file name.
4. The spooled file must be in RDY status.
5. The spooled file must be of type *SCS.
3.2.6.2 Printing with the new version of the monitor
The new monitor can be used in a similar manner. You only have to create an
Action entry with default attributes using option 8 from the APU main menu. You
do not need to define or change the three functions shown in Figure 68.
The default values are defined to be compatible with the first monitor version. For
more information about the new monitor capabilities, see Chapter 2, “Advanced
Function Presentation” on page 35.
To create an Action entry for the APU monitor, use option 8 on the APU main
menu. The display is shown in Figure 68.
Chapter 3. Enhancing your output 81
Figure 68. APU with monitor
After your action entry is created, you need to add the output queue and start the
monitor as already described for the first monitor. As soon as a spooled file with
the same name as your print definition arrives on the monitored queue, the APU
spooled file is automatically produced.
3.3 Using the Page Printer Formatting Aid
Page Printer Formatting Aid (PPFA) is a compiler for standard AFP print
formatting resources called page definitions and form definitions. It compiles the
source modules for these resources into AS/400 objects. AFP page and form
definitions are source and object level compatible, so these modules can be
interchanged between AFP systems and applications.
Note: Do not confuse an APU print definition with the two AFP resources
mentioned here. Page and form definitions are commonly referred to as
“pagedefs” and “formdefs”.
Table 4. Components required for this example
Components IPDS printer
1 PPFA YES
2 PSF/400 YES
3 Font Collection Recommended
4 AFP Utilities/400 Optional
5 AFP Printer Driver Optional
Create action entry
Type choices, press Enter.
Sequence . . . . . . . 10 Number
Text . . . . . . . . . Use default parameter
Type options, press Enter.
1=Select
Opt Function
Define selection for input spooled file
Define action for input spooled file
Define action for output spooled file
F12=Cancel
82 IBM AS/400 Printing V
3.3.1 Creating a source physical file for form and page definitions
You must first create a source physical file to contain the source code:
1. Create a source physical file to contain the code:
CRTSRCPF FILE(MYLIB/PPFASRC1) MBR(ENHANCE)
2. Invoke the Source Entry Utility (SEU) to edit the new member (you can also
use WRKMBRPDM or other commands, according to your preferences):
STRSEU SRCFILE(MYLIB/PPFASRC1) SRCMBR(ENHANCE)
3. Code the form definition and page definition as shown here:
0001.00 /*-----------------------------------------------------*/
0002.00 /* ENHANCE OUR OUTPUT WITH */
0003.00 /* PAGE PRINTER FORMATTING AID */
0010.00 /*-----------------------------------------------------*/
0011.00 FORMDEF FORMJH 1
0012.00 REPLACE YES ;
0013.00
0014.00
0015.00 COPYGROUP FORM1 ; 2
0016.00 SUBGROUP COPIES 1 OVERLAY SMPOVL1
0017.00 SUBGROUP COPIES 1 OVERLAY SMPOVL2
0012.00
0013.00
0014.00 3
0015.00 SETUNITS 1 INCH 1 INCH
0016.00
0017.00
0018.00
0019.00
0020.00
1 PPFA is a part of the AFP PrintSuite/400 and does not require any
additional components to create page and form definitions. The PPFA
resources are usable on most other AFP systems with a Print Services
Facility (PSF) installed. PSF/2 does not support Page Definitions.
2 PSF/400 is required to print with PPFA resources. The IPDS printer must be
configured with AFP=*YES. See 3.3.4, “Considerations” on page 88, for
more information about the restrictions of spooled files processed with
PPFA resources.
3 PPFA uses downloaded fonts in AFP Raster or Outline format. The
QFNTCPL library is delivered with OS/400 but contains fonts in 240-pel
resolution. If the printer uses 300-pel resolution, font substitution occurs
and the presentation of the data may not be as desired. See 4.6, “Font
substitution” on page 101, for more information about font substitution.
4 AFP Utilities/400 can be used to create overlays that are referenced by
PPFA.
5 The AFP Printer Driver can also be used to create overlays. For more
information about the AFP driver, see Chapter 5, “The IBM AFP Printer
Driver” on page 117.
Notes
Chapter 3. Enhancing your output 83
In the same source file, we can code the page definition source shown in the
following examples:
0021.00
0022.00 PAGEDEF PAGEJH
0023.00 WIDTH 8.0 IN 1
0024.00 HEIGHT 11.0 IN
0025.00 DIRECTION ACROSS 2
0026.00 REPLACE YES;
0027.00 FONT NORM CR12; 3
0028.00 FONT BIG H200D0;
0029.00
0030.00 PRINTLINE
0031.00
0032.00 POSITION 0.8 IN 0.166 1
0033.00 FONT NORM 2
0034.00 REPEAT 7 3
0035.00
0036.00 PRINTLINE 1
0038.00 POSITION 0.8 IN 1.5 2
0039.00 FONT BIG 3
0041.00
1 FORMJH is the name of the form definition. REPLACE *YES is used to tell
PPFA to replace the form definition if it already exists.
2 We use the Copy Group statement to provide two copies. Note that each
copy has a different overlay.
3 We set the general parameter using the SETUNITS command.
Notes
1 You must define the paper size in inches, millimeters, or units.
2 This specifies portrait orientation.
3 Define the font using a coded font name. “CR12” is used for most of the
data. “H200D0” is used for the “INVOICE NR” in our invoice example.
Notes
1 After the first input line is recognized, provide the information where the
data will start to print. Inches or millimeters can be used.
2 Define the font to be used for the data using the coded font name.
3 The same formatting is used for the next seven lines of your data.
Notes
84 IBM AS/400 Printing V
0042.00 PRINTLINE
0044.00 POSITION 0.8 IN 1.666 1
0045.00 FONT NORM 2
0046.00 REPEAT 38 3
This is a simple example of using page and form definitions for document
formatting. The intent is to illustrate the concept, not to define the capabilities.
These AFP resources are capable of producing sophisticated document output,
including program logic based on the line data field content.
3.3.2 Compiling the form and page definitions
Before you can use the page and form definition, you must create the AFP
resource by compiling the source code. The following commands are used for
this purpose:
CVTPPFASRC Create a page definition and form definition.
CRTFORMDF Create a form definition object.
CTRPAGDFN Create a page definition object.
3.3.2.1 Creating the AFP resources
You must create a physical file in which to place the compiled objects. In the
following example, we use:
• A physical file FORMDEF to receive the AFP form definition as a member.
• A physical file PAGEDEF to receive the AFP page definition as a member.
Add the QPPFA library in your library list. Otherwise, you cannot find the
CVTPPFASRC command. Type CVTPPFASRC on the command line, and press PF4
(Prompt) to see the display like the example shown in Figure 69.
1 This keyword is used to define the next print line after the repetition. You
must define the entire page of your existing data in the spooled file.
2 Define the position for INVOICENR. No keyword REPEAT is required if only
one line or line portion is defined.
3 Now you can use the Helvetica 14 point (pt) font defined on line 0028.00.
Notes
1 Define the next print position of the data.
2 Use the font NORM for the rest of the data.
3 REPEAT 38 indicates that the next 38 lines have the same formatting.
Note:
Chapter 3. Enhancing your output 85
Figure 69. Creating the AFP resources
3.3.2.2 Creating the form and page definition objects
You need to invoke the CRTFORMDF command to create the AS/400 form
definition. Type CRTFORMDF on the command line, and press PF4 to see a display
like the example shown in Figure 70.
Figure 70. Creating the AS/400 *FORMDF object
Convert PPFA Source (CVTPPFASRC)
Type choices, press Enter.
File . . . . . . . . . . . . . . > PPFASRC1 Name
Library . . . . . . . . . . . > MYLIB Name, *LIBL, *CURLIB
Member . . . . . . . . . . . . . > ENHANCE Name
Form definition file . . . . . . > FORMDEF Name, *NONE
Library . . . . . . . . . . . > MYLIB Name, *LIBL, *CURLIB
Page definition file . . . . . . > PAGEDEF Name, *NONE
Library . . . . . . . . . . . MYLIB Name, *LIBL, *CURLIB
Listing output . . . . . . . . . > *NONE *PRINT, *NONE
Source listing options . . . . . *SRC, *NOSRC, *SECLVL...
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
You can create one or both objects at the same time. This example shows that
both objects are compiled and placed in two different physical files. The
member resulting from the compilation has the name defined in the source
code (FORMJH for the form definition and PAGEJH for the page definition). A
prefix is added at the front of the name depending on the type of object, F1 and
P1.
Note
Create Form Definition (CRTFORMDF)
Type choices, press Enter.
Form definition . . . . . . . . > F1FORMJH Name
Library . . . . . . . . . . . > MYLIB Name, *CURLIB
File . . . . . . . . . . . . . . > FORMDEF Name
Library . . . . . . . . . . . > MYLIB Name, *LIBL, *CURLIB
Member . . . . . . . . . . . . . *FORMDF Name, *FORMDF
Text 'description' . . . . . . . > 'New form definition sample'
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
86 IBM AS/400 Printing V
Notice we add the F1 prefix to the name of the form definition so it picks up the
correct member name. To create the page definition, type CRTPAGDFN on the
command line and press PF4 to see a display like the example shown in Figure
71.
Figure 71. Creating the AS/400 *PAGDFN object
3.3.3 Printing with the form and page definitions
You can only use page and form definitions with LINE data or AFPDS. Line data
is similar to SCS data but does not contain any SCS formatting information. You
must change or override your application printer file to specify DEVTYPE=*LINE
and add the form definition and page definition names.
Note: DEVTYPE=*LINE is not supported for externally described printer files
(DDS support).
Figure 72 shows you how to change the device type in the printer file.
Create Page Definition (CRTPAGDFN)
Type choices, press Enter.
Page definition . . . . . . . . P1PAGEJH Name
Library . . . . . . . . . . . MYLIB Name, *CURLIB
File . . . . . . . . . . . . . . PAGDEF Name
Library . . . . . . . . . . . MYLIB Name, *LIBL, *CURLIB
Member . . . . . . . . . . . . . *PAGDFN Name, *PAGDFN
Text 'description' . . . . . . . Sample page definition
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 3. Enhancing your output 87
Figure 72. Change Printer File (CHGPRTF) (Part 1 of 2)
Press the Page Down or Page Forward key to move to the next display, shown in
Figure 73.
Figure 73. Change Printer File (CHGPRTF) (Part 2 of 2)
Complete your printer file modification by pressing Enter. Now you can invoke
your print program. A spooled file is placed in the output queue. Because the
spooled file contains only line data, you cannot display or send this spooled file.
Change Printer File (CHGPRTF)
Type choices, press Enter.
File . . . . . . . . . . . . . . > ENHANCE Name, generic*, *ALL
Library . . . . . . . . . . . *LIBL Name, *LIBL, *ALL, *ALLUSR...
Device:
Printer . . . . . . . . . . . *SAME Name, *SAME, *JOB, *SYSVAL
Printer device type . . . . . . > *LINE *SAME, *SCS, *IPDS, *LINE...
Page size:
Length--lines per page . . . . *SAME .001-255.000, *SAME
Width--positions per line . . *SAME .001-378.000, *SAME
Measurement method . . . . . . *SAME *SAME, *ROWCOL, *UOM
Lines per inch . . . . . . . . . *SAME *SAME, 6, 3, 4, 7.5, 7,5...
Characters per inch . . . . . . *SAME *SAME, 10, 5, 12, 13.3, 13...
Overflow line number . . . . . . *SAME 1-255, *SAME
Record format level check . . . *SAME *SAME, *YES, *NO
Text 'description' . . . . . . . *SAME
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Change Printer File (CHGPRTF)
Type choices, press Enter.
Decimal format . . . . . . . . . *SAME *SAME, *FILE, *JOB
Font character set:
Character set . . . . . . . . *SAME Name, *SAME, *FONT
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Code page . . . . . . . . . . Name
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Point size . . . . . . . . . . 000.1-999.9, *NONE
Coded font:
Coded font . . . . . . . . . . *SAME Name, *SAME, *FNTCHRSET
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Point size . . . . . . . . . . 000.1-999.9, *NONE
Table Reference Characters . . . *SAME *SAME, *YES, *NO
Page definition . . . . . . . . P1PAGEJH Name, *SAME, *NONE
Library . . . . . . . . . . . MYLIB Name, *LIBL, *CURLIB
Form definition . . . . . . . . F1FORMJH Name, *SAME, *NONE, *DEVD
Library . . . . . . . . . . . MYLIB Name, *LIBL, *CURLIB
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
88 IBM AS/400 Printing V
3.3.4 Considerations
Creating and using page and form definitions provides powerful formatting
capabilities. However, you need to consider some characteristics of this approach
to formatting:
• Once a page or form definition is created, the run-time support is provided by
PSF/400. The compiler (PPFA) is only required on the development system.
• The example in this chapter uses only a few of the capabilities of PPFA.
Creating more complex applications requires greater AFP skills.
• Several Business Partner products are available to design page and form
definitions (see 2.2.2, “OEM products” on page 45). These products provide a
graphical design interface for these resources (there is no graphical interface
available on the AS/400 system).
• Using LINE data with page and form definitions for formatting has the
following restrictions:
– You cannot copy, display, or send a spooled file produced with LINE data.
– You cannot use the AFP Viewer (see 5.6.3.1, “Using the AFP Viewer” on
page 132) to display the spooled file.
– Spooled files formatted with page and form definitions cannot be converted
to an ASCII printer data stream by the host print transform.
3.4 APU versus PPFA
Table 5 shows a comparison between APU and PPFA.
Table 5. APU and PPFA comparison
Function APU PPFA
Display the input spooled file YES NO
Can draw line and box without overlay YES NO
Can place overlays and page segments YES YES
Display spooled file output on a terminal YES NO
Support Outline Font (download) YES YES
Font Character Set and Code Page support YES NO
Coded font NO YES
Program must be installed on each system YES NO
Display SPLF with AFP viewer YES NO
Print spooled file with host print transform YES NO
Requires PSF/400 Only for
IPDS
printers
YES
Spooled file can be sent using SNDNETSPLF YES NO
DBCS enabled NO YES
© Copyright IBM Corp. 2000 89
Chapter 4. Fonts
This chapter describes how fonts are specified in AFP applications and the new
font enhancements for OS/400 at Version 3 Release 2 and higher. For an
introduction to AS/400 font terminology, refer to Appendix D of AS/400 Printer
Device Programming or Chapter 6 of AS/400 Guide to AFP and PSF, S544-5319.
4.1 Where fonts are stored
Fonts are stored either in the printer (printer-resident) or on the AS/400 system
(host-resident). In the latter case, they are automatically downloaded to the
printer by PSF/400 when required.
4.1.1 Printer-resident fonts
These fonts are usually held in the printer's non-volatile memory (NVRAM) or on
a hard disk, but older printers may keep them on diskette, font cards, cartridges,
or even daisy wheels.
Printer-resident fonts are selected by a Font Global Identifier (FGID). For
example, one version of Courier may be 011, while a version of Times New
Roman is 5687.
Listing printer-resident fonts is usually done by selecting a test option from the
printer menus or referring to the printer operating guide. Be sure that you are
viewing the font list for the appropriate data stream (for example, IPDS fonts are
not available to PC applications). Similarly, AFP applications cannot make direct
use of PCL or PostScript fonts. Ensure that you select the decimal value of the
FGID, not the hex value that may also be listed. A page from the IPDS font list
from an IBM Network Printer 17 is shown in Figure 74 on page 90.
90 IBM AS/400 Printing V
Figure 74. IPDS font listing from an IBM Network Printer 17
In terms of performance, printer-resident fonts are the preferred option. Some
printers, such as the IBM Advanced Function Common Control Unit (AFCCU)
printers and the IBM Network Printer range, have scalable resident fonts, which
means that large (or small) characters can be printed without loss of shape or
clarity. The scaling process is carried out by the printer, avoiding any host
processing overhead.
The downside is that different printers may give different results printing the same
data due to the printers' different font capabilities. OS/400 usually invokes font
substitution to ensure that something is printed, but it may not be what you were
expecting! An even worse situation is when a substituted font becomes the
corporate standard. A new printer may subsequently print the correct font but
appear to the customer to be printing the “wrong” font.
4.1.2 Host-resident fonts
Host-resident fonts are stored in AS/400 system libraries shipped with the
operating system. For example, QFNTCPL is a library of 240-pel IBM
Compatibility fonts. There is a range of chargeable fonts available in both 240-
and 300-pel density. Providing no font substitution takes place (and this can be
controlled), the fidelity of the typeface and positioning of characters is guaranteed
from printer to printer. The character sets and code pages are classified
Chapter 4. Fonts 91
according to their characteristics so that you can soon learn to change to a
different font simply by altering a single letter in the character set name, for
example:
C0H20080 Helvetica Latin1-Roman Medium 8-point
C0H20090 Helvetica Latin1-Roman Medium 9-point
C0H30090 Helvetica Latin1-Italic Medium 9-point
C0H50090 Helvetica Latin1-Italic Bold 9-point
Holding font resources centrally is desirable from a change management and
security point of view. However, these fonts must be downloaded at the beginning
of a job. This may have implications on performance; there may be a delay before
the first page of the job is printed. The font resources usually remain resident in
the printer for subsequent jobs and eliminate this problem. Other considerations
are that host-resident raster fonts take up large amounts of disk space. Take care
to include them in the users' library list (for interactive jobs) or the job's own
library list (for batch jobs). Techniques you can use to minimize these issues are
described in 4.5.1, “Downloading host-resident outline fonts” on page 100, and in
4.9, “Using a resource library list” on page 107.
Host-resident fonts are selected by specifying a font character set and code page
(FNTCHRSET and CDEPAG), for example:
C0S0CR10 Courier Roman 10-point
T1V10285 United Kingdom
They may also be selected by using a coded font (CDEFNT), which is a specific
combination of character sets and code pages, for example:
X0CR07 Courier Roman 10-point (UK)
X0CR07 is a reference to the same character set and code page combination
previously shown. Most IBM font products are placed in libraries beginning with
“QFNTxxx”, so use the following command to quickly locate them and to look for
all font resources on your system:
WRKLIB *ALL/QFNT*
WRKOBJ OBJ(*ALL/*ALL) OBJTYPE(*FNTRSC)
When you have located the font resources, you can use the Work with Font
Resources (WRKFNTRSC) command. For example, the following command
locates all font character set names in the QFNTCPL library:
WRKFNTRSC FNTRSC(QFNTCPL/*ALL) OBJATR(FNTCHRSET)
The pel density can also be determined by selecting option 5 (Display attributes).
4.2 How fonts are selected
Fonts can be selected for an entire spooled file or for individual lines or fields
within a spooled file. The usual place to specify the font for an entire spooled file
is in the printer file. This is achieved by using the CRTPRTF, CHGPRTF, or
OVRPRTF command. The relevant keywords for these commands are:
• FONT
Font Global Identifier (FGID). The point size (if more than one point size is
available) may also be specified.
92 IBM AS/400 Printing V
• FNTCHRSET
Font Character Set. This can only be specified when the printer file also has
DEVTYPE(*AFPDS), and is used only when printing to IPDS printers
configured with AFP=*YES. A code page must also be specified.
• CDEFNT
Coded Font. This can only be specified when the printer file also has
DEVTYPE(*AFPDS) and is used only when printing to IPDS printers
configured with AFP=*YES.
Varying font selection by field for line is normally done within an
externally-described printer file using Data Description Specifications (DDS). The
parameters previously listed are also available as DDS keywords. Unlike a
standard printer file, multiple fonts may be specified together with functions such
as BARCODE to print characters as a barcode and CHRSIZ to scale characters
(although using an outline font and varying point size is a superior method; see
4.5.2, “Why use an outline font” on page 100).
The data stream that OS/400 produces when converting and printing a spooled
file is determined by the DEVTYPE parameter in the printer file. This also has an
effect on font selection as shown in Table 6.
Table 6. Font and data stream support
Note that externally-described printer files (created using DDS) may have
multiple fonts selected for different records to be printed. A printer file created
with device type *SCS is restricted to the selected font for the entire spooled file.
Table 6 does not include device types *USERASCII or *AFPDSLINE. The
application is entirely responsible for creating the data stream in the former case.
*USERASCII simply tells OS/400 to send the data to the printer “as is”. There
might well be ASCII transparency commands to change fonts within the data. For
AFPDSLINE, fonts are normally selected in a page definition associated with the
line data.
4.2.1 Characters per inch (CPI)
The CPI parameter may be specified when the FGID is not known, or where use
of a particular fixed-pitch is more important than a font type style. This is usually
used for SCS printers.
For IPDS printers (and most SCS printers), the selected font has an implied CPI
value. For monospaced fonts, you can rely on a fixed pitch for your font. For
proportionally-spaced and typographic fonts, the characters per inch varies
DEVTYPE
parameter
Font ID Font character set Coded font
*SCS Yes No No
*IPDS Yes No No
*AFPDS Yes Yes1 Yes1
*LINE Yes Yes1 2 Yes1 2
1. Printer must be configured as *IPDS, AFP=*YES.
2. When used in a page definition applied to the line data.
Chapter 4. Fonts 93
depending on the characters in your data. However, if FONT(*CPI) is specified, a
particular monospaced font is used as shown in Table 7. If these default fonts are
not available, a printer-resident font is substituted (see 4.6, “Font substitution” on
page 101).
Table 7. CPI to font relationship
System-supplied printer files use FONT(*CPI). This ensures that the appearance
of the output is similar regardless of the printer that is used.
When you specify PAGRTT(*COR) on the printer file, the following font
substitution occurs:
• 12-pitch fonts are replaced with 15-pitch fonts (FGID 222).
• 15-pitch fonts are replaced with 20-pitch fonts (FGID 281).
• All other fonts are replaced with a 13.3 pitch font (FGID 204) with the
exception of the 4028 printer, which uses a 15-pitch font (FGID 222).
Vertical spacing (specified by the LPI parameter) is 70 percent of the normal
spacing.
4.3 Which fonts are available
Be aware that there are no 300-pel fonts supplied as a default with OS/400.
Therefore, it is usually necessary to buy some font libraries unless you rely on
using printer-resident fonts only.
Purchased font libraries are usually restored to a QFNTxx library name using the
Restore Licensed Program (RSTLICPGM) command.
4.3.1 Fonts supplied at no charge
There are two types of fonts that are supplied at no charge. These fonts are:
• AFP compatibility fonts: The QFNTCPL library is installed with OS/400.
Therefore, the product number is the same as the operating system. The
library contains the 240-pel compatibility fonts, for example Courier, Gothic,
Orator, Prestige, and Proprinter Emulation. These fonts were available on
older IBM printing devices, therefore the term “compatibility”, and are required
for Facsimile Support/400 (Fax/400). Fax/400 emulates an IPDS printer and
CPI Default font ID Name
5 245 Courier Bold Double Wide
10 011 Courier
12 087 Letter Gothic
13.3 * 204 Matrix Gothic
15 222 Gothic
16.7 400 Gothic
18 1 252 Courier
20 1 281 Gothic Text
* These values are valid only for DBCS printers
94 IBM AS/400 Printing V
uses only 240-pel fonts. They are mostly fixed-pitch fonts measured in
characters per inch (5, 8.55, 10, 12, 13.3, 15, 17.1, 18, 20, 27 cpi), but a few
are mixed-pitch characters that are approximately 12 cpi.
• 300-pel euro symbol support: Support for the euro currency symbol was
added at V4R3 for both 240-pel and 300-pel printer resolutions.
4.3.2 240-pel fonts available at a charge
The following fonts are available, but for a charge:
• 5763-FNT Advanced Function Printing Fonts/400: This product has been
largely superseded by the IBM AFP Font Collection (see Table 8) but may still
be a requirement if you specifically need one or more of the Sonoran font
families. For new customers, purchasing the AFP Font Collection is a much
better value and a preferred strategy for the reasons explained in 4.5.2, “Why
use an outline font” on page 100.
Table 8. 5763-FNT Advanced Function Printing Fonts/400
You may also notice QFNT00, which does not contain any fonts, but contains
product control information such as the message file, copyright notices, and
modification level.
• 5763-FN1 Advanced Function Printing DBCS Fonts/400: These fonts are
downloadable double-byte character set raster fonts. See Table 9 for an
overview of these fonts.
Library Feature code Family
QFNT01 5051 Sonoran Serif
QFNT02 5052 Sonoran Serif Headliner
QFNT03 5053 Sonoran Sans Serif
QFNT04 5054 Sonoran Sans Serif Headliner
QFNT05 5055 Sonoran Sans Serif Condensed
QFNT06 5056 Sonoran Sans Serif Expanded
QFNT07 5057 Monotype Garamond
QFNT08 5058 Century Schoolbook
QFNT09 5059 Pi and Specials
QFNT10 5060 ITC Souvenir
QFNT11 5061 ITC Avant Garde Gothic
QFNT12 5062 Math and Science
QFNT13 5063 DATA1
QFNT14 5064 APL2
QFNT15 5065 OCR A and OCR B
Chapter 4. Fonts 95
Table 9. 5730-FNI Advanced Function Printing DBCS fonts/400
• 5648-B45 AFP Font collection version 2: This is the latest version of the
IBM AFP Font Collection. This includes a comprehensive set of 240-pel and
300-pel fonts, and outline font character sets and coded fonts. Support for the
euro currency symbol and new languages (Thai and Lao) is also included.
4.3.3 300-pel fonts available at a charge
IBM AFP Font Collection (5648-B45) is the standard font set for the AS/400
system. This is also the consolidated AFP font product, available across all of the
major IBM system platforms. IBM AFP Font Collection consists of the Expanded
Core fonts and the Compatibility fonts. The Expanded Core Fonts include such
standard font families as Helvetica, Times New Roman, and Courier. These fonts
are provided in the 240-pel, 300-pel, and outline format. The fonts come in over
48 language groups.
An optional feature of IBM AFP Font Collection is Type Transformer and Utilities
for Windows. This is a comprehensive “workbench” for creating and customizing
fonts. The core utility provides for the conversion of any Adobe Type 1 font to an
AFP font. Since TrueType fonts can be easily converted to Adobe Type 1 format,
virtually any PC-based font can be converted to an AFP font. Additional utilities
provide for editing individual characters within a font as well as customizing font
code pages and coded fonts.
Note: Type Transformer was only available initially under OS/2. In June 2000, the
Windows version became available. This version is implemented with an
extensive graphical interface and interactive management of font upload
operations.
More information on Type Transformer and Utilities for Windows can be found in
4.11, “Creating AFP fonts with Type Transformer” on page 110.
In addition to Type Transformer and Utilities for Windows, a number of DBCS font
sets are also available as optional features of IBM AFP Font Collection.
Library Feature code Family
QFNT61 5071 Japanese
QFNT62 5072 Korean
QFNT63 5073 Traditional Chinese
QFNT64 5074 Simplified Chinese
QFNT65 5075 Thai
• At OS/400 V4R5, the IBM AFP Font Collection CD is shipped with new
orders of Print Services Facility/400 (PSF/400).
• There are several older font families, such as Sonoran, that are not part of
the IBM AFP Font Collection. These are available in the 300-pel format via
Programming Request for Price Quotation (PRPQ).
Notes
96 IBM AS/400 Printing V
4.4 How fonts are installed
Font libraries supplied on tape media are simply restored to the system by using
the RSTLICPGM command or option 11 from the LICPGM menu (GO LICPGM).
The IBM AFP Font Collection may be ordered on tape or CD-ROM media.
• Tape media: There are over forty libraries on tape media, but it is unlikely that
all will be required. Choose the appropriate libraries for your country or
language. For many customers, the most preferred ones are:
QFNTCDEPAG Expanded code pages
QFNTCFOLA1 Latin 1 outline character sets. These are the equivalent of the
IBM Core Interchange fonts, but in outline format.
QFNTCPL 240-pel Compatibility fonts. This should already be on the
system. It includes some code pages.
QFNT300CPL 300-pel versions of the Compatibility fonts.
QFNT240LA1 Latin 1 character sets, 240 pel. These may be regarded as
the equivalent of the IBM Core Interchange Font set.
QFNT300LA1 Latin 1 character sets, 300 pel. These may be regarded as
the equivalent of the IBM Core Interchange Font set.
Raster fonts such as these take up a fairly significant amount of disk space, so
only add the ones you need.
• CD-ROM media: If you order the AFP Font Collection on CD-ROM media (as
is the case if you order the optional tools such as Type Transformer), you need
to transfer the fonts to the AS/400 system in one of two ways depending on
whether your system has a CD-ROM drive installed (RISC systems only). Be
sure to order the AS/400 version labelled “Fonts for OS/400”.
To load the fonts from the system CD-ROM drive (usually named OPT01 or
similar), follow these steps:
1. Mount the CD-ROM in the drive, and make the drive ready.
2. Identify which font library you want to restore using the booklet and the
Program Directory listing. For example, the 300-pel Latin 1 font character
set is in CD-ROM library LA1300, and the suggested host library name is
QFNT300LA1.
3. Restore your selected library using the following command (or a similar
one):
RSTLIB SAVLIB(LA1300) DEV(OPT01) OPTFILE('/LA1300') RSTLIB(QFNT300LA1)
Note: If you have any trouble locating file names on the CD (for example,
because of missing documentation), use the GO OPTICAL menu to locate
them. The Work with Optical Directories (WRKOPTDIR) is the most useful
because you can determine the volume ID of the CD-ROM as well as
directories and file names from this one command.
If you do not have a system CD-ROM drive, you must manually transfer the
fonts as follows:
1. Refer to the booklet and the Program Directory listing to locate the
CD-ROM directory containing the required fonts.
Chapter 4. Fonts 97
2. Upload these fonts using PC Support/400 or Client Access/400 to a
suitable shared folder on the AS/400 system (for example, one called
“FONTS”).
3. Create a physical data file on the AS/400 system:
CRTPF FILE(MYLIB/FONTFILE) RCDLEN(8192)
TEXT('Physical file for temporarily receiving fonts') LVLCHK(*NO)
4. Move each required font to the physical file:
CPYFRMPCD FROMFLR(FONTS) TOFILE(MYLIB/FONTFILE) FROMDOC(C0H20000)
TRNTBL(*NONE) TRNFMT(*NOTEXT)
5. Create each individual font resource using the Create Font Resource
(CRTFNTRSC) command as follows:
CRTFNTRSC FNTRSC(QFNT300LA1/C0H40000) FILE(MYLIB/FONTFILE)
TEXT('Helvetica 10-point Bold')
The last two steps can be automated with CL coding. Otherwise, they must be
repeated for each and every font resource.
4.4.1 Making the fonts available
Printer writer jobs need to find the requested fonts. This applies to interactive and
batch jobs and for spooled files sent from other systems. The preferred way to do
this is to specify the required libraries in the PSF configuration object assigned to
the printer device description (see 4.9, “Using a resource library list” on page
107).
An alternative method is to add the required libraries to the system library list or
the user library list. These are held as system values. You can view or change
these system values using the following commands:
WRKSYVAL QSYSLIBL
WRKSYSVAL QUSRLIBL
Another alternative method of accessing the font resources is to store them in
any of the special font libraries (QFNT01 to QFNT19), assuming that they no
longer exist. These are normally reserved for other chargeable font character
sets, that is, AS/400 font licensed program products (see 4.3.2, “240-pel fonts
available at a charge” on page 94). Since 300-pel and 600-pel printers have
become the standard, there is much less likelihood that these older 240-pel fonts
are needed.
These particular libraries are appended to the system portion of the user’s library
list when a print job is submitted interactively. They are a useful means of
ensuring that the required fonts are always available. They do not show up in a
display of the user’s library list. For batch jobs, ensure that the font libraries are in
the job’s library list.
Some print enabling applications, such as AFP Utilities (5769-AF1) or
Advanced Print Utility (APU, 5798-AF3), need access to those font libraries
when a new overlay or APU print definition is being developed. You could add
the font libraries before calling the utility menu using the EDTLIBL or
ADDLIBLE commands.
Note
98 IBM AS/400 Printing V
There is a no-charge utility available to assist in loading your IBM AFP Font
Collection (5648-B45) fonts in the special (QFNT01 to QFNT19) libraries. It can
be found by clicking Downloads at the AS/400 printing Web site at:
http://www.ibm.com/printers/as400
You need to download the file from the Web to your PC and then use FTP to
upload to your AS/400 system. This package includes two AS/400 commands to
help you load and print sample fonts from the IBM AFP Font Collection (5648-113
or 5648-B45) software.
• LOADFNTC: Load Font Collection
• PRTFNTC: Print Font Collection Samples
Both commands provide help text describing each command’s parameter.
All font objects will be restored in 10 libraries on your system as shown in Table
10.
Table 10. Restored font objects
Failure to add font libraries before submitting a print job is a common problem.
The symptoms are usually a PQTxxx error message in the QSYSOPR message
log and a message similar to the following example:
Character set C0A05580 could not be found or has a pel density (resolution)
incompatible with the device.
In this case, the message is indicating either that the character set is not present
on the system, or that an object of that name exists but at the wrong pel density
for the device. To correct the problem, add the library in which the object is
located to the library list, or change the printer file/DDS to explicitly reference the
object/library combination. The latter may be preferable for performance reasons.
The operating system does not have to search through many objects in many
libraries to locate the required resource.
Note: The previous example illustrates that if one has both 240- and 300-pel
versions of a character set, they have the same object name and must, therefore,
be stored in separate libraries. See Figure 75 for an example.
Description AS/400 library
AFP Font Collection Code Pages QFNT01
AFP Font Collection Compatibility Coded Fonts QFNT02
AFP Font Collection 240-pel Compatibility Fonts QFNT02
AFP Font Collection 300-pel Compatibility Fonts QFNT03
AFP Font Collection 240-pel Fonts QFNT04
AFP Font Collection 300-pel Fonts QFNT05
AFP Font Collection Outline Fonts QFNT06
AFP Font Collection Coded Fonts QFNT07
AFP Font Collection Coded Fonts (4 chars) QFNT08
AFP Font Collection Outline Coded Fonts QFNT09
AFP Font Collection Outline Codes Fonts (4 chars) QFNT10
Chapter 4. Fonts 99
Figure 75. Fonts with the same object name, different libraries
One of the tasks the PSF/400 printer writer job performs is to determine the
printer resolution. Therefore, in the preceding example, only the second
C0N20000 font resource object is selected for printing to a 300-pel printer even if
the QFNT240LA1 library was higher in the library list.
4.5 Outline fonts
Traditionally, fonts are stored as raster fonts. Each font is stored as a bit pattern
(bitmap) for each and every character in a character set and once for every size
and weight/posture (medium, bold, italic, bold italic). The bitmapped font is
resolution-specific, so these large storage requirements are repeated for fonts of
different pel densities. For host-resident raster fonts, there is a delay in printing
while the raster sets are downloaded to the printer.
An outline font is an alternative means of storing a font. Each character is stored
only once for each weight or posture. The stored outline font is defined using
vector mathematics to describe its shape. This means the font may be drawn by
the printer at a wide range of point sizes (1 to 999 points). Outline fonts may also
be referred to as scalable or vector fonts (Figure 76).
Figure 76. Representation of a raster font and an outline font
Previously, AFP outline fonts were only found as printer-resident fonts. Now
products, such as the AFP Font Collection, contain host-resident AFP outline
Work with Objects
Type options, press Enter.
2=Edit authority 3=Copy 4=Delete 5=Display authority 7=Rename
8=Display description 13=Change description
Opt Object Type Library Attribute Text
C0N20000 *FNTRSC QFNT240LA1 FNTCHRSET Latin1-Times New Roman-Roman
C0N20000 *FNTRSC QFNT300LA1 FNTCHRSET TIMES NEW ROMAN LATIN 1-ROMAN
Parameters for options 5, 7 and 13 or command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F11=Display names and types
F12=Cancel F16=Repeat position to F17=Position to F24=More keys
100 IBM AS/400 Printing V
fonts and tools, such as the OS/2 Type Transformer can produce AFP outlines
from Adobe Type 1 PC fonts.
4.5.1 Downloading host-resident outline fonts
Version 3.0 Release 2.0 and Version 3.0 Release 7.0 introduced limited support
(through program temporary fixes (PTFs)) for downloading AFP outline fonts by
PSF/400. This was restricted to certain coded fonts in the IBM AFP Font
Collection product. At Version 4.0 Release 2.0, scaling information for
downloaded outline fonts is added in the printer file and in DDS. This is similar to
the current point size parameter on the FONT keyword, except that the range is
from 0.1 to 999 points.
A printer that supports outline font download is required, such as an IBM AFCCU
printer. Although printers, such as IBM Network Printers, use resident outline
fonts, they cannot receive downloaded outline fonts.
4.5.2 Why use an outline font
Outline fonts are extremely efficient in performance terms. One outline font can
replace a range of raster font point sizes, thereby reducing font download time,
the number of raster fonts that must be kept at the host, and the font storage
requirements at the printer. They are also easy to specify (for example, an
18-point host-resident font) to be downloaded. Consider this example:
OVRPRTF FILE(QSYSPRT) DEVTYPE(*AFPDS) FNTCHRSET(MYLIB/CZH200 T1V10285 18.0)
You can also specify the same printer-resident font to be invoked at the printer:
OVRPRTF FILE(QSYSPRT) FONT(2304 18.0)
Note: You do not need to specify the data-stream device type to use a
printer-resident font.
Outline fonts are resolution-independent. Therefore, as printers become capable
of printing at higher resolutions, the application investment in using outline fonts
is maintained. Because it is the device that rasterizes the outline font sent to it,
you can use the same AFP outline font sent to a printer (at 240, 300, or 600 dpi)
or sent to a display at various resolutions. The fonts may be placed in a single
library because they no longer have a resolution attribute.
Migrating existing raster fonts may be achieved either by obtaining the equivalent
IBM AFP outline font or purchasing an equivalent Type 1 scalable font
(PC-based) from a font vendor and converting it to an AFP outline font using IBM
Type Transformer. If the application uses older font families such as Sonoran
Serif or Sonoran Sans Serif, these are similar to Times New Roman and
Helvetica, but they are not identical. The reason for this is that the Sonoran fonts
and other fonts were hand-tuned for best quality on 240-pel printers and cannot
be converted to outline font technology. This is why IBM recommends the
adoption of the strategic Expanded Core fonts (Times New Roman, Helvetica,
and others). These fonts are available as host raster and outline fonts, and
commonly as printer-resident outline fonts. This is particularly the case for new
applications. Note that Helvetica is an equivalent of Arial, widely used in PC
applications.
A practical example for using outline fonts is to print large characters (for
example, at 720-point (approximately 10 inches high)) in retail store applications
Chapter 4. Fonts 101
or on packing carton delivery slips. Prior to using outline fonts, the two principle
means of printing large characters were to use graphic symbols sets or scale
printer-resident fonts using the CHRSIZ DDS keyword. For a discussion of the
pros and cons of using these methods, see A.4.1, “Using GDDM fonts” on page
283. For details of their use, please refer to AS/400 Printing III, GG24-4028. Note
that CHRSIZ is not supported on newer printers, such as the IBM AFCCU
printers, because of the trend towards outline fonts.
4.5.3 Scalable fonts for MULTIUP and COR
When the applicable PTF is applied and the QPRTVALS data area is set up as
described in 10.5.4, “Using the QPRTVALS data area” on page 217, the AS/400
system will always select a scalable font for printing with MULTIUP or COR
(multiple-up and Computer Output Reduction) or when the spooled file attributes
specify FONT(*CPI). This only applies for IBM AFCCU printers.
If the font identifier in the printer device description is between 300 and 511
(inclusive), this font is selected and scaled to an appropriate point size. If the font
in the device description is not between 300 and 511, the AS/400 system uses
font 304. Font 304 is a scalable Gothic font that is supported by these printers for
almost all single-byte character set (SBCS) code pages except Arabic, Cyrillic
Greek, Hebrew, Latin 2/3/4/5, and Symbols.
Another recommended font is 416, a scalable Courier Roman font that is
supported for almost all SBCS code pages except Japanese Katakana.
To activate this function, ensure the printer writer is ended and then type:
CHGDTAARA DTAARA(QUSRSYS/QPRTVALS (6 1)) VALUE('Y')
This places the character Y in the sixth byte of the QPRTVALS data area. To
change the default to something other than 304, enter:
CHGDEVPRT DEVD(printername) FONT(416 12.0)
See Table 11 for information on PTF support for scalable fonts with MULTIUP and
COR.
Table 11. PTF support for scalable fonts with MULTIUP and COR
4.6 Font substitution
PSF/400 uses font substitution tables to perform font substitution. Font
substitution may also be referred to as font mapping and takes one of the
following forms:
Version/release PTF
V3R1 SF43120
V3R2 SF43431
V3R6 SF42712
V3R7 SF44664
V4R1 and above Base operating system
102 IBM AS/400 Printing V
• Font ID to Font ID:
This occurs when the requested font is not available on the printer but a
similar one is available. This is printer-resident to printer-resident font
substitution, which is the most common type of substitution.
• Font ID to Font Character Set:
This occurs when the target printer has no resident fonts, or when resident
fonts are disabled by the Create/Change Print Services Facility Configuration
(CRTPSFCFG/CHGPSFCFG) command or an equivalent WRKAFP2
command. See 4.8, “Disabling resident font support” on page 106, for details
of disabling printer-resident fonts.
One reason for there being no printer-resident fonts might be when the device
is actually a process emulating a printer (for example, Facsimile Support/400
or the Distributed Print Facility (DPF) of Print Services Facility/2 (PSF/2)).
Some older IBM printers also did not have resident fonts (for example, the
3900-1, 3825, and 3835).
• Font Character Set to Font ID:
This substitution of a host-resident font for a requested printer-resident font
occurs only when one of the following situations is true:
– The host font character set was not found and the printer supports resident
fonts.
– The printer does not accept downloaded fonts (most impact printers).
Reasons for not finding the host font character set include: not authorized to
use that font, the font was not in the user's library list, or the font exists, but at
a different resolution than that of the printer.
Note: A code page may be substituted in the same way as a font character set
with the exception that a code page is resolution-independent. Therefore, this
does not give rise to a substitution.
The particular fonts substituted in the previous cases are documented in
Appendix D of AS/400 Printer Device Programming. OfficeVision/400 has its own
table of substituted fonts, which is documented in Setting Up Printing in an
OfficeVision/400 Environment, SH21-0511.
4.6.1 Suppressing font substitution messages
Normally font substitution is logged in the job log, and a message, such as the
following example, is sent to the message queue defined in the printer device
description (usually QSYSOPR):
PQT2072 Font substitution was performed
At Version 4.0 Release 2.0, these messages may be suppressed, if desired,
using the FNTSUBMSG keyword on the CRTLPSFCFG or CHGPSFCFG
command. The default is *YES to continue generating these messages as at
present. Otherwise, you can block the messages as follows:
CHGPSFCFG PSFCFG(NP17) FNTSUBMSG(*NO)
Messages indicating that font substitution failed are not blocked.
Chapter 4. Fonts 103
4.7 Font table customization
Until recently, customers had to accept the system's internal font mapping. In
addition, the use of applications, such as OfficeVision/400 (where only font IDs
are specified), restricted the customer's choice of fonts.
Version 3.0 Release 7.0 introduced the ability to create your own font mapping
tables. These are searched before the existing system tables. This facility applies
only to AFP printers, and PSF/400 is required. Tables may be created to control
any or all of the following examples:
• Host-resident font character set to printer-resident font ID mapping
• Printer-resident font ID to host-resident font character set mapping
• Host-resident to printer-resident code page mapping
• Printer-resident to host-resident code page mapping
Since there are several commands associated with font table customization, type
the following command:
GO CMDFNTTBL
The display appears as shown in Figure 77.
Figure 77. Work with Font Tables menu on a V3R7 system
4.7.1 Creating the font tables
It is first necessary to create one or more font tables, and then add, alter, or
delete entries from them. Only one of each of the four font substitution cases
previously described may be created using the Create Font Table (CRTFNTTBL)
command. They are assigned a system-supplied name as follows:
*PHFCS Printer to Host-resident Font Character Set
This creates a table named QPHFCS in the QUSRSYS library,
object type *FNTTBL.
CMDFNTTBL Work with Font Tables
Select one of the following:
Commands
1. Add Font Table Entry ADDFNTTBLE
2. Change Font Table Entry CHGFNTTBLE
3. Create Font Table CRTFNTTBL
4. Delete Font Table DLTFNTTBL
5. Display Font Table DSPFNTTBL
6. Remove Font Table Entry RMVFNTTBLE
Related Command Menus
7. AFP Commands CMDAFP
8. Font Resource Commands CMDFNTRSC
9. PSF Configuration Commands CMDPSFCFG
Bottom
Selection or command
===>
F3=Exit F4=Prompt F9=Retrieve F12=Cancel F16=Major menu
(C) COPYRIGHT IBM CORP. 1980, 1996.
104 IBM AS/400 Printing V
*PHCP Printer to Host-resident Code Page
This creates a table named QPHCP in the QUSRSYS library,
object type *FNTTBL.
*HPFCS Host to Printer-resident Font Character Set
This creates a table named QHPFCS in the QUSRSYS library,
object type *FNTTBL.
*HPCP Host to Printer-resident Code Page
This creates a table named QHPCP in the QUSRSYS library,
object type *FNTTBL.
4.7.2 Adding a font table entry
As an example, if you want to use a host-resident font with OfficeVision/400, you
must either use a printer that does not support resident fonts (these tend to be
larger system printers such as the 3820 and 3835) or switch off printer-resident
font support using the CHGPSFCFG command (WRKAFP2 command at Version
3.0 Release 1.0 and Version 3.0 Release 6.0). Your specified font ID is then
substituted to a host-resident font according to the font tables documented in
Section D.5 of AS/400 Printer Device Programming. This may not be an exact
substitution (the table identifies these exceptions), or you may want to use a
custom-supplied host font. To do this, you need to add an entry to the QPHFCS
font table.
Suppose you are using FGID 75 (Courier 12 cpi) in your OfficeVision/400
documents. This is normally substituted to C0S0CR12, which is not an exact
match. If you have the Core Interchange Fonts installed on your system, you can
substitute C04200B0 instead as shown in Figure 78.
Figure 78. Adding a different printer-resident to host-resident font substitution
Note: The WIDTH keyword in the previous command refers to the characters per
inch value (12 in our example) divided into 1440. These values for the common
Add Font Table Entry (ADDFNTTBLE)
Type choices, press Enter.
Font table . . . . . . . . . . . > *PHFCS *PHFCS, *HPFCS, *PHCP, *HPCP
Printer to host font:
Printer font:
Identifier . . . . . . . . . . > 75 1-65535
Width . . . . . . . . . . . . > 120 1-32767, *NONE, *PTSIZE
Attributes . . . . . . . . . . *NONE *NONE, *BOLD, *ITALIC...
Graphic character set . . . . *SYSVAL Number, *SYSVAL
Point size . . . . . . . . . . *WIDTH 1.0-999.9, *WIDTH, *NONE
Host font:
Font character set . . . . . . > C04200B0 Name
Type . . . . . . . . . . . . . *RASTER *RASTER, *OUTLINE
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Chapter 4. Fonts 105
cpi sizes (10, 12, 15, etc.) may be listed on the printer IPDS font listing (see the
example in Figure 74 on page 90).
You must also ensure that any writers to printers configured as *IPDS, AFP=*YES
are ended before attempting to change the font tables. Otherwise, you receive
messages similar to:
Cannot allocate object QPHFCS in library QUSRSYS
Font table QPHFCS in library QUSRSYS not changed
If this occurs, use the following command to locate which writers are still active:
WRKOBJLCK OBJ(QUSRSYS/QPHFCS) OBJTYPE(*FNTTBL)
You can then determine whether to end the writers immediately, or defer the font
table changes to a later time. Successful addition of the font table is reported by:
Font table entry added to font table QPHFCS
This may be checked using the DSPFNTTBL command, which causes the
following display, as shown in Figure 79, to appear.
Figure 79. Displaying entries in a customized font table
A final point to note in the case of OfficeVision/400 is that you are probably still
restricted to monospaced (fixed-pitch) host-resident fonts because the alignment
of tabs and columns is incorrect if typographic fonts (variable-spaced) are used.
4.7.3 Other font table commands
The remaining commands are self-explanatory:
• Change Font Table Entry
• Delete Font Table
• Remove Font Table Entry
Display Font Table
Font Table . : QPHFCS
Text . . . . : Printer to host-resident mapping table
Printer Graphic Host
Font Character Point Font
Identifier Width Attribute Set size Character Type
75 120 *NONE 1269 *WIDTH C04200B0 *RASTER
Bottom
Press Enter to continue.
F3=Exit F12=Cancel
106 IBM AS/400 Printing V
4.7.4 Customer-defined font ranges
If your operating system is prior to Version 3.0 Release 7.0, there is an alternative
method to customizing font tables. This uses a new function added to Version 3.0
Release 1.0 and upwards through PTFs for customer-defined printer-resident
fonts. This works as explained here:
1. Disable the printer's resident font support as described in 4.8, “Disabling
resident font support” on page 106.
2. Identify up to five host-resident font character sets that you want to use.
3. Rename these to C0USERF1 through C0USERF5 using the Rename Object
(RNMOBJ) command.
4. Specify any or all of the font IDs, 65501 to 65505, in your application. These
are mapped to the character sets in the range C0USERF1 to C0USERF5.
One use of this feature might be in OfficeVision/400 where you have a
host-resident font that is actually a barcode set or a signature. You can use the
preceding procedure to refer to it by a font ID.
This support is enabled by the PTFs shown in Table 12.
Table 12. PTF details for customer-defined font ranges
4.8 Disabling resident font support
You must disable resident font support on the printer. Otherwise, normal font
substitution will occur (printer-resident font to printer-resident font, as described
in 4.6, “Font substitution” on page 101). To do this, follow these steps:
1. Ensure the printer writer is ended:
ENDWTR PRTNP17 *IMMED
2. Use the WRKAFP2 command (V3R1 and V3R6) to display or print the current
status of the data area created by WRKAFP2:
WRKAFP2 DEVD(PRTNP17) PRINTONLY(*YES)
Re-running the command resets all parameters to their default value unless
you explicitly re-define them again.
3. Issue the WRKAFP2 command with the Disable Resident Fonts keyword
enabled plus any special settings you may have already:
WRKAFP2 DEVD(PRTNP17) DRF(*YES)...
4. For V3R2, V3R7, and later, use the CRTPSFCFG or CHGPSFCFG commands
instead of WRKAFP2. These may be changed without affecting other settings:
CHGPSFCFG PSFCFG(PRTNP17) RESFONT(*NO)
Version/Release APAR PTF Cum-pak
V3R1 SA54431 SF31920 6198
V3R2 SA54431 SF32128 6233
V3R6 SF55079 SF39367 -
V3R7 and later Base operating system
Chapter 4. Fonts 107
Note that the earlier WRKAFP2 command uses the syntax “disable resident
fonts?”. The CHGSFCFG command asks: “resident font support?”. Therefore, the
yes or no response is different.
4.9 Using a resource library list
A PSF configuration object allows you to specify which particular libraries are
searched for AFP resources (including fonts). This might be for reasons of:
• Security: Can restrict libraries searched.
• Performance: Searching fewer libraries is faster
• Device resolution issues: AFP resources created at different pel densities
can be placed in appropriate libraries. For example, there is no point in
searching 240-pel font libraries when using a 300-pel printer.
The PSFCFG object may define a user resource library, a device resource library,
or both. The former is searched first, but may have *NONE specified, which
means that only the device resource library is searched.
The relevant keywords are User Resource Library (USRRSCLIBL) and Device
Resource Library (DEVRSCLIBL).
Figure 80. Part of a CHGPSFCFG command
The example in Figure 80 shows how the command might be used with a printer
that only supports 300-pel fonts from the AS/400 system. The user resource
library is set to *JOBLIBL, meaning the job's current library list is searched for
any AFP resources referenced. The device resource library list names three
libraries, the first two containing 300-pel fonts, and the last library possibly
containing AFP resources in 300-pel format and unique to that printer.
Change PSF Configuration (CHGPSFCFG)
Type choices, press Enter.
PSF configuration . . . . . . . PSFCFG > NP17
Library . . . . . . . . . . . > QGPL
User resource library list . . . USRRSCLIBL *JOBLIBL
Device resource library list . . DEVRSCLIBL > QFNT300CPL
> QFNT300LA1
+ for more values > AFPRSCLIB
IPDS pass through . . . . . . . IPDSPASTHR *NO
Activate release timer . . . . . ACTRLSTMR *NORDYF
Release timer . . . . . . . . . RLSTMR *NOMAX
Restart timer . . . . . . . . . RESTRTMR *IMMED
SNA retry count . . . . . . . . RETRY 2
Delay time between SNA retries RETRYDLY 0
Text 'description' . . . . . . . TEXT > 'PSFCFG object for IBM Networ
Printer 17'
More..
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
108 IBM AS/400 Printing V
If all the resources used for the print jobs are contained in a few libraries,
consider setting USRRSCLIBL to *NONE so only the device resource library is
searched.
The PSF configuration object could be specified in one or multiple printer device
descriptions, as shown in Figure 81.
Figure 81. Change Device Desc (Printer) (CHGDEVPRT)
4.10 Font capturing
PSF/400 can download fonts to certain IPDS printers when they are configured
as *IPDS, AFP=*YES in their device description. Since Version 3.0 Release 1.0,
these fonts are stored across job boundaries on the basis that the next job is
likely to use them. This is known as font caching. Once the PSF/400 writer is
ended, all AFP resources in the printer (including fonts) are deleted.
With Version 4.0 Release 2.0, a printer can hold these fonts after the writer is
ended, if so desired. This also applies if the printer is subsequently powered off.
Printing performance is improved because the fonts no longer need to be
downloaded. This is especially beneficial to users of double-byte fonts because
these fonts are large in size. This process is known as font capturing.
Two steps are necessary to implement font capturing:
1. Mark the desired font resources as eligible for capture.
2. Define the printer to be capable of font capturing.
4.10.1 Font resources eligible for capture
Not all fonts contain the necessary information in the internal structured fields to
permit them to be uniquely identified. If fonts have this information, they are said
to be marked. Examples of tools that can mark fonts are APSRMARK (contained
within PSF/MVS) and Type Transformer (available as an option within the IBM
Font Collection). Version 4.0 Release 2.0 of OS/400 also has this function.
Change Device Desc (Printer) (CHGDEVPRT)
Type choices, press Enter.
User-defined object:
Object . . . . . . . . . . . . > NP17 Name, *SAME, *NONE
Library . . . . . . . . . . > QGPL Name, *LIBL, *CURLIB
Object type . . . . . . . . . > *PSFCFG *DTAARA, *DTAQ, *FILE...
Data transform program . . . . . *NONE Name, *SAME, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
User-defined driver program . . *NONE Name, *SAME, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Text 'description' . . . . . . . '9.28.252.110'
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 4. Fonts 109
However, if the font does not have the required structured fields present, these
tools have no effect.
Details of the fonts that may be captured are:
• Outline Fonts (single and double-byte):
These include AFP outline fonts shipped with the IBM AFP Font Collection
and are already marked. If Type Transformer is used to create new outline
fonts, the option to mark them is user-selectable.
• Raster Fonts (single byte)
Some of the newer fonts in the IBM Font Collection are marked. Earlier fonts
may not be marked if they do not contain the necessary information as
described above. If the user attempts to mark these fonts, a warning message
is issued.
• Raster Fonts (double-byte):
These fonts contain the necessary information to enable them to be marked.
Note: A raster font is actually built from two font resources: the font character
set and the code page. Therefore, both of these resources must be marked if
they are to be eligible for capture.
4.10.2 Marking a font resource
An OS/400 font resource may be a font character set, code page, or coded font.
These are OS/400 objects with the attribute of FNTCHRSET, CDEPAG, or
CDEFNT. Note that a coded font cannot be marked for capture. Use the
WRKFNTRSC command to quickly locate font resources on your system and
DSPFNTRSCA to identify whether they have been marked (FNTCAPTURE
*YES). Displaying the font attributes also tells you the pel density of the font
character set as shown in Figure 82.
Figure 82. Displaying attributes of a font resource on a V4R2 system
Remember that FNTCAPTURE *YES means that the font is eligible for capture,
not that it has been captured by the printer.
When creating OS/400 font resources from resources sent from other systems,
use the CRTFNTRSC command. This command and the new CHGFNTRSC
command now allow a user to mark the font as eligible for capture. This is done
by entering the following command:
Display Font Resource Attributes
System: ALICEH02
Font Resource . . . . . . . . . . . : C0H200A0
Library . . . . . . . . . . . . . : QFNT300LA1
Object attribute . . . . . . . . . . : FNTCHRSET
Pel Density . . . . . . . . . . . . : 300
Font Capture . . . . . . . . . . . . : *YES
Date . . . . . . . . . . . . . . . . : 12/16/94
Time . . . . . . . . . . . . . . . . : 00:00:00.00
Text . . . . . . . . . . . . . . . . : HELVETICA LATIN1-ROMAN MED 11-PT
Press Enter to continue.
F3=Exit F12=Cancel
110 IBM AS/400 Printing V
CHGFNTRSC FNTRSC(QFNTCPL/C0D0GT13) FNTCAPTURE(*YES)
This causes the current date and time stamp to be added to the font, which is
what PSF/400 uses to track whether the font in the printer is truly the same as the
one being referenced in the spooled file (just having the same object and library
name is not enough). The default for FNTCAPTURE is *NO.
The CRTFNTRSC command has an additional keyword *FILE. This tells PSF/400
to use the font capture information stored within the font. If no information is
found, then *NO is assumed. This allows users to mark fonts on other systems
(for example, using APSRMARK) and then send them for use on the AS/400
system.
4.10.3 Defining the printer for font capture
In addition to defining the font resources, the user must define the printer as
being capable of font capturing. This is done by modifying the printer's PSF
Configuration Object. The keyword is FNTCAPTURE and the options are *YES or
*NO. This permits the user to selectively define which printers will support font
capturing.
At the time this redbook was written, only the IBM AFCCU printers are capable of
using the font capture facility.
4.10.4 Considerations for font capture
Note: You must be authorized to use a font resource, regardless of whether it has
been captured in the printer. This is because some fonts might be security
sensitive (for example, a Magnetic Ink Character Recognition (MICR) font used
for printing checks or a font representing someone's signature). Therefore,
exercise caution when marking such fonts, because many printers today can be
accessed from more than one system.
Captured fonts remain in the printer indefinitely unless overwritten by later font
capture instructions. The host printer writer cannot alter this condition.
If a concern exists about font resources from user libraries being captured and
“polluting” the printer font resources, there are several actions you can take to
guard against this:
• Change the USRRSCLIBL parameter in the PSFCFG object to *NONE. This
means that user libraries are not searched for resources.
• Run the CHGFNTRSC command against any fonts in user libraries specifying
FNTCAPTURE(*NO).
• Suppress font capturing altogether by setting FNTCAPTURE to *NO in the
PSFCFG object.
4.11 Creating AFP fonts with Type Transformer
Type Transformer is a Windows-based PC tool that can be used to create AFP
fonts for the AS/400 system. All the source Type 1 fonts used to build the AFP
Font collection are supplied or you can use your own Type 1 fonts. Here is an
example of building single-byte fonts and moving them to the AS/400 host.
Chapter 4. Fonts 111
A single byte AFP font can be created in five steps:
1. Select the Output Font resolution. Valid options are any combination of AFP
Outline, 240-pel raster, and 300-pel raster. In the following example, AFP
Outline and 300-pel raster fonts are created.
2. Select the icon to choose the Type 1 (Typefaces) to be converted to AFP
Fonts (Figure 83). Any directory that has valid Adobe Type 1 outline fonts
(*.pfb extension) will have its typeface displayed. You can create Adobe Type 1
outline fonts from TrueType fonts with the FontLab editor supplied in this
package.
Figure 83. Type Transformer: T1 icon selection
Highlight the typefaces, and click OK. You can choose one or several
typefaces to convert as long as the *.pfb files reside in the same directory
(Figure 84 on page 112).
112 IBM AS/400 Printing V
Figure 84. Selecting multiple typefaces
3. If you are creating raster fonts or coded fonts, select the icon to choose the
point sizes to be used (Figure 85).
Figure 85. Selecting a point size
You can select one or multiple point sizes by highlighting the point sizes to be
used and clicking Add (Figure 86). There is an option to create fractional point
sizes. If you choose this option, you are required to complete the character set
name or the coded font name. More information is provided in the Type
Transformer User’s Guide that comes online with this product.
Chapter 4. Fonts 113
Figure 86. Choosing multiple point sizes
4. Choose a filter by clicking the icon to reduce unnecessary characters
(Figure 87). This is an optional step, but it may help keep the size of the AFP
font to a minimum. More information on character lists can be found in the
Type Transformer User’s Guide.
Figure 87. Choosing a filter
Select the character list, and click Open (Figure 88 on page 114).
114 IBM AS/400 Printing V
Figure 88. Select Character Lists
5. Start the job by clicking the icon (Figure 89).
Figure 89. Starting the job
Give the job a name (up to eight characters) and a description. Select the type
of reports to generate, and click Transform (Figure 90).
Chapter 4. Fonts 115
Figure 90. Start Job
There are several additional options that you can use to customize the AFP
output fonts:
• You can define coded fonts using the icon.
• You can rename the coded fonts using the icon.
• You can customize output typeface names using the icon.
• You can customize character set font names using the icon.
Once the font conversion job is complete, store the fonts on the AS/400 system
using the icon (Figure 91).
Figure 91. Storing converted fonts
You can select the output fonts to store from the window shown in Figure 92 on
page 116. Choose the platform, highlight the font objects to store, and click
Store.
116 IBM AS/400 Printing V
Figure 92. Select store destination
Personal Communications V4.3 (or higher) or Client Access/400 and Object Rexx
for Windows is required to use this store function.
Select the session ID where your AS/400 system is logged on. Provide the
system name, select the output libraries, and provide a user ID and a password.
Type Transformer stores the font resources on your AS/400 host (Figure 93).
Figure 93. Storing fonts on the AS/400 host
© Copyright IBM Corp. 2000 117
Chapter 5. The IBM AFP Printer Driver
The IBM Advanced Function Presentation Printer (AFP) Driver is a printer driver
used to produce AFP output from PC applications. This means it can be used for
printing PC documents on high-speed AFP system printers, produce electronic
forms using your favorite PC application, and even create signatures and logos
from existing or newly-scanned sources. The driver is included with Client
Access/400 or may be downloaded from the World Wide Web free of charge.
5.1 Overview
The AFP Printer Driver is supported in the following environments:
• Windows 3.1
• Windows for Workgroups 3.11
• WIN OS/2
• Windows 95
• Windows 98
• Windows 2000
• Windows NT
The AFP drivers are similar to standard PC drivers in that they are small in size,
fit on a standard diskette, and are installed in the normal manner (for example,
through the Windows Control Panel). They differ from normal printer drivers in
that the output is Advanced Function Presentation Data Stream (AFPDS) instead
of the more usual Printer Control Language (PCL), Personal Printer Data Stream
(PPDS), PostScript, and others. You “print” the output to a port or file the same as
any Windows printer drivers.
5.1.1 Why use the AFP Printer Driver
The AFP Printer Driver offers a variety of functions to optimize your output:
• Overlays: Creating overlays (electronic forms) with the AFP Printer Driver
means you can use your existing PC application to design a form and are
limited only by the capabilities of that application. You can use advanced
desktop processing features, such as curved boxes and shading together with
basic functions such as text alignment and spell checking. Company
letterhead, terms and conditions, or an invoice layout are common examples.
• Page segments: If you already have your company or client's logos in PC
format, you can include these in overlays, or perhaps create them as a
separate AFP resource called a page segment. Signatures are another
candidate. Captured at a PC-attached scanner, they can be imported into a
PC application and then “printed” as an AFP page segment. Individual page
segments representing user's signatures can then be printed along with the
letterhead overlay.
• AFP documents: Using the AFP Printer Driver with Client Access/400
network printing, you can send your PC documents for printing on a
high-speed AS/400 AFP system printer instead of overloading your desktop
PC printer.
118 IBM AS/400 Printing V
5.2 Installing the AFP Printer Driver
The following instructions use Client Access/400 for Windows 95/NT V3R1M2 as
an example. They assume that Client Access/400 is already installed without the
AFP Printer Driver installed.
1. This procedure requires that you re-boot your PC. End all other applications
before beginning this process.
2. Open the Client Access folder and then the Accessories folder.
3. Double-click the Selective Setup icon.
4. At the Install Client Access - Component Selection window, select the Printer
drivers checkbox (Figure 94), and click Change.
Figure 94. Client Access/400 Component Selection display
5. Select the AFP printer driver (Figure 95).
Figure 95. Installing the Client Access/400 printer drivers
Chapter 5. The IBM AFP Printer Driver 119
6. Click Continue.
7. Click Next.
8. When you are satisfied with the settings, click Next. The installation begins,
taking a few moments to load the driver.
9. At this point, you may choose to view the README.TXT file.
10.Select the option to re-boot your PC at this time.
11.When your PC has restarted, a Welcome to Client Access window is
displayed. Close this window, and open the Printers folder.
12.Click Add Printer.
13.Select the Local printer radio button (Figure 96).
Figure 96. Selecting a local printer driver
14.At the Manufacturer and Printer window, select IBM and an AFP driver that is
appropriate for your environment (Figure 97).
Figure 97. Manufacturer and printer window
120 IBM AS/400 Printing V
The available drivers and their uses are:
• IBM AFP 144: Generic AFP driver for impact printers.
Use this driver for creating AFPDS output at approximately 144 dpi. This is
used only for printing to IPDS impact printers such as certain IBM 6400,
4247, and 4230 models.
• IBM AFP 600: Generic AFP driver for any IPDS laser printer at 300 or 600
dpi.
• IBM AFP 3160: Creates 240-pel output for the 3160 Model 1 printer.
• IBM AFP 240 (Microsoft): Generic 240 dpi AFP driver for 32-bit Windows
systems (Windows 95).
• IBM AFP 240 (Windows 3.x drivers): Generic 240 dpi AFP driver for
16-bit Windows systems such as Windows 3.1, Windows for Workgroups,
and WIN-OS/2.
• IBM AFP 300 (Microsoft): Generic 300 dpi AFP driver for 32-bit Windows
systems (Windows 95).
• IBM AFP 300 (Windows 3.x drivers): Generic 300 dpi AFP driver for
16-bit Windows systems such as Windows 3.1, Windows for Workgroups,
and WIN-OS/2.
• IBM AFP xxxx (Microsoft): Printer-specific AFP driver for 32-bit Windows
systems (Windows 95).
• IBM AFP xxxx (Windows 3.x drivers): Printer-specific AFP driver for
16-bit Windows systems such as Windows 3.1, Windows for Workgroups,
and WIN-OS/2.
• IBM AFP Facsimile Support/400: Specific driver for use with Facsimile
Support/400.
This AFP driver is used for faxing PC documents with the Facsimile
Support/400 program product. It has support for Image only.
• IBM AFP WPM/2: Specific driver for ImagePlus Workstation Program/2.
This AFP driver is used for producing AFP output from the IWPM/2 product.
It also has support for Image only.
You can install more than one AFP print driver just as you can install multiple
printer drivers for one physical printer (for example, PCL and Postscript
drivers).
15.The next window shows a list of the ports on your PC. Select FILE (Figure 98)
for creating overlays and page segments or a printer port to print documents.
Chapter 5. The IBM AFP Printer Driver 121
Figure 98. Connecting the printer driver to a port
16.Leave the next window with the defaults for printer name and “no” for the
default Windows printer.
17.Change the invitation to print a test page to No.
18.Click Finish. Then a new printer icon is created (Figure 99).
Figure 99. Completed Add Printer process
The driver is now ready for use with your PC applications. To learn how to do this,
refer to 5.3, “Creating an overlay” on page 122, or 5.4, “Creating a page segment”
on page 126.
5.2.1 Installation from the World Wide Web
The latest version of the AFP Printer Driver may be obtained from the World Wide
Web at: http://www.printers.ibm.com/afpdr.html
However, only the version supplied with the IBM program products are licensed
and, therefore, supported by IBM. Copies of the driver from the Web are supplied
“as is”.
122 IBM AS/400 Printing V
To add the AFP Printer Driver, download the installation program to a convenient
directory (C:\TEMP, for example). Then perform the following steps:
1. Create a destination directory to receive the files (C:\AFPDRVR in this
example). Ensure the directory name has no more than eight letters in its title,
or the driver files will not be unpacked.
2. Click Start->Run and enter the string shown in Figure 100. Be sure to include
the “/D” option to create any sub-directories that may be needed. You can
specify the destination directory to be a diskette or a network drive if required.
3. After you unpack the files, the procedure to install the driver is the same as
already described (from step 11 in 5.2, “Installing the AFP Printer Driver” on
page 118). However, in this case, at the Manufacturer and Printer window, you
need to select Have Disk. Then indicate the drive and directory where you
unpacked the files.
Figure 100. Running the AFP Printer Driver installation program
5.3 Creating an overlay
The following steps show you how to set up the driver for producing overlays
(electronic forms). You can perform this process globally for Windows 95 or when
you select the driver from your PC application (through the Properties button).
1. Open the Printers window, and select the AFP Printer Driver icon. Right-click,
and select Properties.
2. Select the Details tab, and then select Setup. The display shown in Figure
101 appears.
Chapter 5. The IBM AFP Printer Driver 123
Figure 101. AFP Printer Driver Setup
a. If the Code page box is empty, click Defaults, and the T1001004 code
page (Personal Computer: Desktop Publishing) is added.
b. Change Paper Size as required (for example, A4 or Letter).
c. Check that the Image Resolution dialog box matches that of your target
printer. If you are using a specific driver for your printer model, this box is
grayed out as shown in Figure 101.
Note: Most desktop laser printers, including the IBM Network Printers, use
AFP resources at 300 dpi even if they subsequently print the output at 600
dpi. If you are unsure of your printer's resolution, refer to the tables in
Appendix E, “Printer summary” on page 313.
d. Leave the Orientation dialog box at its default (Portrait), unless you want to
print documents in landscape. This setting is overridden by the
application's Page Setup (or similar), and is only used for applications that
do not have page setup control such as Microsoft Paintbrush.
e. Leave the Compressed Images parameter selected. If you use an AFP
Print Driver for an older IBM printer, such as an IBM 3820, this parameter is
not selectable.
3. Click Options... to display the window shown in Figure 102 on page 124.
124 IBM AS/400 Printing V
Figure 102. AFP Printer Driver setup: Options—Overlay
4. Change the Output Type to Overlay (not Medium overlay).
a. Select the Clip limits option, leave the Clip Method as Offset plus size,
and change Top and Left to “0” (Figure 103).
b. The values for Height and Width are in proportion to the paper size you
defined earlier but may be changed if required.
Figure 103. AFP Printer Driver setup options: Clip limits
c. Select OK to save these settings and return to the Options window.
5. For now, no changes are required to the Fonts window. This is discussed
further in 5.5, “Text versus image” on page 129.
6. No changes are required to the Images window.
7. Click OK to save these settings and return to the main page of the AFP Printer
Driver Setup.
8. Click OK to close the Setup window.
9. Click OK to close the Printer Properties window.
Chapter 5. The IBM AFP Printer Driver 125
To use the AFP Printer Driver with your PC application, simply select the print
command (sometimes a separate printer setup is available).
10.Select the required AFP Printer Driver.
11.Click Properties to check or change your output type or if you want to change
any of the settings.
12.When you confirm the print operation, a Print To File dialog box is shown with
a default directory location. If you have shared folders support (that is, your
AS/400 disks are mapped to your PC as local disks), you can print directly to a
convenient shared folder as shown in Figure 104. You can give the file any
name you want, but a good convention is to use the suffix .OLY (for Overlay).
Figure 104. Print to File on Shared Folder
Note: In this example, we assume that the i:\ drive is assigned to QDLS.
If you do not have shared folders support, you need to file transfer the AFP file
using another method such as Client Access/400 file transfer or File Transfer
Protocol (FTP) if your PC and AS/400 system are using TCP/IP. The latter
method is described in 5.6.2, “File transfer of AFP resources using FTP” on
page 130.
13.As a one-time step, you must create a physical file on the AS/400 system to
receive the resource. Use the following command:
CRTPF FILE(SIMON/UPLOAD) RCDLEN(32766)
TEXT('File for transfer for AFP resources') LVLCHK(*NO)
14.Copy your AFP file from the folder into the physical file as shown here:
CPYFRMPCD FROMFLR(ITSODIR) TOFILE(SIMON/UPLOAD)
FROMDOC(INVOICE.OLY) TRNTBL(*NONE)
In the preceding example, we copied an overlay (INVOICE.OLY) created using
the AFP Printer Driver from a shared folder (ITSODIR) to a physical file
(UPLOAD). If you used Client Access file transfer or FTP, the object is already
in the physical file.
15.Create the OS/400 AFP resource:
CRTOVL OLY(SIMON/INVOICE) FILE(SIMON/UPLOAD) MBR(UPLOAD)
TEXT('Coffee Shop Invoice')
126 IBM AS/400 Printing V
This is now an AFP resource that may be used with your applications as
described in Chapter 3, “Enhancing your output” on page 67. It is an OS/400
object with an object type of *OVL.
Note: Steps 13, 14, and 15 have been automated into an OVERLAY command
provided with the AS/400 Programming Sampler available from the AS/400
printing Web site, which is: http://www.ibm.com/printers
Select Resources for AS/400, and click Downloads/freetools.
5.4 Creating a page segment
The following steps show you how to set up the driver for producing page
segments (AFP images such as graphics, logos, and signatures). You can
perform this process globally for Windows 95 or when you select the driver from
your PC application (through the Properties button).
1. Follow the process described in 5.3, “Creating an overlay” on page 122, up to
step 3 (“Click on Options”).
2. Change the output type to Page Segment.
3. The only advanced options available are Clip limits and Images. Select the
Clip limits dialog box, and leave the Clip Method as Offset plus size.
The next step depends on the image you want to create as a page segment.
For an image that occupies most or all of the page, leave the Top/Left and
Width/Height settings at their defaults. If you are producing a company logo or
signature, which typically occupies a small area of the page, you can:
a. Place your logo in the top left-hand area of the page.
b. In the AFP Printer Driver Setup, change Paper Size to User Defined (for
example, 2 inches wide by 1.5 inches deep). See Figure 105.
Figure 105. Changing the User Defined Paper Size
This reduces the amount of surrounding white space you capture with the
page segment and makes positioning it easier. See Figure 106 for an
example.
Chapter 5. The IBM AFP Printer Driver 127
Figure 106. Clip art logo in a PC application
Alternatively, you can use this method:
a. At the Advanced Clip Limits window, enter the coordinates of the top
left-hand corner of the logo (or area you want to capture) in Top and Left.
b. Change Width and Height as required (for example, 2 inches by 1.5
inches).
This latter method does not work with some newer applications such as Lotus
Freelance. A third method is to import the logo into Microsoft Paintbrush
(Windows 3.x only) and select the Partial option from the print command (that
is, print only the area of your drawing that you specify).
To use the AFP driver with your PC application, simply select the print
command (sometimes a separate printer setup is available).
4. Select the required AFP Printer Driver.
5. Click Properties to check or change your output type or if you want to change
any of the settings.
6. When you confirm the print operation, a “Print to File” dialog box is shown with
a default directory location. If you have shared folders support (that is, your
AS/400 disks are mapped to your PC as local disks), you can print directly to a
convenient shared folder as shown in Figure 107 on page 128. You can give
the file any name you want, but a good convention is to use the suffix .PSG
(for Page Segment).
128 IBM AS/400 Printing V
Figure 107. Print to File on a shared folder
Note: In this example, we assume that the i:\ drive is assigned to QDLS.
If you do not have shared folders support, you need to file transfer the AFP file
using another method such as Client Access/400 file transfer or FTP if your
PC and AS/400 system are using TCP/IP. The latter method is described in
5.6.2, “File transfer of AFP resources using FTP” on page 130.
7. As a one-time step, you must create a physical file on the AS/400 system to
receive the resource. Use the following command:
CRTPF FILE(SIMON/UPLOAD) RCDLEN(32766)
TEXT('File for transfer for AFP resources') LVLCHK(*NO)
8. Copy your AFP file from the folder into this physical file:
CPYFRMPCD FROMFLR(ITSODIR) TOFILE(SIMON/UPLOAD)
FROMDOC(CUP.PSG) TRNTBL(*NONE)
In the preceding example, we copied a page segment (CUP.PSG) created
using the AFP Printer Driver from a shared folder (ITSODIR) to a physical file
(UPLOAD). If you used Client Access file transfer or FTP, the object is already
in the physical file.
9. Create the OS/400 AFP resource:
CRTPAGSEG PAGSEG(SIMON/CUP) FILE(SIMON/UPLOAD) MBR(UPLOAD)
TEXT('Logo - coffee cup')
This is now an AFP resource that may be used with your applications as
described in Chapter 2, “Advanced Function Presentation” on page 35. It is an
OS/400 object with an object type of *PAGSEG.
Note: Steps 7, 8, and 9 have been automated into a “SEGMENT” command
provided with the AS/400 Programming Sampler available from the AS/400
printing Web site at: http://www.printers.ibm.com/products.html
Then, select AS/400 application coding sample.
Chapter 5. The IBM AFP Printer Driver 129
5.5 Text versus image
Most versions of the AFP Printer Driver allow you to print text as text rather than
as image. This is the default setting controlled by the Fonts option in Advanced
Options from the main Setup window. This means that text in your PC document
is produced as text wherever possible with graphics and shading being produced
as image. It is more efficient to produce text-based overlays and documents in
terms of both the file size and the speed of printing. For example, a standard
business overlay created as image at 300 pel resolution might be 100K in size.
That same overlay utilizing text may be less that 5K.
You need to install the IBM AFP Font Collection (described in 4.3, “Which fonts
are available” on page 93) on the AS/400 system where you intend to print the
AFP resources. This is necessary to provide the PC code page used and to
provide the AFP character sets. The latter are resolution-dependent (that is, 240
or 300-pel). Code pages are not resolution-dependent. The PC code page used
with the AFP Printer Driver is located in library QFNTCDEPAG after installation of
the IBM AFP Font Collection.
The driver produces text by mapping common PC fonts such as Arial and Times
New Roman onto host AFP equivalents, or near-equivalents such as Helvetica
and Times New Roman. The font table (IBMAFP.INI) is installed with the other
driver files in the WINDOWS\SYSTEM directory. You can observe these
mappings by clicking on a PC font together with the point size and style (Figure
108).
Figure 108. Advanced Font Options: Font substitution
If required, you can add your own mappings. For example, you can map Arial
Narrow to the same Helvetica host character set or even a different host font
altogether using the Add button. Changes may be made using the Modify and
Delete buttons. These changes are recorded in another table, PENNUSER.INI,
located in the \WINDOWS directory.
130 IBM AS/400 Printing V
You must ensure that all these fonts are available at print time and in the correct
resolution (240 or 300-pel). Newer versions of the driver also allow the use of
outline fonts. With outline fonts, you only need to specify the typeface (for
example, CZH400 for Helvetica Bold) and all point sizes are mapped to it. Outline
fonts are described in 4.5, “Outline fonts” on page 99.
The choice of whether to use text or image is made at the Advanced Options -
Fonts dialog box for overlays and documents only. The Use Substitution Table
checkbox is selected by default. This means your output will use AFP fonts where
possible and image (raster) elsewhere. If you want the entire document printed
as Image, de-select the checkbox. You can also experiment with Use text rules.
This draws lines as text instead of as an image.
Note: Some versions of the driver (for example, Windows NT and earlier versions
of the Windows 3.x drivers) do not support text output. Therefore, these drivers
do not have the Fonts option available.
Using the AFP Viewer, you can check how your document is being produced
(text, image, or both). See 5.6.3.1, “Using the AFP Viewer” on page 132.
5.6 Other AFP Printer Driver tasks
This section looks at customizing the AFP Printer Driver further, describes other
file transfer methods for transferring the AFPDS output to the AS/400 system,
and discusses some common problems.
5.6.1 Using the Images dialog box
Do not confuse this with printing the document in text or image. If any part of your
document uses image, you can control its appearance by selecting the Images
option and then one of four gray scale methods. You can also adjust the intensity
and contrast controls. How much effect you see depends on the quality and
capabilities of your printer.
These options are documented in the online help.
5.6.2 File transfer of AFP resources using FTP
If you do not have support for shared folders to directly print the AFP file to the
AS/400 system, you may want to use TCP/IP file transfer using File Transfer
Protocol (FTP) as described here. Both your PC and the AS/400 system must be
using TCP/IP, and the FTP daemon must be running on the AS/400 system. Open
a DOS Window, and refer to the example in Figure 109.
Chapter 5. The IBM AFP Printer Driver 131
Figure 109. FTP session to transfer overlay resource
Note: There is no need to create a physical file on the AS/400 system first.
However, this method will overwrite the member in the file if it already exists.
5.6.3 Problem solving
A good source of commonly-experienced problems is the README file included
with the driver (true for any product, but especially so for this one). Some of the
more common problems and answers are:
• When installing the AFP Printer Driver on Windows 3.x, why is a dialog box
displayed prompting me to insert a diskette with Serif fonts?
C:\>ftp lucyh01 1
Connected to lucyh01.systland.ibm.com.
220-QTCP at lucyh01.systland.ibm.com.
220 Connection will close if idle more than 60 minutes.
User (lucyh01.systland.ibm.com:(none)): simonh 2
331 Enter password.
Password: 3
230 USERID24 logged on.
ftp> bin 4
200 Representation type is binary IMAGE.
ftp> lcd temp 5
Local directory now C:\temp
ftp> cd simon 6
250 Current library changed to SIMON.
ftp> put test.oly 7
200 PORT subcommand request successful.
150 Sending file to member OLY in file TEST in library SIMON.
250 File transfer completed successfully.
1118 bytes sent in 0.00 seconds (1118000.00 Kbytes/sec)
ftp> quit 8
221 QUIT subcommand received.
C:\>
The steps shown in Figure 109 are explained here:
1 The FTP command to the TCP/IP name of your host system (you can use the
IP address of the system instead).
2 Normal OS/400 user ID.
3 Normal password of your user ID.
4 This specifies a binary file transfer (not ASCII).
5 Change to the local (PC) directory where the AFP file is stored. You can type
a different drive letter and subdirectory if appropriate (for example,
D:\TEST\OVLS).
6 Change directory on the AS/400 system (actually changing the current
library).
7 This copies the AFP file from the PC to the AS/400 system.
8 Type this to exit FTP.
Notes
132 IBM AS/400 Printing V
Answer: Ignore this dialog box. Select Cancel in the dialog box, and the
installation will complete successfully.
• How do I know which version of the AFP Printer Driver I am using?
Answer: From the AFP Printer Driver's Setup window, click About. The
version is similar to the IBM AFP Printer Driver for Windows Version 4.22. The
same applies for a driver from the World Wide Web or IBM AFP Driver for
Windows, Version 4.12 for the Client Access/400 version.
• When I print an AFP document or spooled file using an AFP resource where
these have been created by the AFP driver, I get a message, “Code page
T1001004 was not found”.
Answer: If you are using text instead of image, you need this PC ANSI code
page on the AS/400 system. See 5.5, “Text versus image” on page 129.
5.6.3.1 Using the AFP Viewer
Details on the use of the AFP Viewer can be found in several sources, including:
• Client Access for Windows
• AS/400 Guide to Advanced Function Presentation and Print Services Facility,
S544-5319
The AFP Viewer can be a useful tool for diagnosing problems. For example, you
can invoke the AFP Viewer to examine it using the overlay presented in Chapter
3, “Enhancing your output” on page 67. Follow these steps:
1. Open the Client Access folder, then the Accessories folder.
2. Double-click the AFP Workbench Viewer icon.
3. Select File->Open, and locate the file name of the overlay (CAFE.OLY, in this
example). The resulting window is shown in Figure 110.
Chapter 5. The IBM AFP Printer Driver 133
Figure 110. AFP overlay viewed using the AFP Viewer
If you click Options->Image View-> Color->and your favorite color, the AFP output
is displayed in this color where the output is represented by image as opposed to
a screen font. In this case, all the text in the overlay appears in black (text) and
the logo and boxes in red (image).
This is useful for tracking performance problems with documents or resources
created using the AFP printer driver (for example, when your all-text document
has actually been created as image instead of more efficient text).
134 IBM AS/400 Printing V
5.6.4 Performance of the AFP Printer Driver
The most important factor in the performance of the driver is whether it is
produced in text or image and has already been discussed. Other factors that
help maintain or improve performance are:
• Crop page segments (so you do not “print” the rest of the page as white
space).
• Avoid excessive use of shading.
• Draw square boxes, rectangles, and so on rather than rounded boxes. It may
be possible for the driver to print the former as text rules.
5.6.5 Creating AFP documents
The following steps take you through a one-time process to set up the driver for
producing AFP versions of PC documents (for example, letters or reports
produced using Lotus Word Pro or Microsoft Word, presentations using Lotus
Freelance Graphics, and spread sheets from Microsoft Excel). These are just a
few typical applications. As long as you are using a Windows or OS/2 application
with a graphical user interface, you can “print” your output using the AFP printer
driver.
You can perform this process globally for Windows 95 or when you select the
driver from your PC application (through the Properties button).
1. Follow the process described in 5.3, “Creating an overlay” on page 122, up to
step 3 (“Click Options”).
2. Change the output type to Document. Leave the Output Type option at the
default.
3. Click Form Definitions and then click Modify... (Figure 111).
Figure 111. AFP Printer Driver setup: Options—Document
a. If you want to specify duplex printing and use a different drawer, select the
Create inline form definition checkbox and the other options as required.
You can also specify an AFP overlay to be printed with your document, but
you must ensure it is available as a separate resource on the system from
which you want to print. In the example shown in Figure 112, we specified
simplex printing from Drawer 2.
Chapter 5. The IBM AFP Printer Driver 135
Figure 112. Selecting an inline form definition
b. Click OK to save these settings, and return to the Options window.
4. Select OK to save these settings, and return to the main page of the AFP
Printer Driver setup.
5. Click OK to close the Setup window.
6. Click OK to close the Printer Properties window.
The driver is now set up to produce AFP versions of your PC documents. To
configure Client Access/400 Network Printing, see 9.2, “Client Access/400
Network Printing” on page 186.
136 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 137
Chapter 6. Host print transform
This chapter describes how the host print transform function can be used to
convert SCS and AFPDS spooled files into an ASCII printer data stream. Host
print transform has been available on the AS/400 system since Version 2.0
Release 3.0. New capabilities have been added in the versions and releases that
have followed.
6.1 Host print transform overview
The host print transform 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 resultant 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 113 on page 138 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.
138 IBM AS/400 Printing V
Figure 113. Host print transform overview
ASCII printers can be attached to displays, PCs, or directly to a LAN. For detailed
information on printer attachment methods, see 1.7.7, “Printer attachment
methods” on page 32.
Host print transform is also used with the remote system printing function
(LPR/LPD). For more information, see Chapter 8, “Remote system printing” on
page 171.
Finally, Facsimile Support/400 uses the host print transform when the fax
controller used is an IBM 7852-400 ECS/Data Fax modem.
For host print transform considerations on performance, recoverability, fidelity,
and currency, see 1.7.8.1, “PSF/400 IPDS printers versus HPT ASCII printers” on
page 32.
6.2 Host print transform enhancements
The host print transform function continues to be enhanced either by PTFs or in
new versions or releases of OS/400. Host print transform includes the following
enhancements in V3R1 and later:
• AFPDS to ASCII transform and AFPDS to TIFF format transform; support for
text, image, and barcode commands.
• New and enhanced tags for WSCST; new data streams supported.
• New API QWPZHPTR brings the capabilities of the host print transform to the
AS/400 application developers.
• New manufacturer type and model special values are added continuously by
PTFs as part of the base code.
Modem
InfoWindow
Server
PC
LPR
PJL
Lexlink
Fax IBM Network
Station
LAN ASCII
Printers
Chapter 6. Host print transform 139
• Support DBCS printing; both the SCS to ASCII and the AFPDS to ASCII
transform are supported (V3R2 and V3R7 and later).
• Image scaling enhancement; with this enhancement, Facsimile Support/400
received faxes are printed at the correct size.
• New barcodes, Royal Mail, and Japan Postal are now supported (V4R2).
Note: All the enhancements provided by PTFs are already available and are part
of PTF cumulative tapes.
6.3 Host print transform process
SCS or AFPDS spooled files can be converted to an ASCII printer data stream
and printed on ASCII printers. The host print transform converts the SCS data
stream or the AFPDS data stream just before it is sent to the ASCII printer. The
AS/400 spooled file contains SCS data or AFPDS data, not the converted ASCII
data.
Note: IPDS spooled files cannot be converted by the host print transform.
AFP resources (such as fonts, overlays, page segments) referenced in AFPDS
spooled files are converted into an ASCII printer data stream and passed to the
ASCII printer.
Figure 114 shows the host print transform process.
Figure 114. Host print transform process
The host print transform function generates an ASCII printer data stream for a
number of IBM and non-IBM printers. To generate the different ASCII data
streams, the host print transform function uses AS/400 system objects that
describe characteristics of a particular printer. These objects are named Work
Station Customizing Objects (WSCST) and you can customize them.
The host print transform API QWPZHPTR invokes the SCS transform or AFPDS
transform according to the data stream type (printer attributes). This API brings
the capabilities of host print transform to the AS/400 application developer.
Host Print
Transform
Spool
Application
Work Station
Customizing Object
(WSCST)
Image Print
Transform (V4R2) QWPZHPTR
API
AFP
Resources
Printer File
ASCII
Printer
DEVTYPE
*SCS or *AFPDS
ASCII
140 IBM AS/400 Printing V
In Version 4.0 Release 2.0, if the image print transform function is enabled, host
print transform calls it for USERASCII spooled files. If the USERASCII spooled
file contains Tag Image Format (TIFF), Graphics Interchange Format (GIF), OS/2
and Windows bitmap (BMP), or PostScript Level 1 data streams, it is processed
by the image print transform. For detailed information on the image print
transform function, see Chapter 7, “Image print transform” on page 161.
6.4 Enabling host print transform
To enable the host print transform function, you must change the printer device
description, or if you are using remote system printing, change the output queue
description. The following parameters are used by the host print transform
function:
TRANSFORM Host print transform function
MFRTYPMDL Manufacturer, Type and Model
PPRSRC1 Paper source 1
PPRSRC2 Paper source 2
ENVELOPE Envelope source
ASCII899 ASCII code page 899 support (symbols code page)
WSCST Workstation customizing object and library
Host print transform is enabled when you specify *YES for the TRANSFORM
parameter in the printer device description, or if you are using remote system
printing, it is enabled in the output queue description.
Note: Client Access for Windows 95/NT creates or changes the printer device
description based on the printer's session configuration. The host print transform
function should be enabled by changing the session configuration on the
personal computer and not the device description in the AS/400 system. For
detailed information, see Chapter 9, “Client Access/400 printing” on page 185.
The host print transform function is also available when using remote system
printing with CNNTYPE(*IP) or (*IPX) and the Send TCP/IP Spooled File
(SNDTCPSPLF) command.
• For remote system printing, the TRANSFORM, MFRTYPMDL, and WSCST
parameters are part of the Create Output Queue (CRTOUTQ) command and
Change Output Queue (CHGOUTQ) command.
• The SNDTCPSPLF command includes the TRANSFORM, MFRTYPMDL, and
WSCST parameters.
The same WSCST object works for both the AFPDS to ASCII transform and the
SCS to ASCII transform.
6.5 SCS to ASCII transform
The SNA Character String (SCS) data stream is a text-only data stream used for
such items as job logs and general listings. The SCS to ASCII portion of the host
print transform function provides 3812 SCS printer emulation. That means it
supports page printer functions such as orientation and Computer Output
Reduction (COR).
Chapter 6. Host print transform 141
SCS to ASCII transform works by mapping commands in the SCS data stream to
similar commands in the ASCII printer data stream. It does not support converting
the data stream to an image the same way the AFP to ASCII transform does in
raster mode.
Host print transform has the ability to process an IOCA image embedded in the
SCS data stream. This is done by OfficeVision/400 with the graphic instruction.
The target printer must be a laser printer supporting the PPDS or PCL data
streams.
Note: The OV/400 graphic instruction allows you to embed an IOCA (image) or
GOCA (graphic) object into the SCS data stream. Only IOCA objects are
supported by the host print transform function.
Overlays referenced in the printer file, either for an application or for
OfficeVision/400, are not supported by the SCS to ASCII transform.
Note: If the printer file device type is changed to *AFPDS, the spooled file
created by the application is AFPDS. The overlays referenced in the printer file
(front overlay and back overlay) will be handled by the AFP to PCL transform.
Almost all ASCII page printers have an unprintable border around the page where
data cannot be printed. The SCS to ASCII transform function can compensate for
the no-print borders. This is demonstrated in Figure 115.
Figure 115. NOPRTBDR tag example
LINE 7
LINE 7
Unprintable
border
Unprintable
border
1
2
3
142 IBM AS/400 Printing V
This works the same for the other NOPRTBDR tags (bottom, left, and right). The
value specified is always a correction.
Note: The no-print border values in the WSCST object cannot be used to position
or format your output. Depending on the unprintable border size, no correction is
possible if your print output starts at line 1, 2, or 3.
6.6 AFPDS to ASCII transform
AFPDS to ASCII transform supports AFPDS font, text, image, and barcode
commands. It can convert the AFP data stream to a number of ASCII printer data
streams, but the best or premier support is to the following ASCII printer data
streams:
• PPDS levels 3 and 4 (IBM 4019 and 4029 laser printers)
• PCL 4, 5, and 6 (IBM Network Printers, IBM 4039 laser printer, HP LaserJet,
HP InkJet (in raster mode only)
For other ASCII printer data streams, only the text of the AFP document is
printed. Images and barcodes are not supported. If the printer does not support
absolute movement, and the tags are not defined in the WSCST, the text is not
positioned correctly. It is shown as one long string.
AFPDS resources (overlays, page segments, fonts) referenced in AFPDS
spooled file are automatically converted and passed to the ASCII printer. See
6.6.3, “Processing AFP resources” on page 148, for more information.
The AFPDS to ASCII transform function was developed so that the transform
always converts the AFP data stream to ASCII as well as possible. AFPDS
functions that are not supported by the AFPDS to ASCII transform or cannot be
converted to the ASCII printer data stream are ignored.
AFPDS to ASCII transform has two methods of performing the data stream
conversion:
• Mapping mode: Map AFP commands to similar commands in the ASCII
printer data stream. This method is available for all supported ASCII printer
data streams.
1 In this example, the top margin is ½ inch. This is the equivalent of three
lines.
2 In the application, the first line prints at line 7, which means a skip of six
lines, or one inch.
3 The top no-print border (NOPRTBDR) tag in the host print transform WSCST
object is set to 720/1440 inch (½ inch). This value (equivalent to three lines)
is a correction.
In this case, the NOPRTBDR value is equal to the top margin and will
compensate for it. The first print line prints at line 7 as defined in the
application.
Notes
Chapter 6. Host print transform 143
• Raster mode: Builds a raster image of the page in AS/400 memory and prints
the page as an image. This method is available for PPDS, pages, and PCL
data streams.
Host print transform uses the mapping mode or the raster mode according to the
printer data stream specified (PRTDTASTRM tag) in the Workstation Customizing
object (WSCST object). To use raster mode, the PRTDTASTRM tag must be
changed in the referenced WSCST object (for example, for a PCL5 printer from
HPPCL5 (mapping mode) to HPPCL5I (raster mode)). See 6.8, “New and
enhanced tags for WSCST objects” on page 152, for more information.
AFPDS to ASCII transform does not require PSF/400 to transform and print
AFPDS spooled files on ASCII printers.
6.6.1 Mapping mode
Mapping mode maps AFPDS commands to similar commands in the ASCII
printer data stream. This method is available for all supported ASCII printer data
streams.
Mapping mode provides good performance, but is limited in function on the ASCII
printer. For example, you cannot print 270 degree orientation to a printer that only
supports 0 and 90 degree orientations.
Using mapping mode, the AFPDS to ASCII transform can convert and download
AFP host resident fonts to PPDS and PCL printers. This provides font fidelity to
these printers. For other ASCII data streams, only printer resident fonts can be
used with mapping mode.
Mapping mode: Processing AFP fonts
In AFP documents, fonts and code pages can be specified as printer-resident or
host-resident. Printer-resident fonts are specified by a Font Global ID (FGID), and
printer-resident code pages are specified by a Code Page ID (CPID).
Host-resident fonts are specified by a font character set name, and host-resident
code pages are specified by a code page name. When mapping AFP fonts to
ASCII fonts, the AFPDS to ASCII transform allows the user to use fonts resident
on their ASCII printer or download host-resident fonts to PCL and PPDS printers.
The AFPDS transform can use either the 240-pel or 300-pel version of a
host-resident font. For the best results, the 300-pel version should be used. With
240-pel fonts, the character images are scaled to 300-pel. This may cause the
edges of the characters to be jagged or fuzzy. Font character sets exists in the
240 pel version in the Font Compatibility Set shipped with OS/400 (library
QFNTCPL in QSYS). We recommend using 300-pel fonts from the IBM Font
Collection for IBM Operating Systems (5648-113).
When downloading host-resident fonts to an ASCII printer, the fonts are cleared
from the printer's memory at the end of the document. The host print transform
function assumes the ASCII printer is a shared device, and there is no way to
know what other applications will do to the printer.
When an AFP document calls for a printer-resident font and code page
(FGID/CPID), the AFPDS to ASCII transform performs the following steps to
select a font when the transform is in mapping mode:
144 IBM AS/400 Printing V
1. Check the WSCST object to see if these values (FGID/CPID) are defined. If
they are, the printer commands from the WSCST are sent to the printer to set
the font and code page.
2. If the FGID is not defined in the WSCST object, an internal table in the code
lists the commonly used FGIDs and their attributes. This helps in generating
the ASCII printer commands to select the font.
The following legend applies to the information shown in Table 13.
• U = Uniformly spaced
• M = Mixed pitch
• T = Typographic
• i = Italic
• b = Bold
• w = Double Wide
Table 13. Commonly used FGIDs table
FGID Name Type of font Attribute Point Pitch
5 Orator U 10
11 Courier U 10
12 Prestige U 10
18 Courier U i 10
38 Orator U b 10
39 Gothic U b 10
40 Gothic U 10
46 Courier U b 10
66 Gothic U 12
68 Gothic U i 12
69 Gothic U b 12
85 Courier U 12
86 Prestige u 12
87 Letter Gothic U 12
92 Courier U i 12
110 Letter Gothic U b 12
111 Prestige U b 12
112 Prestige U i 12
160 Essay M 12
162 Essay M i 12
164 Prestige M 12
173 Essay M 12
204 Matrix Gothic U 13
Chapter 6. Host print transform 145
If the FGID is not in the table and the ASCII data stream is PPDS or PCL, the
transform sends the font request to the printer and lets it perform a best fit
match. This is similar to what the SCS to ASCII transform does today.
3. In all other cases, the font request is ignored, and printing continues in the
current font.
When an AFP document calls for a host-resident code page and font character
set, the AFPDS transform performs the following steps to select a font:
1. If the ASCII data stream is PPDS or PCL, the transform obtains the font
resource and converts it to the proper format for printing.
221 Prestige U 15
223 Courier U 15
230 Gothic U 15
244 Courier U w 5
245 Courier U b,w 5
252 Courier U 17
253 Courier U b 17
254 Courier U 17
256 Prestige U 17
281 Gothic Text U 20
290 Gothic Text U 27
751 Sonoran Serif T 8 27*
760 Times T 6 36*
761 Times T b 12 18*
762 Times T b 10 15*
763 Times T i 12 18*
764 Times T b,i 10 21*
765 Times T b,i 12 18*
1051 Sonoran Serif T 10 21*
1056 Sonoran Serif T i 10 21*
1351 Sonoran Serif T 12 18*
1653 Sonoran Serif T b 16 13*
1803 Sonoran Serif T b 18 12*
2103 Sonoran Serif T b 24 9*
* The pitch column for typographic fonts indicates the width of the space character
between the printed characters.
FGID Name Type of font Attribute Point Pitch
146 IBM AS/400 Printing V
2. If the ASCII data stream is not PPDS or PCL, the transform ignores the font
request. Printing continues in the current font.
6.6.2 Raster mode
Raster mode builds a raster image of the page in AS/400 memory and then sends
the image to the printer. This method is available for PPDS, Pages, and PCL data
streams. This method is slower than mapping mode, but allows:
• Support of ink jet printers that require the page to be printed in order (only one
pass of the page). Normally, AFP documents make multiple passes of the
page (for example, an overlay is printed before the text is printed).
• Font fidelity for printers to which the transform cannot download fonts.
• Support of AFPDS functions not available on ASCII printers, such as multiple
page orientations to a 4019 printer.
Raster mode: Processing AFP fonts
In AFP documents, fonts and code pages can be specified as printer-resident or
host-resident. Printer-resident fonts are specified by a Font Global ID (FGID), and
printer-resident code pages are specified by a Code Page ID (CPID).
Host-resident fonts are specified by a font character set name, and host-resident
code pages are specified by a code page name. In raster mode, only
host-resident fonts can be used.
The AFPDS transform can use either the 240-pel or 300-pel version of a
host-resident font. For the best results, the 300-pel version should be used. With
240-pel fonts, the character images are scaled to 300 pel. This may cause the
edges of the characters to be jagged or fuzzy. Font character sets exists in the
240-pel version in the Font Compatibility Set shipped with OS/400 (library
QFNTCPL in QSYS). We recommend using 300-pel fonts from the IBM Font
Collection for IBM Operating Systems (5648-113).
When an AFP document calls for a printer-resident code page and font
(CPID/FGID), the AFPDS to ASCII transform performs the following steps to
select a font if the transform is in raster mode:
1. The transform looks in the spooled file library list and font libraries QFNTCPL
and QFNTxx for a host-resident character set and code page. The code page
name to look for is determined by converting the CPID to a four-character
string and appending it to the prefix “T1V1”.
The font character set name to look for is determined by looking at Table 14.
Table 14. Font substitution table 2
FGID range Substituted font
character set name
Fonts 1 through 17 C0S0CR10
Font 18 C0S0CI10
Fonts 19 through 38 C0S0CR10
Font 39 C0D0GB10
Font 40 C0D0GT10
Fonts 41 through 45 C0S0CR10
Chapter 6. Host print transform 147
If code page 259 (Symbols) is specified, Table 14 is not used. In this case,
character set C0S0SYM2 is used for fonts 0 to 65. For all other fonts,
character set C0S0SYM0 is used.
Font 46 C0S0CB10
Fonts 47 through 65 C0S0CR10
Fonts 66 through 68 C0D0GT12
Font 69 C0D0GB12
Fonts 70 through 91 C0S0CR12
Font 92 C0S0CI10
Fonts 93 through 109 C0S0CR12
Fonts 110 through 111 C0S0CB12
Fonts 112 through 153 C0S0CR12
Fonts 154 through 161 C0S0ESTR
Font 162 C0S0EITR
Fonts 163 through 200 C0S0ESTR
Fonts 201 through 210 C0D0GT13
Fonts 211 through 229 C0S0CR15
Font 230 C0D0GT15
Fonts 231 through 239 C0S0CR15
Fonts 240 through 246 C0S0CR10
Fonts 247 through 259 C0D0GT18
Fonts 260 through 273 C0S0CB10
Fonts 274 through 279 C0D0GT18
Fonts 280 through 289 C0D0GT20
Fonts 290 through 299 C0D0GT24
Fonts 300 through 2303 C0D0GT18
Fonts 2304 through 3839
or 4098 through 65279
Fonts with point size 0 through 7.5 C0D0GT18
Fonts with point size 7.6 through 9.5 C0S0CR15
Fonts with point size 9.6 through 11.5 C0S0CR12
Fonts with point size 11.6 through 13.5 C0S0CR10
Fonts with point size 13.6 and greater C0S0CB10
Fonts 3840 through 4095 (User-defined) No substitution
Fonts 65280 through 65534 (User-defined) No substitution
FGID range Substituted font
character set name
148 IBM AS/400 Printing V
All of the preceding character sets exist in 240-pel versions in the font
compatibility set that is shipped with OS/400 (Library QFNTCPL in QSYS) or,
for best results, in 300-pel versions in the IBM Font Collection for IBM
Operating Systems (5648-113).
2. If the correct host-resident font cannot be found, the transform ignores the font
request and printing continues in the current font. If this is the first font request
of the document, the transform ends with an error.
When an AFP document calls for a host-resident font character set and code
page, the AFPDS transform gets the font character set and converts it to the
proper format for printing. Font bitmaps are moved into the raster image of the
page.
6.6.3 Processing AFP resources
AFPDS to ASCII transform uses the new List Spooled File AFPDS Resources
(QGSLRSC) and Copy AFPDS Resource (QGSCPYRS) APIs to process external
resources such as character sets, overlays, and page segments.
For font character sets, the AFPDS to ASCII transform always calls the List
Spooled File AFPDS Resources API for the 300-pel version. If the resource
cannot be found on the system, the AFPDS to ASCII transform calls the API a
second time for the 240-pel version.
Overlays and page segments are converted. Support for IO1 images (IOCA) and
IM1 images (raster) referenced in page segments is included. Fonts referenced in
overlays are processed according to the mode selected.
AFP resources are cleared from the printer's memory at the end of the document.
The host print transform function assumes the ASCII printer is a shared device,
and there is no way to know what other applications will do to the printer.
6.6.4 Processing AFPDS barcodes
A barcode is a predetermined pattern of bars and spaces that represent numeric
or alphanumeric information in a machine readable form. Barcodes are commonly
used in many applications including item tracking, inventory control, point-of-sale
operations, and patient care.
The IBM Advanced Function Print (AFP) data stream defines an architecture for
presenting barcodes. The following industry barcode standards are supported by
the AFPDS to ASCII transform function:
• Code 39, AIM USS-39
• MSI
• UPC/CGPC Version A
• UPC/CGPC Version E
• UPC Two-digit Supplemental
• UPC Five-digit Supplemental
• EAN-8
• EAN-13
• Industrial 2-of-5
• Matrix 2-of-5
• Interleaved 2-of-5, AIM USS-1 2/5
• Codabar 2-of-7, AIM USS-Codabar
Chapter 6. Host print transform 149
• Code 128, AIM USS-128
• EAN Two-digit Supplemental
• EAN Five-digit Supplemental
• POSTNET
• Japan Postal (New V4R2)
• Royal Mail (New V4R2)
Note: UCC/EAN-128 is supported by host print transform. UCC/EAN-128 is a
standard that consists of both a barcode standard and a defined data structure.
The barcode used is a subset of Code 128. More information about the Uniform
Code Council and UCC/EAN-128 can be found at: http://www.uc-council.org/
Barcode support is available for PCL and PPDS data streams in mapping mode
or in raster mode. In mapping mode, barcodes are implemented in the AFPDS to
ASCII transform as downloaded fonts.
In addition to the barcode symbol, the barcode data stream can also request that
human readable interpretation (HRI) be printed. The following fonts are required
to print the barcode HRI:
• OCR-A
• OCR-B for UPC barcodes
• Device default, Gothic Roman 10 point
OCR-A, OCR-B, and Gothic Roman 10 point are available in the 240-pel
compatibility fonts (library QFNTCPL in QSYS).
Note: For best results, we recommend that you use outline fonts or 300-pel fornts
from the IBM AFP Font Collection (5648-B45).
6.6.5 How AFPDS to ASCII transform handles a no-print border
Absolute movement is done with reference to the origin of the page. The AFP
data stream expects the origin to be the upper left corner of the physical page.
Most ASCII laser printers have a no-print border, and their origin is in the upper
left corner of the printable area.
AFPDS to ASCII transform uses the current no-print border values from the
workstation customizing object to determine the position of the origin on the
ASCII printer.
In mapping mode, the AFPDS to ASCII transform adjusts cursor movement within
the printable area of the page so it appears that the origin is in the upper left
corner of the physical page (what an AFP data stream expects). Cursor
movements within the no-print border are moved to the edge of the no-print
border. AFP positions past the top and left no-print border values are reduced by
no-print border values to print at the correct paper location.
Note: No-print border problems in mapping mode can be corrected by changing
to raster mode or removing the no-print border values from WSCST.
For raster mode, the page is turned into an image and the first row and column
that contains a black pel is known. If that row or column is in the no-print border,
the entire image is shifted to preserve the top and left edges. This may result in
data being clipped from the right and bottom edges.
150 IBM AS/400 Printing V
6.6.6 AFPDS to TIFF
Host print transform can also transform an AFPDS data stream to TIFF. The data
stream tag (PRTDTASTRM) in the WSCST object is used to determine the type of
transform:
• TIFF Packbit format if PRTDTASTRM tag set to TIFF_PB
• TIFF G4 format if PRTDTASTRM tag set to TIFF_G4
AFPDS to TIFF transform works the same as the AFPDS to ASCII transform in
raster mode. The following source is the full WSCST source needed to transform
AFPDS to the TIFF Packbit format:
:WSCST DEVCLASS=TRANSFORM.
:TRNSFRMTBL.
:PRTDTASTRM
DATASTREAM=TIFF_PB.
:INITPRT
DATA ='4D4D002A'X.
:RESETPRT
DATA ='00000000'X.
:EWSCST.
To create the WSCST object for the AFPDS to TIFF transform, copy the
preceding source into a source file member and use the CRTWSCST command
to create and compile the object.
Note: WSCST objects QWPTIFFPB and QWPTIFFG4 are available in library
QSYS on V3R2 and V3R7 and later. Since this is not used for printing, there is no
manufacturer type and model added for it.
For example, an application program can now use the host print transform API to
convert an AFPDS spooled file to a TIFF image and then present the image on an
IBM 3489 InfoWindow II display.
6.6.7 Transform spooled file and write to folder
A program sample for retrieving data from a spooled file, transforming it through
host print transform, and writing the output to a folder is available from the IBM
Redbooks Web site. This type of program can be used to transform output data
(for example, AFP pages to TIFF images) from an AS/4000 output queue to a
folder to be accessible to a browser. The sample code can be found at:
http://www.redbooks.ibm.com
On the redbooks home page, click Additional Materials. Click here for the
directory listing. On the list that is displayed, search for the directory SG242160.
Using FTP, you can download the command (HPTTOFLR.CMD) and the source
code of the program (HPTTOFLR.C) from this directory.
For the transformation, this program allows you to use any of the available Work
Station Customizing (WSCST) objects. For creating output in TIFF, use the
WSCST example in 6.6.6, “AFPDS to TIFF” on page 150.
6.6.8 AFPDS to ASCII transform limitations
The following list describes the limitations of AFP to ASCII transform. This list is
not prioritized.
Chapter 6. Host print transform 151
• Dot matrix ASCII printers are not supported. Since these printers do not
support absolute movement, even text does not print correctly. Text prints as
one long string.
• The transform does not support AFP graphics (GOCA) commands. For
example, pie charts generated by BGU or GDF files imbedded in the spooled
file will not print.
• The transform ignores the fidelity attribute of the spooled file and always
performs content printing.
• The transform does not support COR and multi-up printing.
• The transform does not support color barcodes.
• At this time, the transform can only produce 240 or 300 dpi images.
6.7 Host print transform customization
If you do not find your printer in the list of the manufacturer type and model
(MFRTYPMDL) special values, or if you need additional print functions, you can
specify a workstation customized (WSCST) object instead of a MFRTYPMDL
special value.
Before you can begin customizing an ASCII printer, you must have information on
the functions that the ASCII printer supports. You can only add or change printing
functions that a printer supports. You also need the hexadecimal values for these
functions. Often, the technical reference manual for the printer provides this
information.
The source of a WSCST object is a tag language. Tags can contain information
for host print transform, hard-coded printer commands, or printer commands with
replacement parameters (variables). Figure 116 shows an example of the
WSCST source and the three tag types.
Figure 116. WSCST source and tag types
152 IBM AS/400 Printing V
Use the following steps to customize the functional characteristics of an ASCII
printer:
1. Use the RTVWSCST command to retrieve an existing WSCST object into a source
physical file.
2. Use SEU or the STRPDM command to update or change the WSCST source file.
3. Use the CRTWSCST command to compile or create a customized WSCST object.
4. Specify *WSCST as the MFRTYPMDL value in the printer device description, in
the CRTOUTQ/CHGOUTQ if you are using remote system printing, or in the
SNDTCPSPLF command.
5. Specify the name of your WSCST object in the WSCST parameter in the
device description, in the CRTOUTQ/CHGOUTQ if you are using remote
system printing, or in the SNDTCPSPLF command.
Customizing an ASCII printer may involve a trial-and-error process. The amount
of time required to customize a printer depends on the type of printer, regardless
of whether the printer is already supported by the AS/400 system, and the
completeness of the manual for the printer. Plan anywhere from one to five days
to complete a successful ASCII printer customization.
For detailed information on customizing a WSCST object, see AS/400 Printing IV,
GG24-4389. The “Advanced host print transform customization” chapter contains
an example and a description of the different tags. The manual AS/400
Workstation Customization Programming, SC41-3605, also contains a
description of all the tags.
6.8 New and enhanced tags for WSCST objects
The following list describes the new and changed tags for the host print transform
WSCST objects:
• PRTDTASTRM (Printer Data Stream):
The PRTDTASTRM tag defines the data stream of the ASCII printer. This tag
is currently defined, but the following data stream values are added:
– IBMPPDS3:
The IBM personal printer data stream level 3 is supported. This is used for
the IBM 4019 printer. Supported functions over level 2 are page rotation
and non-compressed image.
– IBMPPDS4:
The IBM personal printer data stream level 4 is supported. This is used for
the IBM 4029 printer. Supported functions over level 3 are multiple
rotations on a page and compressed image.
– IBMPPDS3I:
The IBM personal printer data stream level 3 is supported in raster mode.
This value means the same to SCS to ASCII transform as IBMPPDS3 since
it only supports the mapping mode. For AFP to ASCII transform, this value
causes it to go into raster mode for a PPDS level 3 (4019) printer.
Chapter 6. Host print transform 153
– IBMPPDS4I:
The IBM personal printer data stream level 4 is supported in raster mode.
This value means the same to SCS to ASCII transform as IBMPPDS4 since
it only supports the mapping mode. For AFP to ASCII transform, this value
causes it to go into raster mode for a PPDS level 4 (4029) printer.
– HPPCL4I:
The Hewlett Packard PCL4 printer data stream is supported in raster
mode. This value means the same to SCS to ASCII transform as HPPCL4
since it only supports the mapping mode. For AFP to ASCII transform, this
value causes it to go into raster mode for a PCL4 printer.
– HPPCL5I:
The Hewlett Packard PCL5 printer data stream is supported in raster
mode. This value means the same to SCS to ASCII transform as HPPCL5
since it only supports the mapping mode. For AFP to ASCII transform, this
value causes it to go into raster mode for a PCL5 printer.
– TIFF_PB:
This value is used for AFPDS to TIFF format transform. With this value, the
image is generated in TIFF Packbit format.
– TIFF_G4:
This value is used for AFPDS to TIFF format transform. With this value, the
image is generated in TIFF G4 format.
– IOCA_G3MH (V3R7 and later):
To support fax when the IBM 7852-400 modem is used as a fax controller.
– IOCA_G3MRK2 (V3R7 and later):
To support fax when the IBM 7852-400 modem is used as a fax controller.
– IOCA_G3MRK4 (V3R7 and later):
To support fax when the IBM 7852-400 modem is used as a fax controller.
• HORAMOV (Horizontal Absolute Move):
The HORAMOV tag adjusts the print position in the current line according to
the value given in the command. The format of the tag is:
:HORAMOV
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• VERAMOV (Vertical Absolute Move):
The VERAMOV tag adjusts the print position in the current column according
to the value given in the command. The format of the tag is:
:VERAMOV
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
154 IBM AS/400 Printing V
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• RASEND (Raster Graphics End):
Marks the end of a raster graphics image. The format of the tag is:
:RASEND
ASCII control sequence.
• TOPMARGINI (Set Top Margin in Inches):
Sets the top of the page in inches. The format of the tag is:
:TOPMARGINI
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• TEXTLENL (Set Text Length):
Sets the length or bottom margin of the page. The format of the tag is:
:TEXTLENL
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
DATA = ASCII control sequence.
• PRTNXTCHR (Print Next Character):
Causes the printer to treat the next code point as a graphic character. The
format of the tag is:
:PRTNXTCHR
DATA = ASCII control sequence.
• PRTANGLE (Print Angle):
Changes the direction of future printing on the page. This allows printing in all
four directions on the same page. The format of the tag is:
:PRTANGLE
ANGLE = 0 | 90 | 180 | 270
DATA = ASCII control sequence.
6.9 New MFRTYPMDL special values
These new manufacturer type and model (MFRTYPMDL) special values provide
default paper sizes. You can use them when no device description exists for the
target printer (for example, when the printer is attached using TCP/IP LPR-LPD
and a remote output queue is used).
Note: When a device description exists for the target printer, the default paper
sizes are specified in the device description.
These new MFRTYPMDL special values are available with Version 3.0 Release
2.0 and Version 3.0 Release 7.0 and later:
*WSCSTLETTER Set Letter format
*WSCSTLEGAL Set Legal format
Chapter 6. Host print transform 155
*WSCSTEXECUTIVE Set Executive format
*WSCSTA3 Set A3 format
*WSCSTA4 Set A4 format
*WSCSTA5 Set A5 format
*WSCSTB4 Set B4 format
*WSCSTB5 Set B5 format
*WSCSTCONT80 Set continuous form 80 characters
*WSCSTCONT132 Set continuous form 132 characters
*WSCSTNONE Paper size not specified (no Set paper size command in
the data stream)
If you have a printer device description, you must also specify *NONE for the
default paper size parameters. If you don’t, the value from the paper size
parameters will override the value of the WSCST object.
Note: If no paper size is specified, no COR will occur. It can be used to disable
the COR function. To use these new WSCST objects, complete the following
steps:
1. Retrieve the workstation customized object, for example:
RTVWSCST DEVTYPE(*TRANSFORM) MFRTYPMDL(*IBM4317) SRCMBR(NP17SRC)
SRCFILE(QGPL/QTXTSRC)
2. Create a customized workstation configuration object:
CRTWSCST WSCST(QGPL/NP4317) SRCMBR(NP17SRC)
You will receive the message “Customization object NP4317 created
successfully”.
3. Stop the remote writer:
ENDWTR WTR(outputq_name) OPTION(*IMMED)
4. To change the output queue, enter the CHGOUTQ command, and press the F4
(Prompt) function key. Then page down until you see the parameters shown in
Figure 117.
Figure 117. Change Output Queue: HPT and WSCST parameter
On this display, enter the following parameter values:
• Manufacturer type and model: *WSCSTA4 (or any from the other
formats)
• Workstation customizing object: NP4317 (the object that you created
with the command CRTWSCST)
Change Output Queue (CHGOUTQ)
Type choices, press Enter.
......................... ....... ........
Host print transform . . . . . . *YES *YES, *NO
Manufacturer type and model . . *wscsta4
Workstation customizing object NP4317 Name, *NONE
Library . . . . . . . . . . . qgpl Name, *LIBL, *CURLIB
......................... ....... ........
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
156 IBM AS/400 Printing V
• Library: QGPL (the library specified in the CRTWSCST command)
5. Press Enter to modify your output queue.
6.10 DBCS support in host print transform
In August 1996, host print transform was enhanced through a number of V3R2
PTFs to support double-byte character set (DBCS) printing. These enhancements
can also be found in the base of the V3R7 and later versions and releases.
These enhancements allow DBCS printing to ASCII printers through the Send
TCP Spooled file (LPR) command or the remote system printing and ASCII LAN
attached printer option where host print transform is the only transform option.
They can also be used in place of the transform found on PC and terminal
emulators, but only if they emulate a 3812 printer.
6.10.1 DBCS SCS to ASCII transform
The host print transform uses AS/400 ICONV support to convert EBCDIC data to
ASCII data.
6.10.1.1 DBCS EBCDIC to ASCII transform
FROM to CCSID mapping tables provide the mapping of CCSIDs to convert a
double-byte EBCDIC character in an application data stream into an ASCII
character code value (for that same character).
The workstation customizing object provides new tags to identify the
FROM(EBCDIC) CCSID and the TO (ASCII) CCSID. If no tag is specified in the
workstation customizing object, the FROM-TO assignment is made according to
the information in Table 15.
Table 15. Default from or to the CCSID table
From CCSID Default CCSID Language
5026 932 Japanese
5035 932 Japanese
930 932 Japanese
931 932 Japanese
939 932 Japanese
933 949 Korean
937 959 Traditional Chinese
935 1381 Simplified Chinese
Chapter 6. Host print transform 157
6.10.1.2 New WSCST objects for DBCS
The DBCS WSCST objects and their corresponding manufacturer type and model
(MFRTYPMDL) special values shown in Table 16 were added as part of this
enhancement for SCS to ASCII transform.
Table 16. DBCS WSCST objects and corresponding MFRTYPMDL
6.10.2 DBCS AFPDS to ASCII transform
Host print transform processes DBCS AFP print jobs in raster mode only. For
more information on the raster mode, see 6.6.2, “Raster mode” on page 146. That
is, a raster image of each page is created in AS/400 memory and sent to the
printer. The ASCII printer must accept raster images to work with the AFPDS to
ASCII transform.
The main change to the AFPDS to ASCII transform is the support of DBCS fonts.
The host print transform requires the DBCS fonts selected in a DBCS AFP print
job to be loaded on the AS/400 system. DBCS fonts that reside on the ASCII
printer are not used to process DBCS print jobs.
Host print transform has also been enhanced to support a character rotation of
270 degrees. DBCS languages use a character rotation of 270 degrees to
implement right-to-left, top-to-bottom printing.
6.10.3 New tags and supported data streams for DBCS
The following new tags are added for the Host Print Transform workstation
customizing objects:
• EBCASCCSID (EBCDIC-to-ASCII CCSID mapping):
Use the EBCACCSID tag to begin a group of one or more EBCASCCSIDE
tags. This tag must be followed by one or more CCSID mapping entries. There
are no parameters on this tag. The syntax for this tag is:
:EBCASCCSID.
• EBCASCCSIDE (EBCDIC-to-ASCII CCSID mapping entry):
This new tag defines the mapping of double-byte EBCDIC CCSIDs to their
ASCII CCSID. The ECBCASCCSIDE tag must follow an EBCASCCSID tag.
The syntax of this tag is:
:EBCASCCSIDE
EBCDICCSID = EBCDIC CCSID (integer)
ASCIICCSID = ASCII CCSID (integer).
EBCDICCSID is a required parameter. It defines the EBCDIC CCSID identifier.
The CCSID is a registered EBCDIC identifier used to specify the CCSID of the
source characters.
WSCST MFRTYPMDL Description
QWPESCP *ESCPDBCS Epson ESC/P DBCS printers
QWPIBM2414 *IBM5575 IBM Non-Pages PS/55 printers
QWPPAGES *IBMPAGES IBM Pages PS/55 printers
QWPNEC201 *NECPCPR201 NEC PC-PR101/201 printers
QWPLIPS3 *CANLIPS3 Canon LIPS# printers
158 IBM AS/400 Printing V
ASCIICCSID is a required parameter. It defines the ASCII CCSID identifier.
The CCSID is a registered ASCII identifier used to specify the CCSID of the
target characters.
• EEBCASCCSID (End EBCDIC-to-ASCII CCSID mapping table entry):
Use the EEBCACCSID tag to end the EBCDIC-to-ASCII CCSID mapping
customization. The syntax for this tag is:
:EEBCASCCSID.
• PRTALLCHR (Print All Characters):
This command causes the printer to interpret the bytes that follow as printable
characters rather than control codes. Note that the PRTNXTCHR provides the
same function, but only for one byte. The syntax of this tag is:
:PRTALLCHR
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
DATA = ASCII control sequence.
• SI (Shift IN):
This command causes the printer to interpret the bytes that follow as SBCS
characters. The syntax of this tag is:
:SI
DATA = ASCII control sequence.
• SO (Shift OUT):
This command causes the printer to interpret the bytes that follow as DBCS
characters. The syntax of this tag is:
:SO
DATA = ASCII control sequence.
• DBSPACE (DBCS Space):
The DBSPACE tag defines the ASCII control sequence for the double-byte
space control function for an ASCII printer. The syntax of this tag is:
:DBSPACE
DATA = ASCII control sequence.
• CHRORIENT (Character Orientation):
The CHRORIENT tag defines the control sequence for setting different
character orientations. The syntax of this tag is:
:CHRORIENT
ORIENT = PORTRAIT|LANDSCAPE|RTT180|RTT270
DATA = ASCII control sequence.
• SCPITCH (Set Character Pitch):
The SCPITCH tag defines the control sequence for setting the number of
characters per inch. The syntax of this tag is:
:SCPITCH
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
Chapter 6. Host print transform 159
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• SLPITCH (Set Line Pitch):
The SLPITCH tag defines the control sequence for setting the number of lines
per inch. The syntax of this tag is:
:SLPITCH
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• FONTSCALING (Set Font Size Scaling):
The FONTSCALING tag defines the control sequence for setting the font size
scaling. The syntax of this tag is:
:FONTSCALING
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
• FONTSCALE (Set Font Size Scale):
The FONTSCALE tag defines the control sequence for setting the font size
scaling. The syntax of this tag is:
:FONTSCALE
SCALE = 1VX1H | 2VX1H | 1VX2H | 2VX2H
DATA = ASCII control sequence.
• CPI (Set Characters per Inch):
The CPI tag defines the control sequence for setting the number of characters
per inch. New values for 6, 6.7, 7.5, and 18 cpi are added to this tag. The
syntax of this tag is:
:CPI
CPI = 5|6|67|75|10|12|133|15|166|171|18|20|25|27
DATA = ASCII control sequence.
• GLTYPE (Set Grid Line Width):
The GLTYPE tag defines the control sequence for setting the grid line type.
The syntax of this tag is:
:GLTYPE
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRN
DATA = ASCII control sequence.
• GLWIDTH (Set Grid Line Type):
The GLWIDTH tag defines the control sequence for setting the grid line width.
The syntax of this tag is:
:GLTYPE
VAROFFSET = variable offset in control sequence
160 IBM AS/400 Printing V
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
DATA = ASCII control sequence.
• DRAWLINE (Draw Grid Line):
The DRAWLINE tag defines the control sequence for the draw grid line
function. The syntax of this tag is:
:DRAWLINE
VAROFFSET = variable offset in control sequence
VARLEN = variable length
VARTYPE = HIGHLOW|LOWHIGH|CHRDEC|CHRHEX|CHRAN
CNVNUM = conversion ratio numerator
CNVDEN = conversion ratio denominator
DATA = ASCII control sequence.
To support the new DBCS printers, new data stream values are available to the
PRTDTASTRM tag. These new values are:
• IBMNONPAGES: The IBM DBCS Non-Pages (dot matrix printers) data stream
is supported.
• IBMPAGES: The IBM DBCS Pages data stream is supported.
• ESC/P: The Epson DBCS ESC/P data stream is supported.
• LIPS2+: The Canon DBCS LIPS2+ data stream is supported.
• LIPS3: The Canon DBCS LIPS3 data stream is supported.
© Copyright IBM Corp. 2000 161
Chapter 7. Image print transform
This chapter provides information about the image print transform function
available with Version 4.0 Release 2.0, and describes how to enable it to provide
additional support for printers that are attached to the AS/400 system. The image
print transform function is an OS/400 function that is capable of converting image
or PostScript data streams into AFPDS or ASCII printer data streams. The
conversion takes place on the AS/400 system, which means the data stream
generated is independent of any printer emulators or hardware connections.
7.1 Image print transform function
The image print transform function (Figure 118) converts image or print data from
one format into another. The resultant data stream is a printer data stream.
Therefore, it is capable of being interpreted by a supporting printer.
Figure 118. Image print transform function
The image print transform function can convert the following data streams:
• Tag Image File Format (TIFF)
• Graphics Interchange Format (GIF)
• OS/2 and Windows Bitmap (BMP)
• PostScript Level 1
The image print transform function can generate the following data streams:
• Advanced Function Printing Data Stream (AFPDS)
• Hewlett-Packard Printer Control Language (PCL)
• PostScript Level 1
PostScript (PS)
TIFF
GIF
BMP
PostScript
TIFF
GIF
BMP
Print Services
Facility/400
Host Print
Transform
IPDS Printer
AFP(*YES) ASCII Printer
IPDS
AFPDS
PS
PCL
PS
PCL
AFPDS
PostScript
TIFF
GIF
BMP
Image Print
Transform
Spool
Image Print
Transform API
QIMGCVTI
Integrated File
System (IFS)
IBM Network
Station
CA/400
Network Printing
162 IBM AS/400 Printing V
Similar to the host print transform function, the image print transform function
converts the data on the AS/400 system instead of using an emulator.
When a data stream is converted by the image print transform function, the
printer data stream that is created contains a bit-mapped image. A bit-mapped
image is an array of numeric values. Each value represents part or all of a pixel.
A pixel is a single point or dot of an image.
An image is usually measured in terms of pixels for both width and height. The
resolution of an image is then defined as the number of pixels (dots) per unit of
measure. For example, a resolution supported by many printers is 300 dots per
inch (dpi). Therefore, an image having dimensions of 1200 pixels by 1500 pixels
has a width of 4 inches and a height of 5 inches when it is printed at 300 dpi.
7.2 Why use image print transform
There are many advantages for using the image print transform function.
• Support for Intelligent Printer Data Stream (IPDS) printers:
TIFF, GIF, and BMP image files, as well as PostScript Level 1 files, can be
converted to AFPDS format and printed on IPDS printers configured
AFP(*YES).
• Support for ASCII printers:
TIFF, GIF, and BMP image files, as well as PostScript Level 1 files, can be
converted to PCL-5 and PostScript Level 1 format and printed on ASCII
printers supporting these standards.
Note: You cannot convert from one type of PostScript to another using the
image print transform function. When the input and output data streams are
PostScript, the data is sent directly to the output destination without
conversion.
• Customized printer support:
Image configuration objects are used with the image print transform function
to specify certain characteristics of the converted data streams. When
associated with the device description information for a printer connected to
the AS/400 system, image configuration objects act as a template for the
converted data stream. Attributes, such as data stream format, color, and
resolution, are all specified in the image configuration object.
• Additional capabilities:
In addition to converting data from one format to another, other functions can
be performed by the image print transform function. Among these are the
ability to reduce color, compress data, and change photometricity. For more
information about the features of the image print transform function, consult
AS/400 System API Reference, SC41-5801.
Note: You cannot perform functions that your printer does not support. For
example, you cannot print in landscape orientation when your printer only
supports portrait orientation.
Chapter 7. Image print transform 163
7.3 Image print transform process
The image print transform function converts data from one image or print data
stream format to another. In the process, image processing functions can be
performed, including conversion from color to gray to bi-level, re-sizing,
compression, and decompression.
The convert image API (QIMGCVTI) accepts an input data stream from an
integrated file system (IFS) file, a spooled file, or memory, and sends the
converted data stream to a file, spooled file, or memory.
The user may select an image configuration to describe the output data similar to
selecting a device description. Image print transform determines the required
transformations from the input data stream and the image configuration object
without further assistance from the user. The interfaces also allow the user to
directly specify attributes of the input and output data streams or to override
individual attributes in the image configuration.
Figure 119. Converting data streams using image print transform
In pre-spool mode (Figure 119), image print transform runs in the job calling the
API. Input parameters, along with the image configuration object, are used to
control the transform. A new spooled file is created, and image print transform
writes the converted data stream to it. It also sets the appropriate spooled file
attributes to describe the data stream (print data).
Image print transform is integrated with spooled file processing so that any of the
supported data stream formats can be spooled to any dot-addressable printer
connected to the AS/400 system. The AS/400 system detects and performs the
required transforms without assistance from the user. To achieve this goal, image
print transform is called by the same application program interface (API) that calls
the host print transform.
Although most users choose to delay any transforms until print time, the API also
allows transforms before spooling the file. Therefore, the user can control
whether the processing occurs in pre-spool or post-spool mode.
In post-spool mode, see Figure 120 on page 164 if the target printer is an ASCII
printer. See Figure 121 on page 164 if the target printer is an IPDS AFP(*YES)
Image Print
Transform
Integrated File
System (IFS)
Spooled Files
Memory
Integrated File
System (IFS)
Spooled Files
Memory
Image Print
Transform (API)
QIMGCVTI
Image
Configuration
Object
User Job
164 IBM AS/400 Printing V
printer. The image print transform function is called automatically by the system
as part of spool processing.
Figure 120. Printer writer or remote writer with HPT (*YES)
The driver for ASCII printers calls the host print transform API interface program,
which reads the spooled file attributes to determine whether to call host print
transform or the image print transform post-spool interface. If the image print
transform post-spool interface is called, it reads the device description, image
configuration object, and the spooled file attributes directly to determine the
required output format and resolution of the printer. If data-stream transform is
not possible, the post-spool interface returns an indicator to that effect to the host
print transform API interface program.
Figure 121. Image print transform and PSF/400
If the target printer is IPDS (AFP*YES), Print Services Facility/400 (PSF/400)
selects a spooled file to be processed. If the spooled file is *USERASCII,
PSF/400 calls host print transform to find out if the spooled file can be
transformed. If the spooled file can be transformed, image print transform makes
the transformation, one buffer at a time, into AFPDS depending on the printer
device description image configuration object and passes the transformed buffer
back to PSF/400.
Note: As the spooled file is transformed buffer by buffer, this process results in
poor performance. Consider the usage carefully.
Output Queue
Host Print
Transform
Spooled Files
Image
Configuration
Object
Image Print
Transform
Interface to
Printer
Interface to
Remote Queue
USERASCII in
AFPDS out Host Print
Transform
Output Queue
Spooled Files
Image
Configuration
Object
Image Print
Transform
IPDS Printer
AFP(*YES)
Print Services
Facility/400
Chapter 7. Image print transform 165
If the spooled file cannot be transformed, the spooled file is held, and an error
message is returned to the QSYSOPR message queue.
7.3.1 Where output attributes are derived
The following output attributes are derived from the image configuration object
unless specified otherwise in the user-defined data attribute of the spooled file:
• Data stream format
• Photometric interpretation
• Resolution units
• Horizontal resolution
• Vertical resolution
• Compression type
• Bits per sample
• No print borders (left, right, top, bottom)
The following output attributes are derived from the printer file (for example,
spooled file attributes) if the output data stream format is AFPDS and the printer
is an IPDS printer that has AFP(*YES) specified in the configuration.
• Output queue
• Paper size
The output attribute paper size is derived from the printer device description if the
output data stream format is PCL5 or PostScript.
7.4 Printing with the image print transform function
The image print transform function works with both ASCII and IPDS printers that
have AFP(*YES) specified in the configuration. When the image print transform
function is used, the transform does not take place until after the data stream is
spooled. Then, when the spooled file is printed or sent to a remote output queue,
it is first sent to the image print transform function to be transformed.
Once a printer device is created with the image print transform function enabled,
printing with the image print transform function is done automatically.
7.4.1 Printing to an ASCII printer
To enable the image print transform function when printing to an ASCII printer,
complete the following steps:
• Ensure that the spooled file is a *USERASCII spooled file.
• Verify that the printer device description has the TRANSFORM field set to
*YES.
• Verify that the printer device description has the IMGCFG field set to a valid
value other than *NONE.
The TRANSFORM field and the IMGCFG field can be set when the device
description is created with the CRTDEVPRT command, or changed after the
device description is created with the CHGDEVPRT command.
166 IBM AS/400 Printing V
7.4.2 Printing to an IPDS printer
To enable the image print transform function when printing to an IPDS printer that
has AFP(*YES) specified in the configuration, complete the following steps:
• Ensure that the spooled file is a *USERASCII spooled file.
• Verify that the printer device description has the IMGCFG field set to a valid
value other than *NONE.
The IMGCFG field can be set either when the device description is created with
the CRTDEVPRT command, or changed after the device description is created
with the CHGDEVPRT command.
7.4.3 Sending the spooled files
To enable the image print transform function when using remote system printing
for sending the spooled files through a remote output queue, complete the
following steps:
1. Ensure that the spooled file is a *USERASCII spooled file.
2. Verify that the output queue has the TRANSFORM field set to *YES.
3. Verify that the output queue has the IMGCFG field set to a valid value other
than *NONE.
The TRANSFORM field and the IMGCFG field can be set when the output queue
is created with the Create Output Queue (CRTOUTQ) command, or changed
after the output queue has been created with the Change Output Queue
(CHGOUTQ) command.
7.5 Image configuration objects
An image configuration object contains various printer characteristics that the
image print transform function and the convert image API use when creating
output. An image configuration object is basically a list of characteristics that is
supported by the printer it represents, acting as a template that guides the
transform process. Each image configuration object has values for the following
fields:
• Image format
• Photometric interpretation
• Bits per sample
• Resolution units
• Horizontal resolution
• Vertical resolution
• Compression type
• No-print borders (left, right, top, bottom)
All of these fields can be overridden by using the convert image API and
specifying a value for the field of the same name.
7.5.1 Values of image configuration objects
The following special values are allowed for the image configuration (IMGCFG)
field of the CRTDEVPRT, CHGDEVPRT, CRTOUTQ, and CHGOUTQ commands.
Chapter 7. Image print transform 167
You can also use these values when calling the convert image API. For more
information, see AS/400 System API Reference, SC41-5801.
Each special value is described in terms of the data streams that are supported,
the maximum resolution in dots per inch (dpi), and whether the printer has color
or does not support compression.
The following list contains examples of image configuration objects, grouped by
type of printer.
Note: For a complete list of all the image configuration objects, see AS/400
Printer Device Programming, SC41-5713, or AS/400 System API Reference,
SC41-5801.
• Printers supporting PCL data streams (*IMGA01-*IMGA09)
*IMGA01 PCL 300-dpi printer
*IMGA04 PCL 300-dpi color printer
• Printers supporting PostScript data streams (*IMGB01-IMGB15)
*IMGB01 PostScript 300-dpi printer
*IMGB04 PostScript 300-dpi color printer
• Printers supporting IPDS data streams (*IMGC01-*IMGC11)
*IMGC01 IPDS 240-dpi printer
*IMGC02 IPDS 300-dpi printer
• Printers supporting PCL and PostScript data streams (*IMGD01-*IMGD11)
*IMGD01 PCL/PostScript 300-dpi printer
*IMGD02 PCL/PostScript 600-dpi printer
The recommended image configuration objects for some common printers are in
the following list.
Note: For a complete list, see AS/400 Printer Device Programming, SC41-5713,
or AS/400 System API Reference, SC41-5801.
*IMGB11 Epson Stylus Color 600, 800 with PostScript
*IMGD01 HP Laserjet III, IIID, IIISi, 4L with PostScript
*IMGA02 HP Laserjet 4, 4P, 4V, 4Si, 4 Plus
*IMGA02 HP Laserjet 5, 5P, 5Si
*IMGA02 HP Laserjet 6, 6P, 6L
*IMGC01 IBM 3130, 3160-1 AF Printer (240-pel mode)
*IMGC02 IBM 3130 AF Printer (300-pel mode)
*IMGC06 IBM 4028 Laser Printers
*IMGB05 IBM 4303 Network Color Printer
*IMGC06 IBM 4312, 4317, 4324 NP with IPDS feature (LAN)
*IMGA02 IBM 4312, 4317, 4324 NP (ASCII/LAN)
*IMGD02 IBM 4312, 4317, 4324 NP with PostScript (ASCII/LAN)
*IMGC03 IBM Infoprint 60
*IMGC05 IBM Infoprint 62 Model 2
*IMGC06 IBM Infoprint 62 Model 3
*IMGC05 IBM Infoprint 4000
*IMGA02 Lexmark Optra S Printers
*IMGD05 Lexmark Optra SC Color Printer
*IMGA02 Okidata OL800, OL810 LED Page Printers
168 IBM AS/400 Printing V
*IMGD04 QMS Magicolor CX
*IMGB06 Tektronix Phaser 560
*IMGA02 Xerox 4230 DocuPrinter
7.6 Printing with the convert image API
The convert image QIMGCVTI API provides the same transform capabilities as
the image print transform function. In addition, printing with the convert image
API gives the user more control over how the output looks than the image print
transform function offers. It gives the user the ability to immediately transform a
data stream when delaying the transform is not desired. It also has more options
regarding the type of input object and output object. The convert image API
supports input and output from an integrated file system (IFS) file, a spooled file,
or main storage.
The convert image API can generate a spooled file that is transformed with the
image print transform function. When this is done, the convert image API stores
all the values needed to do the transform in the user-defined data attribute of the
spooled file for later use by the image print transform function when the transform
is performed. For more information on how to use the convert image API, see the
AS/400 System API Reference, SC41-5801.
7.7 Converting PostScript data streams
Converting PostScript data streams is performed differently from converting
image data streams. PostScript conversion requires the font files to rasterize the
data. You can also find more debugging and message information if the
PostScript file does not convert correctly.
7.7.1 Fonts
To convert PostScript files effectively, PostScript fonts are required to convert text
and symbols into bit-mapped images. The following lists of fonts are supplied by
IBM for use with the image print transform function. Each set of fonts is located in
the IFS in the specified directory. For each font name, there is a corresponding
font file containing rasterization information. This information is stored in the
psfonts.map file.
Note: Do not alter the font files or the psfonts.map file shipped with OS/400.
Changing a font file or font mapping can cause the image print transform function
to produce unpredictable as well as undesirable results.
The Latin fonts are stored in the /QIBM/ProdData/OS400/Fonts/PSFonts/Latin
directory.
The Symbol fonts are stored in the
/QIBM/ProdData/OS400/Fonts/PSFonts/Symbols directory.
Note: For a list of the IBM supplied PostScript fonts, see AS/400 Printer Device
Programming, SC41-5713.
Chapter 7. Image print transform 169
7.7.2 User-supplied fonts
To enhance the capabilities of the image print transform function, you can add
your own font files to be used in conjunction with the IBM-supplied fonts shipped
with OS/400. These fonts are called user-supplied fonts. They need to be stored
in the /QIBM/UserData/OS400/Fonts/PSFonts directory:
The user-supplied font mapping file (psfonts.map) is stored in the same directory
as the user supplied fonts. It behaves the same way as the psfonts.map file that
is shipped with OS/400. An important difference is that you can find user-supplied
fonts by looking first at the user-supplied font mapping file and then at the
OS/400 font mapping file.
To add a user-supplied font, complete the following steps:
1. Use an ASCII text editor to open the psfonts.map file located in
/QIBM/UserData/OS400/Fonts. If this file does not exist, you need to create it.
2. Add a new line to the file to include the new font name and associated path
and file name, for example:
font MyNewFont /QIBM/UserData/OS400/Fonts/PSFonts/MNF.PFB
Here, MyNewFont is the name of the font, and MNF.PFB is the associated font
file.
3. Save the new psfonts.map file.
4. Copy the font file into the directory specified in the psfonts.map file.
To delete a user-supplied font, simply remove the line mapping the font name to
its associated file in psfonts.map, and remove the font file from the AS/400
system.
7.7.3 Font substitution
When a font requested within a PostScript data stream is not available on the
AS/400 system, a font substitution can be defined if there is a similar font
available. Font substitution is the mapping of a font name to a font that is
available and similar (in terms of its rasterization properties) to the font file being
replaced. You can also specify font substitution if existing font mapping is
producing undesirable output.
To define a font substitution, complete the following steps:
1. Use an ASCII text editor to open the psfonts.map file that is located in
/QIBM/UserData/OS400/Fonts. If this file does not exist, you need to create it.
2. Add a new line to the file to include the font name and the path and file name
of the font file you want to use as a substitute, for example:
font Courier /QIBM/UserData/OS400/Fonts/PSFonts/HEL.PFB
3. Save the new psfonts.map file.
170 IBM AS/400 Printing V
7.8 Troubleshooting
The following answers are to questions that may arise when you use the image
print transform function or convert image API:
• Why does it take so long to process PostScript data streams?
One reason why PostScript data streams take a long time to process is the
amount of information that needs to be transformed. Color documents
especially require large amounts of memory and many data conversions,
which means longer processing times.
Note: If the photometricity of the converted data stream is not requested, it is
assumed, by default, to be RGB, or color. However, if you know you do not
want RGB, or the data stream is not color, specify an image configuration
object that only supports black and white output. This greatly increases the
throughput of the image print transform function and speeds up PostScript
processing.
• Why is the converted data stream positioned incorrectly on or off the page?
Why is it not centered?
The resolution specified in the image configuration object is probably not
supported by the printer with which the object is configured. When this
happens, an incorrect no-print border is retrieved from the image configuration
object and the data is consequently positioned incorrectly on the output page.
The printer may also be set up to automatically add a no-print border, which
will cause the output generated by the image print transform function to be
shifted on the page. Verify that the correct image configuration object is being
used with the printer, and that the printer has been set up properly and has
been physically calibrated.
• Why did my PostScript data stream not generate a new data stream?
Chances are that the PostScript data stream did not contain any printable
data. To verify this, check the job log of the writer invoking the image print
transform function. Look for a message indicating no printable data was found.
If no message exists, an error may have occurred processing the file, in which
case, refer to the PostScript processing job for more information.
• Why is the printed image three times the original size when converted from
color or gray scale to black and white?
When a color image or gray scale image is converted to black and white, a
dithering process takes place. In this process, a single color or gray scale
pixel is transformed into a 3x3 matrix of pixels. Each pixel within this matrix is
either black or white, depending on the color being rendered.
© Copyright IBM Corp. 2000 171
Chapter 8. Remote system printing
Remote system printing allows spooled files created on an AS/400 system to be
automatically sent to and printed on other systems.
8.1 Remote system printing overview
The source system must be at Version 3.0 Release 1.0 or later to support remote
system printing. The spooled files are sent from an output queue using the Start
Remote Writer (STRRMTWTR) command. The STRRMTWTR command allows
spooled output files to be automatically sent to other systems using SNA
distribution services (SNADS), Transmission Control Protocol/Internet Protocol
(TCP/IP), or Internetwork Packet Exchange (IPX). A user-defined connection is
also supported with all the destination types (DESTTYPE).
Figure 122 shows the physical connections and the communications protocols
used to connect the remote systems.
Figure 122. Remote system printing overview
The following parts of remote system printing are already documented with
configuration examples, supported data stream tables, and AFP resources
considerations in either AS/400 Printer Device Programming, SC41-5713, or
AS/400 Printing IV, GG24-4389, and are not discussed in this chapter.
• AS/400 to AS/400 Version 3 and later
• AS/400 to AS/400 Version 2
• AS/400 to S/390 system
• AS/400 to Print Services facility/2 (PSF/2)
• AS/400 to RS/6000 (with destination type *OTHER)
Note: See Appendix H, “AS/400 to AIX printing” on page 367, for more
information.
SNA
TCP/IP
DESTTYP:
*OS/400
DESTTYP:
*OS/400V2
DESTTYP:
*S390
DESTTYP:
*PSF2
DESTTYP:
*OTHER
DESTTYP:
*NETWARE3
DESTTYP:
*NDS
IPX
IPX
SNA
TCP/IP
TCP/IP
SNA
PSF/2
Other
AS/400
NetWare4
NetWare3
AS/400 Output
Queue
AS/400
V2
S/390
SNA
172 IBM AS/400 Printing V
8.2 AS/400 system and TCP/IP LPR-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
(SNTCPSPLF) command, the TCP/IP LPR command, or remote system printing
provide this function by allowing you to specify what 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
(Figure 123).
Figure 123. TCP/IP line printer requester: Line printer daemon
The objective of this section is to explain the case when the target printer is
connected using an interface such as an IBM Network Printer with a LAN card, an
IBM Network Print Server, an HP JetDirect card, or a Lexmark MarkNet XLe.
Note: If the target printer supports PJL/PCL commands and you are at Version
3.0 Release 7.0 or later, we recommend that you connect your printer directly on
the LAN with the PJL driver. For detailed information, see 11.2.2, “Configuring
LAN-attached ASCII printers using PJL drivers” on page 241.
8.2.1 Creating the output queue
To create the remote output queue for your printer. Follow these steps:
1. Type the CRTOUTQ (Create Output Queue) command on any command line and
press the F4 (Prompt) function key. The display shown in Figure 123 appears.
Note: The following Create Output Queue displays are at V3R7 and later.
Some parameters are not present at V3R1, V3R2, or V3R6.
Return Code
Data File(s)
Control File
Host Print
Transform
L
P
R
AS/400
Output Queue
Remote Printer
Queue
L
P
D
Printer
Chapter 8. Remote system printing 173
Figure 124. Create Output Queue (Part 1 of 6)
2. On this display, enter the following parameter values:
• Output queue: The name of your output queue (in this example, RMT)
• Library: A library name (in this example, MYLIB)
• Remote system: *INTNETADR or the host name (if defined in TCP/IP Host
Table Entries)
Leave the default value for the other parameters, and press the Enter key to
continue. The display shown in Figure 125 appears.
Figure 125. Create Output Queue (Part 2 of 6)
3. On this display, enter the parameter value for Remote printer queue. The
name of the remote printer queue is determined by the interface used. In this
example, the target printer is an IBM Network Printer with a LAN interface card
and the queue name is PASS. See 12.1.9, “Remote printer queue names” on
page 258, for the recommended queue names depending on the type of
interface used (HP JetDirect, MarkNet XLe, and so on).
To continue, press the Page Down key. The display shown in Figure 126 on page
174 appears.
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Output queue . . . . . . . . . . RMT Name
Library . . . . . . . . . . . MYLIB 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
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Output queue . . . . . . . . . . > RMT Name
Library . . . . . . . . . . . MYLIB 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...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
174 IBM AS/400 Printing V
Figure 126. Create Output Queue (Part 3 of 6)
4. On this display, enter the following parameter values:
• Writer to autostart: 1
• Connection type: *IP
• Destination type: *OTHER
Leave the default values for the other parameters, and press the Enter key to
continue. The display shown in Figure 127 appears.
Figure 127. Create Output Queue (Part 4 of 6)
5. On this display, leave the default value (*YES) for the host print transform
parameter. To continue, press the Enter key. The display shown in Figure 128
appears.
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
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...
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Writers to autostart . . . . . . *NONE 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
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 8. Remote system printing 175
Figure 128. Create Output Queue (Part 5 of 6)
6. On this display, enter the following parameter values:
• Manufacturer type and model: Enter a value according your target printer
type (in this example, *IBM4317).
• Internet address: The IP address of your printer (in this example, 123.1.2.3)
Note: The Internet address is only prompted for if *INTNETADR is specified
for the remote system.
• Destination options: *NONE, see the following section for a discussion of
this parameter.
• Print separator page: For V3R7 and later, enter *YES or *NO. For V3R1,
V3R2, and V3R6, see 8.2.3, “Separator pages” on page 178, for an alternate
solution.
To continue, press the Page Down key to view the display shown in Figure
129.
Figure 129. Create Output Queue (Part 6 of 6)
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Writers to autostart . . . . . . *NONE 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
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Internet address . . . . . . . . '123.1.2.3'
Destination options . . . . . . *NONE
Print separator page . . . . . . *YES *YES, *NO
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Output Queue (CRTOUTQ)
User defined option . . . . . . *NONE Option, *NONE
+ for more values
Type choices, press Enter.
User defined object:
Object . . . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Object type . . . . . . . . . *DTAARA, *DTAQ, *FILE...
User driver program . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Text 'description' . . . . . . . Remote output queue for 4317
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
176 IBM AS/400 Printing V
7. Enter a text description for your output queue (in this example, “Remote
output queue for 4317”) and leave the default values for the other parameters
(these parameters are V3R7 only).
8. Press the Enter key to create the output queue.
9. When the configuration is completed, complete the following steps:
a. Test the TCP/IP connection, using the PING command, with the IP address
of your printer.
b. If the PING is successful:
• Start the remote writer:
STRRMTWTR OUTQ(outputq_name)
• Print something (for example, a print screen).
c. If either the PING fails or you are unable to print, then you are in
troubleshooting mode (see 12.1, “Communication, connection, and
configuration problems” on page 253).
8.2.2 Destination options
When CNNTYPE(*IP) is specified, destination-dependent options are added to
the control file that is sent to the LPD server. When CNNTYPE(*IPX) is specified,
this field is used to determine how spooled files are handled once they are sent to
the remote system.
The destination options are up to 128 characters of filters and predefined options
enclosed in apostrophes. The options are separated by one or more blanks.
Note: Anything that is not recognized as a filter, a predefined option, or a
reserved character is passed to the remote system.
The following predefined options apply to processing by LPR under OS/400 and
are specified in the DESTOPT parameter:
• *USRDFNTXT
This predefined option sends the current user-defined text of the user profile
as options to the remote system. The user-defined text of the user profile can
be set using the system application program interface (API) CHGUSRPRTI.
The text can be displayed using the system API DSPUSRPRTI or by
displaying the spooled file attributes.
• *NOWAIT
This option is only valid if the connection type *IPX is used.
• J
This option overrides the default job name for the banner page printed on the
remote system, if a banner page is printed at all. The characters immediately
following the “J” are used as the job name. For example, to specify a job name
of “Id12”, specify:
DESTOPT('JId12')
• XAIX
This option is used in the TCP/IP environment only. This option tells the local
AS/400 system how to produce multiple copies on the remote system.
Chapter 8. Remote system printing 177
If “XAIX” is not specified (the default), one print command per copy requested
is placed in the control file. This control file and a single copy of the data is
then sent to the remote system. However, some remote systems (similar to
most direct LAN attached printers) ignore multiple print commands within the
control file. Therefore, the other method might be preferred.
If “XAIX” is specified, OS/400 places one print command in the control file and
sends it together with the data multiple times to the remote system, depending
on the Number of copies parameter of the spooled filed attributes.
Note: If the XAIX option has been specified, but the LPD does not support this
method, message TCP3701 (Send request failed for spooled file) is returned.
However, one copy may still print, depending on the LPD implementation.
When the send request fails, the remote writer will try sending again,
continuing until the spooled file is held.
• XAUTOQ
If the connection to the remote system times out during transformation of the
spooled file into ASCII by the host print transform, with this option, the
transformed spooled file is sent back to the same output queue using the
AS/400 LPD server rather than failing with a timeout error. The transformed
spooled file name is modified to be unique. Then, since the spooled file is
already in ASCII, it is sent directly to the target printer without any
transformation and avoids a timeout.
Note: When using TCP/IP LPR-LPD and the host print transform function, we
recommend that the subsystem QSPL has a minimum size of 6 MB.
To implement this function, you need to specify the new DESTOPT parameter,
XAUTOQ. On the LPR, or the SNDTCPSPLF, CRTOUTQ, or CHGOUTQ
command, the parameter is capitalized. The AS/400 LPD server must also be
running. Check for server jobs with the command:
WRKACTJOB SBS(QSYSWRK) JOB(QTLPD*)
This displays all LPD servers started with names QTLPDnnnnn, where nnnnn
are unique identifying numbers. If no servers are displayed or you want to
start an additional server, use the command:
STRTCPSVR SERVER(*LPD)
The number of servers started is determined by the TCP/IP configuration.
Starting multiple servers increases their availability since each processes one
job at a time.
Messages are logged to indicate whether auto-queueing is needed. When the
following messages are received, the remote system times out and the
transformed spooled file is sent to the same output queue:
TCP342F Remote host system closed connection unexpectedly.
TCP3600 Spooled file sent.
When the following messages are received, the remote system times out and
the AS/400 LPD server is not available to receive the transformed spooled file:
TCP342F Remote host system closed connection unexpectedly.
TCP3701 Send request failed for spooled file.
When the transformed spooled file is sent to the original output queue, the
spooled file name is changed to LPDzzzz to indicate that it was received by
LPD. zzzz indicates identifying alphanumeric characters. The job name is
178 IBM AS/400 Printing V
changed to QPRTJOB, and the user data is set to the original file name. The
job number and spooled file number are determined from the LPD server. The
original spooled file can be kept or deleted. This occurs after the file has been
sent, even if it is sent back to the original queue. If the transformed file is sent
to the original queue, it is deleted after it has been sent to the remote system.
Most of the commands and filters of the line printer daemon protocol can be
specified in the DESTOPT parameter, but some are reserved for use by LPR.
These exceptions are:
• Supported print filters:
Any option starting with one of the following characters is interpreted as a print
filter. This character is built into the print command sent to LPD in the control
file. The filter is for use by the LPD daemon to modify the printed output, but
how this is used depends on the LPD implementation.
c, d, f, g, l, n, p, r, t, and v
The meaning of some flags are:
– f: Print file as plain text. Many ASCII control characters may be discarded
(except BS, CR, HT, FF, and LF).
– l: This flag is the default. It keeps all ASCII control characters.
– p: This filter causes the file to be printed in “pr” format. It prints headings
(date, time, title, etc.) and page numbers.
• Reserved characters:
There are also some reserved characters. These character are used by the
SNDTCPSPLF command for the control file. An option must not start with one
of the following characters:
K, C, H, I, L, M, N, P, S, T, U, W, 1, 2, 3, and 4
For example, CLASS=ASCII is not allowed because the character “C” is
reserved for use by the SNDTCPSPLF command. However, “-CLASS=ASCII”
is permitted.
The meaning of some characters are:
– H: Name of the sending host, set by LPR to the AS/400 configured name.
– L: Print banner page command, added by LPR if print separator page *YES
is specified (default).
– M: Send mail to a given user ID when printed (not supported).
The meaning of the previous commands and filters can be found in the line
printer daemon protocol reference documentation. This documentation has no
IBM form number, but can be found in several places on the Internet.
8.2.3 Separator pages
The Print separator page parameter is only available on V3R7 and later. If you
are running V3R1, V3R2, or V3R6, you can suppress the separator page by
creating data area QTMPLPR of type *CHAR in library QTCP. Specify an
authority of *USE to prevent normal users from changing the data area:
CRTDTAARA DTAARA(QTCP/QTMPLPR) TYPE(*CHAR) AUT(*USE)
Chapter 8. Remote system printing 179
Note: This task must be performed by someone who has at least *CHANGE
authority to the QTCP library.
The option to omit the separator page request is turned on or off based on the
value of the first character in the data area. If this character is a capital N, the
option is enabled. If it is any other character, the option is disabled. If the data
area does not exist, the option is disabled.
• To enable (suppress the separator page) enter:
CHGDTAARA DTAARA(QTCP/QTMPLPR (1 1)) VALUE('N')
• To disable (print the separator page) enter:
CHGDTAARA DTAARA(QTCP/QTMPLPR (1 1)) VALUE(' ')
8.2.4 ‘Load Letter’ message on the printer
If the host print transform function is used and if the page size parameter in your
printer file does not match a page size entry in the MFRTYPMDL (Manufacturer
type, and mode) or WSCST (Workstation Customizing) object, Letter format is
used as the default format. In this case, if the printer is loaded with a paper format
other than Letter, the message “Load Letter” may be displayed on your printer.
This problem occurs especially when using an A4 paper format. To circumvent
the problem, complete the following steps according to your OS/400 version and
release, substituting your own values for the various parameters:
8.2.4.1 For V3R1 and V3R6
Follow these steps:
1. To retrieve the workstation customized object, type the following command:
RTVWSCST DEVTYPE(*TRANSFORM) MFRTYPMDL(*IBM4317) SRCMBR(NP17SRC)
SRCFILE(QGPL/QTXTSRC)
Note: For the MFRTYPMDL parameter, enter a value depending on your
target printer (in this example, *IBM4317), and use your own values for
SRCMBR and SRCFILE.
2. Use SEU to edit the source file:
STRSEU SRCFILE(QGPL/QTXTSRC) SRCMBR(NP17SRC)
3. Page through the source file until you find the following tag (around statement
0001.67):
:PAGESIZE
PAGWTH=12240
PAGLEN=15840
DATA='1B266C303241'X.
4. Change the escape sequence in the DATA parameter to:
DATA='1B266C323641'X.
Note: This changes the value Letter ('3032') to A4 ('3236').
5. Exit the SEU source edit (press F3 and Enter).
6. To create a customized workstation configuration object, type the following
command:
CRTWSCST WSCST(QGPL/NP17A4) SRCMBR(NP17SRC)
180 IBM AS/400 Printing V
You will receive the message “Customization object NP17A4 created
successfully”.
7. Stop the remote writer:
ENDWTR WTR(outputq_name) OPTION(*IMMED)
8. To change the output queue, enter the CHGOUTQ command, and press the F4
(Prompt) function key. Then page down until you find the parameters shown in
Figure 130.
Figure 130. Change Output Queue: HPT and WSCST parameter
On this display, enter the following parameter values:
• Manufacturer type and model: *WSCST
• Workstation customizing object: NP17A4 (the object that you created
with the command CRTWSCST)
• Library: QGPL (the library specified in the CRTWSCST command)
9. Press the Enter key to modify your output queue.
8.2.4.2 For V3R2, V3R7, and later
Follow these steps:
1. To retrieve the workstation customized object, type the following command:
RTVWSCST DEVTYPE(*TRANSFORM) MFRTYPMDL(*IBM4317) SRCMBR(NP17SRC)
SRCFILE(QGPL/QTXTSRC)
Note: For the MFRTYPMDL parameter, enter a value depending on your
target printer (in this example, *IBM4317), and use your own values for
SRCMBR and SRCFILE.
2. Create a customized workstation configuration object:
CRTWSCST WSCST(QGPL/NP4317) SRCMBR(NP17SRC)
You will receive the message “Customization object NP4317 created
successfully”.
3. Stop the remote writer:
ENDWTR WTR(outputq_name OPTION(*IMMED)
4. To change the output queue, enter the CHGOUTQ command, and press the F4
(Prompt) function key. Then page down until you find the parameters shown in
Figure 131.
Change Output Queue (CHGOUTQ)
Type choices, press Enter.
......................... ....... ........
......................... ....... ........
Host print transform . . . . . . *YES *YES, *NO
Manufacturer type and model . . *WSCST
Workstation customizing object NP17A4 Name, *NONE
Library . . . . . . . . . . . QGPL Name, *LIBL, *CURLIB
......................... ....... ........
......................... ....... ........
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 8. Remote system printing 181
Figure 131. Change Output Queue: HPT and WSCST parameter
On this display, enter the following parameter values:
• Manufacturer type and model: *WSCSTA4
• Workstation customizing object: NP4317 (the object that you created
with the command CRTWSCST)
• Library: QGPL (the library specified in the CRTWSCST command)
5. Press the Enter key to modify your output queue.
8.3 AS/400 and NetWare printing
Beginning with Version 3.0 Release 7.0 of OS/400, remote system printing can
now send spooled files to a NetWare server using the Internetwork Packet
Exchange (IPX) protocol. The NetWare server can be either on the Integrated PC
Server or a PC.
When you have the Enhanced Integration for NetWare feature (an optional part of
OS/400 (5716-SS1 for V3R7 or 5769-SS1 for V4R1 and V4R2)), you can print
from the AS/400 system to NetWare printers that use the standard NetWare print
support.
NetWare uses a print queue, a print server, and a printer to allow a workstation to
print to a network printer. The print queue is the object that temporarily holds the
print job file until the job is printed. See Figure 132 for an illustration of the
AS/400 system to NetWare printing process.
Figure 132. AS/400 system to NetWare printing
As each user's spooled job is processed on the output queue, the AS/400 system
authenticates a connection for the user to the appropriate server. Each user must
Change Output Queue (CHGOUTQ)
Type choices, press Enter.
......................... ....... ........
......................... ....... ........
Host print transform . . . . . . *YES *YES, *NO
Manufacturer type and model . . *WSCSTA4
Workstation customizing object NP4317 Name, *NONE
Library . . . . . . . . . . . QGPL Name, *LIBL, *CURLIB
......................... ....... ........
......................... ....... ........
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
IPX
STRRMTWTR
to Output Queue
RMTNW
Printer
Remote Output
Queue: RMTNW
NetWare Server
Print Queue
Spool File
Spool File
Spool File
Spool File
182 IBM AS/400 Printing V
have a NetWare authentication entry or use the Start NetWare Connection
(STRNTWCNN) command to start a NetWare connection manually.
The Add NetWare Authentication Entry (ADDNTWAUTE) command adds
authentication information for a server to a user profile. The information specifies
how the user signs on to the server. This information is used to start
authenticated connections to servers. An authenticated connection to a server is
required to issue requests to the server. If an authenticated connection does not
exist, the system attempts to start a connection using data stored in the
authentication entries.
Note: Ideally, each user has an authentication entry authorizing them to the
specified NetWare print queue. If users do not have an authentication entry, they
must specify AUTJOB(*ANY) on the STRNTWCNN command.
8.3.1 Preparing for remote system printing
Preparation work must be done on both the source system (AS/400 system) and
target system (NetWare server) for remote system printing to work. The following
list shows what must be present or created before remote system printing can be
used:
• On the AS/400 system Version 3.0 Release 7.0 or later, ensure that the
Enhanced Integration for NetWare is installed.
• On the AS/400 system, configure and start Internet Packet Exchange (IPX)
configuration support. For IPX configuration, see Internet Packet Exchange
(IPX) Support, SC41-3400.
• On the NetWare Server, load the NetWare Enhanced Integration NLM. The file
to be loaded is AS4NW410 for NetWare 4.10, or AS4NW312 for NetWare 3.12
servers.
• On the AS/400 system, use the STRNTWCNN AUTJOB(*ANY) command to connect
to the NetWare server, or use the ADDNTWAUTE command if you want to start the
STRNTWCNN automatically.
• On the NetWare server, ensure the NetWare User specified on the
STRNTWCNN or ADDNTWAUTE command is a valid NetWare user.
• On the AS/400 system, use the CRTOUTQ command to create the remote
output queue for NetWare printing.
• On the NetWare server, ensure the NetWare queue exists on a volume of a
server that runs the NetWare Enhanced Integration NLM.
8.3.2 Creating an output queue
To create the remote output queue, type the Create Output Queue (CRTOUTQ)
command on any command line, and press the F4 (Prompt) function key. The
display shown in Figure 133 appears.
Chapter 8. Remote system printing 183
Figure 133. Create Output Queue (Part 1 of 2)
On this display, enter the following parameter values:
• Output Queue: The name of your output queue (in this example, RMTNTW).
• Library: A library name (in this example, MYLIB).
• Remote system: For DESTTYPE(*NETWARE3), specify the name of the
server for the Remote System parameter value.
For DESTTYPE(*NDS), you can specify either the name of the tree or the
special value *NWSA for the remote system parameter. If you use *NWSA, the
tree name is from DSPNWSA OPTION(*NETWARE).
In this example, we use DESTTYPE(*NDS) and the remote system name is
the tree name IBM_TREE1.
• Remote printer queue: For DESTTYPE(*NETWARE3), specify the name of
the server for the Remote Printer Queue parameter value.
For DESTTYPE(*NDS), the Remote Printer Queue parameter can be a
distinguished name that begins with a period. If the name does not begin with
a period, the name is a partial name and is used in conjunction with the NDS
context specified in the system network server attributes (DSPNWSA) to form
the distinguished name of the NetWare print queue.
In this example, we use DESTTYPE(*NDS), and the Remote Printer Queue
parameter is a distinguished name that begins with a period
(.NTW_QUEUE.ASPRT.NTWHP).
To continue, press the Page Down key until the display, like the example shown in
Figure 134 on page 184, appears.
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Output queue . . . . . . . . . . > RMTNTW Name
Library . . . . . . . . . . . MYLIB 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 . . . . . . . . . > IBM_TREE1
Remote printer queue . . . . . . .NTW_QUEUE.ASPRT.NTWHP
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
184 IBM AS/400 Printing V
Figure 134. Create Output Queue (Part 2 of 2)
Complete the parameters as shown in this list:
• Writer to autostart: 1
• Connection type: *IPX
• Destination type: *NETWARE3 or *NDS - (in this example, *NDS)
• Host print transform: *YES
• Manufacturer type and model: Enter a value according to your target printer
type (in this example, *IBM4039HP)
• User-defined option: *NONE, *NOWAIT, *BANNER
• *NOWAIT: The spooled file is removed from the AS/400 queue as soon as
the entire file is sent to NetWare queue. If you do not select this option, the
spooled file remains in the AS/400 output queue until the file is removed
from the NetWare queue, which occurs either when the file is printed or
when a NetWare utility is used to delete it.
• *BANNER='text': Specify up to 12 characters that you want to print on a
NetWare banner page. The banner page, which precedes the NetWare
print job, also prints the user name.
Note: You must type *BANNER in uppercase letters. Enclose the text in
single quotes, and make sure there are no spaces before and after the
equal sign.
Press the Enter key to create the RMTNTW remote output queue.
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Writers to autostart . . . . . . 1 1-10, *NONE
Queue for writer messages . . . QSYSOPR Name
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Connection type . . . . . . . . > *IPX *SNA, *IP, *IPX, *USRDFN
Destination type . . . . . . . . > *NDS *OS400, *OS400V2, *PSF2...
Host print transform . . . . . . *YES *YES, *NO
Manufacturer type and model . . *IBM4039HP
Workstation customizing object *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Destination options . . . . . . *NONE
User defined option . . . . . . *NONE Option, *SAME, *NONE
+ for more
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
© Copyright IBM Corp. 2000 185
Chapter 9. Client Access/400 printing
This chapter covers printing in the Client Access for Windows 95/NT
environment. In this environment, it is possible to print PC application output on
an AS/400 printer, AS/400 application output on a PC printer, or, by using a
combination of these functions, print PC application output on another PC printer.
9.1 Client Access/400 printing overview
The ability to use 5250 printer emulation over native TCP/IP connections was
introduced with Client Access for Windows 95/NT Version 3 Release 1
Modification 3 when OS/400 Version 4 Release 2 was available.
When using AS/400 Client Access for your printing needs, two different types of
printing capabilities are provided:
• Printing PC application output to SCS, IPDS, or ASCII printers attached to the
AS/400 system:
This function is called Network Printing (previously called Virtual Print). It
allows PC users to identify AS/400-attached printers as their network attached
printer.
Client Access/400 provides SCS and AFP Printer Drivers, which convert PC
application output from ASCII to EBCDIC if the target printer is an SCS or
IPDS printer. This conversion occurs on the PC before the spooled file is
placed in an AS/400 output queue.
Note: The application output type also determines which driver, SCS or AFP,
can be used.
Windows drivers have to be used if the target printer is an ASCII printer. In this
case, the spooled file in the AS/400 output queue is shown with a
*USERASCII Device Type (DEVTYPE) attribute.
• Printing AS/400 application output on a PC-attached printer:
In this case, AS/400 spooled files in an SCS or an AFP data stream must be
converted into an 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 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.
186 IBM AS/400 Printing V
Note: For detailed information on host print transform, see Chapter 6, “Host
print transform” on page 137.
Redirecting PC application output via 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 PC application output.
9.2 Client Access/400 Network Printing
The Client Access/400 Network Printing (previously named virtual print) function
allows you to print from a PC application to a printer attached somewhere in the
network that is defined to an AS/400 system. The following examples of
AS/400-attached printers can be used as target printers:
• SCS printers, twinax attached
• IPDS printers, configured AFP(*NO) or AFP(*YES), twinax or LAN attached
• ASCII printers, attached to PCs, displays, or LAN attached
For more information on printer attachment methods, see 1.4, “AS/400 printer
attachment methods” on page 15.
9.2.1 Configuring an AS/400 printer to Windows 95
This example shows all the necessary steps to configure an AS/400-attached
printer to Client Access for Windows 95/NT. Windows 95 was used for this
example.
1. Start the Add Printer wizard. The wizard can be started in several ways, for
example:
• Open the folder My Computer->Printers, and double-click the Add
Printer icon.
• Click Start->Settings->Printers, and double-click the Add Printer icon.
2. The Add Printer Wizard window is shown. On this window, click Next. The
window shown in Figure 135 appears.
Chapter 9. Client Access/400 printing 187
Figure 135. Defining the attachment method of the printer
3. Click the Network printer radio button, and then click Next. The window
shown in Figure 136 appears.
Figure 136. Network path or queue name
4. Click Browse to find the AS/400 system to which the printer is attached. The
window shown in Figure 137 on page 188 appears.
188 IBM AS/400 Printing V
Figure 137. Browse for Printer (Part 1 of 2)
5. On the Browse for Printer window, select the AS/400 system by clicking the +
(plus) sign. The list of the printers attached to the selected AS/400 system as
shown in Figure 138 appears.
Figure 138. Browse for Printer (Part 2 of 2)
6. Select the printer you want to use, and click OK.
Chapter 9. Client Access/400 printing 189
Note: Instead of browsing the network, you can directly enter the network path
or queue name. In this case, enter on of the following options:
\\Systemname\Printername
\\Systemname\Printername;Profilename
\\Systemname\/OutqueueLibraryname/Outqueue
\\Systemname\/OutqueueLibraryname/Outqueue;Profilename
7. The Add Printer Wizard window (Figure 139) shows the path to the printer.
Click Next.
Note: If you do not need to print from DOS-based programs, click Next.
Otherwise, click Yes. For the Capture Printer Port, select the LPT port. Then,
click OK and Next. This is only necessary when a PC application cannot print
directly to a Windows 95/NT printer driver.
Figure 139. Path to the printer
8. The window now lets you choose the manufacturer, type, and model of the
printer (Figure 140 on page 190). When selected, click Next.
Note: These drivers need to be installed in Client Access. If they are not there,
use Selective Install via Client Access to install them.
190 IBM AS/400 Printing V
Figure 140. Manufacturer and model of the printer
9. On the window shown in Figure 141, confirm the supplied printer name or
change it. Also, specify if you want to use it as default printer for the Windows
applications. The default value is “No”. Then click Next.
Figure 141. Installing as a default printer
10.The Add Printer Wizard window displayed allows you to print a test page on
the selected printer. To print it, click Finish.
11.Then you see a window asking you if the test page printed correctly. Click Yes
or No depending on the output received. This ends the configuration.
Chapter 9. Client Access/400 printing 191
9.2.2 Network printer setup
Once you have installed a network printer with the default options, you may need
to configure it further. The following example was performed using Client
Access/400 for Windows 95/NT Version 3 Release 1 Modification 3 with Windows
95:
1. Right-click the printer icon, and select Properties from the pop-up menu.
2. On the General page, you can enter a comment that is visible when you share
the printer with other users and when they set up your printer. You can also
print a test page from there.
3. The Details page of the printer properties notebook (Figure 142) is mainly
used to select a driver. Choose or configure the port, and set the spooling
options.
Figure 142. Printer properties: Details page for Windows 95
4. The last page of the properties notebook is labeled Options (Figure 142). On
this page, you can define the AFP driver options. See Chapter 5, “The IBM
AFP Printer Driver” on page 117, for detailed information on the AFP driver.
9.2.3 AS/400 print profile
The following example, based on Client Access/400 for Windows 95/NT Version 3
Release 1 Modification 3 with Windows 95, shows the steps required to add or
change an AS/400 print profile:
1. Select the Client Access icon, and then the Client Access Properties icon.
On the Client Access Properties window, select Printer profiles.
2. On the Printer Profiles windows, you can add a new profile or modify an
existing one (for example, the Default AS/400 Print Profile).
192 IBM AS/400 Printing V
Click Add, or select an existing profile and click Change. In this case, the
window shown in Figure 143 appears.
Figure 143. Adding an AS/400 print profile
3. On the Change or Add AS/400 Print Profile, you can specify the following
values:
a. Type a descriptive name for your profile if you are in the Add AS/400 Print
Profile window.
b. The Type of data parameter allows you to specify in which data stream the
data is sent to the AS/400 system. You can select one of the following
options:
• Auto-select: The data type is automatically selected.
• Use printer file: The data type specified in the DEVTYPE (Device
Type) parameter of the default or user-specified AS/400 printer file is
used. In this case, the DEVTYPE parameter must be *SCS, *AFPDS, or
*USERASCII.
• SCS: A spooled file of type *SCS (SNA Character String) is generated.
• AFPDS: A spooled file of type *AFPDS (Advanced Function Printing
Data Stream) is generated.
• User ASCII: A spooled file of type *USERASCII (User ASCII) is
generated.
Chapter 9. Client Access/400 printing 193
Considerations on data type selection
• If your target printer is an ASCII printer, specify User ASCII. This will
avoid any further transformations.
• If the application output is graphical (such as output from Microsoft
Word, AmiPro, Freelance) and must be printed on an IPDS printer
configured AFP(*YES), specify data type AFPDS.
Note: Even if host print transform can transform AFPDS to ASCII,
specify User ASCII if the target printer is an ASCII printer.
• If the application output is text only, specify data type SCS if the target
printer is SCS or IPDS configured AFP (*YES) or (*NO).
Note: Even if host print transform can transform SCS to ASCII, specify
User ASCII if the target printer is an ASCII printer.
Table 17 may help you choose the correct type of data.
Table 17. Recommended data types and drivers
c. Select the Transform ASCII to SCS box if you have a file containing ASCII
data that you want to print on an SCS printer.
The Transform ASCII to SCS option is a simple ASCII to EBCDIC
conversion with some basic SCS commands such as carriage return and
line feed. It was designed to print text and cannot handle graphics.
d. The printer file used on the AS/400 system can be specified or changed.
You can use the Browse button to search the AS/400 system for the printer
file.
9.2.4 Considerations on Client Access/400 Network Printing
Redirecting printed output from PC applications to the AS/400 system has a
number of benefits for PC users:
• The ability to use powerful OS/400 spool management functions such as
printing a page range or saving the spooled file after printing.
• Use of powerful high speed printers, including IPDS printers with full error
recovery functions to avoid data loss.
• Producing output in the device independent AFP data stream for printing and
archiving.
• Using standard company wide AFP resources such as overlays and page
segments.
Output type Target printer Type of data
(AS/400 print
profile)
Printer driver
(properties)
Text or Graphics ASCII printer User ASCII Windows printer
driver
Text SCS or IPDS
AFP(*YES) or (*NO)
SCS IBM SCS xxxx
Driver
Graphics IPDS AFP (*YES) AFPDS IBM AFP xxxx Driver
194 IBM AS/400 Printing V
9.3 Printing AS/400 output on a PC printer
An AS/400 application generates an SCS, IPDS, or AFPDS data stream for
printing. Because PC connected printers are ASCII printers that support data
streams such as PPDS, PCL/3 or PCL/5, the spooled files produced by AS/400
applications have to be transformed to the appropriate data stream for the PC
printer.
Note: AS/400 IPDS spooled files cannot be transformed into ASCII.
There are three ways to achieve this conversion:
• 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
Workstation Customizing (WSCST) object. The same WSCST object is used
for all printers of a similar type.
• 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 available on all PCs using the printer.
The following sections include configuration examples. The environment we used
was:
• Windows 95
• Client Access for Windows 95/NT Version 3 Release 1 Modification 3
• OS/400 Version 4 Release 2
• Automatic configuration of devices on the AS/400 system were turned on.
Using automatic device configuration, the printer device description is based
on the configuration on the PC. Any changes made to the device description
manually on the AS/400 system are overwritten when the session is started on
the PC. Parameters not sent by the PC are kept, by the host, such as Image
Object name. This is a reason to use a unique workstation ID, which is also
the device description file name.
Note: Before a printer emulation session can be configured, at least one printer
must be defined to Windows.
9.3.1 Configuring a printer emulation session
This example describes how to configure a printer emulation session for use with
or without the host print transform function. It assumes that you have already
configured a Client Access connection to the AS/400 system via SNA or TCP/IP.
Client Access Version 3 Release 1 Modification 3 allows native TCP/IP printer
emulation sessions in addition to SNA.
1. Start the configuration program by selecting the Start or Configure Session
icon in the Client Access Accessories folder.
Chapter 9. Client Access/400 printing 195
A welcome window is shown. Click OK. A window appears like the one shown
in Figure 144.
Figure 144. Configuring IBM Personal Communications 5250
2. On the Configure PC5250 window, complete these steps:
a. Select the AS/400 system.
b. Select the Printer option for Type of emulation.
c. A name for the printer (workstation ID) can be given. This name appears on
the AS/400 system as the printer device name and output queue name.
Note: If this field is left blank, an ID based on the currently active session
number is given when establishing the session.
d. Select the Host code-page used. This information is used to transform the
EBCDIC characters sent from the AS/400 system to the corresponding
ASCII code points.
e. Click Setup to continue. A window appears like the example shown in
Figure 145 on page 196.
196 IBM AS/400 Printing V
Figure 145. Printer emulation setup with host print transform
3. On the PC5250 Printer Emulation Setup window, specify:
a. The AS/400 message queue to be used with the library name.
b. The Courier 10 font is used if FONT(*DEVD) is specified.
c. If you want to have the data stream conversion done by PC5250 rather
than by the OS/400 host print transform function, skip substeps d through
h.
d. Select the Transform print data to ASCII on AS/400 box.
e. Specify a printer model.
f. Specify a paper size for drawer 1, drawer 2, and envelope hopper.
g. Do not select Printer supports ASCII code page 899 (this code page is not
standard on ASCII printers, and usually requires a special font cartridge).
h. Leave the default value for Customizing Object and Library.
This results in a device description on the AS/400 system with the following
parameters values:
DEVD PRT22
DEVCLS *VRT
TYPE 3812
AFP *NO
CTL QVIRCD0001
FONT 011
TRANSFORM *YES
MFRTYPMDL *IBM4039HP
WSCST *NONE
Chapter 9. Client Access/400 printing 197
If the use of a workstation customization table is required, select Other
Printer as the Printer model and specify the name of your customized WSCST
object in the Customizing Object field and the library name. This results in the
following parameter values in the printer device description:
DEVD PRT22
DEVCLS *VRT
TYPE 3812
AFP *NO
CTL QVIRCD0001
FONT 011
TRANSFORM *YES
MFRTYPMDL *WSCST
WSCST MYWSCST <--- The name of your customized object *LIBL
Note: If both WSCST and a printer model are specified, the workstation
customizing object is ignored. We recently changed this to allow any of the
WSCSTLETTER and other WSCST* objects, which indicate the paper type to
be used with the Customization Object specified. The *OTHER object is no
longer allowed.
4. Click OK to return to the previous window.
5. Click OK to start the printer emulation session. Windows appear, such as the
examples shown in Figure 146. The printer can be started or stopped from this
window.
Figure 146. Printer session window
6. To save the session and create an icon, click File and Save as.... The window
shown in Figure 147 on page 198 appears.
198 IBM AS/400 Printing V
Figure 147. Save Workstation Profile as
7. Enter a name for the configuration file (in this example, PRT22), and click OK.
The window shown in Figure 148 appears.
Figure 148. Create printer session icon
8. Click Yes to create an icon for the printer session. The Browse for Folder
window shown in Figure 149 appears.
Chapter 9. Client Access/400 printing 199
Figure 149. Selecting a destination for the icon
9. Click the destination (folder/desktop) where the icon should be placed, and
click OK. The window shown in Figure 150 appears.
Figure 150. Icon information
10.Click OK to create the icon.
11.Now a printer defined to Windows can be connected to this session. Click File
and Printer Setup from the printer emulation session window. The window
shown in Figure 151 on page 200 appears.
200 IBM AS/400 Printing V
Figure 151. Selecting a printer
12.Click the printer you want to use, and then click OK to end the configuration.
Note: If no printer is connected with a printer emulation session, the Windows
default printer is used, and the window shown in Figure 152 appears.
Figure 152. Using the default printer
9.3.2 Modifying and using a printer definition table (PDT)
This example assumes that a printer emulation session is already configured and
working. For a description of how to configure a printer emulation session, follow
the instructions in 9.3.1, “Configuring a printer emulation session” on page 194,
and do not specify host print transform.
Printer definition tables (PDTs) can be used to override host formatting (done
through the SCS commands), or to initialize the printer independent of the SCS
formatting. The steps to modify one are:
1. Create or change a printer definition file (PDF).
2. Convert the printer definition file to a printer definition table.
PDFs can be modified with any editor on your PC. They consist of macro
definitions that specify how to convert the SCS code to ASCII strings. Many PDFs
and PDTs come with Client Access. More details and a list of functions available
can be found in the Client Access/400 Personal Communications 5250 Reference
Guide, SC41-3553.
Chapter 9. Client Access/400 printing 201
The following example shows how to change a PDF, create the PDT, and how to
configure the PC5250 session to use the PDT:
1. Select a printer definition file for modifying. In most cases, an existing PDF is
selected for modification. The PDF, which is closest to the functionality of the
physical printer used, should be copied and then edited. In this example, the
HPLJ4.PDF file has been copied to the I4039HP.PDF file. The path for the
PDF files for a default Client Access installation is:
\program files\ibm\client access\emulator\pdfpdt
You can search for the PDF files in a separate subdirectory named PDFPDT.
Figure 153. I4039HP.PDF table (partial)
/**********************************************************************/
/* */
/* PRINTER SESSION DEFINITION FILE FOR: HP LaserJet 4 */
/* */
/**********************************************************************/
BEGIN_MACROS
NUL EQU 00 /* Nul character */
BAK EQU 08 /* Back Space */
TAB EQU 09 /* Tab */
LFF EQU 0A /* Line Feed */
FFF EQU 0C /* Form Feed */
CRR EQU 0D /* Carriage Return */
P12 EQU 1B 26 6B 34 53 /* 12 Pitch-Characters/Inch */
P10 EQU 1B 26 6B 30 53 /* 10 Pitch-Characters/Inch */
ESC EQU 1B /* Escape */
SPA EQU 20 /* Space */
P17 EQU 1B 26 6B 32 53 /* 16.7 Pitch-Characters/inch */
CS1 EQU 1B 28 38 55 /* Roman 8 char set 1 */
CS2 EQU 1B 29 38 55 /* Roman 8 char set 2 */
EC1 EQU 1B 28 35 4D /* PS Math Symbol Set */
EC2 EQU 1B 29 30 4E /* ECMA-94 Latin 1 char set 2 */
PC1 EQU 1B 28 30 4E /* PC-8 (IBM US) char set 1 */
PC2 EQU 1B 29 30 4E /* PC-8 (IBM US) char set 2 */
............................................
............................................
NOR EQU 1B 45 /* Normal background-foreground*/
SFG EQU 1B 28 73 /* */
END_MACROS
/**********************************************************************/
/* Session Parameters */
/**********************************************************************/
MAXIMUM_PAGE_LENGTH=060 /* Printed lines per page */
MAXIMUM_PRINT_POSITION=080 /* Printed characters per line */
INTERV_REQ_TIMER=001
HORIZONTAL_PEL=0720 /* */
............................................
............................................
MIDDLE_DOT_ACCENT = B7
ONE_SUPERSCRIPT = B9
NUMBER_SIGN = 70
THREE_SUPERSCRIPT = B3
TWO_SUPERSCRIPT = B2
REQUIRED_SPACE = 20
/**********************************************************************/
/* Internal Data Area. */
/* Do not change these statement. */
/**********************************************************************/
PRINTER_ID=99 99
/**********************************************************************/
/* End of Definition File */
/**********************************************************************/
202 IBM AS/400 Printing V
In the example shown in Figure 153, we made two changes to the PDF:
• The following line:
EC1 EQU 1B 28 30 4E /* ECMA-94 Latin 1 char set 1 */
has been changed to:
EC1 EQU 1B 28 35 4D /* PS Math Symbol Set */
to use the PS Math Symbol Set instead of the Latin 1 Symbol Set.
• The following entry:
NUMBER_SIGN=23
has been changed to:
NUMBER_SIGN=70
to print the mathematical symbol “Pi” instead of the number sign.
2. Convert the PDF to a PDT
Select File from the pull-down menu of the printer emulation session. Then
select Printer Setup, and the window shown in Figure 154 appears.
Note: Converting a PDF to a PDT can be done from any emulation window. In
this example, we are going to use the converted PDT with the printer
emulation session, so we do the conversion from that emulation session.
Figure 154. Printer Setup window
3. Select the Use PDT box, and click Select PDT.... The Select PDT file window
shown in Figure 155 appears.
Chapter 9. Client Access/400 printing 203
Figure 155. Select PDT file
4. Click Convert PDF..., and the Convert PDF to PDT window shown in Figure
156 appears.
Figure 156. Convert PDF to PDT
5. Select the modified PDF, and click Convert. The PDF File Converter window
shown in Figure 157 on page 204 appears.
204 IBM AS/400 Printing V
Figure 157. PDF File Converter
6. If compilation is successful, click Close, and the Convert PDF to PDT window
is shown again.
7. On the Convert PDF to PDT window, click Close, and the Select PDT File is
shown. The converted PDT is highlighted. Click OK, and the Printer Setup
window is shown.
8. On the Printer Setup window, click OK to end the configuration.
Note: It is not necessary to restart the session with the AS/400 system. The
newly converted PDT takes effect immediately.
© Copyright IBM Corp. 2000 205
Chapter 10. IBM AS/400 network printers
There is a wide range of IBM AS/400 network laser printers. The current printer
line includes:
• IBM Network Printer 12
• IBM Network Printer 17
• IBM Infoprint 20
• IBM Infoprint 21
• IBM Infoprint 32
• IBM Infoprint 40
• IBM Infoprint Color 8
This chapter explains how you can maximize printer effectiveness when it is
attached to an AS/400 system. IBM Network Printer 17 was used for this
illustration, but the highlighted features generally apply to all the monochrome
network printers.
Note: For the latest setup and configuration reference, click the Publications link
at: http://www.ibm.com/printers
10.1 Overview
There are a number of shared characteristics that make IBM AS/400 network
printers a good choice for AS/400 and network environments, including:
• 600 and 1200 dpi resolutions
• Multiple active physical attachments
• Data stream auto-sensing
• Writer sharing to switch between network clients and servers, and AS/400
writers
The newest member of the IBM AS/400 network printer family is IBM Infoprint 21.
This printer adds several important additional features that are key to printing in a
network environment, including:
• It supports Internet Printing Protocol (IPP), which enables you to reference
and print to a printer via a URL.
• An embedded Web server within the printer enables access to the printer from
any Web client. This provides the capability to view printer information and to
manage the printer directly from any Web browser.
• IBM Homerun printer controller provides the capabilities of the Advanced
Function Common Controller (AFCC) used in much larger IBM AS/400
printers.
IBM AS/400 network printers make ideal workgroup, distributed, or small system
printers within AS/400 network environments. An overview of the principal
supported attachments, protocols, and data streams is shown in Figure 158 on
page 206.
Although they may be attached using conventional means, such as twinaxial
cable or parallel cable, their greatest flexibility is realized when they are TCP/IP
LAN-attached. When installed on a Token-Ring or Ethernet LAN, they can receive
data from a variety of host systems as well as PC clients on the LAN. Network
206 IBM AS/400 Printing V
management software, in the form of IBM Network Printer Manager, may be used
to monitor and maintain the printers, either across the LAN or through the World
Wide Web. This is discussed in 10.4.1, “Network Printer Manager” on page 215.
Figure 158. Network printer connectivity
10.2 Configuration scenarios
This section outlines simple and advanced uses of network printers.
10.2.1 Example 1: LAN-attached IPDS printer
Here an NP17 has been attached to an AS/400 system through Ethernet (Figure
159). The printer is used in the Accounting department of a business, printing
variable data with electronic forms (overlays) sent with the data from the AS/400
system. The printer is configured as type *IPDS, AFP=*YES.
Protocols
Attachments Datastreams
Token Ring
Ethernet
Twinax
Coax
Parallel
Serial
IPDS
Postscript L2
PCL 5e
TCP/IP
NetBIOS
IPX/SPX
AppleTalk
Chapter 10. IBM AS/400 network printers 207
Figure 159. LAN-attached Network Printer 17
10.2.2 Example 2: Dual-configuration printer
This example shows the same physical printer, but a second logical device has
been configured on the AS/400 system (Figure 160). This second device is
configured as a LAN-attached ASCII printer and receives only the PCL data
stream. The reason this has been done is because the printer is now being used
for general purpose office printing such as reports, screen prints, and program
listings. Although these can be sent to the IPDS device, it is quicker to send such
simple documents using a PCL device description. The printer has been set up to
automatically switch between the two operating modes. This is indicated on the
printer's operator panel (PCL ETHERNET and IPDS ETHERNET) so users know
which particular type of output is being printed.
The second device is configured as an emulated 3812 Model 1 with LAN
attachment *IP. This configuration is available at Version 3.0 Release 7.0 and
later. Prior to this, we can use a remote output queue for a similar effect. These
types of configuration are discussed in 1.4, “AS/400 printer attachment methods”
on page 15.
Figure 160. Single LAN-attached Network Printer 17: Two logical devices
10.2.3 Example 3: Shared dual-configuration printer
In this example, in addition to the dual-configuration use made by a single AS/400
system. A second AS/400 system also directly uses the printer. Again, the printer
Network
Printer 17
IPDS Ethernet
AS/400
PCL
Network
Printer 17
IPDS Ethernet
AS/400
208 IBM AS/400 Printing V
manages the switching between the two different hosts as it does for switching
between data streams (Figure 161).
Figure 161. Shared Network Printer 17
10.2.4 Example 4: Shared multi-purpose printer
We can continue to extend the versatility of the network printer by adding options
such as a Token-Ring adapter, an envelope feeder, two 500-sheet input bins, and
an offset stacker/jogger output bin. Users on the Token-Ring LAN can now send
PCL or PostScript jobs to the printer, perhaps using the offset stacker for e-mail,
spread sheets, and other PC documents. The PCs can be on a Windows NT
server in Figure 162, but can also be on an OS/2, Novell NetWare, or Apple
network. They might also use the existing Ethernet adapter instead of
Token-Ring.
Alternative options might be a 10-bin mailbox feature in place of the offset stacker
for printing confidential personnel records, a Twinax adapter instead of one of the
LAN adapters, or even a higher-throughput NP24 to cope with even more traffic!
Figure 162. Shared Network Printer 17 with options
These examples show how network printers may be installed in an initially simple
manner to satisfy one particular requirement, yet grow with the demands of the
enterprise.
PCL
Network
Printer 17
IPDS Ethernet
AS/400 AS/400
IPDS
Postscript L2
PCL
Network
Printer 17
IPDS Ethernet
AS/400 AS/400
IPDS
Token-Ring
Windows NT Server
Chapter 10. IBM AS/400 network printers 209
10.3 Printer setup
Each model of the Network Printer is shipped with the following manuals:
• User's Guide
• Quick Set-up
• Safety Information
The publication numbers of the manuals vary by language. In addition, the
following publications are shipped when the appropriate attachment options are
purchased:
• Twinax/Coax Configuration Guide, G544-5241
• Ethernet and Token-Ring Configuration Guide, G544-5240
• Ethernet and Token Ring Configuration Guide (Infoprint 21), S544-5711
The following publications are available for purchase in hardcopy format:
• IPDS and SCS Technical Reference, S544-5312
• PCL5e and PostScript Technical Reference, S544-5344
They are also freely available on the World Wide Web at:
http://www.printers.ibm.com/manuals.html
This redbook is not a substitute for any of these publications. Use the shipped
manuals for unpacking and basic setup (for example, installing the toner
cartridge, loading paper, and using the operator panel). Use the optional
attachment guides to attach the printer to the system.
10.3.1 Printer menu details
To print out the Configuration Page for any of the monochrome models, ensure
the printer display shows READY. Then press the following keys in sequence:
Online->Menu->Item->Enter. If the printer does not show READY, but shows the
status of the last job (for example, IPDS ETHERNET), not all the menu printout
options are available.
The following values are the settings that we recommend for the menus affecting
host printing. IBM Network Printer 17 was used as an example. For other models,
and for more detailed information, refer to the User's and Configuration Guides.
Menu items are only listed here if they relate to host-based printing in some way,
either directly or indirectly.
10.3.1.1 TEST MENU
Use this menu to print out the Configuration Page (see the preceding paragraphs)
as well as listings of IPDS resident fonts.
10.3.1.2 PAPER MENU
This controls paper-handling when this is not specified by the host.
SOURCE TRAY 1
This is the default tray used when one is not specified in the data
stream (for example, when printing a test page). However, if you
want to use the auxiliary tray with host jobs, set SOURCE to AUX.
This is explained in “Auxiliary tray” on page 213.
210 IBM AS/400 Printing V
MANUAL OFF
This applies to paper feeding from the auxiliary tray. Set it to OFF
(automatic feed) unless you are feeding special stationery, such
as stiff card stock and want to feed these singly.
AUXSIZE LETTER or A4 or as required
You must specify the loaded paper size for the auxiliary tray since
this tray does not have a paper size sensor.
10.3.1.3 CONFIG MENU
In the case of host printing, this only applies to an SCS data stream.
JAMRECOVERY ON
10.3.1.4 TOKEN RING and ETHERNET MENU
This menu is only present if a LAN feature (LAN NIC (Network Interface Card)) is
installed.
PERSONALITY AUTO
PORT TIMEOUT 15
Other parameters vary according to your particular requirements (IP address and
others).
10.3.1.5 TWINAX SCS MENU
This menu is only present if a Twinax feature is installed.
CODE PAGE The country code page of your system (037 - U.S., 285 - U.K.,
for example)
10.3.1.6 TWINAX SETUP MENU
This menu is only present if a Twinax feature is installed.
SCS ADR An address from 0 to 6
Must be different than the IPDS address. Set this address to
OFF if you do not want an SCS-only device description for this
printer.
IPDS ADR An address from 0 to 6
Must be different than the SCS address.
EDGE-EDGE ON
For Network Printers 12 and 17 only. This is contrary to the
recommendation in the User's Guide, but you have more
scope for defining applications that can extend to the edge of
the page. Note that the setting in this menu applies to SCS
printing only.
BUFFERSIZE 1024
This applies to IPDS printing only. The SCS buffer size is
always 256 bytes.
PORT TIMEOUT 90
Chapter 10. IBM AS/400 network printers 211
10.3.1.7 IPDS MENU
This menu is only present if the IPDS feature (IPDS SIMM (Single Inline Memory
Module)) is installed.
PAGEPROT AUTO
DEF CD PAG The country code page of your system (037 - U.S., 285 - U.K.,
for example)
EMULATION 43xx.
Set this to native mode (43xx). Ensure you install on your
system the program temporary fixes (PTFs) listed in Table 18
on page 212. Operating the printer in 4028 mode affects font
substitution and twinax auto-configuration.
DEF FGID 416 (or any FGID of your choice)
CPI 10.0 (or any CPI to match your FGID choice)
VPA CHK ON
X OFFSET 0
Y OFFSET 0
PAGE WHOLE
This setting is explained in 10.5.5, “Using the IPDS menu PAGE
setting” on page 218.
EDGE-EDGE ON
For Network Printers 12 and 17 only. This is contrary to the
recommendation in the User's Guide, but you have more scope
for defining applications that can extend to the edge of the page
as well as greater compatibility with edge-to-edge printers such
as the IBM 3130 and Infoprint 60. See 10.5.6, “Edge-to-edge
printing” on page 221, for details.
FONT SUB ON
Note that the default is OFF.
IPDS PORT TRING (if Token-Ring attach), ETHER (if Ethernet attach), or
TX (if Twinax attach).
If you have both LAN and Twinax adapters on the printer, only
one may be active for IPDS support at any one time. This does
not depend on the setting of the IPDS port, however.
Note: You cannot have a device using two IPDS ports
simultaneously. For example, if you have a twinax adapter and
a LAN adapter, only one may be active for IPDS at any one
time. However, this does not prevent you from configuring both
adapters for IPDS use. Despite the setting of this item, the port
used for IPDS jobs simply depends on which port is activated
first by the STRPRTWTR command (or equivalent command on
a non-AS/400 system). You can even share IPDS traffic
between the two ports using the PORT TIMEOUT option for
each adapter (for example, if the printer is shared by multiple
systems, one that uses twinax and the other uses LAN cabling).
212 IBM AS/400 Printing V
EARLY COMPL OFF
This item only appears if a twinax adapter is also present. If this
item is enabled, the printer sends back a good
acknowledgement (ACK) when it has received the data, not
when it has printed the data. This improves performance, but
runs the risk of losing data (for example, through a paper jam).
This is how the printer operates in SCS mode in any case,
relying on features such as JAMRECOVERY=ON (in the
CONFIG MENU) to reprint a page. Using EARLY COMPL=OFF
in the IPDS implementation causes the printer not to send a
good ACK until the completed output is in the output bin,
together with the host IPDS data stream re-transmitting the
page if required. Therefore, error recovery is improved.
10.3.2 Recommended PTF levels
The PTFs listed in Table 18 provide the correct PSF/400 support for the network
printers in native mode (EMULATION set to 4312, 4317, or 4324 in the IPDS
MENU). The PTFs also add support for the IBM 4247-001 impact printer. The
Ethernet and Token-Ring Configuration Guide, G544-5240, may mention PTF
SF33025 for V3R7. This PTF is now in the base operating system.
Table 18. PTF support for network printers in native mode (43xx)
10.3.3 Microcode
Microcode is the internal machine code that resides on the SIMMs and NICs. The
Configuration Page may show code levels with an “R” or an “F” after the
numbers. These indicate ROM or Flash SIMMs. It is only possible to download
new levels of microcode to Flash SIMMs. If the SIMM type is not indicated, it is
usually a Flash SIMM.
Customers may upgrade the code levels of LAN NIC cards using Network Printer
Manager. Token-Ring and Ethernet microcode are available on the Web at:
http://www.printers.ibm.com/util.html
A service representative performs other code upgrades. In either case, this
should only be done when advised by IBM Technical Support.
10.3.4 Tray and bin selection
This explains the settings required to select the auxiliary tray (an input tray) and
the mailbox bins and offset stacker (output bins). Note that the terms tray and bin
may be used synonymously in the documentation.
Version and Release APAR PTF Cumulative pack
V3R1 SA52845 SF43120 -
V3R2 SA52845 SF43431 7014
V3R6 SA55722 SF42712 -
V3R7 and later Base Operating system
Chapter 10. IBM AS/400 network printers 213
10.3.4.1 Input trays
Input tray selection is outlined in Table 19.
Table 19. Input tray selection
Auxiliary tray
If you want to use the auxiliary tray with SCS jobs, but do not want to change
printer files to specify *CUT on the FORMFEED parameter, use the following
workaround:
1. Set the source tray in the PAPER MENU to AUX.
Note: This also results in the AUX tray being used for test pages and font
listings.
2. Set AUXSIZE in the PAPER MENU to the paper size that is used (for example,
LETTER or A4).
3. Set MANUAL in the PAPER MENU to OFF. Otherwise, you are prompted to
load each piece of paper.
4. Set the IPDSPASTHR parameter in the PSFCFG Object to *NO.
5. In the printer file, specify DRAWER=4 (or any number greater than 3). The
printer cannot find drawer 4 so it picks from the default tray defined in step 1.
To use this tray with PCL jobs with either an ASCII LAN device description or a
remote output queue, the WSCST (Workstation Customizing Object) must be
edited. Refer to Chapter 6, “Advanced Host Print Transform Customization” in
AS/400 Printing IV, GG24-4389 for details of modifying such an object. The
source text you need to edit is:
:litdata.
:DWRNBR
VAROFFSET= 3
VARLEN=0
DRAWER parameter
in printer file
FORMFEED parameter
in printer file
Drawer name on printer
SCS printing
1 *AUTOCUT 1
2 *AUTOCUT 2
3 *AUTOCUT Auxiliary
any *CUT Manual Tray
E1 *AUTOCUT Envelope Feeder
IPDS and AFP printing
1 *AUTOCUT 1
2 *AUTOCUT 2
3 *AUTOCUT 3
any *CUT Auxiliary Tray (with MANUAL=OFF)
any *CUT Auxiliary Tray (with MANUAL=ON)
E1 *AUTOCUT Envelope Feeder
214 IBM AS/400 Printing V
VARTYPE=CHRHEX
:elitdata.
DATA ='1B266C3548'X.
Change the last line to:
DATA ='1B266C3248'X.
10.3.4.2 Output bins
Table 20 applies to Network Printer 17 only. These options are available only on
this model.
Mailbox bins and Offset Stacker/Jogger
To send output to these bins, specify the printer file OUTBIN parameter according
to Table 20. The Offset Stacker/Jogger and Mailbox are mutually exclusive. If an
output bin is selected but not present, the output is sent to the bin indicated by
the OUTPUT setting in PAPER MENU.
Table 20. Output bin selection
Table 21 applies to the NP24 only. The finisher option is available only on this
model.
2000-sheet finisher
To send output to these bins, specify the printer file OUTBIN parameter according
to Table 21.
Continuous stacking (or tray linking of the three output bins in the finisher) may
be selected through the printer operator panel, as well as in the OUTBIN
parameter of the printer file. Do not mix jobs that use continuous stacking and
individual output bin selection. The printer will honor the latter. Therefore, jobs
might be mixed in the three finisher trays. If you want to use the continuous
stacking feature, set this at the printer and leave the printer file OUTBIN
parameter at its default value of *DEVD (device default).
OUTBIN parameter in printer file Tray name on printer
1 Main output bin
2 Offset stacker/jogger
3 Mailbox Bin 1
4 Mailbox Bin 2
5 Mailbox Bin 3
6 Mailbox Bin 4
7 Mailbox Bin 5
8 Mailbox Bin 6
9 Mailbox Bin 7
10 Mailbox Bin 8
11 Mailbox Bin 9
12 Mailbox Bin 10
Chapter 10. IBM AS/400 network printers 215
If an output bin is selected but not present, the output is sent to the bin indicated
by the OUTPUT setting in PAPER MENU.
Table 21. Output bin selection
10.4 Attachment information
The diagram in Figure 158 on page 206 summarizes the connectivity options for
the network printer range. The two main methods of attaching a network printer to
the AS/400 system are:
• As PCL printers using:
– A remote output queue (V3R1/V3R6 and later)
– A direct TCP/IP LAN device description (V3R7 and later)
– Through a PC, 5250 terminal, or LAN attachment device using host print
transform (HPT)
• As IPDS or SCS printers using:
– Twinax
– LAN (using Token-Ring or an Ethernet interface card)
For details of these methods, refer to one or more of the following sources:
• Chapter 11, “Configuring LAN-attached printers” on page 223, in this
publication
• Chapter 3, “Attaching to the AS/400 (Twinax)” in Twinax/Coax Configuration
Guide, G544-5241
• Chapter 10, “AS/400 to print PCL and PostScript files” and Chapter 11,
“AS/400 to print IPDS files” in Ethernet and Token-Ring Guide, G544-5240
10.4.1 Network Printer Manager
This software should be regarded as essential for managing and maintaining a
network of network printers. Running on a PC client such as OS/2, Windows 95,
or Windows NT, it permits remote configuration and management of the network
printer range. For full details, refer to the Web site at:
http://www.printers.ibm.com/npm.html
OUTBIN parameter in printer file Tray name on printer and output orientation
1 Main output bin, face down
2 Side output tray, face up
3 Top tray of Finisher, face down
4 Middle tray of Finisher, face down
5 Bottom tray of Finisher, face down
6 Top tray of Finisher, face up
7 Middle tray of Finisher, face up
8 Bottom tray of Finisher, face up
9 Continuous stacking, face down
216 IBM AS/400 Printing V
It may be downloaded free of charge. It is also supplied on the CD-ROM that
accompanies the printers.
For a system or network administrator, the utility may be used for:
• Configuring the printer after basic set-up by the end-user.
• Information regarding the printers' configuration such as paper-handling
capabilities, installed features, and usage data.
• Management of the printer in day-to-day operations, including:
– Notifying you of problems as soon as they appear and before they are
reported by the user.
– Where the problem lies (for example, a cover open or a paper jam).
– Advance notice of certain conditions (for example, low toner level).
– Remote reset of the printer, if necessary.
• Upgrading Token-Ring or Ethernet software remotely “on the fly” (that is,
without ending the writer to the printer).
The version of Network Printer Manager for the Web may also be used to
manage printers that provide standard printer compatibility within network
environments (RFC 1759) such as the Hewlett-Packard 5Si and Lexmark
Optra N.
10.5 Output presentation
This section explains why the presentation of your printed output may vary
depending on how the network printer is configured.
10.5.1 IPDS, AFP=*YES
This refers to the DEVTYPE and AFP parameters in the printer device
description. For this mode, it is important to remember that the physical page size
is determined by the printer reporting its loaded paper size back to PSF/400. The
logical page size is dictated by the PAGESIZE parameter in the printer file.
10.5.2 IPDS, AFP=*NO
This refers to the DEVTYPE and AFP parameters in the printer device
description. For this mode, it is important to remember that both the physical and
logical page sizes are determined by the page size defined in the spooled file
attributes. Therefore, the physical page and the logical page sizes are the same
as far as OS/400 is concerned.
10.5.3 SCS mode
SCS mode is the operating mode when the device description is an emulated
3812 Model 1. The page size depends on the settings on the printer, together with
any changes made by data stream commands such as lines per inch or
characters per inch. Such commands override settings made at the printer.
Chapter 10. IBM AS/400 network printers 217
10.5.4 Using the QPRTVALS data area
A system-wide data area may be set up for your printer writers, if so desired. This
supports a number of functions for all *IPDS, AFP=YES printers, not just the
network printers.
To create the data area, issue the following commands:
CRTDTAARA DTAARA(QUSRSYS/QPRTVALS) TYPE(*CHAR) LEN(256)
CHGOBJOWN OBJ(QUSRSYS/QPRTVALS) OBJTYPE(*DTAARA)
NEWOWN(QSYS) CUROWNAUT(*SAME)
GRTOBJAUT OBJ(QUSRSYS/QPRTVALS) OBJTYPE(*DTAARA)
USER(*PUBLIC) AUT(*ALL)
The first command creates the data area (note that you must create it in library
QUSRSYS). The second command assigns ownership of the object to QSYS,
and the third command makes it available to all users. The functions provided by
QPRTVALS are not available if the latter steps are not performed.
You can check the setting of QPRTVALS at any time by typing:
DSPDTAARA DTAARA(QUSRSYS/QPRTVALS)
The functions are enabled by the character “Y” being present in one of the first six
positions of the data area. The available functions are:
QPRTVALS
Data area Function
Position 1 Logical page origin is the same as physical page origin.
Position 2 Change rotation of the logical page (on older printers).
Position 3 Emulate a 3835-1 unprintable border on a 3835-2 printer.
Position 4 Do not move overlays with front and back margins.
Position 5 Increase the *COR top margin.
Position 6 Use scalable fonts for MULTIUP and COR.
Most of the settings for QPRTVALS are covered in Chapter 5, “AS/400 Printing
Enhancements” in AS/400 Printing IV, GG24-4389.
10.5.4.1 Logical and physical page origin
With a printer configured as *IPDS, AFP=*YES, the physical page size is returned
to PSF/400 by the printer, including dimensions of any unprintable borders.
PSF/400 offsets the logical page onto the physical page, taking into account the
unprintable border. This function of QPRTVALS puts the logical page back on top
of the physical page origin again.
If you are designing new applications and you can place all of your data in the
printable area, we advise that you map the logical page origin to the physical
page origin using this function of QPRTVALS so that output from your new
applications is aligned correctly, whether you print to printers with or without an
unprintable area. This is also the output presentation seen on a printer configured
as *IPDS, AFP=*NO.
To activate this function, ensure the printer writer is ended and type:
CHGDTAARA DTAARA(QUSRSYS/QPRTVALS (1 1)) VALUE('Y')
218 IBM AS/400 Printing V
This places the character “Y” in the first byte of the data area. Then restart the
print writer.
10.5.4.2 Increased COR top margin
This is one of the few changes you can make to the COR facility. COR is used
when the Page Rotation parameter in the printer file is set to *COR, and is
frequently invoked when the rotation is *AUTO. System-supplied printer files
default to *AUTO. *COR presents your output on a logical page size of 11 inches
wide by 8.5 inches deep (that is, in landscape orientation). It also increases the
character-per-inch value (for example, from 10 or 12 cpi to 13.3 or 15 cpi).
When printing on punched paper, the top margin of 0.5 inches may not be enough
for the text to clear the holes. You can increase the margin to 0.75 inches by
using this part of QPRTVALS. Note that the lines-per-inch (LPI) value is also
slightly increased, compressing the lines of output slightly.
Position 5 for QPRTVALS also works if the logical page has been rotated 180
degrees using the PSFCFG parameter EDGEORIENT.
To activate this function, ensure the printer writer is ended and type:
CHGDTAARA DTAARA(QUSRSYS/QPRTVALS (5 1)) VALUE('Y')
This places the character “Y” in the fifth byte of the data area.
10.5.5 Using the IPDS menu PAGE setting
This menu item determines how data is positioned on the page at the printer
level.
10.5.5.1 PAGE=WHOLE
This is the default (that is, use the whole page for printing). Any changes to the
positioning of data are made at the host. Changes to the X or Y-OFFSET values,
as described later, are an exception, these are changes made at the printer
microcode level. The host is unaware of these differences.
For Network Printer 24, data may fall into the unprintable area if position 1 in
QPRTVALS is set to “Y”. If the printer file FIDELITY keyword is set to
*ABSOLUTE and the IPDS MENU VPA CHK item is ON, an IPDS negative
acknowledgement (NACK) with sense data X'08C1..00' is generated and the job
is held.
Figure 163 illustrates the effect of this parameter on the Network Printer 24.
Chapter 10. IBM AS/400 network printers 219
Figure 163. Output presentation with PAGE=WHOLE on Network Printer 24
We strongly recommend that you use the PAGE=WHOLE setting for IPDS
printing. However, for applications with particular requirements, you can use
other page settings, as discussed here.
10.5.5.2 PAGE=PRINT
This setting re-positions the logical page origin, attempting to print at least some
of the data even if some is lost. The logical page origin is moved to avoid the
unprintable border (regardless of whether any data falls in the unprintable area).
This is usually done to preserve the data in the top left-hand corner of the page
so data to the right of the page or in the lower-right area may be lost (fall in the
unprintable border or even off the physical page). Whether an exception is
reported depends on the setting of the VPA CHK item (Valid Printable Area
Check). If you use the PAGE=PRINT setting, set VPA CHK=OFF.
Figure 164 on page 220 illustrates the effect of this parameter on Network
Printer 24.
220 IBM AS/400 Printing V
Figure 164. Output presentation with PAGE=PRINT
We recommend that you use this setting only if you are printing non-critical data.
10.5.5.3 PAGE=COMP1
This setting is similar to PAGE=PRINT except that the lines per inch for any lines
of IPDS text are compressed in an attempt to fit the data on the page and keep it
out of the unprintable border. This setting is not recommended for new
applications.
10.5.5.4 PAGE=COMP2
This setting works the same way as PAGE=COMP1, but with more IPDS
positioning commands. Neither of these settings move images, graphics, or
barcodes. This setting is not recommended for new applications.
Chapter 10. IBM AS/400 network printers 221
10.5.6 Edge-to-edge printing
We recommend that you set the IPDS Menu item EDGE-EDGE to ON for AFP
printing on Network Printer 12 and Network Printer 17 models. Only these models
have edge-to-edge printing ability.
10.5.6.1 Network Printer 12/17 and 24 printable area compatibility
The network printers have unprintable borders of 4mm at the edges of the paper
(for A4, the unprintable borders on the long edges are 3.86mm). The Network
Printer 12 and Network Printer 17 can print to the edge of the paper if the
EDGE-to-EDGE item is switched on (in the TWINAX SETUP menu for SCS
printing and in the IPDS MENU for IPDS printing).
Network Printer 24 cannot print to the edge of the paper. It maintains its
unprintable borders as previously explained. Therefore, in a network of mixed
Network Printer 12/17 and Network Printer 24 printers, print output might be
positioned differently. Normally this is not an issue. If the application uses very
precise formatting, or exact alignment with preprinted or electronic forms, steps
must be taken to ensure compatible output. This may be achieved either by
adjusting host settings, or by adjusting the individual printer settings as follows:
• Host adjustment:
Rather than manage the setup of multiple individual printers, we prefer that
you control adjustments to the logical page at the host. To do this, follow these
steps:
1. Set Network Printer 12/17 printers to use edge-to-edge printing.
2. Leave X and Y-offsets (in IPDS MENU) at 0 on all models.
3. Use position 1 of QPRTVALS to align the logical page origin with the
physical page origin.
4. Design applications to avoid the unprintable areas of the Network Printer
24.
Using this as a basis ensures consistency of output across present and future
AFP printers.
• Printer adjustments:
If the EDGE-EDGE item in the IPDS MENU is set to OFF, the Network Printer
12 and Network Printer 17 unprintable borders are the same as those of the
NP24 with the exception that an A4 page has slightly different unprintable
borders on the long edge. This is shown in Figure 165 on page 222.
The difference between these borders is small (4 - 3.86 mm = 0.14mm).
However, if the data in your print application is precise (for example, you need
to place a field of text inside a pre-printed box), you might see alignment
differences between the Network Printer 12/17 and the Network Printer 24
when you are not using edge-to-edge printing.
222 IBM AS/400 Printing V
Figure 165. Relative printable areas of Network Printer 12/17 and Network Printer 24 printers
If it is necessary to make an adjustment on the printer, the IPDS MENU has
options to adjust the offset of the printed page (that is, adjust the origin at which
the logical page is placed on the physical page). For the Network Printer 24
printer, you can move the left-hand unprintable border by 0.14mm to match that
of the Network Printer 12/17. However, the permissible values for the X-OFFSET
and Y-OFFSET are measured in pels. Because this is a 600-pel printer, (that is,
600 pels per inch), you can calculate the following measurements:
• 600 pels = 1 inch
• 25.4mm = 1 inch, therefore:
• 1 mm = 600 / 25.4 pels
• 1 mm = 23.6 pels
• 0.14 mm is approximately 2 to 3 pels
Therefore, you can set the Network Printer 24s X-OFFSET to 2 or 3 in the IPDS
MENU.
Note: This affects only IPDS printing, and not PCL or PostScript printing. This
should be sufficiently similar to the settings of the Network Printer 12 and
Network Printer 17 with edge-to-edge off.
We recommend that you do not adjust individual printer settings unless
absolutely necessary. Host adjustments, together with edge-to-edge printing,
ensures that your output presentation is consistent across your network printer
inventory.
© Copyright IBM Corp. 2000 223
Chapter 11. Configuring LAN-attached printers
Several printer attachment methods are available on the AS/400 system. This
appendix provides information on how to configure AS/400 LAN-attached IPDS or
ASCII printers. This chapter is divided in two parts:
• Configuring LAN-attached IPDS printers
• Configuring LAN-attached ASCII printers
For considerations on LAN-attached IPDS printers, see 1.4.2, “IPDS printers
LAN-attached” on page 16. For considerations on LAN-attached ASCII printers,
see 1.4.5, “ASCII printers LAN-attached” on page 19. For a discussion on IPDS
printers versus ASCII printers, see 1.6.4, “USERASCII spooled files” on page 25.
Note: For additional configuration information, see Ethernet and Token-Ring
Configuration Guide, G544-5240.
11.1 Configuring LAN-attached IPDS printers
The following IBM AS/400 IPDS printers can be LAN-attached to the AS/400
system:
• Any IPDS printer with an IBM Advanced Function Common Control Unit
(AFCCU), including:
– IBM 3130
– IBM 3160
– Infoprint 60
– Infoprint 62
– Infoprint 2000
– Infoprint 3000
– Infoprint 4000
• IBM AS/400 network printers with the appropriate LAN card, including:
– IBM Network Printer 12
– IBM Network Printer 17
– Infoprint 20
– Infoprint 21
– Infoprint 32
– Infoprint 40
– Infoprint 70
Note: For more information on network printers, see Chapter 10, “IBM AS/400
network printers” on page 205.
• The IPDS printers IBM 3812, 3816, 3912, 3916, 3112, 3116, 4028, 4230, and
6400 using the I-DATA 7913 Printer LAN Attachment box (TCP/IP Token-Ring
or Ethernet)
Note: See 11.1.3, “TCP/IP BOOT service for V4R1 and later” on page 237, for
information on how to change the I-DATA 7913 setting.
The configuration of LAN-attached IPDS printers differ depending on the version
and release of the OS/400. This section includes an example for Version 3.0
Release 2.0 and Version 3.0 Release 7.0 and later.
224 IBM AS/400 Printing V
Note: For previous releases (V3R1 or V3R6), see 12.1.7, “Configuring
LAN-attached IPDS printers” on page 257, for instructions.
If your TCP/IP network is not already set up on your AS/400 system, see 12.1.1,
“Setting up a TCP/IP network on the AS/400 system” on page 253. The
configuration steps are:
1. Check that Print Services Facility/400 (PSF/400) is installed on your system
(see 1.3.2.3, “Is PSF/400 installed” on page 11).
2. To avoid any problem, check to have the latest cumulative PTFs installed on
your system (see 12.10, “Additional information” on page 278).
3. Complete your printer setup. If your printer is an IBM Network Printer, see
10.3, “Printer setup” on page 209, for detailed information.
4. Create a printer device description.
5. Create a PSF configuration object.
6. Ping the TCP/IP address, vary on the printer, and start the printer writer. For
detailed information, see 12.1.3, “Pinging the TCP/IP address” on page 254.
11.1.1 Configuring LAN-attached IPDS printers on V3R2
If you migrate from V3R1 to V3R2, the WRKAFP2 data area is replaced by a PSF
configuration object created using the Create PSF Configuration (CRTPSFCFG)
command.
During the first Start Print Writer (STRPRTWTR) after the migration to V3R2, the
system automatically creates a PSF configuration object using the values
specified in the data area (WRKAFP2). The name of the PSF configuration object
is the same as the printer device description name, and the PSF configuration
object is placed into the library QGPL.
11.1.1.1 Creating the device description
To create the device description for your printer, follow these steps:
1. Type the Create Device description Printer (CRTDEVPRT) command on any
command line, and press the F4 (Prompt) function key. A display appears as
shown in Figure 166.
Figure 166. Create Device Description (Printer) V3R2 (Part 1 of 6)
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . PRT01 Name
Device class . . . . . . . . . . *RMT *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . 0 0, 1, 2, 3, 4, 10, 13, 301...
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 225
2. On this display, enter the following parameter values:
• Device description: The name of your printer (in this example, PRT01)
• Device class: *RMT
• Device type: *IPDS
• Device model: 0
Press the Enter key to continue. The display shown in Figure 167 appears.
Figure 167. Create Device Description (Printer) V3R2 (Part 2 of 6)
3. On this display, set the Advanced function printing parameter value to *YES.
Note: Any IPDS LAN-attached printer must be configured AFP=*YES.
Then, press the Enter key to continue. A display appears as shown in Figure
168.
Figure 168. Create Device Description (Printer) V3R2 (Part 3 of 6)
4. On this display, set the AFP attachment parameter value to *APPC.
Press the Enter key to continue. A display appears like the example shown in
Figure 169 on page 226.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 Name
Device class . . . . . . . . . . > *RMT *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 0 0, 1, 2, 3, 4, 10, 13, 301...
Advanced function printing . . . *YES *NO, *YES
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 Name
Device class . . . . . . . . . . > *RMT *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 0 0, 1, 2, 3, 4, 10, 13, 301...
Advanced function printing . . . *YES *NO, *YES
AFP attachment . . . . . . . . . *APPC *WSC, *APPC
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
226 IBM AS/400 Printing V
Figure 169. Create Device Description (Printer) V3R2 (Part 4 of 6)
5. On this display, enter the following parameter values:
• Online at IPL: *YES
• Font identifier: 11 (or another font ID used as the default font)
• Form feed: Specifies the form feed attachment used for this printer. Enter
*AUTOCUT for a page printer, or *CONT for a continuous forms printer (in
this example, *AUTOCUT).
Leave the default values for the other parameters, and press the Enter key to
continue. The display shown in Figure 170 appears.
Figure 170. Create Device Description (Printer) V3R2 (Part 5 of 6)
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 Name
Device class . . . . . . . . . . > *RMT *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 0 0, 1, 2, 3, 4, 10, 13, 301...
Advanced function printing . . . *YES *NO, *YES
AFP attachment . . . . . . . . . *APPC *WSC, *APPC
Online at IPL . . . . . . . . . *YES 0-65535
Font:
Identifier . . . . . . . . . . > 11 3, 5, 11, 12, 13, 18, 19...
Point size . . . . . . . . . . *NONE 000.1-999.9, *NONE
Form feed . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Bottom.
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 Name
Device class . . . . . . . . . . > *RMT *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > *IPDS 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 0 0, 1, 2, 3, 4, 10, 13, 301...
Advanced function printing . . . *YES *NO, *YES
AFP attachment . . . . . . . . . *APPC *WSC, *APPC
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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Printer error message . . . . . *INQ *INQ, *INFO
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 227
You can leave the default value *INQ for the Printer error message parameter.
To continue, press the Page Down key. The display shown in Figure 171
appears.
Figure 171. Create Device Description (Printer) V3R2 (Part 6 of 6)
6. Enter any name for the Remote location parameter (in this example, TCPIP)
and a text description for device configuration object. You can leave the
default parameter values for the other parameters.
Then, press the Enter key to create the device description. You receive the
message Description for device PRT01 created.
11.1.1.2 Creating the PSF configuration object for V3R2
To create the PSF configuration support, follow these steps:
1. Type the Create PSF Configuration (CRTPSFCFG) command on any command
line, and press F4 (Prompt). The display shown in Figure 172 on page 228
appears.
Create Device Desc (Printer) (CRTDEVPRT)
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Maximum pending request . . . . 6 1-31
Print while converting . . . . . *YES *NO, *YES
Print request timer . . . . . . *NOMAX 1-3600, *NOMAX
Form definition . . . . . . . . F1C10110 Name
Library . . . *LIBL Name, *LIBL, *CURLIB
Character identifier: Name, *LIBL, *CURLIB
Graphic character set . . . . *SYSVAL 1-32767, *SYSVAL
Code page . . . . . . . . . . 1-32767
Remote location . . . . . . . . TCPIP Name
Local location . . . . . . . . *NETADR Name, *NETADR
Remote network identifier . . . *NETADR Name. *NETADR, *NONE
Mode . . . . . . . . . . . . . . QSPWTR Name, SPWTR, *NETADR
Text description . . . . . . . . Device description for PRT01
Dependent location name . . . . *NONE Name, *NONE
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
228 IBM AS/400 Printing V
Figure 172. Create PSF Configuration object V3R2 (Part 1 of 3)
2. On this display, enter the following parameter values:
• PSF configuration: Enter the name of the PSF configuration object. Must
be the same name as the name of the printer device description (in this
example, "PRT01").
• Library: QGPL (the default or any library name).
• User resource library list: Specifies the user resource library list to be
used for searching AFP resources.
• Device resource library list: Specifies the device resource library list to
be used for searching AFP resources (in this example, *JOBLIBL).
• IPDS pass through: IPDS pass through reduces the PSF/400 conversion
time for some *SCS and *IPDS spooled files. Enter *YES or *NO (in this
example, *YES).
• Activate release timer: Specifies the point at which the release timer
(RLSTMR) is activated. Leave the default value "*NORDYF".
• Release timer: This is the timer whose value is referenced by the Activate
release timer (ACTRLSTMR) parameter.
If the ACTRLSTMR parameter is set to *NORDYF, the release timer
parameter specifies the amount of time to wait after the last page of the last
ready spooled file has printed before releasing the printer (in this example,
*SEC15).
Note: If only one system is using the printer, specify *NOMAX. There is no
need to release the printer for another system.
• Restart timer: Specifies the amount of time to wait before the printer writer
attempts to re-establish either a session or dialog.
• SNA retry count: Specifies the number of retry attempts to establish a
session. This is the number of retries that PSF/400 makes to establish a
connection with a printer.
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
PSF configuration . . . . . . . > PRT01 Name
Library . . . . . . . . . . . > QGPL Name, *CURLIB
User resource library list . . . *JOBLIBL *JOBLIBL, *CURLIB, *PRTF...
Device resource library list . . *DFT Name, *DFT
+ for more values
IPDS pass through . . . . . . . *Yes *NO, *YES
Activate release timer . . . . . *NORDYF *NORDYF, *IMMED...
Release timer . . . . . . . . . *SEC15 1-1440, *NOMAX, *SEC15...
Restart timer . . . . . . . . . *IMMED 1-1440, *IMMED
SNA retry count . . . . . . . . 2 1-99, *NOMAX
Delay time between SNA retries 10 0-999
Text 'description' . . . . . . . PSF configuration object for PRT01
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Chapter 11. Configuring LAN-attached printers 229
Note: Even if the parameter name is “SNA retry count”, this is also valid for
TCP/IP when the PTF SF42745 (V3R2) is installed on the system.
• Delay time between retries: 10
• Text 'description': A description for your PSF configuration object
To continue, press F10 (additional parameters) and then the Page Down key.
The display shown in Figure 173 appears.
Figure 173. Create PSF Configuration object V3R2 (Part 2 of 3)
3. Enter the following parameter values:
• Blank page: Specifies whether PSF/400 issues a blank page after every
separator page and spooled file copy that contains an odd number of
pages. This parameter is for a continuous forms printer.
• Page size control: Specifies whether the page size (forms) in the printer is
set by PSF/400. This parameter only applies to: IBM 4230, 4247, 4028,
6404, 6408, 6412, and IBM network printers.
Note: If you change the drawers for using different paper sizes, enter *YES
for this parameter.
• Resident fonts: Specifies if the printer resident fonts are used by
PSF/400.
• Resource retention: Specifies whether resource retention across spooled
files is enabled.
• Edge orient: When the page rotation value of a spooled file is *COR or
*AUTO and the system rotates the output, a 90-degree rotation is normally
used. When this parameter is *YES, PSF/400 rotates the output 270
degrees instead of 90 degrees.
• Remote location name: The IP address of your printer (in this example,
9.99.99.999).
• TCP/IP port: 5001
• TCP/IP activation timer: *NOMAX
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
Additional Parameters
Blank page . . . . . . . . . . . *NO *YES, *NO
Page size control . . . . . . . *NO *NO, *YES
Resident fonts . . . . . . . . . *YES *YES, *NO
Resource retention . . . . . . . *YES *YES, *NO
Edge orient . . . . . . . . . . *NO *YES, *NO
Remote location:
Name or address . . . . . . . '9.99.99.999'
TCP/IP port . . . . . . . . . . 5001 1-65535, *NONE
TCP/IP activation timer . . . . *NOMAX 1-2550, *NOMAX
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
230 IBM AS/400 Printing V
Note: If only one AS/400 system uses the printer, use the default value
(170 seconds). If more than one system shares the printer, set the value to
*NOMAX, which causes PSF/400 to wait to establish a connection.
To continue, press the Page Down key. The display shown in Figure 174
appears.
Figure 174. Create PSF Configuration object V3R2 (Part 3 of 3)
4. Leave the default parameters values, and press the Enter key to create the
PSF configuration object.
11.1.2 Configuring LAN-attached IPDS printers on V3R7 and later
If you migrate from V3R1, V3R2, or V3R6 to V3R7 or later, always delete all the
printer device descriptions and the associated WRKAFP2-created data areas
(V3R1 and V3R6). You can check that all objects are deleted by using the Work
with Objects (WRKOBJ) command and specifying the name of the printer as the
object name.
11.1.2.1 Creating a device description
To create the device description for your printer, complete these steps:
1. Type the Create Device description Printer (CRTDEVPRT) command on any
command line and press F4 (Prompt). The display shown in Figure 175
appears.
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
PSF defined option . . . . . . . *NONE *NONE
+ for more values
Replace . . . . . . . . . . . . *YES *YES, *NO
Authority . . . . . . . . . . . *LIBCRTAUT Name, *LIBCRTAUT, *CHANGE...
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Chapter 11. Configuring LAN-attached printers 231
Figure 175. Create Device Description-V3R7 and later (Part 1 of 6)
2. On this display, enter the following parameter values:
• Device description: The name of your printer (in this example, "PRT01")
• Device class: *LAN
• Device type: *IPDS
• Device model: 0
Then, press the Enter key to continue. The display shown in Figure 176
appears.
Figure 176. Create Device Description-V3R7 and later (Part 2 of 7)
On this display, set the LAN attachment parameter value to *IP.
To continue, press the Enter key. The display shown in Figure 177 on page
232 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . PRT01 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...
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 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
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
232 IBM AS/400 Printing V
Figure 177. Create Device Description-V3R7 and later (Part 3 of 7)
3. On this display, leave the default value *YES for the advanced function
printing parameter.
To continue, press the Enter key. The display shown in Figure 178 appears.
Figure 178. Create Device Description-V3R7 and later (Part 4 of 7)
4. On this display, enter the following parameter values:
• Port number: 5001
• Online at IPL: *YES
• Font identifier: 11 (or another font ID used as the default font)
• Form feed: Specifies the form feed attachment used for this printer. Enter
*AUTOCUT for page printer, or *CONT for a continuous forms printer (in
this example, *AUTOCUT).
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 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
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 233
Leave the default values for the other parameters, and press the Enter key to
continue. The display shown in Figure 179 appears.
Figure 179. Create Device Description-V3R7 and later (Part 5 of 7)
You can leave the default value *INQ for the printer error message parameter.
To continue, press the Page Down key. The display shown in Figure 180
appears.
Figure 180. Create Device Description-V3R7 and later (Part 6 of 7)
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > PRT01 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Printer error message . . . . . *INQ *INQ, *INFO
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Message queue . . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . *NOMAX 1-2550, *NOMAX
Maximum pending request . . . . 6 1-31
Print while converting . . . . . *YES *NO, *YES
Print request timer . . . . . . *NOMAX 1-3600, *NOMAX
Form definition . . . . . . . . F1C10110 Name
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Remote location:
Name or address '9.99.99.99'
User-defined options . . . . . . *NONE Name, *NONE
+ for more values
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
234 IBM AS/400 Printing V
5. On this display, enter the following parameter values:
• Activation timer: *NOMAX
Note: If only one AS/400 system uses the printer, use the default value
(170 seconds). If more than one system shares the printer, set the value to
*NOMAX, which causes PSF/400 to wait to establish a connection.
• Remote location: The IP address of your printer (in this example,
9.99.99.99).
You can leave the default values for the other parameters.
To continue, press the Page Down key. The display shown in Figure 181
appears.
Figure 181. Create Device Description-V3R7 and later (Part 7 of 7)
On this display, enter the following parameter values:
• User-defined object: The name of the PSF configuration object (the one
created in the next step with the CRTPSFCFG command, in this example,
NP17)
• Library: Any library name (in this example, QGPL)
• Object type: *PSFCFG
• Text 'description': A text description for your printer configuration object
You can leave the default parameter values for the other parameters.
Then, press the Enter key to create the device description. You will receive the
message Description for device PRT01 created.
11.1.2.2 Creating the PSF configuration object
To create the PSF configuration support, follow these steps:
1. Enter the Create PSF configuration (CRTPSFCFG) command on any command
line, and press F4 (Prompt). The display shown in Figure 182 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
User-defined object:
Object . . . . . . . . . . . . NP17 Name, *NONE
Library . . . . . . . . . . QGPL Name, *LIBL, *CURLIB
Object type . . . . . . . . . *PSFCFG *DTAARA, *DTAQ, *FILE...
Data transform program . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
User-defined driver program . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Text 'description' . . . . . . . Device description for PRT01
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 235
Figure 182. Create PSF Configuration object-V3R7 and later (Part 1 of 3)
2. On this display, enter the following parameter values:
• PSF configuration: Any name, but must correspond to the name specified
in the DEVD user-defined object parameter.
Note: The same PSF configuration object can be used for more than one
printer.
• Library: Any library name, but must correspond to the name specified in
the DEVD user-defined object library parameter.
• User resource library list: Specifies the user resource library list to be
used for searching AFP resources.
• Device resource library list: Specifies the device resource library list to
be used for searching AFP resources.
• IPDS pass through: IPDS pass through reduces the PSF/400 conversion
time for some *SCS or *IPDS spooled files. Enter *YES or *NO (in this
example, *YES).
• Activate release timer: Specifies the point at which the release timer
(RLSTMR) is activated. Leave the default value NORDYF.
• Release timer: This is the timer whose value is referenced by the Activate
Release Timer (ACTRLSTMR) parameter.
If the ACTRLSTMR parameter is set to *NORDYF, the release timer
parameter specifies the amount of time to wait after the last page of the last
ready spooled file has printed before releasing the printer (in this example,
*SEC15).
Note: If only one system is using the printer, specify *NOMAX. There is no
need to release the printer for another system.
• Restart timer: Specifies the amount of time to wait before the printer writer
attempts to re-establish either a session or dialog.
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
PSF configuration . . . . . . . > NP17 Name
Library . . . . . . . . . . . QGPL Name, *CURLIB
User resource library list . . . *JOBLIBL *JOBLIBL, *CURLIB, *PRTF...
Device resource library list . . *DFT Name, *DFT
+ for more values
IPDS pass through . . . . . . . *YES *NO, *YES
Activate release timer . . . . . *NORDYF *NORDYF, *IMMED...
Release timer . . . . . . . . . > *SEC15 1-1440, *NOMAX, *SEC15...
Restart timer . . . . . . . . . *IMMED 1-1440, *IMMED
APPC and TCP/IP retry count . . 15 1-99, *NOMAX
Delay between APPC retries . . . 90 0-999
Automatic session recovery . . . *NO *NO, *YES
Acknowledgment frequency . . . . 100 1-32767
Text 'description' . . . . . . . PSF configuration object
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
236 IBM AS/400 Printing V
• APPC and TCP/IP retry count: Named SNA retry count in V3R7 and
V4R1. Specifies the number of retry attempts to establish a session. This is
the number of retries that PSF/400 makes to establish a connection with a
printer.
Note: Even if the name is “SNA retry count” in V3R7 and V4R1, this is also
valid for TCP/IP when PTF SF42655 (V3R7) or SF43250 (V4R1) is
installed on the system.
• Delay time between retries: 90 (the default value).
• Automatic session recovery (V4R2): Specifies whether PSF/400
automatically attempts to resume printing when a session has been
unexpectedly ended by a device.
• Acknowledgement frequency (V4R2): Specifies the frequency, in pages,
with which PSF/400 sends IPDS acknowledgment requests to a printer.
The acknowledgment request responses from the printer contain
information as to the status of pages sent to the printer.
• Text 'description': A description for your PSF configuration object.
To continue, press F10 (additional parameters) and then the Page Down key.
The display shown in Figure 183 appears.
Figure 183. Create PSF Configuration object V3R7 and later (Part 2 of 3)
3. Enter the following parameter values:
• Blank page: Specifies whether PSF/400 issues a blank page after every
separator page and spooled file copy that contains an odd number of
pages. This parameter is for continuous forms printers.
• Page size control: Specifies whether the page size (forms) in the printer is
set by PSF/400. This parameter only applies to the following printers: IBM
4230, 4247, 4028, 6404, 6408, 6412, and IBM network printers.
Note: If you change the drawers for using different paper sizes, enter *YES
for this parameter.
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
Additional Parameters
Blank page . . . . . . . . . . . *NO *YES, *NO
Page size control . . . . . . . *NO *NO, *YES
Resident fonts . . . . . . . . . *YES *YES, *NO
Resource retention . . . . . . . *YES *YES, *NO
Edge orient . . . . . . . . . . *NO *YES, *NO
Use outline fonts . . . . . . . *YES *YES, *NO
PSF defined option . . . . . . . *NONE
+ for more values
Font substitution messages . . . *YES *YES, *NO
Capture host fonts at printer . *NO *NO, *YES
Cut sheet emulation mode . . . . *NONE *NONE, *CHKFIRST, *CHKALL
Replace . . . . . . . . . . . . *YES *YES, *NO
Authority . . . . . . . . . . . *LIBCRTAUT Name, *LIBCRTAUT, *CHANGE...
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Chapter 11. Configuring LAN-attached printers 237
• Resident fonts: Specifies if the printer resident fonts are used by
PSF/400.
• Resource retention: Specifies whether the resource retention across
spooled files is enabled.
• Edge orient: When the page rotation value of a spooled file is *COR or
*AUTO and the system rotates the output, 90 degree rotation is normally
used. When this parameter is *YES, PSF/400 rotates the output 270
degrees instead of 90 degrees.
• Use Outline fonts: Specifies whether the user wants the requested
downloadable AFP raster fonts replaced with the equivalent downloadable
outline fonts.
Note: In V3R7 and V4R1, the Remote location name, TCP/IP port, and
Activation timer parameters are displayed in the CRTPSFCFG command.
They are ignored, since they are part of the printer device description.
• Font substitution messages (V4R2): Specifies whether PSF/400 logs the
font substitution message.
• Capture host fonts (V4R2): Specifies whether the printer should capture
host downloaded fonts. See 4.10, “Font capturing” on page 108, for
detailed information on font capturing.
• Cut sheet emullation (V4R2): This parameter is for continuous forms
printers. It specifies to what degree PSF/400 will do size checking of the
document when using Cut Sheet Emulation.
To continue, press the Page Down key. The display shown in Figure 184
appears.
Figure 184. Create PSF Configuration object V3R7 and later (Part 3 of 3)
Leave the default parameter values, and press the Enter key to create the
PSF configuration object.
11.1.3 TCP/IP BOOT service for V4R1 and later
Bootstrap Protocol (BOOTP) provides a dynamic method for associating
workstations with servers and assigning IP addresses. The BOOTP Server is
used to configure and provide support for the I-DATA-7913 Lan attachment. This
attachment can be use to connect Twinax or Coax IPDS printers to the AS/400
system. Figure 185 on page 238 shows the Add BOOTP Table Entry display.
Create PSF Configuration (CRTPSFCFG)
Type choices, press Enter.
PSF defined option . . . . . . . *NONE *NONE
+ for more values
Replace . . . . . . . . . . . . *YES *YES, *NO
Authority . . . . . . . . . . . *LIBCRTAUT Name, *LIBCRTAUT, *CHANGE...
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
238 IBM AS/400 Printing V
Figure 185. Add BOOTP Table Entry display
The parameters are explained here:
• Client Host name: The name of the client host system.
• Mac address: The physical network address of the hardware that the client
uses to access the network.
• IP address: The Internet Protocol (IP) address defined for the client.
• Hardware type: The type of network connection hardware the client is using
to access the network. Valid values for hardware type are:
– One Ethernet
– Six Token-Ring or IEEE Ethernet (802.3)
• Gateway IP address: The gateway IP address of the network on which the
client is loaded.
• Subnet mask: The subnet mask of the network on which the client is loaded.
11.2 Configuring LAN-attached ASCII printers
ASCII printers can be attached directly on the LAN (Token-Ring or Ethernet)
using the following connection methods:
• PJL drivers *IBMPJLDRV or *HPPJLDRV (this support is available on OS/400
V3R7 and later releases)
• SNMP drivers
11.2.1 Configuring LAN-attached ASCII printers using LexLink
The following configuration example is for V3R7 and later. For prior releases
(V3R1, V3R2, and V3R6), refer to Chapter 1 in AS/400 Printing IV, GG24-4389.
If you migrate from V3R1, V3R2, or V3R6 to V3R7 and later, we recommend that
you delete the device descriptions for any ASCII printer LAN-attached using the
LexLink protocol, and then re-create them (see Figure 186).
Add BOOTP Table Entry
System: SYSTEM05
Network device:
Client host name . . . prt7913
MAC address . . . . . . 098390907747A
IP address . . . . . . 99.99.99.99
Hardware type . . . . . 6
Network routing:
Gateway IP address . . 99.99.99.99
Subnet mask . . . . . . 99.999.99.99
Boot:
Type . . . . . . . . .
File name . . . . . . .
File path . . . . . . .
F3=Exit F12=Cancel
Chapter 11. Configuring LAN-attached printers 239
To create the device description for your printer, follow these steps:
1. Type the Create Device description Printer (CRTDEVPRT) command on the
command line, and press F4 (Prompt).
Figure 186. CRTDEVPRT for LAN-attached ASCII printer using LexLink (Part 1 of 3)
2. Enter the following parameter values:
• Device description: The name of your printer (in this example, MYPRT)
• Device class: *LAN
• Device type: 3812
• Device model: 1
• LAN attachment: *LEXLINK
• LAN remote adapter address: Specifies the 12-character hexadecimal
LAN address of the ASCII printer.
Note: If an internal INA card is used, display the address using the
printer's operator panel. For a MarkNet XLe, the address is printed on the
back side of the device.
• Adapter type: Specify *INTERNAL if an internal INA card is used or *External
if a MarkNet XLe is used.
• Port number: For the MarkNet XLe, use the following values:
– 0 for serial port
– 1 for parallel port
– 2 for parallel port 2
Note: This parameter does not appear if the adapter type is *INTERNAL.
• Online at IPL: *YES
• Font identifier: 11 (or another font ID used as the default font)
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > MYPRT Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *LEXLINK *LEXLINK, *IP, *USRDFN
Switched line list . . . . . . . Name
+ for more values
LAN remote adapter address . . . 10005A1095A2 000000000001-FFFFFFFFFFFE
Adapter type . . . . . . . . . . > *EXTERNAL *INTERNAL, *EXTERNAL
Adapter connection type . . . . *PARALLEL *PARALLEL, *SERIAL
Port number . . . . . . . . . . 1 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancelre
F13=How to use this display F24=More keys
240 IBM AS/400 Printing V
• Form feed: Specifies the form feed attachment used for this printer. Enter
*AUTOCUT for page printer or *CONT for a continuous forms printer (in this
example, *AUTOCUT).
Figure 187. CRTDEVPRT for LAN-attached ASCII printer using LexLink (Part 2 of 3)
3. On the display shown in Figure 187, enter the following parameter values:
• Activation timer: *NOMAX
Note: If only one AS/400 system uses the printer, leave the default value
(170). If more than one system shares the printer, set the value to
*NOMAX, which causes the writer to wait to establish a connection.
• Inactivity timer: Specifies the amount of time the printer writer keeps a
lock on the device before releasing it (in this example, *SEC15).
Note: If only one system is using the printer, specify *NOMAX, no need to
release the printer for another system.
• Host print transform: *YES or *NO, but normally *YES since the spooled
files from the AS/400 system must be transformed from EBCDIC to ASCII.
• Manufacturer type, model: Enter a value according your printer type (in
this example, *IBM4312).
• Paper source 1: Enter your default paper format (in this example, *A4).
• Paper source 2: Enter your default paper format (in this example, *A4).
• Envelope source: Enter your default envelope format (in this example,
*C5).
You can leave the default parameter values for the other parameters.
To continue, press the Page Down key. The display shown in Figure 188
appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Printer error message . . . . . *INQ *INQ, *INFO
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . *NOMAX 1-2550, *NOMAX
Inactivity timer . . . . . . . . *SEC15 1-30, *ATTACH, *NOMAX...
Host print transform . . . . . . *YES *NO, *YES
Manufacturer type and model . . *IBM4312
Paper source 1 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Paper source 2 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Envelope source . . . . . . . . *B5 *MFRTYPMDL, *MONARCH...
ASCII code page 899 support . . *NO *NO, *YES
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 241
Figure 188. CRTDEVPRT for LAN-attached ASCII printer using LexLink (Part 3 of 3)
4. Enter a text description for your printer configuration object. You can leave the
default parameter values for the other parameters. Then press the Enter key
to create the device description.
11.2.2 Configuring LAN-attached ASCII printers using PJL drivers
To be LAN attached with the PJL driver, your printer must support Printer Job
Language (PJL) and PCL. See 12.1.5, “Print Job Language (PJL) support” on
page 255, for more information.
Before starting the configuration, check for the following PTFs by using the
Display Program Temporary Fix (DSPPTF) command:
• V3R7: SF43497, SF44339, and SF45336
• V4R1 and V4R2: Part of the base code
Note: The PJL drivers are not supported on V3R2.
To create the device description for your printer, follow these steps:
1. Type the Create Device description Printer (CRTDEVPRT) command on any
command line, and press F4 (Prompt). The display shown in Figure 189 on
page 242 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Character identifier:
Graphic character set . . . . *SYSVAL 1-32767, *SYSVAL
Code page . . . . . . . . . . 1-32767
User-defined options . . . . . . *NONE Name, *NONE
+ for more values
User-defined object:
Object . . . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Object type . . . . . . . . . *DTAARA, *DTAQ, *FILE...
Data transform program . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
User-defined driver program . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Text 'description' . . . . . . . Device description MYPRT(NP12)
Bottom
242 IBM AS/400 Printing V
Figure 189. CRTDEVPRT for the LAN-attached ASCII printer using the PJL driver (Part 1 of 7)
2. On this display, enter the following parameter values:
• Device description: The name of your printer (in this example, NPLAN)
• Device class: *LAN
• Device type: 3812
• Device model: 1
Then, press the Enter key to continue. The display shown in Figure 190
appears.
Figure 190. CRTDEVPRT for LAN-attached ASCII printer using PJL driver (Part 2 of 7)
3. On this display, set the LAN attachment parameter value to *IP.
To continue, press the Enter key. The display shown in Figure 191 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . NPLAN Name
Device class . . . . . . . . . . *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . 1 0, 1, 2, 3, 4, 10, 13, 301...
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 243
Figure 191. CRTDEVPRT for the LAN-attached ASCII printer using the PJL driver (Part 3 of 7)
4. On this display, enter the following parameter values:
• Port number: Specify 2501 for IBM Network printers (IBM 4312, 4317, and
4324) or 9100 for all HP, Lexmark, and most IBM printers.
Note: For more information on port number, see 12.1.4, “Port number” on
page 254.
• Online at IPL: *YES
• Font identifier: 11 (or another font ID used as the default font)
• Form feed: Specifies the form feed attachment used for this printer. Enter
*AUTOCUT for a page printer or *CONT for a continuous forms printer (in this
example, *AUTOCUT).
Leave the default values for the other parameters and press the Enter key to
continue. The display shown in Figure 192 on page 244 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Port number . . . . . . . . . . 2501 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
244 IBM AS/400 Printing V
Figure 192. CRTDEVPRT for the LAN-attached ASCII printer using the PJL driver (Part 4 of 7)
You can leave the default value *INQ for the Printer error message parameter.
To continue, press the Page Down key. The display shown in Figure 193
appears.
Figure 193. CRTDEVPRT for the LAN-Attached ASCII Printer using the PJL driver (Part 5 of 7)
5. On this display, enter the following parameter values:
• Activation timer: 170
• Inactivity timer: Specifies the amount of time the printer writer keeps a
lock on the device before releasing it (in this example, *SEC15).
Note: If only one system is using the printer, specify *NOMAX, no need to
release the printer for another system.
You can leave the default values for the other parameters.
To continue, press the Enter key. The display shown in Figure 194 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Port number . . . . . . . . . . 2501 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Printer error message . . . . . *INQ *INQ, *INFO
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . 170 1-2550, *NOMAX
Inactivity timer . . . . . . . . *SEC15 1-30, *ATTACH, *NOMAX
Host print transform . . . . . . *YES *NO, *YES
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 245
Figure 194. CRTDEVPRT for the LAN-attached ASCII printer using the PJL driver (Part 6 of 7)
6. On this display, enter the following parameter values:
• Manufacturer type, model: Enter a value according your printer type (in
this example, *IBM4317).
• Paper source 1: Enter your default paper format (in this example, *A4).
• Paper source 2: Enter your default paper format (in this example, *A4).
• Envelope source: Enter your default envelope format (in this example,
*C5).
You can leave the default parameter values for the other parameters.
To continue, press the Page Down key. The display shown in Figure 195 on
page 246 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . 170 1-2550, *NOMAX
Inactivity timer . . . . . . . . *SEC15 1-30, *ATTACH, *NOMAX...
Inactivity timer . . . . . . . . *ATTACH 1-30, *ATTACH, *NOMAX...
Type of parity . . . . . . . . . > *NONE *TYPE, *EVEN, *ODD, *NONE...
Host print transform . . . . . . *YES *NO, *YES
Manufacturer type and model . . *IBM4317
Paper source 1 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Paper source 2 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Envelope source . . . . . . . . *C5 *MFRTYPMDL, *MONARCH...
ASCII code page 899 support . . *NO *NO, *YES
Character identifier:
Graphic character set . . . . *SYSVAL 1-32767, *SYSVAL
Code page . . . . . . . . . . 1-32767
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
246 IBM AS/400 Printing V
Figure 195. CRTDEVPRT for the LAN-attached ASCII printer using the PJL driver (Part 7 of 7)
7. On this display, enter the following parameter values:
• Remote location: The IP address of your printer (in this example,
"9.99.80.145").
• System driver program: *IBMPJLDRV
Note: For which drivers to use, depending on the target printer, see 12.1.5,
“Print Job Language (PJL) support” on page 255.
• Text 'description': A description for your printer configuration object.
You can leave the default parameter values for the other parameters.
8. Press the Enter key to create the device description. You receive the message
Description for device NPLAN created. If you have any problems after the
configuration, see 12.1, “Communication, connection, and configuration
problems” on page 253, for detailed information.
11.2.3 Configuring LAN-attached ASCII printers using SNMP drivers
With OS/400 V4R5, a new PCL driver, the SNMP driver, is added. Simple
Network Management Protocol (SNMP) is a standard TCP/IP network protocol.
The SNMP print driver provides the functionality of the PJL driver but does not
require the target printer to support PJL commands. To use the SNMP print driver,
the following rules apply:
• For the SNMP print driver to work with a specific printer, the printer must
support the industry-standard Host Resource Management Information Base
(RFC 1514). We highly recommend (but it is not required) that the printer also
support the Printer Management Information Base (RFC 1759).
• If the printer is connected to a network adapter, the adapter must also be
compatible with RFC 1514.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Remote location:
Name and address . . . . . . . 9.99.80.145
User-defined options . . . . . . *NONE Name, *NONE
+ for more values
User-defined object:
Object . . . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Object type . . . . . . . . . *DTAARA. *DTAQ, *FILE...
Data transform program . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURRENT
System driver program . . . . . *IBMPJLDRV
Text 'description' . . . . . . . Device description for NPLAN printer
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 247
• If the printer is connected to an external network adapter that has more than
one port, the printer should be connected to the first parallel port, and there
should be no other SNMP-capable devices attached to the adapter.
• The printer and any adapter connected with the SNMP print driver must have
set the community to public. This is normally the default setting. Read-only
access to the public community is sufficient.
Note: Additional information on the SNMP print driver can be found in APAR
II03291.
Support for the SNMP print driver with IBM Infoprint 21 is also available at
OS/400 V4R4 and V4R3.
To create the device description for your printer, follow this process:
1. Type the Create Device description Printer (CRTDEVPRT) command on any
command line, and press F4 (Prompt). The display shown in Figure 196
appears.
Figure 196. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 1 of 7)
2. On this display, enter the following parameter values:
• Device description: The name of your printer (in this example, NPLAN)
• Device class: *LAN
• Device type: 3812
• Device model: 1
Then, press the Enter key to continue. The display shown in Figure 197 on
page 248 appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . NPLAN Name
Device class . . . . . . . . . . *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . 1 0, 1, 2, 3, 4, 10, 13, 301...
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
248 IBM AS/400 Printing V
Figure 197. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 2 of 7)
3. On this display, set the LAN attachment parameter value to *IP.
To continue, press the Enter key. The display shown in Figure 198 appears.
Figure 198. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 3 of 7)
4. On this display, enter the following parameter values:
• Port number: Specify 2501 for IBM Network printers (IBM 4312, 4317, and
4324), or 9100 for all HP, Lexmark, and most IBM printers.
Note: For more information on port number, see 12.1.4, “Port number” on
page 254.
• Online at IPL: *YES
• Font identifier: 11 (or another font ID used as the default font)
• Form feed: Specifies the form feed attachment used for this printer. Enter
*AUTOCUT for a page printer or *CONT for a continuous forms printer (in this
example, *AUTOCUT).
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Port number . . . . . . . . . . 2501 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 249
Leave the default values for the other parameters, and press the Enter key to
continue. The display shown in Figure 192 appears.
Figure 199. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 4 of 7)
You can leave the default value *INQ for the printer error message parameter.
To continue, press the Page Down key. The display shown in Figure 200
appears.
Figure 200. CRTDEVPRT for the LAN-Attached ASCII printer using the SNMP driver (Part 5 of 7)
5. On this display, enter the following parameter values:
• Activation timer: *NOMAX
Note: If only one AS/400 system uses the printer, use the default value
(170 seconds). If more than one system shares the printer, set the value to
*NOMAX, which causes the AS/400 system to wait to establish a connection.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Device description . . . . . . . > NPLAN Name
Device class . . . . . . . . . . > *LAN *LCL, *RMT, *VRT, *SNPT, *LAN
Device type . . . . . . . . . . > 3812 3287, 3812, 4019, 4201...
Device model . . . . . . . . . . > 1 0, 1, 2, 3, 4, 10, 13, 301...
LAN attachment . . . . . . . . . *IP *LEXLINK, *IP, *USRDFN
Port number . . . . . . . . . . 2501 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 . . . . . . . . . . . *AUTOCUT *TYPE, *CONT, *CUT, *AUTOCUT
Separator drawer . . . . . . . . *FILE 1-255, *FILE
Separator program . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Printer error message . . . . . *INQ *INQ, *INFO
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . *NOMAX 1-2550, *NOMAX
Inactivity timer . . . . . . . . *SEC15 1-30, *ATTACH, *NOMAX
Host print transform . . . . . . *YES *NO, *YES
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
250 IBM AS/400 Printing V
• Inactivity timer: Specifies the amount of time the printer writer keeps a
lock on the device before releasing it (in this example, *SEC15).
Note: If only one system is using the printer, specify *NOMAX. There is no
need to release the printer for another system.
• Host print transform: *YES or *NO, but normally *YES as the spooled
files from the AS/400 system must be transformed from EBCDIC to ASCII.
You can leave the default values for the other parameters.
To continue, press the Enter key. The display shown in Figure 201 appears.
Figure 201. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 6 of 7)
6. On this display, enter the following parameter values:
• Manufacturer type, model: Enter a value according your printer type (in
this example, *IBM4317).
• Paper source 1: Enter your default paper format (in this example, *A4).
• Paper source 2: Enter your default paper format (in this example, *A4).
• Envelope source: Enter your default envelope format (in this example,
*C5).
You can leave the default parameter values for the other parameters.
To continue, press the Page Down key. The display shown in Figure 202
appears.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Message queue . . . . . . . . . QSYSOPR Name, QSYSOPR
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Activation timer . . . . . . . . 170 1-2550, *NOMAX
Inactivity timer . . . . . . . . *SEC15 1-30, *ATTACH, *NOMAX...
Inactivity timer . . . . . . . . *ATTACH 1-30, *ATTACH, *NOMAX...
Type of parity . . . . . . . . . > *NONE *TYPE, *EVEN, *ODD, *NONE...
Host print transform . . . . . . *YES *NO, *YES
Manufacturer type and model . . *IBM4317
Paper source 1 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Paper source 2 . . . . . . . . . *A4 *MFRTYPMDL, *LETTER...
Envelope source . . . . . . . . *C5 *MFRTYPMDL, *MONARCH...
ASCII code page 899 support . . *NO *NO, *YES
Character identifier:
Graphic character set . . . . *SYSVAL 1-32767, *SYSVAL
Code page . . . . . . . . . . 1-32767
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Chapter 11. Configuring LAN-attached printers 251
Figure 202. CRTDEVPRT for the LAN-attached ASCII printer using the SNMP driver (Part 7 of 7)
7. On this display, enter the following parameter values:
• Remote location: The IP address of your printer (in this example,
9.99.80.145).
• User-defined options: *IBMSHRCNN causes the SNMP print driver to
open and close the data port on the printer for every copy of every spooled
file. This enables multiple writers and systems to share the printer. If this
option is specified, the Inactivity Time is ignored. This option must be
specified for the IBM Infoprint 21 printer.
• System driver program: *IBMSNMPDRV
Note: For which drivers to use, depending on the target printer, see 12.1.5,
“Print Job Language (PJL) support” on page 255.
• Text 'description': A description for your printer configuration object.
You can leave the default parameter values for the other parameters.
8. Then, press the Enter key to create the device description. You receive the
message Description for device NPLAN created. If you have any problems after
the configuration, see 12.1, “Communication, connection, and configuration
problems” on page 253, for detailed information.
Create Device Desc (Printer) (CRTDEVPRT)
Type choices, press Enter.
Remote location:
Name and address . . . . . . . 9.99.80.145
User-defined options . . . . . . *IBMSHRCNN Name, *NONE
+ for more values
User-defined object:
Object . . . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . Name, *LIBL, *CURLIB
Object type . . . . . . . . . *DTAARA. *DTAQ, *FILE...
Data transform program . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURRENT
System driver program . . . . . *IBMSNMPDRV
Text 'description' . . . . . . . Device description for NPLAN printer
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
252 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 253
Chapter 12. Problem determination techniques
This chapter discusses problems related to installing and driving printers. It also
presents methods and techniques that may be used to isolate the source of the
problems. It points to various documentation sources where additional
information can be found. It is not, however, a substitute for
problem-determination methods described in the system, device manuals, or
online help.
No performance problems are discussed in this chapter. However, you can find
details of this in Appendix A, “PSF/400 performance factors” on page 279.
For detailed information on printer configuration, see Chapter 11, “Configuring
LAN-attached printers” on page 223. If you are using a remote output queue, see
Chapter 8, “Remote system printing” on page 171.
12.1 Communication, connection, and configuration problems
This topic covers printer problems related to communication, connection, and
configuration. For the different printer attachment methods, see 1.4, “AS/400
printer attachment methods” on page 15.
12.1.1 Setting up a TCP/IP network on the AS/400 system
To drive a TCP/IP attached printer, the TCP/IP subsystem must be properly
configured and has to be up and running. Use the following steps to set up a
TCP/IP network on the AS/400 system:
1. Create a Token-Ring or Ethernet line description using the CRTLINTRN or
CRTLINETH command.
2. Vary on the line description using the VRYCFG command.
3. Add a TCP/IP interface using the ADDTCPIFC command.
4. Start TCP/IP interface using the STRTCPIFC command.
5. Add a TCP/IP route definition, if necessary, using the ADDTCPRTE command.
6. Start TCP/IP with the STRTCP command.
If your TCP/IP network is already implemented, use the WRKACTJOB command to
check if QTCPIP is running. If it is not running, use the STRTCP command to start it.
12.1.2 SSAP values in the line description
Use the DSPLIND command to check the Source Service Access Points (SSAP)
values in the line description according to the type of communication used. Keep
these points in mind:
• You must have the following SSAP entries when attaching IPDS printers or
ASCII printers using the PJL drivers (Version 3.0 Release 7.0 or later), or
using remote system printing with a connection type of *IP:
SSAP 12 *MAXFRAME *NONSNA
SSAP AA *MAXFRAME *NONSNA
254 IBM AS/400 Printing V
• The line description must contain the following SSAP entries when attaching
ASCII printers using the Lexlink protocol (using a Lexmark Internal Network
Adapter or a MarkNet XLe external LAN adapter):
SSAP 12 *MAXFRAME *NONSNA
SSAP 16 *MAXFRAME *NONSNA
SSAP 1A *MAXFRAME *NONSNA
12.1.3 Pinging the TCP/IP address
When the configuration is completed, test the TCP/IP connection using the PING
command on the AS/400 system with the IP address of your printer:
PING '123.1.2.3'
• If the PING is successful, vary on the printer:
VRYCFG CFGOBJ(Printer_dev) CFGTYPE(*DEV) STATUS(*ON)
Then start the print writer (if not using a remote output queue):
STRPRTWTR DEV(Printer_dev)
If you are using a remote output queue, enter:
STRRMTWTR DEV(Printer_dev)
Print a job as a test (for example, a print screen). If this fails to print, continue
with the following section.
• If the PING fails, perform these actions:
a. Verify the configurations of the AS/400 system, TCP/IP subsystem, the
printer, and any intervening devices such as routers. Can you PING any of
these devices? Then contact your LAN coordinator for assistance.
b. Verify that the AS/400 LAN adapter card and printer hardware are fully
operational. Use the WRKTCPSTS command to access a menu of useful
commands, including the option to check whether the TCP/IP interface with
your LAN adapter card is active (Work with TCP/IP interface status).
c. Check the IP address of the printer LAN card (printer setup) and the one
specified in the AS/400 configuration.
12.1.4 Port number
The port number is important for connecting the printer. The value varies
according to the printer type. The TCP/IP port parameter is in the PSF
configuration object in Version 3.0 Release 2.0 and in the device description in
Version 3.0 Release 7.0 and later.
Note: The port number is a parameter of the WRKAFP2 command in Version 3.0
Release 1.0 and Version 3.0 Release 6.0.
The following port numbers are used according to the printer type and the
attachment method:
5001 IBM IPDS printer on the LAN (TCP/IP)
2501 IBM Network Printers (4312, 4317, 4324) and IBM Infoprint printers
(4320, 4322, 4332) in ASCII mode, network-attached, and using the
PJL print driver
Chapter 12. Problem determination techniques 255
9100 IBM Infoprint Color 8, older IBM laser printers (for example, 4039), all
HP, all Lexmark in ASCII mode, network-attached, and using the PJL
driver
Note: If the printer LAN attachment card (internal or external) has
more than one entry, the port number can be 9100, 9101, or 9102.
If none of these values is successful, consult your printer's
manufacturer to determine if your printer has a dedicated port that
accepts PCL/PJL commands.
12.1.5 Print Job Language (PJL) support
The following printers support PCL and PJL and can be TCP/IP LAN-attached
using the PJL drivers (Version 3.0 Release 7.0 and later):
• IBM 4039 Plus and IBM Network Printer 12, 17, and 24
• Lexmark Optra family
• HP LaserJet IIISi
• HP LaserJet 4, 5, and 6 family
Note: There is no PJL support on early IBM 4039 models nor on the HP LaserJet
III.
If PJL is not supported, the message CPD337F is returned. If in doubt, consult
your printer's manufacturer to determine if your printer supports PCL and PJL.
Use the *IBMPJLDRV driver for all IBM printers (for example, IBM Network
Printer 12 and 17 and Infoprint 20 and 32). Note that IBM Infoprint 12 does not
support PJL.
Use the *HPPJLDRV driver for all HP and HP compatible printers.
12.1.6 Message PQT3603
The message PQT3603 is issued for a connection problem with a LAN-attached
IPDS printer configured as AFP(*YES). The message PQT3603 includes the
name of the printer, the remote location name, and an error code defining the
failed condition. For an example, see Figure 203.
Figure 203. Message PQT3603
Depending on the error code, perform the following recovery actions:
• 10: The specified remote location name (RMTLOCNAME) was rejected.
Specify a correct remote location name. This is either the IP address of the
printer or its corresponding name in a host table entry list. Verify that the IP
address at the device and the remote location name in the PSF configuration
object (Version 3.0 Release 2.0) or in the printer device description (Version
3.0 Release 7.0 and later) are the same. If you are using a RMTLOCNAME
name, check the IP address in the TCP/IP host table.
• 15: The activation timer (ACTTMR) value configured for the device expired
before the device was available.
Message . . . . : Connection with device PRT1 cannot be established.
Cause . . . . . : A session cannot be established with the device at
RMTLOCNAME PRT1B02, using PORT 5001. The error code is 10.
256 IBM AS/400 Printing V
Increase the value for ACTTMR in the PSF configuration object (Version 3.0
Release 2.0) or in the printer device description (Version 3.0 Release 7.0 and
later), or determine if your network has a problem.
• 22: The device did not respond to a connection request.
The device may not be able to accept a connection request because:
– Another writer (possibly on another system) is sending it data.
– It is in the process of ending a connection with another writer.
– It is in an error condition on another system.
– The device is configured on another system where sharing of the device
has not been configured.
If the device has a connection with another writer or the device is in the
process of ending a connection with another writer, this is a normal error code.
Otherwise, verify that the port number (PORT) specified in the PSF
configuration object (Version 3.0 Release 2.0) or in the printer device
description (Version 3.0 Release 7.0 and higher) matches the port number
specified at the device. If these values match, you may need to reset the
device before starting the writer.
Also refer to the information in the following point on error codes 20-39. If the
problem continues, report it using the ANZPRB command.
• 20-39: A communications failure occurred.
Verify configuration values and check for problems in your network. Consider
increasing the value specified for RETRY in the PSF configuration object
used.
If a PSF configuration object is not in use, create one (use the CRTPSFCFG
command). In Version 3.0 Release 2.0, the PSF configuration object must
have the same name as the printer. In Version 3.0 Release 7.0 and later,
specify the name of the PSF configuration object in the printer device
description using the USRDFNOBJ parameter.
After correcting the problem, start the printer writer to begin processing again.
If the problem continues, report it using the ANZPRB command.
• 41-59: An internal failure occurred.
These error codes (and especially 46) occur with:
– A hardware problem on the printer.
– Down-level printer microcode levels. Install the latest one for ETH or TR,
CTL, and IPDS. Print the printer configuration page to see the level of the
installed microcode.
– Check any routers and their definitions, any switch box or hubs, and
cabling.
Note: If no error code is returned in the message PQT3603, perform the same
actions as for error code 41-59.
After correcting the problem, start the printer writer to begin processing again. If
the problem continues, report it using the ANZPRB command.
Chapter 12. Problem determination techniques 257
12.1.7 Configuring LAN-attached IPDS printers
The configuration of IPDS LAN attached printers to an AS/400 system has
changed with different versions and releases:
• Configuring LAN-attached IPDS printers on Version 3.0 Release 1.0
On Version 3.0 Release 1.0, you need a device description (CRTDEVPRT)
and a data area created by the WRKAFP2 command. You must first create the
WRKAFP2 command. The instructions to create and use it are in the cover
letter of PTF SF29961. The source code for the command is also included in
this cover letter. The name of the data area must be the same as the printer
name.
• Configuring LAN-attached IPDS printers on Version 3.0 Release 2.0
On Version 3.0 Release 2.0, you need a device description (CRTDEVPRT)
and a PSF configuration object (CRTPSFCFG). The name of the PSF
configuration must be the same as the name of the printer.
Note: If you migrate from Version 3.0 Release 1.0 to Version 3.0 Release 2.0,
during the first Start Printer Writer (STRPRTWTR), a PSF configuration object
is automatically created by the system and includes the WRKAFP2 data area
values (used in V3R1). This PSF configuration object is placed in the library
QGPL and has the same name as the printer device description.
• Configuring LAN-attached IPDS printers on Version 3.0 Release 6.0
On Version 3.0 Release 6.0, you need a device description (CRTDEVPRT)
and a data area created by the WRKAFP2 command. You must first create the
WRKAFP2 command. The instructions to create and use it are in the cover
letter of PTF SF31461. The source code for the command is also included in
this cover letter. The name of the data area must be the same as the printer
name.
• Configuring LAN-attached IPDS printers on Version 3.0 Release 7.0 and
later
On Version 3.0 Release 7.0 and later, you need a device description
(CRTDEVPRT) and a PSF configuration object (CRTPSFCFG). The name of
the PSF configuration can be any name, but this object must be referenced in
the USRDFNOBJ parameter of the device description.
The RMTLOCNAME, PORT, and ACTTMR parameters are now part of the
printer device description. However, they still appear in the CRTPSFCFG
Version 3.0 Release 7.0 and Version 4.0 Release 1.0, but are not used here.
Take care that you enter the values for these parameters in the correct place
(that is, the device description).
Note: If you migrate from earlier releases of OS/400 to Version 3.0 Release
7.0 or later, we recommend that you:
– Delete existing printer device descriptions.
– Delete existing data areas created by the WRKAFP2 command (V3R1 and
V3R6).
Re-create new printer device descriptions and new PSF configuration objects.
For detailed information on printer configuration, see 11.1, “Configuring
LAN-attached IPDS printers” on page 223.
258 IBM AS/400 Printing V
12.1.8 Configuring for remote system printing
Some printers are unable to accept host printing commands directly, but must
have them interpreted by another process. The line printer daemon (LPD) is one
such common process, and is frequently used when printing to an ASCII
LAN-attached printer using some kind of LAN adapter (for example, a JetDirect
card or external box). The daemon runs inside the card and is regarded as
another system as far as OS/400 is concerned.
To print to such a remote “system”, you need to create a remote output queue
using the normal Create Output Queue (CRTOUTQ) command. The most
common problems result from the wrong print queue name. See 12.1.9, “Remote
printer queue names” on page 258, for details. Also check for the correct
destination options to avoid timeout problems or the wrong number of copies.
This is covered in 8.2.2, “Destination options” on page 176.
If host print transform is used and if the page size parameter in your printer file
does not match a page size entry in the WSCST table, the letter format is used as
the default format. In this case, the printer may display the message “Load
Letter”. See 8.2.4, “‘Load Letter’ message on the printer” on page 179, for
workarounds to this problem.
Note: If possible, attach your remote ASCII printers using the PJL drivers
(Version 3.0 Release 7.0 and later) instead of a remote output queue. This
provides greater functionality. See 11.2.2, “Configuring LAN-attached ASCII
printers using PJL drivers” on page 241, for detailed information.
12.1.9 Remote printer queue names
If you are using a remote output queue with a connection type *IP and a
destination type *OTHER to attach an ASCII printer using TCP/IP, you must
specify the name of the remote printer queue on the target system. This name
varies depending on the device supplying the LPD function.
Note: This also applies if you use the SNDTCPSPLF command.
Table 22 shows some of the more frequently-encountered printer queue names.
Table 22. Internal print queue names for selected print devices
Interface used Queue name
HP JetDirect Card (internal) ‘text‘ for unformatted output
‘text‘ for formatted output
HP JetDirect Server (external) (3 ports - 1 IP
address)
‘text1‘ or ‘raw1‘ for port 1
‘text2‘ or ‘raw2‘ for port
‘text3‘ or ‘raw3‘ for port
Integrated Network Option (IBM 4039, 3112,
3116, Lexmark OPTRA)
‘pro0‘
Lexmark MarkNet XLe ‘/prt1‘ for parallel 1
‘/prt2‘ for parallel 2
‘/prt9‘ or ‘/ser‘ for serial port
IBM Network Print Server ‘/prt1‘......‘/prt8‘ - 8 logical parts
IBM Network printer (4312, 4317, 4324)
IBM Infoprint Printers (4320, 4322, 4332)
PASS (or TEXT if PASS does not work)
Chapter 12. Problem determination techniques 259
Note: You must use these names for a successful connection. They are
hard-coded into the LPD daemons, unlike OS/400 where an output queue name
may be (almost) anything you want.
12.2 Printer-writer-related problems
This topic relates to print writer problems. Normally, the job log may give you the
necessary information to correct the problem (for example, prompting you to
answer any non-answered messages). You can check the status of the writers
using the WRKWTR command, the status of the spooled files with the WRKSPLF
or WRKOUTQ command, and the status of the output queue with the WRKOUTQ
command. The information provided by these commands is discussed in the
following sections.
12.2.1 Print writer ends
If the printer ends unexpectedly, a job log is sent to the QEZJOBLOG output
queue (or two job logs for an AFP print writer). The reported messages can help
you to find the problem. It may be as minor as someone switching off the printer
(for example, to clear a paper jam). To check that a printer called NP17 is
powered on and varied on, enter:
WRKCFGSTS *DEV NP17
The display shown in Figure 204 appears.
Figure 204. Work with Configuration Status display
If the printer status is VARIED OFF, use option 1 (Vary On). Use the Help key for
an explanation of the different statuses that are possible.
IBM Infoprint 12 'raw'
IBM Infoprint Color 8 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
LPTx_TEXT - Where x = port
UNIX/RISC printer queue name (case sensitive)
Interface used Queue name
Work with Configuration Status SYS00005
11/14/97 15:36:33
Position to . . . . . Starting characters
Type options, press Enter.
1=Vary on 2=Vary off 5=Work with job 8=Work with description
9=Display mode status 13=Work with APPN status...
Opt Description Status -------------Job--------------
NP17 VARIED ON
260 IBM AS/400 Printing V
If you still have a problem, the following reasons are some of the typical causes
of the writer ending:
• Duplicate IP address
After configuring a LAN-attached printer, the PING test may be OK, but when
you try to print, the print writer ends immediately.
In this case, check for a duplicate IP address:
a. Disconnect the printer (at the printer end, for example, remove the LAN
cable).
b. Ping the IP address of the printer:
PING '123.1.2.3'
c. If the PING is successful, you have a duplicate address. Contact your LAN
coordinator.
If the PING is unsuccessful (as it should be), reconnect the printer and
check the writer job log for any messages.
• Message queue full
The printer writer ends immediately after a STRPRTWTR command. No
message or job log is available. This can happen when the message queue
associated with the printer is full. When the message queue is full, even the
normal start writer message cannot be written to the queue. Therefore, the
writer ends.
Use the DSPDEVD command to display the message queue name associated
with the printer, and then use the WRKMSGQ command (change, view, and clear
options available).
• Activation timer - Release timer
If you are sharing a printer with another system, the activation timer and the
release timer can be the reason that the print writer ends. When sharing a
printer, these two parameters must contain the following values:
– ACTTMR: Activation Timer (printer device description).
This parameter should be set to *NOMAX. With this value, you can wait
indefinitely until another system using the printer releases it.
– RLSTMR: Release Timer (PSF configuration object):
This parameter should be set to *SEC15.
Note: If this value is *NOMAX, the first system accessing the printer does not
release it, and any other systems cannot use it.
12.2.2 Spooled files remain in RDY status
Using the WRKWTR command, you can see that the writer is STR (Started), but
the spooled file remains RDY (Ready) on your output queue with no printing.
In this case, check the status of the output queue. Use the WRKOUTQ command,
and check the status in the upper right corner of the Work with Output Queue
display. The status must be RLS/WTR. See Figure 206 on page 263 for an
example of this display.
Chapter 12. Problem determination techniques 261
• If the status is HLD, the queue is held and no writer is started to the queue.
Use the RLSOUTQ command to release the output queue. You can now start
a writer to the queue using the STRPRTWTR command.
• If the status is HLD/WTR, the queue is held and a writer is started to the
queue. Use the RLSOUTQ command to release the output queue.
• If the status is RLS, the queue is released, but no writer is started to the output
queue. Start the writer using the STRPRTWTR command. If you have already
done this, the writer is probably ending immediately. Refer to 12.2.1, “Print
writer ends” on page 259.
• If the status is RLS/WTR, the queue is released and a writer is started to the
queue. Be patient! The status of the spooled file must change from RDY to
WTR if the target printer is configured AFP(*NO), or from RDY to PND to
WTR, and then to PRT if the target printer is configured AFP(*YES). The
spooled file should then be printed.
12.2.3 Spooled file remains in PND status
Using the WRKWTR command, you can see that the writer is in STR (Started)
status, but the spooled file remains in PND (Pending) status in your output queue.
Nothing is printed. In this case, the print driver job (PDJ) cannot establish a
connection with the printer (it is waiting for an answer from the printer).
Therefore, you need to complete these steps:
1. End the writer (see the next section).
2. Power off the printer.
3. Wait approximately 10 seconds (to avoid causing LAN problems).
4. Power on the printer.
5. Start the print writer again.
12.2.4 Ending the writer
To end the writer immediately, enter the following command:
ENDWTR WTR(printer_name) OPTION(*IMMED)
This end of job forces a job log. If you forget the *IMMED option, you can issue
the command again, but this time with the option.
To end the writer abnormally (if the previous command does not work), enter:
CALL QSPENDWA printer-name
This is rarely needed.
From a WRKOUTQ display, you can use option 9 (Work with printing status) to
perform all the previous commands. However, using a guided, step-by-step
process tells you exactly what to do next, instead of wondering whether to use
WRKWTR, WRKSPLF, and so on. Learn to use this option.
Tip
262 IBM AS/400 Printing V
12.2.5 Spooled file status
Figure 205 shows the status for a spooled file from its creation up to its printing
(or transmission to another system (remote system printing)). To check the status
of a spooled file, use the WRKSPLF or the WRKOUTQ command.
Figure 205 also shows the spooled file status when the target printer is
configured AFP(*NO), AFP(*YES) with PSF/400, and if remote system printing is
used.
Figure 205. Spooled file status
Figure 205 shows only some of the main statuses that are possible. A complete
list of all spooled file statuses follows:
OPN Open: The file has not been completely processed and is not ready to
be selected by a writer.
RDY Ready: The file is available to be written to an output device by a
writer.
DFR Deferred: The file has been deferred from printing.
SND Sending: The file is being or has been sent to a remote system.
CLO Closed: The file has been completely processed by a program, but
SCHEDULE(*JOBEND) was specified and the job that produced the
file has not yet finished.
HLD Held: The file has been held.
SAV Saved: The file has been written and then saved. This file will remain
saved until it is released.
PND Pending: The file is in the conversion phase, or pending to be printed.
You can have more than one spooled file in PND status in an output
queue.
RDY
or
DFR
RDY
or
DFR
RDY
or
DFR
PSF
Applications
Print Writer
Data Stream
Conversion
Print Request
Queue
Print Driver
Spool Spool
Print Writer Print Writer
Printer
Printer
AFP(*NO)
Printer
AFP(*YES)
Remote System
Output Queue
Spool
OPN
WTR
OPN
PND
WTR
PRT
OPN
SND
Chapter 12. Problem determination techniques 263
WTR Writer: This file is currently being produced by the writer on an output
device.
PRT Printing: The file has been sent to the printer, but print complete status
has not yet been sent back to the system.
MSGW Message Waiting: This file has a message that needs a reply or an
action to be taken.
The following status values with a * (asterisk) in front of them are displayed when
an action is performed on the file as a result of selecting an option:
*CHG Changed: This file was changed using option 2 (Change).
*HLD Held: This file was held using option 3 (Hold).
*RLS Released: This file was released using option 6 (Release).
12.2.6 Output queue status
The status of the output queue can also tell you whether a writer is started to the
queue. Use the WRKOUTQ command. The display shown in Figure 206 appears.
Figure 206. Work with Output Queue display
In the top right-hand corner, the Status field refers to the status of the output
queue (RLS - Released) and the status of the print writer (WTR - Writing) in this
example.
The following list contains all of the output queue status.
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.
Work with Output Queue
Queue: PRT01 Library: QUSRSYS Status: RLS/WTR
Type options, press Enter.
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 P
TESTOUTQ DBAS RDY 1 1 *STD
MODEL JENNY RDY 1 1 *STD
TESTIN LEGS HLD 1 1 *STD
QSYSPRT DBAS HLD 1 1 *STD
QSYSPRT SANDY HLD 1 1 *STD
QSYSPRT SANDY HLD 346 1 *STD
FAXPRT DEBBIE HLD 1 1 *STD
Parameters for options 1, 2, 3 or command
===>
F3=Exit F11=View 2 F12=Cancel F20=Writers F22=Printers
F24=More keys
264 IBM AS/400 Printing V
12.2.7 AFCCU printers: Minimize delay when stopping and starting
The AFCCU printers include Infoprint 60, Infoprint 62, Infoprint 2000, Infoprint
3000, and Infoprint 4000. They have a configuration option called “Clear Memory
for Security”. This option can have a significant impact on the time required to
start the printer after it has been stopped by PSF and the printer subsystem.
To prevent unnecessary delay when starting and stopping AFCCU printers, set
this option to “NO” unless you have extraordinary security requirements. “YES”
requires the printer to zero out all print data storage when the printer is restarted.
This is not required for normal security because pointers to the data are no longer
active. This has been the standard for IPDS printers and, until AFCCU, has had
little impact on performance. Now, with the large amount of storage in AFCCU
printers, clearing can take several minutes, enough to make a noticeable
difference to customers who start and stop their printers multiple times a day.
Note: “YES” is the default setting for this option on all current AFCCU printers.
There are plans to use “NO” as the setting for future printers.
12.2.8 QSTRUP execution during IPL
This section contains references to the QSTRUP program that runs at IPL time. It
is divided into two sections. The first section changes the message logging of the
job log to increase job log information for diagnostic uses. The second section
has example changes to the program pertaining to the spooling functions on the
system.
12.2.8.1 Tracking the QSTRUP program at IPL
Follow this process:
1. Analyze the problem. In this case, the writer is not starting during the startup
routine at IPL.
2. Make a diagnosis. Check the QSTRUPJD job in the QEZJOBLOG output
queue for messages relating to the device description not varied on or writer
not starting. If the logging is not there or not complete enough, change the job
description for the next IPL. Use the CHGJOBD QSTRUPJD command as
follows:
CHGJOBD JOBD(QSTRUPJD) LOG(4 0 *SECLVL) LOGCLPGM(*YES)
Note: The job identifier in the QEZJOBLOG output queue is:
job number/QPGPMR/QSTRUPJD.
12.2.8.2 Changing the QSTRUP program
Follow this process:
1. On the OS/400 command line, type:
DSPSYSVAL QSTRUPPGM
This displays the name and library of the active startup program for the
AS/400 system. It usually points to QSYS/QSTRUP.
2. On the OS/400 command line, type:
RTVCLSRC PGM(QSYS/QSTRUP) SRCFILE(QGPL/QCLSRC)
This retrieves the CL source of the startup program from step 1.
3. On the OS/400 command line, type:
Chapter 12. Problem determination techniques 265
STRSEU SRCFILE(QGPL/QCLSRC) SRCMBR(QSTRUP)
Edit the CL source that you extracted from the program. Look for
QSYS/STRPRTWTR DEV(*ALL) in the source. This starts all the printers with
the defaults. Insert the specific printer on a line just before the
QSYS/STRPRTWTR command, for example:
QSYS/STRPRTWTR DEV(printer_name) ALIGN(*FILE)
Note: If the STRPRTWTR command is not being used, look for the
QWCSWTRS program. This is an alternative approach to start writers. It
checks to see if a device description is varied on before trying to start the
writer. Review Informational APAR II09679 for details (this APAR can be
downloaded as a PTF cover letter). This is a good solution for writers not
starting at IPL. It loops through the device description 30 times to see if they
are varied on. The STRPRTWTR command checks only once and then passes
by.
4. On the OS/400 command line, type:
CRTCLPGM PGM(QSYS/QSTRUP) SRCMBR(*PGM)
Note: This writes over the system default QSTRUP program. If you do not
want to overwrite it, proceed to the next step.
5. If you do not want to overwrite the default QSTRUP program, on the OS/400
command line, type the following command:
CRTCLPGM PGM(library/QSTRUP) SRCMBR(*PGM)
Note: A good choice for the library is QGPL.
6. Change the system value QSTRUPPGM to refer to the new program. On the
OS/400 command line, type:
CHGSYSVAL QSTRUPPGM VALUE('QSTRUP library')
At the next IPL, the printers should be started correctly.
12.3 Where your print output goes
The elements that control printing have a defined hierarchy. Figure 207 on page
266 shows that hierarchy. In the diagram, you can see that the system looks at
the elements in this order: printer file, job description, user profile, workstation
description, and system value. The system looks first for the output queue and
print device in the printer file.
It is important to know and remember the following conditions:
• If the spooled parameter is set to *YES in the printer file, the output must go to
an output queue. In this case, the first output queue name specified
(according to the hierarchy) is used.
• If the spooled parameter is set to *NO in the printer file, the output must go to
a device. In this case, the first device specified (according to the hierarchy) is
used.
266 IBM AS/400 Printing V
Figure 207. Hierarchy of the elements controlling printing
In the example shown in Figure 208, we assume that the SPOOL parameter is set
to *YES. This means the system will search for an output queue. The first one
found according to the hierarchy of the printing elements is PRT04 in the job
description. PRT04 is used as the output queue by the application.
Figure 208. Example of where your print output goes
12.4 Spooled file goes to hold status
If the spooled file is in a hold condition, a message is generated in the QSYSOPR
job log. To see the reported message, type:
DSPMSG QSYSOPR
Printer File
Spool the Data: *Yes or *NO
Output Queue: *JOB
Job Description
Output Queue: *USRPRF
User Profile
Output Queue: *WRKSTN
Workstation Description
Output Queue: *DEV
Job Description
Printer Device: *USRPRF
User Profile
Printer Device: *WRKSTN
Workstation Description
Printer Device: *SYSVAL
Print File
Printer Device: *JOB
QPRTDEV System Value
Printer Device: PRT01 PRT01
Output Queue
System Value
Printer File Job Description User Profile
OUTQ(*JOB)
DEV(PRT06)
OUTQ(PRT04)
DEV(*USRPRF)
OUTQ(PRT03)
DEV(*WRKSTN)
OUTQ(JENNIFER)
DEV(PRT07)
QPRTDEV(PRT01)
WS Description
PRT04
Chapter 12. Problem determination techniques 267
Then locate the message and perform the appropriate action. Many factors can
cause the spooled file to be held (for example, directing a spooled file to a printer
not supporting the data stream, a negative acknowledgment reported by an IPDS
printer, or AFP resources not found). The printer writer is trying to help you by not
allowing you to print invalid or missing data!
In the QSYSOPR message queue, you see message CPF3395 (Figure 209),
indicating that the spooled file was held.
Figure 209. Message CPF3395
Another message just before CPF3395 gives the cause of the error. Some
examples are illustrated in the following sections.
12.4.1 Writer cannot re-direct the spooled file
If you submit a spooled file to a printer not supporting the data stream of the
spooled file, processing stops, and the writer holds the spooled file. Figure 210
shows message CPI3379 returned when trying to print an AFPDS spooled file to
a printer configured as *IPDS, AFP(*NO).
Figure 210. Message CPI3379
Regarding the previous recovery information, note that to change the device
description, you must first vary off the device. Therefore, the sequence is: end
writer, vary off device, change device description, vary on, and finally start writer.
In the QSYSOPR message queue, this message is followed by message
CPF3395 (spooled file held by writer). Depending on the spooled file data stream
and the target printer, the error message returned can be CPI3370, CPI3372,
CPI3373, CPI3376, or CPI3377.
Message ID . . . . . . : CPF3395 Severity . . . . . . . : 60
Message type . . . . . : Information
Date sent . . . . . . : 11/16/97 Time sent . . . . . . : 10:08:40
Message . . . . : File QSYSPRT held by writer PRT02 on output queue PRT02 in
QUSRSYS.
Cause . . . . . : Writer PRT02 held file QSYSPRT number 2 job
026403/ITSCID17/QPADEV0010 on output queue PRT02 in QUSRSYS. The next file
was processed.
Message ID . . . . . . : CPI3379 Severity . . . . . . . : 30
Message type . . . . . : Information
Date sent . . . . . . : 11/16/97 Time sent . . . . . . : 10:08:40
Message . . . . : Writer PRT02 cannot re-direct file QSYSPRT to device
PRT02.
Cause . . . . . : Writer PRT02 could not re-direct file QSYSPRT number 2 job
026403/ITSCID17/QPADEV0010 to device PRT02. Advanced function printing data
stream (AFPDS) data cannot be converted to the format required to produce
the file on that device.
Recovery . . . : File QSYSPRT can only be produced on a printer supported
by advanced function printing (AFP). If device PRT02 can be started with the
AFP specified as *YES, stop the writer, change the device description for
the printer (CHGDEVPRT command) by specifying the AFP parameter as *YES, and
start the writer again.
268 IBM AS/400 Printing V
12.4.2 Message PQT3630
Message PQT3630 is returned when an error occurs during the processing of an
IPDS spooled file directed to a printer configured as *IPDS, AFP(*YES). The
QSYSOPR message queue shows the sequence of messages presented in
Figure 211.
Figure 211. QSYSOPR message queue
The message CPF3395 “File QSYSPRT held by writer NP17 on output queue
NP17 in QUSRSYS” gives information on the writer action. To see the cause of
the error, the message PQT3630 “Device NP17 returned negative
acknowledgment with sense data” must be analyzed.
Press F1 to display the additional message information shown in Figure 212.
Figure 212. Message PQT3630
The sense data is the negative acknowledgement (NACK) returned by the printer
to the writer (in this case, PSF/400). Six classes of data stream exceptions are
returned by the printer. They are:
• Command reject
• Intervention required
• Equipment check
• Data check
• Specification check:
– IO images
– Barcodes
– Graphics
– General
• Conditions requiring host notification
In this example, the NACK returned is “08C1”, the first two bytes of the sense
data. Refer to IBM Intelligent Printer Data Stream Reference, S544-3417, or to
the IPDS manual of the printer for an explanation of the exception ID.
Device NP17 returned negative acknowledgment with sense data.
Data Check at printer NP17.
Printing of file QSYSPRT by writer NP17 not complete.
File QSYSPRT held by writer NP17 on output queue NP17 in QUSRSYS.
Message ID . . . . . . : PQT3630 Severity . . . . . . . : 10
Message type . . . . . : Information
Date sent . . . . . . : 11/16/97 Time sent . . . . . . : 10:33:14
Message . . . . : Device NP17 returned negative acknowledgment with sense
data.
Cause . . . . . : Sense data X'08C10100 DE010001 00000000 D62D0101 01010000
00000001' was received from device NP17.
Recovery . . . : See messages that follow for additional information about
the error condition. The data stream manual for your printer contains more
information about the sense data.
Technical description . . . . . . . . : The internal message identifier (ID)
is CNACK101.
Chapter 12. Problem determination techniques 269
Table 23 shows an example of the exception ID from an IPDS reference manual.
Table 23. Data check exceptions
According to Table 23, exception “08C1” is a position check. This means you are
trying to print outside the physical page. The cause is that the page size defined
in the printer file is larger than the physical page size (paper), and the FIDELITY
parameter is set to *ABSOLUTE in the printer file. This is discussed in the next
section.
12.4.3 Fidelity parameter
The fidelity parameter in the printer file specifies whether printing continues when
print errors are found for printers configured with AFP(*YES). Two values are
possible for this parameter:
*CONTENT Printing continues when errors are found.
*ABSOLUTE Printing stops when errors are found.
If the fidelity is set to *ABSOLUTE and any AFP resources, such as fonts,
overlays, or page segments referenced in the spooled file are not available, the
spooled file is held by the writer.
The QSYSOPR message queue shows the sequence of messages presented in
Figure 213.
Figure 213. QSYOPR message queue: Resource object not found
For the message PQT0012 “The resource object PS1 was not found for user
USER01”, press F1 to display the additional message information. The possible
causes for this problem include:
• AFP resources are not in the system.
• The library containing the resources is not in the library list.
• Fonts are not available or are not available in the printer resolution.
12.5 Copying spooled files
You can use the Copy Spooled File (CPYSPLF) command to copy a spooled file
to a physical file. But, if the spooled file is *USERASCII, *AFPDS, *LINE, or
*AFPDSLINE (determined by the DEVTYPE parameter on the printer file), you
cannot copy the spooled file. If the spooled file is *IPDS, you can copy it, but the
data stream cannot contain any special device requirements such as fonts,
barcodes, or rotated text.
Exception ID Description Action code
X’0821.00’ Undefined character 01
X’0860.00’ Numeric representation precision check 01
X’08C1.00’ Position check 01
.......................................................
The resource object PS1 was not found for user USER01.
Spooled file QSYSPRT did not print.
File QSYSPRT held by writer NP17 on output queue NP17 in QUSRSYS.
................................................................
270 IBM AS/400 Printing V
One other possibility is to use the Get Spooled File (QSPGETSP) API to get the
data from an existing spooled file. Data is retrieved from the existing spooled file
by a buffer (one or more) and is stored in a user space. For detailed information
on the QSPGETSP API and other spooled file APIs, see AS/400 System API
Reference, SC41-5801.
The third possibility is to use the QSPGETF system program. To place the copied
spooled file back into an output queue, you can use the QSPPUTF system
program. Authority to these system programs is *PUBLIC *EXCLUDE.
• System program QSPGETF has the following five parameters. All character
parameters must be entered in uppercase and be enclosed in quotation
marks. The database file and member are created if they do not exist prior to
the call.
1- 10 Character spooled file name.
2- 20 Character qualified database file name in which to dump the
spooled file. The first 10 characters contain the database file name.
The second 10 characters contain the database file library name.
3- 26 Character qualified job name of the job that created the spooled
file. The first 10 characters contain the job name. The second 10
characters contain the job user. The last six characters contain the
job number.
4- Numeric spooled file number 1 through 9999. If using the call
interface, specify the spooled file number as a hex value as:
X'0001' to X'270F' for spooled file numbers of 1 through 9999.
5- 10 Character database file member name in which to dump the
spooled file.
The following example dumped spooled file, QPRINT, to database file,
SPOOLDB, and member, MBR1. The spooled file number was 1. You can
enter the information on the command line or prompt on the call command to
enter the parameters.
CALL PGM(QSYS/QSPGETF) PARM('QPRINT ' 'SPOOLDB USER1LIB '
'DSP03 USER1 010160' X'0001' 'MBR1 ')
• System program QSPPUTF has the following three parameters. All character
parameters must be entered in uppercase and be enclosed in quotation
marks.
1- 20 Character qualified database file name from which to re-spool the
spooled file. The first 10 characters contain the database file name.
The second 10 characters contain the database file library name.
2- 20 Character qualified output queue name to which to re-spool the
spooled file. The first 10 characters contain the output queue
name. The second 10 characters contain the output queue library
name.
3- 10 Character database file member name to which to re-spool the
spooled file.
The following example re-spooled a previously dumped spooled file from
database file SPOOLDB and member MBR1 to output queue USER1. You can
enter the information on the command line or prompt on the call command to
enter the parameters.
Chapter 12. Problem determination techniques 271
CALL PGM(QSYS/QSPPUTF) PARM('SPOOLDB USER1LIB '
'USER1 QGPL ' 'MBR1 ')
12.6 Problem with output presentation
Many presentation problems are related to the position of the data on the page,
the printer's unprintable border, or to the page rotation parameter in the printer
file.
12.6.1 Physical page: Logical page
The physical page is the format of the paper loaded in the printer. The logical
page size is from the printer file page size parameter.
12.6.1.1 Physical page size same as logical page size
In the example shown in Figure 214, the physical page size is the same as the
logical page size.
• With a rotation of 0 degrees, all the physical, logical, overlay, and data origins
are at the top left corner of the paper.
• With a rotation of 90 degrees, the logical page and the overlay are positioned
from the physical page origin at the bottom left corner of the paper. Data
positioning is from the top left corner of the logical page.
Figure 214. Physical page same as logical page
Note: We recommend that you set the physical page size equal to the logical
page size to avoid data position problems.
12.6.1.2 Logical page smaller than physical page
In the example shown in Figure 215 on page 272, the logical page size is smaller
than the physical page size.
Physical Origin
Logical Origin
Data Origin
Overlay Origin
Physical Origin
Logical Origin
Overlay Origin
Data Origin
Rotation 0 Degrees Rotation 90 Degrees
272 IBM AS/400 Printing V
Figure 215. Logical page smaller than physical page
With a rotation of 0 degrees, all the physical, logical, overlay, and data origins are
at the top left corner of the paper. The data is properly positioned.
With a rotation of 90 degrees, the logical page and the overlay are positioned
from the physical page origin at the bottom left corner of the paper. Data
positioning is from the top left corner of the logical page. You will encounter a
data position problem.
12.6.1.3 Logical page larger than physical page
In the example shown in Figure 216, the logical page size is larger than the
physical page size.
Figure 216. Logical page larger than physical page
With a rotation of 0 degrees, all the physical, logical, overlay, and data origin are
on the top left corner of the paper. The data is properly positioned.
Physical Page Logical Page
Physical Origin
Logical Origin
Data Origin
Overlay Origin
Physical Origin
Logical Origin
Overlay Origin
Data Origin Rotation 0
Degrees
Rotation 90 Degrees
Physical Page Logical Page
Physical Origin
Logical Origin
Data Origin
Overlay Origin
Physical Origin
Logical Origin
Overlay Origin
Data Origin
Rotation 0
Degrees
Rotation 90 Degrees
Chapter 12. Problem determination techniques 273
With a rotation of 90 degrees, the logical page and the overlay are positioned
from the physical page origin on bottom left corner of the paper. Data positioning
is from the top left corner of the logical page. You will encounter a data position
problem, as the top lines of the print output are outside the physical page. You
may lose part of your print output.
12.6.2 Printer setup
Some printers have an unprintable border and the logical page is positioned at
the edge of the printable area instead of the edge of the physical page (Figure
217).
Figure 217. Unprintable border
Printer setup parameters, such as Page=Print, Edge-to-Edge, VPA Check, and
the QPRTVALS data area, allow you to move the origin from the edge of the
printable area to the edge of the physical page, or to control its effect.
Note: If you have printers without an unprintable border and printers with an
unprintable border, having the origin at the same place ensures the same
presentation on both types of printer.
For detailed information, see Chapter 10, “IBM AS/400 network printers” on page
205, AS/400 Printing III, GG24-4028, and AS/400 Printing IV, GG24-4389, for
various models of printers.
12.6.3 Computer Output Reduction
If you specify a page rotation of *AUTO or *COR in the printer file, and your data
cannot fit on the page because your logical page is larger than the physical page,
the Computer Output Reduction (COR) function is used (Figure 218 on page
274). *COR always uses CORing, regardless of page size (unlike *AUTO).
Origin Printable Area
Logical Origin
Data Origin
Overlay Origin
Physical Origin
Physical Origin
Logical Origin
Data Origin
Overlay Origin
Unprintable Border
274 IBM AS/400 Printing V
Figure 218. Computer Output Reduction
The COR function rotates your page 90 degrees and prints your data with a
smaller font. For example, a 15 cpi or 17.1 cpi is used.
Note: To avoid non-desired COR, selected a rotation value of 0, 90, 180, or 270
degrees in the printer file.
12.6.4 A3 page support
Before A3 paper became a commonly-supported page size, PSF/400 was limited
to a maximum page size of 11.3 inches for the short side and 14 inches for the
long side of the logical page. The effect of this was that output was truncated with
a printer file specifying a page size of over 140 characters at 10 cpi, 168
characters at 12 cpi, 210 characters at 15 cpi, and so on.
A PTF is now available to allow larger page sizes for printers that support A3
paper size. It is only effective for printers configured as *IPDS, AFP=*YES.
Note: *IPDS, AFP=NO printers do not have this problem because they take the
logical page size from the printer file in this case.
The APAR number for Version 3.0 Release 7.0 and V4R1 is SA64384. PTF
numbers are SF44581 and SF44098, respectively. At the time this redbook was
written, support had not been added for earlier releases of OS/400.
12.7 Font problems
Many messages are related to fonts, and most simply report that a font
substitution was performed (for example, the message PQT2072). See Figure
219.
Computer Output
Reduction
Rotation
*AUTO or *COR
Computer Output Reduction
COR
Chapter 12. Problem determination techniques 275
Figure 219. Font substitution message PQT2072
You can also receive other font substitution messages, such as:
PQT2066 Font substitution was performed. Your print request referred to a
resident font, and resident fonts are not supported by this printer.
PQT3531 Font substitution was performed. Your print request referred to a
character set, and this printer only supports resident fonts.
PQT3533 Font substitution was performed. Your print request referred to a
character set with an incompatible resolution to the printer.
PQT3535 Font substitution was performed. Your print request referred to a
character set and code page. The code page could not be found.
PQT3537 Font substitution was performed. Your print request referred to a
character set and code page. You are not authorized to use the
character set.
PQT3539 Font substitution was performed. Your print request referred a
character set and code page. You are not authorized to use the
code page.
PQT3541 Font substitution was performed. Your print request referred to a
raster character set, and you requested that outline fonts be used
when possible.
PQT3542 Font substitution was performed. Your print request referred to a
character set and code page. The device does not support outline
fonts.
PQT3543 Font substitution was performed. Your print request referred to
character set at one resolution, and a character set with this
resolution cannot be found.
PQT3544 Font substitution was performed. Your print request referred to an
outline font, but outline fonts are not supported by the printer.
On each message, there is useful information about the font resources with the
problem.
Note: In Version 4.0 Release 2.0 and later, a parameter in the PSF configuration
object allows you to suppress logging the font substitution messages.
Message ID . . . . . . . . . : PQT2072
Message file . . . . . . . . : QPQMSGF
Library . . . . . . . . . : QSYS
Message . . . . : Font substitution was performed.
Cause . . . . . : Your print request for file &1 number &2 in job &5/&4/&3
referred to resident character set (FGID) 10 and resident code page 0037.
These resident resources are not present in printer PRT01. A font
substitution was performed that keeps as many characteristics as
possible of the originally requested font. Resident character set (FGID)
11 and resident code page 0037 were substituted. A value of *DFLT for
the substituted character set (FGID) or code page means that the printer
default was used. If you specified absolute fidelity, processing of the print
request ended. If you specified content fidelity, the substitution was
performed, and processing of the print request continued.
276 IBM AS/400 Printing V
For more information on fonts, font tables customization, outline fonts, and font
substitutions, see Chapter 4, “Fonts” on page 89.
12.7.1 Problems with shading at different resolutions
If you create an overlay with AFP Utilities/400, AFP Driver, or other tools, you
have the option to shade inside a box. The shaded element that is created is
often a raster pattern that depends on the pel density of the printer to which it is
going. If the density does not match, you may notice some or all of these
symptoms:
• You receive message PQT3513 that states “The resolution of an image does
not match the resolution of the printer”. If the printer file is set to *Absolute
fidelity, the file is held. If the fidelity is set to *Content, the page will print, but
the shading may be distorted.
• The distortion is most apparent if you have shading that was generated for a
300-pel printer but is printed on a 240-pel printer. There is a noticeable
“waffle” pattern in the output. If you have shading that was generated for a
240-pel printer printing at 300-pel, the texture might change somewhat, but it
is not as bad.
• There may be performance degradation. If you are on V3R1, check for PTF
SF44977. This fix was included in all other current releases.
Possible solutions are:
• With V3R7 or later, you can use the PSF configuration object to specify the
Device Resource Library List. That way you can create two versions of the
overlay, one for each density, and have them in different libraries. Then you
list the appropriate library in each printer's DEVRSCLIBL parameter.
• If you are on an earlier release and need to print on printers at different
densities, we recommend that you create the resource at 240-pel to print on
the 300-pel printers. This avoids the waffle effect.
12.8 Drawer and paper path selection problems
To use the drawer selection for a printer, the FORMFEED parameter must be set
to *AUTOCUT. If this is not done, the DRAWER parameter is ignored (because,
for example, PSF/400 believes it is using a printer with continuous forms). The
FORMFEED parameter is in the printer file and also in the printer device
description (the parameter in the printer file may default to *DEVD).
Note: The Facsimile Support/400 product uses the drawer number to specify the
format of the facsimile (for example, drawer 1=letter, and drawer 3=A4). In this
case, the FORMFEED parameter must also be set to *AUTOCUT.
12.8.1 IBM 4247 paper path selection
The IBM 4247 printer can be configured in 4230/4224 emulation or in native
mode. The paper path selection varies from one mode to the other.
12.8.1.1 4230/4214 emulation mode
For 4230/4214 emulation, only one attachment may be on the printer at a time.
Chapter 12. Problem determination techniques 277
If you want to use the automatic sheet feeder, it is best that you run in 4230/4214
emulation mode. For automatic sheet feeder, specify FORMFEED(*AUTOCUT),
DRAWER(n) on the printer file, where n is:
1 Drawer 1
2 Drawer 2
3 Drawer 3
For 4230/4214 continuous forms, specify FORMFEED(*CONT) on the printer
file.
12.8.1.2 4247 native mode
For 4247 mode, multiple attachments may be on the printer at the same time.
However, in this mode, the drawer selection number for the automatic sheet
feeder has changed. Specify FORMFEED(*AUTOCUT), DRAWER(n) on the printer file,
where n is:
5 Drawer 1
6 Drawer 2
7 Drawer 3
For 4247 front continuous forms attachment, specify FORMFEED(*CONT) in the printer
file.
For 4247 rear continuous forms attachment (Version 3.0 Release 1.0 and Version
3.0 Release 6.0), specify FORMFEED(*AUTOCUT) DRAWER(2) in the printer file.
For 4247 rear continuous forms attachment (Version 3.0 Release 2.0 and Version
3.0 Release 7.0 and later), specify FORMFEED(*CONT2) or FORMFEED(*AUTOCUT)
DRAWER(2) in the printer file.
12.9 Printing on ASCII printers
The following considerations are for printing AS/400 spooled files to ASCII
printers:
• Use the host print transform function in place of an emulator (PC or display).
There are more printer functions, such as the AFPDS to ASCII transform, and
the transform table can be customized. For detailed information on host print
transform, see 1.3.3, “Host print transform” on page 13.
• In the host print transform table, select the emulation or driver according to
your printer type and model.
• Check the printer setup (code page, paper format, timeout, and so on).
• Check that your printer file parameters reflect your ASCII printer capabilities
(for example, page size (A3 supported?), duplexing (supported?), and
available fonts).
• Refer to the ASCII printer technical manual for available fonts, size of the
unprintable border, maximum lines per page, maximum characters per line,
and so on.
278 IBM AS/400 Printing V
12.10 Additional information
Because program temporary fixes (PTFs) might be superseded rapidly, check the
PTF numbers provided in this document for their accuracy. The World Wide Web
provides lists with recent PTF numbers and microcode levels for IBM printers.
These lists can be found at: http://www.printers.ibm.com/products.html
Subsequent ones are, for example:
• Hints and tips:
Contains technical items or “flashes”.
• Service planning:
Contains the minimum and current microcode level of the IBM Network
Printers.
• Service notes:
Gives a list with recommended OS/400 PTFs for printers configured with AFP
functions.
Alternatively, your IBM representative should be able to provide a list of required
PTFs.
© Copyright IBM Corp. 2000 279
Appendix A. PSF/400 performance factors
This appendix considers factors relating to printing performance on the AS/400
system, in approximate order of importance, starting with the most significant to
the least significant. Which factors have the most affect on your system printing
depends on your particular system and printer configuration, as well as the type
of spooled files you are printing.
A.1 AS/400 system storage
The amount of system storage (memory) allocated to the *SPOOL pool is crucial
for successful AFP printing. The minimum for AFP printing should be 2000 KB to
3000 KB (that is, 2 MB to 3 MB). For AFP printers operating simultaneously,
consider allocating 500 KB to 1000 KB more for each additional printer. If you are
using LPR/LPD printing (for example, with a remote output queue), start with at
least 6 MB in *SPOOL.
You can check the storage allocated on the Work with System Status
(WRKSYSSTS) display. To identify the *SPOOL pool, press F11 twice to produce
the Work with System Status display shown in Figure 220 on page 280.
In this example, the setting of the QPFRADJ (Performance Adjustment) system
value has automatically allocated storage across the storage pools. The system
value controls whether automatic balancing of memory is done and when it is
done (at IPL, during normal operations, or both).
If you do not use automatic adjustment, you can monitor the *SPOOL pool for
excessive page faulting, and even change the pool size “in flight”, although you
are only taking it from another pool that may have a greater requirement (for
example, a batch or interactive job).
Be aware that the automatic adjustment may be too slow in responding to use the
printing subsystem, especially for smaller jobs. On systems running Version 4.0
Release 1.0 or later, you can use the Work with Shared Pools (WRKSHRPOOL)
command to assign minimum and maximum percentage values for *SPOOL (use
the F11 key marked (Display tuning data)). If auto-tuning is set on through
QPFRADJ, these limits may be adjusted automatically. The default minimum
percentage is 1% of the total main storage. In the example shown in Figure 221
on page 281, the total system storage is 4718592 KB, and the minimum
percentage size for *SPOOL has been set at 10%.
280 IBM AS/400 Printing V
Figure 220. Work with System Status: Displaying pool names
A.2 Data stream type
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 the 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
print 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 following
steps:
1. An SCS spooled file sent to an IPDS printer is:
a. Converted to generic IPDS.
b. Converted to AFPDS.
c. Converted into printer-specific IPDS.
The converted spooled file is then sent to the printer.
2. An IPDS spooled file is:
a. Converted to AFPDS.
b. Converted into printer-specific IPDS.
The converted spooled file is then sent to the printer.
3. An AFPDS spooled file is converted directly into printer-specific IPDS format.
The converted spooled file is then sent to the printer.
Work with System Status LUCYHH05
12/01/97 16:25:34
% CPU used . . . . . . . : 2.8 Auxiliary storage:
Elapsed time . . . . . . : 00:00:01 System ASP . . . . . . : 67.71 G
Jobs in system . . . . . : 19243 % system ASP used . . : 35.1832
% addresses used: Total . . . . . . . . : 67.71 G
Permanent . . . . . . : .007 Current unprotect used : 467 M
Temporary . . . . . . : .010 Maximum unprotect . . : 487 M
Type changes (if allowed), press Enter.
System Pool Reserved Max
Pool Size (K) Size (K) Active Pool Subsystem Library
1 415780 244856 +++++ *MACHINE
2 3545416 0 204 *BASE
3 47184 0 4 *SPOOL
4 710212 0 87 *INTERACT
Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Restart
F11=Display paging option F12=Cancel F24=More keys
This is explained in 1.3, “Printer writer” on page 6.
Note
Appendix A. PSF/400 performance factors 281
The conversion for SCS and IPDS are there to ensure complete fidelity of the
result. For example, this ensures that if a front overlay was specified in the printer
file of an SCS spooled file, the overlay comes across in the conversion.
Obviously, there is time and system processor cycles involved in the SCS and
IPDS conversions. With Version 3.0, a new customizing option (called IPDS Pass
Through) enables control over SCS and IPDS conversions to reduce the
conversion time. See A.2.1, “IPDS pass through” on page 282, for more
information.
These conversions are illustrated in Figure 221. Notice how the size of the
shaded box decreases depending on the data stream type specified. This
represents the reduced work the AS/400 processor has to perform.
Figure 221. Data stream transforms when printing to an IPDS AFP(*YES) printer
Generally speaking, if your output is to contain AFP resources, such as overlays,
page segments, and host font character sets, specify *AFPDS in the printer file. You
frequently need to do this, in any case, to obtain support for certain DDS
keywords.
If you are printing to a printer configured as *IPDS, AFP=NO, code the data
stream type as *IPDS (for example, an IPDS impact printer). This data stream
has several restrictions (these restrictions are discussed in 1.3, “Printer writer” on
page 6).
Datastream type
SCS IPDS AFPDS
Print Writer Print Writer Print Writer
Data Stream
Converter
SCS
IPDS
AFPDS
IPDS
Data Stream
Converter
IPDS
AFPDS
IPDS
Data Stream
Converter
AFPDS
IPDS
Print Driver Print Driver Print Driver
IPDS Printer
AFP(*YES)
IPDS Printer
AFP(*YES)
IPDS Printer
AFP(*YES)
282 IBM AS/400 Printing V
Leave the data stream type as *SCS if your output is straightforward (reports,
listings, for example) and can be printed on any of the printers in your
organization.
A.2.1 IPDS pass through
This parameter is available on the WRKAFP2 (V3R1/V3R6) and WRKPSFCFG
(V3R2/V3R7 and later) commands described in Chapter 11, “Configuring
LAN-attached printers” on page 223. It cuts down on some of the internal
transforms described previously (for example, an SCS spooled file is converted
directly to printer-specific IPDS, and an IPDS spooled file does not require any
conversion).
There are some restrictions as to its use such as spooled files with overlays,
image data, or software multi-up. However, in these cases, the normal transforms
will occur. Therefore, for a printer configured as *IPDS, AFP=*YES, set the
IPDSPASTHR parameter to *YES.
A.2.2 Printer device description parameters
These settings are related to the data stream conversion carried out by the
AS/400 processor. They obviously apply only to individual printers.
• Print while converting: This should be set to *YES so that pages in a large
spooled file may start to print before the entire process of conversion has
completed. You may also want to adjust the priority of the writer job, for
example, by using:
WRKACTJOB SBS(QSPL)
Then, change the job priority for the WTR job for your printer in the range 0
(highest priority) through to 9 (lowest priority). This allows you some control
over the conversion process.
• Maximum pending requests: This refers to the number of spooled files that
may be converted by the AS/400 processor for each printer at any one time.
The default value is 6. If you are regularly printing many small (one page to
five page) spooled files to a fast printer (20 ipm to 30 ipm), you may want to
increase this value. If you are printing larger spooled files (300 pages and
more), you may want to decrease this value slightly. The main effect is on disk
usage.
A.3 AFP resource retention
Since Version 3.0 Release 1.0, PSF/400 automatically stores downloaded AFP
resources in an IPDS printer across job boundaries subject to memory
constraints. This is on the likely chance that the succeeding job can also
reference one or more of the previous job's AFP resources. This cuts down on
resource download time and, therefore, the overall throughput of the job. Note
that this is possible because the AFP print job contains only references to the
AFP resources. These may or may not actually be present in the data stream.
Resource retention may be switched off if required, using the RSCRET parameter
in the WRKPSFCFG command or the DRR parameter in the WRKAFP2
command. The default in each case is for resource retention to be enabled.
Appendix A. PSF/400 performance factors 283
A.3.1 Clear memory for security
Some AFP printers, including the AFCCU printers, have a similar hardware
feature called “Clear Memory for Security”. This flushes the printer memory
between each print job and, therefore, should be set to *NO. IBM AFCCU printers
are shipped with this feature enabled, so it is worth checking the printer operator
panels to ensure it is disabled.
A.4 Font types
Typically, when a font is downloaded to a printer, it is a raster (bitmapped) image
containing the entire character set. Outline (scalable) fonts contain only the
vector instructions for drawing the selected characters. Therefore, using outline
fonts reduces the download time considerably. This is more noticeable when
printing large characters because the printer's control unit scales the outline font
to the requested point size. Techniques for working with font performance are
described in the following sections:
• Section 4.5.1, “Downloading host-resident outline fonts” on page 100
• Section 4.5.2, “Why use an outline font” on page 100
• Section 4.10, “Font capturing” on page 108
• Section 5.5, “Text versus image” on page 129
At the present time, downloading outline fonts is only possible with IBM AFCCU
printers.
A.4.1 Using GDDM fonts
Strictly speaking, these are not fonts, but graphical symbol sets (object type
*GSS) found in the QGDDM library shipped with the OS/400 operating system.
They are used in a similar manner, for example, using the FONT keyword and
specifying a graphical symbol set such as ADMWMOB (Multi-National Open
Block). The results are smooth, rounded characters scaled to the size specified
with the CHRSIZ keyword. They are referenced by the name of the graphical
symbol set (for example, in Figure 222).
Figure 222. DDS record format specifying a GDDM font
The penalty is that they take longer to produce and print than raster or
printer-resident scalable fonts. This is particularly noticeable on IPDS impact
printers where text appearance is lower in priority in any case. Shipping
documentation is a typical example. Fast printer throughput is usually the aim as
long as the enlarged output is readable.
There is significantly faster performance if you use an outline font and then scale
it to the required size using a point size (for example, using Helvetica Bold). See
Figure 223 on page 284.
0030 A R TXT1
0031 A LIN01 1A
0032 A FONT(ADMWMOB)
0033 A CHRSIZ(2.0 3.0)
284 IBM AS/400 Printing V
Figure 223. DDS record format using a printer-resident outline font
On a printer that does not have outline fonts (such as an IPDS impact printer),
specify a resident font, but use the CHRSIZ keyword to scale it. The quality of the
character shape is not as good. The appearance is “blocky”, but printing is faster
than if using a GDDM font. CHRSIZ is not supported on the AFCCU printers, but
these have outline fonts in any case.
A.5 Library list searches
You can help PSF/400 locate AFP resources quickly by placing AFP resources in
user library lists (USRRSCLIBL) and device resource library lists (DEVRSCLIBL).
The two parameters refer to those in the PSF configuration objects associated
with printer device descriptions.
An example of an AFP resource placed in a user resource library might be a
user's signature stored as a page segment called USERSIG. Therefore, the
printer file can reference the page segment by this name. Which signature is
printed depends on the user submitting the job. An example of using the device
resource library might be to store different versions of the same overlay by device
resolution (240 or 300 dpi). Which overlay is used depends on the printer to
which the job is sent.
Generally speaking, the higher in the library list an AFP resource appears, the
better. In addition, explicitly specify a resource where possible (for example,
MYLIB/INVOICE to specify an AFP overlay), rather than *LIBL/INVOICE.
A.6 Creating efficient AFP resources
Some tools are more efficient than others at producing AFP resources. As an
unscientific rule of thumb, the easier and more user-friendly the tool is, the
less-efficient the resource is! AFP Utilities/400 is native to the AS/400 system,
offers a near-WYSIWYG approach to designing overlays, and produces relatively
efficient AFP resources in terms of file size and speed of printing. The AFP driver
allows you to produce overlays using sophisticated PC functions, but if the driver
is set up to produce a resource entirely composed of image data, the download
and print speed is noticeably reduced. The answer is to create such an overlay
using text components wherever possible (see 5.5, “Text versus image” on page
129).
General principles for such tools are that rounded elements, such as curves and
rounded boxes, take longer to produce than square elements, and dotted or
dashed lines take longer to print than solid lines. The reason for this is that
straight lines may often be produced using text IPDS commands, instead of
image commands.
Excessive use of shading may also slow downloading and printing an AFP
resource. Obviously, the design should take precedence, and simple experiments
0030 A R TXT1
0031 A LIN01 1A
0032 A FONT(2305 (*POINTSIZE 30))
Appendix A. PSF/400 performance factors 285
may show that the shading or particular design is not having any noticeable effect
on performance.
A.7 Other factors
These may or may not be of significance, depending on your particular printing
configuration.
A.7.1 PSF configuration object parameters
These parameters apply to any printer that references the PSFCFG object in its
device description.
The ACKFRQ (Acknowledgement Frequency) parameter in the PSFCFG object is
new with Version 4.0 Release 2.0. It specifies the frequency, in pages, with which
PSF/400 sends IPDS acknowledgement requests to the printer. In return, the
printer responds with information about the status of the print job (how many
pages have been printed, for example).
The parameter can be used with the AUTOSSNRCY (Automatic Session
Recovery) parameter, also new with Version 4.0 Release 2.0. If a problem causes
a print session to be disconnected and then re-established, PSF/400 may send
duplicate pages to be reprinted because it did not have the current status of the
printer. By increasing the ACKFRQ parameter, you can reduce the number of
reprinted pages. However, too many acknowledgements slow down the
communication between PSF/400 and the printer.
This parameter should relate to the speed of the printer. If we imagine a printer
rated at 100 ipm (impressions per minute), the default ACKFRQ setting of 100
pages will cause an acknowledgement to be transmitted every minute. You can,
therefore, increase this parameter for faster printers and reduce it for slow
desktop printers. If the number of pages in the job is less than the ACKFRQ
value, an acknowledgement is sent at the end of the job in any case. But be
aware of the increased likelihood of duplicate pages should the session to a
printer with a high acknowledgement interval end abnormally.
A.7.2 Printer file parameters
These parameters require a change to the printer file used by your application.
Unless you have special requirements, set the Spooled Output Schedule printer
file parameter to *IMMED rather than *FILEEND so spooled file processing may
begin without waiting for the producing job to complete (it may be closing files or
performing other non-printing tasks).
A.7.3 Printer settings
These changes are made at the printer operator panel.
• MTU Sizes: Many printers have an optimum Maximum Transmission Unit
(MTU) size. The MTU is the maximum allowable length of data packets in
bytes. This is usually documented in the setup guide for the printer. For
example, the recommended size for an AFCCU printer using TCP/IP is 4096.
This value should match the MTU size of other devices on the LAN. For an
SNA-attached printer, the printer MTU should not exceed the value specified
286 IBM AS/400 Printing V
in Maximum Frame Size in the APPC Controller description. In turn, this value
should be equal to or less than the equivalent value in the Token-Ring line
description. A common value for the SNA Token-Ring is 4060.
• Printer Memory: Printers with particular requirements include those that
support multiple data streams. Memory may be used to swap out resources
and print commands while those of another data stream are loaded.
For IPDS printing on the IBM Network Printer range, best performance with
current microcode levels is seen with 16 MB to 20 MB memory, depending on
the complexity of the output. PCL memory requirements for these printers,
whether it be from the AS/400 system or a PC client, depends on additional
factors such as the page size used and duplexing. These requirements are
documented in the User's Guide for each model. For the IBM 3130, we
recommend that you use at least 16 MB of extra memory for each additional
data stream (PCL or PostScript) that is used. Extra memory may also benefit
the throughput of IPDS-only jobs.
• Early Print Complete: This option, or similar, is available on some
twinaxially-attached IPDS printers including the IBM network printers. If
enabled, the printer sends back a good acknowledgement to PSF/400 when it
has received the data rather than when it has printed it. This improves
performance at the risk of losing data (for example, through a paper jam). If
you enable this feature, set the PRTERRMSG parameter in the device
description to *INFO to ensure you are made aware of any conditions or
interventions at the printer.
We do not recommend that you enable this feature unless you always save
copies of your spooled files. One of the keystones of the IPDS architecture is
the two-way dialogue between host and printer and the improved error
recovery it provides. You may find that third-party implementations of IPDS
are, in fact, using a similar feature to Early Print Complete (that is, they send a
good acknowledgement back to the host immediately on receiving the data).
• IPDS Buffer Size: Also found only on twinaxially-attached printers, this should
be set to 1024 bytes rather than 256.
© Copyright IBM Corp. 2000 287
Appendix B. Data Description Specifications (DDS) formatting
DDS formatting within the printer file is the standard OS/400 interface to printed
output in the same manner that DDS is the interface for external database files.
DDS can be used for SCS, IPDS, and AFP output. With host print transform, this
can be extended to ASCII formats). Printer file DDS contains support for all the
elements in a standard document including overlays, images, graphics,
barcoding, lines, boxes, and fonts. Printer file DDS is covered in detail in OS/400
Printer Device Programming V4R2, SC41-5713. This appendix provides a couple
of examples to illustrate how documents can be formatted with DDS.
The quality of the illustrations in this appendix is not representative of the high
quality output that can be produced on the AS/400 system, but is a function of the
processes used to produce this publication.
B.1 DDS functionality example
Figure 224 on page 288 shows a sample application that provides a
comprehensive example of DDS output formatting.
The DDS source used for this sample application is shown in Figure 225 on page
289 and Figure 226 on page 290.
288 IBM AS/400 Printing V
Figure 224. DDS functionality example
Appendix B. Data Description Specifications (DDS) formatting 289
Figure 225. DDS source for DDS functionality example (Part 1 of 2)
A* DDS Functionality Printer File Specifications (1 of 2)
A*
A R HEADR1
A PAGRTT(0)
A DRAWER(1)
A* Print "DDS Functionality" in Helvetica Bold 20-point outline font
A LIN01 35A
A FNTCHRSET(CZH400 +
A (*POINTSIZE 20) T1V10037)
A POSITION(0.7 3.0) COLOR(RED)
A* Print "OS/400 V3R1 . . ." in Helvetica 12-point bitmapped font
A* w/dynamic positioning
A LIN02 35A
A FNTCHRSET(C0H200B0 T1V10037)
A POSITION(&VALDWN &VALACR)
A COLOR(PNK)
A VALDWN 5S 3P
A VALACR 5S 3P
A* Print variety of lines w/ fixed attributes
A R LINE1
A LINE(1.3 2.6 0.2 *VRT *NARROW)
A LINE(1.1 2.8 0.4 *VRT *MEDIUM)
A LINE(0.9 3.0 0.6 *VRT *WIDE)
A* Print dynamic lines (position and attributes from program)
A R LINE2
A LINE(&LD &LA &LL *HRZ &LW)
A LD 5S 3P
A LA 5S 3P
A LL 5S 3P
A LW 5S 3P
A* Print fixed box
A R BOX1
A BOX(0.8 1.0 1.5 2.0 .1)
A* Print dynamic box (position and box attributes)
A R BOX2
A BOX(&BULD &BULA &BLRD &BLRA &BWTH)
A BULD 5S 3P
A BULA 5S 3P
A BLRD 5S 3P
A BLRA 5S 3P
A BWTH 5S 3P
A* Print LIN08 - "Multiple Overlays per page" in default font
A* Print LIN09 - "Multiple Page Segments per page" in default font
A* Print "Dynamic Positioning" in printer-resident font 2311
A R TXT0
A LIN08 35A 36 27
A LIN09 35A 50 31
A 51 33 'Dynamic Positioning for OVL & PSG'
A FONT(2311 (*POINTSIZE 12))
A* Print LIN03 - "Vertical/Horizontal" in printer-resident font 18
A* Print LIN05 - "L" in GDDM scalable font
A* Print LIN06 - "LARGE CHARACTERS" in GDDM scalable font
A* Print LIN07 - "Add Points Addressability" in font 46 (Courier)
A R TXT1
A LIN03 35A POSITION(1.3 3.3)
A FONT(18) COLOR(BRN)
A LIN04 35A COLOR(YLW) FONT(19)
A POSITION(3.1 2.4)
A LIN05 1A FONT(ADMWMOB)
A POSITION(2.9 1.0)
A CHRSIZ(9.0 20.0)
A LIN06 15A FONT(ADMWMOB)
A POSITION(3.4 1.3)
A CHRSIZ(6.0 6.0)
A LIN07 35A FONT(46)
A POSITION(4.7 1.7)
290 IBM AS/400 Printing V
Figure 226. DDS source for DDS functionality example (Part 2 of 2)
Looking at both the printed sample of “DDS Functionality” and the DDS source,
let's review the specifications in detail:
• DDS Functionality (LIN01): Printed in a 20-point Helvetica Roman-Bold font
0.7 inches down and 3.0 inches across. The FRONTMGN parameter of the
printer file is set at 0 so the down/across positions are from the top/left edge of
the page.
Note: The POSITION keyword specifies the baseline or bottom left point of the
first character to print.
The font is specified using FNTCHRSET, which defines the character set and
code page to use. In the C0H400J0 font character set resource, “C0” means it
is a character set, “H400” means Helvetica Roman-Bold, and “J” means
20-point. This is a typographic font, part of the AFP Font Collection. For
300-pel printers, C0H400J0 is normally found in library QFNT300LA1. Code
A* DDS Functionality Printer File Specifications (2 of 2)
A*
A*
A*
A*
A* Print "Rotate" in four orientations
A R TXT2
A TXT1@1 6 COLOR(TRQ)
A POSITION(2.7 6.4)
A TXT1@2 6 TXTRTT(90) COLOR(RED)
A POSITION(2.7 6.4)
A TXT1@3 6 TXTRTT(180) COLOR(BLU)
A POSITION(2.7 6.4)
A TXT1@4 6 TXTRTT(270) COLOR(GRN)
A POSITION(2.7 6.4)
A* Print Interleaved 2 of 5 bar code vertically
A* Print Code 3 of 9 bar code horizontally
A R BAR1
A BAR1@1 8S BARCODE(INTERL2OF5 3 *VRT)
A POSITION(2.0 1.8)
A BAR2@1 8 BARCODE(CODE3OF9 3)
A POSITION(2.0 2.5)
A* Print text in outline (or scalable) fonts
A R FNT1
A CHR1 1 POSITION(5.7 2.0) COLOR(RED)
A FONT(2305 (*POINTSIZE 30)) CHRID
A LTR1 1 POSITION(5.7 2.85) COLOR(RED)
A FONT( 420 (*POINTSIZE 13))
A LTR2 1 POSITION(5.7 3.0) COLOR(BLU)
A FONT(2310 (*POINTSIZE 45))
A LTR3 1 POSITION(5.7 3.4) COLOR(PNK)
A FONT(2305 (*POINTSIZE 80))
A LTR4 1 POSITION(5.7 4.3) COLOR(GRN)
A FONT(20224 (*POINTSIZE 55))
A LTR5 1 POSITION(5.7 4.8)
A FONT(2307 (*POINTSIZE 20))
A CHR2 1 POSITION(5.35 5.45) COLOR(RED)
A FONT(2305 (*POINTSIZE 110)) CHRID
A* Print images (page segments) w/ variable names and positioning
A R PSG1
A PAGSEG(&PSGNAM &PSGDWN &PSGACR)
A PSGNAM 8A P
A PSGDWN 5S 3P
A PSGACR 5S 3P
A* Print Overlays One-Two-Three in fixed and dynamic form
A R OVL1
A ENDPAGE
A OVERLAY(*LIBL/DDSOVL1 6.0 1.3)
A OVERLAY(&OVLNM2 6.9 2.5)
A OVERLAY(DDSOVL3 &OV3DWN &OV3ACR)
A PAGSEG(BUSPART 7.20 1.9)
A OVLNM2 8A P
A OV3DWN 5S 3P
A OV3ACR 5S 3P
Appendix B. Data Description Specifications (DDS) formatting 291
page T1V10037 is the USA/Canada code page and is normally located in
library QFNTCPL.
• OS/400 V3R2 and Later Releases (LIN02): Prints field in Helvetica
Roman-Medium 12-point 0.9 inches down and 3.3 inches across. The
FNTCHRSET value is CZH200, which is an example of the new (V4R2) outline
font support. An outline font is one vector-based object that can be scaled to
any desired point size. A new parameter (POINTSIZE) supplies the 12-point
sizing for this text. Dynamic positioning is used, where the program variables
LINDWN and LINACR are loaded with the down/across values and referenced
in the DDS as program-to-system fields.
• Vertical/Horizontal lines and boxes (LIN03): Prints in Courier Italic starting
1.3 inches down and 3.3 inches across. The keyword FONT(18) specifies
printer-resident Courier Italic.
• Bar Code Symbologies (LIN04): Prints in printer-resident font 19, which is
OCR-A.
• Large Characters (LIN05): The “L” is printed in the Open Block font scaled by
the CHRSIZ keyword to 9.0 width and 20.0 height. ADMWMOB is the Open
Block font, one of the GDDM scalable fonts, and is located in the QGDDM
library. The balance of the text also prints in Open Block, but is scaled to 6.0
wide and 6.0 high.
• All Points Addressability: Prints in printer-resident Courier Bold, which is
FONT(46).
• Multiple Overlays per Page (LIN08): Prints in the printer-resident Courier
(font 11), which is the default font. In this case, it is specified as font identifier
011 in the printer device description.
• Multiple Page Segments per Page: Also prints in the default font.
• Dynamic Positioning for OVL and PSF: Prints in printer-resident font 85,
which is Prestige Elite. This is a printer-resident outline font with the
POINTSIZE parameter defining the size.
• Rotate: Prints the text “Rotate” in the four different rotations; 0, 90, 180, and
270. Note how the POSITION (2.7 inches down and 6.4 inches across)
defines a baseline starting point for each rotation.
• Lines (Record formats LINE1 and LINE2): Three vertical and three
horizontal lines are printed. The first vertical line begins at a point 1.3 inches
down and 2.6 inches across and has a length of 0.2 inches. The line width is
*NARROW, which means 0.008 inches wide.
All five parameters of the LINE keyword can be program-to-system variables,
enabling the application to dynamically “draw” lines. LINE2 illustrates a
dynamic line with all five variables passed from the application.
• Boxes (Records formats BOX1 and BOX2): Two boxes are drawn in the
DDSFUN3 example. The first (or thicker) box is defined by the top left (0.8
down, 1.0 across) and bottom right (1.5 down, 2.0 across) positions. The box
width is 0.1 inch. Box width can also be specified by the *NARROW,
*MEDIUM, and *WIDE special values. All five parameters of the BOX keyword
can be program-to-system variables, which enables the application to
dynamically “draw” boxes. BOX2 depicts an example of a fully dynamic box.
292 IBM AS/400 Printing V
• Text in Record Format FNT1: This record format prints text in a number of
printer-resident outline fonts. Font 2305 is Helvetica Italic. Font 420 is Courier
Bold. Font 2310 is Times New Roman Italic. Font 20224 is boldface.
• Page Segments: The IBM logo is dynamically placed using program to
system variables for page segment name, down position, and across position.
Unlike text, this position marks the top left point of the page segment image
(top left when printed in standard orientation or with 0 rotation).
Note: The strawberry image, a page segment called STRWNB is not explicitly
placed by DDS. It is part of overlay three.
• Overlays: Three simple overlays are shown in the DDSFUN3 example.
“Overlay One” is an AS/400 overlay object (*OVL) called DDSOVL1. It is
placed 6.0 down and 1.3 across. This is, again, relative to the page margins
and marks the top left point of the overlay.
“Overlay Two” is dynamically referenced from the program by the variable
OVLNM2.
“Overlay Three” is dynamically positioned from the program by the variables
OV3DWN and OV3ACR for down and across.
• Barcoding: Two examples of a barcode are specified. The field BAR1@1 is
printed vertically in the Interleaved 2 of 5 barcode, starting at 2.0 down and
1.8 across. The barcode is printed with a height value of 3, which prints a
1/2-inch high barcode. Interleaved 2 of 5 is a numeric-only barcode. The
human readable field value (012345678) is printed below the barcode, along
with the check digit (4).
The field BAR2@1 is printed horizontally in the Code 3 of 9 barcode starting at
2.0 down and 2.5 across. It prints horizontally because *HRZ is the default.
The human readable (01020304) field value is also the default. Note that Code
3 of 9 is an alphameric barcode (up to 50 characters) and does not include a
check digit.
B.2 Super Sun Seeds invoicing example
Applying the previous example, we can develop a more relevant application
example—the Super Sun Seeds invoice. This application (program INVNEW1)
produces a tailored, multi-page invoice. Individual pages are built based on the
number of customer transactions. Page components include invoice heading
information, item detail information, and invoice totals. The totals also include a
payment coupon. In addition, there is a variable marketing offer with a
customized image placed on the last page of some invoices.
Figure 227 through Figure 229 on page 295 show how three of the invoice pages
turn out.
Appendix B. Data Description Specifications (DDS) formatting 293
Figure 227. Improved Printing Corp example
294 IBM AS/400 Printing V
Figure 228. Organic Garden Supplies example (Part 1 of 2)
Appendix B. Data Description Specifications (DDS) formatting 295
Figure 229. Organic Garden Supplies example (Part 2 of 2)
The first page (Figure 227 on page 293) is for a customer with less than 16
transactions so the entire invoice can fit on one page—invoice heading, item
detail, marketing offer, totals, and payment coupon. The next two pages (Figure
228 and Figure 229) illustrate a customer whose invoice overflows to two pages.
Here the format of page one has been changed to show only invoice heading and
item information. Page two is moved up, with abbreviated heading information
followed by the balance of the transactions, the marketing offer, the invoice totals,
and the payment coupon.
296 IBM AS/400 Printing V
For a customer invoice requiring more than two pages, an additional type of page
is added. This is a “middle” page that contains the abbreviated invoice header
and the item transactions.
This application demonstrates the integration of DDS formatting with the
application program and the ability to compose pages intelligently. In this
example, many of the differences between pages are produced by selecting
different overlays.
Figure 230 through Figure 235 on page 301 show several of the different overlays
used to create different page types.
Figure 230. Overlay for a single page invoice (INVALL)
Appendix B. Data Description Specifications (DDS) formatting 297
Figure 231. Overlay for the first page of a multi-page invoice (INVFST)
298 IBM AS/400 Printing V
Figure 232. Overlay for the middle page of a multi-page invoice (INVMID)
Appendix B. Data Description Specifications (DDS) formatting 299
Figure 233. Overlay for the last page of a multi-page invoice (INVLST)
The DDS source that produced this invoicing application (INVNEW1) is shown in
Figure 234 on page 300 and Figure 235 on page 301.
300 IBM AS/400 Printing V
Figure 234. DDS source for the invoicing application (Part 1 of 2)
A* INVNEW1 - Printer File DDS for Super Sun Seeds Invoice
A* Example 1 (part 1 of 2)
A*
A*
A* Page 1 Top of Invoice
A*- include Name and Address and Invoice Heading information
A*
A R INVTOP SKIPB(10)
A ZIPPN 9S 12 BARCODE(POSTNET)
A SPACEA(2)
A NAME 25A 12
A STNAME 25A 48
A SPACEA(1)
A STREET 25A 12
A STSTRT 25A 48
A SPACEA(1)
A CITY 25A 12
A STCITY 25A 48
A SPACEA(1)
A STATE 2A 12
A ZIP 9S 16 EDTWRD(' - ')
A STSTE 2A 48
A STZIP 9S 52 EDTWRD(' - ')
A SPACEA(3)
A CUST# 6S 0 14 EDTCDE(Z)
A INVC# 6S 0 32 EDTCDE(Z)
A 49DATE EDTCDE(Y)
A PAYDAT 6S 0 66EDTCDE(Y)
A SPACEA(2)
A SHPVIA 10A 14
A 34DATE EDTCDE(Y)
A TERMS 10A 47
A SLSMAN 16A 64
A SPACEA(4)
A*
A* Page 2 Abbreviated Header
A*
A R INVTP2 SKIPB(10)
A NAME 25A 12
A SPACEA(2)
A CUST# 6S 0 14 EDTCDE(Z)
A INVC# 6S 0 32 EDTCDE(Z)
A 49DATE EDTCDE(Y)
A PAYDAT 6S 0 66EDTCDE(Y)
A SPACEA(4)
A*
A* Detail Lines
A*
A R DETLIN
A QTY 4S 0 8 EDTCDE(Z)
A UOM 2A 13
A ITEM# 8S 0 18
A ITMDES 25A 28
A SELPRC 6S 2 58 EDTCDE(J)
A EXTPRC 7S 2 70 EDTCDE(J)
A SPACEA(1)
A*
A* Multiple Page Message
A* - Text is in Helvetica 11-point (C0H200A0) raster font, or
A* - Text is in Helvetica 11-point (CZH200) outline font
A R PAGEOF
A PAGCON 4A POSITION(10.7 7.3)
A FNTCHRSET(C0H200A0 T1V10037)
A PAGCNT 2S 0 POSITION(10.7 7.8)
A FNTCHRSET(CZH200 +
A* (*POINTSIZE 11) T1V10037)
A EDTCDE(Z)
Appendix B. Data Description Specifications (DDS) formatting 301
Figure 235. DDS source for the invoicing application (Part 2 of 2)
Seven record formats are used in this DDS source:
• INVTOP: Full invoice heading information
• INVTP2: Abbreviated invoice heading information
• DETLIN: Transaction detail lines
• INVBOT: Invoice bottom (totals and payment coupon)
• OFFER: Marketing offer
• PAGSEG: Print variable page segment (image). Segment name passed from
the program.
A* INVNEW1 - Printer File DDS for Super Sun Seeds Invoice
A* Example 1 (part 2 of 2)
A* Invoice Totals
A* - includes Interleaf 2 of 5 barcode
A*
A R INVBOT SKIPB(51)
A TOTDUE 9S 2 67 EDTWRD(' , , $0. -')
A SPACEA(4)
A PAYDA@ 6S 0 25 EDTCDE(Y)
A TOTD@2 9S 2 67 EDTWRD(' , , $0. -')
A SPACEA(2)
A NAME@2 25A 12
A SPACEA(1)
A STRE@2 25A 12
A BARPRC 15S 0 52BARCODE(INTERL2OF5 3)
A SPACEA(1)
A CITY@2 25A 12
A SPACEA(1)
A STAT@2 2A 12
A* ZIP@2 9A 16
A ZIP@2 9S 16 EDTWRD(' - ')
A*
A* Offer Print
A* - Font 92 is Courier Italic 12-pitch (printer-resident)
A*
A R OFFER SKIPB(43)
A FONT(92)
A OFFR@1 24A 36
A SPACEA(1)
A OFFR@2 24A 36
A SPACEA(1)
A OFFR@3 24A 36
A SPACEA(1)
A OFFR@4 24A 36
A SPACEA(1)
A OFFR@5 24A 36
A SPACEA(1)
A OFFR@6 24A 36
A SPACEA(1)
A*
A* Images/Page Segments
A* - Dynamic page segment name passed from program
A*
A R PAGSEG PAGSEG(&PSEG 7.0 2.6)
A PSEG 8A P
A*
A*
A* Images/Page Segments
A* - variable overlay name from program
A*
A R PRTOVL OVERLAY(&OVRLAY 0 0)
A OVRLAY 8A P
A*
A* Endpage forces page advance
A*
A R ENDPAGE ENDPAGE
302 IBM AS/400 Printing V
• PRTOVL: Print variable overlay. The following overlays are used:
– INVALL: One page invoice
– INVFST: First page of multi-page invoice
– INVMID: Middle page of a multi-page invoice
– INVLST: Last page of multi-page invoice
This invoicing example (INVNEW1) produces an effective business document,
making use of electronic forms, barcoding, custom images, and tailored
marketing messages. Because the entire document is electronic, it is easily
changed. There are a number of enhancements that can be made to the
application to further enhance its value.
A fixed overlay can be printed on the back side of selected pages. In the case of
invoicing, this might be a page containing the terms and conditions of the invoice.
This is called a constant back overlay. Additional electronic copies can be
automatically produced and printed in collated sequence. In this example, you
might have a customer invoice, a packing list, and a file copy. Information on
each copy can be tailored. For example, pricing information can be suppressed
on the packing list. Since all DDS document keywords provide for dynamic
control, a completely dynamic or “floating” invoice could be produced. In this
case, the document is precisely tailored for each customer. For example, if a
given customer has 15 transactions, the invoice is designed for exactly 15
transactions.
There are two additional application examples (INVNEW2 and INVNEW3) that
implement the preceding enhancements. INVNEW2 implements the copies, price
suppression, and constant back overlay. INVNEW3 adds the dynamic (or floating)
invoice format. The DDS source for these examples and a comprehensive library
of AFP application examples can be found in the AS/400 AFP Programming
Sampler at: http://www.printers.ibm.com/as400
© Copyright IBM Corp. 2000 303
Appendix C. Print openness
Various combinations of new and enhanced application program interfaces
(APIs), new printer file parameters, new printer device description parameters,
new output queue parameters, and new printer writer parameters were added in
V3R7, and can be used to provide increased print functionality.
Print openness enables IBM or third parties to provide support for:
• Data stream transforms (to PCL, to PostScript)
• Better identification of supported personal print data streams
• Third-party attributes on printer file
• Third-party attributes on printer device description
• Third-party printer attachment
• TCP/IP LAN attached printers
• HP JetDirect LAN protocol printers
Figure 236 shows how the driver and data transform programs provided by the
user interface with the open writer and other APIs provided by the system.
Figure 236. Interface to user driver and data transform programs
The user driver program or any other user application that processes spooled
files can find information on how to process a spooled file using attributes such
as user-defined options, user-defined data, and user-defined objects. These
attributes are associated with output queues, printer devices descriptions, and
spooled files.
OR
OR
APIs to interface
with open writer
Data transform program
provided by the system
Interface for user data
transform program
APIs to manipulate
user space
APIs to retrieve
Device description
APIs for other devices
APIs that interface
with printer device
APIs to manipulate
spooled files
STRPRTWTR
Command
Device APIs
QUSRSPLA
QSPOPNSP
QSPGETSP
QSPCLOSP
QOLELINK
QOLDLINK
QOLRECV
QOLSEND
QOLSETF
Device APIs
Open
Writer
ESPDRVXT
User
Driver
QUSCRTUS
QUSCHGUS
QUSPRTUS
QSPEXTWI
QSPSETWI
QSPSNDWM
ESPDRVXT
ESPDRVXT
User data
transform
program
304 IBM AS/400 Printing V
C.1 Additional functions provided on the printer file
Additional functions provided on the printer file include new parameters on the
following commands:
• CRTPRTF: Create Printer File
• CHGPRTF: Change Printer File
• OVRPRTF: Override Printer File
Note: All the parameters added are valid only with SPOOL(*YES).
The new parameters are:
• USRDFNOPT: User-defined options that can be used by user applications or
user-specified programs that process spooled files. The maximum number of
options is four, and the default for the parameter is *NONE. The user can enter
any character.
• USRDFNDTA: User-defined data that can be used by user applications or
user-specified programs that process spooled files. The user can enter any
character up to 255 characters. The default for the parameters is *NONE.
• USRDFNOBJ: User-defined object that can be used by user applications or
user-specified programs that process spooled files. The parameter is made up
of the qualified object name and the object type. The object name meets the
AS/400 object naming convention. The possible choices for object types are:
*DTAARA, *DTAG, *FILE, *USRIDX, *USRQ, *USRSPC, and *PSFCFG. The
single default for the parameter is *NONE.
In addition, the following commands and APIs are enhanced:
• The Display File Description (DSPFD) command is enhanced to display the
new parameters added to the printer file.
• The Display Override (DSPOVR) command is enhanced to display the new
parameters added on the OVRPRTF command.
• The Work with Spooled File Attributes (WRKSPLFA) command is enhanced to
display the new parameters added to the printer file.
• The Change Spooled File Attributes (CHGSPLFA) command is enhanced to
support the parameters added to the printer file.
• The Retrieve Spooled File Attributes (QUSRSPLA) API is enhanced to
support the new printer file level of functions as new attributes.
• The Create Spooled File (QSPCRTSP) API is enhanced to support the new
printer file level of functions as new attributes.
C.2 Additional functions provided on the PRTDEVD commands
Additional functions are provided on the printer device description commands:
• CRTDEVPRT: Create Device Description Printer
• CHGDEVPRT: Change Device Description Printer
• DSPDEVD: Display Device Description
Appendix C. Print openness 305
The new parameters are:
• USRDFNOPT: User-defined options that can be used by user applications or
user-specified programs that process spooled files. The maximum number of
options is four, and the default for the parameter is *NONE. The user can enter
any character.
• USRDFNOBJ: User-defined object that can be used by user applications or
user-specified programs that process spooled files. The parameter is made up
of the qualified object name and the object type. The object name meets the
AS/400 object naming convention. The possible choices for object type are
*DTAARA, *DTAG, *FILE, *USRIDX, *USRQ, *USRSPC, and *PSFCFG. The
single default for the parameter is *NONE.
• USRDTATFM: User-specified program to transform the spooled file data
before it is processed by the driver program. The default value for the
parameter is *NONE.
• USRDRVPGM: User-specified driver program to process the spooled file. The
default value for the parameter is *NONE.
• RMTLOCNAME: Specifies the remote location name of printer device. This
value may be an SNA network ID and control point name, an Internet protocol
(IP) host name, or an Internet address.
• LANATTACH: Specifies the driver type that is used to attach the printer to the
network. The possible values are:
– *LEXLINK: LexLink attachment
– *IP: TCP/IP attachment
– *USRDFN: User-defined attachment
C.3 Additional functions provided on the output queue commands
Additional functions are provided on the output queue commands:
• CRTOUTQ: Create Output Queue
• CHGOUTQ: Change Output Queue
The added parameters are:
• USRDFNOPT: User-defined options that can be used by user applications or
user-specified programs that process spooled files. The maximum number of
options is four, and the default for the parameter is *NONE. The user can enter
any character.
• USRDFNOBJ: User-defined object that can be used by user applications or
user-specified programs that process spooled files. The parameter is made up
of the qualified object name and the object type. The object name meets the
AS/400 object naming convention. The possible choices for object type are
*DTAARA, *DTAG, *FILE, *USRIDX, *USRQ, *USRSPC, and *PSFCFG. The
single default for the parameter is *NONE.
• USRDTATFM: User-specified program to transform the spooled file data
before it is processed by the driver program. The default value for the
parameter is *NONE.
Note: In V4R2, a sample transform exit program that supports page range
processing when using a remote output queue (LPR) is shipped in the
QUSRTOOL library. The tool is called TSPRWPR.
306 IBM AS/400 Printing V
• USRDRVPGM: User-specified driver program to process the spooled file. The
default value for the parameter is *NONE.
In addition, the following parameters and commands are enhanced:
• New values in the DESTTYPE (Destination Type) parameter and the
CNNTYPE (Connection Type) parameter to support Host-to-LAN printing with
the Integrated PC Server NetWare.
• New parameter SEPPAGE (Separator Page) specifies whether to request a
separator page when the connection type is *IP or *USRDFN.
• The WRKOUTQD command is enhanced to display the new and changed
output queue attributes.
C.4 Additional functions
Other functions that are provided include:
• Two new APIs are added: Change Output Queue (QSPCHGOQ) and Change
Configuration Description (QDCCCFGD). The first one can be used to change
some attributes of an output queue, and the other one can be used to change
some of the attributes of the device description. Also both can change a new
attribute called User Defined Data. This parameter can be extracted by a
driver program using either the QSPROUTQ (Retrieve Output Queue
Information) API or the QSPRDEVD (Retrieve Device Description Information)
API. The maximum length of the user-defined data is 5000 and the default for
the attribute is *NONE.
• The User Data Transform (USRDTATFM) parameter is added to the Send TCP
Spooled File (SNDTCPSPLF) command. The user can specify the name of a
transform program to use instead of the host print transform.
• The Separator Page (SEPPAGE) parameter is added to the Send TCP
Spooled File (SNDTCPSPLF) command that allows the user the option to print
a banner page or not.
• The Start Print Writer (STRPRTWTR) command includes a new parameter
called INIT. It allows the user to specify whether to initialize the printer device.
• The new DDS keyword Data Stream Command (DTASTMCMD) is added that
allows users to store information in the data stream of the spooled file. The
information is enclosed within an AFPDS NOOP command. This keyword is
valid with AFPDS spooled files only.
C.5 Print openness: New APIs
The following APIs are added mainly to assist driver programs processing
spooled files:
• QSPEXTWI (Extract writer status):
Can be used by a print driver exit program to extract information about the
writer and about the spooled file the writer is processing.
• QSPSETWI (Set writer status):
Can be used by a print driver exit program to set information related to the
spooled files the writer is processing.
Appendix C. Print openness 307
• QSPSNDWM (Send writer message):
Can be used by a print driver exit program to send informational and inquiry
messages to the writer's message queue.
• ESPDRVXT (Print driver exit):
Defines how a user-defined print driver exit program must be written to be
used with the AS/400 print writer program.
• ESPTRNXT (Writer transform exit):
Defines the interface between a user-defined transform program and the
AS/400 print writer program.
• QWPZHPTR (Host print transform API):
Host print transform API to access the SCS to ASCII transform or the AFPDS
to ASCII transform.
• QSPBSEPP (Build separator page):
Builds the system separator page to be printed for the spooled file.
• QSPBOPNC (Build open time commands):
Builds “open time” commands for the spooled file. The “open time” commands
contain most of the file level commands needed to format the printed output.
• QGSLRSC (List spooled file AFPDS resources):
Generates a list of the AFPDS resources found in the specified spooled file
and returns the list in a user space.
• QGSCPYRS (Copy AFPDS resources):
Puts AFPDS data stream equivalent of the specified AFPDS resource into the
specified user space.
For detailed information on APIs, see AS/400 System API Reference,
SC41-5801.
308 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 309
Appendix D. Network Station printing
The IBM Network Station has both a parallel port and a serial port, either of which
can be used to print to an attached printer. The ports appear to the internal
operating system as TCP/IP sockets, to and from which bytes may be read and
written. This is the mechanism that makes printing to a printer attached to the
IBM Network Station parallel or serial port possible.
In addition, use the IBM Network Station Manager program (through the browser)
to ensure that the “Parallel printer port” setting is “On” (the default) to enable
printing support on the IBM Network Station.
D.1 Printing from OS/400
Each IBM Network Station can have a printer attached to either its parallel or
serial port. The printer must also be supported by the OS/400 host print
transform. Any AS/400 user in the network can print AS/400 output to the printers
attached to the IBM network stations.
D.1.1 AS/400 Network Station printer driver
Printers attached to IBM Network Stations are supported through the standard
printing subsystem through host print transform. You can use a wide variety of
different models from different manufacturers. Also, all printing functions are
supported such as:
• Printing page ranges
• Printing a separator page
• Limited printer status reporting
AS/400 Network Station print driver operation
Since the IBM Network Station is attached to a LAN, its printer can be shared
between several hosts. This is made possible by the way the printer writer
operates. The operation of the printer writer serving an IBM Network Station
attached printer is slightly different than that of other printer writers.
When this printer writer is started, it establishes a session to the IBM Network
Station and checks the availability of the printer. If the session cannot be
established within the activation timer value, a message is sent to the operator. If
there are spooled files on the output queue, the writer sends them to that IBM
Network Station's printer. If there are no more spooled files on the output queue,
the printer closes the session with the IBM Network Station printer after the
inactivity timer expires. Closing this session allows other servers to print on the
IBM Network Station printer. In addition, if you end the printer writer, it also closes
the session with the printer.
If new files become ready on the output queue, the writer tries to establish a new
session with the IBM Network Station printer.
D.1.2 Creating printer device descriptions
You must create a device description for each printer attached to an IBM Network
Station. You can either use the IBM Network Station Setup Assistant (STRNSSA)
Task 4300, or you can create the necessary printer device descriptions manually.
310 IBM AS/400 Printing V
If you choose to create printer device descriptions with the CRTDEVPRT
command, the following values must be used:
• Device class: Choose *LAN.
• Device type: Choose 3812.
• Device model: Choose 1.
• LAN attachment: Choose *IP. This indicates that the printer is using TCP/IP
communications.
• Port number: Choose 6464 for a parallel port attached printer and 87 for a
serial port attached printer.
Note: A serial port attached printer should have its serial interface set to the
following values:
– Baud rate: 9600 bps
– Data bits: 8 bits
– Parity: none
– Stop bit: 1
– Handshaking: DTR/DSR
• Activation timer: This value specifies the amount of time (in seconds) to wait
for the device to respond to an activation request. If a response is not received
within this time, message CPA337B is returned. This message asks the
operator if the request should be retried or canceled.
Choose any value that is suitable for your environment.
Note: If you use Task 4300 of the IBM Network Station Setup Assistant, this
value defaults to 500 seconds.
• Inactivity timer: Choose *ATTACH. This value varies by the value on the
physical attachment (ATTACH parameter) and certain values on the device
class (DEVCLS) and application type (APPTYPE) parameters. For
DEVCLS(*SNPT) or APPTYPE(*DEVINIT) support, *ATTACH maps to
*NOMAX. For DEVCLS(*LAN), *ATTACH maps to *SEC15. For
APPTYPE(*NRF) and APPTYPE(*APPINIT) support, *ATTACH maps to 1
minute.
You may specify an interval between 1 minute and 30 minutes or the special
values *SEC15, *SEC30, or *NOMAX.
The IBM Network Station handles only one activation request at a time from
any host. The Inactivity Timer parameter allows sharing the printer device
among several hosts. After the time you specified has elapsed, the writer job
releases the device if there are no more spooled files to print. If you specify
*NOMAX for the Inactivity Timer parameter, the writer keeps the connection to
printer active until you stop the printer writer. Therefore, using *NOMAX
effectively prevents sharing the printer.
Note: If you use Task 4300 of the IBM Network Station Setup Assistant, this
value defaults to 1 minute.
• Host print transform: Choose *YES. This is required to transform AS/400
EBCDIC data to ASCII data.
• Manufacturer type and model: Type in the value that reflects the printer to
be configured. To determine that value, you can press the Help key to view the
list of supported printers.
Appendix D. Network Station printing 311
• Remote location name: Specify the IP address or the name of the IBM
Network Station to which the printer is attached.
Note: If you want to specify the name, you must first create an entry in the
TCP/IP Host Table.
• System driver program: Specifies the printer driver type to be used for this
configuration. For IBM Network Station attached printers, this value must be
*NETSTNDRV.
D.2 Local printing
This section outlines aspects of local printing.
D.2.1 5250 screen copy to a local printer
If you click the Print pull-down option in the 5250 emulator, you can select local or
host print. If you click Local, the contents of the 5250 session window can be
printed on the IBM Network Station directly-attached printer. If you click Host, the
AS/400 system print function is invoked, and you see the message “Print
operation complete to the default printer device file”.
D.2.2 Printing from Java
Java is the only language in which IBM Network Station applications can be
written. Release 2.5+ of the IBM Network Station software includes an
implementation of Sun's 1.1 JVM, which includes the ability to print with Java
applications.
Note: All printing through the JVM generates PostScript output. Page Layout is
the responsibility of the Java application. Untrusted applets are not allowed to
create print jobs.
An overview for developers, written by Sun, can be found at:
http://java.sun.com/products/jdk/1.1/docs/guide/awt/designspec/printing.html
As part of this support, it is possible to send Java application output to the AS/400
system through LPR/LPD. Typically, you have a print dialog that allows you to
specify a print destination of PARALLEL1, SERIAL1, or a remote print destination
in the form of QueueName@ServerName. The first two values direct output to a locally
attached printer, while the third value causes output to be sent to a remote
system (which can be an AS/400 system) through LPR/LPD.
As previously noted, the output is generated in PostScript. Therefore, you need to
make sure that the printer the AS/400 system ultimately routes the spooled data
to is capable of printing PostScript.
312 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 313
Appendix E. Printer summary
This appendix provides a summary of AS/400 system-supported printers,
including IBM production printers, IBM industrial printers, and IBM workgroup
printers.
Table 24. IBM production printers for the AS/400 system
IBM AS/400
printer
Max
speed
Technology Resolution Attachment Data stream Features
Infoprint 60 60 ipm Laser 600 x 600
(240 and 300
dpi input
accepted)
IP Token Ring
IP Ethernet
SNA Token Ring
IPDS
PCL
High speed/capacity
AFCCU control unit
Up to 4 input bins
750,000 imp/month
Cut sheet/duplex
Multi-function finisher
includes stapling, folding,
saddle stitching, insertion
Infoprint 62 62 ipm Non Contact
Flash Fusing
Laser
240 x 240
300 x 300
IP Token Ring
IP Ethernet
SNA Token Ring
IPDS Continuous form
AFCCU control unit
Wide forms
(to 14-1/2")
Power Stacker option
Infoprint 70 70 ipm Laser 600 x 600 IPToken-Ring
IP Ethernet
IPDS
PostScript/PCL
(supported via a
print server)
Homerun Control Unit
High capacity input
Finishing, including stapling
400k impressions/month
Infoprint 2000 110 ipm Laser 600 x 600 SNA Token Ring,
IP Token Ring
IP Ethernet
PostScript 3
PCL
IPDS
Note: PCL and
PostScript 3
support through
print server
transforms.
High speed, high volume,
high fidelity
Up to 2.0million imp/month
Cut sheet
Infoprint 3000 Up to
334 ipm
Laser 600 x 600, SNA Token Ring,
IP Token Ring
IP Ethernet
IPDS High speed, high volume,
18" print width = 2-up
Simplex, duplex,
Intelligent Post-Processing,
Up to 17.4 million imp/mo
Continuous form
Infoprint 4000 Up to
1002
ipm
Laser 240 x 240,
300 x 300,
480 x 480,
600 x 600,
SNA Token Ring
IP Token Ring
IP Ethernet
IPDS High speed, high volume,
Resolution to 600 dpi
18" print web = 2-up
Simplex, duplex,
Intelligent Post-Processing,
Up to 17.4 million imp/mo
Continuous form
Infoprint 4000
HiLite Color
Up to
1002
ipm
Highlight
Color Laser
240 dpi
300 dpi
Attaches to
Infoprint 4000
and IBM 3900
IPDS High speed, high volume
color
Continuous Form
314 IBM AS/400 Printing V
Table 25. IBM industrial printers for the AS/400 system
Table 26. IBM workgroup printers for the AS/400 system
IBM AS/400
printer
Speed Technology Resolution Attachment Data stream Features
4230 375 cps -
600 cps
Dot Matrix Varies by
print quality
mode
Twinax,
Serial/Parallel
IPDS LAN (7913)
ASCII LAN (NPS)
IPDS
SCS
ProPrinter
Heavy Duty
IPDS graphics, barcode
Easy to use
Very Quiet (53 dBA)
4232 600 cps Dot Matrix Varies by
print quality
mode
Serial or Parallel
ASCII LAN (NPS)
ProPrinter or
4224-3XX
Heavy duty
Easy to use
Very quiet (53 dBA)
4247 700 cps Dot Matrix Varies by
print quality
mode
Twinax
Serial/Parallel
IPDS LAN (7913)
ASCII LAN (7913)
IPDS
SCS
ProPrinter or
Epson
Up to 6 inputs
2 continuous forms
Up to 8-part forms
Quiet (55 dBA)
6400
Cabinet
500 lpm
1000 lpm
1500 lpm
Line Matrix Varies by
print quality
mode
Twinax,
Serial/Parallel,
IP Ethernet IPDS
ASCII Ethernet
IPDS
ProPrinter,
Printronics
Epson
SCS
Code V, IGP
Heavy Duty
Very Quiet (52 dBA)
Low cost of operation
Web-controlled Op panel
NPM support
6400
Pedestal
500 lpm
1000 lpm
Line Matrix Varies by
print quality
mode
Twinax,
Serial/Parallel,
IP Ethernet IPDS
IP Ethernet ASCII
IPDS
ProPrinter,
Printronics
Epson
SCS
Code V, IGP
Heavy Duty
Low cost of operation
Web-controlled Op panel
NPM support
4400 Thermal
Label
Printer
6-10
Inches
Per
Second
Thermal 300 dpi
203 dpi
Twinax
Serial/Parallel
IP Ethernet IPDS
IP Ethernet ASCII
IPDS
ProPrinter
Printronics
Epson
SCS
Code V, IGP
4, 6, 8 inch width models
Heavy-duty Industrial Design
Remote Web Management
Barcode verifier
Cutter
IBM AS/400
printer
Speed Technology Resolution Attachment Data stream Features
Infoprint
Color 8
(4308)
8 ppm Full Color
Laser
600 x 600 Serial/Parallel,
Ethernet,
Token Ring
PCL5e
PostScript 3
35,000 imp/month
AS/400 Support via Host Print
Transform
Network
Printer 12
(4312)
12 ppm Laser 300 x 300
600 x 600
Twinax,
Serial/Parallel,
Ethernet
(10/100),
Token Ring
IPDS
SCS
PCL5e
PostScript
IBM Integrated AFP/IPDS
35,000 imp/month
Edge to Edge Printing
Infoprint 12
(4912)
12 ppm Laser 1200 x 1200 Parallel,
Ethernet
PCL6
PostScript 3
Low cost, entry network printer
20,000 imp/month
Network
Printer 17
(4317)
17 ipm Laser 300 x 300
600 x 600
Twinax,
Parallel,
Ethernet,
Token Ring
IPDS
SCS
PCL5e
PostScript
IBM Integrated AFP/IPDS
65,000 imp/month
10 bin mailbox
Cut sheet/duplex
Appendix E. Printer summary 315
Infoprint 20
(4320)
20 ppm Laser 600 x 600
1200 x 1200
Twinax,
Parallel,
Ethernet
(10/100),
Token Ring
IPDS
SCS
PCL5e
PostScript 3
IBM Integrated AFP/IPDS
75,000 imp/month
11 by 17 support
Cut sheet/duplex
Infoprint 21
(4321)
21 ppm Laser 600 x 600
1200 x 1200
Twinax,
Parallel,
Ethernet
(10/100),
Token Ring
IPDS
SCS
PCL6
PostScript 3
PDF
IBM Integrated AFP/IPDS
Integrated web server
Label-ready
Web-based management
IPP-enabled
Infoprint 32
(4332 001)
32 ppm Laser 600 x 600
1200 x 1200
Twinax,
Parallel,
Ethernet
(10/100),
Token Ring
IPDS
SCS
PCL5e
PostScript 3
IBM Integrated AFP/IPDS
150,000 imp/month
11 by 17 support
Cut sheet/duplex
High-function finisher includes
stapling, collation
Infoprint 40
(4332 002)
40 ppm Laser 600 x 600
1200 x 1200
Twinax,
Parallel,
Ethernet
(10/100),
Token Ring
IPDS
SCS
PCL5e
PostScript 3
IBM Integrated AFP/IPDS
200,000 imp/month
11 by 17 support
Cut sheet/duplex
High-function finisher includes
stapling, collation
IBM AS/400
printer
Speed Technology Resolution Attachment Data stream Features
316 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 317
Appendix F. PSF/400 performance results
This appendix contains selected results from a PSF/400 V4R2 performance
evaluation. The performance evaluation was performed by the IBM Printing
Systems Company Performance Group in Boulder, Colorado.
F.1 Environment
PSF/400 V4R2 printing performance was measured using an AS/400 Model
510/2144 processor with IBM Network Printer 24, IBM Infoprint 60, and IBM
Infoprint 4000 printers attached to a dedicated 16 MB Token-Ring. The AS/400
system was totally dedicated to printing with no other processes active except for
measurement. The printer Token-Ring was connected only to the AS/400 system
and one of the printers at any one time.
The AS/400 Model 510/2144 is a low to medium performance system relative to
the other current AS/400 models. Based on V4R1 Commercial Processing
Workload (CPW) ratings, the Model 510/2144 system's performance compares to
other selected models as shown in Table 27.
Table 27. Performance comparison of some AS/400 models
F.1.1 Software
The PSF/400 V4R2 software was preliminary GA level, believed to represent GA
level performance. Software parameters relevant to performance were set to:
• 10,000 KB Spool (QSPL) Storage
• 8 KB Receive Buffer size
• 8 KB (NP24) and 32 KB (IP60 and IP4000) Send Buffer sizes
• 4096 byte MTU size
• 16 KB Maximum Frame size
Model V4R1 CPW ratings
500 21.4 to 43.9
600 22.7 to 73.1
510/2144 111.5
620 85.6 to 464.3
530 148.0 to 650.0
640/2237 319.0
640/2238 563.3
640/2239 998.6
650 1,794.0 to 2,743.6
840 16,500
318 IBM AS/400 Printing V
F.1.2 Hardware
The AS/400 system that was used included this setup:
• Model 510
• Processor Type 2144
• 512 MB Memory
• 28 GB DASD
• 2619-001 IOP/Token-Ring adapter
• 16MB Token-Ring
Performance was evaluated using three printers, each attached to the AS/400
system by means of a 16 Mb Token-Ring.
• Network Printer 24 (NP24/4324):
– IPDS, PCL, or PostScript
– Cut-sheet
– 24 pages per minute (PPM) simplex, 19 PPM duplex
– 300 dpi resolution
– 20 MB memory
• Infoprint 60 (IP60):
– IPDS only
– Cut-sheet
– 60 PPM, both simplex and duplex
– 240 and 300 dpi resolution (prints at 600 dpi)
– 64 MB of memory
• Infoprint 4000 (IP4000):
– IPDS only
– Continuous forms
– 708 PPM (2-up duplex)
– 240 dpi resolution
– 128 MB of memory
This IP4000 “printer” was actually a laboratory device that is based on a
real IP4000 control unit, but simulates the paper and imaging hardware of
the real IP4000. In function and performance, it represents the IP4000
faithfully except for the lack of printed output.
F.2 Methodology
The parameters for determining PSF/400 V4R2 performance are:
• Time for the first page to print and total job time: These are the elapsed
times between job submission and printing the first page of the job, and
between job submission and printing the last page of the job. For the IP4000,
the time for the first page was assumed to be when the operator panel
displayed “Printing”.
• Spooled file conversion throughput: This is defined as the rate of
converting the spooled file in pages per minute (PPM), from the first page of
the job until the last page of the job. This is determined from Start and End
time stamps for the spooled file conversion process of PSF/400.
• Printer throughput: This is defined as the rate of printing in pages per minute
(PPM), from the first page of the job until the last page of the job.
Appendix F. PSF/400 performance results 319
Instrumentation was used with the IP4000 to arrive at steady-state printing
rates more accurately.
• PSF/400 V4R2 use of the AS/400 system processor: This is the use of the
processor during both the PSF/400 spooled file conversion and printer driver
phases, where appropriate. It is reported both as percent utilization and as
processor time (milliseconds) per page converted and printed.
The procedure for PSF/400 V4R2 measurements begins with complete isolation
of the AS/400 system from all connections other than the printer, and
de-activation of all processes other than PSF/400 and the Performance Monitor.
Files to be measured have already been placed on the spool. Each measurement
is made using this procedure:
1. Print a few pages of the job to be measured to make sure fonts and other
resources have been downloaded to the printer before the measurement
starts.
2. Start PSF Trace to record start and stop times for the spooled file conversion
and printer driver phases of PSF/400. While PSF Trace can have a large effect
on performance if it is not used carefully, using it to record this limited data has
no measurable effect.
3. Start the Performance Monitor to gather information about processor use
while converting and printing.
4. Release the spooled file to be measured, starting a timer at the same time.
5. Record the time at which the first page has been printed and dropped into the
output hopper (cut sheet printers) or shown as “printing” (IP4000).
6. Record the time at which the last page has been printed.
7. Stop the Performance Monitor and PSF Trace.
8. Retrieve start, stop, and processor use information for the spooled file
conversion and printer driver from information recorded by PSF Trace and
Performance Monitor.
This information is then processed as a spread sheet, and the results are
tabulated.
F.3 Performance cases
Twenty-three print jobs were used, although not all with any one printer. Fifteen
print jobs are native AS/400 applications. Many of these were produced as
sample programs for marketing demonstrations (for example, Super Sun Seeds)
or are variations of sample programs. AS/400 applications typically specify
print-resident fonts.
One of the native AS/400 jobs and two others were printed using the host print
transform facility of the AS/400 for a total of 26 distinct cases. These cases are
shown in Table 28 on page 320 with descriptions of their origins and
characteristics.
Eight print jobs are from a set of AFP (Performance Reference Pages that have
been used to evaluate performance of PSF products and printers for some time).
Some of them use downloaded fonts that are not in the current Core Interchange
set, which can cause PSF/400 and printers to process the job differently.
320 IBM AS/400 Printing V
Applications such as these (common in the MVS environment) typically specify
and use downloaded fonts. These jobs represent complex AFP applications.
They were imported to the AS/400 spool.
Some of these jobs produce output that appears the same as or similar to the
output of another job, using a different form with different performance
characteristics. These similarities in appearance are noted in the descriptions.
Table 28. Names and descriptions of performance cases
Case name Case description
INVPRE Text with overlay. Produces one version of the Super Sun Seeds invoice
application. INVPRE is an SCS application where the invoice overlay has
been added using the Printer File (that is, OVRPRTF). Sample output from
this test case is shown in Figure 237 on page 334.
INVNEW2 Text with overlays and barcodes. Produces an AFP version of Super Sun
Seeds involve using DDS. Each invoice can have multiple customized
pages. Each invoice has three collated copies—customer, packing list, and
file—each of which is different. Sample output from this test case is shown
in Figure 238 on page 334.
INVNEW2A Same as INVNEW2 but without barcodes. Sample output from this test case
is shown in Figure 239 on page 335.
INVNEW3 Text with overlays and barcodes. A more sophisticated version of Super Sun
Seeds invoice using DDS. Each page is drawn (using dynamic variables in
DDS) to match the number of customer transactions. Appearance is the
same as INVNEW2. Sample output from this test case is shown in Figure
238 on page 334.
INVNEW3A Same as INVNEW3 but without barcodes. Appearance is the same as
INVNEW2A. Sample output from this test case is shown in Figure 239 on
page 335.
INVSCS Text with overlays. Advanced Print Utility (APU) version of Super Sun Seeds
invoice application. INVSCS is the original application, creating flat SCS for
a preprinted invoice form. Using an APU print definition, the SCS spooled
file is transformed into an AFP spooled file. This case uses the AFP spooled
file. Sample output from this test case is shown in Figure 240 on page 335.
INVPDEF Text with overlays. This is a Super Sun Seeds invoicing application
formatted by using page and form definitions. Using an override to the
printer file, the original SCS application is switched to line data, and the
page definition and form definition are added. Sample output from this test
case is shown in Figure 241 on page 336.
INVPDEFA An invoicing application similar to INVPDEF, using fewer overlays and
different data. Appearance is somewhat similar to INVPDEF. Sample output
from this test case is shown in Figure 241 on page 336.
SHLFLB 30 labels, with a barcode on each label. This shelf label application was
created using the Print Format Utility (a module of AFP Utilities). Sample
output from this test case is shown in Figure 242 on page 336.
SHLFLBA 30 labels, with a barcode on each. Shelf application from PFU. This is not
the same application as SHLFLB, but it is similar in appearance. Sample
output from this test case is shown in Figure 242 on page 336.
SCS 57 132-character lines of SCS data. Plain text in SCS format. Sample output
from this test case is shown in Figure 243 on page 337.
Appendix F. PSF/400 performance results 321
SCSA 29 72-character lines of SCS data. Plain text in SCS format. This is not the
same application as SCS. Sample output from this test case is shown in
Figure 244 on page 337.
SCS-PT 57 132-character lines of SCS data printed using passthrough. The
appearance is the same as SCS. Sample output from this test case is shown
in Figure 243 on page 337.
SCS-PTA 29 72-character lines of SCS data printed using passthrough. The
appearance is the same as SCSA. This is not the same application as
SCS-PT. Sample output from this test case is shown in Figure 244 on page
337.
SCS-PDEF 57 132-character lines of unformatted line data. Same text as SCS printed
with the same appearance using a page definition.
TXT8K-HPT 8000 text characters. This is the TXT08K case done with host print
transform (for a PCL printer). The appearance is similar to TXT08K. Sample
output from this test case is shown in Figure 245 on page 338.
CMLIM-HPT Complex text with IM image, 49325 bytes total. This is the TXTTCMLIM
case done with host print transform (for a PCL printer). The appearance is
similar to TXTCMLIM. Sample output from this test case is shown in Figure
247 on page 339.
INVN2-HPT Text with overlays. This is the INVNEW2 case done with host print transform
(for a PCL printer). Appearance is similar to INVNEW2.
TXT08K Simple DCF text pages of 8000 text characters each, format off, one
downloaded font (gothic). Direction of printing is done, and there are 9346
bytes per page (text and controls). Sample output from this test case is
shown in Figure 245 on page 338.
TXT32K Simple DCF text pages of 32000 text characters each, format off, one
downloaded font (gothic). Direction of printing is done and there are 35951
bytes per page (text and controls). Sample output from this test case is
shown in Figure 246 on page 338.
TXTCMLIM Complex DCF text pages of 4799 text characters each, two columns of
justified text, with eight different downloaded fonts (Sonoran), three tables,
and a 5.2 square inch GDDM (ceiled) image on each page. Direction of
printing is down, and there are 40325 bytes per page (text, image and
controls). Sample output from this test case is shown in Figure 247 on page
339.
STMTSHAD Complex billing statement pages using OGL overlays. The overlay contains
two images (3.36 square inches total), and 306 text characters, and has
19467 bytes total (text, image, and controls). 47 lines of 12 fields of variable
data are printed on each page (using pagedef specifications) for another
7674 bytes per page (text and controls). Seven downloaded fonts are used
(Sonoran and Prestige Pica). Note that the overlay is stored in the printer’s
memory and does not have to be retransmitted for every page. Sample
output from this test case is shown in Figure 248 on page 339.
RAST24 Pages containing one simple image page segment of 24 square inches.
Page segment source is PMF. 173138 bytes per page (image data and
controls). Sample output from this test case is shown in Figure 249 on page
340.
Case name Case description
322 IBM AS/400 Printing V
F.4 Results
Seven tables of performance information follow. Table 29, Table 30 on page 324,
and Table 31 on page 325 show the number of pages printed and the
performance results for each case used with the NP24, IP60, and IP4000
printers. Table 32 on page 326 and Table 33 on page 328 summarize and
compare printing rates and processor use for the three printers. Table 34 on page
330 shows calculated AS/400 Model 510/2144 processor utilization based on
measured processor use, at NP24, IP60, and IP4000 maximum printing rates.
Table 35 on page 331 compares the performance effects of operating PSF/400 in
simultaneous print and convert mode (Print While Convert (PNC) = YES) to
operating with PWC=NO.
F.4.1 PSF/400 V4R2 with Network Printer 24
The NP24 printer is a cut-sheet printer with 300 dpi resolution, with maximum
printing speeds of 24 PPM (simplex) and 19 PPM (duplex) using letter sized
paper. Some jobs were printed in duplex, some in simplex, and one (INVSCS) is a
mixed simplex and duplex application. All NP24 measurements were made with
PWC=NO, which causes printing to wait until spooled file conversion is complete
(Table 29).
Table 29. NP24 performance with PSF/400 V4R2 (AS400 Model 510/2144): Print While Convert=NO
RAST50 Pages containing one simple image page segment of 50 square inches.
Page segment source is PMF. 360453 bytes per page (image data and
controls). Sample output from this test case is shown in Figure 250 on page
340.
CHKSG410 Pages each containing 10CCITT Group 4 compressed 240 dpi IOCA
checks of 4.09 square inches each. 43478 bytes per page (image data and
controls). Sample output from this test case is shown in Figure 251 on page
341.
G479BO52 Pages each containing one 79 square inch CCITT Group 4 compressed 240
dpi IOCA image (5:1 compression). 109819 bytes per page (image data and
controls). Sample output from this test case is shown in Figure 252 on page
341.
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
INVPRE 80 :19 3:35 1.811 26 24 .1 8.5 1.9 10.4
INVNEW2 80 :30 4:39 1,644 36 19 .1 13.3 2.0 15.3
INVNEW3 80 :30 4:42 623 37 19 .3 13.1 8.8 21.9
INVSCS 80 :30 6:13 1,733 33 13 .1 11.5 2.1 13.6
INVPDEF 80 :31 4:33 1,314 30 19 .0 13.5 1.3 14.7
SHLFLB(s) 80 :24 3:39 694 78 24 .1 67.6 2.5 70.1
SCS(s) 80 :19 3:34 1,890 51 24 .1 12.0 1.0 13.0
Case name Case description
Appendix F. PSF/400 performance results 323
F.4.2 PSF/400 V4R2 with IP60
The IP60 printer is a cut-sheet printer with both 240 dpi or 300 dpi resolutions. It
prints at 600 dpi in either case. Its maximum printing speed is 60 PPM in both
simplex and duplex when using letter sized paper. Some jobs are printed in
duplex, some in simplex, and one (INVSCS) is a mixed simplex and duplex
application. The IP60 measurements shown in Table 30 on page 324 were made
with PWC=NO, which causes printing to wait until the spooled file conversion is
SCS-PT(s) 80 :18 3:33 2,927 59 24 .0 12.0 1.0 13.0
SCS-PDEF 80 :19 3:33 2,133 22 24 .1 6.1 1.5 7.6
TXT8K-HPT 80 :54 4:56 na na 19 4* na na 123.4
CMLIM-HPT 80 :1:15 5:16 na na 19 10* na na 309.8
INVN2-HPT 90 1:30 6:02 na na 19 12* na na 399.0
TXT08K 80 :26 4:35 5,926 54 19 .1 5.5 1.8 7.3
TXT32K 80 :31 4:42 1,638 31 19 .1 11.3 4.0 15.3
TXTCMLIM 80 :32 4:41 1,182 47 19 .2 23.6 5.3 28.9
STMTSHAD 80 :40 6:08 845 61 14 .0 43.4 2.0 45.4
RAST24 80 :41 4:50 612 42 19 .4 41.5 14.4 55.9
RAST50 80 :55 10:01 298 41 8 .6 82.3 43.9 126.1
CHKSG410 80 :36 4:44 1,069 61 19 .1 34.1 4.1 38.3
G479BO52 80 :43 13:14 740 39 6 .1 31.6 9.6 41.3
Notes:
(s) Indicates simplex printing.
* Since there are no distinct conversion and printing processes with HPT, all processor use and utilization are
shown under “Printing”.
• No. Pages: The total number of pages printed for the job. For duplex jobs, this is twice the number of sheets
produced by the printer.
• Page Times: The number of minutes and seconds (from the time the job was released from the spool) until the
first and last pages were printed.
• Conversion Rate: The rate in pages per minute at which the spooled file was converted prior to printing.
• Conversion Util: The percent of the time the AS/400 processor was busy while the spooled file was being
converted. When no other work is using the processor (as in these measurements), the spooled file conversion
process uses as much processor time as it can and converts at a high rate. When other processors are running,
as they normally are, utilization for conversion is higher and the conversion rate is lower.
• Printing Rate: The rate in pages per minute at which pages were printed.
• Printing Util: The percent of the time the AS/400 processor is busy while the spooled file is being printed. For
a given job, printing utilization is approximately proportional to the printing rate.
• Processor Time per Page: The milliseconds of time during which the processor is busy for each page
converted, printed, and totalled. This number is independent of the rate at which pages are being printed.
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
324 IBM AS/400 Printing V
complete. IP60 measurements made with PWC=YES were also made. Results
are compared to the PWC=NO results in Table 30 on page 324.
Table 30. IP60 performance with PSF/400 V4R2 (AS400 Model 510/2144): Print While Convert=NO
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
INVPRE(s) 300 :26 5:25 5,488 47 60 2 5.1 17.5 22.6
INVNEW2 300 :35 6:03 4,478 53 52 1 7.0 11.1 18.1
INVNEW2A 300 :31 5:29 5,028 43 60 1 5.2 11.3 16.4
INVNEW3 300 :32 6:30 4,255 53 50 1 7.5 17.1 24.6
INVNEW3A 300 :35 5:33 4,255 39 60 1 5.4 14.0 19.4
INVSCS 300 :38 1:04 4,216 54 28 1 7.6 25.2 32.8
INVPDEF 78 :32 1:48 1,286 30 60 1 14.0 11.5 25.5
SHLFLB(s) 300 :52 5:50 892 98 60 1 65.8 9.9 75.7
SHLFLBA 300 1:04 6:05 861 93 59 .2 64.5 2.6 67.1
SCS(s) 240 :27 4:26 2,780 69 60 .2 14.9 1.7 16.6
SCS-PT(s) 240 :28 4:47 4,260 77 55 .1 10.8 1.2 12.0
SCS-PDEF(s) 240 :33 4:32 4,528 37 60 .3 4.9 3.4 8,3
TXT08K 320 :31 5:49 - - 60 na 4.3 3.3 7.6
TXT32K 320 :38 5:56 2,365‘ 40 60 1 10.2 7.5 17.7
TXTCMLIM 320 :42 6:00 1,596 49 60 2 18.3 25.0 43.4
STMTSHAD 320 :45 6:03 2,520 71 60 1 17.0 14.6 31.6
RAST24 300 1:17 6:15 641 42 60 2 39.2 24.6 63.8
RAST50 300 1:39 6:37 300 39 60 4 78.0 45.4 123.4
CHKSG410 300 :51 5:49 1,243 76 60 1 36.8 6.5 43.3
G479BO52 300 :59 5:57 874 46 60 1 31.6 15.0 46.6
Appendix F. PSF/400 performance results 325
F.4.3 PSF/400 V4R2 with IP4000
The IP4000 printer is a continuous-forms printer that can be used in either 240
dpi or 300 dpi resolution. For this study, it was used in 240 dpi resolution. Its
maximum printing speed is 708 PPM when printing two-up duplex on letter sized
pages. All jobs were printed on the IP4000 in two-up duplex. The IP4000
measurements shown in Table 31 were made with PWC=NO, which causes
printing to wait until the spooled file conversion is complete.
Table 31. IP4000 performance with PSF/400 V4R2 (AS/400 Model 510/2144): Print While Convert=NO
Notes:
(s) Indicates simplex printing.
(msec) Stands for milliseconds or thousandths of a second.
• No. Pages: The total number of pages printed for the job. For duplex jobs, this is twice the number of sheets
produced by the printer.
• Page Times: The number of minutes and seconds (from the time the job was released from the spool) until the
first and last pages were printed.
• Conversion Rate: The rate in pages per minute at which the spooled file was converted prior to printing.
• Conversion Util: The percent of the time the AS/400 processor was busy while the spooled file was being
converted. When no other work is using the processor (as in these measurements), the spooled file conversion
process uses as much processor time as it can and converts at a high rate. When other processors are
running, as they normally are, utilization for conversion is higher and the conversion rate is lower.
• Printing Rate: The rate in pages per minute at which pages are printed.
• Printing Util: The percent of the time the AS/400 processor is busy while the spooled file is being printed. For
a given job, printing utilization is approximately proportional to the printing rate.
• Processor Time per Page: The milliseconds of time during which the processor was busy for each page
converted, printed, and totalled. This number is independent of the rate at which pages are being printed.
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
INVPRE 3520 :25 5:23 12,857 83 708 25 3.9 21.8 25.6
INVNEW2A 3520 :20 5:18 15,589 81 708 14 3.1 12.5 15.6
INVNEW3A 3520 :25 5:27 12,512 75 708 21 3.6 17.9 21.5
INVPDEFA 804 :10 1:17 9,805 46 708 7 2.8 6.4 9.2
SHLFLBA 3480 4:03 8:58 880 97 708 3 66.2 2.2 68.4
SCSA 3520 :25 5:23 10,353 8 708 1 5.1 0.9 6.1
SCS-PTA 3520 :18 5:16 15,808 9 708 .4 3.5 0.4 3.8
TXT08K 3520 :30 5:28 8,322 58 708 4 4.2 3.3 7.5
TXT32K 2112 :54 5:51 2,715 45 478 4 9.9 5.3 15.3
TXTCMLIM 3520 1:59 9:47 1,880 54 389 17 17.4 23.2 40.5
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
326 IBM AS/400 Printing V
F.4.4 Comparison: Printing rates using PSF/400 V4R2 on Model 510/2144
The printing rates (with PWC=NO) for NP24, IP60, and IP4000 are compared in
Table 32. Explanations of less-than-maximum speed results are included after the
table.
These rates were achieved when the AS/400 system was doing nothing else,
when the Token-Ring was not shared with any other devices, and when the
spooled file conversion had already completed. Some of these rates might not be
achieved under other circumstances, especially with the high-speed IP4000.
Some jobs were not measured on all three printers because of functional
differences.
Table 32. Printing rates (PPM) for NP24, IP60, and IP400: Print While Convert=NO
STMTSHAD 3520 1:06 7:36 3,621 92 538 15 15.3 17.3 32.6
RAST24 1200 2:00 5:59 638 43 288 11 40.6 21.6 62.2
CHKSG410 2300 1:43 5:36 1,427 79 589 6 33.3 6.1 39.5
G479BO52 2000 2:12 8:48 962 50 305 7 31.3 13.3 44.7
Notes:
(msec) Stands for milliseconds or thousandths of a second.
• No. Pages: The total number of pages printed for the job. For two-up duplex jobs, this is four times the number
of sheets produced by the printer.
• Page Times: The number of minutes and seconds (from the time the job was released from the spool) until the
first and last pages were printed.
• Conversion Rate: The rate in pages per minute at which the spooled file was converted prior to printing.
• Conversion Util: The percent of the time the AS/400 processor is busy while the spooled file is being
converted. When no other work is using the processor (as in these measurements), the spooled file conversion
process uses as much processor time as it can and converts at a high rate. When other processors are running,
as they normally are, utilization for conversion is higher and the conversion rate is lower.
• Printing Rate: The rate in pages per minute at which pages are printed.
• Printing Util: The percent of the time the AS/400 processor is busy while the spooled file is being printed. For
a given job, printing utilization is approximately proportional to the printing rate.
• Processor Time per Page: The milliseconds of time during which the processor is busy for each page
converted, printed, and totalled. This number is independent of the rate at which pages are being printed.
Case NP24 IP60 IP4000
INVPRE (s)24 (s)60 708
INVNEW2 19 52 5 -
INVNEW2A - 60 708
INVNEW3 19 50 5 -
INVNEW3A - 60 708
INVSCS 13 6 28 6 -
Case
No. of
pages
Page times Conversion Printing Processor Time
(mins:secs) Rate Util Rate Util per page (msec)
First Last (PPM) (%) (PPM) (%) Cvt Prt Tot
Appendix F. PSF/400 performance results 327
INVPDEF 19 60 -
INVPDEFA - - 708
SHLFLB (s)24 (s)60 -
SHLFLBA - 59 5 708
SCS (s)24 (s)60 -
SCSA - - 708
SCS-PT (s)24 (s)55 5 -
SCS-PTA - - 708
SCS-PDEF (s)24 (s)60 -
TXT08K-HPT 19 - -
CMLIM-HPT 19 - -
INVN2-HPT 19 - -
TXT08K 19 60 708
TXT32K 19 60 478 1
TXTCMLIM 19 60 389 3
STMTSHAD 14 1 60 538 3
RAST24 19 60 288 2
RAST50 8 1 60 -
CHKSG410 19 60 589 2
G479BO52 6 1 60 305 2
(s) Printing in simplex.
1. Limited by printer control unit capability. That is, this model of the IP4000 is not
capable of printing this case at maximum speed of 708 PPM.
2. Limited by Token-Ring attachments. The theoretical limitation of the 16 Mb per
second Token-Ring is 2 MB per second and the practical data rate limitation of
TCP/IP and the Token-Ring, including the effects of this printer's Token-Ring
adapter, is below that. For example, printing the RAST24 case at 708 PPM requires
an average sustained data rate to the printer of slightly more than 2 MB per second
because of the amount of data contained in each page.
3. Limited by PSF/400 processing of downloaded fonts while printing. This job prints
at a rated speed if printer-resident fonts are used. A PSF/400 improvement not yet
available also eliminates this limitation.
4. Limited by PSF/400 processing of downloaded fonts. This job prints faster but not
at a maximum speed (because of printer control unit limitations) if printer-resident
fonts are used. A PSF/400 improvement not available in V4R2 also eliminates this
limitation.
5. Limited by mechanical problems in the IP60, which prevented paper from being
provided for each print cycle. The IP60 is capable of printing this job at 60 PPM.
6. Limited by switching between simplex and duplex.
Case NP24 IP60 IP4000
328 IBM AS/400 Printing V
F.4.5 Comparison of processor requirements
Processor requirements for printing are summarized in Table 33. The amounts of
processor time used to convert and print each page have been calculated from
the times for the entire file, and then added together to show the total processor
time needed to convert and print each page.
These times are shown in milliseconds of processor time per page. Processor
time to convert these cases is generally larger than the processor time to print,
although there are exceptions. Those applications that use relatively large
amounts of processor time per page to convert may convert slowly (maybe more
slowly than the maximum speed of the printer), especially if the AS/400 processor
is less powerful or is heavily used for other purposes than printing. The
throughput of some applications can be limited by how fast the spooled file
conversion can run, especially with high-speed or large numbers of printers, or
with small or heavily loaded AS/400 systems. This can cause jobs to print more
slowly than expected and continuous forms printers to pause.
Table 33. Processor usage for printing in milliseconds per page: Print with Convert=NO
Case
AS/400 Processor milliseconds per page
Model 519/2144 (measured) Model 640/2237**
IP60 IP4000 IP400
Cvt Prt Tot Cvt Prt Tot Cvt Prt Tot
INVPRE 5.1 17.5 22.6 3.9 21.8 25.6 1.4 7.6 8.9
INVNEW2 7.0 11.1 18.1 - - - - - -
INVNEW2A 5.2 11.3 16.4 3.1 12.5 15.6 1.1 4.4 5.5
INVNEW3 7.5 17.1 24.6 - - - - - -
INVNEW3A 5.4 14.0 19.4 3.6 17.9 21.5 1.3 6.3 7.5
INVSCS 7.6 25.2 32.8 - - - - - -
INVPDEF 14.0 11.5 25.5 - - - - - -
INVPDEFA - - - 2.8 6.4 9.2 1.0 2.2 3.2
SHLFLB 65.8 9.9 75.7 - - - - - -
SHLFLBA 64.5 2.6 67.1 66.2 2.2 68.4 23.1 0.8 23.9
SCS 14.9 1.7 16.6 - - - - - -
SCSA - - - 5.1 0.9 6.1 1.8 0.3 2.1
SCS-PT 10.8 1.2 12.0 - - - - - -
SCS-PTA - - 0 3.5 0.4 3.8 1.2 0.1 1.3
SCS-PDEF 4.9 3.4 8.3 - - - - - -
TXT08K-HPT - - - - - - - --
CMLIM-HPT - - - - - - - --
INVN2-HPT - - - - - - - --
TXT08K 4.3 3.3 7.6 4.2 3.3 7.5 1.5 1.2 2.6
Appendix F. PSF/400 performance results 329
The SHLFLB case, consisting of 30 barcodes per page and nothing else, uses a
significant amount of processor time. Differences in processor time between
INVNEW2 and INVNEW2A, and between INVNEW3 and INVNEW3A, which differ
mostly by inclusion of less than one barcode per page, also support the
conclusion that applications that use BCOCA barcodes heavily require significant
processor time and may not convert at high-speed printer rates.
Image-intensive applications, such as RAST24, RAST50, and CHKSG410, also
use significant amounts of processor time per page, mostly due to the amounts of
data that must be processed. These applications may also convert more slowly
than the maximum speeds of some printers. Using image compression can
minimize this effect.
F.4.6 Predictions of processor utilizations at printing speeds
Calculated processor utilizations for printing at various aggregate rates on two
different AS/400 models are shown in Table 34 on page 330. Model 510/2144 has
a V4R1 CPW rating of 111.5, and Model 640/2238 (a 2-way system) has a V4R1
CPW rating of 583.3 (about 5.2 times as powerful). Using a more powerful system
has the effect of reducing the average processor utilization needed to print a
particular file at a certain rate by the difference in processing power, in this case,
approximated by the difference in CPW ratings of the two AS/400 models. The
utilizations represent the average processor utilization needed to convert and
TXT32K 10.2 7.5 17.7 9.9 5.3 15.3 3.5 1.9 5.3
TXTCMLIM 18.3 25.0 43.4 17.4 23.2 40.5 6.1 8.1 14.2
STMTSHAD 17.0 14.6 31.6 15.3 17.3 32.6 5.3 6.0 11.4
RAST24 39.2 24.6 63.8 40.6 21.6 62.2 14.2 7.5 21.7
RAST50 78.0 45.4 123.4 - - - - - -
CHKSG410 36.8 6.5 43.3 33.3 6.1 39.5 11.6 2.1 13.8
G479BO52 31.6 15.0 46.6 31.3 13.3 44.7 10.9 4.6 15.6
* These particular HPT jobs, which are measured using the default customization
table (this includes the “mapping” option), require large amounts of processor time
to print. This is required for conversion from AFPDS to PCL to allow printing on
PCL printers (on the NP24 in PCL mode, in this case). For comparison, see the
processor time per page for the same jobs printed directly to the NP24 in IPDS
mode (TXT08K, TXTCMLIM, and INVNEW2).
** The processor times per page for the AS/400 Model 640/2237 are not measured
results. They were extrapolated from the Model 510/2144 results using the V4R1
CPW ratings for the two models (111.5 and 319.0) to demonstrate the effect of
using a more powerful processor. Extrapolations to less powerful processors result
in proportionally larger processor milliseconds per page, according to the ratio of
their CPW ratings and the Model 510/2144 CPW rating.
Case
AS/400 Processor milliseconds per page
Model 519/2144 (measured) Model 640/2237**
IP60 IP4000 IP400
Cvt Prt Tot Cvt Prt Tot Cvt Prt Tot
330 IBM AS/400 Printing V
print each application at the maximum speeds of the three printers. As you can
see from previous tables, not all of these applications print on all three printers
(for example, the HPT ones), and some that print on a particular printer do not
print at maximum speed. Furthermore, some that printed at maximum speed
might not on different AS/400 configurations or under different circumstances.
The utilizations represent the theoretical processor loads if each application is
printed at the speeds shown. Where predicted utilizations are high, especially
when over 100%, the application requires more processor power than the AS/400
model shown to print at the desired speed, even with no other loads on the
system.
Note that this does not guarantee the ability to convert and print these
applications at the indicated speeds (on these AS/400 configurations or any
other).
Table 34. Predicted total processor utilization for printing, in percent: Print While Convert=NO
Case
Calculated AS/400 processor utilization
Model 510/2144 Model 640/2238
60PPM 480PPM 960PPM 60PPM 480PPM 960PPM
INVPRE 2.3 18.1 36.2 0.4 3.5 6.9
INVNEW2 1.8 14.8 29.0 0.3 2.8 5.5
INVNEW2A 1.6 13.1 26.3 0.3 2.5 5.0
INVNEW3 2.5 19.7 39.3 0.5 3.8 7.5
INVNEW3A 1.9 15.6 31.1 0.4 3.0 5.9
INVSCS 3.3 26.3 52.5 0.6 5.0 10.0
INVPDEF 2.6 20.4 40.8 0.5 3.9 7.8
INVPDEFA 0.9 7.4 14.8 0.2 1.4 2.8
SHLFLB 7.6 60.6 121.1 1.4 11.6 23.2
SHLFLBA 6.7 53.7 107.4 1.3 10.3 20.5
SCS 1.7 13.3 26.6 0.3 2.5 5.1
SCSA 0.6 4.9 9.8 0.1 0.9 1.9
SCS-PT 1.2 9.7 19.3 0.2 1.8 3.7
SCS-PTA 0.4 3.1 6.1 0.1 0.6 1.2
SCS-PDEF 0.8 6.7 13.3 0.2 1.3 2.5
TXT08K-HPT 12.3 98.7 197.4 2.4 18.9 37.7
CMLIM-HPT 31.0 247.9 495.7 5.9 47.4 94.8
INVN2-HPT 39.9 319.2 638.4 7.6 61.0 122.O
TXT08K 0.8 6.4 12.2 0.1 1.2 2.3
TXT32K 1.8 14.4 28.3 0.3 2.7 5.4
TXTCMLIM 4.3 34.4 69.4 0.8 6.6 13.3
Appendix F. PSF/400 performance results 331
F.4.7 Print While Convert (PWC)=Yes compared to PWC=NO
Most PSF/400 V4R2 measurements were done with PWC=NO for repeatability
and control of the experiments, but PSF/400 Spool File Conversion is normally
done while printing (PWC=YES). Measurements were made to compare
PWC=YES performance to PWC=NO performance using the IP60 printer.
Selected results are compared in Table 35. The general differences are:
• Time to first page is shorter with PWC=YES. This is no surprise, since printing
can start before the entire file is converted.
• Conversion rates are generally a little slower with PWC=YES, but not always
in these measurements (this may reflect on the accuracy of the
measurements). This might also be expected, since the conversion and
printing processes are competing for processor and other resources.
However, this difference is not large in this dedicated environment where other
demands do not exist.
Other consistent differences are not obvious. The total processor time for
converting and printing is generally about the same for both cases.
Table 35. Print While Convert (PWC) YES compared to PWC NO: AS/400 Model 510/2144
STMTSHAD 3.2 25.6 50.6 0.6 4.8 9.7
RAST24 6.4 51.2 102.1 1.2 9.8 19.5
RAST50 12.3 98.4 197.4 2.4 18.9 37.7
CHKSG410 4.3 34.4 69.3 0.8 6.6 13.2
G479BO52 4.7 37.6 74.6 0.9 7.1 14.3
Case
First page times Conversion Average Processor
time
(mins:secs) Rates (PPM) Utilizations per Page
No Yes No Yes No Yes No Yes
INVPRE :26 :27 5,488 3,724 2 2 22.6 20.3
INVNEW2 :35 :32 4,478 4,157 2 2 18.1 17.2
INVNEW3 :32 :38 4,255 3,947 2 2 24.6 19.9
INVSCS :38 :42 4,216 3,871 2 1 32.8 30.1
INVPDEF :32 :41 1,286 1,333 2 2 25.5 25.1
SHLFLB :52 :28 892 799 7 7 75.7 75.2
SCS :27 :27 2,780 2,764 2 2 16.6 19.9
SCS-PT :28 :22 4,260 4,022 1 1 12.0 12.1
SCS-PDEF :33 :30 4,528 4,103 1 1 8.3 8.3
Case
Calculated AS/400 processor utilization
Model 510/2144 Model 640/2238
60PPM 480PPM 960PPM 60PPM 480PPM 960PPM
332 IBM AS/400 Printing V
F.5 Application of results
Some practical conclusions and observations can be made from this information:
• Most of the printing applications used in these measurements, particularly the
native AS/400 applications, are practical on at least one high speed printer
such as the IP4000, given a powerful enough AS/400 system and spare
capacity.
• It is possible to determine the amount of processor power needed to print at a
certain rate (for example, on two IP60 printers at 120 PPM) using the
information in this appendix. Where processors other than the Model
510/2144 are involved, CPW ratings are used to adjust the data to get an
approximate answer.
Where large numbers of printers are involved, and where other key
applications place heavy requirements on the AS/400 system, you must use
more care with this approach.
• Characteristics of applications have large effects on throughput, on the
AS/400 power required to achieve it, on the printer attachment bandwidth
needed, and on a printer's ability to print at its maximum rate.
Some applications, then, may be too demanding to print on high speed or
large numbers of printers, using slow or heavily loaded AS/400 systems.
The processor power needed to convert and print at a given rate depends
almost entirely on application characteristics, and not on the printer. In
particular, these applications may require more of an AS/400 processor than
others, and may be more likely to print at less than the maximum speeds of
some printers.
– Those using significant numbers of barcodes implemented in BCOCA. The
spooled file conversion may use a lot of processor time and run at a slow
rate (PPM). However, BCOCA applications implemented using Page
Definition support in Page Printer Formatting Aid (PPFA) can be much
more efficient than the applications used here, because PPFA produces
BCOCA objects that can require significantly less processing by PSF/400.
TXT08K :31 :33 - 5,439 - 1 7.6 7.6
TXT32K :38 :30 2,365 2,308 2 2 17.7 17.7
TXTCMLIM :42 :37 1,596 1,479 4 4 43.4 42.5
STMTSHAD :45 :37 2,520 2,212 3 3 31.6 28.1
RAST24 1:17 :36 641 605 6 6 63.8 59.5
RAST50 1:39 :35 300 293 11 14 123.4 25.6
CHKSG410 :51 :37 1,243 1,266 4 4 43.3 40.0
G479BO52 :59 :32 874 856 4 5 46.6 46.3
Case
First page times Conversion Average Processor
time
(mins:secs) Rates (PPM) Utilizations per Page
No Yes No Yes No Yes No Yes
Appendix F. PSF/400 performance results 333
– Those using significant amounts of image data, especially if it is not
compressed. The spooled file conversion may use a lot of processor time
and run at a slow rate, and attachment limitations may prevent data from
being delivered to a printer at the rate needed to print at its maximum
speed.
– Those using host print transform to print an AFPDS spooled file on a PCL
printer.
– Those using downloaded fonts on every page with a printer that supports
both downloaded raster and downloaded outline fonts (that is, all “AFCCU”
printers such as the IP60 and IP4000, or any other printer that supports
both the LF1 and LF3 font subsets). Applications that use printer-resident
fonts do not need this additional processing, and a planned improvement to
PSF/400 will reduce processor use for applications that download fonts.
• The spooled file conversion may use much more processor resource than
printing. This can limit printing throughput with combinations of high speed or
large numbers of printers, and with slow or heavily loaded AS/400 systems.
• The data in this appendix can also be adjusted to approximate the effects of
multiple printers, other printers, or other AS/400 models, for example:
– An application, such as INVPDEFA, is expected to need about 11% of a
Model 510/2144 AS/400 system to print at 708 PPM. For the same
application, two 708 PPM printers are expected to need about 22% of the
processor.
– An application, such as the SHLFLB application, which uses about 90% of
the system to print at 708 PPM, is not feasible for two 708 PPM printers (it
is not really feasible for one unless almost the entire processor is available
for printing) on a Model 510/2144 AS/400 system.
– An application, such as the SHLFLB application, if printed on an AS/400
Model 650/2240 (V4R1 CPW rating of 1,794.0), needs only about 5%
utilization of the eight processors in that model instead of almost 90%
utilization on the Model 510/2144 when printing on a single 708 PPM
IP4000.
F.6 Sample output
Figure 237 on page 334 through Figure 252 on page 341 show examples of the
output from the test cases described in this appendix. The quality of these
illustrations is not representative of the high quality output produced from
PSF/400, but is a function of the processes used to produce this publication.
334 IBM AS/400 Printing V
Figure 237. INVPRE
Figure 238. INVNEW2 and INVNEW3
Appendix F. PSF/400 performance results 335
Figure 239. INVNEW2A and INVNEW3A
Figure 240. INVSCS
336 IBM AS/400 Printing V
Figure 241. INVPDEF and INVPDEFA
Figure 242. SHLFLB and SHLFLBA
Appendix F. PSF/400 performance results 337
Figure 243. SCS and SCS-PT
Figure 244. SCSA and SCS-PTA
338 IBM AS/400 Printing V
Figure 245. TXT08K and TXT8K-HPT
Figure 246. TXT32K
Appendix F. PSF/400 performance results 339
Figure 247. TXTCMLIM and CMLIM-HPT
Figure 248. STMTSHAD
340 IBM AS/400 Printing V
Figure 249. RAST24
Figure 250. RAST50
Appendix F. PSF/400 performance results 341
Figure 251. CHKSG410
Figure 252. G479B052
342 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 343
Appendix G. Advanced Print Utility implementation case study
This appendix helps you implement a typical printing solution from start to finish.
The project involves the conversion from pre-printed, continuous forms stationery
to plain, cut-sheet, laser-printed pages. The solution is based on Advanced
Function Presentation and, in particular, the Advanced Print Utility (APU)
program product. In addition to printing enhanced copies of your documents, it
offers the foundation for related activities, such as faxing, viewing, and archiving.
There are several useful references for using APU itself:
• Chapter 2, “Advanced Function Presentation” on page 35
• Advanced Print Utility User’s Guide, S544-5351
• AS/400 Guide to AFP and PSF, S544-5319 (Chapter 12)
In particular, you will find it useful to work through the tutorial in the User’s Guide.
Once you have the basic skills needed, you can adopt some of the hints and tips
described at the end of this chapter.
G.1 Ordering printers
This section provides details of three typical printer configurations:
• Low End: For printing AFP jobs and occasional PC LAN jobs
• Departmental: Ability to print more complex AFP and PC LAN jobs
• Production: Can print complex AFP production jobs plus PC LAN jobs,
segregated by input and output bins
G.1.1 Low-end printer: IBM Network Printer 12
This printer configuration can accept AFP print jobs and seamlessly print PC jobs
from a LAN. If required, it can be expanded with additional paper trays, a duplex
unit, and more memory. See Table 36.
Table 36. IBM Network Printer 12 hardware expansions
G.1.2 Departmental printer: IBM Infoprint 21
This printer is suitable for printing more complex AFP jobs, as well as PC LAN
jobs. The extra paper tray provides flexibility, for example different colored paper
or a pre-printed letterhead. The duplex unit enables duplex printing, for example
Product/feature name Feature code
4312 printer Model 001, 002, 003 depending on country
voltage (120, 220 or 100 V)
IPDS SIMM 4820
Extra 8 Mb memory 4308
Network Interface Card - 1 of:
Token Ring
Ethernet 10BaseT/2
Fast Ethernet 10/100 Base TX
Twinax SCS
4120
4161
4402
4141
344 IBM AS/400 Printing V
printing an AFP overlay of terms and conditions on the back or simply reducing
paper use for PC word-processing documents. See Table 37.
Table 37. IBM Infoprint 21 hardware expansions
G.1.3 AS/400 production printer and PC LAN departmental printer
This configuration provides a fast, well-equipped printer suitable for use as the
main production printer for a small company or one of several departmental
printers in a larger enterprise. The numerous input drawers and output bins
provide great flexibility in paper handling. The hard drive provides a copier-like
“Repro” facility for generating multiple copies of PC jobs without additional printer
processing. See Table 38.
Table 38. AS/400 production printer and PC LAN departmental printer hardware expansions
Product/feature name Feature code
4322 printer Model 001 (low voltage)
Model 002 (high voltage)
IPDS SIMM 4820
Extra 16Mb memory 4316
Network Interface Card - 1 of:
Token Ring
Ethernet 10BaseT/2
Fast Ethernet 10/100 Base TX
Twinax SCS
4120
4161
4162
4141
Duplex Unit 4402
Additional Input Drawer and Tray 4501
Note: The AS/400 print kit that is available, which includes Ethernet and IPDS, is a single
package.
Product/feature name Feature code
4332 printer Model 004 (low voltage)
Model 005 (high voltage)
IPDS SIMM 4820
Extra 32Mb memory 4332
Network Interface Card - 1 or 2 of:
Token Ring
Ethernet 10BaseT/2
Fast Ethernet 10/100 Base TX
Twinax SCS
4120
4161
4162
4141
Duplex Unit 4402
2,500 sheet input unit 4520
2,000 sheet finisher 4620 (low voltage)
4621 (high voltage)
Face-up output tray 4630
Hard Drive 4320
Appendix G. Advanced Print Utility implementation case study 345
G.2 Ordering and obtaining software
The following software is required:
• Print Services Facility/400 (PSF/400)
• IBM AFP PrintSuite for AS/400, Advanced Print Utility feature
• AFP Font Collection
The following software is useful but not essential:
• AFP Utilities/400
• IBM AFP Driver for Windows
• Client Access/400, Operations Navigator feature
Note that ValuPak for AS/400 Printing (5769-PPK) includes the following software
products:
• IBM AFP PrintSuite for AS/400, Advanced Print Utility feature
• IBM AFP PrintSuite for AS/400, PPFA/400 feature
• AFP Font Collection
• AFP Utilities/400
Note: At V4R5, AFP Font Collection is included with new orders of PSF/400.
G.2.1 Checking whether the software is already installed
On an OS/400 command line, type:
DSPSFWRSC
A screen similar to the example shown in Figure 253 appears.
Figure 253. Display Software Resources
Note: The Enhanced Print Kit combines the Ethernet and IPDS features.
G.2.1.1 PSF/400
Page down through the list, and look for an entry similar to the example in Figure
254 (OS/400 V4R4) or Figure 255 on page 346 for releases prior to OS/400
V4R4. Both screens confirm that you have PSF/400 installed.
Display Software Resources
System: DEMO720A
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
346 IBM AS/400 Printing V
Figure 254. PSF/400 installed confirmation screen: OS/400 V4R4
Figure 255. PSF/400 installed confirmation: Releases prior to OS/400 V4R4
G.2.1.2 AFP PrintSuite/400: APU feature
Page down through the list, and look for an entry similar to the example shown in
Figure 256.
Figure 256. APU feature list display
You can also access the main menu by typing the command:
GO QAPU/APU
If you do not see option 8 (Configure APU Monitor Action), you are using the
V3R7M0 (or V3R2M0) product version. Contact your IBM representative to order
the no-charge maintenance upgrade of V3R7M1.
G.2.1.3 AFP Font Collection
You might have noticed AS/400 AFP font products installed on your system in the
above displays. The AFP Font Collection is not installed as a licensed program
product and, therefore, does not show up in these displays. Typically the various
font libraries are installed into libraries such as QFNT300LA1. To check whether
these libraries are present, type:
WRKLIB QFNT*
If the only library displayed is QFNTCPL, this contains the original 240-pel fonts
supplied with OS/400 and is unlikely to be of use. You may also see libraries
QFNT00 to QFNT15 and QFNT61 to QFNT65. These also contain 240-pel fonts.
Assuming you use 300-pel fonts, the only sure way to check for the presence of
these fonts on your system is to type:
WRKFNTRSC FNTRSC(*ALL/*ALL) OBJATR(FNTCHRSET)
From the list of fonts returned, use option 5 (Display attributes) to check the pel
density of the selected font. If you do not have any 300-pel fonts installed, you
need to order the AFP Font Collection.
Resource
ID Option Feature Description
5769SS1 36 5112 OS/400 - PSF/400 1-20 IPM Printer Support
Resource
ID Option Feature Description
5769SS1 17 5102 OS/400 - Print Services Facility
5769SS1 17 2924 OS/400 - Print Services Facility
Resource
ID Option Feature Description
5798AF3 *BASE 5050 AFP PrintSuite for AS/400
5798AF3 *BASE 2924 AFP PrintSuite for AS/400
5798AF3 1 5101 Advanced Print Utility for AS/400
5798AF3 1 2924 Advanced Print Utility for AS/400
Appendix G. Advanced Print Utility implementation case study 347
G.2.1.4 AFP Utilities/400
Use the DSPSFWRSC command again, and look for a screen similar to the
example shown in Figure 257.
Figure 257. AFP Utilities/400 resource display
G.2.1.5 IBM AFP Driver for Windows
From your chosen Windows PC, select Add Printer. Follow the wizard
instructions through the first few screens until the printer manufacturer and model
display appears, which is shown in Figure 258.
Figure 258. Printer manufacturer and model display
If you see the display shown in Figure 258, you have at least one of the IBM AFP
Drivers installed or have the ability to install it.
G.2.1.6 Client Access/400: Operations Navigator feature
Click Start->IBM Client Access. Verify that the AS/400 Operations Navigator
appears in the list of components. You can use either Client Access Express for
Windows or the original Client Access for Windows 95/NT.
For further information about Operations Navigator, refer to the Client Access
documentation and Managing AS/400 V4R4 with Operations Navigator,
SG24-5646.
You may also find outline (resolution-independent) fonts installed (with a pel
density attribute of “OUTLINE”). These are a good choice of font, but you must
ensure your printer is capable of using them. Examples include IBM Infoprint
20, 21, 32, and 40.
Note
Resource
ID Option Feature Description
5769AF1 *BASE 5050 IBM AFP Utilities for AS/400
5769AF1 *BASE 2924 IBM AFP Utilities for AS/400
348 IBM AS/400 Printing V
G.3 Installing the software
All the software may be installed “in-flight” without affecting system operations.
We recomment that you follow this sequence:
1. PSF/400
2. AFP Utilities/400
3. AFP Font Collection
4. Advanced Print Utility
Instructions for installing each software product are included in the “Program
Directory” page shipped with the product. However, a quick guide to the
installation is covered in the following section.
G.3.1 PSF/400
On a command line, type:
GO LICPGM
Select option 11 (Install licensed programs). For V4R3 and earlier versions,
install Option 17 (Print Services Facility/400). For V4R4 and later versions, install
option 36, 37 or 38, depending on which software tier you purchased. See Figure
259.
Figure 259. V4R4 and higher install options
G.3.2 AFP Utilities/400
This product may be on the same CD as the PSF/400 feature. Again, go to the
Install Licensed Programs menu. You will install product 5769-AF1. This may be
at release V4R2 or V4R4.
G.3.3 AFP Font Collection
There is no need to install all the 70 and greater font libraries on the CD or tape
media. The most likely ones you will want to install are listed in Table 39, together
with their name on the CD-ROM and an explanation of what they contain.
See 4.4.1, “Making the fonts available” on page 97, for a font utility that assists in
installing the AFP Font Collection.
Table 39. Commonly installed font libraries
AS/400 font
library name
File name on
CD-ROM media
What they contain When to install
QFNTCDEPAG CDEPAG Code Pages Always
QFNT300CPL 300CPL 300-pel versions of
the standard OS/400
fonts in QFNTCPL
If printing to 300-pel
printers 1 3
Licensed Product
Option Program Option Description
5769SS1 36 OS/400 - PSF/400 1-20 IPM Printer Support
5769SS1 37 OS/400 - PSF/400 1-45 IPM Printer Support
5769SS1 38 OS/400 - PSF/400 Any Speed Printer Support
Appendix G. Advanced Print Utility implementation case study 349
Additional font libraries you may want to install are listed in Table 40. The 240-pel
versions of these libraries are also available.
Table 40. Additional font libraries
QFNT300LA1 300LA1 300-pel Expanded
Core fonts for the
Latin 1 language
group
If printing to 300-pel
printers and using the
Latin1 language group 2
QFNT240LA1 240LA1 240-pel Expanded
Core fonts for the
Latin 1 language
group
If printing to 240-pel
printers 3
QFNTOLNLA1 OLNLA1 Outline fonts for the
Latin 1 language
group
If printing to printers
capable of using
downloaded outline fonts 3
Notes:
1. Or higher-resolution printers emulating 300-pel printers
2. The various language groups and the languages they support are defined in the
Program Directory. Therefore, you might install a different font library, for example
QFNT300LA3.
3. To determine the relevant characteristics of your printer, refer to the table in
Appendix E, “Printer summary” on page 313.
AS/400 font
library name
File name on
CD-ROM media
What they contain What they provide
QFNT300OCR 300OCR 300-pel Optical
Character Recognition
fonts
Support for OCR
characters and additional
monospaced fonts
QFNTOLNOCR OLNOCR Outline Optical
Character Recognition
fonts
Support for OCR
characters and/or
additional monospaced
fonts
QFNT300APL 300APL 300-pel APL
programming language
fonts
Support for APL
characters and/or
additional monospaced
fonts
QFNTOLNAPL OLNAPL Outline APL
programming language
fonts
Support for APL
characters and additional
monospaced fonts
QFNT300BM BM300 300-pel IBM
BookMaster fonts
To provide additional
monospaced fonts
QFNTOLNBM BMOLN Outline IBM
BookMaster fonts
To provide additional
monospaced fonts
QFNT300SYM SYM300 300-pel Symbols fonts To provide additional
scientific, mathematical
and special purpose
characters
AS/400 font
library name
File name on
CD-ROM media
What they contain When to install
350 IBM AS/400 Printing V
G.3.4 Advanced Print Utility
You cannot install this product through the GO LICPGM menu. Instead, use the
following two commands (assuming the media is CD-ROM in a device named
OPT01):
• RSTLICPGM LICPGM(5798AF3) DEV(OPT01) OPTION(*BASE)
• RSTLICPGM LICPGM(5798AF3) DEV(OPT01) OPTION(1)
The most current release of this product is V3R7M1.
G.3.5 Additional steps that may be required
The software is now installed and ready to use. The following steps customize the
software according to your local requirements.
G.3.5.1 Setting the APU defaults
Go to the main APU menu which is accessed by typing:
GO QAPU/APU
While you have a command line present, add any required font libraries to your
library list, for example:
ADDLIBLE QFNTCDEPAG
ADDLIBLE QFNT300LA1
Create libraries for the APU print definitions and AFP resources, for example:
CRTLIB LIB(APUDATA) TEXT(‘APU Print Definitions')
CRTLIB LIB(IMAGES) TEXT(‘AFP Images’)
CRTLIB LIB(OVERLAYS) TEXT(‘AFP Overlays’)
Select option 6 (Set APU Defaults) and fill in the fields as desired. An example is
shown in Figure 260.
QFNTOLNSYM SYMOLN Outline Symbols fonts To provide additional
scientific, mathematical
and special purpose
characters
AS/400 font
library name
File name on
CD-ROM media
What they contain What they provide
Appendix G. Advanced Print Utility implementation case study 351
Figure 260. Set APU Defaults example
G.3.5.2 Program temporary fixes for APU
While you are setting up your APU environment, consider ordering PTF SF62571.
This may be loaded and applied immediately. The PTF fixes several minor APU
problems, including AFP overlay and page segments moving with APU page
margins, and only one SCS spooled file being displayed when selecting a
spooled file for creating print definitions.
G.3.5.3 APU font database synchronization
If for any reason you did not install APU after installing the AFP Font Collection,
the internal fonts database that APU uses will not reflect what is installed on the
system. This situation might also arise if you later add a font library, or add
custom fonts. To re-synchronize the fonts database, type:
CALL QAPU/QYPUSYNC
This may take a few minutes to run. You can run it at any time, but if the fonts are
in use by an application (for example, being applied in an APU print definition) the
program may fail. Wait a few moments, and then call the program again.
G.4 Designing electronic documents
There are many guides to creating printed documents, from typographer’s guides
to magazine articles. While a complete understanding of this extensive skill is not
required, a few simple guidelines will improve the quality and comprehension of
your documents.
First decide whether you are directly replicating your pre-printed stationery, or
completely re-designing it. The former is easier, but this is also an ideal time to
bring your documents up-to-date, so perhaps a combination of the two would be
appropriate. For example you might keep the general look of an invoice, but with
a new company logo. A more radical change would be to move from a landscape
to portrait format. This will make the presentation more consistent, from paper to
fax, for example. Now is a good time to question whether the information you
have on the form really needs to be there, whether it is on the pre-printed form or
printed from the application. You can also cut down on the number of additional
Set APU Defaults
Typechoices,pressEnter.
Unit of measure . . . . *CM *INCH, *CM, *ROWCOL, *UNITS
Decimal point character . . or ,
Font family . . . . . . COURIER LATIN1 Value F4 for List
Color . . . . . . . . . *DEFAULT *DEFAULT, Value F4 for List
Definition library . . APUDATA Name
Code Page . . . . . . . T1V10285 Name F4 for List
Addl. resource libs. . IMAGES Name
OVERLAYS Name
Name
Name
Job description . . . . QYPUJOBD Name
Library . . . . . . . *LIBL Name, *LIBL
352 IBM AS/400 Printing V
copies generated. Conversely, you can determine if an additional, automatic copy
of the document would benefit your organization.
Ideally, choose a single document (such as an invoice) and re-design it, keeping
in mind that a similar document, such as a credit note or purchase order, may
have slightly different fields. Allow space and the correct registration for
addresses, especially if you use window envelopes. White (empty) space does
not necessarily have to be filled and often adds clarity.
If you or another department have a “mock-up” prepared using a Windows
application, remember that this can form the basis for the actual AFP overlay,
using the IBM AFP Driver for Windows. However most users tend to cram too
much detail onto such forms and in particular do not consider registration of
addresses within window envelopes (and concealment of confidential data away
from the window). If the mock-up design does not contain more advanced
features such as curved boxes and lines, you will later find it much easier to map
text using APU if the AFP overlay is constructed using AFP Utilities/400. The
latter method will also construct a much more efficient overlay, in terms of printing
performance.
G.4.1 Which fonts to use
Fonts are a potential area of conflict, between the wishes of the marketing
department and the document ease of creation. Sans serif fonts, such as
Helvetica make bold headings, while a serif font, such as Times New Roman,
provides a more formal look and makes large areas of text easier to read. An
example of the latter might be Terms and Conditions printed as an AFP overlay
on the back of an invoice. Numeric data needs to be in a monospaced font (where
every character is of equal width) so that the figures align. Examples include
Courier, Prestige, Gothic Text, Letter Gothic, and IBM BookMaster.
Using fonts within the IBM AFP Font Collection will pay dividends if and when you
move to alternative means of presentation for example faxing or viewing.
Otherwise, you may need to create an AFP version of your corporate font. If this
exists as a PostScript (Adobe Type 1) font, you can use the IBM Type
Transformer product to create these fonts, in 240, 300, or AFP Outline format.
Remember that you will still need a monospaced font if you have columns of
figures to be aligned. See Chapter 4, “Fonts” on page 89, for more information on
Type Transformer.
A common technique is to construct all static areas of the form (for example, the
overlay) in a typographic font, such as Helvetica and Helvetica Bold. Then map
the variable text using a monospaced font throughout, such as Courier, Letter
Gothic or BookMaster. This helps the recipient identify which data applies to them
and which data is standard text. This is more appropriate for business documents
such as statements, invoices and purchase orders. It is less appropriate for
individual documents such as letters.
G.5 Creating the resources
With the above advice in mind, you can now start to create your company logos,
signatures, electronic forms, and fonts. There are many tools available, but the
ones provided in the ValuPak for AS/400 Printing should be sufficient. Table 41
compares and contrasts the different tools.
Appendix G. Advanced Print Utility implementation case study 353
Table 41. Font creation tools comparison
Note that you may use both tools together: AFP Utilities/400 for the bulk of the
document, with text, shaded boxes and lines, the IBM AFP Driver to create page
Tool Advantages Disadvantages
AFP Utilities/400 • Easy to use, Quick
learning curve
• Call to AFP Viewer
provides WYSIWYG
view of electronic form
• Produces efficient
overlays
• Overlay source
created, stored, and
saved as OS/400
objects on the AS/400
system
• May be used from any
OS/400 5250 session
• Easy to correlate
overlay elements
positioning with that of
the variable text
• PC-sourced and
designed elements,
such as company logos
or signatures may be
created separately but
built into the AFP
Utilities/400 overlay
Only a near-WYSIWYG view
in design mode
IBM AFP Driver for Windows • May be used from any
Windows application
• Permits use of
advanced design
elements, such as
curved lines and boxes,
angled text, corporate
PC fonts, easy access
to clip-art, etc.
• Allows use of PC
word-processor
functions, such as
spell-checking and text
alignment
• Requires setup and
management of the
creation process, for
example shared folder,
AS/400 database file,
and driver installation
• Backup and storage of
the source Windows
documents is a
separate process to be
managed
• May be difficult to
correlate
characteristics of the
overlay with that of the
AS/400 system, for
example lines per inch
• Produces relatively
inefficient AFP
overlays; complex
overlays may print
slowly on smaller
printers
354 IBM AS/400 Printing V
segments of the company logo and signatures, the IBM AFP Driver to create an
overlay of Terms and Conditions. Use the appropriate tool for the appropriate
task!
An additional possibility is to use the “Define boxes” facility within APU itself. This
is a very limited method. There is no WYSIWYG facility at all, nor shaded or
curved boxes. Even lines must be drawn as boxes. However if your form is very
simple, it may be appropriate to use this facility and, therefore, keep all design
elements within APU.
G.6 Building and testing APU print definitions
This step involves mapping the variable text in your spooled files to the new
positions in the electronic form. Before you start, we advise that you collect
several different examples of your spooled files and place them in a special
output queue. One is supplied with APU (QYPUOUTQ in QAPU), but we suggest
you create one in the same library you use for your print definitions, for example:
CRTOUTQ OUTQ(APUDATA/APUTEST)
In addition, create two queues for handling successful and unsuccessful
processing of APU print definitions, for example:
CRTOUTQ OUTQ(APUDATA/APUOK)
CRTOUTQ OUTQ(APUDATA/APUFAIL)
Now you need to locate several sample spooled files that you will use to build
your new documents. Pick a simple one, a complex one, and any that are slightly
different, for example extending to several pages or with different sequences of
data. Store them in the APUTEST queue and ensure they have SAVE=*YES set.
We will refer to these spooled files as the “original SCS spooled files”. It may be
helpful to print them out, but do not worry about the fonts or page rotation. We will
use APU to set these as required.
Follow the APU User’s Guide to set up the basic elements of the print definition. If
you have directly replicated your pre-printed stationery through the AFP overlay,
you may not even need to perform any text mapping (“field mapping”). As a
minimum, we suggest the following settings:
• Print definition name: Same as the spooled file name
• Set print definition attributes: Hard-code the page size (for example, US
Letter 11 by 8.5 inches or A4 size 11.69 x 8.27 inches), the page rotation
(probably 0 or 90), and the margins (set to 0). Set the default font family to a
monospaced font, such as Courier, for now.
Save this print definition. Then in the Define a Copy section, use the following
settings:
• Set page layout options: Leave these options at their default settings for
now, unless you want to name a Back Overlay.
• Define field mapping; Define constants; Define boxes; Define page
segments: Leave these settings at their default settings.
• Define overlays: Name your AFP overlay here.
Appendix G. Advanced Print Utility implementation case study 355
You now have enough set up in APU to print one of your original SCS spooled
files. Refer to “Manually Associating a Print Definition with a Spooled File” in
Chapter 5 of the APU User’s Guide. Fill in the names of the print definition and
the print definition library name (you may be able to select the default settings). In
the Post processing SUCCESS/FAILURE fields, set each of these to *OUTQ, and
name the output queues as APUOK and APUFAIL respectively. On the second
panel, set the output queue name to that of your actual printer output queue (for
example, PRT01).
Now press Enter, and observe the bottom left of your screen. A sequence of
equals signs and asterisks indicates the progress of the Apply Print Definition
process. If a message tells you that the print definition was applied successfully,
go to the output queue for your printer and observe the new AFP spooled file
there. When this is printed, decide which, if any, of your variable text requires
mapping into position and return to the APU Print Definition (Define field
mapping) section.
If the print definition was not successfully applied, check your job log as to the
cause of the failure. The most common causes of failure are:
• The original SCS spooled file was not in a RDY state (for example it was HLD
or SAV)
• The name of your print definition was not found or did not agree with the exact
name of the original SCS spooled file
• You do not have the APU print definition library in your library list
If there was a problem, the original SCS spooled file should have been moved to
the APUFAIL queue. You can move it back to the APUTEST queue, correct the
problem as above, and re-run the test. If successful, the original SCS spooled file
will have been moved to the APUOK queue, and you can again move it back to
the APUTEST queue or simply use the APUOK queue as your source for further
tests. The flowchart in Figure 261 on page 356 shows the possible results of APU
processing.
356 IBM AS/400 Printing V
Figure 261. APU processing flowchart
G.6.1 Other common problems
• Q. I can’t see my sample spooled file on the Select A Sample Spooled File
screen
A. Change the output queue to reflect the one you are working with
(APUTEST for example) or change the User to *ALL, or your current user ID,
or that of the person who produced the sample spooled file. You cannot
change the default output queue or user ID for this screen.
Note: If you can only see one sample spooled file in the list, but you know you
have several in the test queue, this is a bug that can be fixed by using PTF
SF62571.
• Q. The APU process produced an AFP spooled file, which printed with my
remapped text but with no AFP overlays, or printed in the wrong font.
A. Ensure the library containing your AFP resources, fonts, overlays, page
segments, is in your library list
Start
SCS spooled file
Original SCS
spooled file is moved to
the APUOK queue
APU processing
===***___
New AFP spooled file is
produced, sent to the
output queue
Original SCS spooled
file is moved to the
APUFAIL queue
APU processing
OK?
Yes
Yes
Stop
Appendix G. Advanced Print Utility implementation case study 357
• Q. Some of my text was formatted correctly, but some is missing, and there
are random characters on the page.
A. The formatting you created in the “Define field mapping” section does not
exactly match the underlying data. Unmapped data will still be printed. This
unmapped data may be partial elements of your data, therefore the
appearance of “random” characters!
G.6.2 Viewing APU output
You may find it convenient to view your APU-enhanced spooled files while
developing and testing them. It’s also possible for this to be a low-cost means for
users to view output instead of printing it.
To do this, start the Operations Navigator component of Client Access/400 from
your PC. This assumes you have already set up Operations Navigator within
Client Access/400. Select Basic Operations and either Printer Output or
Printers as preferred. These are the equivalents of the AS/400 WRKSPLF and
WRKWTR commands. If you have a lot of spooled files or output queues, you will
improve screen refresh performance by highlighting one of the above choices,
and selecting Options->Include from the menu bar. Specify your preferred
printer and output queues to filter the view. See Figure 262.
Figure 262. Specifying preferred printer and output queues
When you double-click on a spooled file, the AFP Viewer is invoked automatically
and your output may be seen in a WYSIWYG view (see Figure 263 on page 358
for an example). This may save you several trips to the printer and a lot of paper!
358 IBM AS/400 Printing V
Figure 263. AFP Viewer: Spooled file
If you find that the AFP viewer cannot locate the AFP resources, check the
settings of Options->Preferences->More->Resource Path. Ensure that you are
pointing to an appropriate path, for example the network drive on the AS/400
system where the AFP resources were created.
G.7 Automatically starting the APU Monitor
This section provides advice about using the automated process of capturing
SCS spooled files, applying the APU print definitions, and sending the new AFP
spooled files to various destinations.
It is intended that the APU Monitor batch process be started from the main APU
menu (option 4), for example interactively. Many customers prefer that the job be
automatically started along with their other jobs at system startup.
In addition, there is an issue with the APU Monitor that, by default, it runs in
QBATCH as a never-ending job (QYPUMON). If QBATCH has a limit on the
number of active jobs (such as just 1), this will prevent other batch jobs from
starting in QBATCH unless QYPUMON is ended.
There are at least two ways of handling these issues:
• Create an entirely new subsystem, just for the APU Monitor
• Modify QBATCH to allow multiple jobs to run
G.7.1 Creating a separate APU subsystem
The following procedure creates a new subsystem for the APU Monitor. If the
naming convention is followed, this procedure still allows you to view the APU
Monitor status, and to stop and restart it from the main APU menu if required.
1. Create a new subsystem called APUMON by copying the QBATCH subsystem
description:
Appendix G. Advanced Print Utility implementation case study 359
CRTDUPOBJ OBJ(QBATCH) FROMLIB(QSYS) OBJTYPE(*SBSD) NEWOBJ(APUMON)
2. Remove the three default job queue entries from APUMON:
RMVJOBQE SBSD(QSYS/APUMON) JOBQ(QGPL/QBATCH)
RMVJOBQE SBSD(QSYS/APUMON) JOBQ(QGPL/QS36EVOKE)
RMVJOBQE SBSD(QSYS/APUMON) JOBQ(QGPL/QTXTSRCH)
3. Create a job queue called APUMON in QSYS:
CRTJOBQ JOBQ(QSYS/APUMON) TEXT('Job Q for APU Monitor')
4. Add a new job queue entry to the APUMON subsystem:
ADDJOBQE SBSD(QSYS/APUMON) JOBQ(QSYS/APUMON)
5. Make a copy of the APU-supplied job description QYPUJOBD in library QAPU,
place it somewhere convenient such as QSYS:
CRTDUPOBJ OBJ(QYPUJOBD) FROMLIB(QAPU) OBJTYPE(*JOBD) TOLIB(QSYS)
6. Change QSYS/QAPUJOBD to refer to job queue QSYS/APUMON:
CHGJOBD JOBD(QSYS/QYPUJOBD) JOBQ(QSYS/APUMON) PRTDEV(PRT01)
The reference to PRT01 is useful if you know you will always be printing to a
single printer (the system printer) or if you want to define a default printer
device for APU jobs to use.
7. Modify the APU Defaults (option 6 from the main APU menu) to use the
customized job description, for example QSYS/QYPUJOBD. Make sure you
have the required font, code page, and APU print definition libraries in your
library list first. Otherwise, you won’t be able to successfully exit option 6.
8. Test the new subsystem by starting it interactively:
STRSBS(APUMON)
Then start the APU monitor from the main APU menu, option 4. Test with an
SCS spooled file placed on a monitored output queue. It should be picked up,
and a print definition should be applied and printed.
If the SCS spooled file is already on the output queue, it may be necessary to
hold and release it to initiate the process.
9. End the APU monitor by selecting option 5 from the main APU menu, and end
the APUMON subsystem:
ENDSBS SBS(APUMON) OPTION(*IMMED)
10.Test the job to see if it can be started in batch by using the following
command:
STRSBS(APUMON)
SBMJOB CMD(CALL PGM(QAPU/QYPUDQMN) JOB(QYPUMON)
JOBD(QSYS/QYPUJOBD))
11.Test the job again with an SCS spooled file. If it is successful, create a small
CL program with the above two lines of code, and add the program to your
startup procedures.
Note: You could use any JOB name above, but if you use QYPUMON, you can
then check the status of the APU Monitor from the main APU menu using option
3. Also note that you can stop and start the APU Monitor using options 4 and 5.
The above is one method of automating the APU Monitor. It creates a totally
separate subsystem that you can take down or bring up at will without disturbing
360 IBM AS/400 Printing V
any other batch operations. Because it is called APUMON, it is more likely to
appear at the top of the list in WRKACTJOB, which is convenient.
Another method of automating the APU Monitor is to modify QBATCH itself.
G.7.2 Modifying QBATCH to allow multiple jobs to run
You could use either of the following commands:
CHGJOBQE SBSD(QBATCH) JOBQ(QBATCH) MAXACT(n+1)
MAXACT(*NOMAX)
Here, n is the current number of maximum active jobs, and n+1 is simply your
adding an extra job to the MAXACT number.
There are several issues here. One is the performance implication of unlimited
jobs running in QBATCH. Another is that if there is still a limit, QYPUMON may
still be unable to run or may prevent another job from running.
If you continue with this procedure, you must add the CL command (CALL
PGM(QAPU/QYPUDQMN) from the procedure above to your startup CL
programs. Instead of starting a separate APUMON subsystem though, you need
an instruction that says, “Whenever the QSPL subsystem starts, I want
QYPUMON to start as well”. This is called an auto-start job entry. Use a
command similar to:
ADDAJE SBSD(QSPL) JOB(QYPUMON) JOBD(QAPU/QYPUJOBD)
G.8 Using APU for production printing
Only when you have created some working APU print definitions and started to
have them automatically applied through the APU Monitor, you will see how
powerful the APU batch process is. This section describes case studies where
various elements of AFP and APU have been exploited to meet real customer
requirements.
G.8.1 Using APU Monitor Actions
An APU Monitor Action is a single or repeated application of your APU print
definition to an SCS spooled file. You might use this process to:
• Produce two copies of an AFP spooled file, sent to two or more different
printers, perhaps in different locations
• Perform some other form of output, for example to fax the AFP spooled file or
send it to an archival system, as well as printing it
• Store a copy of the AFP spooled file on an output queue for reprinting in case
the output becomes damaged or spoiled
• Route a non-AFP spooled file to a different printer or location
The above list largely assumes you are generating multiple identical copies of the
AFP spooled file. There is no reason why the AFP spooled files should not differ
slightly. The following section describes how to setup the different APU Monitor
Actions to realize the sample requirements presented previously.
Appendix G. Advanced Print Utility implementation case study 361
G.8.1.1 Sending an AFP spooled file to multiple destinations
Let’s suppose you want to print a formatted AFP report in two different locations.
The data in the report is identical in all respects. You want to print the address of
the receiving location at the top of the report. Obviously, this address will be
different. Traditionally, the printers would have been loaded with pre-printed
headed stationery to achieve this. Let’s assume you created an electronic overlay
of just the address, called ADDRESS. You store this in a location-specific library,
for example LONDON. The overlay for the second location is also called
ADDRESS, but stored in a library called DUBLIN.
The APU print definition is common to both locations, so you store that in your
general-purpose library (for example APUDATA, along with any other
general-purpose overlays: with lines, boxes, and shading for example).
Finally, you add the libraries to the PSF configuration objects for the location
printers. LONDPRT1 has libraries APUDATA and LONDON, and DUBPRT1 has
libraries APUDATA and DUBLIN.
The APU Monitor action looks like the display shown in Figure 264.
Figure 264. APU Monitor action display
The settings on the next page can be changed as required. Now press F15 (Next
Action), and repeat the above settings except for the following two parameters:
Run option . . ......... *REPRINT *NORMAL, *NOCOPY, *REPRINT
Output queue . ......... DUBPRT1 Name, *DEV, *SPOOLFILE
Note the use of the *REPRINT run option. This is very important from an AS/400
performance point of view. Since you have already created the AFP spooled file,
there is no need to go through the processing of it again. Simply send it to the
remote printer. The AFP spooled file is already “tagged” with a reference to use
the Dublin address overlay. This is found in the printer’s Device Resource library
list in the PSF configuration object.
Define action for output spooled file
Sequence . . . . . . : 100
Text . . . . . . . . : Send report to LONDON printer
Action . . . . . . . : 1 / 1
Panel . . . . . . . . : 1 / 2
Type choices, press Enter.
User exit before . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Print Definition . . . *SPOOLFILE Name, *SPOOLFILE, *NONE
Library . . . . . . . *PRTDEFLIB Name, *PRTDEFLIB, *LIBL
Run option . . . . . *NORMAL *NORMAL, *NOCOPY, *REPRINT
User exit middle . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Output device . . . . . *JOB Name, *JOB
Output queue . . . . . LONDPRT1 Name, *DEV, *SPOOLFILE
Library . . . . . . . *LIBL Name, *LIBL
More...
F12=Cancel F15=Next action
362 IBM AS/400 Printing V
The above approach also has benefits in maintaining the forms. If and when the
location telephone or fax number changes, you simply make one small change to
one overlay object. No other important parts of the print production are affected.
Conversely, if the company decides on a change to the font or lines/boxes on the
Invoice overlay, the main Invoice overlay can be changed, and the updated result
will be in immediate effect at all locations, local and remote.
G.8.1.2 Sending (slightly different) AFP spooled files to multiple
destinations
You should be able to see that the above example may easily be extended to
placing the AFP spooled file copies on output queues that actually point to other
devices, such as a fax output queue or an output queue monitored by an
archiving process.
You could enhance the process slightly and request that the faxed AFP spooled
file contains a fax message along the lines of “This is your faxed copy; a printed
confirmation will be with you in 24 hours”. We can easily generate an overlay to
convey this message. However, the addition of this overlay is no longer
location-specific (London/Dublin), but action-specific (print and fax? or just
print?).
Let’s assume that to generate a combined faxed/printed document, the
application places the SCS spooled file on a specific output queue, called
FAXPRINT (this could also be a manual process). You have a print definition
called INVOICE, in library APUDATA. You also have a copy of this print definition,
called INVOICEF, which is the same print definition but with the “Fax Message”
overlay described above included in all the page formats. There are two keys to
make this work. First, you monitor the FAXPRINT output queue in Define
Selection for Input Spooled File. Second, having made a successful selection,
you have two APU Monitor actions as before, in Define Action for Output Spooled
File. The difference this time is that, as well as different printer output queues
(one of them being the fax queue LONDFAX), the second APU Monitor Action
specifies a different print definition name as shown in Figure 265 through Figure
267.
Figure 265. APU Monitor Action: Specifying a different print definition
Define selection for input spooled file
Sequence . . . . . . : 110
Text . . . . . . . . : Send report to LONDON fax queue & printer
Type choices, press Enter.
File . . . . . . . . . *ALL Name, Generic*, *ALL
Output queue . . . . . FAXPRINT Name, Generic*, *ALL
Library . . . . . . . *LIBL Name, *LIBL
User . . . . . . . . . *ALL User, Generic*, *ALL
User Data . . . . . . . *ALL User Data, Generic*, *ALL
Form Type . . . . . . . *ALL Form Type, Generic*, *ALL
Program . . . . . . . . *ALL Name, Generic*, *ALL
Library . . . . . . . Name, *LIBL
Appendix G. Advanced Print Utility implementation case study 363
Figure 266. Define action for output spooled file (Part 1 of 2)
Figure 267. Define action for output spooled file (Part 2 of 2)
Note the different Run option. The *NOCOPY name is a little misleading. The “no
copy” refers to the internal process of copying the original SCS spooled file and,
in this case, no internal copy is required. What actually happens is that only some
re-processing is necessary, for example the application of a different print
definition.
Define action for output spooled file
Sequence . . . . . . : 110
Text . . . . . . . . : Send report to LONDON fax queue & printer
Action . . . . . . . : 1 / 1
Panel . . . . . . . . : 1 / 2
Type choices, press Enter.
User exit before . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Print Definition . . . *SPOOLFILE Name, *SPOOLFILE, *NONE
Library . . . . . . . *PRTDEFLIB Name, *PRTDEFLIB, *LIBL
Run option . . . . . *NORMAL *NORMAL, *NOCOPY, *REPRINT
User exit middle . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Output device . . . . . *JOB Name, *JOB
Output queue . . . . . LONDPRT1 Name, *DEV, *SPOOLFILE
Library . . . . . . . *LIBL Name, *LIBL
More...
F12=Cancel F15=Next action
Define action for output spooled file
Sequence . . . . . . : 110
Text . . . . . . . . : Send report to LONDON fax queue & printer
Action . . . . . . . : 2/2
Panel . . . . . . . . : 1 / 2
Type choices, press Enter.
User exit before . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Print Definition . . . INVOICEF Name, *SPOOLFILE, *NONE
Library . . . . . . . *PRTDEFLIB Name, *PRTDEFLIB, *LIBL
Run option . . . . . *NOCOPY *NORMAL, *NOCOPY,*REPRINT
User exit middle . . . *NONE Name, *NONE
Library . . . . . . . Name, *LIBL
User parameter . . . Value
Output device . . . . . *JOB Name, *JOB
Output queue . . . . . LONDFAX Name, *DEV, *SPOOLFILE
Library . . . . . . . *LIBL Name, *LIBL
More...
F12=Cancel F14=Previous action F15=Next action
364 IBM AS/400 Printing V
For a summary, see Table 42.
Table 42. APU action and Run option summary
G.8.1.3 Saving a copy of the AFP spooled file
You may decide to keep a copy of the AFP spooled file for 24 hours to guard
against the printed documents being spoilt (for example being torn in a mailing
machine). You could keep a copy of the original SCS spooled file, but you would
then have to go through the APU processing again. To do this, simply create
additional output queues, for example LONDPRT1S (“S” for “save”). Name this
queue in the last APU Monitor Action, with a Run option of *REPRINT and Save
*YES. You could devise a manual or automatic process for clearing down the
output queue daily, using the CLROUTQ command.
G.8.1.4 Routing non-AFP spooled files through APU
As a bonus, the APU Monitor Actions provide a reasonable method of spooled file
re-routing. Suppose there is the possibility that users might send spooled files
ineligible for AFP processing to the printer, for example a screen print. You need
to handle these cases (referred to as a “drop-through” because the spooled file
does not meet any of the APU Monitor Action criteria and “drops through” the list
of actions to the end).
To do this, add an action entry near the end of the list to capture these cases. It is
likely that the spooled file name or the output queue will be generic, with use of
the “*” wildcard. On the third Action Entry (Define Action for Output Spooled File),
the print definition name is set as *NONE. That is, no APU print definition will be
applied, and no AFP spooled file will be created. The re-routing is done in the
second Action Entry (Define action for input spooled file). In the Success field,
enter the name of the desired target output queue. See Figure 268 for an
example.
Figure 268. Define action for input spooled file: Success field
If you have: Use Run option:
Only one APU Monitor Action *NORMAL
Second, or subsequent Action, same print
definition
*REPRINT
Second, or subsequent Action, different print
definitions
*NOCOPY
Define action for input spooled file
Sequence . . . . . . : 900
Text . . . . . . . . : Drop through for screen prints
Type choices for input spooled file after successful
or failed processing respectively, press Enter.
Success . . . . . . . . *OUTQ *NONE, *HOLD, *DELETE, *OUTQ
Output queue . . . . QPRINT Name
Library . . . . . . *LIBL Name, *LIBL
Failure . . . . . . . . *HOLD *NONE, *HOLD, *DELETE, *OUTQ
Output queue . . . . Name
Library . . . . . . Name, *LIBL
Appendix G. Advanced Print Utility implementation case study 365
G.9 Documentation
It is important to define a good naming convention for all your AFP resources,
print definitions, libraries, and so on, from the beginning. Remember that OS/400
is much more limited in its names than Windows. For example, an overlay name
is restricted to eight characters.
G.9.1 Documenting APU component names
Items that you should record include:
• APU Defaults (option 6 from the main APU menu)
• APU Print Definition names and libraries
Page Format names and copy names
• APU Print Definition Attributes
• AFP resource names and libraries:
– Overlays
– Page segments
– Fonts
– Page segments and fonts used within an overlay
• Source document names and location if not on the AS/400 system
• APU Print Definition page format selection rules
• APU Monitor Action Entries
• Any special notes about the application
A working spreadsheet is very useful to have alongside you while creating the
documents. It then becomes a valuable documentation source for the completed
project. See Table 43 for an example.
Table 43. Working spreadsheet example
The example in Table 43 shows only a suggestion for the column headings. For
example, if you were also using AFP Utilities/400 to create the overlays, you
might have a column to indicate their names and locations. The example also
shows another column for any page segments used within the AFP Utilities
overlays.
IBM AFP Naming Conventions - London
Spool
File
Number
Print
Definition
Name
APU
Page
Formats
APU
Copies
Overlays AS/400
Library
APU
Monitor
Steps
WinNT Path for source
overlay documents
Notes
LONDON INVOICES
INV694000 INV694000 INVFIRST CLIENT INVFIRST APUDATA 10 N:\AFP\INVOICE\INVFIRST.DOC Picked from Bin 1 (plain paper)
INVBAC N:\AFP\INVOICE\INVBAC.DOC INVBAC prints on reverse side
OFFICE INVFIRST Picked from Bin 2 (yellow paper, pre-punched)
OFFICE N:\AFP\INVOICE\OFFICE.DOC OFFICE overlay prints on front side
INVANY CLIENT INVANY N:\AFP\INVOICE\INVANY.DOC Picked from Bin 1 (plain paper)
INVBAC INVBAC prints on reverse side
OFFICE INVANY Picked from Bin 2 (yellow paper, pre-punched)
OFFICE OFFICE overlay prints on front side
366 IBM AS/400 Printing V
A separate page in the spreadsheet could record the APU Monitor Action steps.
See Table 44 for an example.
Table 44. Spreadsheet recording APU Monitor Action steps
Such spreadsheets are valuable only if they are kept up-to-date! Much of the
required information may be printed directly from APU, using option 5 (Display
contents) or option 6 (Print contents) from the Work with Print Definitions menu in
APU. Note that option 6 may generate many pages. It is usually better to copy
and paste the required information into a spreadsheet or other PC document.
G.9.2 Where APU print components are stored
For the purposes of backup or transfer to another system, Table 45 records how
and where the main APU components are stored on the AS/400 system.
Table 45. APU component storage information
IBM AFP APU Monitor Actions
Action Action Selection for Input Spooled File Action for Input Spooled File Action #1 for Output Spooled File
No. Name SPLF name OUTQ USER Success OUTQ Failure OUTQ Print Definition Run opt Device OUTQ Hold Save Outbin
10 London Invoices INV694000 PRT01A *ALL *HOLD n/a *OUTQ APUFAIL APUDATA\INV694000 *NORMAL PRT01 PRT01 *NO *YES *DEVD
APU
component
OS/400 object
type
Object
attribute
Object name Library
APU print
definition
*USRSPC APUPRTDEF User-defined User-defined
APU Monitor
Action Rules
*FILE PF QAYPUMA0 QUSRSYS
APU fonts
database
*FILE PF QAYPUFN0 QUSRSYS
© Copyright IBM Corp. 2000 367
Appendix H. AS/400 to AIX printing
There are a number of ways of sending AS/400 spooled files to an Infoprint
Manager for AIX server. Each one has different advantages depending on a
variety of considerations, such as the data stream type of the spooled file and the
supported target printer, number and diversity of applications and printers,
customer preference, and available programming skills.
This appendix attempts to provide guidelines to the different approaches, when
they could be used, and additional tips. This appendix has been written from the
view point of an AS/400 user, and assumes that an Infoprint Manager for AIX
specialist is available.
H.1 TCP/IP versus SNA
There are basically two diverse ways of using Infoprint Manager for AIX as a
server for AS/400 printing. Sending files to the server over TCP/IP allows you to
take advantage of many of the features of Infoprint Manager for AIX to manage
your output, such as queue management, printer pooling, and sharing printers
with other clients. PSF Direct, over an SNA connection, allows the AS/400
system to use the Infoprint Manager for AIX connected printer as if it were
attached to the AS/400 system directly.
H.1.1 Sending spooled files using TCP/IP
The TCP/IP command to send a spooled file from the AS/400 system to Infoprint
Manager for AIX is LPR. The AS/400 system has an alias for LPR, which is
SNDTCPSPLF. These two commands are equivalent. You can use either
command directly on the command line or in a CL program, or indirectly by
setting up a remote output queue.
H.1.1.1 Remote Output Queue
Figure 269 on page 368 shows an example of creating a Remote Output Queue.
In this particular example, all spooled files are of DEVTYPE(*AFPDS). No
transformation needs to happen to these types of files.
368 IBM AS/400 Printing V
Figure 269. Remote Output Queue creation example
The parameter descriptions shown in Figure 269 are explained here:
• OUTQ: Give the output queue on the AS/400 system a meaningful name that
corresponds to the destination on the Infoprint Manager for AIX system.
• RMTSYS: Remote System. This is the system name of the Infoprint Manager
for AIX server. Enter the actual name here, and then add the AIX system’s
host name to the AS/400 host table using the AS/400 CFGTCP option 10.
Alternately, you can enter the value *INTNETADR, and then use the
INTNETADR field to specify the address directly. If the name is in lower case,
enclose it between single quotes.
• RMTPRTQ: Remote Printer Queue. This corresponds to the Infoprint Manager
for AIX Logical Destination (not the Infoprint Manager for AIX queue). If the
name contains lower case, enclose it between single quotes.
Create Output Queue (CRTOUTQ)
Output queue . . . . . . . . . . OUTQ > IP60AIX
Library . . . . . . . . . . . > QUSRSYS
Maximum spooled file size: MAXPAGES
Number of pages . . . . . . . *NONE
Starting time . . . . . . . .
Ending time . . . . . . . . .
+ for more values
Order of files on queue . . . . SEQ *FIFO
Remote system . . . . . . . . . RMTSYS > 'INFOPRNT'
Remote printer queue . . . . . . RMTPRTQ > 'IP60-l'
Writers to autostart . . . . . . AUTOSTRWTR > 1
Queue for writer messages . . . MSGQ QSYSOPR
Library . . . . . . . . . . . *LIBL
Connection type . . . . . . . . CNNTYPE > *IP
Destination type . . . . . . . . DESTTYPE > *OTHER
Host print transform . . . . . . TRANSFORM > *NO
Manufacturer type and model . . MFRTYPMDL *IBM42011
Workstation customizing object WSCST *NONE
Library . . . . . . . . . . .
Image configuration . . . . . . IMGCFG *NONE
Internet address . . . . . . . . INTNETADR >
Destination options . . . . . . DESTOPT > '-odatat=afpds'
Print separator page . . . . . . SEPPAGE *YES
User defined option . . . . . . USRDFNOPT *NONE
User defined object: USRDFNOBJ
Object . . . . . . . . . . . . *NONE
Library . . . . . . . . . .
Object type . . . . . . . . .
User driver program . . . . . . USRDRVPGM *NONE
Library . . . . . . . . . . .
Spooled file ASP . . . . . . . . SPLFASP *SYSTEM
Text 'description' . . . . . . . TEXT > 'OutQ to send AFPDS to IP60
attached to IPM for AIX'
Display any file . . . . . . . . DSPDTA *NO
Job separators . . . . . . . . . JOBSEP 0
More
Operator controlled . . . . . . OPRCTL *YES
Data queue . . . . . . . . . . . DTAQ *NONE
Library . . . . . . . . . . .
Authority to check . . . . . . . AUTCHK *OWNER
Authority . . . . . . . . . . . AUT *USE
Appendix H. AS/400 to AIX printing 369
• CNNTYPE: Connection Type. Must be specified as *IP.
• DESTTYP: Destination Type. Must be specified as *OTHER.
• TRANSFORM: Host print transform. This parameter determines whether the
AS/400 spooled file is sent as is or is translated to ASCII. For example,
*AFPDS spooled files are not transformed. Spooled files that are *SCS will
need to be transformed. This will be discussed further in H.2, “AS/400 spooled
file data streams” on page 372.
• MFRTYPMDL: Manufacturer Type and Model. If you specify
TRANSFORM(*YES), use this parameter to specify how the transform is to
take place. If you are using an IBM supplied transformation, you would enter
the name here, such as *IBM4332 or *HP5SI. If you create a Workstation
Customization Object, enter the value *WSCST here, and use the next
parameter to name the object and its library.
• WSCST: Workstation Customizing Object. Use this entry to name your own
Workstation Customization Object.
• DESTOPT: Destination Options. This parameter allows you to specify some of
the processing options to Infoprint Manager for AIX. Enclose the options in
single quotes. Details on using the DESTOPT are in H.4.4, “Destination
Options” on page 381.
All files that arrive in this queue will be sent to the same Infoprint Manager for AIX
Logical Destination and will have the same Destination Options. This method can
be used when you have a limited number of destinations with a limited variety in
how each file will be handled.
H.1.1.2 SNDTCPSPLF command (LPR)
For greater flexibility in how each file is handled, use the SNDTCPSPLF
command and specify the Remote Printer Queue, Destination Options and other
parameters as appropriate. Section H.3.3, “Output queue monitor” on page 377,
covers how to build a monitor application to automate the selecting of spooled
files and setting the parameters for the SNDTCPSPLF command.
Figure 270 on page 370 shows an example of the SNDTCPSPLF command. In
this particular example, the spooled file to be sent is DEVTYPE(*SCS). It will be
transformed to “flat ASCII” using host print transform and a custom Workstation
Customization Object. See H.4.1, “Processing line AS/400 SCS files as ‘flat
ASCII’” on page 378, for more information on processing “flat ASCII”. The
destination options name the form definition to be used and a file on the AIX
system that contains additional processing instructions.
370 IBM AS/400 Printing V
Figure 270. SNDTCPSPLF or LPR command screen
Using RMTSYS, RMTPRTQ, DESTTYP, TRANSFORM, MFRTYPMDL, WSCST,
and DESTOPT is the same as using the remote output queue described in
H.1.1.1, “Remote Output Queue” on page 367.
• FILE: Spooled file. The name of the spooled file to send.
• JOB: Job name/user/number. Specify the three components of the Job
identifier. In an interactive environment, these values can be retrieved from
the WRKSPLF or WRKOUTQ panels and either pressing F11 to see the
appropriate view or entering an 8 to view the spooled file attributes. For an
automated batch process, see H.3.3, “Output queue monitor” on page 377, for
a discussion on the DTAQ (Data Queue) parameter in an Output Queue
Description.
• SPLNBR: Spooled file number. If there is only one spooled file of a given
name in the Job, you can specify *ONLY. Otherwise, specify the exact number
or *LAST.
H.1.2 PSF Direct
PSF Direct provides a direct-print connection between an MVS, VSE, VM, or
AS/400 system and a printer defined to IBM Infoprint Manager for AIX. PSF
Direct gives you control of key print processes from your AS/400 system. An
Infoprint actual destination appears to be directly attached to your AS/400
system. Jobs print without delay because they are not spooled by the Infoprint
Manager server. Because the AS/400 controls the print process, it returns
job-completion and error messages to the AS/400 systems operator.
To use PSF Direct, you need the IBM Communications Server for AIX to
communicate between the AS/400 system and AIX. You create printer and APPC
definitions on the AS/400 system so that print jobs can be directed to the Infoprint
Manager for AIX printer. All spooled data on the AS/400 system is converted to
IPDS before being sent to the server.
Send TCP/IP Spooled File (SNDTCPSPLF)
or
Send TCP/IP Spooled File (LPR)
Remote system . . . . . . . . . RMTSYS 'INFOPRNT'
Printer queue . . . . . . . . . PRTQ 'IP60-l'
Spooled file . . . . . . . . . . FILE QSYSPRT
Job name . . . . . . . . . . . . JOB DSP01
User . . . . . . . . . . . . . MIRA
Number . . . . . . . . . . . . 013140
Spooled file number . . . . . . SPLNBR *ONLY
Destination type . . . . . . . . DESTTYP *OTHER
Transform SCS to ASCII . . . . . TRANSFORM *YES
User data transform . . . . . . USRDTATFM *NONE
Library . . . . . . . . . . .
Manufacturer type and model . . MFRTYPMDL *WSCST
Internet address . . . . . . . . INTNETADR
Workstation customizing object WSCST FLATASCII
Library . . . . . . . . . . . QUSRSYS
Delete file after sending . . . DLTSPLF *NO
Destination-dependent options . DESTOPT '-of=F1STD -odatat=line
-oparmdd=/u/afpres/parmstd132'
Print separator page . . . . . . SEPPAGE *YES
Appendix H. AS/400 to AIX printing 371
The printer is defined to IBM Infoprint Control on AIX. A host receiver on AIX
passes the IPDS from the AS/400 system to a secondary print process,
depending on the connection type and data stream of the destination printer. If
the target printer uses the PCL or PPDS data streams, this process will perform
the appropriate translation.
After PSF Direct is configured, users or applications can use normal print
submission processes to send AS/400 spooled files to the Output Queue
corresponding to the PSF Direct printer. PSF/400 automatically directs the output
to the PSF Direct server.
Only one host can print to a given device at a time using a PSF Direct. The
session needs to be ended or released before you can use the printer for a PSF
Direct session from another mainframe or from IBM Infoprint Control. On the
AS/400 system, you can use the timer values in the PSF Configuration Object to
automatically release the writer from one system so another can use the printer.
See the appropriate version of AS/400e Printer Device Programming, for more
details on sharing IPDS printers. Other PSF hosts have similar timers. See the
documentation for each product respectively.
The differences between PSF Direct, using SNA, and printing over TCP/IP are
illustrated in Table 46.
Table 46. Differences between PSF Direct, using SNA, and printing over TCP/IP
Function TCP/IP printing to
Infoprint Manager for AIX
PSF Direct
Resources Must reside on the Infoprint
Manager for AIX server.
Reside on AS/400
AS/400 Spooled file types
supported.
*SCS (using HPT), *AFPDS,
*USERASCII
*SCS, *IPDS, *AFPDS,
*LINE, *AFPDSLINE
Output Printer Data Streams
supported
Any data stream supported
by Infoprint Manager for AIX:
IPDS, PCL, PPDS,
PostScript (PostScript would
only work if it is generated by
a user program as a
*USERASCII spooled file.)
IPDS, PPDS, PCL4, PCL5,
PCL5c
Sharing Multiple systems may send
output to the same printer at
the same time. Infoprint
Manager for AIX will print
according to queue
definitions.
Only one Host may print to
the printer at one time.
Sharing can be set up on a
time-out basis using
PSFCFG.
Data Stream Conversions *SCS to “flat ASCII” or PCL
is done using HPT on the
AS/400 system. This must
be explicitly defined in the
Remote Output Queue or
the SNDTCPSPLF
command. All other
conversions are done on
Infoprint Manager for AIX.
All file types are
automatically converted to
IPDS by PSF/400 before
being sent to the Infoprint
Manager server.
372 IBM AS/400 Printing V
You may want to consider PSF Direct if you do not need dynamic switching
between hosts. For example, you print AS/400 “batch” jobs at night using PSF
Direct, and during the day, the printer is used by other users. PSF Direct allows
you to send *SCS spooled files without conversion to ASCII, and *LINE or
*AFPDSLINE, which would not work at all over TCP/IP.
There is currently no single document that offers specific setup instructions for
using PSF Direct for AIX with an AS/400 system. The IBM Infoprint Manager for
AIX PSF Direct Network Configuration Guide for System/370, S544-5486 has
information on configuration SNA and the Host Receiver on the AIX system. For
the AS/400 system, refer to the configuration samples for SNA printing to PSF/2
in the IBM AS/400 Printing III, GG24-4028. Additional information on the AS/400
configuration for PSF Direct can also be found in the IBM Infoprint Manager for
Windows NT.
The PSF Direct: AS/400 Configuration manual written for Infoprint Manager for
Windows NT. This manual can be found online at:
http://www.printers.ibm.com/R5Psc.nsf/web/ntpsfd
H.2 AS/400 spooled file data streams
The following sections describe the different data streams that can be created as
AS/400 spooled files. They also explain how they can be sent to and printed on
an Infoprint Manager for AIX server.
H.2.1 *SCS
The default data stream on the AS/400 system is known as SNA Character
Stream (SCS). This is an EBCDIC data stream with a minimum of control
characters for setting LPI and CPI, for example. This is the data stream
generated by system applications such as screen prints, compile listings, job
logs, or queries. Many packages from AS/400 software vendors generate SCS.
Infoprint Manager for AIX does not support processing SCS spooled files. You
would have to perform one of the following actions to handle them:
PSF/400 required PSF/400 is not required if all
AFP printing is done at the
server.
Yes
Queue Management Infoprint Manager for AIX
panels or Java GUIs.
Done using AS/400
commands.
Message handling (for
example, a paper jam)
Infoprint Manager for AIX
panels or Java GUIs; can
interface with Network
Printer Manager tool for
supported printers
Messages are sent to
AS/400 Systems Operator
Communication protocol
between AS/400 and
Infoprint Manager for AIX.
TCP/IP SNA LU6.2 (printer may be
connected to Infoprint
Manager for AIX using
TCP/IP, Channel, or parallel)
Function TCP/IP printing to
Infoprint Manager for AIX
PSF Direct
Appendix H. AS/400 to AIX printing 373
• Convert the application to generate *AFPDS.
• Convert the SCS spooled files to “flat ASCII” and then apply a form definition
and page definition to format the data.
• Convert the SCS spooled file to PCL.
• Use PSF Direct.
H.2.1.1 Converting to *AFPDS
If you have access to the original application or the printer file for the application,
you can change or override the printer files to generate *AFPDS spooled files,
which are supported on Infoprint Manager for AIX.
Another option is Advanced Print Utility (APU), a part of PrintSuite for AS/400.
APU is designed to re-engineer simple SCS output into sophisticated fully
graphical AFP pages. It could be used to convert AS/400 *SCS spooled files to
*AFPDS without needing to change the original application.
H.2.1.2 Converting to ‘flat ASCII’ and add form and page definitions
You can use host print transform with a default Workstation Customization object
to send *SCS files as “flat ASCII” to Infoprint Manager for AIX. The instructions
on how to create the *WSCST are explained in H.4.1.1, “WSCST for ‘flat ASCII’”
on page 378. The EBCDIC characters are converted to ASCII, and all control
codes are removed except Carriage Return, Line Feed, and New Page. This
works best if the applications were generated using Program Defined Printer
Files. Externally Defined Printer Files work, but you will lose any controls such as
LPI or CPI changes.
To print this file correctly on Infoprint Manager for AIX, the data will have to be
matched up with the appropriate form definition and page definition. This can be
done using Default Documents on the Infoprint Manager for AIX side, or using the
Destination Options of the SNDTCPSPLF Command or Remote Output Queue on
the AS/400 system. These alternatives are described in greater detail in the
following section.
H.2.1.3 Converting to PCL
In your Remote Output Queue or SNDTCPSPLF command, you can indicate that
PCL is to be generated by specifying a Manufacturer Type and Model, such as
*IBM4332. This is probably the easiest from a programming point of view, and is
most appropriate if the target printer is a PCL printer. If that is the case, you may
even choose to print these file to the PCL printer without any additional
conversions on Infoprint Manager for AIX. Along with the usual restrictions of host
print transform there are other points to consider:
• If the application references printer resident fonts, a font mapping is done,
which may or may not match your original document.
• If the spooled file references the front or back overlay, they will not be
included. One overlay per document can be added back in using the
Destination Options. See H.4.4.2, “Overlays with the SCS file” on page 381.
• Some users are not satisfied with the results of PAGRTT(*COR) or (*AUTO)
when using host print transform, because it defaults to 15 cpi instead of 13 cpi.
• If the target printer is ultimately an IPDS printer, this method means you will be
translating the spooled file twice, with more chances of fidelity being lost.
374 IBM AS/400 Printing V
• User exit programming may be required on Infoprint Manager for AIX to
support multiple drawer selections in PCL.
• Finally, the PCL data stream generated is likely to take much more bandwidth
than the corresponding AFPDS or “flat ASCII” file generated using the other
two methods listed above.
H.2.1.4 PSF Direct
*SCS spooled files can be sent to an Infoprint Manager for AIX printer using PSF
Direct. The spooled files are translated to IPDS by PSF/400.
H.2.2 OV/400 and Final Form Text
Extensions to the SCS data stream, called Final Form Text Document Content
Architecture, are used in generating the output of Office Vision/400 (OV/400).
There are more controls supported, such as for font selection, line justification,
and the ability to include IOCA images. These files cannot be sent “as is” to
Infoprint Manager for AIX over TCP/IP. If the file is converted to “flat ASCII”, all
formatting controls will be lost. Unless they were extremely predictable, the
document cannot likely be recreated using page and form definitions.
One option is to convert OV/400-generated spooled files to PCL. The same
restrictions described under *SCS apply.
OV/400 documents can be printed on Infoprint Manager for AIX using PSF Direct.
Note: Support for OV/400 will end in May 2001.
H.2.3 *AFPDS
AFPDS can be generated in a number of ways, including:
• The printer file used by a high level program or system application can be
created (or changed or overridden) to use DEVTYPE(*AFPDS).
• APU can be used to convert existing SCS spooled files to AFPDS.
• AFPU/400 (Advanced Function Printing Utilities/400) has a component called
Print Format Utility that can generate AFPDS spooled files.
• ERP applications, such as J. D. Edwards OneWorld, can create AFPDS
directly from the line-of-business application programs.
• Third-party applications, such as Doc/1 and Custom Statement Formatter,
create AFPDS directly.
• PostScript and image print files can be transformed by Image Print Transform
(a component of host print transform) into AFPDS.
• ImagePlus and Facsimile Support/400 and other image products produce
MODCA-P, which is equivalent to AFPDS.
For the most part, AFPDS spooled files can be sent to Infoprint Manager for AIX
over TCP/IP for printing. Use TRANSFORM(*NO) in the Remote Output Queue or
the SNDTCPSPLF command. AFP resources will need to be moved to the server
and placed in appropriate directories.
There is one very important exception. Many printer files take advantage of
Computer Output Reduction (COR) on the AS/400 system, either explicitly with
Appendix H. AS/400 to AIX printing 375
PAGRTT(*COR) or implicitly with PAGRTT(*AUTO). This includes most system
supplied printer files as well as the output generated by many user or vendor
programs. The idea is to take output that was normally formatted for the large
paper supported on line printers and reduce and rotate it to fit on the smaller
paper used by cut-sheet laser printers. Neither *COR nor *AUTO is supported by
Infoprint Manager for AIX. If you simply take your SCS printer file and change it to
create AFPDS, you will not see the same results when printing through Infoprint
Manager for AIX as printing on the AS/400 system. To compensate for this, you
would have to explicitly specify in the printer file PAGRTT(90 or 270), FRONT &
BACKMGN (.5 .5), FNTCHRSET (a 13 cpi font such as C0D0GT13 or
C0620090), and LPI (8 or 9) to have similar results.
You can print all *AFPDS spooled files using PSF Direct. PAGRTT(*AUTO) and
(*COR) will be supported. External resources will be managed from the AS/400
system and do not need to be manually transferred to Infoprint Manager for AIX
server.
H.2.4 *IPDS
A version of IPDS that is specific to some of the older twinax IPDS printers, such
as 3812 and 4224 may be generated on the AS/400 system, and printed without
using PSF/400 to some printers. It is not a full implementation of that data
stream. Some of the features supported in this data stream are barcodes, printer
resident fonts, and embedded IOCA images. Overlays, page segments, host
fonts, and other AFP resources are not supported.
This subset of IPDS data stream is not supported on Infoprint Manager for AIX.
You cannot send these files to the server that is using TCP/IP. The applications
would have to be changed to generate *AFPDS.
You can use PSF Direct to send *IPDS spooled file to the printer via Infoprint
Manager for AIX since they are converted to full IPDS by PSF/400.
H.2.5 *LINE or *AFPDSLINE
PSF/400 has supported *LINE and *AFPDSLINE (or Mixed) data streams for
quite some time. Only recently, it could be generated by standard programming
techniques using printer files. Form definitions and page definitions are used to
format these types of files. Although Infoprint Manager for AIX also supports Line
and Mixed data streams, you cannot send the AS/400 files to Infoprint Manager
for AIX using TCP/IP, since the AS/400 system adds some control characters
between records, and these are not recognized by Infoprint Manager for AIX.
You can use PSF Direct to send *LINE or *AFPDSLINE to printers via Infoprint
Manager for AIX as they are converted to *IPDS by PSF/400.
H.2.6 *USERASCII
OS/400 does not explicitly generate spooled files that contain ASCII data
streams. However, user or vendor applications may generate spooled files that
contain ASCII. The AS/400 system does no checking on the validity of the
content of those files. Some of the third-party packages use this capability to
generate PCL or PostScript. Client Access/400 allows you to generate ASCII data
streams on a PC client using an ASCII driver. This output can be placed on the
AS/400 Output Queue transparently.
376 IBM AS/400 Printing V
Spooled files that contain *USERASCII may be sent over TCP/IP to Infoprint
Manager for AIX. Use TRANSFORM(*NO) when sending these files using
TCP/IP.
PSF Direct cannot be used to send *USERASCII files to Infoprint Manager for
AIX.
H.3 Automating the process
Depending on the complexity and variety of the applications, there are a few
different ways to automate the process of sending the spooled files over TCP/IP
and selecting the correct transformation options and processing resources.
H.3.1 Default Document
If all your spooled files use a very limited number of printing characteristics such
as data stream type, form and page definitions, etc., you can set up a Logical
Destination and Default Document on Infoprint Manager for AIX. In the default
document, you name the AFP resources, and you set up the Logical Destination
to use that Default Document. On the AS/400 side, you would direct those files
needing those resources to that Logical Destination. If you are using AS/400
Remote Output queues, you would need one queue for each Logical Destination.
Assume most of your output from your AS/400 system consists of system
generated SCS spooled files that are 132 columns by 66 lines. These are going
to be converted to “flat ASCII”, and a form and page definition will be used to
format the page. The chain of definitions might look something like the AS/400
Remote Output Queue shown in Figure 271.
Figure 271. AS/400 Remote Outut Queue
On Infoprint Manager for AIX, you would have a Logical Printer that references a
Default Document:
Logical-Printer-Name = STD132-l
Default-Document = STD132-dd
The Default Document that looks similar to the example in Figure 272 would be
created to define the formatting options.
CRTOUTQ OUTQ(STD132)
RMTSYS(INFOPRINT)
RMTPRTQ('STD132-l')
CNNTYPE(*IP)
DESTTYPE(*OTHER)
MFRTYPMDL(*WSCST)
WSCST(FLATASCII)
TEXT('Remote outq for logical destination STD132-l')
Appendix H. AS/400 to AIX printing 377
Figure 272. Default document example
H.3.2 Destination options in the remote output queue
Another approach for the one or few formatting combinations is to hard code the
appropriate parameters in the Destination Options (DESTOPT) of a Remote
Output queue on the AS/400 system.
For the same example, you could use the parameters shown in Figure 273.
Figure 273. Destination Options (DESTOPT) of a Remote Output Queue on the AS/400 system
In the above two methods, you would need one Infoprint Manager for AIX Logical
Destination and one AS/400 Remote Output queue for each different application
being sent to each printer. For example, if you have two printers and three
applications, you would have to set up six AS/400 Remote Output Queues and six
Logical Destinations on Infoprint Manager for AIX. For more information, see
H.4.4, “Destination Options” on page 381.
H.3.3 Output queue monitor
The final method is to use build an output queue monitor application that watches
for files arriving on AS/400 output queues, and then builds the Destination Option
string and sets other SNDTCPSPLF parameters on the fly.
The parameter, DTAQ, in the create or change output queue command, allows
you to name a data queue. Any time a spooled file is placed in that output queue
in a RDY state, or its state changes to RDY, a record is written to the Data Queue
with information about that file. A monitor program is set up to receive the data
queue records, and takes appropriate action for the spooled file it references.
Depending on the situation, you may need to use a combination of the following
elements in your monitor application:
Default-document-name = STD132-dd
Document-format = line-data
Resource-context-font = /usr/lpp/afpfonts
Resource-context-form-definition = /usr/lpp/psf/fontlib
Resource-context-overlay = /usr/lpp/psf/fontlib
Resource-context-page-definition = /usr/lpp/psf/fontlib
Form-definition = F1STD132
Convert-to-ebcdic = true
page-definition = P1STD132
Carriage-control-type = ansi-ascii
Input-exit = /usr/lpp/psf/bin/asciinpe
CRTOUTQ OUTQ(STD132)
RMTSYS(INFOPRINT)
RMTPRTQ('STD132-l')
CNNTYPE(*IP)
DESTTYPE(*OTHER)
MFRTYPMDL(*WSCST)
WSCST(FLATASCII)
DESTOPT('-of=F1STD132 -odatat=line -oparmdd=/u/afpres/parmstd132’)
TEXT('Remote outq for logical destination STD132-l')
378 IBM AS/400 Printing V
• Lookup tables or files. These can be used to match up the name of the original
AS/400 output queue to the target Infoprint Manager for AIX logical destination
name, or match up the AS/400 spooled file name or other attribute with a
Destination Options string.
• Calls to system API QUSRSPLA to Retrieve Spooled File Attributes. The
information retrieved includes information about the spooled file, such as data
stream type, page size, overlay name. For more information, see AS/400
System API Reference, SC41-3801 or SC41-5801.
A combination of CL and RPG (or other language) may be needed.
Along with the monitor program, a robust system may need some house keeping
functions such as error checking and table maintenance. If there is a problem and
the monitor needs to be ended, spooled files may have to be held and released in
order to put a record back in the data queue.
H.4 Special considerations
The following sections cover several special considerations that you may
encounter in your specific implementation of AS/400 to AIX printing.
H.4.1 Processing line AS/400 SCS files as ‘flat ASCII’
There may be times when the you choose to convert the existing AS/400 SCS
spooled files to “flat ASCII” and then format them with form and page definitions
when they arrive at the Infoprint Manager for AIX server. “Flat ASCII” refers to a
simple ASCII file that contains only text and simple line and page controls. The
basic steps are:
1. Create a WSCST that converts the spooled file to “flat ASCII”.
2. Create form and page definitions on Infoprint Manager for AIX.
3. Create a “parmdd” file with parameters for the Infoprint Manager for AIX
line2afp program. The line2afp program processes the line data against the
form and page definition, producing a fully resolved AFPDS file. Line2afp is an
alias for ACIF, AFP Conversion, and Indexing Facility.
4. Send the spooled file from the AS/400 system to Infoprint Manager for AIX
using the SNDTCPSPLF command, or use a Remote Output Queue. You must
specify:
a. TRANSFORM(*YES)
b. MFRTRPMDL(*WSCST)
c. WSCST(FLATASCII)
5. Specify Destination Options using the DESTOPT parameter as required, or
use a Default Document on Infoprint Manager for AIX.
H.4.1.1 WSCST for ‘flat ASCII’
Here is an example of the source for a Workstation Customization Object used to
convert simple SCS spooled files to ASCII. As you can see, only a few of the
original SCS controls are converted. Any other controls are dropped. Contrast
this to the sample WSCST for IBM4039HP shown in Chapter 6 of IBM AS/400
Printing IV, GG24-4389.
Appendix H. AS/400 to AIX printing 379
:WSCST DEVCLASS=TRANSFORM.
:TRNSFRMTBL.
:SPACE
DATA ='20'X.
:FORMFEED
DATA ='0C'X.
:LINEFEED
DATA ='0A'X.
:LPI
LPI = 8
DATA ='0D'X.
:EWSCST.
The tags for SPACE, FORM-FEED, and LINEFEED are fairly obvious, converting
those to the required ASCII equivalents. The LPI tag was inserted to resolve a
problem we had at one account that was printing at 8 LPI and had more than 66
lines on the page. HPT was inserting a new form feed after 66 lines by default.
This tag eliminated that problem, and has no effect on other spooled files.
To create the WSCST, type the source into a Source Physical File member. The
Type field for the member should be blank or *NONE. Use the CRTWSCST command
to create the object. Here is an example of the command:
CRTWSCST WSCST(mylib/FLATASCII)
SRCMBR(FLATASCII)
TEXT('Convert SCS to Flat ASCII')
SRCFILE(mylib/mysrc)
This WSCST can now be used in the SNDTCPSPLF command or in a definition
for a Remote Output Queue.
H.4.2 Sample page and form definition for STD132
The most common of the AS/400 spooled files has a record length of 132 and a
page length of 66. Figure 274 on page 380 shows a sample of a form definition
and page definition source used to format these files once they arrive on Infoprint
Manager for AIX. This assumes they have been converted to ASCII using the
above FLATASCII Workstation Customization Object.
380 IBM AS/400 Printing V
Figure 274. Sample form and page definition source
The source may be compiled using PPFA on either the AS/400 system or on the
Infoprint Manager for AIX system.
When the AS/400 WSCST converts an SCS spooled file to ASCII, it inserts a form
feed at the end of every page, including the last page. The CONDITION TEST in
the page definition prevents a blank page from being generated.
H.4.3 Parmdd file
The parmdd file may be used to set some of the parameters used by the line2afp
program, which converts the “flat ASCII” data to AFPDS. Using a parmdd file is
optional. You could specify these parameters in the Destination Options. There is
a limit of 132 characters for DESTOPT, so we chose to use a parmdd file. Here is
an example of a parmdd file:
cc=yes
cctype=z
fdeflib=/u/afp/resources
formdef=f1std132
pdeflib=/u/afp/resources
pagedef=p1std132
inpexit=/usr/lpp/psf/bin/asciinpe
The Parameter Descriptions are explained in the following list:
• Cc=yes or no: Specifies whether the input file has carriage-control
characters.
– yes: The file contains carriage-control characters. “yes” is the default.
– no: The file does not contain carriage-control characters.
SETUNITS 1 IN 1 IN
LINESP 8.8 LPI;
FORMDEF STD132
OFFSET .25 .5
REPLACE YES;
PAGEDEF STD132
REPLACE YES
WIDTH 10 IN HEIGHT 7.5 IN
DIRECTION DOWN;
FONT CR13 CS 420090 CP V10500;
PRINTLINE CHANNEL 1 REPEAT 66
FONT CR13
POSITION MARGIN TOP;
ENDSUBPAGE;
PRINTLINE CHANNEL 1 REPEAT 1 FONT CR13 POSITION 1 MM 1 MM;
PRINTLINE REPEAT 1 FONT CR13 POSITION 1 MM NEXT;
CONDITION TEST
START 1 LENGTH 1
WHEN GE X'00' BEFORE SUBPAGE
CURRENT CURRENT;
Appendix H. AS/400 to AIX printing 381
Carriage-control characters, if present, are located in the first byte (column) of
each line in a document. They are used to control how the line will be
formatted (single space, double space, triple space, and so forth). In addition,
other carriage-controls can be used to position the line anywhere on the page.
If there are no carriage-controls, single spacing is assumed.
• inpexit=/usr/lpp/psf/bin/asciinpe: Converts unformatted ASCII data into a
record format that contains an American National Standards Institute (ANSI)
carriage control character in byte 0 of every record, and then converts the
ASCII stream data to EBCDIC stream data.
• cctype=z: The file contains ANSI carriage-control characters that are encoded
in ASCII. “z” is the default.
For more information on other parameters used in the parmdd file, refer to the
section on line2afp in the IBM Infoprint Manager for AIX Reference, S544-5475.
H.4.4 Destination Options
Destination Options provide a means to specify how a file being sent from the
AS/400 system to a print server is to be processed. For a complete description of
all available options, see the IBM Infoprint Manager for AIX Reference. The
maximum length of the field is 132 characters.
H.4.4.1 Basic SCS spooled file
The DESTOPT parameter to match up an SCS printer file with the STD132 form
definition appropriate parmdd file would look something like this example:
-of=f1std132 -odatat=line -oparmdd=/u/afpres/parmstd132
See the previous section for information on the parmdd file.
The form definition name ends up being specified twice. Once within the parmdd
file, where it is used by the line2afp program and again in the Destination Options
for use at print time.
These destination options could be hard coded into a Remote Output queue. If
you are using the Monitor program described above, you could create a lookup
table that selects different Destination Options based on the spooled file name or
other parameters.
H.4.4.2 Overlays with the SCS file
If you have an SCS spooled file that references an overlay, the overlay will not be
sent (nor any reference to it) if the file is converted to ASCII using host print
transform. An overlay reference can be added using the Destination Options. If
the overlay name is always the same for given spooled files, you can use a
lookup table. If not, for even greater flexibility use the QUSRSPLA API to retrieve
spooled file attributes into a program.
The overlay name is added to the Destination Options using the format:
-ooverlay=myovl
In the following example, we check to see if there is a value to OVL, and if so, it is
concatenated to the DESTOPT field which will be used subsequently in the
SNDTCPSPLF command:
382 IBM AS/400 Printing V
IF COND(&OVL *NE '*NONE')
THEN(CHGVARVAR(&DESTOPT)
VALUE(&XOPT *BCAT '-ooverlay=' *CAT &OVL))
XOPT contains the base options as in H.4.4.1, “Basic SCS spooled file” on page
381. The overlay specified will print on every page of the document. If you have a
different overlay specified as a BACKOVL in your AS/400 spooled file, you may
need to build a page definition to handle this. Be aware that this may not be
practical for OV/400 documents.
H.4.4.3 User name
If you are using the SNDTCPSPLF command, the user name that is printed on
the Infoprint Manager for AIX cover sheet will be the name of the person issuing
the SNDTCPSPLF command, not the user who created spooled file on the
AS/400 system. If you are using a monitor program, it will be the person who
started the monitor job.
To help the users sort their output, use the -ouserid option in DESTOPT to specify
the name, which will show up on the Infoprint Manager for AIX queues and on any
cover sheets printed. The monitor program can obtain this value from the
information it picks up from the data queue. Here is an example of adding the
user name to the destination options (XOPT contains the base options as in
H.4.4.1, “Basic SCS spooled file” on page 381):
CHGVAR VAR(&DESTOPT) VALUE(&XOPT *BCAT '-ouserid=' *CAT &USER )
This is not a problem if you are using remote output queues. The name of the
owner of the spooled file will print on the cover sheet.
H.4.5 Output from the AS/400 query
When a user generates a query report, there is an option to select the form size
to print. When the file is printed on an AS/400 attached laser printer, the output
could look quite different, depending on the value of width selected.
• If the width is less than 85, the data is printed in portrait format at 10
characters per inch, 6 lines per inch.
• If the width is greater than 85, but less than or equal to 132, the spooled file is
generated at 10 cpi, but Computer Output Reduction is invoked, and the result
is landscape print at 13.3 cpi, and approximately 8.5 LPI.
• If the width is greater than 132, the spooled file is generated at 15 cpi.
Computer Output Reduction is evoked, and the output is converted to 20 cpi.
If the customer desires that the output have similar characteristics when printed
via Infoprint Manager for AIX, it takes a little more work than needed for other
system generated files. One cannot rely on a simple lookup by spooled file name.
The attributes for CPI and WIDTH need to be retrieved using QUSRSPLA to
determine the appropriate combination of form and page definitions to use.
H.4.6 Transferring resources
AS/400 overlays and page segments must be converted to a physical file before
they can be transferred to AIX. Use the Convert Overlay to Physical File Member
(CVTOVLPFM) and the Convert Page Segment to Physical File Member
(CVTPAGSPFM) commands, which are included in AFPU/400 (Figure 275).
Appendix H. AS/400 to AIX printing 383
Figure 275. Convert Overlay to PFM
Make sure you select option 2 (Continuous) for the Format of data. The Convert
Page Segment to PFM has a similar structure.
Transfer the resource to the Infoprint Manager for AIX using FTP. Make sure the
file is sent in binary format. Place the resource in a directory that will be found by
Infoprint Manager for AIX. See Infoprint Manager for AIX Reference Manual,
S544-5475, for information on the search order.
H.4.7 Large spooled files
In a couple of cases, customers have experienced problems sending very large
spooled files from the AS/400 system to Infoprint Manager for AIX. Smaller
spooled files work fine, but when they send large files, they receive error
messages TCP3405 and TCP3701, Send Request Failed. No messages are
issued on Infoprint Manager for AIX. It was ultimately determined to be a problem
with the /var file space on the server side. Have the AIX System Administrator
increase the size of this file space.
H.5 Case studies
The following case studies are based on actual Infoprint Manager for AIX
customer situations. In some cases, the situations were simplified for emphasis of
certain points.
H.5.1 One printer, all AFPDS
This customer had been a faithful user of AFP on the AS/400 system for some
time, and most applications had already been formatted with
DEVTYPE(*AFPDS). They were adding an Infoprint Manager for AIX server so
they could share their large printer with other users.
It was a fairly straightforward task to create one remote output queue to point to
the Logical Destination used for the printer. The only destination option used was
'-odatat=afpds'. Overlays and page segments had to migrate to Infoprint Manager
for AIX.
Convert Overlay to PFM
Overlay . . . . . . . . . . : myovl
Library . . . . . . . . . : mylib
Type choices, press Enter.
Format of data . . . . . . . 2 1=Fixed, 2=Continuous
To file . . . . . . . . . . Myovlpf Name, *VM, *MVS
Library . . . . . . . . . *CURLIB Name, *CURLIB
To member . . . . . . . . . *OVL Name, *OVL
Text 'description' . . . . . *OVLTXT
Replace . . . . . . . . . . N Y=Yes, N=No
Create file . . . . . . . . Y Y=Yes, N=No
Text 'description' . . . . . Physical file for my overlay
384 IBM AS/400 Printing V
H.5.2 One printer, four document types
This example was not actually from an AS/400 host, but the situation can apply to
the AS/400 system.
This customer was migrating from a non-IBM printer to an IBM AFP Printer. They
only had three distinct applications that required special formatting. All the rest
was equivalent to STD132 earlier in this chapter.
With the previously installed printer, all the formatting was done at the printer, so
it was decided to maintain that philosophy by setting up four remote output
queues on the host to point to separate Logical Destinations on Infoprint Manager
for AIX, one per application and one for STD132. The rest of the resource
selection was to be done based on Default Documents that were associated with
the Logical Destinations.
H.5.3 70 printers, 12 applications, SCS spooled files
The customer had a third-party application package that generated SCS spooled
files. They were migrating from impact printers using preprinted forms and had
about 11 applications with specific formatting requirements for overlays and font
changes, along with unformatted system printing. They could not modify the
source.
They chose to use form and page definitions to do their formatting. All the AFP
resources were created on Infoprint Manager for AIX. Remote output queues with
hard coded Destination Options to name resources would not be practical
because 1400 would be required for all the valid combinations. A monitor
program was written. On the AS/400 system, one (local) output queue was set up
for every destination on Infoprint Manager for AIX. Each output queue pointed to
one common data queue. The monitor program read the entries from the data
queue and used lookup tables to match the name of the application to a
Destination Option string, and the name of the AS/400 Output Queue to the name
of an Infoprint Manager for AIX Logical Destination. This program also modified
the user name as described above.
H.5.4 Multiple printers, many data streams
This customer was installing Infoprint Manager for AIX to share printing between
AS/400, MVS, and LAN users on a wide variety of printers over four buildings,
ranging from PCL printers to the IBM Infoprint 4000. On the AS/400 system, the
applications included:
• Basic system printing STD132
• Query reports of different sizes
• SCS spooled files that had overlays
• OV/400 documents, some of which had overlays
• AFPDS spooled files.
We started with the basic monitor, similar to the one used in the previous
example. However, much more logic had to be applied to build the appropriate
Destination Options and set the appropriate Transformation parameters in the
SNDTCPSPLF command. Lookup tables were used to gather general information
about each spooled file type, and to match up the target Logical Destination. The
QUSRSPLA API was used to gather information such as data stream, if it was
generated using Final Form Text Document Content Architecture, query size,
Appendix H. AS/400 to AIX printing 385
overlay names, and user name. Some files were sent with TRANSFORM(*NO),
some with MFRTYPMDL(*HP5SI), and others used the FLATASCII custom
*WSCST.
H.6 Sending AS/400 spooled files to OnDemand for UNIX
Automating the process of moving AS/400 spooled files to an AIX platform for
loading into OnDemand for UNIX can be accomplished. The degree of
automation that you want, as well as the volumes that will be moved, will affect
the effort you need to expend to get the job done.
Following is an outline of the tasks required to automatically move financial
statements from an AS/400 system to OnDemand for UNIX. IBM Global Services
recently completed this work at a number of customer situations, with very
satisfactory results.
H.6.1 AS/400 side tasks
You may also want to perform these tasks for the AS/400 system:
• Write a program to monitor for spooled files entering an output queue (see
above notes).
• Using the spooled files APIs, open the spooled file object, extract the report
data stream, and write it to a stream file in the IFS.
• Write another program that uses the automated FTP functions to send the
stream file in the IFS to the AIX server.
H.6.2 AIX side tasks
For AIX, you may want to perform these tasks:
• Write a program which monitors the arrival of the stream file in the designated
directory on the server.
• Have the OnDemand load process execute to load the stream file received
into the proper Application Group in OnDemand.
While the high level tasks are quite straightforward, the details of the
implementation are where you may become overwhelmed. For example, how do
you differentiate between different report types, and how do you manage the
growth of the addition of new report types over time? Or, how do you handle
different data streams that may be created, SCS or AFPDS?
In addition, the degree of automation required will determine how much effort you
put into table definitions, error monitoring, reporting, and so on. These are all
components of the implementation that add complexity and effort to the overall
project.
H.7 AS/400 printing to an Infoprint Manager for Windows NT or 2000 server
Some of the techniques described above for printing to an Infoprint Manager for
AIX server also apply to Infoprint Manager for Windows NT or 2000. The
remainder of this section will refer to Windows NT, but it also applies to Infoprint
Manager for Windows 2000.
386 IBM AS/400 Printing V
Spooled files can be sent from the AS/400 system to the Infoprint Manager for
Windows NT server via TCP/IP. This can be done using a Remote Output Queue
or the SNDTCPSPLF command, as described in H.1.1.1, “Remote Output Queue”
on page 367, and H.1.1.2, “SNDTCPSPLF command (LPR)” on page 369.
PSF Direct is supported from the AS/400 system to Infoprint Manager for
Windows NT. There is configuration documentation available on the IBM Printing
Systems Division Web site at: http://www.printers.ibm.com/R5Psc.nsf/web/ntpsfd
To use PSF Direct, you need the IBM SecureWay Communications Server
product to communicate between the AS/400 system and Windows NT.
The considerations presented in H.2, “AS/400 spooled file data streams” on page
372, regarding the different AS/400 spooled file data streams can be applied to
sending those same types of files to Infoprint Manager for Windows NT.
Using an Output Queue Monitor in conjunction with Infoprint Manager for
Windows NT may still have a use if you want to automate the sending of different
spooled file types to different Infoprint Manager for Windows NT logical
destinations.
H.7.1 Hypothetical case studies
These scenarios have been verified to work. They are included here to illustrate
the possible co-existence between AS/400 and Windows NT for printing.
H.7.1.1 One channel attached printer, two hosts
A customer currently has an IBM 3900-001 printer attached via parallel channel
to a PSF/2 server, using Distributed Print Function (DPF). There are two AS/400
hosts sending data to the printer. The customer wants to move to a Windows NT
solution. Infoprint Manager for Windows NT does not support DPF. Consequently,
the customer will use PSF Direct and set up the PSF Configuration Objects on
each AS/400 system so that the printer session will time out if there are no
spooled files ready.
H.7.1.2 Two printers, three applications
A customer wants to use Infoprint Manager for Windows NT to share their two
medium-speed printers with the AS/400 system and other LAN users. The
AS/400 applications consists of invoices and statements that are already in
AFPDS format, and other SCS printing generated using the default system printer
files. They plan on using the STD132 form and page definitions as described in
H.4.2, “Sample page and form definition for STD132” on page 379.
This customer will set up four remote output queues on the AS/400 system. Two
of these will be for the AFPDS spooled file that are to print on each of the two
printers. These output queues will have TRANSFORM(*NO) specified. The target
logical destinations will reference a default document that is set up for printing
AFPDS by specifying:
document-format=afpds
Two other AS/400 output queues will be set up to handle the default system
printing. They will be setup with TRANSFORM(*YES) and use the “Flat ASCII”
Workstation Customization Object as described in H.4.1.1, “WSCST for ‘flat
ASCII’” on page 378. They will point to two logical destinations that use a default
Appendix H. AS/400 to AIX printing 387
document for printing that is similar to the one described in H.3.1, “Default
Document” on page 376.
H.8 Additional references
For more information, please refer to the following publications:
• AS/400e Printer Device Programming Version 4, SC41-5713
• Infoprint Manager for AIX Reference, S544-5475
• IBM Infoprint Manager for AIX PSF Direct: Network Configuration Guide for
System/370, S544-5486
• IBM AS/400 Printing III, GG24-4028
• AS/400e System API Reference Version 4, SC41-5801
• IBM AS/400 Printing IV, GG24-4389
• Windows NT PSF Direct: AS/400 Configuration
388 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 389
Appendix I. Infoprint 2000 printing considerations
The announcement of the IBM Infoprint 2000 Multifunctional Production System,
Models RP1, NP1, and DP1 with its high speed cut sheet printing and duplicating
did not provide a robust AS/400 print solution. The data streams supported
initially are PostScript 3, PDF, PCL6 and LCDS/Metacode. The AS/400 system
provides direct connection only via a remote outqueue and the use of the host
print transform (HTP) functions as described in Chapter 6, “Host print transform”
on page 137. The use of an intermediate system, such as the IBM Infoprint
Manager AIX and other third-party solutions, also allows AS/400 spool output to
printed on the Infoprint 2000. An IPDS version of the DP1 model will be offered at
a later date, supporting the Advanced Function Presentation architecture’s
Intelligent Printer Data Stream.
Many of the installations of the Infoprint 2000 are for reprographics and network
printing applications and the amount of print from the AS/400 system represents
a small percentage of the total print workload. Other installations have been for
specific applications that have used customized HPT or intermediate solutions.
The following sections look at the considerations for print files and HPT and the
use of an intermediate solution for application formatting.
Note: The IPDS version of IBM Infoprint 2000 was announced in September
2000.
I.1 Print file considerations and HPT formatting
Printing directly from the AS/400 system to the Infoprint 2000 can result in many
challenges and require changes in the operations procedures. The AS/400 spool
output (Data Type=*SCS and *AFPDS only) must be converted into ASCII. A
supplied or custom HPT will be used. The AS/400 HPT objects will create ASCII
data streams for PCL, pure ASCII or image. One or more of these HPTs may be
used to provide optimum results. If a HPT is being used today for other ASCII
printers that support PCL, then the results should be identical. If twinax attached
printers or AFP printers are being used, differences and limitations may apply.
The remote print writer (STRRMTWTR) is an automated LPR to the printer
queue. Some of the limitations of the HPT and remote writers are:
• No Forms mount messages (ignored)
• No Page Range printing (unsupported program is available)
• Copies are transmitted individually (XAIX parameter in the outqueue)
• No multi-up support
• SCS and AFPDS data types only supported (*USERASCII is passed through)
• DDS functions, such as scale and rotate of page segments, are not supported
• Draw commands that print in the ‘no print borders’ will be adjusted into the
print area
The primary output of AS/400 applications are business oriented, for example
Invoices, Packing List, Labels (with barcodes), reports, and so on. The unique
functions of Infoprint 2000, like the production of booklets and other output
formats produced by PC and network applications, are not usually necessary.
390 IBM AS/400 Printing V
Therefore, the primary objective will be to produce business output on Infoprint
2000 at a rated speed, meeting the business objectives of the organization.
One requirement that has been and will remain important is maintaining the
integrity of the printed page. Printing on Infoprint 2000, a local network printer or
an AFP Printer should provide similar results. The fonts should be mapped,
boxes and lines appear in the same place, graphic objects reproduced accurately,
and so on. The differences that exist in the hardware and software technology
may not map one to one. Therefore, content integrity is the default. The objective
is to minimize the differences.
The print management functions that can be specified in the Print File using the
CHGPRTF, OVRPRTF, and CRTPRTF commands and the function of the native
print writer give the application developer control over the printing process. Many
of these print file parameters are ignored by the AS/400 HPT processing of the
Remote Writer. For example, jobs that have an overlay specified in the print file to
merge SCS output with a form, will ignore the overlay, printing the data not the
form. Overlays and Page Segments referenced in the DDS (externally described
print file) of *AFPDS output will be processed and converted.
Customization of the HPT table may be necessary to specify input and output
options on the printer. We reccommend that you use he latest printer microcode.
Understanding the PCL data stream is necessary if special functions are to be
implemented. Infoprint 2000 will honor the PCL drawer selections with the
Release 3.0 Version 3.15 of the printer microcode.
Control of SCS and IPDS printers have allowed jobs with different characteristics
to be sent to the same output queue. The AS/400 writer would assist in managing
the workflow with operator messages, workload balancing, and so on. With the
Remote Print Writer and HPT, it may be necessary to create many output queues,
one for each job characteristic that will be coded in a unique HPT. In many
accounts, this will require additional operator instructions or changes to current
instructions that will place job print integrity on the operator. One of the
restrictions encountered in early installations was the use of simplex and duplex
printing on pre-punched paper. The 3130 and 3160s used by the account had
edge sensitivity and would rotate the pages for proper printing. This now requires
planning of drawers for simplex and duplex, and the input bin changed in the print
file. The HPT object used or customized will need to send the correct escape
sequence for that drawer.
Custom HPT information is provided in Chapter 6 of this manual. Additional HPT
information is available on the AS/400 Web site in Rochester. The knowledge
base under the category of Print has setup, customization, and PTF information.
Information provided includes remote print writer considerations, the page range
program, TCP/IP printing, and HPT customization.
I.2 Infoprint Manager and other solutions
The use of a print solution other than the native AS/400 writers has been an
option for years. Many of these solutions can be applied to printing from the
AS/400 system to the Infoprint 2000. IBM Infoprint Manager has been used for
printing of AFPDS on the printer. All of the necessary AFP resources are loaded
into the AIX system as described in Chapter 2 of AS/400 Printing IV, GG24-4389.
Overlays, page segments, and fonts are then processed by Infoprint Manager and
Appendix I. Infoprint 2000 printing considerations 391
delivered to the printer. Operator control of the printing is moved from the AS/400
system to the Infoprint Manager system. With Infoprint Manager, printing control
is robust.
Some of the other solutions for formatting spooled files that can be used are
applications like Create!Print, Planet Press, and so on. These solutions either
interface with the AS/400 spool and create USERASCII output on the AS/400
system or rely on the AS/400 system to provide a trigger on the front of the
document that will invoke a PostScript Macro on the printer to format the data.
The processing of the SCS spooled files into ASCII with a trigger that will invoke
the PostScript application will require either AS/400 application modification and
the use of the *WSCSTNONE transform or a custom HPT that will add the trigger
to an existing application’s spooled file. If multiple trigger applications are
needed, each will require a customized WSCST and its own outqueue.
The system supplied host print transform for outputting ASCII is the
*WSCSTNONE transform. To create a custom WSCST with a trigger requires the
retrieval and modification of a HPT that outputs ASCII. The retrieval of the ASCII
HPT and the modification of the HPT are the initial sequence to invoke the
PostScript trigger application.
The WSCST source that was retrieved (RTVWSCST) from the IBM provided
ASCII HPT (*WSCSTNONE) is shown in the example in Figure 276.
Figure 276. WSCT source
The trigger required by this application was the insertion of a cover page
containing the form name on the front of the spooled file. To do this, we modify
the initial printer sequence sent to the printer by the host print transform in the
print writer. The ASCII hex value was determined for the form name, and the hex
value '0C' is the form feed or page eject. Line 5 of the WSCST source above was
changed from a hex value of '00' to the ASCII value for trigger name, HRFORM1,
followed by a form feed of hex '0C'. The value became DATA
='4852464F524D310C'X. This custom HPT was then saved and compiled using
the CRTWSCST command and added to the remote outqueue description
(WRKOUTQD). Every job that is processed through this outqueue will arrive at
Columns . . . : 1 71 Browse AGROSE/QTXTSRC
SEU==> ASCII
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
*************** Beginning of data *************************************
0000.01 :WSCST DEVCLASS=TRANSFORM.
0000.02
0000.03 :TRNSFRMTBL.
0000.04 :INITPRT
0000.05 DATA ='00'X.
0000.06 :SPACE
0000.07 DATA ='20'X.
0000.08 :CARRTN
0000.09 DATA ='0D'X.
0000.10 :FORMFEED
0000.11 DATA ='0C'X.
0000.12 :LINEFEED
0000.13 DATA ='0A'X.
0000.14 :EWSCST.
****************** End of data ****************************************
392 IBM AS/400 Printing V
the printer as pure ASCII and have a header page with the word HRFORM1 as its
only content. All other printer file values specified, such as cpi, font, simplex,
duplex, etc., are ignored.
The revised customization object is shown (Figure 277) and is compiled using the
CRTWSCST command.
Figure 277. Revised customization list
I.2.1 Another application solution
The controller for the Infoprint 2000 Reprographics System can be modified to
provide additional application flexibility. In one installation, a shareware
PostScript macro was used to produce two-up on the printer. The technique is
similar to the trigger application. The PostScript shareware was installed on the
printer controller, and a monitor was invoked to scan the input stream for the
processing options supported Since two-up could be either simplex or duplex,
additional WSCST tags were used on the HPT. They processed specific print file
attribute and imbedded keyword triggers in the beginning of the spooled file sent
to the printer. The tags for simplex, duplex, and tumble printing were added to the
*WSCSTNONE retrieved object.
The AS/400 spooled file could specify simplex, duplex, or duplex tumble for the
output. Printing on three hole paper requires that the holes be on different sides
in the input drawers for simplex and duplex. Logic was also added to the scan
program to submit the print job to use the correct drawer. The following lines were
added after line 13 to the unmodified WSCST above:
0000.14 :SMPXPRT
0000.15 DATA ='53494D504C45580A'X.
0000.16 :DUPXPRT
0000.17 DATA ='4455504C45580A'X.
0000.18 :DUPXPRT
0000.19 DATA ='54554D424C450A'X.
The result was an ASCII file arriving in Infoprint 2000 with three additional lines of
data added to the beginning of the ASCII spooled file, with the value in the third
line being the trigger for the two-up application with logic to choose drawers
Columns . . . : 1 71 Browse AGROSE/QTXTSRC
SEU==> ASCII
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
*************** Beginning of data *************************************
0000.01 :WSCST DEVCLASS=TRANSFORM.
0000.02
0000.03 :TRNSFRMTBL.
0000.04 :INITPRT
0000.05 DATA ='4852464F524D310C'X.
0000.06 :SPACE
0000.07 DATA ='20'X.
0000.08 :CARRTN
0000.09 DATA ='0D'X.
0000.10 :FORMFEED
0000.11 DATA ='0C'X.
0000.12 :LINEFEED
0000.13 DATA ='0A'X.
0000.14 :EWSCST.
****************** End of data ****************************************
Appendix I. Infoprint 2000 printing considerations 393
based on the physical paper orientation needed for printing simplex and duplex
two-up.
Note that pure ASCII and PCL, should not be mixed within a file. The PCL escape
sequences will be treated as data once the printer decides that the data stream is
not PCL.
Each of these solutions requires a knowledge of the data stream provided by the
AS/400 system, the impact of the HPT on document integrity, and the application
capability of any intermediate system. Placing shareware into the printer
controller also requires UNIX knowledge. Each of these solutions has strengths
and weaknesses and may be a custom installation.
I.2.2 Operator considerations
The current procedures used for operations control may need to be modified,
often significantly, to insure print integrity. Print jobs may need to be modified to
direct them to the new queue or operator procedures may need to be updated if
the operators moved jobs from a job queue to the printer device queue. Any job
where print file attributes are ignored, need to be handled as an exception and
may require a unique output queue. If the job is moved into the incorrect queue,
there is no checking of the data, and it is possible to experience a higher number
of print errors and reprints.
Additional reasons for multiple PCL queues may be the need to modify rotation to
force portrait for applications where there is no source or the print file cannot be
modified. Special line spacing is often desired for Computer Output Reduction
(COR) to better fit the page or to offset for prepunched paper, functions that could
be handled automatically by the PSF/400 writer. Each exception needs to be
documented, and training needs to be provided for increased operator training.
Page restart integrity now is an operator task with the remote outqueue. For
example, if it was necessary to restart a print job on an AS/400 system attached
3130 Printer, the PSF/400 writer would determine the exact page to restart based
on the position on the page. A two-up duplex job actually contains four logical
pages. If a jam occurred while printing pages 17 through 20, the AS/400 system
would resend beginning at page 17. The page restart for the remote outqueue
does not consider page position because the multi-up is done by the printer,
allowing resending at any page number.
Since the AS/400 system assumes at once LPR is complete, the job has printed,
the disposition of print jobs may need to be set to SAVE=*YES. This allows the
resending of jobs.
394 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 395
Appendix J. Printing enhancements in recent OS/400 releases
This appendix summarizes the enhancements in OS/400, Print Services
Facility/400 (PSF/400), and related printing software in the last four
releases—V4R2 through V4R5.
J.1 Version 4 Release 5
Version 4 Release 5 includes the following enhancements:
• SNMP ASCII Printer Driver OS/400
• SNMP ASCII Printer Driver for IBM Infoprint 21
• Expanded printer speed ranges for PSF/400
• Type Transformer for Windows
Another enhancement in the V4R5 time frame, but not part of the release, is
AFPDS/IPDS support for OneWorld, an ERP e-business solution from J. D.
Edwards.
J.1.1 SNMP ASCII printer driver
The Simple Network Management Protocol (SNMP) ASCII Printer Driver is a new
printer driver for TCP/IP attached printers. This printer driver provides the
function found in the PJL printer driver but does not require the printer to support
PJL commands. With the SNMP printer driver, there are now three ASCII printer
drivers:
• LPR, or remote output queue
• PJL printer driver
• SNMP printer driver
See 11.2.3, “Configuring LAN-attached ASCII printers using SNMP drivers” on
page 246, for more information.
J.1.2 SNMP driver for Infoprint 21
A special version of the SNMP printer driver is provided for IBM Infoprint 21. IBM
Infoprint 21 is a new generation network printer for the AS/400 system. It is the
first IBM AS/400 printer to use the IBM Homerun controller. The Homerun
controller is designed with the capabilities of the IBM Advanced Function
Common Controller Unit (AFCCU), the standard controller for high-speed
printers) but geared for lower-speed network printers. The spooling design
incorporated within the Homerun controller greatly enhances print performance in
a network environment. However, there can be incompatibilities when using the
PJL printer driver. The SNMP ASCII printer driver is the recommended printer
driver for Infoprint 21. Support for the SNMP printer driver for Infoprint 21 is also
available for V4R3 and V4R4 via a PTF.
The SNMP printer driver is only needed when Infoprint 21 is used as a PCL
printer. When used as an Intelligence Printer Data Stream (IPDS) printer, then
PSF/400 is the printer driver.
396 IBM AS/400 Printing V
J.1.3 PSF/400 printer ranges
PSF/400 is licensed by printer speed ranges. Each licensed speed range enables
an unlimited number of printers (for the licensed AS/400 system) within that
range. With V4R5, the printer speed ranges have been expanded as follows:
• 1 to 28 pages per minute
• 1 to 45 pages per minute
• Any speed (1 to unlimited pages per minute)
J.1.4 AFP Font Collection bundled with PSF/400
AFP Font Collection, the comprehensive set of AFP fonts for the AS/400 system
(and other servers), is now bundled with new orders of PSF/400 (beginning with
V4R5).
J.1.5 Type Transformer for Windows
Type Transformer for Windows, a font conversion and editing platform, became
available in June 2000. Type Transform for Windows, a feature of AFP Font
Collection (5648-B45), enables conversion of Adobe and TruType fonts to AFP
fonts for use with AS/400 print and presentation applications. Type Transformer
also includes utilities for editing individual font characters and for editing code
pages.
For details on Type Transformer for Windows, see 4.11, “Creating AFP fonts with
Type Transformer” on page 110.
J.1.6 AFP/IPDS support for OneWorld
OneWorld, a leading ERP software solution from J. D. Edwards, now has
integrated support for AFPDS/IPDS. This support shipped in October 2000 with
OneWorld Xe. With this support, any OneWorld application output can be created
in either AFP or PDF format.
J.2 Version 4 Release 4
The following AS/400 program products have been enhanced with this new
release:
• OS/400 5769-SS1
• Print Services Facility/400 (a feature of OS/400) 5769-SS1
• Advanced Function Printing Utilities for AS/400 5769-AF1
• AFP Font Collection 5648-B45
• Content Manager OnDemand for AS/400 5769-RD1
The new DDS keywords support these features:
• Switch between simplex and duplex printing within a spooled file
• Force printing on a new sheet of paper anywhere in a spooled file
• Direct selected pages of a spooled file to a specific output bin
• Tabbed insert pages from a finisher anywhere within an output file
• Specify z-fold options for any page within an output file
• Include an overlay and specify the orientation (rotation) at which the overlay
should be printed
Appendix J. Printing enhancements in recent OS/400 releases 397
New printer file functions include:
• Print overlays on the back side of pages without any variable data
• Specify that output should be corner-stapled, edge-stitched, or saddle-stitched
as a printer file option.
J.2.1 Simplex/duplex mode switching DDS
This DDS keyword allows you to switch back and forth between simplex and
duplex mode when printing. This is useful when parts of a job should be simplex
and other parts should be duplex. Setting the proper mode can improve job
throughput.
J.2.2 Force new sheet DDS
When printing in duplex mode, the Force new sheet DDS keyword provides
control of the sheet in addition to the side. Execution of this keyword forces a new
sheet to be selected regardless of whether you are currently on the front side or
back side of the sheet in process.
J.2.3 Output bin DDS
This keyword enables DDS-level (for example, page level) control of output bin.
Prior to this support, all pages in a spooled file went to the output bin defined in
the printer file.
J.2.4 Insert DDS
As part of the finishing options added during the V4 releases, the insert DDS
keyword enables insertion of a sheet from the inserter (for example, as found on
the Infoprint 60 finisher) within the current print job. This provides for inclusion of
such booklet inserts as cover sheets, back pages, and tab sections.
J.2.5 Z-fold DDS
Certain output finishers (for example, the Infoprint 60 finisher) support the z-fold
operation. This operation takes an 11 by 17 inch page (for example, spreadsheet)
and “z-folds” it down to 8 ½ by 11 inch size. This is handy to include large format
pages in a standard size booklet.
J.2.6 Overlay rotation DDS
This DDS parameter for the OVERLAY keyword provides the capability to change
the orientation of overlays on the page. This avoids the need to have the same
overlay stored multiple times in different orientations.
J.2.7 Constant back overlay in the printer file
A new printer file keyword provides the capability to print an overlay on the back
side (duplex side) of a sheet without application data. This capability is useful in
any application where application data is to be printed on the front side and static
data on the back side. An example would be a customer invoice where the back
side of the sheet has static terms and condition information that is put there as an
overlay.
398 IBM AS/400 Printing V
J.2.8 Print finishing
Support for stapling options, initially supported in V4R2, is now added directly to
the printer file. CORNERSTPL, EDGESTITCH, and SADLSTITCH are the
keywords. For example, CORNERSTITCH(*TOPLEFT) causes the print job to
staple in the top left corner of the page. The function selected must be supported
on the specified printer (for example, Infoprint 32, Infoprint 40, Infoprint 60).
J.2.9 AS/400 font management
AS/400 applications can use both AS/400-resident and printer-resident fonts. The
mapping table that manages font selection and substitution is now
user-modifiable using the PSF configuration object. This enables you to control
font fidelity for your applications across a variety of different printers with greater
flexibility and precision.
J.2.10 Advanced Function Printing Utilities (AFPU) enhancements
AFPU provides a set of supporting functions for advanced output applications,
including electronic form design and management of forms and images.
Enhancements with V4R4 include new barcode symbol, color support, and
improved image handling.
J.2.11 Content Manager OnDemand for AS/400
Content Manager OnDemand is a comprehensive archival system for the AS/400
system. It supports the organization, indexing, storage, retrieval, viewing, faxing,
printing, and network presentation of AS/400 documents, reports, and other
objects. V4R4 implements the OnDemand user interface into Operations
Navigator. In addition, OnDemand is now integrated with EDMSuite
ContentConnect, which provides Web access across multiple document
repositories. Web access is provided by NetConnect.
J.3 OS/400 Version 4 Release 3
In OS/400 Version 4 Release 3, Print Services Facility/400 and associated native
OS/400 print support (Printer File and DDS) have been enhanced. They provide
new application capabilities and take advantage of new printers and printer
attachments. These enhancements include:
• Integration of AFP Workbench into Client Access/400
• DDS indexing keyword to support for archiving and viewing applications
• Support for line data formatting enhanced
• Automatic resolution enhancement
• Font performance improvement reduces CPU utilization
• Sizing and rotation for page segments
• Enhanced PostScript transform
• IPDS Pass-through
• Enhanced AFP Font Collection with support for euro, expanded languages
• Availability of new versions of Advanced Print Utility, Page Printer Formatting
Aid, AFP Toolbox, and SAP R/3 AFP Print (members of the AFP PrintSuite
family)
These are explained in greater detail in the following sections.
Appendix J. Printing enhancements in recent OS/400 releases 399
J.3.1 Integration of AFP Workbench into Client Access/400
Functions in the AFP Workbench that had previously been an optional, priced
feature of Client Access/400 are now integrated as part of the product. Client
Access/400 (CA/400) users can now view any document on their PC or in a
CA/400 shared folder that is in AFP, ASCII, TIFF, PCX, DCX, or DIB data format.
They can also use AFP Workbench Viewer to create page segments (images) or
overlays (electronic forms) from any PC application program and upload them to
OS/400 for printing with OS/400 applications. This AFP Printer Driver for
Windows can also be downloaded from the Web site at:
http://www.ibm.com/printers/as400
For additional details, see Chapter 5, “The IBM AFP Printer Driver” on page 117.
J.3.2 Indexing keyword in DDS
The AFP presentation architecture includes support for indexing fields in a print
record to be used for navigation by an archival/retrieval program, or by a
document viewing or browsing program (such as the AFP Viewer in CA/400). In
Version 4 Release 3, Data Description Specifications (DDS) has been enhanced
to enable specification of fields in a record as AFP index fields. Output from these
applications can now be used with archival/retrieval programs for fast retrieval of
individual pages or groups or pages in the archive. Archival programs that use
AFP index fields include IBM Content Manager/OnDemand for AS/400,
OnDemand for AIX, and OnDemand for NT. OnDemand for AS/400 was formerly
named RDARS/400. The AFP Viewer in CA/400 also supports using index
information in documents to quickly locate any group of pages within a spooled
file, PC file, or shared folder.
J.3.3 Support for line data enhanced
Support for generating line data from AS/400 applications and using page and
form definitions to format output external to the application program was
introduced in Version 3 Releases 2 and 7. However, many applications from
third-party vendors, as well as customer applications, could not take advantage of
this powerful new formatting capability because they were already formatted
using DDS (although the DDS specifications were simple). In Version 4 Release
3, new OS/400 system function has been provided to automatically convert
output from programs that use DDS into line data so that they can be formatted
using all the capabilities of AFP page definitions and form definitions objects.
Page and form definitions are created using Page Printer Formatting Aid
(PPFA/400) or similar products. PPFA/400 is a component of the AFP PrintSuite
for AS/400. See Chapter 3, “Enhancing your output” on page 67, for more
information on formatting application output with PPFA/400.
J.3.4 Automatic resolution enhancement
Many current IBM AS/400 IPDS printers print at a resolution of 600 dpi. However,
applications may have been developed to use raster fonts in 240 dpi or 300 dpi
resolutions. New multiple resolution font support in OS/400 Version 4 Release 3
provides the capability for these applications to take advantage of the increased
print quality of new printers without application or resource changes. PSF/400 will
coordinate with the printer to download the best resolution to enable the printer to
render a requested font at 600 dpi.
400 IBM AS/400 Printing V
Note that resolution enhancement applies to fonts. For images, page segments
that are in Image Object Content Architecture (IOCA) are resolution-independent
and will be rendered at the resolution of the target printer. For older page
segments that use the IM1 format, those are converted to IOCA when possible.
When such a conversion is not possible, the image is rendered “as is”. This will
result in a change in the size of the image if the IM1 resolution and the printer
resolution are different.
J.3.5 Font performance improvement
For applications that use AFP fonts downloaded to a printer that supports both
raster and outline fonts, a performance enhancement in OS/400 V4R3 can result
in a reduction in CPU utilization of 50 to 70%. This represents a significant
improvement in system performance for customers who print on IBM high-speed
AFP printers, or for customers running mid- to high-speed printers on a
CPU-constrained system.
J.3.6 Sizing and rotating page segments
Support for page segments (image objects) has been enhanced with new DDS
options for dynamic sizing and rotation. This allows you to create one page
segment (a company logo, for example) and dynamically size or rotate it based
on the needs of each different print application. Previously, a separate page
segment object was required for every size and rotation required across all of
your printing applications. With this support, only one version of an image is
required. The rotation and scaling of page segment images is done in the printer.
Therefore, only certain printers are supported (those with printer controllers).
J.3.7 Enhanced PostScript transform
The transformation of PostScript files, part of Image Print Transform services
included in V4R2, is enhanced to provide Double-Byte Character Set (DBCS)
support. Using this support enables PostScript files to be transformed to AFPDS
or PCL and routed to either AFP or PCL printers.
This PostScript transform handles all PostScript L1 functions and some of
PostScript L2 functions. See Chapter 7, “Image print transform” on page 161, for
information on Image Print Transform.
J.3.8 IPDS pass through
IPDS pass through is now a standard printer file parameter. With IPDS
pass-through, you can significantly increase overall printing performance to IPDS
printers for print files not requiring advanced IPDS services. See Appendix A,
“PSF/400 performance factors” on page 279, for more information on IPDS
pass-through.
J.3.9 AFP Font Collection with Euro, expanded languages
AFP Font Collection (program 5648-B45), the one-stop resource for AFP fonts,
has been repackaged. It now includes support for additional languages and
support for the euro currency symbol. AFP Font Collection is a comprehensive
set of AFP fonts with over 1,000 fonts from the most popular type families. Such
family examples include Times New Roman, Helvetica, and Courier. These fonts
come in a full range of sizes, resolutions (240, 300, and outlines), and languages
Appendix J. Printing enhancements in recent OS/400 releases 401
(over 48). See Chapter 4, “Fonts” on page 89, for additional information on AFP
Font Collection.
J.3.10 AFP PrintSuite for AS/400
AFP PrintSuite for AS/400 is a family of products for formatting application output
into advanced electronic documents. This family includes:
• Advanced Print Utility (APU)
• Page Printer Formatting Aid/400 (PPFA/400)
• AFP Toolbox for AS/400
• SAP R/3 AFP Print
Each of these electronic document products was enhanced with new versions in
May 1998 (V3R7M1).
For additional details on the changes to APU, see Chapter 2, “Advanced Function
Presentation” on page 35.
J.4 OS/400 Version 4 Release 2
Changes in V4R2 include:
• OS/400 V4R2, including Image Print Transform services
• Print Services Facility/400 V4R2, including PostScript support, outline fonts,
font capture, cut sheet emulation, and finishing
• AFP Utilities V4R2, with enhancements to electronic form creation on the
AS/400 system
• New and revised guides to AS/400 printing include this redbook and AS/400
Guide to Advanced Function Presentation and Print Services Facility
S544-5319.
J.4.1 OS/400 Image Print Transform Services
OS/400 adds a new subsystem to support documents and files in PostScript print
format as well as the TIFF, GIF, and BMP image file formats. These are common
formats found in network applications. This new subsystem, called Image Print
Transform, will transform those input formats into AFP, PCL, or PostScript format.
These transforms are invoked automatically as part of the normal print process or
invoked through an API as a standalone process.
Let's look at the automatic process first. An application, such as one running on a
CA/400 client or the IBM Network Station, generates a PostScript file to an
AS/400 output queue. If a writer is started to that queue going to an IPDS printer,
then PSF/400 will take control. When it starts to process the PostScript file, it
passes control to the Image Print Transform subsystem to convert the PostScript
to AFP. The Image Print Transform, in turn, uses a new object—the Image
Configuration Object—to provide additional information on how to do the
conversion. The converted AFP is passed back to PSF/400, which sends it out
(as an Intelligent Printer Data Stream) to the printer.
The automatic process could also be routed to a PCL printer. In this case, host
print transform would receive the PCL data stream from Image Print Transform
services and send it on to a PCL printer.
402 IBM AS/400 Printing V
The Image Print Transform process can also be run via an API. Here, the input
files might reside on the IFS file system. The API can be run to convert the file
formats to memory, to another file, or to an output queue. For example, you may
want to “preprocess” a PostScript file to AFP prior to putting it on the output
queue to speed up the printing process.
In addition, there are also non-print applications that may require the kind of
transform services provided by this new subsystem.
These new transform services add to the transform facilities already provided by
the AS/400 system:
• AFP to PCL
• AFP to TIFF
• SCS to ASCII
• SCS to TIFF
See Chapter 7, “Image print transform” on page 161, for more information about
Image Print Transform.
J.4.2 Support for outline fonts
Outline fonts are now supported on the AS/400 system. Outline fonts are familiar
to PC users because they are standard with TruType and Adobe Type 1 fonts. To
date, the AS/400 system has only supported raster (also known as bitmapped)
fonts. With raster fonts, each character in each font, in each point size, is an
image. All of these images are stored on the AS/400 system (as entries in a font
character set object). They are downloaded to the printer when they are
referenced in an application. In contrast, outline fonts are vector representations
of a font. There is only one small object required for all point sizes. Any point size
can be selected, as compared to a limited number of sizes with raster fonts. Both
AS/400-resident outline fonts (available through AFP Font Collection, for
example) and printer-resident outline fonts are supported. Outline fonts improve
printing performance, require less printer memory, and provide unlimited size
selections.
J.4.3 Font capture
Font capture is a font performance enhancement that retains (“captures”) a font
on the printer hard drive. Font capture has a significant impact when the
connection to the printer is slow or when large Double Byte Character Set
(DBCS) fonts are used. DBCS fonts are graphic-type fonts used in indeographic
languages such as Japanese and Chinese. Font capture also has an impact with
Single Byte Character Set (SBCS) fonts, but it may be less.
J.4.4 Cut-sheet emulation
Cut-sheet emulation ensures that duplex applications, created for cut-sheet
printers, print correctly on two-up duplex production printers (such as the Infoprint
4000 production printer family). The output from continuous-form production
printers (after the forms have been sliced in two and interleaved by
postprocessing) is identical to the output from a cut-sheet duplex printer. This
capability allows you to easily take advantage of the increased speed and
reliability of continuous form printers without changing your operating procedures
or programs.
Appendix J. Printing enhancements in recent OS/400 releases 403
J.4.5 Finishing support
Initial finishing support was added in V4R2. This support included:
• Edge stapling
• Corner stapling
• Saddle stitch
• Insert
• Z-fold
Edge, corner, and saddle stitching were added to the printer file using the
USRDFNDTA keyword. The syntax for the USRDFNDATA keyword is:
'CORNERSTPL(*TOPLEFT)')
Insertion and z-fold (as well as the stapling and stitching options) were added to
the AS/400 page and form definitions. PPFA/400 or other similar tools for building
AS/400 page and form definitions could be used to enable these functions.
Certain finishing operations require a combination of DDS and the form definition
(at V4R2). These functions were integrated in DDS and the printer file at V4R4.
See J.2, “Version 4 Release 4” on page 396, for the current support for finishing.
J.4.6 TCP/IP configuration enhancements
Several changes were made to the session management of TCP-IP connected
IPDS printers. With the Automatic Session Recovery keyword (AUTOSSNRCY),
you can specify if you want PSF/400 to automatically reconnect on a TCP/IP
network error. With the acknowledgment frequency keyword (ACTFRQ), you can
set how often to query the printer for the updated page counter. A high frequency
setting minimizes the number of reprinted pages on a network error, but may
reduce performance slightly.
The remote location name, port, and activation timer were removed from the PSF
configuration object (PSFCFGOBJ). These keywords were moved to the printer
device description.
J.4.7 Font substition messages
A new parameter in the PSF Configuration Object provides control over whether
font substitution messages are logged to the message queue. See Appendix
11.1.2, “Configuring LAN-attached IPDS printers on V3R7 and later” on page
230, for more information.
J.4.8 AFP Utilities for V4R2
AFP Utilities is a set of three supporting utilities for AFP applications on the
AS/400 system. The Overlay Utility allows you to create electronic forms from any
AS/400 terminal. The Print Format Utility is an AFP version of Query/400. It
creates AFP applications directly from AS/400 database files. Resource
Management Utility enables you to manage overlay and image resources on the
AS/400 system. For details on V4R2 enhancements, see 2.3, “AFP Utilities/400
V4R2 enhancements” on page 45.
404 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 405
Appendix K. Using the additional material
This redbook also contains additional Web material. See the appropriate section
below for instructions on using or downloading this material.
K.1 Locating the additional material on the Internet
The CD-ROM, diskette, or Web material associated with this redbook is also
available in softcopy on the Internet from the IBM Redbooks Web server. Point
your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG242160
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the
redbook form number.
K.2 Using the Web material
The additional Web material that accompanies this redbook includes the
following:
File name Description
hpttoflr.c HPTTOFLR Transform spooled file (uses
QwpzHostPrintTransform)
hpttoflr.cmd HPTTOFLR transform spooled file and write to folder
sg242160.pdf First edition of the Printing V redbook
ws_ftp.log FTP log file
K.2.1 How to use the Web material
Create a subdirectory (folder) on your workstation and copy the contents of the
Web material into this folder.
406 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 407
Appendix L. Special notices
This publication is intended to help customers, business partners, and IBM
system engineers who need to understand the fundamentals of printing on the
AS/400 system to help them develop, or advise others about the design and
development of AS/400 printing applications. The information in this publication is
not intended as the specification of any programming interfaces that are provided
by Print Services Facility/400, PrintSuite/400, AFP Utilities/400, and IBM Font
Collection. See the PUBLICATIONS section of the IBM Programming
Announcement for Print Services Facility/400, PrintSuite/400, AFP Utilities/400,
and IBM Font Collection 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, 500 Columbus Avenue, Thornwood, NY 10594 USA.
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 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.
408 IBM AS/400 Printing V
The following document contains examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the examples
contain the names of individuals, companies, brands, and products. All of these
names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
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
IBM Redbooks
Redbooks Logo
Advanced 36 Advanced Function Printing
AFCCU AFP
AIX APL2
APPN AS/400
AS/400e AT
BookMaster ContentConnect
CT Current
EDMSuite GDDM
ImagePlus InfoWindow
Intelligent Printer Data Stream IPDS
Manage. Anything. Anywhere. Netfinity
Network Station OfficeVision
OfficeVision/400 Operating System/400
OS/2 OS/400
Print Services Facility RMF
RS/6000 S/390
SecureWay SOMobjects
SP System/370
System/390 WIN-OS/2
Wizard XT
400 Lotus
Freelance Graphics Word Pro
Notes Tivoli
TME NetView
Cross-Site Tivoli Ready
Tivoli Certified Planet Tivoli
Appendix L. Special notices 409
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, SET Secure Electronic Transaction, 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.
410 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 411
Appendix M. Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
M.1 IBM Redbooks
For information on ordering these publications see “How to get IBM Redbooks” on
page 415.
• Inside AS/400 Client Access for Windows 95/NT, Version 3 Release 1
Modification 2, SG24-4748
• Managing AS/400 V4R4 with Operations Navigator, SG24-5646
The following publications are available online in softcopy format only at the
redbooks home page at: http://www.redbooks.ibm.com
At the site, click Redbooks Online and enter the book number in the search field
that appears. Click Submit Search. When the search results appear, click the
appropriate book title.
• AS/400 Printing III, GG24-4028
• AS/400 Printing IV, GG24-4389
M.2 IBM Redbooks collections
Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at ibm.com/redbooks for information about all the CD-ROMs offered,
updates and formats.
M.3 Other resources
These publications are also relevant as further information sources:
• IBM AFP Fonts: Font Samples, G544-3792
• IBM AFP Fonts: Font Summary, G544-3810
• IBM AFP Fonts: Licensed Program Specifications, G544-5229
• Ethernet and Token-Ring Configuration Guide, G544-5240
• Twinax/Coax Configuration Guide, G544-5241
• Infoprint Hi-Lite Color Introduction and Planning Guide, G544-5420
CD-ROM Title Collection Kit
Number
IBM System/390 Redbooks Collection SK2T-2177
IBM Networking Redbooks Collection SK2T-6022
IBM Transaction Processing and Data Management Redbooks Collection SK2T-8038
IBM Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
IBM AS/400 Redbooks Collection SK2T-2849
IBM Netfinity Hardware and Software Redbooks Collection SK2T-8046
IBM RS/6000 Redbooks Collection SK2T-8043
IBM Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
412 IBM AS/400 Printing V
• IBM Intelligent Printer Data Stream Reference, S544-3417
• IBM AFP Fonts: Technical Reference for Code Pages, S544-3802
• IBM Page Printer Formatting Aid: User's Guide, S544-5284
• IPDS and SCS Technical Reference, S544-5312
• AS/400 Guide to AFP and Print Services Facility, S544-5319
• PCL5e and Postscript Technical Reference, S544-5344
• Advanced Function Printing Utilities for OS/400, S544-5349
• AS/400 Advanced Print Utility Users's Guide, S544-5351
• IBM AFP Toolbox for AS/400 User's Guide, S544-5368
• SAP R/3 AFP Print for AS/400 User's Guide, S544-5412
• Infoprint Manager for AIX Reference, S544-5475
• IBM Infoprint Manager for AIX PSF Direct: Network Configuration Guide for
System/370, S544-5486
• Ethernet and Token Ring Configuration Guide (Infoprint 21), S544-5711
This publication is available in softcopy only at:
http://publib.boulder.ibm.com/pubs/pdfs/prsys/54457112.pdf
• AFP Traditional Chinese Font Catalog, SC18-0124
• AFP Simplified Chinese Font Catalog, SC18-0133
• AFP Thai Font Catalog, SC18-0137
• AFP Japanese Font Catalog, SC18-2332
• Mixed Object Document Content Architecture Reference, SC31-6802
• Client Access/400 Personal Communications 5250 Reference Guide,
SC41-3553
• AS/400 Workstation Customization Programming, SC41-3605
• AS/400 DDS Reference - Version 3, SC41-3712
• AS/400 Printer Device Programming - Version 3, SC41-3713
• AS/400 System API Reference - Version 3, SC41-3801
• Description Specifications Guide, SC41-4712
• OS/400 Printer Device Programming V4R2, SC41-5713
• AS/400 System API Reference - Version 4, SC41-5801
• Setting Up Printing in an Office Vision/400 Environment, SH21-0511
The following publications are available in softcopy only from the AS/400 Online
Library at: http://as400bks.rochester.ibm.com/pubs/html/as400/onlinelib.htm
At the site, select your language and click GO!. Click V3R2 and then Search or
view all V3R2 books. In the search field that appears, enter the book number
and click Find. Select the appropriate title that appears.
• Internet Packet Exchange (IPX) Support, SC41-3400
• AS/400 TCP/IP Configuration and Reference - Version 3, SC41-3420
Appendix M. Related publications 413
M.4 Referenced Web sites
These Web sites are also relevant as further information sources:
• The latest version of the AFP Printer Driver may be obtained from:
http://www.printers.ibm.com/afpdr.html
• The AS/400 Programming Sampler is available online from the AS/400
printing Web site at: http://www.printers.ibm.com/products.html
• Information about the Uniform Code Council and UCC/EAN-128 can be found
online at: http://www.uc-council.org
• Certain softcopy technical references can be downloaded free from the Web
at: http://www.printers.ibm.com/manuals.html
• Token-Ring and Ethernet microcode can be accessed online at:
http://www.printers.ibm.com/util.html
• For information regarding Network Printer Manager, visit the Web site at:
http://www.printers.ibm.com/npm.html
• Selected DDS source code and a comprehensive library of AFP application
examples can be found online in the AS/400 AFP Programming Sampler at:
http://www.printers.ibm.com/as400
• A “Printing from Java” overview for developers, written by Sun, can be found
online at: http://java.sun.com/products/jdk/1.1/docs/guide/awt/designspec/
printing.html
• Visit the IBM Redbooks home page at: http://www.redbooks.ibm.com
• The manual, PSF Direct: AS/400 Configuration, written for Infoprint Manager
for Windows NT, can be found online at:
http://www.printers.ibm.com/R5Psc.nsf/web/ntpsfd
• There is a no-charge utility available to assist in loading your IBM AFP Font
Collection (5648-B45) fonts in the special (QFNT01 to QFNT19) libraries. It
can be found online at: http://www.ibm.com/printers/as400
414 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 415
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 ibm.com/redbooks
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:
• Telephone Orders
• Fax Orders
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.
In United States or Canada
Outside North America
e-mail address
pubscan@us.ibm.com
Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
United States (toll free)
Canada (toll free)
Outside North America
1-800-879-2755
1-800-IBM-4YOU
Country coordinator phone number is in the “How to Order” section at
this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
United States (toll free)
Canada
Outside North America
1-800-445-9269
1-403-267-4455
Fax phone number is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
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 Intranet for Employees
416 IBM AS/400 Printing V
IBM Redbooks fax order form
Please send me the following:
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.
Title Order Number Quantity
First name Last name
Company
Address
City Postal code
Telephone number Telefax number VAT number
Invoice to customer number
Country
Credit card number
Credit card expiration date Card issued to Signature
© Copyright IBM Corp. 2000 417
Index
Symbols
*AFPDS 5
*AFPDSLINE 5
*HPCP 104
*HPFCS 104
*IPDS 4
*LINE 5
*NOCOPY 63
*NORMAL 63
*NOWAIT 176
*PHCP 104
*PHFCS 103
*REPRINT 63
*SCS 4
*USERASCII 5
*USRDFNTXT 176
Numerics
2000-sheet finisher 214
240-pel fonts 94
300-pel euro symbol support 94
300-pel fonts 95
4230/4214 emulation mode 276
4247 native mode 277
A
A3 page support 274
action group entry 58
activation timer 260
Advanced Function Common Control Unit (AFCCU) 16
Advanced Function Presentation
AFP resources 42
APU print model 37
AS/400 AFP model 35
creating AFP resources 43
overview of AFP on the AS/400 system 35
page and form definitions print model 41
PFU print model 39
toolbox print model 42
what is AFP 35
Advanced Function Presentation (AFP) 35
Advanced Function Presentation (AFP) Printer Driver 117
Advanced Function Printing
AFP resource retention 282
AFPDS to ASCII transform 142
Advanced Function Printing Data Stream (AFPDS) 5, 162
Advanced Function Printing Utilities (AFPU) enhancements
398
Advanced Print Utility
APU default setup 71
APU enhancements 49
APU environment 69
APU monitor enhancement 52
APU print model 37
configure APU Monitor Action 57
creating the print definition 72
fonts 69
print using the APU monitor 80
starting APU Monitor 65
using Advanced Print Utility 69
using APU monitor 56
working with the print definition 74
Advanced Print Utility (APU) 49, 67, 69
AFCCU (Advanced Function Common Control Unit) 16
AFCCU printers, stopping and starting 264
AFP (Advanced Function Presentation) 35
AFP compatibility fonts 93
AFP Font Collection 95
with PSF/400 396
AFP Font Collection with euro 400
AFP fonts created with Type Transformer 110
AFP model 35
AFP Printer Driver 117
creating an AFP document 134
creating an overlay 122
creating efficient AFP resources 284
creating page segment 126
file transfer of AFP resources using FTP 130
images dialog box 130
installing AFP printer driver 118
other AFP printer driver tasks 130
overview 117
performance of AFP printer driver 134
text or image 129
why use the AFP printer driver 117
AFP PrintSuite for AS/400 401
AFP resource creation 43
AFP resources 42, 43, 84
AFP toolbox print model 42
AFP Utilities 45, 403
AFP Workbench in Client Access/400 399
AFP/IPDS support for OneWorld 396
AFPDS (Advanced Function Printing Data Stream) 5
AFPDS line data stream 5
AFPDS spooled file 23, 25
AFPU V4R2 enhancements 45
application programming interface
ESPDRVXT (print driver exit) 307
ESPTRNXT (writer transform exit) 307
QGSCPYRS (copy AFPDS resources) 307
QGSLRSC (list spooled file AFPDS resources) 307
QIMGCVTI (convert image) 168
QSPBOPNC (build open time commands) 307
QSPBSEPP (build separator page) 307
QSPEXTWI (extract writer status) 306
QSPSETWI (set writer status) 306
QSPSNQWM (send writer message) 307
QWPZHPTR (host print transform) 307
APU (Advanced Print Utility) 49, 67
APU default setup 71
APU environment 69
APU monitor 56, 65
first version 80
new version 80
418 IBM AS/400 Printing V
APU monitor action 57
APU monitor enhancement 52
APU print engine 66
APU print model 37
APU versus PPFA 88
AS/400 AFP model 35
AS/400 font management 398
AS/400 network printers 205
AS/400 output on a PC printer 194
AS/400 print profile 191
ASCII data stream 5
ASCII printers 165, 277
attached to displays 17
attached to PCs 18
LAN-attached 19
ASCII printing 277
attachment methods
ASCII printers attached to displays 17
ASCII printers attached to PCs 18
ASCII printers LAN-attached 19
IPDS printers LAN-attached 16
printers attached to PSF Direct 20
printers attached to PSF/2 DPF 21
printers attached to WSC or 5x94 15
automatic resolution 399
auxiliary tray 213
B
BCOCA application 332
BCOCA object 332
bin and tray selection 212
BOOTP (Bootstrap Protocol) 237
Bootstrap Protocol (BOOTP) 237
C
calculated processor utilization 329
CDEFNT (Coded Font) 92
Change Spooled File Attributes (CHSPLFA) 2
characters per inch (CPI) 92
CHSPLFA (Change Spooled File Attributes) 2
Client Access/400 printing
AS/400 print profile 191
AS/400 printer to Windows 95 186
considerations on CA/400 network printing 193
network printer setup 191
Network Printing function 186
overview 185
Printer Definition Table (PDT) 200
printer emulation 194
printing AS/400 output on PC printer 194
Coded Font (CDEFNT) 92
commands
ADDNTWAUTE (Add NetWare Authentication) 182
CHGSPLFA (Change Spooled File Attributes) 2
CRTOUTQ (Create Output Queue) 172
CRTPSFCFG (Create PSF Configuration (V3R2)) 227
CRTWSCST (Create WSCST) 152
ENDWTR (End Writer) 3
RTVWSCST (Retrieve WSCST) 152
STRNTWCNN (Start NetWare Connection) 182
STRPRTWTR (Start Print Writer) 3
STRRMTWTR (Start Remote Writer) 176
WRKCFGSTS (Work wit Configuration Status) 3
WRKOUTQ (Work with Output Queue) 2
WRKSPLF (Work with Spooled Files) 2
WRKSPLFA (Work with Spooled File Attributes) 2
communication problems 253
comparison of printing rate 326
comparison of processor requirements 328
Computer Output Reduction (COR) 273
CONFIG MENU 210
configuration problems 253
configuring for remote system printing 258
connection problems 253
constant back overlay in the printer file 397
Content Manager OnDemand for AS/400 398
convert image API 168
convert image API (QIMGCVTI) 163
converting PostScript data streams 168
copying spooled files 269
COR 101
COR (Computer Output Reduction) 273
COR top margin 218
CPI (characters per inch) parameter 92
create source for form and page definitions 82
creating an overlay 122
creating page segment 126
customer-defined font ranges 106
cut-sheet emulation 402
D
data description specification (DDS) 287
data streams
AFPDS (Advanced Function Printing Data Stream) 5
AFPDSLINE (AFPDS line data stream) 5
AS/400 generated IPDS (full IPDS) 8
data streams on the AS/400 system 3
IPDS (Intelligent Printer Data Stream) 4
LINE (Line data stream) 5
SCS (SNA Character String) 4
USERASCII (ASCII data stream) 5
DBCS support in host print transform 156
DBCS AFPDS to ASCII transform 157
DBCS EBCDIC to ASCII transform 156
DBCS SCS to ASCII transform 156
new tags 157
new WSCST objects 157
supported data streams 157
DDS (data description specification) 287
DDS functionality example 287
DDS functionality specification 290
destination options 176
DESTOPT parameter 176
device description 224, 230
DEVTYPE 28
disabling resident font support 106
drawer and paper path selection problems 276
dual-configuration printer 207
dual-shared configuration printer 207
Index 419
duplex 49
duplicate IP address 260
E
edge-to-edge printing 221
element repeat 47
End Writer (ENDWTR) 3
ending the writer 261
ENDWTR (End Writer) 3
enhancing your output 67
euro with AFP Font Collection 400
externally-described printer file 36
F
FGID (Font Global Identifier) 91
fidelity parameter 269
File field 64
finishing support 403
FNTCHRSET (Font Character Set) 92
FONT (Font Global Identifier) 91
font capture 402
font capturing 108
Font Character Set (FNTCHRSET) 92
Font Character Set to Font ID 102
Font Global Identifier (FGID) 91
Font ID to Font Character Set 102
Font ID to Font ID 102
font mapping 101
font performance 400
font resource 108, 109
font substitution 169
font substitution messages 102, 275, 403
font table command 105
font table customization 103
font table entry 104
font tables 103
fonts 43, 69, 93
240-pel fonts available at a charge 94
300-pel fonts available at a charge 95
AFP Font Collection 95
at no charge 93
customer-defined font ranges 106
disabling resident font support 106
font substitution 101
font tables customization 103
host-resident fonts 90
installation 96
making the fonts available 97
outline fonts 99
PostScript 168
printer-resident fonts 89
problems 274
selection 91
storage 89
suppressing font substitution messages 102
user-supplied 169
using resource library list 107
force new sheet DDS 397
form and page definition object 85
form and page definitions 84, 86
form definition 43, 47
Form Type field 64
formatting 287
G
Graphics Interchange Format (GIF) 161
H
hardware 318
Hewlett-Packard Printer Control Language (PCL) 162
Hold field 64
host print transform 13, 332
AFPDS to ASCII transform 142
AFPDS to TIFF 150
create WSCST object 152
customization 151
DBCS support 156
enabling host print transform 140
enhancements 138
mapping mode 143
new and enhanced tags for WSCST objects 152
new MFRTYPMDL special values 154
no print border (AFPDS to ASCII) 149
NOPRTBDR tag example 142
overview 137
process 139
processing AFP resources 148
processing barcodes 148
raster mode 146
retrieve WSCST object 152
SCS to ASCII transform 140
transform limitations 150
transform spooled file, write to folder 150
unprintable border 141
Host to Printer-resident Code Page 104
Host to Printer-resident Font Character Set 104
host-resident fonts 90
host-resident outline font 48, 100
HPT ASCII printers versus PSF/400 IPDS 32
I
IBM 4247 paper path selection 276
IBM 5x94 15
I-DATA-7913 LAN attachment 237
iIndexing keyword in DDS 399
image compression 329
image configuration objects 166
image print transform 14, 161
Advanced Function Printing Data Stream (AFPDS) 162
convert image (QIMGCVTI) API 168
converting PostScript data streams 168
definition 161
Graphics Interchange Format (GIF) 161
Hewlett-Packard Printer Control Language (PCL) 162
image configuration objects 166
OS/2 and Windows Bitmap (BMP) 161
420 IBM AS/400 Printing V
PostScript Level 1 161, 162
printing 165
printing to an ASCII printer 165
printing to an IPDS printer 166
printing with image print transform 165
process 163
sending the spooled files 166
Tag Image File Format (TIFF) 161
troubleshooting 170
using 162
Image Print Transform Services for OS/400 401
implementing a printing concept 27
Infoprint 21 SNMP driver 395
Infoprint 4000 318
Infoprint 60 318
InfoWindow displays 17
input spooled file action 60
input spooled file selection criteria 59
input trays 213
insert DDS 397
installing AFP printer driver 118
Intelligent Printer Data Stream (IPDS) 4
INVNEW1 program 292
IP4000 318
IP4000 printer 325
IP60 printer 323
IPDS (Intelligent Printer Data Stream) 4
IPDS MENU 211
IPDS menu PAGE setting 218
IPDS pass through 282, 400
IPDS printer 166
IPDS printers LAN-attached 16
IPDS spooled file 23, 24
IPDS, AFP=*NO 216
IPDS, AFP=*YES 216
J
J option 176
J.D. Edwards OneWorld Xe 396
L
LAN-attached ASCII printers 19, 238
using LexLink 238
using PJL drivers 241
using SNMP drivers 246
LAN-attached IPDS printers 16, 223, 257
on V3R2 224
on V3R7 and later 230
LAN-attached printers 223
library list searches 284
line data 399
line data stream 5
line printer daemon (LPD) 172
line printer requester (LPR) 172
load letter message 179
logical and physical page origin 217
logical page 271
M
mailbox bins 214
mapping mode, processing AFP fonts 143
message queue full 260
messages
PQT3603 255
PQT3630 268
microcode 212
mixed data stream 5
monitor actions example 54
monitor example 53
Multiple Text Mapping 50
MULTIUP 101
N
NetWare
*BANNER option 184
*NOWAIT option 184
Add NetWare Authentication 182
AS/400 and NetWare Printing 181
Create Output Queue 182
preparing for remote system printing 182
Start NetWare Connection 182
NetWare printing 181
Network Printer 12/17 221
Network Printer 24 221, 318
Network Printer Manager 215
network printers 205
attachment information 215
configuration scenarios 206
dual-configuration printer 207
edge-to-edge printing 221
IPDS menu PAGE setting 218
LAN-attached IPDS printer 206
microcode 212
Network Printer Manager 215
output presentation 216
overview 205
printer menu details 209
printer setup 209
setup 191
shared dual-configuration printer 207
shared multi-purpose printer 208
tray and bin selection 212
using the QPRTVALS Data Area 217
Network Printing considerations 193
Network Printing function for CA/400 186
network station
local printing 311
print driver 309
printing 309
printing from Java 311
NP24 printer 322
O
OEM products 45
Offset Stacker/Jogger 214
Omit Back Side Page Layout 47
OneWorld AFP/IPDS support 396
Index 421
OS/2 and Windows bitmap (BMP) 161
OS/400 Image Print Transform Services 401
OS/400 printing enhancements 395
outline font 99, 100
outline font support 52, 402
output attributes 165
output bin DDS 397
Output bin field 65
output bins 214
Output device parameter 64
output enhancement 67
Advanced Print Utility 67
Page Printer Formatting Aid 67
using Advanced Print Utility (APU) 69
using PPFA 81
output from an AS/400 on a PC printer 194
output presentation 33, 216
output queue 172
NetWare 182
spooled files 1
Output queue parameter 64
output queue status 263
output spooled file action 60, 62
overlay 43
overlay rotation DDS 397
Overlay Utility 45
P
page and form definitions print model 41
page definition 43
Page Printer Formatting Aid
compile the form and page definitions 84
create source for form and page definition 82
create the form and page definition objects 85
page and form definitions print model 41
printing with form and page definitions 86
using PPFA 81
Page Printer Formatting Aid (PPFA) 67, 81
page segment 43
PAGE setting 218
PAGE=COMP1 220
PAGE=COMP2 220
PAGE=PRINT 219
PAGE=WHOLE 218
PAPER MENU 209
PCs connected to ASCII printers 18
PDT (printer definition table) 200
performance
AFP resource retention 282
AS/400 system storage 279
clear memory for security 283
creating efficient AFP resources 284
data stream type 280
font types 283
IPDS pass through 282
library list searches 284
printer device description parameters 282
printer file parameters 285
printer settings 285
PSF configuration object parameters 285
performance monitor 319
PFU (Print Format Utility) 39
PFU print model 39
physical page 271
ping TCP/IP address 254
PJL (Print Job Language) 255
port number 254
positioning data
logical page 271
physical page 271
problem with output presentation 271
PostScript data streams 168
PostScript fonts 168
PostScript Level 1 161, 162
PostScript transform 400
PPFA (Page Printer Formatting Aid) 67, 81
PPFA versus APU 88
PQT3603 message 255
PQT3630 message 268
print and convert mode 322
print criticality 27
print definition 65, 72, 74
testing 79
Print definition parameter 63
print engine 66
print finishing 398
Print Format Utility 47
Print Format Utility (PFU) 39
Print Job Language (PJL) support 255
print openness
additional functions 306
additional functions on the output queue commands 305
additional functions on the printer file 304
additional functions on the PRTDEVD commands 304
new APIs 306
print output 68
print output requirements 27
print profile 191
Print Services Facility/400 9
PSF/400 already installed 11
PSF/400 IPDS printers versus HPT ASCII printers 32
PSF/400 process 10
Print to Host-resident Font Character Set 103
print writer 8
printer attached methods 32
printer attachment methods 15
printer definition table (PDT) 200
printer DEVTYPE 28
printer emulation session 194
printer ends 259
printer file DDS 287
printer file device type 27
printer menu details 209
printer ranges for PSF/400 396
printer requirements 30
printer setup 209, 273
Printer to Host-resident Code Page 104
printer type 48
printer writer 6
422 IBM AS/400 Printing V
printer-resident fonts 89
printers attached to PSF Direct 20
printers attached to PSF/2 DPF 21
printers attached to WSC or 5x94 15
printer-writer-related problems 259
printing AS/400 output on PC printer 194
printing concept 27
considerations 32
enhancing your output presentation 33
print criticality 27
print output requirements 27
printer attachment methods 32
printer file device type 27
printer requirements 30
PSF/400 IPDS printers versus HPT ASCII printers 32
type of printers 30
writer supporting printer DEVTYPE 28
printing enhancements for OS/400 395
printing from Java 311
printing on ASCII printers 277
printing on the AS/400
data streams on the AS/400 system 3
host print transform 13
image print transform 14
implementing a printing concept 27
output queues 1
Print Services Facility/400 9
printer attachment methods 15
printer writer 6
Printing SCS, IPDS, AFPDS, and USERASCII spooled
files 23
remote system printing 22
spooled files 1
printing on the AS/400 system 1
printing SCS, IPDS, AFPDS, and USERASCII spooled files 23
printing with image print transform 165
print-resident font 319
problem determination
A3 page support 274
additional information 278
AFCCU printers, stopping and starting 264
communication, connection, configuration problems 253
computer output reduction 273
configuring LAN-attached IPDS printers 257
drawer and paper path selection problems 276
fidelity parameter 269
font problem 274
message PQT3603 255
message PQT3630 268
output queue status 263
ping TCP/IP address 254
port number 254
Print Job Language (PJL) support 255
printer setup 273
printing on ASCII printers 277
problem with output presentation 271
problem with shading 276
QSTRUP execution during IPL 264
remote printer queue name 258
setting up TCP/IP network on AS/400 253
spooled file goes to hold status 266
spooled file status 262
spooled files remain in PND status 261
spooled files remain in RDY status 260
SSAP values in line description 253
where your print output goes 265
writer cannot re-direct spooled file 267
problem determination techniques 253
problem with output presentation 271
program, INVNEW1 292
program-described printer file 36
PSF configuration object 227, 234
V3R7 and later 234
PSF Direct connected to printers 20
PSF trace 319
PSF/2 DPF connected to printers 21
PSF/400 IPDS printers versus HPT ASCII printers 32
PSF/400 printer ranges 396
PSF/400 spooled file conversion 331
PSF/400 V4R2 performance 317
PSF/400 V4R2 performance parameter 318
PSF/400 V4R2 software 317
PSF/400 with AFP Font Collection 396
PTFs 278
Q
QFNT240LA1 96
QFNT300CPL 96
QFNT300LA1 96
QFNTCDEPAG 96
QFNTCFOLA1 96
QFNTCPL 96
QIMGCVTI 163, 168
QPRTVALS data area 217
QSTRUP execution during IPL 264
QSTRUP program
at IPL 264
changing 264
queues to be monitored 57
R
raster mode processing AFP fonts 146
recommended PTF levels 212
record format 301
release timer 260
remote printer queue 173
remote printer queue name 258
remote system printing 22, 182, 258
create output queue 172
destination options 176
line printer daemon (LPD) 172
line printer requester (LPR) 172
load letter message 179
NetWare printing 181
overview 171
remote printer queue 173
remote printer queue name 258
Index 423
separator pages 178
Start Remote Writer 176
TCP/IP LPR-LPD printing 172
XAIX option 176
XAUTOQ option 177
resident font support 106
resource library list 107
rotating and sizing page segments 400
S
Save field 65
scalable fonts for MULTIUP and COR 101
SCS (SNA Character String) 4
SCS mode 216
SCS spooled file 23
separator pages 178
shading at different resolutions 276
shared multi-purpose printer 208
simplex/duplex mode switching DDS 397
sizing and rotating page segments 400
SNA Character String (SCS) 4
SNMP ASCII printer driver 395
SNMP driver for Infoprint 21 395
software, PSF/400 V4R2 317
source physical file 82
Source Service Access Point (SSAP) 253
spooled files
copying 269
copying spooled files 269
hold status 266
image print transform 166
output queue 1
printing AFPDS spooled files 25
printing IPDS spooled files 24
printing SCS spooled files 23
printing USERASCII spooled files 25
printing USERASCII spooled files with the image print
transform 26
remain in PND status 261
remain in RDY status 260
status 262
writer cannot re-direct 267
SSAP (Source Service Access Point) 253
SSAP values in line description 253
Start Printer Writer (STRPRTWTR) 3
STRPRTWTR (Start Printer Writer) 3
substitution messages for fonts 275
suppressing font substitution messages 102
switching DDS 397
T
Tag Image File Format (TIFF) 161
TCP/IP
ping TCP/IP address 254
setting up TCP/IP network on AS/400 253
TCP/IP BOOT Service (V4R1 and later) 237
TCP/IP LPR-LPD printing 172
TCP/IP BOOT Service (V4R1 and later) 237
TCP/IP configuration 403
TCP/IP network on AS/400 253
TEST MENU 209
TOKEN RING and ETHERNET MENU 210
transform spooled file, write to folder 150
tray and bin selection 212
troubleshooting print image transform 170
tutorial 48
TWINAX SCS MENU 210
TWINAX SETUP MENU 210
Type Transformer 110
Type Transformer for Windows 396
types of printers 30
U
User data field 64
User exit after field 65
User exit before parameter 63
User exit middle field 64
USERASCII spooled file 23, 25
printing with image print transform 26
user-supplied fonts 169
V
view electronic form on PC 45
W
where print output goes 265
Work Station Customizing Objects (WSCST) 14
Work with Configuration Statu (WRKCFGSTS) 3
Work with Output Queue (WRKOUTQ) 2
Work with Spooled File Attributes (WRKSPLFA) 2
Work with Spooled Files (WRKSPLF) 2
workstation controller 15
Workstation Customizing Object
*WSCSTA3 155
*WSCSTA4 155
*WSCSTA5 155
*WSCSTB4 155
*WSCSTB5 155
*WSCSTCONT132 155
*WSCSTCONT80 155
*WSCSTEXECUTIVE 155
*WSCSTLEGAL 155
*WSCSTLETTER 155
*WSCSTNONE 155
WRKCFGSTS (Work with Configuration Status) 3
WRKOUTQ (Work with Output Queue) 2
WRKSPLF (Work with Spooled Files) 2
WRKSPLFA (Work with Spooled File Attributes) 2
WSCST (Work Station Customizing Objects) 14
X
XAIX option 176
XAUTOQ option 177
Z
z-fold DDS 397
424 IBM AS/400 Printing V
© Copyright IBM Corp. 2000 425
IBM Redbooks review
Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook
"made the difference" in a task or problem you encountered. Using one of the following methods, please review the
Redbook, addressing value, subject matter, structure, depth and quality as appropriate.
• Use the online Contact us review redbook form found at ibm.com/redbooks
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Document Number
Redbook Title
SG24-2160-01
IBM AS/400 Printing V
Review
What other subjects would you
like to see IBM Redbooks
address?
Please rate your overall
satisfaction:
O Very Good O Good O Average O Poor
Please identify yourself as
belonging to one of the following
groups:
O Customer
O Business Partner
O Solution Developer
O IBM, Lotus or Tivoli Employee
O None of the above
Your email address:
The data you provide here may be
used to provide you with information
from IBM or our business partners
about our products, services or
activities.
O Please do not use the information collected here for future marketing or
promotional contacts or other communications beyond the scope of this
transaction.
Questions about IBM’s privacy
policy?
The following link explains how we protect your personal information.
ibm.com/privacy/yourprivacy/
(0.5” spine)
0.475”<->0.873”
250 <-> 459 pages
IBM AS/400 Printing V
®
SG24-2160-01 ISBN 0738419443
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks
IBM AS/400
Printing V
A primer on AS/400
printing in today’s
networked environment
Configuration,
performance, problem
determination,
enhancements
In-depth education on
AFP and ASCII printing
This IBM Redbook describes how to use printing functions on the
AS/400 system. It supplements the standard reference
documents on AS/400 printing by providing more specific “how
to” information, such as diagrams, programming samples, and
working examples. It addresses the printing function found in
OS/400, Print Services Facility/400 (PSF/400), Advanced Print
Utility, Page Printer Formatting Aid, AFP Font Collection, and other
print-enabling software. The original edition applied to Version 3
Release 2 for CISC systems and Version 4 Release 2 for RISC
systems. This second edition includes information about the new
functions that are available in releases up to and including
Version 4 Release 5.
This document is intended for customers, business partners, and
IBM systems specialists who need to understand the
fundamentals of printing on the AS/400 system. It is designed to
help you develop or advise others concerning the design and
development of AS/400 printing applications.
This document is not intended to replace existing AS/400 printing
publications, but rather to expand on them by providing detailed
information and examples.
© Copyright IBM Corp. 2003. All rights reserved. ibm.com/redbooks 1
Redbooks Paper
Bringing PHP to Your IBM iSeries
Server
Hypertext Preprocessor (PHP) is a powerful server-side scripting language for the Apache
Web server. PHP is popular for its ability to process database information and create dynamic
Web pages. Server-side refers to the fact that PHP language statements, which are included
directly in your HTML, are processed by the Web server. Scripting language means that PHP
is not compiled. Since the results of processing PHP language statements is standard HTML,
PHP-generated Web pages are quick to display and are compatible with most all Web
browsers and platforms. PHP is for the open source Apache community as Net.Data® is for
the IBM® community.
To “run” PHP scripts with your HTTP Server (powered by Apache), a PHP engine is required
on your IBM^™ iSeries™ server. The PHP engine is an open source product, so this
IBM Redpaper demonstrates the process to download, compile, install, and then configure
PHP on your iSeries. It explains how to install versions 4.3.0 and the older version 4.2.2 of
PHP.
The PHP engine is available both as an Apache module and a CGI-BIN. Support for PHP as
a module is not yet available for OS/400®. The step-by-step implementation discussed in this
Redpaper involves the CGI version of PHP running in OS/400 Portable Application Solutions
Environment (PASE). This allows you to run AIX® binaries directly on an iSeries. It includes
the necessary patches for the minor modifications needed to the PHP source code.
Note: If you want to know why this is so great, see the article “Programming with PHP on
the iSeries” for iSeries Network by David Larson and Tim Massaro. You can find this article
on the Web at:
http://www.iseriesnetwork.com/resources/artarchive/
index.cfm?fuseaction=viewarticle&CO_ContentID=15746&channel=art&PageView=Search
With permission from iSeries Network, we include the article in this Redpaper. To skip the
article, go to “Prerequisites” on page 11.
David Larson
Bryan Logan
Tim Massaro
Heiko Mueller
Brian R. Smith
2 Bringing PHP to Your IBM ^ iSeries Server
Programming with PHP on the iSeries server
Hypertext Preprocessor Language is a powerful, server-side scripting language for Web page
creation. Scripting language means PHP requires no compilation, very much like Perl or
Rexx. Because PHP is a server-side language, you can include it directly in HTML, and it is
recognized and processed by a Web server.
The first “P” in PHP is a remnant from the original acronym for Personalized Home Page. This
was the term that PHP creator Rasmus Lerdorf used when he first used a set of Perl scripts to
monitor access to his online resume. Since then, however, PHP has become the most
popular optional module configured on Web servers. See the following Web sites:
http://www.netcraft.com/survey
http://www.securityspace.com/s_survey/data/man.200204/apachemods.html
Here, we introduce the PHP language and walk you step-by-step through configuring PHP to
access DB2® Universal Database™ (UDB) from your Apache Web server. Then, we provide
examples to show you how iSeries shops can use PHP to create dynamic Web pages based
on new or existing iSeries DB2 UDB databases.
What is PHP?
PHP code can easily access database files and output HTML, resulting in non-static,
up-to-date Web pages. It's a technique similar to JavaServer Pages (JSPs) or Common
Gateway Interface (CGI) binary (often called CGI-BIN) programming. Also, PHP is an opensource
project. Open-source code can be useful if you want to tweak the behavior of PHP, but
it's even more valuable because there are many open-source PHP applications and code
samples available on the Web. This means you can get a new PHP Web project up and
running quickly with little investment.
Restriction: PHP is not supported on the iSeries server by IBM. We have provided these
instructions for you to download a public domain open-source copy of a PHP engine to
allow you to run PHP scripts on the iSeries server.
Specifically, the following items are not supported by IBM:
The open-source CGI-BIN based PHP engine
Any of the PHP scripts that you would write against this PHP engine
The other open source tools described in this Redpaper used for building the PHP
engine.
These items are fully supported by IBM:
5722-SS1 Option 33 OS/400 PASE and all utilities supplied with it
The VisualAge® C++ compilers
The HTTP Server (powered by Apache) support for OS/400 PASE CGIs
Bringing PHP to Your IBM iSeries Server 3
Hundreds of ready-made
applications written in PHP are
available as shareware, and many
commercial products employ it.
Until recently, PHP has enjoyed a
reputation for reliability and
security. See “Beware of PHP
bugs” on page 11.
Figure 1 shows the difference
between standard static Web
pages and dynamic Web pages
using server-side PHP processing.
In the first scenario on the left, a
standard URL request arrives at
the Web server asking for Web
page http://www.somepage.html.
The Web server sees this request
and returns the HTML that is in the
file somepage.html.
In the second scenario on the right, the index.php file contains the special
View PHP Source for this Query
The highlights include:
odbc_connect: This is the “Open” of the database. The link variable is used by other odbc
functions later in the script.
odbc_exec: The variable filled in on the HTML form contains the string that we will run as
an SQL statement. odbc_exe runs the SQL statement and returns results in the $result
variable.
odbc_numfields: A function determines how many columns are returned for this record.
We use this value to put HTML PHP Running WRKACTJOB in PASE
Redpaper
ibm.com/redbooks
High Availability
On the AS/400 System
A System Manager’s Guide
Susan Powers
Nick Harris
Ellen Dreyer Andersen
Sue Baker
David Mee
Tools and solutions to improve your
highly available AS/400 system
Components for a successful high
availability system
Hardware options for high
availability
Front cover
International Technical Support Organization
High Availability On the AS/400 System:
A System Manager’s Guide
June 2001
© Copyright International Business Machines Corporation 2001. 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.
First Edition (June 2001)
This edition applies to Version 4, Release Number 5 of OS/400 product number 5769-SS1.
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.
Before using this information and the product it supports, be sure to read the general information in Appendix H,
“Special notices” on page 183.
Take Note!
iii
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Part 1. What is high availability? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Chapter 1. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.1 When to consider a high availability solution . . . . . . . . . . . . . . . . . . . . . . . .3
1.1.1 What a high availability solution is. . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.2 What high availability is. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
1.2.1 Levels of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.3 Determining your availability requirements . . . . . . . . . . . . . . . . . . . . . . . . .7
1.4 Determining how high you need to go . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
1.5 Estimating the value of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
1.6 iSeries factors for maximum availability . . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.7 Scheduled versus unscheduled outage . . . . . . . . . . . . . . . . . . . . . . . . . . .10
1.7.1 Scheduled outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
1.7.2 Unscheduled outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
1.8 Comparison to planned preventive maintenance (PPM) . . . . . . . . . . . . . .11
1.9 Other availability definition considerations . . . . . . . . . . . . . . . . . . . . . . . .12
Chapter 2. Developing an availability plan . . . . . . . . . . . . . . . . . . . . . . . . .15
2.1 The business plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
2.1.1 Project scope and goal definition. . . . . . . . . . . . . . . . . . . . . . . . . . . .16
2.2 Human resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
2.2.1 Project organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
2.3 Communication and sponsorship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
2.4 Service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
2.5 Third party contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
2.5.1 Application providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
2.5.2 Operating system provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
2.5.3 Hardware providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
2.5.4 Peripheral equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
2.5.5 Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
2.6 Verifying the implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
2.6.1 Documenting the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
2.7 Rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Chapter 3. High availability example solutions . . . . . . . . . . . . . . . . . . . . . .25
3.1 A high availability customer: Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . .25
3.2 A large financial institution: Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .26
3.2.1 Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.3 A large retail company: Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.4 A small manufacturing company: Scenario 4. . . . . . . . . . . . . . . . . . . . . . .29
3.5 A distribution company: Scenario 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Part 2. AS/400 high availability functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Chapter 4. Hardware support for single system high availability . . . . . . .35
4.1 Protecting your data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
iv High Availability on the AS/400 System: A System Manager’s Guide
4.2 Disk protection tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Disk mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1 Standard mirrored protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 Mirrored protection: Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Mirrored protection: Costs and limitations . . . . . . . . . . . . . . . . . . . . 39
4.3.4 Determining the level of mirrored protection. . . . . . . . . . . . . . . . . . . 40
4.3.5 Determining the hardware required for mirroring . . . . . . . . . . . . . . . 44
4.3.6 Mirroring and performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.7 Determining the extra hardware required for performance . . . . . . . . 46
4.4 Remote DASD mirroring support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Remote load source mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.2 Enabling remote load source mirroring. . . . . . . . . . . . . . . . . . . . . . . 47
4.4.3 Using remote load source mirroring with local DASD . . . . . . . . . . . . 47
4.5 Planning your mirroring installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.1 Comparing DASD management with standard and remote mirroring 49
4.6 Device parity protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 How device parity protection affects performance . . . . . . . . . . . . . . 51
4.6.2 Using both device parity protection and mirrored protection . . . . . . . 52
4.7 Comparing the disk protection options . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Concurrent maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Redundancy and hot spare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 OptiConnect: Extending a single system . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11 Cluster support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.12 LPAR hardware perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.12.1 Clustering with LPAR support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.13 UPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.14 Battery backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.15 Continuously powered main storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.16 Tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.16.1 Alternate installation device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 5. Auxiliary storage pools (ASPs). . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Deciding which ASPs to protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.1 Determining the disk units needed . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Assigning disk units to ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Using ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Using ASPs for availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.2 Using ASPs to dedicate resources or improve performance. . . . . . . 66
5.3.3 Using ASPs with document library objects . . . . . . . . . . . . . . . . . . . . 67
5.3.4 Using ASPs with extensive journaling . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.5 Using ASPs with access path journaling . . . . . . . . . . . . . . . . . . . . . 68
5.3.6 Creating a new ASP on an active system. . . . . . . . . . . . . . . . . . . . . 68
5.3.7 Making sure that your system has enough working space . . . . . . . . 69
5.3.8 Auxiliary storage pools: Example uses. . . . . . . . . . . . . . . . . . . . . . . 69
5.3.9 Auxiliary storage pools: Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.10 Auxiliary storage pools: Costs and limitations . . . . . . . . . . . . . . . . 70
5.4 System ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4.1 Capacity of the system ASP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4.2 Protecting your system ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5 User ASPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5.1 Library user ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
v
Chapter 6. Networking and high availability . . . . . . . . . . . . . . . . . . . . . . . .75
6.1 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
6.2 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
6.3 Network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
6.4 Testing and single point of failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
6.5 Hardware switchover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
6.6 Network capacity and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
6.7 HSA management considerations with networking . . . . . . . . . . . . . . . . . .81
6.7.1 Network support and considerations with a HAV application . . . . . . .82
6.8 Bus level interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
6.8.1 Bus level interconnection and a high availability solution. . . . . . . . . .84
6.8.2 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Chapter 7. OS/400: Built-in availability functions . . . . . . . . . . . . . . . . . . . .87
7.1 Basic OS/400 functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
7.1.1 Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
7.1.2 Journal receivers with a high availability business partner solution . .88
7.2 Commitment control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
7.2.1 Save-while-active with commitment control . . . . . . . . . . . . . . . . . . . .90
7.3 System Managed Access Path Protection (SMAPP) . . . . . . . . . . . . . . . . .90
7.4 Journal management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
7.4.1 Journal management: Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
7.4.2 Journal management: Costs and limitations . . . . . . . . . . . . . . . . . . .92
7.5 Logical Partition (LPAR) support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
7.6 Cluster support and OS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Chapter 8. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
8.1 Foundations for good performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
8.1.1 Symmetric multiprocessing (SMP). . . . . . . . . . . . . . . . . . . . . . . . . . .95
8.1.2 Interactive jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
8.1.3 Batch jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
8.1.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
8.2 Journaling: Adaptive bundling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
8.2.1 Setting up the optimal hardware environment for journaling . . . . . . .98
8.2.2 Setting up your journals and journal receivers . . . . . . . . . . . . . . . . . .98
8.2.3 Application considerations and techniques of journaling . . . . . . . . . .99
8.3 Estimating the impact of journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
8.3.1 Additional disk activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
8.3.2 Additional CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
8.3.3 Size of your journal auxiliary storage pool (ASP). . . . . . . . . . . . . . .100
8.4 Switchover and failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Part 3. AS/400 high availability solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Chapter 9. High availability solutions from IBM . . . . . . . . . . . . . . . . . . . .105
9.1 IBM DataPropogator/400. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
9.1.1 DataPropagator/400 description . . . . . . . . . . . . . . . . . . . . . . . . . . .106
9.1.2 DataPropagator/400 configuration. . . . . . . . . . . . . . . . . . . . . . . . . .107
9.1.3 Data replication process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
9.1.4 OptiConnect and DataPropagator/400. . . . . . . . . . . . . . . . . . . . . . .108
9.1.5 Remote journals and DataPropagator/400. . . . . . . . . . . . . . . . . . . .109
9.1.6 DataPropagator/400 implementation . . . . . . . . . . . . . . . . . . . . . . . .109
9.1.7 More information about DataPropagator/400 . . . . . . . . . . . . . . . . . .109
vi High Availability on the AS/400 System: A System Manager’s Guide
Chapter 10. High availability business partner solutions . . . . . . . . . . . . 111
10.1 DataMirror Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.1.1 DataMirror HA Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.1.2 ObjectMirror. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.1.3 SwitchOver System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.1.4 OptiConnect and DataMirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.1.5 Remote journals and DataMirror . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.1.6 More information about DataMirror. . . . . . . . . . . . . . . . . . . . . . . . 114
10.2 Lakeview Technology solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.2.1 MIMIX/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.2.2 MIMIX/Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.2.3 MIMIX/Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.2.4 MIMIX/Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.2.5 MIMIX/Promoter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.2.6 OptiConnect and MIMIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.2.7 More Information About Lakeview Technology . . . . . . . . . . . . . . . 119
10.3 Vision Solutions: About the company. . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.3.1 Vision Solutions HAV solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.3.2 Vision Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.3 OMS/400: Object Mirroring System . . . . . . . . . . . . . . . . . . . . . . . 123
10.3.4 ODS/400: Object Distribution System . . . . . . . . . . . . . . . . . . . . . 124
10.3.5 SAM/400: System Availability Monitor . . . . . . . . . . . . . . . . . . . . . 124
10.3.6 High Availability Services/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.3.7 More information about Vision Solutions, Inc. . . . . . . . . . . . . . . . 126
Chapter 11. Application design and considerations . . . . . . . . . . . . . . . . 127
11.1 Application coding for commitment control. . . . . . . . . . . . . . . . . . . . . . 127
11.2 Application checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.3 Application checkpoint techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.3.1 Historical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.4 Application scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.4.1 Single application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.4.2 CL program example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Chapter 12. Basic CL program model . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
12.1 Determining a job step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
12.1.1 Summary of the basic program architecture . . . . . . . . . . . . . . . . . 133
12.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2.1 Distributed relational database. . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2.2 Distributed database and DDM . . . . . . . . . . . . . . . . . . . . . . . . . . 134
12.3 Interactive jobs and user recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
12.4 Batch jobs and user recovery and special considerations . . . . . . . . . . 135
12.5 Server jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.6 Client Server jobs and user recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 137
12.7 Print job recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Part 4. High availability checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Appendix A. How your system manages auxiliary storage . . . . . . . . . . . .141
A.1 How disks are configured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
A.2 Full protection: Single ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
A.3 Full protection: Multiple ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
A.4 Partial protection: Multiple ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
vii
Appendix B. Planning for device parity protection. . . . . . . . . . . . . . . . . . . 147
B.1 Mirrored protection and device parity protection to protect the system ASP. 147
B.2 Mirrored protection in the system ASP and device parity protection in the user
ASPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
B.2.1 Mirrored protection and device parity protection in all ASPs. . . . . . . . . 149
B.2.2 Disk controller and the write-assist device . . . . . . . . . . . . . . . . . . . . . . 150
B.2.3 Mirrored protection: How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Appendix C. Batch Journal Caching for AS/400 boosts performance. . . 153
C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
C.2 Benefits of the Batch Journal Caching PRPQ. . . . . . . . . . . . . . . . . . . . . . . . 153
C.2.1 Optimal journal performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
C.3 Installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
C.3.1 Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
C.3.2 Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
C.3.3 For more information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Appendix D. Sample program to calculate journal size requirement . . . 155
D.1 ESTJRNSIZ CL program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
D.2 NJPFILS RPGLE program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
D.3 Externally described printer file: PFILRPT . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Appendix E. Comparing availability options . . . . . . . . . . . . . . . . . . . . . . . . 167
E.1 Journaling, mirroring, and device parity protection . . . . . . . . . . . . . . . . . . . . 167
E.2 Availability options by time to recover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Appendix F. Cost components of a business case. . . . . . . . . . . . . . . . . . . 169
F.1 Costs of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
F.1.1 Hardware costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
F.1.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
F.2 Value of availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
F.2.1 Lost business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
F.3 Image and publicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
F.4 Fines and penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
F.5 Staff costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
F.6 Impact on business decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
F.7 Source of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
F.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Appendix G. End-to-end checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
G.1 Business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
G.1.1 Business operating hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
G.2 High availability project planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
G.3 Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
G.4 Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
G.4.1 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
G.4.2 Machine rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
G.4.3 Office building. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
G.4.4 Multiple sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
G.5 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
G.6 Systems in current use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
G.6.1 Hardware inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
G.6.2 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
G.6.3 LPAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
viii High Availability on the AS/400 System: A System Manager’s Guide
G.6.4 Backup strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
G.6.5 Operating systems version by system in use . . . . . . . . . . . . . . . . . . . .180
G.6.6 Operating system maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
G.6.7 Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
G.7 Applications in current use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
G.7.1 Application operational hours current . . . . . . . . . . . . . . . . . . . . . . . . . .181
Appendix H. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
© Copyright IBM Corp. 2001 ix
Preface
Availability and disaster recovery represents a billion dollar industry in the United
States alone. Professional associations and institutes, such as the Association of
Contingency Planners, Business Resumption Planning Association, Contingency
Planning and Recovery Institute, and their associated journals and magazines
are devoted to keeping an information system (and, therefore, the business)
available to both internal and external business users. The growth of e-business
further emphasizes the need to maintain system availability.
Implementing a high availability solution is a complex task that requires diligent
effort and a clear view of the objectives to be accomplished. The key to the
process is planning and project management. This includes planning for an event,
such as an outage, that may never occur, and project management with the
discipline to dogmatically prepare, test, and perform for business resumption.
Planning is paramount to the health of a highly available business.
This Redpaper is intended to help organize the tasks and simplify the decisions
involved in planning and implementing a high availability solution. While some of
the most relevent items are covered, this Redpaper cannot cover all cases
because every situation is unique.
To assist IT managers with understanding the most important facts when planning
to implement a high availability solution, detailed information is provided. This
information can help business partners and IBMers to discuss high availability
considerations with customers.
In addition, this Redpaper provides examples of highly available solutions, the
hardware involved in AS/400 availability solutions, and OS/400 operating system
options that add to the reliability of the system in an availability environment.
Application software and how it affects an availability solution are also discussed.
Significant players in the solution are the business partners who provide the high
availability middleware. In addion to discussing their products, a checklist is
provided to help to establish a planning foundation.
Note: A service offering is available from IBM for examining and recommending
availability improvements. Contact your IBM marketing representative for further
information.
The team that wrote this Redpaper
This Redpaper was produced by contributions from a team of specialists from
around the world working at the International Technical Support Organization,
Rochester Center.
Susan Powers is a Senior I/T Specialist at the International Technical Support
Organization, Rochester Center. Prior to joining the ITSO in 1997, she was an
AS/400 Technical Advocate in the IBM Support Center specializing in a variety of
communications, performance, and work management assignments. Her IBM
career began as a Program Support Representative and Systems Engineer in
Des Moines, Iowa. She holds a degree in mathematics, with an emphasis in
x High Availability on the AS/400 System: A System Manager’s Guide
education, from St. Mary’s College of Notre Dame. She served as the project
leader for this redbook.
Nick Harris is a Senior Systems Specialist for the AS/400 system in the
International Technical Support Organization, Rochester Center. He specializes
in server consolidation and the Integrated Netfinity Server. He writes and teaches
IBM classes worldwide in areas of AS/400 system design, business intelligence,
and database technology. He spent 11 years as a System Specialist in the United
Kingdom AS/400 Business and has experience in S/36, S/38, and the AS/400
system. Nick served to outline the requirements and set much of the direction of
this Redpaper.
Ellen Dreyer Andersen is an Certified IT Specialist in Denmark. She has 21
years of experience working with the AS/400 and System/3x platforms. Since
1994, Ellen has specialized in AS/400e Systems Management with a special
emphasis on performance, ADSM/400, and high availabiity solutions.
Sue Baker is a Certified Consulting I/T Specialist working on the Advanced
Technical Support team with IBM in Rochester. She has worked over 15 years with
IBM mid-range system customers, in the industries of manufacturing, transportation,
distribution, education, and telecommunications. She currently focuses on developing
and implementing performance, capacity planning, and operations management
techniques needed in the more complex multiple system and high availabiliy
customer environment.
David Mee is a Strategic Accounts Project Manager in the Global Strategic
Accounts Group of Vision Solutions. He specializes in application and database
design, as well as integration and implementation of high availability solutions
worldwide. He has over 15 years of experience in IBM Midrange systems, and
holds a computer science degree with additional certificates from UCI and UCLA
in RPG, Cobol, Pascal, C and Visual Basic programming languages. He writes
and teaches classes on high availability, mirroring, and application resiliency for
Vision Solutions.
Thanks to the following people for their invaluable contributions to this project:
Steve Finnes, Project Sponsor
Segment Manager, AS/400 Brand
Bob Gintowt, RAS Architecture
Availability/Recovery and Limits to Growth, IBM Rochester laboratory
Fred L. Grunewald
Vision Solutions, Inc.
Glenn Van Benschoten, Director Product Marketing
Lakeview Technology
Michael Warkentin, Senior Product Specialist
DataMirror
xi
Comments welcome
Your comments are important to us!
We want our Redpapers to be as helpful as possible. Please send us your
comments about this or other Redbooks in one of the following ways:
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Send your comments in an Internet note to redbook@us.ibm.com
xii High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 1
Part 1. What is high availability?
Part 1 of this Redpaper discusses what high availability is. Levels of availability
are discussed, as well as outage types, factors comprising an availability plan,
and examples of high availability solutions.
2 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 3
Chapter 1. Background
Early systems were considered available when they were up and running. As the
demands of business, communications, and customer service grew, systems had
to be up and running through the normal working day (usually 8 to 10 hours).
Failures during this working period were not acceptable. In availability terms, this
was a 5 x 8 service (five days at 8 hours each day).
If a system was unavailable during this period, rapid recovery was necessary.
Backups would be restored and the system and the database were inspected for
integrity. This process could take days for larger databases.
These ocurrences eventually led to the definition of availability. In general,
availability means the amount of service disruption that is acceptable to the end
user.
This Redpaper provides insight into the challenges and choices a system
manager may encounter when embarking on a project to make a business more
highly available. This Redpaper does not provide a detailed technical setup of
OS/400 or application products. This information is covered in other technical
publications, for example the AS/400 Software Installation guide, SC41-5120.
1.1 When to consider a high availability solution
When considering if a high availability solution is right for you, ask yourself these
questions:
• Will we benefit from using synchronized distributed databases?
• Do our users need access to the AS/400 system 24 hours a day, 365 days a
year?
• Do our users operate in different time zones?
• Is there enough time for nightly backups, scheduled maintenance, or installing
new releases?
• If our telephone sales application is not always up and running, will we lose
our customers to the competition?
• Is there a single point of failure for any data center?
• Can we avoid the loss of data or access to the system in the event of a
disaster or sabotage?
• When the production machine is overloaded, can we move some users to a
different machine for read only jobs?
A high availability solution can benefit any of these situations.
1.1.1 What a high availability solution is
High (or continuous) availability systems usually include an alternate system or
CPU that mirrors some of the activity of the production system, and a fast
communications link. These systems also include replication or mirroring
software and enough DASD to handle the volume of data for a reasonable
recovery time as shown in Figure 1 on page 4.
4 High Availability on the AS/400 System: A System Manager’s Guide
Figure 1. The basics of a high availability solution
Table 1 outlines some of the requirements of an HA solution. Tally these features
to help simplify your investigation of high availability solutions.
Table 1. Requirements of a high availability solution
Features Solution A Solution B Solution C Data Propagator
24 x 7 availability No
Eliminate downtime for
backup and
maintenance
No
Replication of database Yes
Replication of other
objects
No
Data replication to
non-AS/400 systems
Yes
Handle unplanned
outages
No
Automatically switch
users to a target system
No
Workload distribution Yes
Error recovery Yes
Distribution to multiple
AS/400 systems
Yes
Commitment control
support
Production Machine
Mirroring to one more AS/400s
Backup Machine 2
Backup Machine
Background 5
Figure 2 illustrates a business operating with high availability.
Figure 2. A highly available business
Note the redundancy of communications links, servers, the distributed work
environment, and the use of backup power.
1.2 What high availability is
High availability is a much maligned phrase because it can have different
meanings and is dependant on discussion variables. This Redpaper takes a
holistic approach by discussing high availability as it applies to an organization,
rather than an individual product or feature. This broadens the scope
tremendously and prevents tunnel vision.
Sync checks Yes
Filtering of mirrored
objects
Yes (DB only)
Execute remote
commands
No
OptiConnect support Yes
Utilize Remote Journals Yes
Features Solution A Solution B Solution C Data Propagator
Network
Distribution site
Manufacturing site
Machine room B
AC UPS
AC UPS
Application
servers
Machine room A
Application
servers
Database
servers
Database
servers
Routers
Routers
Customers
Suppliers
Shop floor data
collection
WAN
Network
Network
LAN
Network
Network
6 High Availability on the AS/400 System: A System Manager’s Guide
High availability in this context states that an organization, or part of an
organization, can respond to a third-party request using the organization’s normal
business model. Normal is defined as including set levels of availability. Requests
on the business can be anything, such as a sales call, an inventory inquiry, a
credit check, or an invoice run.
High availability is achieved by having an alternative system that replicates the
availability of the production system. These systems are connected by
high-speed communications. High availability software is used to achieve the
replication. Chapter 10, “High availability business partner solutions” on page
111, discusses these solutions for the AS/400e system.
1.2.1 Levels of availability
Information systems experience both planned and unplanned outages. Systems
can be classified according to the degree to which they cope with different types
of outages.
Your system can be as available as it is planned or designed to be. Orient your
implementation choices toward your desired level of availability. These levels
include:
• High availability: High availability relates to keeping an application available
during planned business (service) hours. Systems provide high availability by
delivering an acceptable or agreed upon level of service to the business during
scheduled periods of operation.
The system is protected in this high availability type of environment to recover
from failures of major hardware components, such as a CPU, disks, and power
supplies when an unplanned outage occurs. This involves redundancy of
components to ensure that there is always an alternative available if
something breaks. It also involves conducting thorough testing to ensure that
any potential problems are detected before they can affect the production
environment.
• Continuous operations: Continuous operations means that a system can
provide service to its users at all times without outages (planned or
otherwise). A system that has implemented continuous operations is capable
of operating 24 hours a day, 365 days a year with no scheduled outage.
This does not imply that the system is highly available. An application can run
24 hours a day, 7 days a week and still be available only 95% of the time
because of unscheduled outages. When unscheduled outages occur, they are
typically short in duration and recovery actions are unnecessary or minimal.
The prerequisite for continuous operations is that few or no changes can be
made to the system. In a normal production environment, this is a very unlikely
scenario.
• Continuous availability: This type of availability is similar to continuous
operations. Continuous availability is a combination of high availability and
continuous operations. This means that the applications remain available
across planned and unplanned system outages and must be implemented on
system, application, and business levels.
Continuous availability systems deliver an acceptable or agreed upon service
7 days a week, 24 hours a day. They add to availability provided by
fault-tolerant systems by tolerating both planned and unplanned outages. With
Background 7
continuous availability, you can avoid losing transactions. End users do not
have to be aware that a failure or outage has occurred in the total
environment.
In reality, when people say they need continuous availability, they usually
mean that they want the application to be available at all times during the
agreed service hours, regardless of problems with, or changes to, the
underlying hardware or software. What makes this more stringent than high
availability is that the service hours get longer and longer, to the point that
there is no time left for making changes to any of the system components.
Note: The total environment consists of the computer, the network,
workstations, applications, telephony, site facilities, and human resources. The
levels of protection that a total environment offers depends on how many of
these functions are wrapped into the integrated solution.
1.3 Determining your availability requirements
When most people are first asked how much availability they require, they often
reply that they want continuous availability. However, the high cost of continuous
availability often makes such requirements unrealistic. The question usually
comes down to how much availability someone can afford.
There are not many applications that can justify the cost of 100% availability. The
cost of availability increases dramatically as you get closer to 100%. Moving from
90% to 97%, for example, probably costs nothing more than better processes and
practices, and very little in terms of additional hardware or software. Moving from
97% to 99.9% requires investing in the latest hardware technology, implementing
very good processes and practices, and committing to staying current on software
levels and maintenance.
At the highest extreme, 99.9% availability equates to 8.9 hours downtime a year.
99.998% equates to just 10 minutes unplanned downtime a year. Removing that
last ten minutes of downtime is likely to be more costly than moving from 99.9%
to 99.998%. What may be more beneficial, and less expensive, is to address
planned outages. In an IBM study, planned outages accounted for over 90% of all
outages. Of the planned ones, about 40% are for hardware, software, network, or
application changes.
Appendix F, “Cost components of a business case” on page 169, helps you
decide if the value of availability to the application justifies the expense.
1.4 Determining how high you need to go
It was previously mentioned that the former version of availability translated into a
customer’s access to the business. A 9 a.m. to 5 p.m. time frame is a valid form of
availability requirement. However, today the terms “24 x 7” or “24 x 365” are more
commonly used. Even high availability is often substituted by the term
“continuous availability”.
The term The 9s is also popular and means a 99% availability. On its face, this
seems like a high requirement. However, if you analyze what this value means in
business terms, it says that your process is available 361.35 days per year. In
8 High Availability on the AS/400 System: A System Manager’s Guide
other words, for 3.65 days, the process is not available. This equates to 87.6
hours, which is a huge and unacceptable amount of time for some businesses.
In recent press articles, up to $13,000 a minute has been quoted as a potential
loss. This is a $68,328,000 a year lost potential. It is not difficult to justify a high
availability solution when confronted by these sorts of numbers. However, it is one
of the lessons to learn as well as an obstacle to block and tackle. The business
can potentially lose this amount of money. When planning for a high availability
solution, convincing the business to commit to even a fraction of this amount is
difficult. However, use any recent unplanned or planned outages to estimate the
cost.
It is recommended that you start with a departmental analysis. For example, how
much would it cost the business if the salespeople could not accept orders for two
hours due to a system failure?
To continue using the 9s, add .9% to your figure of 99%. This now equals 99.9%
availability. Although this is obviously very close to 100%, it still equates to 8.76
hours. The AS/400e has been quoted as offering 99.94% availablility or 5.1 hours.
This is according to a recent Gartner Group report, “AS/400e has the highest
availability of any stand-alone, general business server: 99.94 percent” (“Platform
Availability Data: Can You Spare a Minute?” Gartner Group, 10/98). This applies
to the hardware and operating system and unplanned outages. It does not apply
to application or scheduled outages.
1.5 Estimating the value of availability
The higher the level of availability, the higher the investment required. It is
important to have a good understanding of the dollar value that IT systems
provide to the business, as well as the costs to the business if these systems are
not available. This exercise can be time consuming and difficult when you
consider the number of variables that exist within the company. Some companies
delay the analysis.
Once the value of the availability of your IT services is determined, you have an
invaluable reference tool for establishing availability requirements, justifying
appropriate investments in availability management solutions, and measuring
returns on that investment.
The estimation process should:
• Analyze by major application or by services provided: The major cost of
an outage is the cumulative total of not having the applications available to
continue business.
• Determine the value of system availability: It is not easy to determine the
cost of outages. The inaccessibility of each application or program has varying
effects on the productivity of its users. Start with a reasonable estimation of
what each critical application is worth to the business. Some applications are
critical throughout major portions of the day, while others can be run any time
or on demand.
• Look at direct versus indirect costs: Direct costs are the time and revenue
lost directly because a system is down. Indirect costs are those incurred by
another department or function as a result of an outage. For example, a
Background 9
marketing department may absorb the cost of a manufacturing line being shut
down because the system is unavailable. This is an indirect cost of the outage,
but it is nonetheless a real cost to the company.
• Consider tangible versus intangible costs: Tangible costs are direct and
indirect costs that can be measured in dollars and cents. Intangible costs are
those for which cash never changes hands, such as lost opportunity, good will,
market share, and so on.
• Analyze fixed versus variable costs: Fixed costs are direct, indirect,
tangible, or intangible costs that result from a failure, regardless of the outage
length. Variable costs are those that vary with the duration of the down time,
but that are not necessarily directly proportional.
For more detailed calculations and methodology, refer to So You Want to Estimate
the Value of Availability, GG22-9318.
1.6 iSeries factors for maximum availability
The IBM ~ iSeries and AS/400e systems are renown for their availability
due to a number of factors:
• Design for availability:
A single iSeries server delivers an
average of 99.9+% availability.
According to data collected by IBM
over the last two years, AS/400 and
iSeries owners have experienced an
average of less than nine hours of
unplanned down time per year. Figure
3 indicates two out of three factors of
unplanned outages that can be
affected by proper design. IBM
delivers a very reliable server
because the IBM Development team
designs, creates, builds, tests, and services the iSeries and AS/400 systems
as a single entity.
• Effective system management process:
As noted in Figure 4, 90 percent
available translates to 36 days. Lack of
attention to system management
disciplines and processes affect the
availability achieved. Availability
solutions, such as clusters, are
undermined when system
management processes are lacking or
nonexistent.
An effective system management
strategy ties heavily into automation,
such as an automatic archival of data, continuous system auditing, responding
to security exposures, and monitoring error logs, backup and restores, and so
on. A quote by Gartner Group puts this in perspective: By the year 2003,
“100% availability will remain elusive as user-controlled disciplines have an
40.0%
40.0%
20.0%
Hardware,
disasters,
power
Operator
Error Application
Failure
Figure 3. Unplanned outage factors
Availability
Percentage
99.9999
99.999
99.99
99.9
99
90
Total Outage
Per Year
32 seconds
5 minutes
53 minutes
8.8 hours
87 hours (3.6 days)
876 hours (36 days)
=
=
=
=
=
=
Figure 4. Unplanned outage factors
10 High Availability on the AS/400 System: A System Manager’s Guide
ever-greater relative impact on achieving availability” (Gartner Group, June
Conference, Dallas, Tx., 1997).
An investment in system management disciplines, automation, and application
recovery is necessary. Just a few additional hours of yearly downtime reduces
availability from 99.99% availability to 99.9%.
• Increase automation:
Increased availability means a reduction in the possibility of errors and
recovery delays, and an increase in consistency. Human errors can create
more down time than hardware failures or power outages. More effective
automation through the use of automation software and tools can help offset
an overburdened staff and allow them to attend to more unique and critical
decisions and tasks. As availability requirements increase, investments in
automation must also increase.
• Exploit availability techniques and applications designed for availability:
Decrease unplanned outages and their effects by utilizing server availability
options (for example, disk protection) and OS/400 functions, such as access
path protection, file journaling, and user auxiliary storage pools (ASPs).
Target a phased approach at increasing application resiliency (recoverability)
and availability. As a general rule, an application on a non-clustered system is
difficult to recover. A cluster solution cannot overcome a poor application
design.
Use applications that incorporate commitment control or other transaction
methods, and use application recovery to decrease application recovery times
and database integrity issues (incomplete transactions). You must use
journaling and application recovery techniques to achieve high availability at a
minimum. More sophisticated and highly available applications also use
commitment control. Each technique is a building block foundation to all highly
available environments.
• Implement special solutions to meet your availability goals:
To reach your availability goals, special solutions, such as iSeries or AS/400
clusters with monitoring, automatic switchover, and recovery automation, are
implemented to control both planned and unplanned outages. If you sidestep
the issues described above, even sophisticated options like clusters may not
provide the highest possible availability levels. Small outages, such as
recovering or reentering transactions, add up.
1.7 Scheduled versus unscheduled outage
Many Information Technology departments have a good understanding of disaster
recovery protection, which includes unscheduled outages. It can also involve
anything from dual site installations to third-party vendors offering disaster
recovery suites. Most of these installations provide protection from fires, floods, a
tornado or an airplane crash on the site. The instance of the dangers affecting the
site are very rare, but, if they do happen, they are catastrophic.
Scheduled outages can impact a business’ financial well-being. Strong focus is
warranted to plan for and minimize the time involved for scheduled outages.
There has been little focus in this area, except for hardware and software
vendors.
Background 11
1.7.1 Scheduled outages
A scheduled outage is a form of planned business unavailability. Scheduled
outages include a production line shutdown for maintenance, the installation of a
new PABX, resurfacing the car park, or the entire sales team leaving town for a
convention. All of these can influence the smooth operation of the business and,
therefore, the customers.
In I/T terms, these outages may be due to a hardware upgrade, operating system
maintenance or upgrade, an upgrade of an application system, network
maintenance or improvements, a workstation maintenance or upgrade, or even a
nightly backup.
The focus of outage discussion is shifting from unplanned outages (disasters,
breakdowns, floods, and the like), to planned outages (primarily nightly backups,
but also upgrades, OS/400 updates, application updates, and so forth). A growing
solution is to consolidate individual systems onto large systems, rather than
install distributed systems in departments or subsidiaries. This suggests that you
may have users in different time zones, which can further minimize or eliminate
the time available for routine operations, such as a backup. With a high availability
solution and mirrored systems, customers can perform their daily backup on the
backup system and let the users and work be done on the production system at
the same time.
1.7.2 Unscheduled outages
Unscheduled outages include obscure occurrences. As mentioned earlier, these
can include such things as fires, floods, storms, civil unrest, sabotage, and other
assorted happenings. These outages are fairly well recognized and many
organizations have disaster recovery plans in place to account for these types of
occurrences. Testing these disaster plans should not be overlooked. We identify
this in Appendix G, “End-to-end checklist” on page 175.
1.8 Comparison to planned preventive maintenance (PPM)
When researching this Redpaper, the authors found that there are only a few
publications that relate to high availability for Information Infrastructure within
organizations. They then looked laterally and found some good sources regarding
practices and processes in the engineering aspect.
For many years, most manufacturing companies ran their businesses based on
sound planned preventive maintenance programs. These programs cover the
plant systems and services that support the manufactured product. Companies
have long understood terms such as resiliency, availability, mean time to failure,
and cost of failure.
To define the planned preventive maintenance schedule for a production line is a
very complex operation. Some simple examples of the high level tasks that need
to be performed include:
• Documenting a business plan: This includes business forecasts, current
product forecasts, new product forecasts, and planned business outages
(vacation, public holidays).
12 High Availability on the AS/400 System: A System Manager’s Guide
• Documenting environmental issues: This includes the frequency of power
failures, fires, storms, floods. This also includes civil issues, such as unrest,
strikes, layoffs, and morale.
• Documenting the processes used: This includes throughput, hours of
operation, longevity of the product, and planned product changes.
• Taking inventory of all parts involved in the process: This includes
purchase costs, purchase dates, history, quality, meantime to failure,
replacement cycles, and part availability.
• Documenting the maintenance and replacement process
• Estimating the cost for running the process and comparing it to the value
of the product
• Estimating the affordability of a planned preventive maintenance
program
• Documenting the resources required to manage the process: This
includes job specifications, critical skills, and external skills.
These tasks can be compared to the following tasks in the Information
Management area. Imagine these refer to an application that supports one part of
the business:
• Documenting the business plan: This includes business forecasts, current
business forecasts that the application supports, business growth in this
application, planned business outages (vacation, public holidays).
• Documenting environmental issues: This includes the frequency of power
failures, fires, storms, floods. This also includes civil issues, such as unrest,
strikes, layoffs, and morale.
• Documenting the processes used: This includes throughput, hours of
operation, longevity of the application, and planned application changes.
• Taking inventory of all parts involved in the application: This includes
purchase costs, purchase dates, history, quality, application failures,
replacement cycles, hardware required to run the application, software
maintenance schedules, software fix times, time required to implement ad hoc
fixes, and developer availability.
• Documenting the maintenance and replacement process
• Estimating the cost for running the application and comparing it to the value of
the business area
• Estimating the afford ability of making the application highly available program
• Documenting the resources needed to manage the application: This
includes application specifications, job specifications, critical skills, and
external skills.
This information is parsed into smaller sizes that can be applied to any business.
1.9 Other availability definition considerations
Designing a solution for high availability requires a practical knowledge of the
business. The solution should fit the design of the business operations and
structure. Does the organization have an accurate and approved business
Background 13
process model? If it does, a major portion of the solution design is easy to plan. If
there is no business process model, do not make assumptions at this stage. It is
critical to get accurate information since this is the foundation of your plan.
Identify the systems and end users of each part of the business process model.
Once identified, you have the names of people to relate, in practical terms, just
how high is high availability.
14 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 15
Chapter 2. Developing an availability plan
For maximum availability, it is very important that planning is performed for the
operating system, hardware, and database, as well as for applications and
operational processes. As indicated in Figure 5, the level of availability is affected
by products and use of technology. An unreliable system, poor systems
management, security exposures, lack of automation, and applications that do
not provide transaction recovery and restart capability weakens availability
solutions.
Achieving the highest
possible level of availability
is accomplished using
clustering software,
hardware solutions, and the
planning and management
of high availability products.
An availability plan also
needs to consider other
factors that influence the
end result, such as
organizational and political issues. It is important to understand the challenges
involved in each implementation phase to find the most appropriate tools and
techniques for the customer environment.
The need for higher availability can be relaxed by determining what a business
actually needs and what is possible using the available technology. In reality, most
applications can withstand some planned outage, either for batch work, backups,
and reorganization of files, or to affect application changes. In most cases, the
application is expected to be available at the host, or perhaps on the network that
is owned and controlled by the organization. However, continuous availability in
the environment outside the control of the organization (that is, on the Internet) is
not normally included in the business case.
This chapter explores the basic recommendations for planning for system
availability. Start by looking at the needs of the business and the information
necessary to support it. These actions are separated into the following areas:
• Reviewing the business plan
• Understanding the human resources issues
• Dealing with third party contracts
2.1 The business plan
This section gives the reader an insight into the information that is gathered from
the business. Some of this is found in the business plan and some from
investigating individual departments.
Why do you need all this information? To make the business and application
highly available, you must take a wider view than just maintaining access to the
information (system). It is not enough to have the most highly available system if
the telephone system fails and no one can contact your company.
2) Effective
Systems
Management
4) Application
Design and
Techniques
5) iSeries
and
AS/400
Clusters
1) Products,
designed for
reliability 3) AUTOMATION
Level of Availability 100%
C
osts Figure 5. Essentials for maximum server availability
16 High Availability on the AS/400 System: A System Manager’s Guide
When you gather this information or interview staff within the company, you may
be questioned as to why you need this information. Some co-workers may deny
access to the information itself while some co-workers may roadblock your
access to the people with the information. In cases such as these, your executive
sponsor plays a very important role. The roadblocks you find can be easily
avoided with the sponsor’s help.
2.1.1 Project scope and goal definition
The business case, the driving reason for the high availability project, can be
used as the starting point for defining the goals and understanding the scope of
the project. Requirements and goals should be gathered from any department or
party affected by system management. The project team must prioritize the
requirements according to their urgency, importance, and dependencies, and to
be able to define the short and long term goals.
Success criteria and completion criteria should be defined appropriately.
Quantifiable results are essential. Even if it is an intangible benefit, such as
customer satisfaction, you need to provide concrete methods to measure them.
To verify the requirements and goals, several starting points can be used:
• Look for established solutions for special requirements.
• Find out whether it is possible to develop a solution in a reasonable amount of
time and with a reasonable amount of resource.
• Visit reference sites.
• Discuss the requirements with experienced consulting teams.
After this work is done, the first draft of the project definition is ready. Show it to
the executive steering committee to get feedback as to whether it reflects their
vision.
The results from this meeting are the central theme for elaborating on the detailed
project definition. Input for this step includes:
• Requirements
• All information
• Type of politics
• Vision
The result is a clear and unambiguous definition of the scope and the goal
definition.
2.2 Human resources
Producing an availability plan is not a single-threaded process, and it can not be
built on one person’s view. It is critical to build a team. The team should represent
the needs of those they represent. Members must understand the department
problems, be a voice for their challenges, be able to communicate their needs,
and support an action plan.
A good project group is critical to this type of planning project. The activities of
the business are diverse, represented by members bringing a diverse set of
needs and views regarding both the problems and solutions,
Developing an availability plan 17
There will be some very tough times, long hours, and unease as the project
progresses. Determination, empathy, and leadership are valued skills for the team
makeup.
Take a look at existing resources with an emphasis on your existing staff. In many
cases, the skills required can be found within your staff. In other cases, it makes
more sense to look outside the staff for the required talents. The final makeup of
the team may represent both personnel inside and outside the company (or the
department, if the study is of a more-focused nature).
2.2.1 Project organization
The organization of the project team can be categorized in two parts: the
members of the team, and the other organization parties involved. Many different
skills are required on the team. Criteria for the suitability of each team member
includes their skills as well as their availability and personal characteristics, such
as how they work on a team, negotiation skills, and knowledge of the technical
solution, as well as the workings of the company. A suitable project manager
should be selected from within or outside the company. The project manager is
the “face” of the project and is responsible for the total health of the project,
ensuring that the objectives and goals are met in the highest quality fashion
within the specified time schedule and budget.
When the team is built, a lot of communication is necessary. Regular status
meetings should be held to communicate and assess the actual status of the
project, checkpoint the progress, make short-term decisions, and assess
remaining activities. The sponsoring executives should be informed of the status
in regular meetings.
Consider providing an office workspace for the project team, and supply it with
applicable reference material for the subject area and company. Sometimes
management chooses a project manager from outside the company. Sometimes
an organization expert joins the project team to provide the project manager with
knowledge about the internal structures of the company.
2.3 Communication and sponsorship
The support of the company’s management to the project is critical to its success.
The ultimate responsibility for the project should lay with an executive steering
committee, or an executive serving as a contact between the team and
executives. The steering committee represents the management involvement and
sponsorship. It can be used to solve complications with other parts of the
organization, communicate expectations to affected company parties, and
provide decision making power.
The vision of the project scope and objectives should be made clear to everyone
involved. This vision must be broadly communicated through the entire
organization so that everyone can be aware of the consequences the project has
for them. Reactions, especially negative, should be taken seriously and should be
used to reach a clearer project vision. Pay special attention to communication
because this can prompt people to bring their ideas into the project.
18 High Availability on the AS/400 System: A System Manager’s Guide
Non-technical aspects should be emphasized in the project plan so that
non-technical people involved can better adopt the project as their own. If it is
appropriate, consider having a customer or supplier representative on the team.
2.4 Service level agreements
Service level agreements are contracts with business departments within your
company and, in many cases, businesses with whom you have an external
contractual relationship. If your network resources are not up and running, you
can not keep these commitments.
Within your company, service requirements probably differ by department. For
example, your accounting department may be able to tolerate down time of the
accounting applications for up to one hour before it starts negatively impacting
department operation. Likewise, marketing may agree to a calendar three-hour
down time, but it can allow only an hour of down time on a customer-reference
database.
You make service level agreements to track your IT organization’s performance
against business requirements. Based on these agreements, set priorities and
allocate limited IT resources. By linking your IT department to your service desk,
you can manage complex relationships among user problems, corporate assets,
IT changes, and network events.
System management can provide a centralized view of your current asset
inventory. This enables your analysts to correctly analyze and resolve problems.
Help desk analysts work with administrators to plan and manage the effects of
such IT changes as deploying and upgrading applications. System management
involves tracking, logging, and escalating user interactions and requests.
2.5 Third party contracts
Service level agreements outside your company can mean a loss of business to a
competitor if you can’t meet your commitments. This can have serious
consequences for your company.
Most organizations have contracts with external suppliers. However, the third
parties are not all typically under the control of one department. As a Systems
Manager implementing a high availability solution, you interface with many
different aspects of your organization to gather the required information and
possibly change the contracts to meet your new needs.
Contractors or resources utilized from outside the company represents
programmers, technicians, operators, or a variety of consultants.
2.5.1 Application providers
The AS/400 system gets its name from Application System. The majority of
AS/400 customers have one or many applications installed on their AS/400
system and the attached workstations.
When reviewing the application, establish how the provider supports your
business and determine the required level of support. This can range from a 9
a.m. to 5 p.m. telephone support provider contract, to employing developers
Developing an availability plan 19
skilled with the particular application. The more critical the application, the higher
level of skills that are required to perform problem determination that enables the
fix to be resolved in the shortest possible time.
The application provider should be able to define the rough release schedule for
the application. This allows you to plan for application system updates. They
should also be able to provide varying levels of fix support if the application fails
in some way.
Develop an escalation process for critical failures. Think through and document
what steps to follow to recover from a critical failure.
Note: This information applies to applications written outside the company. The
same considerations apply for applications developed in-house.
2.5.2 Operating system provider
Operating system suppliers are similar to application providers. However, the
opportunity to enhance the operating system code typically occurs more
frequently than application providers code. Enhancements to the OS/400
operating system typically occur with an annual frequency. Updates occur more
frequently on application software.
2.5.3 Hardware providers
Hardware provided by non-IBM distribution channels can include:
• CPUs
• Towers
• Tapes
• DASD
• IOPs
• Workstations
• Printers
Contracting with hardware providers is a relatively simple method to utilize
resources outside the company. The contractor’s reliability is normally well known
and high. Maintenance organizations are highly skilled and can provide high
levels of service, depending on the cost. At minimum, the hours of coverage for
support should match your planned availability requirements.
Many large customers have arrangements for key supplies to be “warehoused” at
the customer site. In other words, the supplies are owned by the maintainer but
are stored at the customer site.
Be careful when ordering new hardware. Order only with a goal that ensures
availability of spare parts early in the product life. Demand for a product can be so
great that there are no spare parts available.
2.5.4 Peripheral equipment
The hardware components of a computing system go beyond the central
processing unit and controllers. To reach end users, a computing system includes
peripheral equipment, such as workstations, printers, routers, and modems.
20 High Availability on the AS/400 System: A System Manager’s Guide
Maintaining peripheral equipment can be difficult. You must judge the benefits of
maintaining parts and components on-site for fast replacement, compared to a
repair contract for the main equipment or a combination of both. Consider the
longevity of the peripherals. For example, when printers, displays, modems and
such are replaced, it is not uncommon to update the technology.
Sometimes, a replacement is made as an upgrade of functionality, either because
the former model is withdrawn from sales and support, or the needs of the users
require more function than the broken unit. It is not uncommon (perhaps even
typical) for the replacement unit to provide equivalent or more function for less
cost to the business.
At first glance, replacing technology may not seem to be a big problem. For
example, consider the case of a printer connected to a personal computer that is
used by others within the network.
Assume this departmental printer fails and is non-repairable. One solution is to
simply replace the printer. However, after the new printer arrives and is
connected, it needs a new driver loaded on the server operating system. The load
of the new driver can raise a number of significant issues:
• Is an IPL required to be recognized by the system?
• Is a configuration required?
• Do the applications work with the new driver?
• What if the load causes the server to fail?
This circumstance can result in driver loads across the whole network that reduce
the hours of productive business.
Therefore, even the smallest components of the total environment can have a
major impact. It is advised that you plan for some redundancy, including when
and how you carry out bulk replacements.
2.5.5 Facilities
Facilities include machine rooms, power supplies, physical security, heating and
air-conditioning, office space, ergonomics, and fire and smoke prevention
systems to name but a few. The facilities that complete the total environment are
as complex as the applications and computer hardware.
2.5.5.1 Site services
It is important to work alongside the site facilities personnel and to understand
contracts and service levels. For example, turning off the air conditioning for
maintenance can potentially have a disastrous effect on the systems in the
machine room. The contract with facilities should include spare air-conditioners or
the placement of temporary mobile conditioners.
2.5.5.2 Machine rooms
A good system manager has a well documented understanding of the machine
rooms and the equipment within. The same redundancy requirements should be
placed on critical services just as there are on computer systems.
Developing an availability plan 21
2.5.5.3 UPS
The use of Uninterruptible Power Supplies (UPS) has grown tremendously over
the past ten years. The cost of a small UPS has reduced and they are now very
affordable.
When considering a UPS, keep in mind these three broad areas:
• Machine Room: The machine room is a prime candidate for a UPS because it
often requires continuous power. The ultimate solution is to generate your own
power. Ideally, the national power supply serves only as a standby, with limited
battery backup. Some customers do have this arrangement, but it is an
expensive solution. There are simpler solutions that provide nearly the same
level of service.
Consider switching to a generated power environment. When the power fails,
the standby generator starts. Unfortunately, there is a time lag before the
system comes on line. Therefore, an interim battery backup is needed to
support the systems while the generated power comes online. To register that
the power has failed and then switch between battery, generator, and back to
normal power requires a complicated and expensive switch. It may also
require links to the systems to warn operators of the power failure.
Another area that is often overlooked is the provision over power supplies for
other equipment in the machine room, for example, consoles, printers, and
air-conditioning. It is not enough to have a UPS for the system if there is no
access to the console. In an extreme condition, you may be unable to shut the
system down before the battery power fails if there is no UPS support for the
console.
• The site: When considering the site, you must look at all areas, for example:
– If you have a disaster recovery service, is there space to park the recovery
vehicle in the car park close to the building to attach network cabling?
– In some buildings, access to the machine room is a problem and systems
must be moved through windows via a crane because the lifts are too small
or cannot take the weight.
– Are there high availability facilities in the general office space, such as an
emergency telephone with direct lines in case the PABX fails. This allows
the business to continue even if the desk phones fail.
When developing the availability plan, document these restrictions and plan for
circumventions.
• The workstation: Key users may need backup power to their workstation if
there is no full standby generation.
Looking at workstations from an ergonomic view, you may find potential issues
that can result in long term unavailability of the human resources. An example
is repetitive strain injury. This can severely impact your critical human
resources in a company and cost a significant amount in litigation.
It is worth investing time and money to solve these problems when planning
for availability.
22 High Availability on the AS/400 System: A System Manager’s Guide
2.6 Verifying the implementation
Verifying (by testing) the proposed high availability solution before putting it into
production cannot be over-emphasized. Some of the activities involved in testing
the implementation are explained in the following list (several areas of verifying,
or testing, are involved):
• Build a prototype: A prototype is a simulation of a live production. Develop a
prototype to test the quality of the high availability solution. Make sure it can
be easily reproduced. This lowers the risk of disturbing production during
installation rollout.
• Regression tests: Ensure that the replicated solution works in the same way
as the prototype by performing a number of regression tests in the new
environment. These same tests should be used in the production environment
to ensure the quality of the final high availability implementation.
• Disaster recovery test: Develop routines to ensure that a disaster recovery is
smooth and as fast as possible. This requires a real crash test with detailed
documentation of the steps required to get the system up and running,
including how long it takes and where to find backup media and other required
material.
• Volume test: Few companies have the resources to build a test environment
large enough to do realistic tests with production-like volumes. Some recovery
centers and business partners offer the use of their environments for
performing tests in larger volumes. It is an important step to help ensure that
the system behaves as expected during the actual production.
2.6.1 Documenting the results
To retest the systems after a problem has been fixed, it is important to have every
test situation well documented. The documentation should include:
• Hardware requirements
• Software requirements
• HAV requirements
• A test case category
• Tools required to perform the test
• A list of steps to execute the test case
• Results of the test (pass or fail)
• The name of the individual executing the test case
• The date on which the test case was executed
• Notes taken while the case is executed
• Anticipated results for each step of the test case
• Actual results
• Comments on general notes for each test case.
• A list of any problem records opened in the event that the test was not
successful
2.7 Rollout
The testing sequence ends with the confirmed rollout of the solution. The rollout
is another milestone in the overall project. For the first time, the production
environment is actually affected. A well designed rollout strategy is crucial. Many
things can impact the success of the rollout. Carefully check all prerequisites.
Developing an availability plan 23
In a typical rollout, a great number of people are affected. Therefore,
communication and training is important. For the rollout into production volumes,
sufficient support is required. A minor incident can endanger the production
rollout.
The basic infrastructure of the company influences the rollout process. The
situation differs depending on the industry area.
The risk of problems increases with the number of external factors and the
complexity of the system. The ideal case is a monogamous environment with all
equipment owned by the company, including a high-performance network. All
success factors can then be planned and controlled within individual
departments.
The main issue of the rollout is characterized by finding the appropriate rollout
strategy. The project can begin in phases or all at once. A test scenario can
validate the proper rollout. As the final proof of concept, a pilot rollout should be
considered.
Consider business hours and critical applications. Minimize the risk by taking
controllable steps. The rollout can include down time for the production system.
Therefore, timing must be negotiated with all concerned people. The rollout can
take place inside or outside of business hours. Remember that some of the
required prerequisites may not be available at these times.
A project planning tool is helpful. Lists of resources, availability of resources, time
restrictions, dependencies, and cost factors should be documented. Provide a
calendar of activities, black-out dates, and milestones.
24 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 25
Chapter 3. High availability example solutions
As companies increase their dependency on technology to deliver services and to
process information, the risk of adverse consequences to earnings or capital from
operational failures increases. If technology-related problems prevent a company
from assessing its data, it may not be able to make payments on schedule, which
would severely affect its business. Costly financial penalties may incur, the
company’s reputation may suffer, and customers may not be able to deliver
services or process information of their own. The company may even go out of
business all together.
Technology-related problems can increase:
• Transaction risk: This arises from problems with service or product delivery
• Strategic risk: This results from adverse business decisions or improper
implementation of those decisions
• Reputation risk: This has its source in negative public opinion
• Compliance risk: This arises from violations of laws, rules, regulations,
prescribed practices, or ethical standards
Every customer has their own unique characteristics. The implementation of a
high availability solution is customized to customer needs and budgets, while
keeping in mind the risks of encountering and recovering from problems. This
chapter describes examples of customer requirements and the high availability
solutions they choose.
3.1 A high availability customer: Scenario 1
A Danish customer with 3,000 users on a large AS/400 system had difficulty
finding time to complete tasks that required a dedicated system for maintenance.
These tasks included such operations as performing nightly backups, installing
new releases, and updating the hardware.
One reason this challenge occurred is because the customer′s AS/400 system
was serving all of their retail shops across Scandinavia. As these shops extended
their hours, there was less and less time for planned system outages.
They solved their problem by installing mirroring software on two AS/400
systems.
To increase availability, the customer bought a second AS/400 system and
connected the two machines with OptiConnect/400. Next, they installed mirroring
software, and mirrored everything on the production machine to the backup
machine. In the event of a planned or an unplanned system outage, the system
users could switch to the backup machine in minutes.
This solution made it easy for the shops to expand their hours and improve sales
without losing system availability or sacrificing system maintenance.
26 High Availability on the AS/400 System: A System Manager’s Guide
3.2 A large financial institution: Scenario 2
Financial services typically require the most highly available solutions. Risks
affect every aspect of banking, from interest rates the bank charges to the
computers that process bank data. All banks want to avoid risk, but the risk of
equipment failure and human error is possible in all systems. This risk may result
from sources both within and beyond the bank’s control.
Complete details of and a general outline of the SCAAA Bank’s new hot backup
configuration are provided in the following list:
• An original production AS/400e Model 740 in Madison
• A Model 730 backup AS/400e at IBM’s Chicago Business Recovery Services
Center
• Both machines running the same level of OS/400 (V4R5)
• High availability software applications transferring data and objects from the
customer applications on the production machine to those on the backup
machine
• TCP/IP communications protocol used for communications with the BRS
Center
• A T1 line from the Madison branch to IBM’s POP server in Chicago, where IBM
is responsible for communications from the POP server to the BRS center
SAAA Bank of Madison, Wis., is no exception. SAAA specializes in commercial
and institutional banking, and it provides comprehensive financial services to
other banks, governments, corporations, and organizations. It has received AAA,
Aaa and AAA ratings from Standard and Poor’s, Moody’s, and IBCA (Europe’s
leading international credit rating agency), respectively. It has offices around the
world, with over 5,200 employees woking in commercial centers worldwide.
The Madison branch provides services to U.S. companies and subsidiaries of
German corporations in North America. The Information Systems department of
the Madison branch is intimately involved with the actual business of the bank,
not just its computers.
On a typical day, the workload consists of foreign exchange transactions, money
market transactions, securities transactions, options transactions, and loans. The
IS department sees every transaction that goes through and does the utmost to
ensure that each one executes accurately and promptly. Given the profitability of
the Madison branch, the IS department plays a major role in the success of the
bank as a whole.
The core data is largely stored on an IBM AS/400e system. Protecting the bank’s
data means eliminating all single points of failure on that platform. Prior to 1997,
the bank took the following steps to ensure business continuity:
• Running regular backups, even making midday backups
• Adding a redundant token-ring card to prevent system failure
• Eliminating cabling problems by using an intelligent hub
• Providing dual air conditioning systems to address environmental variables
High availability example solutions 27
• Installing universal power supplies (UPSs) to permit system operations during
electrical failure
• Providing RAID5 to maintain parity information across multiple disks
• Installing a second RAID controller to manage the array when the original
controller fails
• Leasing twenty seats at the IBM Business Recovery Services (BRS) Center in
Sterling Forest, NY, so that the essential work of the bank can be carried out in
the event of a disaster
After recognizing the bank’s exposure to possible data loss, the bank chose
MIMIX Availability Management Software. Running high availability software over
a WAN to the BRS Center protects from all risks of data loss.
The high availability software solution at SAAA Bank was modified to meet the
demands of the bank’s daily schedule. This adjustment was necessary because
the applications required journaling to be turned off at the end of the day to
facilitate close-of-business processing. This is a characteristic that makes them
somewhat difficult to replicate. The bank accomplished this through an elaborate
process.
During the day, the bank turned on AS/400e journaling capabilities, but at the end
of the business day, the bank shut down MIMIX and the journal files for both
systems. At about 6:30 p.m., the bank ran close-of-business processing on both
machines simultaneously. This way their databases remained synchronized.
About two hours later, when the processing was complete, the bank restarted
journaling on both machines and MIMIX was brought back up. The next morning,
high availability software started replicating the day’s transactions. The entire
process was automated, but an operator was always available in case of an
emergency. The flexibility of MIMIX enabled the bank to keep the databases in
synch at all times.
In 1998, a potentially serious incident occurred at the bank. An operator working
on the test system meant to restore some data to the test libraries. Unfortunately,
they were copied and loaded into the production system. This overwrote all
payments that had to be sent out later that afternoon, leaving the bank in a critical
position.
After detecting the error, the operator immediately switched over to the mirrored
system on the backup machine located at the BRS center. That system held a
mirrored, real time copy of all the bank’s transactions for the day. By clicking a
button, the operator initiated a full restore from the backup system to the
production system, ensuring synchronization of the two databases. This process
required only about 25 minutes.
Without high availability application software (MIMIX) the bank would have had to
restore from a mid-day backup (which requires about 10 hours worth of work). In
addition, about 20 bank staff members would have had to return to the bank and
re-enter all the lost transactions at overtime rates. The estimated costs of these
activities was around $28K. Even greater costs would have resulted from the one
day interest penalties for late or nonexistent outgoing payments.
The fastest and most comprehensive way to ensure maximum uptime and high
availability is through added redundancy and fault-tolerant models. With the
28 High Availability on the AS/400 System: A System Manager’s Guide
implementation of high availability software (MIMIX) at the BRS Center, the bank
achieved the highest level of disaster prevention and continuous operations in
over 20 years. The strategy provided the availability management, flexibility, and
reliability needed to maintain business continuity in the event of a disaster at the
location.
3.2.1 Benefits
Looking back, SAAA Bank found that using high availability management
software at the BRS center provided these benefits:
• Maintained uninterrupted business processing, despite operator errors and
environmental disasters, such as floods, fires, powers outages, and terrorist
acts
• Dramatically reduced the cost of disasters, especially disasters that arise at
the user level
• Sustained the bank’s reputation for reliability: Because the bank acts as a
clearing house for several other banks, SAAA Bank had to ensure that the
system was operational and that payments were sent out in a timely manner
• Simplified the recovery process: High availability software freed the IS
department from lengthy restore projects and eliminated the need to spend
time and money re-entering lost data
• Enabled the IS department to switch to the backup database at the BRS
center when required
3.3 A large retail company: Scenario 3
Retailing is a new area for very high availability. As retail companies enter the
area of e-commerce, the business demands are considerable. Companies
operating in a global marketplace must have their systems online 24 hours a day,
every day, all year long.
This section describes an example of a large retail company, referred to as EDA
Retail for the purposes of the discussion.
EDA Retail is a Danish lumber wholesale business. They also own and run a
chain of hardware retail stores across Denmark, Norway, and Sweden, supplying
everything for the do-it-yourself person. These hardware stores run a
Point-of-Sale (POS) solution from IBM, which connects to a large AS/400 system.
At the time this information was gathered, the system was a 12-way model 740
with 1 TB of DASD. All inventory and customer data is stored on this one AS/400
system.
The connection to the AS/400 system is the lifeline to all of the stores. If the
connection to the AS/400 system is down, or if the AS/400 system is not up and
running at all times, EDA Retail employees cannot take returns, check inventory,
check customer data, or perform any related functions while selling goods to their
customers.
The unavailability of information developed into a unacceptable problem for EDA
Retail. They had grown from a big to a very large enterprise during the four years
from when they installed the AS/400 system. Management determined that a
breakdown of the AS/400 system would cost the enterprise about 40,000 U.S.
High availability example solutions 29
dollars per hour. In addition, planned shutdowns, such as that necessary for the
daily backup, system maintenance, upgrades, and application maintenance were
becoming a problem. The problem multiplied when a chain of stores in Sweden
was taken over and expected to run on the EDA Retail’s system. These acquired
stores had longer opening hours than the corresponding stores in Denmark,
which increased the necessity for long opening hours of the AS/400 system at
EDA Retail.
The IBM team did a thorough analysis of EDA Retail’s installation in order to
develop an environment with no single point of failure. At this time, the IBM team
responsible for the customer proposed an extra system for backup, using
dedicated communication lines between the two systems.
The proposed solution involved a backup AS/400 system in a new, separate
machine room of its own, and an OptiConnect line between the two AS/400
systems. A key feature in this environment was a High Availability solution from
Vision Solutions. This solution mirrors all data on the system to a target (backup)
system on a real time basis.
In addition to the necessary hardware, this allows EDA Retail to become immune
to disasters, planned shutdowns (for example, system maintenance), and
unplanned shutdowns (such as system failures). In the case of a shutdown, either
planned or unplanned, EDA Retail can switch users to the backup system. Within
thirty minutes of the breakdown, operations continue.
The primary test of the project was a Role Swap, in which roles are switched
between the two systems. The system normally serving as the source system
becomes the target system, and vice versa. When the roles are switched and
mirroring is started in reverse mode, the user’s connection to the new source
system is tested to determine if they can run their applications as they normally
would. A success is illustrated when the correct data, authorizations, and other
objects or information are successfully mirrored, with the transactions also
mirrored to the new target system.
The successful completion of a second test of this nature marked the end of the
implementation project and the beginning of normal maintenance activities. The
users had access to the information they required even while the backup was
taken. Their information remained available at all times except during the role
swap.
3.4 A small manufacturing company: Scenario 4
This solution applies to manufacturing and to any small business with limited
information technology resources. These firms do not typically operate seven
days a week, but they may operate 24 hours per day, Monday through Friday.
The business requires that the systems be available when they are needed with a
minimum of intervention. If the system fails, they need a backup system on which
to run. They can then contact their external I/T services supplier for support. This
support can take a day or so to arrive. In the meantime, they run their business
with unprotected information.
30 High Availability on the AS/400 System: A System Manager’s Guide
It is important to note that they are still running in this situation. The third party
services provider then arrives, fixes the problem, and re-synchronizes the
systems.
DMT Industries is a manufacturer of medical supplies which has become highly
globalized over the last several years. Their globalization raises the demand on
the IT division to provide a 24 x 7 operation.
DMT Industries has various platforms installed. One of the strategic business
applications, which must be available at all times, is running on the AS/400
platform.
A total of 1,500 users from all over the world have access to the system, which is
located in Denmark. Until early 1998, DMT Industries could offer only 20 hours of
system availability per day. The remaining four hours were used for the nightly
backup. As it became necessary to offer 24 hour availability, they decided to
implement a high availability solution.
The installation then consisted of two identical AS/400 systems, located in
separate machine rooms, a dedicated 100 Mbit Ethernet connection between
them, and software from Vision Solutions. This enabled DMT Medical to perform
their nightly backup on the backup system to which all production data was
mirrored. They simply stopped the mirrored data from the production machine
from being applied on the backup system while the backup ran. The users could
continue operations on the production system as required.
3.5 A distribution company: Scenario 5
This example represents a three-tiered SAP solution (reportedly the largest site
worldwide).
TVBCo is a distribution company utilizing J.D. Edwards (JDE) applications. The
company focuses on expanding knowledge about human protein molecules and
transforming them by means of biotechnological methods and clinical tests.
TVBCo had developed into a completely integrated worldwide pharmaceutical
business. Its European Distribution Center in Holland houses a central IBM
AS/400e production system, accessed by a large number of TVBCos branches in
Europe. A second AS/400e machine is used for testing, development, and
backup. The production AS/400e system plays a critical role in TVBCos European
operations, so the company wanted to reduce its downtime to a minimum.
In cooperation with IBM, TVBCo started developing an availability management
plan and purchased two AS/400e systems. MIMIX availability management
software solution was installed.
High availability software immediately replicated all production system
transactions on a defined backup system and performed synchronization
checking to verify data integrity. Critical data and other items were always present
and available on the backup system so that users could switch to that system and
continue working if an unplanned outage occured.
Aside from the immediate safekeeping of all data, high availability software
maintained an accurate, up-to-date copy of the system setup on the back-up
machine. For that purpose, all user profiles, subsystem descriptions, and other
High availability example solutions 31
objects were replicated. High availability software also controlled the production
system and the actual switchover in case of a failure. The backup machine
monitored whether the production machine was still on. The moment it detected
that something was wrong, it warned the system operator, who could decide to
switch over. When that decision was made, all necessary actions had already
been set out in a script so that the operator only had to intervene in exceptional
cases.
The TVBCo customized procedure included sending warnings to all users,
releasing the backup database, activating subsystems and backup users, and
switching interactive users to the backup system.
TVBCo soon decided to start using high availability software as its worldwide
standard for processing and invoicing. The data changed continuously, and a
traditional backup could not be produced because too few stable points existed in
the day. With the chosen high availability solution, the backup was made while the
file was active. Therefore, taking the application offline was not necessary. In
addition, the high availability solution backup ran, on average, only a couple of
seconds (sometimes even less) behind production. Contrast this if a tape were
made every hour (the backup could have run up to one hour behind in real time).
The second application, an electronic data interchange (EDI) package,
automates the purchase of supplies. This package retrieves batch data from the
computer networks managed by the company’s suppliers. This process is not
continuous so a more traditional backup method may be suitable. However, after
estimating the considerable effort required to adapt the batch protocols and DDM
files, it was decided to use high availability software. Because their chosen high
availability software solution kept the backup data current (almost to the second),
the company did not need to request that the batches be sent again when a
problem occured with the production machine. Also, high availability software
allowed the backup to be made in batches (for example, to relieve the network
during peak hours).
The third critical application replicated by high availability software is a DSI
logistics program. Since this application not only generates packing lists and is
used for updating the contents of the warehouse in the J.D. Edwards database, it
must have information about the most recent setup of the warehouse. This
information must, of course, remain available when the production equipment
breaks down. Otherwise, the orders may be processed but the forklift operators
would not know where to unload the merchandise. Like the J.D. Edwards
application, the input and output of this application (and, therefore, the
replicating) is a real time process.
The data from the J.D. Edwards application and the IBM application are copied to
the backup while the file is active. The batch processes from a variety of
platforms, are copied to the AS/400e production system at scheduled intervals.
With high availability software, it is not necessary to take the application offline
because the backup is made while the file is active. High availability software also
controls the production system and actual switchover in case of a failure.
TVBCos data center is supported by a staff of 70. The hardware consists of two
AS/400e Model 500 systems connected with TCP on ethernet adapters.
32 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 33
Part 2. AS/400 high availability functions
Many areas of a system implementation contribute to the availability rating. Each
option provides differing degrees of availability.
Part II discusses the hardware, storage options, operating system features, and
network components that contribute to a high availability solution. Appendix F,
“Cost components of a business case” on page 169, provides a reference to
compare the availability options of journaling, mirrored protection, device parity
protection, and others.
34 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 35
Chapter 4. Hardware support for single system high availability
The selection of hardware components provides a basis for system availability
options. This chapter discusses some of the considerations for protecting your
data and available features and tools from a hardware perspective on a single
system and options using multiple systems.
Hardware selections greatly contribute to a system’s high availability
characteristics. This chapter discusses:
• Data protection options
• Concurrent maintenance
• Hot spares
• OptiConnect
• Clusters
• LPAR
• Power options
• Tape devices
4.1 Protecting your data
Your first defense against data loss is a good backup and recovery strategy. You
need a plan for regularly saving the information on your system. In addition to
having a working backup and recovery strategy, you should also employ some
form of data protection on your system.
When you think about protecting your system from data loss, make the following
considerations:
• Recovery: Can you retrieve the information that you lost, either by restoring it
from backup media or by creating it again?
• Availability: Can you reduce or eliminate the amount of time that your system
is unavailable after a problem occurs?
• Serviceability: Can you service it without affecting the data user?
Disk protection can help prevent data loss and keep your system from stopping if
you experience a disk failure.
The topics that follow provide information on the different types of disk protection,
as well as using the types with one another.
4.2 Disk protection tools
Several disk availability tools are available for reducing or eliminating system
downtime. They also help with data recovery after a disk failure. The tools
include:
Although disk protection can reduce downtime or make recovery faster, it is not
a replacement for regular backups. Disk protection cannot help you recover
from a complete system loss, a processor failure, or a program failure.
Remember
36 High Availability on the AS/400 System: A System Manager’s Guide
• Mirrored protection
• Device parity protection
• Auxiliary storage pools (ASPs)
• Others
These disk protection methods help protect your data. You can use these
methods in different combinations with one another. Your choice of disk tools
determines your level of disk protection and vice versa. Figure 6 shows the
different levels of availability.
Figure 6. Levels of availability
High availability, as shown in Figure 6, includes mirroring, RAID-5, offline backup,
UPS, CPM, clustering, journaling, auxiliary storage pools, SMAPP, commitment
control, and save-while-active components.
Topics not covered in this Redpaper are discussed in The System Administrator’s
Companion to AS400 Availability and Recovery, SG24-2161, and the Backup and
Recovery, SC41-5304.
4.3 Disk mirroring
Mirrored protection is an OS/400 high availability function in the licensed internal
code that protects data from loss due to failure, or due to damage to a
disk-related component.
Mirrored protection is a high availability software function that duplicates
disk-related hardware components to keep the AS/400 system available if one of
the disk components fails. It prevents a loss of data in case of a disk-related
hardware failure. Mirroring is used on any model of the AS/400 system and is a
part of the Licensed Internal Code (LIC).
Bus 2
IOP
Mirroring
Bus 3
IOP
Controller Controller
* Journaling
* Auxiliary storgae pools
* SMAAP
* Commitment control
Clustered
systems
Continuous power Backup power
supply
UPS
Tape
Array 1
Array 2
Disk Bus
controller
RAID - 5
Hardware support for single system high availability 37
Different levels of mirrored protection are possible, depending on what hardware
is duplicated. The hardware components that can be duplicated include:
• Disk units (to provide the lowest (relative) level of availability)
• Disk controllers
• Disk I/O processors (IOP)
• Buses (to provide the highest (relative) level of availability)
Mirroring protection is configured by the ASP. For optimum protection, there must
be an even number of components at each level of protection. The system
remains available during a disk, controller, IOP, or bus failure if the failing
component and hardware components that are attached to it are duplicated.
When you start mirrored protection or add disk units to an ASP that has mirrored
protection, the system creates mirrored pairs using disk units that have identical
capacities. Data is protected because the system keeps two copies of data on
two separate disk units.
When a disk-related component fails, the system can continue to operate without
interruption by using the mirrored copy of the data until the failed component is
repaired. The overall goal is to protect as many disk-related components as
possible. To provide maximum hardware redundancy and protection, the system
attempts to pair disk units that are attached to different controllers, input/output
processors, and buses.
If you have a multi-bus system or a large single-bus system, consider using
mirrored protection. The greater the number of disk units attached to a system,
the more frequently disk-related hardware failures occur. This is because there
are more individual pieces of hardware that can fail. Therefore, the possibility of
data loss or loss of availability as a result of a disk or other hardware failure is
more likely.
Also, as the amount of disk storage on a system increases, the recovery time
after a disk storage subsystem hardware failure increases significantly. Downtime
becomes more frequent, more lengthy, and more costly.
Mirroring can be used on any AS/400 system model. The system remains
available during a failure if a failing component and the hardware components
that are attached to it have been duplicated. See 4.8, “Concurrent maintenance”
on page 54, to better understand the maintenance aspect.
Remote mirroring support allows you to have one mirrored unit within a mirrored
pair at the local site, and the second mirrored unit at a remote site.
For some systems, standard DASD mirroring remains the best option. Evaluate
the uses and needs of your system, consider the advantages and disadvantages
of each type of mirroring support, and decide which is best for you.
Refer to B.2.3, “Mirrored protection: How it works” on page 151, for a more
detailed description.
4.3.1 Standard mirrored protection
Standard DASD mirroring support requires that both disk units of the load source
mirrored pair (unit 1) are attached to the multi-function I/O processor (MFIOP).
This option allows the system to initial program load (IPL) from either load source
38 High Availability on the AS/400 System: A System Manager’s Guide
in the mirrored pair. The system can dump main storage to either load source if
the system terminates abnormally. However, since both load source units must be
attached to the same I/O processor (IOP), controller level protection is the best
mirroring protection possible for the load source mirrored pair.
How the AS/400 system addresses storage
Disk units are assigned to an auxiliary storage pool (ASP) on a unit basis. The
system treats each storage unit within a disk unit as a separate unit of auxiliary
storage. When a new disk unit is attached to the system, the system initially
treats each storage unit within as non-configured. Through Dedicated Service
Tools (DST) options, you can add these nonconfigured storage units to either the
system ASP or a user ASP of your choice. When adding non-configured storage
units, use the serial number information that is assigned by the manufacturer to
ensure that you are selecting the correct physical storage unit. Additionally, the
individual storage units within the disk unit can be identified through the address
information that can be obtained from the DST Display Disk Configuration display.
When you add a nonconfigured storage unit to an ASP, the system assigns a unit
number to the storage unit. The unit number can be used instead of the serial
number and address. The same unit number is used for a specific storage unit
even if you connect the disk unit to the system in a different way.
When a unit has mirrored protection, the two storage units of the mirrored pair are
assigned the same unit number. The serial number and the address distinguish
between the two storage units in a mirrored pair. To determine which physical disk
unit is being identified with each unit number, note the unit number assignment to
ensure correct identification. If a printer is available, print the DST or SST display
of your disk configuration. If you need to verify the unit number assignment, use
the DST or SST Display Configuration Status display to show the serial numbers
and addresses of each unit.
The storage unit that is addressed by the system as Unit 1 is always used by the
system to store licensed internal code and data areas. The amount of storage
that is used on Unit 1 is quite large and varies depending on your system
configuration. Unit 1 contains a limited amount of user data. Because Unit 1
contains the initial programs and data that is used during an IPL of the system, it
is also known as the load source unit.
The system reserves a fixed amount of storage on units other than Unit 1. The
size of this reserved area is 1.08 MB per unit. This reduces the space available
on each unit by that amount.
4.3.2 Mirrored protection: Benefits
With the best possible mirrored protection configuration, the system continues to
run after a single disk-related hardware failure. On some system units, the failed
hardware can sometimes be repaired or replaced without having to power down
the system. If the failing component is one that cannot be repaired while the
system is running, such as a bus or an I/O processor, the system usually
continues to run after the failure. Maintenance can be deferred and the system
can be shut down normally. This helps to avoid a longer recovery time.
Even if your system is not a large one, mirrored protection can provide valuable
protection. A disk or disk-related hardware failure on an unprotected system
leaves your system unusable for several hours. The actual time depends on the
Hardware support for single system high availability 39
kind of failure, the amount of disk storage, your backup strategy, the speed of your
tape unit, and the type and amount of processing the system performs.
4.3.3 Mirrored protection: Costs and limitations
The main cost of using mirrored protection lies in additional hardware. To achieve
high availability, and prevent data loss when a disk unit fails, you need mirrored
protection for all the auxiliary storage pools (ASPs). This usually requires twice
as many disk units. If you want continuous operation and data loss prevention
when a disk unit, controller, or I/O processor fails, you need duplicate disk
controllers as well as I/O processors.
A model upgrade can be done to achieve nearly continuous operation and to
prevent data loss when any of these failures occur. This includes a bus failure. If
Bus 1 fails, the system cannot continue operation. Because bus failures are rare,
and bus-level protection is not significantly greater than I/O processor-level
protection, you may not find a model upgrade to be cost-effective for your
protection needs.
Mirrored protection has a minimal reduction in system performance. If the buses,
I/O processors, and controllers are no more heavily loaded on a system with
mirrored protection than they would be on an equivalent system without mirrored
protection, the performance of the two systems should be approximately the
same.
In deciding whether to use mirrored protection on your system, evaluate and
compare the cost of potential downtime against the cost of additional hardware
over the life of the system. The additional cost in performance or system
complexity is usually negligible.
Also consider other availability and recovery alternatives, such as device parity
protection. Mirrored protection normally requires twice as many storage units. For
concurrent maintenance and higher availability on systems with mirrored
protection, other disk-related hardware may be required.
Limitations
Although mirrored protection can keep the system available after disk-related
hardware failures occur, it is not a replacement for save procedures. There can be
multiple types of disk-related hardware failures, or disasters (such as flood or
sabotage) where recovery requires backup media.
Mirrored protection cannot keep your system available if the remaining storage
unit in the mirrored pair fails before the first failing storage unit is repaired and
mirrored protection is resumed.
If two failed storage units are in different mirrored pairs, the system is still
available. Normal mirrored protection recovery is done because the mirrored
pairs are not dependent on each other for recovery. If a second storage unit of the
same mirrored pair fails, the failure may not result in a data loss. If the failure is
limited to the disk electronics, or if the service representative can successfully
use the Save Disk Unit Data function to recover all of the data (a function referred
to as “pump”), no data is lost.
40 High Availability on the AS/400 System: A System Manager’s Guide
If both storage units in a mirrored pair fail causing data loss, the entire ASP is lost
and all units in the ASP are cleared. Be prepared to restore your ASP from the
backup media and apply any journal changes to bring the data up to date.
4.3.4 Determining the level of mirrored protection
The level of mirrored protection determines whether the system continues
running when different levels of hardware fails. The level of protection is the
amount of duplicate disk-related hardware that you have. The more mirrored pairs
that have higher levels of protection, the more often your system is usable when
disk-related hardware fails. You may decide that a lower level of protection is
more cost-effective for your system than a higher level.
The four levels of protection, from lowest to highest, are as follows:
• Disk unit-level protection
• Controller-level protection
• Input/output processor-level protection
• Bus-level protection
When determining what level of protection is adequate, consider the relative
advantages of each level of protection with respect to the following
considerations:
• The ability to keep the system operational during a disk-related hardware
failure.
• The ability to perform maintenance concurrently with system operations. To
minimize the time that a mirrored pair is unprotected after a failure, you may
want to repair failed hardware while the system is operating.
During the start mirrored protection operation, the system pairs the disk units to
provide the maximum level of protection for the system. When disk units are
added to a mirrored ASP, the system pairs only those disk units that are added
without rearranging the existing pairs. The hardware configuration includes the
hardware and how the hardware is connected.
The level of mirrored protection determines whether the system continues
running when different levels of hardware fail. Mirrored protection always provides
disk unit-level protection that keeps the system available for a single disk unit
failure. To keep the system available for failures of other disk-related hardware
requires higher levels of protection. For example, to keep the system available
when an I/O processor (IOP) fails, all of the disk units attached to the failing IOP
must have mirrored units attached to different IOPs.
The level of mirrored protection also determines whether concurrent maintenance
can be done for different types of failures. Certain types of failures require
concurrent maintenance to diagnose hardware levels above the failing hardware
component. An example would be diagnosing a power failure in a disk unit that
requires resetting the I/O processor to which the failed disk unit is attached. In
this case, IOP-level protection is required.
The level of protection you get depends on the hardware you duplicate. If you
duplicate disk units, you require disk unit-level protection. If you also duplicate
disk unit controllers, you require controller-level protection. If you duplicate
Hardware support for single system high availability 41
input/output processors, you require IOP-level protection. If you duplicate buses,
you require bus-level protection.
Mirrored units always have, at least, disk unit-level protection. Because most
internal disk units have the controller packaged along with the disk unit, they have
at least controller-level protection.
4.3.4.1 Disk unit-level protection
All mirrored storage units have a minimum of disk unit-level protection if they
meet the requirements for starting mirrored protection (storage units are
duplicated). If your main concern is protecting data and not high availability, disk
unit-level protection may be adequate.
The disk unit is the most likely hardware component to fail, and disk unit-level
protection keeps your system available after a disk unit failure. Concurrent
maintenance is often possible for certain types of disk unit failures with disk
unit-level protection.
Figure 7 shows disk unit-level protection. The two storage units make a mirrored
pair. With disk unit-level protection, the system continues to operate during a disk
unit failure. If the controller or I/O processor fails, the system cannot access data
on either of the storage units of the mirrored pair, and the system is unusable.
Figure 7. Disk unit level protection
4.3.4.2 Controller-level protection
If the planned disk units do not require a separate controller, you already have
controller-level protection for as many units as possible and do not need to do
anything else. If your planned disk units do require a separate controller, add as
many controllers as possible while keeping within the defined system limits. Then
balance the disk units among them according to the standard system
configuration rules.
Bus
Input/Output
Programmer
Disk
Unit
Disk
Unit
Controller
42 High Availability on the AS/400 System: A System Manager’s Guide
To keep your system available when a controller fails, consider using concurrent
maintenance. The controller must be dedicated to the repair action in this
process. If any disk units attached to the controller do not have controller-level
protection, concurrent maintenance is not possible.
To achieve controller-level protection, all disk units must have a mirrored unit
attached to a different controller. Most internal disk units have their controller
packaged as part of the disk unit, so internal disk units generally have at least
controller-level protection. Use problem recovery procedures in preparation for
isolating a failing item or to verify a repair action.
Figure 8 illustrates controller-level protection.
Figure 8. Input/output controller-level protection
The two storage units make a mirrored pair. With controller-level protection, the
system can continue to operate after a disk controller failure. If the I/O processor
fails, the system cannot access data on either of the disk units, and the system is
unusable.
4.3.4.3 IOP-level protection
If you want IOP-level protection and you do not already have the maximum
number of IOPs on your system, add as many IOPs as possible while keeping
within the defined system limits. Then, balance the disk units among them
according to the standard system configuration rules. You may need to add
additional buses to attach more IOPs.
To achieve I/O processor-level protection, all disk units that are attached to an I/O
processor must have a mirrored unit attached to a different I/O processor. On
many systems, I/O processor-level protection is not possible for the mirrored pair
for Unit 1.
Bus
Input/Output
Programmer
Disk
Unit
Disk
Unit
Controller Controller
Hardware support for single system high availability 43
IOP-level protection is useful to:
• Keep your system available when an I/O processor fails
• Keep your system available when the cable attached to the I/O processor fails
• Concurrently repair certain types of disk unit failures or cable failures. For
these failures, concurrent maintenance needs to reset the IOP. If any disk units
that are attached to the IOP do not have IOP-level protection, concurrent
maintenance is not possible.
Figure 9 illustrates IOP-level protection.
Figure 9. IOP-level protection
The two storage units make a mirrored pair. With IOP-level protection, the system
continues to operate after an I/O processor failure. The system becomes
unusable only if the bus fails.
4.3.4.4 Bus-level protection
If you want bus-level protection, and you already have a multiple-bus system,
nothing must be done. If your system is configured according to standard
configuration rules, the mirrored pairing function pairs up storage units to provide
bus-level protection for as many mirrored pairs as possible. If you have a
single-bus system, you can add additional buses as a feature option on systems
supporting multiple buses.
Bus-level protection can allow the system to run when a bus fails. However,
bus-level protection is often not cost-effective because of the following problems:
• If Bus 1 fails, the system is not usable.
• If a bus fails, disk I/O operations may continue, but so much other hardware is
lost (such as work stations, printers, and communication lines) that, from a
practical standpoint, the system is not usable.
Bus
Input/Output
Programmer
Disk
Unit
Controller
Disk
Unit
Controller
Input/Output
Programmer
44 High Availability on the AS/400 System: A System Manager’s Guide
• Bus failures are rare compared with other disk-related hardware failures.
• Concurrent maintenance is not possible for bus failures.
To achieve bus-level protection, all disk units that are attached to a bus must have
a mirrored unit attached to a different bus. Bus-level protection is not possible for
Unit 1.
Figure 10 illustrates bus-level protection.
Figure 10. Bus-level protection
The two storage units make a mirrored pair. With bus-level protection, the system
continues to operate after a bus failure. However, the system cannot continue to
operate if Bus 1 fails.
4.3.5 Determining the hardware required for mirroring
To communicate with the rest of the system, disk units are attached to controllers,
which are attached to I/O processors, which are attached to buses. The number
of each of these types of disk-related hardware that are available on the system
directly affects the level of possible protection.
Bus 1
Input/Output
Programmer
Disk
Unit
Controller
Bus 2
Input/Output
Programmer
Disk
Unit
Controller
Hardware support for single system high availability 45
To provide the best protection and performance, each level of hardware should be
balanced under the next level of hardware. That is, the disk units of each device
type and model should be evenly distributed under the associated controllers.
The same number of controllers should be under each I/O processor for that disk
type. Balance the I/O processors among the available buses.
To plan what disk-related hardware is needed for your mirrored system, plan the
total number and type of disk units (old and new) that are needed on the system,
as well as the level of protection for the system. It is not always possible to plan
for and configure a system so that all mirrored pairs meet the planned level of
protection. However, it is possible to plan a configuration in which a very large
percentage of the disk units on the system achieve the desired level of protection.
When planning for additional disk-related hardware, perform the following steps:
1. Determine the minimum hardware that is needed for the planned disk units to
function. Plan for one disk unit size (capacity) at a time.
2. Plan the additional hardware needed to provide the desired level of protection
for each disk unit type
Planning the minimum hardware needed to function
Various rules and limits exist on how storage hardware can be attached. The
limits may be determined by hardware design, architecture restrictions,
performance considerations, or support concerns.
For each disk unit type, first plan for the controllers that are needed and then for
the I/O processors that are needed. After planning the number of I/O processors
needed for all disk unit types, use the total number of I/O processors to plan for
the number of buses that are needed.
4.3.6 Mirroring and performance
When mirrored protection is started, most systems show little difference in
performance. In some cases, mirrored protection can improve performance.
Generally, functions that mostly perform read operations experience equal or
better performance with mirrored protection. This is because read operations
have a choice of two storage units to read from. The unit with the faster expected
response time is selected. Operations that mostly perform write operations (such
as updating database records) may see slightly reduced performance on a
system that has mirrored protection because all changes must be written to both
storage units of the mirrored pair. Therefore, restore operations are slower.
In some cases, if the system ends abnormally, the system cannot determine
whether the last updates were written to both storage units of each mirrored pair.
If the system is not sure that the last changes were written to both storage units
of the mirrored pair, the system synchronizes the mirrored pair by copying the
data in question from one storage unit of each mirrored pair to the other storage
unit.
The synchronization occurs during the IPL that follows the abnormal system end.
If the system can save a copy of main storage before it ends, the synchronization
process takes just a few minutes. If not, the synchronization process can take
much longer. The extreme case could be close to a complete synchronization.
46 High Availability on the AS/400 System: A System Manager’s Guide
If you have frequent power outages, consider adding an uninterruptible power
supply (UPS) to your system. If main power is lost, the UPS allows the system to
continue. A basic UPS supply provides the system with enough time to save a
copy of main storage before ending. This prevents a long recovery. Both storage
units of the load source mirrored pair must be powered by the basic UPS.
4.3.7 Determining the extra hardware required for performance
Mirrored protection normally requires additional disk units and input/output
processors. However, in some cases, you may need additional hardware to
achieve the level of desired performance.
Use these points to decide how much extra hardware you may need:
• Mirrored protection causes a minor increase in central processing unit usage
(approximately 1% to 2%).
• Mirrored protection requires storage in the machine pool for general purposes
and for each mirrored pair. If you have mirrored protection, increase the size of
your machine pool by approximately 12 KB for each 1 GB of mirrored disk
storage (12 KB for 1 GB DASD, 24 KB for 2 GB DASD, etc.).
• During synchronization, mirrored protection uses an additional 512 KB of
memory for each mirrored pair being synchronized. The system uses the pool
with the most storage.
• To maintain equivalent performance after starting mirrored protection, your
system should have the same ratio of disk units to I/O processors as it did
before. To add I/O processors, you may need to upgrade your system for
additional buses.
Note: Because of the limit on buses and I/O processors, you may not be able
to maintain the same ratio of disk units to I/O processors. In this case, system
performance may degrade.
4.4 Remote DASD mirroring support
Standard DASD mirroring support requires that both disk units of the load source
mirrored pair (Unit 1) are attached to the Multi-function I/O Processor (MFIOP).
This allows the system to IPL from either load source in the mirrored pair and
allows the system to dump main storage to either load source if the system ends
abnormally. However, since both load sources must be attached to the same I/O
Processor (IOP), the best mirroring protection possible for the load source
mirrored pair is controller-level protection. To provide a higher level of protection
for your system, use remote load source mirroring and remote DASD mirroring.
Remote DASD mirroring support, when combined with remote load source
mirroring, mirrors the DASD on local optical buses with the DASD on optical
buses that terminate at a remote location. In this configuration, the entire system,
including the load source, can be protected from a site disaster. If the remote site
is lost, the system can continue to run on the DASD at the local site. If the local
DASD and system unit are lost, a new system unit can be attached to the set of
DASD at the remote site, and system processing can be resumed.
Remote DASD mirroring, like standard DASD mirroring, supports mixing
device-parity-protected disk units in the same ASP with mirrored disk units. The
device parity DASD can be located at either the local or the remote site. However,
Hardware support for single system high availability 47
if a site disaster occurs at the site containing the device parity DASD, all data in
the ASPs containing the device parity DASD is lost.
Remote mirroring support makes it possible to divide the disk units on your
system into a group of local DASD and a group of remote DASD. The remote
DASD is attached to one set of optical buses and the local DASD to another set of
buses. The local and remote DASD can be physically separated from one another
at different sites by extending the appropriate optical buses to the remote site.
4.4.1 Remote load source mirroring
Remote load source mirroring support allows the two disk units of the load source
to be on different IOPs or system buses. This provides IOP- or bus-level mirrored
protection for the load source. However, in such a configuration, the system can
only IPL from, or perform a main storage dump to, the load source attached to the
MFIOP. If the load source on the MFIOP fails, the system can continue to run on
the other disk unit of the load source mirrored pair, but the system is not able to
IPL or perform a main storage dump until the load source attached to the MFIOP
is repaired and usable.
4.4.2 Enabling remote load source mirroring
To use remote load source mirroring support, remote load source mirroring must
first be enabled. Mirrored protection must then be started for ASP 1. If remote
load source mirroring support is enabled after mirrored protection has already
been started for ASP 1, the existing mirrored protection and mirrored pairing of
the load source must not change. Remote load source mirroring support can be
enabled in either the DST or the SST environment. If you attempt to enable
remote load source mirroring, and it is currently enabled, the system displays a
message that remote load source mirroring is already enabled. There are no
other errors or warnings for enabling remote load source mirroring support.
If the remote load source is moved to the MFIOP, the IOP and system may not
recognize it because of the different DASD format sizes used by different IOPs. If
the remote load source is missing after it has been moved to the MFIOP, use the
DST Replace disk unit function to replace the missing load source with itself. This
causes the DASD to be reformatted so that the MFIOP can use it. The disk unit is
then synchronized with the active load source.
Remote load source mirroring may be disabled from either DST or SST. However,
disabling remote load source mirroring is not allowed if there is a load source disk
unit on the system that is not attached to the MFIOP. If you attempt to disable
remote load source mirroring support and it is currently disabled, the system
displays a message that remote load source mirroring is already disabled.
4.4.3 Using remote load source mirroring with local DASD
Remote load source mirroring can be used to achieve IOP-level or bus-level
protection of the load source mirrored pair, even without remote DASD or buses
on the system. There is no special setup required, except for ensuring that a disk
unit of the same capacity as the load source is attached to another IOP or bus on
the system. To achieve bus-level protection of all mirrored pairs in an ASP,
configure your system so that no more than one-half of the DASD of any given
capacity in that ASP are attached to any single bus. To achieve IOP-level
48 High Availability on the AS/400 System: A System Manager’s Guide
protection of all mirrored pairs in an ASP, have no more than one-half of the
DASD of any given capacity in the ASP attached to any single IOP.
There is no special start mirroring function for remote load source support. The
system detects that remote load source mirroring is enabled and automatically
pairs up disk units to provide the best level of possible protection. It is not
possible to override or influence the pairing of the disk units other than by
changing the way the hardware of the system is connected and configured.
Normal mirroring restrictions that concern total ASP capacity, an even number of
disk units of each capacity, and other such considerations, apply.
4.4.3.1 Remote DASD mirroring: Advantages
Advantages of remote DASD mirroring include:
• Providing IOP-level or bus-level mirrored protection for the load source
• Allowing the DASD to be divided between two sites, mirroring one site to
another, to protect against a site disaster
4.4.3.2 Remote DASD mirroring: Disadvantages
Disadvantages of remote DASD mirroring include:
• A system that uses Remote DASD Mirroring is only able to IPL from one DASD
of the load source mirrored pair. If that DASD fails and cannot be repaired
concurrently, the system cannot be IPLed until the failed load source is fixed
and the remote load source recovery procedure is performed.
• When Remote DASD Mirroring is active on a system, and the one load source
the system can use to IPL fails, the system cannot perform a main storage
dump if the system ends abnormally. This means that the system cannot use
the main storage dump or continuously-powered main store (CPM) to reduce
recovery time after a system crash. It also means that the main storage dump
is not available to diagnose the problem that causes the system to end
abnormally.
4.5 Planning your mirroring installation
If you decide that remote DASD mirroring is right for your system, prepare your
system and then start site-to-site mirroring. Determine whether your system is
balanced and meets standard configuration rules. The system must be configured
according to the standard rules for the mirrored pairing function to pair up storage
units to provide the best possible protection from the hardware that is available.
Plan for the new units to add for each ASP.
If you plan to start mirrored protection on a new system, that system is already
configured according to standard configuration rules. If you are using an older
system, it may not follow the standard rules. However, wait until after attempting
to start mirrored protection before reconfiguring any hardware.
When considering mirrored protection, review these planning steps:
1. Decide which ASP or ASPs to protect.
2. Determine the disk storage capacity requirements.
3. Determine the level of protection that is needed for each mirrored ASP.
4. Determine what extra hardware is necessary for mirrored protection.
5. Determine what extra hardware is needed for performance.
Hardware support for single system high availability 49
In general, the units in an ASP should be balanced across several I/O processors,
rather than all being attached to the same I/O processor. This provides better
protection and performance. Plan the user ASPs that have mirrored protection
and determine what units to add to the ASPs. Refer to Chapter 5, “Auxiliary
storage pools (ASPs)” on page 63, for more information about ASPs.
4.5.1 Comparing DASD management with standard and remote mirroring
For the most part, managing DASD with remote mirroring is similar to managing
DASD with standard mirroring. The differences are in how you add disk units and
how you restore mirrored protection after a recovery.
Adding disk units
Unprotected disk units must be added in pairs just as with general mirroring. To
achieve remote protection of all added units, one half of the new units of each
capacity of DASD should be in the remote group and one half in the local group.
Single device-parity protected units may be added to ASPs using remote
mirroring. However, the ASP is not protected against a site disaster.
4.6 Device parity protection
Device parity protection is a high availability hardware function (also known as
RAID-5) that protects data from loss due to a disk unit failure or because of
damage to a disk. It allows the system to continue to operate when a disk unit
fails or disk damage occurs.
The system continues to run in an exposed mode until the damaged unit is
repaired and the data is synchronized to the replaced unit. To protect data, the
disk controller or input/output processor (IOP) calculates and saves a parity value
for each bit of data. Parity protection is built into many IOPs. It is activated for disk
units that are attached to those IOPs.
Device parity involves calculating and saving a parity value for each bit of data.
Conceptually, the parity value is computed from the data at the same location on
each of the other disk units in the device parity set. When a disk failure occurs,
the data on the failing unit is reconstructed using the saved parity value and the
values of bits in the same location on other disks. The system continues to run
while the data is being reconstructed.
Logically, the implementation of device parity protection is similar to the system
checksum function. However, device parity is built into the hardware. Checksum,
on the other hand, is started or stopped using configuration options on the
AS/400 system menu.
If a failure occurs, correct the problem quickly. In the unlikely event that another
disk fails in the same parity set, you may lose data.
Recommendation
50 High Availability on the AS/400 System: A System Manager’s Guide
The overall goal of device parity protection is to provide high availability and to
protect data as inexpensively as possible.
If possible, protect all the disk units on your system with device parity protection
or mirrored protection. This prevents the loss of information when a disk failure
occurs. In many cases, you can also keep your system operational while a disk
unit is being repaired or replaced.
Before using device parity protection, note the benefits that are associated with it,
as well as the costs and limitations.
Some device parity protection advantages:
• It can prevent your system from stopping when certain types of failures occur.
• It can speed up your recovery process for certain types of failures, such as a
site disaster or an operator or programmer error.
• Lost data is automatically reconstructed by the disk controller after a disk
failure.
• The system continues to run after a single disk failure.
• A failed disk unit can be replaced without stopping the system.
• Device parity protection reduces the number of objects that are damaged
when a disk fails.
Some device parity protection disadvantages:
• It is not a substitute for a backup and recovery strategy.
• It does not provide protection from all types of failures, such as a site disaster
or an operator or programmer error.
• Device parity protection can require additional disk units to prevent slower
performance.
• Restore operations can take longer when you use device parity protection.
System checksum is another disk protection method similar to device parity.
Checksum is not supported on RISC systems, and it is not discussed in this
Redpaper. You can find information on checksum in Backup and Recovery,
SC41-5306.
Note
Device parity protection is not a substitute for a backup and recovery strategy.
Device parity protection can prevent your system from stopping when certain
types of failures occur. It can speed up your recovery process for certain types
of failures. But device parity protection does not protect you from many types of
failures, such as system outages that are caused by failures in other
disk-related hardware (for example, disk controllers, disk I/O processors, or a
system bus).
Remember
Hardware support for single system high availability 51
For information on planning for device parity protection, refer to Appendix B,
“Planning for device parity protection” on page 147.
4.6.1 How device parity protection affects performance
Device parity protection requires extra I/O operations to save the parity data. This
may cause a performance problem. To avoid this problem, some IOPs contain a
non-volatile write cache that ensures data integrity and provides faster write
capabilities. The system is notified that a write operation is complete as soon as a
copy of the data is stored in the write cache. Data is collected in the cache before
it is written to a disk unit. This collection technique reduces the number of
physical write operations to the disk unit. Because of the cache, performance is
generally about the same on protected and unprotected disk units.
Applications that have many write requests in a short period of time, such as
batch programs, can adversely affect performance. A single disk unit failure can
adversely affect the performance for both read and write operations.
The additional processing that is associated with a disk unit failure in a device
parity set can be significant. The decrease in performance is in effect until the
failed unit is repaired (or replaced) and the rebuild process is complete. If device
parity protection decreases performance too much, consider using mirrored
protection. These topics provide additional details on how a disk unit failure
affects performance:
• Disk unit failure in a device parity protection configuration
• Input/output operations during a rebuild process
• Read operations on a failed disk unit
• Write operations on a failed disk unit
4.6.1.1 Disk unit failure in a device parity protection configuration
The write-assist device is suspended when a disk unit failure occurs in a
subsystem with device parity protection. If the write-assist device fails, it is not
used again until the repair operation is completed. The performance advantage of
the write-assist device is lost until the disk unit is repaired.
The subsystems with device parity protection are considered to be exposed until
the synchronization process completes after replacing the failed disk unit. While
the disk unit is considered exposed, additional I/O operations are required.
4.6.1.2 Input/output operations during a rebuild process
I/O operations during the rebuild (synchronization) process of the failed disk unit
may not require additional disk I/O requests. This depends on where the data is
read from or written to on the disk unit that is in the synchronization process. For
example:
• A read operation from the disk area that already has been rebuilt requires one
read operation.
• A read operation from the disk area that has not been rebuilt is treated as a
read operation on a failed disk unit.
• A write operation to the disk that has already been rebuilt requires normal
read and write operations (two read operations and two write operations).
• A write operation to the disk area that has not been rebuilt is treated as a write
operation to a failed disk unit.
52 High Availability on the AS/400 System: A System Manager’s Guide
Note: The rebuild process takes longer when read and write operations to a
replaced disk unit are also occurring. Every read request or every write request
interrupts the rebuild process to perform the necessary I/O operations.
4.6.2 Using both device parity protection and mirrored protection
Device parity protection is a hardware function. Auxiliary storage pools and
mirrored protection are software functions. When you add disk units and start
device parity protection, the disk subsystem or IOP is not aware of any software
configuration for the disk units. The software that supports disk protection is
aware of which units have device parity protection.
These rules and considerations apply when mixing device parity protection with
mirrored protection:
• Device parity protection is not implemented on ASP boundaries.
• Mirrored protection is implemented on ASP boundaries.
• You can start mirrored protection for an ASP even if it currently has no units
that are available for mirroring because they all have device parity protection.
This ensures that the ASP is always fully protected, even if you add disks
without device parity protection later.
• When a disk unit is added to the system configuration, it may be device parity
protected.
• For a fully-protected system, you should entirely protect every ASP by device
parity protection, by mirrored protection, or both.
• Disk units that are protected by device parity protection can be added to an
ASP that has mirrored protection. The disk units that are protected by device
parity protection do not participate in mirrored protection (hardware protects
them already).
• When you add a disk unit that is not protected by device parity protection to an
ASP that has mirrored protection, the new disk unit participates in mirrored
protection. Disk units must be added to, and removed from, a mirrored ASP in
pairs with equal capacities.
• Before you start device parity protection for disk units that are configured
(assigned to an ASP), you must stop mirrored protection for the ASP.
• Before you stop device parity protection, you must stop mirrored protection for
any ASPs that contain affected disk units.
• When you stop mirrored protection, one disk unit from each mirrored pair
becomes non-configured. You must add the non-configured units to the ASP
again before starting mirrored protection.
4.7 Comparing the disk protection options
There are several methods for configuring your system to take advantage of the
disk protection features. Before selecting the disk protection options that you
want to use, compare the extent of protection that each one provides.
Hardware support for single system high availability 53
Table 2 provides an overview of the availability tools that can be used on the
AS/400 system to protect against different types of failure.
Table 2. Availability tools for the AS/400 system
Be aware of the following considerations when selecting disk protection options:
• With both device parity protection and mirrored protection, the system
continues to run after a single disk failure. With mirrored protection, the
system may continue to run after the failure of a disk-related component, such
as a controller or an IOP.
• When a second disk failure occurs, meaning that the system has two failed
disks, the system is more likely to continue to run with mirrored protection than
with device parity protection. With device parity protection, the probability of
the system failing on the second disk failure can be expressed as P out of n.
Here, P is the total number of disks on the system, and n is the number of
disks in the device parity set that had the first disk failure. With mirrored
protection, the probability of the system failing on the second disk failure is 1
out of n.
What is needed Device parity
protection
Mirrored
protection
User ASPs
Protection from data
loss due to
disk-related
hardware failure
Yes - See Note 1 Yes Yes - See Note 4
Maintain availability Yes Yes No
Help with disk unit
recovery
Yes - See Note 1 Yes Yes - See Note 4
Maintain availability
when disk controller
fails
See Note 3 Yes - See Note 2 No
Maintain availability
when disk I/O
processor fails
No Yes - See Note 2 No
Maintain availability
when disk I/O bus
fails
No Yes - See Note 2 No
Site disaster
protection
No Yes - See Note 5 No
Notes:
1. Load source unit and any disk units attached to the MFIOP are not protected.
2. Depends on hardware used, configuration, and level of mirrored protection.
3. With device parity protection using the 9337 Disk Array Subsystem, the system
becomes unavailable if a controller is lost.
4. With device parity protection using the IOP feature, the system is available as long
as the IOP is available.
5. Configuring ASPs can limit the loss of data and the recovery to a single ASP.
6. For site disaster protection, remote mirroring is required.
54 High Availability on the AS/400 System: A System Manager’s Guide
• Device parity protection requires up to 25% additional disk capacity for
storage of parity information. The actual increase depends on the number of
disk units that are assigned to a device parity set. A system with mirrored
protection requires twice as much disk capacity as the same system without
mirrored protection. This is because all information is stored twice. Mirrored
protection may also require more buses, IOPs, and disk controllers, depending
on the level of protection that you want. Therefore, mirrored protection is
usually a more expensive solution than device parity protection.
• Usually, neither device parity protection or mirrored protection has a
noticeable effect on system performance. In some cases, mirrored protection
actually improves system performance. The restore time to disk units
protected by device parity protection is slower than the restore time to the
same disk devices without device parity protection activated. This is because
the parity data must be calculated and written.
4.8 Concurrent maintenance
Concurrent maintenance is the process of repairing or replacing a failed
disk-related hardware component while using the system.
Concurrent maintenance allows disks, I/O processors, adapters, power supplies,
fans, CD-ROMs, and tapes to be replaced without powering down the server.
On systems without mirrored protection, the system is not available when a
disk-related hardware failure occurs. It remains unavailable until the failed
hardware is repaired or replaced. However, with mirrored protection, the failing
hardware can often be repaired or replaced while the system is being used.
Concurrent maintenance support is a function of system unit hardware
packaging. Not all systems support concurrent maintenance.
Mirrored protection only provides concurrent maintenance when it is supported by
the system hardware and packaging. The best hardware configuration for
mirrored protection also provides for the maximum amount of concurrent
maintenance.
It is possible for the system to operate successfully through many failures and
repair actions. For example, a failure of a disk head assembly does not prevent
the system from operating. A replacement of the head assembly and
synchronization of the mirrored unit can occur while the system continues to run.
The greater your level of protection, the more often concurrent maintenance can
be performed.
On some models, the system restricts the level of protection for Unit 1 and its
mirrored unit to controller-level protection only. Under some conditions, diagnosis
and repair can require active mirrored units to be suspended. You may prefer to
power down the system to minimize the exposure of operating with less mirrored
protection. Some repair actions require that the system be powered down.
Deferred maintenance is the process of waiting to repair or replace a failed
disk-related hardware component until the system can be powered down. The
system is available, although mirrored protection is reduced by whatever
hardware components have failed. Deferred maintenance is only possible with
mirrored protection or device parity protection.
Hardware support for single system high availability 55
4.9 Redundancy and hot spare
The basic rule for making a server system highly available is to use redundant
parts where needed and affordable. Just like the basic idea behind Redundant
Array of Independent Disks (RAID), all parts in a server are subject to be a single
point of failure. These part can include:
• The CPU
• The power supply
• The main logical board
• The main memory
• Adapter cards
These are all parts that, if even one fails, the overall system is rendered unusable.
To decrease the time involved in replacing a defective component, some
customers consider implementing what is known as a hot spare. In effect, the
customer keeps a local inventory of any component that either:
• Has a higher failure rate than usual
• Has a long lead-time when a replacement is required
Note: The term hot spare typically refers to a disk unit. However, the same
concept applies to a hot site or another system used for recovery.
Planning for spare disk units
Spare disk units can reduce the time the system runs without mirrored protection
after a disk unit failure of a mirrored pair. If a disk unit fails, and a spare unit of the
same capacity is available, that spare unit can be used to replace the failed unit.
The system logically replaces the failed unit with the selected spare unit. It then
synchronizes the new unit with the remaining good unit of the mirrored pair.
Mirrored protection for that pair is again active when synchronization completes
(usually less than an hour). However, it may take several hours (from the time a
service representative is called until the failed unit is repaired and synchronized)
before mirrored protection is again active for that pair.
To make full use of spare units, you need at least one spare unit of each capacity
that you have on your system. This provides a spare for any size of disk unit that
may fail.
4.10 OptiConnect: Extending a single system
An OptiConnect cluster is a collection of AS/400 systems connected by dedicated
fiber optic system bus cables. The systems in an OptiConnect cluster share a
common external optical system bus located in an expansion tower or frame. The
system providing the shared system bus is called the hub system. Each system
that plugs into this shared bus with an OptiConnect Bus Receiver card is called a
satellite system. Each satellite system dedicates one of its external system buses
that connects to the receiver card in the hub system’s expansion tower or rack.
The term OptiConnect link refers to the fiber optic connection between systems in
the OptiConnect cluster. The term path refers to the logical software established
connection between two OptiConnect systems. An OptiConnect network always
56 High Availability on the AS/400 System: A System Manager’s Guide
consists of at least two AS/400 systems. One of the AS/400 systems is
designated as the hub and at least one other system is designated as a satellite.
There are two levels of redundancy available in an OptiConnect cluster:
• Link redundancy: Link redundancy is an optical bus hardware feature. Any
two systems attached to the hub system shared bus can establish a path
between them, including paths to the hub system itself. You can establish path
redundancy by configuring two hub systems in the OptiConnect cluster. Each
satellite uses two buses to connect with two hub systems. OptiConnect
software detects the two logical paths between the two systems and uses both
paths for data flow. If a path failure occurs, the remaining path picks up all of
the communication traffic.
• Path redundancy: The OS/400 infrastructure for any system determines the
logical path to another system. It does this by designating which system bus
each of the systems that form the path uses. The link between any two
satellite systems does not depend on the hub system bus. The two systems
use the bus, but the hub system is not involved. Link redundancy is
determined by the system models. For OptiConnect clusters, link redundancy
is always provided when the extra fiber optic cable is installed. For path
redundancy, an extra set of OptiConnect receiver cards and an extra
expansion tower or frame are required along with another set of cables.
OptiConnect for OS/400 is an AS/400-to-AS/400 communication clustering
solution. It combines unique OptiConnect fiber bus hardware and standard
AS/400 bus hardware with unique software. It uses distributed data management
(DDM) to allow applications on one AS/400 system to access databases located
on other AS/400 systems. The AS/400 systems that contain the databases are
the database servers. The remote systems are considered the application client
or clients. In most cases, the hub also acts as the database server. Since all
systems can communicate with each other (providing that the hub is active), any
system can be the client. Some OptiConnect configurations have AS/400 systems
that act simultaneously as a server and a client. However, any system can act as
a database server.
OptiConnect for OS/400 is a communications vehicle. OptiConnect for OS/400
products provide AS/400 systems with physical links for a high availability
clustered solution. OptiConnect for OS/400 components support the
infrastructure for applications to conduct data exchanges over high speed
connections.
OptiConnect for OS/400 does not offer high availability with applications that
utilize the hardware links. OptiConnect for OS/400 can be the transport
mechanism for in-house developed applications, business partner software, or
remote journal support.
Further information on OptiConnect is found in 6.8, “Bus level interconnection” on
page 82, and 6.8.1, “Bus level interconnection and a high availability solution” on
page 84.
Hardware support for single system high availability 57
4.11 Cluster support
For planned or unplanned outages, clustering and system mirroring offer the most
effective solution. For customers requiring better than 99.9% system availability,
AS/400 clusters are viable.
Cluster solutions connect multiple AS/400 systems together with various
interconnect fabrics, including high-speed optical fiber, to offer a solution that can
deliver up to 99.99% system availability.
High availability is achieved with an alternative system that replicates the
availability of the production system. These systems are connected by
high-speed communications and use replication software to achieve this. They
also require enough DASD to replicate the whole or critical part of the production
system. With the entire system replicated, the mirrored system can enable more
than just a disaster recovery solution.
Combining these clusters with software from AS/400 high-availability business
partners (such as those described in Chapter 10, “High availability business
partner solutions” on page 111) improves the availability of a single AS/400
system by replicating business data to one or more AS/400 systems. This
combination can provide a disaster recovery solution.
Clusters are a configuration or a group of independent servers that appear on a
network as a single machine. As illustrated in Figure 11, a cluster is a collection
of complete systems that work together to provide a single and unified computing
resource
Figure 11. Cluster definition
This cluster group is managed as a single system or operating entity and is
designed specifically to tolerate component failures and to support the addition or
subtraction of components in a way that is transparent to users. Clusters allow
you to efficiently group systems together to set up an environment that provides
availability that approaches 100% for critical applications and critical data.
Resources can be accessed without regard to location. A client interacts with a
cluster as if it were a single system.
58 High Availability on the AS/400 System: A System Manager’s Guide
With the introduction of clusters, the AS/400e system offers a continuous
availability solution if your business demands operational systems 24 hours a day,
365 days a year (24 x 365). This solution, called OS/400 Cluster Resource
Services, is part of the OS/400 operating system. It provides failover and
switchover capabilities for your systems that are used as database servers or
application servers. If a system outage or a site loss occurs, the functions that are
provided on a clusters server system can be switched over to one or more
designated backup systems that contain a current copy (replica) of your critical
resource. The failover can be automatic if a system failure should happen, or if
you can control how and when the transfer takes place by manually initiating a
switchover.
Cluster management tools control the cluster from anywhere in the network. End
users work on servers in the cluster without knowing or caring where their
applications are running.
In the event of a failure, Cluster Resource Services (CRS), which is running on all
systems, provides a switchover. This switch causes minimal impact to the end
user or applications that are running on a server system. Data requesters are
automatically rerouted to the new primary system. You can easily maintain
multiple data replications of the same data.
Any AS/400 model that can run OS/400 V4R4 or later is compatible for
implementing clustering. You must configure Transmission Control
Protocol/Internet Protocol (TCP/IP) on your AS/400e systems before you can
implement clustering. In addition, you can purchase a cluster management
package from a High Availability Business Partner (HAV BP) that provides the
required replication functions and cluster management capabilities.
Refer to AS/400 Clusters: A Guide to Achieving Higher Availability, SG24-5194,
for further information.
4.12 LPAR hardware perspective
Logical partitions allow you to
run multiple independent
OS/400 instances or
partitions. Figure 12 shows a
basic LPAR configuration. For
V4R5, each partition has has
its own processors, memory,
and disks. For V5R1,
resources can be share
between partitions. With
logical partitioning, you can
address multiple system
requirements in a single
machine to achieve server
consolidation, business unit
consolidation, and mixed production and test environments. You can run a cluster
environment on a single system image. LPAR support is available on n-way
symmetric multiprocessing iSeries models 8xx and AS/400 models 6xx, Sxx, and
7xx. See 7.5, “Logical Partition (LPAR) support” on page 93.
Primary partition
Development
environment
#1
SYS1
OS/400 OS/400
Production
environment
SYS2
PPPPP PP
SYS3
Development
environment
#2
OS/400
P
New release
testing
840 8-way AS/400 with 3 partitions
V4R5 V4R4 V4R5
Figure 12. A basic LPAR configuration
Hardware support for single system high availability 59
By itself, LPAR does not provide a significant availability increase. It can,
however, be used to complement other availability strategies.
See 7.5, “Logical Partition (LPAR) support” on page 93, for a discussion of LPAR
from an OS/400 view.
4.12.1 Clustering with LPAR support
Since each partition on an LPAR system is treated as a separate server, you can
run a cluster environment on a single system image. One cluster node per CPU
can exist within one LPAR system.
Clustering partitions can provide for a more cost efficient clustering solution than
multiple systems. However, an LPAR clustered environment increases single
points of failure. For example, if the server’s primary partition becomes
unavailable, all secondary partitions also become unavailable (the opposite is not
true).
In some environments, LPAR ideally lends itself to situations where both a local
and remote backup server is desired. A good example is when a business works
to provide its own disaster recovery capability.
The highest level of
availability is obtained
with two separate
servers. Figure 13 shows
that, with clustering
active, data is replicated
to both the local backup
server and the remote
server. In the event of a
disaster (or the need for
the entire local hardware
to be powered off), the
remote backup server is
available. In some cases, this is more cost-efficient (including floor space) than
separate servers.
Integrated availability options
In most cases, it is recommended that integrated availability solutions be used
with a cluster to further mask or reduce downtime and to increase a cluster's
efficiency. Consider the following list:
• Disk protection: Device Parity Protection (RAID-5) and OS/400 Disk Mirroring.
• Auxiliary storage pools (ASPs)
• Access path protection
• Logical Partitions (LPAR)
In all cases, it is highly recommended that these integrated availability options be
used in a clustered environment, as well as on a standalone iSeries or AS/400
server.
Primary partition
Production
environment
SYS1
OS/400 OS/400
Backup
environment 2
SYS2
PP PPPPPP
Local 8-way iSeries (partitioned)
SYS3
Backup
environment 3
and remote hot
backup for
disaster
recovery
OS/400
PPPP
Remote 4-way
AS/400
HABP Replication HABP Replication
HABP Replication
Figure 13. LPAR, local and remote iSeries and AS/400 cluster
60 High Availability on the AS/400 System: A System Manager’s Guide
4.13 UPS
An uninterruptible power supply (UPS) provides auxiliary power to the processing
unit, disk units, the system console, and other devices that you choose to protect
from power loss. When you use a UPS with the AS/400 system, you can:
• Continue operations during brief power interruptions (brown outs).
• Protect the system from voltage peaks (white outs).
• Provide a normal end of operations that reduces recovery time when the
system is restarted. If the system abnormally ends before completing a normal
end of operations, recovery time is significant.
Normally, a UPS does not provide power to all local workstations. The UPS also
usually does not provide power to modems, bridges, or routers that support
remote workstations. Consider supplying alternate power to both workgroups
since the inability of worker access to information disrupts productivity. You can
avoid such disruption with proper availability and recovery implementation.
Also, design your interactive applications to handle the loss of communication
with a workstation. Otherwise, system resources are used in an attempt to
recover devices that have lost power. Refer to Chapter 12, “Communications
Error Recovery and Availability” in The System Administrator’s Companion to
AS/400 Availability and Recovery, SG24-2161, for more information on resources
used during device recovery.
The programming language reference manuals provide examples of how to use
the error feedback areas to handle workstations that are no longer
communicating with the application. Backup and Recovery, SC41-5304,
describes how to develop programs to handle an orderly shutdown of the system
when the UPS takes over.
4.14 Battery backup
Most (but not all) AS/400 models are equipped with a battery backup. Based on
the system storage size, relying on a battery backup for enough time for an
orderly shutdown is not sufficient.
The battery capacity typically varies between 10 and 60 minutes. The useful
capacity depends on the application requirements, main storage size, and system
configuration. Consider the reduction of capacity caused by the natural aging of
the battery and environmental extremes of the site when selecting the battery.
The battery must have the capacity to maintain the system load requirements at
the end of its useful life.
Refer to Backup and Recovery, SC41-5304, for power down times for the
advanced series systems. Refer to the AS/400 Physical Planning Reference,
SA41-5109, for power down times for the AS/400 Bnn-Fnn models. Also, refer to
the Physical Planning Reference for later AS/400 models at the Web site:
http://www.as400.ibm.com/tstudio/planning/index.rf.htm
Hardware support for single system high availability 61
4.15 Continuously powered main storage
On V3R6 systems and later, AS/400 systems are equipped with a System Power
Control Network (SPCN) feature. This provides the Continuously Powered Main
Storage (CPM) function. During a power fluctuation, the transition to CPM mode
is 90 seconds after an initial 30 second waiting period. The internal battery
backup provides sufficient power to keep the AS/400 system up for the 120
seconds until the transition to the CPM is complete. With CPM enabled, the
battery provides sufficient power to shut down the system and maintain the
contents of memory for up to 48 hours after a power loss without user interface or
control.
The transition to CPM is irreversible. CPM interrupts the processes at the next
microcode end statement and forces as many updates to the disk as it can.
During the next IPL, it restores main storage and attempts to complete
outstanding updates. Preserving main storage contents significantly reduces the
amount of time the system requires to perform an IPL after a power loss. CPM
operates outside of transaction boundaries.
You can use the CPM feature along with a UPS (or the battery backup). If the
system detects that the UPS can no longer provide sufficient power to the
system, the data currently in memory is put into “sleep” mode. The CPM storage
feature takes control and maintains data in memory for up to 48 hours. With the
CPM feature, the system automatically initiates an IPL after power is restored.
CPM is a viable feature. Choosing to use CPM depends on your expectations of
your local power and battery backup or generator to maintain power at all times.
Refer to Backup and Recovery, SC41-5304, for more information on CPM
requirements.
4.16 Tape devices
For information on what tape devices are available for each AS/400 model, and
the hardware and software requirements to support each model, refer to the
iSeries Handbook, GA19-5486, and iSeries and AS/400e System Builder,
SG24-2155.
For save and restore performance rates, see Appendix C, “Save and Restore
Rates of IBM Tape Drives for Sample Workloads”, and Section 8.1, “Save and
Restore Performance” in the AS/400 Performance Capabilities Manual at:
http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R5PDF/AS4PPCP3.PDF
4.16.1 Alternate installation device
On V4R1 (and later) systems, you can use a combination of devices that are
attached on the first system bus, as well as additional buses. The alternate
installation device does not need to be attached to the first system bus. For
example, the 3590 tape drive can be positioned up to 500 meters or two
kilometers away. This enables a physical security improvement since users who
are allowed access to the machine room may be different than those operating
the tape drives.
62 High Availability on the AS/400 System: A System Manager’s Guide
You can select an alternate installation device connected through any I/O bus
attached to the system. When you perform a D-mode IPL (D-IPL), you can use
the tape device from another bus using the Install Licensed Internal Code display.
For example, if you have a 3590 attached to another bus (other than Bus 1), you
can choose to install from the alternate installation device using the Install
Licensed Internal Code display and then continue to load the LIC, OS/400, and
user data using the alternate installation device.
Note: Set up alternate installation device support prior to performing a D-IPL.
System Licensed Internal Code (SLIC) media is necessary to perform the D-IPL
that restores and installs from the tape device.
Some models (typically with 3590 tape devices attached) experience a
performance improvement when using an alternate installation device for other
save and restore or installation operations. This is caused by having the tape
drive on a different IOP than the one to which the load source unit is attached. On
systems prior to V4R1, the alternate installation device is only supported using
devices attached to the first system bus. The first system bus connects to the
service processor IOP. Typically, this is where the optical or tape devices used for
installations are attached.
Before using the alternate installation device, ensure that it is defined on a bus
other than system Bus 1. You must enable the device. When installing from the
alternate installation device, you need both your tape media and the CD-ROM
media containing the Licensed Internal Code.
Recommendation
© Copyright IBM Corp. 2001 63
Chapter 5. Auxiliary storage pools (ASPs)
An auxiliary storage pool (ASP) is a software definition of a group of disk units on
your system. This means that an ASP does not necessarily correspond to the
physical arrangement of disks. Conceptually, each ASP on your system is a
separate pool of disk units for single-level storage. The system spreads data
across the disk units within an ASP. If a disk failure occurs, you need to recover
only the data in the ASP that contained the failed unit. Prior to V5R1, here are two
types of ASPs:
• System auxiliary storage pool
• User auxiliary storage pools
Your system may have many disk units attached to it that are optionally assigned
to an auxiliary storage pool. To your system, the pool looks like a single unit of
storage. The system spreads objects across all disk units. You can use auxiliary
storage pools to separate your disk units into logical subsets.
When you assign the disk units on your system to more than one ASP, each ASP
can have different strategies for availability, backup and recovery, and
performance. ASPs provide a recovery advantage if the system experiences a
disk unit failure resulting in data loss. If this occurs, recovery is only required for
the objects in the ASP that contained the failed disk unit. System objects and
user objects in other ASPs are protected from the disk failure. There are also
additional benefits and certain costs and limitations that are inherent in using
ASPs.
5.1 Deciding which ASPs to protect
Because mirrored protection is configured by auxiliary storage pool, the ASP is
the user’s level of control over single-level storage. Mirrored protection can be
used to protect one, some, or all ASPs on a system. However, multiple ASPs are
not required in order to use mirrored protection.
Mirrored protection works well when all disk units on a system are configured into
a single ASP (the default on the AS/400 system). In fact, mirroring reduces the
need to partition auxiliary storage into ASPs for data protection and recovery.
However, ASPs may still be recommended for performance and other reasons.
To provide the best protection and availability for the entire system, mirror all
ASPs in the system. Consider the following situations:
• If the system has a mixture of some ASPs with and without mirrored
protection, a disk unit failure in an ASP without mirrored protection severely
limits the operation of the entire system. Data can be lost in the ASP in which
the failure occurred. A long recovery may be required.
Independent ASPs are introduced at V5R1. At the time this Redpaper was
written, the appropriate information was not available.
Note
64 High Availability on the AS/400 System: A System Manager’s Guide
• If a disk fails in a mirrored ASP, and the system also contains ASPs that are
not mirrored, data is not lost. However, in some cases, concurrent
maintenance may not be possible.
The disk units that are used in user ASPs should be selected carefully. For best
protection and performance, an ASP should contain disk units that are attached
to several different I/O processors. The number of disk units in the ASP that are
attached to each I/O processor should be the same (that is, balanced).
ASPs are further discussed in Chapter 5, “Auxiliary storage pools (ASPs)” on
page 63.
5.1.1 Determining the disk units needed
A mirrored ASP requires twice as much auxiliary storage as an ASP that is not
mirrored. This is because the system keeps two copies of all the data in the ASP.
Also, mirrored protection requires an even number of disk units of the same
capacity so that disk units can be made into mirrored pairs.
On an existing system, note that it is not necessary to add the same types of disk
units already attached to provide the required additional storage capacity. Any
new disk units may be added as long as sufficient total storage capacity and an
even number of storage units of each size are present. The system assigns
mirrored pairs and automatically moves the data as necessary. If an ASP does
not contain sufficient storage capacity, or if storage units cannot be paired,
mirrored protection cannot be started for that ASP.
The process of determining the disk units needed for mirrored protection is
similar for existing or new systems. Review the following points to plan disk
requirements:
1. Determine how much data each ASP contains.
2. Determine a target percent of storage used for the ASP (how full the ASP will
be).
3. Plan the number and type of disk units needed to provide the required storage.
For an existing ASP, you can plan a different type and model of disk unit to
provide the required storage.
After planning for all ASPs is complete, plan for spare units, if desired. Once you
know all of this information, you can calculate your total storage needs.
The planned amount of data and the planned percent of storage used work
together to determine the amount of actual auxiliary storage needed for a
mirrored ASP. For example, if an ASP contains 1 GB (GB equals 1,073,741,824
bytes) of actual data, it requires 2 GB of storage for the mirrored copies of the
data. If 50% capacity is planned for that ASP, the ASP needs 4 GB of actual
storage. If the planned percent of storage used is 66%, 3 GB of actual storage is
required. One gigabyte of real data (2 GB of mirrored data) in a 5 GB ASP results
in a 40% auxiliary storage utilization.
Total planned storage capacity needs
After planning for the number and type of storage units needed for each ASP on
the system, and for any spare storage units, add the total number of storage units
of each disk unit type and model.
Auxiliary storage pools (ASPs) 65
The number planned is the number of storage units of each disk unit type, not the
number of disk units.
The following section provides a more detailed description.
5.2 Assigning disk units to ASPs
If you decide that you want more than one auxiliary storage pool (ASP), make the
following determinations for each ASP:
• How much storage do you need?
• What disk protection (if any) should you use?
• Which disk units should be assigned?
• Which objects should be placed in the ASP?
The Workstation Customization Programming book, SC41-5605, provides
information to help you with these considerations. This book is only available
online at the AS/400 Library at: http://as400bks.rochester.ibm.com
At the site, click AS/400 Information Center. Select your language and click GO!
Click V4R4 and then click Search or view all V4R4 books. Enter the book
number in the seach field and click Find. Finally, click the appropriate publication
that appears.
When you work with disk configuration, you may find it helpful to begin by making
a list of all the disks and disk-related components on your system. You can put
this information in a chart like Table 3, or you may want to draw a diagram.
Table 3. Disk configuration example chart
5.3 Using ASPs
User ASPs are used to manage the following system performance and availability
requirements:
• Provide dedicated resources for frequently used availability objects, such as
journal receivers
• Allow online and unattended saves.
• Place infrequently used objects, such as large history files, on disk units with
slower performance
IOP Controller Unit Type and
model
Type and
model
Capacity Resource
name
Name of
mirrored pair
1 00 01 1 6602-030 1031 1 DD001
1 10 01 2 6602-074 733 1 DD019
1 10 02 3 6602-070 1031 1 DD036
1 00 02 6 6602-030 1031 1 DD002
1 10 03 4 6602-074 773 3 DD005
1 10 04 5 6602-074 773 3 DD033
66 High Availability on the AS/400 System: A System Manager’s Guide
5.3.1 Using ASPs for availability
Different parts of your system may have different requirements for availability and
recovery. For example, you may have a large history file that is changed only at
the end of the month. The information in the file is useful but not critical. You may
put this file in a separate library in a user ASP that does not have any disk
protection (mirrored protection or device parity protection). You could omit this
library from your daily save operations and choose to save it only at the end of the
month when it is updated.
Another example would be documents and folders. Some documents and folders
are critical to the organization and should be protected with device parity
protection or mirrored protection. They can be put in a protected user ASP. Others
are kept on the system to provide information but do not change very often. They
can be in a different user ASP with a different strategy for saving and for
protection.
5.3.2 Using ASPs to dedicate resources or improve performance
If you are using user ASPs for better system performance, consider dedicating
the ASP to one object that is very active. In this case, you can configure the ASP
with only one disk unit. However, it usually does not improve performance to
place a single device-parity protected unit in a user ASP because the
performance of that unit is affected by other disk units in the device parity set.
Refer to Figure 14 for a visual example of multiple ASPs.
Figure 14. Auxiliary storage pools
Allocating one user ASP exclusively for journal receivers that are attached to the
same journal can improve journaling performance. By having the journal and
database files in a separate ASP from the attached receivers, there is no
contention for journal receiver write operations. The units that are associated with
the ASP do not have to be repositioned before each read or write operation.
Journaling uses as many as 10 disk arms when writing to a journal receiver.
Configuring an ASP with more than 10 arms does not provide any additional
performance advantage for journaling. However, if you do have an ASP with more
than 10 arms, journaling uses the 10 fastest arms. If you add more disk units to
Load
Source
System ASP User ASP
used for save/archive
on compressed DASD
User ASP
used for journal receivers
ASP 1 ASP 2
ASP 3
Auxiliary storage pools (ASPs) 67
the ASP while the system is active, the system determines whether to use the
new disk units for journal receivers the next time the change journal function is
performed.
Another method for improving performance is to make sure that there are enough
storage units in the user ASP to support the number of physical input and output
operations that are done against the objects in the user ASP. You may have to
experiment by moving objects to a different user ASP and then monitor
performance in the user ASP to see if the storage units are used excessively. If
the units show excessive use, you should consider adding more disk units to the
user ASP.
5.3.3 Using ASPs with document library objects
You can place document library objects (DLOs) in user ASPs. The possible
advantages of placing DLOs in user ASPs are:
• The ability to reduce save times for DLOs and to separate them by their save
requirements.
• The ability to separate DLOs by availability requirements. Critical DLOs can be
placed in user ASPs that are protected by mirrored protection or device parity
protection. DLOs that change infrequently can be placed in unprotected ASPs
with slower drives.
• The ability to grow to a larger number of documents. If you have V3R7 or a
later release of the OS/400 licensed program, you can run multiple SAVDLO or
RSTDLO procedures against different ASPs. If you have V4R1 or a later
release of the OS/400 licensed program, you can run multiple SAVDLO
operations on the same ASP.
One approach for placing DLOs in user ASPs is to leave only system DLOs
(IBM-supplied folders) in the system ASP. Move other folders to user ASPs. The
system folders do not change frequently, so they can be saved infrequently.
You can specify an ASP on the SAVDLO command. This allows you to save all the
DLOs from a particular ASP on a given day of the week. For example, you could
save DLOs from ASP 2 on Monday, DLOs from ASP 3 on Tuesday, and so on. You
could save all changed DLOs daily.
The recovery steps if you use this type of save technique would depend on what
information was lost. If you lost an entire ASP, you would restore the last complete
saved copy of DLOs from that ASP. You would then restore the changed DLOs
from the daily saves.
When you save DLOs from more than one ASP in the same operation, a different
file and a sequence number are created on the tape for each ASP. When you
restore, you must specify the correct sequence number. This makes it simple to
restore the changed DLOs only to the ASP that was lost without needing to know
all the folder names.
These restrictions and limitations apply when placing DLOs in user ASPs:
• When using a save file for a save operation, you can save DLOs from only one
ASP.
• When using an optical file for a save operation, you can save DLOs from only
one ASP.
68 High Availability on the AS/400 System: A System Manager’s Guide
• If you are saving to a save file and you specify SAVDLO DLO(*SEARCH) or
SAVDLO DLO(*CHG), you must also specify an ASP, even if you know the
results of you search are found in a single ASP.
• Documents that are not in folders must be in the system ASP.
• Mail can be filed into a folder on a user ASP. Unfiled mail is in the system ASP.
Note: When you specify DLO(*SEARCH) or DLO(*CHG) for the SAVDLO
command, specify an ASP, if possible. Specifying an ASP saves system
resources.
5.3.4 Using ASPs with extensive journaling
If journals and files being journaled are in the same ASP as the receivers and the
ASP overflows, you must end journaling of all files and recover from the
overflowed condition for the ASP. Backup and Recovery describes how to recover
an overflowed ASP.
If the journal receiver is in a different ASP than the journal, and the user ASP that
the receiver is in overflows, perform the following steps:
1. Create a new receiver in a different user ASP.
2. Change the journal (CHGJRN command).
3. Save the detached receiver.
4. Delete the detached receiver.
5. Clear the overflowed ASP without ending journaling.
6. Create a new receiver in the cleared ASP.
7. Attach the new receiver with the CHGJRN command.
5.3.5 Using ASPs with access path journaling
If you plan to use explicit access path journaling, IBM recommends that you first
change the journal to a journal receiver in the system ASP (ASP 1) for a few days.
Start access path journaling to see storage requirements for the receiver before
you allocate the specific size for a user ASP.
5.3.6 Creating a new ASP on an active system
Beginning with V3R6 of the OS/400 licensed program, you can add disk units
while your system is active. When you add disk units to an ASP that does not
currently exist, the system creates a new ASP. If you choose to create a new user
ASP while your system is active, be sure you understand the following
considerations:
• You cannot start mirrored protection while the system is active. The new ASP
is not fully protected unless all of the disk units have device parity protection.
• You cannot move existing disk units to the new ASP while your system is
active.The system must move data when it moves disk units. This can be done
only through Dedicated Service Tools (DST).
• The system uses the size of an ASP to determine the storage threshold for the
journal receivers that are used by system-managed access-path protection
(SMAPP).
When you create an ASP while your system is active, the size of the disk units
that you specify on the operation that creates the ASP is considered the size
of the ASP for SMAPP. For example, assume that you add two disk units to a
Auxiliary storage pools (ASPs) 69
new ASP (ASP 2). The total capacity of the two disk units is 2,062 MB. Later,
you add two more disk units to increase the capacity to 4,124 MB. For the
purposes of SMAPP, the size of the ASP remains 2,062 MB until the next time
you perform an IPL. This means that the storage threshold of your SMAPP
receivers is lower and the system must change receivers more often. Usually,
this does not have a significant impact on system performance.
The system determines the capacity of every ASP when you perform an IPL. At
that time, the system makes adjustments to its calculations for SMAPP size
requirements.
5.3.7 Making sure that your system has enough working space
When you make changes to your disk configuration, the system may need
working space. This is particularly true if you plan to move disk units from one
ASP to another. The system needs to move all the data from the disk unit to other
disk units before you move it. There are system limits for the amount of auxiliary
storage.
If your system does not have sufficient interim storage, begin by cleaning up your
disk storage. Many times, users keep objects on the system, such as old spooled
files or documents, when these objects are no longer needed. Consider using the
automatic cleanup function of Operational Assistant to free some disk space on
your system.
If cleaning up unnecessary objects in auxiliary storage still does not provide
sufficient interim disk space, another alternative is to remove objects from your
system temporarily. For example, if you plan to move a large library to a new user
ASP, you can save the library and remove it from the system. You can then restore
the library after you have moved disk units. Here is an example of how to
accomplish this:
1. Save private authorities for the objects on your system by typing SAVSECDTA DEV
(tape-device).
2. Save the object by using the appropriate SAVxxx command. For example, to
save a library, use the SAVLIB command. Consider saving the object twice to
two different tapes.
3. Delete the object from the system by using the appropriate DLTxxx command.
For example, to delete a library, use the DLTLIB command.
4. Recalculate your disk capacity to determine whether you have made sufficient
interim space available.
5. If you have enough space, perform the disk configuration operations.
6. Restore the objects that you deleted.
5.3.8 Auxiliary storage pools: Example uses
The following list explains how ASPs are used to manage system performance
and backup requirements:
• You can create an ASP to provide dedicated resources for frequently used
objects, such as journal receivers.
70 High Availability on the AS/400 System: A System Manager’s Guide
• You can create an ASP to hold save files. Objects can be backed up to save
files in a different ASP. It is unlikely that both the ASP that contains the object
and the ASP that contains the save file will be lost.
• You can create different ASPs for objects with different recovery and
availability requirements. For example, you can put critical database files or
documents in an ASP that has mirrored protection or device parity protection.
• You can create an ASP to place infrequently used objects, such as large
history files, on disk units with slower performance.
• You can use ASPs to manage recovery times for access paths for critical and
noncritical database files using system-managed access-path protection.
5.3.9 Auxiliary storage pools: Benefits
Placing objects in user ASPs can provide several advantages, including:
• Additional data protection: By separating libraries, documents, or other
objects in a user ASP, you protect them from data loss when a disk unit in the
system ASP or other user ASPs fails. For example, if you have a disk unit
failure, and data contained on the system ASP is lost, objects contained in
user ASPs are not affected and can be used to recover objects in the system
ASP. Conversely, if a failure causes data that is contained in a user ASP to be
lost, data in the system ASP is not affected.
• Improved system performance: Using ASPs can also improve system
performance. This is because the system dedicates the disk units that are
associated with an ASP to the objects in that ASP. For example, suppose you
are working in an extensive journaling environment. Placing libraries and
objects in a user ASP can reduce contention between the journal receivers
and files if they are in different ASPs. This improves journaling performance.
However, placing many active journal receivers in the same user ASP is not
productive. The resulting contention between writing to more than one receiver
in the ASP can slow system performance. For maximum performance, place
each active journal receiver in a separate user ASP.
• Separation of objects with different availability and recovery
requirements: You can use different disk protection techniques for different
ASPs. You can also specify different target times for recovering access paths.
You can assign critical or highly used objects to protected high-performance
disk units. You may assign large low-usage files, like history files, to
unprotected low-performance disk units.
5.3.10 Auxiliary storage pools: Costs and limitations
There are some specific limitations that you may encounter when using auxiliary
storage pools (ASPs):
• The system cannot directly recover lost data from a disk unit media failure.
This situation requires you to perform recovery operations.
• Using ASPs can require additional disk devices.
• Using ASPs requires you to manage the amount of data in an ASP and avoid
an overflowed ASP.
• You need to perform special recovery steps if an ASP overflows.
• Using ASPs requires you to manage related objects. Some related objects,
such as journals and journaled files, must be in the same ASP.
Auxiliary storage pools (ASPs) 71
5.4 System ASP
The system automatically creates the system ASP (ASP 1). This contains disk
Unit 1 and all other configured disks that are not assigned to a user ASP. The
system ASP contains all system objects for the OS/400 licensed program and all
user objects that are not assigned to a user ASP.
Note: You can have disk units that are attached to your system but are not
configured and are not being used. These are called non-configured disk units.
There are additional considerations that you should be aware of regarding the
capacity of the system ASP and protecting your system ASP. These are explained
in the following sections.
5.4.1 Capacity of the system ASP
If the system ASP fills to capacity, the system ends abnormally. If this occurs, you
must perform an IPL of the system and take corrective action (such as deleting
objects) to prevent this from re-occurring. You can also specify a threshold that,
when reached, warns the system operator of a potential shortage of space. For
example, if you set the threshold value at 80 for the system ASP, the system
operator message queue (QSYSOPR) and the system message queue
(QSYSMSG) are notified when the system ASP is 80% full. A message is sent
every hour until the threshold value is changed, or until objects are deleted or
transferred out of the system ASP. If you ignore this message, the system ASP
fills to capacity and the system ends abnormally.
A third method for preventing the system ASP from filling to capacity is to use the
QSTGLOWLMT and QSTGLOWACN system values.
5.4.2 Protecting your system ASP
IBM recommends that you use device parity protection or mirrored protection on
the system ASP. Using disk protection tools reduces the chance that the system
ASP will lose all data. If the system ASP is lost, addressability to objects in every
user ASP is also lost.
You can restore the addressability by restoring the entire system or by running
the Reclaim Storage (RCLSTG) command. However, the RCLSTG command
cannot recover object ownership. After you run the command, the QDFTOWN
user profile owns all objects found without ownership intact. You can use the
Reclaim Document Library Object (RCLDLO) command procedure to recover
ownership of document library objects.
5.5 User ASPs
Grouping a set of disk units together and assigning that group to an auxiliary
storage pool (ASP) creates a user ASP. You can configure user ASPs 2 through
16. They can contain libraries, documents, and certain types of objects. There are
two types of user ASPs:
• History file
• Non-library user ASPs
Once you have ASPs configured, you should protect them by using mirroring or
device parity protection.
72 High Availability on the AS/400 System: A System Manager’s Guide
5.5.1 Library user ASPs
Library user ASPs contain libraries and document library objects (DLOs). It is
recommended that you use library user ASPs because the recovery steps are
easier than with non-library user ASPs. You should be familiar with the following
regulations regarding library user ASPs:
• Do not create system or product libraries (libraries that begin with a Q or #)or
folders (folders that begin with a Q) in a user ASP. Do not restore any of these
libraries or folders to a user ASP. Doing so can cause unpredictable results.
• Library user ASPs may contain both libraries and document library objects.
The document library for a user ASP is called QDOCnnnn (here, nnnn is the
number of the ASP).
• Journals and files that are being journaled must be in the same ASP. Place the
journal receivers in a different ASP. This protects against the loss of the files
and the receivers if a disk media failure occurs.
• Journaling cannot be started on an object (STRJRNPF or STRJRNAP
command) if the journal (object type *JRN) and the object to be journaled are
in different ASPs.
• Journaling cannot be started again for a file that is saved and then restored to
a different ASP that does not contain the journal. The journal and the file must
be in the same ASP for journaling to be automatically started again for the file.
• No database network can cross ASP boundaries.
• You cannot create a file in one ASP that depends on a file in a different ASP.
All based-on physical files for a logical file must be in the same ASP as the
logical file. The system builds access paths only for database files in the same
ASP as the based-on physical file (temporary queries are not limited). Access
paths are never shared by files in different ASPs. Record formats are not
shared between different ASPs. Instead, a format request is ignored and a
new record format is created.
• You can place an SQL collection in a user ASP. You specify the target ASP
when you create the collection.
• If the library user ASP does not contain any database files, set the target
recovery time for the ASP to *NONE. This would be true, for example, if the
library user ASP contains only libraries for journal receivers. If you set the
access path recovery time to *NONE, this prevents the system from doing
unnecessary work for that ASP. The Backup and Recovery Guide, SC41-5304,
describes how to set access path recovery times.
Non-library user ASPs
Non-library user ASPs contain journals, journal receivers, and save files with
libraries that are in the system ASP. If you are assigning access path recovery
times for individual ASPs, you should set the target recovery time for a non-library
user ASP to *NONE. A non-library user ASP cannot contain any database files
and cannot, therefore, benefit from SMAPP.
If you set an access path recovery time for a non-library user ASP to a value
other than *NONE, the system performs extra work with no possible benefit.
Backup and Recovery Guide, SC41-5304, describes how to set access path
recovery times.
Auxiliary storage pools (ASPs) 73
Using ASPs can require protecting user ASPs. Keep the following points in mind
regarding user ASP protection:
• All ASPs, including the system ASP, should have mirrored protection or consist
entirely of disk units with device parity protection to ensure that the system
continues to run after a disk failure in an ASP.
• If a disk failure occurs in an ASP that does not have mirrored protection, the
system may not continue to run. This depends on the type of disk unit and the
error.
• If a disk failure occurs in an ASP that has mirrored protection, the system
continues to run (unless the both storage units of a mirrored have failed).
• If a disk unit fails in an ASP that has device parity protection, the system
continues running as long as no other disk unit in the same device parity set
fails.
• System limits are set for auxiliary storage. During an IPL, the system
determines how much auxiliary storage is configured on the system. The total
amount is the sum of the capacity of the configured units and their mirrored
pairs (if any). Disk units that are not configured are not included. The amount
of disk storage is compared to the maximum that is supported for a particular
model.
• If more than the recommended amount of auxiliary storage is configured, a
message (CPI1158) is sent to the system operator’s message queue
(QSYSOPR) and the QSYSMSG message queue (if it exists on the system).
This message indicates that too much auxiliary storage exists on the system.
This message is sent once during each IPL as long as the amount of auxiliary
storage on the system is more than the maximum amount supported.
74 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 75
Chapter 6. Networking and high availability
One of the major items to consider for availability is the network. When planning
for a network, capacity and accessibility are addressed, just as capacity and
accessibility are planned for the system itself.
Your company needs a stable computing environment to fuel its business growth
and to sharpen its advantage in a competitive marketplace. When major hubs or
routers are down, users have difficulty accessing key business applications. The
ability to carry on business, such as enrolling new members to a bank, or to
respond to member inquiries, is impacted. To minimize this effect, aim for
stringent metrics (for example, 99.5 percent availability of the operational
systems).
Ultimately, the network must be sound and recoverable to support core business
applications. Employ a carefully planned comprehensive network management
solution that is:
• Scalable and flexible, no matter how complicated the task
• Provides around-the-clock availability and reliability of applications to users,
no matter where they’re located
• Capable of building a solid network foundation, no matter how complex the
system
This chapter comments on the various network components of an HA solution
and how they can affect the overall availability.
6.1 Network management
Networks typically comprise a wide variety of devices, such as hubs, routers,
bridges, switches, workstations, PCs, laptops, and printers. The more different
components and protocols there are in a network, the more difficult it is to
manage them.
Problem detection and response can be at a local or remote level. Tools can help
you correct problems at the source before users are affected and minimize
downtime and performance problems.
Management tools provide a detailed view of the overall health and behavior of
your network's individual elements. These elements, such as routers, servers,
end systems, data, event flow, and event traffic are useful to record. When
network problems occur, use management tools to quickly identify and focus on
the root cause of the error.
The focal point of control is where all network information is viewed to provide a
complete picture of what is happening. This console or server provides
monitoring and alert actions, as well as maintenance capabilities.
With proper network management, the time to respond to and resolve a network
error is reduced.
76 High Availability on the AS/400 System: A System Manager’s Guide
6.2 Redundancy
Availability is measured as the percentage of time that online services for a
critical mass of end users can function at the end-user level during a customer's
specified online window.
When systems are combined into a cluster, the supporting network must be able
to maintain the same level of availability as the cluster nodes. Communication
providers must deliver guarantees that they will be available for, and have
sufficient capacity for, all possible switch scenarios. There must be alternate
network paths to enable the cluster services to manage the cluster resources.
Redundant paths can prevent a cluster partition outage from occurring.
Redundant network connections are illustrated in Figure 15.
Figure 15. Redundant network connections
As shown in Figure 15, the adapter card can be a LAN, WAN, or ATM adapter.
Duplicates are installed, as well as duplicate memory and disk units. Indeed,
System A serves as a duplicate system to System B, and vice versa.
When a network connection between two machines that are part of the business
process does not function, it does not necessarily mean the business process is
in danger. If there is an alternative path and, in case of malfunctioning, the
alternative path is taken automatically, monitoring and handling these early
events assures a minimum breakage.
6.3 Network components
Protocol, physical connection, the hardware and software needed, the backup
options available, and network design are all factors to consider for a highly
available network.
Memory
card
Memory
card
Processor
Card
Memory
card
Memory
card
Adapter
Card
(redundant)
Adapter
Card
(active)
Processor
Card
System B
Processor
LAN, WAN,
or ATM cards
Mirrored disks Mirrored disks
System A
Processor
Network
Adapter
Card
(redundant)
Adapter
Card
(active)
Networking and high availability 77
Components involved in a network include:
• Protocols:
– Bisynchronous
– Asynchronous
– Systems Network Architecture (SNA): The predominate protocol for
connecting terminals to host systems. SNA has strong support for
congestion control, flow control, and traffic prioritization. It is known to
provide stable support for large and complex networks. However, SNA is
not capable of being routed natively across a routed network. Therefore, it
must be encapsulated to flow across such a network.
– Transmission Control Protocol/Internet Protocol (TCP/IP): TCP/IP is
the protocol used to build the world’s largest network, the Internet. Unlike
SNA, all hosts are equal in TCP/IP. The protocol can be carried natively
through a routing network. TCP/IP is the de facto published standard. This
allows many vendors to interoperate between different machines. Poor
congestion control, flow control, traffic prioritization, and a lack of controls
makes it difficult to guarantee a response time over a wide area network.
– Internetwork Packet Exchange (IPX) was developed for NetWare:
NetWare is a network operating system and related support services
environment introduced by Novell, Inc. It is composed of several different
communication protocols. Services are provided in a client/server
environment in which a workstation (client) requests and receives the
services that are provided by various servers on the network. Since this is
usually a secondary protocol, the requirements need to be analyzed.
However, they may need to be considered for transport only.
– Communication lines: Communication lines support the previously
described protocols. Special interfaces may be required to connect to the
AS/400e system, remote controllers, personal computers, or routers. The
type and speed of the line depends on the requirement of performance and
response times. Considerations for such facilities include:
• Leased: Private set of wires from the telephone company. These wires
can be:
– Point-to-point: Analog or digital
– Multi-point: Phone company provides the connection of multiple
remote sites through the central telephone offices
• Integrated Services Digital Network (ISDN): Basic or primary access
• Frame relay: An internal standard. The re-routing of traffic is the
responsibility of the frame relay provider. For a fail-safe network, all
endpoints should have a dial backup or ISDN connection.
• Virtual Private Networks (VPN): Utilize a service provider that provides
encryption and uses the Internet network for the transmission of data to
the other site. VPN allows secure transfers over TCP/IP (IPSec) and
multiprotocol (L2TP) networks.
• Multiprotocol Switched Services: ATM or LAN
• Hardware: A factor that may limit the speed in which communication lines are
connected. These factors include:
78 High Availability on the AS/400 System: A System Manager’s Guide
– Controllers: Manage connections for legacy terminals and personal
computers with twinax support cards
– Bridge
– Routers: Allows encapsulation of SNA data into TCP/IP and routes it over
a communication network
– Frame Relay Access Devices (FRADs): Used to buffer SNA devices from
a frame relay network. It also channels SNA, BSC, Asynch, and
multiprotocol LAN traffic onto a single frame relay permanent virtual circuit
and eliminates the need to have separate WAN links for traditional and LAN
traffic.
– Terminal Adapter: Used in an ISDN network to buffer the device from the
physical connection
– Modems: Used for analog lines
– DSU and CSU: Used for digital lines
– Switches: WAN switches for networks carrying high volumes of traffic at a
high speed. These are networks that cope with both legacy and new
emerging applications in a single network structure. The network mixes
data, voice, image, and video information, and transports different traffic
types over a single bandwidth channel to each point.
• Software: When the network consists of LANS, routers, and communication
lines, a management tool such as Operation Control/400 with Managed
System Services/400, Nways Workgroup Manager, or IBM Netfinity is advised
to help manage the network.
From routers to remote controllers, review all network components. If there are
critical requirements for remote access, you must provide alternative network
paths. This can be as simple as a dialup link or as complex as a multi-path private
network.
6.4 Testing and single point of failure
The problem with managing a complex computing system is that anything can go
wrong with any components at any time. In any development shop, applications
are tested. Network, hardware, and external link recovery should be tested with
the same emphasis. Just as planning for redundancy, recovery, are a must for
high availability, so is testing possible scenarios.
In a highly available environment, testing is particularly more critical. By
employing a highly available solution, a business makes a serious commitment to
exceptional levels of reliability. These levels not only rely on hardware and
software, but they can only be achieved with stringent problem and change
management. Identified problems must be replicated and a change must be put in
place and tested before further presenting a further production risk.
Testing should involve obvious things (such as hardware, network, and
applications), and less obvious components (such as the business processes
associated with the computer systems, facilities, data, and applications from
external providers, as well as accurately documented job responsibilities).
Consider your implementation test environment and your ongoing problem or
change test environment when implementing a highly available solution. A
Networking and high availability 79
second system or separate LPAR partition can be used for operating system and
application test environments.
Figure 16 illustrates a very simple HA environment. There is a two-node cluster or
replication environment. A separate system is available for development that has
no links to the cluster. Development cannot test changes in a clustered
environment. To enable tested changes to be made to the cluster, a fourth system
is added. Changes can then be tested on the development systems before
moving these changes into production.
Figure 16. Cluster test scenario
Note: Figure 16 illustrates a basic customer setup. The routers, LANs, WANs,
etc., required to simulate the real environment are not shown.
Creating a separate cluster with two smaller systems meets most testing needs.
However, some hardware or peripherals may not work with smaller systems. The
production environment can only truly be tested with actual and careful function
duplication.
Testing needs to involve a planned switchover, a failover (unplanned switchover),
the rejoin of the systems, and adding a system to the cluster. Be sure to re-test
these scenarios after each system upgrade and any major change to any of the
cluster components.
A single network adapter card in a server system that works in a client/server
environment is a single-point-of-failure (SPOF) for this server. Likewise, a single
SCSI adapter connecting to an external storage system is a SPOF. If a complete
server fails within a group of several servers, and the failed server cannot be
easily and quickly replaced by another server, this server is an SPOF for the
server group or cluster.
The straightforward solution is that adapter cards can be made redundant by
simply doubling them within a server and making sure a backup adapter becomes
active if the primary one fails.
System B
Production
System C
Backup
System D
Development 2 System A
Development 1
80 High Availability on the AS/400 System: A System Manager’s Guide
CPU, power supplies, and other parts can be made redundant within a server too.
This requires that the backup adapter becomes active if the primary one fails.
These components can also be made redundant by requiring special parts that
are not very common in the PC environment and thus quite expensive. However,
in cooperation with a software agent (the HA software), two or more servers in an
HA cluster can be set up to replace each other in case of a node outage.
When cluster nodes are placed side-by-side, a power outage or a fire can affect
both. Consequently, an entire building, a site, or even a town (earthquakes or
other natural disasters) can be an SPOF. Such major disasters can be handled by
simply locating the backup nodes at a certain distance from the main site. This
can be very costly and IT users must be careful to evaluate their situation and
decide which SPOFs to cover.
General considerations for testing a high availability environment are described in
Appendix F, “Cost components of a business case” on page 169.
6.5 Hardware switchover
A hardware switchover may occur in case of a planned role swap or an unplanned
role swap (for example, a system outage). The role swap typically involves 5250
device switching from the failed system to the backup system.
Note: A hardware switchover can also be called a role swap. Figure 17 shows an
example IP address assignment for two systems in a cluster preparing for a
hardware switchover.
Figure 17. IP address takeover between two systems in a cluster
In a clustered environment, the typical tasks for enabling a hardware switchover
are:
1. Quiesce the system:
a. Remove users from the production system.
b. Ensure all jobs in the production job queues have completed.
c. Hold those job queues.
Production system
1.3.22.426
1.3.22.427
1.3.22.322
1.3.22.327
Server 1 Server 2
1.3.22.120
(Inactive)
IP Address takeover
1.3.22.120
(Active)
Networking and high availability 81
d. Check synchronization of database transactions.
e. End subsystems.
2. End high availability applications on the source machine.
Make sure all journal receiver entries are complete.
3. End high availability applications on the target machine.
4. Switch between the source and target systems.
5. Switch the network to the target system.
6. Start application and transaction mirroring in reverse mode on the target
system.
7. Connect users to the target system.
8. Make necessary changes and updates to the source system and start that
system.
9. Switch the roles of the source and target systems again.
10.Switch the network.
11.Start mirroring in normal model.
Note: Switchover capabilities are enhanced at V5R1. However, they are not
covered in this Redpaper.
6.6 Network capacity and performance
As business requirements have evolved, a greater dependency has been put on
information technology (IT) strategies to remain competitive in the marketplace.
More and more, the marketplace means an e-business environment. Network
performance directly corresponds to business performance. This increased
reliance on the network creates the need for high availability within the
infrastructure.
New and evolving applications, such as interactive white boarding, video
conferences, and collaborative engineering, have significantly increased the need
for bandwidth capacity. In addition to bandwidth requirements, these applications
create very different traffic patterns from traditional client/server applications.
Many of these new applications combine voice, video, and data traffic and have
driven the convergence of these infrastructures. As this convergence occurs, the
volume of time-sensitive traffic increases. Instantaneous rerouting of traffic must
occur to maintain the integrity of the application.
Reliability and fault tolerance are critical to maintain continuous network
operations.
6.7 HSA management considerations with networking
Networking management is associated with network performance, particularly in
regards to HSA and Continuous Operations support and in a mission-critical
application environment. After the network is set up, monitor it to be sure it runs
at maximum efficiency.
82 High Availability on the AS/400 System: A System Manager’s Guide
The primary concerns of continuity are associated with a server’s
communications pointers to other servers and their respective clients. When
networks are consolidated, a common complication is the duplication of network
addresses for existing devices. Each of these potential problem areas are readily
identified with proper network management tools.
6.7.1 Network support and considerations with a HAV application
Many AS/400 application environments take advantage of several OS/400
communication facilities. The primary concern with these facilities is not so much
involved with day-to-day operation activities but is more likely to be involved with
the role swap (redirection) of the database function from the production system to
a backup system. Moving executing jobs from one physical AS/400 system unit to
another requires that pointers managed for these systems are adjusted in a quick
and efficient manner. Several communications facilities are involved:
• OptiConnect
• TCP/IP
• SNA
Each facility utilizes certain name attributes or address pointer conventions to
indicate another AS/400 system’s presence in a network. Implementing
continuous operations support requires that the name attributes or pointer
conventions be changed to reflect that the current state of business is operating
on another AS/400 system.
Scenario with Tivoli network management in action
This section illustrates a fictitious example of what a network management tool
can do.
It is noon, the peak traffic time for an international travel agency Web site.
Thousands of customers worldwide access the site to book airline, hotel, and car
reservations. Without warning, the Web site crashes, literally shutting down the
agency’s lucrative e-business trade and closing the doors to customers. With
each passing minute, tension mounts because the company stands to lose
millions of dollars in revenue.
Tivoli instantly sifts through enormous amounts of data for the root cause of the
problem. Moments later, it pinpoints the source of the problem: a failing router.
Immediately, the company’s e-business traffic is automatically rerouted through
an auxiliary router. Meanwhile, system administrators recycle the router and
resolve the problem. Downtime is minimized, customers remain satisfied, and a
near-disaster is averted. The agency is back online and back in business.
This example illustrates how a network management tool like Tivoli improves
system availability.
6.8 Bus level interconnection
Bus level interconnetion consists of hardware and software support between two
AS/400 systems at the application level. This path provides a high performance
bandwidth for client systems requiring local database access time. By using this
feature of the AS/400 system, many customers have been able to use multiple
systems to work as a single application image to clients. The SAP R/3
Networking and high availability 83
application, with its three-tier configuration and OptiConnect, is an example of
how bus level interconnection is used for this purpose.
Figure 18 depicts a three-tiered configuration showing the bus level
interconnection arrangement with two bus owners (referred to as a hub). This
arrangement provides redundancy for the shared bus path.
Figure 18. Three-tiered configuration: OptiConnect assignments
In a shared bus redundancy arrangement, it is not necessary for the application
servers to be the bus owners because there is no technical reason why the
database servers can’t assume that role. The only rule you must adhere to with
this arrangement is that either application or database servers must perform this
role as a pair. You can’t have one application server and one database server
assume the bus owner role in the redundancy arrangement. If you choose a
primary application and a database server for this assignment, there may come a
time when both those systems must go through some sort of dedicated process
or a power sequence.
Application
Server
SAP Client
Host: IP@2
SAP Client
Host: IP@2
Backup
Application
Server
Database
Server
Backup
Database
Server
Client LAN/WAN
IP@2
IP@3
IP@2 (inactive)
Bus Owner 1
Sysnam=APPL1
Bus Owner 2
Sysnam=APPL2
84 High Availability on the AS/400 System: A System Manager’s Guide
This operation can not be allowed to occur because any DDM and SQL
procedures through OptiConnect (for example) cease and would, therefore, affect
availability of the backup systems when continuous operations is required for the
application user. When the bus owner goes to a restricted state or power
sequence, all OptiConnect traffic between remote systems stops.
Note: HSL OptiConnect is introduced at V5R1. However, it is not covered in this
Redpaper.
6.8.1 Bus level interconnection and a high availability solution
Besides providing high-speed data throughput, bus level interconnection allows
OMS/400 to transport data to the backup system efficiently and quickly so that
exposure to data loss is very minimal. One shared bus between an application
server and two database server systems can accommodate the data requests
from the application server. This is done on behalf of the clients to the primary
database server while concurrently supporting the data mirroring path between
the primary database server and backup database server. However, better
resiliency in this example would be provided if both database servers each
supported a shared bus to the application server providing a dual bus path (also
referred to as shared bus redundancy).
OMS/400 supports the use of OptiConnect for data replication to the backup
system. When configuring your application database library in OMS/400, the
specification for Opticonnect requires only the System Name from the OS/400
Network Attribute System Name. All pointers to the remote system and the apply
processes are built by the configuration process.
6.8.2 TCP/IP
This protocol is also supported by OMS/400. When OptiConnect cannot be used,
or is not in operation, this path can also serve as a route for data replication.
Primarily, this path is used by SAM/400 for verification of the primary database
server’s operation and signals the redirection of the primary database system’s IP
address to the backup database server system in the event of an unplanned
outage. In the application environment, it is the path that the client uses for
application requests from the application server and the path used between the
application server and database server to access stream files prevalent in this
environment (also called the access network).
Networking and high availability 85
Figure 19. Three-tiered configuration: IP assignments
Figure 19 shows the suggested ethernet LANs for supporting client traffic through
the access network (Client LAN/WAN) path. This occurs while operations,
development, and SAM/400 use the AS/400 LAN for additional traffic for testing
the availability of the production system.
Note: In relationship to Figure 19, the OptiConnect arrangement has been
removed from the diagram to keep it uncluttered. However, you can still assume
that all four AS/400 systems are connected in that manner.
The LANs can be bridged for network redundancy. However, security would have
to be implemented to keep client traffic out of the AS/400 LAN because of direct
accessibility to the database servers. It should be noted that SAM/400 can use all
of these protocols in combination to test the validity of an unplanned outage.
Figure 19 shows several IP address assignments. This is designed to keep the
client interface consistent with one address/host name. In the event of a role
swap with an application server, the client operator does not need to be
concerned with configuration tasks and does not need to use a second icon on
their desktop for access to a backup system.
Application
Server
SAP Client
Host: IP@2
SAP Client
Host: IP@2
Backup
Application
Server
Database
Server
Backup
Database
Server
Client LAN/WAN
AS/400 LAN
IP@2 IP@3
IP@2 (inactive)
IP@4
IP@6 (no name)
IP@5
IP@4 (inactive)
IP@7 IP@8
86 High Availability on the AS/400 System: A System Manager’s Guide
For the application server that must use a backup database server, it also uses
the same IP address as that of the primary database server. The role swap
procedures outlined in SAM/400 manages the ending and starting of different
interfaces. This option facilitates the identification of each system in its new role
throughout the LAN. Note that the respective backup systems have inactive IP
addresses (as reflected in the interface panel of the TCP configuration menu).
These addresses are started during the role swap procedure when the backup
system becomes the production environment.
The additional IP address for the primary database server is not generally
assigned a host name which is the case with other addresses. This ensures that
the address is not being used by the clients through the access network. The
main purpose is for the reversed role the primary database server plays when it
has stopped operating (for planned or unplanned outages) and it must now be
synchronized with the backup database server. Naturally, for continuous
operations, the business moves to the backup database server and the database
located there begins processing all transactions while the primary database
server system is being attended to. After awhile, the primary database server files
become aged and must be refreshed with the current state of business before
returning to operation.
One method is to save the files from the backup system to the production system.
However, this method would impact the user’s availability while they are still using
the backup database server. OMS/400 is designed to reverse the roles of the
primary and backup system to reversed target and reversed source respectively.
That means the backup system can capture and send the database changes back
to the production system so that it can catch up and be current with the business
operation.
The function that the additional IP address plays here is that its allows the system
to connect to the AS/400 LAN (as shown in Figure 19) without having to use its
normal interface (at this time, it is inactive) when TCP services are required. All
this occurs while the business is still using the backup system to run its
applications. Once the systems are equal, the user can then return them to their
original roles by scheduling a planned role swap. Usually, you would select a time
of day when activity is low or when work shifts are changing.
© Copyright IBM Corp. 2001 87
Chapter 7. OS/400: Built-in availability functions
This chapter reviews existing OS/400 functions, specifically those that enhance
system availability, databases, and applications. These functions form the
foundation of the AS/400 system.
Note: This chapter only summarizes these functions. The System Administrator’s
Companion to AS/400 Availability and Recovery, SG24-2161, provides more
details on OS/400 functions designed for availability.
This chapter also outlines clustering and LPAR. Introduced in OS/400 V4R4,
these features provide system redundancy and expand availability and replication
options.
7.1 Basic OS/400 functions
Some availability functions for the AS/400 system were architected into the initial
design (some were carried over from the preceding System/38). Some of these
functions include:
• Auxiliary storage pools (ASPs)
• Journaling
• Commitment control
These functions were delivered when the system main storage and processing
power were small in comparison to the resource needs of the applications that
enabled them. Therefore, many applications were developed without these
functions.
As these applications grew in functionality and user base, the task of enabling the
functions grew quickly. Now, newer functions are available to provide nearly 100%
availability. These new functions are founded on the historic functions and are not
enabled by many applications. Therefore, application developers must revisit their
applications and enable these historic functions to enable the new functions.
ASPs are discussed in Chapter 5, “Auxiliary storage pools (ASPs)” on page 63.
Journaling and commitment control are discussed in this section.
7.1.1 Journaling
Journals define which files and access paths to protect with journal management.
This is referred to as journaling a file or an access path. A journal receiver
contains journal entries that the system adds when events occur that are
journaled, such as changes to database files. This process is shown in Figure 20
on page 88.
88 High Availability on the AS/400 System: A System Manager’s Guide
Figure 20. The journaling process
Journaling is designed to prevent transactions from being lost if your system ends
abnormally or has to be recovered. Journal management can also assist in
recovery after user errors. Journaling provides the ability to roll back from an
error to a stage prior to when the error occurred if both the before and after
images are journaled.
To recover, the restore must be done in the proper order:
1. Restore your backup from tape.
2. Apply journaled changes.
We recommend that you keep a record of which files are journaled.
Use journal management to recover changes to database files that have occurred
since your last complete save.
A thorough discussion of journaling is beyond the scope of this chapter. For more
information about journaling, refer to OS/400 Backup and Recovery, SC41-5304.
7.1.2 Journal receivers with a high availability business partner solution
Business partner high availability solutions incorporate the use of journaling. A
description of journal receivers with OMS/400 and ODS/400 is explained in this
section.
Journal receivers are used by OMS/400 and ODS/400. OMS/400 transmits the
image of database records recorded there for use by the apply jobs on the target
database server. ODS/400, on the other hand, uses the entries recorded in the
OS/400 audit journal (QAUDJRN) to tell it what object operations must be
performed on the target AS/400 system. The issue with journal receivers is that,
FILEA FILEB FILEC
Receiver
#1
Journal
Receiver
#3
Receiver
#2
Journal
CHANGES DELETES
A
D
D
S
OS/400: Built-in availability functions 89
when transactions occur in the applications, and objects are manipulated, the
resulting entries placed in the receivers make them grow in size until they reach
the maximum threshold of 1.9 GB.
Reaching the maximum threshold must be avoided because the business
applications and system functions that use the journaled objects cease operation.
They will not resume operation until the filled receiver has been detached from
the journal and a new receiver is created and attached.
Typically, the AS/400 user can take advantage of the system’s ability to manage
the growth and change of receivers while the applications are running. Or, they
may elect to write their own management software. However, either solution
overlooks one important aspect: synchronization with the reader function that
transmits the journal entry to a backup system (OMS/400) or performs an object
function (ODS/400) on behalf of the backup system. If, for any reason, the
production system cannot communicate the data and object changes to the
backup system, no receiver can be deleted until replication resumes and all
journal entries have been processed by the high availability application.
Therefore, if the AS/400 user elects one of the first two options to manage
receivers, they could inadvertently delete those receivers before their contents
were interrogated by high availability software for replication and synchronization
purposes.
Placing journal receivers in user ASPs minimizes the impact journaling may place
on some application environments, especially if it has never been used for a given
application environment. Since the write I/O changes from asynchronous (with
regards to the program execution) to synchronous (where the program producing
the write activity must actually wait for the record to be written to the journal
receiver) latency is introduced and program execution may increase elapsed time.
This result can be seen in batch applications that produce many significant write
operations to a database being journaled.
Using user ASPs only for the journal receivers allows for quick responses to the
program from the DASD subsystems. The only objects being used in that ASP are
the journal receivers and the most typical operation is write I/O. Therefore, the
arms usually are positioned directly over the cylinders for the next contiguous
space allocation when a journal receiver extent is written to the disk.
Obviously, following this recommendation places more responsibility on the user
for managing receivers and the DASD space they utilize. The associated journal
must remain in the same ASP as the database it is recording. To implement the
user ASP solution, create a new library in the user ASP and, during the next
In such a case, Vision Suite recommends the use of its Journal Manager. This
Vision Suite feature changes journal receivers based on a policy established by
the user. It also coordinates between the reader jobs for replication and the
user’s requirements to free auxiliary storage space and save receivers offline.
Once it has been implemented, the user’s interface for this requirement simply
observes the Work with Disk Status (WRKDSKSTS) and monitors the user
auxiliary storage pool (ASP) utilization threshold.
Note
90 High Availability on the AS/400 System: A System Manager’s Guide
Change Journal (CHGJRN) operation, specify the new receiver to be qualified to
that library.
7.2 Commitment control
Commitment control is an extension of journal management. It allows you to
define and process a group of changes to resources, such as database files or
tables, as a logical unit of work (LUW). Logically, to the user, the commitment
control group appears as a single change. To the programmer, the group appears
as a single transaction.
Since a single transaction may update more than one database file, when the
system is in a network, a single transaction may update files on more than one
system. Commitment control helps ensure that all changes within the transaction
are completed for all affected files. If processing is interrupted before the
transaction is completed, all changes within the transaction are removed.
Without commitment control, recovering data for a complex program requires
detailed application and program knowledge. Interrupted programs cannot easily
be re-started. To restore the data up to the last completed transaction, typically a
user program or utility, such as a Data File Utility (DFU), is required to reverse
incomplete database updates. This is a manual effort, it can be tedious, and it is
prone to user error.
Commitment control ensures that either the entire group of individual changes
occur on all participating systems, or that none of the changes occur. It can assist
you with keeping your database files synchronized.
7.2.1 Save-while-active with commitment control
Using the save-while-active function while commitment control processing is
active requires additional consideration. When an object is updated under
commitment control during the checkpoint processing phase of a
save-while-active request, the system ensures that the object is saved to the
media at a commitment boundary. All objects that have reached a checkpoint
together are saved to the media at the same common commitment boundary.
It is important to make sure that all performance considerations have been
correctly implemented in this situation. Otherwise, the system may never be able
to reach a commitment boundary. It may not be able to obtain a checkpoint image
of the objects to be saved. Procedures need to be specified to ensure that all of
the objects reach a checkpoint together and all of the objects are saved in a
consistent state in relationship to each other. If the checkpoint versions of the
objects are not at an application boundary, user-written recovery procedures may
still be necessary to bring the objects to an application boundary.
Refer to OS/400 Backup and Recovery, SC41-5304 for details on coding for
commitment control and save-while-active.
7.3 System Managed Access Path Protection (SMAPP)
An access path describes the order in which records in a database files are
processed. A file can have multiple access paths if different programs need to see
the records in different sequences. If your system ends abnormally when access
OS/400: Built-in availability functions 91
paths are in use, the system may have to rebuild the access paths before you can
use the files again. This is a time-consuming process. To perform an IPL on a
large and busy AS/400 system that has ended can take many hours.
You can use journal management to record changes to access paths. This greatly
reduces the amount of time it takes the system to perform an IPL after it ends
abnormally.
Access path protection provides the following benefits:
• Avoids rebuilding access paths after most abnormal system ends
• Manages the required environment and makes adjustments as the system
changes if SMAPP is active
• Successful even if main storage cannot be copied to storage Unit 1 of the
system ASP during an abnormal system end
• Generally faster and more dependable than forcing access paths to auxiliary
storage for the files (with the FRCACCPTH parameter)
The disadvantages of access path protection include:
• Increases auxiliary storage requirements
• May have an impact on performance because of an increase in the activity of
the disks and processing unit
• Requires file and application knowledge for recovery. There is a small
additional processor overhead if *RMVINTENT is specified for the
RCVSIZOPT parameter for user-created journals. However, the increase in
storage requirements for access path journaling is reduced by using
*RMVINTENT.
• Normally requires a significant increase in the storage requirements for
journaling files. The increase with SMAPP is less than when access paths are
explicitly journaled.
Two methods of access-path protection are available:
• System management access-path protection (SMAPP)
• Explicit journaling of access paths
An access path (view) describes the order in which records in a database file are
processed. A file can have multiple access paths if different programs need to see
the records in different sequences. If your system ends abnormally when access
paths are in use, the system may have to rebuild the access paths before you can
use the files again. This can be a time-consuming process, since an IPL on a
large busy server that had ended abnormally may take many hours. Two methods
of access-path protection are available:
• OS/400 System Managed Access Path Protection (SMAPP)
• Explicit journaling of access paths
7.4 Journal management
You can use journal management to recover the changes to database files or
other objects that have occurred since your last complete save. Use a journal to
define what files and access paths you want to protect with journal management.
This is often referred to as journaling a file or an access path. A journal receiver
92 High Availability on the AS/400 System: A System Manager’s Guide
contains the entries (called journal entries) that the system adds when events
occur that are journaled, such as changes to database files, changes to other
journaled objects, or security-relevant events.
Use the remote journal function to set up journals and journal receivers on a
remote AS/400 system. These journals and journal receivers are associated with
journals and journal receivers on the source system. The remote journal function
allows you to replicate journal entries from the source system to the remote
system.
The main purpose of journal management is to assist in recovery. You can also
use the information that is stored in journal receivers for other purposes, such as:
• An audit trail of activity that occurs for database files or other objects on the
system
• Assistance in testing application programs. You can use journal entries to see
the changes that were made by a particular program.
Figure 21 shows the steps involved for journaling.
Figure 21. The Journaling Process
7.4.1 Journal management: Benefits
Benefits of journal management can include:
• A reduction in the frequency and amount of data saved
• Improved ability and speed of recovery from a known point to the failure point
• Provides file synchronization if the system ends abnormally
7.4.2 Journal management: Costs and limitations
Disadvantages of journal management include:
• An increase in auxiliary storage requirements
• Can have an impact on performance because of an increase in the activity of
disks and the processing unit
MEMORY
1 6 2 4
Journal
Receiver Synch Point
6
3 5
ASP1 ASP2
Before image
After image
OS/400: Built-in availability functions 93
• Requires file and application knowledge for recovery
Refer to the OS/400 Backup and Recovery, SC41-5304 for further information.
7.5 Logical Partition (LPAR) support
In an n-way symmetric multi-processing iSeries or AS/400e server, logical
partitions allow you to run multiple independent OS/400 instances or partitions,
each with their own processors, memory, and disks.
Note: With OS/400 V5R1, a single processor can be sliced for sharing across
partitions.
You can run a cluster environment on a single system image. With logical
partitioning, you can address multiple system requirements in a single machine to
achieve server consolidation, business unit consolidation, and mixed production
and test environments.
Figure 22 shows an LPAR configuration with resources shared across partitions.
Figure 22. Example LPAR configuration
Each logical partition represents a division of resources in your AS/400e system.
Each partition is logical because the division of resources is virtual rather than
physical. The primary resources in your system are its processors, memory (main
storage), I/O buses, and IOPs.
An LPAR solution does not offer a true failover capability for all partitions. If the
primary partition fails, all other partitions also fail. If there are multiple secondary
partitions backing each other up, they have the capability to failover between
partitions. These secondary partitions are nodes and are a cluster solution.
However, they are not a separate server implementation. LPAR cannot provide
the same level of availability as two or more node cluster solutions.
830
4-way
2 GB
memory
A
2-way
1 GB
B
2-way
1 GB
94 High Availability on the AS/400 System: A System Manager’s Guide
See 4.12, “LPAR hardware perspective” on page 58, for discussion of LPAR from
a hardware perspective.
7.6 Cluster support and OS/400
The ultimate availability solution consists of clustered systems. OS/400 V4R4
introduced clustering support. This support provides a common architected
interface for application developers, iSeries software providers, and high
availability business partners to use in-building high availability solutions for the
iSeries and AS/400 server. The architecture is built around a framework and is
the foundation for building continuous availability solutions for both the iSeries
and AS/400 servers.
Clustering provides:
• Tools to create and manage clusters, the ability to detect a failure within a
cluster, and switchover and failover mechanisms to move work between
cluster nodes for planned or unplanned outages
• A common method for setting up object replication for nodes within a cluster
(this includes the data and program objects necessary to run applications that
are cluster-enabled)
• Mechanisms to automatically switch applications and users from a primary to
a backup node within a cluster for planned or unplanned outages
Clustering involves a set of system APIs,
system services, and exit programs as
shown in Figure 23. Data replication
services and the cluster management
interface are provided by IBM HABPs.
How clustering works, and planning for
clusters, is described in AS/400 Clusters,
A Guide to Achieving Higher Availability,
SG24-5194.
Cluster
Management
Provided
by HABPs
Data
Resiliency
Replication
technology
provided by
HABPs
Cluster Resource Services
Base OS/400 cluster functions from IBM
APIs
Application
Resiliency
High
availability
cluster
enabled
applications
Figure 23. Cluster overview
© Copyright IBM Corp. 2001 95
Chapter 8. Performance
Performance is an availability issue from several view points. First and foremost,
to the end user, poor performance can be significantly more frustrating than a
system outage. Poor performance can even result in lost sales. An example
would be a customer calling to check the availability or price of an item. If the
response of the service representative (or a Web-enabled application) is too long,
the customer looks elsewhere.
Poor performance can be caused by any number of factors, which can be any
computing component between the end-user incoming request and the delivery of
the response. The timing is affected by the performance of the communication
links, routers, hubs, disk arms (service time), memory, and the CPU. Service
agreements can hold both parties accountable, with the parties being the service
provider (you the business), and the receiver or requestor of the service (the
customer).
Do not delay the planning for performance for your high availability environment
until after implementing the system and applications. Plan for it prior to
installation. Set your expectations and guidelines accordingly.
It is easy to suggest that, by implementing a backup machine, the spare capacity
on the backup can give extra cycles to a sluggish application. This is very rarely
the case. Investigating the proposed performance of the new environment should
reap dividends during the implementation phase.
This section discusses the implication of performance on the various levels of
availability.
Note: Performance ratings of save and restore hardware and software options
can be found in the AS/400 Performance Capabilities Reference. This can be
accessed online at: http://www.ibm.com/eserver/iseries/library
8.1 Foundations for good performance
This section briefly describes the fundamental elements of good performance on
the AS/400e servers.
8.1.1 Symmetric multiprocessing (SMP)
In the AS/400e world, SMP has multiple meanings. First and foremost, it is a
hardware deployment capability. iSeries processors and some AS/400e
processors can be purchased in 2-way, 4-way, 8-way, 12-way, 18-way, and
24-way configurations. In the industry, all the n-way processor configurations are
referred to as SMP processor systems.
Due to the architecture of the AS/400 server and OS/400, applications and
utilities are able to take advantage of the SMP models without overt programming
efforts. However, it is possible to obtain even higher levels of throughput by
redesigning batch processes to take advantage of multiple processors.
Another use of the term SMP in the AS/400e world refers to a feature of the
operating system called DB2 Symmetric Multiprocessing for AS/400. This feature
enables a dynamic build of access paths or views for queries (including
96 High Availability on the AS/400 System: A System Manager’s Guide
OPNQRYF and the query manager) utilizing parallel I/O and parallel processing
across all available processors. Plan carefully for the use of this feature because
it can significantly increase overall CPU utilization in addition to increased
physical I/O operations.
To learn more about the DB2 Symmetric Multiprocessing for AS/400 feature, refer
to the iSeries Handbook, GA19-5486 and the Performance Capabilities
Reference, which can be accessed online at:
http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R5PDF/AS4PPCP3.PDF
8.1.2 Interactive jobs
Just as you would not implement a major application change without analysis of
the potential performance impact, you need to determine the potential impact of
implementing high availability on your interactive workload. Ask the following
questions:
• What effect will the proposed implementation have on interactive
performance?
• If journaling is to be activated, what will its impact be?
• Have you decided to rewrite your applications to ensure data integrity by
utilizing commitment control? What will this performance impact be?
The answers to these questions must be analyzed and fed back to the business
plan and incorporated into your service level agreements.
8.1.3 Batch jobs
Batch jobs are another key area for high availability. This is one place that backup
machines may have a positive effect on the performance of the primary system.
You may be able to redirect work from your primary system to the backup system.
This is most feasible for read only work. Other types of batch jobs could be very
difficult to alter to take advantage of a second system and a major re-write may
be necessary.
If you choose to utilize your backup system for read only batch work, make sure
that you understand the impact of these jobs on the high availability business
partner apply processes. If the work you run on the backup system interferes in
any way with these apply processes, you may reduce your ability to switchover or
failover in a timely manner.
You need to consider the impact of activating journaling on your batch run times
and explore the possibility of incorporating commitment control to improve run
time in a journaled environment. This is discussed in more detail in 8.2.3,
“Application considerations and techniques of journaling” on page 99.
8.1.4 Database
Consider the types of database networks utilized by your application when
understanding performance. Do you have multiple database networks, a single
database network, multiple database networks across multiple servers, or a
single database network across multiple servers?
Performance 97
As stated, the major performance impact for a database is the start of journaling.
Each database operation (except read operations) involves journal management.
This adds a physical I/O and code path to each operation.
8.2 Journaling: Adaptive bundling
Journaling’s guarantee of recover ability is implemented with extra I/O and CPU
cycles. Since V4R2 of OS/400, the technique of adaptive bundling has been used
to reduce the impact of these extra I/O operations.
This means that journal writes are often grouped together for multiple jobs, in
addition to commit cycles. Refer to Figure 24 for a simple illustration.
Figure 24. Adaptive bundling
Unless you have taken specific actions, a single batch job can minimally take
advantage of adaptive bundling. A high penalty is paid in extra I/O with every
record update performed.
It is normal to see an increase in both I/O and CPU utilization after turning on
journaling. Even on a well-tuned system, the CPU utilization increase can be as
high as 30%. This increase in utilization increases response time. An even higher
degradation is common for single threaded batch jobs that do not run
commitment control.
Journaling increases the number of asynchronous writes. The effect of these
asynchronous writes is shown on the Transition Report of Performance Tools.
Modules QDBPUT, QDBGETKY, and QDBGETSQ show evidence of this
asynchronous I/O request.
Joe1
Job 1
Job 2
Average Bundle Size
Comm Line
Memory
98 High Availability on the AS/400 System: A System Manager’s Guide
To reduce the impact of journaling:
• Group inserts under a commit cycle
• Group inserts
• Split a batch job into several jobs and run them in parallel
8.2.1 Setting up the optimal hardware environment for journaling
Building a sound hardware environment for your journaled environment can
minimize the impact of journaling. Start by creating a user auxiliary storage pool
(ASP) that utilizes mirrored protection.
Depending on the amount of storage required for your journal receivers, and the
release of OS/400 you are running, you can allocate between 6 and 200 total
arms to this user ASP. These disk arms should have dedicated IOPs with at least
.5 MB of write cache per arm. Regardless, these arms should be the fastest
available on your system.
Note: The total stated number of arms are not “operational” numbers after turning
on mirroring.
If you are running a release of OS/400 prior to V4R5, the maximum number of
disk arms the system can efficiently use for parallel I/O operations for journaling
is 30. In V4R5, if you utilize the *MAXOPT parameter on the receiver size
(RCVSIZOPT) keyword, the number of used disk arms increases to 200.
8.2.2 Setting up your journals and journal receivers
Refer to Section 6.2 “Planning and Setting Up Journaling” in the Backup and
Recovery Guide, SC41-5304, for detailed information. Also keep the following
points in mind:
• The journal and journal receiver objects should not be in the same library as
the files they are to journal.
• The journal object (*JRN) should not reside in the user ASP of the journal
receiver (*JRNRCV) objects.
• Isolate journal receiver writes from system managed access path protection
(SMAPP) writes by specifying RCVSIZOPT(*RMVINTENT) on the CRTJRN
and CHGJRN commands. In addition to isolating the SMAPP I/O operations to
arms dedicated for that activity, your journal receivers will not fill as quickly.
The system uses two-thirds of allocated ASP arms for JRNRCV objects and
the remaining one-third for SMAPP entries.
• Suppress open and close journal entries by utilizing OMTJRNE(*OPNCLO) on
the STRJRNPF command.
• Use system managed receivers by specifying MNGRCV(*SYSTEM) on the
CRTJRN and CHGJRN commands to enable better system performance
during the change of journal receivers. You can ensure that your business
partner package maintains control over the actual changing of journal
receivers by specifying a threshold on your journal receivers that is larger than
the size specified in the partner package.
The MNGRCV(*SYSTEM) requires the parameter THRESHOLD be specified
on the CRTJRNRCV command.
Performance 99
8.2.2.1 Determining the number of journals and receivers
Generally speaking, you always have multiple journal and journal receivers.
Some strategies for determining the number of journals and journal receivers you
have include:
• By application: To simplify recovery, files that are used together in the same
application should be assigned to the same journal. In particular, all the
physical files underlying a logical file should be assigned to the same journal.
Starting in V3R1, all files opened under the same commitment definition within
a job do not need to be journaled to the same journal. If your major
applications have completely separate files and backup schedules, separate
journals for the applications may simplify operating procedures and recovery.
• By security: If the security of certain files requires that you exclude their
backup and recovery procedures from the procedures for other files, assign
them to a separate journal, if possible.
• By function: If you journal different files for different reasons, such as
recovery, auditing, or transferring transactions to another system, you may
want to separate these functions into separate journals. Remember, a physical
file can be assigned to only one journal.
If you have user ASPs with libraries (known as a library user ASP), all files
assigned to a journal must be in the same user ASP as the journal. The journal
receiver may be in a different ASP. If you place a journal in a user ASP without
libraries (non-library user ASP), files being journaled must be in the system ASP.
The journal receiver may be in either the system ASP or a non-library user ASP
with the journal. See the section titled “Should Your Journal Receivers Be in a
User ASP?” in the Backup and Recovery Guide, SC41-5304, for more information
about the types of ASPs and restrictions.
Remember to consult the Backup and Recovery Guide, SC41-5304 for restore or
recovery considerations when setting up your environment. Even though you set
up this environment to minimize the need to ever fully restore your system, you
may have to partially restore within your own environment or fully restore if you
take advantage of the Rochester Customer Benchmark Center or a
disaster/recovery center.
8.2.3 Application considerations and techniques of journaling
Database options that have an impact on journaling and system performance are:
• The force-write ratio (FRCRATIO) parameter for physical files that are
journaled. This allows the system to manage when to write records for the
physical file to disk because, in effect, the journal receiver has a force-write
ratio of one.
• Record blocking when a program processes a journaled file sequentially
(SEQONLY(*YES)). When you add or insert records to the file, the records are
not written to the journal receiver until the block is filled. You can specify
record blocking with the Override with Database File (OVRDBF) command or
in some high-level language programs. This is a standard and good
performance practice that significantly helps the performance of journaling
too.
100 High Availability on the AS/400 System: A System Manager’s Guide
• Use OMTJRNE(*OPNCLO)) to reduce the number of journal entries. If you
choose to omit open journal entries and close journal entries, note the
following considerations:
– You cannot use the journal to audit who has accessed the file for read only
purposes.
– You cannot apply or remove journal changes to open boundaries and close
boundaries using the TOJOBO and TOJOBC parameters.
– Another way to reduce the number of journal entries for the file is to use
shared open data paths. This is generally a good performance
recommendation regardless of journaling activity.
• Utilize the Batch Journal Caching PRPQ. This offering:
– Forces journal entries to be cached in memory for most efficient disk writes
– Is designed to reduce journaling's impact on batch jobs
– Is selectively enabled
Additional information about the Batch Journal Caching PRPQ can be found in
Appendix C, “Batch Journal Caching for AS/400 boosts performance” on page
153.
8.3 Estimating the impact of journaling
To understand the impact of journaling on the capacity of a system, consider the
processes involved. Additional overhead is involved for disk and CPU activity and
additional storage is required in preparation for potential recovery.
8.3.1 Additional disk activity
Consider that each row updated, added, or deleted has either one or two journal
entries. While this is an asynchronous I/O operation, your disk arm response time
can increase. This causes degradation to your production workload. Under
certain circumstances, these asynchronous I/O operations become synchronous
I/O operations and cause your application to wait for them to complete before
they can continue.
8.3.2 Additional CPU
Each update, add, or delete operation utilizes additional CPU seconds to
complete. The ratio of CPU per logical I/O is a key factor in determining the
additional CPU required for journaling.
8.3.3 Size of your journal auxiliary storage pool (ASP)
Depending on how accurate you want your estimate of space requirements to be,
follow one of the two methodologies explained in this section to estimate your
space requirements.
8.3.3.1 Using weighted average record length
Perform the following steps to use a weighted average record length:
1. Determine the average number of entries per time period (number of days or
hours) worth of receiver entries you want or need available.
Performance 101
To take advantage of the journal’s ability to protect your data and to provide an
audit trail, you may want to keep more than a few hours worth of receiver
entries for transmission to a secondary system. Once the data is written to the
disk, the only expense involved beyond the disk space consumed is the cycles
required to retrieve the entries for further analysis.
2. Determine the weighted average record length.
Add 155 to this weighted average record length.
3. Multiply the results from step 2 by the results from step 1 and divide by 1,024
to determine the KB. Or, divide by 1,048,576 to determine the MB required.
8.3.3.2 Using actual changes logged by file management
The file description contains information useful for calculating storage usage. To
utilize this information:
1. Execute a CL program to capture FD information.
2. Execute an RPG program to translate the date to a table for further
calculations.
3. Rerun CL in as you did in step 1.
4. Execute an RPG program to add a second set of FD information to a table.
5. Calculate requirements based on information in the file.
8.4 Switchover and failover
Highly available systems involve clustering. When a production system is
switched over to the backup system, either for a planned or an unplanned outage,
the time required to make this switchover is critical.
To reduce the time involved in this switchover process, consider the networks and
performance as explained in the following section.
Networks and performance
The performance of a communications network provides acceptable (or
non-acceptable) response time for the end users. Response time provides the
perception for the end user of the reliability and availability of the system. In
general, to improve performance:
• Avoid multiple layers of communications.
• Avoid communication servers (such as Microsoft SNA server, IBM
Communication Server, or NetWare SNA server).
• Use Client Access/400 or IBM eNetwork Personal Communications for AS/400
where possible.
• Use a native protocol instead of ANYNET.
The Best/1 licensed program, a component of 5769-PT1, can capture information
on a communication line and predict utilization and response times.
102 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 103
Part 3. AS/400 high availability solutions
Combining the features of OS/400 system and network hardware with AS/400e
high availability software produced by IBM business partners is an important
method for improving a single systems availability. Part III discusses these
components and it also explores the considerations for writing applications to
support a highly available environment.
104 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 105
Chapter 9. High availability solutions from IBM
The foundation of all high availability functions is OS/400. The AS/400
development and manufacturing teams continue to improve the AS/400 system
for feature, function, and reliability options with each release of OS/400. In
particular, the OS/400 remote journal feature enhances high availability solutions
by enabling functions below the machine interface (MI) level.
Note: Prior to OS/400 V4R2, remote journal functions were coded into application
programs. APIs and commands are available in V4R2 and V4R3 respectively.
Cluster solutions connect multiple AS/400 systems together using various
interconnect fabrics, including high-speed optical fiber. Clustered AS/400
systems offer a solution that can deliver up to 99.99% system availability.
For planned or unplanned outages, clustering and system mirroring offer the most
effective solution. IBM business partners that provide high systems availability
tools complement IBM availability tools with replication, clustering, and system
mirroring solutions.
The IBM (application) contribution to AS/400 High Availability Solutions includes
the IBM DataPropagator Relational Capture and Apply for AS/400 product. From
this point on, this product is referred to as DataPropagator/400. This chapter
describes the IBM package and its benefits as a minimal High Availability
Solution.
9.1 IBM DataPropogator/400
The IBM solution that fulfills some of the requirements of an HSA solution is
DataPropagator/400.
Note: The DataPropagator/400 product was not designed as a high availability
solution. In some cases, it can cover the needs for data availability, as discussed
in this chapter.
DataPropagator/400 is a state-of-the-art data replication tool. Data replication is
necessary when:
• Supplying consistent real time reference information across an enterprise
• Bringing real time information closer to the business units that require access
to insulate users from failures elsewhere on the network
• Reducing network traffic or the reliance on a central system
• On-demand access disrupts production or response
• Migrating systems and designing a transition plan to move the data while
keeping the systems in sync
• Deploying a data warehouse with an automated movement of data
• Current disaster plan strategies do not adequately account for site-failure
recovery
DataPropagator/400 is not a total High Availability Solution because it only
replicates databases. It does not replicate all of the objects that must be mirrored
for a true High Availability Solution in a dynamic environment.
106 High Availability on the AS/400 System: A System Manager’s Guide
However, consider DataPropagator/400 for availability functions in a stable
environment where the following criteria can be met:
• Only the database changes during normal production on the AS/400 system.
• Such objects as user profiles, authorities, and other non-database objects are
saved regularly on the source system and restored on the target system when
changed.
In other words, in a stable environment, where only the database changes,
replicating the database to a backup system and transferring users manually to
this system may be a sufficient availability and recovery plan (Figure 25).
Figure 25. Usage of DataPropagator/400
9.1.1 DataPropagator/400 description
IBM DataPropagator/400 automatically copies data within and between IBM DB2
platforms to make data available on the system when it is needed. The IBM
DataJoiner product can be used in addition to the DataPropagator/400 product to
provide replication to several non-IBM databases. Immediate access to current
and consistent data reduces the time required for analysis and decision making.
DataPropagator/400 allows the user to update copied data, maintain historical
change information, and control copy impact on system resources. Copying may
involve transferring the entire contents of a user table (a full refresh) or only the
changes made since the last copy (an update). The user can also copy a subset
of a table by selecting the columns they want to copy.
Making copies of database data (snapshots) solves the problem of remote data
access and availability. Copied data requires varying levels of synchronization
with production data, depending on how the data is used. Copying data may even
be desired within the same database. If excessive contention occurs for data
access in the master database, copying the data offloads some of the burden
from the master database.
Why replication?
Reengineer business processes
Improve decision making
Speed application deployment
Increase online throughput
Improve system availability
Support audit requirements
Support data warehousing
Support mobility
AS/400
OS/2
Windows NT
AIX
HP-UX
Solaris System
DB2
Oracle
Sybase
Informix
Microsoft SQL server
Ordering/billing
IMS
DB2
DB2
Manufacturing
Mobile
MVS
VM/VSE
High availability solutions from IBM 107
By copying data, users can get information without impacting their production
applications. It also removes any dependency on the performance of remote data
access and the availability of communication links.
DataPropagator/400 highlights include:
• An automatic copy of databases
• Full support for SQL (enabling summaries, derived data, and subsetted
copies)
• During a system or network outage, the product restarts automatically from
the point where it stopped. If this is not possible, a complete refresh of the
copies can be performed if allowed by the administrators. Also, for example, if
one of the components fails, the product can determine that there is a break in
sequence of the data being copied. In this case, DataPropagator/400 restarts
the copy from scratch.
• Open architecture to enable new applications
• DataPropagator/400 commands that support AS/400 system definitions
• Full use of remote journal support in V4R2
9.1.2 DataPropagator/400 configuration
In the database network, the user needs to assign one or more roles to their
systems when configuring the DataPropagator/400 environment. These roles
include:
• Control server: This system contains all of the information on the registered
tables, the snapshot definitions (the kind of data you want to copy and how to
copy it), the ownership of the copies, and the captures in reference to
registrars and subscribers.
• Data server: This contains the source data tables.
• Copy server: This is the target system.
Depending on the structure of the company, the platforms involved, and customer
preferences, a system in the network can play one or more of these three roles.
DataPropagator/400, for example, works powerfully on a single AS/400 system,
which, at the same time, serves as the Control, Copy, and Data Server.
9.1.3 Data replication process
With DataPropagator/400, there are two steps to the data replication process:
• The Capture process: This is for reading the data.
• The Apply process: This is for applying updated data
Figure 26 and Figure 27 on page 108 illustrate these processes.
108 High Availability on the AS/400 System: A System Manager’s Guide
Figure 26. The DataPropagator/400 Capture process
Figure 27. The DataPropagator/400 Apply process
Features included in the Capture and Apply processes include:
• Support for the remote journal function to offload the source CPU
• Automated deletion of journal receivers
• Replication over a native TCP/IP-based network
• Multi-vendor replication with DataJoiner (replication to and from Oracle,
Sybase, Informix, and Microsoft SQL Server databases)
• Integration with the Lotus Notes databases
9.1.4 OptiConnect and DataPropagator/400
DataPropagator/400 is based on a distributed relational database architecture
(DRDA) and is independent of any communications protocol. Therefore, it uses
OptiConnect and any other media without additional configuration.
Administration
Target
BASE
Control
COPY
COPY
COPY
APPLY
Unit of Work
Change Data
Control
CAPTURE
Journal
Base tables
Column selection
After image or before and
after image
Operational System
Administration
BASE
Unit of Work
Change Data
Control
CAPTURE
Journal
Operational System Control Target
PL/User Copy
HISTORY
STAGING
APPLY
AGGREGATE
Base and Copy tables
Internal and Repetition
Column and Row selection
Computed Columns
Aggregations
Append or Replace
High availability solutions from IBM 109
9.1.5 Remote journals and DataPropagator/400
DataPropagator/400 takes advantage of an operating system’s remote journal
function. With remote journals, the capture process is run at the remote journal
location to offload the capture process overhead from the production system.
The Apply process does not need to connect to the production system for
differential refresh because the DataPropagator/400 staging tables reside locally
rather than on the production system. In addition, because the
DataPropagator/400 product is installed only on the system that is journaled
remotely, the production system no longer requires a copy of
DataPropagator/400.
9.1.6 DataPropagator/400 implementation
DataPropagator/400 is most beneficial for replicating data to update remote
databases. One real-life example of this is a customer in Denmark who had a
central AS/400 system and stored all production data, pricing information, and a
customer database on it. From this central machine, data was distributed to sales
offices in Austria, Germany, Norway, and Holland (each of which operated either
small AS/400 systems or OS/2 PCs). Each sales office received a subset of the
data that was relevant to their particular office. See 3.1, “A high availability
customer: Scenario 1” on page 25, for a description of this customer scenario.
9.1.7 More information about DataPropagator/400
For more information about IBM DataPropagator/400 solutions, refer to
DataPropagator Relational Guide, SC26-3399, and DataPropagator Relational
Capture and Apply/400, SC41-5346. Also, visit the IBM internet Web site at:
http://www.software.ibm.com/data/dbtools/datarepl.html
110 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 111
Chapter 10. High availability business partner solutions
High availability middleware is the name given to the group of applications that
provide replication and management between AS/400e systems and cluster
management middleware. IBM business partners that provide high system
availability tools continue to complement IBM availability offerings of clustering
and system mirroring solutions. Combining clusters of AS/400 systems with
software from AS/400 high-availability business partners improves the availability
of a single AS/400 system by replicating business data to one or more AS/400
systems. This combination can provide a disaster recovery solution.
This chapter explores the applications provided by IBM High Availability Business
Partners (HABPs), DataMirror, Lakeview Technology, and Vision Solutions. This
chapter also discusses the options these companies provide to support a highly
or continuously available solution.
Note: For customers requiring better than 99.9% system availability, AS/400
clusters with high-availability solutions from an IBM Business Partner are
recommended.
10.1 DataMirror Corporation
DataMirror Corporation is an IBM business partner with products that address a
number of issues, such as data warehousing, data and workload distribution, and
high availability. DataMirror products run on IBM and non-IBM platforms.
The DataMirror High Availability Suite uses high performance replication to
ensure reliable and secure delivery of data to backup sites. In the event of
planned or unplanned outages, the suite ensures data integrity and continuous
business operations. To avoid transmission of redundant data, only changes to
the data are sent to the backup system. This allows resources to be more
available for production work. After an outage is resolved, systems can be
resynchronized while they are active.
The DataMirror High Availability Suite contains three components:
• DataMirror High Availability (HA) Data
• ObjectMirror
• SwitchOver System
Figure 28 on page 112 illustrates the components of the DataMirror High
Availability Suite. The corresponding DataMirror HA Suite Source Menu is shown
in Figure 29 on page 112.
Some of the software vendors mentioned in this chapter may have products
with functions that are not directly related to the high availability issues on the
AS/400 system. To learn more about these products, visit these vendors on the
World Wide Web. You can locate their URL address at the end of the section
that describes their solution.
Note
112 High Availability on the AS/400 System: A System Manager’s Guide
Figure 28. DataMirror High Availability Suite
Figure 29. DataMirror HA Suite Source Menu
10.1.1 DataMirror HA Data
DataMirror HA Data mirrors data between AS/400 production systems and
failover machines for backup, recovery, high systems availability, and clustering.
Object
Changes
Database files
and or
AS/400 objects
User Application
Role Swap
Database files
and or
AS/400 objects
Role Swap
Meta Data
Object Capture
User Application
Filtering
Communications
Manager
Object Capture
Data Transformation
Communications
Manager
Transformation Server
Object Mirror
SwitchOver System
Source Target
High availability business partner solutions 113
A user can replicate entire databases or individual files on a predetermined
schedule in real time or on a net change basis. They can refresh the backup
machine nightly or weekly as required. They can also use DataMirror HA Data to
replicate changes to databases in real time so that up-to-the-minute data is
available during a scheduled downtime or disaster.
DataMirror HA Data software is a no-programming-required solution. Users
simply install the software, select which data to replicate to the backup system,
determine a data replication method (scheduled refresh or real time), and begin
replication. At the end of a system failure, fault tolerant resynchronization can
occur without taking systems offline.
DataMirror HA Data supports various high availability options, including workload
balancing, 7 x 24 hour operations availability, and critical data backup. Combined
with Data Mirror ObjectMirror software and SwitchOver System, a full spectrum of
high availability options is possible.
10.1.2 ObjectMirror
ObjectMirror enables critical application and full system redundancy to ensure
access to both critical data and the applications that generate and provide data
use.
ObjectMirror supports real time object mirroring from a source AS/400 system to
one or more target systems. It provides continuous mirroring as well as an
on-demand full refresh of AS/400 objects that are grouped by choice of
replication frequency and priority.
ObjectMirror features include:
• Grouping by choice to mirror like-type objects based on frequency or priority
• Continuous real time mirroring of AS/400 objects
• Intelligent replication for guaranteed delivery to backup systems even during a
system or communication failure
• Object refresh on a full-refresh basis as needed
• Fast and easy setup, including an automatic registration of objects
• Ability to send an object or group of objects immediately without going through
product setup routines
10.1.3 SwitchOver System
The SwitchOver System operates on both the primary and backup AS/400
systems to monitor communications or system failures. During a failure, the
SwitchOver System initiates a logical role switch of the primary and backup
AS/400 systems either immediately or on a delayed basis.
A Decision Control Matrix in the SwitchOver System allows multiple line
monitoring, detailed message logging, automated notification, and user-exit
processing at various points during the switching process. An A/B switch (shown
in Figure 30 on page 114) allows the user to automatically switch users and
hardware peripherals, such as twinax terminals, printers, and remote controllers.
114 High Availability on the AS/400 System: A System Manager’s Guide
Figure 30. DataMirror SwitchOver system
10.1.4 OptiConnect and DataMirror
The DataMirror High Availability Suite supports SNA running over OptiConnect
between multiple AS/400 systems. After OptiConnect is installed on both source
and target AS/400 systems, the user needs to create controllers and device
descriptions.
After controllers and devices are varied on, the user simply specifies the device
name and remote location used in the DataMirror HA Data or Object Mirror target
definition. Files or objects that are specified can then be defined, assigned to the
target system, and replicated.
10.1.5 Remote journals and DataMirror
The DataMirror High Availability (HA) Suite is capable of using the IBM remote
journal function in OS/400. The architecture of the DataMirror HA Suite allows the
location of the journal receivers to be independent from where the production
(source) or failover (target) databases reside. Therefore, journal receivers can be
located on the same AS/400 system as the failover database. This allows the use
of DataMirror intra-system replication to support remote journals.
Customers can invoke remote journal support in new implementations.
Additionally, the existing setup can be modified if remote journal support was not
originally planned.
10.1.6 More information about DataMirror
To learn more about DataMirror products, visit DataMirror on the Internet at:
http://www.datamirror.com
Remote Systems
Mainframe ???
???????????
Async, BSC, SDLC,
X.25, ISDN, Frame Relay
using V24, V35, X21
X25, T1/T2
5394
5494
Twinax attached
terminals, printers
5250 PC cards
LCW
....
Twinax attached
terminals, printers
5250 PC cards
SWITCH
A B
SwitchOver System
1234 1234
DATA DATA
OS/400 OS/400
Token Ring
Ethernet FDDI
5394
PC
Routers or
Bridges
Remote LAN PC
High availability business partner solutions 115
10.2 Lakeview Technology solutions
Lakeview Technology, an IBM business partner, offers a number of products to
use in an AS/400 high availability environment. Their high availability suite
contains five components:
• MIMIX/400
• MIMIX/Object
• MIMIX/Switch
• MIMIX/Monitor
• MIMIX/Promoter
The following sections highlight each of these components.
10.2.1 MIMIX/400
MIMIX/400 is the lead module in the Lakeview Technology MIMIX high availability
management software suite for the IBM AS/400 system. It creates and maintains
one or more exact copies of a DB2/400 database by replicating application
transactions as they occur. The AS/400 system pushes the transaction data to
one or more companion AS/400 systems. By doing this, a viable system with
up-to-date information is always available when planned maintenance or
unplanned disasters bring down the primary system. MIMIX/400 also supports
intra-system database replication.
Figure 31 shows the basic principles of the MIMIX/400.
Figure 31. The basics principles of Mimix/400
The key functions of MIMIX/400 are:
• Send: This function scrapes the source system journal and sends the data to
one or more target systems. This function offers the following characteristics:
– Is written in ILE/C for high performance
– Uses CPI-C to provide a low-level generic interface that keeps CPU
overhead to a minimum
Source AS/400 system Target AS/400 system
CPI-C
Com
munications
CPI-C
Com
munications
Applications
Journaling
is the key
A
Data
B
Data
Journal
receiver
116 High Availability on the AS/400 System: A System Manager’s Guide
– Supports filtering to eliminate files from MIMIX copies and to optimize
communication throughput, auxiliary storage usage, and performance on
the target system
– Generates performance stamps, which continue throughout the replication
cycle, for a historic view of performance bottlenecks
• Receive: This function collects transactions from the Send function. The
Receive function stores and manages the transactions on the backup system
for processing using the Apply function. The Receive function offers these
features:
– A temporary staging step where transactions are pushed off the sending
system as soon as possible to eliminate the load from the source system
CPU
– Fast performance because it is written in ILE/C
– Variable length log space entries to make the most of available CPU and
DASD resources
– Filtering capabilities for greater capacity exists on the target system to
boost performance on the Send side
• Apply: This function reads all transactions and updates the duplicate
databases on the target systems accordingly. The Apply function supports the
following features:
– Offers a file or member control feature to manage file name aliases and
define files to the member level (files are locked during the Apply process
for maximum configuration flexibility and to prevent files from being
unsynchronized)
– Opens up to 9,999 files simultaneously within a MIMIX Apply session
– Supports record lengths up to 32 K in size
– Manages DB2/400 commitment control boundaries during the Apply and
Switch processes
– Uses a log process to protect against data loss during a source system
outage
– Includes a graphical status report of source and target system activity. It
displays the report in an easy-to-read format for operators to quickly
identify MIMIX operating environment issues.
• Synchronize: This function verifies that the target system has recorded exact
copies of the source system data. The Synchronize function supports the
following features:
– Offers keyed synchronization to keep target and source databases in
synchronization with the unique “key” field in each record
– Provides support tools to analyze and correct file synchronization errors by
record
• Switch: This function prepares target systems for access by users during a
source system outage. The Switch function performs the following tasks:
– Defines systems, journals, fields, and data areas. The Send, Receive, and
Apply sessions are linked into a logical unit called a data group.
High availability business partner solutions 117
– Uses a data group manager to reverse the direction of all MIMIX/400
transmissions during an outage
– Offers a journal analysis tool to identify transactions that may be
incomplete after an outage
10.2.2 MIMIX/Object
The MIMIX/Object component creates and maintains duplicate images of critical
AS/400 objects. Each time a user profile, device description, application program,
data area, data queue, spooled file, PC file, image file, or other critical object is
added, changed, moved, renamed, or deleted on an AS/400 production system,
MIMIX/Object duplicates the operation on one or more backup systems.
The key elements of MIMIX/Object include:
• Audit Journal Reader: This element scrapes the source system security audit
journal for object operations and passes them to the distribution reader. The
features of the Audit Journal Reader include:
– Management of objects within a library by object and type; document
library objects (DLOs) by folder path, document name, and owner; and
integrated file system objects by directory path and object name
– Management of spooled-file queues based on their delivery destination
– Explicit, generic (by name), and comprehensive (all) identification of library,
object, DLO, and integrated file system names
– An “include” and “exclude” flag for added naming precision
– Integrated file system control to accommodate hierarchical directories,
support long names, and provide additional support for byte stream files
• Distribution Reader: This element sends, receives, confirms, retries, and
logs objects to history and message queues. The features of the Distribution
Reader include:
– Multi-thread asynchronous job support to efficiently handle high volumes of
object operations
– A load-leveling journal monitor to automatically detect a large back log for
greater parallelism in handling requests
– A history log to monitor successful distribution requests; offering reports by
user, job, and date; and provides effective use of time for improving security
control and management analysis
– A failed request queue to provide error information, and for deleting and
retrying options for ongoing object integrity and easy object resolution
– An automatic retry feature to resubmit requests when objects are in use by
another application until the object becomes available
– Automatic management of journal receivers, history logs, and transaction
logs to minimize the use of auxiliary storage
• Send Network Object: This element relies on the Audit Journal Reader, which
interactively saves and restores any object from one system to another. It
offers simplified generic distribution of objects manually or automatically
through batch processing.
118 High Availability on the AS/400 System: A System Manager’s Guide
10.2.3 MIMIX/Switch
The MIMIX/Switch component detects system outages and initiates the MIMIX
recovery process. It automatically switches users to an available system where
they can continue working without losing information or productivity.
The key elements of MIMIX/Switch include:
• Logical Switch: This element controls the physical switch, communication
and device descriptions, network attributes, APPC/APPN configurations,
TCP/IP attributes, and timing of the communication switchover. The features of
the Logical Switch include:
– User exits to insert user-specified routines almost anywhere in the
command stream to customize the switching process
– A message logging feature to send status messages to multiple queues
and logs for ensuring the visibility of critical information
• Physical Switch: This element automatically and directly communicates with
the gang switch controller to create a switchover. The features of the Physical
Switch include:
– A custom interface to the gang switch controller to switch communication
lines directly
– An operator interface to facilitate manual control over the gang switch
controller
– Remote support to initiate a switch through the gang switch controller from
a distance
– Interface support of twinax, coax, RJ11, RS232, V.24, V.35., X.21, DB9, or
other devices that the user can plug into a gang switch
• Communications Monitor: This element tracks the configuration object
status to aid in automating retry and recovery. An automatic verification loop
ensures that MIMIX/Switch only moves users to a backup system when a
genuine source system outage occurs.
10.2.4 MIMIX/Monitor
The MIMIX/Monitor component combines a command center for the
administration of monitor programs and a library of plug-in monitors so the user
can track, manage, and report on AS/400 processes.
MIMIX/Monitor regulates the system 24 hours a day. It presents all monitor
programs on a single screen with a uniform set of commands. This minimizes the
time and effort required to insert or remove monitors or change their parameters.
The MIMIX/Monitor also accepts other data monitoring tools created by
customers and third-party companies into its interface.
The user can set the programs included with MIMIX/Monitor to run immediately,
continually at scheduled intervals, or after a particular event (for example, a
communications restart).
MIMIX/Monitor includes prepackaged monitor programs that the user can install
to check the levels in an uninterrupted power supply (UPS) backup system, or to
evaluate the relationship of MIMIX to the application environment.
High availability business partner solutions 119
10.2.5 MIMIX/Promoter
The MIMIX/Promoter component helps organizations maintain continuous
operations while carrying out database reorganizations and application upgrades,
including year 2000 date format changes. It uses data transfer technology to
revise and move files to production without seriously affecting business
operations.
MIMIX/Promoter builds copies of database files record-by-record, working behind
the scenes while users maintain read-and-write access to their applications and
data. It allows the user to fill the new file with data, change field and record
lengths, and, at the same time, keep the original file online.
After copying is complete, MIMIX/Promoter moves the new files into production in
a matter of moments. This is the only time when the application must be taken
offline.
Implementing an upgrade also requires promoting such non-database objects as
programs and display files. To handle these changes, many organizations use
change management tools, some of which can be integrated with
MIMIX/Promoter′ s data transfer techniques.
10.2.6 OptiConnect and MIMIX
MIMIX/400 integrates OptiConnect for OS/400 support for the IBM high-speed
communications link, without requiring separate modules. The combination of
MIMIX and OptiConnect provides a horizontal growth solution for interactive
applications that are no longer contained on a single machine. OptiConnect
delivers sufficient throughput for client/server-style database sharing among
AS/400 systems within a data center for corporate use. MIMIX/400 complements
the strategy by making AS/400 server data continuously available to all clients.
10.2.7 More Information About Lakeview Technology
For more information about the complete Lakeview Technology product line, visit
Lakeview Technology on the Internet at: http://www.lakeviewtech.com
10.3 Vision Solutions: About the company
Vision Solutions was founded in 1990 by two systems programmers working at a
hospital IT staff in California. They recognized the need for a dual systems
solution that would exploit the rich OS/400 architecture and provide an
application for managing business integrity using dual AS/400 systems. Originally
known as Midrange Information Systems, Inc., the name was changed to Vision
Solutions, Inc. in July 1996. Today it has grown into an international company with
development staff and facilities in the Netherlands, South Africa, and the United
States. It employs over 150 people worldwide.
10.3.1 Vision Solutions HAV solutions
When you consider the costs of purchasing additional assets in the form of
hardware, software, and consulting services to expand the hours of operations, to
increase the scope of a business’ growth capability, and to allow greater
utilization of a business solution on the AS/400 platform, using dual systems for
mirroring the business application system is a prudent business decision. If the
120 High Availability on the AS/400 System: A System Manager’s Guide
focus is strictly on the disaster aspects of dual systems, the decision to go with
this solution is never quick or easy to make. By expanding the view of why a
business must use dual systems to the other advantages of continuous
operations support, improved availability from dedicated backup processes and
workload balancing, the decision process leads to a wise business project.
Vision Solutions supports this effort with its management and integrity facilities
that are built directly into Vision Suite. One main advantage of using Vision Suite
for your HSA and Continuous Operations requirements is that many of its
application integrity features exceed the requirements of most AS/400 mission
critical applications today. When considering dual systems, pursue your
evaluations with due diligence and use the following criteria:
• Integrity: How do you know the backup system is equal to your production?
Do you employ more analysts to write additional utilities for monitoring or
support that use your existing staff? Or, will this decision software reside in the
HSA solution?
• Performance: How much data can you push to the other system to minimize
in-flight transactions being lost during an unplanned outage using the
minimum possible CPU? If your application employs OS/400 Remote
Journaling and Clustering, does the HSA vendor demonstrate live support of
this capability?
• Performance: What happens when your network stops or your backup system
fails for an indefinite period of time? Can you catch up quickly to protect your
business?
• Ease of Use: Can my existing operations staff use this application?
• Application Support: As an application evolves and possibly extends its use
of the rich OS/400 architecture, will your HSA application be able to support
those extensions without customized software?
Pursue this criteria for your business needs and commitments with regards to
continuous operations and business integrity.
10.3.2 Vision Suite
There are three components to Vision Suite:
• Object Mirroring System/400 (OMS/400)
• Object Distribution System/400 (ODS/400)
• System Availability Monitor/400 (SAM/400)
The requirements for Vision Suite necessitate the use of the OS/400 Journal
function for both OMS/400 and ODS/400. Journaling gives Vision Suite the ability
to deliver real time database transactions and event driven object manipulations
to a backup AS/400 system. While some AS/400 application environments have
journaling already active, the integrated Vision Suite Journal Manager can relieve
the user of the journal receiver management function. Figure 32 on page 121
illustrates a typical configuration between a production system and a backup
system. The journal receivers provide the input to Vision Suite for replication to
the backup Database Server system.
10.3.2.1 OMS/400
This component replicates and preserves the Application Integrity established in
your software design. It immediately transfers the transitional changes that occur
High availability business partner solutions 121
in your data areas, data queues, and physical files to a backup AS/400 system.
As the application database is manipulated by the programs I/O requests, and
these operations are recorded in the journal by OS/400, OMS/400 transports the
resulting journal entries of those requests to a backup database server in real
time. This minimizes any data loss due to an unplanned outage. As shown in
Figure 32, the Reader/Sender function takes the journal entry over to the backup
system through various communications media supported in OS/400. Any
communications media utilizing the SNA or TCP/IP protocols and OptiMover are
supported by Vision Suite.
Figure 32. Typical Vision Suite configuration
The Receiver function places the journal entry into the Router function so that it
may be assigned to an Apply Queue. The Apply Queue writes the record image
captured in the journal entry into the appropriate data object located on the
backup system. All objects in a given Database Server are distributed evenly
across multiple Apply Queues provided for that single database. The equal
separation of files (according to logical relationships in DB2/400 or applications)
ensures an even use of CPU and memory resources among each Apply Queue.
10.3.2.2 Application integrity
In addition to the requirement of delivering data efficiently and quickly, OMS/400
manages the synchronization and integrity of the database and data objects by
using several background processes that do not require operator control and
management. Integrity of your database between each physical file, data area,
LAN
Production System Backup System
System ASP
User ASP
Journal Receivers
SQL Tables, Stream files, objects
Reader/Sender Communications Media Receiver
System ASP
Router
Apply Apply
SQL Tables, Stream files, objects
122 High Availability on the AS/400 System: A System Manager’s Guide
and data queue, along with the applications, is a cornerstone for successful role
swaps. Role swap is Vision terminology for moving the business processes, which
can be end users, batch jobs, or a combination of both application environments
from one AS/400 server to another.
Assurances for complete Application integrity on your backup systems allow you
to quickly declare disasters instead of hoping for something else to happen. No
integrity issue of any type ensures that planned or unplanned outages occur with
a quick role swap supporting continuous operations at minimum downtime.
Furthermore, the journal receivers generated from all of the database activity
impacts the auxiliary storage space in a short time if these objects are not
managed. Vision Suite features its Journal Manager function that creates journal
environments for your mission critical databases. It can completely control the
entire management role of journal receivers on both the production and backup
AS/400 server. This ensures that the client is free for other AS/400 maintenance
functions.
10.3.2.3 ODS/400
The second component of Vision Suite preserves the Environment Integrity
developed for your application by replicating all supported object types of that
application. This is an important consideration for any AS/400 system requiring
continuous operations. While database transactions are complex and numerous
compared to object manipulations, change management of your application
environment must be duplicated on the backup system to ensure a timely and
smooth role swap (move the business from the production system to the backup
system). To ensure Environment Integrity, a user should choose to perform
change management on each individual system or use ODS/400 to replicate the
various object changes to those systems.
Increasingly, object security has heightened the need for ODS/400. In pre-client
(or PC Support) days, typical security control was managed through 5250 session
menus. However, today’s WAN and Internet/intranet network environments utilize
many application tools that are built on ODBC and OLE database interfaces.
AS/400 IT staffs must meet the challenge of taking advantage of OS/400 built-in
object security. This involves removing public authority from mission critical
objects and interjecting the use of authorization lists and group profiles. While the
AS/400 system maintains a high-level interface for this work, the interlocking
relationships of objects, databases, and users (both local and remote) become
complex. ODS/400 maintains this complex environment so that its integrity is
preserved on your backup system.
In mission critical AS/400 applications, the main focus for continuous operations
and high availability is the integration of the database with its associated software
and related security object authorizations and accesses.
10.3.2.4 SAM/400
The final component of Vision Suite is SAM/400. Its main purpose is to monitor
the production (or source application) system heartbeat and condition the role
swap when all contact is lost. It has ancillary functions for keeping unwarranted
users from accessing the backup system when it is not performing the production
function. It also provides user exits for recovery programs designed by the
Professional Services staff for specific recovery and environment requirements.
High availability business partner solutions 123
Vision Solutions, Inc. products operate on two or more AS/400 systems in a
network and use mirroring techniques. This ensures that databases, applications,
user profiles, and other objects are automatically updated on the backup
machines. In the event of a system failure, end users and network connections
are automatically transferred to a predefined backup system. The Visions
products automatically activate the backup system (perform a role swap) without
any operator intervention.
With this solution, two or more AS/400 systems can share the workload. For
example, it can direct end-user queries that do not update databases to the
backup system. Dedicated system maintenance projects are another solution
benefit. The user can temporarily move their operations to the backup machine
and upgrade or change the primary machine.
This High Availability Solution offers an easy and structured way to keep AS/400
business applications and data available 24 hours a day, 7 days a week.
The Vision Solutions, Inc. High Availability Solution (called Vision Suite) includes
three components:
• Object Mirroring System (OMS/400)
• Object Distribution System (ODS/400)
• System Availability Monitor (SAM/400)
The following sections highlight each component.
10.3.3 OMS/400: Object Mirroring System
The Object Mirroring System (OMS/400) automatically maintains duplicate
databases across two or more AS/400 systems.
Figure 33 illustrates the OMS/400 system. This system uses journals and a
communication link between the source and target systems.
Figure 33. Object Mirroring System/400
User application
programs
Journal receivers
User databases
OMS/400 sender
User query
programs
User Space
User databases
OMS/400 receiver
Router
Source system Target AS/400
124 High Availability on the AS/400 System: A System Manager’s Guide
The features of the OMS/400 component include:
• Automatic repair of such abnormal conditions as communication,
synchronization, or system failure recoveries
• Synchronization of enterprise-wide data by simulcasting data from a source
system to more than 9,000 target destinations
• User space technology that streamlines the replication process
• An optional ongoing validity check to ensure data integrity
• Automatic restart after any system termination
• Automatic filtration of unwanted entries, such as opens and closes
• The power to operate programs or commands from a remote system
• The ability to dynamically capture data and object changes on the source
system and copy them to the target system without custom commands or
recompiles
• The option to create an unlimited number of prioritized AS/400 links between
systems
• Total data protection by writing download transactions to tape
• Support of RPG/400 for user presentation, and ILE/C for system access, data
transmission, and process application
• Full support of the IBM OptiConnect/400 system
• Global journal management when a fiber optic bus-to-bus connection is
available
• The use of CPI-C to increase speed of data distribution using minimal CPU
resources
10.3.4 ODS/400: Object Distribution System
The Object Distribution System (ODS/400) provides automatic distribution of
application software, authority changes, folders and documents, user-profile
changes, and system values. It also distributes subsystem descriptions, job
descriptions, logical files, and output queue and job queue descriptions.
ODS/400 is a partner to the OMS/400 system, and it provides companies with full
system redundancy. It automatically distributes application software changes,
system configurations, folders and documents, and user profiles throughout a
network of AS/400 computers.
ODS/400 supports multi-directional and network environments in centralized or
remote locations. For maximum throughput, ODS/400 takes advantage of
bi-directional communications protocol and uses extensive filters.
10.3.5 SAM/400: System Availability Monitor
The System Availability Monitor (SAM/400) can switch users from a failed primary
system to their designated secondary system without operator intervention.
SAM/400 works in conjunction with OMS/400 and ODS/400, continuously
monitoring the source system. In the event of a failure, SAM/400 automatically
redirects users to the target system. This virtually eliminates downtime.
High-speed communications links, optional electronic switching hardware, and
High availability business partner solutions 125
SAM/400 work together to switch users to a recovery system in only a few
minutes.
SAM/400 offers:
• Continuous monitoring of all mirrored systems for operational status and
ongoing availability
• A fully programmable response to react automatically during a system failure,
which reduces the dependence on uninformed or untrained staff
• The ability to immediately and safely switch to the target system, which
contains an exact duplicate of the source objects and data during a source
system failure (unattended systems are automatically protected 24 hours a
day, 7 days a week)
• User-defined access to the target system based on a specific user class or
customized access levels
The SAM/400 component offers:
• Up to ten alternate communication links for monitoring from the target system
to the source system
• Automatic initiation of user-defined actions when a primary system failure
occurs
• Exit programs to allow the operator to customize recovery and operations for
all network protocols and implementations
Figure 34 illustrates the SAM/400 monitoring process.
Figure 34. SAM/400 structure
Users are allowed to access applications at the “End” point.
10.3.6 High Availability Services/400
High Availability Services/400 (HAS/400) consists of software and services. The
HAS/400 solution is comprised of:
SAM/400
Traffic
Role
Swap
Start
conversation
Yes
Source system Target AS/400
SAM/400
Remote
switch
controller
A/B switch
panel
Is the other
system active??
No
Do we have
a hardware switch ?
Call user
exit pgm
Yes
126 High Availability on the AS/400 System: A System Manager’s Guide
• Analysis of the customer environment in terms of system availability needs
and expectations, critical business applications, databases, and workload
distribution capabilities
• An implementation plan written in terms of solution design and the required
resources for its deployment
• Installation and configuration of the software products and the required
hardware
• Education for the customer staff on operational procedures
• Solution implementation test and validation
• Software from Vision Solutions, Inc., as previously described
10.3.7 More information about Vision Solutions, Inc.
For more information about Vision Solutions, Inc. products, visit Vision Solutions
on the Internet at: http://www.visionsolutions.com
© Copyright IBM Corp. 2001 127
Chapter 11. Application design and considerations
Applications are regarded as business-critical elements. The viewpoint of
systems management is changing from a component view to an application view.
Here are a few considerations that are now made at the application level:
• The entire application, or parts of the application, must be distributed.
• The application has to be monitored to guarantee availability.
• Operations, such as scheduling jobs and doing backups, are recommended.
• User profiles must be created, given access to applications, changed, and
deleted.
If a system is unavailable, and rapid recovery is necessary, backups are restored
and the system and the database are inspected for integrity. The recovery
process could take days for larger databases.
This scenario requires improvement in the areas of restore speed and application
recovery. Both of these areas can be costly to implement. High speed tape drives
are very expensive items and, for very large databases, they may not show
enough restore time improvement to meet user demands.
Application recovery requires a lot of development effort and is, therefore, very
costly. This, in itself, may also degrade availability. To make the application more
available, considerable additional processing and I/O should be available. This
means the response time degrades unless there is an abundance of computing
resources.
In the past, application recovery was at the bottom of the list of availability tasks.
The size of required systems would be too expensive for the business to justify.
These days, with the vast improvements on price and performance power,
solutions exist that provide a high level of availability. In addition, businesses are
now able to define the cost of system outage more accurately.
From a user point-of-view (both a system end user, and a receiver of services),
the availability of a system relates to the information available at a given time. A
customer holding for a price lookup considers the efficiency of the answer as an
indication of the quality of the business.
Designing applications for high availability is a comprehensive topic and
textbooks have been dedicated to this topic alone. From a high level, some of the
considerations are discussed in this chapter. Areas that are covered include
application checkpointing design, considerations, and techniques (including CL
programs), for the interactive environment.
11.1 Application coding for commitment control
You can use commitment control to design an application so that it can be started
again if a job, an activation group within a job, or the system ends abnormally.
The application can be started again with the assurance that no partial updates
are in the database due to incomplete logical units of work from a prior failure.
There are numerous documents that describe the use of commitment control and
journaling. The OS/400 Backup and Recovery, SC41-5304, contains journaling
and commitment control requirements. IBM language-specific manuals include:
128 High Availability on the AS/400 System: A System Manager’s Guide
• DB2 for AS/400 SQL Programming, Version 4, SC41-5611
• ILE C for AS/400 Programmer’s Guide, Version 4, SC09-2712
• ILE COBOL for AS/400 Programmer’s Guide, Version 4, SC09-2540
• ILE RPG for AS/400 Programmer’s Guide, Version 4 SC09-2507
These manuals contain information about using commitment control for a
particular language. Various Redbooks and “how to” articles are found throughout
IBM-related web sites. These sites include:
• http://www.news400.com
“Safeguard Your Data with RI and Triggers”, Teresa Kan December, 1994
(page 55)
• http://www.news400.com
“AS/400 Data Protection Methods”, Robert Kleckner, December 1993 (page
101)
11.2 Application checkpointing
In general, application checkpointing is a method used to track completed job
steps and pick up where the job last left off before a system or application failure.
Using application checkpointing logic, along with commitment control, you can
provide a higher lever of resiliency in both applications and data, regardless of
whether they are mission critical in nature.
Throughout the existence of IBM midrange systems, application checkpointing
has been used to help recover from system or application failures. It is not a new
subject when it comes to IBM midrange computing, specifically on the AS/400
system. However, there are some new features.
Unlike commitment control, application checkpointing has no system level
functions that can be used to automate recovery of an application. If commitment
control is used, and the job stream has multiple job steps, the application needs
to know which job has already run to completion. Application checkpoints help
the programmers to design recovery methods that can prevent the restarted jobs
from damaging the database by writing duplicate records.
Remember that there is additional information written on concepts and methods
for application checkpoints, as well as recovery with or without journaling and
commitment control.
The following sections define recovery methods for applications that work in any
high availability environment for the AS/400 system (including clustering). Most of
the concepts also work for other (non-AS/400) platforms.
11.3 Application checkpoint techniques
Techniques for application checkpointing and recovery vary for every program.
Whether you use Cobol, RPG, SQL or C as the application language, the
methods employed for application checkpointing remain constant.
Without journaling and commitment control capabilities, programmers devise
their own tracking and recovery programs. This section describes an example of
how this is done.
Application design and considerations 129
11.3.1 Historical example
The following scenario describes a customer environment that runs the sales
force from a System/36 in the early 1980s.
The customer’s remote sales representatives dial into a BBS bulletin board
system from their home computer, upload the day’s orders, and request the sales
history for the clients they are to visit the next day. The next morning, the same
remote sales representative dials into the BBS to retrieve the requested
information.
BBS systems and modems were not reliable in the early 1980s. Many of the
transfers ended abnormally. Application programmers devised a method to
update data areas with specific job step information after the job steps
completed. If the Operator Control Language (OCL) job starts and finds an error
code in the data area, the program logic jumps to the last completed step (as
indicated by the data area) and starts from there. This is a primitive form of
application checkpointing, but it works.
Later applications utilized log files. Programs were designed to retrieve
information from the log file if the last job step was not successful. Using the
program name, last completed job step, current and next job step, as well as the
total job steps, the programmer determined where to start the program. The
program itself contained recovery subroutines to process if the recovery data
area contained information that a job failure occurred.
As for the data, temporary files were created containing the before image of a file.
Reading the required record, then writing the temporary file prior to any updates
or deletes, the information was written back to its original image if the job failed.
At the completion of the job, all temporary files were removed.
With the high availability products on the market today, a more efficient design is
possible. A permanent data file includes the data area logic. High availability
products mirror data areas and data queues. However, the HA applications work
off of journal information.
Note: Data areas and data queues can not be journaled in OS/400 V4R4. Moving
any checkpoint logic from a data area to a data file operates with more efficiency
and provides a higher restart capability than data areas.
11.4 Application scenarios
The following paragraphs explain application checkpointing methods in various
scenarios. The methods described are not the only possible options for
application checkpoints. However, they provide a good starting point for
managing your high availability environment with application checkpoints that
work in any HA environment.
11.4.1 Single application
For a single application, checkpoints are established by adding recovery logic to
the program to handle the commit and roll back functions. The job’s Control
Language (CL) program needs to include checks for messages that indicate an
incomplete or open Logical Unit of Work (LUW).
130 High Availability on the AS/400 System: A System Manager’s Guide
Testing for incomplete job runs is the primary requirement of application
checkpoints. Some simple testing of control information for an error code prior to
running the start or end commit command prevents users from getting erroneous
messages. If the control information is clean, run the Start Commitment Control
(STRCMTCTL) function and change the control information to uncompleted. If the
control information has an error code, act on it by performing either a commit or
rollback. Most often, the action is a rollback. At the completion of the program,
execute a commit and then change the control information to indicate a
successful update.
11.4.2 CL program example
This example uses CL programs. It is assumed that the Logical Unit of Work
(LUW) includes all I/O operations that this program performs. If a rollback takes
place, all changes are removed from the system.
If there is a higher complexity to the application, such as multiple levels of
application calls, or many updates, inserts, and deletes, you should consider this
a multiple application program.
Also, in this example, a data area is used for the control information. For High
Availability, it is recommended that you have the control information in a data file.
Mirroring record information is more efficient than data areas or data queues
because the current release of OS/400 (V4R4) does not support journaling data
areas or data queues. Successful and complete recovery from a system failure is
more likely if the recovery information is contained in a mirrored file.
If this job is used in a multi-step job stream, place true application checkpoint
functions into it. To do this, create a checkpoint-tracking file. The
checkpoint-tracking file used to track the job steps must include information about
the job and where to start.
PGM
DCL &OK *CHAR 1
RTVDTAARA CONTROL &OK 1 1
IF COND(&OK *NE ‘ ‘) THEN(ROLLBACK)
CHGDTAARA &OK ‘E’
STRCMTCTL
CALL UPDPGM
RTVDTAARA CONTROL &OK 1 1
IF COND(&OK *NE ‘ ‘) THEN(ROLLBACK)
IF COND(&OK *EQ ‘ ‘) THEN(COMMIT)
ENDCMTCTL
CHGDTAARA &OK ‘ ’
ENDPGM
Basic CL program model 131
Chapter 12. Basic CL program model
The following model contains the basic information for most jobs. Additional
information can and should be tracked for better recovery:
* Program Name
* Current Job Step
* Previous Job Step
* Next Job Step
* Total Job Steps
* Job Start time
* Job Name
* User
* Last processed record key information
The information listed here should help you determine where you are, where you
were, and where to go next. You can also determine how far into the job you are
and who should be notified that the job was interrupted.
12.1 Determining a job step
The diagrams shown in Figure 35 and Figure 36 illustrate how to determine a job
step.
Figure 35. Determining a job step (Part 1 of 3))
Figure 36. Determining a job step (Part 2 of 3)
All programs have some basic flow. Using Commitment Control, the data is
protected with the LUW, Commit, and Rollback. The diagram shown in Figure 37 on
page 132 shows these components.
Open Read Calculate Write EOJ Return
Open file Read file Modify data Write file EOJ Return
CC/LUW
No
132 High Availability on the AS/400 System: A System Manager’s Guide
Figure 37. Determining a job step (Part 3 of 3)
To determine the key points for the job step markers, notice how the data is read,
manipulated, and written. Also look at any end-of-job processing.
If the job fails while processing the data, start at the last completed processed
record. This means that the section where the data is read into the program is a
“key point” for your job step. Most applications read the data first, so this is the
first job step. If there is a section of the program prior to the read that must be
recalculated, it should be the first point of the job step.
After determining where the data is read, look at where the data is written. In this
example, commitment control provides the second key point. When the data is
committed to a disk, it can’t be changed. By placing the next job step at this point,
a restart bypasses any completed database changes and moves to the next
portion of the program.
If the program writes thousands of records, but performs a commit at every 100,
the checkpoint tracking information should include some key elements for the last
committed record. This information should be collected for step 1 after every
commit. With the information collected this way, a restart can go to step 1 and set
the initial key value to start reading at the last committed point.
End of job processing can cause many application restart attempts to fail. The
reasons for this should appear obvious. If the job does not have an end of job
(EOJ) summary or total calculations to perform, then step 2 is the last job step.
However, if summary reports and total calculations must be performed (for
example, for an invoice application), some added logic is needed. Most summary
or total calculations are performed on data that is collected and calculated from a
previously performed file I/O. They are usually stored in a table or in an array in
memory. If the job fails before EOJ calculations are made, memory allocated for
the job is released. Take this into consideration when working with commitment
control’s logical unit of work. The logic for determining the recovery job steps may
need to be “Start everything over”. With improper commitment control logic, data
loss is possible.
If, on the other hand, the job is extremely long running or is a critical job, write the
summary information into a work file. The process of completing a job step and
writing out the work file occurs before EOJ processing and can be considered its
own job step. If you use a work file for array or table information, place the name
of the work file in the tracking file as well. Include restart logic in the program to
reload any tables or arrays for EOJ processing.
Open file Read file Modify data Write file EOJ Return
CC/LUW
No
Step 1 Step 2 Step 3
Basic CL program model 133
Keep in mind that high availability solution providers can track and mirror files
that are created and deleted on the fly. However, processing overhead is much
higher and the chance of “in-flight transactions” can occur at the time of failure.
This results in lost data. Therefore, it is recommended that work files be created
and maintained instead of created and deleted.
Using the Clear Physical File Member (CLRPFM) function on the AS/400 system
maintains the journal link with the file and reduces the overhead of saving and
restoring file information caused by a create and delete. Create temporary files in
the QTEMP library on the AS/400 system. QTEMP can not be mirrored by high
availability solution providers. This library can contain true temporary files in
which the contents can be easily recreated. If a job fails, temporary files do not
affect the program outcome.
The last checkpoint in the job should take place immediately before the end of, or
return to, the previous job step. This checkpoint can clear any error flags, reset
the program name, or remove the tracking record from the checkpoint tracking
file. Creating logging functions for history reporting can also be performed from
this checkpoint.
12.1.1 Summary of the basic program architecture
The examples and logic defined in 11.3, “Application checkpoint techniques” on
page 128, work within the AS/400 system on all release levels of OS/400 from
Version 1 onward. If you plan on moving to a clustered environment available
from IBM (from OS/400 V4R4 onward), the model described here provides a
good start for cluster ready.
Add additional tracking information to start the users at a specific point in the
application, such as tracking screens and cursor positions. When writing out the
checkpoint-tracking file, reserve space for this information so the recovery
process can place the user as close to where they left off as possible. Information
for screens and cursor positions, as well as job information, user information, and
file information can be retrieved from the Information Data Structures (INFDS)
provided by OS/400.
A wealth of information can be retrieved from the INFDS, including screen
names, cursor positions, indicator maps, job information, and more. Part of the
cluster ready requirements is to restart the users where they last left off. Using
application checkpoints accomplishes this.
12.2 Database
At the core of the AS/400e system is the relational database. When multiple
systems are involved, a portion or a copy of the data can reside on the remote
system. This is called a distributed database.
12.2.1 Distributed relational database
Application coding for distributed databases require more involved and
complicated logic than programs designed for accessing data on a single system.
Application checkpoint logic adds further complexity to the program logic. Both of
these situations require a seasoned programmer analyst. This should be
someone with patience, persistence, and experience. This section addresses
134 High Availability on the AS/400 System: A System Manager’s Guide
some of the concerns of programming in a distributed relational database
environment.
Note: Using the ideas and concepts discussed in this chapter, and deploying
them into any distributed application model, does not change the amount of work
for the programmer. Application checkpointing is not concerned with where the
data is. Rather, it is concerned with where the application runs.
If you use DRDA as the basis of the distributed database, the applications reside
with the data on all systems. DRDA submits a Unit of Work (UoW) that executes a
sequence of database requests on the remote system. In other words, it calls a
program and returns the information.
DRDA uses a two-phase commit for the database. This means that the data is
protected from failure over the communications line, as well as system or job
failures.
If the program on the remote system performs proper application checkpointing
when the remote system, remote application, or communications, fails during the
processing of UoW, the restart picks up from where it left off.
Adding a “from location” field and “to location” field in the checkpoint-tracking file
allows reports information that better defines the locations of the jobs running. It
also helps isolate communication fault issues with the application modules that
start and stop communications.
It is recommended that application checkpointing in a DRDA environment be
setup in a modular fashion. A recovery module that controls the reads and writes
to the checkpoint-tracking file make analysis and recovery easier. Take special
care to ensure that the database designers include the checkpoint-tracking file in
the original database design. This enables the recovery module to treat each
existence of the tracking file as an independent log for that local system.
A future release of DB2/400 UDB Extended Enterprise Edition (EEE) will include
scalability for Very Large Database (VLDB) support. Like DRDA, the VLDB
database is distributed over different systems. Unlike DRDA, the access to the
data is transparent to the program. No special communication modules or
requester jobs need to be created and maintained. Since the environment looks
and feels like a local database, the application checkpointing logic must treat it
like a local database running in the multiple application mode.
For more details on the workings of DB2/400 and DRDA, refer to DB2/400
Advanced Database Functions, SG24-4249.
12.2.2 Distributed database and DDM
You can use DDM files to access data files on different systems as a method of
having a distributed database. When the DDM file is created, a “shell” of the
physical file resides on the local system. The shell is a pointer to the data file on
the remote system.
The program that reads from, and writes to, this file does not know the data is
located on a different system. Since DDM files are transparent to the application,
approach application checkpointing logic as discussed in 11.4.1, “Single
application” on page 129.
Basic CL program model 135
12.3 Interactive jobs and user recovery
The information and logic necessary to recover from a system or application
failure is no different between interactive jobs and batch jobs. There is a
difference in how much user recovery is needed.
There are three basic parts to every job:
• Data
• Programs
• Users
Use commitment control and journaling to address data recovery.
The file layout for the checkpoint-tracking file described previously has a space
reserved for the user name. This user name field can be used to inform the user
that the job was abnormally ended and that a restart or recovery process will run.
If this were an interactive job with screen information, the chance of the user
getting back to where they left off is not high. To correct this deficit, the recovery
process tracks more information to place the user as close to the point they left
off as possible. The addition of current screen information, cursor positions, array
information, table pointers, and variables can be stored in the tracking file along
with all the other information.
The AS/400 system stores all of the information it needs to run the application
accessible by the programmer. The programmer simply needs to know where to
find it. The Information Data Structure (INFDS) in RPG contains most, if not all, of
the information required to get the user back to the screen from where they left
off.
Use the Retrieve Job Attribute (RTVJOBA) command to retrieve job attributes
within the CL of the program. Retrieve system values pertinent to the job with the
Retrieve System Value (RTVSYSVAL) command.
Internal program variables are in control of the application programmer. Recovery
logic within the application can retrieve the screen and cursor positions, the run
attributes, and system values and write them to the tracking file along with key
array, table, and variable information. In the event of a failure, the recovery logic
in the program determines the screen the user was on, what files were open,
what the variable, array, and key values were, and even place the cursor back to
the last used position.
12.4 Batch jobs and user recovery and special considerations
Unlike interactive jobs, batch jobs have no user interface that needs to be tracked
and recovered. Since the user interface is not a concern, the checkpoint tracking
process defined in 11.4.1, “Single application” on page 129, and 12.2.1,
“Distributed relational database” on page 133, should suffice.
In general, this is true. This section describes additional vital information about
when the recovery environment includes high availability providers software.
These considerations include:
136 High Availability on the AS/400 System: A System Manager’s Guide
• Job queue information for the batch jobs cannot be mirrored: This means
that if you submit multiple related jobs to a single threaded batch queue, and
the system fails before all those jobs are completed, restarting may not help.
• Determining what jobs have been completed and what jobs still need to
run: If you have created a checkpointing methodology with the points
described previously, you have a tracking record of the job that was running at
the time of the failure. Using this information, restart that job and then
manually submit the remaining jobs to batch.
If this was a day-end process, determining the jobs that still need to be run
should not be complicated. If it was a month-end process, the work to restart
all the jobs consumes more time but it can be achieved with few or no errors. If
this was a year-end process, the work to restart all the necessary jobs in the
correct order without missing vital information can be very time consuming.
A simple solution is to store tracking information for batch jobs in the
application checkpoint-tracking file. The added work in the recovery file is
minimal, yet the benefits are exponential.
Within the job that submits the batch process, a call to the application
checkpointing job name, submitted time, submitted queue, and submitted
status is ideal. The application checkpoint module writes this information to
the checkpoint-tracking file. When the job runs in batch mode, it modifies the
status to “Active”. Upon completion, remove the record or mark as was done in
the tracking file to complete a log of submitted jobs.
Within any high availability environment, the tracking information is processed
almost immediately. In the event of a system failure, the recovery module
interrogates the tracking file for submitted jobs that are still in a JOBQ status
and automatically resubmit them to the proper job queue in the proper order
(starting with the job with an “Active” status). This possibility prevents any user
intervention, therefore eliminating “user error”.
12.5 Server jobs
The nature of a server job is very robust. To maintain reliability, server jobs
should be able to recover from most, if not all, error conditions that can cause
normal jobs to fail.
Since server jobs run in a batch environment, the recovery process itself is
identical to the batch process described in 12.4, “Batch jobs and user recovery
and special considerations” on page 135. However, additional considerations for
error recovery are necessary for the recovery file.
With application checkpointing built into the server job, error conditions can be
logged in the tracking file and corrections to either the server job or the client jobs
can be made based on what is logged.
Using application checkpoints to isolate faults and troubleshoot error conditions
is an added advantage to a well-designed recovery process. If the server job
fails, connection to the client can still exist. If this open connection is not possible,
there may be a way to notify the client to re-send the requested information or
Unit-of-Work (UoW). Either way, the server job must track the information in the
checkpoint-tracking file.
Basic CL program model 137
12.6 Client Server jobs and user recovery
Client Server jobs come in many different models, including thin clients, fat
clients, and other clients that include attributes of both fat and thin clients.
Even though they have a different label, these client server jobs are either a
batch job or an interactive job. The environment that the job runs in dictates the
type of recovery to perform.
Most client server applications rely on the client to contact the server to request
information from the server. Thin clients contact the server and pass units of work
for the server to perform and report back. Fat clients request data and process
the information themselves. “Medium” clients perform various aspects of each
method.
Recovery for the client server jobs should be mutually exclusive. If the client job
fails, the connection to the server can still exist. The client may be able to pick up
where it left off.
If this open connection is not possible, there may be a way to notify the server to
re-send the request for information. Either way, the client job must track the
information in the checkpoint-tracking file.
If the processing of the client request pertains to a long running process, it may
be best to design that particular job as a thin client. With a thin client design, the
processing is performed on the server side where application checkpointing
tracks and reports the job steps. In this case, recovery on the client includes
checking whether the communications is still available. If not, then submit the
request again from the beginning.
If the processing of the client pertains to critical information, the design should
lean towards the fat client model. If the client is a fat client model, the application
checkpointing logic described in this book should suffice.
Note: The nature of a client server relationship varies greatly. It is worth the time
to determine whether the recovery process in a client server environment is
necessary prior to writing the recovery steps. Thin clients perform much faster in
a restart mode if they are simply started again with absolutely no recovery logic.
For example, if a client process makes one request to the server for information,
adding recovery logic can double or even triple the amount of time required to
make that request.
12.7 Print job recovery
In the standard program model, information is collected, processed, and written.
The process of writing the information typically occurs during the end of job
(EOJ), after all the data is collected. In this case, adding a checkpoint at the
beginning of the EOJ processing restarts the printing functions in the event of a
restart. The scenario is described in “Distributed relational database” on
page 133.
Exceptions to this rule include programs that collect and write “detailed”
information as the job runs. Again, 12.2.1, “Distributed relational database” on
138 High Availability on the AS/400 System: A System Manager’s Guide
page 133, describes how a job step defined at the proper locations recreates
every function within the steps.
Even with a detailed and proper running recovery function in place, there is no
way to “pick up where you left off” in a print job. The print file itself is closed when
the job runs. Rewriting to it is not possible.
With proper application checkpoints in place, the print information should not be
lost. It is, however, duplicated to some extent.
If a print job within that application requires a specific name, that name should be
tracked in the checkpoint-tracking file and proper cleanup should be performed
prior to the job running again.
© Copyright IBM Corp. 2001 139
Part 4. High availability checkpoints
Part IV discusses miscellaneous items that are helpful when implementing a high
availability solution. Included in this part is information on a Batch Caching
solution, a discussion of the management of disk storage, device parity features,
and a checklist of items to consider when implementing your high availability
solution.
140 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 141
Appendix A. How your system manages auxiliary storage
For many businesses, computers have replaced file cabinets. Information critical
to a business is stored on disks in one or more computer systems. To protect
information assets on your AS/400 system, you need a basic understanding of
how it manages disk storage.
On the AS/400 system, main memory is referred to as main storage. Disk storage
is called auxiliary storage. Disk storage may also be referred to as DASD (direct
access storage device).
Many other computer systems require you to take responsibility for how
information is stored on disks. When you create a new file, you must tell the
system where to put the file and how big to make it. You must balance files across
different disk units to provide good system performance. If you discover later that
a file needs to be larger, you need to copy it to a location on the disk that has
enough space for the new larger file. You may need to move other files to
maintain system performance.
The AS/400 system is responsible for managing the information in auxiliary
storage. When you create a file, you estimate how many records it should have.
The system places the file in the location most conducive for good performance.
In fact, it may spread the data in the file across multiple disk units.
When you add more records to the file, the system assigns additional space on
one or more disk units. The system uses a function that is called virtual storage to
create a logical picture of how the data looks. This logical picture is similar to how
data is perceived. In virtual storage, all of the records that are in a file are
together (contiguous), even though they may be physically spread across multiple
disk units in auxiliary storage. The virtual storage function also keeps track of
where the most current copy of any piece of information is (whether it is in main
storage or in auxiliary storage).
Single-level storage is a unique architecture of the AS/400 system that allows
main storage, auxiliary storage, and virtual storage to work together accurately
and efficiently. With single-level storage, programs and system users request
data by name rather than by where the data is located.
Disk storage architecture and management tools are further described in AS/400
Disk Storage Topics and Tools, SG24-5693.
A.1 How disks are configured
The AS/400 system uses several electronic components to manage the transfer
of data from a disk to main storage. Data must be in main storage before it can be
used by a program.
142 High Availability on the AS/400 System: A System Manager’s Guide
Figure 38. Components used for data transfer
Figure 38 shows the components that are used for data transfer. The components
include:
• Bus: The bus is the main communications channel for input and output data
transfer. A system may have one or more buses.
• I/O processor: The input/output processor (IOP) is attached to the bus. The
IOP is used to transfer information between main storage and specific groups
of controllers. Some IOPs are dedicated to specific types of controllers, such
as disk controllers. Other IOPs can attach more than one type of controller (for
example, tape controllers, and disk controllers).
• Disk controller: The disk controller attaches to the IOP and handles the
information transfer between the IOP and the disk units. Some disk units have
built-in controllers. Others have separate controllers.
• Disk unit: Disk units are the actual devices that contain the storage units.
Hardware is ordered at the disk-unit level and each disk unit has a unique
serial number.
A.2 Full protection: Single ASP
A simple and safe way to manage and protect your auxiliary storage is to perform
the following tasks:
• Assign all disk units to a single auxiliary storage pool (the system ASP).
• Use device parity protection for all disk units that have the hardware capability.
• Use mirrored protection for the remaining disk units on the system.
With this method, your system continues to run even if a single disk unit fails.
When the disk is replaced, the system can reconstruct the information so that no
data is lost. The system may also continue to run when a disk-related hardware
component fails. Whether your system continues to run depends on your
B
U
S
Processor Main Storage
Input/Output
Processor
(IOP)
Disk
Controller
Disk Unit
Storage Unit
Input/Output
Processor
(IOP)
Disk
Controller
Disk Unit
Storage Unit
How your system manages auxiliary storage 143
configuration. For example, the system continues to run if an IOP fails and all of
the attached disk units have mirrored pairs that are attached to a different IOP.
When you use a combination of mirrored protection and device parity protection
to fully protect your system, you increase your disk capacity requirements. Device
parity protection requires up to 25% of the space on your disk units to store parity
information. Mirrored protection doubles the disk requirement for all disks that do
not have the device parity protection capability.
Figure 39 shows an example of a system with full protection. The system has 21
disk units. All of the disk units are assigned to the system ASP. The system
assigns unit numbers to each configured disk on the system. Notice that the
mirrored pairs share a common unit number.
Figure 39. Full protection: Single ASP
A.3 Full protection: Multiple ASPs
You may want to divide your disk units into several auxiliary storage pools.
Sometimes, your overall system performance may improve by having user ASPs.
For example, you can isolate journal receivers in a user ASP. Or, you can place
history files or documents that seldom change in a user ASP that has lower
performance disk units.
You can fully protect a system with multiple ASPs by performing the following
tasks:
• Use device parity protection for all disk units that have the hardware capability.
• Set up mirrored protection for every ASP on the system. You can set up
mirrored protection even for an ASP that has only disk units with device parity
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 3
Unit 2 Unit 2 Unit 4 Unit 4
Unit 1
6602 9336 9336
6602 6602 9336 9336
Unit 5
Unit 6
Unit 7
Unit 8
9337
Unit 13
Unit 14
Unit 16
9337 6603
Unit 11
Unit 10
Unit 15
Unit 17
Unit 12
Unit 9
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
144 High Availability on the AS/400 System: A System Manager’s Guide
protection. That way, if you add units that do not have device parity protection
in the future, those units are automatically mirrored.
Note: You must add new units in pairs of units with equal capacity. Before
configuring this level of protection, be sure that you know how to assign disk units
to ASPs.
Figure 40 shows an example of two ASPs. Both ASPs have device parity
protection and mirrored protection defined. Currently, ASP 2 has no mirrored
units.
Figure 40. Full protection: Multiple ASPs
A.4 Partial protection: Multiple ASPs
Sometimes, full protection (using a combination of device parity protection and
mirrored protection) may be too costly. If this happens, you need to develop a
strategy to protect the critical information on your system. Your objectives should
be to minimize the loss of data and to reduce the amount of time in which critical
applications are not available. Your strategy should involve dividing your system
into user ASPs and protecting only certain ASPs. Note, however, that if the
system is not fully protected and an unprotected disk unit fails, serious problems
can occur. The entire system can become unusable, end abnormally, require a
long recovery, and data in the ASP that contains the failed unit must be restored.
Before configuring this level of protection, be sure that you know how to assign
disk units to ASPs.
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 3
Unit 2 Unit 2 Unit 4 Unit 4
Unit 1
6602 9336 9336
6602 6602 9336 9336
Unit 5
Unit 6
Unit 7
Unit 8
9337
Unit 13
Unit 14
Unit 16
6603
Unit 10
Unit 11
9337
Unit 15
Unit 17
Unit 12
Unit 9
ASP 2
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
How your system manages auxiliary storage 145
The following list provides suggestions for developing your strategy:
• If you protect the system ASP with a combination of mirrored protection and
device parity protection, you can reduce or eliminate recovery time. The
system ASP, and particularly the load source unit, contain information that is
critical to keeping your system operational. For example, the system ASP has
security information, configuration information, and addresses for all the
libraries on the system.
• Think about how you can recover file information. If you have online
applications, and your files change constantly, consider using journaling and
placing journal receivers in a protected user ASP.
• Think about what information does not need protection. This is usually
information that changes infrequently. For example, history files may need to
be online for reference, but the data in the history files may not change except
at the end of the month. You could place those files in a separate user ASP
that does not have any disk protection. If a failure occurs, the system becomes
unusable, but the files can be restored without any loss of data. The same may
be true for documents.
• Think about other information that may not need disk protection. For example,
your application programs may be in a separate library from the application
data. It is likely the case that the programs change infrequently. The program
libraries could be placed in a user ASP that is not protected. If a failure occurs,
the system becomes unusable, but the programs can be restored.
Two simple guidelines can summarize the previous list:
1. To reduce recovery time, protect the system ASP.
2. To reduce loss of data, make conscious decisions about which libraries must
be protected.
Figure 41 on page 146 shows an example of three ASPs. ASP 1 (system ASP)
and ASP 3 have device parity protection and mirrored protection defined.
Currently, ASP 3 has no mirrored units and ASP 2 has no disk protection. In this
example, ASP 2 could be used for history files, reference documents, or program
libraries. ASP 3 could be used for journal receivers and save files.
146 High Availability on the AS/400 System: A System Manager’s Guide
Figure 41. Different protection for multiple ASPs
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 4
Unit 2 Unit 2 Unit 12 Unit 12
Unit 1
6602 9336 9336
6602 6602 9336 9336
Unit 5
Unit 6
Unit 7
Unit 8
9337
Unit 13
Unit 14
Unit 16
6603
Unit 10
Unit 11
9337
Unit 15
Unit 17
Unit 12
Unit 9
ASP 2
ASP 3
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
© Copyright IBM Corp. 2001 147
Appendix B. Planning for device parity protection
If you intend to have a system with data loss protection and concurrent
maintenance repair, plan to use one of the following configurations:
• Mirrored protection and device parity protection to protect the system ASP.
• Mirrored protection for the system ASP and device parity protection for user
ASPs.
• Mirrored protection and device parity protection to protect the system ASP and
user ASPs.
Note: You can use device parity protection with disk array subsystems as well as
with input-output processors (IOP).
For each device parity protection set, the space that is used for parity information
is equivalent to one disk unit. The minimum number of disk units in a subsystem
with device parity protection is four. The maximum number of disk units in a
subsystem with device parity protection is seven, eight, or 16, depending on the
type. A subsystem with 16 disk units attached has two device parity protection
sets and the equivalent of two disk units dedicated to parity information.
For more information about device parity protection, see Backup and Recovery,
SC41-5304.
B.1 Mirrored protection and device parity protection to protect the system ASP
This section illustrates an example of a system with a single auxiliary storage
pool (ASP). The ASP has both mirrored protection and device parity protection.
When one of the disk units with device parity protection fails, the system
continues to run. The failed unit can be repaired concurrently. If one of the
mirrored disk units fails, the system continues to run using the operational unit of
the mirrored pair. Figure 42 on page 148 shows an example of mirrored
protection and device parity protection used in the system ASP.
148 High Availability on the AS/400 System: A System Manager’s Guide
Figure 42. Mirrored protection and device parity protection to protect the system ASP
B.2 Mirrored protection in the system ASP and device parity protection in the user
ASPs
You should consider device parity protection if you have mirrored protection in the
system ASP and are going to create user ASPs. The system can tolerate a failure
in one of the disk units in a user ASP. The failure can be repaired while the
system continues to run. Figure 43 shows an example of a system ASP with
device parity.
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 3
Unit 2 Unit 2 Unit 4 Unit 4
Unit 5
Unit 1
Unit 6
Unit 7
Unit 8
6602 9336 9336
6602 6602 9336 9336
9337
Unit 13
Unit 14
Unit 15
Unit 16
Unit 17
6603
Unit 9
Unit 10
Unit 11
Unit 12
9337
Planning for device parity protection 149
Figure 43. Mirrored protection in the system ASP and device parity protection in the user ASPs
B.2.1 Mirrored protection and device parity protection in all ASPs
If you have all ASPs protected with mirrored protection, to add units to the
existing ASPs, also consider using device parity protection. The system can
tolerate a failure in one of the disk units with device parity protection. The failed
unit can be repaired while the system continues to run.
If a failure occurs on a disk unit that has mirrored protection, the system
continues to run using the operational unit of the mirrored pair. Figure 44 on page
150 shows an example of mirrored protection and device parity protection in all
ASPs.
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 3
Unit 2 Unit 2 Unit 4 Unit 4
Unit 5
Unit 1
Unit 6
Unit 7
Unit 8
6602 9336 9336
6602 6602 9336 9336
9337
Unit 9
Unit 10
Unit 11
Unit 12
9337
User ASP 2
Unit 13
Unit 14
Unit 15
Unit 16
Unit 17
6603
User ASP 3
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
150 High Availability on the AS/400 System: A System Manager’s Guide
Figure 44. Mirrored protection and device parity protection in all ASPs
B.2.2 Disk controller and the write-assist device
The disk controller for the subsystems with device parity protection performs an
important function for write operations. The controller keeps a list of all
uncommitted data written to the write-assist device that has not been written to
the data disk or the parity disk. Use this list during a power failure on the AS/400
system.
Write requests and the write-assist device
A write request to the subsystems with device parity protection starts three write
operations. Data to be written to the disk units is first stored in the buffer in the
disk controller. From this buffer, the data is sent to the write-assist device, the
data disk, and the parity disk.
The following actions occur during a write request:
1. A write operation to the write-assist device:
Data is written to the write-assist device sequentially. A write operation to the
write-assist device does not require parity calculation.
The disk controller (identifier and disk address) adds the header information.
Trailing information is added for the data before writing to the write-assist
device. The header information can be used during a power failure.
Normally, the write operations to the write-assist device are completed before
the write operations to the disk units. The disk controller sends a completion
message to storage management that allows the application to continue. The
System ASP
Load Source
6602
Unit 1 Unit 1 Unit 3 Unit 3
Unit 2 Unit 2 Unit 4 Unit 4
Unit 5
Unit 1
Unit 6
Unit 7
Unit 8
6602 9336 9336
6602 6602 9336 9336
9337
Unit 9
Unit 9
Unit 10
Unit 10
Unit 11
Unit 12
Unit 13
Unit 14
Unit 15
9337 6603
User ASP 2
Legend
Unit n - Unit n = Mirrored pair
Unit n Unit protected by device
parity protection
Planning for device parity protection 151
data that is written on the write-assist device is marked as uncommitted on the
disk controller.
Note: The write operation to the data disk and the parity disk continues in the
background until the data is successfully written and is marked as committed
in the disk controller.
2. A write operation to the disk unit.
• For data, the operation:
– Reads the original data
– Writes the new data
• For parity data, the operation:
– Reads the original parity information
– Compares the new data with the original data and the original parity to
calculate the new parity
– Writes the new parity information
The write operation to the data disk usually completes before the write
operation to the parity disk. The write operation to the data disk does not have
to wait for the parity calculation. The delay between the writing of new data
and the writing of the new parity information is known as delayed parity.
3. Data is marked as committed data when it is successfully written to both the
data disk unit and the parity disk unit.
4. A completion message is sent to storage management only if the write
operation on the write-assist device or the data disk unit has not already sent
a message.
The performance for this type of write operation depends on disk contention and
the time that is needed to calculate the parity information.
B.2.3 Mirrored protection: How it works
Since mirrored protection is configured by ASP, all ASPs must be mirrored to
provide for maximum system availability. If a disk unit fails in an ASP that is not
mirrored, the system can’t be used until the disk unit is repaired or replaced.
The start mirrored pairing algorithm automatically selects a mirrored configuration
to provide the maximum protection at the bus, I/O processor, or controller level
for the hardware configuration of the system. When storage units of a mirrored
pair are on separate buses, they have maximum independence or protection.
Because they do not share any resource at the bus, I/O processor, or controller
levels, a failure in one of these hardware components allows the other mirrored
unit to continue operating.
Any data written to a unit that is mirrored is written to both storage units of the
mirrored pair. When data is read from a unit that is mirrored, the read operation
can be from either storage unit of the mirrored pair. Because it is transparent to
the user, they don’t know from which mirrored unit the data is being read. The
user is also not aware of the existence of two physical copies of the data.
If one storage unit of a mirrored pair fails, the system suspends mirrored
protection to the failed mirrored unit. The system continues to operate using the
152 High Availability on the AS/400 System: A System Manager’s Guide
remaining mirrored unit. The failing mirrored unit can be physically repaired or
replaced.
After the failed mirrored unit is repaired or replaced, the system synchronizes the
mirrored pair by copying current data from the storage unit that has remained
operational to the other storage unit. During synchronization, the mirrored unit to
which the information is being copied is in the resuming state. Synchronization
does not require a dedicated system and runs concurrently with other jobs on the
system. System performance is affected during synchronization. When
synchronization is complete, the mirrored unit becomes active.
© Copyright IBM Corp. 2001 153
Appendix C. Batch Journal Caching for AS/400 boosts performance
In the year 2000, a Programming Request for Price Quotation (PRPQ) offering
became available to improve the performance of an AS/400e system when
journals are involved. It is known as Batch Journal Caching for AS/400 PRPQ,
and the order number is 5799-BJC. It installs and runs correctly on any national
language version.
C.1 Overview
The Batch Journal Caching for AS/400 PRPQ can provide a significant
performance improvement for batch environments that use journaling. Benefits
include:
• It changes the handling of disk writes to achieve the maximum performance
for journaled database operations.
• By caching journal writes in main memory, it can greatly reduce the impact of
journaling on batch run time by eliminating the delay in waiting for each journal
entry to be written to disk.
This PRPQ is an ideal solution for customers with batch workloads who use
journaling as part of a high availability solution to replicate database changes to a
backup system.
C.2 Benefits of the Batch Journal Caching PRPQ
Applications that perform large numbers of database add, update, or delete
operations should experience the greatest improvement when this PRPQ is
active. Although it is directed primarily toward batch jobs, some interactive
applications may also benefit. Applications using commitment control should see
less improvement because commitment control already performs some journal
caching.
With traditional non-cached journaling in a batch environment, each database
record added, updated, or deleted by the batch job causes a new journal entry to
be constructed in main memory. The batch job then waits for each new journal
entry to be written to disk to assure recovery. This results in a large number of
disk writes.
The Batch Journal Caching PRPQ provides the ability to selectively enable a new
variation of journal caching. It changes the handling of disk writes to achieve the
maximum performance for journaled database operations. Both the journal
entries and the corresponding database records are cached in main memory,
thereby delaying writing journal entries to disk until an efficient disk write can be
scheduled. This prevents most database operations from being held up while
waiting for the synchronous write of journal entries to disk.
By more aggressively caching journal writes in main memory, it can:
• Greatly reduce the impact of journaling on batch run time by reducing the
delay in waiting for each journal entry to be written to disk.
154 High Availability on the AS/400 System: A System Manager’s Guide
• Avoid the problems and costs associated with making application changes
(such as adding commitment control) to improve batch performance in these
environments.
C.2.1 Optimal journal performance
For optimal journal performance, many factors beyond using this PRPQ should
be considered, including:
• The number and type of disk units and disk controllers
• Amount of write cache
• Placement of journal receivers in user auxiliary storage pools (ASPs)
• Application changes
C.3 Installation considerations
The prerequisites and limitations of the Batch Journal Cache PRPQ are identified
here.
C.3.1 Prerequisites
This PRPQ runs under the latest levels of operating system. Install either:
• OS/400 V4R5 with PTFs MF24863, MF24866, MF24870, and SF63192
• OS/400 V4R4 with PTFs MF24293, MF24626, and SF63186
C.3.2 Limitations
This batch cache type of journaling differs from traditional journaling and can
affect the recover ability of the associated database files. Because journal entries
are temporarily cached in main memory, a few recent database changes that are
still cached and not yet written to disk can be lost in the rare event of a severe
system failure where the contents of main memory are not preserved.
This type of journaling may not be suitable for interactive applications where
single system recovery is the primary reason for using journaling. Also, it may not
be suitable where it is unacceptable to lose even one recent database change in
the rare event of a system failure in which the contents of main memory are not
preserved.
Batch journal caching is primarily intended for situations where journaling is used
to enable database replication to a second system (for example, for high
availability or Business Intelligence applications) under a heavy workload like
batch processing. This also applies to heavy interactive work with applications
that do not employ commitment control. This function can also be selectively
enabled to optimize performance when running nightly batch workloads. It can
then disabled each morning to optimize recoverability when running interactive
applications. This can speed up some nightly batch jobs without sacrificing robust
recovery for daytime interactive work.
C.3.3 For more information
After installing the PRPQ software product, read the README member of the
README AS/400 file in the QBJC library for instructions on this product. Use
DSPPFM FILE(QBJC/README) MBR(README) to display the file.
For further information, contact your IBM marketing representative.
© Copyright IBM Corp. 2001 155
Appendix D. Sample program to calculate journal size requirement
D.1 ESTJRNSIZ CL program
esj1: pgm
dclf estjrnsiz/lastipl
call qwccrtec /* retrieve last IPL information */
CPYSPLF FILE(QPSRVDMP) TOFILE(ESTJRNSIZ/LASTIPL)
DLTSPLF FILE(QPSRVDMP)
loop: rcvf
monmsg msgid(CPF0864) exec(goto cmdlbl(endit))
if (%sst(&lastipl 103 17) *ne ’ ’) +
then(chgdtaara lastipl %sst(&lastipl 103 17))
goto loop
endit: call pfildtl
endpgm
D.2 NJPFILS RPGLE program
FQPRINT O F 132 PRINTER OFLIND(*INOF) USROPN
FPFILRPT O E Printer OFLIND(*IN90)
D* Include error code parameter
D/COPY QSYSINC/QRPGLESRC,QUSEC
Dlstlib s 10A
Dlstfil s 10A
Dipltim s z
Dtimipl ds
D ccipl 2A
D yyipl 2A
D sep1 1A INZ(’-’)
D mmipl 2A
D sep2 1A INZ(’-’)
D ddipl 2A
D sep3 1A INZ(’-’)
D hhipl 2A
D sep4 1A INZ(’.’)
D nnipl 2A
D sep5 1A INZ(’.’)
D ssipl 2A
D sep6 1A INZ(’.’)
D msipl 6A INZ(’000000’)
Dlastipl ds
D iplmo 1 2A
D iplda 4 5A
D iplyr 7 8A
D iplhr 10 11A
D iplmi 13 14A
D iplse 16 17A
Dtimestamp s z INZ(*SYS)
Dqmbrovr s 1A
Dqmbrfmt s 8A
Dqmbrdovr s 9B 0 INZ(4096)
Dnummbrs s 4B 0
Dnumobjs s 4B 0
Dobjtolist s 20 INZ(’*ALL *ALLUSR ’)
DFIRST_ERR S 1 INZ(’0’)
Dobj_count s 9 0 INZ(1)
Dmbr_count s 9 0 INZ(1)
Dobjspcnam s 20A INZ(’OBJECTS ESTJRNSIZ ’)
Dmbrspcnam s 20A INZ(’MEMBERS ESTJRNSIZ ’)
Dext_attr s 10A
Dspc_name s 20A
Dspc_size s 9B 0 INZ(1)
Dspc_init s 1 INZ(x’00’)
Dobjlstptr s *
Dmbrlstptr s *
Dobjspcptr s *
Dmbrspcptr s *
DARR s 1 BASED(objlstptr) DIM(32767)
DRCVVAR s 8
DRCVVARSIZ s 9B 0 INZ(8)
DARRm s 1 BASED(mbrlstptr) DIM(32767)
DRCVVARm s 8
156 High Availability on the AS/400 System: A System Manager’s Guide
DRCVVARSIZm s 9B 0 INZ(8)
D* Common list header
DOUSH0100 DS BASED(OBJSPCPTR)
D OUSUA 1 64 User area
D OUSSGH 65 68B 0 Size generic header
D OUSSRL 69 72 Structure rel level
D OUSFN 73 80 Format name
D OUSAU 81 90 API used
D OUSDTC 91 103 Date time created
D OUSIS 104 104 Information status
D OUSSUS 105 108B 0 Size user space
D OUSOIP 109 112B 0 Offset input parm
D OUSSIP 113 116B 0 Size input parm
D OUSOHS 117 120B 0 Offset header secti
D OUSSHS 121 124B 0 Size header section
D OUSOLD 125 128B 0 Offset list data
D OUSSLD 129 132B 0 Size list data
D OUSNBRLE 133 136B 0 Number list entries
D OUSSEE 137 140B 0 Size each entry
D OUSSIDLE 141 144B 0 CCSID list ent
D QUSCID 145 146 Country ID
D OUSLID 147 149 Language ID
D OUSSLI 150 150 Subset list indicat
D OUSERVED00 151 192 Reserved
D* Common list header
DMUSH0100 DS BASED(MBRSPCPTR)
D MUSUA 1 64 User area
D MUSSGH 65 68B 0 Size generic header
D MUSSRL 69 72 Structure rel level
D MUSFN 73 80 Format name
D MUSAU 81 90 API used
D MUSDTC 91 103 Date time created
D MUSIS 104 104 Information status
D MUSSUS 105 108B 0 Size user space
D MUSOIP 109 112B 0 Offset input parm
D MUSSIP 113 116B 0 Size input parm
D MUSOHS 117 120B 0 Offset header secti
D MUSSHS 121 124B 0 Size header section
D MUSOLD 125 128B 0 Offset list data
D MUSSLD 129 132B 0 Size list data
D MUSNBRLE 133 136B 0 Number list entries
D MUSSEE 137 140B 0 Size each entry
D MUSSIDLE 141 144B 0 CCSID list ent
D MUSCID 145 146 Country ID
D MUSLID 147 149 Language ID
D MUSSLI 150 150 Subset list indicat
D MUSERVED00 151 192 Reserved
D* Structure for OBJL0200
DQUSL020002 DS BASED(objlstptr)
D QUSOBJNU00 1 10 Object name used
D QUSOLNU00 11 20 Object lib name use
D QUSOBJTU00 21 30 Object type used
D QUSIS01 31 31 Information status
D QUSEOA 32 41 Extended object attr
D QUSTD06 42 91 Text description
D QUSUDA 92 101 User defined attr
D QUSERVED22 102 108 Reserved
D* File Definition Template (FDT) Header
D* This section is always located at the beginning of the returned data.
DQDBQ25 DS 4096 Header info
D QDBFYRET 1 4B 0 Bytes returned
D QDBFYAVL 5 8B 0 Bytes available
D*QDBFHFLG 2
D QDBBITS27 9 10 Attribute bytes
D QDBBITS1 9 9
D* QDBRSV100 2 BITS
D* QDBFHFPL00 1 BIT
D* QDBRSV200 1 BIT
D* QDBFHFSU00 1 BIT
D* QDBRSV300 1 BIT
D* QDBFHFKY00 1 BIT
D* QDBRSV400 1 BIT
D* QDBFHFLC00 1 BIT
D* QDBFKFSO00 1 BIT
D* QDBRSV500 1 BIT
D* QDBFHSHR00 1 BIT
D* QDBRSV600 2 BITS
D* QDBFIGCD00 1 BIT
Sample program to calculate journal size requirement 157
D* QDBFIGCL00 1 BIT
D QDBRSV7 11 14 reserved
D QDBLBNUM 15 16B 0 # data members
D*QDBFKDAT 14
D QDBFKNUM00 17 18B 0
D QDBFKMXL00 19 20B 0
D* QDBFKFLG00 1
D QDBBITS28 21 21
D* QDBRSV802 1 BIT
D* QDBFKFCS02 1 BIT
D* QDBRSV902 4 BITS
D* QDBFKFRC02 1 BIT
D* QDBFKFLT02 1 BIT
D QDBFKFDM00 22 22
D QDBRSV1000 23 30 keyed seq ap
D QDBFHAUT 31 40 public aut
D QDBFHUPL 41 41 pref storage unit
D QDBFHMXM 42 43B 0 max members
D* Maximum Members (MAXMBRS)
D QDBFWTFI 44 45B 0 max file wait time
D QDBFHFRT 46 47B 0 FRCRATION
D QDBHMNUM 48 49B 0 # members
D QDBRSV11 50 58 reserved
D* Reserved.
D QDBFBRWT 59 60B 0 max recd wait time
D*QDBQAAF00 1
D QDBBITS29 61 61 add’l attrib flags
D* QDBRSV1200 7 BITS
D* QDBFPGMD00 1 BIT
D QDBMTNUM 62 63B 0 tot # recd fmts
D*QDBFHFL2 2
D QDBBITS30 64 65 add’l attrib flags
D* QDBFJNAP00 1 BIT
D* QDBRSV1300 1 BIT
D* QDBFRDCP00 1 BIT
D* QDBFWTCP00 1 BIT
D* QDBFUPCP00 1 BIT
D* QDBFDLCP00 1 BIT
D* QDBRSV1400 9 BITS
D* QDBFKFND00 1 BIT
D QDBFVRM 66 67B 0 1st supported VRM
D QDBBITS31 68 69 add’l attrib flags
D* QDBFHMCS00 1 BIT
D* QDBRSV1500 1 BIT
D* QDBFKNLL00 1 BIT
D* QDBFNFLD00 1 BIT
D* QDBFVFLD00 1 BIT
D* QDBFTFLD00 1 BIT
D* QDBFGRPH00 1 BIT
D* QDBFPKEY00 1 BIT
D* QDBFUNQC00 1 BIT
D* QDBR11800 2 BITS
D* QDBFAPSZ00 1 BIT
D* QDBFDISF00 1 BIT
D* QDBR11900 3 BITS
D QDBFHCRT 70 82 file level indicato
D QDBRSV1800 83 84
D QDBFHTXT00 85 134 file text descript
D QDBRSV19 135 147 reserved
D*QDBFSRC 30
D QDBFSRCF00 148 157
D QDBFSRCM00 158 167
D QDBFSRCL00 168 177 source file fields
D* Source File Fields
D QDBFKRCV 178 178 access path recover
D QDBRSV20 179 201 reserved
D QDBFTCID 202 203B 0 CCSID
D QDBFASP 204 205 ASP
D* X’0000’ = The file is located in the system ASP
D* X’0002’-X’0010’ = The user ASP the file is located in.
D QDBBITS71 206 206 complex obj flags
D* QDBFHUDT00 1 BIT
D* QDBFHLOB00 1 BIT
D* QDBFHDTL00 1 BIT
D* QDBFHUDF00 1 BIT
D* QDBFHLON00 1 BIT
D* QDBFHLOP00 1 BIT
D* QDBFHDLL00 1 BIT
158 High Availability on the AS/400 System: A System Manager’s Guide
D* QDBRSV2101 1 BIT
D QDBXFNUM 207 208B 0 max # fields
D QDBRSV22 209 284 reserved
D QDBFODIC 285 288B 0 offset to IDDU/SQL
D QDBRSV23 289 302 reserved
D QDBFFIGL 303 304B 0 file generic key
D QDBFMXRL 305 306I 0 max record len
D FMXRL1 305 305A
D QDBRSV24 307 314 reserved
D QDBFGKCT 315 316B 0 file generic key
D field count
D QDBFOS 317 320B 0 offset to file scop
D array
D QDBRSV25 321 328 reserved
D QDBFOCS 329 332B 0 offset to alternate
D collating sequence
D table
D QDBRSV26 333 336 reserved
D QDBFPACT 337 338 access path type
D QDBFHRLS 339 344 file version/releas
D QDBRSV27 345 364 reserved
D QDBPFOF 365 368B 0 offset to pf speciD
fic attrib section
D QDBLFOF 369 372B 0 offset to LF speciD
fic attrib section
D QDBBITS58 373 373
D* QDBFSSCS02 3 BITS
D* QDBR10302 5 BITS
D QDBFLANG01 374 376
D QDBFCNTY01 377 378 sort sequence table
D QDBFJORN 379 382B 0 offset to jrn
D section
D* Journal Section, Qdbfjoal.
D QDBFEVID 383 386B 0 initial # distinct
D values an encoded
D vector AP allowed
D QDBRSV28 387 400 reserved
D*The FDT header ends here.
D*Journal Section
D*This section can be located with the offset Qdbfjorn, which is located in the FDT heade
DQDBQ40 DS jrn section
D QDBFOJRN 1 10 jrn nam
D QDBFOLIB 11 20 jrn lib nam
D*QDBFOJPT 1
D QDBBITS41 21 21 jrn options flags
D* QDBR10600 1 BIT
D* QDBFJBIM00 1 BIT
D* QDBFJAIM00 1 BIT
D* QDBR10700 1 BIT
D* QDBFJOMT00 1 BIT
D* QDBR10800 3 BITS
D QDBFJACT 22 22 jrn options
D* ’0’ = The file is not being journaled
D* ’1’ = The file is being journaled
D QDBFLJRN 23 35 last jrn-ing date
D QDBR105 36 64 reserved
D* Structures for QDBRTVFD
D* Input structure for QDBRTVFD API header section
DQDBRIP DS Qdb Rfd Input Parms
D*QDBRV 1 1 varying length
D QDBLORV 2 5B 0 Len. o rcvr var
D QDBRFAL 6 25 Ret’d file & lib
D QDBFN00 26 33 Format name
D QDBFALN 34 53 File & lib name
D QDBRFN00 54 63 Recd fmt name
D QDBFILOF 64 64 File override flag
D QDBYSTEM 65 74 System
D QDBFT 75 84 Format type
D*QDBEC 85 85 varying length
D* Retrieve member information structure
D*Type Definition for the MBRL0100 format of the userspace in the QUSLMBR API
DQUSL010000 DS BASED(mbrlstptr)
D QUSMN00 1 10 Member name
D*Record structure for QUSRMBRD MBRD0200 format
DQUSM0200 DS 4096
D QUSBRTN03 1 4B 0 Bytes Returned
D QUSBAVL04 5 8B 0 Bytes Available
D QUSDFILN00 9 18 Db File Name
Sample program to calculate journal size requirement 159
D QUSDFILL00 19 28 Db File Lib
D QUSMN03 29 38 Member Name
D QUSFILA01 39 48 File Attr
D QUSST01 49 58 Src Type
D QUSCD03 59 71 Crt Date
D QUSSCD 72 84 Src Change Date
D QUSTD04 85 134 Text Desc
D QUSSFIL01 135 135 Src File
D QUSEFIL 136 136 Ext File
D QUSLFIL 137 137 Log File
D QUSOS 138 138 Odp Share
D QUSERVED12 139 140 Reserved
D QUSNBRCR 141 144B 0 Num Cur Rec
D QUSNBRDR 145 148B 0 Num Dlt Rec
D QUSDSS 149 152B 0 Dat Spc Size
D QUSAPS 153 156B 0 Acc Pth Size
D QUSNBRDM 157 160B 0 Num Dat Mbr
D QUSCD04 161 173 Change Date
D QUSSD 174 186 Save Date
D QUSRD 187 199 Rest Date
D QUSED 200 212 Exp Date
D QUSNDU 213 216B 0 Nbr Days Used
D QUSDLU 217 223 Date Lst Used
D QUSURD 224 230 Use Reset Date
D QUSRSV101 231 232 Reserved1
D QUSDSSM 233 236B 0 Data Spc Sz Mlt
D QUSAPSM 237 240B 0 Acc Pth Sz Mlt
D QUSMTC 241 244B 0 Member Text Ccsid
D QUSOAI 245 248B 0 Offset Add Info
D QUSLAI 249 252B 0 Length Add Info
D QUSNCRU 253 256U 0 Num Cur Rec U
D QUSNDRU 257 260U 0 Num Dlt Rec U
D QUSRSV203 261 266 Reserved2
D* Record structure for data space activity statistics
DQUSQD DS
D QUSNBRAO 1 8I 0 Num Act Ops
D QUSNBRDO 9 16I 0 Num Deact Ops
D QUSNBRIO 17 24I 0 Num Ins Ops
D QUSNBRUO 25 32I 0 Num Upd Ops
D QUSNBRDO00 33 40I 0 Num Del Ops
D QUSNBRRO00 41 48I 0 Num Reset Ops
D QUSNBRCO 49 56I 0 Num Cpy Ops
D QUSNBRRO01 57 64I 0 Num Reorg Ops
D QUSNAPBO 65 72I 0 Num APBld Ops
D QUSNBRLO 73 80I 0 Num Lrd Ops
D QUSNBRPO 81 88I 0 Num Prd Ops
D QUSNBRRK 89 96I 0 Num Rej Ksel
D QUSNRNK 97 104I 0 Num Rej NKsel
D QUSNRGB 105 112I 0 Num Rej Grp By
D QUSNBRIV 113 116U 0 Num Index Val
D QUSNBRII 117 120U 0 Num Index Ival
D QUSVDS 121 124U 0 Var Data Size
D QUSRSV107 125 192 Reserved 1
C* Set things up
C EXSR INIT
C* Start mainline process
C* set pointer to first object
C EVAL objlstptr = objspcptr pt to b1 of usrsp
C EVAL objlstptr = %addr(arr(OUSOLD + 1)) pt to entry 1
C EVAL numobjs = OUSNBRLE
C* process all entries
C DO numobjs
C EVAL libn = qusolnu00
C EVAL filn = QUSOBJNU00
C IF QUSEOA = ’PF ’ only PF types
C EVAL QDBFALN = filn + libn
C CALL ’QDBRTVFD’ get full details
C parm QDBQ25
C parm 4096 QDBLORV
C PARM QDBRFAL
C parm ’FILD0100’ QDBFN00
C parm QDBFALN
C parm ’*FIRST ’ QDBRFN00
C parm ’0’ QDBFILOF
C parm ’*LCL ’ QDBYSTEM
C parm ’*EXT ’ QDBFT
C parm QUSEC
C IF QUSBAVL > 0
160 High Availability on the AS/400 System: A System Manager’s Guide
C MOVEL ’QDBRTVFD’ APINAM 10
C EXSR APIERR
C END
C* Have FD info, test for SRC versus DTA
C testb ’4’ QDBBITS1 10 11 10 on = DTA
C* 11 on = SRC
C *in10 ifeq *on is a data file
C setoff 10
C* is the file already journaled?
C QDBFJORN ifgt 0
C* yes, get jrn info
C eval QDBQ40 = %SUBST ( QDBQ25
C : QDBFJORN + 1
C : %SIZE( QDBQ40 ))
C eval jrnnam = QDBFOJRN
C eval jrnlib = QDBFOLIB
C if QDBFJACT = ’0’
C eval jrnact = ’N’
C end
C if QDBFJACT = ’1’
C eval jrnact = ’Y’
C end
C else
C eval jrnnam = *blanks
C eval jrnlib = *blanks
C eval jrnact = ’ ’
C end
C* now get member list
C EVAL spc_name = mbrspcnam
C CALL ’QUSLMBR’
C parm spc_name
C parm ’MBRL0100’ mbr_fmt 8
C parm QDBFALN
C parm ’*ALL ’ mbr_nam 10
C parm ’0’ mbr_ovr 1
C parm QUSEC
C IF QUSBAVL > 0 Any errors?
C MOVEL ’QUSLMBR’ APINAM
C EXSR APIERR
C END
C* resolve pointer
C CALL ’QUSPTRUS’
C PARM SPC_NAME
C PARM MBRSPCPTR
C PARM QUSEC
C* Check for errors on QUSPTRUS
C QUSBAVL IFGT 0
C MOVEL ’QUSPTRUS’ APINAM 10
C EXSR APIERR
C END
C EVAL mbrlstptr = mbrspcptr
C EVAL mbrlstptr = %addr(arrm(MUSOLD + 1))
C EVAL nummbrs = MUSNBRLE
C DO nummbrs
C EVAL mbrn = QUSMN00
C EVAL QDBFALN = FILN + LIBN
C CALL ’QUSRMBRD’
C PARM QUSM0200
C PARM QMBRDOVR
C parm ’MBRD0200’ QMBRFMT
C parm QDBFALN
C parm QUSL010000
C parm ’0’ QMBROVR
C parm QUSEC
C IF QUSBAVL > 0
C MOVEL ’QUSRMBRD’ APINAM 10
C EXSR APIERR
C END
C eval QUSQD = %SUBST ( QUSM0200
C : QUSOAI + 1
C : QUSLAI )
C* have detail info, now create data
C eval rcdlen = qdbfmxrl
C* calc seconds since IPL
C timestamp subdur ipltim runsec:*S 10 0
C* calc ave ops per sec
C QUSNBRIO add QUSNBRUO rcdops
C eval rcdops = rcdops + QUSNBRDO
Sample program to calculate journal size requirement 161
C QUSNBRRO00 add QUSNBRRO01 mbrops
C rcdops IFGT 0
C mbrops ORGT 0
C rcdops div runsec avrrcdops
C mbrops div runsec avrmbrops
C avrrcdops add avrmbrops jrnsec
C rcdlen add 155 jrnsiz
C eval jrnsiz = (jrnsiz * jrnsec * 86400) / 1048576
C END
C EXSR dodetail
C eval avrrcdops = 0
C eval avrmbrops = 0
C eval jrnsec = 0
C eval jrnsiz = 0
C EVAL mbrlstptr = %addr(arrm(MUSSEE + 1)) incr to next ent
C END
C END
C END
C EVAL objlstptr = %addr(arr(OUSSEE + 1))
C END
C* End mainline process
C EXSR DONE
C* * * Subroutines follow * * *
C* INIT subroutine
C INIT BEGSR
C OPEN QPRINT
C exsr wrthead
C z-add 16 qusbprv set err code struct
C to omit exceptions
C* Does user space exist for OBJECT list?
C eval spc_name = objspcnam
C eval ext_attr = ’QUSLOBJ ’
C EXSR USRSPC
C* Does user space exist for MEMBER list?
C eval spc_name = mbrspcnam
C eval ext_attr = ’QUSLMBR ’
C EXSR USRSPC
C* Retrieve last IPL time derived from previous step
C *DTAARA DEFINE LASTIPL LASTIPL 17
C IN LASTIPL
C move iplyr yripl 2 0
C move iplyr yyipl
C move iplmo mmipl
C move iplda ddipl
C move iplhr hhipl
C move iplmi nnipl
C move iplse ssipl
C IF yripl > 88
C move ’19’ ccipl
C ELSE
C move ’20’ ccipl
C END
C MOVEL TIMIPL IPLTIM
C* Fill the user space with object list
C eval spc_name = objspcnam
C call ’QUSLOBJ’
C parm spc_name
C parm ’OBJL0200’ fmtnam 8
C parm objtolist
C parm ’*FILE ’ objtype 10
C parm QUSEC
C* Any errors?
C IF QUSBAVL > 0
C MOVEL ’QUSLOBJ’ APINAM
C EXSR APIERR
C END
C* Get a resolved pointer to the user space
C CALL ’QUSPTRUS’
C PARM SPC_NAME
C PARM OBJSPCPTR
C PARM QUSEC
C* Check for errors on QUSPTRUS
C QUSBAVL IFGT 0
C MOVEL ’QUSPTRUS’ APINAM 10
C EXSR APIERR
C END
C ENDSR
C*
162 High Availability on the AS/400 System: A System Manager’s Guide
C* USRSPC subroutine
C USRSPC BEGSR
C* Verify user space exists
C CALL ’QUSROBJD’
C PARM RCVVAR
C PARM RCVVARSIZ
C PARM ’OBJD0100’ ROBJD_FMT 8
C PARM SPC_NAME
C PARM ’*USRSPC’ SPC_TYPE 10
C PARM QUSEC
C* Errors on QUSROBJD?
C IF QUSBAVL > 0
C IF QUSEI = ’CPF9801’ user space not foun
C CALL ’QUSCRTUS’ create the space
C PARM SPC_NAME
C PARM EXT_ATTR 10
C PARM SPC_SIZE
C PARM SPC_INIT
C PARM ’*ALL’ SPC_AUT 10
C PARM *BLANKS SPC_TEXT 50
C PARM ’*YES’ SPC_REPLAC 10
C PARM QUSEC
C PARM ’*USER’ SPC_DOMAIN 10
C* Errors on QUSCRTUS?
C IF QUSBAVL > 0
C MOVEL ’QUSCRTUS’ APINAM 10
C EXSR APIERR
C END
C* else error occurred accessing the user space
C ELSE
C MOVEL ’QUSROBJD’ APINAM 10
C EXSR APIERR
C END
C END
C ENDSR
C* APIERR subroutine
C APIERR BEGSR
C* If first error found, then open QPRINT *PRTF
C IF NOT %OPEN(QPRINT)
C OPEN QPRINT
C ENDIF
C* Print the error and the API that received the error
C EXCEPT BAD_NEWS
C EXSR DONE
C ENDSR
C* DONE subroutine
C DONE BEGSR
C WRITE TTLSEP
C WRITE TTLS
C EVAL *INLR = ’1’
C RETURN
C ENDSR
C* WRTHEAD subroutine
C wrthead begsr
C WRITE AFT1
C WRITE AFT2
C WRITE AFT3
C WRITE AFT4
C ENDSR
C* DODETAIL subroutine
C DODETAIL BEGSR
C IF *IN90 = *ON
C EXSR WRTHEAD
C EVAL *IN90 = *OFF
C EVAL lstlib = *blanks
C END
C*
C IF LSTLIB <> LIBN
C WRITE AFMBR
C EVAL LSTLIB = LIBN
C GOTO GETOUT
C END
C IF LSTFIL <> FILN
C WRITE AFNOLIB
C EVAL LSTFIL = FILN
C goto GETOUT
C END
C WRITE AFNOFIL
Sample program to calculate journal size requirement 163
C GETOUT TAG
C add jrnsec tjrnsec
C add jrnsiz tjrnsiz
C ENDSR
OQPRINT E BAD_NEWS 1
O ’Failed in API ’
O APINAM
O ’with error ’
O QUSEI
D.3 Externally described printer file: PFILRPT
A*%%***********************************************************************
A*%%TS RD 20010115 123614 SMBAKER REL-V4R4M0 5769-PW1
A*%%FI+10660100000000000000000000000000000000000000000000000000
A*%%FI 0000000000000000000000000000000000000000000000000
A*%%***********************************************************************
A R AFT1
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SKIPB(001)
A SPACEA(001)
A 3
A DATE(*YY)
A EDTWRD(’0/ / ’)
A 86
A ’Journal size estimate’
A 170
A ’Page: ’
A +0
A PAGNBR
A*%%***********************************************************************
A*%%SS
A*%%CL 001
A*%%***********************************************************************
A R AFT2
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A 80
A ’---------Record---------’
A 107
A ’--------Member--------’
A 131
A ’-----Journal Estimate-----’
A*%%***********************************************************************
A*%%SS
A*%%***********************************************************************
A R AFT3
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A 42
A ’Record’
A +3
A ’----------Journal----------’
A 82
A ’Number of’
A 97
A ’Average’
A 107
A ’Number of’
A 122
A ’Average’
A 131
A ’Average ops’
A 151
A ’MB per’
A*%%***********************************************************************
A*%%SS
A*%%***********************************************************************
A R AFT4
A*%%***********************************************************************
164 High Availability on the AS/400 System: A System Manager’s Guide
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A SPACEA(001)
A 3
A ’Library’
A 16
A ’File’
A 29
A ’Member’
A 42
A ’Length’
A +3
A ’Name’
A +8
A ’Library’
A +5
A ’Act’
A 81
A ’Operations’
A 94
A ’per second’
A 107
A ’Operations’
A 119
A ’per second’
A 132
A ’per second’
A 154
A ’day’
A*%%***********************************************************************
A*%%SS
A*%%CL 001
A*%%***********************************************************************
A R AFMBR
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A LIBN 10A O 3
A FILN 10A O 16
A MBRN 10A O 29
A RCDLEN 5S 0O 43
A EDTCDE(3)
A JRNNAM 10A O +3
A JRNLIB 10A O +2
A JRNACT 1A O +3
A RCDOPS 11S 0O 80
A EDTCDE(3)
A AVRRCDOPS 7S 1O 96
A EDTCDE(3)
A MBROPS 10S 0O 107
A EDTCDE(3)
A AVRMBROPS 7S 1O 121
A EDTCDE(3)
A JRNSEC 11S 1O 131
A EDTCDE(3)
A JRNSIZ 10S 3O 146
A EDTCDE(3)
A*%%***********************************************************************
A*%%SS
A*%%SN JRNACT x
A*%%***********************************************************************
A R AFNOLIB
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A FILN 10A O 16
A MBRN 10A O 29
A RCDLEN 5S 0O 43
A EDTCDE(Z)
A JRNNAM 10A O +3
A JRNLIB 10A O +2
A JRNACT 1A O +3
A RCDOPS 11S 0O 80
A EDTCDE(3)
A AVRRCDOPS 7S 1O 96
Sample program to calculate journal size requirement 165
A EDTCDE(3)
A MBROPS 10S 0O 107
A EDTCDE(3)
A AVRMBROPS 7S 1O 121
A EDTCDE(3)
A JRNSEC 11S 1O 131
A EDTCDE(3)
A JRNSIZ 10S 3O 146
A EDTCDE(3)
A*%%***********************************************************************
A*%%SS
A*%%SN JRNACT x
A*%%***********************************************************************
A R AFNOFIL
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A MBRN 10A O 29
A RCDLEN 5S 0O 43
A EDTCDE(Z)
A JRNNAM 10A O +3
A JRNLIB 10A O +2
A JRNACT 1A O +3
A RCDOPS 11S 0O 80
A EDTCDE(3)
A AVRRCDOPS 7S 1O 96
A EDTCDE(3)
A MBROPS 10S 0O 107
A EDTCDE(3)
A AVRMBROPS 7S 1O 121
A EDTCDE(3)
A JRNSEC 11S 1O 131
A EDTCDE(3)
A JRNSIZ 10S 3O 146
A EDTCDE(3)
A*%%***********************************************************************
A*%%SS
A*%%SN JRNACT x
A*%%***********************************************************************
A R TTLSEP
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A 129
A ’--------------’
A 146
A ’-----------’
A*%%***********************************************************************
A*%%SS
A*%%***********************************************************************
A R TTLS
A*%%***********************************************************************
A*%%RI 00000
A*%%***********************************************************************
A SPACEB(001)
A TJRNSEC 11S 1O 131
A EDTCDE(3)
A TJRNSIZ 10S 3O 146
A EDTCDE(3)
A*%%***********************************************************************
A*%%SS
A*%%CP+999CRTPRTF
A*%%CP+ FILE(ESTJRNSIZ/PFILRPT)
A*%%CP+ DEVTYPE(*SCS)
A*%%CP PAGESIZE(*N 192 *N )
A*%%CS+999CRTPRTF
A*%%CS+ FILE(QTEMP/QPRDRPT )
A*%%CS+ DEVTYPE(*SCS)
A*%%CS PAGESIZE(*N 132 *N )
A*%%***********************************************************************
166 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 167
Appendix E. Comparing availability options
This appendix can help you compare availability options so that you can make
decisions about what to protect and how. Journaling, mirroring, and device parity
protection are compared by the extent of data loss, recovery time, and
performance impact. Recovery time by failure type, and availability options by
failure type are identified.
E.1 Journaling, mirroring, and device parity protection
Table 4 compares several important attributes of journaling physical files,
mirrored protection, and device parity protection, including how they affect
performance, the extent of loss, and recovery time.
Table 4. Journaling physical files, mirrored protection, and device parity attribute comparison
E.2 Availability options by time to recover
Table 5 shows which availability options can reduce the time needed to recover
from a failure. The number of plus (+) signs in a column indicates an option’s
impact on the time to recover compared to the other options. An option with more
pluses has greater relative impact.
Table 5. Availability options by time to recover
Attribute Physical file
journaling
Mirrored
protection
Device parity
protection
Data loss after a
single disk failure
Loss of file data is
determined by
currency of backup
None None
Recovery time after
a single disk unit
failure
Potentially many
hours
None to a few hours None to a few hours
Performance impact Minimal to
significant
Minimal, except
some read
operations improve
Minimal, except
restore operations
degrade
Option DASD System Power loss Program
failure
Site
loss
Save operation + + + + +
Journal files ++ ++ ++ +
Access path
protection
++ ++ ++
UPS +++
User ASPs ++
Device parity
protection
+++
Mirrored protection +++
Dual systems +++ + ++
168 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 169
Appendix F. Cost components of a business case
Creating an accurate business case for some IT applications is not trivial. This is
certainly the case when justifying a high availability solution. Many of the benefits
provided by high availability are intangible.
To help you create a business case for improving the availability of an application,
this appendix provides a list of costs (both for providing availability and those
associated with outages) that can be used as part of that business case.
Without a detailed study of your business, it is difficult to know whether an outage
in your company will have a similar impact. Use this appendix as a guideline to
justify the need for further study.
F.1 Costs of availability
The costs for providing an improvement in high availability are very intangible.
The value of availability is much harder to ascertain. One of the first steps is to
study the current availability statistics and understand which objective to improve.
It is conceivable that a single faulty component, such as a local display, creates
an invalid perception that the availability problem is within an application.
Review sources of information, such as problem management reports, system
logs, operator logs, and so on, to identify the outages over the past year. Verify
this list with the application owner to ensure that you both have the same
perception of the current availability.
Next, identify and categorize the root cause for every outage, both planned and
unplanned. From this list, identify the items with the highest impact on availability.
It is only when you understand what is causing the application to be unavailable
at a given moment that you can effectively create a plan to improve that area.
Use this information to identify which causes of outages must be addressed to
gain the availability improvement you desire.
The plan is likely to include some change in processes, and it may also involve
hardware and software changes.
The following sections provide information on some of the contributing factors for
costs.
F.1.1 Hardware costs
A component failure impact analysis can be done to identify the single point of
failure and the components that, if lost, would have a serious impact on the
application availability. The only way to provide continuous operations is to have
redundancy for all critical components.
Take the result of that study and discuss the results with the sponsors. There may
be some identified components that are addressed as an expected upgrade
process. Size and price the remaining components. At a minimum, consider the
console hardware component.
170 High Availability on the AS/400 System: A System Manager’s Guide
F.1.2 Software
Just as redundant hardware is required to provide for continuous operations,
redundant software is also required. Additional licenses of some programs may
be required.
Does the current application need to be updated to support the high availability
solution? Is this the time to add this application to help manage operations and
availability? Are additional licenses required? When evaluating costs, consider:
• Application change control
• Change and problem management
• Utilities
F.2 Value of availability
The value of availability (or the cost of unavailability) is more difficult than arriving
at the cost or providing that availability. For example, if you lose a network
controller, what is the cost impact of the loss? This depends on many things:
• Which applications do the users in the affected area use?
If the application developers access a test system, the cost will be lower.
• Which shift did the outage occur? What time?
• How long did it take to recover?
• How do you report availability?
F.2.1 Lost business
The amount of business lost because of an outage can vary from individual
transactions, to the actual loss of a customer.
If the amount of business transacted by your application is consistent, compare
the average value of business with the amount of business transacted on the day
an application outage occurred.
It is difficult to tie the loss of a customer to an application outage. If you have a
relatively small number of high-value customers, you probably have a close
relationship with them and they may make you aware of why they moved their
business elsewhere.
If you are in the retail industry, it is unlikely that you can produce a definite figure
for the number of customers lost due to application unavailability. One possible
method, however, is to follow a series of application outages and determine if it
was followed by a trend in the amount of repeat business.
Either of these analysis methods require working with the application owner to
obtain and record the required information.
It is likely that a single outage may result in lost transactions, where a series of
outages may result in lost customers. Therefore, the cost of each outage is also
impacted by the frequency of outages.
Cost components of a business case 171
F.3 Image and publicity
As businesses become more computerized and visible on the Internet, electronic
links between supplies and customers are becoming a standard. The availability
of applications becomes more visible to those outside the company. With a click
of the mouse, customers can go on to another source for their goods or services.
Recurring application outages are known quickly by customers (existing and
potential). This impacts your validity for winning new contracts or renewing
existing ones. Poor availability leads to bad publicity, which is very difficult to
rectify.
To make matters worse, potential customers can be anywhere in the world. You
should modify your view of the outage impact to reflect this.
It is nearly impossible to assess the cost of poor publicity caused by poor
availability. If you have a public relations department, they may be aware of
existing negative publicity and should have some idea of the cost to improve the
public perception of the company.
F.4 Fines and penalties
Fines and penalties imposed as a result of application unavailability is an
objective number to obtain. In some industries, application availability is
monitored by controlling bodies. Companies are expected to maintain a certain
level of availability, for example, the airline industry. There are also moves within
the financial world to encourage companies to maintain high levels of availability.
Extended outages can lead to fines from the governing bodies.
F.5 Staff costs
There may be significant staff costs both during and after an outage. Depending
on the application affected, prolonged outages can have a significant financial
cost in lost productivity. For example, for an application controlling a factory
production line, there could be many people sitting around not able to do their
job. Overtime may need to be paid to catch up on target productivity.
Identify the users of a given application, estimate the impact of an application
outage on those people, and then multiply by their average salary per hour to
provide a rough idea of the cost in terms of lost productivity. Factor in the
overtime rate if lost productivity is made up by overtime to give a rough recovery
cost.
Add the cost of the IT staff involved in recovering from the outage, and factor in
any additional availability hours that may be required by the end users to catch up
on their work.
F.6 Impact on business decisions
Depending on the type of application, the cost of an application outage varies
considerably. This depends on how timely the information must be and the type of
data involved. The loss of a business intelligence application varies from very
172 High Availability on the AS/400 System: A System Manager’s Guide
small to very large. For order processing in a factory working on just-in-time, the
impact can be significant. If items are not ordered in time, the whole factory could
halt production due to the lack of one key component.
Work with the application owners to identify the impact of the application
unavailability for a given amount of time. Identify both a worst and best case
scenario, and cost of reach. Then, agree on realistic average cost.
F.7 Source of information
To obtain some data to help in these calculations, check these sources:
• Application: If a business case was created for the application when it was
first developed, there may be some cost benefit estimates in that document
that are useful. Factor in the age of the document, however, to determine the
applicability of the figures.
• Disaster recovery: If your company has a disaster recovery agreement, it is
likely that a business case had to be presented in relation to that expenditure.
It should contain estimates of the impact of a system outage. Additionally,
when the business case includes the application or system level, use those
figures or extrapolate an idea of the financial cost of the loss of a given
application.
Speak to the developers of the disaster recovery business case to see where
they obtained the financial impact information used to build the case.
• Transaction values: Transactions for an average day can be recorded and
used to assess the impact of an outage for an application. Record the number
of transactions per day for each application. You can at least identify the
change in the number of transactions if an outage occurs. If you can agree on
an average value per transaction, this allows you to more readily estimate the
financial impact of lost transactions.
• Industry surveys: Data processing firms and consultants have produced
studies over the years, with example costs for outages. Their reports can
include a cost range per hour and an average cost per hour.
F.8 Summary
Every industry and every company has unique costs and requirements. Tangible
outage costs are only one part of the equation. You may be fortunate enough to
suffer no unplanned outages, and yet still require better application availability. To
maintain competitiveness, if your competitors are offering 24 x 7 online service,
you may have no choice but to move in that direction. This may be the case even
if there is currently not enough business outside the normal business hours to
justify the change by itself. Additional availability can give you access to a set of
customers you currently do not address (for example, people on shift work who
do their business in the middle of the night). Internet shopping introduces a
completely new pattern of consumer behavior. Previously, once a customer was
in your shop, they were more inclined to wait ten minutes for the system to come
back than to get back in the car and drive even minutes to your competitor. Now
shopping is done by clicking a computer mouse. If you have better availability
than your competitors, you have the opportunity to pick up customers from
competing sites while their system is down.
Cost components of a business case 173
Some retail outlets switch to a credit authorization business when the first
provider experiences any interruption. They switch to another provider once the
next interruption happens. If your systems have better availability, you have the
opportunity to pick up a competitor’s business when they experience an outage.
If your customer support systems are available 24 x 7, you have flexibility to have
fewer call center staff. Once your customers realize they can get service any
time, the trend tend to favor fewer calls during the day with more in the off-peak
hours. This allows you to reduce the number of operators required to answer the
volume of calls at a given time.
If you can spread the workload associated with serving your customers over a
longer period of time, the peak processing power required to service that
workload decreases. This can defer an additional expense to upgrade your
system.
Due to mergers or business growth, you may be required to support multiple time
zones. As the number of zones you support increases, the number and duration
of acceptable outage times rapidly decreases.
A successful full business case includes these considerations, and others that
are more specific to your company and circumstances. Most importantly, a
successful availability project requires total commitment on the part of
management and staff to work together towards a common goal.
174 High Availability on the AS/400 System: A System Manager’s Guide
© Copyright IBM Corp. 2001 175
Appendix G. End-to-end checklist
This chapter provides a guide to the tasks and considerations needed when
planning a new high availability solution. It is not a definitive list and looks
different for each customer, depending on the particular customer situation and
their business requirements. Use it as a guide to help you consider factors
influencing the success of a high availability solution.
Note: A service offering is available from IBM to examine and recommend
improvements for availability. Contact your IBM marketing representative for
further information.
G.1 Business plan
The investment in a high availability solution is considerable. It is critical that this
investment is reflected back to the Business Plan. This will ease the justification
of the solution, and in the process will display the value of the information
technology solution to the business.
Does a valid business plan exist?
• Tactical Plan
Do you have a tactical plan?
• Strategic Plan
Do you have a strategic plan?
G.1.1 Business operating hours
Define the current operating hours of all parts of the business, no matter how
insignificant. Suppliers and customers should also be included in this information.
How long can the customer business survive in the extent of a systems failure?
Describe the survivability of the various different parts of the business, and rank
their criticality.
• Business operating hours:
– Current normal operating hours
– Operating hours by application/geography
– Planned extensions to operating hours
– Extensions by application/geography
• Business processes:
Do business processes exist for the following areas:
– Information Systems Standards
– Geographic standards
– Centralized or local support
– Language
– Help desk
– Operating systems
– Applications
176 High Availability on the AS/400 System: A System Manager’s Guide
G.2 High availability project planning
Major points for a successful project plan are:
• Objective of the project: Prepare an accurate and simple definition of the
project and its goals.
• Scope of the project: Define the scope of the project. This definition will more
than likely be broken down to several major sub-projects.
• Resources: Are there sufficient resources to manage and facilitate the
project?
• Sponsorship: Is there an Executive Management sponsor for the project?
• Communication:
– Does the project have an effective communications media for the project?
– Communications to the business, sponsors, and customers
– Communications and collaboration of parties working on the project?
• Cost management:
– Is there a budget for the project?
– Has the budget been established based on cost of outage?
G.3 Resources
Soft resources are a critical success factor.
• Current skills: Do you have an accurate skills list? Do you have job
specifications for the current skills?
• Required skills: What skills are required for the new operation?
• Critical skills: Do all these skills exist? Do you have a job specification for all
critical skills?
• Skills retention:
– Vitality
Are existing resources encouraged to maintain their skills currency? Is
there a skills development plan for existing resources?
– Loss from the department
• Are you likely to lose resources as result of the project?
• Are these critical skills?
• Through lack of interest in new mode of operation?
• Through learning skills valuable outside the business?
G.4 Facilities
Are the facilities listed in this sections available?
• Testing the recovery plan
– Do you have tested recovery plan?
– Are there any activities planned during the project that could impact it
• Types of planned and unplanned activities?
End-to-end checklist 177
G.4.1 Power supply
Ask the following questions about your power supply:
• Reliability:
– Is the local power supply reliable?
– How many outages in the past year?
– How many weather related?
• Quality: Is the local power supply company committed to maintaining a quality
service?
• Power switchover: Do you require power switchover?
• UPS:
– Are there any UPSs in the installation?
– Do they qualify with the particular power supply options?
– Do they have the capacity to meet the new demands?
• Servers:
– Is a UPS required for the Servers?
– How many?
– What type (battery/generator)/size/duration of backup supply/location?
– Are the systems aware of power failure?
– Do programs need to be developed to allow the systems to reaction to
power failures?
• Clients:
– Do clients need to have UPS?
– What type (battery/generator)/size/duration of backup supply/location?
• Other equipment:
– Is there other equipment that needs UPS?
– Consoles/Printers/PABX/Network Devices/Machine facilities?
• Generated supply:
– Will you be running a generated backup?
– What configuration will be running?
– Local power - generated backup
– Generated power - local backup
G.4.2 Machine rooms
Ask the following questions regarding machine rooms.
• Flooring:
– What is the current standard for your machine room?
– Fully accessible or semi-accessible
• Fire Protection:
– What is the current fire protection method?
– Halon/Water/CO2
• Air-conditioning:
– Is the machine room air-conditioned?
– At what point will the equipment fail without air-conditioning?
– Will the machine room ever achieve this condition with-out air-conditioning?
178 High Availability on the AS/400 System: A System Manager’s Guide
– Is there spare capacity in the air-conditioning system?
– Is there redundancy in the current air-conditioning?
• Contracts:
– Do contracts and services levels exist for machine rooms?
– Do these need amending for the new system?
G.4.3 Office building
Ask the following questions regarding your office building:
• Workstations:
– Have the workstations been assessed for their ergonomic function?
– Will the changes to the current system effect your liability for your
employees ergonomics?
• Cabling systems:
– Does the facility have a structured cabling system?
– Will the existing cabling system accommodate the new system?
• PABX:
– Is the current PABX capable of operating in the new environment?
– Does the existing PABX have redundancy?
– Is redundancy in the PABX a requirement?
G.4.4 Multiple sites
Answer the following questions regarding multiple sites.
• Are there multiple local sites (within the same site)?
• Are any of the local sites located across a public space? (highway, area)
• Are any remote sites less than 2km away?
• Are any remote greater than 2km away?
• Are any sites across an international border?
• Do the remote sites have a different PTT?
G.5 Security
In this section, answer the following questions regarding security:
• Policy:
– Does a detailed security policy exist?
– Is there a site security function?
– Does this function set policy for I/T security?
• Physical security:
– Is access protection provided?
– Is there a documented process for dismissal employees?
– Does this process also limit risk to systems prior to dismissal?
• Office space: Is the office space protected?
End-to-end checklist 179
• Machine room:
– Is the machine room protected?
– Does the protection system provide an audit trail?
• Site:
– Does the site have physical security?
– Will the new system require this to be updated?
• Operating system security:
– Do the systems implement security?
– What level is implemented?
– What level is required?
– What applications at what level?
• AS/400 security levels:
– What level of AS/400 security is implemented?
– What level is required?
• Personal computer security:
– What forms of PC security have been implemented?
– Do these levels need changing?
• Remote users:
– What type of remote security has been implemented?
– How do remote users access the systems?
– Intranet?
– Internet?
• Network security: What network security is in place?
• Printing:
– Are there secure printing requirements?
– Are the printers producing secure output located in a controlled
environment?
G.6 Systems in current use
Document the model, processor feature, interactive feature, main storage, DASD
capacity, DASD arms, protection, and ASP.
G.6.1 Hardware inventory
Prepare the inventory list of the all the hardware components in your current
system, including:
• Processors
• DASD subsystems: DASD Space available
• Mirroring
• RAID-5
• Third Party solutions
180 High Availability on the AS/400 System: A System Manager’s Guide
• Tape subsystems
– Multiple tapes subsystems versus tape library
– Data transfer rate
• IOPs and Towers
G.6.2 Redundancy
What level on redundancy are you planning?
• System (cluster)
• Tower
• Bus
• I/O processor
• Controller
• Adapter
G.6.3 LPAR
• Are you planning to use LPAR support for the project?
• Transition support with LPAR?
• Server consolidation support with LPAR?
G.6.4 Backup strategy
Even with a continuously available solution backups are necessary. Is there a
new backup strategy in plan?
Does this plan include the following components?
• Media Management
• Media storage
• Automated backup
• Performance
• Save-while-active
• Incremental backups
• Disaster recovery backup
G.6.5 Operating systems version by system in use
• Interactive CPU, batch CPU, DASD utilization, network utilization LAN/WAN.
• Are there multiple operating systems versions in this plan?
• Do you plan to rationalize these into the same version?
• Is there a plan for bringing systems to the same version
G.6.6 Operating system maintenance
• Servers: Do you have maintenance contracts for your server operating
systems?
• Clients: Do you have maintenance agreements in place for your client
software?
G.6.7 Printers
• Do you have a list of your printer inventory?
• Are the printers supported with a maintenance agreement?
• Will the printers support the new environment?
End-to-end checklist 181
G.7 Applications in current use
Inventory of server based applications
• Application provider
• Version
• Number of users
• Database size in MB
• Data transfer requirements
Inventory of client based applications
• Application provider
• Version
• Number of users
• Database size in MB
• Data transfer requirements
Application maintenance
• Support contracts
– Do support contract exist for all applications?
– What is the support level?
– Are there react time guarantees?
– Does this meet the new availability requirements?
• Frequency of update
– Does the application have updates?
– What is the frequency of update?
G.7.1 Application operational hours current
Ask youself the following questions:
• By application what are the operational hours?
• Are there any processing peak periods that extend these operating hours?
Application processing peaks.
Application processing map
An application processing map shows the time plan of when various applications
run on both server and client machines. It shows the interleaving of applications
and should identify any periods that have an opportunity for very high or very low
requirement.
• Interactive
• Batch
• During the day
• Day end
• Month end
• quarter end
• year end
• fiscal year end
Application operational hours requirement: 5x8, 7x24, 24x365
What are the assessed operational requirements of each application?
182 High Availability on the AS/400 System: A System Manager’s Guide
Growth information; applications, database, users
What is the growth information for each application and its associated database
and users?
Splitting an application
Is the splitting of the application across multiple machines a consideration?
© Copyright IBM Corp. 2001 183
Appendix H. Special notices
This publication is intended to help customers, business partners, and IBMers
who are looking to implement a high availability solution for their AS/400 system.
It provides planning checklists and background information to understand the
facets of planning for a high availability solution, implementing a high availability
solution, and managing the project installation itself. The information in this
publication is not intended as the specification of any programming interfaces that
are provided by OS/400. See the PUBLICATIONS section of the IBM
Programming Announcement for OS/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
184 High Availability on the AS/400 System: A System Manager’s Guide
environments may vary significantly. Users of this document should verify the
applicable data for their specific environment.
This document contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples contain the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual
business enterprise is entirely coincidental.
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:
The following terms are trademarks of other companies:
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. (For a complete list of
Intel trademarks, see http://www.intel.com/tradmarx.htm)
UNIX is a registered trademark in the United States and/or other countries
licensed exclusively through X/Open Company Limited.
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.
e (logo)®
IBM
Redbooks
Redbooks Logo
APPN AS/400
AS/400e AT
CT Current
DataJoiner DataPropagator
DB2 DRDA
Netfinity Nways
OS/2 OS/400
RPG/400 SAA
SP System/36
System/38 XT
400 Lotus
Lotus Notes Notes
Tivoli
Results:
Error ".odbc_error().":".odbc_errormsg()."");
elseif (odbc_num_rows($result)==0):
echo("Query ran successfully");
else:
?>
");
endif;
} elseif ($host || $database || $query) {
echo("All three fields must be filled in for a query
".odbc_field_name($result,$i+1)."");
}
?>
");
for ($j =0;$j
");
} else {
echo("Use PHP to run an SQL Query on an iSeries database:
");
}
?>
tags around each cell.
Another PHP script
For one additional PHP example, let us include a script that will work only in the PASE version
of PHP. This example takes advantage of the fact that the PASE “system” command writes
any spooled output, produced by a command, to standard output. That is, you can run any
commands with an OUTPUT(*PRINT) parameter in the PASE shell and have the results sent
to STDOUT.
For example, if you're on the PASE command line QP2TERM, you can type the command
system wrkactjob (Work with Active Jobs (WRKACTJOB)) and see the results as they scroll
across the screen. Our example, phpactjob, simply formats this output into an HTML table.
Figure 5 shows the output of this script.
10 Bringing PHP to Your IBM ^ iSeries Server
Figure 5 PHP formats the result of Work with Active Jobs (WRKACTJOB) at an HTML table
Here is the phpactjob source code. Note that we use back quotation marks (``) to run the
command Work with Active Jobs (WRKACTJOB) and capture the output. This output is then
broken into lines by searching for the new line character “\n” using the strtok function of PHP.
";
print "";
print " ";
while ($line = strtok("\n"))
{
print "";
print $line;
print "
";
print " ";
}
print "";
print "thend";
?>
Bringing PHP to Your IBM iSeries Server 11
A starting point
You have been introduced to PHP and how to use it on the iSeries server. Use this article as
a starting point to find other examples and documentation that can have you running PHP in
no time.
Probably the best place to find help, tutorials, and examples about PHP is the PHP project
Web site at:
http://www.php.net
You can also check out the PASE on iSeries PartnerWorld® Web site at:
http://www-919.ibm.com®/developer/factory/pase/overview.html
Also see the iSeries Linux home page at:
http://www.iseries.ibm.com/linux
You can find a neat demo application showing PHP using ODBC Driver for Linux at the
following Web site:
http://www-1.ibm.com/servers/eserver/iseries/linux/odbc/guide/demoindex.html
This demo includes PHP using binary large objects (BLOBs) that contain employee
photos in the sample iSeries EMPLOYEE database.
Beware of PHP bugs
Recently, a few security holes were discovered in PHP. The most recently discovered one
involves the code for handling file uploads. This flaw lets hackers easily crash the PHP server
and possibly take it over remotely. The flaw affects PHP versions 4.2.0 and 4.2.1. CERT rates
the problem as critical.
The PHP Group announced a fix release, version 4.2.2, that all PHP users employing PHP's
file-upload facility should install immediately. The fix is available on the Web at:
http://www.php.net/release_4_2_2.php
Prerequisites
This IBM Redpaper assumes that you have the following hardware and software on your
iSeries server:
5722-SS1: OS/400 (5722-SS1) at V5R2 (though the same basic steps should work on an
iSeries server at V5R1)
5722-SS1 Option 13: OS/400 - System Openness Includes
5722-SS1 Option 33: OS/400 PASE
Note: We assume for this document that you are running at V5R2 of OS/400. If you
have OS/400 V5R2 then all you must do is to make sure that 5722-SS1 Option 33
OS/400 PASE has been installed.
Since OS/400 V5R1 supports some levels of AS/400 hardware that is not supported by
PASE (PASE requires a certain version (level) of PowerPC® processor) you must first
determine if your AS/400 hardware supports PASE. You can find a detailed list of
processors on which PASE can run on the Web at:
http://www.as400.ibm.com/developer/factory/pase/ehardware.html
12 Bringing PHP to Your IBM ^ iSeries Server
5722-DG1: IBM HTTP Server for iSeries. This LPP contains the HTTP Server (powered by
Apache), which is the only HTTP server for which PHP will work.
Also, install the latest Apache group PTF package. For V5R2, the group PTF package
number is SF99098.
The command make
A make command can be found in OS/400’s PASE for V5R2.
If you are using V5R1 of OS/400 then you will have to download the make command. We
suggest using the GNU make command that can download from
http://www.gnu.org/directory/gnu/make.html
5799-PTL: (Optional) PRPQ iSeries Tools for Developers. This tool kit is optional for this
work but you may find it useful for some other similar projects. For details see
http://www.iseries.ibm.com/developer/factory/tools
This Redpaper also assumes that you have the following hardware and software on your
build machine. The build machine could be either a separate pSeries™ running AIX or an
iSeries running OS/400 with the following software:
The command patch
If you do not have a patch program on your system, try the GNU patch. The GNU patch
program is usually not on AIX or OS/400 machines. You can download version 2.5 (not
2.5.4) from:
ftp://ftp.gnu.org/pub/gnu/patch
To compile the source, follow these steps:
a. Untar the source using the tar command.
b. Type cd to go to the directory.
c. Perform a ./configure.
d. Run the make command.
e. Run make install.
The GNU command gzip command to compresses and decompresses files. You can
download this from:
http://www.gnu.org/directory/GNU/gzip.html
The VisualAge C++ compiler for AIX. You can find information about this compiler at:
http://www.ibm.com/software/ad/vacpp/
If your build machine will be AIX (not OS/400) you must match the AIX version to the target
OS/400 PASE version. That is, the application binary created on AIX needs to be
compatible with the version of OS/400 PASE that you want to the application to run in. To
help you plan this issue see:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzalf/rzalfplanning.htm
We have tested these instructions on AIX 4.3 and newer.
Alternatively, V5R2 of OS/400 PASE now supports installation of either the IBM VisualAge
C++ Professional for AIX Version 6.0 or the IBM C for AIX Version 6.0 software products.
This means you can compile OS/400 PASE applications within OS/400 PASE. A separate
AIX system is not required. IBM VisualAge C++ Professional for AIX Version 6.0
(5765-F56) and IBM C for AIX (5765-F57) are separately available program products from
IBM. Note that the VisualAge C++ Professional for AIX compiler product also includes the
C for AIX compiler product.
Bringing PHP to Your IBM iSeries Server 13
Installation instructions
Follow these steps to download and prepare the PHP source files for compile.
Downloading PHP
Download the version of PHP you need for your iSeries.
1. Download the tar file php-4.3.0.tar.gz for PHP 4.3.0 from the following Web site:
http://www.php.net
2. Using FTP, send this file to the machine on which you will build PHP. This may be the AIX
machine or the iSeries machine with the VisualAge compiler. We will call this your build
machine.
3. Untar the file by using the following commands:
gunzip php-4.3.0.tar.gz
tar -xvf php-4.3.0.tar
Patching the source code file
A patch is required to run PHP on the iSeries. We included patch files for both the 4.3.0 and
the older 4.2.2 versions of PHP. The patch changes the default PHP DB2 support from AIX
DB2 to OS/400 DB2.
1. Download and save the patch file to the build machine. You can find the file on the ITSO
home page at:
http://www.redbooks.ibm.com/
Click Additional materials to access the directory listing of additional materials to
download. Open the directory REDP3639, in which you will find the files
php422pase.patch and php430pase.patch.
Download the patch file into the same directory from which you ran the tar command.
2. Change directory (cd) to that directory and run the following patch command:
patch -p0 < php430pase.patch
Locating iSeries specific files
You must locate and bring to your build machine the following iSeries files:
The sqlcli.h and the libdb400.exp files contain DB2 UDB AS/400 support.
The as400_libc.exp file is an iSeries-specific extension to the AIX file libc.a. This file is part
of 5722-SS1 Option 13 OS/400 - System Openness Includes.
Follow these instructions to obtain the files from your iSeries:
1. Enter the following command:
CPY OBJ('/QIBM/include/sqlcli.h') TODIR('/home/yourid') TOCCSID(*STDASCII) DTAFMT(*TEXT)
Note: At the time of this writing an offer for free 60-day trial version of VisualAge C++
Professional for AIX, V6.0 is now available for download. See:
http://www14.software.ibm.com/webapp/download/search.jsp?go=y&rs=vacpp
Note: We include the patch files for both the 4.3.0 and the older 4.2.2 versions of PHP.
These instructions, however, are written for version 4.3.0.
14 Bringing PHP to Your IBM ^ iSeries Server
2. Using FTP, send the /home/yourid/sqlcli.h file from your iSeries to the build machine.
3. Send, using FTP, the libdb400.exp and as400_libc.exp files from the iSeries directory
/QOpenSys/QIBM/ProdData/OS400/PASE/lib to the AIX build machine.
Preparing for the PHP compile
Follow these steps to prepare the files and directories needed for the successful compile of
PHP on your build machine. These steps are assuming ksh.
1. Set the CFLAGS, CC, and CPPFLAGS environment variables as follows.
export CFLAGS='-ma -DPASE -I /home/yourid -bI:/home/yourid/libdb400.exp
-bI:/home/yourid/path/as400_libc.exp'
export CC=xlc
export CPPFLAGS=-qflag=e:e
2. Change to the php-4.3.0 directory using the cd command.
3. Run the following command:
./configure --with-ibm-db2 \
--with-config-file-path=/QOpenSys/php/etc \
--prefix=/QOpenSys/php/ \
--enable-force-cgi-redirect \
--without-mysql
4. If you are compiling directly in PASE on iSeries, add the following configure flags (be sure
to add a “\” to the end of the previous line):
--build=powerpc-ibm-aix4.3.3.0 \
--host=powerpc-ibm-aix4.3.3.0
The configure should take some time to run. After it finishes, you need to make final
adjustments to the files listed in the following steps.
5. Edit the Makefile:
remove -ldb2 from ODBC_LIB
remove -ldb2 from EXTRA_LIBS
6. Edit the config_vars.mk file:
remove -ldb2 from ODBC_LIBS
remove -ldb2 -lbind from EXTRA_LIBS
7. Edit the main/build-defs.h file:
remove -ldb2 from PHP_ODBC_LIBS
8. Edit the main/php_config.h file:
Delete #define HAVE_MMAP 1
Delete #define HAVE_SETITIMER 1
Note: The flags for -I and -bI are the uppercase format of the letter “i”.
Note: The Makefile is generated with lines greater than 2048 characters. Some editors,
such as vi, cannot handle the long lines, so you need to use a different editor. FTP the
Makefile to a different machine and back if necessary.
Note: PHP version 4.3.0 does not have a config_vars.mk. This step is for PHP version
4.2.2 only.
Bringing PHP to Your IBM iSeries Server 15
If you run this on a V5R1 OS/400 server, use the following command:
Delete #define HAVE_STATVFS 1
Delete #define HAVE_PREAD 1
Delete #define HAVE_PWRITE 1
Compiling (make)
You have two choices depending on whether you are compiling in AIX on the pSeries or in
PASE on the iSeries.
If you are compiling in PASE on the iSeries
Follow these steps if you are compiling the PHP source code on your iSeries:
make
make install
mkdir /QOpenSys/php/etc
cp php.ini-dist /QOpenSys/php/etc/php.ini
This installs and puts all the files in the correct directory. You need write access to the
/QOpenSys directory.
At this point, you may skip to “Testing PHP” on page 16.
If you are compiling in AIX on the pSeries
Follow these steps if you are compiling the PHP source code on your pSeries:
1. Edit the Makefile (see the note in step 5 on page 14 about the long lines of the Makefile)
for the line "install_targets =",remove "install-pear".
2. Enter the following commands in the order shown:
mkdir /tmp/QOpenSys
3. At the AIX prompt, run the following commands:
make
make install INSTALL_ROOT=/tmp/
This installs PHP into /tmp/QOpenSys/php.
4. Enter the following commands in the order shown:
mkdir /tmp/QOpenSys/php/etc
cp php.ini-dist /tmp/QOpenSys/php/etc/php.ini
5. Edit the Makefile (see the note in step 5 on page 14 about the long lines of the Makefile)
for the line "install_targets =",add "install-pear".
If the location of your home directory on your AIX box is different than the location of your
home directory in PASE (for example, on AIX your home directory is /usr/home/usr4/jdoe
and on PASE it is /home/john), replace all occurrences of "/usr/home/usr4/jdoe/" to
"/home/john/" in the Makefile. Make sure that you include the first and last “/” so you don't
lose your directory separator.
6. Enter the following commands in the order shown:
cd /tmp
tar -cvf ~/php430pasebin.tar QOpenSys
cd ~
tar -cvf php430pasesrc.tar php-4.3.0
16 Bringing PHP to Your IBM ^ iSeries Server
7. Using FTP, send both php430pasebin.tar and php430pasesrc.tar to your home directory
on the iSeries server.
8. Enter the following commands in the order shown:
cd /
tar -xvf ~/php430pasebin.tar
cd ~
tar -xvf php430pasesrc.tar
cd php-4.3.0
make install-pear
Testing PHP
From the PASE shell in OS/400, run the command:
/QOpenSys/php/bin/php -v
This should tell you the version of PHP you have.
Configuring HTTP Server (powered by Apache) to use PHP
Edit the file httpd.conf using the Apache GUI interface. The key statements needed are:
ScriptAlias /php-bin/ /QOpenSys/php/bin/
AddType application/x-httpd-php .php
Action application/x-httpd-php /php-bin/php
$line
