Les cookies nous permettent de vous proposer nos services plus facilement. En utilisant nos services, vous nous donnez expressément votre accord pour exploiter ces cookies.En savoir plus OK

Backup Recovery and Media Services for OS/400 A Practical Approach

Backup Recovery and Media Services for OS/400 A Practical Approach

Revenir à l'accueil

 

Au format "texte" :

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 This message is issued when the user or the application tries to insert or update a foreign key, and a matching parent key value does not exist.  CPF502E: Referential constraints could not be validated for member This message is issued when the system cannot validate a referential constraint because of a record or a file lock.  CPF503A: Referential constraint violation on member This message is issued when the delete rule is NOACTION or RESTRICT and the user or the application tries to delete or update a parent key having matching foreign key values. These messages have a severity level of 30, and the default reply is “Cancel”. Escape messages There are two new escape messages for referential integrity errors:  CPF523B: Referential constraint error processing member This message is issued when the system cannot enforce a referential constraint.  CPF523C: Referential constraints journal error This message is issued when the system cannot enforce a referential constraint because the corresponding parent and dependent files are not journaled, or they are not journaled to the same journal. Both messages have a severity level of 30 and fall into the range of escape messages that are unrecoverable. 3.7.2 Handling referential integrity messages in applications To handle these messages, new file status codes have been provided for ILE languages. In the original program model (OPM) environment, any message due to errors in referential integrity enforcement maps to the existing I/O error status codes “01299” for RPG/400 and “90” for COBOL/400. Referential integrity messages in ILE RPG programs You can check the new status “01222” if you want to handle the CPF502E message. There is also a corresponding inquiry message RNQ1222 and a corresponding escape message RNX1222. Both of them have severity level 99 and the following text: Unable to allocate a record in file &7 due to referential constraint error (R C G D F). Status “01022” handles CPF502D and CPF503A. There is also a corresponding inquiry message RNQ1022 and a corresponding escape message RNX1022. Both of them have severity level 99 and the following text: Referential constraint error on file &7. The existing status code “01299” and the corresponding inquiry message RNQ1299 and escape message RNX1299 are used to handle escape messages CPF523C and CPF523B. 52 Advanced Functions and Administration on DB2 Universal Database for iSeries Referential integrity messages in ILE COBOL programs Status “9R” handles all the notify messages previously listed for referential integrity exceptions. Both escape messages are handled by the status code “90” set for the exceptions in the CPF5200 range. Referential integrity messages in ILE C programs ILE/C maps these messages to the existing error number values. SQLCODE values mapping referential integrity messages The SQLCODE values are:  SQLCODE 530 handles the notify message CPF502D.  SQLCODE 531 indicates that you are updating a parent key with matching dependent records.  SQLCODE 532 indicates that you are deleting a parent key with matching dependent records. See Appendix B, “Referential integrity: Error handling example” on page 337, for a coding example about error handling when using referential integrity. 3.8 Referential integrity constraint management This section describes:  Constraint states  Check pending condition  Commands you can use to manage referential integrity constraints  Save and restore  How to obtain information about referential integrity constraints 3.8.1 Constraint states A referential constraint can be in one of the following states:  DEFINED state: The constraint definition exists at the file level, but the constraint is not enforced. Defined constraints are purely by definition and not by function. The file members do not have to exist for the constraint to be defined. – Defined/enabled: A constraint that remains enabled when it is moved to the established state – Defined/disabled: A constraint that remains disabled when it is moved to the established state  ESTABLISHED state: A referential constraint is established when the foreign key attributes match those of the parent key and both files contain a member. The constraint has now been formally created in the DBMS. In this state, the constraint can be: – Established/enabled: DB2 UDB for iSeries enforces referential integrity for this constraint. – Established/disabled: DB2 UDB for iSeries does not enforce referential integrity for a constraint in this state. However, the access paths associated with the constraint are still maintained. See Database Programming, SC41-5701, for a complete discussion of constraint states. Chapter 3. Referential integrity 53 3.8.2 Check pending A referential constraint is placed in check pending status if the DBMS determines that mismatches may exist between the parent and foreign keys. The check pending status only applies to referential constraints in the established/enabled state. There are several operations that can cause a check pending condition:  Adding referential constraints to existing files with invalid data  Abnormal system failures  Save/restore operations  Apply/remove journal changes When a referential constraint relationship has been marked as check pending, the associated parent and dependent files can be opened, but the system imposes some restrictions on the I/O operations to those files:  Only read and insert operations are allowed on the parent file.  No I/O operations are allowed on the dependent file. The system imposes these restrictions to ensure that applications and users are not accessing and changing records that are possibly inconsistent and, therefore, violating referential integrity. To move a constraint relationship out of check pending, you must use disable (CHGPFCST) to disable the constraint that allows any I/O operations to be performed on the parent and dependent file. You can then correct your parent and foreign key values so that they again meet referential integrity. Once the data corrections are completed, you can enable the constraint that causes DB2 UDB for iSeries to process and verify that every non-null foreign key value is valid. If this verification finds mismatches, the relationship is again marked as check pending and the process repeats itself. The check pending status of a file can be determined with the Work with Physical File Constraints (WRKPFCST) command (refer to Figure 3-20 on page 57) and the Display Physical File Description (DSPFD) command (refer to Figure 3-23 on page 62). 3.8.3 Constraint commands The commands provided to manage referential integrity constraints are:  Change Physical File Constraint (CHGPFCST)  Display Check Pending Constraint (DSPCPCST)  Work with Physical File Constraints (WRKPFCST)  Edit Check Pending Constraint (EDTCPCST)  Remove Physical File Constraint (RMVPFCST) CHGPFCST command The Change Physical File Constraint (CHGPFCST) command provides a way to:  Enable a referential constraint: Enable causes the system to verify the data integrity of the specified constraint (for example, every non-null foreign key value has a matching parent key). If the verification is successful, the referential constraint is enforced by DB2 UDB for iSeries. Remember that this enable process may not be a short-running operation when the associated files contain a large number of records. 54 Advanced Functions and Administration on DB2 Universal Database for iSeries  Disable a referential constraint: Disabling a constraint essentially turns off referential integrity for that constraint relationship. Although the constraint is still defined in the DBMS, the DBMS no longer enforces referential integrity for the disabled constraint relationship. Any I/O operation is allowed on the parent and dependent file, even if that operation violates referential integrity. As mentioned in the check pending section, the disable option is used with check pending constraints so that users can clean up their parent and foreign key data before having the system re-verify the constraint. Disabling a constraint can allow faster file I/O operations in performance-critical situations. However, you must consider the trade-off in this situation. While the constraint is disabled, the data can violate referential integrity, and you are unaware of the violation until the constraint is re-enabled. In addition, you must wait for the system to re-verify all of your foreign key values on the re-enable. To limit your data integrity exposure when a constraint is disabled, first use the Allocate Object (ALCOBJ) command to exclusively lock the files associated with the constraint to be disabled. This allocation prevents other users from changing the file data while the constraint is disabled. Then, use the De-allocate Object (DLCOBJ) command to free the files once the referential constraint has been re-enabled. Before enabling or disabling a constraint, the system obtains:  Exclusive allow-read locks on the parent file, member, and access paths  Exclusive no-read locks on the dependent file, member, and access paths These locks are released at the end of the CHGPFCST command. DSPCPCST command The Display Check Pending Status (DSPCPCST) command can be used on referential constraints that are in a disabled state to display which records in the dependent file do not have matching parent key values, thereby causing the check pending condition. The following example shows how the DSCPCPCST output can be used to fix a constraint that is currently marked as check pending. In the Order Entry database, we define a referential constraint ORDERHDR_CNBR (Parent Key and foreign key is the Customer_Number field in both files) between existing CUSTOMER and ORDERHDR files having the contents listed in Table 3-1 and Table 3-2. Table 3-1 CUSTOMER table CUSTOMER_NUMBER CUSTOMER_NAME ... 10509 Benson Mary 15006 Smith Steven ... 14030 Peterson Robert ... 13007 Robinson Richard ... 21603 White Paul ... Chapter 3. Referential integrity 55 Table 3-2 ORDERHDR table The constraint is marked as check pending because ORDERHDR contains records related to Customer 12312, which does not exist in the CUSTOMER file. In this case, follow these steps: 1. Lock up your referential integrity network with the ALCOBJ command while you are correcting your parent and foreign key data: ALCOBJ OBJ((CUSTOMER *FILE *EXCL *FIRST) (ORDERHDR *FILE *EXCL *FIRST)) 2. If the constraint is not yet disabled, disable the constraint so that the DSPCPCST command can read the dependent file: CHGPFCST FILE(ORDERHDR) CST(ORDERHDR_CNBR) STATE(*DISABLED) 3. Display which records in ORDERHDR have a customer number that does not exist in the CUSTOMER file: DSPCPCST FILE(ORDENTL/ORDERHDR) CST(ORDERHDR_CNBR) The output of this command is shown in Figure 3-19. Figure 3-19 DPSCPCST output 4. According to the DSPCPCST output, clean up your foreign and parent keys value. In this case, it appears that Customer 12312 needs to be added to the CUSTOMER file. 5. Once the data is corrected, enable the constraint so that the DBMS can verify that your parent and foreign key data is now in sync: CHGPFCST FILE(ORDERHDR) CST(ORDERHDR_CNBR) STATE(*ENABLED) ORDER_NUMBER ... CUSTOMER_NUMBER ORDER_DATE 00010 ... 10509 05/08/01 00020 ... 10509 05/09/01 02020 ... 12312 02/03/01 02021 ... 12312 04/13/01 02022 ... 12312 04/25/01 Display Report Width . . .: 142 Column . .: 1 Control . . . . Line ....+....1....+....2....+....3....+....4....+ .......... ORDER_NUMBER CUSTOMER_NUMBER ORDER_DATE ------------ --------------- ---------- 000001 02020 12312 02/03/2001 000002 02021 12312 04/13/2001 .... 000003 02022 12312 04/25/2001 ****** * * * * * E N D O F D A T A * * * * * 56 Advanced Functions and Administration on DB2 Universal Database for iSeries 6. Now that the constraint has been successfully enabled, release the locks on your referential integrity network with the DLCOBJ command: DLCOBJ OBJ((CUSTOMER *FILE *EXCL *FIRST) (ORDERHDR *FILE *EXCL *FIRST)) 3.8.4 Removing a constraint This section shows how to remove physical file (or table) constraints. Both the native and SQL interfaces can be used to remove file constraints:  The native interface provides the Remove Physical File Constraint (RMVPFCST) command.  The SQL interface allows you to remove an existing constraint from a file through the DROP clause of the ALTER TABLE statement. The SQL interface supports the removal of one constraint at a time. The following statement removes the customer_key constraint from the CUSTOMER file: ALTER TABLE mylib/CUSTOMER DROP CONSTRAINT customer_key The following statements remove (respectively) the primary key, the constraint_name unique constraint, and the constraint_name referential constraint from the CUSTOMER file: ALTER TABLE mylib/CUSTOMER DROP PRIMARY KEY ALTER TABLE mylib/CUSTOMER DROP UNIQUE constraint_name ALTER TABLE mylib/CUSTOMER DROP FOREIGN KEY constraint_name In contrast, the native interface allows you to remove more than one constraint at a time. In addition, you can sub-select the physical file constraints you want to remove by specifying the option that only referential constraints, marked as check pending, should be removed. Let's examine the impact of the RMVPFCST command according to the different values of its parameters. The following statement removes the constraint_name constraint from CUSTOMER file: RMVPFCST FILE(mylib/CUSTOMER) CST(constraint_name) TYPE(constraint_type) If CST(*CHKPND) is specified, all the referential constraints in the check pending condition are removed, regardless of the value of the TYPE parameter. The following statement removes all the constraint_type constraints from the CUSTOMER file in mylib: RMVPFCST FILE(mylib/CUSTOMER) CST(*ALL) TYPE(constraint_type) In this case, the system removes the unique or referential constraints following the sequence in which they have been created: RMVPFCST FILE(mylib/CUSTOMER) CST(*ALL) Chapter 3. Referential integrity 57 The RMVPFCST statement removes all the constraints defined over the CUSTOMER file in mylib, including the damaged constraints since the TYPE default value is *ALL. In this case, the system removes the primary key constraint first, then all of the unique constraints (in their creation sequence), and finally, all of the referential constraints (in their creation sequence). WRKPFCST command The Work with Physical File Constraints (WRKPFCST) command is similar to the other Control Language Work commands. With this command, you can gain access to most of the constraint operations from a single display. The WRKPFCST command lets you see one or all the physical file constraints defined over one or more files, depending on the values you set for the WRKPFCST parameters. Figure 3-20 displays the sample output from the WRKPFCST command. Figure 3-20 Work with Physical File Constraints display On this display, you can:  Change the state of constraints (option 2): This option invokes the CHGPFCST command (see “CHGPFCST command” on page 53).  Remove a constraint (option 4): This option invokes the RMVPFCST command (see 3.8.4, “Removing a constraint” on page 56, for more details).  Display constraints in check pending status (option 6): This option executes the DSPCPCST command (see “DSPCPCST command” on page 54). The state column lists the status of the referential constraints: defined or established and enabled or disabled. The check pending status column displays which constraints are currently in check pending. Disabled constraints are always shown as being in check pending condition although check pending does not apply to disabled constraints. Work with Physical File Constraints Type options, press Enter. 2=Change 4=Remove 6=Display records in check pending Check Opt Constraint File Library Type State Pending CUSTOMER_K > CUSTOMER ORDENTL *PRIKEY ORDDTL_KEY ORDERDTL ORDENTL *PRIKEY ORDDTL_HOR > ORDERDTL ORDENTL *REFCST EST/ENB NO ORDERHDR_K > ORDERHDR ORDENTL *PRIKEY ORDERHDR_C > ORDERHDR ORDENTL *REFCST EST/ENB YES SALESREP_K > SALESCUS ORDENTL *PRIKEY SALESREP_C > SALESCUS ORDENTL *REFCST EST/ENB NO STOCK_KEY STOCK ORDENTR *PRIKEY STOCK_SNBR STOCK ORDENTR *REFCST EST/ENB NO SUPPLIER_K > SUPPLIER ORDENTR *PRIKEY Parameters for options 2, 4, 6 or command Bottom ===> F3=Exit F4=Prompt F5=Refresh F12=Cancel F15=Sort by F16=Repeat position to F17=Position to F22=Display constraint name 58 Advanced Functions and Administration on DB2 Universal Database for iSeries EDTCPCST command The Edit Check Pending Constraints (EDTCPCST) command allows you to manage the verification of referential constraints that have been marked as check pending. The system displays the constraints marked as check pending and the estimated time it takes the system to verify the constraint once the parent and foreign key data have been corrected. From our previous example (Figure 3-20), the corresponding EDTCPCST display output is shown in Figure 3-21 with the ORDERHDR_CNBR constraint that was placed in check pending status. Figure 3-21 Edit Check Pending Constraints display From this display, you can set a sequence for the constraints verification. You can also delay the verify process to a later time, specifying *HLD on the sequence field. DB2 UDB for iSeries starts verifying the constraints right after you specify the sequence. The elapsed time since the beginning of the process is also displayed. During this process, the constraint status is set to RUN. Other constraints waiting for verification are marked with READY. Verifying at IPL time The Edit Check Pending Constraints display (Figure 3-22) is shown during a manual mode IPL if there are constraints in check pending condition. Edit Check Pending Constraints SYSTEM03 05/14/01 18:39:36 Type sequence, press Enter. Sequence: 1-99, *HLD ----------Constraints----------- Verify Elapsed Seq Status Cst File Library Time Time 1 RUN STOCK > STOCK ORDENTR 00:10:00 00:02:40 2 READY SALES > SALESCUS ORDENTL 00:01:48 00:00:00 *HLD CHKPND ORDER > ORDERHDR ORDENTL 00:00:01 00:00:00 Bottom F3=Exit F5=Refresh F12=Cancel F13=Repeat all F15=Sort by F16=Repeat position to F17=Position to F22=Display constraint name Chapter 3. Referential integrity 59 Figure 3-22 Editing Check Pending Constraint display at IPL time On this display, you have three alternatives:  If you want the system to suspend the IPL and verify a constraint at this time, for that constraint, you have to type a Sequence value less than or equal to the IPL threshold number.  If you need the system to verify a constraint after the IPL, you have to use a sequence value greater than the threshold. The IPL then continues, and at the IPL completion, the system automatically starts verifying that constraint.  If you want to handle the check pending condition by yourself during the normal activity, hold the constraint verification by leaving the Sequence value set to *HLD. If several constraints must be verified at the same time, either during IPL or at the end, you can specify an ordering sequence for them by inserting ordered values into the Sequence field. 3.8.5 Save and restore considerations As mentioned in 3.3.3, “Referential integrity and access paths” on page 25, when a set of database files is saved, all the physical file constraints and associated access paths are saved as well. At restore time, the system attempts to re-establish the constraints for the user. During the restore operation, the system determines whether the parent and dependent files associated with the referential constraints are at the same data level (in other words, at the same integrity level according to their constraints). If the system determines that the related files and constraints are not at the same level, the constraint relationship is marked as check pending. The system does not spend time verifying every foreign key value during the restore. It only checks the data level of the associated files. This data level verification is much quicker than the DBMS verification of every foreign key value and still preserves referential integrity. Edit Check Pending Constraints SYSTEM03 05/24/01 11:14:25 IPL threshold . . . . . . . . . . . . . 50 0-99 Type sequence, press Enter. Sequence: 1-99, *HLD ----------Constraints----------- Verify Elapsed Seq Status Cst File Library Time Time *HLD CHKPND ORDER > ORDERHDR ORDENTL 00:45:30 00:05:15 *HLD CHKPND SALES > SALESCUS ORDENTL 00:01:43 00:00:36 *HLD CHKPND STOCK > STOCK ORDENTR 00:00:25 00:00:05 Bottom F5=Refresh F13=Repeat all F15=Sort by F16=Repeat position to F17=Position to F22=Display constraint name 60 Advanced Functions and Administration on DB2 Universal Database for iSeries Other DBMS automatically either place the constraints in check pending or verify every foreign key value when you load backup copies of your database files onto the system. DB2 UDB for iSeries gives you the benefit of the doubt when restoring database backups. For example, you always save both your parent and dependent files every Monday night. A system failure on Thursday necessitates that you load the backup tape copies of your dependent and parent file. DB2 UDB for iSeries then quickly verifies that the dependent and parent files being restored are at the same data level (which is true since they were backed up together) and leaves the referential integrity constraint in a valid state. This allows you to move your backup onto the system as quickly as possible while still guaranteeing referential integrity. Here’s an example of DB2 UDB for iSeries protecting your data integrity. You restore a version of the dependent file without restoring the corresponding version of the parent file. This only leads to a check pending condition when some parent records have changed since the save operation took place, which now causes your parent and newly restored dependent files to be at different data levels. For this example, we assume that some parent records have changed since the save operation. The associated referential constraint is marked as check pending since data inconsistencies may exist due to the different data levels detected by the DBMS. You are responsible for cleaning up this check pending situation before users and applications can fully access these files. To avoid check pending and the associated recovery work, always save your referential integrity network in the same save request. This keeps the associated parent and dependent files at the same level so that you can restore the network with one request. When your referential integrity network is split across different libraries, you cannot save and restore the network with a single request. In this case, you need to prevent other jobs from changing your file data levels during your multiple request save or restore operation by using the Allocate Object (ALCOBJ) command to lock up your referential integrity network. Here's an example of the steps to follow in this situation:  When saving your referential integrity network: a. Allocate the files you have to save with the ALCOBJ command, and set Lock State to *EXCL. b. Save your network. c. Release the locks on the files by using the De-allocate Object (DLCOBJ) command.  When restoring your referential integrity network: a. Allocate the libraries your files are restored into by using the ALCOBJ command and setting Lock State to *EXCLRD. b. Restore your files in any sequence. c. Release the locks previously established on the libraries using the DLCOBJ command. When a dependent file is restored and the parent file is still missing, the constraint is left in a defined/enabled state. As soon as the parent file is restored, the constraint is established and the data levels immediately are verified. Therefore, the parent and dependent files can be restored in any sequence while still avoiding check pending. When you restore files belonging to a referential integrity network, the system can determine whether the files are at different data levels for every single constraint. Restoring files at different data levels may result in a mix of check pending and non-check pending constraints. Only the constraints potentially affected by the database changes that caused the data level mismatch are put into check pending. Chapter 3. Referential integrity 61 If you restore a database file over an existing one, the existing constraints are preserved. For example, if you remove some constraints from the file currently on the system, the additional constraints saved on the media are not restored. 3.8.6 Restore and journal apply: An example Consider the example described in 3.5.3, “A CASCADE example” on page 39. You may want to save this referential integrity network. Since all the files are in the same library, issue a single save request: SAVOBJ OBJ(ORDERH DETAIL FEATURE) LIB(TEST) DEV(device) OBJTYPE(*FILE) Consider the example where a system failure has caused you to lose the DETAIL file, and you now need to recover your referential integrity network. Follow these steps: 1. Allocate the involved files to avoid changes by other jobs. Use the ALCOBJ command with Lock Type set to *EXCL to prevent other users from reading inconsistent data. 2. Restore all of the referential integrity network: RSTOBJ OBJ(ORDERH DETAIL FEATURE) SAVLIB(TEST) DEV(device) OBJTYPE(*FILE) 3. Apply journal changes to all of the involved files: APYJRNCHG JRN(TEST/QSQJRN) FILE((TEST/ORDERH) (TEST/DETAIL) (TEST/FEATURE)) CMTBDY(*YES) 4. De-allocate the ORDERH, DETAIL, and FEATURE files. For details on journaling, commitment control, and applying journal entries, see Backup and Recovery Guide - Advanced, SC41-3305. 3.8.7 Displaying constraint information You can display or output the constraints and their related attributes and states for a file in the following ways:  Run the Display Physical File Description (DSPFD) command  Run the Display Database Relations (DSPDBR) command  Query the system catalog tables DSPFD and DSPDBR commands The DSPFD command also provides a complete description of all the constraints defined for a file. You can select this specific information by specifying: DSPFD FILE(ORDENTL/ORDERHDR) TYPE(*CST) This command shows which constraints are defined for the ORDERHDR file and their description as shown in Figure 3-23. 62 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 3-23 Physical file constraints from DSPFD In the Constraint Description section (highlighted in bold) in Figure 3-23, all of the parameter values set through the ADDPFCST command or ALTER TABLE/CREATE TABLE statements for each constraint are listed. The DSPFD command issued for a given file shows a referential constraint definition only for the parent file. To determine which referential constraints refer to this file as a parent file, you must use the DSPDBR command. This command lists these constraints in the Dependent Files section, where some new information has been added to differentiate among referential constraints, logical files, SQL indexes, or SQL views. Figure 3-24 shows this information for the ORDERHDR file. Display Spooled File File . . . . . : QPDSPFD Page/Line 1/1 Control . . . . . Columns 1 - 78 Find . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+... 5/16/01 Display File Description DSPFD Command Input File . . . . . . . . . . . . . . . . . . . : FILE ORDERHDR Library . . . . . . . . . . . . . . . . . : ORDENTL Type of information . . . . . . . . . . . . : TYPE File attributes . . . . . . . . . . . . . . : FILEATR *ALL System . . . . . . . . . . . . . . . . . . : SYSTEM *LCL File Description Header File . . . . . . . . . . . . . . . . . . . : FILE ORDERHDR Library . . . . . . . . . . . . . . . . . . : ORDENTL Type of file . . . . . . . . . . . . . . . : Physical File type . . . . . . . . . . . . . . . . . : FILETYPE *DATA Auxiliary storage pool ID . . . . . . . . . : 01 Constraint Description Primary Key Constraint Constraint . . . . . . . . . . . . . . : CST ORDERHKEY Type . . . . . . . . . . . . . . . . : TYPE *PRIMARY Key . . . . . . . . . . . . . . . . . : KEY ORHNBR Number of fields in key . . . . . . . : 1 Key length . . . . . . . . . . . . . : 5 Referential Constraint Constraint . . . . . . . . . . . . . . : CST ORDERHDRCNBR Type . . . . . . . . . . . . . . . . : TYPE *REFCST Check pending . . . . . . . . . . . . : NO Constraint state . . . . . . . . . . : STATE ESTABLISHED *ENABLED Parent File Description File . . . . . . . . . . . . . . . . : PRNFILE CUSTOMER Library . . . . . . . . . . . . . . : LIB ORDENTL Parent key . . . . . . . . . . . . . : PRNKEY CUSNBR Foreign key . . . . . . . . . . . . . . : FRNKEY CUSNBR Delete rule . . . . . . . . . . . . . . : DLTRULE *RESTRICT Update rule . . . . . . . . . . . . . . : UPDRULE *RESTRICT Chapter 3. Referential integrity 63 Figure 3-24 Referential constraints from DSPDBR on the parent file As you can see by comparing the Constraint Description line (in bold) from Figure 3-23 and the last line in bold in Figure 3-24, the DSPFD and DSPDBR commands provide complete information about the constraints involving the physical files in question. Catalog inquiry DB2 UDB for iSeries provides a system-wide catalog. The SQL catalog is a set of views in the QSYS2 library built over the cross-reference files where DB2 UDB for iSeries maintains all information related to the structure and the contents of all database files. The catalog also keeps information related to the physical file constraints. You can retrieve any information you need about the constraints defined over your database files using the system views provided in the QSYS2 library:  SYSCST: General information about constraints. The underlying catalog tables are QADBFCST and QADBXREF.  SYSCSTCOL: Information about the columns referenced in a constraint. This is a view defined over the QADBCCST and QADBIFLD catalog tables.  SYSCSTDEP: Information about the constraint dependencies on tables. The catalog tables involved are QADBFCST and QADBXREF.  SYSKEYCST: Information about the primary, unique, and foreign keys. The underlying catalog tables are QADBCCST, QADBIFLD, and QADBFCST.  SYSREFCST: Information about referential constraints from the cross-reference file table QADBFCST. Display Spooled File File . . . . . : QPDSPDBR Page/Line 1/1 Control . . . . . Columns 1 - 78 Find . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+... 5/16/01 Display Data Base Relations DSPDBR Command Input File . . . . . . . . . . . . . . . . . . . : FILE ORDERHDR Library . . . . . . . . . . . . . . . . . : ORDENTL Member . . . . . . . . . . . . . . . . . . : MBR *NONE Record format . . . . . . . . . . . . . . . : RCDFMT *NONE Output . . . . . . . . . . . . . . . . . . : OUTPUT * Specifications Type of file . . . . . . . . . . . . . . . : Physical File . . . . . . . . . . . . . . . . . . . : ORDERHDR Library . . . . . . . . . . . . . . . . . : ORDENTL Member . . . . . . . . . . . . . . . . . : *NONE Record format . . . . . . . . . . . . . . : *NONE Number of dependent files . . . . . . . . : Files Dependent On Specified File Dependent File Library Dependency JREF Constraint SALE ORDENTL Data TOTALSALE ORDENTL Data YEARSALE ORDENTL Data ORDERDTL ORDENTL Constraint ORDERHDRNUM Bottom F3=Exit F12=Cancel F19=Left F20=Right F24=More keys 64 Advanced Functions and Administration on DB2 Universal Database for iSeries Consider this example: SELECT * FROM SYSCST WHERE TABLE_NAME = 'ORDERDTL' AND TABLE_SCHEMA = 'ORDENTL' This query returns information at the constraint level about the constraints defined over the ORDERDTL file in the ORDENTL library. The most significant details are shown in Figure 3-25. Figure 3-25 Constraint information To see which fields constitute the key of the constraint, you have to query SYSCSTCOL. Use the previous example: SELECT * FROM SYSCSTCOL WHERE TABLE_NAME = 'ORDERDTL' AND TABLE_SCHEMA = 'ORDENTL' ORDER BY CONSTRAINT_NAME This query returns the names of the fields forming the various constraint keys of ORDERDTL file. See Figure 3-26. Figure 3-26 Constraint column information The catalog table, SYSKEYCST, keeps more detailed information regarding key fields in a physical file constraint, such as the ordinal position of the field, in the key, and this position in the table layout: SELECT *FROM SYSKEYCST WHERE CONSTRAINT_SCHEMA = 'ORDENTL' AND CONSTRAINT_NAME = 'ORDERDTL_KEYS' AND TABLE_SCHEMA = 'ORDENTL' AND TABLE_NAME = 'ORDERDTL' This statement returns the information shown in Figure 3-27. Figure 3-27 Detailed constraint key information For a referential constraint, detailed information can be selected from SYSREFCST (in the ORDERDTL case, for example): Chapter 3. Referential integrity 65 SELECT * FROM SYSREFCST WHERE CONSTRAINT_NAME = 'ORDERHDRNUM' AND CONSTRAINT_SCHEMA = 'ORDENTL' This statement returns the information shown in Figure 3-28. Figure 3-28 Referential constraint information To determine the complete definition of a referential constraint through catalog views, you need to perform a join:  From SYSREFCST, you can retrieve the name of the unique or primary key constraint identifying the parent key.  By using the name of the constraint, SYSCST provides the name and library of the corresponding parent file and the type of the constraint itself (primary key or unique constraint).  SYSCSTCOL gives the parent key (unique or primary key) fields. These actions can be expressed through the following query: SELECT C.UNIQUE_CONSTRAINT_SCHEMA , C.UNIQUE_CONSTRAINT_NAME , A.CONSTRAINT_TYPE , A.TABLE_SCHEMA , A.TABLE_NAME , C.UPDATE_RULE , C.DELETE_RULE , B.COLUMN_NAME FROM SYSCST A, SYSCSTCOL B, SYSREFCST C WHERE C.CONSTRAINT_SCHEMA = 'ORDENTL' AND C.CONSTRAINT_NAME = 'ORDERHDRNUM' AND B.CONSTRAINT_SCHEMA = C.UNIQUE_CONSTRAINT_SCHEMA AND B.CONSTRAINT_NAME = C.UNIQUE_CONSTRAINT_NAME AND A.CONSTRAINT_SCHEMA = C.UNIQUE_CONSTRAINT_SCHEMA AND A.CONSTRAINT_NAME = C.UNIQUE_CONSTRAINT_NAME GROUP BY C.UNIQUE_CONSTRAINT_SCHEMA , C.UNIQUE_CONSTRAINT_NAME , A.CONSTRAINT_TYPE , A.TABLE_SCHEMA , A.TABLE_NAME , C.UPDATE_RULE , C.DELETE_RULE , B.COLUMN_NAME The output of the previous query consists of as many rows as the parent key fields. In the example of the ORDDTL_HORD constraint (see 3.4.3, “Another example: Order Entry scenario” on page 32), the query returns the output shown in Figure 3-29. Figure 3-29 Parent key information 66 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 67 Chapter 4. Check constraint This chapter explains:  DB2 UDB for iSeries check constraints  Defining a check constraint  General considerations  Application impacts of check constraint  Check constraint management  Tips and techniques 4 68 Advanced Functions and Administration on DB2 Universal Database for iSeries 4.1 Introduction One of the main contributions of the SQL-92 standard is the specification of a rich collection of integrity constraints. The constraints in SQL-92 can be classified into three categories:  Domain or table constraints  Referential integrity constraints  General assertions Each of these constraints are explained in the following sections. 4.1.1 Domain or table constraints Table or domain constraints in SQL-92 are used to enforce restrictions on the data allowed in particular columns of particular tables. Any column in a table may be declared as NOT NULL. This indicates that null values are not permissible for that column. In addition, a set of one or more columns may be declared as UNIQUE. This indicates that two rows may not have the same values for certain columns, which are those that form the key for the table. Each table also can have, at most, one designated PRIMARY KEY consisting of a set of one or more columns. Primary keys must be both unique and not null. The permissible values of a column may also be restricted by means of a CHECK constraint. A CHECK clause specifies a condition that involves the column whose values are restricted. Semantically, a CHECK constraint is valid if the condition evaluates to true or unknown for every row in the table. 4.1.2 Referential integrity constraints A referential integrity constraint involves two tables called the parent table and the dependent table. Intuitively, every row in the referencing table must be a “child” of some row in the referenced table. Referential integrity disallows “orphans” that are created by insertions (of child rows), updates (of child or parent rows), or deletions (of parent rows). Referential integrity can be violated by insertions or updates to the referencing table or by updates or deletions to the referenced table. 4.1.3 Assertions Assertions in SQL-92 constraints provide the ability for expressing general constraints that may involve multiple tables. As in CHECK constraints, the condition that is evaluated can be an arbitrary SQL predicate. The assertion is satisfied if the condition evaluates to true or unknown. This chapter describes how DB2 UDB for iSeries supports the CHECK constraint that is part of the table constraints of SQL-92. Note: New function was added in V4R2M0 to allow 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. Chapter 4. Check constraint 69 4.2 DB2 UDB for iSeries check constraints Check constraints in DB2 UDB for iSeries let you ensure that users authorized to change a column's value use only values that are valid for that column. It ensures that the value being entered in a column of a table belongs to the set of valid values defined for that field. For example, you may specify that the “legal” values for an employee evaluation field defined as an integer might be 2, 3, 4, or 5. Without the check constraint, users can enter any integer value into such a field. To ensure that the actual value entered is 2, 3, 4, or 5, you must use a trigger or code the rule in your application program. A check constraint increases the data integrity because the constraints are validated against every interface (RPG, Data File Utility, ODBC client programs, Interactive SQL, etc.) that updates or inserts database records. The operating system enforces the rules, not the application program. For this reason, there is no way to bypass any control, and the integrity is assured. The programmer no longer has to add this verification code to every application program that updates or inserts a database record. A check constraint is associated with a file and contains check conditions that are enforced against every row in the file. Whenever a row is inserted or updated, the database manager evaluates the check condition against the new or changed row to guarantee that all new field values are valid. If invalid values are found, the database manager rejects the insert or update operation. Here are some examples:  Range checking: The field value must be between 1 and 50  Domain or value checking: The field can be one of the following values: 1, 3, 5, 7, or 9  Field comparisons: total_sales < credit_limit Remember that the check constraint is valid if the condition evaluates to true or unknown. Some of the current alternatives to the check constraint are to:  Code the constraints in the application programs. This may give more flexibility in coding the business rules, but the rules are not enforced in all of the iSeries interfaces (for example, DFU or ODBC client programs).  Use the DDS keywords (COMP, RANGE, VALUES) in the display and logical files. The problem with this approach is that the rules are only enforced in green-screen applications.  Use before triggers. In this case, the rule is enforced on all interfaces, but it is not a part of a database table. It is not a declarative approach. There are some obvious advantages for using the CHECK constraint option in the iSeries server:  There is much less coding to do if the business rules are defined only once in the database.  The administration is much easier because the business rules become part of the database.  The data integrity of the database is improved because the rules are enforced on all interfaces.  Since the database manager is performing the validation, the enforcement is more efficient than the application level enforcement. 70 Advanced Functions and Administration on DB2 Universal Database for iSeries 4.3 Defining a check constraint This section discusses the interfaces and commands that you can use to add a check constraint. We refer to the native interface and the SQL interface. Let's start with the native CL command ADDPFCST. In the following example, we define a check constraint in the CUSTOMER file, where the customer_total (CUSTOT) cannot be greater than the customer_credit_limit (CUSCRD). Enter the ADDPFCST command, and press F4. The display shown in Figure 4-1 appears. Figure 4-1 Prompt for the ADDPFCST command Note that the type of constraint is *CHKCST. The name of the constraint must be unique in the library where it is being created. The display shown in Figure 4-2 prompts you for the check condition. Figure 4-2 Check condition for a check constraint The condition clause of a check constraint can be up to 2000 bytes long. Add PF Constraint (ADDPFCST) Type choices, press Enter. File . . . . . . . . . . . . . . > CUSTOMER Name Library . . . . . . . . . . . > ORDAPPLIB Name, *LIBL, *CURLIB Constraint type . . . . . . . . > *CHKCST *REFCST, *UNQCST, *PRIK Constraint name . . . . . . . . CUSCRD_LIMIT_CUSTOT F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys Add PF Constraint (ADDPFCST) Type choices, press Enter. Check constraint . . . . . . . . > 'CUSTOT <= CUSCRD' F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys Chapter 4. Check constraint 71 When you add a constraint to an existing file, the existing records must not violate the constraint condition. If the system finds records violating the constraint, a diagnostic message is issued for the first 25 rows that failed the check, and the constraint is set to the check pending condition. The display in Figure 4-3 shows the diagnostic message issued by the system. Figure 4-3 Detailed message for CPD32D3 You can use the Relative Record Number (RRN) scalar function to identify the record that is violating the constraint. This is accomplished by typing the following command in an Interactive SQL session: SELECT rrn(customer), cusnbr FROM customer Figure 4-4 shows the results of this query. In this case, the record with the customer number equal to 100 violates the constraint since its relative record number happens to be 1. Important: The condition clause of a check constraint is a restricted form of the search-condition of the WHERE and HAVING clauses of the SQL statements. You do not need the DB2 Query Manager and SQL Development Kit for iSeries product to define the condition through the native interface. Additional Message Information Message ID . . . . . . : CPD32D3 Severity . . . . . . . : 20 Message type . . . . . : Diagnostic Date sent . . . . . . : 10/16/01 Time sent . . . . . . : 11:20 Message . . . . : Field values are not valid for check constraint. Cause . . . . . : Check constraint CUSCRD_LIMIT_CUSTOT for file CUSTOMER in library ORDAPPLIB is in check pending. The constraint is in check pending because record 1 in the file has a field value that conflicts with the check constraint expression. If the record number for the file is 0, then the record either cannot be identified or does not apply to the check pending status. Recovery . . . : Use the CHGPFCST command for the file to disable the constraint. Use the DSPCPCST command for the file to display the records that are causing the constraint to be in check pending. Update the file to make sure each field value does not conflict with the check constraint expression. Press Enter to continue. F3=Exit F6=Print F9=Display message details F10=Display messages in job log F12=Cancel F21=Select assistance level 72 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 4-4 Query result Now let's see how to create a check constraint using the SQL interface. The SQL interface provides two ways to create a check constraint:  CREATE TABLE statement, which has the constraint clause  ALTER TABLE statement, which allows a table constraint to be added to an existing table with the ADD constraint option At creation time, you can define the check constraint with the SQL CREATE TABLE statement: CREATE TABLE ORDAPPLIB/CUSTOMER (CUSTOMER_NUMBER FOR COLUMN CUSNBR CHAR(5) NOT NULL WITH DEFAULT, CUSTOMER_NAME FOR COLUMN CUSNAM CHAR (20) NOT NULL WITH DEFAULT, ................ ................ ................ CONSTRAINT CUSCRD_LIMIT_CUSTOT CHECK (CUSTOT <= CUSCRD )) The CREATE TABLE statement also allows you to define a check constraint at the column level. The restriction is that a column-level constraint cannot reference any other column. Here is an example: CREATE TABLE ORDAPPLIB/EMPLOYEE ( EmpID# CHAR(2), EmpName CHAR(30), Salary INTEGER CONSTRAINT salarychk CHECK(Salary > 0 AND Salary < 10000), Bonus INTEGER CHECK(Bonus >=0), CONSTRAINT BonusSalaryChk CHECK (bonus<= salary)) Display Data Data width . . . . . . : Position to line . . . . . Shift to column . . . . . . ....+....1....+....2.... RRN ( CUSTOMER ) CUSNBR 1 00100 2 00001 3 00003 5 00009 6 00990 7 00008 8 00500 9 00007 11 55555 12 00400 13 00201 14 00101 15 00102 16 00103 17 00045 More F3=Exit F12=Cancel F19=Left F20=Right F21=Split Chapter 4. Check constraint 73 There is an advantage that SQL CREATE TABLE has over CRTPF when you define constraints. CREATE TABLE allows both the DB file object and associated constraints to be created on a single command. CRTPF is always a two-step process: 1. Use CRTPF to create the DB object. 2. Use ADDPFCST to create your constraints. You can also add check constraints to existing files. This is illustrated in the following example: ALTER TABLE ORDAPPLIB/CUSTOMER ADD CONSTRAINT CUSCRD_LIMIT_CUSTOT CHECK(CUSTOT <= CUSCRD) When you are adding a constraint to an existing file, the existing records must not violate the constraint. If the system finds records violating the constraint, an error is issued, similar to the one shown in Figure 4-5, and the constraint is not created. Figure 4-5 Additional message for SQL0544 In this case, you must correct the records that are violating the constraint before you try to create it again. After the constraint is successfully created, you can see its definition by using the DSPFD ORDAPPLIB/CUSTOMER command. Press the Page Down key to see the display shown in Figure 4-6. Additional Message Information Message ID . . . . . . : SQL0544 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Message . . : CHECK constraint CUSCRD_LIMIT_CUSTOT cannot be added Cause . . . : Existing data in the table violates the CHECK constraint rule in constraint CUSCRD_LIMIT_CUSTOT. The constraint cannot be added Recovery . : Change the data in the table so that it follows the constraint specified in CUSCRD_LIMIT_CUSTOT. Try the request again. Press Enter to continue. F3=Exit F6=Print F9=Display message details F10=Display messages in job log F12=Cancel F21=Select assistance level Important: The behavior of the ADDPFCST command is different than the ALTER TABLE SQL statement when they encounter violating records during the creation of the check constraint. In the first case, the constraint is added, while in the second case, it is not added. This is also true for the CREATE TABLE statement. The SQL interface complies with the SQL-92 standard, while the native interface follows the traditional OS/400 approach. 74 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 4-6 Spooled file for the DSPFD command You can also see constraints associated with the file by entering the WRKPFCST command. The display shown in Figure 4-7 appears. Figure 4-7 Result of the WRKPFCST command Let’s look at some examples: ALTER TABLE ORDAPPLIB/STOCK 1 ADD CONSTRAINT PRODUCT_PRICE_MIN CHECK(PRODUCT_PRICE > 0 AND PRODUCT_AVAILABLE_QTY >= 0) Display Spooled File File . . . . . : QPDSPFD Page/Line 2/21 Control . . . . . Columns 1 - 78 Find . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. Constraint Description Primary Key Constraint Constraint . . . . . . . . . . . . . . : CST QSYS_CUSTOMER_ Type . . . . . . . . . . . . . . . . : TYPE *PRIMARY Key . . . . . . . . . . . . . . . . . : KEY CUSNBR Number of fields in key . . . . . . . : 1 Key length . . . . . . . . . . . . . : 5 Check Constraint Constraint . . . . . . . . . . . . . . : CST CUSTOT_LIMITED Type . . . . . . . . . . . . . . . . : TYPE *CHKCST Check pending . . . . . . . . . . . . : NO Constraint state . . . . . . . . . . : STATE ESTABLISHED *ENABLED Check constraint expression . . . . . . : CHKCST CUSTOT <= CUSCRD F3=Exit F12=Cancel F19=Left F20=Right F24=More keys Work with Physical File Constraints Type options, press Enter. 2=Change 4=Remove 6=Display records in check pending Opt Constraint File Library Type State QSYS_CUSTO > CUSTOMER ORDAPPLIB *PRIKEY CUSTOT_LIM > CUSTOMER ORDAPPLIB *CHKCST EST/ENB Parameters for options 2, 4, 6 or command ===> F3=Exit F4=Prompt F5=Refresh F9=Retrieve F12=Cancel F15=Sort F16=Repeat position to F17=Position to F22=Display constraint name Chapter 4. Check constraint 75 ALTER TABLE ORDAPPLIB/CUSTOMER 2 ADD CONSTRAINT CUSTOMER_TYPE CHECK(CUSTYP IN ('01', '02', '03, 'O4','05, '08', '10')) ALTER TABLE ORDAPPLIB/EMPLOYEE 3 ADD CONSTRAINT SALARY_RANGE CHECK(EMPSAL BETWEEN 1000 AND 300000) ALTER TABLE ORDAPPLIB/EMPLOYEE_TRANSAC 4 ADD CONSTRAINT HOURS_LABORED CHECK(ORDINARY_HOURS + EXTRA_HOURS < 168) 4.4 General considerations This section highlights some considerations that you must take into account when you define CHECK constraints. Let's start with the condition clause of the check constraint. The condition clause of a check constraint can contain any expression or functions allowed on an SQL WHERE clause with the following exceptions:  You cannot reference columns of a different table.  You cannot reference rows of the same table, which means you cannot use the following column functions: – SUM – AVERAGE – MIN – MAX – COUNT  Subqueries are not allowed.  Host variables are not allowed.  Parameter markers are not allowed.  The following special registers cannot be used: – CURRENT TIMEZONE – CURRENT SERVER – USER The condition clause of a check constraint can reference more than one column of the same record of the file. Explanation: 1 This check constraint in the STOCK file checks that every price of a product has a price greater than 0 and, at the same time, that the quantity available of a product is greater than or equal to 0. 2 This check constraint in the CUSTOMER file checks that each customer is associated with one of the enumerated types. 3 This check constraint in the EMPLOYEE file checks that the salary of an employee is in the range of $1,000 and $300,000. 4 This check constraint in the EMPLOYEE_TRANSAC file checks that an employee cannot work more than 168 hours in a week. Note the calculations involving two fields of the same row. 76 Advanced Functions and Administration on DB2 Universal Database for iSeries DB2 UDB for iSeries does not prevent conflicting constraints from being defined. Suppose you just created the CUSTOMER file and then you define the following two CHECK constraints before you enter the first record: ALTER TABLE ORDAPPLIB/CUSTOMER ADD CONSTRAINT IMPAIR_TYPE CHECK(CUSTYP IN ('01', '03', '05, 'O7','09')) ALTER TABLE ORDAPPLIB/CUSTOMER ADD CONSTRAINT PAIR_TYPE CHECK(CUSTYP IN ('02', '04', '06, 'O8','10')) In the preceding example, the two constraints that are defined prevent the insertion of any record to the CUSTOMER file. If one check condition is valid, the other one is not valid. Let's try to insert the following record into the CUSTOMER file: INSERT INTO ORDAPPLIB/CUSTOMER (CUSNBR, CUSTYP) VALUES('00001', '01') The message shown in Figure 4-8 is displayed. Figure 4-8 Additional message for SQL0545 If we change the CUSTYP value to “02”, the other constraint is violated. Other considerations of which you should be aware are:  The constraint name has to be unique across all constraint types that exist in the file's library.  A table or file has a limit of 300 combined constraints (referential constraints, primary, unique, and check constraints).  Only single member files are supported. Additional Message Information Message ID . . . . . . : SQL0545 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Message . . . . : INSERT or UPDATE not allowed by CHECK constraint. Cause . . . . . : The value being inserted or updated does not meet the criteria of CHECK constraint PAIR_TYPE. The operation is not allowed. Recovery . . . : Change the values being inserted or updated so that CHECK constraint is met. Otherwise, drop the CHECK constraint PAIR_TYPE Press Enter to continue. F3=Exit F6=Print F9=Display message details F10=Display messages in job log F12=Cancel F21=Select assistance leve Important: It is the developer’s responsibility to ensure that check constraints are not mutually exclusive. Chapter 4. Check constraint 77  When you add a check constraint, DB2 UDB for iSeries makes an exclusive lock on the table for the verification of the condition clause. 4.5 Check constraint integration into applications Before check constraint support was implemented in DB2 UDB for iSeries, check constraint validations had to be performed by the application program. Now you can let DB2 UDB for iSeries ensure your data integrity both through the referential integrity and check constraint definitions. Using the check constraint definitions may improve your application's performance. The domain checks are much more efficient and quicker when performed at the operating system level rather than by an application code. However, once a programmer has defined check constraints and referential constraints to the DBMS, the existing integrity checks should be removed from the application program. Otherwise, the application performance will degrade since the same checking is being performed twice (at the application level and at the system level). 4.5.1 Check constraint I/O messages The enforcement of the check constraint definitions is done when:  An insert is being done to the table with check constraints.  An update is being done to the table with check constraints.  A delete is being done on a parent table that has a referential integrity constraint defined with their dependent tables and a SET DEFAULT or SET NULL is specified. A new message has been defined to handle the error occurring during a check constraint enforcement. Instead of coding domain checks in the application programs, coding is needed for handling check constraint error conditions. The text of the message is shown in Figure 4-9. Note: The verification for adding a check constraint to large files can take some time. In our test environment, it took about 10 minutes to verify a 5 million row table on a 50S machine. 78 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 4-9 Detailed message for CPF502F 4.5.2 Check constraint application messages To handle these messages in SQL procedures or in embedded SQL statements, new SQL codes have been provided for this purpose. In Figure 4-10, you can see the new messages added to the SQL run time. Figure 4-10 SQL messages for the check constraint Display Formatted Message Text System: SY Message ID . . . . . . . . . : CPF502F Message file . . . . . . . . : QCPFMSG Library . . . . . . . . . : QSYS Message . . . . : Check constraint violation on member CUSTOMER. Cause . . . . . : The operation being performed on member CUSTOMER file CUSTOMER in library ORDAPPLIB failed. Constraint PAIR_TYPE prevents record number 2 from being inserted or updated because the field value conflicts with the check constraint. If the record number is zero, then the error occurred on a insert operation. The reason code is 01. The reason codes and their meanings are as follows: 01 - Violation due to insert or update operation. 02 - Violation caused by a referential constraint. Recovery . . . : Either specify a different file, change the file, or change the program. Then try your request again. Possible choices for replying to message . . . . . . . . . . . . . . . : C -- The request is canceled. Press Enter to continue. F3=Exit F11=Display unformatted message text F12=Cancel Display Message Descriptions System: SYS Message file: QSQLMSG Library: QSYS Position to . . . . . . . Message ID Type options, press Enter. 5=Display details 6=Print Op Message ID Severity Message Text SQL0543 30 Constraint &1 conflicts with SET NULL or SET Default SQL0544 30 CHECK constraint &1 cannot be added. 5 SQL0545 30 INSERT or UPDATE not allowed by CHECK constraint. SQL0546 30 CHECK condition of constraint &1 not valid. SQL0551 30 Not authorized to object &1 in &2 type *&3. SQL0552 30 Not authorized to &1. SQL0557 30 Privilege not valid for table or view &1 in &2 SQL0569 10 Not all requested privileges revoked from object SQL0570 10 Not all requested privileges to object &1 in &2 SQL0573 30 Table &1 in &2 does not have a matching parent F3=Exit F5=Refresh F12=Cancel Chapter 4. Check constraint 79 The SQL message, SQL0545, is the most important for the application programmers. The detailed description is shown in Figure 4-11. Figure 4-11 Detailed message for SQL0545 SQL0545 has an SQLSTATE of “23513”, which is useful for a condition or handler declarations in SQL procedures. Refer to Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503, for a detailed discussion on SQL procedures. Now let's see how the errors are reported in ILE programs:  In ILE RPG, you can check the new status 1022, which handles the CPF502F message.  In ILE COBOL, the file status “9W” handles the check constraint violation.  ILE C maps these messages to the existing error codes.  OPM programs map these messages to the existing generic error codes. 4.6 Check constraint management This section discusses the management considerations of the check constraints. The managing part of a check constraint is the same as a referential integrity constraint. The commands to manage the constraints are exactly the same as for referential integrity. These commands are:  Change Physical File Constraint (CHGPFCST)  Display Check Pending Constraint (DSPCPCST)  Work with Physical File Constraint (WRKPFCST)  Edit Check Pending Constraint (EDTCPCST)  Remove Physical File Constraint (RMVPFCST) For a complete description of these commands, refer to 3.8, “Referential integrity constraint management” on page 52. Display Formatted Message Text System: SYSTEM1 Message ID . . . . . . . . . : SQL0545 Message file . . . . . . . . : QSQLMSG Library . . . . . . . . . : QSYS Message . . . . : INSERT or UPDATE not allowed by CHECK constraint. Cause . . . . . : The value being inserted or updated does not meet the criteria of CHECK constraint &1. The operation is not allowed. Recovery . . . : Change the values being inserted or updated so that the CHECK constraint is met. Otherwise, drop the CHECK constraint &1. Press Enter to continue. F3=Exit F11=Display unformatted message text F12=Cancel 80 Advanced Functions and Administration on DB2 Universal Database for iSeries 4.6.1 Check constraint states A check constraint is the same as a referential constraint in terms of its possible states. The four states of a check constraint are:  Defined and enabled  Defined and disabled  Established and enabled  Established and disabled Each term is explained in the following list: Defined The constraint definition has been added to the file, but not all the pieces of the file are there for enforcement. For example, the file's member does not exist. Established The constraint definition has been added to the file, and all the pieces of the file are there for enforcement. Enabled The check constraint is enforced if the constraint is also established. If the constraint is defined, the file member does not exist for enforcement. Disabled The constraint definition is not enforced regardless of whether the constraint is established or defined. Use the WRKPFCST command to see the constraints defined for the CUSTOMER file. Figure 4-12 Physical file constraints There are two check constraint definitions for this file. One is established and enabled, and the other one is established and disabled. At the same time, the constraint that is disabled has some records in a check pending condition. If you want to see the records that are causing the check condition, type option 6 next to the constraint with the check pending status. Figure 4-13 shows the job log of the job in which the ADDPFCST command was executed and caused the check pending condition. Work with Physical File Constraints Type options, press Enter. 2=Change 4=Remove 6=Display records in check pending Check Opt Constraint File Library Type State Pending QSYS_CUSTO > CUSTOMER ORDAPPLIB *PRIKEY CUSTOT_LIM > CUSTOMER ORDAPPLIB *CHKCST EST/ENB NO CUSCRD_VS_ > CUSTOMER ORDAPPLIB *CHKCST EST/DSB YES Parameters for options 2, 4, 6 or command ===> F3=Exit F4=Prompt F5=Refresh F9=Retrieve F12=Cancel F15=Sort F16=Repeat position to F17=Position to F22=Display constraint name Chapter 4. Check constraint 81 Figure 4-13 Check constraint messages 4.6.2 Save and restore considerations When a table is saved, all of its check constraints are saved. For restores, if the check constraints are on the save media and the saved file does not exist, the check constraint is added to the file. However, if the file exists in the system, any check constraint on the SAVE media is ignored. If you are restoring data and the data results in a check constraint violation, the data is restored and the constraint goes into a check pending condition. The state of the constraint stays the same. When you run the CRTDUPOBJ command from a file with check constraints, the check constraints are propagated from the original file to the new file. Both the constraint state and the check pending status are replicated from the original to the destination file. Display All Messages System: RC Job . . : QPADEV0004 User . . : HERNANDO Number . . . : 00 CHECK constraint CUSTOT_LIMIT_CUSCRD cannot be added. 3 > ADDPFCST FILE(ORDAPPLIB/CUSTOMER) TYPE(*CHKCST) CST(CUSCRD_VS_CUSTOT ST('CUSCRD < CUSTOT') Field values are not valid for check constraint. 1 Field values are not valid for check constraint. Field values are not valid for check constraint. Field values are not valid for check constraint. Field values are not valid for check constraint. Field values are not valid for check constraint. Field values are not valid for check constraint. Field values are not valid for check constraint. Constraint is in check pending. 2 Constraint was added. 3 1 constraint(s) added to file CUSTOMER but constraint(s) in error. Press Enter to continue. F3=Exit F5=Refresh F12=Cancel F17=Top F18=Bottom Notes: 1 The condition is checked for every single record in the file. In this case, there are several records that do not meet the condition. 2 Since there are records that violate the condition, a check pending status is set for the constraint. 3 Since the native interface has been used, the constraint is added to the file. 82 Advanced Functions and Administration on DB2 Universal Database for iSeries 4.7 Tips and techniques We complete this chapter with some tips for those of you who are responsible for moving the business rules to the database. This applies to both check constraints and referential integrity constraints. Start identifying and isolating the application code that is responsible for the referential integrity and check constraint checks. These pieces of code that are duplicated in several different programs should be rewritten in ILE procedures that can be bound and reused by several application programs. These procedures can then be defined as trigger programs to make the concerning checks. At the same time, start to clean up your data. This can be done by queries that highlight records that are violating the constraints, or you can natively define the constraints and use the WRKPFCST command to see the records that are in check pending. At this step, carefully schedule the time for these queries so you do not interrupt the normal operation of the business. Once your data is clean, it is time to enable all the constraints and remove the trigger programs that are no longer needed. Before you decide on your check constraint naming convention, consider this tip: It might make it easier to turn system constraint errors into meaningful user feedback by defining your constraint name to be the message number that you really want displayed to the end user. When you define the check constraints, a question may arise: Is it better to have one large check constraint or multiple check constraints? When there is more than one check constraint for a file, the system implicitly ANDs the result of each constraint during the enforcement phase. From the performance point of view, one large constraint performs slightly better than multiple check constraints because the implicit AND processing is eliminated. On the other hand, it is easier to manage and identify multiple but simpler check constraints. It is easier to identify problems when the system detects violations of the constraint. It is up to the application programmer or the DBA to decide which approach is better. Let's look at an example: ALTER TABLE ORDAPPLIB/STOCK ADD CONSTRAINT PRODUCT_PRICE_MIN CHECK(PRODUCT_PRICE > 0) ALTER TABLE ORDAPPLIB/STOCK ADD CONSTRAINT PRODUCT_AVAIL_MIN CHECK(PRODUCT_AVAILABLE_QTY >= 0) ALTER TABLE ORDAPPLIB/STOCK ADD CONSTRAINT PRODUCT_MIN_STOCK CHECK(PRODUCT_MIN_STOCK_QTY >= 0) These three check constraints can be combined in one constraint as shown in the following example: ALTER TABLE ORDAPPLIB/STOCK ADD CONSTRAINT STOCK_CONSTRAINTS CHECK(PRODUCT_PRICE > 0 AND PRODUCT_AVAILABLE_QTY >= 0 AND PRODUCT_MIN_STOCK_QTY >= 0) Note: Keep in mind that, if you have multiple check constraints that are violated on an insert operation, only a single error message is returned. The system stops enforcement and signals the error on the first check constraint violation it finds. © Copyright IBM Corp. 1994, 1997, 2000, 2001 83 Chapter 5. DRDA and two-phase commitment control This chapter presents:  DRDA evolution from DRDA-1 to DRDA-2  DRDA-2 connection management  Two-phase commitment control  SQL support for DRDA-2  Coexistence between DRDA-1 and DRDA-2  Recovering from failures  Application design considerations  A DRDA-2 program example  DRDA over TCP/IP  DB2 Connect setup over TCP/IP 5 84 Advanced Functions and Administration on DB2 Universal Database for iSeries 5.1 Introduction to DRDA The Distributed Relational Database Architecture (DRDA) represents IBM’s proposal in the arena of distributed database access. This architecture defines the rules, the protocols, and the semantics for writing programs implementing distributed data access. All the platforms participating in this architecture must comply with these rules and definitions. This chapter does not discuss, in detail, every component of DRDA. The purpose is to provide you with a brief outlook on DRDA evolution and to describe the implementation of DRDA in the DB2 UDB for iSeries environment. 5.1.1 DRDA architecture Distributed Relational Database Architecture allows you to access data in a distributed relational database environment by using SQL statements in your applications. The architecture has been designed to allow distributed data access for systems in like and unlike operating environments. This means that your applications can access data residing on homogeneous or heterogeneous platforms. DRDA is based on these IBM and non-IBM architectures:  SNA Logical Unit Type 6.2 (LU 6.2)  TCP/IP Socket Interface  Distributed Data Management (DDM) architecture  Formatted Data Object Content Architecture (FD:OCA)  Character Data Representation Architecture (CDRA) On the iSeries server, DRDA is part of DB2 UDB for iSeries, which is part of the OS/400 operating system. 5.1.2 SQL as a common DRDA database access language SQL has become the most common data access language for relational databases in the industry. SQL was chosen as part of DRDA because of its high degree of standardization and portability. In a distributed environment, where you want to access data at remote locations, the SQL requests are routed to the remote systems and they are executed remotely. Prior to sending the remote SQL request, a DRDA application must establish a connection with the remote relational database where the data is located. This is the purpose of the CONNECT SQL statement provided by DRDA. 5.1.3 Application requester and application server In a distributed relational database environment, the system running the application and sending the SQL requests across the network is called an application requester (AR). Any remote system that executes SQL requests coming from the application requester is also known as an application server (AS). Some platforms can participate in a distributed database environment as both an application requester and an application server. The diagram in Figure 5-1 shows the current application requester and application server capabilities of different database management systems. Chapter 5. DRDA and two-phase commitment control 85 Figure 5-1 Current support for application requester (AR) and application server (AS) Note: Currently, the DB2 Universal Database and DB2 Connect offer different levels of DRDA implementation depending on the OS platform. The support level equivalent to that of OS/400 is available for AIX, Windows NT, HP-UX, and OS/2. Consult the appropriate documentation for the latest additions. 5.1.4 Unit of work Unit of work (UoW), unit of recovery (UR), or logical transaction are different ways to refer to the same concept. The DRDA terminology prefers the term unit of work. Unit of work refers to a sequence of database requests that carry out a particular task, such as in a banking application when you transfer money from your savings account to your checking account. This task has its logical independence and should be treated “atomically”, which means that either all its components are executed or none of them are. You do not want your savings balance to be updated without your checking balance being updated too. A unit of work is generally terminated by a commit operation if the entire task completes successfully. For more information about UoW, refer to Distributed Database Programming, SC41-5702. DRDA defines the following levels of service regarding UoW:  Level 0, Remote Request (RR): – One request within one UoW to one DBMS. Remember that DB2 UDB for iSeries provides one DBMS. DB2 for OS/390 or DB2 Universal Database can provide multiple DBMSs on the same system. – Remote request was available before DRDA, thanks to DDM support.  Level 1, Remote Unit of Work (RUW): – One or more SQL requests within one UoW to a single DBMS. – Switching to a different location is possible, but a new UoW must be started and the previous one must be completed. – Remote Unit of Work is supported by both the SNA and TCP/IP implementations of DRDA.  Level 2, Distributed Unit of Work (DUW): – Many SQL requests within one UoW to several DBMS. – Two-phase commit is required. – A single request may reference objects residing on the same DBMS. DB2 for MVS DB2 for MVS DB2 for VM DB2 for VM DB2 for iSeries DB2 for iSeries DB2 UDB DB2 UBD Non - IBM Non - IBM AR (Local DB) AS (Remote DBs) 86 Advanced Functions and Administration on DB2 Universal Database for iSeries – The Distributed Unit of Work is currently supported only by the SNA implementation of DRDA.  Level 3, Distributed Request (DR): – In addition to the services provided by Distributed UoW, DR allows a single SQL request to include references to multiple DBMSs, such as joining tables stored at different locations. – This is an architected level and will be available in the future. The diagram in Figure 5-2 may be helpful in understanding the levels of DRDA. Figure 5-2 Architected service levels of DRDA 5.1.5 Openness Many non-IBM relational database providers (for example, Informix, Oracle Sybase, XDB Systems, and others) implement different levels of DRDA support in their products. DRDA offers the ability to access and exchange data in like and unlike system environments, therefore, contributing to the openness of IBM platforms in regard to interoperability. 5.2 Comparing DRDA-1 and DRDA-2 The difference between DRDA-1 and DRDA-2 from an application point of view is illustrated in Figure 5-3. DRDA-2 introduces:  Two-phase commit protocol to keep multiple databases in synchronization  Synchronization Point Manager (SPM) to manage the two-phase commit  A new connection management  New SQL statements to manage multiple connections DRDA-1 cannot maintain multiple connections in one unit of work. To connect to a different application server, the application must be in a connectable state, which is achieved by ending the unit of work with a COMMIT or ROLLBACK statement. Distributed Request (DR) . L . E . V . E . L . 3 . . . . . . future SQL Request SQL Request SQL Request SQL Request . L . E . V . E . L . 2 . . . . V3R1 Zurich Rochester Seoul . L . E . V . E . L . 1 . . V2R1 .1 Distributed Unit Of Work (DUW) Remote Unit Of Work (RUW) Remote Request (RR) . . . . . . Chapter 5. DRDA and two-phase commitment control 87 DRDA-2 can connect to multiple servers without losing the existing connections. A single unit of work can span multiple servers. Keep in mind that a single SQL statement still cannot address more than one server at a time. For example, it is still not possible to join two files residing on different systems. Figure 5-3 Remote Unit of Work (DRDA-1) versus Distributed Unit of Work (DRDA-2) Figure 5-3 shows three units of work. The arrows pointing to the left indicate the only possible way to access data in a DRDA-1 application. The arrows pointing to the right show the new flexibility of a DRDA-2 application accessing multiple systems in the same UoW. Let's consider, for example, the Rochester system on the right-hand side. It issues three requests: Request2, Request4, and Request6. Each of these requests belong to a different unit of work. The Rochester system on the left-hand side also issues three requests (Request 3, Request 4, and Request 5), each targeting a different application server within one UoW. 5.3 DRDA-2 connection management Connection management refers to the set of mechanisms by which you can direct your database requests in a distributed database network. DRDA-2 has enhanced connection management, which allows an application program to keep alive the existing connections and perform I/O operations on multiple relational databases within the same unit of work. Currently, this architected level of DRDA is available only over SNA. It will also be available in DRDA- 1 DRDA-2 iSeries iSeries iSeries iSeries iSeries iSeries Application Servers Application Requester Application Servers Seoul Rochester Zurich or any other "DRDA" system UOW 1 Request 1 Request 2 UOW 2 Request 3 Request 4 Request 5 UOW 3 Request 6 Request 7 Zurich Rochester Seoul 88 Advanced Functions and Administration on DB2 Universal Database for iSeries future releases over the TCP/IP implementation of DRDA. There are also some changes to the way the CONNECT statement behaves in DRDA-2 if you compare it with the DRDA-1 CONNECT behavior. In DRDA-1, the current connection is destroyed when a new CONNECT statement is issued. In DRDA-2, another CONNECT statement does not destroy the existing connections. A new one is created instead and becomes the current connection. Also, if you issue a CONNECT statement toward an existing connection, you receive negative SQLCODE if your programs use DRDA-2 connection management and the current connection does not change. In a DRDA-1 program, this operation is legitimate and does not return an error. 5.3.1 Connection management methods As we previously indicated, DB2 UDB for iSeries allows you to use both the DRDA-1 connection management method and the DRDA-2 connection manager. When you create your SQL program or module, you specify which connection method you want to use:  DRDA-1 connection management is set on the CRTSQLxxx command by specifying RDBCNNMTH(*RUW).  DRDA-2 connection management is specified on the CRTSQLnnn command by specifying RDBCNNMTH(*DUW), which is also the default for the creation commands. Because the connection method changes the semantics of the CONNECT statement, you must be aware of this parameter when you are recompiling existing applications, because they can behave in a different way if compiled with the *DUW option. For more details, see 5.6, “DRDA-1 and DRDA-2 coexistence” on page 95. DB2 UDB for iSeries also allows you to specify that an implicit connection must take place when the program is started. This is the purpose of the RDB parameter on the precompiler commands. This implicit CONNECT will be of the type specified in the RDBCNNMTH parameter. If an RDB name is specified, the connection to this remote database is established automatically at program start time. Therefore, the first re-connection statement in the program has to be SET CONNECTION. If CONNECT is initiated to this application server by the program logic, the SQL0842 message (SQLCODE = -842 - “Connection to relational database xxx already exists”) is sent to the application. Check for this SQLCODE explicitly after every CONNECT statement. In general, this SQLCODE can be ignored by the application. Remember that a CONNECT statement followed by SQLCODE = -842 does not change the current connection. 5.3.2 Connection states DRDA-2 introduces new connection states. A connection may be either held or released and current or dormant. For clarification, see Figure 5-4. Chapter 5. DRDA and two-phase commitment control 89 Figure 5-4 Connection states Figure 5-4 shows a general picture of the architecture. The application goes into an UNCONNECTED state when the current connection is destroyed. The application ends in an unconnected state if all the connections are released and a commit is performed. The CONNECT and RELEASE statements allow the application to change a connection state from held to released:  Released state: Means that a disconnect will occur at the next successful commit operation (a rollback has no affect on connections). Therefore, a released state can be thought of as a pending disconnect.  Held state: Means that a connection will not be lost at the next commit operation. A connection in the released state cannot be put back into a held state. This means that a connection may remain in a released state across unit of work boundaries if a ROLLBACK is issued. Regardless of whether a connection is in a held or released state, a connection can also be in a current or dormant state:  Current state: Means that the connection is the one used for SQL statements that are executed.  Dormant state: Means that the connection is suspended. While in this state, no SQL statements can use this connection. Nevertheless, SQL statements can always be executed against the current connection. If you want a dormant connection to become the current connection, use the SET CONNECTION SQL statement. The existing current connection will become dormant. In fact, there can be only one connection in the current state at a time. All other connections are in a dormant state. You cannot use the CONNECT statement to make a dormant connection current in a DB2 UDB for iSeries application. The semantic of the CONNECT statement is different in DB2 UDB for iSeries and DB2 for OS/390, where a CONNECT to an existing connection equates to a SET CONNECTION statement. Current H eld Released Dormant Commit Commit Commit Set Connection X Set Connection Y Set Connection Y Set C onnect oi n X Connect to Y Connect to Y Connect to X Release X Release X Unconnected Current Released Current Held Dormant Released Dormant Held Commit 90 Advanced Functions and Administration on DB2 Universal Database for iSeries When a connection goes to the dormant state, all the open cursors, locks, and prepared statements are preserved. When this connection becomes current again in the same unit of work, all locks, cursors, and prepared statements are restored to their previous values. In a network where systems at different levels coexist, you may have connections to DRDA-2 servers and to DRDA-1 servers at the same time. Connection to DRDA-1 servers must be dropped by using the DISCONNECT statement. Once disconnected, an application must connect to the database again before it can direct SQL statements to it. 5.4 Two-phase commitment control Synchronizing multiple databases requires additional effort compared to the process of keeping data consistent on a single system. Because multiple physical locations are involved, the synchronization process is split into two phases to ensure data consistency across multiple locations. The database managers involved in the distributed unit of work must make sure that either all of them commit their changes or roll all the changes back consistently. The protocol by which multiple database managers can keep their data in sync is called two-phase commitment control. In an application using two-phase commit, the COMMIT statement generates a rather complex sequence of operations that allows the various agents in the network to keep their data in a consistent state. Also, a two-phase commit protects your applications against network or system failures that may occur during the transaction. In these cases, the database managers involved in the unit of work automatically roll back their changes. As mentioned already, current DRDA-2 implementation is based on LU 6.2 architecture. When an LU 6.2 conversation supports a two-phase commitment control data flow, we say that it is a protected conversation. Some new verbs have been added to the APPC protocol to support protected conversations. You have direct access to this support on the iSeries server by using ICF files or CPI-C functions in your applications. Any LU 6.2 conversation not capable of a two-phase commitment control flow is called unprotected conversation. DRDA-1 supports only unprotected conversations. 5.4.1 Synchronization Point Manager (SPM) To control the two-phase commit flow, DB2 UDB for iSeries implements a component called Synchronization Point Manager. The SPM also controls rollback among the various protected resources. Either all changes are committed or they are rolled back. With distributed updates, sync point managers on different systems cooperate to ensure that resources reach a consistent state. The example in Figure 5-5 shows the type of information that flows between the application requesters and application servers to commit work on protected conversations. Chapter 5. DRDA and two-phase commitment control 91 Figure 5-5 Technical view of two-phase commit flow Each application requester and each application server have a sync point manager attached. DBMS participating in a Distributed Unit of Work has to cooperate to ensure the synchronization. Phase one consists of this process: 1. The application requester issues a COMMIT. All participating application servers and the application requester must be synchronized. The requester must wait now until it receives the OK from its SPM. 2. The SPM of the application requester sends a prepare for commit request to the SPMs of the servers. 3. All the SPMs at the server systems initiate the process of logging all the database changes and reaching the sync point. 4. The servers send a completion message to their SPMs. 5. The SPM requests a commit from the application servers SPM. For phase two, proceed with the following actions: 1. Once the SPMs have received the responses and logged them, they return a committed message. 2. The server SPMs send Forget to the application requester SPM and OK to their application servers. Everything has been synchronized now. 3. The application requester receives the OK from its SPM and can continue. Figure 5-6 shows the application view of the two-phase commit flow. Requestor SPM SPM Server 1 2 3 4 5 6 7 8 Phase 1 Phase 2 Sync Point Prepare Take Sync Point Sync point Request Commit Committed Forget OK OK 92 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-6 Application view of two-phase commit flow Note: The more database management systems (DBMS) that are involved in one Distributed Unit of Work, the more messages have to flow. This requires more resources and causes additional communication line traffic. 5.5 DB2 UDB for iSeries SQL support for connection management With DRDA-2, some SQL connection statements were added or have changed. They are listed here in alphabetical order. For more details, refer to Distributed Database Programming, SC41-5702. CONNECT (Type 1) The CONNECT (Type 1) statement connects an activation group within an application process to the identified application server, using the rules for the Remote Unit of Work. The term activation group refers to a substructure of a job that contains the resources necessary to run programs. For more details on activation groups, see ILE Concepts, SC41-5606. Database #1 Coordinator Application requests CC ... COMMIT Coordinator starts CC: Phase 1: Journal disk, keep locks If all participants OK: "End of phase 1" Journal Application continues ... ... Database #2 Prepare Commit Prepare Commit Ready for CC Ready for CC Phase 1: Journal disk, keep locks Phase 2: Commit Journal release locks Phase 2: Commit Journal release locks If all participants OK: "End of phase 2" Journal ( Committment Boundary) Execute Commit Execute Commit Commit done Commit done Chapter 5. DRDA and two-phase commitment control 93 If your application runs multiple activation groups, each connection is private to the activation group that issued it. The connection terminates if the activation group ends. This termination occurs whether the application is using the DRDA-1 or DRDA-2 connection methods. A program compiled with the RDBCNNMTH parameter of the CRTSQLpgm command set to *RUW runs with the CONNECT Type 1 connection method. Consecutive CONNECT statements can be executed successfully because CONNECT does not remove the activation group from the connectable state. A connect to the application server to which the activation group is currently connected is executed similar to any other CONNECT statement. CONNECT cannot execute successfully when it is preceded by any SQL statement other than CONNECT, COMMIT, or ROLLBACK. To avoid an error, execute a COMMIT or ROLLBACK operation before the CONNECT. CONNECT (Type 2) The CONNECT (Type 2) statement connects an activation group within an application process to the identified application server using the rules for the Distributed Unit of Work. This server is then the current server for the process. A program runs with this connection management method if it is compiled with the RDBCNNMTH parameter of the CRTSQLpgm command set to *DUW. DISCONNECT The DISCONNECT statement destroys one or more connections for unprotected connections (connections without two-phase commit). See 5.4, “Two-phase commitment control” on page 90. You cannot issue a DISCONNECT statement toward a protected conversation or toward any connection that sent SQL statements during the current unit of work. RELEASE The RELEASE statement places one or more connections in the released state. This statement is allowed only for protected conversations. If the statement is successful, each identified connection is placed in the released state and is, therefore, destroyed during the execution of the next COMMIT operation. Keep in mind that a ROLLBACK will not end the connection. If the current connection is in the released state when a commit operation is executed, destroying that connection places the activation group in the unconnected state. In this case, the next SQL statement to this application server must be CONNECT. If SET CONNECTION is used to this application server, an error (SQL0843, “Connection to relational database xxx does not exist.”) is encountered. SET CONNECTION is only possible to an application server other than the previously released one. Note: CONNECT (Type 2) cannot be issued a second time to the same server as long as the connection is still alive. Use SET CONNECTION to activate another server. Note: Creating and maintaining active connections requires some effort on behalf of the systems involved in the database network. This is why your applications should drop active connections if they are not going to be reused. 94 Advanced Functions and Administration on DB2 Universal Database for iSeries SET CONNECTION SET CONNECTION activates an already connected server so that all SQL statements, from now on, are directed to this server until another SET CONNECTION is issued, a CONNECT to a new server is executed, or the connection is ended. The SET CONNECTION statement brings the state of the connection from dormant to current. After the activation group is reconnected to the server, it finds that its environment is in the same status as when it left this connection. The connection reflects its last use by the activation group with regard to the status of locks, cursors, and prepared statements. 5.5.1 Example of an application flow using DRDA-2 In Figure 5-7, you can find a high-level description of a DRDA-2 application flow. Notice that the environment includes the coexistence of both the DRDA-2 and DRDA-1 systems. Figure 5-7 Application flow example using the new connection management The systems located in Rochester and Seoul support DRDA-2, where the system in Zurich is running at DRDA-1. The AR in Rochester connects to Seoul, does some work, connects back to the local database without COMMIT, and reconnects to Seoul through the new SET CONNECTION statement. Then Rochester connects to Zurich, Seoul is released, and Rochester reconnects to the local database. Before we finish our unit of work, we release and disconnect Zurich. After finishing the unit of work, no more remote connections are active because we released Seoul and disconnected Zurich. Finally, we are connected to our local database, Rochester. CONNECT TO SEOUL SELECT _ _ _ _ CONNECT TO ROCHESTER ENTER_ _ _ _ SET CONNECTION SEOUL UPDATE_ _ _ _ CONNECT TO ZURICH SELECT_ _ _ _ RELEASE SEOUL SET CONNECTION ROCHESTER DELETE COMMIT DISCONNECT ZURICH ROCHESTER DRDA-2 iSeries (AR) ZURICH DRDA-1 iSeries SEOUL DRDA-2 iSeries These iSeries servers could also be any other "DRDA" platform Chapter 5. DRDA and two-phase commitment control 95 5.6 DRDA-1 and DRDA-2 coexistence As Figure 5-7 shows, DRDA-2 and DRDA-1 systems can coexist in the same network, and a DRDA-2 application can access both types of application servers during its execution. Since DRDA-1 application servers do not support a protected conversation, some limitations may apply as to which systems can be accessed in update mode. An application requester determines, at the initial connect time, whether a DRDA-1 application server can be updated. A DRDA-2 application requester connection to a DRDA-1 application server can be used to perform updates when:  The program was compiled with an isolation level other than *NONE.  There are no other connections or they all are DRDA-1 read-only connections. Note: COMMIT(*NONE) on DB2 UDB for iSeries means that no transaction isolation is done and no logs are written. It can only be used in a DB2 UDB for iSeries-like environment. At connect time, the DB2 UDB for iSeries application requester chooses whether a sync point manager is used and, thus, whether the application server can be updated. Depending on this decision, different DRDA and commitment control protocols are used. Table 5-1 shows how the different flows can be mixed together. Table 5-1 Mixing DRDA levels Table 5-1 indicates:  Application requester is at DRDA-1: All application servers use the DRDA-1 flow. This implies a single-phase commit and unprotected conversations.  Application requester is at DRDA-2 supporting a single-phase commit (1PC): When the application server is at DRDA-1, DRDA-1 protocol is used. All others use a DRDA-2 flow with single-phase commit.  Application requester is at DRDA-2 with a two-phase commit: When the application server is at DRDA-1, DRDA-1 flows are used. When the application server is at DRDA-2 with single-phase commit capability, DRDA-2 single-phase commit flow is used. When the application server is at DRDA-2 with two-phase commit capability, DRDA-2 two-phase commit flow is used. In a heterogeneous environment, the protocol used depends on the application requester according to Table 5-1. Application server requesters Application servers DRDA-1 DRDA-2 1PC DRDA-2 2PC DRDA-1 DRDA-1 DRDA-1 DRDA-1 DRDA-2 1PC DRDA-1 DRDA-2 1PC DRDA-2 1PC DRDA-2 2PC DRDA-1 DRDA-2 1PC DRDA-2 2PC Notes: 1PC = Single phase commit 2PC = Two-phase commit 96 Advanced Functions and Administration on DB2 Universal Database for iSeries 5.7 Recovery from failure As we mentioned earlier, in most cases the recovery is totally automatic. When the systems detect a failure, the current transaction is automatically rolled back on all the systems. Still, there is a narrow window in the two-phase commit cycle where a network failure or a system failure may leave the transaction in a pending state because the application requester cannot determine which action to take. This window is located right before the last step of the two-phase commit process, when the application server may already have committed a transaction, but for some reason cannot send the final acknowledgment. When the transaction hangs, all the locks are preserved and the application receives an I/O error. This section describes how the system or the users can recover after a network or a system failure in a two-phase commit environment. 5.7.1 General considerations To control the synchronization over multiple systems, DB2 UDB for iSeries uses a Logical Unit of Work ID. This identifier is the same on all systems involved, whether they are application requesters or application servers with like or unlike platforms. On DB2 UDB for iSeries, the unit of work ID looks similar to the following example: APPNET.ROCHESTER.X'F2DEB3D611CA'.00001 Note: This ID is composed of four parts, where:  APPNET is the APPN Net-ID  ROCHESTER is the application requester system name  X'F2DE.... is related to the job, running a protected conversation  000... relates to the program call within the job On the iSeries server, this identifier should actually be called activation group ID because the number remains the same over the life of an activation group. The program or activation group can start a large number of units of work. Ending the program and calling it again changes the last part of the identification number, which then looks similar to this example: APPNET.ROCHESTER.X'F2DEB3D611CA'.00003 If you start a new job on the iSeries server and run the same application, the identifier will change its third component: APPNET.ROCHESTER.X'F2E1B36111CB'.00001 Note: A new job changes the last two parts of the identification number. 5.7.2 Automatic recovery DB2 UDB for iSeries with DRDA-2 and two-phase commitment control provides a comprehensive recovery mechanism after system, network, or job failures. Automatic recovery was tested with programs from the Order Entry Application example described in Chapter 2, “Using the advanced functions: An Order Entry application” on page 11, particularly with the Insert Order Detail program documented in Appendix A, “Order Entry application: Detailed flow” on page 329. This program (INSDET) calls a stored Chapter 5. DRDA and two-phase commitment control 97 procedure (STORID) on a remote iSeries server. The stored procedure updates a STOCK table on the remote system. Then, the calling program inserts an order detail record in a ORDERDTL table on the local system. After doing this, the Distributed Unit of Work (DUW) is completed. Note: ROCHESTER is the local system (AR). ZURICH is the remote system (AS). In this test scenario, the stored procedure program on the remote system was abruptly terminated, cancelling the job before the database changes on both systems were committed. In this case, the remote system (application server) rolled back the one database change automatically and provided information in the job log. At the application requester, information provided in the program ended, but not before rolling back the local database change, which was a record insert. The rollback operation is needed since the calling program received SQL error return code -918, which corresponds to message SQL0918. The details are shown in Figure 5-8. Figure 5-8 Message SQL0918 The job log of the remote system (ZURICH) reported the following information: ............... CPI9152 Information Target DDM job started by source system. CPI3E01 Information Local relational database accessed by ROCHESTER. CPC1125 Completion Job ../ITSCID06/ROCHESTER was ended by user ITSCID03. CPD83DD Diagnostic Conversation terminated; reason 02. 02 -- The conversation was issued a Deallocate Type (Abend) to force the remote location to roll back. CPF4059 Diagnostic System abnormally ended the transaction with device ROCHESTER. CPI8369 Information 1 pending changes rolled back; reason 01. 01 -- The commitment definition is in a state of Reset. CPF83E4 Diagnostic Commitment control ended with resources not committed. ............... 5.7.3 Manual recovery The Work with Commitment Definition (WRKCMTDFN) command allows users to manage commitment definitions for any job on the system. This command becomes particularly useful when a system or line failure causes transactions to hang while waiting for synchronization. A commitment definition reports information about a job commitment control status after commitment control has been started with either the Start Commitment Control (STRCMTCTL) command or by a program containing embedded SQL commitment statements. Display Formatted Message Text System: ROCHESTER Message ID . . . . . . . . . : SQL0918 Message file . . . . . . . . : QSQLMSG Library . . . . . . . . . : QSYS Message . . . . : ROLLBACK is required. Cause . . . . . : The activation group requires a ROLLBACK to be performed prior to running any other SQL statements. Recovery . . . : Issue a ROLLBACK CL command or an SQL ROLLBACK statement and then continue. 98 Advanced Functions and Administration on DB2 Universal Database for iSeries Using Work with Commitment Definitions This command provides detailed information about the commitment control status of an activation group. The main display may look similar to the example in Figure 5-9, where only one active commitment definition is shown. Figure 5-9 Work with Commitment Definition command display If more activation groups are involved, more commitment definitions are listed. When you choose option 5 (Display status), three more displays with further details of the commitment definition shown in Figure 5-10 through Figure 5-12 appear. Figure 5-10 Display Commitment Definition Status (Part 1 of 3) Work with Commitment Definitions System: ROCHESTER Type options, press Enter. 5=Display status 12=Work with job 14=Forced commit 16=Forced rollback ... Commitment Resync In Opt Definition Job User Number Progress 5 *DFTACTGRP P23KXC48E ITSCID06 004590 NO Bottom 3=Exit F5=Refresh F9=Command line F11=Display logical unit of work 12=Cancel F16=Sort by logical unit of work ID F24=More keys Display Commitment Definition Status ROCHESTER 05/25/01 23:03:42 Job: P23KXC48E User: ITSCID06 Number: 004590 Commitment definition . . . . . . : *DFTACTGRP Activation group . . . . . . . . : 2 Logical Unit of Work ID . . . . . : APPNET.ROCHESTER.X'F32D995711EE'.00003 Job active . . . . . . . . . . . : YES Server job . . . . . . . . . . . : Resource location . . . . . . . . : REMOTE Default lock level . . . . . . . : *CHG Role . . . . . . . . . . . . . . : State . . . . . . . . . . . . . . : RESET Date/time stamp . . . . . . . . : Resync in progress . . . . . . . : NO Number of commits . . . . . . . . : 2 Number of rollbacks . . . . . . . : 0 More... Press Enter to continue. F3=Exit F5=Refresh F6=Display resource status F9=Command line F12=Cancel Chapter 5. DRDA and two-phase commitment control 99 Figure 5-11 Display Commitment Definition Status (Part 2 of 3) Figure 5-12 Display Commitment Definition Status (Part 3 of 3) Press F6 to look more into the details of a commitment definition. A window is displayed about the status of the single resources that are protected by commitment control (Figure 5-13). Display Commitment Definition Status ROCHESTER 05/25/01 23:03:42 Job: P23KXC48E User: ITSCID06 Number: 004590 Commitment definition . . . . . . : *DFTACTGRP Activation group . . . . . . . . : 2 Heuristic operation . . . . . . . : Default journal . . . . . . . . . : Library . . . . . . . . . . . . : Notify object . . . . . . . . . . : *NONE Library . . . . . . . . . . . . : Object type . . . . . . . . . . : Member . . . . . . . . . . . . : More... F3=Exit F5=Refresh F6=Display resource status F9=Command line F12=Cancel Display Commitment Definition Status ROCHESTER 05/25/01 23:03:42 Job: P23KXC48E User: ITSCID06 Number: 004590 Commitment definition . . . . . . : *DFTACTGRP Activation group . . . . . . . . : 2 Commitment options: Wait for outcome . . . . . . . : WAIT Action if problems . . . . . . : ROLLBACK Vote read-only permitted . . . : NO Action if End . . . . . . . . . : WAIT Bottom F3=Exit F5=Refresh F6=Display resource status F9=Command line F12=Cancel 100 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-13 Display Resource Status display When you select option 1 (Record level), the system displays the local files whose records are involved in the commitment definition (Figure 5-14). Figure 5-14 Display Record Level Status display Press F11 (Display status) to view more details. In addition to the number of database changes committed, rolled back, or still pending, the display shows the lock level, the status, the journal, and commit cycle identifier for the file. Display Commitment Definition Status ROCHESTER 05/25/01 23:03:42 Job: P23KXC48E User: ITSCID06 Number: 004590 Commitment definition . . . . . . : *DFTACTGRP Activation group . . . . . . . . : 2 ,...................................................................... : Display Resource Status : : : : Type option, press Enter. : : 1=Select : : : : Opt Resource : : 1 Record level : Object level : : Conversation : : Remote file : : Remote RDB : : API : : : : Bottom : : F5=Refresh F12=Cancel : : : :.....................................................................: Display Record Level Status System: ROCHESTER Job: P23KXC48E User: ITSCID06 Number: 004590 Commitment definition . . . . . . . . : *DFTACTGRP -------------Changes-------------- File Library Member Commit Rollback Pending ORDERDTL ORDENTL ORDERDTL 0 0 1 Bottom Press Enter to continue. F3=Exit F5=Refresh F6=Display resource status F9=Command line F11=Display status F12=Cancel F16=Job menu Chapter 5. DRDA and two-phase commitment control 101 Showing an example of manual recovery is not an easy task, since there is really little chance that the transaction will be interrupted when it is in an undecided state. The two-phase commitment control critical window is very narrow. In these rare situations, the WRKCMTDFN command provides a way to complete the transaction and release all the locks. It is up to the user to determine whether to use a commit or a rollback and force the transaction boundary by using either of the following methods on the display shown in Figure 5-9 on page 98:  Option 14 (Forced commit)  Option 16 (Forced rollback) The manual recovery process may violate the alignment of the various databases in the network. Avoid this procedure if the automatic resynchronization is still possible by restoring the communication among the systems. Force the end of the transaction if the environment where the transaction was running before the failure cannot be restored, such as in the case of data loss or other serious system or network outages. 5.8 Application design considerations This section describes how application developers should design their programs to fully exploit the flexibility provided by DRDA-2 in a distributed environment. 5.8.1 Moving from DRDA-1 to DRDA-2 The essential advantage of the Distributed Unit of Work (DRDA-2) over Remote Unit of Work (DRDA-1) is represented by the ability to access different locations within the same transaction, allowing much more flexibility to database and application design. The flexibility offered by DRDA-2 introduces more complexity in regard to handling the connections within your applications. Multiple connections may be active at the same time, and you may need to determine whether your application is already connected to a specific location. To obtain this information, check the SQLCODE after issuing a CONNECT statement directed to that particular location. If you receive SQLCODE = -842, this means that the connection is already active and that you may need to perform a SET CONNECTION to establish that location as the current connection. If you receive SQLCODE = 0, the connection has just been activated and becomes the current connection. Performance in a DRDA-2 environment The higher the number is of the connections concurrently active, the higher the impact is on the application and system performance. Design your applications by trying to find the right balance between keeping your connections active, so that you do not need to restart them when you need them, and releasing the idle connections to reduce the system overhead. The behavior of the initial connection depends on the programming model used by your application:  OPM programs: In a DRDA-1 program, each initial call of a program implicitly connects to the database specified in the RDB parameter of the CRTSQLxxx command. When the program terminates its execution, the connection is destroyed. If the same program is called several times within a job, the implicit connection is established each time. In a DRDA-1 program, you can count on this behavior and avoid coding the initial connection. 102 Advanced Functions and Administration on DB2 Universal Database for iSeries  ILE programs: If ILE programs are created using the default parameters, the initial connection to the location specified in the RDB parameter will occur once in the life of an activation group. The connection will last as long as the activation group exists. In general, this behavior depends on the value of the CLOSQLCSR parameter, which defaults to *ENDACTGRP. If your program runs in the default activation group or in a named activation group, you may need to check for existing connections. 5.9 DRDA-2 program examples This section gives three examples of programs using DRDA-2 connection management and two-phase commitment control. The programs are taken from the Order Entry scenario. 5.9.1 Order Entry main program The main program of our application only has the purpose of establishing the connections to the local and remote databases and of calling the various subprograms. The design choice of establishing all the necessary connections at the beginning allows the developers of the subprograms to rely on the existing connections. In the subprograms, there are only SET CONNECTION statements. The following code listing shows a COBOL version of the main program: IDENTIFICATION DIVISION. PROGRAM-ID. T4249MAIN. * * This is the main program of the order entry application. * The program establishes all the connections, so that the * various sub-programs will need to issue only SET CONNECTION * statements. At the end of the cycle, this program will * release all the connections and commit all the changes. * ENVIRONMENT DIVISION. * DATA DIVISION. * WORKING-STORAGE SECTION. * * The error flag parameter is used by the various sub-programs * to communicate a failure. * No Errors: ERRFLG = 0 * Failure : ERRFLG = 1 * 01 ERR-FLG PIC X(1). 01 TOTAMT PIC S9(11) PACKED-DECIMAL. 01 CUSNBR PIC X(5). 01 ORDNBR PIC X(5). * EXEC SQL INCLUDE SQLCA END-EXEC. PROCEDURE DIVISION. * EXEC SQL CONNECT TO RCHASM02 END-EXEC. * * Establish connections and check for successfull connect * IF SQLCODE NOT = 0 AND SQLCODE NOT = -842 THEN Chapter 5. DRDA and two-phase commitment control 103 DISPLAY "Error connecting to RCHASM02" END-IF. EXEC SQL CONNECT TO RCHASM03 END-EXEC IF SQLCODE NOT = 0 AND SQLCODE NOT = -842 THEN DISPLAY "Error connecting to RCHASM03" END-IF. * Calling the restart procedure, that checks for * incomplete orders and deletes them. CALL "T4249RSTR" USING ERR-FLG. IF ERR-FLG = 0 THEN * Calling the insert order header program CALL "T4249CINS" USING CUSNBR, ORDNBR, ERR-FLG IF ERR-FLG = 0 THEN * Calling the insert detail rows program CALL "T4249RIDT" USING CUSNBR, ORDNBR, ERR-FLG IF ERR-FLG = 0 THEN * Calling the finalize order program CALL "T4249FNLO" USING CUSNBR, ORDNBR, TOTAMT, ERR-FLG IF ERR-FLG = 0 THEN STOP RUN END-IF END-IF END-IF END-IF. * In case of errors, perform a ROLLBACK EXEC SQL ROLLBACK END-EXEC. STOP RUN. 5.9.2 Deleting an order This program may be invoked either at the beginning of the application execution (if some incomplete orders are found for the user) or at the end of it (if the user requests a cancellation of the order). The program scans the order detail rows and, for each item, it updates the quantity in the stock file at the remote site. At the end, the program deletes the order header. This operation causes all of the detail rows to go away as well because of the CASCADE rule that we implemented. If no errors are encountered in the process, the program commits the entire transaction. The following code listing shows a COBOL implementation of this procedure: IDENTIFICATION DIVISION. PROGRAM-ID. T4249CORD. * * This program scans all the details referring to the input * order number; it updates the available quantity of each * detail in the remote STOCK file. * ENVIRONMENT DIVISION. * DATA DIVISION. * WORKING-STORAGE SECTION. * 01 H-ORDQTY PIC S9(5) PACKED-DECIMAL. 01 H-PRDQTA PIC S9(5) PACKED-DECIMAL. 104 Advanced Functions and Administration on DB2 Universal Database for iSeries 01 H-PRDNBR PIC X(5). 01 H-ORHNBR PIC X(5). * EXEC SQL INCLUDE SQLCA END-EXEC. * EXEC SQL DECLARE DETAIL CURSOR FOR SELECT PRDNBR ,ORDQTY FROM ORDENTL/ORDERDTL WHERE ORHNBR = :h-ORHNBR END-EXEC. * LINKAGE SECTION. * 01 WK-ORHNBR PIC X(5). 01 ERR-FLG PIC X(1). * PROCEDURE DIVISION USING WK-ORHNBR ERR-FLG. * MOVE WK-ORHNBR TO H-ORHNBR. MOVE "0" TO ERR-FLG. * EXEC SQL SET CONNECTION RCHASM03 END-EXEC. * IF SQLCODE = 0 THEN EXEC SQL OPEN DETAIL END-EXEC ELSE MOVE "1" TO ERR-FLG END-IF. * * Read each detail's ordered quantity and update STOCK * PERFORM UNTIL SQLCODE NOT = 0 OR ERR-FLG NOT = 0 * EXEC SQL FETCH DETAIL INTO :h-PRDNBR ,:h-ORDQTY END-EXEC * IF SQLCODE = 0 THEN * EXEC SQL SET CONNECTION RCHASM02 END-EXEC * IF SQLCODE = 0 THEN * EXEC SQL UPDATE ORDENTR/STOCK SET PRDQTA = PRDQTA + :h-ORDQTY WHERE PRDNBR = :h-PRDNBR END-EXEC IF SQLCODE NOT = 0 THEN MOVE "1" TO ERR-FLG END-IF * ELSE MOVE "1" TO ERR-FLG END-IF * EXEC SQL SET CONNECTION RCHASM03 END-EXEC * IF SQLCODE NOT = 0 THEN Chapter 5. DRDA and two-phase commitment control 105 MOVE "1" TO ERR-FLG END-IF * END-IF END-PERFORM. * IF SQLCODE < 0 AND ERR-FLG = 0 THEN MOVE "1" TO ERR-FLG END-IF. * IF ERR-FLG = 0 THEN EXEC SQL DELETE FROM ORDENTL/ORDERHDR WHERE ORHNBR = :h-ORHNBR END-EXEC * IF SQLCODE NOT = 0 THEN MOVE "1" TO ERR-FLG END-IF END-IF. * IF ERR-FLG = "0" THEN EXEC SQL COMMIT END-EXEC ELSE EXEC SQL ROLLBACK END-EXEC END-IF. * GOBACK. 5.9.3 Inserting the detail rows The following example is an excerpt of the Insert Detail program. This fragment of code shows only the statements that are relevant to a DRDA-2 connection and two-phase commitment control. The full implementation of this program (INSDET) can be found in Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503, since this program activates a remote stored procedure. This program inserts the detail order item in the ORDERDTL file at the local database and updates the quantity in the inventory by calling a remote stored procedure, which accesses the STOCK file at the remote system: This program excerpt (from program INSDET) ==================== shows the vital statements for -- DRDA-2 connection management and -- two-phase commitment control ... ................... ................... ROCHESTER is local database system ZURICH is remote database system ................... ................... ................... * **************************************************************** * The following Two-Phase Commit for local and remote system * * is only executed, if the conditions are met ... * * The first COMMIT after one DUW therefore is done only after * * the ordered quantity has been deducted from STOCK file on * * the remote system and the first order record has been * 106 Advanced Functions and Administration on DB2 Universal Database for iSeries * inserted correctly in the ORDERDTL file on the local system.* * Every item record for an order is committed, because * * of releasing the record lock on STOCK file. * * Note: SQL COMMIT in the program starts commitment control * * for the activation group automatically: * **************************************************************** * C/EXEC SQL C+ COMMIT C/END-EXEC ................... ................... ................... * **************************************************************** * -- Connection to the REMOTE database: -- * * At start of the program DRDA connection mgmt. establishes * * connection automatically to the remote sys. as according to * * the relational database specified in the compil. parameter * * in command CRTSQLxxx RDB(....). Therefore this program * * is connected to remote database ZURICH already. * * For further remote re-connections SET CONNECTION is used: * **************************************************************** * ................... ................... C/EXEC SQL C+ SET CONNECTION ZURICH After 1.connect C/END-EXEC remote ................... ................... ................... * **************************************************************** * The CALL of the stored procedure (at the remote system) * * is prepared and executed. * * It updates the STOCK file, and searches for alternatives, * * if necessary. * **************************************************************** Code for stored procedure, see chapter "Stored Procedures". ................... ................... ................... ................... **************************************************************** * -- Connection to the LOCAL database: -- * * At this point, connection to the local database is estab- * * lished. For the first time in the execution of the program * * the CONNECT statement has to be executed. * * The connection to the local database then goes to dormant * * state, after connecting to the remote DB (above) again. * * For further local re-connections SET CONNECTION is used: * **************************************************************** * C *IN51 IFEQ '0' 1st connect C/EXEC SQL -- local C+ CONNECT TO ROCHESTER C/END-EXEC C MOVE '1' *IN51 After 1.connect C ELSE local Chapter 5. DRDA and two-phase commitment control 107 C/EXEC SQL C+ SET CONNECTION ROCHESTER C/END-EXEC C END * **************************************************************** * An order detail record is inserted in the local database, * * if referential integrity rules are not violated, i.e. * * the primary key of ORDERDTL file must be unique, and/or a * * corresponding order number must exist in the ORDERHDR * * parent file. Otherwise an SQL error message is sent from * * database management: * **************************************************************** * C/EXEC SQL C+ INSERT INTO ORDENTL/ORDERDTL (ORHNBR, PRDNBR, ORDQTY, ORDTOT) C+ VALUES(:ORDNBR, :DPRDNR, :DQUANT, :DITTOT) C/END-EXEC ................... ................... ................... C SQLCOD IFEQ -530 RI Constraint ................... ................... * **************************************************************** * If ORDERHDR parent file does not have corresponding * * order number (RI rule violated), * * update of order quantity in STOCK file on remote system * * is rolled back by two-phase commitment control management: * **************************************************************** * C/EXEC SQL C+ ROLLBACK C/END-EXEC ................... ................... ................... C GOTO BEGIN ................... ................... ................... ................... * **************************************************************** * If PF3 is pressed, order entry has finished. All * * connections are released in order to save on resources: * **************************************************************** * C/EXEC SQL C+ RELEASE ALL C/END-EXEC * **************************************************************** * The following COMMIT statement activates previous RELEASE: * **************************************************************** * C/EXEC SQL C+ COMMIT 108 Advanced Functions and Administration on DB2 Universal Database for iSeries C/END-EXEC ................... ................... ................... 5.10 DRDA over TCP/IP So far, we have dealt with either DRDA over SNA or with the DRDA implementation on the iSeries server in general. This section discusses the iSeries server implementation of DRDA over TCP/IP. The requirement for DRDA over TCP/IP stems from the explosive growth in usage of this protocol and the fact that many large accounts are already running TCP/IP or are moving all new applications to TCP/IP. The support for DRDA over TCP/IP on the iSeries server has been made available with OS/400 version V4R2M0. The implementation of DRDA over TCP/IP up to V4R5 supports DRDA level 1. This satisfies the UNIX or Windows NT client and DataPropagator needs. It is in V5R1 that the implementation of DRDA over TCP/IP supports DRDA level 2. The DRDA application server is based on multiple connection-oriented server jobs running in the QSYSWRK subsystem. A DRDA background program (listener) listens for TCP connect requests on well-known DRDA port 446. The DRDA server jobs are defined by prestart job entries. Once the application requester connects to the listener at the AS, the listener issues a request to wake up a prestarted server job. The listener then passes the socket descriptor to the server job, and any further communication occurs directly between the client application and server job. If you use the SNA implementation of DRDA, you need to configure the controller that governs the communication between the local and the remote system. Then, you need to refer to this controller in the device description parameter of the ADDRDBDIRE command. If you use the TCP/IP implementation of DRDA, you can refer to the IP address of the remote server on the Remote Location Name parameter of the ADDRDBDIRE command, and specify the port if it is other than the default DRDA port of 446. The iSeries server always uses the default port. This eliminates all of the complexity of configuring the communications between the two servers. 5.10.1 Configuring DRDA over TCP/IP This section covers the configuration process for DRDA over TCP/IP between two iSeries servers. The system located in Rochester takes the role of the application server, and the system in Zurich accesses the database located on the Rochester machine as an application requester. The configuration process for this simple scenario consists of these phases:  Setting up the application server: This phase involves the following configuration activities: a. Configuring TCP/IP on the AS system b. Setting the attributes for the DDM server job c. Starting the DDM server job  Setting up the application requester: This phase involves the following configuration activities: a. Configuring TCP/IP on the AR system b. Adding the AS system to the Relational Database Directory c. Defining the user profile under which the connect to the AS is being done Chapter 5. DRDA and two-phase commitment control 109 Configuring TCP/IP on the application server First you have to make sure that there is an appropriate host table entry for the local ROCHESTER machine. At this point, you may also want to add a host name for the AR machine located in Zurich. An alternative approach is to specify a remote domain name server in your TCP/IP configuration for automatic host name resolution. In our example, we outline the steps required for defining the TCP/IP host table entry: 1. At the CL command line, enter the GO CFGTCP command. 2. The TCP/IP configuration menu is shown. Here, select option 10. 3. The Work with TCP/IP Host Table Entries display is shown. Check that there is a valid entry for the local host. 4. Choose the ADD option, and enter the Internet address of the remote AR in the column named Internet Address (Figure 5-15). Figure 5-15 Working with the host table entries 5. This invokes the Add TCP/IP Host Table Entry (ADDTCPHTE) command. On this command, you can define the name and the alias names of the remote host (Figure 5-16). Figure 5-16 Adding the host table entries Setting the attributes for the DDM server job Before you start the server job on the AS system, you can change the job's attributes by using the Change DDM TCP/IP Attributes (CHGDDMTCPA) command. There are two attributes that can be changed with this command:  AUTOSTART: Specifies whether to automatically start the DDM server when TCP/IP is started. This parameter takes effect the next time the STRTCP command is run. Work with TCP/IP Host Table Entries System: ROCHESTER Type options, press Enter. 1=Add 2=Change 4=Remove 5=Display 7=Rename Internet Host Opt Address Name 1 10.10.10.2 _ 10.10.10.1 ROCHESTER _ 127.0.0.1 LOOPBACK LOCALHOST Add TCP/IP Host Table Entry (ADDTCPHTE) Type choices, press Enter. Internet address . . . . . . . . > '10.10.10.2' Host names: Name . . . . . . . . . . . . . ZURICH_______________________________ _________________________________________________________________________ _________________________________________________________________________ ___________________________________________________ + for more values _ Text 'description' . . . . . . . HOST TABLE ENTRY FOR AS/400 SYSTEM AT ZURICH______________ 110 Advanced Functions and Administration on DB2 Universal Database for iSeries  PWDRQD: Specifies whether client systems are required to have a password in addition to a user ID on incoming connection requests to this system as a server. This parameter takes effect on the next DRDA or DDM connect request over TCP/IP. Now, follow these steps: 1. On the CL command line, enter the CHGDDMTCPA command, and press PF4 so you can see the current settings. 2. Change the DDM server job attributes to the values shown in Figure 5-17. Figure 5-17 Changing the DDM server job attributes Starting the DDM server job Use the STRTCPSVR SERVER(*DDM) command to start the DDM server job. Now you can find a new job, QRWTLSTN, running in the QSYSWRK subsystem. This is the listener job waiting for connect requests on port 446. Configuring TCP/IP on the application requester Configuring TCP/IP on the application requester involves exactly the same steps as for the application server. Refer to “Configuring TCP/IP on the application server” on page 109. Adding the AS system to the relational database directory Probably the most important step in DRDA over TCP/IP configuration is adding the relational database entry for the remote database to which you want to connect. The relational database entry defines the location of the remote server and the method of connection. 1. Use the ADDRDBDIRE command to add the RDB entry for the application server located in Rochester (Figure 5-18). Change DDM TCP/IP Attributes (CHGDDMTCPA) Type choices, press Enter. Autostart server . . . . . . . . AUTOSTART *YES Password required . . . . . . . PWDRQD *YES Note: The value of the PWDRQD attribute has some implications for the Change Relational Database Directory Entry (CHGRDBDIRE) and Remove Relational Database Directory Entry (RMVRDBDIRE) commands. A bit in the *LOCAL RDB directory entry is used to store if a password is required to access this iSeries server by an AR. An inquiry message CPA3E01 is issued if the local entry is changed to a non-local entry or if the *LOCAL entry is deleted. The following text is associated with this message: Removing the *LOCAL directory entry may cause loss of configuration data. (C G) We strongly recommend that you record the current setting before you proceed. Chapter 5. DRDA and two-phase commitment control 111 Figure 5-18 Adding the relational database entry 2. On the Relational Database parameter of the ADDRDBDIRE command, specify the name of the database on the remote server. 3. On the Remote Location parameter of the ADDRDBDIRE command, specify the Internet address of the remote application server. If you already specified the Internet address of the remote server in TCP/IP host table entry, you can use the host name in place of the Internet address. In our example, we specified ROCHESTER rather than 10.10.10.1. This allows you to have some flexibility if, for some reason, you change the Internet address of the remote server. 4. On the Type parameter of the ADDRDBDIRE command, specify the value *IP. This signifies to the local system that you are using the TCP/IP implementation of DRDA to connect to the remote server. Note that *SNA is the default setting for this parameter. 5. On the PORT parameter, specify the default value *DRDA. Some servers, such as DB2 Universal Database, use a different port. You need to find out which port to specify from the documentation for the specific server product and set that port number. Defining a user profile for DRDA over the TCP/IP connection You can use the Add Server Authentication Entry (ADDSVRAUTE) command to add authentication information for a given user under which the connect is being done. The user ID and password are associated with the user profile and remote application server. This information flows to the AS each time the AR issues a connect request. 1. Make sure that you have *SECADM special authority, as well as *OBJMGT and *USE authorities, to the user profile to which the server authentication entry is being added. 2. Check whether the retain server security data (QRETSVRSEC) system value is set to 1. If the value is 0 (do not retain data), the password is not saved in the entry. 3. Type the ADDSVRAUTE command and press F4. 4. Add the authentication entry shown in Figure 5-19 and Figure 5-20. Add RDB Directory Entry (ADDRDBDIRE) Type choices, press Enter. Relational database . . . . . . ROCHESTER__________ Remote location: Name or address . . . . . . . 10.10.10.1__________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________ Type . . . . . . . . . . . . . *IP_ *SNA, *IP Text . . . . . . . . . . . . . . RDB ENTRY FOR THE AS/400 SYSTEM IN RO CHESTER 112 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-19 Adding the authentication entry Figure 5-20 Adding the authentication entry Note: Make sure the server name is in uppercase. Along with ADDSVRAUTE command, there are two additional commands available:  Change Server Authentication Entry (CHGSVRAUTE): Allows you to change the user ID and password for an authentication entry added by the ADDSVRAUTE command.  Remove Server Authentication Entry (RMVSVRAUTE): Allows you to remove authentication entries added by the ADDSVRAUTE command. 5.10.2 Examples of using DRDA over TCP/IP The discussion in the previous section contains details about the method of configuring DRDA over TCP/IP. This section discusses how to actually access the data in the remote server. It examines two different scenarios:  Using Interactive SQL  Using C programming Add Server Auth Entry (ADDSVRAUTE) Type choices, press Enter. User profile . . . . . . . . . . > JAREK Name, *CURRENT Server . . . . . . . . . . . . . > ROCHESTER____________________________ ________________________________________________________________________ ________________________________________________________________________ User ID . . . . . . . . . . . . *USRPRF______________________________ ________________________________________________________________________ ____________________________________________________________________... More... Add Server Auth Entry (ADDSVRAUTE) Type choices, press Enter. User password . . . . . . . . . PASSWORD_____________________________ ________________________________________________________________________ ________________________________________________________________________ ____________________________________________________________________... Bottom Chapter 5. DRDA and two-phase commitment control 113 Interactive SQL example Probably the easiest way to take advantage of a DRDA connection to a remote database is to use Interactive SQL. The following simple SQL session documents all major points to remember while running DRDA over TCP/IP: 1. Start Interactive SQL with the Start SQL (STRSQL) command. Make sure that the commitment control level you are running at is at least *CHG. At the SQL prompt, press the F13 key, and then select option 1. Change the Commitment Control Attribute to *CHG. Return to the SQL session by pressing F3. Now you are ready to test the SQL statements shown in Figure 5-21. Figure 5-21 Using DRDA over TCP/IP with SQL The following list explains the SQL statements that are numbered in Figure 5-21: 1 When you start your Interactive SQL session, you are connected, by default, to your local database. 2 The initial connection to the local system is protected by two-phase commit protocols. If a subsequent connection is made to a system that has only RUW capability, that connection is read-only. Therefore, you cannot perform any committable transactions, including automatically creating an SQL package for the Interactive SQL program, if the connection is to a non-iSeries server and this is the first time the connection is attempted. The solution to this is to drop the connection to the local database before you connect to the remote server. You may use the SQL statement RELEASE ALL to accomplish this task. When you execute this command, the resources held by any database in the system are released and any pending transaction is rolled back. Enter SQL Statements Type SQL statement, press Enter. Session was saved and started again. STRSQL parameters were ignored. Current connection is to relational database ZURICH.1 > release all 2 RELEASE of all relational databases completed. > commit 3 Commit completed. > connect to rochester Current connection is to relational database ROCHESTER. 4 > select * from ordapplib/customer SELECT statement run complete. > update ordapplib/customer set cuscrd = cuscrd * 1.1 5 where cusnbr = '99995' 1 rows updated in CUSTOMER in ORDAPPLIB. > select * from ordapplib/customer SELECT statement run complete. > commit 6 Commit completed. > call caseproc ('99995',0) 7 CALL statement complete. > select * from ordapplib/customer SELECT statement run complete. > commit Commit completed. ===> Bottom 114 Advanced Functions and Administration on DB2 Universal Database for iSeries 3 The COMMIT statement is required to move the connection from a released to an unconnected state. See the discussion in 5.3.2, “Connection states” on page 88, for more information. 4 After you establish the connection to the remote AS, make sure that the connection type is 1. Place the cursor on the connection message, and press F1. A message display with the information shown in Figure 5-22 appears. Figure 5-22 Connection type for DRDA over TCP/IP 5 Because this is the first *RUW connection, committable updates can be performed. 6 Changes to the remote database should be committed before the connection is dropped. 7 One of the most powerful features of the DRDA architecture is the ability to run remote stored procedures. The stored procedure in this step performs exactly the same action as the update statement in 5. For a detailed discussion on DB2 UDB for iSeries stored procedure implementation, refer to Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503. 2. To finish the SQL session, press F3. You may want to save your current session by using option 1. ILE C example The way you code your application program, which accesses remote AS with DRDA over TCP/IP support, is similar to the procedure described for the Interactive SQL session. The following example code highlights the most important considerations: 1. Compile your program with an isolation level of *CHG or above. If you have a connection to the remote AS at compile time, you may create an appropriate SQL package on the target system. The following Create C-embedded SQL (CRTSQLCI) command creates the program object on the local system and the SQL package at the remote server: CRTSQLCI OBJ(ORDAPPLIB/SQLCNCT) SRCMBR(SQLCNCT) RDB(ROCHESTER) OBJTYPE(*PGM) OUTPUT(*PRINT) RDBCNNMTH(*RUW) 2. The ILE C code is listed here: Additional Message Information Message ID . . . . . : SQL7971 Severity . . . . . . . : 00 Message Type . . . . : Information Message . . . : Current connection is to relational database ROCHESTER. Cause . . . . : The product identification is QSQ04020, the server class name is QAS, and the user ID is JAREK. The connection method used is *DUW The connection type is 1. A list of the connection types follows: -- Type 1 indicates that committable updates can be performed and either the connection uses an unprotected conversation, is a connection to an application requester driver program using *RUW connection method, or is local connection using *RUW connection method. -- Type 2 indicates that the conversation is unprotected and no committable updates can be performed. -- Type 3 indicates that the conversation is protected and it is unknown if committable updates can be performed. -- Type 4 indicates that the conversation is unprotected and it is unknown More... Chapter 5. DRDA and two-phase commitment control 115 #include #include #include #include EXEC SQL BEGIN DECLARE SECTION; char Chr_CusNbr[ 5 ]; char Chr_CusNam[ 20 ]; char Chr_CusTel[ 15 ]; char Chr_CusFax[ 15 ]; char Chr_CusAdr[ 20 ]; char Chr_CusCty[ 20 ]; char Chr_CusZip[ 5 ]; decimal( 11,2 ) Nmpd_CusCrd; decimal( 11,2 ) Nmpd_CusTot; EXEC SQL END DECLARE SECTION; EXEC SQL INCLUDE SQLCA; void main() { char Chr_Commit; printf( "Please enter the value for Customer Number :\n" ); gets( Chr_CusNbr ); printf( "Please enter the value for Customer Name :\n" ); gets( Chr_CusNam ); printf( "Please enter the value for Customer Tel :\n" ); gets( Chr_CusTel ); printf( "Please enter the value for Customer Fax :\n" ); gets( Chr_CusFax ); printf( "Please enter the value for Customer Address :\n" ); gets( Chr_CusAdr ); printf( "Please enter the value for Customer City :\n" ); gets( Chr_CusCty ); printf( "Please enter the value for Customer Zip :\n" ); gets( Chr_CusZip ); printf( "Please ener ythe value for Customer Credit Limit :\n" ); scanf( "%D(11,2)", &Nmpd_CusCrd ); EXEC SQL release all; 1 if ( sqlca.sqlcode != 0 ) { printf( "Error occured in the release of databases\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); } printf( "Released all Databases...\n" ); EXEC SQL commit; 2 if ( sqlca.sqlcode != 0 ) { printf( "Error occured in commit release of database\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); 116 Advanced Functions and Administration on DB2 Universal Database for iSeries } EXEC SQL connect to ROCHESTER; 3 if ( sqlca.sqlcode != 0 ) { printf( "Error occured in Connecting to Database\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); } printf( "Successfully connected to ROCHESTER..\n"); EXEC SQL commit; if ( sqlca.sqlcode != 0 ) { printf( "Error occured in commit of connection\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); } printf( "Commited the Connection...\n" ); EXEC SQL call 4 ordapplib/inscst( :Chr_CusNbr, :Chr_CusNam, :Chr_CusTel, :Chr_CusFax, :Chr_CusAdr, :Chr_CusCty, :Chr_CusZip, :Nmpd_CusCrd ); if ( sqlca.sqlcode != 0 ) { printf( "Error occured in calling stored procedure\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); EXEC SQL rollback; if ( sqlca.sqlcode != 0 ) { printf( "Error occured in rollback\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); } printf( "Rollback Complete...\n" ); } else { EXEC SQL commit; Chapter 5. DRDA and two-phase commitment control 117 if ( sqlca.sqlcode != 0 ) { printf( "Error occured in commit\n" ); printf( "The SQLCODE is %d\n", sqlca.sqlcode ); printf( "The Error Message :\n" ); printf( "%s\n", sqlca.sqlerrmc ); exit( -1 ); } printf( "Commit Complete...\n" ); } exit(0); } 5.10.3 Troubleshooting DRDA over TCP/IP DRDA over TCP/IP works fine until someone changes something. While handling the problems, you need to be single-minded about isolating them. First, ask yourself these simple questions:  Is the server job running on the application server? Make sure that QRWTLSTN is running in the QSYSWRK subsystem. Start the NETSTAT command, and select option 3 to check whether the listener job listens on the well-known port 446.  Are you authorized to use the connection? Does the server require a password along with the user ID on the connection request? If a password is needed, add your profile by using the ADDSVRAUTE command to the server authorization entry list.  Does your connection permit committable updates? Use Interactive SQL to check the connection type to the remote application server. Refer to “Interactive SQL example” on page 113, for a detailed discussion on this subject. If you went over this simple checklist and still encounter problems with your DRDA over TCP/IP connection, it is time to take a more systematic approach: 1. On the AS system, find the prestart job that is servicing your requests. When you start the listener job with the STRTCPSVR command, one or more prestart jobs are started in the QSYSWRK subsystem. The name of this prestart job is QRWTSRVR, and the user profile under which the job runs initially is QUSER. When your request to start a connection is accepted by the prestart job, it swaps QUSER to your user profile. The easiest way to identify the fully-qualified name for the prestart job servicing your requests is to look into the history log. There should be a log entry pertaining to your user ID (Figure 5-23). Notes:  Disconnect from the local database since it is protected by a two-phase commit. If you have a connection to a *DUW capable database, all subsequent connections to *RUW capable databases are read-only.  The COMMIT statement is needed to change the local database status from released to unconnected.  Connect to the remote AS using DRDA over TCP/IP. The connection method is *RUW, and committable updates are permitted.  Call the remote stored procedure. This procedure inserts a new record into the customer file. 118 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-23 Identifying a server job servicing your profile An alternative method is to use the WRKACTJOB command. 2. Once you identify your prestart job, you can start a service job with the STRSRVJOB command (Figure 5-24). Figure 5-24 Starting a service job 3. Enter the STRDBG command, and press F4. Change the Update production Files parameter to *YES (Figure 5-25). Figure 5-25 Starting debug for the prestart job 4. If the connection to the AS is still active, you can check the AR-AS interaction by looking at the job log of the prestarted job that is servicing your requests. Use the following command on the AS to display the job log: DSPJOBLOG JOB(034509/QUSER/QRWTSRVR) Display History Log Contents Job 034557/QUSER/QRWTSRVR started on 12/17/01 at 11:44:41 in subsystem QSYSWRK Job 034558/QUSER/QRWTSRVR started on 12/17/01 at 11:44:41 in subsystem QSYSWRK DDM job 034509/QUSER/QRWTSRVR servicing user JAREK on 12/17/01 at 11:44:42. Start Service Job (STRSRVJOB) Type choices, press Enter. Job name . . . . . . . . . . . . QRWTSRVR Name User . . . . . . . . . . . . . QUSER Name Number . . . . . . . . . . . . 034509 000000-999999 Start Debug (STRDBG) Type choices, press Enter. Program . . . . . . . . . . . . PGM *NONE Library . . . . . . . . . . . + for more values Default program . . . . . . . . DFTPGM *PGM Maximum trace statements . . . . MAXTRC 200 Trace full . . . . . . . . . . . TRCFULL *STOPTRC Update production files . . . . UPDPROD *YES Chapter 5. DRDA and two-phase commitment control 119 Figure 5-26 Job log of the prestart job Looking at the job log entries (Figure 5-26), you can now see that you were trying to call the INSCST stored procedure with an incorrect number of parameters. 5. Close your connection to the AS system. Since the prestart job was being serviced, the job log associated with this job is saved in a spooled file. This spooled file is stored with your user ID. Note: The job log is also saved when the system detects that a serious error occurred in processing the request that ended the connection. 6. Use the Work with Spooled File (WRKSPLF) command to display the content of the spooled file (Figure 5-27). Figure 5-27 Spooled file content 7. Stop debugging with the End Debug (ENDDBG) command, and stop the service job with the End Server Job (ENDSRVJOB) command. Display All Messages System: ROCHESTER Job . . : QRWTSRVR User . . : QUSER Number . . . : 034509 Job 034557/QUSER/QRWTSRVR started on 12/17/01 at 11:44:41 in subsystem QSYSWRK in QSYS. Job entered system on 12/17/01 at 11:44:41. Target job assigned to handle DDM connection started by source system ove TCP/IP. ACGDTA for 034557/QUSER/QRWTSRVR not journaled; reason 1. Local relational database accessed by ZURICH. Number of parameters on CALL not valid for procedure INSCST in ORDAPPLIB. 5769SS1 V4R2M0 980228 Display Job Log ROCHESTER 12/17/01 14:28:56 Page 1 Job name . . . . . . . . . . : QRWTSRVR User . . . . . . : QUSER Number . . . . . . . . . . . : 034558 Job description . . . . . . : QUSER Library . . . . . : QGPL MSGID TYPE SEV DATE TIME FROM PGM LIBRARY INST TO PGM LIBRARY INST CPF1124 Information 00 12/17/01 11:44:41 QWTPIIPP QSYS 0599 *EXT *N Message . . . . : Job 034558/QUSER/QRWTSRVR started on 12/17/01 at 11:44:41 in subsystem QSYSWRK in QSYS SQL0440 Diagnostic 30 12/17/01 14:26:56 QSQXCUTE QSYS 1B9A QSQXCUTE QSYS 1B9A Message . . . . : Number of parameters on CALL not valid for procedure INSCST in ORDAPPLIB. Cause . . . . . : The number of parameters specified on a CALL statement is not the same as the number of parameters declared for procedure INSCST in ORDAPPLIB. Recovery . . . : Specify the same number of parameters on the CALL as on the procedure definition. Try the request again. 120 Advanced Functions and Administration on DB2 Universal Database for iSeries 5.11 DB2 Connect access to an iSeries server via TCP/IP Since OS/400 V4R2, it is possible to connect to an iSeries server from DB2 Connect on a Windows machine using TCP/IP. The following example employs OS/400 V4R5 and the DB2 UDB for Windows NT Version 7.1. 5.11.1 On the iSeries server The following process lists the necessary steps to be performed on the iSeries server: 1. Verify that the TCP/IP stack is working correctly. To do this, obtain the IP address of the iSeries server or hostname, and ping the iSeries server from the DB2 Connect machine. To find the IP address, go to the Configure TCP/IP menu. Enter CFGTCP, and choose Work with TCP/IP interface. The IP address should be displayed as shown in Figure 5-28. Figure 5-28 Work with TCP/IP Interfaces 2. To find the hostname, go to the Configure TCP/IP menu, and choose Work with TCP/IP host table entries. You should find the hostname that has been assigned to the IP address. 3. You need a relational database (RDB) name for the iSeries server. If it has already been created, you can display it by using the DSPRDBDIRE command. The RDB with a location of *LOCAL is the one you need, as shown in Figure 5-29. If it has not been created, use the ADDRDBDIRE command to add the RDB entry. For example, the following command would add an RDB entry named DALLASDB: ADDRDBDIRE RDB(DALLASDB) RMTLOCNAME(*LOCAL) Work with TCP/IP Interfaces System: AS23 Type options, press Enter. 1=Add 2=Change 4=Remove 5=Display 9=Start 10=End Internet Subnet Line Line Opt Address Mask Description Type 10.10.10.10 255.255.255.0 TRNLINE *TRLAN Bottom F3=Exit F5=Refresh F6=Print list F11=Display interface status F12=Cancel F17=Top F18=Bottom Chapter 5. DRDA and two-phase commitment control 121 Figure 5-29 Display Relational Database Directory Entries 4. You must create a collection called NULLID. The reason for this is that the utilities shipped with DB2 Connect and DB2 UDB store their packages in the NULLID collection. Since it does not exist by default in the iSeries server, you must create it using the following command: CRTLIB LIB(NULLID) 5. Products that support DRDA automatically perform any necessary code page conversions at the receiving system. For this to happen, both systems need a translation table from their code page to the partner code page. The default Coded Character Set Identifier (CCSID) on the iSeries server is 65535. Since DB2 Connect does not have a translation table for this code page, you need to change the individual user profiles to contain a page. You need to change the individual user profiles to contain a CCSID that can be converted properly by DB2 Connect. For US English, this is 037. For other languages, see DB2 Connect Personal Edition Quick Beginning, GC09-2967. The following command changes the CCSID for an individual user profile to 037: CHGUSRPRF userid CCSID(037) 6. Verify that you are using the default port 446 for DRDA service. To do this, go to the Configure TCP/IP menu (CFGTCP), select Configure Related Tables, and then select Work with service table entries. Verify that the DRDA service is set for port 446, as shown in Figure 5-30. Display Relational Database Directory Entries Position to . . . . . . Type options, press Enter. 5=Display details 6=Print details Relational Remote Option Database Location Text AS23 *LOCAL DB entry for local AS23 AS24 10.10.10.20 RBD Entry for AS24 Bottom F3=Exit F5=Refresh F6=Print list F12=Cancel (C) COPYRIGHT IBM CORP. 1980, 2000. 122 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-30 Work with Service Table Entries 7. The Distributed Data Management (DDM) job must be started for DRDA to work. If you want the DDM job to be automatically started whenever TCP/IP is started, you can change the attributes of the DDM job using the CHGDDMTCPA command and set the Autostart server parameter to *YES. 8. If you choose not to autostart the server, issue the following command to start the DDM server job: STRTCPSVR(*DDM) 9. Make sure you have user IDs defined on the iSeries server for the users that will be connecting. 5.11.2 On the workstation The following steps are required on DB2 UDB: 1. Launch Client Configuration Assistant (db2cca from the command prompt). 2. Click the Add button to add a new data source. 3. On the Source tab, choose Manual configuration, and click Next. 4. On the Protocol tab, choose TCP/IP for protocol, and select the item The database physical residence on a host or AS/400. Then, select the option Connect directly to the server, as shown in Figure 5-31. Click Next. Work with Service Table Entries System: AS23 Type options, press Enter. 1=Add 4=Remove 5=Display Opt Service Port Protocol drda 446 udp echo 7 tcp echo 7 udp exec 512 tcp finger 79 tcp finger 79 udp ftp-control 21 tcp ftp-control 21 udp ftp-data 20 tcp ftp-data 20 udp gopher 70 tcp More... Parameters for options 1 and 4 or command ===> F3=Exit F4=Prompt F5=Refresh F6=Print list F9=Retrieve F12=Cancel F17=Top F18=Bottom Chapter 5. DRDA and two-phase commitment control 123 Figure 5-31 Protocol tab of the workstation configuration 5. On the TCP/IP tab, fill in the host name of the iSeries server. The port number should be 446. Click Next. 6. On the Database tab, fill in the relational database name, and click Next. 7. If you plan to use the ODBC applications, click the ODBC tab and select Register this database for ODBC as a system data source. 8. Click Finish. 9. Click Test Connection to verify that the connection works. You are prompted for an iSeries server user ID and password, as shown in Figure 5-32. Figure 5-32 Prompt for iSeries server user ID and password 10.Enter your user ID and password, and then click OK. If the connection test passed, a successful message box appears, as shown in Figure 5-33. 124 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 5-33 Message box for successful connection 5.11.3 Consideration Once you complete the configuration in the previous section, you should be able to access iSeries server data. However, you may notice that there are some areas that work differently in the iSeries server and other platforms. These areas are discussed in the following sections. Administrative interface In the current implementation, you cannot perform administrative functions for the iSeries server database through the UDB control center. The best tool for the iSeries server database is Operations Navigator. The differences in the administrative interface are due to the variation of administrative requirements and the operation of the underlying operating system. Several administrative functions are not available by DB2 Universal Database for iSeries because the database manager and operating system automatically handle the tasks. For example, DB2 Universal Database for iSeries doesn't provide a RUNSTATS utility for optimizer statistics because its database manager keeps these statistics current at all times. Likewise, there is no concept of table spaces in DB2 Universal Database for iSeries. DB2 Universal Database for iSeries does not support the notion of independent, isolated databases on the iSeries server. Instead, DB2 Universal Database for iSeries is implemented as a single system-wide database. Journaling in DB2 Universal Database for iSeries DB2 Universal Database for iSeries is so reliable that database administrators may not journal all their tables. However, if you are connecting to an iSeries server database through DB2 Connect, tables must be journaled before the database can be accessed for update. Otherwise, you only have read-only access to the table. If you attempt to update the table without journaling, you would see an error message such as this example: --------------------------- Command entered ---------------------------- insert into result values ('Insert','Insert from UDB/NT command center'); ------------------------------------------------------------------------ DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL7008N REXX variable "RESULT " contains inconsistent data. SQLSTATE=55019 © Copyright IBM Corp. 1994, 1997, 2000, 2001 125 Chapter 6. DB2 Import and Export utilities This chapter covers the following topics:  Explains the CPYFRMIMPF command (Import utility)  Explains the CPYTOIMPF command (Export utility)  Explains how to use the Import and Export utilities from DB2 UDB V7.2 6 126 Advanced Functions and Administration on DB2 Universal Database for iSeries 6.1 Introduction A data loader utility enables the loading of data exported from other database servers into DB2 UDB for iSeries. Two commands in OS/400 are available for users to import (load), and export (unload) data to and from the iSeries server:  Copy From Import File (CPYFRMIMPF): Loads the imported data into the DB2 UDB for iSeries table  Copy To Import File (CPYTOIMPF): Prepares the DB2 UDB for iSeries table data for export from the iSeries server 6.2 DB2 UDB for iSeries Import utility Database tables from heterogenous databases, such as Oracle, Sybase, Microsoft SQL Server, etc., can be ported to DB2 UDB for iSeries tables using this utility. 6.2.1 CPYFRMIMPF The Copy From Import File (CPYFRMIMPF) command is used to load data to DB2 UDB for iSeries after the file is copied to a source file (FROMFILE) and then into a DB2 UDB for iSeries table (TOFILE). This is shown in Figure 6-1. Figure 6-1 Data load flow The following steps summarize a data load from a database table: 1. Create an import file for the data that will be copied to DB2 UDB for iSeries. The format for this data can be in delimited format or fixed format. 2. Send the data to the import file (typically with FTP or Client Access). 3. Create a DB2 UDB for iSeries externally described database file(table) or DDM file that contains the resulting data (target file) of the import file. 4. Create the Field Definition File if a *FIXED data format is used. File from external database Import file created on iSeries server (FROMFILE) Field Definition File (optional) Final DB2 UDB for iSeries (TOFILE) TCP/IP CA/400 ODBC CPYFRMIMPF Chapter 6. DB2 Import and Export utilities 127 5. Use the CPYFRMIMPF command to copy (translate or parse the records) from the import file to the target file. The source file (FROMFILE) The source file (FROMFILE) can be any one of the following file types:  Stream file  DDM file  Tape file  Source physical file  Distributed physical file  Program described physical file  Single format logical file  Externally described physical file with one field (of non-numeric data type) Note: If an externally described physical file has one field, the data type must be CHARACTER, IGC OPEN, IGC EITHER, IGC ONLY, GRAPHIC, or variable length. The file can be copied or imported to the iSeries server using several methods, including:  TCP/IP file transfer (text transfer)  CA/400 support (file transfer, ODBC)  Copy From Tape (CPYFRMTAP) command Sending the data into the import file causes the necessary ASCII to EBCDIC data conversions to occur. The target file (TOFILE) The source file is copied to the database target file, also referred to as the TOFILE. The target file can be any one of the following file types:  Source file  DDM file  Distributed physical file  Program described file  Externally described physical file Data format The data contained in the imported file can be in either the delimiter format or the fixed format:  Character delimited: A delimiter format import file has a series of characters (delimiters) that are used to define where fields begin and end. The parameters of the command defines what characters are used for delimiters.  Fixed format: A fixed format import file uses the user-defined Field Definition File (FDF) that defines the format of the import file. The Field Definition File is used to define where fields begin, end, and are null. The record format of import file (DTAFMT) parameter determines if the source file is delimited (*DLM) or fixed (*FIXED). Field definition file The field definition file to describe fixed formatted files must use the format shown in Table 6-1. 128 Advanced Functions and Administration on DB2 Universal Database for iSeries Table 6-1 Field definition format In reference to Table 6-1, note the following statements:  Field name is the name of the field in the TOFILE. FDF is case sensitive.  The Starting position is the byte in the FROMFILE from where the data is copied.  The Ending position is the byte in the FROMFILE from where the data is copied.  The Null character position is the byte in the FROMFILE that indicates if the field is null. A value of “Y” means the field is null. A value of “N” means the field is not null. If this value is “0”, no null character is provided.  *END is the indicator for the end of the field definition file and must be included. Delimited format import file The import file’s data is interpreted by the following characters and data types for a delimited format import file:  Blanks – All leading and trailing blanks are discarded for character fields unless enclosed by string delimiters. – A field of all blanks is interpreted as a null field for character data. – Blanks cannot be embedded within a numeric field. – A blank cannot be selected as a delimiter.  Null fields A null field is defined as: – Two adjacent field delimiters (no data in between) – A field delimiter followed by a record delimiter (no data in between), an empty string – A field of all blanks If the field is null, the following statement is true: If the output field is not nullable and the import is a null field, the record is not copied, and an error is signaled.  Delimiters – A delimiter cannot be a blank. – A string delimiter cannot be the same as a field delimiter, record delimiter, date separator, or time separator. – A string delimiter can enclose all non-numeric fields (character, date, time, and so on). The string delimiter character should not be contained within the character string. – A field and record delimiter can be the same character. – The defaults for delimiters are as follows: Field name Starting position Ending position Null character position Field1 1 12 13 Field2 14 24 0 Field3 25 55 56 *END Chapter 6. DB2 Import and Export utilities 129 • String: Double quote (") • Field: Comma (,) • Decimal point: Period (.) • Record: End of record (*EOR) – If the data type of the from parameter is CHARACTER, OPEN, EITHER, or ONLY, all double-byte data must be contained within string delimiters or shift characters (for OPEN, EITHER, or ONLY data types).  Numeric field – Numeric fields can be imported in decimal or exponential form. – Data to the right of the decimal point may be truncated depending on the output data format. – Decimal points are either a period or a comma (command option). – Signed numeric fields are supported, + or -.  Character or Varcharacter fields – Fields too large to fit in the output fields are truncated (right), and a diagnostic message is sent. – An empty string is defined as two string delimiters with no data between them. – For a character to be recognized as a starting string delimiter, it must be the first non-blank character in the field. For example, 'abc' with ' as the delimiter is the same as abc for input. – Data after an ending string delimiter and before a field or record delimiter is discarded.  IGC or VarIGC fields – The data from the FROMFILE is copied to the TOFILE, and if any invalid data is received, a mapping error is generated. – Data located between the Shift Out and Shift In characters is treated as double byte data and is not parsed for delimiters. The Shift characters, in this case, become “string delimiters”.  Graphic, VarGraphic fields The data from the FROMFILE is copied to the TOFILE.  CCSIDs (coded character set identifiers) – The data from the FROMFILE is read into a buffer by the CCSID of the FROMFILE. The data in the buffer is checked and written to the TOFILE. The CCSID of the open TOFILE is set to the value of the FROMFILE, unless a TOFILE CCSID is used. If a TOFILE CCSID is used, the data is converted to that CCSID. If the FROMFILE is a tape file, and the FROMCCSID(*FILE) parameter is specified, the job CCSID is used, or the FROMFILE CCSID is requested by the user. – The character data (delimiters) passed in on the command is converted to the CCSID of the FROMFILE. This allows the character data of the FROMFILE and command parameters to be compatible.  Date field – All date formats supported by the iSeries server can be imported, including: *ISO, *USA, *EUR, *JIS, *MDY, *DMY,*YMD, *JUL, and *YYMD. – A date field can be copied to a timestamp field. 130 Advanced Functions and Administration on DB2 Universal Database for iSeries  Time field – All time formats supported by the iSeries server can be imported, including: *ISO, *USA, *EUR, *JIS, and *HMS. – A time field can be copied to a timestamp field.  Date and time separators All valid separators are supported for date and time fields.  Timestamp field Timestamp import fields must be 26 bytes. The import ensures that periods exist in the time portion and a dash exists between the date and time portions of the timestamp.  Number of fields mismatch If the FROMFILE or TOFILE do not have the same number of fields, the data is either truncated to the smaller TOFILE size, or the extra TOFILE fields receives a null value. If the fields are not null capable, an error message is issued. 6.2.2 Data load example (file definition file) A source file, IMPF_TEST, was created using the Create Physical File (CRTPF) command specifying a record length of 258 bytes. The customer data was then transferred to the iSeries server source file using FTP. A sample of the data is shown in Figure 6-2. Figure 6-2 Customer data sample A target file, or TOFILE, was created using Data Definition Specification (DDS) called CUST_IMPF. At this time, the CPYFRMIMPF command can be used to format the delimited file as shown in Figure 6-3. Display Physical File Member File . . . . . . : IMPF_TEST Library . . . . : TPSTAR Member . . . . . : IMPF_TEST Record . . . . . : 1 Control . . . . . Column . . . . . : 1 Find . . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+... 1 ,"Customer#000000001 ",15 Monroe Ave, Chicago IL 60601 2 ,"Customer#000000002 ","Stewartville MN 55976 3 ,"Customer#000000003 ","389 Dexter Pl, Fargo ND 4 ,"Customer#000000004 ","10 N Main, Wausau WI 5 ,"Customer#000000005 ","Bailey Bldg, Bedford Falls 6 ,"Customer#000000006 ","101 Superior St, Duluth MN 7 ,"Customer#000000007 ","1921 N 5th St, St Louis MO 8 ,"Customer#000000008 ","32891 Park Ave, New York NY 9 ,"Customer#000000009 ","1032 S Broadway, Littleton CO 10 ,"Customer#000000010 ","5672 Cobb Pkwy, Bldg 3, Atlanta GA 11 ,"Customer#000000011 ","8192 River Rd, Aurora IL 12 ,"Customer#000000012 ","County Rd 9, Pine Island MN 13 ,"Customer#000000013 ","25th and Main, Appleton WI 14 ,"Customer#000000014 ","2342 Center St, Earlville IL 15 ,"Customer#000000015 ","444 Michigan Ave, Chicago Chapter 6. DB2 Import and Export utilities 131 Figure 6-3 CPYFRMIMPF example A fixed format using a field definition file (FDF) can also be used to convert the data. The example in Figure 6-4 of the FDF, CUST.FDF, was created in the Screen Edit Utility (SEU) as a TEXT file. Figure 6-4 Field definition file The CPYFRMIMPF command for the *FIXED format is shown in Figure 6-5 and Figure 6-6. Copy From Import File (CPYFRMIMPF) Type choices, press Enter. From stream file . . . . . . . . From file: File . . . . . . . . . . . . . IMPF_TEST Name Library . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB Member . . . . . . . . . . . . *FIRST Name, *FIRST To data base file: File . . . . . . . . . . . . . CUST_IMPF Name Library . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB Member . . . . . . . . . . . . *FIRST Name, *FIRST Replace or add records . . . . . *ADD *ADD, *REPLACE, *UPDADD Stream file record length . . . *TOFILE Number, *TOFILE From CCSID . . . . . . . . . . . *FILE 1-65533, *FILE Record delimiter . . . . . . . . *EOR Character value, *ALL... Record format of import file . . *DLM *DLM, *FIXED String delimiter . . . . . . . . '"' Character value, *NONE More... LEVEL 0 SCREEN CHECK YOUR LEVEL This is screen.Columns . . . : 1 71 Browse V2KEA45/QTXTSRC SEU==> CUST.FDF FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 *************** Beginning of data ************************************* 001.00 CUSTKEY 1 12 0 002.00 CUSTOMER 14 40 0 003.00 ADDRESS 42 83 0 004.00 PHONE 85 101 0 005.00 MKTSEGMENT 103 114 0 006.00 COUNTRY 116 142 0 007.00 CONTINENT 144 170 0 008.00 REGION 172 198 0 009.00 TERRITORY 200 226 0 010.00 SALES00001 228 254 0 011.00 DUMMYKEY 256 258 0 012.00 *END ****************** End of data **************************************** 132 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-5 CPYFRMIMPF Command (Part 1 of 3) Figure 6-6 CPYFRMIMPF command (Part 2 of 3) Copy From Import File (CPYFRMIMPF) Type choices, press Enter. From stream file . . . . . . . . From file: File . . . . . . . . . . . . . > IMPF_TEST Name Library . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB Member . . . . . . . . . . . . *FIRST Name, *FIRST To data base file: File . . . . . . . . . . . . . > CUST_IMPF Name Library . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB Member . . . . . . . . . . . . *FIRST Name, *FIRST Replace or add records . . . . . *ADD *ADD, *REPLACE, *UPDADD Stream file record length . . . *TOFILE Number, *TOFILE From CCSID . . . . . . . . . . . *FILE 1-65533, *FILE Record delimiter . . . . . . . . > *ALL Character value, *ALL... Record format of import file . . > *FIXED *DLM, *FIXED String delimiter . . . . . . . . '"' Character value, *NONE More... Copy From Import File (CPYFRMIMPF) Type choices, press Enter. Remove leading blanks . . . . . *LEADING *LEADING, *NONE Field delimiter . . . . . . . . ',' Character value, *TAB Field definition file: File . . . . . . . . . . . . . > QTXTSRC Name Library . . . . . . . . . . > TPSTAR Name, *LIBL, *CURLIB Member . . . . . . . . . . . . > CUST_FDF Name, *FIRST Decimal point . . . . . . . . . *PERIOD *PERIOD, *COMMA Date format . . . . . . . . . . *ISO *ISO, *USA, *EUR, *JIS... Date separator . . . . . . . . . '/' /, -, ., ,, *BLANK Time format . . . . . . . . . . *ISO *ISO, *USA, *EUR, *JIS, *HMS Time separator . . . . . . . . . ':' :, ., *BLANK Copy from record number: Copy from record number . . . *FIRST Number, *FIRST Number of records to copy . . *END Number, *END Errors allowed . . . . . . . . . *NOMAX Number, *NOMAX More... Chapter 6. DB2 Import and Export utilities 133 Figure 6-7 CPYFRMIMPF Command (Part 3 of 3) If a field in the source file is not included in the target file, omit the field in the FDF file. Enhancements have been made to the CPYFRMIMPF Import utility by adding the following parameters:  Remove leading blanks (RMVBLANK) – If *LEADING is specified along with STRDLM(*NONE), then DB2 UDB for iSeries strips leading blanks from a character string before placing the resulting string in the specified character column. – With *NONE, all leading blanks are included in the result string that is copied into the specified target character column.  Replace null values (RPLNULLVAL) – When *FLDFT is specified, if the data being imported (for example, blanks in a numeric field) causes DB2 UDB for iSeries to place a null value in a target column that does not allow nulls, then DB2 UDB for iSeries will assign the default value to the target column instead. – When the default value *NO is specified, no replacement of null values is performed. 6.2.3 Data load example (Data Definition Language) The Data Definition Language (DDL) source file STAFF.ddl and the Database extract file STAFFA.csv in comma-separated variable (CSV) format reside on the source system. The database extract file has to be exported to DB2 UDB for iSeries on the target iSeries server AS23. A TCP/IP connection exists between the two systems. Copy From Import File (CPYFRMIMPF) Type choices, press Enter. Error record file: File . . . . . . . . . . . . . *NONE Name, *NONE Library . . . . . . . . . . Name, *LIBL, *CURLIB Member . . . . . . . . . . . . Name, *FIRST Replace or add records . . . . . *ADD *ADD, *REPLACE Replace null values . . . . . . *NO *NO, *FLDDFT Bottom F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys 134 Advanced Functions and Administration on DB2 Universal Database for iSeries To transfer these two files to the iSeries server, follow these steps: 1. FTP the ddl file and csv file to the iSeries server as shown here: C:\>ftp as23 1 Connected to AS23. 220-QTCP at rchasm23.rchland.ibm.com. 220 Connection will close if idle more than 5 minutes. User (AS23:(none)): vijay 2 331 Enter password. Password: 3 230 VIJAY logged on. ftp> put c:\vijay\staff.ddl vijay/sqlsrc.staff 4 200 PORT subcommand request successful. 150 Sending file to member STAFF in file SQLSRC in library VIJAY. 250 File transfer completed successfully. ftp: 317 bytes sent in 0.00Seconds 317000.00Kbytes/sec. ftp> put c:\vijay\staffa.csv vijay/staffa.staffa 5 200 PORT subcommand request successful. 150 Sending file to member STAFFA in file STAFFA in library VIJAY. 250 File transfer completed successfully. ftp: 2205 bytes sent in 0.01Seconds 220.50Kbytes/sec. ftp>quit 6 Figure 6-8 shows the DDL source imported to create the table STAFFI on the iSeries server. Notes: 1 From a command line, type FTP to the iSeries server AS23. 2 Enter your user ID and press Enter. 3 Type your password and press Enter. 4 Type the PUT sub-command to copy the staff.ddl file in the vijay directory to member STAFF in source physical file SQLSRC in the library VIJAY. Note the use of the forward slash (/) and the period (.) in the target file name (library/file.member) format. 5 Type the PUT sub-command to copy the extracted database file staffa.csv in the vijay directory to the single field physical file member STAFFA in the physical file STAFFA in the library VIJAY. Note the use of the forward slash (/) and the period (.) in the target file name (library/file.member) format. 6 Type QUIT and press Enter to exit the FTP session. Chapter 6. DB2 Import and Export utilities 135 Figure 6-8 Imported DDL for the STAFFA table Figure 6-9 shows the STAFFA data file imported in the CSV data format to the VIJAY library. Columns . . . : 1 71 Browse VIJAY/SQLSRC SEU==> STAFF FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 *************** Beginning of data ************************************* 0001.00 0002.00 CREATE TABLE VIJAY.STAFFI ( 0003.00 ID SMALLINT NOT NULL , 0004.00 NAME VARCHAR(9) CCSID 37 DEFAULT NULL , 0005.00 DEPT SMALLINT DEFAULT NULL , 0006.00 JOB CHAR(5) CCSID 37 DEFAULT NULL , 0007.00 "YEARS" SMALLINT DEFAULT NULL , 0008.00 SALARY DECIMAL(7, 2) DEFAULT NULL , 0009.00 COMM DECIMAL(7, 2) DEFAULT NULL 0010.00 ); 0011.00 ****************** End of data **************************************** F3=Exit F5=Refresh F9=Retrieve F10=Cursor F11=Toggle F12=Cancel F16=Repeat find F24=More keys (C) COPYRIGHT IBM CORP. 1981, 2000. 136 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-9 Imported STAFFA.csv data file 2. Use the Run SQL Statement (RUNSQLSTM) command from the iSeries server command line to use the DDL source to create the STAFFI table in library VIJAY: RUNSQLSTM SRCFILE(VIJAY/SQLSRC) SRCMBR(STAFF) COMMIT(*NONE) NAMING(*SQL) This command has the *SQL naming convention specified as used in the DDL in Figure 6-8. Also the COMMIT parameter is specified with the value *NONE as because just want to create the table in library VIJAY and do not plan to use commitment control. 3. The last step imports the STAFFA file in the CSV data format using the CPYFRMIMPF command. It also includes populating the STAFFI table in the library VIJAY. Type the following command from a command line and press Enter to accept the defaults for string a delimiter and field separator: CPYFRMIMPF FROMFILE(VIJAY/STAFFA) TOFILE(VIJAY/STAFFI) MBROPT(*REPLACE) Member STAFFI file STAFFI in VIJAY cleared. 35 records copied from member STAFFA. Use the RUNQRY command to look at the data in table STAFFI: RUNQRY *N VIJAY/STAFFI *...+....1....+....2....+....3....+....4....+....5....+....6. 10 ,"Sanders ",20 ,"Mgr ",7 ,18357.50 ,300.00 20 ,"Pernal ",20 ,"Sales",8 ,18171.25 ,1112.45 30 ,"Marenghi ",38 ,"Mgr ",5 ,17506.75 ,500.00 40 ,"O'Brien ",38 ,"Sales",6 ,18006.00 ,846.55 50 ,"Hanes ",15 ,"Mgr ",10 ,20659.80 ,.00 60 ,"Quigley ",38 ,"Sales",0 ,16808.30 ,650.25 70 ,"Rothman ",15 ,"Sales",7 ,16502.83 ,1152.00 80 ,"James ",20 ,"Clerk",0 ,13504.60 ,128.20 90 ,"Koonitz ",42 ,"Sales",6 ,18001.75 ,1386.70 100 ,"Plotz ",42 ,"Mgr ",7 ,18352.80 ,.00 110 ,"Ngan ",15 ,"Clerk",5 ,12508.20 ,206.60 120 ,"Naughton ",38 ,"Clerk",0 ,12954.75 ,180.00 130 ,"Yamaguchi",42 ,"Clerk",6 ,10505.90 ,75.60 140 ,"Fraye ",51 ,"Mgr ",6 ,21150.00 ,.00 150 ,"Williams ",51 ,"Sales",6 ,19456.50 ,637.65 160 ,"Molinare ",10 ,"Mgr ",7 ,22959.20 ,.00 170 ,"Kermisch ",15 ,"Clerk",4 ,12258.50 ,110.10 180 ,"Abrahams ",38 ,"Clerk",3 ,12009.75 ,236.50 190 ,"Sneider ",20 ,"Clerk",8 ,14252.75 ,126.50 200 ,"Scoutten ",42 ,"Clerk",0 ,11508.60 ,84.20 210 ,"Lu ",10 ,"Mgr ",10 ,20010.00 ,.00 220 ,"Smith ",51 ,"Sales",7 ,17654.50 ,992.80 230 ,"Lundquist",51 ,"Clerk",3 ,13369.80 ,189.65 240 ,"Daniels ",10 ,"Mgr ",5 ,19260.25 ,.00 250 ,"Wheeler ",51 ,"Clerk",6 ,14460.00 ,513.30 260 ,"Jones ",10 ,"Mgr ",12 ,21234.00 ,.00 270 ,"Lea ",66 ,"Mgr ",9 ,18555.50 ,.00 280 ,"Wilson ",66 ,"Sales",9 ,18674.50 ,811.50 290 ,"Quill ",84 ,"Mgr ",10 ,19818.00 ,.00 300 ,"Davis ",84 ,"Sales",5 ,15454.50 ,806.10 310 ,"Graham ",66 ,"Sales",13 ,21000.00 ,200.30 320 ,"Gonzales ",66 ,"Sales",4 ,16858.20 ,844.00 330 ,"Burke ",66 ,"Clerk",1 ,10988.00 ,55.50 340 ,"Edwards ",84 ,"Sales",7 ,17844.00 ,1285.00 350 ,"Gafney ",84 ,"Clerk",5 ,13030.50 ,188.00 Chapter 6. DB2 Import and Export utilities 137 This command produces the report shown in Figure 6-10. Figure 6-10 RUNQRY report for the STAFFI table 6.2.4 Parallel data loader When using the CPYFRMIMPF command, you can take advantage of loading data into DB2 Universal Database for iSeries in parallel when the DB2 UDB for iSeries Symmetric Multiprocessing (SMP) licensed feature of OS/400 is installed and activated on the iSeries server to activate parallelism. DB2 UDB for iSeries uses multiple tasks to load the large file. The command breaks the file into blocks and submits the blocks in parallel; the entire file is processed at the same time. The number of tasks used during the copy is determined by DEGREE(*NBRTASKS) on the Change Query Attributes (CHGQRYA) command. Table 6-2, based on the results of performance testing by the Teraplex Center using a 12-processor iSeries server, shows the advantages of parallel processing. The test used an import file containing 350 million rows with 100 GB of data. Table 6-2 Parallel data load Display Report Report width . . . . . : 64 Position to line . . . . . Shift to column . . . . . . Line ....+....1....+....2....+....3....+....4....+....5....+....6.... ID NAME DEPT JOB YEARS SALARY COMM 000001 10 Sanders 20 Mgr 7 18,357.50 300.00 000002 20 Pernal 20 Sales 8 18,171.25 1,112.45 000003 30 Marenghi 38 Mgr 5 17,506.75 500.00 000004 40 O'Brien 38 Sales 6 18,006.00 846.55 000005 50 Hanes 15 Mgr 10 20,659.80 .00 000006 60 Quigley 38 Sales 0 16,808.30 650.25 000007 70 Rothman 15 Sales 7 16,502.83 1,152.00 000008 80 James 20 Clerk 0 13,504.60 128.20 000009 90 Koonitz 42 Sales 6 18,001.75 1,386.70 000010 100 Plotz 42 Mgr 7 18,352.80 .00 000011 110 Ngan 15 Clerk 5 12,508.20 206.60 000012 120 Naughton 38 Clerk 0 12,954.75 180.00 000013 130 Yamaguchi 42 Clerk 6 10,505.90 75.60 000014 140 Fraye 51 Mgr 6 21,150.00 .00 000015 150 Williams 51 Sales 6 19,456.50 637.65 000016 160 Molinare 10 Mgr 7 22,959.20 .00 More... F3=Exit F12=Cancel F19=Left F20=Right F21=Split Load time Degree of parallel processing 47+ hours 1 4+ hours 12 138 Advanced Functions and Administration on DB2 Universal Database for iSeries 6.3 DB2 UDB for iSeries Export utility DB2 UDB for iSeries tables can be exported into a flat file with the CPYTOIMPF CL command (single threaded only). 6.3.1 CPYTOIMPF The Copy To Import File (CPYTOIMPF) command is used to export data from a DB2 UDB for iSeries table to either a source physical file or a stream file. The command copies an externally defined file to an import file; the term import file is used to describe a file created for the purpose of copying data between heterogenous databases. The import file (TOSTMF or TOFILE parameter of the command) can be sent to an external system using FTP or Client Access. The export data flow is shown in Figure 6-11. Figure 6-11 Data export flow The following steps summarize a data load from a database file: 1. Create an import file (TOFILE) for the data that will be copied to the external system. The format for this data can be in delimited format or fixed format. 2. Use the CPYTOIMPF command to copy (translate or parse the records) from the source DB2 UDB for iSeries file (FROMFILE) to the import file (TOFILE). 3. Send the data in the import file (typically with FTP or Client Access) to the external system. The source file (FROMFILE) The source file (FROMFILE) can be any one of the following file types:  Source physical file  Distributed physical file  Single format logical file  Externally described physical file with one field (of non-numeric data type) Note: If an externally described physical file has one field, the data type must be CHARACTER, IGC OPEN, IGC EITHER, IGC ONLY, GRAPHIC, or variable length. CPYTOIMPF Stream file or source file FTP or Client Access DB2 UDB for iSeries table External system Chapter 6. DB2 Import and Export utilities 139 The file can be copied or exported from the iSeries server using several methods, including:  TCP/IP file transfer (text transfer)  CA/400 support (file transfer, ODBC)  Copy To Tape (CPYTOTAP) command Sending the data into the import file causes the necessary EBCDIC to ASCII data conversions to occur. The target file (TOFILE) The source file (FROMFILE) is copied to the import file, also referred to as the TOFILE or TOSTMF. The import file can be any one of the following file types:  Parameter TOFILE – Source physical file – If the file is not a source file, the file can have only one field; the field of the file cannot be a numeric data type – Program described physical file – Externally described physical file that can have only one field; the field of the file cannot be a numeric data type  Parameter TOSTMF Specifies the path name of the output stream file to which the source file is copied. Data format (DTAFMT) The data can be copied to the TOFILE as either delimiter format or fixed format:  Delimited format (*DLM): A series of characters as delimiters to define where strings, fields, and records begin and end. – Delimiters cannot be blank. – A period cannot be a string delimiter. – A string delimiter cannot be the same as a field or record delimiter. – The defaults for delimiters are: • String: Double quote (“) • Field: Comma (,) • Record: End of record (*EOR)  Fixed format (*FIXED): Each field of the file is copied without delimiters – The NULLS parameter can only have the value *YES if DTAFMT(*FIXED) is used. This places either a “Y” or “N” after field data indicating if the field is null or not null. – The NULLS parameter can also have the default value *NO. This does not place a “Y” or “N” after field data. – A field definition file is not needed. Additional function has been added to the following parameters of the CPYTOIMPF command:  Stream file code page (STMCODPAG) Allows you to specify the code page of the target stream file. In the past, you would use another tool or command to first create the stream file with the desired code page to override the default behavior of the command. 140 Advanced Functions and Administration on DB2 Universal Database for iSeries  Replace or add records (MBROPT) If the CPYTOIMPF command is given an empty database table to copy, then DB2 UDB for iSeries now clears the target stream file when MBROPT(*REPLACE) is specified. 6.3.2 Creating the import file (TOFILE) This section shows the creation of the TOFILE using the *FIXED and *DLM data formats. The DB2 UDB for iSeries STAFF table in the library VIJAY is exported to another database server along with the DDL source for the file from the member STAFF in the SQLSRC source physical file in the library VIJAY: 1. Use the CRTPF command to create a single field physical file with a record length of 72 bytes: CRTPF FILE(VIJAY/PF72) RCDLEN(72) MAXMBRS(*NOMAX) 2. Use the RMVM command to remove the PF72 member from the PF72 file: RMVM FILE(VIJAY/PF72) MBR(PF72) More members are added to the file PF72 as we use the Export utility to create the import file (TOFILE). 3. Use the CPYTOIMPF command to copy the STAFF file and add the STAFFNLN member to the file PF72; the command specifies the DTAFMT(*FIXED) and NULLS(*NO) parameters as shown here: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOFILE(VIJAY/PF72 STAFFNLN) MBROPT(*REPLACE) DTAFMT(*FIXED) NULLIND(*NO) Figure 6-12 shows a partial list of the resulting member STAFFNLN. Figure 6-12 TOFILE with DTAFMT(*FIXED) NULLS(*NO) Display Physical File Member File . . . . . . : PF72 Library . . . . : VIJAY Member . . . . . : STAFFNLN Record . . . . . : 1 Control . . . . . Column . . . . . : 1 Find . . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. 10 Sanders 20 Mgr 7 18357.50 300.00 20 Pernal 20 Sales8 18171.25 1412.45 30 Marenghi 38 Mgr 5 17506.75 500.00 40 O'Brien 38 Sales6 18006.00 846.55 50 Hanes 15 Mgr 10 20659.80 0.0 60 Quigley 38 Sales0 16808.30 650.25 70 Rothman 15 Sales7 16502.83 1152.00 80 James 20 Clerk0 13504.60 128.20 90 Koonitz 42 Sales6 18001.75 1386.70 100 Plotz 42 Mgr 7 18352.80 0.0 110 Ngan 15 Clerk5 12508.20 206.60 120 Naughton 38 Clerk0 12954.75 180.00 130 Yamaguchi42 Clerk6 10505.90 75.60 140 Fraye 51 Mgr 6 21150.00 0.0 150 Williams 51 Sales6 19456.50 637.65 More... F3=Exit F12=Cancel F19=Left F20=Right F24=More keys Chapter 6. DB2 Import and Export utilities 141 4. Use the CPYTOIMPF command to copy the STAFF file and add the STAFFNLY member to the file PF72; the command specifies the DTAFMT(*FIXED) and NULLS(*YES) parameters as shown here: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOFILE(VIJAY/PF72 STAFFNLY) MBROPT(*REPLACE) DTAFMT(*FIXED) NULLIND(*YES) Figure 6-13 shows a partial list of the resulting member STAFFNLY; notice the “Y” after each field that has a null value and “N” after each field that does not have a null value. Figure 6-13 TOFILE with DTAFMT(*FIXED) NULLS(*YES) 5. Use the CPYTOIMPF command to copy the STAFF file and add the STAFFDLM member to the file PF72; the command specifies the DTAFMT(*DLM) parameter and uses the default delimiter values as follows: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOFILE(VIJAY/PF72 STAFFDLM) MBROPT(*REPLA CE) Figure 6-14 shows a partial list of the resulting STAFFDLM member; this member shows the data ready for export in the most common CSV format that is used to port data between heterogenous databases. Display Physical File Member File . . . . . . : PF72 Library . . . . : VIJAY Member . . . . . : STAFFNLY Record . . . . . : 1 Control . . . . . Column . . . . . : 1 Find . . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. 10 NSanders N20 NMgr N7 N18357.50 N300.00 N 20 NPernal N20 NSalesN8 N18171.25 N1412.45 N 30 NMarenghi N38 NMgr N5 N17506.75 N500.00 N 40 NO'Brien N38 NSalesN6 N18006.00 N846.55 N 50 NHanes N15 NMgr N10 N20659.80 N0.0 Y 60 NQuigley N38 NSalesN0 Y16808.30 N650.25 N 70 NRothman N15 NSalesN7 N16502.83 N1152.00 N 80 NJames N20 NClerkN0 Y13504.60 N128.20 N 90 NKoonitz N42 NSalesN6 N18001.75 N1386.70 N 100 NPlotz N42 NMgr N7 N18352.80 N0.0 Y 110 NNgan N15 NClerkN5 N12508.20 N206.60 N 120 NNaughton N38 NClerkN0 Y12954.75 N180.00 N 130 NYamaguchiN42 NClerkN6 N10505.90 N75.60 N 140 NFraye N51 NMgr N6 N21150.00 N0.0 Y 150 NWilliams N51 NSalesN6 N19456.50 N637.65 N More... F3=Exit F12=Cancel F19=Left F20=Right F24=More keys 142 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-14 TOFILE with DTAFMT(*DLM) 6. Use the CPYTOIMPF command to copy the DDL source from the STAFF member in the SQLSRC source physical file in the VIJAY library and add the STAFFDDL member to the file PF72; the command specifies the DTAFMT(*FIXED) parameter as shown here: CPYTOIMPF FROMFILE(VIJAY/SQLSRC STAFF) TOFILE(VIJAY/PF72 STAFFDDL) MBROPT(*REPLACE) DTAFMT(*FIXED) Figure 6-15 shows a partial list of the resulting member STAFFDLM. Display Physical File Member File . . . . . . : PF72 Library . . . . : VIJAY Member . . . . . : STAFFDLM Record . . . . . : 1 Control . . . . . Column . . . . . : 1 Find . . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. 10 ,"Sanders ",20 ,"Mgr ",7 ,18357.50 ,300.00 20 ,"Pernal ",20 ,"Sales",8 ,18171.25 ,1412.45 30 ,"Marenghi ",38 ,"Mgr ",5 ,17506.75 ,500.00 40 ,"O'Brien ",38 ,"Sales",6 ,18006.00 ,846.55 50 ,"Hanes ",15 ,"Mgr ",10 ,20659.80 ,, 60 ,"Quigley ",38 ,"Sales",,16808.30 ,650.25 70 ,"Rothman ",15 ,"Sales",7 ,16502.83 ,1152.00 80 ,"James ",20 ,"Clerk",,13504.60 ,128.20 90 ,"Koonitz ",42 ,"Sales",6 ,18001.75 ,1386.70 100 ,"Plotz ",42 ,"Mgr ",7 ,18352.80 ,, 110 ,"Ngan ",15 ,"Clerk",5 ,12508.20 ,206.60 120 ,"Naughton ",38 ,"Clerk",,12954.75 ,180.00 130 ,"Yamaguchi",42 ,"Clerk",6 ,10505.90 ,75.60 140 ,"Fraye ",51 ,"Mgr ",6 ,21150.00 ,, 150 ,"Williams ",51 ,"Sales",6 ,19456.50 ,637.65 More... F3=Exit F12=Cancel F19=Left F20=Right F24=More keys Chapter 6. DB2 Import and Export utilities 143 Figure 6-15 TOFILE for DDL source 6.3.3 Exporting the TOFILE The members STAFFDDL and STAFFDLM in the import file PF72 in the VIJAY library are exported to the external system. A TCP/IP connection exists between the iSeries server and the external database server. FTP is used for the data transfer between the two database servers. The FTP dialogue from the external system is shown here: C:\>ftp as23 1 Connected to AS23. 220-QTCP at rchasm23.rchland.ibm.com. 220 Connection will close if idle more than 5 minutes. User (AS23:(none)): vijay 2 331 Enter password. Password: 3 230 VIJAY logged on. ftp> get vijay/pf72.staffddl c:\vijay\staff.ddl 4 200 PORT subcommand request successful. 150 Retrieving member STAFFDDL in file PF72 in library VIJAY. 250 File transfer completed successfully. ftp: 305 bytes received in 0.00Seconds 305000.00Kbytes/sec. ftp> get vijay/pf72.staffdlm c:\vijay\staff.csv 5 200 PORT subcommand request successful. 150 Retrieving member STAFFDLM in file PF72 in library VIJAY. 250 File transfer completed successfully. ftp: 2136 bytes received in 0.00Seconds 2136000.00Kbytes/sec. ftp> quit 6 Display Physical File Member File . . . . . . : PF72 Library . . . . : VIJAY Member . . . . . : STAFFDDL Record . . . . . : 1 Control . . . . . Column . . . . . : 1 Find . . . . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7.. CREATE TABLE VIJAY.STAFFI ( ID SMALLINT NOT NULL , NAME VARCHAR(9) CCSID 37 DEFAULT NULL , DEPT SMALLINT DEFAULT NULL , JOB CHAR(5) CCSID 37 DEFAULT NULL , "YEARS" SMALLINT DEFAULT NULL , SALARY DECIMAL(7, 2) DEFAULT NULL , COMM DECIMAL(7, 2) DEFAULT NULL ); ****** END OF DATA ****** Bottom F3=Exit F12=Cancel F19=Left F20=Right F24=More keys 144 Advanced Functions and Administration on DB2 Universal Database for iSeries 6.3.4 Creating the import file (STMF) This section shows the creation of the STMF import file in the integrated file system (IFS) on the iSeries server using the *FIXED and *DLM data formats. The DB2 UDB for iSeries file STAFF in library VIJAY are exported to another database server along with the DDL source for the file from the member STAFF in source physical file SQLSRC in library VIJAY. 1. Use the make directory command to create the vijay directory in the integrated file system: md vijay 2. Use the CPYTOIMPF command to copy the STAFF file and add the staffnln.txt stream file to the vijay directory; the command specifies the DTAFMT(*FIXED) and NULLS(*NO) parameters as shown here: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOSTMF('/vijay/staffnln.txt') MBROPT(*REPLACE) RCDDLM(*LF) DTAFMT(*FIXED) Figure 6-16 shows a partial list of the resulting staffnln.txt stream file. Notes: 1 From a command line, type FTP to the iSeries server AS23. 2 Enter your user ID and press Enter. 3 Type your password and press Enter. 4 Type the GET sub-command to copy the STAFFDDL member in the file PF72 in the VIJAY library to the staff.ddl file in the vijay directory. Note the use of the forward slash (/) and the period (.) in the target file name (library/file.member) format. 5 Type the GET sub-command to copy the STAFFDLM member in the PF72 file in the VIJAY library to the staff.csv file in the vijay directory. Note the use of the forward slash (/) and the period (.) in the target file name (library/file.member) format. 6 Type QUIT and press Enter to exit the FTP session to iSeries server AS23. Chapter 6. DB2 Import and Export utilities 145 Figure 6-16 STMF DTAFMT(*FIXED) NULLS(*NO) 3. Use the CPYTOIMPF command to copy the STAFF file and add the staffnly.txt stream file to the vijay directory; the command specifies the DTAFMT(*FIXED) and NULLS(*YES) parameters as shown here: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOSTMF('/vijay/staffnly.txt') MBROPT(*REPLACE) RCDDLM(*LF) DTAFMT(*FIXED) NULLS(*YES) Figure 6-17 shows a partial list of the resulting staffnly.txt stream file. Browse : /vijay/staffnln.txt Record : 1 of 36 by 14 Column : 1 63 by 79 Control : ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+.... ************Beginning of data************** 10 Sanders 20 Mgr 7 18357.50 300.00 20 Pernal 20 Sales8 18171.25 1412.45 30 Marenghi 38 Mgr 5 17506.75 500.00 40 O'Brien 38 Sales6 18006.00 846.55 50 Hanes 15 Mgr 10 20659.80 0.0 60 Quigley 38 Sales0 16808.30 650.25 70 Rothman 15 Sales7 16502.83 1152.00 80 James 20 Clerk0 13504.60 128.20 90 Koonitz 42 Sales6 18001.75 1386.70 100 Plotz 42 Mgr 7 18352.80 0.0 110 Ngan 15 Clerk5 12508.20 206.60 120 Naughton 38 Clerk0 12954.75 180.00 130 Yamaguchi42 Clerk6 10505.90 75.60 140 Fraye 51 Mgr 6 21150.00 0.0 F3=Exit F10=Display Hex F12=Exit F15=Services F16=Repeat find F19=Left F20=Right (C) COPYRIGHT IBM CORP. 1980, 2000. 146 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-17 STMF DTAFMT(*FIXED) NULLS(*YES) 4. Use the CPYTOIMPF command to copy the STAFF file and add the staffdlm.csv stream file to the vijay directory; the command specifies the DTAFMT(*DLM) parameter and uses the default delimiters as shown here: CPYTOIMPF FROMFILE(VIJAY/STAFF) TOSTMF('/vijay/staffdlm.csv') MBROPT(*REPLACE) RCDDLM(*LF) Figure 6-18 shows a partial list of the resulting staffdlm.csv stream file. This stream file shows the data ready for export in the most common CSV format that is used to port data between heterogenous databases. Browse : /vijay/staffnly.txt Record : 1 of 36 by 14 Column : 1 72 by 79 Control : ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+.... ************Beginning of data************** 10 NSanders N20 NMgr N7 N18357.50 N300.00 N 20 NPernal N20 NSalesN8 N18171.25 N1412.45 N 30 NMarenghi N38 NMgr N5 N17506.75 N500.00 N 40 NO'Brien N38 NSalesN6 N18006.00 N846.55 N 50 NHanes N15 NMgr N10 N20659.80 N0.0 Y 60 NQuigley N38 NSalesN0 Y16808.30 N650.25 N 70 NRothman N15 NSalesN7 N16502.83 N1152.00 N 80 NJames N20 NClerkN0 Y13504.60 N128.20 N 90 NKoonitz N42 NSalesN6 N18001.75 N1386.70 N 100 NPlotz N42 NMgr N7 N18352.80 N0.0 Y 110 NNgan N15 NClerkN5 N12508.20 N206.60 N 120 NNaughton N38 NClerkN0 Y12954.75 N180.00 N 130 NYamaguchiN42 NClerkN6 N10505.90 N75.60 N 140 NFraye N51 NMgr N6 N21150.00 N0.0 Y F3=Exit F10=Display Hex F12=Exit F15=Services F16=Repeat find F19=Left F20=Right (C) COPYRIGHT IBM CORP. 1980, 2000. Chapter 6. DB2 Import and Export utilities 147 Figure 6-18 STMF DTAFMT(*DLM) 5. Use the CPYTOIMPF command to copy the DDL source from the STAFF member in the SQLSRC source physical file in the VIJAY library and add the staff.ddl stream file to the vijay directory; the command specifies the DTAFMT(*FIXED) parameter as shown here: CPYTOIMPF FROMFILE(VIJAY/SQLSRC STAFF) TOSTMF('/vijay/staff.ddl') MBROPT(*REPLACE) RCDDLM(*LF) DTAFMT(*FIXED) Figure 6-19 shows a list of the resulting staff.ddl stream file. Browse : /vijay/staffdlm.csv Record : 1 of 36 by 14 Column : 1 59 by 79 Control : ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+.... ************Beginning of data************** 10 ,"Sanders ",20 ,"Mgr ",7 ,18357.50 ,300.00 20 ,"Pernal ",20 ,"Sales",8 ,18171.25 ,1412.45 30 ,"Marenghi ",38 ,"Mgr ",5 ,17506.75 ,500.00 40 ,"O'Brien ",38 ,"Sales",6 ,18006.00 ,846.55 50 ,"Hanes ",15 ,"Mgr ",10 ,20659.80 ,, 60 ,"Quigley ",38 ,"Sales",,16808.30 ,650.25 70 ,"Rothman ",15 ,"Sales",7 ,16502.83 ,1152.00 80 ,"James ",20 ,"Clerk",,13504.60 ,128.20 90 ,"Koonitz ",42 ,"Sales",6 ,18001.75 ,1386.70 100 ,"Plotz ",42 ,"Mgr ",7 ,18352.80 ,, 110 ,"Ngan ",15 ,"Clerk",5 ,12508.20 ,206.60 120 ,"Naughton ",38 ,"Clerk",,12954.75 ,180.00 130 ,"Yamaguchi",42 ,"Clerk",6 ,10505.90 ,75.60 140 ,"Fraye ",51 ,"Mgr ",6 ,21150.00 ,, F3=Exit F10=Display Hex F12=Exit F15=Services F16=Repeat find F19=Left F20=Right (C) COPYRIGHT IBM CORP. 1980, 2000. 148 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-19 STMF for DDL source 6.3.5 Exporting the STMF The stream files staff.ddl and staffdlm.csv in the vijay directory in the iSeries server Integrated File System are exported to the external system. A TCP/IP connection exists between the iSeries server and the external database server. FTP is used for the data transfer between the two database servers. The FTP dialogue from the external system is shown here: C:\>ftp as23 1 Connected to AS23. 220-QTCP at rchasm23.rchland.ibm.com. 220 Connection will close if idle more than 5 minutes. User (AS23:(none)): vijay 2 331 Enter password. Password: 3 230 VIJAY logged on. ftp> get /vijay/staff.ddl c:\vijay\staff.ddl 4 200 PORT subcommand request successful. 150-NAMEFMT set to 1. 150 Retrieving file /vijay/staff.ddl 250 File transfer completed successfully. ftp: 294 bytes received in 0.00Seconds 294000.00Kbytes/sec. ftp> get /vijay/staffdlm.csv c:\vijay\staff.csv 5 200 PORT subcommand request successful. 150 Retrieving file /vijay/staffdlm.csv 250 File transfer completed successfully. ftp: 1987 bytes received in 0.03Seconds 66.23Kbytes/sec. ftp> quit 6 Browse : /vijay/staff.ddl Record : 1 of 11 by 14 Column : 1 59 by 79 Control : ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+.... ************Beginning of data************** CREATE TABLE VIJAY.STAFFI ( ID SMALLINT NOT NULL , NAME VARCHAR(9) CCSID 37 DEFAULT NULL , DEPT SMALLINT DEFAULT NULL , JOB CHAR(5) CCSID 37 DEFAULT NULL , "YEARS" SMALLINT DEFAULT NULL , SALARY DECIMAL(7, 2) DEFAULT NULL , COMM DECIMAL(7, 2) DEFAULT NULL ); ************End of Data******************** F3=Exit F10=Display Hex F12=Exit F15=Services F16=Repeat find F19=Left F20=Right (C) COPYRIGHT IBM CORP. 1980, 2000. Chapter 6. DB2 Import and Export utilities 149 6.4 Moving data from DB2 UDB 7.2 to DB2 UDB for iSeries This section illustrates two approaches for moving data, among many other valid options. The first approach is based exclusively on the Import and Export utilities in a very direct way. The second approach combines the Export utility with the CPYFRMIMPF CL command for better performance. 6.4.1 First approach: Using the Export and Import utilities In the first approach we found a very direct way to move data that was also very friendly to users already familiarized with DB2 UDB 7.2: 1. Before starting, define the target iSeries database in DB2 UDB V7.2. 2. Use the DB2 UDB Export utility for exporting data from DB2 UDB V7.2 to an integrated exchange file (IXF). 3. Use the DB2 UDB V7.2 Command Center or other DB2 UDF V7.2 SQL interface to connect to DB2 Universal Database for iSeries. 4. Use the Import utility for importing the IXF file into a predefined target table. The Export utility can be used to export DB2 UDB V7.2 information into an operating system file in one of the following formats:  Integrated exchange file (IXF): A data format explicitly designed for exchanging relational data. IXF files are the preferred file format for exchanging information between DB2 UDB V7.2 databases.  Delimited ASCII file (DEL): A very popular family of flat files for exchanging information, in which text fields are enclosed by quotations, fields are separated by commas, and decimals are delimited by a point. Those delimiter characters can be changed if needed. Delimited ASCII files are very popular also for exchanging information among personal productivity tools, such as spreadsheets, where they are known as CSV files.  Worksheet format file (WSF): Highly used for exchanging information between spreadsheets and other tools, including relational databases. In order to use the export utility, you can use the interactive Control Center interface or a DB2 UDB V7.2 SQL interface such as Command Center or DB2CMD. Exporting relational data using the Control Center From the Control Center, expand the object tree until you find the Tables or Views folder. Then right-click the table or view you want in the contents pane. Select Export from the pop-up menu, as shown in Figure 6-20. Notes: 1 From a command line, type FTP to the iSeries server AS23. 2 Enter your user ID and press Enter. 3 Type your password and press Enter. 4 Type the GET sub-command to copy the staff.ddl stream file in the vijay directory in the integrated file system to the staff.ddl file in the vijay directory. 5 Type the GET sub-command to copy the staffdlm.csv stream file in the vijay directory in the integrated file system to the staff.csv file in the vijay directory. 6 Type QUIT and press Enter to exit the FTP session to the iSeries server AS23. 150 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 6-20 Starting Control Center’s Export notebook This takes you to the Export notebook. Follow the instructions for providing necessary information as output file, output file format, message file, select sentence, etc. as shown in Figure 6-21. Figure 6-21 Export notebook You can choose between running the Export command immediately by clicking the OK button or reviewing the export command by clicking the Show Command, as shown in Figure 6-22. Chapter 6. DB2 Import and Export utilities 151 Figure 6-22 Export command as generated by the Control Center For general information about the Control Center, you can find detailed information in online help facility within the Control Center. Exporting relational information using the Export command You can also use the Export command from an SQL interface, such as DB2CMD, which is a very practical approach when you need to export data periodically, because it lets you create a batch file. An example of the Export command issued through the CLP is shown here: db2 export to staff.ixf of ixf select * from userid.staff Exporting relational information using Export API You can also use the provided export application programming interface (API), sqluexpr. For general information about creating applications containing DB2 administrative APIs, see DB2 UDB Application Development Guide V6, SC09-2845. Importing an IXF file into DB2 UDB for iSeries From a DB2 UDB V7.2 SQL interface, you connect to the target DB2 UDB for iSeries database using the following command: CONNECT TO RCHASM23 USER DLEMA USING MYPASS Then you use the following Import command to import data into the target table: IMPORT FROM SOURCE_IXF_FILE.IXF OF IXF INSERT INTO DLEMA.DESTTABLE Here SOURCE_IXF_FILE.IXF is the IXF file located in the workstation where the SQL interface is being used. The Import utility in DB2 UDB for iSeries V5R1 is limited to importing IXF files into existing tables. All in a batch As a convenient way to move multiple tables in a periodic way, you can create a batch file as shown in the following example: -- CONNECTION TO DB2 UDB 7.2 SOURCE DATABASE CONNECT TO NWS_DWH USER MYUSER USING MYPASWRD; -- EXPORTING DATA INTO IXF FILES Important: A destination table with compatible columns must exist previously, and it must be journaled. If it is not, you will receive an SQL error -7008. 152 Advanced Functions and Administration on DB2 Universal Database for iSeries EXPORT TO C:\TEMP\ASS.IXF OF IXF SELECT * FROM DB2ADMIN.ASS WHERE END_DT IS NULL; EXPORT TO C:\TEMP\ACT.IXF OF IXF SELECT * FROM DB2ADMIN.ACT WHERE ACT_TS > ‘2001-01-01 00:00:00.000000’; EXPORT TO C:\TEMP\USR.IXF OF IXF SELECT USR_IP_ID, NM, DEPT_OU_ID, CC_OU_ID, BLD_ID FROM DB2ADMIN.USR; -- AND MANY MORE... -- -- CONNECTION TO DB2 UDB FOR ISERIES CONNECT TO RCHASM23 USER AS400USR USING AS400PWD; -- IMPORTING IXF DATA INTO ISERIES SERVER IMPORT FROM C:\TEMP\ASS.IXF OF IXF INSERT INTO DLEMA.ASS; IMPORT FROM C:\TEMP\ACT.IXF OF IXF INSERT INTO DLEMA.ACT; IMPORT FROM C:\TEMP\USR.IXF OF IXF INSERT INTO DLEMA.USR; You run this batch file with the following DB2 UDB V7.2 command: db2cmd -w -c db2 -f c:\temp\export_import.sql -z c:\temp\export_import.log -t Here c:\temp\export_import.sql is the batch file and c:\temp\export_import.log is a text file, where the informational, warning, and error conditions will be stored for review in case of failure. 6.4.2 Second approach: Using Export and CPYFRMIMPF The second approach is more appropriate for moving large data sets because it performs better: 1. Use the DB2 UDB Export utility for exporting data from DB2 UDB V7.2 to a DEL file. 2. Move the DEL file to the iSeries server. 3. Use the CPYFRMIMPF CL command to load the DEL file into the target table. Using Export utility for exporting data to a DEL file You can use the Export utility from the Control Center as shown in “Exporting relational data using the Control Center” on page 149, but export to a delimited ASCII file. You can also use an interactive or batch command interface for executing a sentence as shown in the following example: EXPORT TO C:\TEMP\FILE.DEL OF DEL SELECT * FROM SAMPLEDB02.STAFF The resulting delimited ASCII file can now be loaded into the iSeries server using FTP and then loaded into the target table using the CPYFRMIMPF command, as explained in 6.2, “DB2 UDB for iSeries Import utility” on page 126. 6.5 Moving data from DB2 UDB for iSeries into DB2 UDB 7.2 You can move data from DB2 UDB for iSeries into DB2 UDB V7.2 using the same two approaches shown in 6.4, “Moving data from DB2 UDB 7.2 to DB2 UDB for iSeries” on page 149. 6.5.1 Using the Import and Export utilities Using any SQL interface to DB2 UDB V7.2 such as Command Center or DB2CMD, you can connect to the source iSeries server database and use the Export command to export any table to an IXF file, as shown here: CONNECT TO RCHASM23 USER AS400USR USING AS400PWD; EXPORT TO C:\TEMP\IXF_FILE.IXF OF IXF SELECT * FROM SCHEMA.TABLE Chapter 6. DB2 Import and Export utilities 153 Here, c:\temp\ixf_file.ixf is the target file on the workstation in which you execute the command. After you export the iSeries server data into an IXF file, you can import into DB2 UDB V7.2 using the Import utility. In this case, you have some extra functionality, like importing into a new table as shown in the following example: IMPORT FROM C:\TEMP\IXF_FILE OF IXF CREATE INTO DB2ADMIN.TARGETTABLE Here, c:\temp\ixf_file is the source IXF file, and DB2ADMIN.TARGETTABLE is the destination table. You can find valuable options that enable you to import appending into an existing table, import replacing an existing table, or import updating an existing table. For a detailed discussion on the Import and Export utilities in DB2 UDB V7.2, refer to Data Movement Utilities Guide and Reference, which you can find on the Web at: http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/ report?fn=db2v7dmdb2dm07.htm#HDREXPOVW 6.5.2 Using the CPYTOIMPF command and the Import utility Similarly, you can use the CPYTOIMPF command to create a delimited file (also known as a CSV file) and FTP it into a DB2 UDB V7.2 workstation as described in 6.3, “DB2 UDB for iSeries Export utility” on page 138. Then you can use the Import utility on the DB2 UDB V7.2 workstation as shown in the following example: IMPORT FROM C:\TEMP\DEF_FILE OF DEF INSERT INTO DB2ADMIN.TARGETTABLE IMPORT FROM C:\TEMP\DEF_FILE OF DEF CREATE INTO DB2ADMIN.TARGETTABLE2 IMPORT FROM C:\TEMP\DEF_FILE OF DEF INSERT_UPDATE INTO DB2ADMIN.TARGETTABLE2 154 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 155 Part 3 Database administration Operations Navigator offers a Windows-like graphical interface to configure, monitor, and manage the OS/400 environment. This part gives you insight into the wide range of DB2 Universal Database for iSeries database administration functions available through the Operations Navigator graphical interface, which comes packaged with Client Access Express for Windows V5R1. This part of the book covers the following topics:  Database functions using Operations Navigator  The use of Database Navigator  Reverse engineering and Generate SQL  Visual Explain Part 3 156 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 157 Chapter 7. Database administration This chapter discusses using the Database component of Operations Navigator to administer, view, and manipulate your databases. This chapter discusses:  Basic database operations  SQL scripts  Query attributes  SQL Performance Monitors 7 158 Advanced Functions and Administration on DB2 Universal Database for iSeries 7.1 Database overview The Database component of Operations Navigator provides a graphical interface for many DB2 Universal Database for iSeries database operations, including:  Creating and managing tables, views, indexes, SQL, and stored procedures  Creating and managing OS/400 journals (record changes to the database and other functions supporting journals)  Entering new, or modifying already created, SQL statements  Running and debugging previously created SQL statements (referred to as scripts)  Saving SQL statements for later use  Doing performance analysis of SQL statements  Capturing current SQL statements for any job running on the system The Database component of AS/400 Operations Navigator is not installed by default when choosing a Typical installation option of IBM AS/400 Client Access Express. If the Database component is not currently installed, you can run Selective Setup to install it as discussed in Managing OS/400 with Operations Navigator V5R1 Volume 1: Basic Functions, SG24-6226. With proper authorization to the database objects, the user of the database graphical interface has easy access to OS/400 server administration tools, has a clear overview of the entire database system, can perform remote database management, and receives assistance for complex tasks. For OS/400 V4R4, key enhancements to DB2 Universal Database for iSeries included an interface to the SQL-specific performance monitor and new Universal Database Object Relational Support functions, such as various types of binary large objects (LOBs), user defined data types (UDTs), user defined functions (UDFs), and DataLinks. OS/400 V4R5 delivered a mix of enhancements across a wide variety of DB2 UDB functions and interfaces including:  Distributed Relational Database Architecture (DRDA) password encryption to improve the security of Internet and intranet solutions.  The iSeries Data Loader utilities (Copy From Import File (CPYFRMIMPF) and Copy To Import File (CPYTOIMPF) CL commands) were enhanced and made easier to use in V4R5.  iSeries external stored procedure support was upgraded in V4R5 with the addition of Java as a supported language  Further Java database improvements were made to the iSeries SQLJ support. For example, the implementation was re-engineered to deliver performance similar to static, embedded SQL and extended dynamic SQL.  The iSeries SQL CLI was significantly enhanced to make it more compatible with the ODBC standard.  On the performance front, the database engine was enhanced to reduce the number of cases where SQL open data paths (ODPs) are non-reusable.  Operations Navigator was enhanced to improve the manageability of DB2 Universal Database for iSeries. The major additions include a Display Physical File Description (DSPFD) type of output for tables, views, and indexes and Visual Explain for graphical analysis of query implementations. Chapter 7. Database administration 159  Porting the database components of an application to the iSeries server was much improved in V4R5. Improvements to the SQL Stored Procedure language and the SQL Call Level Interface (CLI) top the list of portability enhancements. The SQL Stored Procedure language has been available since V4R2 and has been widely used to successfully port procedures written in proprietary languages such as Transact SQL and PL/SQL to DB2 Universal Database for iSeries.  Full autocommit support that improves the integrity transactions performed by ODBC- and JDBC-based client applications and lifts the restrictions that prevented stored procedures and triggers from making committable database changes. 7.1.1 New in V5R1 The new features in V5R1 include:  Database Navigator: A new component that gives a pictorial representation of a schema and DB objects and can generate SQL for those objects  Support for SQL Triggers creation from table properties  Generate SQL from existing DB objects (including DDS created)  RUN SQL script enhancements  The ability to print Visual Explain graphs  Database (SQL) V5R1 functions – Database Text Extenders (including Text Search Engine and XML Extenders) – DRDA 2 Phase Commit Over TCP/IP – DRDA Result Sets – RIGHT OUTER Join – Expressions in INSERT – SQL Triggers – Up to 300 triggers per table – Column triggers – Read only triggers – Longer than 80 character columns in C and C++ pre-compilers – RUNSQLSTM support in OS/400 V5R1 – Support for user-defined functions implemented in Java – Increased large object (LOB) size – now 2 GB up from 15 MB – Maximum total size for all large objects in a table row is now 3.5 GB, up from 1.5 MB  The maximum number of rows allowed in a table increased from 2.1 billion to 4.2 billion in V4R5. The maximum table size remains half of a terabyte (TB). In addition, you can reference more tables – up to 256 – on a single SQL statement. A journal receiver maximum size increased from 2 GB to 1 TB, which reduces the frequency of changing journal receivers. Similarly, the maximum number of journal sequence numbers increased from 2 billion to 10 billion to reduce the frequency of sequence-number resets. These remain unchanged at V5R1. Although OS/400 integrated DB2 Universal Database for iSeries support is one of the major strengths of iSeries servers, a complete description of this support is beyond the goal of this redbook. Good sources for details of DB2 Universal Database for iSeries capabilities are:  iSeries Information Center: http://www.iseries.ibm.com/infocenter Here you can select Database and File Systems->Database management. Under Database management, by selecting DB2 Universal Database for iSeries books online, you can find a list of publications that contain even more information. Most of these publications are listed here. 160 Advanced Functions and Administration on DB2 Universal Database for iSeries  Database Programming, SC41-5701 This book describes database capabilities that are primarily outside of SQL terminology. This includes physical files (correspond to SQL tables), logical files (correspond to SQL views), fields (correspond to SQL columns), records (correspond to SQL rows), file management, and file security.  SQL Programming Guide, SC41-5611  SQL Reference, SC41-5612  DB2 UDB for AS/400 Database Performance and Query Optimization: http://submit.boulder.ibm.com/pubs/html/as400/bld/v5r1/ic2924/index.htm  Distributed Data Management, SC41-5307  Cross-Platform DB2 Stored Procedures: Building and Debugging, SG24-5485  DB2/400: Mastering Data Warehousing Functions, SG24-5184  DB2 UDB for AS/400 Object Relational Support, SG24-5409  DB2 Universal Database for iSeries home page: http://www.iseries.ibm.com/db2/db2main.htm Use this link to learn about the iSeries database, recent announcements, support information, and related products. This page features many useful links to database related issues and products (like Business Intelligence) and gives you access to a wealth of articles, white papers, coding examples, tips, and techniques.  Self-study lab exercise with sample OS/400 database, installation instructions, and lab instructions that can be downloaded from PartnerWorld for Developers iSeries Web site at: http://www.iseries.ibm.com/developer Select Education->Internet Based Offerings->DB2 UDB->Piloting DB2 UDB for iSeries with Operations Navigator in V5R1. Under OS/400, you can use SQL interfaces to access a database file or an SQL table since these terms refer to the same object, classified within OS/400 as a *FILE object type. You can use SQL interfaces to access the file regardless of whether the object was created with the OS/400 Create Physical File (CRTPF) command or the CREATE TABLE SQL statement. OS/400 also supports access to the physical file or table through a logical file (Create Logical File (CRTLF) command) or an SQL view (SQL CREATE VIEW). Table 7-1 shows the corresponding OS/400 term and SQL term for physical files or tables, records or rows, fields or columns, logical files or views, aliases, and indexes. Table 7-1 OS/400 term and SQL term cross reference OS/400 Create statement or term SQL Create statement OS/400 object type OS/400 object attribute SQL term CRTPF CREATE TABLE *FILE Physical File (PF) Table CRTLF CREATE VIEW *FILE Logical File (LF) View CRTDDMF CREATE ALIAS *FILE DDM File (DDMF) Alias CRTLF CREATE INDEX *FILE Logical File (LF) Index Field Column Record Row Chapter 7. Database administration 161 Note: A DDM File represents a Distributed Data Management File. This is the original OS/400 object on the local iSeries server used to provide a link to a file on a remote system. In the context of Table 7-1, an alias created by SQL has no remote system specification. To determine if the DDMF/alias has any remote system specification, you can use the Work with DDM File (WRKDDMF) command. Throughout the remainder of this chapter, the SQL terms table, row, and column are used more frequently than their corresponding OS/400 terms file, record, and field. In some cases, both corresponding terms, such as field or column, are used. 7.2 DB2 Universal Database for iSeries through Operations Navigator overview In the Operations Navigator window, click the + (plus) sign next to the Database function for the system to which you are attached to see the three major function areas as shown in the left pane and right pane in Figure 7-1. Figure 7-1 Database function list view There are several other ways to make the same three database function areas also appear in the right pane as shown. This chapter discusses some of these ways. However, Operations Navigator database capabilities are actually grouped under four functional branches:  Database  Libraries  Database Navigator  SQL Performance Monitors Note: OS/400 supports an object type of table (*TBL). This object type is for data translation. 162 Advanced Functions and Administration on DB2 Universal Database for iSeries The following sections summarize the capabilities under each of these four major database function groupings. Examples and tips on usage are given for selected sub-functions under each major function group to highlight Operations Navigator interfaces into the wide range of DB2 Universal Database for iSeries capabilities. These sections do not explain every action on every pull-down menu, but instead emphasize the actions that are most significant. Such actions as Explore, Open, Shortcuts, and Print options are very similar to these same actions described for Operations Navigator interface in Managing OS/400 with Operations Navigator V5R1 Volume 1: Basic Functions, SG24-6226. For some other database-specific actions or options, you must refer to Operations Navigator online help information. For the database functions described in the following sections, you need the appropriate authority to perform the functions. You can use the SQL GRANT and REVOKE statements to define authority to a table, view, procedure, user-defined functions, and user-defined types. For tables and views, these statements may also specify processing authority, such as SELECT (read), INSERT (write), DELETE, and UPDATE. SQL GRANT and REVOKE can also specify column-level authorities. The Operations Navigator Database interface supports table, view, index, procedure, column, etc. database-related object levels of authority through the Permissions action by right-clicking the database object name within a library. You can specify permissions for all OS/400 objects, including database-related objects through Operations Navigator File Systems interface. An alternative to column-level authority is to use an SQL CREATE VIEW to a table or a Create Logical File (CRTLF) command based on a file and specify only certain columns or fields. Then you specify authorities or permissions to the logical file or view. SQL CREATE VIEW or CRTLF can also specify compare values for columns or fields that limit the rows or records that can be seen by those authorized to the view or logical file. For additional details on the Object Relational Support items (functions and types), refer to DB2 UDB for AS/400 Object Relational Support, SG24-5409. For authority implications of using *SYS or *SQL naming convention when creating new DB objects with Operations Navigator, refer to document number 9510127 in the Support Line Knowledge Base at: http://as400service.ibm.com/supporthome.nsf/document/10000051 Chapter 7. Database administration 163 7.2.1 Database functions overview In the Operations Navigator window, right-click Database to access the pop-up menu shown in Figure 7-2. Figure 7-2 Database pop-up menu functions The possible actions are:  Explore: The right pane displays the three other major database function areas: – Libraries – Database Navigator – SQL Performance Monitors Important iSeries software requirements: Base OS/400 provides SQL “run time support”, not “program development for SQL support”. Run time support includes the following uses of SQL with no SQL software installation required:  All Open Database Connectivity (ODBC) support, which includes Operations Navigator functions and Run SQL Scripts jobs and client workstation jobs using Client Access ODBC support, such as a Visual Basic program  All Java Database Connectivity (JDBC) support, which includes client workstation Java applets and local iSeries Java servlets accessing JDBC  DB2 Universal Database for iSeries support from an already compiled (created) local iSeries program using embedded SQL in the RPG, COBOL, or C program  DB2 Universal Database for iSeries support from an already compiled (created) local iSeries program using the SQL Call Level Interface (CLI) in RPG, COBOL, C, or Java  Use of the RUNSQLSTM command To use DB2 Query Manager support or to compile (create) local iSeries programs using embedded SQL, such as iSeries RPG, COBOL, and C programs, you must have licensed program DB2 Query Manager and SQL Development Kit, 5722-ST1 (5769-ST1 for releases prior to V5R1M0). This is for program development support. 164 Advanced Functions and Administration on DB2 Universal Database for iSeries  Open: This is the same as choosing Explore, except that the contents of the selected file system are displayed in a separate window.  Change Query Attributes: This enables you to specify attributes for database queries and database file keyed access path (index) builds, rebuilds, and maintenance that are run in a job. Query attributes may be specified through the OS/400 Change Query Attributes (CHGQRYA) command. In Operations Navigator, Change Query Attributes provides a graphical interface to apply a superset (more than CHGQRYA provides) of query attributes as stored in a file. These attributes can be applied to one or more active jobs that can be selected from a list. OS/400 supplies a read-only version of the query attributes file–QAQQINI in library QSYS. Run SQL Scripts within Operations Navigator defaults to using the QAQQINI file in library QUSRSYS. You must copy the base QAQQINI file in QSYS into library QUSRSYS if you want Operations Navigator to use its values system wide. Or use the following CL command in the Run SQL Scripts window to default your job to another library where you previously copied the QAQQINI file: CL: CHGQRYA QRYOPTLIB (yourlib); If there is no QAQQINI file in QUSRSYS, internal defaults are used. You can use the Change Query Attribute graphical interface to easily make a copy of the default QAQQINI file in a library of your choice and to change the default values to what is most suitable for your job. We document this interface in 7.4, “Change Query Attributes” on page 217. Any changes to the attribute values are typically determined by an experienced query programmer. You can find the best explanation of how to use these attributes in DB2 UDB for iSeries Database Performance and Query Optimization, which you can find on the Web at: http://submit.boulder.ibm.com/pubs/html/as400/bld/v5r1/ic2924/index.htm In addition to CHGQRYA, you can specify a subset of the query attributes available under Operations Navigator through the OS/400 system values QQRYTIMLMT (time limit) and QQRYDEGREE (degree).  Current SQL for a Job: With this feature, you can select any active job on the iSeries server and display it through the automatically linked Run SQL Scripts option, the SQL statement, if any, currently being executed in the job. In addition to displaying the SQL statement, you can edit or rerun it; you can also display the job log for the selected job or end the job. This can also be used for database usage and performance analysis, linking into the Visual Explain tool documented in Chapter 10, “Visual Explain” on page 301.  Run SQL Scripts: This enables you to enter, edit, run, save, and debug SQL statements across tables within all libraries (includes SQL collections). You can run all supported SQL statements from this action. OS/400 provides a set of base SQL statements for all supported functions that you can select and insert into your SQL statements. You can enter a completely new SQL statement or modify an already available statement for your own unique queries. You can also run CL commands. You can save your own newly created or modified base statements for later use. You must have appropriate file or table and field or column authorities (permissions) to perform the functions at run time. Section 7.3, “Run SQL Scripts” on page 197, shows several examples of building and running SQL script. Restriction: You must have job control (*JOBCTL) special authority to use this function. Chapter 7. Database administration 165  Properties: This enables you to specify to refresh the current display every time a list is displayed or after a time interval is specified in minutes. There are several actions or functions available from the menu bar options for the Database, Libraries, Database Navigator, and SQL Performance Monitors function groupings. This chapter discusses a subset of all of these actions or functions. You must review the online help text for a description of the entire set of actions or functions. 7.2.2 Database library functions overview You can create, delete, and assign permissions (authority) to an OS/400 library under this group of functions. You can also display the list objects within a library and create, change, delete, or assign authorities (permissions) to an SQL table, view, alias, index or OS/400 journal, or OS/400 journal receiver listed within the library. Figure 7-3 shows an example display after expanding the Libraries function and then right-clicking Libraries to see the context menu. Figure 7-3 Database library actions In this example, you see the library names ITSCID63, PORTERL, QGPL, and SQLLIB. These libraries were currently specified in the Initial Library List (INLLIBL) parameter of the OS/400 job description object used by the Operations Navigator session to the iSeries server. The job description is associated with the OS/400 user profile you used to sign on under Operations Navigator when connecting to your iSeries server. By default, only the libraries in the user portion of your iSeries library list are included under the Database component, plus any other library you asked to add here in previous Operations Navigator working sessions. You can add more libraries. Simply click Select Libraries to Display in the pop-up window by either entering a library name or selecting from a list of library names on the system. Then, click the Add button as shown in Figure 7-4. 166 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-4 Database: Adding a library to your library list This change is retained across subsequent new Operations Navigator working sessions. This is done by maintaining a table on the host iSeries, QAUGDBLL in QUSRSYS, which lists all users for the Database portion of Operations Navigator and all the libraries that were chosen to work with using this interface. If you want to remove a library from this list, repeat the previous steps, but select Remove. 7.2.3 Creating an OS/400 library or collection There are several Operations Navigator higher level branches from which you can create an OS/400 library. This section discusses creating a library by selecting Database->Libraries and going to the New Library function as shown in Figure 7-5. Note: Any library added here may be used when you perform actions or functions under this Libraries function of Database. Any library added here is not automatically used by the actions or functions under other database sub-components such as Run SQL Scripts. Nor is it added to the user’s library list on the iSeries server. In other words, while the original list of libraries shown in Operations Navigator is built on the user’s library list, a change in the library list for this interface is not going to affect the user’s library list on the iSeries server. Chapter 7. Database administration 167 . Figure 7-5 Database: Creating a new library A library can contain any supported iSeries object type. However, under the Operations Navigator’s Database interface, you only work with objects related to database support. Under the New Library function, you can create a new library, or you can create an SQL collection. In OS/400, an SQL collection automatically builds a library, and within that library, it creates:  A journal  A journal receiver  A catalog  Optionally, a data dictionary A data dictionary is used for migrated System/36 application environments. When you select the Add to list of libraries displayed check box (circled in Figure 7-5), the newly created library is added to the user’s list of libraries in Operations Navigator working session. This has no affect on the iSeries library list. The library can be placed into the system auxiliary storage pool, ASP1 (default) or a user-defined ASP2 (up to 32). An ASP is a defined set of disk devices that contain only objects created into a library within that ASP. As shipped from IBM, ASP1 contains all disk devices. A user-defined ASP is typically used for a specific performance requirement to reduce disk arm movement or for a specific backup and recovery procedure. For more information about ASP support, journaling support, and overall backup and recovery, please refer to:  iSeries Information Center at: http://www.iseries.ibm.com/infocenter When you reach this site, select Backup, Recovery, and Availability.  Backup and Recovery, SC41-5304 All database-related objects, such as tables, views, journals, and other system objects, like programs, message queues, output queues, and so on, can be created, moved, or restored into any iSeries library. All iSeries tables or files can be created or moved into an SQL collection if the SQL collection does not contain a data dictionary. 168 Advanced Functions and Administration on DB2 Universal Database for iSeries An SQL collection can also contain catalog views that have descriptions and information for all tables, views, indexes, files, packages, and constraints created in the library. All tables created in the SQL collection automatically have journaling performed on them. When referring to an SQL collection in iSeries documentation and screen panels, the collection name and the library name refer to the same object. 7.2.4 Library-based functions Refer to the display shown in Figure 7-6 to see an overview of the functions that are available when you select a specific library. These database functions include:  Assigning authorities (Permissions) to the library and objects within the library  Totaling the number of files and folders (directories) in the library and the storage size of all objects within the library (Properties)  Creating new tables (Table) in the library  Creating new views (View) and aliases (Alias) in the library A view is an object that permits access to a subset of all rows in a table and columns within a row. An alias is an object that allows SQL applications to reference a table or view by another name. In addition, aliases provide an easy way for SQL applications to access data in multiple-member DB2 UDB for iSeries files. In SQL standards, a table represents only one set of data (rows). OS/400 file support includes multiple members, which are sets of records or rows that contain the same field or column definitions, but different sets of data. For example, the MONTHS file can contain a set of rows for January data (member name JAN) and another set of rows for February data (member name FEB). At run time, a command parameter for Member Name (MBR) could specify JAN one time and FEB another time. Opening an SQL alias provides an equivalent function.  Creating new journals to be used with the tables, views, or aliases  Creating new SQL procedures  Creating new user defined functions (Function)  Creating new user defined types (Type) Chapter 7. Database administration 169 Figure 7-6 Database Library functions To bring up the Library functions, right-click a specific library (PFREXP in our example). In this example, we double-clicked PFREXP or selected the Open option in the pull-down menu (1) to see the database-related objects in this library in the right pane. By selecting New in the Library pull-down menu, the next level of objects to create (Table, View, and so forth) are shown in the menu (2). Before we explain more about creating these objects, we discuss the existing objects shown for library PFREXP. We created an alias CSTFILTST (3), which accesses the CSTFIL file, with the member name CST. CSTFIL is shown as a table (7), but was originally created with the OS/400 Create Physical File (CRTPF) command. SQL index object ITMFILIX is at 4. This object was created, based on the ITMFIL table. Section 7.2.5, “Object-based functions” on page 181, explains how to create an index. OS/400 files created through the Create Physical File (CRTPF) and Create Logical File (CRLF) OS/400 commands have access paths (indexes) if key fields are specified, but they are not visible as a separate object of type index. The BUPJRN journal is at 5. Each journal can have one or a pair (dual) of attached journal receivers (where actions on the table or data within the table are actually recorded). BUPJRA and BUPJRB, as the original dual journal receivers, are shown at 6. In our example, BUPJRA and BUPJRB already reached their maximum space for journal entry information. Through journal configuration parameters, a second set of dual journal receivers, BUPJRA1000 and BUPJRB1000, have been created by OS/400, with the system generated 1000 suffix. They are now the attached (receiving entries) journal receivers. A series of tables including CSTFIL, CSTMSTP, CSTMSTRP, and ITMFIL are shown at 7. The two views CSTMST and CSTMSTR are shown at 8. 3 3 4 5 6 7 8 1 2 170 Advanced Functions and Administration on DB2 Universal Database for iSeries Physical file and SQL TABLE differences The OS/400 Create Physical File (CRTPF) command and the SQL CREATE TABLE statement (implicitly used by the Operations Navigator New->Table dialogue) create an OS/400 object type of *FILE. There are CRTPF command OS/400 parameters that have no corresponding CREATE TABLE parameter. These parameters are part of every *FILE object within OS/400 and affect the operating environment when accessing the file or table. Therefore, when you use an SQL-based interface to create a table, OS/400 uses default values for these CRTPF-only parameters. These CRTPF-only parameters include:  Maximum members (MAXMBR parameter): OS/400 physical files can have multiple members (same record layout and field attributes, different sets of records or rows). All SQL tables default to a value of 1. This is also the default for CRTPF, but the user can specify a number or *NOMAX (no limit on the number of members).  Member size (SIZE parameter): OS/400 uses the number of records or rows value to implicitly allocate the initial amount of storage for the file or table. Other values in this parameter optionally specify how to allocate additional storage when the initial storage is exceeded. CRTPF defaults to 10000 records with up to an additional allocation of up 3000 records in 1000 record increments. A system operator message communicates each additional allocation. CREATE TABLE defaults to *NOMAX.  Reuse of deleted record or row storage (REUSEDLT and DLTPCT parameters): When a row or record is deleted, the storage previously occupied by the record or row remains as part of the total file or table storage allocation. DLTPCT is the percent of deleted records or rows compared to all active records or rows in the file or table. At file or table close time, if the number of deleted records or rows exceeds this percentage, a message is issued to the OS/400 History Log (viewed with the Display Log (DSPLOG) command). REUSEDLT specifies to OS/400 whether to insert a new record or row into a new physical storage space (REUSEDLT(*NO)) or into the storage of a previously deleted record or row (REUSEDLT(*YES). CRTPF defaults to DLTPCT(*NONE) and REUSEDLT(*NO). CREATE TABLE defaults to DLTPCT(*NONE) and REUSDLT(*YES). You can specify, change, and view the values for these and additional OS/400 parameters for a file or table by using the following OS/400 commands:  Create Physical File (CRTPF) command  Change Physical File (CHGPF) command  Display File Description (DSPFD) command Note: Regardless of the DLTPCT and REUSDLT parameter values for a file or table, you may have an application environment that you know or suspect may have files or tables with a large number of deleted records (for example, disk storage is increasing with no known increase in the number of new records). In this case, you should consider running the OS/400 Reorganize Physical File Member (RGZPFM) command or its equivalent Operations Navigator Database Reorganize function (see “Managing tables and views” on page 182) on a specific file or table. You can use the DLTPCT parameter message to assist you. Alternatively, you can periodically use the Display File Description (DSPFD) command with TYPE parameter specifying *MBRLIST to see both the number of records or rows in the file or table and the number of deleted records in each member of the file or table. Chapter 7. Database administration 171 For more information on these and other file attributes, refer to Database Programming, SC41-5701, and CL Reference, SC41-5722. You can view the above mentioned settings and other file or table parameters, such as database constraints and triggers, in Operations Navigator by right-clicking the table and selecting the menu options Table Description and Properties. Create Table example To create a new table (or file) on the iSeries server with the traditional interface, you can use DDS or the CREATE TABLE SQL statement. In both cases, you need the appropriate skill, whether it is programming with DDS or SQL knowledge. Follow these steps in Operations Navigator to create a new table: 1. Click Database->Libraries. Then, right-click the library PORTERL in which you want to create the new object. You are presented with a list of choices, as shown in Figure 7-7. Figure 7-7 Create Table example (Part 1 of 3) 2. Select New->Table to access the panel where you specify the table name and description for the new table (see Figure 7-8). Figure 7-8 Create Table example (Part 2 of 3) 3. Click OK and you see the panel where you can specify the columns for the new table (see Figure 7-9). Click the Insert button (1) to insert a new column, and specify the column 172 Advanced Functions and Administration on DB2 Universal Database for iSeries name, type, length, and an optional description. You can also specify a short name (up to 10 characters), column heading (up to three lines of 20 characters each), must contain a value (not null), default value, CCSID and a length to allocate (for VARCHAR and VARGRAPHIC datatypes). Figure 7-9 Create Table example (Part 3 of 3) 4. Use the pull-down list in the Type column (2) to choose the data type for the column. The content of this list depends on the version and release of OS/400 installed on your iSeries server. Since V4R4 DB2 UDB for iSeries added support for BLOB, CLOB, DBCLOB, and datalink data types, these values only appear in the list if your iSeries server is running V4R4 or a later release. 5. When finished with inserting columns, click OK to create the table or select any other item you may need to work on (constraints, indexes, triggers, etc.). Create SQL View example A view is typically used to represent a subset of the columns in a table and, if specified, a subset of the rows in the table. For example, you have a customer table file that has several columns describing the customer, including customer number (key field), customer description, customer address, and customer telephone number. You want to show someone the customer number, customer name, and customer telephone number, but not their address. You also know that customers with a customer number greater than 500 do not want their telephone numbers known. The following steps show you how to create a view (CUST_DIMVU) over the CUST_DIM table: 1. Right-click the library (PORTERL), and select New->View to access the new view panel shown in Figure 7-10. 2 1 2 Chapter 7. Database administration 173 Figure 7-10 Create View example (Part 1 of 6) 2. Enter the name, CUST_DIMVU, for the new view and the description. The Check option specifies whether some type of data validity checking will be performed on an update or insert operation. You must view the help information for additional details. We selected None (default) in our example. 3. Click OK to see the panel with blank input areas, as shown in Figure 7-11. Click the Select Tables button (1) to bring up the current library list for your current Operations Navigator working session. Figure 7-11 Create View example (Part 2 of 6) 4. Previously we selected library PORTERL to create the view. However, the view can be created to use tables in various libraries. To keep this example simple, we select the tables from library PORTERL. 5. To see the tables within a library, either click the + (plus) sign next to the library name or position the mouse on the library and double-click. Select the table, and click the OK button, which places the column names in the upper pane in the area (2 in Figure 7-11). 6. As shown in Figure 7-11, select your table from the library. We selected the CUST_DIM table from the PORTERL library, and clicked OK. We can select another table from the 2 1 174 Advanced Functions and Administration on DB2 Universal Database for iSeries library. We selected the PART_DIM table from the PORTERL library and then clicked the Add button. This places the columns of both the CUST_DIM (1) and PART_DIM (2) tables into the upper pane (see Figure 7-12). We chose two tables to show an example of how Operations Navigator assists you in building SQL statements that could become quite complex. As shown in Figure 7-12, we selected the CUSTKEY and CUSTOMER columns from CUST_DIM and dragged and dropped them into the lower pane. You can see the arrow to the left of the CUSTOMER column (3), which indicates that the next column selection will be inserted after this statement. Figure 7-12 Create View example (Part 3 of 6) You can reposition this arrow for the next insert of a new column by clicking any existing column in the lower pane. In this example, we selected the PHONE column, but have not yet dragged it to the lower pane. In this example, we create a view using only columns from the CUST_DIM table. If you select multiple tables to appear in the upper pane, Operations Navigator expects a JOIN clause in the VIEW statement and issues a message indicating this later if you continue showing more than one table in the upper pane. Since we are only going to use the CUST_DIM table, we select the PART_DIM table in the upper pane and press the Delete key to delete this table from the upper pane. The PART_DIM column names no longer appear in the following displays. 7. As shown in Figure 7-13, we completed a column selection for the CUST_DIMVU view and clicked the Select Rows button. The Select Rows button enables a WHERE clause. The Select Rows window shows the table columns, operators, and functions available in the upper pane. Once a column operator or function is selected (by double-clicking), it is inserted into the Clause pane. You may also manually enter your own text into the Clause area as we did by entering the value 500. Note: If you click the Summary Rows button, the HAVING clause is enabled. 1 2 3 Chapter 7. Database administration 175 Figure 7-13 Create View example (Part 4 of 6) As soon as you have at least one SQL column in the Table pane (1) or text in the Clause pane (2), you can use the Show SQL (3) button to view the current SQL statement. We clicked the Show SQL button to generate the Show Generated SQL window shown in Figure 7-14. Figure 7-14 Create View example (Part 5 of 6) 1 2 3 176 Advanced Functions and Administration on DB2 Universal Database for iSeries 8. In this window, click the Check Syntax button to view the generated SQL and have syntax checking performed. You cannot edit any text on this window. 9. If you are satisfied with the current SQL statement, you can click the OK button twice on successive windows, and the View is created, assuming no errors are detected. Depending on your Operations Navigator refresh setting, a new view appears in an updated display showing the contents of the library, such as the example shown in Figure 7-7 on page 171. 10.To edit the generated SQL, click the Edit SQL button (1), which opens the Edit Generated SQL window shown in Figure 7-15. Figure 7-15 Create View example (Part 6 of 6) 11.In Figure 7-15, the SQL statement area now has a white background. Here, you can enter any characters and also have your syntax checked by using the Check Syntax button (2). 12.After we validated the SQL syntax, we clicked the Submit button (3 in Figure 7-15). Then, the view was created successfully as indicated by the Information window shown. Edit SQL tip: If you make changes through this Edit SQL process, the changes are not saved. You may make changes and successfully create the view as we have done by using the Submit button. However, the changes are not saved in this dialogue because you must exit the Edit SQL function by clicking the Cancel button or using the Windows cancel (X button). SQL changes are not saved because they could be extensive. You can even change the name of the view and the library that is already specified. 1 2 3 Chapter 7. Database administration 177 Create journal example A journal is an object used to record actions on database tables or files and other objects or software that support journaling, such as system auditing. For DB2 UDB for iSeries, journals are typically used to recover from application errors or unscheduled iSeries server outages. Commitment control, as discussed in 7.3.1, “ODBC and JDBC connection” on page 202, requires journaling to implement its COMMIT and ROLLBACK functions. OS/400 uses the journal object as a front-end interface to an attached object, which is a journal receiver that actually contains the journaled data. Each set of related journal data is recorded as a journal entry. Examples of non-DB2 UDB for iSeries software functions that optionally use journals and journal receivers include:  OS/400 security: Action auditing  OS/400 job accounting  TCP/IP-based functions, including IP filters, IP network address translation (NAT), and virtual private network (VPN)  OS/400 software license management tracking Applications can also use OS/400 commands and System Application Program Interfaces (APIs) to write to and read journal entries. OS/400 supports defining and using remote journals as well. A journal associated with a local journal can be defined to reside on a remote iSeries server. The remote journal can be defined so that OS/400 automatically sends journal entries made on the local iSeries server to the corresponding remote iSeries server journal. The primary intent of remote journal support is to quickly and easily replicate data onto a backup iSeries server in a high availability environment where the backup iSeries server can switch over to become the production iSeries server, if an unscheduled outage occurs on the primary iSeries server. To create and set up remote journaling through Operations Navigator, you must first create the local journal and journal receiver. Then use the Properties support for the journal to access actions that set up a remote journal. “Managing journals and journal receivers” on page 192 shows an example of journal and journal receiver properties. The following example shows how to create a local journal (CUST_DIMJ) in the PORTERL library and create its associated journal receiver in the JRNLIB library: 1. Right-click the POTERL library. Select New->Journal to access the New Journal panel (1 in Figure 7-16). 178 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-16 Creating the Journal and Journal Receiver 2. In the New Journal panel, enter the journal name, library, and description. Name the library to hold the journal receiver. You can select a library from a list of the current Operations Navigator session’s library list, except for the library named to contain the journal. In our example, the PORTERL library would not appear in the list. Although you can place a journal receiver in any library you want, including PORTERL in our example, the OS/400 recommendation is to place the journal receiver in a library separate from the library that contains the journal itself. Another recommendation for OS/400 journaling support is to place the library used for the journal receivers in its own user-defined ASP. In our example, we specify library JRNLIB to emphasize a different library for the receiver. JRNLIB must already exist. 3. Click the OK button in the New Journal panel (1). The journal is created, along with an attached journal receiver with a default name and default attributes. If you click the Advanced button, you see the Advanced Journal Attributes panel (2 in Figure 7-16). You see the default attributes that were used in our example to create the CUST_DIMJ journal. If you click the New Receiver button, you see the New Journal Receiver pane (3 in Figure 7-16), which shows the default new journal receiver attributes. Once the journal is created, right-click it and select Properties from the drop-down menu. Then the Properties window appears as shown on the right-hand side in Figure 7-17. On this window, you can start journaling for a table or a group of tables. To do this, click the Tables button. 1 3 2 Chapter 7. Database administration 179 Figure 7-17 Selecting the tables to journal (Part 1 of 2) When you click the Tables button, the Start/End Journaling panel (Figure 7-18) appears. On this display, select the CUST_DIM table and click the Add button to the left of the Tables to journal pane to add it to the list of tables to be journaled in the CUST_DIMJ journal. Click OK to start journaling the CUST_DIM table. 180 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-18 Selecting the tables to journal (Part 2 of 2) The following summary describes the key journal and journal receiver attributes. For a full discussion on these journaling attributes, refer to Backup and Recovery, SC41-5304. Advanced journal attributes Listed here are the advanced journal attributes. Refer to the Advanced Journal Attributes window (2 in Figure 7-16).  Journal message queue: OS/400 issues specific messages for specific changes to the journaling environment. The typical reason for a journaling message is when a journal receiver is reaching its threshold of maximum entries, a message is issued indicating that the current receiver should be detached and a new, fresh journal receiver should be attached. The default message queue is “System Operator”, which is actually message queue QSYSOPR. In some environments, you may choose to manage your own journaling support, or you may have an application that manages the journaling through software. In those cases, you may want to use a message queue other than QSYSOPR.  Receiver managed by – System: By clicking System, you tell OS/400 to automatically detach the current journal receiver and attach a new one when the journal receiver storage space threshold has been reached or when the attached journal receiver’s sequence number has reached a value of 1 TB. Each time the system attaches a new journal receiver to the journal, the journal receiver sequence number is incremented by one. In addition, the system resets the receiver sequence number during IPL, provided the receiver is not required for commitment control recovery. See Commit mode under 7.3.1, “ODBC and JDBC connection” on page 202, for information on commitment control. Under system managed receivers, you can also specify that OS/400 delete receivers when they are no longer needed. If you do not choose this option, the detached receivers remain on the system until you delete them.  Receiver managed by – User: By clicking User, you assume the responsibility for changing journal receivers and determining when to delete receivers you no longer need.  Minimize fixed portion of entries: By clicking this option, you remove job, program, and user profile information from each journal receiver entry. In a busy journaling environment, Chapter 7. Database administration 181 this can significantly reduce storage space required, but restricts selectivity by other OS/400 journal entry support.  Remove internal entries: Depending on what is being journaled, OS/400 sometimes puts its own entries into a journal receiver. By selecting this option, OS/400 deletes these entries from the journal receiver when the system determines they are no longer needed. One good example of these internal entries is those made to support System Managed Access Path (table index) Protection (SMAPP) support. SMAPP journals changes to access paths (that is, key columns or fields) independent of whether you use journaling of database tables or files. SMAPP is intended to minimize access path recovery following an abnormal system termination. Journaling access path changes helps SMAPP do this. To enable SMAPP, you use the OS/400 Edit Recovery for Access Path (EDTRCYAP) command as explained in Backup and Recovery, SC41-5304. New journal receiver attributes Listed here are the new journal receiver attributes. Refer to the New Journal Receiver window (3 in Figure 7-16 on page 178).  Journal name and description: Enter here the journal receiver name and journal receiver descriptive text. As shown, the journal name and description are the default values generated by Operations Navigator. These values are used if you never select the New Receiver button in the Advanced Journal Attributes pane.  Library: Enter the journal receiver library. The default value shown (JRNLIB) was specified on the initial New Journal panel (1 in Figure 7-16 on page 178).  Storage space threshold: Enter the maximum storage in megabytes that the journal receiver can take. You see the default value of 500 MB. The value 500 MB is specified as 500000 KB on the corresponding OS/400 Create Journal Receiver (CRTJRNRCV) command Threshold parameter. The number of journal receiver entries this space can contain depends on the amount of data contained in each entry. When this threshold is reached, a message is sent to the message queue specified in the window pane (2 in Figure 7-16 on page 178). See the online help information for additional details. In addition to the powerful Operations Navigator interface for creating and managing journals and journal receivers discussed in this section and in 7.2.5, “Object-based functions” on page 181, there are several OS/400 journal creation and management commands. To view these commands and access the related online 5250 display-based help information, enter the following command on a 5250 command line: GO CMDJRN 7.2.5 Object-based functions When you right-click a specific database-related object, a pull-down menu appears with functions that are unique for that object type. At this specific object-level interface, you have some additional create functions and a wide range of management functions. Object-based functions for a database include:  Managing a table and view  Adding and managing constraints and triggers for a table  Assigning and changing authorities and permissions to these objects  Creating and managing an index for a table  Managing a journal  Adding and managing an associated journal receiver or a remote journal 182 Advanced Functions and Administration on DB2 Universal Database for iSeries Managing tables and views Right-clicking a table brings up a menu similar to the example shown in Figure 7-19. Figure 7-19 Managing table actions For the CUST_DIM table, these are the actions:  Open: This displays, in the right pane, the first “n” rows of the table. The number of rows displayed and the number of columns displayed for each row depend on the window size, which can be adjusted to be shorter or longer (less or more rows) or narrower or wider (less columns or more columns). With the right permissions, you can update columns, delete rows, and insert new rows. OS/400 issues an error message if you try to make invalid changes to a table. See “Open table example” on page 183.  Quick View: This displays the table data as Open does, but is a read-only view. No changes can be made to the data.  Table Description: Using this item, you can gather similar information as you would using the DSPFD command on the iSeries server. However, in Operations Navigator, you are also allowed to change some attributes such as Reuse of Deleted Records and Share Open Data Path. See “Table Description example” on page 184 for details.  Locked Rows: When the table is in use, this displays whether records are locked, their relative number, which job (fully qualified job name) is actually locking them, and whether the lock type is Read or Update. From this panel, it is also possible to access the locking job’s job log, check what SQL statement is used, and copy it to a Run SQL Scripts instance to work with it. The interface also allows you to end the locking job. “Working on locked rows” on page 196 explains how to use it.  Create Alias: An alias is an object that allows SQL applications to reference a table or view by another name. In addition, aliases provide an easy way for SQL applications to access data in multiple-member iSeries physical files.  Reorganize: This enables you to reorganize the rows within the table according to a specified table key or a named index, or by compressing storage currently occupied by deleted rows. Chapter 7. Database administration 183 If your application frequently inserts new rows and then deletes them, such as in a work file, you should consider using the compression of deleted rows function.  Journaling: This option displays information about any journal that is currently or last associated with a table. If the status shows “Never journaled”, you can start journaling the table by specifying the name of an existing journal in an existing library, selecting the Journal images before change option (to journal both before and after images), and clicking Start.  Generate SQL: Create SQL source statement for the table. See Chapter 10, “Visual Explain” on page 301.  Permissions: This enables you to view and change user profile and public authority or permissions to the table and its columns. See the security chapter in Managing OS/400 with Operations Navigator V5R1 Volume 1: Basic Functions, SG24-6226, for a general discussion on Operations Navigator Permissions support.  Cut: This enables you to select a database object and drag and drop it to a different library. When the drop is completed, the database object is deleted (cut) from the original library.  Copy: This enables you to select a database object and drag and drop it to a different library or in the same library. When the drop is completed, the database object exists in both the source and the target libraries.  Delete: This enables you to select a database object and permanently delete it after you confirm the delete of the object.  Rename: This enables you to select a database object and rename it.  Properties: This enables you to select a database object and display its properties. Different property values are displayed depending on the object type. Also, depending on the object type, you may be able to add, change, or remove property values. For example, when you click Properties for an SQL-created view, you can see a read-only view of the SQL used to create the view. If you click Properties for a view created by Create Logical File (CRTLF) command, you see only a message panel that states there is no SQL statement available. Open table example Figure 7-20 shows some example windows when performing an insert, delete, or update to a table through Operations Navigator. This is the equivalent of using the Update Data (UPDDTA) command to make changes to the records in a physical file. Note: Although both the OS/400 Create Physical File (CRTPF) command and SQL CREATE TABLE create an OS/400 object of type *FILE, there are CRTPF command parameters that have no corresponding SQL CREATE TABLE parameter. Therefore, creating a table either via CREATE TABLE or by using the Operations Navigator New->Table interface requires OS/400 to use default values for these physical file parameters. One such parameter is the Reuse deleted record storage (REUSEDLT) parameter. See “Physical file and SQL TABLE differences” on page 170 for notes on creating a new table. New starting in V5R1 184 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-20 Open table example In the Insert or Delete window (1), you can insert a completely new row or delete an existing row, such as row 7 (customer number 7) in this example. For insert, you must enter the data according to each column’s valid data format or you receive a warning message. If you attempt to delete a row or update a column in a row (update window (2)), you see a warning message window similar to the one that is shown (3). This message cautions about recovering the original data if the table is not being journaled. Table Description example Right-click a table and select Table Description to see context information similar to what you see with the OS/400 DSPFD command. This interface provides information formatted on different notebook pages and is structured as follows:  General tab (Figure 7-21): Displays such information as the member name, its description, size, number of current and deleted rows (therefore, making it easy to judge whether reorganize can be useful), and maximum percentage of deleted rows allowed. Plus it gives you the ability to change the Reuse Deleted Rows (REUSEDLT) parameter and the table description. 1 2 3 Chapter 7. Database administration 185 Figure 7-21 Table Description panel: General  Allocation tab: Allows you to verify if there is a maximum number of rows set on the table, what was the initial number of rows, its subsequent increase, if there is a value set for forcing the writing of updates to auxiliary storage, and to change these settings.  Access Path: Shows the current size of the access path, the maximum size, the maximum key length, whether the access path is valid or shared, whether it is journaled, what the maintenance and recovery of the access path is set to, and other options for further details.  Usage tab: Contains information on creation, modifications, backups and if this files data can share open data paths across jobs (SHARE *YES/NO). The Share open data path check box offers an easy way for you to change this setting for the table.  Activity tab: Allows you to record the level of activity, documenting such information as the number of insert, update and delete operations, the logical and physical reads, clear operations, index builds/rebuilds, a full open and close, reorganize operations, and the number of rows being rejected in open operations (by key, non-key, group by/having selection methods). This tab also contains important information regarding the number of valid and invalid indexes built over the table.  Table Details tab (Figure 7-22): The last tab provides information on: – Creation – Number of allowed members Note: The Access Path tab is only visible for non-SQL described files. For SQL files, use the properties option to see indexes and views or display their individual descriptions. 186 Advanced Functions and Administration on DB2 Universal Database for iSeries – Maximum time a program is to wait for the file and its rows to be available – Maximum row length – Sort sequence – Language identifier – Format level check and identifier – Allowed activity level – Unique identifier for this table in the system – Disk pool it is using and if it is a distributed file Some of the above mentioned values can be changed using this interface. Figure 7-22 Table Description: Table details Changing properties: You must ensure that proper authorization or permission has been given to the Operations Navigator user to access the Table Description and Properties function for the object. You must also ensure the authorized user understands the importance of any table modifications they make. For example, the properly authorized user can delete fields or columns, and therefore, lose the associated data. Programs created (compiled) against the table that has a field or column added or removed may encounter an error during the next file or table open function. Through the Create Physical File (CRTPF) or Change Physical File (CHGPF) command, you can specify the Level Check (LVLCHK) parameter. A table with LVLCHK(*YES) specified detects the added or removed column during file open. Re-creating the program usually resolves the problem if the program does not need to use the column. A program that may have already been performing column validity checking performs unnecessary duplicate processing if a check constraint is added to the table. Chapter 7. Database administration 187 Table Properties example Right-click a table, and select Properties to display all the table properties. We use the initial properties panel (Column information) as shown in Figure 7-23 to discuss table properties:  Column properties  Key constraints  Indexes  Referential constraints  Triggers  Check constraints Figure 7-23 Table Properties example Column properties As shown in Figure 7-23, we moved the cursor to the CNAME field or column, as indicated by the arrow to the left of the column and the highlighted column description. In the upper column list, you see the column data type and length. In the lower pane, you see some information about the column, including the Coded Character Set Identifier (CCSID). The CCSID numeric value specifies how character data is stored on your system. For user-created tables, the character data is defaulted to be stored in the format according to your primary language ID. For example, on the systems used for this redbook, the OS/400 Language ID system value QLANGID is set to ENU – English for United States (uppercase and lowercase). The default CCSID value for ENU is 37, as shown in our Properties example. For more details on CCSID support, refer to AS/400 National Language Support, SC41-5101. The Browse button leads to a dialogue in which you can view other tables that you may want to use as a base definition to add (copy in) a new column to table CSTFIL. The New button enables the Column window shown at the top of Figure 7-23 to accept a new column definition. In the Column window, you enter the appropriate definition information. Select a column in the Column window, and click the Delete button to remove the column from the table. 188 Advanced Functions and Administration on DB2 Universal Database for iSeries You can make other changes or additions to the table and, when finished, click the OK button to make the changes permanent. The changes or additions are run as if you entered the ALTER TABLE SQL statement. If the table was created with the CRTPF command, the original file is deleted and the new file is recreated. The field or column deleted also deletes the associated data. Key Constraints Constraints place some controls on the action to an object or portion of an object. This Key Constraints tab enables you to add, modify, view, or delete the primary key and unique keys for a table. You may modify a constraint if it was defined during your current table editing session. If you added the constraint and then clicked OK on either the New Table dialog or Table Properties dialog, you may only view the constraint. A unique constraint is the rule that the values of the key are valid only if they are unique. Unique constraints can be created using the CREATE TABLE and ALTER TABLE statements. Unique constraints are enforced during the execution of INSERT and UPDATE statements. A PRIMARY KEY constraint is a form of the UNIQUE constraint. The difference is that a PRIMARY KEY cannot contain any nullable columns. Indexes Indexes are your specific definition of key fields or columns and the order of those fields or columns within the complete key. During performance analysis, the OS/400 query optimizer may issue a job log message that recommends a new index be created to improve performance. You can use SQL CREATE INDEX or this tab dialogue to create a new index. The Indexes tab enables you to add modify, view, or delete an index for the table with which you are currently working. You may modify an index only if it was defined during your current table editing session. If you added the index and then clicked OK on either the New Table button or Table Properties button, you can only view the index. Referential Constraints A referential constraint is where one or more columns of a table refer to values of columns in the table you are currently working on or another table that is referred to as the parent table for the current table. The Referential Constraints tab enables you to add, modify, view, or delete referential constraints for the table on which you are currently working. You may modify a constraint only if it was defined during your current table editing session. If you added the constraint and then clicked OK on either the New Table button or Table Properties button, you may only view the constraint. Triggers DB2 Universal Database for iSeries has supported native high-level language (HLL) system (external) triggers since V3R1. A trigger is program to initiate an action (trigger) when an event occurs on a database file/table (insert, update, or delete). Triggers can be initiated either before or after the event. Update triggers can differentiate whether a record/row was actually changed. You need to be cautious when using triggers. They offer powerful functions without knowledge of the current program, but they are called synchronously. If they do too much work before returning control to the original program, you may observe performance degradation. SQL Triggers are new for V5R1. For SQL Triggers, SQL code is used to create the trigger using SQL syntax. With native triggers, a program name is specified to execute (which could, of course, contain SQL). Chapter 7. Database administration 189 New for V5R1 is the support for up to 300 triggers per table. You are now provided with the option to add or replace triggers when you associate a trigger with a database table. Also new in V5R1 is the support for READ event system (external) triggers only – a trigger program that executes when a record is read from a database table. Since DB2 Universal Database for iSeries now supports both system (external) and SQL Triggers, the Operations Navigator Database component now interfaces to both kinds of trigger. Trigger definition and properties are part of the table Properties dialogue. See Figure 7-24. The Properties page for triggers has been changed to display a list of triggers for the table, which could include a mixture of both Native and SQL Triggers. Then the user can select a trigger and go to a more detailed Properties dialogue for that specific trigger. The properties dialogues are different for native and SQL Triggers. Figure 7-24 Defining an SQL Trigger From the General tab screen (Figure 7-25), you can add an SQL Trigger to your table, specify the event to fire the trigger, and indicate whether the trigger applies to the whole table or just the selected columns. 190 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-25 Defining an SQL Trigger: General tab The Timing page specifies the timing and frequency of the trigger and the resulting correlation names (Figure 7-26). Figure 7-26 Defining an SQL Trigger: Timing tab The SQL Statements page (Figure 7-27) contains the code for the SQL program that you are defining as a trigger. You can use the SQL statement examples and fill in the necessary information to make coding SQL easier. If you are adding a trigger to an existing table, you can check for syntax errors by clicking Check Syntax once you have the statement defined. A message is displayed for the first error detected, if any. To check for additional errors, click Check Syntax after the first error is fixed. This button is disabled when you add a trigger to a new table. Chapter 7. Database administration 191 After an SQL trigger has been created, the SQL statements cannot be changed. You will have to delete and recreate the trigger to change the SQL. Figure 7-27 Defining an SQL Trigger: SQL Statements tab On the Add System Trigger dialog, you can add a system (external) trigger to your table. System (external) triggers use a program object that already exists on the system. The program must exist before the trigger can be added. On pre-V5R1 systems, only the program name and library fields are active. See Figure 7-28. Figure 7-28 Defining a system trigger 192 Advanced Functions and Administration on DB2 Universal Database for iSeries Check Constraint A check constraint is specified at the field or column level. A check constraint examines the validity of the data in one or more of the columns in the same table. The Check Constraints tab enables you to add, modify, view, or delete check constraints for the table on which you are currently working. You may modify a constraint only if it was defined during your current table editing session. If you added the constraint and then clicked OK on either the New Table dialog or Table Properties dialog, you may only view the constraint. Database table constraints tips Constraints offer powerful system-provided DB2 UDB functions that need to be understood before you use them. In addition to the Operations Navigator graphical interface to constraints, OS/400 provides several commands to support constraints, such as the Add Physical File Constraint (ADDPFCST) and Remove Physical File Constraint (RMVPFCST) commands. You can access the full range of OS/400 constraints support by using the OS/400 Work with Physical File Constraints (WRKPFCST) command. For additional constraints information, refer to:  Operations Navigator online help information  iSeries Information Center (http://www.iseries.ibm.com/infocenter). You can use the search word constraints  Chapter 15, “Controlling the integrity of your database with constraints”, in Database Programming, SC41-5701  Online help for the OS/400 commands on constraints, accessed through the Work with Physical File Constraints (WRKPFCST) command Managing journals and journal receivers As discussed in “Create journal example” on page 177, a journal and its attached journal receiver record the changes and actions made to a table. Once you create a journal and its initial journal receiver, you can perform additional journal management by right-clicking either the journal or a journal receiver within a library. Figure 7-29 shows the actions that are possible on an existing journal. Chapter 7. Database administration 193 Figure 7-29 Managing a journal The actions are explained in the following list:  Starts and ends journaling: This action starts or ends journaling for one or more specific files or tables. Clicking this action brings up the Start/End Journaling panel shown in Figure 7-30 on page 194. The start and end functions correspond to the OS/400 Start Journaling Physical File (STRJRNPF) and End Journal Physical File Change (ENDJRNPF) commands. Journaling can be started and ended from the item you obtain by right-clicking a table name.  Swap receivers: Clicking this action immediately detaches the currently attached journal receiver and creates a new journal receiver by adding 1 to a sequential number suffix to the journal receiver name. You can also manually swap receivers by using either an option from the Properties action or by using the OS/400 Change Journal (CHGJRN) command.  Permissions: This action lets you view and change the authorities to the journal  Delete: Clicking this action brings up a confirmation window for completing the journal deletion request or canceling it. The journal can only be deleted if all the objects being journaled to the journal have had journaling ended for them.  Properties: This action brings up a panel that shows the original create journal attributes including journal receiver attributes and remote journal attributes, if any. You can also create a new journal receiver or remote journal by using the buttons that lead to additional panels. Figure 7-31 on page 195 shows an example of Journal properties information. We right-clicked the BUPJRN journal and selected Starts and ends table journaling. Figure 7-30 shows the Start/End Journaling display for BUPJRN after we performed some journal-related operations earlier. 194 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-30 Start/End journaling display To start journaling for a file or table, you can select the table and either click the Add button or drag and drop the file name into the list box (1 in Figure 7-30). When all tables you want journaled have been added to the list box, click the OK button. This starts journaling for these files or tables. Alternatively, you could have used the OS/400 Start Journaling Physical File (STRJRNPF) command. Notice the “Journal…” and the “Omit op…” column headings in the list box (1). The “Journal…” heading corresponds to the STRJRNPF command IMAGES (Record images) parameter. The “Omit op…” column heading corresponds to the STRJNPF command OMTJRNE (Omit journal entries) parameter. If you click under the “Journal” or “Omit op” heading to the right of a file or table name, an “X” character appears. If you click again, the “X” disappears. An “X” under Journal means that both before and after record images are written to the journal receiver. If no “X” appears, only an after image is recorded in the journal receiver. An “X” under Omit op… means that file or table open and close actions are not recorded in the receiver. If no “X” appears, all actions on the journaled file or table are recorded in the receiver. In the list box (2 in Figure 7-30), you see the PFREXP/CSTFIL (system naming convention) table is already being journaled at the time the Properties action was selected. You can stop journaling for a file or table by selecting the file or table (listed in 2) and clicking the Remove button and then clicking the OK button. This function corresponds to the OS/400 End Journaling Physical Files (ENDJRNPF) command. Journal Properties example When we right-clicked the BUPJRN journal and selected Properties, the Journal Properties panel appeared as shown in Figure 7-31 on page 195. This shows the original parameters used to create the journal and enables you to make some changes and additions. The Tables button shows you the Start or End journaling panel we already described. 1 2 Chapter 7. Database administration 195 The Receivers button shows you the currently attached receiver and previously detached journal receivers still on the system. You can also add a new journal receiver. The Remote Journals button shows you the current status of a remote journal, if any. You can also add a new remote journal. Figure 7-31 Journal Properties example You can select the Swap receivers box and optionally specify either Continue or Reset to specify the sequence numbering to be used with the new receiver. Then click the OK button to have an immediate detach of the current journal receiver and creation of a new receiver that is immediately attached to the journal. Review online help information (click the Windows ? button and place it on the Swap receivers text; this is the equivalent of context sensitive help on 5250 command screen when you move the cursor to a particular keyword parameter and press F1 for help) to determine if Swap receivers applies to your journaling environment. In this example, we clicked the Receivers button to show you the panel in Figure 7-32. In our example, we have three online, but detached, receivers. The currently attached receiver is BUPJRA0002. 196 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-32 Journal receivers list and properties example By selecting the BUPJRA journal receiver, the lower portion of the panel automatically displays the General properties of this receiver. We already selected the Entries tab information. Select an online detached journal receiver. Click the Delete button to remove the journal receiver and its entries from the system when you no longer need this journaled information. When you click the New button, you see an Add Journal Receiver panel. Clicking the OK button makes any new or delete function permanent. You may also find the journal receiver General, Entries, and Storage information in a separate Properties panel for a specific receiver by performing either of the following actions from the library panel:  Double-clicking the journal receiver object  Right-clicking the journal receiver object and selecting Properties Working on locked rows To gain access to this function, right-click a table. The Locked Rows dialog (Figure 7-33) displays the row number, job, user, job number, current user, status, and lock type for rows that have a row lock placed on them. A row lock is placed on a row when you read a table that is opened for update. While the row lock is in effect, no other job can read the same row for update, which keeps another job from unintentionally deleting the first job's update. Chapter 7. Database administration 197 Figure 7-33 Locked Rows example The Locked Rows panel allows you to perform various tasks:  Check which jobs are locking which rows  View the job log for a job  View an SQL statement that is running or has run in the job  Use the above mentioned SQL Statement with the Run SQL Scripts center  End a job that is listed (provided you have the right authority) Since most of these tasks are rather intuitive, we only document how to link to the SQL Script center to investigate on what is happening in the database. After you start the Locked Rows function, select the job (1 in Figure 7-33) you want to examine. Click the SQL Statement button on the right-hand side of the picture (2) to bring it into the bottom part of the panel (3). At this point, when you click the Edit SQL button (4), the Run SQL Scripts center starts, and the SQL statement is brought into it for you to use. Refer to “Running a single SQL statement” on page 211 for a discussion on how to use this tool. You should also refer to “Linking to the Visual Explain component” on page 212 to see how to use it to conduct database performance analysis. 7.3 Run SQL Scripts The Run SQL Scripts center is a powerful interface to your iSeries database. With it, you can use any SQL statements to issue any kind of operations you are authorized to on the iSeries database objects. Licensed product program 5722-ST1, DB2 Query Manager and SQL Development Kit for iSeries, is not a prerequisite for using Run SQL Scripts. This component of Operations Navigator uses JDBC to access the server. To use SQL from Operations Navigator, right-click the Database component under the iSeries server that contains the data. Figure 7-34 shows the Database context menu with the Run SQL Scripts action highlighted. 2 1 3 4 198 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-34 Run SQL Script Right-click Database to bring up the pull-down menu. Do not click Libraries, because Operations Navigator enables you to potentially access the entire system, rather than limiting you to just the data within a library. Figure 7-35 shows an example of the initial Run SQL Scripts panel. Important: This component has been entirely re-written in V5R1 using Java. It has an enhanced layout and supports these new features as well:  Result data is displayed in the same or a separate window via the Options menu  Run SQL Statement icons  Run SQL statement by double-clicking instead of single-clicking via the Options menu Chapter 7. Database administration 199 Figure 7-35 Run SQL Scripts: Initial input panel The Run SQL Scripts window lets you create, edit, run, and troubleshoot scripts of SQL statements. You can also save the SQL scripts with which you work into a PC file on your PC workstation. There are several run options for the SQL statements that are entered into the SQL statement input area (3). We discuss them later in this section. As shown at 1 in Figure 7-35, you can select to review a list of already provided SQL statements. OS/400 provides a large set of base syntax for almost every possible SQL statement that can be used. You can display the list of existing SQL statements by clicking the down arrow in this area of the panel. You can then select an SQL statement from the list shown and have it inserted into the statement input area (3) by clicking the Insert button (2). You can modify the selected SQL statement or enter your own SQL statement. You can run one or more of your entered your SQL statements in different ways and stop between statements. Before we discuss the run actions, refer to Figure 7-36 to see the different panels within the Run SQL Scripts function. 1 2 3 200 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-36 Run SQL Scripts window pane example The beginning of the list of provided SQL statements is shown at 1. This list was produced by clicking the down arrow (2). In this example, we do not select an SQL statement to be placed into the statement input area (3). However, if we selected one or more SQL statements in the window at 1, the statement or statements would appear in the “SQL statement example” area (4), and you could click the Insert button to place the statements into SQL input area (3). In the SQL statement input area (3), we already entered two simple SQL statements that are partially hidden. We separately ran the following SQL statements: select * from item_fact; select * from cust_dim; Then we viewed the results on a panel (not shown), prior to selecting the list of SQL statements (1). The Run History panel (5) shows you the success and any messages of the SQL statements run. When you select the Edit option from the menu bar, you have the option to clear run history information. Figure 7-37 includes the previous SQL SELECT statements. But, we added SQL statements to illustrate more of the power of DB2 Universal Database for iSeries accessible through Operations Navigator. Figure 7-37 also illustrates some of the run options for the SQL statements we showed under Run SQL Scripts support. 4 2 3 5 1 Chapter 7. Database administration 201 Figure 7-37 Run SQL Scripts: Additional sources Figure 7-37 at 1 shows that we did a select from a table that is in a different OS/400 library (pfrexp) than the libraries included in our job description’s initial library list. We did this by qualifying the table with pfrexp/. The slash separator character (/) is valid because we changed from the default SQL naming convention to the system naming convention. By default, we are running SQL statements on the system to which we are connected. The CONNECT SQL statement used to connect to a remote system as20 (“As20” in our Operations Navigator screen example figures), using OS/400 Distributed Relational Database Architecture (DRDA) over TCP/IP is shown at 2. Assuming this CONNECT statement is successful, all SQL statements thereafter are directed to remote system as20 until an SQL “release all” statement is issued, when the connection returns to access only the local As25 system. OS/400 supports connections to multiple remote systems during the same session. For example, following the statement shown at 4, you can issue a “connect to as05” statement. Assuming this is successful, all the following SQL statements are directed to system As05. You can then issue a “set connection to as20” statement that resets the current dialogue back to system As20. You need to keep track of which system (remote database) you are connected to and on which system you are performing operations. The next statement (3) selects the cust_dim table in the library tpstar01 on the remote system as20. 4 1 3 2 202 Advanced Functions and Administration on DB2 Universal Database for iSeries While we cannot go into the details of DDM/DRDA in this book, we discuss basic setup requirements for the DDM/DRDA example shown here to work over TCP/IP. Refer to 7.4, “Change Query Attributes” on page 217, for more information. A select statement that uses only some of the fields or columns in the cust_dim table and displays only the records or rows where the key field or the CUSTKEY column has a value of 1 or a value of 5 is shown at 4 in Figure 7-37. In a more complex data structure and performance critical environments, you would want to use a combination of the following options:  The Run SQL Scripts option to include query optimizer debug messages in the job log (see 7.3.4, “Run SQL Scripts Run options” on page 210)  SQL Performance Monitor support (see 7.6, “SQL Performance Monitors” on page 220)  Visual Explain (see Chapter 10, “Visual Explain” on page 301) By reviewing the job log, using Visual Explain or going through monitored data, you can determine if the most efficient method is used by OS/400 query support to perform the SQL function. 7.3.1 ODBC and JDBC connection Open Database Connectivity (ODBC) is a standard interface for database connectivity defined by the Microsoft Corporation. ODBC establishes the standard interface to any database as SQL. In general, the ODBC architecture accounts for an application using the ODBC interface, an ODBC Driver Manager, one or more ODBC Drivers, and an ODBC Data Source (place where the data is stored). Java Database Connectivity (JDBC) is an equivalent standard interface for database connectivity from Java applications. Client Access Express provides the iSeries ODBC and JDBC drivers that runs on the PC workstation and the ODBC and JDBC Data Source support that runs on the iSeries server. Production mode job name starts with QZDASOINIT (or QZDASSINIT if SSL is being used). In version 4, with ODBC Data Sources, you can set up a Client Access Express ODBC data source by providing a data source name (a name meaningful to you) and an iSeries server name. Starting in version 5, the setup and administration of Client Access-provided ODBC driver is done by using the standard ODBC data source administrator, provided with the Windows operating system. An ODBC data source consists of the data that the user wants to access and its associated operating system, Database Management System (DBMS), and network platform (if any) used to access the DBMS. Note: DRDA is the IBM-defined architecture for accessing remote databases. It is implemented on all IBM operating systems, and some non-IBM operating system databases support it. At a base set of functions level, it is similar to the ODBC and Java Database Connectivity (JDBC) set of capabilities. On IBM systems, Distributed Data Management (DDM) is a higher level interface to DRDA capabilities. Note: With our examples, each table index (set of key fields or columns) structure is relatively simple, and the number of rows is small relative to a million or more rows that would be present in a data warehouse environment. We also do not have complex join statements (columns joined together from two or more tables). Chapter 7. Database administration 203 Setup information is associated with a data source and may include, for example, data formatting and performance options. Data formatting options include qualified name separators, date and time formats, and data translation. Performance options include when to use record blocking, data compression, or an SQL Package. An SQL package stores previously parsed SQL statements to improve performance when used later. You can also specify if Secure Socket Layer (SSL) is to be used with the ODBC connection. Some client applications (including Operations Navigator) may provide their own unique data source definition. A good source for more information on ODBC support is Client Access Express for Windows, SC41-5509. You can create your own data source to limit the libraries that can be used and, as previously described, your own set of name separators, date and time formats, performance options, and so on. OS/400 provides two data sources that you should understand even if you are not creating your own data source:  A data source used by Operations Navigator itself to perform its functions: This data source is identified by the system name to which you are first connected. For example, if the first system you connect to is called As25, the data source used by Operations Navigator is named QSDN_As25.  A data source is used if you use Database-> Run SQL Scripts: The first time you select the action to Run SQL Scripts to a specific iSeries server, OS/400 creates a JDBC data source for the system (ODBC in V4R5 or previous releases), which can be changed by selecting Connections -> JDBC Setup (Figure 7-38). One JDBC data source is created for each system on which SQL scripts are run. You do not have to create your own JDBC Data Source and understand the data source parameters to run SQL statements against libraries and files or tables to which you are authorized. In 7.3, “Run SQL Scripts” on page 197, we use the default IBM-created data source in our JDBC Data Source Translation parameters. Important: Unless you are an ODBC expert, do not change any of the default settings for this data source. If you change them, Operations Navigator may fail to operate correctly. 204 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-38 JDBC data source panel Server tab Default libraries enables you to change the set of libraries available to the user of this JDBC data sources. The default (*USRLIBL) means to use the initial library list (INLLIBL) parameter specified on the job description for the OS/400 user profile using this JDBC data source. Commit mode controls the level of DB2 Universal Database for iSeries commitment control, including when database changes are considered permanent and whether other users of the same database rows can see column updates that are not yet permanent. A complete description of commitment control is beyond the scope of this redbook. However, you should understand that in the industry, users of SQL typically expect commitment control to be active. That is, an application design determines what a competed transaction (also called a unit of work) is. Any database row changes (column updates, rows deleted, rows inserted) are not considered permanent until a successful transaction has been completed (transaction boundary). At that time, the application performs a commit and all changes are now made permanent. If the application determines that an in-progress transaction should be terminated, it performs a rollback. All changes are as if they had never occurred. If the application abnormally terminates before issuing a commit or rollback, the underlying SQL support performs the rollback. To support commitment control on OS/400, you must also have the tables journaled and the job using these tables must issue a system operation that starts commitment control for the job. This system operation can be invoked by using the OS/400 Start Commitment Control (STRCMTCTL) command or be implicitly invoked by this parameter for values other than *NONE. A commit group refers to the rows that are in the process of being updated, deleted, or inserted. As the help text shows, objects referred to on the COMMENT ON, CREATE, and so forth are also part of this commit group. The commit or rollback applies to all of these rows and objects. Chapter 7. Database administration 205 We include the help text here because the OS/400 default is *NONE, which is not generally supported in the industry. This provides a very flexible operating environment, such as letting other applications or users access the latest database changes. However, *NONE exposes the table rows, even while being processed by the properly authorized Operations Navigator user, to be modified without a required database Commit or Rollback operation sequence to make any database changes permanent. For example, using *NONE means any valid SQL statement that changes column data has made a permanent change to the data. If the properly authorized Operations Navigator user mistakenly updates a column using a wrong value for a key, there is no rollback function available to undo the change to the wrong row. You need either a backup copy of the data or an OS/400 journal to recover the original data. The other commit values specify row locking rules (other applications prevented from updating the same row) and visibility of in-progress changes among applications accessing the same rows. Package tab This tab specifies whether extended dynamic support is enabled. Extended dynamic support provides a mechanism for caching certain dynamic SQL statements on the server. The first time a particular SQL statement is run, it is stored in an SQL package on the server. On subsequent runs of the same SQL statement, the server can skip a significant part of the processing by using information stored in the SQL package. By default, it is not enabled. Performance tab This tab allows you to set performance options. Language tab This tab allows you to specify language options. Other tab The Other tab allows you to set the access type and remarks source options for your connection. Translation tab In most cases, you never need to view or change the JDBC (or ODBC) data source translation parameters. This is because your application tables or files are typically stored as using the Coded Character Set Identifier (CCSID) numeric value that stores the data according to your national language encoding. In these cases, any OS/400 data accessed by the client workstation is translated into the appropriate ASCII format as required for viewing or processing on the client. However, certain OS/400 system files or tables are defined to use the special CCSID 65535. By default, JDBC data source processing does not translate data from a file or table with CCSID 65535. For example, if you want to use Run SQL Scripts against the performance collection files (prefix QAPM...) or a table generated from a virtual private network (VPN) journal (copied to a database file or table), you need to have the character columns translated in most cases. Select the JDBC data source Translate tab and select the Translate CCSID 65535 check box. 206 Advanced Functions and Administration on DB2 Universal Database for iSeries For more information on CCSID support, refer to AS/400 National Language Support, SC41-5101. Format tab There is an important operational difference between using the SQL naming convention and the System naming convention when running SQL statements under Operations Navigator Run SQL Scripts. If you are using the system naming convention and use a non-qualified name, such as a table name with no library qualifier, the system searches for the table within all libraries currently in the session’s (job’s) current library list. If you are using the SQL naming convention, the ANSI standard specification causes the system to look only in the current library within the session’s current library list. For example, assume the user portion of the session’s library list is in the order of TEAM02, followed by library TPSTAR02. Also, assume the unqualified table name is CUST_DIM and is stored in library TPSTAR02. Using the SQL naming convention, the system looks for CUST_DIM only in library TEAM02 and does not find it, which results in an error condition. Using the system naming convention, the system first searches library TEAM02 and then library TPSTAR02. The CUST_DIM table will be found and the SQL statement will run successfully. Format parameters are important if you have a special operating environment, such as your system requiring country specific or multiple country support. You must review the online help text to get the details for all of these parameters. The settings are determined by your requirements. If you want to modify either data source, refer to the online help or consult Client Access Express for Windows, SC41-5509. 7.3.2 Running a CL command under SQL script In addition to running SQL statements under Run SQL Script, Operations Navigator allows the properly authorized user to run any OS/400 Control Language (CL) statement that can be validly run in a batch (no 5250 workstation required) environment. You must precede the OS/400 command syntax with the prefix CL: (uppercase or lowercase) as shown in Figure 7-39. Chapter 7. Database administration 207 Figure 7-39 Run SQL Scripts: Running a CL command The selected CL command is an OS/400 command that submits the job to job queue QBATCH, which is one of the IBM-supplied job queues associated with the IBM-provided subsystem QBATCH. The submit job command parameter (CMD) value can be any OS/400 command or user-defined command. In our example, we used the DSPOBJD command with its own set of parameters. You may also use much simpler OS/400 commands, such as:  Adding a new library to the current library list of the Operations Navigator session using the CL command: CL: ADDLIBLE LIB(PFREXP);  Sending a message to the system operator using the CL command: CL: SNDMSG MSG(’This message is from an Operations Navigator session from user TEAM02.’) TOUSR(*SYSOPR); 208 Advanced Functions and Administration on DB2 Universal Database for iSeries 7.3.3 Run SQL Scripts example using a VPN journal This section shows an example of using Run SQL Script to identify the IP packets, if any, that were denied routing based on OS/400 VPN filtering rules. The standard OS/400 VPN support records permit, deny, and filter rule change occurrences in a system journal named QIPFILTER, stored in library QSYS. The OS/400 Display Journal (DSPJRN) command provides a journal entry time stamp and other compare values to selectively display, print, or copy journal entries to a database file or table. If you choose the database option, you can process the copied journal entries several different ways through SQL. Run SQL Scripts is a good way to experiment with viewing different journal entry field or column data. Once you see a view of the data you want to use repetitively, you can save the SQL statements for later reuse or copy the SQL statements into a program that does further processing or graphical display. This section uses the journal data discussed in the “AS/400 VPN problem determination,” chapter in AS/400 Internet Security: Implementing AS/400 Virtual Private Networks, SG24-5404. We performed the following steps to query the VPN logging data originally placed into the QIPFILTER journal. The query results show the journal entries for packets that have been denied routing, since a large number of deny entries may require further investigation by your security personnel. 1. Create a copy of the IBM-supplied file QSYS/QATOFIPF into a library of your choice, using the OS/400 Create Duplicate Object (CRTDUPOBJ) command, for example: CRTDUPOBJ OBJ(QATOFIPF) FROMLIB(QSYS) OBJTYPE(*FILE) + TOLIB(mylib) NEWOBJ(myfile) Tips for running CL in Run SQL Scripts Running SQL Scripts is a powerful way to test new SQL statements, especially in the sequence you may want to run them in a program. In an actual application environment, you may also want to integrate running system functions through CL commands with your SQL statements. Here are some tips:  Starting with Client Access Express Service Pack 5 (SP5) for V4R4, the following restriction has been removed: For the CL command to be recognized successfully, you must remove (delete) any comment statement, such as: "/* Enter one or more SQL statements separated by semicolons */."  The IBM-supplied SQL statement examples include some CL command examples at the end of the SQL statements.  The key to making the OS/400 command work from an Operations Navigator Run SQL Scripts session is to ensure the objects referenced in the command can be found in the Operations Navigator session’s (job’s) library list or the system library list (system value QSYSLIBL). Adding a library name under the Database->Libraries branch does not carry over to the Run SQL Scripts function. OS/400 commands can always be found through the system value QSYSLIBL. However, objects, such as user-defined commands, may require the appropriate library to be in the Operations Navigator Run SQL Scripts session’s library list. Use Connection -> JDBC Setup to amend the user part of the library list. Chapter 7. Database administration 209 The system file or table QATOFIPF provides the column definitions used by the IBM-supplied queries. In our example, we duplicate this table as ON_IPFTRT. 2. Use the DSPJRN command to copy the journal entries from the QUSRSYS/QIPFILTER journal to the output database file created in the preceding step: DSPJRN JRN(QIPFILTER) JRNCODE(M) ENTTYP(TF) OUTPUT(*OUTFILE) + OUTFILFMT(*TYPE4) OUTFILE(mylib/myfile) ENTDTALEN(*CALC) The DSPJRN command has both starting and ending time-stamp values and starting and ending journal entry sequence numbers so you do not need to copy the entire set of journal entries to the file or table. 3. You need to review the field or column names and descriptions for file or table ON_IPFTRT to determine which columns to select and use for row selection. You may use the OS/400 Display File Field Description (DSPFFD) command or use Operations Navigator to display the table Properties by right-clicking the table name. AS/400 Internet Security: Implementing AS/400 Virtual Private Networks, SG24-5404, provides good background information to help select the appropriate fields or columns. 4. Using Run SQL Scripts, build the SQL statement and view the results. Figure 7-40 shows our example SQL statement and sample output. Figure 7-40 Run SQL Scripts: Viewing ‘denied’ VPN packets The TFACT (filter action) column (1 in Figure 7-40), records values such as PERMIT, DENY, or additional values for adding and changing filter rules and starting and stopping filtering. You also see our SQL compare value for ‘DENY’. You can see that we did not want to look at all (13,000) journal entries, so we started around the middle of the entries with journal entry sequence number 6300 (2 in Figure 7-40). 1 3 4 1 2 210 Advanced Functions and Administration on DB2 Universal Database for iSeries The TFPDIR (packet direction) column specifies “O” for output packet and “I” for input packet. Using the source IP address and port number (3) and the destination IP address and port number (4), a TCP/IP expert can determine the actual workstation and TCP/IP function. A TCP/IP expert may also choose different columns to include in the SQL SELECT statement. 7.3.4 Run SQL Scripts Run options This section explains the Run options available for these SQL statements. We use Figure 7-41 as a basis for explaining the run options. Figure 7-41 Run SQL Script: Run options There are two “selection lists” types from which you can choose to run one or more SQL statements at a single time. You can select the Run option (1) from the Run SQL Scripts menu bar or select one of the green arrow or hour glass Run action icons (2) from the toolbar. These have corresponding functions. You can also select the Run option with a key sequence as shown under the Run pull-down menu. You can pre-specify (defaults are provided) some controls over the Run function through the Options action in the menu bar (6). We discuss these controls in “Controlling SQL run options” on page 213 after we explain the three levels of run options:  Running a single SQL statement  Running a set of SQL statements  Running all SQL statements currently specified 3 B C A 4 1 2 5 D E F 123 D E G 6 Chapter 7. Database administration 211 Running a single SQL statement Place the active screen cursor within the SQL statement text you want to run, for example: select * from pfrexp/cstfil; This is referenced as 4 in Figure 7-41. You can run only this statement by using one of the following actions:  Click the Selected action (C).  Click the “select one line” or “select one line hour glass” icon associated with C in our example in Figure 7-41.  Press Ctrl+Y from the workstation keyboard. Only the single statement will run. If it is a SELECT statement, the results are presented as a window on your Operations Navigator workstation. The column names are presented as column headings. If you want to select only a subset of columns later, you can use these headings and displayed column data to help you select the appropriate columns. Figure 7-42 shows some of the column headings and associated data for the pfrexp/cstfil table. Figure 7-42 Run SQL Script: Sample SQL SELECT output Running a set of SQL statements You can run a set of SQL statements that are currently active in your Operations Navigator session to the iSeries server. Using our example in Figure 7-41, you would run: select * from pfrexp/cstfil; 4 through SELECT CUSTKEY ... IN(1,5); 5 You do this by placing the active screen cursor within the SQL statement text (4) and performing one of the following actions:  Click the From Selected action (B).  Click the From Selected icon (the middle down arrow or the middle hour glass) associated with 2 in our example in Figure 7-41.  Press Ctrl+T from the workstation keyboard. This runs each statement sequentially, beginning with: select * from pfrexp/cstfil; 212 Advanced Functions and Administration on DB2 Universal Database for iSeries We have three SELECT statements in our example. For each SELECT statement, a window of data is presented; all three windows are produced. However, if the SELECTs are fast enough, you may notice only the last SELECT output. The three windows are active on the screen and can be viewed by selecting the appropriate task from the windows task bar, typically at the bottom of a window. If an error occurs and a Stop on error option is selected (as specified under the Options pull-down menu (6 in Figure 7-41), the program stops and the statement where the error occurred remains selected. The statement is ready to be run after it is corrected. Running all SQL statements currently active You can run sequentially all the SQL statements that are currently active in your session to the iSeries server. Using our example, this would start with select * from cust_dim; 3 through SELECT CUSTKEY ... IN(1,5); 5 You run all the SQL statements by doing one of the following tasks:  Click the All action (A).  Click the All icon (leftmost down arrow or leftmost hour glass) associated with 1 in our example in Figure 7-41.  Press Ctrl+R from the workstation keyboard. If an error occurs and a Stop on error option is selected (as specified under the Options pull-down menu (6 in Figure 7-41), the program stops, and the statement where the error occurred remains selected. SQL statement syntax check Using this option (G in Figure 7-41), it is possible to validate a selected SQL statements or statements. This function performs a formal syntax check of the statement, while validating that the objects referenced (libraries, tables, columns) actually exist in the linked database. Resulting messages appear in the result panel. This option can also be invoked by pressing Ctrl+K after selecting an SQL statement. Linking to the Visual Explain component In V4R5, two more icons (D and E in Figure 7-41) were added to the Run SQL Script tool bar. These icons provide access to the Visual Explain function, as do the two new menu items (D and E) under Visual Explain. For more information, refer to Chapter 10, “Visual Explain” on page 301. The Explain option (D), or using Ctrl+E, allows you to review the Optimizer access plan that will be used when executing an SQL statement; the statement is not actually run but optimized with the query attribute Time Limit set to 0. For details on query attributes, see 7.4, “Change Query Attributes” on page 217. It produces a visual explanation of the statement but does not access the actual data from the database, therefore avoiding the unnecessary I/O load. The Run and Explain option (E), or using Ctrl+U, runs the SQL statement and gathers execution time statistics from the statement. It uses the actual access plan from the statement and the statistics and presents these in a graphical format. With this option, the statements are executed before the analysis graph is reported. Chapter 7. Database administration 213 Linking to the SQL Performance Monitor component Using the Recent SQL Performance Monitors option (F) under Visual Explain in Figure 7-41 on page 210, you can obtain a list of the most recent SQL Performance Monitor collections and can then link into the tool to analyze collected data. See 7.6, “SQL Performance Monitors” on page 220, for a discussion on the characteristics and usage of this tool. Controlling SQL run options By selecting Options from the Run SQL Scripts menu bar (6 in Figure 7-41 on page 210), you can control what to do if an SQL error occurs and what levels of additional information should be included in your session to the iSeries server:  Stop on Error: This turns stopping on or off when there is more than one SQL statement to run and an error occurs. If it is turned on (default), the SQL statements are stopped at the SQL statement in error, which remains selected. If it is turned off, all SQL statements continue to run until the end of the script has completed.  Smart Statement Selection: This turns on or off treating the selected SQL statement as a complete statement or attempting to run only the selected text. If it is turned on (default), the complete statement, up to the ending semi-colon (;) character, is attempted. If it is turned off, only the selected text is attempted. If you attempt to run only a portion of the original statement, the statement may complete successfully. However, you are subject to at least two error conditions: – Omitting some text may make the SQL statement fail, because the statement is incomplete. – Omitting some text may still result in successful completion. However, if the JDBC data source used for your session is set to *NONE for commitment control, omitting a phrase an UPDATE statement, such as WHERE CUSTKEY = 1, may update all the rows in the table, which is not what was intended. See 7.3.1, “ODBC and JDBC connection” on page 202, for additional information about commitment control. The most complete OS/400 documentation on commitment control is in Backup and Recovery, SC41-5304.  Include Error Message Help in Run History: This turns on or off (default) the inclusion of additional error message information in the Run History pane when an error occurs. Figure 7-43 shows an example where we specified an invalid column name (WRONGCOL) for the table. Note: This option is no longer available in Operations Navigator Run SQL Scripts in V5R1. Detailed error messages are always displayed in the messages tab on bottom frame. 214 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-43 Run SQL Scripts: Include Error Message Help in Run History  Include Debug Messages in Job Log: This option tells the OS/400 query optimizer support to record its decisions on how to process the SQL request, including any recommendation for creating an index that may improve performance. The option is typically used only when debugging new and complex SQL statements or while analyzing a suspected performance problem. Analyzing the job log messages may be sufficient to determine if a performance problem exists and what action should be taken to resolve the problem. You may also consider using the Operations Navigator interface to the SQL Performance Monitor, which is described in 7.6, “SQL Performance Monitors” on page 220, and Visual Explain, described in Chapter 10, “Visual Explain” on page 301. Figure 7-44 shows an example of an SQL JOIN statement and the associated job log messages that should be reviewed. Chapter 7. Database administration 215 Figure 7-44 Run SQL Scripts: Include Debug Messages in Job Log We use the selected SQL SELECT with JOIN statement (1) to show the associated job log debug messages issued by the query optimizer. To see the current Operations Navigator session’s job log, complete these tasks: a. Click View in the Run SQL Scripts panel. b. Click Job Log (2). In our example job log, we discuss two messages: the optimizer’s suggestion for an access path (index) to file ITMFIL with message ID CPI432F (3) and error message CPI433A (4). By double-clicking message CPI432F, the message details or “second-level text” is displayed. The message text describes why the create index function is recommended and the recommended column names to include in the new index. Message CPI433A may appear multiple times in the job log of a job that has run several SQL statements. Each time an SQL statement is run, the system looks for a file or table by the name of QAQQINI in the QUSRSYS library. This table can be set up by you to specify query attributes that the OS/400 query optimizer will use while processing each SQL statement. If you are not attempting to modify the default OS/400 query processing algorithm through this table, the table will not be in the QUSRSYS library, and this message is considered for information only. 3 4 2 1 216 Advanced Functions and Administration on DB2 Universal Database for iSeries  Run Statement On Double-Click: This option has been added in V5R1. When it is turned on, it allows the running of a SQL statement by double-clicking the SQL statement.  Change Query Attributes: This allows you to easily modify the query options file QAQQINI for your job, provided you remember the job number previously checked in the job log, or for any other job in the system. This is done using the same interface as documented in 7.4, “Change Query Attributes” on page 217. 7.3.5 DDM/DRDA Run SQL Script configuration summary Using Figure 7-37 on page 201, at 2, we showed and discussed an SQL CONNECT statement (“connect to as20;”) to access data on a remote system. For ease of reference, this statement also appears in Figure 7-44. This section provides overview information on configuration parameters required to successfully access remote data. For DRDA to work between a source system (function requester) and target system (request server) where the actual data is and the SQL function is performed, you need a certain DRDA configuration to be set up correctly. The following steps summarize the configuration required (using As25 as the source or requester system and As20 as the target or server system). On the As25 (source system), complete the following steps: 1. Start TCP/IP. 2. Enter the OS/400 Add Relational Database Directory Entry (ADDRDBDIRE) command: ADDRDBDIRE RDB(AS20) RMTLOCNAME(AS20 *IP) TEXT('Remote DB system via TCP/IP’) This relational database entry identifies a database name (RDB parameter), the remote system name, and that the connection is over TCP/IP. TCP/IP must be active on both the source and target systems. A Domain Name Services (DNS) server must be active in the network to resolve to the actual IP address. Note that DRDA runs over SNA connections as well as TCP/IP. 3. Enter the Add Server Authentication Entry (ADDSVRAUTE) command: ADDSVRAUTE USRPRF(TEAM02) SERVER(AS20) PASSWORD(T02EAM) The SQL CONNECT TO target system (remote server)-database statement can explicitly specify USER (user ID) and USING (password) information. If it does not, the user ID and password information specified in the ADDSVRAUTE command are passed to the remote server. Depending on the target system’s (remote server) security requirements for clients to connect to it, a user ID and, optionally, a user password are required that must be successfully validated on the remote server. We strongly recommend that you enter the user profile, server name, and password values in uppercase. 4. To specify a password value for the ADDSVRAUTE command’s PASSWORD parameter, the source system Retain server security data (QRETSVRSEC) system value must be set to 1. On the As20 target (remote server) system, follow these steps: 1. Start TCP/IP. 2. Start the TCP/IP DDM server. Note: To use ADDSVRAUTE support, your user profile must specify *SECADM special authority. You must also have *OBJMGT and *USE authorities to the user profile specified on this command. Chapter 7. Database administration 217 The DDM server jobs run in subsystem QSYSWRK. The jobs are named QRWTLSTN (daemon) and QRWTSRVR (server, one per connection). The network attributes’ DDM/DRDA Request (DDMACC) parameter for processing received DDM/DRDA requests is set to *OBJAUT. This means normal OS/400 processing user profile authority to the requested file or table is performed. This target or server system can be configured to not require a password from the source system. You do this by using the OS/400 Configure TCP (CFGTCP) command interface. Then select Configure TCP/IP applications->Change DDM TCP/IP Attributes. 3. A target system user ID and password must correspond to the user ID and password, if used, received from the requesting source system. 7.4 Change Query Attributes Using the Change Query Attributes item that becomes available when you right-click Database gives you an easy way to change your query options for accessing the database. However, you must be aware that some of the options that are available here can be manipulated using the Change Query Attribute (CHGQRYA) CL command on the iSeries server. There is not an exact one-to-one correspondence. For a detailed discussion on the implications of changing query attributes, refer to the manual DB2 UDB for iSeries Database Performance and Query Optimization in the iSeries Information Center. You can access the Change Query Attributes panel in two ways:  From Operations Navigator, right-click Database and select Change Query Attributes.  From the Run SQL Scripts center, select Options and Change Query Attributes. You then see the Change Query Attributes dialog as shown in Figure 7-45. Figure 7-45 Change Query Attributes panel Now proceed with the following steps: 1. In the upper part of the window (1), you see a list of all jobs currently active in the system. Scroll through the list to locate the job you are interested in, click on its name, and use the 1 3 4 5 2 218 Advanced Functions and Administration on DB2 Universal Database for iSeries Select button (2) to move the selection in the bottom part of the panel (3). You can select more than one job and set common query attributes for all of them at the same time. 2. At this point, you can specify a library (4) in which you want the original QAQQINI file to be copied. Click the Open Attribute button (5), which allows you to edit the copy of QAQQINI you just made in the library (4), as shown in Figure 7-46. Figure 7-46 Editing QAQQINI 3. Click the cell you want to change and type the new value. As shown in Figure 7-46, we change the setting for MESSAGES_DEBUG from the original value *DEFAULT to *YES, therefore, stating that we want debug messages to be recorded for the selected job. When you press Enter to activate your changes, you receive a warning message (Figure 7-47). 4. Click Yes. Figure 7-47 Warning message on modification of the QAQQINI file 5. You are brought back to the Change Query Attributes panel. Click OK to make the change effective. The options that are currently managed in the QAQQINI file and their values are documented in DB2 UDB for iSeries Database Performance and Query Optimization. 7.5 Current SQL for a job You can use this function to select any job running on the system and display the current SQL statement being run, if any. Besides displaying the last SQL statement being run, you can edit and rerun it through the automatically linked Run SQL Scripts option and display the actual job log for the selected job or, even end the job. This can also be used for database usage and performance analysis, with the Visual Explain tool documented in Chapter 10, “Visual Explain” on page 301. To start it, right-click the Database item in Operations Navigator and select Current SQL for a Job. You are presented with the dialog shown in Figure 7-48. Chapter 7. Database administration 219 Figure 7-48 Current SQL for a Job The Current SQL window displays the name, user, job number, job subsystem, and current user for the available jobs on your system. You can select a job and display its job log, the SQL statement currently being run, if any, decide to reuse this statement in the Run SQL Scripts center, or even end the job, provided you have sufficient authority. In our example, we selected an ODBC job (1) and displayed the last SQL statement it ran in the bottom part of the panel (2) using the SQL Statement button (3). To go to its job log, we would use the Job Log button (4). After the SQL statement is brought in the bottom part of the panel, it is possible to use the Edit SQL button (5) to work on this same statement with the Run SQL Scripts center that was previously documented in this redbook. See Figure 7-49. Figure 7-49 Working with current SQL for a job From here, it is also possible to link into Visual Explain, using the appropriate menu item or the icons (1) to help you with database performance analyses. For a discussion on this tool, refer to Chapter 10, “Visual Explain” on page 301. As you may have already noticed, all Operations Navigator database tools are tightly integrated into each other to make it easier for the user to fully exploit their capabilities. 3 2 5 1 4 1 220 Advanced Functions and Administration on DB2 Universal Database for iSeries 7.6 SQL Performance Monitors You can analyze the performance of iSeries SQL statements by putting the appropriate OS/400 job into debug mode, running the SQL statements, and viewing the query optimizer messages in the job log. You can see an example of using job log messages in “Controlling SQL run options” on page 213. This section describes a more powerful SQL performance analysis tool that initially appeared in V4R4 Operations Navigator and was further enhanced in V4R5. This support provides a graphical interface to IBM-provided SQL queries against data collected by the Memory Resident Database Monitor that was introduced in V4R3. In addition to output equivalent to the debug mode optimizer messages, this monitor can monitor multiple jobs and show the actual SQL statement. This interface is referred to as the SQL Performance Monitors. The SQL Performance Monitor, which was originally available in V4R4, only allowed gathering summary performance information from the Memory Resident Database Monitor. In V4R5, it is possible to enhance the usability of this interface by collecting detailed performance information. For a detailed discussion on the Memory Resident Database Monitor, refer to DB2 UDB for iSeries Database Performance and Query Optimization. Before you start an SQL Performance Monitor, you need to determine which job or jobs you want to monitor. There are several techniques you can use to determine the job. We list some of them here:  If you are using SQL statements running Operations Navigator Database-> Run SQL Scripts, you can click the View option from the menu bar. On the drop-down menu that appears, click Job Log to see your current job’s job log. Included in the gray header portion of the job log messages is the name of the job, for example, 139224/QUSER/QZDASOINIT. You can scan down to the earliest job log messages to confirm this job is actually running under the user profile you think it should be.  If you are not running the job that needs to be monitored, you can get the job name from the user of the job, if possible.  If you know the user profile running the SQL jobs, but do not know which job is the one you want to monitor, you can use the OS/400 Work with Object Locks (WRKOBJLCK) command to find the jobs running with that user profile. You may receive more jobs than you anticipated. Then, you may need to look in the job logs of each job for some SQL-like messages to determine which job or jobs to monitor, for example: WRKOBJLCK OBJ(QSYS/TEAM02) OBJTYPE(*USRPRF) MBR(*NONE) This command resulted in five jobs running with user profile TEAM02: one job name starting with QPADEV000L (5250 emulation), two jobs running Client Access Express database serving with job name starting with QZDASOINIT (not using SSL), and two jobs with the job name starting with QZRCSRVS (central server functions). We looked in the job logs for the two QZDASOINIT jobs and in one of them found the message: 148 rows fetched from cursor CRSR0002. This QZDASOINIT job was set by Operations Navigator Run SQL Scripts to Include debug messages in a job log.  You can use the Operations Navigator server jobs interface to find the job by selecting from Operations Navigator Network->Servers-> Client Access. Then right-click Database and select Server Jobs to view the Client Access Express servers (circled in Figure 7-50). Chapter 7. Database administration 221 Figure 7-50 Finding the database server job (Part 1 of 2) When you click Server Jobs, a window appears similar to the one shown in Figure 7-51. This display shows the database server jobs, QZDASOINIT (not using SSL), that are currently started and shows a current user ID for jobs currently doing active database functions. Figure 7-51 Finding the database server job (Part 2 of 2) This display illustrates an advantage of using the Operations Navigator “servers” support to find a job, compared to using OS/400 5250-display based commands such as the Work with Subsystem Jobs (WRKSBSJOB), Work with Active Jobs (WRKACTJOB), or Work with Object Locks (WRKOBJLCK) commands. 222 Advanced Functions and Administration on DB2 Universal Database for iSeries The Operations Navigator interface lists the jobs based on their function. With the OS/400 commands, you need to understand what OS/400 subsystem the server jobs run in and the job name that identifies the server function. In our example, you need to know that the QZDASOINIT jobs do the database serving (in this case ODBC-based) work. You also need to look into the job logs of each active job to find the actual user ID (profile) using the job. The OS/400 commands we discussed show equivalent jobs with the user ID as QUSER. QUSER is the user profile assigned by the system for pre-started Client Access database server jobs. The user profile name actually using the job is indicated in a job log message. The Operations Navigator interface examines the job log messages and shows the active user profile (TEAM02, in our example) if the pre-started job is currently in session with a signed on client. 7.6.1 Starting the SQL Performance Monitor To run an SQL Performance Monitor, you need to: 1. Define a new monitor. 2. Determine whether it’s going to be a Detailed collection or a Summary collection. 3. Specify the jobs to be monitored and the data to be collected for a Summary collection. The Detailed collection is discussed later in “Detailed SQL Performance Monitor example” on page 226. Summary SQL Performance Monitor example To start the SQL monitoring process, follow these steps: 1. Right-click SQL Performance Monitors, and select New as shown in Figure 7-52. Figure 7-52 SQL Performance Monitor (Part 1 of 5) 2. Select Summary. This brings up the New SQL Performance Monitor dialogue panel with three tabs: General, Monitored Jobs, and Data to Collect. Chapter 7. Database administration 223 The General tab is shown in Figure 7-53. Figure 7-53 Starting a Summary SQL Performance Monitor (Part 2 of 5) We entered the monitor name, the library name that is used to contain the collected data, and the amount of main storage allocated to the monitoring process. Do not click the OK button yet. Monitoring all jobs will start if you have not selected specific jobs under the Monitored Jobs tab. Monitoring all jobs is not recommended on a system with hundreds of active jobs because the monitoring process can degrade performance. 3. To specify which OS/400 jobs to manage, click the Monitor Jobs tab, which brings up the panel shown in Figure 7-54. Figure 7-54 Starting a Summary SQL Performance Monitor (Part 3 of 5) 2 1 224 Advanced Functions and Administration on DB2 Universal Database for iSeries 4. You can select to monitor all jobs or to select jobs from the Available jobs list pane (1 in Figure 7-54). After you select a job and click the Select button, the job information is entered into the Selected jobs list pane (2 in Figure 7-54). You remove selected jobs by selecting a job in the Selected jobs pane and clicking the Remove button. In this example, we scrolled down the active job names to display the ones shown in 1. We select to monitor only job QZDASOINIT/QUSER/023247 with PORTERL as the current user. We recommend that you monitor as few jobs as possible, because monitoring a large number of active jobs could impact normal productivity. 5. When you are finished selecting jobs, click the Data to Collect tab. This brings up the panel shown in Figure 7-55. Figure 7-55 Starting a Summary SQL Performance Monitor (Part 4 of 5) 6. This panel shows three sets of SQL monitor data collected during every monitor collection period. You can specifically include other sets of data or simply click the Select All button. You should select all, unless you understand the application implementation in detail so that you need to collect only specific information. When you are satisfied with your monitor collection specification, click the OK button to return to the original SQL Performance Monitor window, which shows the monitor status on the right pane in Figure 7-56. Chapter 7. Database administration 225 Figure 7-56 Starting a Summary SQL Performance Monitor (Part 5 of 5) In our example, we used Run SQL Scripts to run the SQL statement. This statement has a relatively complex WHERE clause as shown in Figure 7-57. Run SQL Scripts is discussed in more detail in 7.3, “Run SQL Scripts” on page 197. Figure 7-57 SQL Performance Monitor: SQL Statement which was monitored Operations Navigator Run SQL Scripts support uses JDBC support. In our example figure, the SQL statement was already run based on the evidence of its appearance within the Run History pane. The message Opening results viewer... indicates the results of the SQL select statement has already been displayed to the Operations Navigator user. 226 Advanced Functions and Administration on DB2 Universal Database for iSeries The SQL Performance Monitor can monitor all SQL work performed on OS/400. In addition to Operations Navigator Run SQL Scripts jobs, other users of OS/400 SQL support would include a client workstation Visual Basic program accessing the OS/400 via ODBC, a client workstation Java applet accessing the OS/400 via Java Database Connectivity (JDBC), a local iSeries program using embedded SQL in the RPG, COBOL, or C program, a local iSeries program using the SQL CLI (Call Level Interface) in RPG, COBOL, C, or Java. OS/400 also has a 5250 workstation-based SQL interface running under the Start SQL (STRSQL) command. Detailed SQL Performance Monitor example To start the SQL monitoring process, right-click SQL Performance Monitors, and select New. Select Detailed as shown in Figure 7-58. Figure 7-58 Starting a Detailed SQL Performance Monitor Name the monitor. Select a library for the collected data and proceed to select the jobs you want to monitor as previously documented in “Summary SQL Performance Monitor example” on page 222. 7.6.2 Reviewing the SQL Performance Monitor results The SQL Performance Monitor statistics are kept in main storage for fast recording, but need to be written to database files to use the Operations Navigator interface to review the results. You can have the statistics written to database files by either pausing or ending the monitor. Right-click the active SQL Performance Monitor. A pop-up window appears that lists the Pause, End, and other monitor actions as shown in Figure 7-59. Chapter 7. Database administration 227 Figure 7-59 Managing the SQL Performance Monitor The possible managing functions are:  Pause: This stops the current collection of statistics and writes the current statistics into several database files or tables that can be queried by selecting the Analyze Results action. The monitor remains ready to collect more statistics, but requires the Continue action to restart collection.  Continue: This restarts the collection of statistics for a monitor that is currently paused.  End: This stops and ends the monitor and writes the current collection of statistics to the database files or tables.  Analyze Results: This brings up a window with three tabs for selecting ways to look at (query) the collected statistics in the database files or tables: – Summary Results – Detailed Results – Composite View  List Explainable Statements: This opens a dialog listing the SQL statements for which the detailed SQL Performance Monitor has collected data and for which a Visual Explain diagram can be produced. See “Listing Explainable Statements” on page 231 for an example.  Properties: This brings up a window with three tabs that represent the original monitor definition: – General – Monitored Jobs – Saved Data An example of the Saved Data tab with the details for our monitor is shown in Figure 7-60. 228 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-60 SQL Performance Monitor: Properties The SQL Performance Monitor file name numeric suffix is updated when each monitor is started. Analyzing a summary of SQL Performance Monitor results OS/400 provides many pre-defined queries to view the recorded statistics. You can select these queries by checking the various query types on the Analyze Results panels. To begin viewing the results, right-click the paused or ended monitor. Select Analyze Results from the pop-up window. Here we analyze results for a Summary Monitor. Figure 7-61 shows the first results panel that groups queries according to three tabs:  Summary Results  Detailed Results  Composite View Chapter 7. Database administration 229 Figure 7-61 SQL Performance Monitor: Analyze Results - Summary results You can select individual queries or use the Select All button. After you select the queries you want to run, click the View Results button. You can even choose to modify the pre-defined queries and run the new queries by clicking the Modify Selected Queries button. An in-depth discussion of using the SQL Performance Monitor results to improve performance is beyond the scope of this redbook. However, we do show sample query results output. To obtain the query results shown in Figure 7-63, you must first select the Detailed Results tab on the Performance Monitor Results window shown in Figure 7-61. This brings up the Detailed Results panel shown in Figure 7-62. 230 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-62 SQL Performance Monitor: Detailed Results You can select individual detail query reports, select all queries, and even modify the provided queries. When you are finished selecting the queries you want, click the View Results button. The OS/400 query optimizer support includes an Index Advisor function. This support includes, when appropriate, a recommendation that a new index should yield improved performance. Columns that should be used in the index are listed. To view this detailed information, you must first select to view Arrival Sequence Information (1 in Figure 7-63). Click the View Results button to access a panel similar to the one shown in Figure 7-64. Figure 7-63 SQL Performance Monitor: Table Scan Information To view the information in Figure 7-63, we had to scroll to the right to find the columns Advised Index and Advised Index Keys (1). You can see that we compressed several columns in the results to make the index path information fit within the window (2). A lab exercise can be downloaded to your iSeries server on a PC workstation as listed in 7.1.1, “New in V5R1” on page 159. The “Self study lab” can be used to familiarize yourself with the power of the SQL Performance Monitor, as well as most of the Operations Navigator Database support. It also includes tips on tuning SQL performance. Analyzing a detailed SQL Performance Monitor Most of the discussion in “Analyzing a summary of SQL Performance Monitor results” on page 228 also applies to a detailed monitor. 2 1 Chapter 7. Database administration 231 Figure 7-64 shows the first results panel that groups queries according to three tabs:  Summary Results  Detailed Results  Extended Detailed Results Figure 7-64 Detailed SQL Performance Monitor: Analyze Results - Detailed Monitor For each of these options, you can run any of the pre-prepared queries or modify them for your own analysis. Although the items listed under the Detailed and Extended Detailed Results tabs have the same names and descriptions, the underlying queries are different. The Extended ones allow you a more complete understanding of the Optimizer choices. You can easily verify this by selecting the same item in both lists and clicking the Modify Selected Query button to have the SQL statement opened with the Run SQL Script center. Listing Explainable Statements The Explainable Statements for SQL Performance Monitor dialog lists the SQL statements for which an SQL Performance Monitor has collected detailed data and for which a Visual Explain graph can be produced. To access this function, click Operations Navigator->Database->SQL Performance Monitors. Then you see a list of the SQL Performance monitors that are currently on the system. Right-click a detailed SQL Performance Monitors collection and select List Explainable Statements, as shown in Figure 7-65. 232 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-65 List Explainable Statements When you select this item, you see the panel in Figure 7-66. The upper half of the panel displays the SQL statements monitored during the data collection session. Click to select the statement (1) you are interested in analyzing. The selected statement appears in the lower half of the dialog. Once the statement is in focus, it is possible to have it analyzed and explained. Click the Run Visual Explain button (2). Refer to Chapter 10, “Visual Explain” on page 301, for a detailed discussion on this tool. Figure 7-66 Using List Explainable Statements As you may have already noticed, the set of database analysis options and tools provided by Operations Navigator are well interconnected and meant to be used together in an iterative fashion. 2 1 Chapter 7. Database administration 233 7.6.3 Importing data collected with Database Monitor It is possible to import Database performance data collected with the more traditional green-screen interface tool, known as Database Monitor. You can start Database Monitor by using either the STRDBMON or STRPFRMON STRDBMON(*YES) CL commands on the iSeries server. While it is beyond the purpose of this redbook to discuss the traditional collection methods, you will certainly be pleased to discover that this data can be analyzed with the simpler and more intuitive instruments made available with Operations Navigator, rather than with the traditional approach. To import data collected with Database Monitor, select Database->SQL Performance Monitor->Import as shown in Figure 7-67. Figure 7-67 Importing data in SQL Performance Monitor (Part 1 of 2) A panel appears like the example in Figure 7-68. On this display, you give a name to new monitor and specify the library and file containing the collected data. Figure 7-68 Importing data in SQL Performance Monitor (Part 2 of 2) 234 Advanced Functions and Administration on DB2 Universal Database for iSeries Due to some new fields being added to the Database Monitor file in V5R1, SQL Performance Monitor only fully supports importing and analyzing database performance data collected in V5R1. Data collected from earlier releases will not have all of the information needed by Visual Explain. The system imports data from earlier releases and converts the data to a V5R1 format. However, it can only use default values for information that was not recorded at the earlier release, and full results cannot be guaranteed when using Visual Explain. Please refer to 7.6.2, “Reviewing the SQL Performance Monitor results” on page 226, for a discussion on how to analyze the collected data. Exit the Visual Explain window and the Explainable Statements window after you complete your analysis. Depending on your future needs for further investigation, you may either retain the performance data or delete it from the system at this time. To delete an SQL Performance Monitor collection, right-click the data collection you are interested in, and select Delete. Importing performance data for Query/400 Query/400 is not included in the list of queries that can be monitored by the SQL Performance Monitor, even though debug messages can be used with Query/400 queries. Because Query/400 queries are often blamed for poor performance, and sometimes even banned from execution during daylight hours, it was thought appropriate to provide guidance to bring Query/400 queries into the scope of Visual Explain. There is no direct Query/400 to SQL command. However, the STRQMQRY CL command will run a query definition (object type *QRYDFN) as an SQL statement, as long as the parameter ALWQRYDFN is set to either *YES or *ONLY. To use this SQL statement with Visual Explain, either start an SQL Performance Monitor for this job before you issue the STRQMQRY command or use the native STRDBMON CL command to collect detailed data for the job. See 7.6.1, “Starting the SQL Performance Monitor” on page 222, for further information. Alternatively, you can access the SQL statement by using the Current SQL for a Job option (obtained by right-clicking the database icon in Operations Navigator). Here we document the actions you need to follow to import the database performance data collected for Query/400 using the STRQMQRY command as a workaround. For documentation on the differences between STRQRY and STRQMQRY, see: http://publib.boulder.ibm.com/pubs/html/as400/v5r1/ic2924/info/index.htm Use STRQMQRY as a search word. In our example, we collect database performance data on a pre-existing Query/400 definition, named TESTQRY in library ITSCID41 using Database Monitor on the iSeries server. We are going to create an SQL Performance Monitor named QRYIMPORT. We perform the following steps: 1. Start the traditional green-screen tool to collect database performance data, Database Monitor, into a file named QAQQDBMN in library ITSCD41, using the STRDBMON CL command: STRDBMON OUTFILE(ITSCID41/QAQQDBMN) TYPE(*DETAIL) COMMENT('Collecting Data for Query/400 - to be Imported in SQL Monitor') See Figure 7-69 for a sample of this command. All traditional 5250 commands and activities documented here have been performed in the same working session. Had it been otherwise, the STRDBMON command should point to the correct job (STRDBMON JOB(nnnnnn/USER/JOBNAME)). Chapter 7. Database administration 235 Figure 7-69 Start Database Monitor 2. Now that we are recording all the database activities for our current job, we can run the previously prepared Query/400 definition using Query Management Query, as shown in Figure 7-70. Figure 7-70 Start Query Management Query Start Database Monitor (STRDBMON) Type choices, press Enter. File to receive output . . . . . > QAQQDBMN Name Library . . . . . . . . . . . > ITSCID41 Name, *LIBL, *CURLIB Output member options: Member to receive output . . . *FIRST Name, *FIRST Replace or add records . . . . *REPLACE *REPLACE, *ADD Job name . . . . . . . . . . . . * Name, *, *ALL User . . . . . . . . . . . . . Name Number . . . . . . . . . . . . 000000-999999 Type of records . . . . . . . . > *DETAIL *SUMMARY, *DETAIL Force record write . . . . . . . *CALC 0-32767, *CALC Comment . . . . . . . . . . . . > Collecting Data for Query?400 - to be Imported in SQL Monitor Bottom F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys Start Query Management Query (STRQMQRY) Type choices, press Enter. Query management query . . . . . > TESTQRY Name Library . . . . . . . . . . . > ITSCID41 Name, *LIBL, *CURLIB Output . . . . . . . . . . . . . * *, *PRINT, *OUTFILE Query management report form . . *SYSDFT Name, *SYSDFT, *QMQRY Library . . . . . . . . . . . Name, *LIBL, *CURLIB Additional Parameters Relational database . . . . . . *NONE Connection Method . . . . . . . *DUW *DUW, *RUW User . . . . . . . . . . . . . . *CURRENT Name, *CURRENT Password . . . . . . . . . . . . Character value, *NONE Naming convention . . . . . . . *SYS *SYS, *SAA Allow information from QRYDFN . > *YES *NO, *YES, *ONLY More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys 236 Advanced Functions and Administration on DB2 Universal Database for iSeries Use the STRQMQRYCL command with the ALLQRYDFN parameter set to *YES to enable it to exploit the pre-existing query definition: STRQMQRY QMQRY(ITSCID41/TESTQRY) ALWQRYDFN(*YES) 3. After the query has finished executing, you notice message QWM2704 posted into your job log, as shown in Figure 7-71. This is an informational message documenting that no query management object was found. However, a query definition having the same name existed and it was used, as allowed by the ALLQRYDFN(*YES) parameter. Figure 7-71 Message QWM2704 4. At this point, if you are finished collecting data, you can end the Database Monitor by using the CL command: ENDDBMON 5. Now you can use the SQL Performance Monitor tool in Operations Navigator to import and analyze the data collected. To do so, select Database->SQL Performance Monitor. Right-click SQL Performance Monitor and select Import. You see the dialog shown in Figure 7-72. Additional Message Information Message ID . . . . . . : QWM2704 Severity . . . . . . . : 00 Message type . . . . . : Diagnostic Date sent . . . . . . : 10/18/00 Time sent . . . . . . : 16:14:21 Message . . . . : STRQMQRY command completed using derived information. Cause . . . . . : Information was derived from a Query/400 query definition and used instead of at least one query management object that could not be found. The Query/400 query definition was found using the names specified for locating the query management object. Recovery . . . : Refer to the job log for the name and object type specific message for each instance in which information had to be derived. Bottom Press Enter to continue. F3=Exit F6=Print F9=Display message details F10=Display messages in job log F12=Cancel F21=Select assistance level Chapter 7. Database administration 237 Figure 7-72 Importing data in SQL Performance Monitor Here specify a name for the new Monitor you are creating and the file and library containing the previously collected data. 6. The new monitor name is added to the list shown at the SQL Performance Monitor item. Right-click it and select List Explainable Statements, as shown in Figure 7-73. Figure 7-73 SQL Performance Monitor - List Explainable Statement After you select this option, you are presented with the List Explainable Statements dialog (Figure 7-74). On this display, you can see the actual SQL statement generated by Query Manager to resolve the original Query/400 request. 238 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 7-74 List Explainable Statements dialog From here, you can link into Visual Explain to analyze the database behavior during the execution of this query. For more information on this subject, refer to Chapter 10, “Visual Explain” on page 301. © Copyright IBM Corp. 1994, 1997, 2000, 2001 239 Chapter 8. Database Navigator This chapter introduces you to the DB2 Universal Database for iSeries Database Navigator feature and its capabilities. It covers the following topics:  Finding Database Navigator  Finding database relationships prior to V5R1M0  Database Navigator maps  Database Navigator map interface  Objects to Display window  Database Navigator map display  Available options on each active icon on a map  Creating a Database Navigator map  Adding new objects to a map  Changing the objects to include in a map  Changing object placement and arranging object in a map  Creating a user-defined relationship 8 240 Advanced Functions and Administration on DB2 Universal Database for iSeries 8.1 Introduction The launch of DB2 Universal Database for iSeries Database Navigator, which is part of Operations Navigator in V5R1M0 Client Access Express, allows database administrators to map the complex relationships between database objects. The database component of Operations Navigator at V5R1M0 provides additional graphical interfaces for new functions that include:  The ability to create and manage tables, views, indexes, constraints, journals, journal receivers, and system (external) and SQL Triggers  The ability to graphically view the relationships between the various parts of an existing DB2 UDB database and save and update these visual maps with the push of a button  The ability to reverse engineer an existing database so that the database administrator can port the database to other iSeries servers as well as other platforms The relationships that you see on the Database Navigator map are the relationships between:  Tables (for example, referential integrity constraints)  Any indexes over the tables  Any constraints, such as primary, foreign, unique, and check  Any views over the tables  Any aliases for the tables, etc. 8.1.1 System requirements and planning Be sure you have an iSeries server with OS/400 V5R1M0, or higher, with:  5722-SS1: Option 12 - Host Servers  5722-TC1: TCP/IP Connectivity Utilities  5722-XE1: Client Access Express V5R1M0 8.2 Finding Database Navigator Database Navigator resides under the Database icon of Operations Navigator. Open the Operations Navigator window and click the desired iSeries server. Click the (+) sign next to the Database icon. Now, click the Database Navigator icon. The Database Navigator maps that are available appear. Database Navigator is part of the Database icon within Operations Navigator. There are three functions beneath the Database icon (Figure 8-1):  Libraries  Database Navigator  SQL Performance Monitors Note: Database Navigator is not intended to be a data modeling tool like some existing products in the industry. Chapter 8. Database Navigator 241 Figure 8-1 Database options within Operations Navigator The new Database Navigator feature allows you to perform many tasks, including:  Create a table  Create a view  Create an alias  Create a journal  Create an index  Create a map of your database  Create new SQL objects to be displayed in the map  View the properties of a map  View the properties of an object within a map  Generate SQL for an object within a map  Generate SQL for all objects within a map  Generate SQL for selected objects within a map  Generate SQL for visible objects in a map  Expand a table in a map  Collapse a table in a map  Add a referential constraint  Add a check constraint  Add user defined relationships to a map  Add a key constraint An option also exists for removing and adding objects to this relationship, such as journals and receivers. These are not selected as a default for the map because they may cause the map to be very complicated. To add these extra objects, click the Options menu as shown in Figure 8-2. 242 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-2 Viewing or changing the user preferences for the Database Navigator map After you select the user preferences option, you can see the default user preferences for creating a Database Navigator map. Figure 8-3 shows you the various objects that may be included on the map. From the Database Navigator map, you can directly affect the relationships on the database by adding or removing indexes, files, views, etc. Figure 8-3 Database Navigator user preferences 8.3 Finding database relationships prior to V5R1M0 To see the benefits of Database Navigator, you must find the relationship between database objects on an iSeries server that is not at Client Access Express V5R1M0. You must use several commands to achieve the same results that you get with Database Navigator. Some of the commands that are needed are:  DSPDBR FILE(SAMPLEDB16/ACT) OUTPUT(*PRINT) This command (Figure 8-4) shows the indexes, views, and constraints related to the selected table.  DSPFD FILE(SAMPLEDB16/ACT) TYPE(*CST) OUTPUT(*PRINT) This command (Figure 8-5) shows the details of the constraints built over the selected table. Chapter 8. Database Navigator 243  DSPFD FILE(SAMPLEDB16/ACT) TYPE(*ACCPTH) OUTPUT(*PRINT) This command (Figure 8-6) shows you the access path that is built over the selected table. You also need to use the WRKJRNA command to determine which files are journaled to other journals. Although the DSPFD command also shows this, you cannot obtain an overview without using these commands. It is possible to build a relationship map. However, it takes time and a great deal of effort. It is also very difficult for a new database administrator to envision the layout of an existing or new database and the effect of removing an index or constraint on other files. This can result in unnecessary resources allocated to files, indexes, and constraints that may not be needed. This is because the referential integrity map is only as good as the last time the database administrator actually checked the authenticity of the map that was previously created. The AFP viewer screens show the commands mentioned in the previous list (Figure 8-4 through Figure 8-6). Figure 8-4 Display Database Relations display Figure 8-5 Display File Description display showing constraints on a particular file 244 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-6 Display File Description display showing access paths The entire process for creating a physical or mental picture of which table is related to which index is very difficult to administer. The practical difficulties of keeping this picture up-to-date requires time and effort on the part of the database administrator. It is also difficult to explain the entire picture when doing training for new staff, and it requires valuable time and effort on the part of the database administrator. The process is simplified with the new Database Navigator feature of Client Access Express V5R1M0. 8.4 Database Navigator maps Database Navigator enables you to visually depict the relationships of database objects on your iSeries server. The visual depiction you create for your database is called a Database Navigator map. In essence, the Database Navigator map is a snapshot of your database and the relationships that exist between all of the objects in the map. Click the Database Navigator icon to bring up the list of Database Navigator maps that are available in the system. The maps appear in the right-hand side of the Operations Navigator window as shown in Figure 8-7. Chapter 8. Database Navigator 245 Figure 8-7 Database Navigator maps Double-click the database map you want to view. The Database Navigator map window with the selected map appears as shown in Figure 8-8. Figure 8-8 Database Navigator map Be aware that the map shown is the Database Navigator map at the time that it was saved. This means that things may have changed on the system since the map was created and saved. To view an up-to-date picture of the database, refresh the map by clicking the View menu and selecting the Refresh option as shown in Figure 8-9. 246 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-9 Refreshing a map The Database Navigator maps are stored on the iSeries server. Only one person at a time can work on the map to ensure integrity. The maps are locked when they are being used. Because they are stored on the iSeries server, you must have a connection to the system to be able to open a map. You can save multiple maps of the same database reflecting the database design at certain points in time. For this, you use different names. Whenever you want to compare how the database design has changed, you open and print the appropriate maps. Using the printouts, you can compare how the database design has changed over time. Note: For a complete explanation of the icons, refer to 8.8, “The Database Navigator map icons” on page 269. 8.5 The Database Navigator map interface As stated previously, the Database Navigator map provides a graphical interface that allows the database administrator to see the layout of the various objects in the database. One of the new functions added for V5R1M0 is the task pad. This is located in the lower part of the Operations Navigator window. If you click on the various higher level options, such as Security, Users and Groups, Database, etc., the task pad changes accordingly to present you with the options that are available when the database functions is selected as shown in Figure 8-10. The options available on the Database task pad are:  Select libraries to display  Create new summary SQL performance monitor  Create new detailed SQL performance monitor  Map your database  Run an SQL script Chapter 8. Database Navigator 247 Figure 8-10 Database task pad options Click the option in the task pad to create a map of your database. The window shown in Figure 8-11 appears. Figure 8-11 Default map display The primary workspace for Database Navigator is a window that is divided into several main areas as shown in Figure 8-12. These areas allow you to find the objects to include in a map, show and hide items in a map, view the map, and check the status of changes pending for a map. The following list describes the main areas of the Database Navigator window:  Locator pane The locator pane, on the left side of the Database Navigator window, is used to find the objects that you want to include in your new map, or to locate objects that are part of an open map. The upper Locator Pane is a search facility that can be used to specify the Name, Type, and Library of the objects that you want to include in the map. The results of the search are displayed in the lower Locator Pane under the Library Tree and Library 248 Advanced Functions and Administration on DB2 Universal Database for iSeries Table tabs. When the results are displayed under these tabs, you can add objects to the map by right-clicking an object and selecting Add to Map or double-clicking the object name. Then, when the map is created, you can see a list of the objects in the map by clicking the Objects In Map tab. The Locator Pane is divided in two parts: – The upper locator window This window allows you to search for database objects on the iSeries server. When an object is found, it is placed in the object window: • On the search criteria, you can specify single objects or search for generic names using the * (for example, EMPLE*). • You can specify all object types or indexes, tables, and views. • You can specify one library from your library list or all libraries to search on. – The lower locator This window has three parts: • The library tree: This can either show individual libraries, libraries in your list, or all libraries on the system. • The library table: This shows the tables, indexes, or views of the libraries in the library tree. • Objects in map: This shows all of the objects in the map, whether they are hidden or not. Within this display, you can select or deselect objects to be placed in the map. Figure 8-12 Three main windows in the Navigator map display Note: Any changes that are made using the search criteria require that you click the Search button to change the library tree or the library table displays. Main Map Window Upper Locator Lower Locator Chapter 8. Database Navigator 249  Map pane The map pane, on the right side of the Database Navigator window, graphically displays the database objects and their relationships. In the Map pane, you can: – Add tables and views that exist on the system, but were not originally included in the current instance of the map – Remove objects from the map – Change object placement – Zoom in or out on an object – Make changes to objects in the map – Generate the SQL for all objects in the map These windows are the main interface that allow you to change what you see in the main map window, search for other objects to add to the map, and move the objects around within the map to make it easy to read.  Object status bar: This part of the window consists of three parts (Figure 8-13): – Object Status Bar: This displays the number of objects that are visible in the Database Navigator map and how many are eligible to be added to the map. – Action Status Bar: This provides a clear description of the actions taken that affect the map and any modifications that are pending. – Modification Status Bar: This indicates whether a modification has been made or is pending. Figure 8-13 The status bar The Database Navigator map display also supports the following menu options:  File menu: You can select a number of options, including: – New: Allows you to create a new map – Open: Allows you to open a previously saved map – Close: This closes the currently open map – Save: Allows you to save the current map with which you are working – Save as: Allows you to save the current map you are working with and change the name and location if the map has previously been saved – Print: This option allows you to print to a previously defined printer – Exit: This option closes the map of your database screen Note: If changes are made to the map, or if this is a new map, you are prompted as to whether you want to save the map. Object Status Action Status Modification Status 250 Advanced Functions and Administration on DB2 Universal Database for iSeries  View menu: The following options are available: – Zoom • In: Allows you to zoom in on the map • Out: Allows you to zoom out on the map • Fit to Window: Allows you to fit the map to the current window size • To Selected Objects: Positions the window to the object that has been selected – Refresh: This updates the database map with any changes that are made. – Object Spacing: This allows you to increase or decrease the vertical and horizontal spacings of the objects in the map. – Show Overview Window: This brings up a window (Figure 8-14) that allows you to see an overview of the map currently open. This overview allows you to position the main screen to any part of the map. This is particularly useful on very large or complicated maps. – Show objects of type: This allows you to add objects to the map, such as aliases, journals, etc. – Arrange: This allows you to change the map back to the original settings. Figure 8-14 Overview windows showing how moving the overview box changes the main map display window  Options menu: The following option are available: – User Preferences: This allows you to change the objects that appear on the map as it is created (Figure 8-15). Chapter 8. Database Navigator 251 Figure 8-15 User Preferences display – Change List of Libraries: This allows you to change the libraries that are displayed (Figure 8-16). Figure 8-16 Change list of libraries display If a new library is typed on the Enter Libraries box, instead of selecting from a list, the system ensures that the library exists before allowing the object to be added to your list.  Map menu: The Generate SQL option appears with the following sub-options: – For all objects – Selected objects – Visible objects For each of these options, the system creates the SQL script used to generate the objects, and it prompts the Run SQL Scripts window to appear as shown in Figure 8-17. 252 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-17 Generate SQL window The Run SQL Scripts window allows you to see the SQL statement that was used to create the object and it allows you to take individual tables, whole databases, or entire maps of objects to other iSeries servers or SQL platforms. The Create option includes the following sub-options:  Journal: This allows you to create a new journal.  Table: This allows you to create a new table.  View: This allows you to create a new view.  User Defined Relationship: This allows you to create a user-defined relationship. This helps by allowing the database administrator to add relationships of important tables, of the database, and so on. This function is likely used to illustrate a referential integrity constraint that is implemented on the application logic and is not defined in the database. This can also be used to illustrate relationships that are not physical in the map for debug or education purposes. A tool bar exists that has a lot of the functionality previously mentioned. It includes the following features:  Show or hide Indexes  Show or hide views  Show or hide journals  Show or hide journal receivers  Show or hide primary key constraints  Show or hide check constraints  Show or hide unique key constraints  Show or hide table aliases  Show or hide view aliases Note: If the objects are not available to hide or view, the button is grayed out. Chapter 8. Database Navigator 253 8.5.1 Objects to Display window Within the Objects to Display window, only one option is available – the Find in Map option. This option allows you to find a specific object in the map. When this option is selected, the chosen object appears in the selected map window. 8.5.2 Database Navigator map display The Database Navigator map main display is another interface for managing and changing your database using Operations Navigator. Each object on the Database Navigator map is active, and various options are available. From the main display, you can add objects to a map, create new objects, etc., as previously described. This section explains the various functions available to you from this display. Right-click the main window to view the following menus (Figure 8-18):  Create: You can create journal, tables, views, and user-defined relationships by choosing this option.  Zoom: You can zoom in or out and make the map fit the window by selecting this option.  Generate SQL: You can generate the SQL for all objects or only the visible options by selecting this option.  Remove all line bends: This removes all bends in the database map joining arrows.  Arrange: Returns the objects within the map to there position at creation even if the map was saved previously.  Properties: This shows you a properties display of the map itself. Figure 8-18 Options that are available when you right-click the map As previously stated, each object type is active. By right-clicking the objects, you can access several different options. Note: A map is saved on the iSeries server as an object type of *FILE. 254 Advanced Functions and Administration on DB2 Universal Database for iSeries Flyover Because each object is active, there is a new function that allows you to view a brief description of an object within the map simply by placing the cursor over the object. This is called a flyover. Depending on the type of object, different information types appear. The basic display for each object shows the object name, the system name on which the object resides, the library, and the type of object as shown in Figure 8-19. Figure 8-19 Example flyover display After you refresh the display, a window, like the example in Figure 8-20, appears while the refresh runs. Figure 8-20 Refresh on database in progress After the map is built or refreshed, you can manipulate the objects however you want. From within the map display, you can actually move the icons around to suit your requirements. Chapter 8. Database Navigator 255 8.6 Available options on each active icon on a map This section discusses the options that are available to you from within the map display. These options are available by right-clicking each of the different objects in the map. 8.6.1 Table options Figure 8-21 shows the various options available to you when you are using the active icon for a table within a Database Navigator map. All objects on a map are active, and they enable you to manipulate the object without leaving the map. Figure 8-21 Flyover display of a table within a Database Navigator map Right-click a table within the map. A window appears as shown in Figure 8-22. Figure 8-22 Right-clicking a table within a Database Navigator map The options that appear include:  Open: This allows you to open the file for update.  Quick view: This shows you the file and its contents (read only). 256 Advanced Functions and Administration on DB2 Universal Database for iSeries  Description: From within this option, there are six tabs: – General: This shows the size of the object, the current number of rows, the number of deleted rows, and whether the table reuses deleted records. – Allocation: This shows the settings for the maximum number of rows, the initial number of rows, the increment of the number of rows, the maximum number of increments, and other options. – Access Path: This shows the current size of the access path, the maximum size, the maximum key length, whether the access path is valid or shared, whether it is journaled, what the maintenance and recovery of the access path is set to, and other options (Figure 8-23). Figure 8-23 Access Path display – Usage: This shows you the creation date of the table, the last used date, the last changed date, and other details of the table. – Activity: This shows the latest activity on the table since the last machine restart. – Details: This shows the creation date of the table, the maximum row length, and more.  Journaling: This specifies whether journaling is on.  Locked Rows: This shows any rows that are locked on the table.  Create Alias: This allows you to create an alias for the table.  Reorganize: This allows you to reorganize the file by compressing deleted records (by table key or by a selected index).  Permissions: This allows you to set security for a table.  Expand (new function): This shows additional details of the table, such as the columns and indexes built over the table.  Collapse (new function): This returns the display to the default setting for the table.  Generate SQL (new function): This creates an SQL script window (Figure 8-24) that allows you to recreate the table or multiple objects depending on the option selected from the Generate SQL screen. The Generate SQL function is new for V5R1M0 and is available Chapter 8. Database Navigator 257 for individual objects or entire databases. This option is available through the Database Navigator map and through the library display within the database option in Operations Navigator. This option is discussed later in more detail. Figure 8-24 Generate SQL Script window  Remove From Map (new function): This removes a particular view from the map. If the object is not included in the map, you see the Add to map function highlighted.  Delete: This allows you to delete a particular table.  Rename: This allows you to rename the table.  Properties: This shows you a display of the properties of a table. 8.6.2 Index options Right-click an index to access the options shown in Figure 8-25. 258 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-25 Right-clicking an index The primary options are:  Description: In this option, there are three views: – Access path: See Figure 8-23 for more details on this screen – Usage: This shows you the creation date of the index, the last used date, the last changed date, and other details of the index. – Details: This shows the creation date of the index, the maximum row length, and more.  Permissions: This allows you to set security for the object. 8.6.3 Constraint options If you right-click any of the constraints on the map, the following options appear:  Generate SQL (new function): This creates an SQL script window (Figure 8-24).  Remove from map (new function): This removes a particular constraint from the map. If the object is not included in the map, the Add to map function appears highlighted.  Properties: This shows you the properties of the table over which the constraint is defined as shown in Figure 8-26. Chapter 8. Database Navigator 259 Figure 8-26 File properties window showing constraints 8.6.4 View options Right-click any view on the map to see the following options:  Quick View: This shows you the view contents (read only).  Description: – Usage: This shows you the creation date of the view, the last used date, the last changed date, and other view details. – Details: This shows the creation date of the view, the maximum row length, and additional details.  Create Alias: This allows you to create an alias for the view.  Permissions: This allows you to set security for the view.  Generate SQL (new function): This creates an SQL script window that allows you to recreate the table or multiple objects depending on the option selected from the generate SQL screen. The Generate SQL function is new for V5R1M0 and is available for individual objects or entire databases. This option is available through the Database Navigator map and also through the library display within the database option in Operations Navigator.  Remove (new function): This removes a particular view from the map. If the object is not included in the map, the Add to map function appears highlighted.  Properties: This shows you the properties of the view. If it is an SQL view, it shows the SQL statement used to create the view. If it is a logical file, a message appears stating that it was not created in SQL and, therefore, it cannot be shown.  Hide (new function): This allows you to remove the view from the map only. 260 Advanced Functions and Administration on DB2 Universal Database for iSeries 8.6.5 Journal options If you right-click a journal, the options shown in Figure 8-27 appear. Figure 8-27 Right-clicking a journal The various options include:  Start or End Table Journaling: This allows you to end or start journaling on any table on the system to the selected journal.  Swap receivers: This allows you to perform the equivalent of a CHGJRN *GEN from a normal green-screen command.  Permissions: This allows you to set security for the journal.  Delete: This allows you to delete a particular journal.  Remove from map (new function): This allows you to remove a particular journal from the map. If the object is not included in the map, the Add to map function appears highlighted.  Hide (new function): This allows you to remove the journal from the map only.  Properties: This shows you the properties of the journal. 8.6.6 Journal receiver options The various Journal receiver options include:  Permissions: This allows you to set security for the journal receiver.  Delete: This allows you to delete a particular journal receiver.  Remove from map (new function): This allows you to remove a particular journal receiver from the map. If the object is not included in the map, the Add to map function appears highlighted.  Hide (new function): This allows you to remove the journal receiver from the map only.  Properties: This shows you the properties of the journal receiver. Chapter 8. Database Navigator 261 8.7 Creating a Database Navigator map The visual depiction that you create of your database is called a Database Navigator map. To create a Database Navigator map, you need to follow these steps: 1. In the Operations Navigator window, expand your server Database. 2. Right-click Database Navigator and select New from the pull-down menu to create your Map as shown in Figure 8-28. Figure 8-28 Database Navigator option 3. The Operations Navigator library list appears in the left side of the Database navigator window. Double-click the SAMPLEDB04 library to expand the objects. 4. Double-click Tables in the Locator Pane to expand all the tables in a database. 5. Double-click the EMPLOYEE table on the lower Locator Pane to start building a map. This table is added to the map and all related objects, as shown in Figure 8-29. 262 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-29 Selecting a database to build a map 6. The map is built from the cross reference files (XREF) on the iSeries server. The relationship and statistics are based from the table that you selected to generate a map as show in Figure 8-30. Figure 8-30 Building a Database Navigator map 7. Click the minus (-) sign next to the SAMPLEDB04 database object to collapse the tree view. Chapter 8. Database Navigator 263 8. Use the vertical and horizontal scroll bars to navigate the map on the Database Navigator window as shown in Figure 8-31. Figure 8-31 Database Navigator map 9. You can save this map by selecting File-> Exit from. Then, if changes are pending, select Yes on the Save Changes To dialog. This map can be reopened at a later time. Once you create the map of your database, you can:  Add new objects to a map  Change the objects to include in a map  Create a user-defined relationship 8.7.1 Adding new objects to a map With Database Navigator, you can create new SQL objects to add to your map. Among the objects that can be created are:  Tables  Journals  Views Note: You can also click the Map your database task on the task pad at the bottom of the Operations Navigator window to create a map. 264 Advanced Functions and Administration on DB2 Universal Database for iSeries To create new SQL objects to be displayed in a map, follow these steps: 1. Open a Database Navigator map. 2. Click the View menu. From the pull-down menu, select Show Objects of Type -> Views to include all Views in the map. The Object Status Bar that was updated with the new objects included in the map appears. Figure 8-32 Adding Views objects in the map 3. Use the vertical and horizontal scroll bars to navigate to the top of the map. 8.7.2 Changing the objects to include in a map By default, Database Navigator searches for and includes all objects in your map. To limit the number of objects that are searched for, you can change the user preferences. To change which objects to include in the map, follow these steps: 1. Open a Database Navigator map. 2. From the Options menu, select User Preferences. 3. On the User Preferences dialog, in the When adding an object to the map find these related objects group box, select the objects you want to include, or deselect the objects you do not want to include. 4. Click OK. 5. If you want to refresh the map with the new preferences, click Yes in the Information box. Important: You can change the zoom level of the Database Navigator map to manage how much of the map you can see in the map pane on the Database Navigator Window. Chapter 8. Database Navigator 265 8.7.3 Changing object placement and arranging object in a map When you have a map, it is possible to arrange and move objects in the map. You also learn how to remove the bends that appear on the relationship lines after the objects is moved to the new location. 1. Double-click the EMPLOYEE table from the list of tables to find this table in the map. 2. Drag-and-drop the EMPLOYEE table to the left as shown in Figure 8-33. 3. Right-click every relationship line and select Remove Bends to remove all bends. Figure 8-33 Changing object placement 4. Right-click in a free space in the map pane in the Database Navigator window. The Arrange function appears. Important: When you use the arrange option, it removes any customized object position or relationship line that you have created. The Arrange option puts the map back in a Default state. 266 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-34 Arrange objects in the map 5. Select Arrange to minimize the line crossing the map. 8.7.4 Creating a user-defined relationship As explained previously, when you have relationships that are defined by your programs, you can create a user-defined relationship in Database Navigator so that your relationship is displayed in the map. An example of this may be creating a user-defined relationship to remind programmers of an important join between two tables. To add a user-defined relationship to your map, complete these steps: 1. Open a Database Navigator map. 2. Right-click in a free space on the map pane in the Database Navigator window. Select the Create function as shown in Figure 8-35. 3. Select Create, and then select User-Defined Relationship to create the new object (UDR). Chapter 8. Database Navigator 267 Figure 8-35 Selecting the function to create a user-defined relationship 4. Specify a name and a description for the user-defined relationship. Unlike some Operations Navigator functions where the description is optional, it is important to provide a meaningful description for your user-defined relationship because it is the only way for you to indicate what the user-defined relationship represents as shown in Figure 8-36. 5. Select the objects that you want to include in the relationship by selecting from the list of objects (Figure 8-36) 6. Choose the shape and color you want for the object (Figure 8-36). 268 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 8-36 Creating a user-defined relationship 7. Click OK to create the user-defined relationship. The map should show a user-defined relationship (UDR) as shown in Figure 8-37. Figure 8-37 Flyover view of a user-defined relationship Chapter 8. Database Navigator 269 8.8 The Database Navigator map icons The icons that you may encounter on the Database Navigator map are shown in Table 8-1. Table 8-1 Database Navigator map icons The Library icon is used in the Database Navigator map display to show a library. The Table icon is used in the Database Navigator map to show a table. The Table Alias icon is used in the Database Navigator map to show table aliases. It also is used as a toolbar icon for adding or removing a table alias from the Database Navigator map. The Index icon is used in the Database Navigator map to show an index. The Journal icon is used in the Database Navigator map to show a journal. It is also used as a toolbar icon for adding or removing a journal from the Database Navigator map. The Journal Receiver icon is used in the Database Navigator map to show a journal receiver. It is also used as a toolbar icon for adding or removing a journal receiver from the Database Navigator map. The Primary Key Constraint icon is used in the Database Navigator map to show a primary key constraint. It is also used as a toolbar icon for adding or removing a primary key constraint from the Database Navigator map. The Check Key Constraint icon is used in the Database Navigator map to show a check key constraint. It is also used as a toolbar icon for adding or removing a check key constraint from the Database Navigator map. The Unique Constraint icon is used in the Database Navigator map to show a unique constraint. It is also used as a toolbar icon for adding or removing a unique constraint from the Database Navigator map. The Foreign Key Constraint icon is used in the Database Navigator map to show a foreign key constraint. The View icon is used in the Database Navigator map to show a view. It is also used as a toolbar icon for adding or removing a view from the Database Navigator map. 270 Advanced Functions and Administration on DB2 Universal Database for iSeries The Show/Hide Index icon is used on the toolbar to add or remove an index from the Database Navigator map. The Show/Hide Alias icon is used on the toolbar to add or remove an alias from the Database Navigator map. Left-click this icon to set the zoom on the map so that it fits the current window size. Left-click this icon to increase the level of zoom on the map at the position of the cursor. Left-click this icon to decrease the level of zoom on the map at the position of the cursor. Left-click this icon to invoke the Overview window function. This allows you to position your Database Navigator map panel to any part of a map. Left-click this icon to decrease the horizontal level of spacing between objects on the map. Left-click this icon to increase the horizontal level of spacing between objects on the map. Left-click this icon to decrease the vertical level of spacing between objects on the map. Left-click this icon to increase the vertical level of spacing between objects on the map. © Copyright IBM Corp. 1994, 1997, 2000, 2001 271 Chapter 9. Reverse engineering and Generate SQL Reverse engineering is one of the major changes that have been included in V5R1M0. This function allows you to create SQL for a given schema, table, index, view, etc., and all related objects to them if that option is selected. This enables database administrators to recreate, create duplicates, and port to other iSeries servers entire databases or particular parts of a database. This chapter includes:  What Generate SQL is  Reverse engineering an existing database  Generating SQL DDL statements from a DDS created database 9 272 Advanced Functions and Administration on DB2 Universal Database for iSeries 9.1 Introduction The new Generate SQL function is often referred to as “reverse engineering for Operations Navigator” because it provides a GUI interface that allows you to reverse engineer several types of database objects. The results are SQL create statements (often referred as DDL statements). The Generate SQL function of Operations Navigator allows you to reconstruct SQL statements used to create existing database objects. With this function, you can reverse engineer database objects and then have the option to display the resulting SQL in the Run SQL Scripts window or saving the output to a file. Using the existing Run SQL Scripts functions, you can then edit, run, and save the SQL statement to a file on the PC. The new Generate SQL Database Objects support the following objects:  Aliases  Distinct types  Functions  Indexes  Procedures  Schemas (collections) and libraries  Tables and physical files  Views and logical files 9.1.1 System requirements and planning Before you Generate SQL, be sure the following prerequisites are available:  5722-SS1: Option 12 - Host Servers  5722-TC1: TCP/IP Connectivity Utilities  5722-XE1: Client Access Express, V5R1M0, with the latest Service Pack applied 9.1.2 Generate SQL Reverse engineering (Generate SQL) allows you, through the Database Navigator map and the Libraries display of Operations Navigator, to re-engineer an SQL database or an iSeries database that were not created using SQL. One of the uses of Generate SQL is to generate the SQL statements of tables, views, indexes, and constraints that were created using the Operations Navigator interface. For example, when you create a table using Operations Navigator, there is no method for saving the SQL statement that is behind the interface. In this case, Generate SQL provides a way to reverse engineer this object and obtain the SQL statement. The Generate SQL function of Database Navigator also creates the SQL statements of databases created by DDS (physical and logical files). You must be aware that keyed-logical files are converted to SQL views. When the Generate SQL process creates the Run SQL script for the selected object, it either marks any problem objects with SQL messages or it does not create the SQL for the object if it is not supported. You can create a Run SQL Script from object context or from schema context. Chapter 9. Reverse engineering and Generate SQL 273 The object context can be invoked from either the Database Navigator map or the Operations Navigator Library display. To do this, right-click the object and select the Generate SQL option. There is a difference between what appears when using the two methods. If the Generate the SQL option is selected from the Library display, the information shown in Figure 9-1 appears. Figure 9-1 Operations Navigator Generate SQL display The display shown in Figure 9-1 allows you to add or remove objects that will be re-engineered. This method allows you to change the objects that are selected and the standard by which they are generated, the format of the Run SQL script (Figure 9-2), and the options used to create the SQL script (Figure 9-3). 274 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-2 Generate SQL format options Figure 9-3 Generate SQL options The options that you can define include:  Standards options: This allows you to select which standards option you want for the generated SQL. The option that you choose affects the syntax of the generated SQL and ultimately how the Generate SQL runs. You may edit this value using the following sub-options: – ANSI/ISO: Select this option to allow the generation of SQL that can be executed on other ANSI/ISO SQL standard compliant databases. Chapter 9. Reverse engineering and Generate SQL 275 – DB2 UDB family: Select this option to allow the generation of SQL for use on other DB2 family platforms. – DB2 UDB with iSeries extensions: Select this option to allow the generation of SQL for use on other iSeries servers. Note: As a general guideline, if you want to generate SQL that is run on other DB2 platforms, select DB2 UDB. In addition, if the platform is another iSeries server, choose to include iSeries extensions. The choice that you make for the standard can affect subsequent formatting choices.  Generate labels: Select this option to include SQL labels and comments to be inserted into the generated SQL.  Format statements for readability: Select this option to format the generated SQL statements with end-of-line characters, tab characters, and spaces.  Include informational message: Select this option to include informational messages in your generated SQL. You should always include informational messages whenever you generate SQL for an object created using Data Description Specification (DDS). DDS is used to describe data attributes in file descriptions that are external to the application program that processes the data. You can then determine if you need to make changes to the generated SQL for it to run correctly. Once you make all the necessary changes, you may want to generate the SQL without the informational messages. Note: If the object for which you are generating SQL was originally created using SQL, there should not be any informational messages.  Include drop statements: Select this option to include drop statements for the objects for which you are generating SQL. The drop statements are inserted before the first Create SQL statement. This allows you to drop the object and then recreate it. Click the Generate button to prompt the system to generate the SQL and bring up the Run SQL script window (Figure 9-4). Figure 9-4 Generate SQL Run SQL Scripts window 276 Advanced Functions and Administration on DB2 Universal Database for iSeries One of the major advantages of the Generate SQL function is that the SQL can be ported to other iSeries servers and even to other platforms supporting SQL. This applies particularly to CASE tools that can use the Run SQL Script as input to recreate the database on other platforms. 9.2 Generating SQL from the library in Operations Navigator With Generate SQL, there is an option from your library in the Operations Navigator window to generate the SQL DDL statement for some objects. To generate this statement, follow these steps: 1. Start Operations Navigator. Click the iSeries server that you want to access (Figure 9-5). Once you have entered your user ID and password, expand the Database option. Figure 9-5 Operations Navigator 2. Under Database, click Libraries. Then select the library name, which in our case is SAMPLEDB04, for your iSeries server connection (Figure 9-6). Chapter 9. Reverse engineering and Generate SQL 277 Figure 9-6 Find library 3. Click the SAMPLEDB04 library to display the current content in the right window panel. On the right panel, press the Ctrl key, and locate and select the following tables as shown in Figure 9-7: – ACT – CL_SCHED – DEPARTMENT – EMP_PHOTO – EMP_RESUME – EMPLOYEE 278 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-7 Selecting objects from the library to generate SQL Figure 9-8 Generate SQL window 4. Click Generate to accept the default values as shown in Figure 9-9. Important: When the Generate SQL function is invoked, the new Generate SQL window appears as shown in Figure 9-8. This window provides a list of the objects initially selected and three tabs that specify Output, Format, and Options that are used in the Generate SQL. Chapter 9. Reverse engineering and Generate SQL 279 Figure 9-9 Generate SQL display 5. Switch to the new Run SQL Scripts window to see the generated SQL statement. Important: The initial list of objects in the Generate SQL window could be modified using the Add and Remove buttons to add new objects or remove objects from the initial list. 280 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-10 SQL generated in the Run SQL Scripts window 6. Click File and select Save As... from the pull-down menu to save the SQL script as shown in Figure 9-11. Chapter 9. Reverse engineering and Generate SQL 281 Figure 9-11 Saving the SQL Script 7. Click Save to save the SQL script file. 9.2.1 Generating SQL to PC and data source files on the iSeries server You can generate the SQL statements to a PC file and to a source member on the iSeries server. Let’s start by showing you how to generate the SQL statements of a group of objects to a PC file: 1. Start Operations Navigator. 2. Right-click the SAMPLEDB04 library (example in our case). Then select Generate SQL as shown in Figure 9-12. Important: You can use the SQL file to replicate your database files on another system (for example, a development system). 282 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-12 Generate SQL library in Operations Navigator 3. In the Generate SQL window, select the Write to file option on the Output tab as shown in Figure 9-13. The generated SQL is saved to a PC file. Figure 9-13 Selecting Generate SQL to PC 4. Click File Type and select the PC file option. 5. In the Location file, click Browse. Then select your directory (c:\DB2NAVSQL) from the pull-down menu to save your file. Chapter 9. Reverse engineering and Generate SQL 283 6. In the File name input field, type GENSQL042.SQL. In the Files of type input field, leave the default SQL files (.sql) as shown in Figure 9-14. Figure 9-14 Saving the SQL script to a PC file 7. Click the Select button to return to the Generate SQL tab. Figure 9-15 Select button 8. Click the Generate button to start generating the SQL DDL statements for all the objects in the library. A status window appears showing the progress of the generate SQL process as a percentage (Figure 9-16). 284 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-16 Generating SQL window 9. In the Operations Navigator window, click the Run SQL Script icon in the database task pad as shown in Figure 9-17. Figure 9-17 Selecting the Run SQL Script from the task pad option Important: One of the new functions added in V5R1 is the task pad (located in the lower part of the Operations Navigator window). If you click the various higher level options, such as Security, Users and Groups, Database, etc., this task pad changes accordingly. One of the database tasks of the task pad is Run SQL Script. Chapter 9. Reverse engineering and Generate SQL 285 10.In the Run SQL Scripts window, click File and select Open from the pull-down menu to open your SQL Script file (GENSQL042). 11.Click Look in and select your directory (C:\DBNAVSQL) from the pull-down menu to save your file. 12.Select your GENSQL042 file and click Open as shown in Figure 9-18. Figure 9-18 Restoring an SQL script file from a PC 13.View the SQL statements generated on the Run SQL Script window as shown in Figure 9-19. Take some time to analyze the order of the statements. Figure 9-19 SQL Script statement generated Important: Once the statements are generated, you can edit them to create a new copy in another library and optionally saved, or you can run them using the SQL Script facility. If multiple objects were selected to be SQL Generated, you have the option to run one, some, or all of the statements after any required editing. 286 Advanced Functions and Administration on DB2 Universal Database for iSeries Let’s see now how to generate the SQL statements of a group of objects to a source physical file on the iSeries server: 1. Click the SAMPLEDB04 library to display the content in the right window panel. 2. Click File and select Generate SQL... from the pull-down menu to view the Generate SQL window as shown in Figure 9-20. This is another way to generate SQL for a group of objects. Figure 9-20 Selecting Generate SQL from the File menu 3. In the Generate SQL window, click the Write to file option in the Output tab as shown in Figure 9-21. Chapter 9. Reverse engineering and Generate SQL 287 Figure 9-21 Generate SQL: Selecting Write to file 4. Click File Type and select the database source file. 5. Click Library and select the SAMPLEDB04 library in our case. 6. In the File Name input field, type GENSQL043. In the Member input field, type GENSQL043. 7. Click the Generate button to start the Generate SQL process on the iSeries server. Figure 9-22 Starting the Generate SQL process on the iSeries server 288 Advanced Functions and Administration on DB2 Universal Database for iSeries 8. Double-click GENSQL043 to see the script on the Operations Navigator window as shown in Figure 9-23. Figure 9-23 Selecting the source physical file to show the Generate SQL Script 9. Expand the window, and use the scroll bar to explore the script file as shown in Figure 9-24. Note: For existing files, the option to append to the file is provided. If an existing file is selected, and the append option is not chosen, you are asked if you want to overwrite the existing file. Chapter 9. Reverse engineering and Generate SQL 289 Figure 9-24 Exploring the SQL Script file from Operations Navigator 9.2.2 Generating SQL from the Database Navigator map It is also possible to generate the SQL DDL statement from some or all objects in a map generated by the Database Navigator feature (Chapter 8, “Database Navigator” on page 239). 1. Click the Database Navigator icon to display the maps on the right that exist on the iSeries server as shown in Figure 9-25. 290 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-25 Opening the Database Navigator map 2. Double-click to open the database map that you created. 3. Click the View menu and select Zoom-> To Fit Window from the pull-down menu to fit all objects on the map in this window as shown in Figure 9-26. Chapter 9. Reverse engineering and Generate SQL 291 Figure 9-26 Fitting all objects in a map 4. Use the vertical and horizontal scroll bars to navigate to the top of the map as shown in Figure 9-27. 292 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-27 Viewing all objects includes in the map 5. Use the criteria selection in the locator pane and select only your SAMPLEDB04 library. Click the Library parameter to select your library as shown in Figure 9-28. Chapter 9. Reverse engineering and Generate SQL 293 Figure 9-28 Selecting only your sample library to appear in the Database Navigator map 6. Click the plus (+) sign next your SAMPLEDB04 database to see the found objects, such as tables, indexes, and views. 7. Click the (+) sign next to the Tables database object to expand it. 8. Double-click the EMPLOYEE table in the list of tables to find this table in the map. 9. Right-click the EMPLOYEE table and select Generate SQL... as shown in Figure 9-29. 294 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-29 Generating SQL for a specific object from the map 10.In the Run SQL Script window, explore the Generated SQL statement, using the scroll bar to navigate as shown in Figure 9-30. Chapter 9. Reverse engineering and Generate SQL 295 Figure 9-30 Generating SQL from the employee table 11.Click File and select Save As... from the pull-down menu to save the SQL script as shown in Figure 9-31. 296 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 9-31 Saving the Script SQL 12.On the Save window, click your directory (C:\DBNAVSQL) from the pull-down menu to save your file. 13.In the Name input field, type GENSQL044. In the Type input field, leave the default SQL files (.SQL) as shown in Figure 9-32. 14.Click Save to save the SQL script file. Figure 9-32 Saving the SQL Script file Now let’s see how to generate the SQL DDL statements for all the objects in a library. 1. Switch to the Database Navigator window. 2. Click the Map option and select Generate SQL from the pull-down menu. Click All Objects... to generate the SQL statement for all objects in your library as shown in Figure 9-33. Chapter 9. Reverse engineering and Generate SQL 297 Figure 9-33 Generate SQL for all objects in a library 3. A status window appears showing the progress of the Generate SQL as a percentage. 4. Click File and select Save As.... from the pull-down menu to save the map. 5. In the Save window, click to select your directory (C:\DBNAVSQL) from the pull-down menu to save your file. 6. In the File name input field, type GENSQL045. In the File of type input field, leave the default as SQL files (.SQL). 7. Click Save to save the SQL script file. 8. Click File and select Exit from the pull-down menu to close the Run SQL Script window. 9.2.3 Generating SQL from DDS The Generate SQL function works with objects created using SQL and also with objects that were created using DDS. These objects can also be reverse engineered into an SQL create statement. This is a way to start migrating or changing existing DDS created databases to SQL. Let’s see how to reverse engineer an existing DDS created database: 1. Click the plus (+) sign next to the Libraries object to expand the list of libraries. 2. Change the list of libraries in Operations Navigator to include the library that has DDS created objects. For this example, let’s say it is DDSLIBXX. Click DDSLIBXX. 298 Advanced Functions and Administration on DB2 Universal Database for iSeries 3. Right-click the DDSLIBXX library and select Generate SQL as shown in Figure 9-34. Figure 9-34 Selecting physical files to generate an SQL statement 4. Leave the default options. Click the Generate button in the Generate SQL window. 5. The SQL Script Center appears with the generated SQL DDL statements posted in the working area as shown in Figure 9-35. Chapter 9. Reverse engineering and Generate SQL 299 Figure 9-35 Exploring SQL script generated from physical files Important: There are some DDS-specific keywords that cannot be converted to SQL. This appears in the code as messages SQL150C and SQL509 (see Figure 9-35). 300 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 301 Chapter 10. Visual Explain The launch of DB2 UDB for iSeries Visual Explain with Operations Navigator V4R5M0 was of great interest to database administrators working in an iSeries server environment. The product has been described as a quantum leap forward in database tuning for query optimization. Visual Explain provides an easy to understand graphical interface that represents the optimizer implementation of the query. For the first time, you can see, in graphic detail, how the optimizer has implemented the query. You can even see all of the facts and figures that the optimizer used to make its decisions. Best of all, the information is presented in one place, in color, with easy to follow displays. There is no more jumping between multiple windows, trying to figure out what is happening. Even better, if you currently have Operations Navigator, you already have Visual Explain. With all of this in mind, is such a richly featured product complicated to use? As long as you are familiar with database tuning, you will enjoy using Visual Explain and want to learn more. This chapter answers these questions:  Where do I find Visual Explain?  How do I use it?  What can it be used for?  Will it tune my SQL queries?  What about green-screen queries and those slow running batch jobs? 10 Note: The Visual Explain tool is most effectively used when you have a firm understanding of the DB2 Universal Database for iSeries query optimizer and database engine. The recommended way to obtain this skill and build this understanding is to attend the classroom-based S6140 - DB2 UDB for iSeries SQL & Query Performance Tuning and Monitoring Workshop from IBM Learning Services at: http://www-1.ibm.com/servers/eserver/iseries/education/ 302 Advanced Functions and Administration on DB2 Universal Database for iSeries 10.1 A brief history of the database and SQL If you look back in history, you will find that the database was actually “invented”. It rapidly gained widespread acceptance. So much so, that today, virtually all commercial applications are based on the concepts of a database. Ever since this invention, programmers have been developing applications to use and maintain these databases in an organization. At the same time, the art of performance tuning databases has evolved. In high-level languages, programmers optimized access to their database files with keyed access paths. Keyed access was then coded in the program to provide record-level access. Users were not involved at this time. As standards evolved, databases became larger and were used for diverse purposes, including both transaction-based and data warehousing applications. Structured Query Language (SQL or query) has, at the same time, become the standard for database access. The scope and power of SQL delivers a standard interface to any database that supports SQL standards. DB2 UDB for iSeries continues to adopt and support the SQL standards. SQL can be used in pre-written applications on the iSeries server, as well as applications generated by users. Many interrogation tools running on PCs depend on the SQL interface to access data on the iSeries server. The (anticipated) spread of e-commerce will lead to even more situations where SQL statements are executed on the iSeries server. The need to optimize data access has never been greater. The database is in the public domain now and not reserved only for programmers. 10.2 Database tuning so far General performance tuning will always influence query performance. Therefore, general system usage, competition with other jobs, other queries, amount of memory, processor capacity, processor usage, and so on will always influence the performance of queries. Assuming that the work environment can be controlled on any given system, the challenge is to apply similar levels of control to the database to optimize the queries. Queries running on the iSeries server are processed through a query optimizer, which creates an access plan based on the information it has available. This access plan includes information about the tables to be accessed and how the query will attempt to access those tables. By reviewing this access plan, actions can be taken to influence the outcome, and therefore, the performance of the query. These actions can include the creation of indexes to support the query, or can involve changing the way that the query statements are structured to create a more efficient access plan. 10.2.1 Query optimizer debug messages The earliest approach, and probably one of the most widely used, is the analysis of query optimizer debug messages. Running the query under the influence of debug causes the query optimizer to write additional informational messages to the job log. Chapter 10. Visual Explain 303 By looking at the messages in the job log and reviewing the second-level text behind the messages, you can identify changes (for example, creating a new index) that could improve the performance of the query. Analysis of optimizer debug messages was made easier with the addition of a predictive query governor. By specifying a time limit of zero in the predictive query governor, query optimizer debug messages can be generated in the job log without actually running the query. This means that a query that may take 16 hours to run can be analyzed in a few seconds. Some changes can be made to the query or the database and the effect can be modelled on the query in just a few minutes. The query would then be run when the optimum implementation has been achieved. 10.2.2 Database Monitor More recently, query optimizer debug messages have been joined by the Database Monitor. The Database Monitor gathers query execution statistics from the iSeries server and records them in a database file. This database file is then analyzed to provide performance information to help tune the query or the database. The Database Monitor is accessed directly from the database component of Operations Navigator. It can also be accessed from a 5250 device using the Start Database Monitor (STRDBMON) command or during the collection of performance data with the STRPFRCOL command. The analysis of the statistics gathered can be done through the SQL Performance Monitors in Operations Navigator. Operations Navigator provides many pre-defined reports to assist with the analysis of the performance data collected in this manner. 10.2.3 The PRTSQLINF command For SQL embedded in program and package objects, the Print SQL Information (PRTSQLINF) CL command extracts the optimizer access method information out of the objects and places that information in a spooled file. The spooled file contents can then be analyzed to determine if any changes are needed to improve performance. 10.2.4 Iterative approach The analysis of queries and tuning for query optimization is an ongoing iterative process. There is no easy solution for query performance and no precise table to which you can refer for the answers. Much depends on a “try it and see” approach. With this approach, queries are analyzed, and changes are made to the environment. The query is run again, and the environment is adjusted. The process repeats until optimum performance is achieved. The task of database tuning is complete only when the following statements are all true:  Users and programmers are not generating any new queries.  All existing queries have been completely tuned.  Query selection, sort, and summarization do not change.  The iSeries server workload is stable.  The volume of data in the tables is stable.  The content of the tables is not changing. 304 Advanced Functions and Administration on DB2 Universal Database for iSeries 10.3 Introducing Visual Explain In Client Access Express, the database component of Operations Navigator is a graphical way to manage the database. Visual Explain has been added to the database component in V4R5M0. Visual Explain provides a graphical way to identify and analyze database performance. 10.3.1 What is Visual Explain Visual Explain provides a graphical representation of the optimizer implementation of a query request. The query request is broken down into individual components with icons representing each unique component. Visual Explain also includes information on the database objects considered and chosen by the query optimizer. Visual Explain’s detailed representation of the query implementation makes it easier to understand where the greatest cost is being incurred. Visual Explain shows the job run environment details and the levels of database parallelism that were used to process the query. It also shows the access plan in diagram form, which allows you to zoom to any part of the diagram for further details. If query performance is an issue, Visual Explain provides information that can help you to determine whether you need to:  Rewrite or alter the SQL statement  Change the query attributes or environment settings  Create new indexes Best of all, you do not have to run the query to find this information. Visual Explain has a modeling option that allows you to explain the query without running it. That means you could try any of the changes suggested and see how they are likely to work, before you decide whether to implement them. Visual Explain is an advanced tool to assist you with the task of enhancing query performance, although it does not actually do this task for you. You still need to understand the process of query optimization and the different access plans that can be implemented. 10.3.2 Finding Visual Explain Visual Explain is a component of Operations Navigator and is found in the Database section of Operations Navigator. To locate the database section of Operations Navigator, you need to establish a session on your selected iSeries server using the Operations Navigator icon. Many functions within Operations Navigator are obtained by right-clicking. For example, you can right-click the Database icon to gain access to several of the query functions (Figure 10-1). Selecting Run SQL Scripts invokes the SQL Script Center. From the SQL Script Center, Visual Explain can be accessed directly, either from the menu or from the toolbar. This is explained in 10.4.1, “The SQL Script Center” on page 306. Another way to access Visual Explain is through the SQL Performance Monitor. The SQL Performance Monitor is used to create Database Performance Monitor data and to analyze the monitor data with pre-defined reports. Figure 10-1 Database options under the Database icon Chapter 10. Visual Explain 305 Visual Explain works with the monitor data that is collected by the SQL Performance Monitor on that system or by the Database Performance Monitor (STRDBMON), which is discussed in 10.6, “Using Visual Explain with Database Monitor data” on page 318. Visual Explain can also analyze Database Performance Monitor data collected on other systems once that data has been restored on the iSeries server. 10.3.3 Data access methods and operations supported Visual Explain was shipped for the first time in V4R5M0. Table 10-1 shows the methods and operations that are supported by Visual Explain. Table 10-1 Query access functions supported Optimizer access plan Debug Visual Explain Non-keyed access methods Table Scan   Parallel Table Scan   Parallel Pre-fetch   Parallel Table Pre-load   Skip Sequential with dynamic bitmap   Parallel Skip Sequential   Keyed Data Access Methods Key Positioning and Parallel Key Positioning   Dynamic Bitmaps/Index ANDing ORing   Key Selection and Parallel Key Selection   Index-From-Index   Index-Only Access   Parallel Index Pre-load   Joining, Grouping, Ordering Nested Loop Join   Hash Join  * Index Grouping   Hash Grouping   Index Ordering   Sort   Query Statements Select   Update   Insert  * Delete   306 Advanced Functions and Administration on DB2 Universal Database for iSeries Each of the methods shown in this table (debug and Visual Explain) provide assistance with the task of debugging queries and the analysis of queries to optimize their performance. None of these will automatically perform the changes for you. The sole purpose is to provide you with the necessary information so you can make an informed choice. The ease of use that Visual Explain offers can quickly disguise the fact that it is an advanced tool working for you in a highly technical area. Use Visual Explain to assist you with the task of enhancing query performance. Although Visual Explain cannot sort out problems for you, it can help you to identify and solve problems in a more effective way. You still need to understand the process of query optimization, the different database access plans that can be implemented, and the effects of those plans on the system. You also need to understand the database that you are tuning, its use, and the impact of creating and changing indexes. 10.4 Using Visual Explain with the SQL Script Center The Run SQL Script window (SQL Script Center) provides a direct route to Visual Explain. The window is used to enter, validate, and execute SQL commands and scripts and to provide an interface with OS/400 through the use of CL commands. 10.4.1 The SQL Script Center To access the SQL Script Center, right-click the Database option in Operations Navigator to see the Database menu. Select Run SQL Scripts. The Run SQL Script window appears with the toolbar as shown in Figure 10-2. Reading from left to right, there are icons to create, open, and save SQL scripts, followed by icons to cut, copy, paste, and insert generated SQL (V5R1) statements within scripts. Sub Query  * Union  * View materialization  * Operational Characteristics Index Usage   Index Advice   Open Data Path Usage   Work Management details  Notes:  Supported for analysis with this method. * PTF # XXX is required for V4R5. You need to load the latest Database Group PTF to obtain the best functionality of Visual Explain. Optimizer access plan Debug Visual Explain Figure 10-2 Toolbar from the SQL Script Center Chapter 10. Visual Explain 307 The hour glass icons (green downward arrows in V4R5) indicate to run the statements in the Run SQL Scripts window. These options are also available under the Run menu (Figure 10-3). From left to right, they run all of the statements in the window (All), run all of the statements from the cursor to the end (From Selected), or run the single statement identified by the cursor position (Selected). To the right of the hour glasses in Figure 10-2 is a Stop button, which is colored red when a run is in progress. The final icon in the toolbar is the Print icon. This is followed by two Visual Explain icons, colored blue and green. The left Visual Explain icon (blue) is to explain the SQL statement. The right Visual Explain icon (green) is to run and explain the SQL statement. The actions that you will choose are explained in a moment. Both of these options are also available on the drop-down menu (Figure 10-4). You may choose either option to start Visual Explain. Another option exists on the Visual Explain pull-down menu to show recent SQL Performance Monitors. SQL Performance Monitors can be used to record SQL statements that are explainable by Visual Explain. We recommend access via the SQL Performance Monitors icon, because this provides the full list of monitors. An SQL script is defined as one or more statements from the Run SQL Script working area below the toolbar. An initial comment is provided. Each complete statement needs a delimiter to mark the end of statement. The SQL Script Center uses a semi-colon (;) for this purpose. 10.4.2 Visual Explain Only The Visual Explain Only option (Ctrl+E or the blue toolbar icon) submits the query request to the optimizer and provides a visual explanation of the SQL statement and the access plan that will be used when executing the statement. In addition, it provides a detailed analysis of the results through a series of attributes and values associated with each of the icons. See Figure 10-5. To optimize an SQL statement, the optimizer validates the statement and then gathers statistics about the SQL statement and creates an access plan. When you choose the Visual Explain Only option, the optimizer processes the query statement internally with the query time limit set to zero. Therefore, it proceeds through the full validation, optimization, and creation of an access plan and then reports the results in a graphical display. Note: When choosing Visual Explain Only, Visual Explain may not be able to explain some complex queries such as hash join, temp join results, etc. In this cases, users have to choose Run and Explain for the SQL statements to see the graphical representation. 10.4.3 Run and Explain The Run and Explain option (Ctrl+U or the green toolbar icon) also submits the query request to the optimizer, and provides a visual explanation of the SQL statement and the access plan that will be used when executing the statement. It provides a detailed analysis of the results through a series of attributes and values associated with each of the icons. Figure 10-3 SQL Script Center Run options Figure 10-4 SQL Script Center Visual Explain options Figure 10-5 Visual Explain access 308 Advanced Functions and Administration on DB2 Universal Database for iSeries However, it does not set the query time limit to zero and, therefore, continues with the execution of the query. This leads to the display of a results window in addition to the Visual Explain graphics. 10.5 Navigating Visual Explain The Visual Explain graphics window (Figure 10-6) is presented in two parts. The left-hand side of the display is called the Query Implementation Graph. This is the graphical representation of the implementation of the SQL statement and the methods used to access the database. The arrows indicate the order of the steps. Each node of the graph has an icon that represents an operation or values returned from an operation. The right-hand side of the display has the Query Attributes and Values. The display corresponds to the object that has been selected on the graph. Initially, the query attributes and values correspond to the final results icon. The vertical bar that separates the two sides is adjustable. Each side has its own window and is scrollable. Figure 10-6 Visual Explain Query Implementation Graph and Query Attributes and Values Notes:  Visual Explain may show a representation that is different from the job or environment where the actual statement was run since it may be explained in an environment that has different work management settings.  If the query is implemented with multiple steps (that is, joined into a temporary file, with grouping performed over it), the Visual Explain Only option cannot provide a valid explanation of the SQL statement. In this case, you must use the Run and Explain option. Chapter 10. Visual Explain 309 The default settings cause the display to be presented with the final result icon (a checkered flag) on the left of the display. Each of the icons on the display has a description and the estimated number of rows to be used as input for each stage of the implementation. Clicking any of the icons causes the Query Attributes and Values display to change and present the details that are known to the query for that part of the implementation. You may find it helpful to adjust the display to see more of the attributes and values. Query attributes and values are discussed further in 10.5.5, “Visual Explain query attributes and values” on page 315. When you right-click any of the icons on the display, an action menu is displayed. The action menu has options to assist with query information and can provide a short cut to table information to be shown in a separate window. More details are shown in 10.5.2, “Action menu items” on page 310. The following action menu items may be found selectively on different icons:  Table Description: Displays table information returned by Display File Description (DSPFD).  Index Description: Displays index information returned by DSPFD.  Create Index: Creates a permanent index on the iSeries server.  Table Properties: Displays object properties.  Index Properties: Displays object properties.  Display Query Environment: Displays environment settings used during the processing of this query.  Additional fly-over panels: These exist for many of the icons. By moving the mouse pointer over the icon, a window appears with summary information on the specific operation. See Figure 10-7. Figure 10-7 Table scan fly-over panel The Visual Explain toolbar (Figure 10-8) helps you navigate the displays. The first four icons (from left to right) help you control the sizing of the display. The left-most icon scales the graphics to fit the main window. For many query implementations, this leaves the graphical display too small to be of value. The next two icons allow you to zoom in and out of the graphic image. The fourth icon (Overview) creates an additional window Figure 10-9 that shows the Visual Explain graphic on a reduced scale. This window has a highlighted area, which represents the part of the image that is currently displayed in the main window. Figure 10-8 Visual Explain toolbar 310 Advanced Functions and Administration on DB2 Universal Database for iSeries In the Overview window (Figure 10-9), you can move the cursor into this highlighted area that is shown in the main window. The mouse pointer changes so you can drag the highlighted area to change the section of the overall diagram that is shown in the main window. The default schematic shows the query with the result on the left, working across the display from right to left, to allow you to start at the result and work back. The remaining four icons on the Visual Explain toolbar allow you to rotate the query implementation image. The icons are:  Starting from the right, leading to the result on the left (default view)  Starting from the left, leading to the result on the right  Starting at the bottom, leading to the result at the top  Starting from the top, leading to the result at the bottom Try these icons to see which style of presentation you prefer. Starting in V5R1, a frame at the bottom of the main Visual Explain window was added. In this frame, you can see two tabs. The Statement Text tab shows the analyzed SQL statement. Also in V5R1, when Visual Explain is used, it activates the Include Debug Messages in Job Log option and conveniently presents those messages under the Optimizer Messages tab. 10.5.1 Menu options The menu options above the toolbar icons are File, View, Actions, and Help. The File option allows you to close the window. Starting on V5R1, the ability to either print or save the Visual Explain output as an SQL Performance Monitor file was added. The View options generally replicate the toolbar icons. The additional options are:  Icon spacing (horizontal or vertical) changes the size of the arrows between the icons.  Arrow labels allow you to show/hide the estimated number of rows that the query is processing at each stage of the implementation.  Icon labels allow you to show/hide the description of the icons.  Highlight expensive icons (new in V5R1) by number of returned rows.  Highlight advised indexes (new in V5R1). The Actions menu item replicates the features that are available on the display. 10.5.2 Action menu items When you right-click a query implementation icon, a menu appears that offers further options. These options may include one of more of the following items. Table Description The Table Description menu item (Figure 10-10) takes you into the graphical equivalent of the Display File Description (DSPFD) command. From here, you can find out more information about the file. The description has several tabs to select to find further information. A limited number of changes can be made from the different tab windows. Figure 10-9 Visual Explain Overview window Chapter 10. Visual Explain 311 Figure 10-10 Table Description Table Properties The Table Properties display (Figure 10-11) shows a list of the columns and their attributes from the table icons. A limited number of changes are allowed from the window. Figure 10-11 Table Properties 312 Advanced Functions and Administration on DB2 Universal Database for iSeries Index Description The Index Description attributes can be accessed to obtain further information about the index. Several changes are allowed to an index from these windows, including access path maintenance settings. The Index Description display is shown in Figure 10-12. Figure 10-12 Index Description Index Properties The Index Properties window (Figure 10-13) shows the columns that exist in the table. A sequential number is placed next to the columns that form the index, with an indication of whether the index is ascending or descending. The display also shows the type of index. Figure 10-13 Index Properties Chapter 10. Visual Explain 313 Create Index From the temporary index icon, the Create Index menu item takes you to a dialogue box where the attributes of the temporary index have been completed (Figure 10-14). Simply click OK to create a permanent index that mirrors the temporary index created by the query. Figure 10-14 New Index on Table display You need to enter an index name. The type of index is assumed to be binary radix with non-unique keys. Note: The Create Index menu item is available from any icon where an index is advised (for example, table scan, key positioning, key selection) in addition to the temp index icon. This is one of the user-friendly features of Visual Explain, which gives you the ability to easily create an index that the optimizer has suggested. 10.5.3 Controlling diagram level of detail Starting on V5R1, users can select how much detail they want to see on the Visual Explain graphs. The VISUAL_EXPLAIN_DIAGRAM row on the QAQQINI file lets you change the level of detail in Visual Explain. When it is set to *BASIC or *DEFAULT, it shows only the icons directly related to the query. When it is set to *DETAIL, it also shows the icons that are indirectly related to the query, such as table scans performed to build temporary indexes. Figure 10-15 shows these two versions of explanation for the same sample query. Most users will be satisfied with the *BASIC diagram while others, with more performance tuning experience, may prefer the *DETAIL diagram. 314 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 10-15 Basic and detailed Visual Explain comparison In Figure 10-15, the table scan on the upper right of the detailed graph is part of the creation of the temporary index. Some other differences between *BASIC and *DETAIL are:  If the single table query uses key positioning, key selection, and table scan, *DETAIL would show an icon for key positioning, key selection, and table scan. *BASIC would show only one icon – key positioning.  If the single table query uses key positioning, *DETAIL shows two icons – key positioning and table probe. *BASIC would show only the key positioning icon. 10.5.4 Displaying the query environment The query environment is available as a fast path from the Final Results icon and shows the work management environment (Figure 10-16) where the query was executed. This information can also be obtained from the Query Attributes and Values displays. Basic Visual Explain Example Detailed Visual Explain Example Chapter 10. Visual Explain 315 Figure 10-16 Environment 10.5.5 Visual Explain query attributes and values The query attributes and values show further information about the optimizer implementation of the query. If you select an icon from the Query Implementation graph, you obtain information about that icon, as well as that part of the query implementation. We selected a few of the query implementation icons to show you the query attributes and values. This way, you can see exactly how much information Visual Explain collects. Prior to Visual Explain, the information was often available, but never in one place. Table name, base table name, index name This section shows the name and library of the table being selected (Figure 10-17). If the table name is a long name (MASTERCUSTOMER), the name of the table being queried and the member of the table will be the short name (MASTE00001). The long name is in a separate line titled “Long Name of the Table being queried”. Figure 10-17 Table name Estimated processing time and table info The estimated processing time (Figure 10-18) shows the time the optimizer expects to take from this part of the query. Figure 10-18 Estimated processing time 316 Advanced Functions and Administration on DB2 Universal Database for iSeries Estimated rows selected and query join info The estimated rows selected (Figure 10-19) shows the number of rows the optimizer expects to output from this part of the query. If the query is only explained, it shows an estimate of the number of rows. If it is run and explained, it actually shows the number of rows selected. It also shows whether the query is CPU or I/O bound, which is information that was not accessible prior to Visual Explain. Figure 10-19 Estimated rows selected Queries can be very CPU-intensive or I/O-intensive. When a query’s constraint resource is the CPU, it is called CPU bound. When a query’s constraint resource is the I/O, it is called I/O bound. A query that is either CPU or I/O bound gives you the opportunity to review the query attributes being used when the query was processing. If SMP is installed on a multi-processor system, you should review the DEGREE parameter to ensure that you are using the systems resources effectively. Information about the index scan performed This display shown in Figure 10-20 provides the essentials about the index that was used for the query, including the reason for using the index, how the index is being used, and static index attributes. It also specifies the access method or methods used such as Index Scan - Key positioning, Index Scan - Key Selection, and Index Only Access. To find the description of the different reason codes, refer to the manual DB2 UDB for iSeries Database Performance and Query Optimization. Figure 10-20 Index scan SMP parallel information The SMP information (Figure 10-21) shows the degree of parallelism that occurred on this particular step. It may appear for more than one icon, because multiple steps can be processed with differing degrees of parallelism. The display also shows whether either parallel pre-fetch or parallel pre-load was used as part of the parallel processing. This information is only relevant when the DB2 SMP licensed feature is installed. The parallel degree requested is the number of parallel tasks that the optimizer used. This is a user setting defined with CHGQRYA, but the optimizer adjusts it based on the system resources. Chapter 10. Visual Explain 317 Figure 10-21 SMP parallel information Index advised information The Index advised section (Figure 10-22) tells you whether the query optimizer is advising the creation of a permanent index. If an index is being advised, the number and names of the columns to create the index are suggested. This is the same information that is returned by the CPI432F optimizer message. If the Highlight Index Advised option is set, advised index information, like base table name, library, and involved columns, will be easily identifiable, as shown in the Figure 10-22. Figure 10-22 Index advised Note that it is possible for the query optimizer to not use the suggested index, if created. This suggestion is generated if the optimizer determines that a new index might improve the performance of the selected data by 1 microsecond. Information about temporary index created This display provides information about the creation of a temporary index as part of the query optimizer implementation (Figure 10-23). The index created is reusable and specifies if a temporary index creation is allowing the associated ODP to be used. If the key column field names of the index are missing, this implies that derived fields were used. Figure 10-23 Temporary index Additional information about SQL statement The display in Figure 10-24 shows information about the SQL environment that was used when the statement was captured. The SQL environment parameters can impact query performance. Many of these settings are taken from the ODBC/JDBC driver settings. The Statement is Explainable specifies if the SQL statement can be explained by the Visual Explain tool. In V4R5, not all statements are explainable. In this section, you will find the SQL statement if you selected the Final Select icon. 318 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 10-24 Additional information Implementation summary for SQL statement The Implementation summary for SQL statement (Figure 10-25) provides information about the type of SQL statement being processed. It also identifies functions that have a particular influence on the optimizer. It specifies the values of the variables used on the SQL statement (Host Variable Values). If the SQL Statement has an Order By, Group By, or a Join, it specifies which implementation was used. In the example in Figure 10-25, the SQL statement did not have an Order By, Group By, or join operation. Figure 10-25 Implementation summary 10.6 Using Visual Explain with Database Monitor data Database Monitor data is query information that has been recorded by one of the DB2 UDB for iSeries performance monitors into a database table that can be analyzed later. Multiple Database Performance Monitors may run on the iSeries at the same time. They can either record information for individual jobs or for the entire system. Each one is individually named and controlled. Any given job can be monitored by a maximum of one system monitor and one job monitor. The Database Performance Monitor can be started from Operations Navigator or with a CL command. With Operations Navigator, the SQL Performance Monitors component is used to collect Database Monitor data. If you want to use Visual Explain with the data collected with an SQL Performance Monitor, then you must choose the detailed monitor collection when setting up the Database Performance Monitor in Operations Navigator. Chapter 10. Visual Explain 319 The Start Database Monitor (STRDBMON) or Start Performance Monitor (STRPFRMON) (with STRDBMON(*YES)) CL commands can also be used to collect Database Performance Monitor data. If you intend to use Visual Explain on the Database Monitor data collected with these CL commands, the data must be imported into Operations Navigator as detailed data. See 7.6, “SQL Performance Monitors” on page 220, for a detailed explanation on how to use SQL Performance Monitor and how to import DBMON data into Operations Navigator. Using Visual Explain Click Operations Navigator-> Database-> SQL Performance Monitors to obtain a list of the SQL Performance Monitors that are currently on the system. Right-click the Performance Monitor, and select List Explainable Statements. An “explainable” statement (Figure 10-26) is an SQL statement that can be explained by Visual Explain. Because Visual Explain does not process all SQL statements, it is possible that some statements will not be selected. Figure 10-26 SQL explainable statements The explainable SQL statements that have been optimized by the job are now listed. If you have been monitoring an SQL Script window, these will be the SQL statements that were entered. To use Visual Explain on any of the statements, select the statement from the display. The full SQL statement appears in the lower part of the display for verification. Click Run Visual Explain (Figure 10-26) to analyze the statement, and prepare a graphical representation of the query. Note: Query optimizer information is only generated for an SQL statement or query request when an ODP is created. When an SQL or query request is implemented with a Reusable ODP, then the query optimizer is not invoked. Therefore, there will be no feedback from the query optimizer in terms of monitor data or even debug messages and the statement will not be explainable in Visual Explain. The only technique for analyzing the implementation of a statement in Reusable ODP mode is to look for an earlier execution of that statement when an ODP was created for that statement. 320 Advanced Functions and Administration on DB2 Universal Database for iSeries Exit the Visual Explain window and the Explainable Statements window when you have completed your analysis. You may either retain the performance data or remove it from the system at this time, depending on your requirements. 10.7 Non-SQL interface considerations Obviously, the Database Performance Monitor can capture implementation information for any SQL-based interface. Therefore, any SQL-based request can be analyzed with Visual Explain. SQL-based interfaces range from Embedded SQL to Query Manager reports to ODBC and JDBC. Some query interfaces on the AS/400 and iSeries servers are not SQL-based and, therefore, are not supported by Visual Explain. The interfaces not supported by Visual Explain include:  Native database access from a high level language, such as Cobol, RPG, etc.  Query  OPNQRYF command  OS/400 Create Query API (QQQQRY) The query optimizer creates an access plan for all queries that run on the iSeries server. Most queries use the SQL interface, and generate an SQL statement, either directly (SQL Script Window, STRSQL command, SQL in high-level language (HLL) programs) or indirectly (Query Monitor/400). Other queries do not generate identifiable SQL statements (Query, OPNQRYF command) and cannot be used with Visual Explain via the SQL Performance Monitor. In this instance, the name SQL, as part of the SQL Performance Monitor, is significant. The statements that generate SQL and can be used with the Visual Explain via the SQL Performance Monitor include:  SQL statements from the SQL Script Center  SQL statements from the Start SQL (STRSQL) command  SQL statements processed by the Run SQL Statement (RUNSQLSTM) command  SQL statements embedded into a high level language program, such as Cobol, Java, or RPG  SQL statements processed through an ODBC or JDBC interface The statements that do not generate SQL and, therefore, cannot be used with Visual Explain via the SQL Performance Monitor include:  Native database access from a high level language, for example, Cobol, RPG, etc.  Query  Open Query File (OPNQRYF) command  OS/400 Create Query API (QQQQRY) 10.7.1 Query/400 and Visual Explain Query/400, now renamed Query, is not supported by Visual Explain even though optimizer debug messages can be used with Query/400 queries since it does not generate SQL. Query/400 queries are often blamed for poor performance and sometimes even banned from execution during daylight hours. It is for this reason that some guidance has been provided to bring Query/400 queries into the scope of Visual Explain. Chapter 10. Visual Explain 321 There is no direct Query/400 to SQL command. However, the Start Query Monitor Query (STRQMQRY) CL command will run a query definition (object type *QRYDFN) as an SQL statement, as long as the ALWQRYDFN parameter is set to either *YES or *ONLY. If you are accessing a multi-member file, performance data is not collected for the second and subsequent members. Instead, you need to use an SQL supported interface, such as an alias for the members. To use this SQL statement with Visual Explain, either start an SQL Performance Monitor for this job in advance of issuing the STRQMQRY command, or use the native STRDBMON CL command to collect data for the job. See 7.6.1, “Starting the SQL Performance Monitor” on page 222. 10.7.2 The Visual Explain icons The icons that you may encounter on the Visual Explain query implementation chart are shown here. The Final Result icon displays the original SQL statement and summary information of how the query was implemented. It is the last icon on the chart. The Table Scan icon indicates that all rows in the table were paged in, and selection criteria was applied against each row. Only those rows meeting the selection criteria were retrieved. To obtain the result in a particular sequence, you must specify the ORDER BY clause. The Parallel Table Scan icon indicates that a table scan access method was used and multiple tasks were used to fill the rows in parallel. The table was partitioned, and each task was given a portion of the table to use. The Skip Sequential Table Scan icon indicates that a bitmap was used to determine which rows would be selected. No CPU processing was done on non-selected rows, and I/O was minimized by bringing in only those pages that contained rows to be selected. This icon usually is related to the Dynamic Bitmap or Bitmap Merge icons. The Skip Sequential Parallel Table Scan icon indicates that a skip sequential table scan access method was used and multiple tasks were used to fill the rows in parallel. The table was partitioned, and each task was given a portion of the table to use. The Derived Column Selection icon indicates that a column in the row selected had to be mapped or derived before selection criteria could be applied against the row. Derived column selection is the slowest selection method. The Parallel Derived Column Selection icon indicates that derived field selection was performed, and the processing was accomplished using multiple tasks. The table was partitioned, and each task was given a portion of the table to use. The Index Key Positioning icon indicates that only entries of the index that match a specified range of key values were “paged in”. The range of key values was determined by the selection criteria whose predicates matched the key columns of the index. Only selected key entries were used to select rows from the corresponding table data. 322 Advanced Functions and Administration on DB2 Universal Database for iSeries The Parallel Index Key Positioning icon indicates that multiple tasks were used to perform the key positioning in parallel. The range of key values was determined by the selection criteria, whose predicates matched the key columns of the index. Only selected key entries were used to select rows from the corresponding table data. The Index Key Selection icon indicates that all entries of the index were paged in. Any selection criteria, whose predicates match the key columns of the index, was applied against the index entries. Only selected key entries were used to select rows from the table data. The Parallel Index Key Selection icon indicates that multiple tasks were used to perform key selection in parallel. The table was partitioned, and each task was given a portion of the table to use. The Encoded Vector Index icon indicates that access was provided to a database file by assigning codes to distinct key values, and then representing these values in an array (vector). Because of their compact size and relative simplicity, Encoded Vector Indexes provide for faster scans. The Parallel Encoded Vector Index icon indicates that multiple tasks were used to perform the encoded vector index selection in parallel. This allows for faster scans that can be more easily processed in parallel. The Sort Sequence icon indicates that selected rows were sorted using a sort algorithm. The Grouping icon indicates that selected rows were grouped or summarized. Therefore, duplicate rows within a group were eliminated. The Nested Loop Join icon indicates that queried tables were joined together using a nested loop join implementation. Values from the primary file were joined to the secondary file by using an index whose key columns matched the specified join columns. This icon is usually after the method icons used on the underlying tables (that is, Index scan-Key selection and Index scan-Key positioning). The Hash Join icon indicates that a temporary hash table was created. The tables queried were joined together using a hash join implementation where a hash table was created for each secondary table. Therefore, matching values were hashed to the same hash table entry. The Temporary Index icon indicates that a temporary index was created, because the query either requires an index and one does not exist, or the creation of an index will improve performance of the query. The Temporary Hash Table icon indicates that a temporary hash table was created to perform hash processing. The Temporary Table icon indicates that a temporary table was required to either contain the intermediate results of the query, or the queried table could not be queried as it currently exists and a temporary table was created to replace it. Chapter 10. Visual Explain 323 10.8 SQL performance analysis using Visual Explain This section presents a brief example on SQL performance analysis using Visual Explain. A complete explanation on performance analysis is beyond the scope of this redbook, but you can find extensive information on Redpapers and workshops at: http://www-1.ibm.com/servers/eserver/iseries/library/ 10.8.1 Database performance analysis methodology There are many different methods to identify problems and tune troublesome database queries. One of the most common methods is to identify the most dominating, time-consuming queries and work on each of them individually. Another method is to leverage global information and to use this information to look for indexes that are “begging” to be created. Operations Navigator SQL Performance Monitor provides you with tools for gathering and analyze SQL performance information. Once you have SQL performance data collected, you can use the predefined queries for looking for specific queries that have large table scans or that are evidencing some lack of indexes. Those predefined queries can be reached by right-clicking the specific SQL Performance Monitor collected and selecting Analyze Results as shown in Figure 10-27. The Dynamic Bitmap icon indicates that a bitmap was dynamically generated from an existing index. It was then used to determine which rows were to be retrieved from the table. To improve performance, dynamic bitmaps can be used in conjunction with a table scan access method for skip sequential or with either the index key position or key selection. The Bitmap Merge icon indicates that multiple bitmaps were merged or combined to form a final bitmap. The merging of the bitmaps simulates boolean logic (AND/OR selection). The DISTINCT icon indicates that duplicate rows in the result were prevented. You can specify that you do not want any duplicates by using the DISTINCT keyword, followed by the selected column names. The UNION Merge icon indicates that the results of multiple subselects were merged or combined into a single result. The Subquery Merge icon indicates that the nested SELECT was processed for each row (WHERE clause) or group of rows (HAVING clause) selected in the outer level SELECT. This is also referred to as a “correlated subquery”. The Incomplete Information icon indicates that a query could not be displayed due to incomplete information. 324 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure 10-27 Analyzing SQL performance results The Basic Statement Information predefined query gives you a very general idea of the queries being monitored, as well as the kind of access methods used by these queries. This reports provides you information related to execution time per each execution, total execution time, advised indexes, whether table scan or temporary index creation was used, and more. Once you detect a query or set of queries that needs further analysis, you can use a detailed query analysis tool like Visual Explain to explore them in detail. Query analysis is iterative in nature. Try something running the job or the individual query to see if it worked. Try it again if it did not work. You can explain with Visual Explain the SQL statements contained in the SQL Performance Monitor Collected data by right-clicking the specific collection and selecting List Explainable Statements from the pop-up menu. A list of explainable statements appears and you can choose those in which you are interested. As an example, Figure 10-28 shows a Visual Explain diagram that permits you to detect that for this query. It is performing a table scan and is not using parallelism. You can see that the SQL statement does not specify an OPTIMIZE FOR n ROWS portion, and the query degree is set to *NONE. Chapter 10. Visual Explain 325 Figure 10-28 Analyzing a simple query: First iteration Based on the information provided by Visual Explain, you change the statement including now an OPTIMIZE FOR ALL ROWS, and we change the parallel degree to *OPTIMIZE. See Figure 10-29. Figure 10-29 Analyzing a simple query: Second iteration No OPTIMIZE FOR n ROWS used. Parallel degree (or query degree) is set to NONE Now the statement includes an OPTIMIZE FOR ALL ROWS affecting the optimizer’s access plan. Using parallelism. Optimizer is asking for 10 parallel threads An index is advised, using fields YEAR, MONTH and RETURNFLAG 326 Advanced Functions and Administration on DB2 Universal Database for iSeries You can see the affect that the changes had over the analyzed query. You can go further and create the suggested index by right-clicking the Table Scan icon and selecting the Create Index option. A New Index on Table window appears (Figure 10-30), where the suggested fields are selected for you. You have to provide a name and library for the new index. You can also change the order of the fields and add new fields to the index if you consider that necessary. Figure 10-30 New Index on Table window Now DB2 UDB for iSeries uses the suggested index, as shown in Figure 10-31. Note that it is possible that DB2 UDB for iSeries may not use the suggested index. Figure 10-31 Analyzing a simple query: Third iteration Chapter 10. Visual Explain 327 Is it really that simple? Tuning SQL statements and database performance can be a very demanding task, but with the new tools introduced in V4R5 and improved in V5R1, such as Visual Explain and SQL Performance Monitor predefined reports, it is becoming more accessible. Performance tuning, particularly when dealing with database operations, is an iterative process but the availability and knowledge of powerful tools allow the performance analyst to find a solution quickly. Knowledge and judicious usage of the OS/400 Database Monitor tool, its predefined queries, and particularly Visual Explain reduces significantly the time and effort required by performance analysts. 328 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 329 Appendix A. Order Entry application: Detailed flow This appendix provides detailed flow charts of each of the modules included in the Order Entry application scenario. A 330 Advanced Functions and Administration on DB2 Universal Database for iSeries Program flow for the Insert Order Header program Figure A-1 shows a functional description of the various components of this application scenario. The DB2 UDB for iSeries functional highlights in this program include:  Referential integrity constraints for the Order Header table  Insert trigger on the Order Header file Figure A-1 Insert Order Header program flow Program description for the Insert Order Header program The idea of this program is to show how to use the following new database functions in a real application:  Referential integrity: When a record is inserted in the Order Header file, the system checks for an existing customer in the Customer table.  Database trigger: Before the insert operation is completed, the database manager activates a program that can verify if the sales representative is assigned to the customer and log any violation attempt.  Program description: The sales person periodically calls the customer over the phone and places an order. The sales person enters the customer number, the order and delivery date, and other general information. The application does not automatically generate an order number. For the sake of simplicity, this is entered by the sales representative. SEND MESSAGE CUSTOMER # NOT VALID SEND MESSAGE SALES PERSON / CUSTOMER RELATIONSHIP NOT VALID A TAKE INPUT FROM SCREEN INSERT ORDER HEADER OK RI ? OK TO INSERT B RI TRIGGER ON INSERT CHECK RELATIONSHIP WRITE AUDIT TRAIL DIFFERENT ACTIVATION GROUP Appendix A. Order Entry application: Detailed flow 331 A more detailed flow of this program is described as follows: 1. The program inserts a row into the Order Header table. 2. If the database referential constraint enforcement detects a customer number not defined in the Customer table, a program message is sent explaining that the customer number is invalid. A correct customer number must be entered. 3. The customer name is displayed at the terminal. 4. A row is inserted into the Order Header table. 5. Since an insert trigger is defined on this table, a program is automatically triggered by the database manager. 6. The trigger program checks if the current user profile is associated to the customer in the Sales/Customer table. If there is no match, the program writes an audit trail entry to an audit table. 7. If the insert is successful, the program returns a positive return code to the main program, which calls the Insert Order Detail program. Program flow for the Insert Order Detail program DB2 Universal Database for iSeries functional highlights in this program include:  Referential integrity constraints for the Order Detail table  Referential integrity constraints for the Stock table (on remote system)  Two-phase Commit and DRDA Level 2  Remote stored procedure The program flow for Insert Order Detail is shown in Figure A-2. 332 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure A-2 Insert Order Detail program flow Program description for Insert Order Detail program The idea of this program is to show how to use the following new database functions in a real application:  Referential integrity: When a record is inserted into the Order Detail table for a new order item, the system checks for a matching order number in the Order Header table.  Two-phase commit with DRDA, Level 2: This procedure inserts a record in a local file and updates the remote inventory file (STOCK file). At the end of this process, you want to release the locks on the inventory record and the transaction is committed. The two-phase commit support guarantees the integrity of this transaction.  Stored procedure: To update the remote inventory file, this program calls a remote stored procedure. The stored procedure checks the availability of the product. If the product has low inventory levels, the stored procedure looks for an alternative and sends the new product code and description back to the calling application. The selected product information is displayed at the terminal and the user has the choice of accepting or rejecting the substitute item. ROLLBACK RI Y N Y 2-PHASE COMMIT C SET CONNECTION REMOTE CONNECT CALL STORED PROCEDURE SET CONNECTION N N STORED PROCEDURE INSERT ORDER DETAIL CANCEL ? MORE ? E Y CHECK ORDER # TAKE PRODUCT NUMBER FROM SCREEN C FROM ORDER HEADER PROGRAM: CUSTOMER #, ORDER # CANCEL ORDER BEGIN ? MORE ITEMS ? ALT ITEM OK? CANCEL ? E B N N N Y Appendix A. Order Entry application: Detailed flow 333  Program description: This program can: a. Get the customer number and the order number from the Insert Order Header program. b. Get the product number and quantity for every single item from the display. c. Issue a SET CONNECTION statement to the remote system. All the necessary CONNECT statements are performed by the main program. d. Call a stored procedure at the remote system to: • Look for the product number in the remote inventory. • Update the Stock table, reducing the quantity on hand if the quantity available is sufficient. • Look for an alternative product if the requested one is out of stock, and update the corresponding quantity. • Pass the product information back to the calling program. e. The stored procedure then passes control back to the calling program. f. At this point, the program sets a connection to the local system and if the user accepts the record, the new item is inserted in the Order Detail file, and the whole transaction is committed. If the user rejects the item, a rollback brings the stock quantity on hand back to its original value. g. A rollback is also performed if referential integrity checking on the Order Detail table fails. This happens if you insert the record with the wrong order number. h. The user also has the option of cancelling the whole order. In this case, a Cancel Order program is called. i. The program keeps a work field with the final totals of the whole order. When the entire order is completed, this value is passed to the next program – Finalize Order. Program flow for the Finalize Order program The DB2 Universal Database for iSeries functional highlights in this program include the trigger on the Update Order Header row. See Figure A-3 for the program flow. 334 Advanced Functions and Administration on DB2 Universal Database for iSeries Figure A-3 Finalize Order program flow Program description for the Finalize Order program The idea of this program is to show how to use the following new database functions in a real application:  Database triggers: In this scenario, a program is triggered after the order header row is updated with the total amount of the order. This program prints the invoice at the branch office as soon as the order has been completed. The program also updates the credit limit on the customer file. If the current balance exceeds 90% of the credit limit, a “warning” fax is automatically sent to the customer by a trigger program to allow the customer to take the appropriate actions (for example, applying for a credit limit increase, based on the credit history of the customer).  Program description: This program can: a. Get the customer number and the order number from the previous process along with the order grand total. A MORE ORDERS ? COMMIT END OK ROLLBACK ? SEND MESSAGE N UPDATE ORDER HEADER UPDATE SALES/ CUSTOMERS UPDATE CUSTOMERS OK ? TRIGGER ON UPDATE FAX CREDIT LIMIT >= ORDER TOTAL = OK DELETE ORDER SEND MESSAGE A CASCADE DELETE ORDER DETAIL TRIGGER ON UPDATE INVOICE WRITING CHECK CREDIT LIMIT READ CUSTOMER FROM ORDER DETAIL PROGRAM CUSTOMER#, ORDER #, ORDER TOTAL TAKE INPUT E Appendix A. Order Entry application: Detailed flow 335 b. Check the customer record. If the credit limit is exceeded, the order is cancelled. To delete the order, the detail is scanned, and the inventory quantity that is on hand for each item is updated by adding the amount reserved for this order. When this process is complete, the order header is deleted, and all the order detail disappears as a result of the *CASCADE constraint on the order header file. The entire transaction is finally committed. Again, the two-phase commit support ensures that the local database and the remote stock file are kept synchronized. c. If the credit limit is OK, this program updates the following fields: • The total amount in the customer file to keep track of the customer balance • The total amount in the Sales Representative/Customer table to reflect the sales person's turnover with the customer • The total amount in the Order Header table items at invoice time d. Because an update trigger is specified on the Order Header table, an invoice program is started immediately. The invoice for the completed order is printed in the branch office. For more information about triggers, see Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503. e. After the preceding updates have been done, COMMIT is executed. f. If there are more orders, the Insert Order Header program is started again. g. If there are no more orders, this Order Entry application has ended. 336 Advanced Functions and Administration on DB2 Universal Database for iSeries © Copyright IBM Corp. 1994, 1997, 2000, 2001 337 Appendix B. Referential integrity: Error handling example This appendix provides an example of a COBOL program that illustrates a coding example of the error handling when you use referential integrity. In the following example, you can see a COBOL SQL implementation of this a procedure. The operation that activates the trigger and the referential integrity check is highlighted in bold. Immediately after the SQL insert, the application checks the SQLCODE for errors and reports the correct message to the user. B 338 Advanced Functions and Administration on DB2 Universal Database for iSeries Program code: Order Header entry program – T4249CINS PROCESS OPTIONS. IDENTIFICATION DIVISION. PROGRAM-ID. T4249CINS. AUTHOR. PROGRAMMER NAME. INSTALLATION. ITSC LABORATORY. DATE-WRITTEN. APRIL 2001. DATE-COMPILED. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-AS400. OBJECT-COMPUTER. IBM-AS400. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT T4249OHRD ASSIGN TO WORKSTATION-T4249OHRD ORGANIZATION IS TRANSACTION FILE STATUS IS STATUS-ERR. ********************************************************** DATA DIVISION. FILE SECTION. FD T4249OHRD LABEL RECORD ARE STANDARD. 01 DSP01. COPY DDS-ALL-FORMATS OF T4249OHRD. *********************************************************** WORKING-STORAGE SECTION. 01 DSPFIL-INDICS. COPY DDS-ALL-FORMATS-INDIC OF T4249OHRD. 77 IND-ON PIC 1 VALUE B"1". 77 IND-OFF PIC 1 VALUE B"0". 01 JOBA-AREA. 03 BYTES-RTN PIC 9(8) BINARY VALUE 0. 03 BYTES-AVAIL PIC 9(8) BINARY VALUE 0. 03 JOBNAME PIC X(10). 03 USERNAME PIC X(10). 03 JOBNUMBER PIC X(6). *=================================================* * Parameters for retrieve job atributes - USERID * *=================================================* 01 RTV-JOBA. 03 RTV-JOB-VAR PIC X(50). 03 RTV-JOB-LEN PIC 9(8) BINARY VALUE 50. 03 RTV-JOB-FMT PIC X(8) VALUE "JOBI0400". 03 RTV-JOB-NAME PIC X(26) VALUE "*". 03 RTV-JOB-ID PIC X(16) VALUE " ". 01 STATUS-ERR PIC XX. 01 ORDNUM PIC X(5). 01 CUSTOMER PIC X(5). 01 ODATE PIC X(10). 01 ODLY PIC X(10). Appendix B. Referential integrity: Error handling example 339 01 OTOTAL PIC S9(9)V9(2) COMP-3. 01 INSERTOK PIC 9. EXEC SQL INCLUDE SQLCA END-EXEC. LINKAGE SECTION. 01 CUSTNBR PIC X(5). 01 ORDNBR PIC X(5). 01 RTCODE PIC X. *========================================================* *This program has three output parameters: Customer numb.* *Order number and Return code. The return code can be: * *Rtcode = 0 - OK Rtcode = 2 - F3 * *========================================================* PROCEDURE DIVISION USING CUSTNBR, ORDNBR, RTCODE. DECLARATIVES. TRANSACTION-ERROR SECTION. USE AFTER STANDARD ERROR PROCEDURE T4249OHRD. WORK-STATION-ERROR-HANDLER. GOBACK. END DECLARATIVES. MAIN-LINE SECTION. OPEN I-O T4249OHRD. PERFORM INITIAZ-HEADER. *=============================================* * Call API to get job atributes and move the * * output parameter into the work area * *=============================================* CALL "QUSRJOBI" USING RTV-JOB-VAR, RTV-JOB-LEN, RTV-JOB-FMT, RTV-JOB-NAME, RTV-JOB-ID. MOVE RTV-JOB-VAR TO JOBA-AREA. MOVE "0" TO RTCODE. MOVE 0 TO INSERTOK. MOVE IND-OFF TO IN15 IN ORDER-I-INDIC. WRITE DSP01 FORMAT IS "EXITLINE". PERFORM ORDER-ENTRY UNTIL IN15 IN ORDER-I-INDIC EQUAL IND-ON OR INSERTOK EQUAL 1. IF IN15 IN ORDER-I-INDIC = IND-ON THEN MOVE "2" TO RTCODE ELSE IF INSERTOK = 1 THEN MOVE "0" TO RTCODE. *===============================================================* *We are not closing the file, because we are overlapping screens* *===============================================================* * CLOSE T4249OHRD. GOBACK. 340 Advanced Functions and Administration on DB2 Universal Database for iSeries ORDER-ENTRY. PERFORM WRITE-READ-ORDER. MOVE ORHNBR OF ORDER-I TO ORDNUM. MOVE CUSNBR OF ORDER-I TO CUSTOMER. MOVE ORHDTE OF ORDER-I TO ODATE. MOVE ORHDLY OF ORDER-I TO ODLY. MOVE ZEROS TO OTOTAL. MOVE CUSTOMER TO CUSTNBR. MOVE ORDNUM TO ORDNBR. IF IN15 IN ORDER-I-INDIC NOT EQUAL IND-ON THEN * * The programs inserts an order in ORDERHDR file. * EXEC SQL INSERT INTO ORDENTL/ORDERHDR VALUES(:ORDNUM, :CUSTOMER, :ODATE, :ODLY, :OTOTAL, :USERNAME) :rk.4:erk. END-EXEC IF SQLCODE EQUAL 0 THEN MOVE 1 TO INSERTOK ELSE *==========================================================* * After the insert operation, you should monitor the * * following SQLCODEs: * * SQL0530(-530) - Referential Integrity violation * * SQL0803(-803) - Order Header already exists * * SQL0443(-443) - Trigger program signalled an exception * *==========================================================* IF SQLCODE EQUAL -530 THEN MOVE IND-ON TO IN98 OF ORDER-O-INDIC MOVE SPACES TO ORHNBR OF ORDER-O MOVE CUSTOMER TO CUSNBR OF ORDER-O ELSE IF SQLCODE EQUAL -803 THEN MOVE IND-ON TO IN99 OF ORDER-O-INDIC ELSE MOVE IND-ON TO IN97 OF ORDER-O-INDIC. ************************************************************* INITIAZ-HEADER. MOVE SPACES TO ORHNBR OF ORDER-O. MOVE SPACES TO CUSNBR OF ORDER-O. MOVE "0001-01-01" TO ORHDTE OF ORDER-O. MOVE "0001-01-01" TO ORHDLY OF ORDER-O. WRITE-READ-ORDER. WRITE DSP01 FORMAT IS "ORDER" INDICATORS ARE ORDER-O-INDIC. MOVE IND-OFF TO ORDER-I-INDIC ORDER-O-INDIC. READ T4249OHRD RECORD INDICATORS ARE ORDER-I-INDIC. © Copyright IBM Corp. 1994, 1997, 2000, 2001 341 Appendix C. Additional material This redbook also contains additional material that is available on the Web. See the following sections for instructions on using or downloading the Web material. Locating the Web material The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp://www.redbooks.ibm.com/redbooks/SG244249 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, SG244249. Using the Web material The additional Web material that accompanies this redbook includes the following files: File name Description dbadvfun.exe iSeries and client source code image readme.txt Readme documentation System requirements for downloading the Web material The following list contains the most important requirements:  iSeries requirements – OS/400 Version 5 Release 1 – 5722-ST1 - DB2 Query Manager and SQL Development kit – 5722-SS1 - Host Servers C 342 Advanced Functions and Administration on DB2 Universal Database for iSeries  PC software – Windows 95/98, Windows NT, or Windows 2000 – Client Access Express for Windows – PC5250 Emulation How to use the Web material Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder. The readme.txt contains the instructions for restoring the iSeries libraries and directories, as well as installing the PC clients and run-time notes. © Copyright IBM Corp. 1994, 1997, 2000, 2001 343 Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. IBM Redbooks For information on ordering these publications, see “How to get IBM Redbooks” on page 344.  DB2/400: Mastering Data Warehousing Functions, SG24-5184  AS/400 Internet Security: Implementing AS/400 Virtual Private Networks, SG24-5404  DB2 UDB for AS/400 Object Relational Support, SG24-5409  Cross-Platform DB2 Stored Procedures: Building and Debugging, SG24-5485  Managing AS/400 V4R4 with Operations Navigator, SG24-5646  Stored Procedures and Triggers on DB2 Universal Database for iSeries, SG24-6503 The following IBM Redbooks will be available in first quarter 2002:  Managing OS/400 with Operations Navigator V5R1 Volume 1: Basic Functions, SG24-6226  Managing OS/400 with Operations Navigator V5R1 Volume 2: Advanced Functions, SG24-6227 Other resources These publications are also relevant as further information sources:  DB2 Connect Personal Edition Quick Beginning, GC09-2967  COBOL/400 User’s Guide, SC09-1812  COBOL/400 Reference, SC09-1813  ILE RPG Programmer’s Guide, SC09-2074  ILE RPG Reference, SC09-2077  DB2 UDB Application Development Guide V6, SC09-2845  AS/400 National Language Support, SC41-5101  Backup and Recovery, SC41-5304  Work Management, SC41-5306  Distributed Data Management, SC41-5307  Client Access Express for Windows, SC41-5509  ILE Concepts, SC41-5606  SQL Programming Guide, SC41-5611  SQL Reference, SC41-5612  Database Programming, SC41-5701  Distributed Database Programming, SC41-5702 344 Advanced Functions and Administration on DB2 Universal Database for iSeries  DDS Reference, SC41-5712  Control Language Programming, SC41-5721  CL Reference, SC41-5722  System API Programming, SC41-5800  SQL Call Level Interface, SC41-5806  DB2 UDB for iSeries Database Performance and Query Optimization: http://submit.boulder.ibm.com/pubs/html/as400/bld/v5r1/ic2924/index.htm Referenced Web sites These Web sites are also relevant as further information sources:  iSeries Information Center: http://www.iseries.ibm.com/infocenter  DB2 Universal Database for iSeries main page: http://www.iseries.ibm.com/db2/db2main.htm  PartnerWorld for Developer - iSeries site: http://www.iseries.ibm.com/developer  Support Line Knowledge Base: http://as400service.ibm.com/supporthome.nsf/document/10000051  Data Movement Utilities Guide and Reference: http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/ document.d2w/report?fn=db2v7dmdb2dm07.htm#HDREXPOVW  iSeries Library: http://www-1.ibm.com/servers/eserver/iseries/library  IBM Learning Services: http://www-1.ibm.com/servers/eserver/iseries/education/ How to get IBM Redbooks Search for additional Redbooks or Redpieces, view, download, or order hardcopy from the Redbooks Web site: ibm.com/redbooks Also 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. IBM Redbooks collections Redbooks are also available on CD-ROMs. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered, as well as updates and formats. © Copyright IBM Corp. 1994, 1997, 2000, 2001 345 Special notices 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 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. 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. 346 Advanced Functions and Administration on DB2 Universal Database for iSeries PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. SET, 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. © Copyright IBM Corp. 1994, 1997, 2000, 2001 347 Index Symbols *DUW option 93 *FILE object 160 *RUW option 93 *SHRUPD 35 Numerics 01222 status 51 A access path 5, 25, 181 activation group 92, 93 activation group ID 96 active jobs 118 add column 186 Add Relational Database Directory Entry (ADDRDBDIRE) command 110 Add Server Authentication Entry (ADDSVRAUTE) command 111 adding multiple constraints 32 referential constraint 28 relational database directory entry 110 server authentication entry 111 ADDPFCST (Add Physical File Constraint) command 28 ADDRDBDIRE (Add Relational Database Directory Entry) command 110 ADDSVRAUTE (Add Server Authentication Entry) command 111 administrative interface 124 advanced functions 6, 11 advanced journal attributes 180 Advised Index 230 alias 168, 182 ALTER TABLE SQL statement 28, 188 ALTER TABLE statement DROP clause 56 Analyze Results panel 228 analyzing SQL Performance Monitor results 228 application design 101 application example 12 application flow using DRDA-2 94 application integrity 22 application message 78 application requester (AR) 84, 110 application server (AS) 84, 93 apply journal changes 49, 53 AR (application requester) 84 AS (application server) 84 ASP (auxiliary storage pool) 167 authentication information 111 automatic recovery 96 auxiliary storage pool (ASP) 167 B breadth cascade 43 business rules referential integrity 22 translated to physical file constraints 32 C C ILE program referential integrity messages 52 CASCADE delete rule 35 CASCADE example 39 cascade network 28 CASCADE rule 23, 25 catalog inquiry 63 CCSID (Coded Character Set Identifier) 187, 205 Change DDM TCP/IP Attributes (CHGDDMTCPA) command 109 Change Physical File Constraint (CHGPFCST) command 53 Change Query Attributes 164, 217 Change Query Attributes (CHGQRYA) command 137 Change Server Authentication Entry (CHGSVRAUTE) command 112 check constraint 7, 24, 67, 192 application message 78 DB2 UDB for iSeries 69 defining 70 I/O message 77 integration into applications 77 management 79 state 80 tips and techniques 82 check pending 53 condition 71 defined 24 protection from 49 CHGDDMTCPA (Change DDM TCP/IP Attributes) command 109 CHGPFCST (Change Physical File Constraint) command 53 CHGQRYA (Change Query Attributes) command 137 CHGSVRAUTE (Change Server Authentication Entry) command 112 Client Access/400 6 COBOL deleting an order 103 DRDA-2 program example 102 ILE program, referential integrity messages 52 Coded Character Set Identifier (CCSID) 187, 205 coexistence for DRDA-1 and DRDA-2 95 collection 166 column 5 command 181 CHGDDMTCPA 109 STRTCPSVR SERVER(*DDM) 110 348 Advanced Functions and Administration on DB2 Universal Database for iSeries command, CL 206 Add Physical File Constraint (ADDPFCST) 28 Add Relational Database Directory Entry (ADDRDBDIRE) 110 Add Server Authentication Entry (ADDSVRAUTE) 111 ADDRDBDIRE (Add Relational Database Directory Entry) 110 ADDSVRAUTE (Add Server Authentication Entry) 111 Change Server Authentication Entry (CHGSVRAUTE) 112 Copy From Import File (CPYFRMIMPF) 126 Copy To Import File (CPYTOIMPF) 126 CRTSQLpgm 93 CRTSQLxxx 101 Print SQL Information (PRTSQLINF) 303 Remove Server Authentication Entry (RMVSVRAUTE) 112 Start Debug (STRDBG) 118 Work with Active Jobs (WRKACTJOB) 118 commit 204 commit group 204 commit mode 204 COMMIT(*NONE) 95 commitment control 43, 204 requirements 25 commitment definition 97 condition clause 70 condition clause of check constraint 75 CONNECT 88 SQL statement 84, 92 CONNECT (Type 1) 92 CONNECT (Type 2) 93 connection current 88 dormant 88 held 88 multiple handling in DRDA-2 101 preserved 7 released 88 states 88 connection DRDA 101 connection management 86 methods 88 on DB2 UDB for iSeries 87 consistency of data in multiple locations 90 constraint 181, 188, 192 commands 53 displaying information 61 domain 68 enforcement 35 management 52 prerequisites 24 referential integrity network example 32 removing 56 self-referencing 34 states 52 table 68 tips 192 types 22 unique or primary key 29 Control Center 149 copy 183 Copy From Import File (CPYFRMIMPF) command 126 Copy To Import File (CPYTOIMPF) command 126, 138 CPF502D notify message 51 CPF502E notify message 51 CPF503A notify message 51 CPF523B escape message 51 CPF523C escape message 51 CPU bound 316 CPYFRMIMPF (Copy From Import File) command 126 CPYTOIMPF (Copy To Import File) command 126, 138 create journal 177 Create Physical File (CRTPF) command 170 create SQL package 114 CREATE TABLE SQL statement 28, 160 CREATE VIEW 160, 162 creating a referential constraint 28 CRTPF (Create Physical File) command 170 CRTSQLpgm 93 CRTSQLpgm command 93 CRTSQLxxx command 101 current SQL statement 218 current state 89 cut 183 cyclic constraint 24 D data access distributed 84 distributed environment 84 methods 305 data consistency 90 Data Description Specifications (DDS) 5 data field 5 data format 127, 139 data inconsistencies 49 data load Data Definition Language example 133 file definition file example 130 data loss 49 data source translation 203, 205 data, invalid check pending 53 database administration 157 Database functions 163 database library functions 165 Database Monitor 303 Visual Explain 318 Database Navigator 8, 239 locator pane 247 map pane 249 menu options 249 system requirements and planning 240 Database Navigator map 244 creating 261 display 253 generating SQL 289 icons 269 Index 349 interface 246 table options 255 database performance analysis methodology 323 database relationship 242 database synchronization on multiple systems 96 Database task pad 246 database tuning 302 DB2 Connect 120 AS/400 port number 123 CCSID for user profile 121 over TCP/IP 120 DB2 family 4 DB2 UDB 7.2 data migration to DB2 UDB for iSeries 149 DB2 UDB for iSeries 3 advanced functions 6 check constraint 69 distributed environment 5 DRDA-2 86 Import utility 126 journaling 124 moving data to DB2 UDB 7.2 152 Operations Navigator 161 overview 4 programming languages 272 sample schema 8 SQL support for connection management 92 DDM (Distributed Data Management) 5 DDM server job 109, 122 DDS (Data Description Specifications) 5 debug messages 302 debug mode 220 default libraries 204 define check constraint 72 DEFINED constraint state 52 DEL (delimited ASCII file) 149 delete 183, 193 delete column 186 delete constraint 56 delete parent record example 36, 38 delete rows 183 delete rule CASCADE, SET NULL, and SET DEFAULT 35 defined 23 deleted record 170 deleting an order 103 DRDA-2 and two-phase commitment control 103 COBOL example 103 delimited ASCII file (DEL) 149 delimited import file 128 dependent file defined 23 same file as parent file 34 dependent table 68 depth cascade 43 detail rows 105 DISABLED constraint state 52 DISCONNECT 90 DISCONNECT statement 93 Display Check Pending Status (DSPCPCST) command 54 Display Database Relations (DSPDBR) command 61 Display Journal Entry Details display 45 Display Physical File Description (DSPFD) command 61 distributed data access 84 Distributed Data Management (DDM) 5 distributed database example 14 distributed database network 87 distributed environment 5 data access in 84 Distributed Relational Database Architecture (DRDA) 6, 84, 201 distributed relational database example 13 Distributed Request (DR) 86 Distributed Unit of Work (DUW) 7, 85 DLTPCT parameter 170 domain constraint 68 dormant state 89 DR (Distributed Request) 86 DRDA 6, 83, 84 application server 108 COMMIT(*NONE) 95 Distributed Unit of Work 7 initial connections 101 level 0 85 level 1 85 level 2 85 level 3 86 DRDA (Distributed Relational Database Architecture) 6, 84, 201, 202 DRDA over TCP/IP 108 troubleshooting 117 DRDA-1 86 coexistence with DRDA-2 95 moving to DRDA-2 101 DRDA-2 86 application flow example 94 Coexistence 95 coexistence with DRDA-1 95 CONNECT 92 connection management 87 connection management method 88 Connection Management on DB2 UDB for iSeries 87 DISCONNECT, DB2 UDB for iSeries 90, 93 performance 101 program example 102 protected conversation 90 RDB Connection Management Method 88 RELEASE, DB2 UDB for AS/400 93 SET CONNECTION 94 Synchronization Point Manager (SPM) 90 two-phase commit 90 unprotected conversation 90 DRDA-2 and two-phase commitment control 105 drop active connections 93 DROP clause of ALTER TABLE statement 56 DSPCPCST (Display Check Pending Status) command 54 DSPDBR (Display Database Relations) command 61 DSPFD (Display Physical File Description) command 61 DUW (Distributed Unit of Work) 7, 85 350 Advanced Functions and Administration on DB2 Universal Database for iSeries E Edit Check Pending Constraints (EDTCPCST) command 58 edit recovery for access path 181 Edit SQL 176 EDTCPCST (Edit Check Pending Constraints) command 58 ENABLED constraint state 52 error handling example 337 escape message 51 ESTABLISHED constraint state 52 example 103 application flow using DRDA-2 94 CASCADE 39 delete parent record 36 no RESTRICT or NOACTION rule 38 Display Journal Entry Details display 45 distributed relational database 13 DRDA-2 program, COBOL 102 inserting the detail rows 105 logical consistency 13 multiple constraints 32 Order Entry application overview 12 referential integrity network 32 SQL CREATE TABLE 29 unmatched foreign key values 28 Explainable Statement 231 Export API 151 Export command 151 Export utility 125, 138, 149, 152 F failure recovery 96 field definition file 127 field level authority 162 file availability 28 Finalize Order program 333 flyover 254 foreign key 35 constraint prerequisites 24 defined 23 in same physical file as primary key 34 foreign key value verification 28 function, user defined 168 G Generate SQL 271, 272 from Database Navigator map 289 from DDS 297 Operations Navigator 276 to PC and data source files 281 H held state 89 hierarchical structure 34 I I/O bound 316 I/O messages 50, 77 ILE C example 114 ILE C programs 52 ILE COBOL programs 52 ILE program 102 ILE RPG programs 51 implicit primary key constraint 31 import file 138 Import utility 125, 126, 149, 153 Include Debug Messages in Job Log 214 Include Error Message Help in Run History 213 index 168, 181, 188 indexes for referential integrity 25 Informix 86 initial DRDA connection 101 Insert Order Detail program 331 Insert Order Header program 330 insert rows 183 inserting detail rows 105 integrated exchange file (IXF) 149 integrated relational database 4 Interactive SQL 113 invalid data check pending 53 IXF (integrated exchange file) 149 J Java Database Connectivity (JDBC) 202 Java stored procedures See also stored procedures Java JDBC (Java Database Connectivity) 202 job log 97 JOIN statement 214 journal 167, 177, 181, 192 journal changes 49 journal entries with referential integrity 45 journal entry 177 journal example 177 journal receiver 177, 178, 181, 192 journaling 43, 124 journaling requirements 25 journals 168 K key constraints 188 key types defined 22 keyed access path 26 keyed logical file 5 L lab exercise 230 Level Check (LVLCHK) parameter 186 library 166, 167 library name 208 library-based functions 168 like operating environments 84 loader utility 126 Index 351 locator pane 247 lock file 28 locked rows 196 locking files 35 log not written 95 logical consistency example 13 logical file 5 logical transaction 85 Logical Unit of Work ID 96 loss of data 49 M manual recovery 97 map pane 249 mapping referential integrity messages 52 maximum members 170 member size 170 messages CPF502D 51 CPF502E 51 CPF503A 51 CPF523B 51 CPF523C 51 referential integrity 50 Modify Selected Queries 229 multiple connections 7 multiple constraints 32 multiple databases 7 multiple locations, data consistency in 90 N network coexistence of DRDA-1/DRDA-2 95 referential integrity or cascade 28 new journal receiver 193 attributes 181 no RESTRICT or NOACTION rule 38 NOACTION rule 35 defined 24 delete example without 38 enforcement 35 non-SQL interface considerations 320 notify messages 51 NULLID collection 121 O object-based function 181 Objects to Display window 253 ODBC (Open Database Connectivity) 6, 202 Open 182 Open Database Connectivity (ODBC) 6, 202 openness 86 Operations Navigator Generate SQL 276 new V5R1 features 159 Visual Explain 301 OPM programs 101 Oracle 86 Order Entry application 11, 12 advanced database functions 17 database 14 detailed flow 329 Order Entry example 12 Order Header entry program 338 orphan foreign key values example 28 OS/400 collection 166 OS/400 library 166 ownership of access path 25 P parallel data load data format 127, 139 delimited import file 128 field definition file 127 source file (FROMFILE) 127, 138 target file (TOFILE) 127, 139 parallel data loader 137 parent file defined 23 same file as dependent file 34 parent key constraint prerequisites 24 defined 23 identifying 29 parent record delete example 36 no RESTRICT or NOACTION rule 38 parent table 68 PC user integrity 22 performance 93 benefits of system provided referential integrity 22 DRDA-2 considerations 101 improved 25 referential integrity application impacts 50 when adding referential constraint 28 performance collection files 205 Permissions 193 permissions 168, 181 physical data 5 physical file 5, 32, 170 add multiple constraints 32 constraints referential integrity network example 32 port number for DRDA connection 123 predictive query governor 303 primary key 23, 29 constraint 23, 29, 31 defined in SQL 29 in same physical file as foreign key 34 properties 168, 193 protected conversation 90, 93 protocols 84 PRTSQLINF (Print SQL Information) command 303 Q QBATCH 207 QRWTLSTN job 110, 117 352 Advanced Functions and Administration on DB2 Universal Database for iSeries QRWTSRVR job 117 query attributes and values 315 query environment Visual Explain query environment 314 query optimizer 220 debug messages 302 Query/400 234, 320 quick view 182 R RDB Connection Management Method 93 RDB parameter 101 RDBCNNMTH parameter 93 RDBCNNMTH(*DUW) 88 RDBCNNMTH(*RUW) 88 read lock 35 record 5 record field 5 record selection 5 recovery 96 automatic 96 from failure 96 manual 97 Work with Commitment Definitions (WRKCMTDFN) command 98 Redbooks Web site 344 Contact us xii Ref Constraint parameter 45 referential constraint 28, 188 creating 29 defined 23 dependent file 31 enforcement 35 example 30 rules 23 referential cycle 24 referential integrity 17, 21, 25, 49 application considerations 50 check pending 53 concepts 22 constraint 18, 24, 68 concept 18 prerequisites 24 constraint management 52 constraint tips and techniques 82 defined 7, 23 error handling 337 example 13 I/O messages 50 introduction 22 journal entries 45 journaling and commitment control 43 message handling in applications 51 messages in RPG ILS programs 51 network 28 relationship 24 restoring data 49 rules ordering 36 SQLCODE values 52 verification queries 28 referential integrity messages in ILE C programs 52 in ILE COBOL programs 52 in ILE RPG programs 51 relational database directory 110 directory entry 110 integration overview 4 RELEASE statement 93 released state 89 remote journal 177, 181, 193 remote locations 84 remote request 85 Remote Request (RR) 85 remote stored procedure 114 using DRDA over TCP/IP 113, 114 Remote Unit of Work (RUW) 85, 93 remove constraint 56 remove internal entries 181 remove journal changes 49, 53 Remove Physical File Constraint (RMVPFCST) command 56 Remove Server Authentication Entry (RMVSVRAUTE) command 112 reorganize 182 reorganize file/table 170 restoring data 49 RESTRICT rule 25, 35 defined 24 delete example without 38 enforcement 35 retain server security data 111 reused connections 93 REUSEDLT parameter 170 reverse engineering 271, 272 RMVPFCST (Remove Physical File Constraint) command 56 RMVSVRAUTE (Remove Server Authentication Entry) command 112 RNQ1222 inquiry message 51 RNX1222 escape message 51 rollback 87, 204 root value 34 row 5 RPG ILE program, referential integrity messages 51 RR (Remote Request) 85 rules 84 enforcement 35 ordering for referential integrity 36 referential integrity 22 Run and Explain option 307 Run History pane 200 Run SQL Script DDM/DRDA configuration summary 216 example using VPN journal 208 Run SQL Scripts 164, 166, 182, 183, 197 Run option 210 running CL in SQL Scripts 208 Index 353 S save and restore 53, 59, 81 Screen Edit Utility (SEU) 131 self study lab 160 self-referencing constraint 34 semantics 84 SET CONNECTION 89 SET CONNECTION statement 94 SET DEFAULT delete rule 35 SET DEFAULT rule 24 SET NULL delete rule 35 SET NULL rule 23 SEU (Screen Edit Utility) 131 shared access path for referential integrity 25 shared lock 35 side-effect journal entry 45 SMAPP 181 Smart Statement Selection 213 SMP (Symmetric MultiProcessing) 137 source file (FROMFILE) 127, 138 span multiple databases 7 SPM (Synchronization Point Manager) 86, 90 SQL 84, 225 collection 167 connect statements 92 index 25 SQL (Structured Query Language) 5 SQL CREATE TABLE statement example 29 SQL index 5 SQL naming convention (operational difference) 206 SQL performance analysis 323 SQL Performance Monitor 213, 220, 228 analyzing summary results 228 detailed monitor analysis 230 reviewing results 226 SQL procedure 168 SQL script running a CL command 206 tips for running CL 208 SQL Script Center 306 SQL statements CONNECT 84 CREATE TABLE/ALTER TABLE 28 SQL TABLE 170 SQL table 5 SQL Trigger 188 SQL view 5 SQL VIEW example 172 SQL-92 standard 68 SQLCODE values 52 Start Debug (STRDBG) command 118 starting and ending journaling 193 starting the SQL Performance Monitor 222 status 01222 51 Stop on Error 213 stored procedures 7 STRDBG (Start Debug) command 118 STRTCPSVR SERVER(*DDM) command 110 Structured Query Language (SQL) 5 swap receivers 193 Sybase 86 Symmetric MultiProcessing (SMP) 137 Synchronization Point Manager (SPM) 86, 90 system failure check pending 53 system naming convention, operational difference 206 T table 162, 167, 168, 181, 182 table constraint 68 table options 255 target file (TOFILE) 127, 139 task pad 246 TCP/IP 108 application requester 110 configuring on the application server 109 DB2 Connect access to iSeries 120 transaction atomicity 43 transaction isolation 95 tree relationship among records in database 34 triggers 7, 181, 188 troubleshooting DRDA over TCP/IP 117 two-phase commitment control 7, 83, 86, 90 needs assessment 18 U unique constraint 23, 29 defined in SQL 29 unique key 23 unit of recovery (UR) 85 unit of work (UoW) 85, 87 unlike operating environments 84 unprotected connections 93 unprotected conversation 90 UoW (unit of work) 85 update lock 35 update row 183 update rule 24 UR (unit of recovery) 85 user defined function 168 user defined type 168 user-defined relationship 266 V verification of foreign key value 28 verification queries 28 view 167, 168, 182 view of physical data 5 View Results button 229 Visual Explain 212, 301, 304 data access methods 305 Database Monitor data 318 icons 321 navigation 308 query attributes and values 315 Query/400 320 SQL performance analysis 323 SQL Script Center 306 Visual Explain Only option 307 354 Advanced Functions and Administration on DB2 Universal Database for iSeries VPN journal 208 W Work with Active Jobs (WRKACTJOB) command 118 Work with Commitment Definition (WRKCMTDFN) command 98 Work with Physical File Constraints (WRKPFCST) command 57 worksheet format file (WSF) 149 writing for DRDA programs 84 WRKACTJOB (Work with Active Jobs) command 118 WRKCMTDFN (Work with Commitment Definition) command 97, 98 WRKPFCST (Work with Physical File Constraints) command 57 WSF (worksheet format file) 149 X XDB Systems 86 (0.5” spine) 0.475”<->0.873” 250 <-> 459 pages Advanced Functions and Administration on DB2 Universal Database for iSeries ® SG24-4249-03 ISBN 0738422320 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 Advanced Functions and Administration on DB2 Universal Database for iSeries Learn about referential integrity and constraints See how Database Navigator maps your database Discover the secrets of Visual Explain Dive into the details of DB2 Universal Database for iSeries advanced functions and database administration. This IBM Redbook equips 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 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. Back cover

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

Standard HTML Page with PHP HelloWorld Generated with PHP"; ?> This is as simple as it gets. The file starts as a normal HTML file. We simply insert PHP statements following the The result of our PHP program would be similar to what is shown in Figure 2. This is a dynamic Web page that contains the name of our Web server and a table built by PHP with details about how PHP is configured on our Web server. This is accomplished by using one of several predefined PHP variables (for example HTTP_HOST) and the PHP function phpinfo. Bringing PHP to Your IBM iSeries Server 5 Figure 2 Dynamic Web page generated by the PHP ‘Hello World’ script PHP on iSeries An iSeries user has two options to set up PHP. You can use PHP with OS/400’s Portable Application Solutions Environment (OS/400 PASE) and the HTTP Server (powered by Apache). Or you can install a Linux logical partition (LPAR) and run Apache and PHP in that partition. Table 1 shows factors to consider before you make this decision. Table 1 Which is for you? PHP as a CGI in PASE versus PHP in a Linux LPAR Factors to consider PHP in PASE and Apache PHP in Linux LPAR OS/400 requirements You should have V5R1 or newer. This should work for V4R5 - but we have not tried it ourselves. You must have V5R1 or newer with specific hardware to run Linux. Cost A cost is associated with PASE (becomes free in V5R2). Note: in V5R1 and prior releases PASE was a nominal fee of around 100 US dollars. A cost is associated with Linux distribution. Setup required No setup is required to use PASE. Some setup associated with the creation of a Linux partition, user IDs, etc., and extra LPAR requires some dedicated processor resource. 6 Bringing PHP to Your IBM ^ iSeries Server If you plan to install PHP on an iSeries server you need to be at V5R1 or later (as we mentioned in Table 1 this could work for V4R5 - but we have not tried it ourselves) and have PASE installed. PASE is the AIX runtime support for iSeries. See “Prerequisites” on page 11 to see if you have the “right stuff” for running PASE on your AS/400® or iSeries hardware. If you plan to install PHP on a Linux LPAR, PHP is most likely included with your Linux distribution. If not, the installation instructions are virtually identical to those found in the PHP distribution itself and in the PHP site FAQs at: http://cvs.php.net/co.php/php4/INSTALL Regardless of where you install PHP, the configuration is the same. To get the Apache Web server to recognize PHP files, you must change the Web server configuration file to include some script aliases for PHP: ScriptAlias /php-bin/ /usr/local/php/bin AddType application/x-httpd-php .php Action application/x-httpd-php /php-bin/php The directory where PHP is installed may differ. PHP as a CGI-BIN program The next example shows a traditional HTML form that uses the Action tag to invoke a CGI-BIN program when a user clicks the Submit button. In this example, the CGI-BIN program is actually a PHP program that processes the fields in the HTML form and uses that information to query a DB2 database. The database we use is called SAMPLE. SAMPLE is actually shipped with V5R1. To create it, follow the instructions at “Creating a sample database” on page 16 in this redpaper. Figure 3 shows the basic HTML form that we use to perform a database query. Our system name is LPAR3NVM. Availability and compatibility You must obtain PHP from these instructions and have AIX skills to compile PHP as new versions come out. Linux will be most compatible with new versions of PHP as they come out. mySQL mySQL is unavailable in PASE by default. You must download and compile it if desired. mySQL is available as an alternative database (it's fairly common to use mySQL with PHP applications). Web server module PHP cannot be a Web server module. It must be a CGI-bin process only. This matters only in extremely performancecritical Web sites. PHP can be installed as an Apache module. Database An ODBC driver is not necessary. To use iSeries DB2 UDB, you must download, install, and configure iSeries ODBC Driver for Linux. This UNIX-based ODBC is free from IBM. It uses sockets to communicate between the Linux LPAR and the iSeries LPAR. Factors to consider PHP in PASE and Apache PHP in Linux LPAR Bringing PHP to Your IBM iSeries Server 7 Figure 3 Basic HTML form used to perform a database query Figure 4 shows the results of our query. Each record returned has been placed in a table row. Figure 4 Results of the query 8 Bringing PHP to Your IBM ^ iSeries Server Here is the dbqueryphp.php script where the actual work is done:
PHP DB Query Tester
Query performed:
Results:
Error ".odbc_error().":".odbc_errormsg().""); elseif (odbc_num_rows($result)==0): echo("Query ran successfully"); else: ?> ".odbc_field_name($result,$i+1).""); } ?> "); for ($j =0;$j ".$row_array [$j ] . ""); } echo(""); } echo("
"); endif; } elseif ($host || $database || $query) { echo("All three fields must be filled in for a query
"); } else { echo("Use PHP to run an SQL Query on an iSeries database:
"); } ?>

Bringing PHP to Your IBM iSeries Server 9
iSeries Host:

Library of the database to query:

Please enter the SQL query to be run:

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 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.

PHPACTJOB Test PHP with WRKACTJOB Output

PHP Running WRKACTJOB in PASE
"; print ""; print "

";
print $line;
print "
"; print ""; while ($line = strtok("\n")) { print ""; print "
$line
"; 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 Options +ExecCGI order allow,deny allow from all Stop and start your HTTP Server (powered by Apache) Web server. Creating a sample database Here we could add the creation of the sample database as supplied with the system. Starting in V5R1, a sample database is shipped with the system. This is explained on the Web at: http://www.ibm.com/servers/eserver/iseries/db2/sqldata.htm Note: The following steps are all done in PASE on the iSeries and not in AIX. Note: If you try running the PHP binary in PASE and it dies with an illegal instruction, check for the existence of a job log. Several things can cause an illegal instruction signal and kill a PASE application. If the illegal instruction was caused by an unsupported system call, the name of the system call will be specified in the job log. The job log should tell you the name of the illegal instruction. Next find the corresponding HAVE_ line in the php_config.h and delete it. Then recompile. This should only happen if you're compiling on a version of AIX that supports certain syscalls that PASE does not support (in addition to the five noted earlier). Bringing PHP to Your IBM iSeries Server 17 To unpack and create the sample database, invoke the procedure from any SQL interface as follows: CALL QSYS.CREATE_SQL_SAMPLE('SAMPLE') Here SAMPLE is the name of the schema that you want to create. However, currently the sample PHP requires some updates. For example, PASE PHP runs as a CGI-BIN and cannot use the $_SERVER ['PHP_AUTH_USER'] and $_SERVER ['PHP_AUTH_PW'] values. Also, when connecting to a database, you may normally use something like this example: $dsn = "DRIVER=iSeries Access ODBC Driver;SYSTEM=$isdb_system;DBQ=$isdb_database"; $db = odbc_connect($dsn, $user, $password); But in PASE, you use something like this example: $db = odbc_connect($isdb_system, "", ""); odbc_setoption($db, 1, SQL_ATTR_DBC_DEFAULT_LIB, $isdb_database); Limitations Since PHP runs as a CGI application and not as an Apache module, some things will not work in this implementation on the iSeries:  HTTP authentication will not work, so any script that tries using the variables $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] will not work. You need to use user accounts and make a form that gets the user name and password and sets a cookie instead.  PHP_SELF does not work. There is a bug in the CGI version of PHP 4.3.0 that corrupts the $_SERVER['PHP_SELF'] variable. For more details on this bug, see PHP's bug page at: http://bugs.php.net/bug.php?id=21261 By the time you read this, that page may have a patch that will fix the issue. If it does, then apply the patch. If it doesn't, use the fix suggested by mailto:tapken@engter.de in the bug report: Create a file called “self_fix.php” in /QOpenSys/php/lib/php/ with the following script: Then in /QOpenSys/php/etc/php.ini, look for the line that says: auto_prepend_file = Change this line to: auto_prepend_file = self_fix.php This should fix the $_SERVER['PHP_SELF'] bug. Note: It does not matter which user ID and password are used when you connect to the ODBC database. It uses the authority of the user profile that is running the web server process. Use the ServerUserID directive in the Apache config to change this. It is actually somewhat of a security hole if you allow others to make a Web page and do not configure the Apache Web server to run the under a different user. 18 Bringing PHP to Your IBM ^ iSeries Server PHP 4.2.2 errata The biggest change from 4.2.2 to 4.3.0 was the configuration process. For this document to apply to 4.2.2, make the following changes to the steps listed previously as noted:  For “Locating iSeries specific files” on page 13: – Step 5 on page 14: Ignore the note about the long line Makefile because it does not exist. – Step 6 on page 14: PHP version 4.3.0 does not have config_vars.mk. This step is for PHP version 4.2.2 only.  For “If you are compiling in AIX on the pSeries” on page 15, follow these steps instead. This is because it does not use PHP itself to try to install PEAR. cd php-4.2.2 make cd .. tar -cvf php422pasesrc.tar php-4.2.2 FTP the tar file to PASE The following steps are all done in OS/400 PASE on the iSeries and not in AIX: cd ~ tar -xvf php422pasesrc.tar cd php-4.2.2 make install The team that wrote this Redpaper The following team created this IBM Redpaper: David Larson is a staff software engineer for IBM in Rochester, Minnesota. His career began at IBM enhancing the functionality of OS/400 PASE and assisting groups inside and outside of IBM in using OS/400 PASE. His recent projects include OS/400 PASE integration with the OS/400 JVM, virtual device drivers for OS/400 and Linux, and hypervisor development. Bryan Logan is a software engineer for IBM Rochester. He is currently on the OS/400 PASE development team. You can contact him by e-mail at: mailto:bryanlog@us.ibm.com Tim Massaro is an advisory programmer for IBM in Rochester, Minnesota. Tim's career includes stints on several S/38 and AS/400 teams, including Work Management, Message Handler, and Operational Assistant. Tim is currently on the DEV/2000 Tools Team. You can reach him by e-mail at: mailto:tmassaro@us.ibm.com Heiko Mueller is a member of the Communications and the OS team for IBM Austria. Prior to joining this team, he worked for a German company delivering support for the iSeries platform. He has passed the certification exams for WebSphere® Solution Designer and iSeries Professional System Operator and spent much of his spare time improving his skills in Java programming, Linux, and AIX. You can reach Heiko by e-mail at: mailto:heiko_mueller@at.ibm.com Brian R. Smith is a Sr. Consulting I/T Specialist in the IBM International Technical Support Organization (ITSO) Rochester Center. The first third of his career was spent in the Rochester Lab with the design, coding, and testing of the System/38™ and AS/400 in the area of communications. He then jumped the wall into technical marketing support in 1990 to pursue the life of teaching and writing. Brian is the team leader of the iSeries e-business team at the ITSO Rochester Center. You can reach Brian via e-mail at: mailto:brsmith@us.ibm.com © Copyright IBM Corp. 2003. All rights reserved. 19 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described 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: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include 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. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. 20 Bring PHP to Your IBM eServer iSeries Server This document created or updated on April 30, 2003. Send us your comments 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: IBM Corporation, International Technical Support Organization Dept. JLU Building 107-2 3605 Highway 52N Rochester, Minnesota 55901-7829 U.S.A. Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: ^™ ™ Redbooks(logo) ™ ibm.com® iSeries™ pSeries™ AIX® AS/400® DB2 Universal Database™ DB2® IBM® Net.Data® OS/400® PartnerWorld® PowerPC® System/38™ VisualAge® WebSphere® The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others. ®

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