Managerial Communication Notes

8/17/2019 Managerial Communication Notes

1/290

AS/400e

Communications ManagementVersion 4

SC41-5406-0


2/290


3/290

AS/400e

Communications ManagementVersion 4

SC41-5406-0


4/290

Note

Before using this information and the product it supports, be sure to read the information in “Notices” on page 249.

Third Edition (May 1999)

This edition applies to version 4, release 4, modification 0 of Operating System/400 licensed program (productnumber 5769-SS1) and to all subsequent releases and modifications until otherwise indicated in new editions. Thisedition applies only to reduced instruction set computer (RISC) systems.

This edition replaces SC41-5406-01.

© Copyright International Business Machines Corporation 1997, 1999. All rights reserved.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

|


5/290


6/290

SNA Pass-through Error Message Processing . . . . . . . . . . . . 85Tracing Communications Lines, Network Interfaces, and Network Servers . . . 86Trace Common Programming Interface Communications . . . . . . . . . 87

Service Job Commands that Interact with TRCCPIC . . . . . . . . . . 87Starting Trace CPI Communications . . . . . . . . . . . . . . . . 87Stopping the Trace . . . . . . . . . . . . . . . . . . . . . . 89Ending the Trace . . . . . . . . . . . . . . . . . . . . . . . 102

Additional Considerations. . . . . . . . . . . . . . . . . . . . 102Trace Intersystem Communications Function . . . . . . . . . . . . . 104Isolating Problems in APPN Networks . . . . . . . . . . . . . . . . 104

Chapter 4. Handling Communications Errors . . . . . . . . . . . . 107Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Configuration Considerations . . . . . . . . . . . . . . . . . . 107Job Considerations . . . . . . . . . . . . . . . . . . . . . . 117System Tuning . . . . . . . . . . . . . . . . . . . . . . . 120

Communications Error Recovery . . . . . . . . . . . . . . . . . . 121Communications Error Recovery Problem Determination . . . . . . . . 122CL Programming Considerations . . . . . . . . . . . . . . . . . 123

Handling Class 1 Errors . . . . . . . . . . . . . . . . . . . . . 124First-Level Error Recovery . . . . . . . . . . . . . . . . . . . 125Second-Level Error Recovery . . . . . . . . . . . . . . . . . . 126

Automatic Communication Recovery . . . . . . . . . . . . . . . . 126Changing QCMNRCYLMT System Value . . . . . . . . . . . . . . 130

Other Operator Second-Level Recovery Controls . . . . . . . . . . . 131Automatic Communication Recovery—Examples . . . . . . . . . . . . 132

AS/400-to-Remote BSC System on a Nonswitched Point-to-Point Line . . . 132AS/400 System to 5294 on an SDLC Nonswitched Point-to-Point Line . . . 134

AS/400 System to Three 5394s on SDLC Nonswitched Multipoint Line . . . 136Line Failure after Successful Switched Connection Made by 5394 to AS/400

System . . . . . . . . . . . . . . . . . . . . . . . . . 137AS/400 System to 5494 on an SDLC Nonswitched Point-to-Point Line . . . 138

AS/400 System to 5494 on a Token-Ring Network . . . . . . . . . . 139AS/400 System to Personal Computers on a Token-Ring Network . . . . . 140AS/400 System to System/370 Host on an SDLC Nonswitched Line . . . . 142AS/400 System to System/370 Host Receiving Abnormal DACTLU . . . . 143

Recovery Procedures—Examples . . . . . . . . . . . . . . . . . 144

Recovery Procedures for a DHCF Device . . . . . . . . . . . . . . 144Recovery Procedures for a 3270 Emulation Device . . . . . . . . . . 144Recovery Procedures for an APPC Device . . . . . . . . . . . . . 144Considerations for Asynchronous Communications Error Recovery . . . . 145

Considerations for X.25 ELLC Error Recovery for SNA Controllers . . . . 146Considerations for Modem Error Recovery . . . . . . . . . . . . . 146

Handling Class 2 Errors . . . . . . . . . . . . . . . . . . . . . 146Remote Work Station Loss of Power and Subsystem Recovery. . . . . . 147

Unsuccessful Automatic Dial on a Switched Line . . . . . . . . . . . 147Remotely Started Normal Deactivation Sequences . . . . . . . . . . 148AS/400-to-AS/400 System on an Ethernet Network . . . . . . . . . . 149Remote Printer Considerations. . . . . . . . . . . . . . . . . . 149

Handling Class 3 Errors . . . . . . . . . . . . . . . . . . . . . 150Application Program Error Recovery . . . . . . . . . . . . . . . . . 150

User-Written Applications . . . . . . . . . . . . . . . . . . . . 151System-Supplied Applications . . . . . . . . . . . . . . . . . . 156

Error Recovery Procedures Parameter Selection Flow Charts . . . . . . . 158

Parameters for Asynchronous Communications Error Recovery Procedures . 158

iv OS/400 Communcations Management V4R4


7/290

Parameters for Binary Synchronous Communications Error RecoveryProcedures . . . . . . . . . . . . . . . . . . . . . . . . 159

Parameters for Ethernet Network Error Recovery Procedures . . . . . . 160

Parameters for ISDN (Integrated Services Digital Network) Error RecoveryProcedures . . . . . . . . . . . . . . . . . . . . . . . . 161

Parameters for IDLC Error Recovery Procedures . . . . . . . . . . . 162Parameters for IBM Token-Ring Network Error Recovery Procedures . . . 162

Parameters for Synchronous Data Link Control Error Recovery Procedures . 163Parameters for Frame Relay Network Error Recovery Procedures. . . . . 166Parameters for DDI Network Error Recovery Procedures . . . . . . . . 167Parameters for Wireless Network Error Recovery Procedures . . . . . . 168

Parameters for X.25 Error Recovery Procedures . . . . . . . . . . . 169

Chapter 5. Communications Threshold Process . . . . . . . . . . . 173Selecting the Threshold Setting . . . . . . . . . . . . . . . . . . 173

Changing the Threshold Setting . . . . . . . . . . . . . . . . . 174

Exceeding a Threshold Limit . . . . . . . . . . . . . . . . . . 174List of Values for Threshold Settings . . . . . . . . . . . . . . . 175

Threshold Error Checks . . . . . . . . . . . . . . . . . . . . . 175

Asynchronous Communications Thresholds . . . . . . . . . . . . . 175Binary Synchronous Communications Thresholds . . . . . . . . . . . 177SDLC Non-X.21 Communications Thresholds . . . . . . . . . . . . 179SDLC X.21 Switched Communications Thresholds . . . . . . . . . . 181X.25 Communications Thresholds . . . . . . . . . . . . . . . . 183

ISDN Communication thresholds . . . . . . . . . . . . . . . . . 185

Chapter 6. Performance . . . . . . . . . . . . . . . . . . . . . 187Network and Line Considerations . . . . . . . . . . . . . . . . . . 188

Line Speed . . . . . . . . . . . . . . . . . . . . . . . . . 188X.21 SHM Port Sharing Performance . . . . . . . . . . . . . . . . 189Line Disconnection on the AS/400 System . . . . . . . . . . . . . . 190

Switched Line Disconnection . . . . . . . . . . . . . . . . . . 190

Manually Disconnecting Switched Lines . . . . . . . . . . . . . . 190Finance or Retail Controller Line Disconnection . . . . . . . . . . . 191SDLC Primary-to-Remote Work Station Line Disconnection . . . . . . . 191SDLC Secondary Lines Using Host Controller-to-System/370 Line

Disconnection . . . . . . . . . . . . . . . . . . . . . . . 192

APPC/APPN Line Disconnection . . . . . . . . . . . . . . . . . 193BSC APPTYPE (*PGM) Line Disconnection . . . . . . . . . . . . . 193Premature Calls for BSC APPTYPE(*PGM) . . . . . . . . . . . . . 194X.25 Considerations . . . . . . . . . . . . . . . . . . . . . 195

Nonswitched vs. Switched Lines . . . . . . . . . . . . . . . . . 195Maximum Throughput . . . . . . . . . . . . . . . . . . . . . 196Duplex vs. Half-Duplex Networks . . . . . . . . . . . . . . . . . 196Point-to-Point vs. Multipoint Lines. . . . . . . . . . . . . . . . . 196

Line Speed Examples . . . . . . . . . . . . . . . . . . . . . 197Process Management . . . . . . . . . . . . . . . . . . . . . 199

Modem Considerations . . . . . . . . . . . . . . . . . . . . . 199Aggregate Line Speeds . . . . . . . . . . . . . . . . . . . . 200

Nonswitched vs. Switched Lines . . . . . . . . . . . . . . . . . 200Duplex vs. Half-Duplex Support . . . . . . . . . . . . . . . . . 201Diagnostic Capability . . . . . . . . . . . . . . . . . . . . . 201

APPC Data Compression. . . . . . . . . . . . . . . . . . . . . 201Protocol Considerations . . . . . . . . . . . . . . . . . . . . . 202

Synchronous Data Link Control (SDLC) Considerations . . . . . . . . 202Polling. . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Contents v


8/290

Normal Disconnect Mode Polling Considerations . . . . . . . . . . . 206IDLC Considerations . . . . . . . . . . . . . . . . . . . . . 210ATM Network Considerations . . . . . . . . . . . . . . . . . . 211

Frame Relay Network Considerations . . . . . . . . . . . . . . . 211Local Area Network Considerations . . . . . . . . . . . . . . . . 213X.25 Considerations . . . . . . . . . . . . . . . . . . . . . 215Binary Synchronous Communications Considerations . . . . . . . . . 217

Asynchronous Communications Considerations . . . . . . . . . . . 218PPP Considerations. . . . . . . . . . . . . . . . . . . . . . 219

General Programming Support Considerations . . . . . . . . . . . . . 219Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . 219

File Placement within a Network . . . . . . . . . . . . . . . . . 220Printer Performance. . . . . . . . . . . . . . . . . . . . . . 221Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Chapter 7. Communications Subsystem Controller Storage and Aggregate

Line Speed . . . . . . . . . . . . . . . . . . . . . . . . . 225Maximum Aggregate Line Speeds . . . . . . . . . . . . . . . . . 225

2623/4xx 5xx MFIOP Controllers . . . . . . . . . . . . . . . . . 225

Calculating Communications Subsystem Storage (2623 and 4xx/5xx MFIOP) . 228

Appendix A. AS/400 VTAM Node Support . . . . . . . . . . . . . . 235

Appendix B. Planning for Coexistence . . . . . . . . . . . . . . . 237

Data Coexistence . . . . . . . . . . . . . . . . . . . . . . . 237Security Coexistence . . . . . . . . . . . . . . . . . . . . . . 240

Appendix C. Communications Functions . . . . . . . . . . . . . . 241

Data Link Protocol Considerations . . . . . . . . . . . . . . . . . 241Using IBM-Supplied Communications Functions . . . . . . . . . . . 241Writing Your Own Application Programs . . . . . . . . . . . . . . 242

Appendix D. Communications Restrictions . . . . . . . . . . . . . 247

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Programming Interface Information . . . . . . . . . . . . . . . . . 250Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 253AS/400 Books . . . . . . . . . . . . . . . . . . . . . . . . . 253Non-AS/400 Books . . . . . . . . . . . . . . . . . . . . . . . 255

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Readers’ Comments — We’d Like to Hear from You . . . . . . . . . . 269

vi OS/400 Communcations Management V4R4


9/290

Figures

1. AS/400 Operations Navigator Display . . . . . . . . . . . . . . xiii2. Work Management Environment . . . . . . . . . . . . . . . . 23. Subsystem Descriptions and Work within the System . . . . . . . . 8

4. SNA Pass-through Error Messaging, Source Node to Terminal User . . . 855. SNA Pass-through Error Messaging, Multinode Network . . . . . . . 866. TRCCPIC prompt with trace option setting set to *ON . . . . . . . . 887. TRCCPIC prompt with trace option setting set to *OFF . . . . . . . . 90

8. An Example of a Trace CPI Communications Report. . . . . . . . . 929. DDS for trace records written to a database file. . . . . . . . . . . 100

10. Error Recovery Example: Time Interval 1 . . . . . . . . . . . . . 12811. Error Recovery Example: Time Interval 2 . . . . . . . . . . . . . 12812. Error Recovery Example: Time Interval 3 . . . . . . . . . . . . . 129

13. Error Recovery Example: Time Interval 4 . . . . . . . . . . . . . 12914. AS/400-to-Remote BSC System on a Nonswitched Point-to-Point Line . . 13215. AS/400 System to 5294 on an SDLC Nonswitched Point-to-Point Line . . 13416. AS/400 System to Three 5394s on Nonswitched Multipoint Line . . . . 136

17. Line Failure after Successful Switched Connection Made by 5394 toAS/400 System . . . . . . . . . . . . . . . . . . . . . . 137

18. AS/400 System to 5494 on an SDLC Nonswitched Point-to-Point Line . . 13819. AS/400 System to 5494 on a token-ring Network . . . . . . . . . . 139

20. AS/400 System to Personal Computers on a token-ring Network . . . . 14021. AS/400 System to System/370 Host on an SDLC Nonswitched Line . . . 14222. AS/400 System to System/370 Host Receiving Abnormal DACTLU . . . 14323. Parameter Selection for Asynchronous Communications Error Recovery

Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15924. Parameter Selection for BSC Error Recovery Procedures . . . . . . . 16025. Parameter Selection for Ethernet Network Error Recovery Procedures . . 16126. Parameter Selection for ISDN Error Recovery Procedures. . . . . . . 161

27. Parameter Selection for IDLC Error Recovery Procedures . . . . . . . 16228. Parameter Selection for token-ring Network Error Recovery Procedures 16329. Parameter Selection for SDLC Error Recovery Procedures . . . . . . 16430. Parameter Selection for Frame Relay Network Error Recovery Procedures 16731. Parameter Selection for DDI Network Error Recovery Procedures . . . . 168

32. Parameter Selection for Wireless Network Error Recovery Procedures . . 16933. Parameter Selection for X.25 Error Recovery . . . . . . . . . . . 17034. Controllers Possible Combination . . . . . . . . . . . . . . . . 226

© Copyright IBM Corp. 1997, 1999 vii


10/290viii OS/400 Communcations Management V4R4


11/290

Tables

1. ADDCMNE Parameters . . . . . . . . . . . . . . . . . . . 92. ADDRTGE Parameters. . . . . . . . . . . . . . . . . . . . 113. Status Codes for Network Server, Network Interfaces, Lines, Controllers,

and Devices. . . . . . . . . . . . . . . . . . . . . . . . 334. CHGSSNMAX Parameters . . . . . . . . . . . . . . . . . . 755. AS/400 LPDA-2 Support Summary . . . . . . . . . . . . . . . 846. When does the AS/400 attempt to connect the remote system? . . . . . 116

7. MINSWTSTS(*VRYON) affect on AS/400 attempts to connect to theremote system . . . . . . . . . . . . . . . . . . . . . . . 116

8. Major and Minor Return Codes for Second-Level Error Recovery . . . . 1529. Remote Printer Escape Messages . . . . . . . . . . . . . . . 155

10. Threshold-Setting Values . . . . . . . . . . . . . . . . . . . 175

11. Asynchronous Communications Network . . . . . . . . . . . . . 17512. Binary Synchronous Communications Network . . . . . . . . . . . 17713. SDLC Non-X.21 Communications Network . . . . . . . . . . . . 17914. SDLC X.21 Communications Network . . . . . . . . . . . . . . 181

15. X.25 Communications Network . . . . . . . . . . . . . . . . . 18316. Aggregate Line Speed . . . . . . . . . . . . . . . . . . . . 20017. Line Speed Examples for the 9406 System Unit . . . . . . . . . . 22618. Protocol and Interface Combinations for the 9406 System Unit . . . . . 227

19. Storage Requirements per Line or Port Group . . . . . . . . . . . 23020. Storage Requirements per Protocol . . . . . . . . . . . . . . . 23221. SDLC Port Group Using Short-Hold Mode Storage Requirements . . . . 23222. Controller Storage Requirements . . . . . . . . . . . . . . . . 232

23. Total Storage Requirements . . . . . . . . . . . . . . . . . . 23224. 9401 Model 150 Line Speeds . . . . . . . . . . . . . . . . . 23325. AS/400 System Connected to NCP through a Switched or Nonswitched

Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

26. AS/400 System Locally Attached to VTAM (not through a NCP . . . . . 23527. Distribution of AS/400 System Objects (See Note 1), Part 1 . . . . . . 23728. Distribution of AS/400 System Objects, Part 2 . . . . . . . . . . . 23829. Distribution of System/36 Objects . . . . . . . . . . . . . . . . 23830. Distribution of System/38 Objects . . . . . . . . . . . . . . . . 239

31. IBM-Supplied Communications Functions . . . . . . . . . . . . . 24232. User-Written Programs with IBM-Supplied Communications Functions . . 24333. Compatible Data Links and Protocols . . . . . . . . . . . . . . 244

© Copyright IBM Corp. 1997, 1999 ix


12/290x OS/400 Communcations Management V4R4


13/290

About Communications Management (SC41-5406)

In this book, the term ‘user’ refers to the application user. The term ‘operator’ refers

to the system operator.

This book contains information that is needed for managing communications on theAS/400 system. The Communications Configuration book describes the objects,

commands, and parameters that are used to configure OS/400 communications.Once that task is complete, you may require additional information on how tomanage the work your AS/400 system performs. This book provides information onhow to do the following:

v Determine the status of your communications objects

v Trace and diagnose communications problems

v Handle and recover from communications errors

v Improve performance

v Determine the aggregate line speed and subsystem storage needs of yourAS/400 system

This book is divided into separate chapters to address the following topics:

v Work management in a communications environment

This topic discusses the use of subsystems to control your communications jobs.Also included are discussions of communications entries, routing information, andhow to handle program start request failures.

v Communications status and configurations

This topic discusses how to do the following:

– Determine the status of communications sessions and conversations

– Work with communications configurations

– Vary on or off a communications object

– Retrieve configuration status – Display connection status

– Display inbound routing information

– Display mode status

– Change the maximum number of sessions

v Tracing and diagnosing communications problems

This topic discusses:

– How to trace communications lines

– Common Programming Interface Communications

– Intersystem communications function (ICF) operations and functions used bya user program

It also provides information on how to isolate problems in an AdvancedPeer-to-Peer Networking (APPN) environment.

v Handling communications errors

This topic provides error recovery information for the following:

– Communications

– Application programs

– Operating system

– Remote work station loss of power

– Subsystems

© Copyright IBM Corp. 1997, 1999 xi


14/290

Communications configuration flow charts for error recovery procedures areprovided.

Also included in this chapter is a discussion of communications problem analysiscovering Link Problem Determination Aid (LPDA) tests, system service tools, andautomatic communications recovery.

v

Communications threshold processThis topic discusses the threshold process and error checks that are provided bythe system.

v Performance

This topic includes information on line speed, X.21 short-hold mode port sharing,line disconnection, modems, data link protocols, printers, and pacing.

v Aggregate line speed and subsystem storage

This topic discusses maximum aggregate line speed on the various AS/400

models in addition to how to calculate subsystem storage for each of the AS/400models.

v Appendixes

The appendixes cover virtual telecommunications access method (VTAM) nodesupport, data and security coexistence, and an overview of communicationsfunctions and data link protocol considerations.

You may need to refer to other IBM books for more specific information about a

particular topic. The Publications Reference provides information on all the books inthe AS/400 library.

Who Should Read This Book

This book supplies programmers and system administrators with the informationthat is needed to develop, maintain, and support communications on the AS/400

system. It provides an overview of communications management and how thesystem works.

You should be familiar with the general communications concepts andcommunications configuration on the AS/400 system. For more information ongeneral communications concepts, refer to Discover/Education Introduction to DataCommunications course, which you may order separately.

You should have read the System Operation book and the Basic System Operation,Administration, and Problem Handling book or have the equivalent knowledge.

AS/400 Operations Navigator

AS/400 Operations Navigator is a powerful graphical interface for Windows clients.With AS/400 Operations Navigator, you can manage and administer your AS/400systems from your Windows desktop.

You can use Operations Navigator to manage communications, printing, database,security, and other system operations. Operations Navigator includes ManagementCentral for managing multiple AS/400 systems centrally.

Figure 1 on page xiii shows an example of the Operations Navigator display:

xii OS/400 Communcations Management V4R4


15/290

This new interface has been designed to make you more productive and is the only

user interface to new, advanced features of OS/400. Therefore, IBM recommendsthat you use AS/400 Operations Navigator, which has online help to guide you.While this interface is being developed, you may still need to use a traditionalemulator such as PC5250 to do some of your tasks.

Installing Operations Navigator

To use AS/400 Operations Navigator, you must have Client Access installed on yourWindows PC. For help in connecting your Windows PC to your AS/400 system,consult Client Access Express for Windows - Setup , SC41-5507-00.

AS/400 Operations Navigator is a separately installable component of Client Accessthat contains many subcomponents. If you are installing for the first time and youuse the Typical installation option, the following options are installed by default:

v Operations Navigator base support

v Basic operations (messages, printer output, and printers)

To select the subcomponents that you want to install, select the Custom installation

option. (After Operations Navigator has been installed, you can add subcomponentsby using Client Access Selective Setup.)

1. Display the list of currently installed subcomponents in the ComponentSelection window of Custom installation or Selective Setup.

2. Select AS/400 Operations Navigator.

3. Select any additional subcomponents that you want to install and continue with

Custom installation or Selective Setup.

After you install Client Access, double-click the AS400 Operations Navigator iconon your desktop to access Operations Navigator and create an AS/400 connection.

Prerequisite and related information

Use the AS/400 Information Center as your starting point for looking up AS/400technical information. You can access the Information Center from the AS/400eInformation Center CD-ROM (English version: SK3T-2027 ) or from one of theseWeb sites:

Figure 1. AS/400 Operations Navigator Display

About Communications Management (SC41-5406) xiii


16/290

http://www.as400.ibm.com/infocenterhttp://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm

The AS/400 Information Center contains important topics such as logicalpartitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also

contains Internet links to Web sites such as the AS/400 Online Library and the

AS/400 Technical Studio. Included in the Information Center is a link that describesat a high level the differences in information between the Information Center andthe Online Library.

For a list of related publications, see the “AS/400 Books” on page 253.

How to send your comments

Your feedback is important in helping to provide the most accurate and high-qualityinformation. If you have any comments about this book or any other AS/400documentation, fill out the readers’ comment form at the back of this book.

v If you prefer to send comments by mail, use the readers’ comment form with theaddress that is printed on the back. If you are mailing a readers’ comment formfrom a country other than the United States, you can give the form to the localIBM branch office or IBM representative for postage-paid mailing.

v If you prefer to send comments by FAX, use either of the following numbers:

– United States and Canada: 1-800-937-3430

– Other countries: 1-507-253-5192

v If you prefer to send comments electronically, use one of these e-mail addresses:

– Comments on books:

[email protected]

IBMMAIL, to IBMMAIL(USIB56RZ)

– Comments on the AS/400 Information Center:

[email protected]

Be sure to include the following:

v The name of the book.

v The publication number of the book.

v The page number or topic to which your comment applies.

xiv OS/400 Communcations Management V4R4


17/290

Summary of Changes for Communications ManagementSubsystem Configuration Considerations

An expanded discussion on subsystem configuration considerations. See“Subsystem Configuration Considerations” on page 3.

Varying a Configuration On or OffAdditional information on varying a configuration on and off, including some

examples. See “Varying a Configuration On or Off” on page 24.

Managing Communication MessagesAdditional information about the primary places where communicationsmessages are logged, including a new message queue, QCFGMSGQ. See

“Managing Communication Messages” on page 76.

System Value ConsiderationsNew information about QCMNARB system values. See “System Value

Considerations” on page 109.

Handling Communications ErrorsExpanded chapter on handling communications errors , with updated

information on configuration considerations, job considerations, andcommunications error recovery problem analysis. See “Chapter 4. HandlingCommunications Errors” on page 107.

Miscellaneous Changes:Updated AS/400 displays, systems, and network device names.

A vertical line (|) to the left of the text indicates a change or addition.

© Copyright IBM Corp. 1997, 1999 xv


18/290xvi OS/400 Communcations Management V4R4


19/290

Chapter 1. Work Management

All of the work that is done is submitted through the work management function.

You can design specialized operating environments to handle different types of workto satisfy the requirements of your system. However, when the operating system isinstalled, it includes a work management environment that supports interactive andbatch processing, communications, and spool processing. This chapter discusses

the communications aspects of work management.

The operating system allows you to tailor this support or to create your own workmanagement environment. To do this, you need an understanding of the work

management concepts. Following is an overview of the work management conceptsand the objects that are supplied by IBM. See the Work Management book for moreinformation about work management.

Concepts

On the AS/400 system, all user jobs operate in an environment that is called asubsystem. This is where the system coordinates processing and resources. Asubsystem description defines a subsystem. Placing a group of jobs with common

characteristics in a subsystem enables users to control the jobs independently ofothers. Users can easily start and end subsystems as needed to support the workbeing done, and to maintain desired performance characteristics. One suchsubsystem, called a controlling subsystem, automatically starts when the systemloads. (For information on how to load the system, see the Basic System Operation,

Administration, and Problem Handling book.)

IBM supplies two subsystem configurations, and may be used without charge. Thefirst configuration includes the following subsystems:

v QBASE, the controlling subsystem, supports interactive, batch, and

communications jobs.v QSPL supports processing of spooling readers and writers.

v QSYSWRK supports system functions.

v QSERVER supports file serving.

v QUSRSYS supports server jobs that performs user functions.

QBASE and QSYSWRK are automatically started when the system starts. Anautomatically started job in QBASE starts QSPL, QSERVER, and QUSRSYS.

The second subsystem configuration supplied by IBM is more complex. Thisconfiguration consists of the following subsystems:

v QCTL, the controlling subsystem, supports interactive jobs that are started at the

console.v QINTER supports interactive jobs that are started at other work stations.

v QCMN supports communications jobs.

v QBATCH supports batch jobs.

v QSPL supports processing of spooling readers and writers.

v QSYSWRK supports system functions.

v QSERVER supports file serving.

v QUSRSYS supports server jobs that performs user functions.

© Copyright IBM Corp. 1997, 1999 1

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|


20/290

Note: Job queues with names identical to their corresponding IBM subsystems arealso supplied. Jobs can start from these queues after their correspondingsubsystems have started.

The QBASE configuration provides the capability to run all the same functionspossible with the QCTL configuration. Because QBASE consists of fewersubsystems, it is easier to manage.

If you change your configuration to use the QCTL controlling subsystem, it startsautomatically when the system starts. An automatically started job in QCTL startsthe other subsystems.

You can change your subsystem configuration from QBASE to QCTL by changingthe system value QCTLSBSD (controlling subsystem) to ‘QCTL QSYS’ on theChange System Value (CHGSYSVAL) command. Then, perform an initial programload (IPL) of the system.

For more information about the controlling subsystems that are shipped by IBM,and for additional subsystem descriptions, see the Work Management book.

Five basic types of jobs run on the system:

v Interactive jobs

v Batch jobs

Figure 2. Work Management Environment

2 OS/400 Communcations Management V4R4

|

|

|


21/290

v Spooling jobs

v Autostart jobs

v Prestart jobs

Figure 2 on page 2 shows these jobs and their relationship to each other.

1 An interactive job starts when you sign on a work station and ends when yousign off.

2 A communications batch job is a job that is started from a program start requestfrom another system.

3 A non-communications batch job is started from a job queue. Job queues arenot used when starting a communications batch job.

4 Spooling functions are available for both input and output. For input spooling, asystem program, called a reader, transfers job instructions and data from an inputdevice (diskette or database file) to a job queue. For output spooling, the systemplaces output records that are produced by a program in an output queue.

5 Autostart jobs perform repetitive work or one-time initialization work. Autostart jobs are associated with a particular subsystem. Each time the subsystem isstarted, the associated autostart jobs are started.

6 Prestart jobs are jobs that begin running before the remote program sends aprogram start request. To run a prestart job, you first must define bothcommunications and prestart job entries in the same subsystem description. Then,make specific programming changes to the prestart job target program with which

your program communicates. For information about defining communications andprestart job entries and managing prestart jobs, see the Work Management book.For information on designing prestart jobs to use the intersystem communicationsfunction (ICF), see the ICF Programming book. For information about designing

prestart jobs to use CPI Communications, see the APPC Programming book.

Subsystem Configuration Considerations

If you have any or all of the following, you need to consider how you configure yoursubsystems for your users:

v Local work stations

v Remote work stations

v Advanced program-to-program communications (APPC)-based 5250 displaysessions

v Telnet sessions

v General APPC communications activityv Any other interactive job

Placing too many users (or too much work load) on a subsystem can adverselyaffect the users on that subsystem. Subsystem monitor jobs provide function forinitiating and ending jobs. In addition, subsystems perform device recovery when a job is ended for some reason. There are various reasons why device recovery may

be needed; some examples include powering off a display, ending an emulatorconnection from the client, or a network failure. This device recovery is done on onedevice at a time, and is a synchronous operation.

Chapter 1. Work Management 3

|

|

|

|

|

|

|


22/290

When a subsystem has many jobs that start or end at one point in time, or manydevices to recover at one time, it can become very busy, and negatively impact thework of others also running in that subsystem. For example, users may not be able

to sign on to the system if the interactive subsystem in which they run is busy.

To maintain good system performance, you should limit the number of devicesallocated to an interactive or communications subsystem to between 200 and 300.

Spreading the work across multiple subsystems provides multiple processes tohandle the work. This provide better error isolation. In addition, multiple processescan lead to greater parallelism on multi-processor systems.

To minimize this effect, separate your system’s work load into multiple subsystems.

In summary, consider these four points when configuring your subsystems:

1. The number of users and jobs

Limit the number of users and jobs that are serviced by any single subsystem to300.

2. The connectivity used to access the system

Subsystems perform best when remote users and jobs are isolated from localusers and jobs. Correspondingly, you should isolate local area network (LAN)users and jobs.

A good way to perform the subsystem configuration is to define oneQINTER/QCMN subsystem pair for any communications line that can support

many users. For example, place all users on a token-ring line into their ownQINTER/QCMN subsystem pair, and place users connected by a 5494 remotecontroller in another subsystem pair.

3. The type of work the subsystem has to perform

In this case, consider the following:

v Are there many jobs starting and ending throughout the day?

v Does the subsystem handle many communications evokes?

v Does the subsystem have frequent device allocation and deallocation?

v Do the devices in the subsystem frequently go into error recovery?

Multiple subsystems provide multiple processes to perform cleanup andrecovery when an error condition occurs. This may result in improved

performance.

v Is one set of users more time-sensitive than another?

v Is the subsystem affected by vary-on and vary-off processing?

4. The geographic location of the users

Use the above considerations to determine the best configuration for yourinteractive subsystems, as well as your communications subsystems.

Interactive Subsystem Configuration Considerations

To configure interactive subsystems, do the following:

1. Identify how you want the interactive users separated, and create the

appropriate subsystem descriptions.

2. For each subsystem you define, use the Add Work Station Entry (ADDWSE)command to identify which users will run in which subsystem.

Each subsystem requires an appropriate work station entry for the users that

will run in it. You can set up work station entries that identify the devices asubsystem allocates, and the devices a subsystem does not allocate.


|

|

|

|

|

|

|

|

|


23/290

You can use generic names for work station name entries on the work station entrycommands. These commands include, Add Work Station Entry (ADDWSE), ChangeWork Station Entry (CHGWSE), and Remove Work Station Entry (RMVWSE).

These generic names for work station entries provide easier addition of workstations to an already active subsystem.

To specify which devices a particular subsystem should allocate, use the following

command:

v ADDWSE SBSD(libname/sbsname) WRKSTN(devname*) AT(*SIGNON)

To specify which devices a particular subsystem should not allocate, use thefollowing command. This workstation entry will allow a job at that device to transfer

into that subsystem.

v ADDWSE SBSD(libname/sbsname) WRKSTN(devname*) AT(*ENTER)

Note: If the subsystem description does not have a workstation entry for a

particular device, the subsystem will not allocate it. However, you cannottransfer an interactive job into that subsystem with that unallocate device.

See Work Management for more information on configuring interactive subsystems.

The QDEVRCYACN system value specifies the device recovery action than is takenwhen an I/O error occurs. The device recovery action can make a significantdifference in the performance of your subsystem, and the system as a whole, whendevice I/O errors occur. This especially applies when many users experience the

same error simultaneously (for example, as a result of a network failure). See“Device Recovery Action (DEVRCYACN)” on page 117, and the Work Management book for more information about QDEVRCYACN.

Communications Subsystem Configuration Considerations

You may benefit by configuring multiple communications subsystems. However, thework that is done in a communications subsystem generally is less than the work

that is performed in a corresponding interactive subsystem. Consider configuringfewer communication subsystems than interactive subsystems.

Some of the work performed in the communications subsystem is done only whenusers connect and disconnect, and for error recovery. This consideration isimportant in the configuration of the communications subsystem.

To configure multiple communications subsystems, use the Add CommunicationsEntry (ADDCMNE) and Remove Communications Entry (RMVCMNE) commands toset up the communications entries.

To specify which devices a communications subsystem should allocate, use thefollowing command:

ADDCMNE SBSD(libname/sbsname) DEV(devname*)

To specify which devices a communications subsystem should not allocate, use thefollowing command:

ADDCMNE SBSD(libname/sbsname) DEV(devname*) MAXACT(0)

See “Communications Device Allocation” on page 6 and the Work Management book for additional information.



24/290

Switched Line Considerations

When a call is successful, the remote system may begin a session with a correctlyconfigured subsystem monitor. Before program start requests are accepted by anAS/400 system, a subsystem that supports communications must start.

Subsystem monitors support the answer function from remote systems. If the callfunction is desired, a user program must make the call manually. Or, you can causethe connection to be established by opening a file or acquiring a device on anassociated controller that specifies INLCNN(*DIAL).

IBM-supplied QBASE and QCMN Subsystem Descriptions

Before program start requests are accepted by an AS/400 system, a subsystem thatsupports communications must be started. Two IBM-supplied subsystems, QBASEand QCMN, accept program start requests for all communications types. QBASE is

the default controlling subsystem. QCMN is the communications subsystem that isused when QCTL is the controlling subsystem. Having the QBASE or QCMNsubsystem active allows program start requests to be accepted for allcommunications types.

The QCMN and QBASE subsystems have device-type entries of *ALL andmode(*ANY). Both subsystems have the appropriate routing entries, usingCMPVAL(PGMEVOKE 29), so all program start requests received by the AS/400system are accepted. If you have either of these subsystems and then start your

own communications subsystem or other subsystems, such as DSNX(QDSNX) orSNADS(QSNADS), read “Communications Device Allocation”. Both subsystemsattempt to allocate the same communications devices.

Communications Device Allocation

When subsystems start, they request allocation of all communications devices forcommunications entries in the subsystem description. The requests are sent to theQLUS (LU services) system job that handles device allocation for allcommunications devices.

QLUS is notified when a communications device is available for program startrequest processing. This notification occurs when the connection between the localand remote system is established for that device. When QLUS receives thisnotification, it attempts to allocate the communications device to a subsystem based

on communication entry definitions. If there is no subsystem active that wants touse the device, QLUS maintains allocation of the device until the device is variedoff, or until a subsystem starts that wants to use the device.

Rules for Device Allocation

When more than one subsystem contains communications entries for acommunications device, QLUS uses the following rules to determine which

subsystem uses the device when the device is available:

v Communications entries with the highest level of detail for the device areprocessed first. The order (from highest to lowest) of detail is: Device name entry,remote location name entry, and device-type entry.



25/290

v Mode names are only used for APPC devices. Each mode on each device isallocated to a subsystem. A specific mode name takes priority over the generic*ANY mode name.

v The time that the subsystem requested the device (when the subsystem isstarted) is used to break ties when two or more subsystems have the same levelof detail for the device and mode.

When a communications device is allocated to a subsystem, it remains in thatsubsystem until the subsystem deallocates the device. When a subsystemdeallocates a device (and deallocation is not due to a device error or varying off thedevice), QLUS attempts to allocate the device to another subsystem.

If a subsystem has a communications device allocated, and you start a secondsubsystem that should use the same communications device allocated to it (basedon the device allocation rules), you can force the original subsystem to deallocatethe device. Here are some ways to cause a subsystem to deallocate a

communications device:

v Varying the device off, and then on again causes QLUS to attempt to allocate thedevice to a subsystem.

v Issuing the Allocate Object (ALCOBJ) command against the device works forBSCEL, SNUF, retail, finance, and asynchronous communications types (requestan *EXCLRD lock). Issuing the Deallocate Object (DLCOBJ) command causesQLUS to attempt to allocate the device to a subsystem.

v Issuing the End Subsystem (ENDSBS) command to end the first subsystem

causes QLUS to automatically attempt to allocate the device to anothersubsystem.

This deallocation causes QLUS to go through the device allocation algorithm again,

which eventually causes the device to be allocated to the second subsystem.

Describing a Subsystem

A subsystem description consists of these parts:

v Subsystem attributes (overall subsystem characteristics).

v Work entries (sources of work). Only the communications entry is discussed inthis book. The communications job is processed when the subsystem receives aprogram start request from a remote system. See the topic “Adding a

Communications Entry” on page 9.

v Routing entries (define how a job’s routing step is started). See the topic “AddingRouting Information” on page 11.

One subsystem attribute is storage pool definitions. Storage pools are logicalallocations of main storage. The same storage pool can be shared by multiplesubsystems. You can display and change your storage pool definitions with theWork with Shared Pools (WRKSHRPOOL) command. The WRKSHRPOOL

command allows you to work with shared pools only. A subsystem might also haveprivate pools, which need the Change Subsystem Description (CHGSBSD)command for changes. If a subsystem is active, the Work with System Status(WRKSYSSTS) command provides an interface to change both shared and privatepools.

You can change the IBM-supplied subsystem descriptions or any user-createdsubsystem descriptions by using the Change Subsystem Description (CHGSBSD)



26/290

command. You can use this command to change the storage pool size, storagepool activity level, and the maximum number of jobs for the subsystem descriptionof an active subsystem.

Figure 3 shows the relationship of the communications entries and routing entrieswith the subsystem description.

Communications Entries in Subsystem Descriptions

The AS/400 system considers communications devices to be another source of

work for a subsystem. Therefore, a communications entry must be defined withinthe subsystem description to identify the devices from which work (program startrequests) can be received by the subsystem. Subsystem descriptions are createdusing the Create Subsystem Description (CRTSBSD) command. Communications

entries are added to a subsystem description using the Add Communications Entry(ADDCMNE) command.

RV2P160-0

Routing Table

Subsystem Description

Autostart

Job Entries

Job Queue

Entries

Work Station

Entries

CommunicationsEntries

The Create Subsystem Description commandcreates a new subsystem description.

CRTSBSD

The Add Work Station Entrycommand defines a new workstation entry.

ADDWSEADDAJE

The Add Autostart Job Entrycommand defines a new auto-start job entry.

The Add Commun-ications Entrycommand definesa new commun-ications entry.

The Add Routing Entrycommand defines a newentry in the routing table.

ADDCMNE

ADDRTGE ADDPJE

The Add Prestart Job Entrydefines a new prestart

job entry.

Prestart JobEntries

ADDJOBQE

The Add JobQueue Entrycommand definesa new job queueentry.

Figure 3. Subsystem Descriptions and Work within the System



27/290

Adding a Communications Entry

You can use the Add Communications Entry (ADDCMNE) command to add acommunications entry to an existing subsystem description.

Each communications entry describes one or more devices or remote locations that

are controlled by the subsystem. The devices identified in the communicationsentries are allocated by the subsystem for receiving program start requests to startcommunications batch jobs.

Table 1 shows the parameters for the ADDCMNE command.

Table 1. ADDCMNE Parameters

Parameter Name Keyword Description Valid Values

Subsystem

description

SBSD Name and library of the

subsystem description.

*LIBL, *CURLIB, or a user-specified library

name; if no library is named, *LIBL is

assumed

Device1 DEV Name of the device description

or the type of device being

used.

device-description-name , *ALL, *APPC,

*ASYNC, *BSCEL, *FINANCE, *INTRA,

*RETAIL, or *SNUF

Remote location1 RMTLOCNAME Name of the remote location. remote-location-name .

Job description JOBD Name and library of the job

description. If the job

description does not exist

when the communications

entry is added, a library

qualifier must be specified.

*USRPRF, *SBSD, or job-description-name .

Possible library values are *LIBL, *CURLIB,

or a user-specified library name

Default user

profile2DFTUSR Default user ID (user profile). user-profile-name , *NONE, or *SYS

Mode3 MODE If the communications type

being used supports modes,

this is the name used by bothends of the data link to refer to

this group of sessions.

*ANY, BLANK, or mode-name

Maximum active

jobs

MAXACT Maximum number of jobs

(program start requests) that

can be active at the same

time.

*NOMAX or maximum-active-jobs

Notes:

1 You must specify either the Device prompt or the Remote location prompt, but not both.

2 The names QSECOFR, QSPL, QDOC, QDBSHR, QRJE, and QSYS are not valid entries for this parameter.

3 Specific mode name entries are processed before *ANY entries are processed.

The following command adds a communications entry for the remote locationCHICAGO to the subsystem description SBS1, which resides in the ALIB library.The DFTUSR parameter defaults to *NONE, meaning that no jobs may enter thesystem through this entry unless valid security information is supplied on the

program start request.

ADDCMNE SBSD(ALIB/SBS1) RMTLOCNAME(CHICAGO)



28/290

Changing a Communications Entry

You can use the Change Communications Entry (CHGCMNE) command to changethe attributes of a communications entry in an existing subsystem description. Theparameters used on this command are the same as the parameters on the Add

Communications Entry command. For a description of these parameters, refer to

“Adding a Communications Entry” on page 9. To determine the communicationsentry to change, use the SBSD, DEV, RMTLOCNAME, and MODE parameters.

The following command changes the communications entry (in the subsystem

description QGPL/BAKER) for the remote location CHICAGO.

CHGCMNE SBSD(QGPL/BAKER) RMTLOCNAME(CHICAGO)MAXACT(*NOMAX)

The maximum activity level is changed to *NOMAX. This means that thecommunications entry puts no restrictions on the number of program start requeststhat may be active at the same time. However, the MAXJOBS value in thesubsystem description BAKER limits the total number of jobs that can be active in

the subsystem. This limit includes those created by a program start request. Also, a

user can specify a limit on the number of active jobs that can be routed through anyparticular routing entry (MAXACT). The limit specified in the routing entry maycontrol the number of jobs using a particular pool or the number of calls of a

particular program. In all cases, none of these limits can be exceeded as a result ofprocessing a program start request.

Removing a Communications Entry

You can use the Remove Communications Entry (RMVCMNE) command to removea communications entry from an existing subsystem description. The SBSD, DEV,

RMTLOCNAME, and MODE parameters are used to determine whichcommunications entry to remove. If a communications entry is to be removed from

an active subsystem, jobs that used this entry cannot be active. Refer to “Adding aCommunications Entry” on page 9 for a description of the parameters.

Note: MODE(*ANY) only removes an entry of *ANY, not specific mode entries.

The following command removes the communications entry for the remote location

CHICAGO from the subsystem description SBS1 in library LIB2.

RMVCMNE SBSD(LIB2/SBS1) RMTLOCNAME(CHICAGO)

Routing Information for Communications Entries

When the system processes a program start request, it creates a fixed-length datastring that is used to route data. The data used to build the routing data stringcomes from the program start request. Program start requests insert the characterstring PGMEVOKE (Program Evoke) into position 29 of the routing data string. Thisensures a match to a routing entry with a compare value of PGMEVOKE in position

29. When you use the Add Routing Entry command to define a routing entry for asubsystem description, you specify a value for the Program to Call (PGM)parameter. That value specifies the name of the program that is to be run for therouting entry. If you specify *RTGDTA (Routing Data) for this parameter, the

program name that is specified in the program start request is used.


|

|

|

|

||


29/290

Note: The PGMEVOKE value must be typed in uppercase.

The routing data created by an incoming program start request contains the

character string PGMEVOKE beginning in position 29. This character string may beused to route program start requests differently than interactive or batch jobs.

Note: To add, change, or remove routing entries, you must have object operational

and object management authorities for the subsystem description.

The following shows the format of the system-generated routing data for a programstart request:

Adding Routing Information

The Add Routing Entry (ADDRTGE) command adds a routing entry to the specifiedsubsystem description. Each routing entry specifies the parameters used to start arouting step for a job. For example, the routing entry specifies the name of the

program to run when the routing data that matches the compare value in thisrouting entry is received.

Table 2 shows the parameters for the ADDRTGE command.

Table 2. ADDRTGE Parameters


Subsystemdescription

SBSD Name and library of thesubsystem description.

Subsystem description name, *LIBL,*CURLIB, or a user-specified library

name; if no library is named, *LIBL is

assumed.

Sequence number SEQNBR Sequence number of the routing

entry.

1 through 9999

Compare value CMPVAL A value that is compared with the

routing data to determine whether

this is the routing entry used for

starting a routing step. If the

routing data matches the routing

entry compare value, that routing

entry is used. Optionally, a

starting position in the routingdata character string can be

specified for the comparison.

*ANY, compare-value: , 1, or

starting-position

Program PGM Name and library of the program

called as the first program run in

the routing step.

*RTGDTA or program-name

Possible library values are: *LIBL,

*CURLIB, or a user-specified library

name.

Mode Name Device Name User ID Name| | | | | |1 8 9 18 19 28

PGMEVOKE Program Name Library Name| | | | | |29 36 37 46 47 56



30/290

Table 2. ADDRTGE Parameters (continued)


Class CLS Name and library of the class

used for the routing steps.

*SBSD or class-name

Possible library values are: *LIBL,

*CURLIB, or a user-specified library

name.Maximum active

routing steps

MAXACT Maximum number of jobs that can

be active at the same time.

*NOMAX or maximum-active-jobs

Storage pool ID POOLID Pool identifier of the storage pool

in which the program runs.

1 or pool-identifier

The following example shows how the sequence number and the compare valuework together. When you add a routing entry to a subsystem description, you

assign a sequence number to the entry. This sequence number tells the subsystemthe order in which routing entries are searched for a routing data match. Forexample, you have a subsystem description that contains the following five routingentries:

Sequence Number Compare Value

10 'ABC'

20 'AB'

30 'A'

40 'E'

50 'D'

The routing entries are searched in sequence number order. If the routing data is

'A', the search ends with routing entry 30. If the routing data is 'AB', the searchends with routing entry 20. If the routing data is 'ABC', the search ends with routingentry 10. Because routing data can be longer than the compare value of the routing

entry, the comparison, which is done in left-to-right order, stops when it reaches theend of the compare value. Therefore, if the routing data is 'ABCD', the search endswith routing entry 10.

If routing entry 20 is changed to have a compare value of 'ABCD', the results of therouting search are different. In this case, the routing entries are:

Sequence Number Compare Value

10 'ABC'

20 'ABCD'

30 'A'

40 'E'

50 'D'

If the routing data is 'A', the search ends with routing entry 30. If the routing data is'AB', the search ends with routing entry 30. If the routing data is 'ABC', the searchends with routing entry 10. If the routing data is 'ABCD', the search ends withrouting entry 10.

In this case, it is no longer possible to match routing entry 20. This is because anyrouting data that matches the compare value for routing entry 20 matches therouting entry 10 first. When a routing entry is changed or added to a subsystem



31/290

description with a compare value that causes this situation, the system sends adiagnostic message identifying the situation.

When you add routing entries to a subsystem description, you should order them sothat the entries likely to be compared oftenest are first. This reduces the searchtime.

You can specify a comparison value of *ANY on the highest numbered routingentry. *ANY means that a match is forced regardless of the routing data. Only onerouting entry can contain the comparison value of *ANY, and it must be the last(highest sequence number) entry in the subsystem description.

The program named in the routing entry is given control when the routing step forthe job is started. Parameters to control the running of the routing step for the jobare taken from the class specified in the routing entry.

This following example adds routing entry 500 to the routing portion of thesubsystem description CMNSBS. To use this routing entry, the routing data mustcontain the characters PGMEVOKE starting in position 29. This is always true for

jobs that are being started as a result of a program start request being received.Any number of jobs can be active through this routing entry at any one time. Theprogram that was sent on the program start request runs in the job becausePGM(*RTGDTA) was specified.

ADDRTGE SBSD(CMNSBS) SEQNBR(500)CMPVAL(PGMEVOKE 29) PGM(*RTGDTA)CLS(QGPL/QBATCH) POOLID(2)

Note: The PGMEVOKE value must be typed in uppercase.

If a library was sent on the program start request, the subsystem searches thatlibrary for the program. Otherwise, the subsystem searches the subsystem’s library

list for the program. The job runs in storage pool 2 using class QBATCH in library

QGPL.

The following command adds routing entry 210 to the routing portion of thesubsystem description CMNSBS. To use this routing entry, the routing data must

contain the characters PROGRAMA that starts in position 37. For jobs being startedas a result of a program start request being received, position 37 always containsthe name of the program sent on the program start request. This allows specialhandling for all jobs that run PROGRAMA. For example, the job can run with a

different class, or it can run in a different pool.

ADDRTGE SBSD(CMNSBS) SEQNBR(210)CMPVAL(PROGRAMA 37) PGM(*RTGDTA)CLS(QGPL/CMNCLASS) POOLID(3)

Note: The compare value (CMPVAL) is case sensitive. If a program start requestwas received for program PROGRAMA, for example, this routing entry would notbe selected.

When using the program name as a compare value (CMPVAL), that routing entryshould have a lower sequence number than the routing entry with PGMEVOKE.

The PGMEVOKE routing entry matches the routing data that is started as a resultof a program start request being received.



32/290

Any number of jobs can be active through this routing entry at any one time. Theprogram that was sent on the program start request runs in the job becausePGM(*RTGDTA) was specified. The job runs in storage pool 3 using class

CMNCLASS in library QGPL.

Changing Routing Information

You can use the Change Routing Entry (CHGRTGE) command to make changes toa routing entry in the specified subsystem description. The parameters used on this

command are the same as the parameters on the Add Routing Entry command.Refer to “Adding Routing Information” on page 11 for a description of theseparameters. The SBSD and SEQNBR parameters are used to determine the routingentry to change.

The following command changes routing entry 1478 in the subsystem descriptionORDER that is found in library LIB5. The same program is used, but now it runs instorage pool 3 by using class SOFAST in library LIB6.

CHGRTGE SBSD(LIB5/ORDER) SEQNBR(1478)CLS(LIB6/SOFAST) POOLID(3)

The following command changes routing entry 157 in the subsystem descriptionPGMR found in library T7. The program INTDEV in library T7 is now called

whenever this routing entry is selected. The other routing entry parameters are notchanged.

CHGRTGE SBSD(T7/PGMR) SEQNBR(157)PGM(T7/INTDEV)

Removing Routing Information

You can use the Remove Routing Entry (RMVRTGE) command to remove a routingentry from the specified subsystem description. If a routing entry is to be removed

from an active subsystem, jobs that used this entry cannot be active. Theparameters used on this command tell the system which routing entry to remove.

The subsystem description and library (SBSD) and the routing entry sequencenumber (SEQNBR) are the parameters that are used on this command. Refer to“Adding Routing Information” on page 11 for a description of the parameters.

The following command removes the routing entry 9912 from subsystem descriptionPERT in library OR.

RMVRTGE SBSD(OR/PERT) SEQNBR(9912)

Handling Program Start Request Failures

When a program start request is received by an Operating System/400 (OS/400)subsystem, it attempts to start a job based on information that is sent with theprogram start request. The user’s authority to the system, existence of the

requested program, and many other items are checked.

If the subsystem determines that it cannot start the job, the subsystem sends amessage (CPF1269) to the QSYSMSG message queue or to QSYSOPR, or theconfigured message queue, when QSYSMSG does not exist. An example of this is

when the requested program is not found. The CPF1269 message contains tworeason codes (you can ignore reason codes of zero).


|

|

|

|

|

|

|

|

|

|

|


33/290

Note: The subsystem does not send the CPF1269 message with reason code 401in all the instances in which it was sent in previous OS/400 versions. Thefollowing describes subsystem conditions, and their resulting CPF1269

message statuses.

No subsystem availableCPF1269 is issued once for each mode description on APPC device

descriptions when there is no subsystem to accept the incomingrequest. Repetitive CPF1269 messages (which previously occurredin restricted state, for example) have been eliminated.

Incorrectly configured device or subsystem

One CPF1269 message is sent if a device or subsystem isincorrectly configured. Besides attempting to fix the configurationerror, the user should vary off and vary on the device. This willpermit another CPF1269 message to be received if the configurationerror is not properly resolved. If the device is not varied off and

varied on, a persistent configuration error may result in a failure forwhich no message is issued.

Inactive QSERVER subsystem

CPF1269 with reason code 413 is sent when the QSERVERsubsystem is not active.

The ICF Programming book includes a description of reason codes and theirmeanings.

If only one nonzero reason code appears, that code is the reason the program startrequest was rejected.

At times, two nonzero reason codes may appear. This occurs when the OS/400subsystem cannot determine whether the program start request is supposed to starta job in the System/36 environment or under the OS/400 subsystem.

One of the reason codes explains why the System/36 environment rejected theprogram start request. The other reason code explains why the AS/400 systemrejected the program start request. When you receive two reason codes, you shoulddetermine where the job runs, and correct the problem.


|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|


34/29016 OS/400 Communcations Management V4R4


35/290

Chapter 2. Working with Communications Configurations andStatus

This chapter documents how to display the communications status of yourapplications programs, and how to display which communications configurations the

application programs are using.

This chapter also contains information about managing configurations, including:

v Methods of saving and restoring configuration descriptions

v Commands for changing, activating and deactivating, and displaying the status ofconfiguration descriptions

v Managing your messages

For information about TCP/IP network status, see the TCP/IP Configuration and Reference book.

Obtaining Application Communications Status Information

You can obtain communications status information about your applications by usingthe Display Job (DSPJOB) or the Work with Job (WRKJOB) commands.Communications status information can be obtained for:

v Active intersystem communications function (ICF) sessions

v Common Programming Interface (CPI) Communications conversations

v User-defined communications

Information that can be obtained includes the number of input, output, and otheroperations, as well as the current operation and most recently issued operation.

You can obtain the communications status information, by using the DSPJOB, orWRKJOB commands with OPTION(*CMNSTS) specified. You can also select option17 from the Display Job or Work with Job displays. To print communications status

information, specify OUTPUT(*PRINT). The Work with Configuration Status, Workwith Active Jobs, and Work with APPN Status can access the Work with Jobdisplay.

Selecting option 17 from the Display Job or the Work with Job displays whencommunications identifiers are active brings up the following display:

© Copyright IBM Corp. 1997, 1999 17

|

|

|

|

|

|


36/290

Display Communications StatusSystem: SYSNAMxxx

Job: DSP02 User: QUSER Number: 007798

Type options, press Enter.5=Display

-------- Communications -------- --------Number of Operations---------

Opt Identifier Method Output Input Other_ ________________ _______________ B *UNKNOWN-CPIC 0 0 1_ USRHANDLE1 *USRDFN 150 20 3_ USRHANDLE2 *USRDFN 51 96 2_ A APPC-CPIC 101 51 11_ DEV1 INTRA-ICF 24 0 1_ ICF00 SNUF-ICF 2 5 1

BottomF3=Exit F5=Refresh F11=Display operations F12=Cancel F16=Job menuF17=Top F18=Bottom

Opt

Type in the number of the appropriate option next to one or more entries.5=Display is the only valid option, and is used to display detailed informationabout the session. For ICF entries, the following kinds of displays can appear:

v Display CPI Communications

v Display APPC ICF Session

v Display Asynchronous ICF Session

v Display BSCEL ICF Session

v Display Finance ICF Session

v Display Intrasystem ICF Session

v

Display Retail ICF Sessionv Display SNUF ICF Session

For CPI Communications entries, the Display CPI Communications displayappears. No options are supported for user-defined communications.

Communications Identifier

This is the identifier that is used by the application program.

CPI Communications conversationsThe conversation_ID returned by the Initialize or Accept_Conversationcalls and specified on all other calls.

ICF sessions

The program device name specified in the application for an active(acquired) ICF session.

User-defined communicationsThe communications handle that the application program is using.

Communications Method

This is the communications method being used.

ICF sessionsThe ICF communications type used. Possible values are:

APPC-ICF

Advanced program-to-program communications



37/290

ASYNC-ICFAsynchronous communications

BSCEL-ICF

Binary synchronous communications equivalence link

FINANCE-ICFFinance communications

INTRA-ICFIntrasystem communications

RETAIL-ICF

Retail communications

SNUF-ICFSNA upline facility communications

CPI Communications conversations

The communications type that is used for the CPI Communicationsconversation. Possible values are:

*UNKNOWN-CPIC

CPI Communications conversations in the Initializeconversation_state .

APPC-CPICCPI Communications conversations in any conversation_state

other than Reset or Initialize.

User-defined communicationsThis field always shows *USRDFN for communications identifiers thatare using user-defined communications support.

OutputThis is the number of output operations that are performed on thecommunications identifier.

ICF sessionsThe number of successful ICF write operations. It does not count writeoperations in which another function, such as invite, is specified and thelength is 0. Cancel, cancel-invite, fail, negative-response, and

request-write operations are not counted. Successful combinedwrite/read operations are counted.

CPI Communications conversationsThis count will be increased when a Send_Data completes successfully.

However, CPI Communications will not increase this count for aSend_Data call with a send_length of zero and another function that isrequested such as a send_type of CM_SEND_AND_CONFIRM. Thiscount also will be increased when an Allocate call completes

successfully.

User-defined communicationsThe number of calls to Send Data (QOLSEND).

Input

This is the number of input operations that are performed on thecommunications identifier.

ICF sessions

The number of successful ICF read operations that received data.

Chapter 2. Working with Communications Configurations and Status 19


38/290

CPI Communications conversationsThe number of Receive_Data calls that have completed successfully.

User-defined communications

The number of calls to Receive Data (QOLRECV).

OtherThis field contains operations that are counted and are not included under

output or input operations.

ICF sessionsThe number of all other high-level language operations such asopen/acquire, acquire, release, and close.

CPI Communications conversationsThe number of all other successful CPI Communications calls that arenot counted under output or input.

User-defined communicationsThe number of calls to Enable Link (QOLELINK) and Set Filter(QOLSETF).

When F11 is pressed on the first Display Communications Status display, a secondDisplay Communications Status display appears. This display lists the current orlast operation issued for the communications identifier.

Display Communications StatusSystem: SYSNAMxxx

Job: DSP02 User: QUSER Number: 007798

Type options, press Enter.5=Display

-------- Communications --------Opt Identifier Method Operation

_ ________________ _______________ B *UNKNOWN-CPIC CMINIT_ USRHANDLE1 *USRDFN QOLSEND

_ USRHANDLE2 *USRDFN QOLRECV_ A APPC-CPIC CMSEND_ DEV1 INTRA-ICF SND,EGP,CFM,DET_ ICF00 SNUF-ICF RFI

BottomF3=Exit F5=Refresh F11=Display number of operations F12=CancelF16=Job menu F17=Top F18=Bottom

OperationThis is the current or last operation that is issued by the program. The operation

displayed is dependent on the communications method that is used for thecommunications identifier.

ICF sessionsThe current or last ICF operation that is issued by the program. TheICF function codes are the same as the function codes used by theTrace ICF function, and are described as follows:

ACQ Acquire

AWT Allow-Write

CFM Confirm



39/290

CLS Close

CNI Cancel-Invite

CNL Cancel

DET Detach

EGP End-of-Group

EOA End-of-Session-Abnormal

EOS End-of-Session

EVK Evoke

FAL Fail

FMH Function-Management-Header

FRC Force-Data

GTA Get-Attributes

INV Invite

NRP Negative-Response

OPN Open with Acquire-Program-Device

RCF Respond-to-Confirm

RCV Receive

REL Release

RFI Read-From-Invited-Program-Devices

RST Restore

RWT Request-to-Write

SDV Subdevice-Selection

SND Send

SPD Suspend

TMR Timer

CPI Communications conversationsThe current or last CPI Communications call that was issued, forexample, CMINIT (Initialize_Conversation). Refer to the CPI Communications Reference book for more information on CPI

Communications calls.

User-defined communicationsThe current or last user-defined communications call that was issued,

for example, QOLELINK, QOLSETF, QOLSEND, or QOLRECV.

When the 5=Display option is entered next to the ICF00 identifier in the first orsecond Display Communications Status display, the following display appears:



40/290

Display SNUF ICF Session

Program device . . . . . . . . . . : ICF00Remote location . . . . . . . . . : RCHSNUFDevice . . . . . . . . . . . . . . : RCHSNUFICF file . . . . . . . . . . . . . : ICFFILE

Library . . . . . . . . . . . . : ICFLIB

Press Enter to continue.

F3=Exit F12=Cancel

The same information is displayed for the other ICF communication types. For

APPC communications the local location name, mode, remote network identifier,logical unit of work ID, and state are also shown.

When the 5=Display option is entered next to the B identifier in the first or second

Display Communications Status display, the following display appears:

Display CPI Communications

Conversation identifier . . . . . : BRemote location . . . . . . . . . : OVRTHERETransaction program . . . . . . . : PARTNERPGM

Device . . . . . . . . . . . . . : APPCDEVLocal location . . . . . . . . . : OVERHEREMode . . . . . . . . . . . . . . : BLANKRemote network identifier . . . . : APPNLogical Unit of Work ID . . . . . : RPC.MARTY2.X'A8FD757A2105'.00001State . . . . . . . . . . . . . . : SENDSide information . . . . . . . . : EXAMPLE

Library . . . . . . . . . . . . : XMPLIB

Press Enter to continue.

F3=Exit F12=Cancel

Working with Communications Configurations

You describe your communications environment to the AS/400 system by creating aset of configuration descriptions. These configuration descriptions identify anddescribe the communications devices and services being used. The configurationdescriptions available for AS/400 communications are as follows:



41/290

Line descriptionsDescribe the physical line and the line protocol that are used forcommunications.

Controller descriptionsDescribe physical remote controllers or provide logical representations ofremote systems.

Device descriptions

Describe the characteristics of physical or logical remote devices.

Mode descriptionsDescribe session limits and characteristics that are used for advanced

program-to-program communications (APPC), Advanced Peer-to-PeerNetworking (APPN), and high-performance routing (HPR).

Class-of-service descriptionsDescribe node and transmission group characteristics that are used for

APPN route selection.

Configuration listsContain entries that describe local and remote locations, pass-through

information, and addresses that are used by a configuration.

Network interface descriptionsDescribe the characteristics or protocol for communications with anIntegrated Services Digital Network (ISDN), frame-relay network, or

asynchronous transfer mode (ATM).

Connection listsContain entries describing local and remote locations in an ISDN network.

Network server descriptions

Describe the characteristics of an integrated PC server (IPCS).

NetBIOS descriptionsDescribe the characteristics of a NetBIOS network that are connected to an

IPCS.

Internetwork Packet Exchange (IPX) DescriptionsDescribe the characteristics of IPX support. IPX descriptions are used forAS/400 IPX support and IPCSs using NetWare.

Communications Configuration Commands

You create and maintain communications configuration descriptions with commandsfrom the system menus or from a command line. If you enter a “Work with...”command on the command line of any display, you are shown a Work withConfiguration Description display. From here you can create, change, copy, rename,

delete, display, print, or retrieve the CL source for a configuration description. Youcan also work with the configuration status. The available Work with ConfigurationDescription commands are as follows:

v Work with Line Descriptions (WRKLIND)

v Work with Controller Descriptions (WRKCTLD)

v Work with Device Descriptions (WRKDEVD)

v Work with Mode Descriptions (WRKMODD)

v Work with Class-of-Service Descriptions (WRKCOSD)

v Work with Configuration Lists (WRKCFGL)

v Work with Network Interface Descriptions (WRKNWID)


|

|

|

|

|

|

|


42/290

v Work with Connection Lists (WRKCNNL)

v Work with Network Server Descriptions (WRKNWSD)

v Work with NetBIOS Descriptions (WRKNTBD)

v Work with IPX Descriptions (WRKIPXD)

Note: For more information on configuration descriptions and the Work with

Configuration Description commands, refer to the Communications Configuration book.

You can also use the following communications configuration commands to maintainconfiguration descriptions:

Retrieve Configuration Source (RTVCFGSRC)Retrieves the configuration source for one or more configurationdescriptions

Save Configuration (SAVCFG)Saves configuration descriptions onto a save media

Restore Configuration (RSTCFG)

Restores previously saved configuration descriptions from a save mediaback onto the system

Note: More information on saving and restoring configurations is in theCommunications Configuration book, or the Backup and Recovery book.

In addition, you can access the status of configuration descriptions with thefollowing two commands:

Work with Configuration Status (WRKCFGSTS)

You use the WRKCFGSTS command to work with the status ofconfiguration descriptions in an interactive environment (see “Working withConfiguration Status”).

Retrieve Configuration Status (RTVCFGSTS)You use the RTVCFGSTS command in a CL program to retrieve the statusof a configuration description (see “Retrieving Configuration Status” onpage 32).

Working with Configuration Status

You can tell the system when to use the communications descriptions you haveconfigured by varying the descriptions on or off. You can also display the status of

the communications descriptions, which tells you the progress the system is makingin performing the operations you have requested. This section explains these

operations.

Varying a Configuration On or Off

After configuring your communications descriptions, you can vary these descriptionson or off using the Vary Configuration (VRYCFG) command. You can also use theWork with Configuration Status (WRKCFGSTS) display to vary on or off one ormore configuration objects, including a network server, network interface, line,

controller, and device.

Rules for varying on or off a specified object type:


|

|

|

|

|

|


43/290

v A line cannot be varied on:

–

Managerial Communication Notes

Documents

Transcript of Managerial Communication Notes