CXZOSAdminGuide en PDF
CXZOSAdminGuide en PDF
z/OS
Administration Guide
Version 4.2.3
Connect:Express z/OS Adminstration Guide
Version 4.2.3
First Edition
This documentation was prepared to assist licensed users of the Connect:Express system ("Sterling Commerce
Software"). The Sterling Commerce Software, the related documentation and the information and know-how it
contains, is proprietary and confidential and constitutes valuable trade secrets of Sterling Commerce, Inc., its affiliated
companies or its or their licensors (collectively "Sterling Commerce"), and may not be used for any unauthorized
purpose or disclosed to others without the prior written permission of Sterling Commerce. The Sterling Commerce
Software and the information and know-how it contains have been provided pursuant to a license agreement which
contains prohibitions against and/or restrictions on its copying, modification and use. Duplication, in whole or in part, if
and when permitted, shall bear this notice and the Sterling Commerce, Inc. copyright legend.
Where any of the Sterling Commerce Software or Third Party Software is used, duplicated or disclosed by or to the
United States government or a government contractor or subcontractor, it is provided with RESTRICTED RIGHTS as
defined in Title 48 CFR 52.227-19 and is subject to the following: Title 48 CFR 2.101, 12.212, 52.227-19, 227.7201
through 227.7202-4, FAR 52.227-14(g)(2)(6/87), and FAR 52.227-19(c)(2) and (6/87), and where applicable, the
customary Sterling Commerce license, as described in Title 48 CFR 227-7202-3 with respect to commercial software
and commercial software documentation including DFAR 252.227-7013(c) (1), 252.227-7015(b) and (2), DFAR
252.227-7015(b)(6/95), DFAR 227.7202-3(a), all as applicable.
The Sterling Commerce Software and the related documentation are licensed either "AS IS" or with a limited warranty,
as described in the Sterling Commerce license agreement. Other than any limited warranties provided, NO OTHER
WARRANTY IS EXPRESSED AND NONE SHALL BE IMPLIED, INCLUDING THE WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR USE OR FOR A PARTICULAR PURPOSE. The applicable Sterling
Commerce entity reserves the right to revise this publication from time to time and to make changes in the content
hereof without the obligation to notify any person or entity of such revisions or changes.
References in this manual to Sterling Commerce products, programs, or services do not imply that Sterling Commerce
intends to make these available in all countries in which Sterling Commerce operates.
Printed in the United States of America.
Copyright © 2003, 2010. Sterling Commerce, Inc. All rights reserved.
Connect:Express is a registered trademark of Sterling Commerce. All Third Party Software names are trademarks or
registered trademarks of their respective companies. All other brand or product names are trademarks or registered
trademarks of their respective companies.
CXZOSAG001
Contents
Preface
Exits Processed in the TOM and AFM Address Spaces ....................................................... 2-16
Connection Interface...................................................................................................... 2-16
Outgoing Sessions .................................................................................................. 2-18
Incoming Sessions .................................................................................................. 2-18
Journal Interface ............................................................................................................ 2-19
ii Connect:Express z/OS Admnistration Guide
Chapter 3 Controlling
Transfer Operations
Overview of Transfer Requests............................................................................................. 3-1
Request Controls ............................................................................................................ 3-2
Request Types ................................................................................................................ 3-2
Partner and Request Types...................................................................................... 3-3
Request Scheduling........................................................................................................ 3-3
File Types and Scheduling...................................................................................... 3-4
Checking the Status of a Request................................................................................... 3-5
Resources............................................................................................................................... 3-5
Connect:Express Resources ........................................................................................... 3-6
Internal Resources................................................................................................... 3-6
Global Resources .................................................................................................... 3-7
Specialized Resources............................................................................................. 3-7
Individual Resources............................................................................................... 3-8
Network Resources ........................................................................................................ 3-9
System Resources........................................................................................................... 3-9
SYSIN Resource Fields.................................................................................................. 3-9
Required Parameters ............................................................................................... 3-10
X.25 Parameters ...................................................................................................... 3-11
TCP/IP Parameters.................................................................................................. 3-11
Optional Parameters................................................................................................ 3-11
Controlling the Flow of Transfers.................................................................................. 3-12
Reporting............................................................................................................................... 3-40
Monitor Status................................................................................................................ 3-40
Operations Status ........................................................................................................... 3-41
Additional Reporting ..................................................................................................... 3-41
APM Messages and Logging.................................................................................. 3-41
Connect:Express Messages..................................................................................... 3-41
Sending User Messages to the SYSLOG Files with L1B2LOG ............................ 3-42
Reliability.............................................................................................................................. 3-43
Conditions Requiring an APM Start....................................................................... 3-44
Conditions Requiring a Hot-start (Run=H) ............................................................ 3-44
Conditions Requiring a Cold-start (RUN=C)......................................................... 3-45
Timers ............................................................................................................................ 3-46
Chapter 6 Troubleshooting
Tracking Events .................................................................................................................... 6-1
Using Diagnostic Tools ................................................................................................. 6-1
Using User Exits to Trace Events .................................................................................. 6-2
Index
Preface
The Connect:Express z/OS Administration Guide is for programmers and network operations staff who install
and maintain Connect:Express z/OS 4.2.3.
This guide assumes knowledge of the z/OS operating system, including its applications, network, and
environment. If you are not familiar with the OS/390 operating system, refer to the z/OS library of manuals.
Chapter Overview
The Connect:Express z/OS Administration Guide is organized into the following chapters and appendices:
Chapter/Appendix Description
Chapter 1 This chapter describes Connect:Express support for the z/OS sysplex environment and
Sysplex Environment includes procedures to implement a Connect:Express/Plex environment and Extended
Recovery.
Chapter 2 This chapter describes the User Exit interface which enables you to start actions throughout
User Exits the transfer process.
Chapter 3 This chapter describes how Connect:Express processes transfer requests and how you can
Controlling Transfer control transfer operations using automation tools, scheduling features, resources, and
Operations security options.
Chapter 4 This chapter describes the file transfer operations of Connect:Express. It covers PeSIT,
Incoming and Outgoing Odette, and ETEBAC transfers that are processed in the TOM, ANM, and APM address
Transfers spaces. This chapter outlines the steps of an incoming and an outgoing file transfer and
identifies the parameters, the transfer process, and reporting capabilities.
Chapter 5 This chapter discusses the PeSIT and ODETTE-FTP protocols. It describes how each
PeSIT and ODETTE-FTP parameter is used, how files are exchanged with Partners, and how information is verified.
Protocols The relationship between internal events and external events is also discussed.
Chapter 6 This chapter describes common problems that you may encounter, tools that you can use to
Troubleshooting identify the problem, and corrective action that you can take. It also includes information
about enhancing system performance and getting help from Technical Support.
Chapter 7 This chapter describes the product maintenance process, with or without SMP/E.
Installing Maintenance
Appendix A This appendix describes the Connect:Express user libraries which provide examples to help
User Libraries you customize and automate Connect:Express.
x Connect:Express z/OS Administration Guide
Chapter/Appendix Description
Appendix B This appendix describes error codes and messages from the Connect:Express application.
Error Codes and
Messages
Appendix C This appendix lists and describes monitor commands that you can use to activate or
Monitor Commands deactivate resources.
Appendix D This appendix identifies the SYSIN parameters for Connect:Express and describes the
Initialization Parameters parameters that are required for Connect:Express to work as a stand-alone, a Plex
manager, or a Plex server, and the optional parameters that you can use to increase
resource productivity and to take advantage of advanced features.
Appendix E This appendix provides definitions of the VTAM resources for Connect:Express. It includes
Definition of VTAM definitions of an application major node, a logmode, a switched major node for X.25, an
Resources interpret table for transparent PAD, and an X25NPSI definition for X.25 links.
Appendix F This appendix describes the DD Names used by Connect:Express in different address
JCL Files for the Monitor spaces.
Appendix G This appendix describes how to set up the Auxiliary Trace Manager (ATM).
Using protocol traces
Appendix H This appendix describes how to define environment variables and how to use long names
Using Environment
Variablesr
Connect:Express Documentation
Connect:Express documentation consists of the following manuals:
The Connect:Express z/OS 4.2.3 Release Notes lists maintenance updates and any important notes.
The Connect:Express z/OS 4.2.3 Installation Guide describes the planning and installation of
Connect:Express.
The Connect:Express z/OS 4.2.3 User Guide includes general information on using the TSO/ISPF
interface, and serves as a reference of user and environment commands.
The Connect:Express z/OS 4.2.3Utilities Guide describes the optional Utilities package that you can
integrate with Connect:Express.
The Connect:Express z/OS 4.2.3 FTP Guide provides you with the information that you need to use
Connect:Express with the FTP protocol.
The Connect:Express z/OS 4.2.3 Administration Guide provides detailed information about transfer
operations for system administrators and other advanced users of Connect:Express.
The Connect:Express z/OS 4.2.3 Options Guide provides information about the CICS, IMS, and RJE
interfaces available for Connect:Express.
The Connect:Express z/OS 4.2.3 PeSIT User Fields Guide describes how you can exchange the PeSIT
Pi37 and Pi99 fields with any PeSIT software.
The Connect:Express z/OS 4.2.3 Etebac3 User Guide provides you with the information that you need to
use Connect:Express with the Etebac3 protocol.
The Connect:Express HTTP Option Implementation Guide provides you with the information that you
need to implement HTTP access to Connect:Express z/OS repository.
The Connect:Express version 4.2.3 SSL Guide includes general information on implementing secured file
transfers.
Preface xi
The Connect:Express version 4.2.3 Sysplex Supervision Guide includes general information on
implementing a group of Connect:Express Plex managers under control of a Connect:Express Plex
supervisor.
xii Connect:Express z/OS Administration Guide
Convention Description
UPPERCASE Uppercase letters in the command format indicate that you type in information as shown.
LETTERS
Lowercase letters Lowercase letters or words in commands or syntax boxes require substitution by the user. For
example, index1.index2.PARMLIB indicates that you must provide the first and second indexes of
the string. "PARMLIB" is mandatory.
Bold Letters Bold print in syntax boxes indicates Connect:Express commands and required parameters. For
example, PLEX=N indicates that the parameter PLEX must be set to N.
Underlined Letters Underlining indicates default values for parameters and subparameters. For example, PLEX=Y|N
specifies that the default for PLEX is N.
Vertical Bars (|) Vertical bars indicate that you can supply one of a series of values separated by the vertical bars.
For example RUN=H|C specifies that H or C is valid.
Monospaced Monospaced characters represent information for screens, commands, Processes, and
characters reports.
(characters of equal
width)
£ or # The Pound character (£) and the hash character (#) are equivalent.
Chapter 1
Sysplex Environment
This chapter describes Connect:Express support for the z/OS sysplex environment and includes procedures to
implement a Connect:Express/Plex environment and Extended Recovery. Refer to the Connect:Express z/OS
Sysplex Supervision Guide for further information.
Overview
Connect:Express now provides full support for the z/OS sysplex environment with the release of
Connect:Express z/OS. For example, users are no longer required to run all Connect:Express MVS
applications, batch utilities, and online connections to Connect:Express within the same z/OS image that runs
Connect:Express. Now, Connect:Express z/OS initializes a manager/server environment. This environment is
called a Connect:Express/Plex. On one z/OS image, the Connect:Express/Plex Manager and its associated
address spaces like the APM, ANM and AFM, are started. The Connect:Express/Plex Manager is the system
that actually performs the file transfers and is known as the TOM Manager. During initialization, the TOM
Manager issues commands to start the Connect:Express/Plex Servers (TOM Servers) in other z/OS images of
the sysplex. This manager/server environment enables the Connect:Express subsystem to be established on all
z/OS images and lets any user interact transparently with the TOM Manager.
Connect:Express z/OS also provides support for the z/OS Extended Recovery Facility, so you do not need to
use other automation products or setup manual procedures to take over if Connect:Express fails. When
Connect:Express is not configured as a Connect:Express/Plex, it is called a Connect:Express stand-alone.
Note: Before using any of the sample code in this section, you should have a running, stand-alone
Connect:Express Version 4.2 system.
1-2 Connect:Express z/OS Administration Guide
C:X
C:X
TOM
Server
CTC TOM
C:X
API ANM APM
User
C:X
ISPF Network
User
C:X C:X
IMS API
User User
CTC
CTC
C:X
TOM
Server
C:X
CICS
User
C:X
Batch
Utility
OS/390 SYSC
Chapter 1 / Sysplex Environment 1-3
C:X
C:X
TOM
TOM
Server
C:X
API ANM APM
User
C:X
ISPF Network
User
C:X C:X
IMS API
User User
C:X
TOM
Server
C:X
CICS
User
C:X
Batch
Utility
OS/390 SYSC
Note: Both sysplex and parallel sysplex environments are supported. IBM defines a sysplex as a collection
of z/OS images that share work, and a parallel sysplex as a sysplex that includes a Coupling Facility.
1-4 Connect:Express z/OS Administration Guide
Connect:Express z/OS makes use of the z/OS facility XCF to communicate between the Connect:Express
TOM Manager and its Connect:Express TOM Servers.
Keyword Description
PLEX=N|Y Specifies whether the Connect:Express system will run in a Connect:Express/Plex environment.
PLEX=Y indicates that the Connect:Express/Plex environment is used and that the
Connect:Express initialization will open and read the CXPLEX data set to retrieve the local
initialization parameters that apply to this member of the Connect:Express/Plex. The CXPLEX DD
and SYSPRTX DD are required for PLEX=Y. PLEX=N indicates that Connect:Express will run as
a stand-alone.
XCFGROUP=$ssn$| Indicates the XCF group name for the Connect:Express/Plex or Extended Recovery environment.
$$ssn$$|name ssn is the subsystem name for this Connect:Express system.
If PLEX=Y, then XCFGROUP=$ssn$
If PLEX=N, then XCFGROUP=$$ssn$$ (used for Extended Recovery)
The XCF group name must be unique within the z/OS sysplex. XCF group names that begin with
A through I or SYS are reserved by IBM. Typically you do not need to specify the XCFGROUP=
keyword.
XRF=N|Y Indicates if Extended Recovery is enabled or not. Extended Recovery enables a partially
initialized Connect:Express stand-alone, Plex Manager, or Plex Server to watch over the active
Connect:Express member. If the active Connect:Express member fails, the partially initialized one
takes over. The CXPLEX DD and SYSPRTX DD are required for XRF=Y. This specifies the
standby TOM procedure that starts during initialization.
Keyword Description
MGRTYP=NO|YES Specifies the manager type for the member. A member can be a Connect:Express/Plex Manager or
Server. When PLEX=Y, it must be the first keyword in the CXPLEX data set.
MGRTYP=YES, the member is a Connect:Express/Plex Manager.
MGRTYP=NO, the member is a Connect:Express/Plex Server.
XCFTIM=3|nn Specifies (in minutes) the time-out value for XCF communications. This is only used when
PLEX=Y. Time-outs that occur when a Connect:Express/Plex Manager is attempting to
communicate with a Connect:Express/Plex Server causes the Connect:Express/Plex Manager to
terminate the Connect:Express/Plex Server. Time-outs that occur when a Connect:Express/Plex
Server is attempting to communicate with a Connect:Express/Plex Manager cause a WTOR to be
issued. The operator can respond with RETRY or CANCEL to retry the communication or to cancel
the Connect:Express/Plex Server. The default is 3.
Chapter 1 / Sysplex Environment 1-5
Keyword Description
XRFPRC=(sys-name, Indicates the Extended Recovery environment system name to which a START command is routed
proc-name) to start its procedure name. This is only used when XRF=Y or Extended Recovery is enabled. The
started member will recognize that it is in an Extended Recovery environment and that the active
member is already up. It will monitor the health of the active member, and wait to take over its work
if the active member fails. For example, if XRFPRC=(SYSC,CXTOMXC), the following command
would be issued to z/OS: RO SYSC,S CXTOMXC. Extended Recovery is supported in both a
PLEX=Y and PLEX=N environment. If XRF=N, this keyword is ignored.
Note: A SYSOUT file referenced by the SYSPRTX DD card in the initialization JCL contains a summary of
CXPLEX cards that were processed.
Note: The same z/OS subsystem must be defined in SYSA, SYSB, and SYSC, and will be used by the
Connect:Express/Plex.
Complete the following steps to change your stand-alone Connect:Express system into a
Connect:Express/Plex:
1. Create a member (MANAGER) in the Connect:Express index1.index2.PARMLIB and include the
following statements.
MGRTYP=YES
SERVER=(SYSA,CXTOMSA)
SERVER=(SYSC,CXTOMSC)
2. Create a member (SERVERA) in the same PDS and include the following statement.
MGRTYP=NO
1-6 Connect:Express z/OS Administration Guide
3. Create a member (SERVERC) in the same PDS and include the following statement.
MGRTYP=NO
4. Ensure that the CXTOM procedure includes the following keywords in the PROC prototype and that these
new keywords are passed to the PGM=P1B2P000 step.
5. Add a DD statement to the CXTOM procedure step that executes PGM=P1B2P000 and points to the
MANAGER member, as shown below.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(MANAGER)
//SYSPRTX DD SYSOUT=&OUT
//SYSCHK DD DUMMY
//SYSCHK2 DD DUMMY
//SYSANM DD DUMMY
//SYSJCL DD DUMMY
//SYSJNL DD DUMMY
//SYSEVT DD DUMMY
//SYSPRM DD DUMMY
//SYSFIL DD DUMMY
//SYSPAR DD DUMMY
//SYSSNA DD DUMMY
//SYSX25 DD DUMMY
//SYSTCP DD DUMMY
//ET5PID DD DUMMY
//ET5FID DD DUMMY
//DIFJNL DD DUMMY
//DIFMBX DD DUMMY
//RSAPARM DD DUMMY
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(SERVERA)
9. Copy the SYSRCY data set used by CXTOM and name it appropriately for the CXTOMSA procedure.
Then change the SYSRCY DD in CXTOMSA to point to this copied SYSRCY data set.
//SYSRCY DD …
Chapter 1 / Sysplex Environment 1-7
10. If the SYSLOG file is not a SYSOUT data set, format a new log file and change the SYSLOG DD in
CXTOMSA to point to this new log data set. You can format the SYSLOG file by referring to step 13 of
the installation procedure. The SYSLOG should be a SYSOUT data set.
//SYSLOG DD SYSOUT=&OUT
11. Copy the CXTOMSA member and name this copy CXTOMSC.
12. Change the CXPLEX DD to point to the SERVERC member.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(SERVERC)
13. Copy the SYSRCY data set used by CXTOM and name it appropriately for the CXTOMSC procedure.
Then change the SYSRCY DD in CXTOMSC to point to this copied SYSRCY data set.
//SYSRCY DD …
14. If the SYSLOG file is not a SYSOUT data set, format a new log file and change the SYSLOG DD in
CXTOMSC to point to this new log data set. You can format the SYSLOG file by referring to step 13 of
the installation procedure. The SYSLOG should be a SYSOUT data set.
//SYSLOG DD SYSOUT=&OUT
Starting a Connect:Express/Plex
After you convert your stand-alone system to a Connect:Express/Plex, start your Connect:Express system on
SYSB as usual, but specify PLEX=Y, as shown below.
RO SYSB,S CXTOM,SSN=TOM4,PLEX=Y
Connect:Express recognizes the PLEX=Y parameter and opens the CXPLEX data set during initialization. The
CXPLEX data set indicates that it is a Connect:Express/Plex Manager and then starts its Connect:Express/Plex
Servers and related address spaces. To start the Servers, commands are issued to z/OS that route START
commands to SYSA and SYSC. The Connect:Express/Plex Manager sends the PLEX=Y, XRF=, and
XCFGROUP= parameters to the Connect:Express/Plex Servers, and then the Connect:Express/Plex Manager
initializes XCF communications.
When the Connect:Express/Plex Servers are started, they read the PLEX=Y parameter and open the CXPLEX
data set. This data set tells Connect:Express to be a Connect:Express/Plex Server and not to start any other
address space. The Connect:Express/Plex Server initializes XCF communications and interfaces with the
Connect:Express/Plex Manager. Any application requesting Connect:Express facilities can run in the same
Connect:Express/Plex Server z/OS image. The application has the same capabilities as if it were running on the
Connect:Express/Plex Manager’s z/OS image.
1-8 Connect:Express z/OS Administration Guide
Extended Recovery
Connect:Express z/OS version 4.2 supports Extended Recovery in both stand-alone and Plexed environments.
You can implement Extended Recovery with the same z/OS image or with different z/OS images. When using
the same image, the recovery is processed if Connect:Express stops. When you implement Extended Recovery
with different z/OS images, the recovery is processed if Connect:Express stops, or if the z/OS image on which
Connect:Express is running stops.
XRFPRC=(SYSB,CXTOM1)
2. Create another member (CXXRF2) in the same PDS and include the following statement.
XRFPRC=(SYSB,CXTOM1)
3. Ensure that the CXTOM procedure includes the following keywords in the PROC prototype and that these
new keywords are sent to the step executing PGM=P1B2P000.
4. Add a DD statement to the CXTOM procedure step that executes the step running PGM=P1B2P000.
PGM=P1B2P000 points to the CXXRF1 member created in step 3.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRF1)
//SYSPRTX DD SYSOUT=&OUT
5. Change the DISP= in the SYSCHK and SYSRCY DDs to DISP=SHR. This change is required to enable
the stand-alone member to have the two data sets allocated, but not opened.
//SYSCHK DD …,DISP=SHR
//SYSRCY DD …,DISP=SHR
6. Copy the CXTOM procedure and name the copy CXTOM1. Delete all steps before the step executing
PGM=P1B2P000.
7. Change the CXPLEX DD to reference the member CXXRF2.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRF2)
Chapter 1 / Sysplex Environment 1-9
RO SYSB,S CXTOM,SSN=TOM4,XRF=Y
Connect:Express recognizes the XRF=Y parameter and opens the CXPLEX data set during initialization.
Connect:Express also checks to see if this member is the active or standby member by looking in the XCF
group.
If there already is an active member, then this is the standby TOM for the active member. If the active
member fails, this standby TOM completes its initialization and then takes control.
If there is no active member, then this Connect:Express TOM becomes the active member and continues
initializing. After initialization, it issues a START command to its standby TOM, which is indicated by the
XRFPRC= keyword in the CXPLEX data set.
If the CXTOM address space fails, the CXTOM1 address space recognizes this failure, continues its
initialization, and takes over the work. Then, it issues a START command to its standby TOM as specified by
the XRFPRC= keyword in the CXPLEX data set. This starts the CXTOM1 procedure, and the standby TOM
takes over.
The CXTOM procedure can include preliminary steps like off loading the recovery file and the checkpoint file
or controlling the journal file. These steps do not have to be repeated in the extended recovery process once
Connect:Express is running. During extended recovery, the CXTOM1 procedure starts with no preliminary
steps. If another failure occurs, extended recovery starts the CXTOM1 procedure on the next system, and the
process is repeated.
Note: Normal termination of the active member terminates the standby TOM with RC=0.
Note: If using SNA connections, define the VTAM APPLs in all z/OS images as DYNAMIC. If using
TCP/IP, define the IP address as a VIPA address so it can be moved with the Connect:Express
application.
Complete the following steps to convert your stand-alone Connect:Express system to a Connect:Express
system with Extended Recovery on different z/OS images:
1. Create a member (CXXRFA) in index1.index2.PARMLIB and include the following statements.
XRFPRC=(SYSA,CXTOMA)
2. Create another member (CXXRFB) in the same PDS and include the following statement.
XRFPRC=(SYSB,CXTOMB)
1-10 Connect:Express z/OS Administration Guide
3. Create another member (CXXRFC) in the same PDS and include the following statement.
XRFPRC=(SYSC,CXTOMC)
4. Ensure that the CXTOM procedure includes the following keywords in the PROC prototype and that these
new keywords are sent to the step executing PGM=P1B2P000.
5. Add a DD statement to the CXTOM procedure that runs the step executing PGM=P1B2P000.
PGM=P1B2P000 points to the CXXRFA member created in step 4.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRFA)
//SYSPRTX DD SYSOUT=&OUT
6. Change the DISP= in the SYSCHK and SYSRCY DDs to DISP=SHR. This change is required to enable
the stand-alone member to have two data sets allocated, but not opened.
//SYSCHK DD …,DISP=SHR
//SYSRCY DD …,DISP=SHR
7. Copy the CXTOM procedure and name the copy CXTOMA. Delete all steps before the step executing
PGM=P1B2P000.
8. Change the CXPLEX DD to reference the member CXXRFC.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRFC)
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRFB)
11. Copy the CXTOMC procedure and name the copy CXTOMB.
12. Change the CXPLEX DD to reference the member CXXRFA.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(CXXRFA)
RO SYSB,S CXTOM,SSN=TOM4,XRF=Y
Connect:Express recognizes the XRF=Y parameter and opens the CXPLEX data set during initialization.
Connect:Express also checks if this member is the active or standby member by looking in the XCF group.
Chapter 1 / Sysplex Environment 1-11
If there already is an active member, then this is the standby TOM for the active member. If the active
member fails, this standby TOM completes its initialization and then takes control.
If there is no active member, then this Connect:Express TOM becomes the active member and continues
initializing. After initialization, it issues a START command to its standby TOM, which is specified by the
XRFPRC= keyword in the CXPLEX data set.
If the CXTOM address space fails, the CXTOMA address space on SYSA recognizes the failure, continues its
initialization, and takes over the work. Then, it issues a START command to its standby TOM as specified by
the XRFPRC= keyword in the CXPLEX data set.
The execution of CXTOM (on SYSB), CXTOMA (on SYSA), CXTOMC (on SYSC), CXTOMB (on SYSB),
and CXTOMA (on SYSA), lets the CXTOM procedure include preliminary steps. This is not repeated once
Connect:Express is running. During extend recovery, the CXTOMA (on SYSA) procedure starts. If another
failure occurs, Extended Recovery starts the CXTOMC (on SYSC) procedure, and the process continues.
Note: Normal termination of the active member terminates the standby TOM with a RC=0.
Note: If using SNA connections, define the VTAM APPLs in all z/OS images as DYNAMIC. If using
TCP/IP, define the IP address as a VIPA address so it can be moved with the Connect:Express
application.
The same z/OS subsystem must be defined on SYSA, SYSB, and SYSC, and is used by the
Connect:Express/Plex. Complete the following steps to convert your stand-alone Connect:Express system to a
Connect:Express/Plex with Extended Recovery:
1. Create a member (MANAGERB) in the Connect:Express index1.index2.PARMLIB and include the
following statements.
MGRTYP=YES
SERVER=(SYSA,CXTOMSA)
SERVER=(SYSC,CXTOMSC)
XRFPRC=(SYSA,CXTOMA)
MGRTYP=YES
SERVER=(SYSB,CXTOMSB)
SERVER=(SYSC,CXTOMSC)
XRFPRC=(SYSC,CXTOMC)
1-12 Connect:Express z/OS Administration Guide
MGRTYP=YES
SERVER=(SYSA,CXTOMSA)
SERVER=(SYSB,CXTOMSB)
XRFPRC=(SYSB,CXTOMB)
4. Create a member (SERVERA) in the same PDS and include the following statements.
MGRTYP=NO
XRFPRC=(,CXTOMSA)
5. Create a member (SERVERB) in the same PDS and include the following statements.
MGRTYP=NO
XRFPRC=(,CXTOMSB)
6. Create a member (SERVERC) in the same PDS and include the following statements.
MGRTYP=NO
XRFPRC=(,CXTOMSC)
7. Ensure that the CXTOM procedure includes the following keywords in the PROC prototype and that these
new keywords are sent to the PGM=P1B2P000 step.
8. Add a DD statement to the CXTOM procedure step that executes PGM=P1B2P000 and points to the
MANAGERB member.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(MANAGERB)
//SYSPRTX DD SYSOUT=&OUT
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(MANAGERA)
11. Copy the CXTOM procedure and name the copy CXTOMB.
12. Change the CXPLEX DD to point to the MANAGERB member.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(MANAGERB)
13. Copy the CXTOM procedure and name the copy CXTOMC.
Chapter 1 / Sysplex Environment 1-13
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(MANAGERC)
15. Copy the CXTOM procedure and name the copy CXTOMSA.
16. In CXTOMSA, delete all steps before the step executing PGM=P1B2P000. Then change the following DD
cards to those shown.
//SYSCHK DD DUMMY
//SYSCHK2 DD DUMMY
//SYSANM DD DUMMY
//SYSJCL DD DUMMY
//SYSJNL DD DUMMY
//SYSEVT DD DUMMY
//SYSPRM DD DUMMY
//SYSFIL DD DUMMY
//SYSPAR DD DUMMY
//SYSSNA DD DUMMY
//SYSX25 DD DUMMY
//SYSTCP DD DUMMY
//ET5PID DD DUMMY
//ET5FID DD DUMMY
//DIFJNL DD DUMMY
//DIFMBX DD DUMMY
//RSAPARM DD DUMMY
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(SERVERA)
18. Copy the SYSRCY data set used by CXTOM and name it appropriately for the CXTOMSA procedure.
Change the SYSRCY DD in CXTOMSA to point to this copied SYSRCY data set.
//SYSRCY DD …
19. If the SYSLOG file is not a SYSOUT data set, format a new log file and change the SYSLOG DD in
CXTOMSA to point to this new log data set. Ensure that SYSLOG is a SYSOUT data set.
//SYSLOG DD SYSOUT=&OUT
20. Copy the CXTOMSA member and name this copy CXTOMSB.
21. Change the CXPLEX DD to point to the SERVERB member.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(SERVERB)
22. Copy the SYSRCY data set used by CXTOM and name it appropriately for the CXTOMSB procedure.
Change the SYSRCY DD in CXTOMSB to point to this copied SYSRCY data set.
//SYSRCY DD …
1-14 Connect:Express z/OS Administration Guide
23. If the SYSLOG file is not a SYSOUT data set, format a new log file and change the SYSLOG DD in
CXTOMSA to point to this new log data set. Ensure that SYSLOG is a SYSOUT data set.
//SYSLOG DD SYSOUT=&OUT
24. Copy the CXTOMSB member and name this copy CXTOMSC.
25. Change the CXPLEX DD to point to the SERVERC member.
//CXPLEX DD DISP=SHR,DSN=index1.index2.PARMLIB(SERVERC)
26. Copy the SYSRCY data set used by CXTOM and name it appropriately for the CXTOMSC procedure.
Change the SYSRCY DD in CXTOMSC to point to this copied SYSRCY data set.
//SYSRCY DD …
27. If the SYSLOG file is not a SYSOUT data set, format a new log file and change the SYSLOG DD in
CXTOMSA to point to this new log data set. Ensure that SYSLOG is a SYSOUT data set.
//SYSLOG DD SYSOUT=&OUT
RO SYSB,S CXTOM,SSN=TOM4,PLEX=Y,XRF=Y
Connect:Express recognizes the PLEX=Y and XRF=Y parameters and opens the CXPLEX data set during
initialization. The CXPLEX data set indicates that it is a Connect:Express/Plex Manager and starts its
Connect:Express/Plex Servers and related address spaces. To start the servers, commands are issued to z/OS
that send START commands to SYSA and SYSC. Then, the Connect:Express/Plex Manager sends the
PLEX=Y, XRF=Y, and XCFGROUP= parameters to the Connect:Express/Plex Servers. The Connect:Express
standby Server is started on SYSA, and then the Connect:Express/Plex Manager initializes XCF
communications.
When the Connect:Express/Plex Servers are started, they read the PLEX=Y and XRF=Y parameters and open
the CXPLEX data set, which tells Connect:Express to be a Connect:Express/Plex Server and not to start any
other address space. The Connect:Express/Plex Server initializes XCF communications and interfaces with the
Connect:Express/Plex Manager. Any application requesting Connect:Express facilities runs in the same
Connect:Express/Plex Server z/OS image. The application has the same capabilities as if it were running on the
Connect:Express/Plex Manager’s z/OS image. The Connect:Express/Plex Server issues the command to start
its standby Server which is also running on the Plex Manager’s z/OS image.
If a Connect:Express/Server fails, the standby server takes over immediately. The standby Server then joins the
XCF group with the Connect:Express/Manager and starts its own standby Server on the same z/OS image.
Chapter 1 / Sysplex Environment 1-15
If the Connect:Express/Plex Manager fails, the Connect:Express/Plex Servers and their standby Servers
terminate automatically along with other address spaces started by the Connect:Express/Plex Manager. Then,
the standby Connect:Express/Plex Manager on SYSA takes over immediately and starts its address spaces
which are the Connect:Express/Plex Servers on SYSB and SYSC. Then, the manager starts its standby
Connect:Express Server on SYSC.
Note: Normal shutdown of the Connect:Express/Plex Manager will cause the Connect:Express/Plex Servers
and all standby Connect:Express Servers in the same XCF group to terminate with RC=0.
1-16 Connect:Express z/OS Administration Guide
Chapter 2
User Exits
This chapter describes the User Exit interface which enables you to start actions throughout the transfer
process.
Overview
Connect:Express provides all the functionality to execute transfers beginning with requesting a transfer to
reporting a successful end of transfer. The transfer operation process is outlined in the table below:
User exits result in actions and can be started at any time during the transfer process. For example, you can
start an action during the monitor initialization or termination.
Some standard exits are provided as load modules or source examples. The following table identifies standard
user exits and the library where you can find them.
EX£APM050 SAMPLIB The data translation facility uses the record processing interface. Source modules
EX£APM051 are provided for you to customize the translation tables if a specific translation
EX£APM052 table is to be used with one partner.
M1USRCNA MACLIB The RACF connection user exit that you can customize.
L1USRCNA SAMPLIB A connection user exit is provided that performs RACROUTE calls.
L1EXSNAP LOADLIB A trace module is provided that can be set into normal exit definition fields or
link-edited with user exits. It dumps exit communication areas at entry of user
exits (connection, selection, transfer initialization, record processing, security and
transfer termination), provided that a SNAPDUMP file is allocated to
Connect:Express and/or the APM.
L1EX£AE2 LOADLIB Trace modules are provided that can be set into normal exit definition fields. It
prints exit communication areas at the entry of the user exits interface, during
transfer initialization and transfer termination. It also dynamically allocates
SYSOUT ’EX£????’ in the APM.
User Exits
A user exit typically corresponds to one phase of the transfer process such as initialization, termination, or
record processing. User exits can be:
Used specifically for one transfer. It executes a function associated with the transfer of one file, like
allocation using a transfer initialization exit. This exit is loaded dynamically when needed, then deleted. It
is defined in the file attributes.
Shared by several transfers to provide a general service, like data translation using a record processing
exit. This exit is loaded during initialization and defined in a presentation table or in the SYSIN file.
Called during the different phases of the transfer. This user exit is called a server exit because a server
is loaded during initialization. The connection server exit, defined in the T1B2PCNT table, and the
transfer server exit, defined in the T1B2PSRT, are examples of server exits.
Note: Standard calls and server type calls can be mixed for a single transfer. See Mixing Server Exits and
Standard User Exits on page 2-20.
User exits are loaded dynamically during initialization or during transfer execution depending on whether they
are dedicated to one transfer or are common to many. Depending on the exit type, user exits are loaded by the
TOM address space or by the APM address space from their SYSLIB. The TOM address space calls
initialization, termination, connection, and journal exits. The APM address space calls initialization,
termination, selection, security, transfer, and record processing exits. The AFM address space calls
initialization, termination and connection exits and the EAS address space calls initialization, termination,
selection, transfer, and record processing exits. With FTP transfers, the SYSLIB is not needed.
Server exits must be reentrant, while record processing exits and beginning and end of transfer exits should be
reentrant. Connect:Express supports both reentrant and non-reentrant exits. User exits should be assembly
modules, however COBOL and PL1 modules are also supported.
Connect:Express protects against user exits that take too much time to execute using timers. A timer is set
when branching to an exit, and when the time expires the task is stopped. The following standard IBM link
conventions are used:
Chapter 2 / User Exits 2-3
D1B2PCNX CNX* Connection interface, TOM and AFM initialization, TOM and AFM
termination
D1B2RUEX UEX* Selection, transfer initialization, and termination, APM and EAS
initialization, APM and EAS termination.
Connect:Express executes symmetrical open/close calls to user exits. This means that after a user exit has
executed successfully, the symmetrical call is activated. For example, if a user exit is called during
Connect:Express initialization and has executed successfully, it will be called again when Connect:Express
terminates. A user exit can also be called during initialization, termination, and at each occurrence of the
process for which it is responsible. This is important when setting up user exits because it means that a user exit
can be called several times. Some exits are disabled when their execution fails, others make the process stop if
the code they return is not OK. The following list provides examples:
Exit Example
Connection exit Is normally called during Connect:Express initialization, at each connection to or from a Partner,
at each end of connection and during Connect:Express termination. The connection exit can
reject the connection. The end of connection call is executed only if the connection call was
successful. The connection exit is disabled if the initialization call is unsuccessful.
Selection exit Is normally called during Connect:Express initialization, at each transfer request to or from a
partner, at each end of transfer and during Connect:Express termination. The selection exit can
reject the transfer request. The end of transfer call is executed only if the transfer request call was
successful. The selection exit is disabled if the initialization call is unsuccessful.
Transfer initialization Is called once, but it is related to the transfer termination exit which is called only if the transfer
exit initialization phase was successfully executed. The transfer initialization exit can reject the
transfer.
NOTE: You can run a transfer initialization exit and no transfer termination exit.
Transfer termination Is called once, but only if the transfer initialization phase was successfully executed. It can be
exit called even if no transfer initialization exit was defined. The transfer termination exit can reject a
transfer on the receiver side.
NOTE: You can run a transfer termination exit and no transfer initialization exit.
2-4 Connect:Express z/OS Administration Guide
Exit Example
Record processing Is called during the open file phase, during each record process and during the close file phase.
exit The transfer record processing exit can interrupt the transfer. If the open phase call is
unsuccessful, the transfer is interrupted, and no other call is executed. If the open call was
successful and the transfer is interrupted, the close call is executed.
Journal exit Is normally called during Connect:Express initialization, at each end of transfer, and during
Connect:Express termination. The journal exit is disabled if the execution is unsuccessful, at any
time.
The table below shows the D1B2PCNX, D1B2RUEX, D1B2RPEX and D1B2PJNL call and status field
values. The D1B2PRAC structure corresponds to a fixed call type.
Connect:Express SYSIN file - UEXJNL= D1B2PJNL Only header is passed input, TOM
initialization Or SYSINEXT if "INIT" R15 output (pre-loaded)
UEXJNL=L1B2PDIX
(journal exits driver)
Connect:Express SYSIN file - UEXJNL= D1B2PJNL Only header is passed input, TOM
termination or SYSINEXT if "TERM" R15 output (pre-loaded)
UEXJNL=L1B2PDIX
JOURNAL SYSIN file - UEXJNL= D1B2PJNL Incoming started transfers and TOM
Or SYSINEXT if outgoing transfers during (pre-loaded)
UEXJNL=L1B2PDIX termination of transfer,
(journal exits driver) successful or not.
Note: Each time an EAS is started or terminated, the selection exit is invoked for initialization or termination.
An EAS is started only when needed, as opposed to the APM which is started for performing future
transfers.
The table below shows how calls to user exits correspond to the successive protocol steps and to
Connect:Express SYSLOG reports. For example, when the CONNECTION OPENED message is issued in the
Chapter 2 / User Exits 2-7
SYSLOG file, the user connection exit has already been invoked with a 'C' call operation. See “Connection
Interface” on page 2-16 for more information.
Note: A re-compile and re-linkedit is necessary when upgrading from previous versions because exits are an
extension of Connect:Express.
Messages
The following messages are sent when the monitor starts and stops, if the option INIT. is selected in the
activation parameters for the exit. (TSO/ISPF 3.3.CNT)
Rejected Message
The following message is sent when USER is rejected.
Accepted Message
The following message is sent when USER is accepted to access the monitor.
Note: The keyword $PESIT$ is reserved. All connections from a partner with the symbolic name $PESIT$
are rejected.
Note: No process is performed during Connect:Express initilalization and termination. Only the INIT and
TERM information messages are issued.
2-10 Connect:Express z/OS Administration Guide
1 * * * * * N Y L1GFICN1
2 3 * * I * N Y L1USRCNA
3 5 * * I * N Y L1USRCNA
4 6 * * I * N Y L1USRCNA
$PESITD$ PESITD Default profile for a user that calls using the PeSIT D protocol.
$PESITE$ PESITE Default profile for a user that calls using the PeSIT E protocol.
$FTP$ FTP Default profile for a user that calls using the FTP protocol.
The default partner is only used for incoming calls, and enables you to leave the network address field blank.
The following screen shows the definition of the PESIT E default partner. The partner type is set to Other so
that the PeSIT User fields facility can be used. The session protocol number is set to 5 for PeSIT E. The total
number of sesions is equal to the number of IN sesions. No OUT session is allowed. The link type is TCP/IP,
and no TCP/IP address control is performed.
Chapter 2 / User Exits 2-11
PARTNER TYPE : O
SESSION PROT.NUM.-T. : 5 : 1 SSL CONFIGURATION : -
AUTOMATIC RESTART : YES DN CONTROL MEMBER : -
LINK TYPES : I : -
EFF. TOTAL/IN/OUT : 064 : 064 : 000 FLOW CONTROL T. SLD : -
CSECTNAME= Required. Specifies the Internal and external name of the load module. This name
1 to 8 char. must be declared in the Connection user exit table associated with the protocol.
Example: L1TSTCNA
FTPPBYP= Defines the FTP users that are not processed by the exit. The length of this FTP
0 to 8 char. parameter is processed. This parameter can be used during tests.
Example: 'FTP' means that all partners which name starts with 'FTP' are not
controlled.
FTPPART= Specifies the symbolic FTP partner name that is returned when an FTP user is $FTP$
1 to 8 char. connected. This name must be defined in the partners directory of
Connect:Express. The keyword $RACGRP$ is used if the symbolic name is
required to be the RACF group.
Example: FTPIN, $RACGRP$
FTPPASW= Specifies the symbolic password that must be associated to the symbolic FTP FTP
0 to 8 char. partner.
Example: FTPPASS
FTPEPRC= Specifies the FTP error code that is sent to the user if the connection is rejected. 530
0 to 8 char. Example: 532
PSDPBYP= Defines the PeSIT D users that are not processed by the exit. The length of this PSD
0 to 8 char. parameter is processed. This parameter can be used during tests.
Example: 'PSD' means that all partners whose name starts with 'PSD' are not
controlled.
PSDPART= Specifies the symbolic PeSIT D partner name that is returned when a PeSIT D user $PESITD$
1 to 8 char. is connected. This name must be defined in the partners directory of
Connect:Express. The keyword $RACGRP$ is used if the symbolic name is
required to be the RACF group.
Example: PESDIN, $RACGRP$
PSDPASW= Specifies the symbolic password that must be associated to the symbolic PeSIT D PESITD
0 to 8 char. partner.
Example: PESDPASS
PSDEPRC= Specifies the PeSIT error code that is sent to the user if the connection is rejected. 304
0 to 8 char. Example: 300
PSEPBYP= Defines the PeSIT E users that are not processed by the exit. The length of this PSE
0 to 8 char. parameter is processed. This parameter can be used during tests.
Example: 'PSE'means that all partners which name starts with 'PSE' are not
controlled.
PSEPART= Specifies the symbolic PESIT E partner name that is returned when a PeSIT E user $PESITE$
1 to 8 char. is connected. This name must be defined in the partners directory of
Connect:Express. The keyword $RACGRP$ is used if the symbolic name is
required to be the RACF group.
Example: PESDIN, $RACGRP$
PSEPASW= Specifies the symbolic password that must be associated to the symbolic PeSIT E PESITE
0 to 8 char. partner.
Example: PESEPASS
PSEEPRC= Specifies the PeSIT error code that is sent to the user if the connection is rejected. 304
0 to 8 char. Example: 300
Chapter 2 / User Exits 2-13
The connection exit must be re-entrant and you must set the parameter AC=1 for link-edit. The preceding
example shows that the internal and external name of the load module is L1TSTCNA. This name must be
declared in the user connection exit table (CNT) for FTP partners. In addition, no bypass is used, and the RACF
group is used as the symbolic partner name. All possible RACF groups must be defined in the Partners
directory of Connect:Express as FTP partners. The symbolic password of these partners is PSR. If the
connection is rejected, the default FTP error code 530 is sent in the FTP REPLY.
One or more journal exits can be executed in the TOM address space.
Action Description
Connect:Express initialization The exit routine receives control with register R1 pointing to a word containing the
program → EXIT routine address of the communication area.
EXIT routine → Connect:Express The exit routine returns control to the protocol program with register R15. Register
initialization program R15 contains a code less than or equal to 90.
The following screen shows an example of an exit call at the initialization of Connect:Express.
D1B2PCNX DSECT
*************************************** HEADER
CNXSSNAM DS CL4 SUBSYSTEM NAME
/...
CNXCALTY DS CL3'OPC' CALL TYPE
The screen below shows an example of an exit call at the termination of Connect:Express.
D1B2PCNX DSECT
*************************************** HEADER
CNXSSNAM DS CL4 SUBSYSTEM NAME
/...
CNXCALTY DS CL3'CLC' CALL TYPE
/...
Action Description
Connect:Express initialization The exit routine receives control with register R1 pointing to a word containing the
program → EXIT routine program address of the communication area. No action is expected from the Exit.
Chapter 2 / User Exits 2-15
The following screen shows an example of a journal exit call at the initialization of Connect:Express.
D1B2PJNL DSECT
Z45ENTRYDS0C
*---------------------------------------------------------------------
* FILE FIELD
*---------------------------------------------------------------------
Z45FILEN DS 0CL8 FILE NAME
Z45KEYWR DS XL4 OR LAST WRITTEN JNL KEY
Z45KINTR DS CL4'INIT' INIT-TERM KEY
Z45DSNAM DS CL44 DATA SET NAME
The following screen shows an example of a journal exit call at the termination of Connect:Express.
D1B2PJNL DSECT
Z45ENTRYDS0C
*---------------------------------------------------------------------
* FILE FIELD
*---------------------------------------------------------------------
Z45FILEN DS 0CL8 FILE NAME
Z45KEYWR DS XL4 OR LAST WRITTEN JNL KEY
Z45KINTR DS CL4'TERM' INIT-TERM KEY
Z45DSNAM DS CL44 DATA SET NAME
Action Description
APM initialization program → The exit routine receives control with register R1 pointing to a word containing the
EXIT routine address of the communication area.
EXIT routine → APM initialization The exit routine returns control to the protocol program with register R15. Register
program R15 contains a code less than or equal to 90.
The screen below shows an example of communication at the initialization of the APM.
D1B2RUEX DSECT
*************************************** HEADER
UEXSSNAM DS CL4 SUBSYSTEM NAME
/...
UEXCALTY DS CL3'OPS' CALL TYPE
/...
2-16 Connect:Express z/OS Administration Guide
The following screen shows an example of communication at the termination of the APM.
*************************************** HEADER
D1B2RUEX DSECT
UEXSSNAM DS CL4 SUBSYSTEM NAME
/...
UEXCALTY DS CL3'CLS' CALL TYPE
/...
Connection Interface
One or more server exits can take control before the session is opened and after the session is closed. These
server exits must be reentrant. These functions are entered as parameters in the T1B2PCNT exit table that is
processed by the L1B2PCNX driver. A connection exit can be called during initialization and termination of
Connect:Express. See Connect:Express Initialization Interface on page 2-8.
Each eligible exit is called before the connection attempt if it is an outgoing call, and after the connection is
detected if it is an incoming call. If one of the exits involved in the connection returns a non-zero code, the
process was unsuccessful. All exits are invoked regardless of the return codes from the previous exits in the
list. If the Connection exit process during the open session phase was successful, the connection exit process is
invoked again during the close session phase. The following example shows how the driver works. Server1,
server2, server3, and server4 were defined in the T1B2PCNT table with their associated session profiles.
When the session opens:
1. Server 1 is invoked and returns OK.
2. Server 2 is not invoked because it doesn’t match the session profile.
3. Server 3 is invoked and returns not OK.
4. Server 4 is invoked and returns OK.
5. Final result is not OK because the server 3 return code was not OK.
When the session closes, there are no calls to servers.
The final return code is set to the maximum code returned in general register 15 by the exits.The user return
code must be in the range of 00 to 90. Codes from 90 to 99 are reserved. Codes greater than 99 are invalid.
Some special return codes are provided:
RC=93: use return code 93 to indicate that your exit must be disabled.
RC=99: use return code 99 to indicate that the maximum return code must be set to the value returned in
CNXMAXRC field of the D1B2PCNX structure.
Chapter 2 / User Exits 2-17
The communication area enable two way exchanges. It is described in the D1B2PCNX DSECT, shown below.
This is in the *MACLIB* and addresses environment information, Partner and network identification, return
codes, and parameters set by the protocol.
D1B2PCNX DSECT
*************************************** HEADER
CNXSSNAM DS CL4 SUBSYSTEM NAME
/...
CNXCALTY DS CL3'CNX' CALL TYPE
/...
*----------------------------------- IDENTIFICATION ------
CNXPRC DS CL3 PROTOCOL RETURN CODE
CNXTRC DS CL4 C:X RETURN CODE
/...
CNXMAXRC DS X EXIT MAX RETURN CODE (R15=99)
******************************** APPLICATION ****************
CNXAPIXX EQU *
*--------------------------*
* FTP APPLICATION AREA *
*--------------------------*
CNXAPIFT ORG CNXAPIXX * * * * * * * * * *
*--------------------------*
* ODETTE APPLICATION AREA *
*--------------------------*
CNXAPI02 ORG CNXAPIXX * * * * * * * * * *
*--------------------------*
* PeSIT D APPLICATION AREA *
*--------------------------*
CNXAPI03 ORG CNXAPIXX * * * * * * * * * *
*--------------------------*
* ETEBAC1,2,3 APPLI AREA *
*--------------------------*
CNXAPI04 ORG CNXAPIXX * * * * * * * * * *
*--------------------------*
* PESIT-E APPLICATION AREA *
*--------------------------*
CNXAPI05 ORG CNXAPIXX * * * * * * * * * *
If an error occurs during execution and it is detected by the exit routine, the protocol program stops the
connection and returns the appropriate TRC code. Refer to Appendix B for a complete listing of return codes.
The following screen shows the values of a TRC issued for a user connection exit error.
If an ABEND occurs during the execution of one server exit, or if the exit requests it, the server exit is disabled.
Two connection server exits are provided with Connect:Express. The L1GFICN1 module is a connection
server exit from the Utilities option that tracks abnormal end of sessions. L1USRCNA is a connection server
exit that can be used for security control . L1USRCNA source code is provided in the *SAMPLIB*.
2-18 Connect:Express z/OS Administration Guide
Outgoing Sessions
The exit routine takes control before establishing a connection with a partner.
Action Description
Protocol program → EXIT The exit routine receives control with register R1 pointing to a word containing the
routine address of the communication area. Application fields are initialized with default
values.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15 and
application fields. Register R15 contains a code less than or equal to 90 that
indicates if the protocol program can perform the connection. Application fields
contain the values to be sent to the Partner in the transfer protocol fields.
If an error occurs during execution of the exit routine, the protocol program does not proceed to establish a
session and issues a TRC=46xx code with xx = R15.
Incoming Sessions
The exit routine takes control after the protocol connection command was received and a partner entry was
found in the Connect:Express directory.
Action Description
Protocol program → EXIT The exit routine receives control with register R1 pointing to a word containing the
routine address of the communication area. Application fields are initialized with values
found in the protocol fields.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15. Register
R15 contains a code that indicates what kind of action the protocol program must
perform.
If an error occurs during execution of the exit routine, the protocol program rejects the connection with the
PRC returned by the user or the default PRC and a TRC=46xx code with xx = R15.
Chapter 2 / User Exits 2-19
Journal Interface
Connect:Express can give control to a user exit routine at the end of transfer using the UEXJNL=xxxxxxx
parameter. This exit is implemented by a mechanism which performs two functions.
It protects Connect:Express from malfunctions. If an error occurs, the exit routine is not invoked. A
message is then sent to the operator console and the control panel shows the exit as DISABLED.
It manages the events in a queue.
All journal exits are called during the initialization and termination of Connect:Express. See Connect:Express
Initialization Interface on page 2-8.
The exit takes control during the following circumstances when Connect:Express is initialized:
At each normal end-of-transfer.
At each abnormal end-of-transfer.
After call attempts to a Partner fail.
The linkage conventions are IBM standards. Register R1 contains the address of a word which has the address
of the communication area. This area contains the same information as the record written in the Journal file
(SYSJNL). When several exits are used (A-SIT, B-SIT, user EXIT), it is possible to execute the L1B2PDIX
module. This exit is entered as a parameter in the Connect:Express SYSIN (UEXJNL). This ensures that
programs are loaded during initialization, and it creates the communication area for the monitor at each
end-of-transfer. See the *SAMPLIB* for more information about implementation. Refer to the EXIT£DIX
example and the £SYSEXT module in the *PARMLIB*. Examples of two end-of-transfer conditions are
shown below.
2-20 Connect:Express z/OS Administration Guide
05 ZON-CR-RECEPT.
10 Z45FILE.
15 Z45FILEN PIC X(8). < SIT00001
15 Z45DSNAM PIC X(44). < EXP.SIT00001.FILE
15 Z45FILTY PIC X. < S
15 Z45DIREC PIC X. < R
15 Z45TRPRT PIC X. < 1
15 Z45PPRNB PIC X. < 1
15 Z45FPSIT.
20 Z45PSFTY PIC 9(5). < 00001
20 Z45PSNAM PIC X(5). < ?????
20 Z45CRDAT PIC X(6). < YYMMDD
20 Z45CRTIM PIC X(6). < HHMMSS
20 Z45PSTAM PIC X(64). < ?????
20 Z45EXDAT PIC X(6). < YYMMDD
20 Z45EXTIM PIC X(6). < HHMMSS
20 Z45FILDA PIC X. < E, A, B
20 Z45FILR1 PIC X(5). < SPACES
10 Z45PART.
15 Z45PARTN PIC X(8). < I4X00001
15 Z45PARTY PIC X. < O
15 Z45PARLK PIC X. < N
15 Z45PARTX PIC X. < 0
15 Z45PARVP PIC X. < 1
15 Z45PARST PIC X. < S
15 Z45PARSP PIC X. < 1
15 Z45SECTB PIC X(2) < SSL CONFIGURATION NUM.
15 Z45PPSIT.
20 Z45LOTYP PIC 9. < 2
20 Z45LOAPN PIC 9(5). < 00022
20 Z45PATYP PIC 9. < 4
20 Z45PAAPN PIC 9(5) < 00001
20 Z45FILR2 PIC X(38). < SPACES
10 Z45REQNB PIC 9(8). < REQUEST NB
10 Z45REQID PIC X(8). < I4X00001
10 Z45REQRS COMP PIC 9(4). < RESTART NB
10 Z45REQCL PIC X. < CLASS
10 Z45SPSTN PIC X. < SESS.TABLE NUM.
10 Z45DATEB COMP-3 PIC 9(8). < 0YYMMDDF
10 Z45HOURB COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45DATEE COMP-3 PIC 9(8). < 0YYMMDDF
10 Z45HOURE COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45TIMET COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45BYTTN COMP PIC 9(8). < BYTES COUNT
10 Z45BYTEN COMP PIC 9(8). < BYTES COUNT
10 Z45RECDN COMP PIC 9(8). < RECORDS COUNT
10 Z45SDRVN COMP PIC 9(8). < SEND/RECV COUNT
10 Z45ABNCD PIC X(4). < 0000 OR RET-COD SXXX
10 Z45PRTRC PIC X(4). < 0000 OR SIT-COD PXXX
10 Z45SYSRC PIC X(4). < 0000 OR SYST. CODE X
10 Z45INTYP PIC X. < INTERRUPTION TYPE
10 Z45FTRID PIC XXX. < 0 → 32767
10 Z45APMNB PIC XX. < APM NUMBER
10 Z45EFFNB PIC XX. < EFFECTOR NUMBER
10 Z45RTDSN PIC X(44). < REMOTE DSNAME
10 Z45TAPID PIC X(82). < APPLI IDENTIF.
10 Z45FILR5 PIC x(66). < SPACES
10 Z45CRKEY PIC XL4 < current key
10 Z45FILR6 PIC X(212). < SPACES
Chapter 2 / User Exits 2-21
05 ZON-CR-RECEPT.
10 Z45FILE.
15 Z45FILEN PIC X(8). < SIT00004
15 Z45DSNAM PIC X(44). < EXP.SIT00004.FILE
15 Z45FILTY PIC X. < S
15 Z45DIREC PIC X. < T
15 Z45TRPRT PIC X. < 1
15 Z45PPRNB PIC X. < 1
15 Z45FPSIT.
20 Z45PSFTY PIC 9(5). < 00004
20 Z45PSNAM PIC X(5). < ?????
20 Z45CRDAT PIC X(6). < YYMMDD
20 Z45CRTIM PIC X(6). < HHMMSS
20 Z45PSTAM PIC X(64). < ?????
20 Z45EXDAT PIC X(6). < YYMMDD
20 Z45EXTIM PIC X(6). < HHMMSS
20 Z45FILDA PIC X. < E, A, B
20 Z45FTRID PIC XXX. < ??? TRF ID
20 Z45FILR1 PIC XX. < SPACES
10 Z45PART.
15 Z45PARTN PIC X(8). < O4X00001
15 Z45PARTY PIC X. < O
15 Z45PARLK PIC X. < N
15 Z45PARTX PIC X. < 0
15 Z45PARVP PIC X. < 1
15 Z45PARST PIC X. < S
15 Z45PARSP PIC X. < 1
15 Z45PPSIT.
20 Z45LOTYP PIC 9. < 2
20 Z45LOAPN PIC 9(5). < 00022
20 Z45PATYP PIC 9. < 4
20 Z45PAAPN PIC 9(5) < 00001
20 Z45FILR2 PIC X(38). < SPACES
10 Z45REQU.
10 Z45REQNB PIC 9(8). < REQUEST NB
10 Z45REQID PIC X(8). < JOBNAME
10 Z45REQRS COMP PIC 9(4). < RESTART NB
10 Z45REQCL PIC X. < CLASS
10 Z45FILR3 PIC X. < SPACES
10 Z45DATEB COMP-3 PIC 9(8). < 0YYMMDDF
10 Z45HOURB COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45DATEE COMP-3 PIC 9(8). < 0YYMMDDF
10 Z45HOURE COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45TIMET COMP-3 PIC 9(8). < 0HHMMSSF
10 Z45BYTTN COMP PIC 9(8). < BYTES COUNT
10 Z45BYTEN COMP PIC 9(8). < BYTES COUNT
10 Z45RECDN COMP PIC 9(8). < RECORDS COUNT
10 Z45SDRVN COMP PIC 9(8). < SEND/RECV COUNT
10 Z45ABNCD PIC X(4). < 0000 OR RET-COD SXXX
10 Z45PRTRC PIC X(4). < 0000 OR SIT-COD PXXX
10 Z45IDTRF COMP PIC 9(8). <
10 Z45ZITRF REDEFINES Z45IDTRF.
15 Z45FILR4 PIC X. <
15 Z45FTRID PIC XXX. < 0 → 32767
10 Z45SPSTN PIC X < 0 → 7
10 Z45FILR5 PIC XXX. < SPACES
10 Z45CRKEY PIC XL4 < current key
10 Z45FILR6 PIC X(212). < SPACES
2-22 Connect:Express z/OS Administration Guide
Selection Interface
One or more server exits can take control before the transfer is selected and after the transfer is deselected.
These server exits must be reentrant. These functions are entered as parameters in the T1APMSRT exit table
processed by the L1APMSRV driver. A selection exit can be called during initialization and termination of
Connect:Express. See Connect Express Initialization Interface on page 2-8.
Chapter 2 / User Exits 2-23
Each eligible exit is invoked before sending the transfer request to the Partner if it is an outgoing call, and after
receiving the request if it is an incoming call. If one of the exits involved in the selection returns a non-zero
code, the process was unsuccessful. All exits are invoked regardless of the return codes from the previous exits
in the list. If the selection exit process during the selection phase returns an OK, the selection exit process is
invoked again during the de-selection phase. The following example shows how the driver works. Server1,
server2, server3, and server4 were defined in the T1APMSRT table with the associated transfer profiles.
During selection:
1. Server 1 is invoked and returns OK
2. Server 2 is not invoked because it doesn’t match the session profile
3. Server 3 is invoked and returns OK
4. Server 4 is invoked and returns OK
5. Final result is OK
During de-selection:
1. Server 1 is invoked and returns OK
2. Server 2 is not invoked because it doesn’t match the session profile
3. Server 3 is invoked and returns not OK
4. Server 4 is invoked and returns OK
5. Final result is not OK
The communication area enables two way exchanges and is described in the D1B2RUEX DSECT, shown
below. This is in the *MACLIB* and addresses environment information, return codes, parameters set by the
protocol, and Partner, file and transfer identification.
The final return code is set to the maximum code returned in general register 15 by the exits.The user return
code must be in the range of 00 to 90. Codes from 90 to 99 are reserved. Codes greater than 99 are invalid.
Some special return codes are provided:
RC=93: use return code 93 to indicate that your exit must be disabled.
2-24 Connect:Express z/OS Administration Guide
D1B2RUEX DSECT
*************************************** HEADER
UEXSSNAM DS CL4 SUBSYSTEM NAME
UEXAPMNB DS CL2 APM NUMBER
UEXEFFNB DS CL2 EFF NUMBER
UEXCALTY DS CL3'SEL' CALL TYPE
UEXDATE DS 0C CURRENT TRANSFER DATE
UEXTIME DS 0C CURRENT TRANSFER TIME
*----------------------------------- IDENTIFICATION ------
*------------------ FILE
UEXDDNM DS CL8 DDNAME
UEXPART DS CL8 PARTNER ID
UEXDSNM DS CL44 DSNAME
UEXDRCT DS CL1 TRANSFER DIRECTION
UEXTYPE DS CL1 INITIALIZA. status (A, I)
* TERMINATION status (E, F, S)
*------------------ TRANSFER
UEXTRFID DS XL4 EXTERNAL TRF IDENT
UEXREQNB DS XL4 INTERNAL TRF IDENT
*------------------ RETURN CODES
UEXSRC DS CL4 SYSTEM RETURN CODE
UEXTRC DS CL4 C:X RETURN CODE
UEXPRC DS CL3 PROTOCOL RETURN CODE
UEXIDT DS X TRANSFER END STATUS
UEXTRFOK EQU X'00' TRF OK PESIT
UEXTRSTR EQU X'04' TRF WILL BE RESTARTED PESIT
UEXTSUSP EQU X'08' TRF SUSPENDED PESIT
UEXTWAIT EQU X'0C' STOPPED BY WAITER PESIT
UEXTINIT EQU X'10' STOPPED BY INITIATOR PESIT
UEXTERSL EQU X'14' ERROR DURING SELECTION
********************************* RESULTS *****************
**************************** USER COMMUNICATION *************
UEXPRMAD DS XL4 USER PARM FROM APM JCL ADD(USD=)
UEXUSDAD DS XL4 USER EXIT COMMUNICATION AREA ADD
******************************** ALLOCATION *****************
UEXALRST DS XL1 RESTART FLAG
******************************** APPLICATION ****************
UEXAPIXX EQU *
*--------------------------*
* FTP APPLICATION AREA *
*--------------------------*
UEXAPIFT ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ODETTE APPLICATION AREA *
*--------------------------*
UEXAPI02 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* PeSIT D APPLICATION AREA *
*--------------------------*
UEXAPI03 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ETEBAC1,2,3 APPLI AREA *
*--------------------------*
UEXAPI04 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* PESIT-E APPLICATION AREA *
*--------------------------*
UEXAPI05 ORG UEXAPIXX * * * * * * * * * *
Continued
Chapter 2 / User Exits 2-25
If an error occurs during execution and it is detected by the exit routine, the protocol program stops the
connection and returns the appropriate TRC code. Refer to Appendix B for a listing of all return codes. The
following screen shows the values of TRC issued for user selection exit errors.
If an ABEND occurs during the execution of one server exit, it will be disabled. The L1GFICN1 module is a
selection server exit from the Utilities option that tracks abnormal end of transfers.
Outgoing Selection
The exit routine takes control before establishing selection with a Partner.
Action Description
Protocol program → EXIT The exit routine receives control with register R1 pointing to a word containing the
routine address of the communication area. Application fields are initialized with default
values.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15 and
application fields. Register R15 contains a code less than or equal to 90 that
indicates if the protocol program can perform the selection. Application fields contain
the values to be sent to the Partner in the transfer protocol fields.
If an error occurs during execution of the exit routine, the protocol program does not demand selection and
issues a TRC=46xx code with xx = R15.
2-26 Connect:Express z/OS Administration Guide
Incoming Selection
The exit routine takes control after the protocol selection command has been received.
Action Description
Protocol program → EXIT The exit routine receives control with register R1 pointing to a word containing the
routine address of the communication area. Application fields are initialized with values
found in the protocol fields.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15 which
contains a code that indicates the kind of action the protocol program must perform.
If an error occurs during execution of the exit routine, the protocol program rejects the selection with the PRC
returned by the user, or the default PRC and a TRC=46xx code with xx = R15.
Note: If a GETMAINED area (sub-pool zero) address is passed through these fields, be aware that if an
abend of the protocol task with UEXTYPE=S (SEL and TEX) calls following a protocol task ABEND,
this address is no longer available.
Using the BRX=3 or 4 option in the APM PARM of EXEC, which corresponds to ATTACH of user
exits, makes the GETMAINED area unsharable unless a special SUBPOOL is used.
Chapter 2 / User Exits 2-27
Action Description
Protocol program → EXIT The exit routine takes control with register R1 pointing to a word containing the
routine address of the communication area.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15. Register
R15 contains a code that indicates what kind of action the protocol program must
perform.
The communication area enables two way exchanges, and is described in the D1B2RUEX DSECT, shown
below. It is in the *MACLIB* and addresses environment information, file and transfer identification, return
codes, allocation parameters, and parameters set by the protocol.
D1B2RUEX DSECT
*************************************** HEADER
UEXSSNAM DS CL4 SUBSYSTEM NAME
UEXAPMNB DS CL2 APM NUMBER
UEXEFFNB DS CL2 EFF NUMBER
UEXCALTY DS CL3'IEX' CALL TYPE
UEXDATE DS 0C CURRENT TRANSFER DATE
UEXTIME DS 0C CURRENT TRANSFER TIME
*----------------------------------- IDENTIFICATION ------
*------------------ FILE
UEXDDNM DS CL8 DDNAME
UEXPART DS CL8 PARTNER ID
UEXDSNM DS CL44 DSNAME
UEXDRCT DS CL1 TRANSFER DIRECTION
UEXTYPE DS CL1 INITIALIZA. status (A, I)
* TERMINATION status (E, F, S)
*------------------ TRANSFER
UEXTRFID DS XL4 EXTERNAL TRF IDENT
UEXREQNB DS XL4 INTERNAL TRF IDENT
*------------------ RETURN CODES
UEXSRC DS CL4 SYSTEM RETURN CODE
UEXTRC DS CL4 C:X RETURN CODE
UEXPRC DS CL3 PROTOCOL RETURN CODE
UEXIDT DS X TRANSFER END STATUS
UEXTRFOK EQU X'00' TRF OK PESIT
UEXTRSTR EQU X'04' TRF WILL BE RESTARTED PESIT
UEXTSUSP EQU X'08' TRF SUSPENDED PESIT
UEXTWAIT EQU X'0C' STOPPED BY WAITER PESIT
UEXTINIT EQU X'10' STOPPED BY INITIATOR PESIT
UEXTERSL EQU X'14' ERROR DURING SELECTION
Continued
2-28 Connect:Express z/OS Administration Guide
*
********************************* RESULTS *****************
*
**************************** USER COMMUNICATION *************
UEXPRMAD DS XL4 USER PARM FROM APM JCL ADD(USD=)
UEXUSDAD DS XL4 USER EXIT COMMUNICATION AREA ADD
*
******************************** ALLOCATION *****************
*
UEXALRST DS XL1 RESTART FLAG
*
******************************** APPLICATION ****************
UEXAPIXX EQU *
*-------------------------*
* C:X APPLICATION AREA *
*-------------------------*
UEXAPI03 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ODETTE APPLICATION AREA *
*--------------------------*
UEXAPI02 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ETEBAC1,2,3 APPLI AREA *
*--------------------------*
UEXAPI04 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* PESIT-E APPLICATION AREA *
*--------------------------*
UEXAPI05 ORG UEXAPIXX * * * * * * * * * *
If an error occurs during execution and it is detected by the exit routine, the protocol program stops the transfer
and returns the appropriate TRC code. The following screen shows values of TRC issued for a user
initialization exit error.
Note: When the user performs the file allocation, some protocol parameters, such as record length
UEXALREC, record format (U03/ U05FRFMT), and file space (U03/U05SPTYP,FKBYT) must be
returned through the D1B2RUEX fields.
Action Description
Protocol program → EXIT The exit routine receives control with register R1 pointing to a word containing the
routine address of the communication area.
EXIT routine → Protocol program The exit routine returns control to the protocol program with register R15. R15
contains a code which indicates what kind of action the protocol program must
execute.
The D1B2RUEX DSECT, shown below, is in the *MACLIB*, and addresses the environment information, file
and transfer identification, return codes, allocation parameters, and parameters set by the protocol.
2-30 Connect:Express z/OS Administration Guide
D1B2RUEX DSECT
*************************************** HEADER
UEXSSNAM DS CL4 SUBSYSTEM NAME
UEXAPMNB DS CL2 APM NUMBER
UEXEFFNB DS CL2 EFF NUMBER
UEXCALTY DS CL3'TEX' CALL TYPE
UEXDATE DS 0C CURRENT TRANSFER DATE
UEXTIME DS 0C CURRENT TRANSFER TIME
*----------------------------------- IDENTIFICATION ------
*------------------ FILE
UEXDDNM DS CL8 DDNAME
UEXPART DS CL8 PARTNER ID
UEXDSNM DS CL44 DSNAME
UEXDRCT DS CL1 TRANSFER DIRECTION
UEXTYPE DS CL1 INITIALIZA. status (A, I)
* TERMINATION status (E, F, S)
*------------------ TRANSFER
UEXTRFID DS XL4 EXTERNAL TRF IDENT
UEXREQNB DS XL4 INTERNAL TRF IDENT
*------------------ RETURN CODES
UEXSRC DS CL4 SYSTEM RETURN CODE
UEXTRC DS CL4 C:X RETURN CODE
UEXPRC DS CL3 PROTOCOL RETURN CODE
UEXIDT DS X TRANSFER END STATUS
UEXTRFOK EQU X'00' TRF OK PESIT
UEXTRSTR EQU X'04' TRF WILL BE RESTARTED PESIT
UEXTSUSP EQU X'08' TRF SUSPENDED PESIT
UEXTWAIT EQU X'0C' STOPPED BY WAITER PESIT
UEXTINIT EQU X'10' STOPPED BY INITIATOR PESIT
UEXTERSL EQU X'14' ERROR DURING SELECTION
*
********************************* RESULTS *****************
*
**************************** USER COMMUNICATION *************
UEXPRMAD DS XL4 USER PARM FROM APM JCL ADD(USD=)
UEXUSDAD DS XL4 USER EXIT COMMUNICATION AREA ADD
******************************** ALLOCATION *****************
UEXALRST DS XL1 RESTART FLAG
******************************** APPLICATION ****************
UEXAPIXX EQU *
*--------------------------*
* FTP APPLICATION AREA *
*--------------------------*
UEXAPIFT ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ODETTE APPLICATION AREA *
*--------------------------*
UEXAPI02 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* C:X APPLICATION AREA *
*--------------------------*
UEXAPI03 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* ETEBAC1,2,3 APPLI AREA *
*--------------------------*
UEXAPI04 ORG UEXAPIXX * * * * * * * * * *
*--------------------------*
* PESIT-E APPLICATION AREA *
*--------------------------*
UEXAPI05 ORG UEXAPIXX * * * * * * * * * *
Continued
Chapter 2 / User Exits 2-31
If an error occurs during execution and it is detected by the exit routine, the protocol program stops the transfer
and returns the appropriate TRC code. Refer to Appendix B for a list of TRC codes. The following screen
shows values of TRC issued for a user termination exit error.
protocol program uses IBM standard linkage conventions and provides a communication area which contains
the items of the current transfer. If the name of the exit is L1APMSRV, the server exit is used.
The user exit is called for the first time during the open file phase. The protocol program provides a
communication area. In this area, the PEXSTATS field is set to the value of EXASTART (B), but there is
nothing in the file record. The user exit sets up the environment.
For each record of the file, the user exit routine takes control from the protocol program which provides a
communication area. In this case, the PEXSTATS field is set to the value of EXAMIDDL (M). It contains the
contents of the file record.
After all the records of the file have been processed, the protocol program gives control to the user exit during
the close file phase and provides a communication area. The PEXSTATS field is set to the value EXAENDED
(E), and the user exit routine must then reset the environment.
The following table summarizes the process.
Action Description
Protocol program → EXIT When the exit routine receives control for CALL with PEXSTATS = M, register R1
routine points to a word containing the address of the communication area. The address of
the current record and its length are indicated by the communication area.
EXIT routine → Protocol program At the end of processing, the exit routine returns control to the protocol program. R15
now contains a code which indicates what action must be done by the protocol. The
length of the record can be changed by the exit according to the record format. If the
record length is fixed, the length cannot be changed. If it is variable, it can be less
than the original length.
The screen below shows values for the PEXSTATS field during transfer.
Implementation
The communication area is designed to allow two-way communications. This area is described by D1B2RPEX
DSECT, shown below. It is in the *MACLIB* and gives information about the environment, file and transfer
identification, return codes, data area (length of the record and the current record), the position of data in the
list, and the position in the file. It also includes applicable parameters conveyed by the protocol. Adding the
PEXDOFFS value to the communication area address gives the address of the data area. The first two bytes of
the data area are set to the current record length, and the current record is behind this field. The exit can change
the length of the record and set the data area record length field with the new value. The exit can change the
data in the current record.
Chapter 2 / User Exits 2-33
D1B2RPEX DSECT
*************************************** HEADER (COMPATIBILITY)
PEXENTRY EQU *
PEXSSNAM DS CL4 SUBSYSTEM NAME
PEXAPMNB DS CL2 APM NUMBER
PEXEFFNB DS CL2 EFF NUMBER
PEXZDATE DS 0C DATE
PEXZTIME DS 0C TIME
********************************** IDENTIFICATION ***********
*--------------------- FILE
PEXNDDN DS CL8 DDNAME
PEXNLUID DS CL8 SESSION PARTNER ID
PEXDIREC DS CL1 DIRECTION
PEXSTATS DS CL1 TRANSFER STATE
EXASTART EQU C'B' BEGIN
EXAMIDDL EQU C'M' MIDDLE
EXAENDED EQU C'E' END
PEXDOFFS DS H DATA AREA OFFSET FROM PEXENTRY
*--------------------- TRANSFER ---------------------
PEXTRFID DS XL4 EXTERNAL TRF IDENT
PEXREQNB DS XL4 INTERNAL TRF IDENT
PEXDSNAM DS XL44 DATA SET NAME
*--------------------- RETURN CODES ---------------------
PEXSRC DS CL4 SYSTEM RETURN CODE
PEXTRC DS CL4 C:X RETURN CODE
PEXPRC DS CL3 PROTOCOL RETURN CODE
PEXIDT DS CL1 IDT CODE
*
**************************** USER COMMUNICATION *************
PEXPRMAD DS XL4 USER PARM FROM APM JCL ADD(USD=)
PEXUSDAD DS XL4 USER EXIT COMMUNICATION AREA ADD
*
*********************************** APPLICATION *************
PEXAPIXX EQU *
*-----------------------------*
* FTP APPLICATION AREA *
*-----------------------------*
PEXAPIFT ORG PEXAPIXX * * * * * * * *
*
*********************************** POINT FACILITY **********
PEXPOINT DS 0CL140 PARMLIST USER
PEXHLNGT EQU *-PEXSSNAM PARMLIST HEADER LENGTH
PEXLDATA DS XL2 DATA LENGTH (BINARY)
PEXRDATA DS 0C FIRST BYTE OF RECORD
2-34 Connect:Express z/OS Administration Guide
- on reception:
- on transmission:
R15 = 2002(1st call) → the end of file is indicated by R15 = 2004 (if the normal
end of file occurs before the logical end of file this is
considered and error.)
R15 = 2000 → current record not to be transmitted
R15 = 2004 → end of file
R15 = 2008 (VSAM) → point the record with key provided
in the communication area
- on transmission/reception:
The file record format determines the options for changing record length. If the file record format is fixed, the
record length cannot be modified. If the file record format is variable, the current length of the record can be
changed, however it cannot exceed the maximum value given in the PEXLRECL field.
If the exit routine indicates an error, or if an error occurs when the protocol program executes a specified
action, the protocol program stops the transfer and returns the appropriate TRC code. Refer to Appendix B for
a complete list of TRC codes. The screen below shows values of TRC issued for user record processing errors.
Read/write operations like QSAM, BPAM, VSAM, and HFS are executed by Connect:Express standard
routines, however users can create their own routines. A user read/write exit model is shown below.
*---------------------------------------------------------------------
* R0 FUNCTION ADDRESSES TYPE/LENG. DIREC VALUE
*---------------------------------------------------------------------
* (0 OPEN input A(DDNAME) E/8 P →E allocation ddname
* (or
* (4 OPEN output A(DDNAME) E/8 P →E allocation ddname
* A(USDAD) B/4 P →E user workarea
* A(RECFM) B/1 P← E record format
* A(LRECL) B/4 P← E record length
* A(BLKSE) B/4 P← E block size
* A(DSORG) E/1 P →E org. S,V,P,M
* A(T1B2Pxx) ./. P →E present. table
*
*----------------------------------------------------------------------
* 8 NOTE A(NOTE-AREA) X/136 P← E see UEXPNTPL field in D1B2RUEX
*
*----------------------------------------------------------------------
* 12 POINT A(POINT-AREA) X/136 P →E see UEXPNTPL field in D1B2RUEX
*
*-----------------------------------------------------------------------
* 16 READ A(BUFFER) E/4 P →E reception buffer
* A(BUFLEN) E/4 P← E cur. phys. buffer length
* A(RECORD) E/4 P← E record count (optional)
*
*---------------------------------------------------------------------
* 20 WRITE A(BUFFER) E/4 P →E buffer sent
* A(BUFLEN) E/4 P →E phys. buffer length
*
*---------------------------------------------------------------------
* 24 CLOSE A(RECORD) B/4 P← E record count (optional)
*
*---------------------------------------------------------------------
* 28 WRITE A(RECORD) B/4 P← E record count (optional)
* FORCE A(BUFLEN) B/4 P← E phys. buffer length
*
*---------------------------------------------------------------------
2-36 Connect:Express z/OS Administration Guide
TYPE/LENGTH Description
Direction Description
You must declare the user read/write exit routine in the protocol presentation table as PRIVATE I/O EXIT. The
protocol program sends the function code through R0 and provides field addresses. A communication area is
given to the user exit by using standard linkage conventions. The user exit must indicate the value of the return
code in register R15 when returning control to the protocol. For a normal completion, the value of the return
code must be zero. For Connect:Express to know that the end of file was detected, you must enter the return
code X'80000004' in the user exit. Otherwise, the return code is interpreted as an error code.
RC=X'800000rr' is a user return code: TRC=45rr.
RC=X'00wxyzrr' is a system return code: TRC=3zfn
where 'fn' is the I/O function failed, 'z' indicates if transfer is restarted or not, and wxyzrr is issued in the
APM SYSLOG file. A system return code (SRC) is indicated in the APM log.
Note: The user private I/O exit is responsible for all I/O services in place of Connect:Express. It is expected
to return at OPEN time the E → P values:
Record format RECFM ('00' = fixed, '04' = variable, '08' = undefined for sequential files).
Record length LRECL
Blocksize BLKSIZE
Note: The function WRITE FORCE is requested by the protocol program in relation to z/OS sequential files
data management. That function is evoked at every protocol synchronization point, and is intended to
ensure that all data acknowledged is physically written onto disk. It is required for a possible restart
procedure.
Controls are done and TRC=3092, 3093, 3094 are issued if one of these values is not returned. You have to
implement these controls for each function that the process executes. This must be done even if the exit routine
does not perform all the functions.
The user exit module must have the attributes RENT, REUS. You can implement a combination of allocation
exits and private I/O exits using the UEXUSDAD/PEXUSDAD user communication area addresses.
Chapter 2 / User Exits 2-37
System Errors
Return codes (R15) are processed according to their types. If the user exit detects a system error, R15 must
contain a value of x'ssrrrrrr', where x'ss' is less than X'80', and where x'rrrrrr' is the system return code.
The Connect:Express log indicates a message with a TRC code of 3iaa where the following values apply:
i = 0 if normal transfer
i = 1 if transfer restarted
aa = the function code
The APM LOG shows a message with an SRC containing the value of register R15.
User Errors
To indicate a user error, the value in register R15 must be in the form of x'ss0000rr,' where x'ss' is equal to or
greater than X'80' and where X'rr' is the user error. The Connect:Express log will show a message with a TRC
code of 45rr where the following values apply:
rr = 01 to 90 (user code)
rr = 91 invalid user exit return code
rr = 92 error on LRECL (OPEN)
rr = 93 error on BLKSIZE (OPEN)
rr = 94 error on RECFM (OPEN)
The APM LOG shows a message with an SRC code containing the value of register R15.
2-38 Connect:Express z/OS Administration Guide
Chapter 3
Controlling
Transfer Operations
This chapter describes how Connect:Express processes transfer requests and how you can control transfer
operations using automation tools, scheduling features, resources, and security options.
Request Controls
When Connect:Express receives a request, several controls are performed before the request is accepted. The
table below describes these controls.
Control Description
File allocation Checks the file allocation parameters. The following controls apply when receiving a file:
control If the Allocation Rule = 0 and the file exists, it is replaced, if it doesn’t exist, it is created.
If the Allocation Rule = 1, the file must already exist.
If the Allocation Rule = 2, the file cannot exist.
These controls also verify that the file must already exist when sending a file. When unloading a
file before sending or reloading after receiving, it must be possible to allocate the work file (PDS,
VSAM, USER, or SYSOUT).
Request Types
The transfer request type defines how the transfer is performed and when the transfer occurs. For example, a
transfer can be executed immediately or scheduled for a later time. The table below describes the different
request types.
N – Normal This request is executed as soon as possible with no restriction of Partner and/or direction.
H – Hold This request type is executed by Connect:Express when an incoming inquiry request is received.
This facility depends on the transfer protocol used.
I – Inquiry This request enables you to inquire if a Partner has a file to be sent. If yes, the file will be
received. In this case, Partners submit a request with a HOLD status. This facility depends on the
transfer protocol used.
U – Unchain This normal request prevents the transfer from being chained in an existing session.
Serialized This is used with the P1B2PRQ2 utility. This request type is used with a list of requests and
indicates that each request is scheduled one after the other.
The request mode parameter is also used to determine if the request must be scheduled immediately, Mode=I,
or deferred, Mode=D. The deferred mode is not valid with a request type of Hold.
Chapter 3 / Controlling Transfer Operations 3-3
Protocol Restrictions
PeSIT D or PeSIT E A reception request sent by other compatible software must be preceded by a transmission
request to Connect:Express with a HOLD status. A reception request sent to another compatible
software must be of type I (Inquiry).
ETEBAC3 Only Normal and Unchained requests are available. You must define the file to be received on the
allocation screen.
ODETTE Only Normal and Hold transmission requests are available. Using the connection request feature,
you can open a connection with a Partner without sending a file and that Partner can send a file to
you.
FTP Normal, Hold, and Unchained requests are available. To receive a file, you must define it on the
allocation screen. See the FTP Guide for more information about FTP transfers.
Request Scheduling
When Connect:Express receives a transfer request, it is entered in the Request Control Table (RCT) and
assigned a unique 8-character request number. This number is returned to the requestor. Connect:Express
creates a backup of the internal tables modified during this operation in the checkpoint file (SYSCHK). The
monitor can then be hot-started without incurring any loss of the data being processed.
The execution and scheduling of a request depends on the following controls:
Control Description
V Outgoing Requests
• NORMAL TRANSMISSION request.
Incoming Requests
• RECEPTION request.
USER file UU Several data sets of various types can be mixed in one transfer.
Outgoing Requests
• NORMAL TRANSMISSION request – unloading step (by ADRDSSU
single/generic) on dynamically allocated files and transfer of the
temporary files.
Incoming Requests
• RECEPTION request – transfer with a dynamically allocated file and
reloading onto any files (by ADRDSSU single/generic).
Parameters Details
Request Parameters The following request parameters can affect the status of a transfer request:
• The Partner can be disabled or enabled.
• The file can be disabled or enabled.
• The direction of transfer
• The type of Link among Connect:Express resources
• The class of transfer among Connect:Express resources
• The priority
Request Type The request type can affect the status of a transfer, especially if the request is a deferred or held
request. Request types are listed below.
NORMAL request – available for selection if immediate
INQUIRY request – available for selection if immediate
IMMEDIAT request – available for selection
DEFERRED request – waiting to be enabled
HOLD request – waiting for external request
SERIALIZED request – available for selection if first in the list
EXTERNAL request – being processed
Connect:Express All applicable resources for a request must be enabled. Verify that the following resources are
Resource Status enabled.
• Connect:Express must be active.
• Global resources such as the Partner Control Table must be enabled.
• Single resources such as one Partner must be enabled.
• Network resources must be active.
• The priority and class of a transfer request can also affect the status. For example, there must
be a resource available that serves that class.
Partner Activity The Partner must be enabled and have enough available outgoing links. The session table can
indicate that only transfers in the same direction are chained in the same session.
Resources
Transfer operations require a number of Connect:Express and system resources. System resources are accessed
by Connect:Express. Typically, you can enable or disable a resource and display its status and activity through
the TSO/ISPF or batch interfaces. As Connect:Express activity increases, so does the need for system
resources. For example, you should improve disk storage access before increasing the number of possible
simultaneous transfers.
This section identifies and describes Connect:Express resources, network resources, and system resources, and
includes information about controlling the flow of transfers.
3-6 Connect:Express z/OS Administration Guide
Connect:Express Resources
There are four classes of Connect:Express resources that you manage during transfer operations. The following
table describes these four classes.
Resource Description
GLOBAL Includes resources like the Partners Control Table (PCT), and the Files Control Table (FCT).
Global resources are used by all transfers.
SPECIALIZED Shared by a group of Partners, files, or requests. For example, Connect:Express selects an APM
serving a certain class.
INDIVIDUAL Attached to one Partner, file, or request. For example, one Partner can be enabled or disabled.
All Connect:Express global resources must be active to initiate transfers, and all specialized resources involved
in the transfer must be active. Connect:Express will not initiate transfers for disabled partners or files.
Connect:Express resources are defined in the directories, the configuration tables, and the SYSIN file, and
enable you to control Connect:Express activity by organizing Connect:Express resources.
Note: Directories and configuration tables are described in the User Guide. The SYSIN file is described in
Appendix D.
Internal Resources
Connect:Express has defined internal resources such as the maximum number of requests to store in the
Request Control Table (RCT). These resources are defined by parameters in the Connect:Express SYSIN file
and determine the internal working area of the monitor. Modifications to any of the following parameters must
be followed by a cold-start.
Parameter Description
You can use a hot-start when you modify any of the SYSIN parameters listed below.
Parameter Description
PCTADD Maximum number of Partner entries added dynamically in the Partner directory.
FCTADD Maximum number of file entries added dynamically in the file directory.
STDMSG Standard network message size. The Maximum is 64 kilobytes, and the default is 4 kilobytes.
Global Resources
The following table lists the global resources, the commands used to implement them, and a short description.
PCT – Partners Enable/disable all When the Partners table is disabled, any new incoming call is rejected
Control Table partners with a negative network response (NRC), and no new outgoing transfer
is initiated. Local requests are queued in the request control table.
FCT – Files Enable/disable all files When the files table is disabled, any new incoming call is rejected with a
Control Table negative network response (NRC), and no new outgoing transfer is
initiated. Local requests are queued in the request control table.
RCT – Request Enable/disable the When the requests table is disabled, any new incoming request is
Control Table requests rejected with a negative protocol response (PRC), and no new outgoing
transfer is initiated. No other local requests are queued in the request
control table.
Specialized Resources
The table below lists special resources, the commands used to implement them, and a short description.
Transfer resources Activate/deactivate one Connect:Express can manage 1 to 8 APMs, and each APM can manage
APM 1 to 16 transfer servers (effectors). The APM is activated during
Connect:Express initialization. If no APMs are available, any new
incoming request is rejected with a negative protocol response (PRC),
and no new transfer is initiated. Local requests are queued in the
request control table.
See “APM SYSIN Parameters” on page D-10.
Network resource Activate/deactivate any All network resources are managed by the ANM. During initialization,
ANM handler or X.25 Connect:Express starts the ANM with needed and authorized link
MCH (TCP/IP can only be handlers, and the X.25 MCHs. Each ANM handler and X.25 handler can
activated). be activated during Connect:Express initialization. If the needed
resource is inactive, no incoming call can be detected on this link, and
no new outgoing transfer is initiated on this link. If the Partner is given a
list of possible links, the first available link is selected. If no link from the
list is available, the local request is queued in the request control table.
See “SYSIN Parameters for the ANM” on page D-5.
FTP resource Activate/deactivate AFM Connect:Express can activate or deactivate the FTP manager (the
Auxiliary FTP Manager). The resource parameters of the AFM are
defined in the AFM parameter file.
See “AFM SYSIN Parameters” on page D-11.
SSL resource Activate/deactivate SSL Connect:Express can activate or deactivate the SLL handler. See “SSL
Parameters” on page D-7.
3-8 Connect:Express z/OS Administration Guide
Class Of Transfer Change the class of Each of the APMs must be dedicated to at least one class of transfer (up
transfer list associated to seven). The class of transfer for incoming requests is determined by
with an APM the Partner directory field class of transfer. The class of transfer for an
outgoing request is an optional parameter. If this parameter is not given,
Connect:Express defines the class for you. If the class of transfer for an
outgoing request was not defined in any of the APMs, it is queued but
not scheduled. If the class of transfer for an incoming request was not
defined in any of the APMs, it is rejected with PRC.
See “APM SYSIN Parameters” on page D-10.
RACF N/A The RACF security interface can be activated during Connect:Express
initialization, and can have different configurations. Note that changing
an RACF parameter requires a hot-start. An RACF SECURITY user exit
is also available.
SYSIN parameters: ADHOCN, RACFUD, RACFCN
Global LINK number N/A The maximum number of input, output, and total active sessions can be
fixed and defined in the T1B2PSLD table. Several Partner definitions
can share one T1B2PSLD table entry. When the maximum is reached,
the outgoing requests for any one of the Partners are queued, and
incoming requests are rejected with a PRC return code.
Individual Resources
The following table lists the individual resources, the commands used to implement them, and a short
description.
Partner Enable/disable one If the partner is disabled, all local requests for this partner are queued
partner in the request control table, and incoming requests for this Partner are
rejected with a PRC.
File Enable/disable one file If the file is disabled, all local requests for this file are queued in the
request control table, and incoming requests for this file are rejected
with a PRC.
Request Enable/disable one If an error occurs, the request can be automatically disabled and will
request not be scheduled until you enable it.
PARTNER LINK Define session limits for The maximum number of input, output, and total active sessions is
number one partner fixed, and defined in the partner directory for each partner. When the
maximum is reached, the outgoing requests for this partner are queued
and incoming requests are rejected with PRC.
PARTNER X25 Declare charge rule This is processed like a resource (incoming requests only). If the rules
charge rule applicable for X.25 of the partners do not match, incoming requests are rejected with a
connections with a PRC.
Partner
Chapter 3 / Controlling Transfer Operations 3-9
Network Resources
Network resources are required to perform file transfers. Some network resources are needed for internal
Connect:Express features such as the TOM LOCAL option. Most network resources of Connect:Express
interface with the ANM, except GLOBAL-LOCAL Connect:Express connections and FTP connections
managed by the AFM.
The Connect:Express SYSIN file contains all the parameters needed to define the ANM environment. These
parameters are sent to the ANM in the SYSANM file created by Connect:Express during initialization. The
different link handlers are started based on the ANM EXEC parameters set by Connect:Express.
Connect:Express selects the handlers to be started depending on the link types set in the partners directory and
on the network options provided by the Connect:Express Asset Protection File.
The Auxiliary Network Manager (ANM) resources include link type handlers and X.25 link accesses. Each
X.25 link access, or MCH, must be defined by a set of parameters. Link type handlers can be any of the
following:
SNA application-to-application handler
3270 handler
X.25 GATE/DATE/PCNE handlers
LU6.2 handler
TCP/IP handler
SSL handler
System Resources
Transfer operations require system resources for file management, system security, storage management, and
performance management. Using and optimizing these resources is discussed in this chapter and chapter 6.
References about z/OS resources are listed in the following table.
Resource Reference
Required Parameters
The following parameters are required. These are set during installation of Connect:Express but can be
changed later.
Field Description
ADHOCN If ADHOCN is set to Y, AD HOC requests are allowed with mandatory RACF security.
If ADHOCN is set to N, AD HOC requests are not permitted.
If ADHOCN is set to U, AD HOC requests are allowed with optional RACF security.
ANMPRC The name of the start procedure for the Auxiliary Network Manager (ANM).
APLNUM Indicates the number of applications that can be connected to the monitor.
APMPRC The name of the start procedure for the Auxiliary Protocol Manager (APM).
DAPM01 Defines the transfer resources. DAPMxx=(E/nn/xyz) DAPMxx, xx can be 01 to 08. The first field E can
01 to 08 be one of the following values:
E – APM must be started during initialization
H – APM cannot be started during initialization, but can be submitted later by command.
O – APM is disabled and cannot be submitted.
The second field, nn, is the number of protocol servers in this APM. Valid values are 01 to 16.
The third field, xyz, defines transfer classes. Valid values are ABCDEFG.
FCTADD This value represents the maximum number of new entries in the File directory sent to Connect:Express
in real-time. If FCTADD=0, updates are prohibited.
MAXSRQ The maximum number of IEFSSREQ issued simultaneously by TSO users or batch JOBs using the API,
(L0B2Z20). If changed, this field requires a cold-start, RUN=C.
PCTADD This value represents the maximum number of new entries in the Partner directory sent to
Connect:Express in real-time. If PCTADD=0, updates are prohibited.
RACFCN If RACFCN is set to Y, Connect:Express controls local or remote user RACF authorization to transmit
requests.
If RACFCN is set to N, Connect:Express does not check the RACF origin of the request.
If RACFCN is set to S, Connect:Express checks user authorization for RACROUTE-SAF for
compatibility with products such as ACF2 and TOP-SECRET.
RMFLOG If RMFLOG is set to Y, Connect:Express sends RMF records. This can be used to measure
Connect:Express system utilization.
If RMFLOG is set to N, Connect:Express does not produce RMF records.
RQEMAX Represents the maximum number of requests in the request control table. This value includes the
possible number of requests pending, those in progress, and those which have been interrupted.
The requests which have been successfully executed are deleted from the RCT. The maximum
recommended number of authorized requests is 1024.
If changed, this field requires a cold-start, RUN=C.
SMFREC This is the user SMF record number assigned to Connect:Express. Enter 000 if you do not want these
records.
Chapter 3 / Controlling Transfer Operations 3-11
X.25 Parameters
X.25 parameters are mandatory if MCHNBR is greater than zero. Each MCHNAM has subparameters which
must be defined. The table below identifies these subparameters.
Field Description
MCHNAM The line macro name defining the MCH in the NCP.
MCHNBR The number of multi-channel lines dedicated to the ANM. The maximum is 32.
MCHWDS Indicates the size of the X.25 packet window size for this subscription.
MCHVCN Sets the number of generated switched circuits for this MCH.
MCHPKS Sets the size of the X.25 packets for this subscription.
MCHRTR Indicates the occurrences and time of the MCH reactivation (in 30 second increments) which is
done automatically if the MCH is lost.
MCHMSC Provides the method of grouping MCHs by identities, or separating the MCHs.
TCP/IP Parameters
The following TCP/IP parameters are mandatory if TCP/IP is used.
Field Description
TCPPRT Defines the TCP/IP port number on which the ANM listens for calls.
Optional Parameters
The following parameters are optional.
Field Description
DAPM02 The APM is not started during Connect:Express initialization, but can be started later by
Connect:Express using an operator command.
DAPM03 to DAPM08 These are keys to use additional APMs and must be licensed.
STDMSG The standard network message size. The maximum is 64, and the default is 4 Kbytes.
AFMPRC Name of the start procedures for the Auxiliary FTP Manager.
Field Description
RACFUD=username The RACF-USER by default. If no RACF USER was set in the Partner directory, the RACFUD
value is used for security verification. If the ADHOCN parameter is set to unsafe, the RACFUD
value is used for security verification for incoming AD HOC transfer requests.
Partner activity You can limit one Partner’s number of input/output sessions, or limit a group of Partners’ number
of input/output sessions. These are defined globally in the Session Link Definition (SLD) table.
You can also direct incoming demands from a partner using the class of transfer, or direct
outgoing calls to the Partner using MCHMSC (X.25) and LOGMODE (SNA) parameters.
File activity You can control file activity by setting the direction for the file transfer, and limiting the Partners
who can receive or transmit the file.
Transfer activity You can defer the time of transfer until it is enabled, or schedule the transfer for a specific date
and time such as, Monday at 13:10 hours. You can also direct outgoing calls to the Partner by
using the class of transfer.
Automation Tools
Automation facilities enable you to integrate file transfer operations into your business processes. Using these
features with a network manager system like NETVIEW can provide the most efficient use of network
resources. This section includes the following topics:
Checking the status of requests and automating transfer requests using modify commands, batch utilities,
programs, user procedures, and user exits
Controlling connections with the L1GFICN1 utility
Checking the status of requests
Restarting transfers automatically
There is also an optional Utilities package with tools to help you implement automation. See the Utilities Guide
for more information.
Chapter 3 / Controlling Transfer Operations 3-13
Facility Description
Modify commands You can send Modify commands to the monitor to activate or deactivate monitor and network
resources. See Appendix C for a list of monitor commands.
Batch utilities and You can call batch utilities within the JCL to request a transfer. The API can also be called from a
API user program to request a file transfer and to monitor transfer operations. Monitoring includes
enabling/disabling monitor resources and displaying the transfer operation and resource status.
See Chapter 4, Monitor Management and Chapter 3, Transfer Requests in the User Guide for
more information.
User procedures User procedures started by Connect:Express enable you to link transfer operations with other
operations or procedures within your business. The monitor can start user procedures at the
different times shown below:
• Connect:Express initialization (SYSIN UPRCPI= field)
• Connect:Express termination (SYSIN UPRABE= and UPREND= fields)
• Initialization of transfer (FILE directory)
• Termination of transfer (FILE directory) depending on UPRFCT= option
User procedures can also be connected to Connect:Express. These procedures enable you to
receive notifications in journal records with all the relevant information about a transfer so you can
quickly glance at the journal records and determine the status or actions that need to be taken.
See Chapter 4, Monitor Management in the User Guide for more information about the journal file.
User exits User exits are programs written by the user that are loaded and activated by Connect:Express.
When Connect:Express is running, control can be handed over to the user program and then
returned to Connect:Express. This enables you to look at the operations and make decisions
about file transfer operations, or halt transfer operations, analyze files, and take corrective action
if necessary. See Chapter 2 of this book for more information about user exits.
When an outgoing call is rejected by the remote Partner, information is stored in the journal file unless the retry
connection procedure is active. The outgoing network parameters (D1B2PCNX data structure in the
*MACLIB*) are sent to the connection exit. The following screen displays the WTO message with the
outgoing call error sent by the L1GFICN1 utility.
The connection exit receives the D1B2PCNX data structure at the end of the session. The screen below shows
the WTO message with a session interruption error sent by the L1GFICN1 utility.
Note: A session can be interrupted after a successful file transfer, and a file transfer can be interrupted
without a session error. A transfer failure can only be detected at the end of the transfer.
When an outgoing call is rejected by the remote Partner, information is stored in the journal file unless the retry
selection procedure is active. The outgoing transfer request parameters (D1B2RUEX data structure in the
*MACLIB*) are sent to the selection exit. The following screen displays the WTO message with the outgoing
transfer request error sent by the L1GFICN1 utility.
The selection exit receives the D1B2RUEX data structure at the end of the transfer. The screen below shows
the WTO message with a transfer interruption error sent by the L1GFICN1 utility.
Restarting Transfers
The current activity of Connect:Express is automatically saved so you can restart Connect:Express if any
failure occurs. Connect:Express does this with a monitor checkpoint file that can be mirrored. The current
status of all the transfer requests, partners, files, and transfer resources (APM) are recorded in this file.
Connect:Express also allocates a Recovery file which registers all transfer requests and their status when the
monitor is not up. Each transfer allocates a request checkpoint file that has a data set name built by the APM.
One index is the unique transfer request number. The current status and counts of the transfer are recorded in
this file. This request checkpoint file is purged when the corresponding request is purged.
A failure can be a monitor stop, a transfer interruption, or a connection error. If the monitor stops, all current
transfers are interrupted, and the monitor checkpoint file and recovery file are used. If the transfer stops, a
transfer request checkpoint is used. If a connection or transfer negotiation fails, no request checkpoint is used.
A transfer can be interrupted by an operator, a system error (SRC=), a network error (NRC=), a protocol error
(PRC=), a monitor decision (TRC=), or the termination of the monitor. This information is found in the
following locations:
The Journal record
The end of transfer user exit parmlist
The Request Control Table
Connect:Express JCL SYSCHK The monitor checkpoint file contains the current SYSMSG
SYSCHK2 status of the control tables RCT, FCT, PCT,
APM.
Connect:Express JCL SYSRCY The recovery files contain all the transfer SYSMSG
requests that have been recorded when
Connect:Express was not up.
APM JCL CHKMODEL This file is a model for the transfer request
checkpoint allocation. The APM gets the volume
number where the allocation must be done, so
you can direct the files to the appropriate disk.
Keywords are provided to you to group the files:
&APMCKI1, &SSN, &APM.
Installation procedure &APMCKI1 First index for all transfer request checkpoint
files.
APM JCL &APM APM number that identifies all checkpoint files
for one APM. This index only applies to the
model file. It is neutralized by the constant value
‘CHKP’ so the transfer can be restarted in any
APM.
Network failure The current link is not available and a session is ‘NOT OBTAINED.’
Protocol reject The Partner rejects the connection and the session is ‘POSTPONED’ OR the Partner rejects the
transfer and the request is ‘POSTPONED.’
You can define several link types for one partner, for example SNA + X25. On each link you can enter a list of
alternate addresses. Connect:Express processes connection network failures in the following manner:
1. x retries every n minutes on the first link, first address
2. x retries every n minutes on the first link, second address
3. ….
4. Change link
5. x retries every n minutes on the second link, first address
6. x retries every n minutes on the second link, second address
7. ….
You can allow this process to continue until all links and addresses have been tried, and then stop or restart it
again indefinitely. If the process is stopped, the Partner and the transfer request are disabled, and you must
enable the Partner and the request before it can be retried.
You can limit the automatic retry to a list of Protocol Return Codes (PRC) in the T1B2PCOD table. The link
types for the Partner are defined in the Partners directory, and the list of alternate addresses are defined in the
SYSX25, SYSSNA, and SYSTCP files. You can also limit the scanning of alternate links and addresses to one
turn by setting Restart=No in the Partners directory.
Retry Parameters
The table below identifies the file location of retry parameters including specific fields and logs used.
SYSIN STIMEV Timer values, first for connection, second for selection
T1B2PCOD Protocol, PRC List of return codes for this protocol Journal Z45PRC
D1B2RUEX UEXPRC
DIRECTORY LINK One link or mixed link with a list Journal Z45PARLK
D1B2RUEX UEXLNKTP
Using T1B2PCOD
Automatic retry is activated when a network connection fails, a session negotiation with the partner fails, or a
file transfer negotiation fails. For network connection failures, the retry process is always activated. For
transfer negotiations, the retry process depends on the protocol return code. Session negotiations with a Partner
and file transfer negotiations can also be rejected. If it is rejected, the Partner issues a protocol return code
(PRC). The T1B2PCOD table is used to control automatic session retry or transfer selection retry according to
the transfer protocol return codes. The following table describes what happens during a session failure and a
transfer selection failure.
Session In case an outgoing call is rejected by a Partner, the PRC received is compared to the PRC
stored in this table and if a match is found, Connect:Express must activate the connection retry
procedure using the SYSIN file parameters STIMOC=y, STIMEV=(n,.).
Transfer Selection If an outgoing transfer selection error occurs, the PRC received is compared to the PRC stored in
this table and if a match is found, Connect:Express must activate the transfer selection retry
procedure using the SYSIN file parameters STIMOC=y,STIMEV=(.,m).
If a PRC code is not found in the table, the following message displays in the Connect:Express log file.
Files
Connect:Express can process PDS files, VSAM files, SYSOUT files, HFS files, and sequential files from disk
or tape media . It can also process user structure files using the ADRDSSU utility, for example. Depending on
your file organization, you should consider the remote platform and software, transfer protocol, and transfer
direction. For example, you cannot transfer PDS files with the ODETTE protocol.
3-18 Connect:Express z/OS Administration Guide
Since transfers take place between different systems, protocols carry only basic file attributes such as record
size and record format. When communicating within homogeneous environments, specific attributes can be
exchanged, like the physical data set name and physical structure. With Connect:Express, Partners can
exchange such attributes through private protocol fields.
TOM, the APM, and the EAS address spaces manage allocation operations. The APM and EAS manage file
input and output commands like file open/close and read/write. You can also use user exits to control file
allocation. For example, you can use a user exit at the beginning of the transfer or a user exit that is called
during the transfer process to control file allocation. The file allocation process involves:
Naming the files
Preparing files for transfer
Allocating files
This section describes the file allocation process and also includes information about Connect:Express
workfiles and checkpoint files.
Note: When the file type includes an unload/reload processing, “name of the file” applies to the file sent or
received, not to the workfiles used for transferring the data.
USER/unload UU (UNLOAD) All All Use depends on the process, RELOAD on the receive
side and UNLOAD on the send side. Use is only
outgoing transmission/incoming reception.
The following table describes how files are transferred based on file type.
Sequential disk files Sequential files can be processed in two modes, block mode and record mode.
In block mode, all the records in the whole block are processed as one unit, then sent. Block
mode performance is better, and is only used in Connect:Express to Connect:Express
environments. Block Mode is set by an option in the presentation table.
In record mode, each record in the block is processed separately into a network message, then
sent. Record mode is supported by any partner and any protocol and is the default transfer
method.
Tape files Generally, tape files can only be exchanged between Connect:Express z/OS partners. The
exception is when the record format is undefined. In this case, the file transfer takes place in
“Record Mode” so any Partner and protocol are supported.
PDS files There are two transfer methods, Unload/Reload and Direct:
With Unload/Reload, the file is transmitted as a VBS file after automatic UNLOAD, and
automatically RELOADED after reception. To use the UNLOAD/RELOAD procedure, the
following conditions must be met.
• The file must be defined with TYPE=PU.
• The $JOBREL1 and $JOBUNL1 JCL files in the SYSJCL library must be customized.
• If you want to select members from the PDS file during unload operations, you must create a
selection member in the SYSPRM library, then enter its name in the UNLOAD/RELOAD
member field in the symbolic file definition.
Using this information, Connect:Express will automatically build the UNLOAD job, submit it, and
wait for the result. Only outgoing transmission and incoming reception are available.
With Direct transfers, the file and structure are sent. Transmission and reception can be
incoming and outgoing only with Connect:Express z/OS Partners.
3-20 Connect:Express z/OS Administration Guide
VSAM files There are two transfer methods, Unload/Reload and Direct:
With Unload/Reload, the file is transmitted as a VBS file after automatic UNLOAD, and
automatically RELOADED after reception. To use the UNLOAD/RELOAD procedure, the
following conditions must be met.
• The file must be defined with TYPE=VU.
• The $JOBREL2 and $JOBUNL2 JCL files in the SYSJCL library must be customized.
• To receive the file, you must create a DELETE/DEFINE member in the SYSPRM library, then
enter its name in the UNLOAD/RELOAD member field in the symbolic file definition.
Using this information, Connect:Express will automatically build the RELOAD job, submit it, and
wait for the result. Only outgoing transmission and incoming reception are available.
With Direct transfers, the file and structure are sent. Only outgoing transmission and incoming
reception with Connect:Express z/OS partners is available and the file must be pre-allocated on
the receiver side.
SYSOUT files There are two transfer methods, Unload/Reload and Direct:
With Unload/Reload, the file is transmitted as a VBS file after automatic UNLOAD, and
automatically RELOADED after reception. To use the UNLOAD/RELOAD procedure, the
following conditions must be met.
• The file must be defined with TYPE=SU.
• The $JOBREL4 and $JOBUNL4 JCL files in the SYSJCL library must be customized.
To send the file, the SYSOUT is unloaded by ISF. To receive the file, you must create a member
in the SYSPRM library that will provide output options to IEBGENER. Then, give its name in the
UNLOAD/RELOAD member field in the symbolic file definition.
Using this information, Connect:Express will automatically build the RELOAD job, submit it, and
wait for the result. Only outgoing transmission and incoming reception are available.
With Direct transfers, the SYSOUT is copied to a file and sent as a Sequential file.
USER files USER files can have any special structure defined by the user that is processed with a
UNLOAD/RELOAD mechanism. For example, it can be a group of files that have to be sent in a
bundle or any data base extraction. USER files can only be transferred using the Unload/Reload
method as described below.
The file is transmitted as a VBS file after automatic UNLOAD, and automatically RELOADED after
reception. To use the UNLOAD/RELOAD procedure the following conditions must be met.
• The file must be defined with TYPE=UU.
• The $JOBREL3 and $JOBUNL3 JCL files in the SYSJCL library must be customized.
To send the file, the user procedure is started to build the VBS file to be sent. On receiving the
file, the reload procedure is started as defined by the user after the VBS file is transmitted.
Connect:Express will automatically start the UNLOAD or RELOAD procedure and wait for the
result before sending the file or notification that the file has been received. Only outgoing
transmission and incoming reception are available. Zipped files can also be transferred this way.
Allocating Files
The file allocation process is more involved when receiving files than sending them. On transmission, you only
need to name the file and have access to it. When receiving files, you must set up parameters for allocation in
the symbolic file definition. Some of the parameters are mandatory depending on the file transfer protocol that
you are using. With some protocols, Connect:Express receives the parameters for the file before receiving the
file. Refer to the User Guide for information about allocating files in an SMS environment.
Connect:Express typically manages file allocation, but it can also be performed by a user exit which is defined
in the symbolic file parameters. Connect:Express provides the following file allocation features:
Feature Description
Allocation of catalogued and Connect:Express can allocate both catalogued and multi-volume file types.
multi-volume files
Chapter 3 / Controlling Transfer Operations 3-21
Feature Description
Rotation on a pool of volumes You can define a group of disks on which you want Connect:Express to allocate a file.
Retention and expiration date You can allocate files with a retention date or an expiration date. With a retention date,
processing the file is kept for a specified number of days. With an expiration date, the file is kept until
a specified date.
Exchange of allocation By exchanging allocation parameters between Partners, the sender can send
parameters between Partners parameters to the receiver so that the file will be exactly the same for the receiver.
Connect:Express typically manages file I/O, but it can also be performed by an I/O user exit which is defined in
a presentation table. The Presentation Protocol field points to the presentation table from the File Attributes
screen.
Connect:Express Workfiles
Connect:Express uses temporary files for the following processes:
Process Description
Checkpoint Connect:Express creates temporary checkpoint files during transfer execution. These files are
processing built from the CHKMODEL allocated in the APM procedure.
IEBCOPY The SYSIN file of IEBCOPY is a temporary file. This is created when you select members for a
procedures PDS Unload/Reload file.
Process Description
Some TSO/ISPF MSG, EDIT, LIST, and CMD involve workfile allocation. The dsn structure is shown below:
functions • If SYSPREF=SYSUID Index1 = SYSUID
• If SYSPREF not equal SYSUID Index1 = SYSPREF and Index2 = SYSUID, 'Clist/Program'
and 'Function' name.
NOTE: Using option 0 from the main menu, you can set the work unit to any unit allowed or leave
it blank.
Checkpoint Files
Connect:Express is designed to be in service 24 hours-a-day, 7 days-a-week and to support file transfer restarts.
To accomplish this, Connect:Express provides checkpoint and recovery files to ensure data integrity in the
event of a transfer interruption, a system failure or other event that requires you to restart Connect:Express. The
Monitor checkpoint and recovery files record the general status of Connect:Express activity, and the current
status of each transfer request is recorded in its own checkpoint file.
Note: Using the SYSTEM CANCEL command can cause data to be lost in the checkpoint file.
transfer request checkpoints to different devices. You can have each APM allocate these temporary files on a
special disk. The following screen shows an example of the transfer request checkpoint data set name.
DD CHKMODEL DSN=CHKIND1.TOM2AP01.CHKMODEL
DD CHKMODEL DSN=CHKIND1.TOM2AP02.CHKMODEL
Security
Security in Connect:Express involves managing identification of Partners and files and controlling access to
Connect:Express features. This section describes the identification parameters used in Connect:Express. It also
outlines the security process and lists the parameters that you can use to setup security in your business
environment.
Identification Parameters
Connect:Express must be able to identify who Partners are, what files to transfer, what method or protocol to
use, and how to notify you that the transfer has taken place. This is done on the following four levels:
Level Description
Application This is the requestor of the transfer. The application processes the data set name and extended
identification for the Partner and the file.
Monitor The monitor executes the transfer and processes the data set name, network address, and
symbolic identification for the Partner and file.
Remote Partner This is the receiving Partner. The remote Partner processes the data set name and the symbolic
and extended identification for the Partner and file.
System The system controls access to the files and processes the data set name and local user
identification.
The tables in this section identify the parameters that Connect:Express uses during the identification process.
The tables are organized by function. The first two columns identify where Connect:Express gets the transfer
information. The third column provides a description, and the last two columns list the reports and fields where
Connect:Express logs information about the transfer.
3-24 Connect:Express z/OS Administration Guide
File Identification
The table below shows how file identification is processed and lists the parameters and logs that
Connect:Express uses.
DIRECTORY SYMBOLIC The symbolic name identifying the file and profile of the JOURNAL Z45FILEN
NAME transfer. It must be negotiated with the Partners involved
before running the transfer. This name must correspond to an SMF Z07FILEN
entry in the remote Connect:Express directory.
P1B2PRQ2 parmlist SFN= The symbolic name of the file to be transferred. JOURNAL Z45FILEN
P1B2PRQ3
P1B2PREQ SMF Z07FILEN
REQUEST
DIRECTORY DSNAME The local identification of the file. It can be sent to the Partner JOURNAL Z45DSNAM
P1B2PRQ2 parmlist DSN= using protocol fields.
P1B2PRQ3 DSR= SMF Z07DSNAM
P1B2PREQ
REQUEST
P1B2PRQ2 parmlist API= The information that the application uses for identifying the JOURNAL Z45TAPID
REQUEST A48= transfer (other than Connect:Express). Most protocols use a
A34= structure of ORIGIN+DESTINATION+NAME+DATE. SYSLOG API_CREATE
SYSAPI82 Connect:Express moves this information from user to user and
stores it in the journal.
D1B2RUEX UEXDDNM= The symbolic file name exchanged between Connect:Express JOURNAL Z45FILEN
and a user exit.
SMF Z07FILEN
UEXDSNM= The physical data set name exchanged between JOURNAL Z45DSNAM
Connect:Express and a user exit.
SMF Z07DSNAM
Partner Identification
The following tables show how Partner identification is processed and lists the parameters and logs that
Connect:Express uses. There is one table for remote system identification, and one for local system
identificaiton.
DIRECTORY SYMB. NAME A symbolic name identifying a remote system or a session profile. JOURNAL Z45PARTN
It is associated with a network address and identifies the partner.
It enables outgoing calls and incoming calls with verification. It SMF Z07PARTN
must be negotiated with the Partner before running the transfer. If
it is not associated with a network address, it identifies a partner
profile and assumes the user is in charge of physical identification.
Chapter 3 / Controlling Transfer Operations 3-25
ODETTE IDENTIF. Application name for the remote ODETTE-FTP site. When there is D1B2PCNX
an incoming call, the name is verified. If no API parameter is given
at request time, the symbolic identification is used as the default in
the origin and destination fields.
SYSX25 SYMB. PARTNER The partner name defined in the directory that has an alternate JOURNAL Z45PART
X25 link defined by the parameters associated with the symbolic
partner. When attempting to make an outgoing connection, the SMF Z07PARTN
directory link is used. If there are problems, then the SYSX25 links
will be used to attempt the connection. When an incoming
connection is attempted, the caller’s link is verified first from the
directory, then using the directory link, then using the SYSX25
links.
Remote address One of the network addresses that the partner can be connected
with.
CUG Call User Group, set in the outgoing X.25 call packet.
UDF User Data Field, set in the outgoing X.25 call packet.
MCHSEL The local identification of the X.25 network through which the
partner is linked.
X25BYPAS XPAD The standard key used for general PAD incoming connections. If JOURNAL Z45PARTN
the calling partner can't be found in the directory, the one
associated with that key will be used. The Calling partner is the SMF Z07PARTN
requestor.
X25BYPAS ETB3 The standard key used for general ETEBAC3 incoming JOURNAL Z45PARTN
connections. If the calling partner network address can't be found
in the directory, the symbolic partner associated with that key is SMF Z07PARTN
used. This symbolic partner must be defined with
TYPE=ETEBAC3, protocol 4.
SYSSNA SYMB. PARTNER The partner name defined in the directory that has an alternate JOURNAL Z45PARTN
SNA link defined by the parameters associated with the symbolic
partner. When attempting to make an outgoing connection, the SMF Z07PARTN
directory link is used. If there are problems, then the SYSSNA
links will be used to attempt the connection. When an incoming
connection is attempted, the caller’s link is verified first from the
directory, then using the directory link, then using the SYSSNA
links.
LUNAME One of the LUNAMES that the partner can use for SYSLOG
communications. When making an outgoing call, the list of
lunames is scanned.
SNA LOGMOD The LOGMOD pointing to a COS table entry, used to access an
SNA partner. The default is taken from the DIRECTORY field.
LU2BYPAS The standard key used for general TED 3270 incoming JOURNAL Z45PARTN
connections. If the calling partner can't be found in the directory
the one associated with that key is used. The calling Partner is the SMF Z07PARTN
requestor.
3-26 Connect:Express z/OS Administration Guide
SYSTCP SYMB.PARTNER The partner name defined in the directory that has an alternate JOURNAL Z45PARTN
TCP/IP Link defined by the parameters associated with the
symbolic partner. When attempting to make an outgoing SMF Z07PARTN
connection, the directory link is used. If any problem occurs, then
the SYSTCP link will be used to attempt the connection. When an
incoming connection is attempted, the caller’s link is verified first
from the directory, then using the SYSTCP links.
ADDRESS One of the TCP/IP addresses that the partner can use for SYSLOG
communications. When making an outgoing call, the list of
TCP/IP addresses is scanned.
PORT The port number associated with the current TCP/IP address.
Used only when making an outgoing call.
FTPBYPAS The standard key used for general FTP incoming connections. If JOURNAL Z45PARTN
the calling partner is not found in the directory, the one associated
with this key is used. The calling Partner is the requester. SMF Z07PARTN
P1B2PRQ2 SPN= The symbolic name of the remote partner you want to transfer JOURNAL Z45PARTN
parmlist with.
P1B2PRQ3 SMF Z07PARTN
P1B2PREQ
REQUEST
P1B2PRQ2 API= Information that the application uses for identifying the transfer. JOURNAL Z45TAPID
parmlist A48= Most protocols use a structure of
REQUEST A34= ORIGIN+DESTINATION+NAME+DATE. SYSLOG API_CREATE
SYSAPI82 Connect:Express moves this information from user to user and
stores it in the journal.
D1B2PCNX CNXAPIXX= The connection parmlist is sent to the connection user exit.
D1B2PUEX UEXAPIXX= The transfer parmlist is sent to the transfer user exit. JOURNAL Z45TAPID
SYSIN DPCSID Symbolic name identifying the local Connect:Express system. This none
general identification is also associated with its DPCPSW value. Both
the DPCSID and the DPCPSW values can be overridden by the alias
for a connection. The DPCSID and the DPCPSW values, or their alias,
must be negotiated with the partner before running the transfers. This
name must match an entry in the remote Connect:Express directory.
DIRECTORY ALIAS The ALIAS is a symbolic name identifying the local Connect:Express none
system for its associated partner. This name will override the DPCSID
connection parameter. The ALIAS must be negotiated with the Partner
before running the transfers. This name must match an entry in the
remote Connect:Express directory.
ODETTE Application name for local ODETTE-FTP. This name is sent at D1B2PCNX
IDENTIF. connection time. It is associated with the local symbolic definition in
the Connect:Express directory. If no API parameter is given at request
time, the symbolic identification is used as the default in the origin and
destination fields.
Chapter 3 / Controlling Transfer Operations 3-27
P1B2PRQ2 DPC= An alias identifying the local Connect:Express system for the current none
parmlist transfer request. This name overrides the DPCSID parameter from
REQUEST SYSIN or the ALIAS field of the directory. It must be negotiated with
the Partner before running this transfer. This name must match an
entry in the remote Connect:Express directory.
P1B2PRQ2 API= This information is used by the application for identifying the transfer. JOURNAL Z45TAPID
parmlist A48= Most protocols use a structure of
REQUEST A34= ORIGIN+DESTINATION+NAME+DATE. SYSLOG API_CREATE
SYSAPI82 Connect:Express moves this information from user to user and stores
it in the journal.
D1B2PCNX CNXAPIXX= The connection parmlist is sent to the connection user exit. none
D1B2RUEX UEXAPIXX= The transfer parmlist is sent to the transfer user exit. none
3-28 Connect:Express z/OS Administration Guide
Using ALIAS
An Alias enables you to transmit files using a name other than your Partner name. Sometimes you may need to
do this when transferring files with a remote Partner. You can replace the DPCSID from SYSIN by the ALIAS
from the directory or request extension for both outgoing and incoming connections. This section provides
examples that show what is sent during an outgoing connection and the verification performed during an
incoming connection.
REQUEST Partner1
Alias= Alias=
My name is
TOMname NAME=
TOMname
C:X
CALLING
Partner1
TOMname
SYSIN
REQUEST Partner1
Alias= Alias=NAMPAR
My name is NAME=
NAMPAR NAMPAR
C:X
CALLING
Partner1
TOMname
SYSIN
Partner1 NAME=
REQUEST
Alias=NAMPAR NAMREQ
Alias=NAMREQ My name is
NAMREQ
Partner1
C:X
CALLING
TOMname
SYSIN
The third example shows that the destination NAMREQ is different from both the SYSIN file field and the
alias field, and so Connect:Express rejects the connection. The fourth example shows that the destination
parameter is equal to the SYSIN field: although an alias is defined in the partner1 definition, Connect:Express
accepts the call.
INVALID DESTINATION message is issued when the destination is neither equal to the SYSIN DPCSID field
nor equal to the partner ALIAS field.
3-30 Connect:Express z/OS Administration Guide
Requestor Identification
The requestor is the user (TSO, BATCH, remote Partner, or origin) that originated the transfer request. For an
incoming transfer request, the requestor name is generally the same as the origin. When a bypass is used from
SYSX25, SYSSNA or SYSTCP files, the requestor is the name of the origin, and the Partner profile from the
bypass is used as partner identification when connecting. The caller name is used as the transfer requestor
identification. The requestor identification (the origin name) does not need to be defined in the directory.
Local z/OS SYSTEM TSO USER The TSO user symbolic name which issued a request from
Connect:Express TSO/ISPF panels (4.1, 4.2, 4.3, 4.4).
External user Origin The name of the remote system that requested an incoming transfer.
Overview of Security
Transfer operations should be executed in a secured environment. Connect:Express has provisions for the
following five levels of security.
1. Symbolic security for flow control.
2. System security for data sets and z/OS commands access.
3. Network security for incoming call verification.
4. SSL/TLS encryption for integrity, confidentiality, and authentication .
Symbolic Security
In a Connect:Express environment, file transfers are organized by symbolic names and passwords. Symbolic
security is based on the following parameters:
The Partner symbolic name and Partner type.
The File symbolic name which identifies the transfer direction for the file, the Partner or list of partners for
receiving the file, and the Partner or list of Partners for Transmitting the file.
Connect:Express verifies that the calling Partner exists in the Partners directory and that the password of the
calling Partner is correct. The called Partner (or destination) is also verified using the local Connect:Express
symbolic name DPCSID or alias.
Connect:Express also verifies that the file exists in the files directory and that the direction of the transfer
request is correct. The receiving partner and transmitting partner are verified by checking the following values
in the Partner fields:
Value Description
Value Description
$$API$$ Used for incoming transfers only. No control is done. It is the responsibility of the application (user
exit).
££API££ Used for incoming transfers only. Any user defined in the list associated with the file is allowed.
Note: A user is not defined in the directory. This is the transfer requestor and it can be different
from the Partner.
The available symbolic security facilities depend on the partner type, as shown in the following table.
T = Connect:Express (TOM) partner All facilities available: symbolic name, password, flow control.
3 = ETEBAC 3 All facilities available: symbolic name, password, flow control. The
application has limited controls. Refer to Connect:Express /F-ETB410
documentation for more information.
Security Parameters
The following table lists all parameters in Connect:Express files that are involved in the security processes.
SYSIN DPCSID The local name of the Connect:Express system Journal Z45TAPID
with which you are transferring files. It is verified user exit U03ORIGN
as the destination for an incoming call and sent U03DESTN
as the origin of an outgoing call. This value is the U05ORIGN
default, but can be replaced by an ALIAS for one U05DESTN
partner or for one transfer. TSO/ISPF API
2.3
PARTNERS SYMB. NAME Remote partner identification. It is verified as the Journal Z45TAPID
DIRECTORY origin for an incoming call, and sent as the user exit UEXPARTN
destination of an outgoing call. SYSLOG U03DESTIN
U03ORIGN
U05DESTIN
TSO/ISPF U05ORIGN
2.3 API
ALIAS DPCSID The local name of the Connect:Express system Journal Z45TAPID
with whom you are transferring files. It is verified user exit UEXPARTN
as the destination for an incoming call and sent U03DESTIN
as the origin of an outgoing call. This value U03ORIGN
replaces the default DPCSID U05DESTIN
TSO/ISPF U05ORIGN
2.3 API
ALIAS DPCSID The local name of the Connect:Express system Journal Z45TAPID
with whom you are transferring files. It is sent as user exit UEXPARTN
the origin of an outgoing call. This value replaces U03DESTIN
the default DPCSID and the ALIAS DPCSID of U03ORIGN
the directory. U05DESTIN
TSO/ISPF U05ORIGN
2.3 API
AD HOC RACF USERID Used for RACF verification on the remote site.
REQUEST
RACF USER Used for RACF verification on the remote site.
GROUP
P1B2PRQ2 SID= The local name of the Connect:Express system Journal Z45TAPID
with whom you are transferring files. It is sent as user exit UEXPARTN
the origin of an outgoing call This value replaces U03DESTIN
the default DPCSID and the ALIAS DPCSID of U03ORIGN
the directory. U05DESTIN
TSO/ISPF U05ORIGN
2.3 API
TSO/ISPF
2.3
System Security
Connect:Express interfaces with system security facilities like RACF – ACF2 and TOP SECRET through the
SAF interface. System security is a combination of RACF type security and options that control file allocation
and the issuing of z/OS commands. System security facilities are invoked to check access to the data sets
transferred. You can disable some verifications. The following conditions apply:
Connect:Express must be allowed to read and create-write all files to be transferred and temporary
workfiles used for unloading/reloading. If not, the typical return code is TRC=2098.
Chapter 3 / Controlling Transfer Operations 3-35
The local requestor or the application that makes the transfer request must be allowed access to the data
set. The local requestor can provide an RACF group at request time. The default is its own group.
The remote requestor or the remote partner who connects to transfer a file must be allowed to access the
data set. Optional RACF USER and RACF GROUP fields are provided in the partner definition for
incoming request verification.
The AD HOC requestor or the remote user who connects to transfer a file with the AD HOC facility must
be allowed to access the data set on the remote site. With this feature, the user provides a user logon and
password, and the symbolic partner definition used for connection (RACF USER and RACF GROUP) is
not involved in the security checking. The AD HOC facility can be completely disabled, or the security
option of the AD HOC feature can be disabled.
Connect:Express is enabled to start any z/OS command, but you may not want users to have access to this
feature. You can set a general option in the SYSIN file to disable this feature (UPRFCT).
You can ensure that the allocation parameters sent are consistent with what you defined in the file
directory.
HFS files are under the control of the BPX server.
Network Security
Network address control is done through the partner definition. Each link type (X.25, SNA, TCP/IP) is given
one network address or a list of network addresses. This control can be disabled if one of the addresses is set to
‘*’ in the directory or in the alternate address files.
Encryption
CRC (Cyclic Redundancy Check) is activated by an option provided in the session tables T1B2PS2x,
T1B2PS3x and T1B2PS5x. This algorithm follows the ISO DIS 8073 transport layer standard. Refer to the
Connect:Express z/OS SSL Guide for securing file transfers.
User Exits
You can manage security through the user exit security interface. Connection, selection, and transfer exits
enable you to control access at different levels. Connect:Express z/OS provides an RACF connection server
exit that you can implement called M1USRCNA. The macro M1USRCNA is provided in the *MACLIB* for
customization, and an example is provided in the *SAMPLIB*. See Chapter 2, User Exits for more information
about user access control.
Protocol Management
When you transfer a file, you exchange information with your Partner using a file transfer protocol that defines
the rules that Partners use to negotiate with each other and transfer files. File transfer protocols are
implemented over network protocols so the administrator must be aware of network protocol parameters used
to communicate over physical links.
Transfer Protocols
A transfer protocol consists of commands for negotiating and terminating a connection or transfer, or for
sending a file. Protocol return codes (PRC) are a means of controlling operations in association with
Connect:Express return codes (TRC).
3-36 Connect:Express z/OS Administration Guide
A transfer is comprised of a series of events that precede or result from protocol commands. Events and results
are reported in the Connect:Express SYSLOG file, Request Control Table (RCT) and Journal. Reports can be
stored in an SMF file.
The protocol used for transferring a file is associated with the Partner using the PROT.NUM field of the Partner
definition in the directory. Each protocol is assigned 15 session tables called T1B2PSxy, where x is the protocol
number and y the session table number (y= 1 – 9, A – F). Fields in protocol commands contain information
about the connection and the data to be transferred. This includes the identification parameters set in
Connect:Express directories or other files, the session and transfer parameters set in tables, and application
parameters.
The following table describes the transfer protocols supported by Connect:Express.
PeSIT Protocol specifications from the French Banking Organization. PeSIT is an FTAM like protocol
enabling all Connect:Express facilities (AD HOC, PDS, VSAM files). PeSIT supports SSL/TLS
protocol.
ODETTE-FTP Protocol specifications from the Organization for Data Exchange by TeleTransmission in Europe
for the European Car Constructors organization. ODETTE supports SSL/TLS protocol.
ETEBAC3 Protocol specifications from the French Banking Organization. Described in the French
documentation Connect:Express /F-ETB410.
Note: PeSIT and ODETTE-FTP protocols are described in Chapter 5, SSL/TLS protocol is described in the
SSL Guide, the FTP protocol is described in the FTP Guide, and the Etebac3 protocol is described in
the Etebac3 User Guide.
Network Protocols
You can connect with a Connect:Express Partner using one or more link types depending on its definition in the
Directory fields and in the SYSSNA, SYSTCP, or SYSX25 files. Connect:Express and the Transfer Protocol
Manager (APM) work with the Network Manager (ANM) to communicate with the Partner. The link drivers of
the ANM handle different types of connections and interface with the Network Protocols executed by VTAM,
X.25-NPSI, or TCP/IP. FTP partners are accessed over TCP/IP links, and FTP transfers are handled by the
AFM and EAS address spaces.
The table below identifies the transfer and network protocols that Connect:Express supports. The codes are
used in the table on page 3-37.
Code Protocol
D PeSIT D
E PeSIT E
O ODETTE-FTP
3 ETEBAC 3
F FTP
Chapter 3 / Controlling Transfer Operations 3-37
The following table lists the available environments and is subject to change.
Computer System X S L p B T
Company 2 N U A S C
5 A 6 D C P
2
D E O 3 D E 3 D E D E O 3 1 D E F O
IBM z/OS X X X X X X X X X X X X X X X X X X
AIX X X X X X X X
COMPAQ
OSF1 UNIX X X X X X X X X
TANDEM GUAR.D30 X X X X X X X
HP HP-UX X X X X X X X X X
NCR UNIX X X X X X X X X X
SUN
SOLARIS UNIX X X X X X X X X X
VARIOUS Windows32 X X X X X X X X
Note: If a Connect:Express Partner has a type of Other, only open protocol facilities are available with this
Partner, even though it uses Connect:Express software.
The ADHOC facility is available with Connect:Express for NT. See Identifying the User on page 3-41 for more
information.
Note: When using PESIT protocol, &PI99, &EXTDSN, and &USRVAR keywords are exclusive. To use
&PI99, the Partner type must be other. To use &EXTDSN and &USRVAR, the Partner type must be
TOM.
† or later
† or later
† or later
3-40 Connect:Express z/OS Administration Guide
† or later
Reporting
You can access reports that provide information about the status of the Connect:Express monitor and
operations in general. You can view the status online as it is happening, or receive notifications through a user
exit, or offline in a journal or log file. You can then use Help to interpret the return codes.
You can use reports to start other processes or take corrective action when required. The Reporting table shows
the report options that are available for the Monitor Status and Operations Status.
Monitor Status
Initialization X X X X
Resources X X X
Termination X X X X
Operations Status
Transfer Requests X X X X X
Connections X X
Transfer Execution X X
Monitor Status
When Connect:Express is initialized or terminated, you can start a user command which reports the status of
Connect:Express. This information comes from the following parameters in the SYSIN file: UPRBEG=,
UPREND=, and UPRABE=. These fields tell you if the Monitor is up or down or if any abends have occurred.
Some user exits are also invoked during initialization and termination of Connect:Express. These include
connection exits, selection exits, and journal exits.
Chapter 3 / Controlling Transfer Operations 3-41
You can check the status and make modifications using the API or TSO/ISPF interface. These can help you
enable or disable resources and manage abnormalities by setting alert thresholds and taking corrective actions.
Operations Status
You can display the status of a transfer request, track connection errors, or introduce your own procedures
before, during, and after the execution of a transfer.
At any time, you can display the status and results of transfer requests by their local request number using API
or TSO/ISPF reports. You can also display active transfer requests for one partner or file, or all transfer
requests using the API or TSO/ISPF. Then you can activate, interrupt, or restart these requests. The log file lets
you look at the entire history of the transfer request while the journal file gives you the transfer results and
statistics.
You can control the local user requests with a transfer request user exit. For example, you can set the priority of
a transfer or select the class of the request. In addition, you can track connection errors online with a user exit
or offline using the log file messages.
Additional Reporting
Transfer operations events are reported in the Connect:Express log file (SYSLOG) with return codes. There are
four types of Return codes:
1. Connect:Express (TOM) Return Codes – TRC
2. Transfer Protocol Return Codes – PRC
3. Network Return Codes – NRC
4. System Return Codes – SRC
Note: See Appendix B, Error Codes and Messages for a listing of TRCs, PRCs and NRCs. SRCs can be
found in the IBM z/OS documentation.
Connect:Express Messages
Any events pertaining to Connect:Express are reported in the Connect:Express message file (SYSMSG). The
message structure is shown below.
The SYSMSG file shows the time stamp, the subsystem name (TOM8), the message number (046), message
type (I), and text. The following table lists the message types:
Code Description
W Warning
E Error
I Information
1 Protocol error
2 All errors detected by the Connect:Express Monitor. For example, scheduling, flow control
allocation, security.
The program that calls L1B2LOG interface must be re-entrant. The following screen shows how to call
L1B2LOG:
*-----------------------------------------------------------------------*
* PROGRAM INITIALIZATION
*-----------------------------------------------------------------------*
*-----------------------------------------------------------------------*
* PROGRAM PROCESS
*-----------------------------------------------------------------------*
MVC USRLOG,MSG1
LA R1,USRLOG POINT TO MESSAGE
ST R1,PARMLOG STORE PARM ADDRESS
LA R1,PARMLOG POINT TO PARM LIST
CALL L1B2LOG PERFORM
LTR R15,R15 OK ?
BNZ LERRMSG NO
B LEND END
*-----------------------------------------------------------------------*
* PROGRAM TERMINATION
*-----------------------------------------------------------------------*
*-----------------------------------------------------------------------*
* PROGRAM CONSTANTS
*-----------------------------------------------------------------------*
*-----------------------------------------------------------------------*
* PROGRAM DYNAMIC WORK AREA
*-----------------------------------------------------------------------*
PARMLOG DS F
USRLOG DS CL133
Refer to the Connect:Express z/OS Utilities Guide for information about sending messages with L1GFIUE1.
Reliability
Connect:Express is designed to be in service 24 hours-a-day, 7 days-a-week, and reliability is of primary
importance. To accomplish this, Connect:Express provides checkpoint and recovery files to ensure data
integrity in the event of a system failure or other event that requires you to restart Connect:Express.
If a system failure occurs, you can restart where you left off with a hot-start. In some cases, the monitor must be
stopped manually like when you update the software or change the Connect:Express configuration. When the
monitor is not up, there is a recovery file that receives and records transfer requests. When the monitor returns
to service, it will restart where it left off, then read the recovery file and perform the transfer requests. The
hot-start uses a checkpoint file that contains the information and current status needed to restart where the
monitor left off.
3-44 Connect:Express z/OS Administration Guide
A cold-start is a fresh start and does not use checkpoint information. In cases when a cold-start is planned, the
checkpoint and recovery files should be saved. Then after the cold-start, the checkpoint and recovery files can
be reloaded.
Note: The Extended Recovery capability in Connect:Express enables automatic recovery within an z/OS
sysplex environment, even when a complete failure of z/OS occurs. See Chapter 1 Sysplex
Environment for more information about Extended Recovery.
To further ensure reliability, parameters are always verified at initialization and whenever they are added,
changed, or deleted. The next sections identify when the monitor needs to be stopped and what type of start
needs to be performed.
Component Description
Tables Most Connect:Express tables are automatically reloaded when updated using the TSO/ISPF
interface. The tables used by the APM, however, are not automatically reloaded. The transfer
server exits table, T1APMSRT, and the presentation protocol parameters table, T1B2PP.., must
be manually reloaded by issuing stop APM/start APM commands.
User Exits Some user exits are loaded by the APM during its initialization. Any change to the exits must be
followed by a stop APM/start APM command. This is needed in the following cases:
• A transfer server exit is declared in the T1APMSRT table and can be inactivated after an
ABEND, or if not found during APM initialization.
• Middle of transfer user exits are declared in T1B2PP.. tables and loaded during APM
initialization.
Component Description
SYSIN When changing most of the SYSIN parameters, you only need a hot-start to make the changes
take effect. One exception is when you update the APLNUM field of the SYSIN file. This must be
followed by the '$LOAD$' procedure and then a hot-start.
CXPLEX When changing the CXPLEX parameter file, you only need to hot-start of Connect:Express.
User Exits Some user exits are loaded by Connect:Express during initialization. Any change to the exits
must be followed by a hot-start of Connect:Express. These include:
• A connection user exit declared in the T1B2PCNT table that can be deactivated after an
ABEND or if it is not found during initialization.
• The request control user exit.
• A Journal user exit
Chapter 3 / Controlling Transfer Operations 3-45
Component Description
Tables Some tables used by Connect:Express are not automatically refreshed in Connect:Express when
updated and require a hot-start. These include:
T1B2PCNX–connection user exits (option 3.3.CNT)
T1B2PSLD–session links definitions (option 3.3.SLD)
T1B2PS..–session protocol parameters (option 3.3.SXX)
T1B2PVOL–allocation volumes (option 3.3.VOL)
T1B2PACS–access control (option 3.3.ACS)
T1B2PCOD–protocol return codes and automatic restart (option 3.3.COD)
Component Description
Version change or A new version of Connect:Express or a PTF (an update to a version) requires a cold-start.
update
SYSIN If any of the following SYSIN parameters are changed, then a cold-start is required.
• DPCSID
• DPCPSW
• MAJIND
• CMDPRE
• RQEMAX
• DAPMxx cards added or deleted
When a cold-start is required, you should plan for it so that you can maintain the current operational status of
Connect:Express. To do this, you need to save the checkpoint and recovery files using an unload procedure.
Then, perform the cold-start, followed by the reload procedure which restores the previous operational status.
Offload and reload procedure examples are provided in the *SAMPLIB* directory in the $CKOFLOD and
$RCOFLOD modules.
Note: The offloading of *SYSCHK* and *SYSRCY* can be included as preliminary steps of the standard
Connect:Express job.
3-46 Connect:Express z/OS Administration Guide
Timers
To avoid locked situations, Connect:Express address spaces activate timers. The table below describes each
timer.
Timer Description
ANM Timer During initialization, the ANM activates the network drivers and the TOM waits for the end of ANM
initialization. If one driver initialization doesn’t succeed and gives no response, the ANM will
continue and return to the TOM that continues to initialize the APM and other resources. This
timer is fixed and set to 4 minutes 30 seconds.
Connection and deconnection timers are activated by the network layers. The ANM provides fixed
connection and deconnection timers with values greater than the current network specifications.
The Data flow timer during the opened session is controlled by the ANM and is set to a maximum
of 7 minutes before aborting a session that is blocked.
TOM Timer In the TOM address spaces, the timer is set against user exits. The connection user exit is run in
the TOM address space and is protected by a 5 minute timer.
APM Timer In the APM address space, the timer is set against remote network problems and local user exits.
The selection, beginning, middle, and end of transfer user exits are run in the APM address space
and are protected by two options. One of these options defines how you call the exit and the time
it is allowed to be active before returning back. When this timer expires, the user exit is detached
if it was previously attached, or the effector is detached.
User Exit Timer During Connect:Express termination, the APM is notified and waits for effector termination. If the
effector doesn’t stop, it is detached after 2 minutes.
AFM/EAS Timers In the FTP address spaces, the timers are set against remote network problems and remote user
inactivity. One timer is dedicated to user inactivity during the connection phase, another one is
dedicated to user inactivity while connected, and another one controls the data transfer duration.
Incoming and
Outgoing Transfers
This chapter describes the file transfer operations of Connect:Express. It covers PeSIT, Odette, and ETEBAC
transfers that are processed in the TOM, ANM, and APM address spaces. This chapter outlines the steps of an
incoming and an outgoing file transfer and identifies the parameters, the transfer process, and reporting
capabilities.
Overview
Each step of transfer operations involves a number of parameters and takes place in one of the address spaces
that are running when Connect:Express is started. Each process is reported in a different way. This chapter has
a section for outgoing transfers and a section for incoming transfers. The following topics are discussed in each
section:
Connection – establishing the Network link (X25, TCP/IP, SNA..)
Session – establishing the Protocol link (PeSIT, ODETTE, ETEBAC3…)
Selection – negotiating the file transfer with the protocol conventions.
Transmission – sending the file to a remote partner.
Reception – receiving the file from the remote partner.
Transfer – exchanging the data.
Connection is executed in the ANM address space. Connection and Session are managed in the TOM address
space, and selection and transfers are managed in the APM address space.
Note: The ANM is a network services provider used by both the TOM and APM address spaces. The ANM
executes network connections and de-connections, and sends and receives data.
One session is executed during a connection, and more than one transfer selection can be executed during a
session. After the transfer negotiation is complete, the file transfer is executed. If the transfer negotiation fails,
4-2 Connect:Express z/OS Administration Guide
the next selection is executed, if any. Every step that was successfully completed is closed or ended, as shown
in the following diagram.
Address Space
APM
TRANSFER APM
APM
APM
TRANSFER APM
APM
The following table lists the situations that are discussed in this chapter and identifies any special
considerations. Outgoing transfers are discussed first. These are the transfers that you request locally. Incoming
transfers correspond to external requests you receive from remote partners. Data exchange is the same for both
outgoing and incoming transfers.
Data exchange
Outgoing Transfers
A local TSO or batch user sends a transfer request to Connect:Express. The four items listed below are
mandatory.
1. Symbolic File name
2. Symbolic Partner name
3. Transfer direction
4. Physical data set name
They must either be provided with the transfer request or stored in the symbolic File name entry in the Files
directory. You can store all necessary parameters so that you only have to enter the symbolic File name to
execute a transfer.
If Connect:Express is started, the request is identified by a request number, queued into the Request Control
Table, and set to enabled or saved in the Connect:Express recovery *SYSRCY* file. If Connect:Express
resources are all available and the number of active sessions for the Partner has not reached the maximum
allowed, the request is scheduled. If the transfer protocol provides a restart facility, the request is allocated a
checkpoint record. The request and checkpoint record will be purged at the successful end of transfer or if you
make a purge request command.
Note: If the file space is known and it is less than or equal to one kilobyte, no checkpoint is allocated.
SYSIN file
PARTNERS directory + SYS-SNA/TCP/X25 files
FILES directory
REQUEST fields
TABLES session, data presentation
USER EXITS
Outgoing Connection
Connect:Express requests and supervises the connection in the ANM address space. This includes both the
open and close connection operations. Each connection is processed by a subtask attached when it is opened
and when it is closed. Connect:Express can manage several simultaneous connections depending on the
available resources. Connection parameters are set in the symbolic Partner definition and the
SYSIN/SYS-SNA/TCP/X.25 files. The retry connection and restart transfer options are defined by the
STIMOC= and STIMEV= fields in the SYSIN file.
The connection is followed by the protocol session. This includes the open and close session operations that are
processed in the Connect:Express address space. The protocol session parameters are set in tables referenced
by the symbolic Partner definition. The connection user exit, if any, is given control before a call, and can
override information or add applicable parameters that Connect:Express does not implement. The connection
user exit is also given control after the close connection.
Parameters used for outgoing connections are defined in the following locations:
Location Parameter
SYSIN file RQEMAX, APLPFX, DAPMxx, STIMEV, STIMOC, , MCH definitions, TCPORG, TCPPRT
PARTNERS directory+ PARTNER NAME, AUTO.RESTART, TYPE OF LINK, LINK TOT.-IN.-OUT., T-FLOW
SYS-SNA/TCP/X25 files REGULAT., MCHMSC, Addresses
One Partner is assigned a list of possible link types, and you can set the link type when you execute the transfer
request. Connect:Express is given a list of network resources and always knows the status of each.
Connect:Express chooses the first available link type, respecting the link types list, and starts with the link type
of the request, if any. Events are reported in the Connect:Express log file, as shown below.
Connection Failure
The following diagram shows a sample configuration, and illustrates how connection failures are processed
using the alternate links that are defined for this partner.
PARTNER
auto.recall YES
line type M SX
addr.x25 111 SYSX25
luname LU SYSSNA
PARTNER 222,A
MCHMSC - PARTNER 333.B - none -
MULTICHANNELS
LS
ANM A 222
X25
X25
Applications LS
B 333
X25
ANMAPP02 PARTNER
ANMAPP03
1
ANMAPP06
TOM X25 111
SNA 2
Application
ANMAPP01 SNA LU
SYSIN
APLPFX=ANMAPP
STIMEV=(n,.)
STIMOC=y
MCHA MSC=A
MCHB MSC=B
MCH1
MCH2
In this example, the Partner is defined in the Connect:Express Partners directory with possible links of SNA or
X.25, and the corresponding LUNAME and X.25 address. The X.25 definition points to the remote 111 X.25
address through the non-specific X.25 network. The MCHMSC is not set. The connection will be established
from a local multichannel defined for Connect:Express without the MCHMSC parameter. The Automatic
Restart option is YES, so that the retry loop will not stop unless the partner is disabled, or if a connection
failure occurs.
4-6 Connect:Express z/OS Administration Guide
The Partner has two entries in the SYSX25 file which means that if a connection fails on the first X.25 link, the
next one will be processed. The first entry in the SYSX25 points to the A local MCH and the remote 222 X.25
address. This configuration can correspond to the definition of a private X.25 link. The second entry in the
SYSX25 points to the B local MCH and the remote 333 X.25 address. No entry exists in SYSSNA for the
Partner.
Connect:Express manages four MCHs, as listed below. Their description is found in the SYSIN file.
1. MCHA is identified by A selection code.
2. MCHB is identified by B selection code.
3. MCH1 is a non selected multichannel.
4. MCH2 is a non selected multichannel.
The SYSIN gives Connect:Express the number of call attempts to process before changing links and the time in
minutes to wait between each attempt. The number of call attempts is entered in the field, STIMOC=y, and the
time in minutes between each call attempt is in the field STIMEV=(n,.).
The first available resource among the following list will be selected for a call: X.25(MCH1 or MCH2,111)
X.25(MCHA,222) X.25(MCHB,333) SNA(LU).
A request is sent to Connect:Express to transfer a file with the Partner. The link type X, for X.25, is set in the
field of the request. Because the X.25 link type is given at request time, the first call attempt is directed to the
X.25 network even though SNA is the first in the link list. If any X.25 link or X.25 handler is inactive at
connection time, STIMOC will be reduced to zero and the next link type in the list is selected.
No X.25 network is specified in the MCHMSC field in the directory, so the call is processed on the MCH that
is not busy. If the connection is successful, the transfer enters the Session phase.
If the connection fails, the TRC code is set to 2077 and you see the message “Not Obtained.” Then,
Connect:Express starts the retry procedure. Remember that you set retry parameters in the SYSIN file. The
number of call attempts is entered in the field, STIMOC=y, and the time in minutes between each call attempt
is in the field STIMEV=(n,.). The following screen shows an example of connection retry processing.
Chapter 4 / Incoming and Outgoing Transfers 4-7
call attempt:
1. X25 MCH(1 or 2) ----> 111
nok1 (wait n minutes) TRC=2077
2. X25 MCH(1 or 2) ----> 111 TRC=2077
nok2
...
y. X25 MCH(1 or 2) ----> 111 TRC=2077
noky
call attempt:
1. X25 MCH(B) ----> 333 TRC=2077
nok1 ... TRC=2077
...
y. X25 MCH(B) ----> 333 TRC=2077
CONNECTION ERROR --> change link.
call attempt:
1. SNA ----> LUNAME TRC=2077
nok1 ... TRC=2077
...
y. SNA ----> LUNAME TRC=2077
noky
CONNECTION ERROR --> first link again and so on.
In the example above, Connect:Express waits the number of minutes that you set and retries until the
connection is obtained or the maximum number of call attempts is reached. When this happens,
Connect:Express moves to the first SYSX25 entry. Then, it selects MCHA if it is active, and sends the call
packet with the remote X.25 address = 222.
After attempting the number of connection retries on MCHA, Connect:Express looks for the next SYSX25
entry. Then, it selects MCHB for more connection retries if it is active.
If the connection is still not obtained, the SNA link is used for the next retries. The automatic call retry/restart
option is set to YES in the Partner definition, so the loop will continue again with the first X.25 link. To stop
the process, you can disable the Partner.
4-8 Connect:Express z/OS Administration Guide
If the automatic retry/restart option was NO, the process stops after the SNA connection failure, the TRC code
is set to 2076, and the Partner Disabled message displays. An example of a configuration is shown in Outgoing
Call Resources on page 4-5.
Outgoing Session
Open and close session operations take place in the TOM address space after connection has been established
with the Partner. Session parameters are general session parameters and set in Connect:Express protocol tables
T1B2PSxx.
Identification Parameters
Identification parameters are Connect:Express default symbolic parameters or user-specific parameters that are
sent through the user connection exit D1B2PCNX data structure. The end session can be one of the following:
Session reject
Normal protocol end
Protocol abort + return codes
Network disconnection
Parameters used for an outgoing session are defined in the following locations:
Location Parameters
PARTNERS Partner name, DPCSID Alias, DPCPSW Alias, Prot. Number, Prot. Tab, ODETTE Identification
directory
Request Partner name, DPCSID Alias, DPCPSW Alias, Transfer Priority, Transfer Class, API fields
The screen below shows an extract from the logging file about an outgoing session.
Session Failure
If a parameter is rejected during the negotiation, the protocol return code (PRC) is set to a value defined by the
protocol specifications. This PRC is compared to the list of PRCs defined in the T1B2PCOD table for this
protocol. If the PRC matches one on the list, the call retry procedure is activated, and the connection is
postponed. If the PRC is not on the list, the connection is rejected.
Chapter 4 / Incoming and Outgoing Transfers 4-9
Outgoing Selection
Selection takes place in an APM address space after a session has been established with the Partner, and
includes the initialization and termination of transfer. Selection parameters are listed below.
Parameter Description
General They are set in Connect:Express protocol tables T1B2PSxy and T1B2PPxx.
presentation
parameters
Identification They are Connect:Express symbolic parameters and allocation parameters from the directories or
parameters the request. They can be changed with user exits by sending parameters through selection and
beginning of transfer exits using the D1B2RUEX data structure.
Retry parameters They are set in the Connect:Express retry table T1B2PCOD.
When a session has been established, several transfers can take place in both directions. Connect:Express
transmits the session context to the APM that was previously selected. The APM attaches a transfer sub-task or
effector, and then the effector asks Connect:Express about transfers to be done and executes them. When
Connect:Express has no more transfers waiting for selection, the APM returns control to the Connect:Express
address space to process the end session.
Depending on the transfer protocol, the user can establish a session to send or receive a file in either direction.
Some protocols provide read and write commands, while others provide only a write command.
Selection operations are managed from the symbolic file definition and depend on the transfer direction. You
can control some operations using the Application Program Interface (API), while some operations are specific
to the file organization for VSAM, PDS and TAPE files. Events are reported in Connect:Express log file, as
shown below.
If an error occurs during selection or transfer, return codes are first reported to user exits, then to the SYSLOG
and SYSJNL, and finally to the TSO/ISPF interface.
Selection Failure
If a parameter is rejected during the negotiation, the protocol return code (PRC) is set to a value defined by the
protocol specifications. This PRC is compared to the list of PRCs defined in the T1B2PCOD table for this
protocol. If this PRC matches one on the list, the call retry procedure is activated, and the request is postponed.
If the PRC is not on the list, the request is rejected.
4-10 Connect:Express z/OS Administration Guide
Outgoing Transmission
Parameters used for outgoing transmission are defined in the following locations:
Location Parameters
Files directory Symbolic file name, Direction, Remote DSN, Presentation Table Number, parameters for
transmission, data set name
Request Symbolic file name, Partner name, Direction, Data set name
Initialization
When the session has been established, the process is transferred from the TOM address space to the APM
address space. The APM asks Connect:Express for transfers to process, and Connect:Express selects the next
eligible request and starts the Beginning of Transmission command. Then Connect:Express sends the APM all
necessary information, including allocation parameters, user exit names, record processing, and security
conditions found in the Request entry or the File Directory entry.
The Beginning of Transmission user exit or the Application Server, if any, is given control to manage file
allocation. It can also override information or add applicable parameters that Connect:Express does not
implement.
The checkpoint file is allocated for this request and exists until the request is purged at the successful end of
transfer. After the Partner accepts the request, Connect:Express indicates that the transfer was accepted.
Information transmitted to the Partner includes:
Type Description
One or more protocol messages are exchanged with Partners for identification, data presentation, and transfer
restarting negotiations. When you are ready to send data, Connect:Express is informed that the transfer has
started.
Chapter 4 / Incoming and Outgoing Transfers 4-11
Termination
One or more protocol messages are exchanged with a Partner at the end of transfer for security purposes. At the
end of protocol acknowledgments, the End of Transmission user exit or the Application Server, if any, is then
given control.
At this point, the transfer has been accepted by the receiver and the file was sent to the receiving application.
Any error detected by the sender in the termination exit is not indicated to the partner. The request checkpoint
file is deleted, and the file is unallocated. Connect:Express is then informed about a new request. The next
request can be a transmission or reception, depending on the protocol and the session parameters that were
negotiated.
When receiving notification that the transfer has successfully ended, Connect:Express adds an entry in the
Journal file and sends the journal record to the user. It adds a record in the SMF file, if required, and starts the
End of Transmission command and then purges the request. Then, Connect:Express sends the APM the next
request to process or notice to end the session.
Outgoing Reception
Parameters used for outgoing transmission are defined in the following locations:
Location Parameters
Files directory Symbolic file name, Direction, Remote DSN, Presentation Table Number, parameters for
transmission, data set name
Request Symbolic file name, Partner name, Direction, Data set name
Initialization
After the session has been established, the process is transferred from the TOM address space to the APM
address space. The APM asks Connect:Express for transfers to process, and Connect:Express selects the next
eligible request and starts the Beginning of Reception command. Then Connect:Express sends the APM all
necessary information, including user exit names, record processing, and security conditions found in the
Request entry or the File Directory entry.
The selection user exit or the application server, if any, is given control to manage file allocation. It can also
override information or add application parameters that Connect:Express does not implement.
4-12 Connect:Express z/OS Administration Guide
Physical File attributes processed by Connect:Express or you (depending on protocol). Some protocols
carry the file attributes like record format, record length and file space. In this case these
allocation parameters are not mandatory in the file definition for reception. If the protocol doesn’t
provide these parameters, then they are mandatory, unless the file is pre-allocated.
When the Partner accepts the transfer, allocation parameters are found in the protocol command and sent to
Connect:Express. Then, Connect:Express issues a log message that the transfer was accepted by the Partner.
Finally, Connect:Express allocates the file if it is set to do file allocation.
The beginning of reception user exit or the application server, if any, is given control and can process file
allocation, if the allocation rule is 3 or A.
The checkpoint record is allocated for this request and exists until the request is purged at the successful end of
transfer. When the file space is known, no checkpoint is allocated if it is less than or equal to one kilobyte. One
or more protocol messages are exchanged with the Partner for identification, data presentation, and transfer
restarting negotiations. When receiving the data, the Connect:Express TOM is informed that the transfer has
started.
Termination
At the end of transfer, one or more protocol messages are exchanged with the Partner for security reasons. The
end of reception user exit or the application server, if any, is then given control.
Being on the receiving side, the termination user exit decides if the transfer was successful. Then, the request
checkpoint record is deleted, and the file is unallocated. At this point, the file is processed by the application,
and the Partner is informed using the protocol acknowledgment command.
When Connect:Express receives notification that a transfer has successfully ended, it adds an entry in the
journal file and sends the journal record to the user with a record in the SMF file, if required. It also starts the
End of Reception command, and purges the request. Connect:Express either sends the next request to the APM
or notice to end the session. The new request can be transmission or reception, according to the protocol and
the session parameters that were negotiated.
Chapter 4 / Incoming and Outgoing Transfers 4-13
Incoming Transfers
A remote Partner can send a request of transfer to Connect:Express through a network. The incoming call is
detected by the ANM network handler and then sent to Connect:Express. The following information is
mandatory, and must be provided at connection or selection time. This information must match the symbolic
partner and file name entries in Connect:Express directories and SYS-SNA/TCP/X.25 files.
Symbolic Partner name
Symbolic Partner password
Network identification
Symbolic File name
Transfer direction
Network identification and symbolic passwords must match the Partner definition, and the transfer direction
and symbolic partner must match the file definition. The request is identified by a request number and queued
in the Request Control Table with the status set to INIT.
If Connect:Express resources are all available and the number of active sessions for the Partner has not reached
the maximum allowed, the request is assigned a transfer resource with the class found in the Partner definition.
Parameters are stored in the following locations:
SYSIN file
PARTNERS directory + SYS-SNA/TCP/X25 files
FILES directory
REQUEST fields
TABLES session, data presentation
USER EXITS
Incoming Connections
An incoming call must be identified by the link type, transfer protocol type, and symbolic Partner name. The
incoming call is detected by the ANM which identifies the link type and sends Connect:Express the network
information. Connection takes place in the TOM address space and includes the open and close session
operations. Each connection is processed by a subtask attached when the session opens, and again when the
session closes. Connect:Express can manage a number of simultaneous connections, depending on available
resources. Connect:Express creates a new request number after a transfer resource has been allocated, and then
waits for the first transfer protocol message.
4-14 Connect:Express z/OS Administration Guide
Connect:Express can identify the active protocol (PeSIT, ODETTE-FTP, ETEBAC3...) based on the
specifications of each protocol listed in the table below.
Protocol Description
PeSIT The pre-connection message carries a symbolic Partner name that is searched for in the
directory.
ODETTE-FTP The X.25 call packet must be answered with an ODETTE-FTP READY message by a server. The
ODETTE-FTP incoming call is identified through the user data field (UDF) found in the X.25
packet or the Sub address. They must match the ODTSAD and ODTUDF fields of the SYSIN file.
When Connect:Express has identified the protocol, it can determine the Partner with its symbolic name, its
network address, or a bypass Keyword.
Connect:Express looks for the symbolic Partner name or network address in the symbolic Partners directory
until a Partner definition is found with the correct protocol. The network address is controlled unless '*' is
found in the remote address field. If this address is different from the current, Connect:Express looks for the
network address complementary file (SYS-SNA/TCP/X.25), if any. If a '*' is in the list from the
DIRECTORY+SYS-SNA/TCP/X.25 REM address fields of one Partner, no input control is done for the
corresponding link type.
CONNECTION PARTNER
Connection and session operations are managed from the symbolic Partner definition. The connection user
exit, if any, is given control after the call, and receives the application parameters that Connect:Express does
not implement. It is also given control after the release of the protocol session. Paremeters used for incoming
connection are defined in the following locations.
Location Parameters
SYSIN file RQEMAX, DAPMxx, TCPORG, TCPPRT, APLPFX, ODTUDF, ODTSAD, MCH definitions
PARTNERS PARTNER NAME, TRANSFER CLASS, TYPE OF LINK, LINK TOT.-IN.-OUT., T-FLOW
directory + REGULAT., Addresses
SYS-SNA/TCP/X25
files
PARTNER
PASSWORD
line type M SX
addr.x25 111 SYSX25
luname LU SYSSNA
protocol 3 PARTNER 222,B
PARTNER 333.A - none -
MULTICHANNELS
LS
ANM A 222
X.25
X. 2 5
Applications LS
B 333
X.25
ANMAPP02 PARTNER
ANMAPP03
1
ANMAPP06
TOM X.25 111
SNA 2
Application
ANMAPP01 SNA LU
SYSIN
APLPFX=ANMAPP
ODTUDF=ODT
ODTSAD=12
MCHA MSC=A
MCHB MSC=B
MCH1
MCH2
In this example, an incoming call is detected by the ANM on an X.25 environment from the remote 222
address. No user data field (UDF) or subaddress is received as protocol identification in the call packet. For
example, UDF='ODT' is an identification from the ODETTE-FTP protocol declared in the SYSIN file. After
sending the incoming call confirm packet, Connect:Express waits for the first protocol message. For example,
if using PESIT, Connect:Express recognizes the PeSIT pre-connection message and looks for the
corresponding symbolic Partner definition in its directory.
The Partner is defined in the Connect:Express Partners directory with possible SNA, X.25, or TCP/IP links and
the corresponding address. For example, the X.25 definition points to the remote 111 X.25 address. The Partner
has two entries in SYSX25:
1. The first entry in SYSX25 points to the remote 222 X.25 address.
2. The second entry in SYSX25 points to the remote 333 X.25 address.
Connect:Express compares the network address received with the list made of the 111 X.25 address from the
directory, the 222 X.25 address from SYSX25, and the 333 X.25 address from SYSX25.
Chapter 4 / Incoming and Outgoing Transfers 4-17
Connect:Express verifies that the protocol and password match, and then verifies that the X.25 charge rule is
correct. If the partner is OK and Connect:Express resources are available, the incoming call is accepted.
LU2PROF
PASSWORD
link type T SYSSNA
luname *
protocol 3 LU2BYPAS LU2PROF
ANM
S N A 3270
Application
SYSIN
APLPFX ANMAPP
MCHA MSC=A
MCHB MSC=B
MCH1
MCH2
In this example, an incoming call is detected by the ANM, and the 3270 handler logon exit is scheduled with
CINIT queued from the remote LUPC3270 terminal.
Connect:Express creates a new request without determining the Partner name and waits for the first message.
Connect:Express must recognize that the PeSIT protocol is in use and that the symbolic Partner name is
PC3270, by looking for this in its directory.
When no entry is found, Connect:Express looks for the LU2BYPAS keyword in the SYSSNA file. This
keyword points to the symbolic Partner name LU2PROF that is taken as a 3270 Partner session profile.
Connect:Express verifies that the profile protocol and password match, and the name PC3270 is processed as
the Requestor name associated with the transfer.
4-18 Connect:Express z/OS Administration Guide
Incoming Session
Open and close session operations take place in the TOM address space after connection has been established
with the Partner. Session parameters are listed below.
Parameter Description
Identification They are Connect:Express default symbolic parameters or user-specific parameters to be passed
through user connection exit D1B2PCNX data structure.
Location Parameters
Partners directory PARTNER NAME, DPCSID ALIAS, DPCPSW ALIAS, PROT.NUMBER, PROT. TAB., ODETTE
IDENTIFICATION
The screen below shows an example of log information for an incoming session.
Incoming Selection
Selection takes place in the APM address space after the session has been established with the Partner. This is
done during the initialization and termination of transfer. Selection parameters are listed below.
Parameter Description
Identification They are Connect:Express symbolic parameters and allocation parameters from the directories or
user-specific parameters to be passed through selection and beginning of transfer exits
D1B2RUEX data structure.
Chapter 4 / Incoming and Outgoing Transfers 4-19
When a session has been established, several transfers can take place in either direction. Connect:Express
transmits transfers to the APM. Then, the APM attaches a transfer sub-task or Effector that waits for incoming
transfer requests.
Depending on the transfer protocol, the caller can establish a session to send or receive a file in either direction.
Some protocols provide read and write commands, while others provide only a write command.
Selection operations are managed from the symbolic File definition and depend on the transfer direction.
Therefore, any transfer protocol whose Partner and File identification conventions do not have 8-character
symbolic names must be interpreted by the application before the request is sent to Connect:Express.
Connect:Express provides symbolic security, which means that a File cannot be transferred with unknown
Partners. The transfer origin Partner can be different from the session origin Partner. Depending on the Partner
type, the transfer origin Partner can be controlled. The following table identfies the Partner types that can be
controlled.
Connect:Express Transfer Partner is controlled and reported in the JOURNAL REQUESTOR field.
OTHER Transfer Partner is controlled and reported in the JOURNAL REQUESTOR field.
APPLICATION Transfer Partner is not controlled, and the session Partner is set in the JOURNAL REQUESTOR
field.
The file identification can be an application structure more than eight characters long. In this case, the
Selection User exit must return a symbolic file name. The exit is called before the request is sent to
Connect:Express. Some operations are user-controlled while other operations are specific to the file
organization (VSAM, PDS, and TAPE files). The events are reported in Connect:Express SYSLOG file, as
shown below.
If an error occurs during connection or transfer, return codes are first reported to user exits, then to the
SYSLOG and SYSJNL, and finally to the TSO/ISPF interface.
Note: No record is added in the Connect:Express journal if an error occurs during selection operation before
the transfer has started.
4-20 Connect:Express z/OS Administration Guide
Incoming Transmission
Parameters used for incoming transmission are defined in the following locations.
Location Parameters
Files directory Symbolic file name, direction, presentation table number, parameters for transmission, data set
name
Initialization
When receiving the external request from the network, the application server or selection user exit is given
control to process information about transfer identification. The following information is received from the
Partner:
Physical File attributes processed by the partner (depending on protocol). Some protocols carry the file
attributes including record format, record length and file space.
When receiving the external request from the Effector, Connect:Express controls the demand which can be an
inquiry or normal demand. If it is an inquiry, then Connect:Express looks for a corresponding hold request. If it
is a normal demand, then Connect:Express controls the demand through the symbolic file name in the
directory. After all verifications are done, Connect:Express indicates that the transfer was accepted.
Connect:Express starts the Beginning of Transmission command and then sends the Effector all necessary
information, including allocation parameters, user exit names, and record processing and security conditions
found in the File Directory entry.
The Beginning of Transmission user exit or the application server is given control to manage file allocation. It
can also override information or add applicable parameters that Connect:Express does not implement.
Chapter 4 / Incoming and Outgoing Transfers 4-21
The checkpoint record is allocated for this request and exists until the request is purged at the successful end of
transfer. When the file space is carried by the current transfer protocol fields, no checkpoint is allocated if it is
less than or equal to one kilobyte.
One or more protocol messages are exchanged with the Partner for identification, data presentation, and
transfer restarting negotiations. When Connect:Express is ready to send the data, it is informed that the transfer
has started.
Termination
At the end of transfer, one or more protocol messages are exchanged with the Partner for security reasons. At
the end of the protocol acknowledgment, the End of Transmission user exit or the application server, if any, is
given control. At this point, the transfer has been accepted by the receiver and the file was sent to the receiving
application. Any error detected by the sender in the termination exit is not indicated to the partner. The request
checkpoint record is deleted, and the file is unallocated. Then, Connect:Express is informed of the transfer end.
When receiving notification that the transfer ended, Connect:Express adds an entry in its journal file and sends
you the journal record. Connect:Express also adds a record in the SMF file if required, starts the End of
Transmission command, purges the request, and then sends the effector the current request number. The
effector waits for the session close command or the next transfer selection.
Incoming Reception
Parameters used for incoming reception are defined in the following locations:
Location Parameters
Files directory Symbolic file name, direction, presentation table number, parameters for transmission, data set
name
Initialization
When receiving the external request from the network, the application server or selection user exit is given
control to process information about transfer identification. The following information is received from a
Partner.
Information Description
Physical File attributes processed by Connect:Express or the user (depending on protocol). Some
protocols carry file attributes like record format, record length and file space. In this case, these
allocation parameters are not mandatory in the file definition for reception. If the protocol doesn’t
provide these parameters, then they are mandatory unless the file is pre-allocated.
4-22 Connect:Express z/OS Administration Guide
When receiving the external request from the effector, Connect:Express controls the symbolic file name in the
directory. If Connect:Express is set to do the file allocation, it is done at this time, then Connect:Express starts
the Beginning of Reception command. After all verification has been done, Connect:Express notifies you that
the transfer was accepted and sends the effector all necessary information, including user exit names, and
record processing and security conditions found in the file directory entry.
The beginning of reception user exit or the application server, if any, is given control and can process file
allocation if the allocation rule is 3 or A.
The checkpoint record is allocated for this request and exists until the request is purged at the successful end of
transfer. One or more protocol messages are exchanged with the Partner for identification, data presentation
and transfer restarting negotiations. When data is received, Connect:Express is informed that the transfer has
started.
Termination
At the end of transfer, one or more protocol messages are exchanged with the Partner for security reasons. The
end of reception user exit or the application server, if any, is then given control. Being on the receiving side, the
termination user exit decides if the transfer was successful. Then, the request checkpoint record is deleted, and
the file is deallocated. At this point, the file will be processed by the application, and the partner is informed
with the last protocol acknowledgment command. Then, Connect:Express receives the message that the
transfer ended.
When receiving information that the transfer ended successfully, Connect:Express adds an entry in the journal
file and sends you the journal record. Then Connect:Express adds a record in the SMF file if required, starts
the End of Reception command, purges the request, and sends the effector the current request number. The
effector waits for the session close command or the next transfer selection.
Data Exchange
During connection and selection negotiations, Partners have previously agreed about the following transfer
conditions:
Network protocol message length
CRC activation
Synchronization (size and window)
Compression
Connect:Express has set up the local environment from its parameters. This includes initializing record
processing, like selecting records to transfer and configuring ASCII-EBCDIC transcription. Connect:Express
also allocates and opens the file to transfer and the request checkpoint file.
The data exchange process is performed in the APM address space and includes the checkpoint process. During
this process, the transmitter sends synchronization points, and the receiver acknowledges the synchronization
points. The synchronization parameters indicate the size or amount of data for one point, and the window
indicates the number of synchronization points to send before waiting for an acknowledgement.
Synchronization points enable you to restart a transfer at a certain point if a failure occurs during the transfer. In
this case, the receiver decides which synchronization point to use to restart the transfer. The transmitter is
allowed to send as many synchronization points as defined in the synchronization window. The current window
table contains active synchronization points that the receiver did not acknowledge. When the window is full,
the transmitter waits for the next ackowledgment from the receiver. Each time the transmitter receives an
acknowledgment from the receiver, it updates the window table.
Transfer protocols process logical records. These logical records are blocked into physical records on disk and
into network messages. Connect:Express must perform different actions depending on the transfer direction.
Chapter 4 / Incoming and Outgoing Transfers 4-23
Transmission
During transmission, Connect:Express reads physical blocks from disk and extracts logical records, makes any
necessary changes, and concatenates logical records into the current protocol message before sending it to the
network. Transmission goes through the following process.
Connect:Express, or a private I/O exit, reads one physical block, and then it sends every logical record to
record processing user exit1, exit2, and exit3. The logical record is compressed and concatenated into the
protocol message to be sent. When the protocol message buffer is full, or the synchronization point is reached,
Connect:Express sends the data to the partner after performing the CRC algorithm, if active. If the
synchronization point is reached, the synchronization point context is added to the window table and a
synchronization message is sent. The current window table, with all active synchronization points, is saved into
the request checkpoint file.
Acknowledgment of one synchronization point causes the APM to update the window table and save it to the
request checkpoint file. Then, the APM informs the Connect:Express monitor (TOM) of the progression of the
transfer so it can update the request table entry.
Note: When the record format (RECFM) is Undefined (U) or Variable Spanned (VS, VBS), one physical
block is considered one logical record.
When the HPO option is used in the T1B2Pxx presentation table, the file is transferred in block mode
regardless of the record format. One physical block is considered one logical record.
Reception
During reception, Connect:Express extracts logical records from protocol messages received from the network,
makes any necessary changes, and concatenates them into physical blocks before writing them to disk.
Reception goes through the following process.
Connect:Express receives one protocol message, and then decompresses every logical record and sends it to
record processing user exit3, exit2, and exit1. The record is then concatenated into the current physical block.
When the I/O buffer is full, Connect:Express or a private I/O exit writes the physical block on disk. When
receiving a synchronization point, Connect:Express saves all counts and pointers needed to restart the transfer
in the request checkpoint file. Then, the APM informs the Connect:Express monitor (TOM) of the progression
of the transfer so it can update the request table entry.
Note: If the HPO option is used, the record received is considered a physical block. The blocking factor
defined locally is used if it is different from the remote's blocking factor. The block received is
restructured into the local block structure.
Translating Data
When transferring data with ASCII computers, you can use EBCDIC to ASCII translation when transmitting
and ASCII to EBCDIC translation when receiving. Translation is done by a middle of transfer user exit
declared in the presentation table T1B2PP05. You activate Connect:Express standard translation by entering
number 05 in the presentation protocol field of the Connect:Express Files directory.
The transfer protocol can carry a data type field, but no negotiation of data type is done by the Connect:Express
standard L1APM050 translation user exit. When you enter 05 in the Presentation Protocol field, the data is
translated based on the transfer direction. When you want specific translation tables or processing, you must
write your own exit and use one of the free Presentation Tables (09 to 24). The translation L1APM050 source
module is provided as an example in the *SAMPLIB* (EX£APM50).
4-24 Connect:Express z/OS Administration Guide
Chapter 5
This chapter discusses the PeSIT and ODETTE-FTP protocols. It describes how each parameter is used, how
files are exchanged with Partners, and how information is verified. The relationship between internal events
and external events is also discussed.
T1B2PS31 Standard PeSIT D one way p99 length = 64 characters not used
Note: T1B2PS31 is mandatory for connections with non-Connect:Express partners using the PeSIT-D
protocol.
5-2 Connect:Express z/OS Administration Guide
PeSIT Commands
PeSIT commands and parameters are identified by a hexadecimal structure in the format (code, length). This
makes it possible to compress parameters when sending data. If a parameter is not entered, default values are
used. The general structure of a PeSIT command is shown below.
The length of the command is 11 characters (hexadecimal), the command identifier is 4020, and org and dest
values are set by partners to identify some internal channel. For Connect:Express, the APM number + the
effector number are part of this channel number. The parameter in the first position is P03, which is 4
characters long, and has a value of ‘A123’ which is ASCII coded. The next parameter is P04, which is 07
characters long, and has the value ‘B123456.’
PeSIT-D’ T1B2PS32 both 2, L=254 PDS, attributes, VSAM, DSN &EXTLAB C:X
(&EXTDSN, &USRVAR), &EXTDAT,
&EXTREQ
† or later
The pre-connection message follows the PeSIT standard but has a non-PeSIT format. It is used by computers to
identify each other. The message consists of the following 3 eight-character EBCDIC fields.
Field Description
Connection
Partner definition
SYSSNA,
SYSX25,
SYSTCP ---------→ Network connection
Selection
FILE definition and Transfer Request
Request extension:
ORIGIN/DESTINATION (> P3, P4, P61, P62)
REMOTE DSN (>P99)
APPLICATION file identification (→ P11, P12, P51, P61, P62, P37 with API=U: form)
selection user exit:
U0xORIGN/U0xDESTN
U0xFTYPE/U0xFNAME/U0xFDATE
U05BANKN/U05CUSTM ---------→ CREATE/SELECT P3, P4, P11, P12, P51, P61, P62, P37, P99
The next two figures show the parameters that are received when a remote partner is connecting to you, and the
PeSIT message and field where they are picked up. It also shows which internal definition is used for
comparison before accepting the transfer.
Connection
←--------- Network connection (X25, SNA, TCP/IP)
Waiting for first message
DIRECTORY ←--------- PRE-CONNECTION (PeSIT,’id’,’psw’)
SYSSNA
SYSTCP
SYSX25
’id’ from the pre-connection message is looked for in the DIRECTORY
if found ’psw’ is controlled
Network identification is controlled unless
’*’ is given in the DIRECTORY,SYSX25, SYSSNA or SYSTCP
list of identification.
SYSX25 : used for X25 network connections
SYSTCP : used for TCP/IP network connections
SYSSNA : used for SNA network connections
contain:
- the list of possible network addresses for ’id’, or ’*’
- the PARTNER profile to be taken when ’id’ is not
found in the DIRECTORY for
X25 PAD connections
SNA TED3270 connections
.--------- Connect P4 P3
Connection user exit:
C0xORIGN/C0xDESTN: (< P3 P4)
CNXPARTN:(< P3) can be replaced by a Partner profile
DPCSID or ALIAS: (< P4) must match
DIRECTORY : (<P3) must be a symbolic name unless the user exit
translates the application P3 to a PARTNER profile set in CNXPARTN.
P3 must be the same as in Pre-connection message
unless the current PARTNER TYPE is neither
’ TOM ’ nor ’OTHER’.
Chapter 5 / PeSIT and ODETTE-FTP Protocols 5-5
Selection
Definition of the transfer REQUESTOR:
The default is the connection PARTNER
If the partner type is TOM or OTHER,
a new PARTNER can be received
as the transfer requestor.
If the partner type is A
the connection PARTNER is kept
as the REQUESTOR.
←--------- CREATE/SELECT P3 P4 P11 P12 P37 P51 P61 P62 P99
Selection user exit: D1B2RUEX
UEXPART = CNXPARTN
UEXDDNM (< P12)
U0xORIGN/U0xDESTN (<P3, P4)
U0xFTYPE/U0xFNAME/U0xFDATE (<P11, P12, P51)
U05BANKN/U05CUSTM (<P61, P62)
U05FLABL (< P37)
U05FUSDF (< P99)
DIRECTORIES: (<P12) must be a symbolic name unless the user exit
translates the application p12 to a FILE profile set in UEXDDNM.
P3 can be different from the connection P3.
If PARTNER TYPE is TOM or OTHER
P3 must be a PARTNER identification found in the
directory unless the transferring PARTNER of the
FILE is $$API$$.
JOURNAL RECORD written at end of transfer OK or not OK
after it has been accepted by Connect:Express :
Z45REQID = U0xORIGN (origin of transfer) for ’ TOM ’ or ’OTHER’
Z45REQID = UEXPARTN (connection) for type = ’APPLICATION’
Z45PARTN = UEXPARTN (connection)
Z45TAPID = ORIGIN/DESTINATION/FILE TYPE/FILE NAME/FILE DATE
Z45RTDSN = from U05FUSDF (P99)
Event Description
The tables in this section describe operations on the network, Connect:Express, and the user interface. You can
use the following 3 levels to analyze events. The table below describes each level.
Level Description
USER actions USER messages and internal traces used for analysis
USER EXIT D1B2RUEX SEL,A You can initiate protocol fields and
FILE and D1B2RUEX IEX,I allocate file (UEXALREC,
checkpoint U03,5.FRFMT, U03,5.SPTYP,
ALLOCATION U03,5.FKBYT expected).
R-CREATE USER EXIT D1B2RUEX TEX,F For information PRC=yyxx and LOG
X'C030' TRANSFER D1B2RUEX SEL,F deallocation. RCT (error sel.)
REJECTED Selection retry is activated or JOURNAL
DEALLOCATION request is disabled.
DELETE checkpoint
R-OPEN USER EXIT D1B2RUEX TEX,F For information PRC=yyxx and LOG
X'C033' ERROR D1B2RUEX SEL,F deallocation RCT (error sel.)
SELECTION JOURNAL
DEALLOCATION
DELETE checkpoint
R-WRITE USER EXIT D1B2RUEX TEX,F For information PRC=yyxx and LOG
X'C036' ERROR D1B2RUEX SEL,F deallocation RCT (error sel.)
SELECTION JOURNAL
DEALLOCATION
DELETE checkpoint
A-CLOSE
X'C034'
RELEASE
X'4023'
USER EXIT
FILE and
checkpoint
ALLOCATION
R-OPEN USER EXIT D1B2RUEX TEX,F For information PRC=yyxx and LOG
X'C033' ERROR D1B2RUEX SEL,F deallocation. RCT (error sel.)
SELECTION Send restart point. JOURNAL
DEALLOCATION
DELETE checkpoint
R-READ USER EXIT D1B2RUEX TEX,F For information PRC=yyxx and SYSLOG
X'C035' ERROR D1B2RUEX SEL,F deallocation RCT (error sel.)
SELECTION JOURNAL
DEALLOCATION
DELETE checkpoint
A-READ
X'C035'
First data USER EXIT D1B2RPEX PEX,B Initiate begin of transfer LOG
TRANSFER (open) RCT (started)
STARTED
Data Process I/O buffer D1B2RPEX PEX,M Uncompress, pass to user, fill buffer,
USER EXIT + record write until synch received
RELEASE
X'4023'
Network cut USER EXIT D1B2PCNX CNX,F Major resource (Connect:Express, SYSLOG
CONNECTION PCT, FCT) inactive
REJECTED
NAK0 USER EXIT D1B2PCNX CNX,F PeSIT LOGON message rejected LOG
CONNECTION TRC=100x
REJECTED x= 1: Header, 2: partner or 3:
password.
CREATE USER EXIT D1B2RUEX SEL,A You are passed protocol fields that
X'C011' identify the transfer and return to
Connect:Express the files symbolic
name to be processed.
R-CREATE USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C030' TRANSFER D1B2RUEX SEL,F deallocation
REJECTED Transfer context is cleared
DELETE data set and
check point
PURGE request
R-OPEN USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C033' ERROR D1B2RUEX SEL,F deallocation
SELECTION Transfer context is cleared
R-WRITE USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C036' ERROR D1B2RUEX SEL,F deallocation
SELECTION Transfer context is cleared
First data USER EXIT D1B2RPEX PEX,B Initiate begin of transfer LOG
TRANSFER (open) RCT (started)
STARTED
Data Process I/O buffer D1B2RPEX PEX,M Uncompress, pass to user, fill buffer,
USER EXIT + record write until synch received
A-CLOSE
X'C034'
Chapter 5 / PeSIT and ODETTE-FTP Protocols 5-15
A-DESELECT TRANSFER ENDED Wait for next transfer or end session. LOG
X'C032' PURGE request JOURNAL
Delete Checkpoint SMF
Transfer context is cleared. RCT purged
If any error occurs at TRANS-END or RCT (interr.)
CLOSE, the transfer is interrupted.
Network cut USER EXIT D1B2PCNX CNX,F Major resource (Connect:Express, LOG
CONNECTION PCT, FCT) inactive
REJECTED
5-16 Connect:Express z/OS Administration Guide
NAK0 USER EXIT D1B2PCNX CNX,F PeSIT LOGON message rejected LOG
CONNECTION TRC=100x
REJECTED x= 1: Header, 2: partner or 3:
password.
SELECT USER EXIT D1B2RUEX SEL,A You are passed protocol fields that
X'C012' identify the transfer and return to
Connect:Express the files symbolic
name to be processed.
R-SELECT USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C031' TRANSFER D1B2RUEX SEL,F deallocation
REJECTED Transfer context is cleared
DELETE checkpoint
PURGE request
R-OPEN USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C033' ERROR D1B2RUEX SEL,F deallocation JOURNAL
SELECTION
DELETE checkpoint
PURGE request Transfer content is cleared.
R-READ USER EXIT D1B2RUEX TEX,F For information TRC=xxxx and LOG
X'C035' ERROR D1B2RUEX SEL,F deallocation JOURNAL
SELECTION
DELETE checkpoint
PURGE request Transfer context is cleared.
A-READ
X'C035'
READ record D1B2RPEX PEX,M Read, pass to user, compress fill buffer
USER EXIT + record and send until synch reached
A-CLOSE
X'C034'
RELEASE
X'4023'
p(8) N/A
p(10) N/A
p(24) N/A
5-22 Connect:Express z/OS Administration Guide
Selection p(25),2 SPBUFLNG,2 In the T1B2PS3x and 5x tables. Buffer length for
STDMSG= data FPDU's. The ANM buffer length parameters
MAXEXT= set in the SYSIN file fit within the protocol
message length.
Selection p(33),1 N/A File organization. not used (files transferred are
always declared sequential).
p(35) N/A
p(36) N/A
Selection p(37),80 U03FLABL Data set name (IBM z/OS syntax or not) from
U05FLABL user or application data.
&EXTLAB Outgoing: If request extension API parameter is
API=U: used API=U:user-data then
p(37)='user-data'
Default is the request data set name.
Selection p(99) C05FUSDF Protocol and field used with AD HOC, PDS, and
U05FUSDF VSAM files exchanging specific information.
API=P: Outgoing
&EXTDAT If partner types is ‘other,’ the remote DSN
&EXTDSN parameter is moved to P(99).
&EXTNUMB Incoming
&MBR Received by &Pi99 if the partner type is other,
&x and by the other keywords if the partner type is
&USRVAR1 Connect:Express.
&USRVAR2
&Pi99
PeSIT P(32) = rrrr LRECL = rrrr; BLOCKSIZE optimized (unless SMS is used)
PeSIT P(42) = ssss Primary space = blocks equivalent to ssss bytes + 10%, no secondary space, unless SMS is
used.
PeSIT P(32) = rrrr LRECL = rrrr+4; BLOCKSIZE optimized (unless SMS is used)
PeSIT P(42) = ssss Primary space = blocks equivalent to ssss bytes + 10%, secondary = 20%, unless SMS is used
When receiving a sequential file with the DCB entered in the directory, the following PeSIT fields are used for
file allocation.
PeSIT P(31) = X‘00’ RECFM = Any value if RECFMT=N in the SYSIN file (no control) or RECFM = F,FB,FBA only
PeSIT P(42) = ssss P(42) omitted. If the space defined is not large enough, abend D37 can occur
PeSIT P(31) = X‘80’ RECFM = Any value if RECFMT=N in the SYSIN file (no control) or RECFM = V,VB,VBA,VBS,U
only
PeSIT P(32) = rrrr LRECL = any if RECFMT=N in the SYSIN file (no control) or rrrr+4 only; BLOCKSIZE compatible.
PeSIT P(42) = ssss P(42) omitted. If the space defined is not large enough, abend D37 can occur.
Table Description
T1B2PS20 This table is reserved and used for the following: (no CRC)
• Both direction sessions
• Compression
• No CRC integrity control
Chapter 5 / PeSIT and ODETTE-FTP Protocols 5-27
Table Description
T1B2PS21 This table is reserved and used for the CRC profile:
• Both direction sessions
• Compression
• CRC integrity control (asynchronous sessions – special logic option)
One feature of the ODETTE-FTP protocol is that only the transmission command is defined, and sending the
partner a Token initiates file reception.
When an ODETTE-FTP session is initiated, it cannot be terminated without giving your partner the
opportunity to send one or more files. Therefore, an active session can only be closed just after the token is
received or later using the ABORT command. You can make a transfer request with the file name $Connect to
call a partner and receive a file without sending anything. The $Connect profile must be defined in the file
directory.
Note: All ODETTE session tables that ship with Connect:Express are defined for ODETTE level 1.2, version
F1. If you need to use ODETTE level 1.3, update one of the available tables and save it in your user
library.
TOKEN →
← TOKEN
A request sent to Connect:Express to transfer with an ODETTE-FTP Partner can be any of the following
transfer types:
TRANSMIT Connect:Express calls the Partner, transmits the File and gives the Partner the token so he can
NORMAL, acknowledge (end to end) the transfer and transmit something, or end the session.
transmit/receive When several transfers are found waiting for transmission in the Connect:Express request table,
session the token is passed to the Partner when no more transfer is waiting for selection, unless the
Partner asks for it.
TRANSMIT Connect:Express calls the Partner, transmits the File and gives the Partner the token so he can
NORMAL, transmit acknowledge (end to end) the transfer, or end the session.
session When several transfers are found waiting for transmission in the Connect:Express request table,
the token is passed to the Partner when no more transfers are waiting for selection, unless the
Partner asks for it.
Use this type for calling to send, without receiving.
TRANSMIT HELD, Use this type to let the Partner come and receive files either without transmitting anything or
transmit or transmitting his own files in the same session.
transmit/receive Transmission of the file is initiated when the Partner calls and gives Connect:Express the token.
session
$Connect Use this type to call the Partner and receive files, if you have no file to send. Connect:Express
calls the partner and gives him the token immediately so that the partner can send his files.
Note: A $Connect symbolic file must be defined in the directory.
ODETTE-FTP Commands
ODETTE-FTP commands are identified by ASCII codes and their structures are fixed and composed of fixed
length ASCII fields. The general structure of an ODETTE-FTP command is shown below.
p5p6
|cmd|p1 | p2 | p3 | p4 | | |p7 |Cr ...
| X | 1 |INITIATOR ID CODE |PASSWORD|4000|B|Y|012|cr
. . . . . . . .
X = SSID. . . . . . .
p1 = Version number = 1 . . . . .
. . . . . .
p2 = ODETTE identification . . . . .
p3 = Password . . . .
. . . .
p4 = Buffer . .
. . .
p5 = Both direction
. .
p6 = Compression
.
p7 = synchronization credit
Cr = Carriage Return
Chapter 5 / PeSIT and ODETTE-FTP Protocols 5-29
Network Identification
One feature of the ODETTE-FTP connection process is the 'ODETTE LISTENER SPEAKING' response to a
network inbound call. If ODETTE-FTP is used over X25, Connect:Express must recognize an ODETTE-FTP
incoming call by the X25 USER DATA FIELD or by a special sub-address. These two parameters can be
declared in the SYSIN fields, ODTUDF and ODTSAD. If ODETTE-FTP is used over TCP/IP the
ODETTE-FTP listener must be started, with a special Port number. This parameter can be declared in the
SYSIN field TCPPRO.
Partner Identification
Another feature of the ODETTE-FTP protocol is the use of specific identification. For example, an Odette
partner definition consists of a symbolic identification that can be associated with an Odette identification. The
protocol number 2 in the symbolic definition indicates that the partner is an Odette partner. In this case, the
following screen is displayed showing the ODETTE-FTP specific identification fields in the Directory.
PESIT DATA :
--------------------
APPLICATION TYPE ... : 1, 2, 3, 4
APPLICATION NUMBER . : NUMERIC (00001:65535)
ODETTE DATA :
--------------------
This screen is common to both PeSIT and Odette partners. You will be prompted for the Odette identification
definition, which can be structured in a standard way or used as a single 25-character string. If you select the
field, a structured screen is displayed to help you conform to the Odette standard. If no Odette identification is
provided, the symbolic partner name is used as the first eight characters of the 25-character string.
Both the remote partner or local partner must be identified in the Connect:Express directory. The local partner
is determined from either the DPCSID field in the SYSIN file (default), or in the Alias field from the remote
partner definition. This local symbolic name must be defined in the directory to associate the corresponding
local Odette identification. This partner identification is used for connection (SSID command).
The following screen shows the ODETTE-FTP local or remote Partner identification.
PARTNER TYPE : T
SESSION PROT.NUM.-T. : 2 : 0 RSA-DES SECURITY T. : -
AUTOMATIC RESTART : NO
Transfer Identification
When the connection has been established, the transfer selection takes place and the file identification is
composed of the following structure:
The origin and destination values are set to the connection identification that you just defined. They can be
changed by using the API field of the Extended transfer request. The following table identifies the different
ways that you can provide identification using the ODETTE protocol.
Identification Description
SYMBOLIC from Symbolic identification from DPCSID/ALIAS (local) and Partner from DIRECTORY/REQUEST
DIRECTORY/REQU fields are the default identification.
EST/SYSIN fields
ODETTE from A specific panel is chained to a standard symbolic Partner definition when the protocol is
DIRECTORY ODETTE (=2).
If any ODETTE-FTP definition is found for the current symbolic Partner name in the directory,
either at incoming call control or outgoing call processing, or for the remote received or local sent,
it will be processed in place of the symbolic name. The local DPCSID/ALIAS identification can
have their own entry in the Partner DIRECTORY to define the local ODETTE-FTP file transfer
with a specific identification instead of a symbolic name.
ODETTE from Specific D1B2PCNX/D1B2RUEX 'U02' application fields are passed both ways following the
USER EXIT general identification by the user interface provided by Connect:Express.
ODETTE from The API field can be set to Origin + Destination + file name + file date. The file name can be set to
REQUEST the data set name using the keyword $DSN$. This field has 26 characters.
The following screen shows the API formatting screen for ODETTE.
ORIGIN:
INTERNATIONAL CODE... ---> 0001 NUMERIC (0001:9999)
ORGANIZATION CODE.... ---> MY ORGANIZATION ALPHANUM
SUB ADDRESS.......... ---> 000001 NUMERIC (000000:999999)
DESTINATION:
INTERNATIONAL CODE... ---> 0001 NUMERIC (0001:9999)
ORGANIZATION CODE.... ---> REMOTE ORG ALPHANUM
SUB ADDRESS.......... ---> 000001 NUMERIC (000000:999999)
(1) If the Keyword $DSN$ is typed in this field, it is replaced by the physical name of the file which has 26
characters. This parameter is sent in the ODETTE file identification field.
5-32 Connect:Express z/OS Administration Guide
(2) If the keyword $DATE$ is typed in this field, it is replaced by the current beginning of transfer date.
(3) If the keyword $TIME$ is typed in this field, it is replaced by the current beginning of transfer time.
The EERP symbolic file name must be declared in the files directory, with allocation rule = A as shown in the
following screen. This enables you to make a request with no data set name.
command sent, and controlled from the command received. The example below shows how Connect:Express
processes identification for an outgoing call with the ODETTE-FTP protocol.
Pre-connection
X25 remote address and user data field or sub address are set from the DIRECTORY
Connection
DPCSID or ALIAS
or
ODETTE IDENTIFICATION from DPCSID/ALIAS entry in the DIRECTORY if any
or
connection user exit:
C02ORIGN → SSID Command sent
REQUEST
or
ODETTE IDENTIFICATION from PARTNER entry in DIRECTORY if any
or
connection user exit:
C02DESTN ← SSID Command Review and controlled
Selection
FILE
Request extension:
ORIGIN/DESTINATION
APPLICATION file Identification (API)
Directory:
ODETTE fields
selection user exit:
U02ORIGN/U02DESTN
U02FLABL → SFID Command Sent.
The following screen shows how Connect:Express processes identification for an incoming call with the
ODETTE-FTP protocol.
Pre-connection
Connection
DIRECTORY:
DPCSID/ALIAS
or
ODETTE IDENTIFICATION from DPCSID/ALIAS entry in DIRECTORY if any
or
Connection user exit:
C02DESTN → SSID command sent
Selection
Z45REQID = PARTNER
Z45PARTN = PARTNER/CNXPARTN
Z45TAPID = ORIGIN/DESTINATION/FILE/DATE
5-36 Connect:Express z/OS Administration Guide
Event Description
The tables in this section describe operations on the network, Connect:Express, and the user interface. You can
use the following 3 levels to analyze events. The table below describes each level.
Level Description
USER actions USER messages and internal traces used for analysis
ODETTE-FTP Caller
ODETTE-FTP caller events occur when you initiate a connection with a remote computer. The following table
shows the relationship between what happens during an ODETTE session, what is shown in the
Connect:Express environment, and how you can access information. It also includes a description of the
process, and reports that you can view.
ODETTE-FTP Caller
USER EXIT D1B2PCNX CNX,C X.25 Network identification. Protocol RCT (init.)
connection application parameters are
passed to Connect:Express.
X.25 Network NOK D1B2PCNX CNX,F Call retry is activated or partner is SYSLOG
USER EXIT disabled. RCT (waiting)
CONNECTION The T1B2PCOD table is looked at for a JOURNAL
REJECTED PRC Match.
PRC=310
Chapter 5 / PeSIT and ODETTE-FTP Protocols 5-37
END USER EXIT D1B2PCNX CNX,F Call retry is activated or partner is LOG
SESSION CONNECTION disabled. RCT (waiting)
ESID X'46' REJECTED JOURNAL
PRC=00xx
END USER EXIT D1B2PCNX CNX,F Call retry is activated or partner is LOG
SESSION CONNECTION disabled. RCT (waiting)
ESID X'46' REJECTED JOURNAL
PRC=00xx
ODETTE-FTP Sender
ODETTE-FTP sender events occur when you initiate a write access on a remote computer. The following table
shows the relationship between what happens during an ODETTE session, what is shown in the
Connect:Express environment, and how you can access information. It also includes a description of the
process, and reports that you can view.
ODETTE-FTP Sender
USER EXIT D1B2RUEX SEL,A You can initiate protocol fields and
FILE and D1B2RUEX IEX,I allocate the file.
checkpoint
ALLOCATION
NEGATIVE USER EXIT D1B2RUEX TEX,F For information PRC=10xx and LOG
ANSWER TRANSFER D1B2RUEX SEL,F deallocation. RCT (error sel.)
SFNA X'33' REJECTED Selection retry is activated or request JOURNAL
DEALLOCATION is disabled. The T1B2PCOD table is
DELETE checkpoint looked at for a PRC Match.
ODETTE-FTP Called
ODETTE-FTP called events occur when you accept a connection from a remote computer. The following table
shows the relationship between what happens during an ODETTE session, what is shown in the
Connect:Express environment, and how you can access information. It also includes a description of the
process, and reports that you can view.
ODETTE-FTP Called
lib. USER EXIT D1B2PCNX CNX,F Connect:Express resources are not up: LOG:
Connect:Express, RCT, PCT, FCT
inactive
Partner not found or found not OK
ODETTE-FTP Receiver
ODETTE-FTP receiver events occur when you accept a write access from a remote computer. The following
table shows the relationship between what happens during an ODETTE session, what is shown in the
Connect:Express environment, and how you can access information. It also includes a description of the
process, and reports that you can view.
ODETTE-FTP Receiver
SFID USER EXIT D1B2RUEX SEL,A The user receives protocol fields,
SFID X'48' identifies the transfer, and sends
Connect:Express the symbolic file name
to be processed.
NEGATIVE USER EXIT D1B2RUEX TEX,F The user exit receives the TRC=xxxx LOG
ANSWER TRANSFER D1B2RUEX SEL,F and can perform deallocation. JOURNAL
SFNA X'33' REJECTED Connect:Express clears the transfer
DELETE data set and context.
check point
PURGE request
First data USER EXIT D1B2RPEX PEX,B Initiate beginning of transfer. LOG
TRANSFER (open) RCT (started)
STARTED
Process I/O buffer D1B2RPEX PEX,M Uncompress, pass to user, fill buffer,
USER EXIT + record write until synch reached.
connection p1,25 Incoming: Session partner name. This name is a default symbolic name Symbolic:
PARTNER,8 or an ODETTE-FTP specific identification. LOG
(specific) Remote: RCT
C02ORIGN Partner is controlled from his symbolic name (find in JOURNAL
C02DESTN DIRECTORY if incoming, given at request time if outgoing)
Outgoing: or specific name if given in Connect:Express DIRECTORY
DPCSID,8 or C02ORIGN (incoming) or C02DESTN (outgoing) when
ALIAS,8 given by USER EXIT.
(specific) Local:
C02ORIGN Partner name sent is the symbolic name (DPCSID or
C02DESTN ALIAS) or specific name if given in Connect:Express
DIRECTORY or C02ORIGN (outgoing) or C02DESTN
(incoming) when given by USER EXIT.
connection p2,8 Incoming: Password is verified in the Partner directory. It is sent from the
PASSWORD,8 SYSIN DPCSID= or the Partner directory alias.
Outgoing:
DPCPSW
(ALIAS,8)
connection p3,5 SPBUFLNG,5 Session exchange buffer length. In the T1B2PS2x tables.
STDMSG= The ANM buffer length parameters from the SYSIN file must
MAXEXT= fit within the protocol’s message length.
selection p6,26 FILE Transfer file name. The symbolic file name (8 characters) can LOG
Symbolic be replaced by an application name (26 characters) which is RCT
API set in the API field or the 26 character data set name using JOURNAL
U02FLABL the $DSN$ keyword in the API name field. SMF
The REMOTE DSN field can be used with symbolic
keywords.
Note: The online help provides a list of available symbolic
variables. Press <PF1> and type VS in the Option to display
this list.
selection p26,1 File DCB File record format. From the file DCB INPUT, or passed to
F, V, U, T DIRECTORY Dynalloc output. Controlled if given in the file DIRECTORY on
reception and if the SYSIN URECFMT parameter is yes.
ODETTE-FTP Description
Format
Fixed Blocking is processed by Connect:Express automatically (FB) or from the DCB given in the FILE
DIRECTORY fields (F, FB, FBA, FBS, ... ).
Variable Blocking is processed by Connect:Express automatically (VB) or from the DCB given in the FILE
DIRECTORY fields (V, VB, VBS, VBA, U...). The logical value of protocol LRECL (P11) is added
RDW and BDW bytes.
Undefined This has nothing to do with the IBM z/OS Undefined format. An ODETTE-FTP undefined format
file is one single record the length of which is the total length of the file. Connect:Express never
sends undefined format files, but can receive such files. The file is processed as a Variable file (V
or U); the record length is that of the file allocated. U is the default with LRECL= 32760. The DCB
can be given in the directory with any variable format (V,VB,VBS,VBA, U...).
5-44 Connect:Express z/OS Administration Guide
ODETTE-FTP Description
Format
Text This is unknown in an IBM z/OS environment. An ODETTE-FTP text format file is a variable
length record file in which any record is terminated by CRLF (Carriage Return + Line Feed) bytes.
Text file processing is conditioned by the TYPE OF DATA parameter defined in the presentation
table (Table T1B2PP05 is an example provided).
The file is processed this way:
Sending a file, any format: the EBCDIC file is translated to ASCII (L1APM050), and sent as a
‘T’– Text file, with '0D0A' added at end of each record (DATA TYPE = ASCII).
Receiving a text file, any format : Both text files sent as ‘T’– Text files in the Odette parameter and
text files sent as ‘F’– Fixed or ‘V’– Variable or ‘U’– Unstructured are suppressed 0D0A (DATA
TYPE = ASCII), and translated to EBCDIC (L1APM050).
NOTE: HFS files are not supported by Connect:Express ODETTE functionality.
Odette P11 = rrrr LRECL = rrrr; BLOCKSIZE optimized (unless SMS is used)
Odette P12 = ssss Primary space = blocks equivalent to ssss bytes + 10%, no secondary space
TEXT data type (A): search for Carriage Return character and deleted. The maximum size of the
line must fit the record length. Records are padded with blanks, a null record is kept as a blank
record.
Odette P11 = rrrr LRECL = rrrr+4; BLOCKSIZE optimized (unless SMS is used)
Odette P12 = ssss Primary space = blocks equivalent to ssss bytes + 10%, secondary = 20%
TEXT data type (A): search for Carriage Return character, it is deleted. The maximum size of the
line must fit the record length. Records are not padded, a null record is kept as a null record.
When receiving a sequential file with the DCB entered in the directory, the following ODETTE fields are used
for file allocation.
Odette P26 = F RECFM = Any value if RECFMT=N (no control) or RECFM = F,FB,FBA only.
Odette P12 = ssss P12 omitted. If the space defined is not large enough, abend D37 can occur.
TEXT data type (A): search for Carriage Return character, it is deleted. The maximum size of the
line must fit the record length. Records are not padded, a null record is kept as a blank record.
Odette P26 = V RECFM = Any value if RECFMT=N in the SYSIN file (no control) or RECFM = V,VB,VBA,VBS,U
only.
Odette P11 = rrrr LRECL = any if LRECLT=N in the SYSIN file (no control) or rrrr+4 only; BLOCKSIZE compatible.
Odette P12 = ssss P12 omitted. If the space defined is not large enough, abend D37 can occur.
TEXT data type (A): search for Carriage Return character, it is deleted. The maximum size of the
line must fit the record length. Records are not padded, a null record is kept as a null record if
RECFM = V*. A null record is skipped if RECFM = U.
Odette P12 = ssss Primary space = blocks equivalent to ssss bytes + 10%, secondary = 20%
The file is filled up until the last short record.
TEXT data type (A): search for Carriage Return character, it is deleted. The maximum size of the
line must fit the record length. Records are not padded, a null record is kept as a null record if
RECFM = V*. A null record is skipped if RECFM = U.
Odette P12 = ssss Primary space = blocks equivalent to ssss bytes + 10%, secondary = 20%
TEXT data type (A): search for Carriage Return character, it is deleted. The maximum size of the
line must fit the record length. Padding and null record process depends on the record format.
Troubleshooting
This chapter describes common problems that you may encounter, tools that you can use to identify the
problem, and corrective action that you can take. It also includes information about enhancing system
performance and getting help from Technical Support.
Tracking Events
You can access messages and return codes online or with a batch procedure. Online information can help you
analyze the problem, control operations, and take action quickly when there is a problem. This section
describes first-level diagnostic tools; the next section describes trace tools used for deeper investigation.
Tool Description
TOM SYSLOG file Used to track chronological events. This file tracks basic information such as file name, partner
name, date time, and request number. You can also track all the related events such as a specific
data flow, a specific link, or a recurrent return code.
APM SYSLOG file Used to track chronological events and get information about file allocation.
ANM SYSMSG file Used to track operational events such as initialization or diagnostics.
SYSPRINT file The utilities options and the API provide a SYSPRINT file in which you can find all information
related to actions made.
6-2 Connect:Express z/OS Administration Guide
Tool Description
Journal file Used to archive transfer reports. You can use the filter screen to select what may be related to
your current problem.
JES SYSOUT files Contains system messages that can help you take the appropriate corrective action.
Messages in the logging file can help you determine what happened with a transfer. Refer to chapter 4 for
detailed information about incoming and outgoing transfers, such as which Connect:Express parameters are
involved in establishing a session with a Partner. Refer to Chapter 5 for information about the relationship
between Connect:Express parameters and PeSIT or Odette protocol parameters.
Additionally, you can activate network traces or any system tracking facility. You can also use special exits to
get online information. Advanced users can install automatic control processes for alerts and statistics using the
interfaces provided by the product. For example, the Utilities package provides powerful automation tools. See
the Utilities Guide for more information about this option.
L1GFICN1 You can use this exit to track connections. It notifies you about incoming and outgoing connection
failures in the TOM SYSMSG file. This connection exit must be defined in the T1B2PCNT table
(TSO/ISPF 3.3.CNT).
L1GFICN1 You can use this exit to track transfer selection. It notifies you about incoming and outgoing
transfer selectIon failures in the SYSMSG file. This selection exit must be defined in the
T1APMSRT table (TSO/ISPF 3.3.SRT).
L1EX£AE2 You can use this exit to track transfer selection. It notifies you about the protocol parameters
received during the transfer selection in an AE2* print file. This beginning/end of transfer exit must
be defined on the file attributes 3/4 screen (TSO/ISPF 1.2), in the START EXIT, or END EXIT
fields.
The AE2* print file name consists of the effector number, the step (Init., Term.), and the status
(Init, End, Failed). AE203IEI is for a transfer done by ‘effector’ number 03, exit during Initialization
of transfer, status ‘I.’ AE205TEF is for a transfer done in ‘effector’ number 05, exit during
Termination of transfer, status ‘F’.
Activating Traces
When online information is not sufficient to analyze a problem, you may need to activate traces. This section
describes how you can track incoming connection errors only, run protocol traces, or run network traces. The
SSL Guide provide information about activating SSL and DN control traces.
Chapter 6 / Troubleshooting 6-3
To use the general trace facility, you must first activate the trace service for Connect:Express using a modify
command, as shown below.
In the example above, an unknown system made an X.25 incoming call. The calling address was 910, the
sub-address was 4, the taxation rule = 0, there is no closed user Group, no User data filed, and the first message
received appears in quotes.
Note: If you update a Partner record, you will deactivate the trace.
Then any rejected incoming calls from this partner generate a message in the SYSLOG file, as shown below.
The PDSE trace file must be allocated with the following format: RECFM = FBA LRECL = 170
The trace shows all events of one protocol session, from session initialization to session termination. The trace
file is identified from the request number or from a time stamp if the request number is unknown (this is the
case with an FTP server session).
Information is structured in XML format. It includes protocol messages, a translation of the protocol
commands, and values that Connect:Express uses during execution of the file transfer.
The trace aspect differs from one protocol to another (PeSIT, FTP, Etebac3, Odette), but Connect:Express
fields conform to a general table shown below.
6-6 Connect:Express z/OS Administration Guide
Commands to Connect:Express
Use the following command to start the ATM:
/F jobmon,S ATM
Use the following command to stop the ATM:
/F jobmon,P ATM
When Connect:Express stops, all active address spaces are stopped, including the trace manager.
Refer to the ATM SYSLOG file to know about the trace activity.
Refer to Connect:Express SYSMSG file to know about operator activity and ATM status.
The type parameter indicates if the trace must include both negotiations and data or only negotiations.
Examples:
To trace partner PARIS, only negotiations:
/F jobmon,TRACEPAR=(PARIS,DIA)
To trace all partners which name begins with 'PAR', negotiations and data:
/F jobmon,TRACEPAR=(PAR*,ALL)
The trace request is identified by a number. To disable the trace request, use the following command to
Connect:Express:
/F jobmon,TRACEOFF=n
'n' is the trace request number that Connect:Express returns after the ATM recorded the request:
JESJCLIN 1 PSRAT4 X 2
JESMSGLG JES2 2 PSRAT4 X 2
JESJCL JES2 3 PSRAT4 X 52
JESYSMSG JES2 4 PSRAT4 X 2
$INTTEXT JES2 5 PSRAT4 A 0
SYSLOG PSRAT4 104 PSRAT4 V 0
R0042562 PSRAT4 110 PSRAT4 A LOCAL 83
A9323570 PSRAT4 111 PSRAT4 A LOCAL 84
R0042601 PSRAT4 112 PSRAT4 A LOCAL 191
R0042602 PSRAT4 113 PSRAT4 A LOCAL 188
R0042604 PSRAT4 114 PSRAT4 A LOCAL 191
R0042605 PSRAT4 115 PSRAT4 A LOCAL 106
R0042607 PSRAT4 116 PSRAT4 A LOCAL 191
R0042608 PSRAT4 117 PSRAT4 A LOCAL 188
R0042610 PSRAT4 118 PSRAT4 A LOCAL 191
R0042611 PSRAT4 119 PSRAT4 A LOCAL 188
Refer to “Using Protocol Traces” on page G-1 for information on reading the ATM SYSOUT file and trace
files based on the file transfer protocol.
000048 INPUT=LINE
000049 NODE=MCH056
000050 SOURCE=GTF
000051 LUPRT=YES
000052 LSPRT=YES
000053 LDPRT=YES
000054 PRINT=YES
000055 RRSUP=NO
000056 VTPRT=YES
000057 GSPRT=YES
000058 SUMMARY=YES
000059 SDPRT=YES
000060 SSPRT=YES
000061 DTPRT=YES
000062 NEPRT=YES
000063 NPPRT=YES
000064 NTPRT=YES
000065 LUPRT=YES
000066 LONGPIU=YES
000067 READ
000068 GO
000069 QUIT
Chapter 6 / Troubleshooting 6-9
Common Problems
When setting up the transfer operations environment, you may encounter some of the common problems
described in this section. For example, connection failures can occur if you did not agree with your partner
about addresses, names and passwords. Transfer errors can occur if you did not agree with your partner about
the file to transfer, and allocation errors can occur if your local file definition was not correct.
Connection Errors
You can view incoming connection errors in the Connect:Express SYSLOG file, and you can check outgoing
connections in the Request Control table. You can also do any of the following to get more information about
connection errors:
Check the request status and TRC on the ISPF 2.1.R screens. Press <PF11> to scroll, then place your
cursor on an entry and press <ENTER> to access help.
Check the monitor SYSLOG file for network return codes and links used.
Check the drivers status on the ISPF 2.1.N screens.
Activate the tracking incoming connection error facility.
Perform a network trace.
Refer to “Incoming and Outgoing Transfers” on page 4-1 and “PeSIT and ODETTE-FTP Protocols” on
page 5-1 for more information.
6-10 Connect:Express z/OS Administration Guide
Transfer Errors
You must view incoming transfer request errors in the Connect:Express SYSLOG file. In the first step of
negotiating a transfer request, an entry is created in the Request Control table. If a problem occurs before the
transfer is started, no record is kept in the Request Control table or in the Journal file. You can check the
Request Control Table for outgoing transfers and incoming transfers after they have started. You can also do
any of the following to get information about transfer errors:
Check the request status and TRC on the ISPF 2.1.R screens. Press <PF11> to scroll, then place your
cursor on an entry and press <ENTER> to access help.
Check the monitor SYSLOG file for return codes and links used.
On the request panel 2.1.R, press <PF1> and then enter the command ‘WR’ or ‘RA’ to display the possible
reasons for the Waiting Request message.
Use the L1EX£AE2 selection exit SYSPRINT file to check for the protocol parameters received.
Perform a network trace.
Refer to Chapter 4 Incoming and Outgoing Transfers and Chapter 5 PeSIT and ODETTE-FTP Protocols for
more information.
REQUEST 00000008 00000008 ALLOCATE FAILED SPM= B 00013680 00006 000001 - - 00000080
00013680
REQUEST 00000008 00000008 ALLOCATE FAILED SMS= - - - - 00000001
REQUEST 00000008 00000008 ALLOCATE FAILED DYN= E 970C I 0000 E 0000 I 0000 S 000042CD
R90 S
REQUEST 00000008 FICTST ALLOCATE FAILED DSN=PSR$TST.GFIPSR4.D001221 Ep I
E I S REQUEST 00000008 FICTST GFIPSR4 SRC=970C TRC=2085 PRC=2204
These messages are explained in the help screen. From the TSO/ISPF interface, type OPTION ==> RC from
any screen. Then select –SRC and – TOM SYSLOG. The results display in the screen below.
-- S: DETAIL
V
_ TOM SYSLOG, 'ALLOC FAILED SPM= / SPW= / SMS= / DYN= / DSN='
You can also do any of the following to get more information about allocation errors:
Check SDSF (‘INPUT ON’) the JESmsg at the top of the SYSOUT file for « IKJ ? ? ?
allocation-messages »
Check for SMS or VAM restrictions. You can perform a job or ISPF 3.2 for this DSN disp= NEW with the
same parameters.
Activate a snapdump. You can get a DYNALLOC trace in the Monitor //SNAPDUMP file. Send the
following z/OS command to Connect:Express: « F monitor,SNAP=E » followed by: « F monitor,
SNAP=ON,12.» Then reproduce the allocation error, and keep the snapdump file.
Chapter 6 / Troubleshooting 6-11
Note: All procedures provided with installation are included in the SYSDUMP DD cards. SYSUDUMP DD
cards should not be deactivated in any of the Connect:Express address spaces. If an abnormal abend
occurs, the development team can analyze the problem. The SYSUDUMP ABEND dumps contain
data and areas about the failing program. SYSMDUMP ABEND dumps contain additional system
areas and SYSABEND ABEND dumps are the largest of the ABEND dumps and contain more system
areas.
CICS Errors
Some errors can occur when using the CICS option of Connect:Express. Most of these are caused because the
transaction stop sequence was not respected, or Connect:Express or CICS abended before a normal stop.
Type the following z/OS command: « /F monitor, $LOAD$ » then stop the monitor and CICS, and restart
both normally.
Check the T3B2ZSSN table used, and //DFHRPL and //STEPLIB.
Check the application using TSO/ISPF 2.5.
Refer to the CICS documentation for more information.
The APM sends data to the ANM using transfer protocol messages, and then the ANM sends data to the
network. The ANM receives data from the network and then sends it to the APM. The length of exchanged
messages can determine link throughput.
The length of transfer protocol messages is defined in Connect:Express session tables. The standard ANM
buffers (STDMSG) and extended ANM buffers (MAXEXT) in kilobytes are defined in the Connect:Express
SYSIN file. VTAM and TCP/IP buffer exchange capabilities are defined in the appropriate configuration files.
All of these parameters must be related.
The length of transfer protocol messages is limited by the Connect:Express session table Message parameter.
You must customize Connect:Express session tables based on your network environment. For example, you
can specify the Connect:Express session table parameters depending on the link type you are using.
Communications between Partners transmitting data is a negotiated process. Values such as the maximum
message length, synchronization values, compression, and segmentation determine the data transfer
performance within Connect:Express. As the Connect:Express administrator, you should be aware that the
following rules apply during transfer negotiation:
The smaller of two differing parameter values is the one that will be used.
You should not modify the default values for Session Protocol tables, but you can create your own tables.
Note: When you want to modify session parameters, only modify the modules described as “Available for
Customization.” Start with the last available entry, then copy the customized tables into your
USERLOADLIB (it must be APF) so that no procedure update can replace a user module. Your USER
LOADLIB must be concatenated before the procedure LOADLIB.
The protocol message must be transported through the ANM, in its STDMSG or MAXEXT buffers to the
network. Over an X25 link, the Switch Major node MAXDATA parameter and those defining VTAM-NCP
data exchange capability are considered. Refer to Appendix E, Definition of VTAM Resources for a list of
general information and examples.
should ensure that the TOM Monitor and the FTP manager execute in a performance group like a TSO address
space.
Storage Estimates
This section describes the storage requirements for different Connect:Express facilities.
Used 4346
ANM Acquired 0 0%
Used 13720
AFM Acquired 0 0%
Used 1208
ATM Acquired 0 0%
Used 704
APM Acquired 0 0%
Used 1128
Used 20824
You can associate a storage protection key, for example key 5, to the main program of Connect:Express. Then
you can restore the parameter ALLOWUSERKEYCSA to ‘N’ . The example below shows how you can set up
a protection key.
T1B2PRCT 16 + (64*RQEMAX) †
T1B2PTCT 16 + (480*RQEMAX) †
T1B2PSST 16 + (1956*NBEFF) †
T1B2PPCT 16 + (216*(NBPAR+PCTADD)) †
T1B2PFCT 16 + (216*(NBFIL+FCTADD)) †
T1B2PXCT (600*PlexServ) †
SYSX25 16 + (76*NBENTRY)
SYSSNA 16 + (52*NBENTRY)
SYSTCP 16 + (76*NBENTRY)
GENERAL USE:
HANDLERS:
GENERAL USE
TEMPORARY USE:
(PROTOCOL attached)
SYNCHRO, in kilobytes, is the synchronization parameter from the T1B2PSxy session table. MSGLG is the
network buffer length parameter from the T1B2PSxy session table in kilobytes. For example, you could have
the following situation:
APM storage for 8 effectors, 8 simultaneous files receiving.
Session table is T1B2PS52, link=SNA (SYNCHRO=64, MSGLG=4).
File (LRECL=240, BLKSIZE=24000).
No user exit executed.
Storage = APM + 8*(EFFECTOR) + 8*(PROTOCOL + RECEPTION)
= 60 + = 8*20 + = 8*(80 + (2*synchro=128 + msglg=4 + blk+lrec=24))
= 2.5 Mbytes.
For example, you should declare only 8 effectors (not 16) with large user exits in COBOL. AFM storage
estimates are discussed in the FTP Guide.
User problem
Documentation issue
If you are unable to diagnose a problem, you can contact technical support. This section will help you analyze
the problem and let you know what kind of information that you will need when you contact technical support.
Analyzing a Problem
The questions below will help you analyze a problem in Connect:Express.
Configuration files Connect:Express parameters, network parameters, system parameters, job streams.
Transfer parameters File/partner local definitions, partner software and machine. Provide hardcopies of
TSO/ISPF definitions.
6-18 Connect:Express z/OS Administration Guide
TOM SYSLOG file Tracks chronological events. From basic information such as file name, partner
name, date time, request number or anything else. You can track all the events
related for example to a specific data flow, a specific link or a recurrent return code.
TOM SYSMSG file Tracks operational events such as initialization and connection user exit messages.
APM SYSLOG file Tracks chronological events. Information are found about file allocation.
ANM SYSMSG file Tracks operational events such as initialization or exceptional diagnostics.
Any utilities and the API Provides a SYSPRINT file in which you can find all needed information. Refer to the
appropriate pages for example, P1B2PRQ2, L0B2Z20.
JOURNAL file Achieves transfer reports. You can use the filter screen to select what may be related
to your current problem. Provide hardcopies of TSO/ISPF view.
Request Control Table (RCT) Shows current status of transfers. Provide hardcopies of TSO/ISPF view.
Abend files and trace files always need to be related with SYSLOG and SYSMSG files.
If an abend occurs, send it to support.
If you get traces of the line or the buffer type, send them to support.
Note: To make a file from a sysout, under IBM SDSF use the ‘PRT ODSN ….’ and ‘PRT’ commands.
Installing Maintenance
This chapter describes how Connect:Express maintenance is delivered and how you can install the
maintenance using SMP/E or not.
Note: TRSMAIN : To uncompress the distribution file on z/OS platform, the JCL provided uses the TRSMAIN utility
delivered by IBM. If this utility is not available on your system, download it from IBM ftp site:
ftp://ftp.software.ibm.com/s390/mvs/tools/packlib/.
7-2 Connect:Express z/OS Administration Guide
//*******************************************************************//
//* UNPACK BIN FILE *//
//*******************************************************************//
//UNPACK EXEC PGM=TRSMAIN,PARM='UNPACK'
//* $CX.BIN : RECEIVED FILE FROM STERLING COMMERCE
//INFILE DD DSN=$CX.N42300A.Pnnnnnn.BIN,
// DISP=OLD
//* &&XMI : UNPACKED LIBRARIES XMIT FORMAT
//OUTFILE DD DSN=$CX.N42300A.Pnnnnnn.XMI,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(40,4,40),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
//SYSPRINT DD SYSOUT=*
//*
//*******************************************************************//
//* ALLOC INSTALLATION LIBRARIES *//
//*******************************************************************//
//ALLOC EXEC PGM=IEFBR14
//DISTLIB DD DISP=(NEW,CATLG,DELETE),
// SPACE=(32720,(50,0,20)),
// DSNTYPE=LIBRARY,
// DCB=(LRECL=80,BLKSIZE=0,RECFM=FB),
// DSN=$CX.N42300A.Pnnnnnn.DISTLIB
//TXLIB DD DISP=(NEW,CATLG,DELETE),
// SPACE=(32720,(400,0,500)),
// DSNTYPE=LIBRARY,
// DCB=(LRECL=80,BLKSIZE=0,RECFM=FB),
// DSN=$CX.N42300A.Pnnnnnn.TXLIB
//TXLIBU DD DISP=(NEW,CATLG,DELETE),
// SPACE=(32720,(180,0,120)),
// DSNTYPE=LIBRARY,
// DCB=(LRECL=80,BLKSIZE=0,RECFM=FB),
// DSN=$CX.N42300A.Pnnnnnn.TXLIBU
//LKLIB DD DISP=(NEW,CATLG,DELETE),
// SPACE=(32760,(370,0,80)),
// DSNTYPE=LIBRARY,
// DCB=(LRECL=0,BLKSIZE=32760,RECFM=U),
// DSN=$CX.N42300A. Pnnnnnn LKLIB
//*
//*******************************************************************//
//* EXTRACT INSTALLATION LIBRARIES *//
//*******************************************************************//
//EXTRACT EXEC PGM=IKJEFT1B,DYNAMNBR=100
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//LOGNAME DD SYSOUT=*
//*
Chapter 7 / Installing Maintenance 7-5
//SYSTSIN DD *
PROFILE NOPREFIX
RECEIVE USERID($TSOUSER) +
INDSN('$CX.N42300A.Pnnnnnn.XMI(DISTLIB)')
DSNAME('$CX.N42300A.Pnnnnnn.DISTLIB')
RECEIVE USERID( $TSOUSER) +
INDSN('$CX.N42300A.Pnnnnnn.XMI(TXLIB)')
DSNAME('$CX.N42300A.Pnnnnnn.TXLIB')
RECEIVE USERID($TSOUSER) +
INDSN('$CX.N42300A.Pnnnnnn.XMI(TXLIBU)')
DSNAME('$CX.N42300A.Pnnnnnn.TXLIBU')
RECEIVE USERID($TSOUSER) +
INDSN('$CX.N42300A.Pnnnnnn.MI(LKLIB)')
DSNAME('$CX.N42300A.Pnnnnnn.LKLIB')
//*
//*******************************************************************//
//* DELETE XMI FILE *//
//*******************************************************************//
//DELXMI EXEC PGM=IDCAMS,REGION=1024K
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE $CX.N42300A. Pnnnnnn XMI
4. Submit this JOB. This job will load the DISTLIB, TXLIB, TXLIBU and LKLIB maintenance libraries.
CMD ==>
PTF: Pnnnnnn
Press ENTER to continue, PF1 for Help, PF3 to Terminate the Install
2. When the Connect:Express Maintenance Installation Main Menu is displayed, fill it with the required
information. Previously entered information when first installation ran is displayed. Use the same
language as the initial installation and select SMP/E install if you previously installed Connect:Express
with this method. Next, press Enter.
Note: Individual field Help displays for all fields. By placing the cursor on an individual field and pressing the PF1 key,
Help for that specific field displays in a pop-up window.
Connect:Express installation CLIST invokes the other installation menus based upon how you specify your
installation selections on the Installation Main Menu.
3. Take one of the following actions:
For a non-SMP/E installation, continue with step 4.
For an SMP/E installation, refer to your completed Worksheet for SMP/E Installation on page 55 to
define the parameters in the SMP/E Main Menu:
• Define the appropriate fields using your high-level qualifier.
• Continue with step 4.
Chapter 7 / Installing Maintenance 7-7
CMD ==>
CMD ==>
Press ENTER to begin the generate, PF1 for Help, PF3 to return
Type CAN to terminate
After Connect:Express installation CLIST generates the JCL, a screen displays the jobnames and a description
of each member created in the file, as shown in the following example. Your screen will look different
depending on what components you installed.
5. Continue with one of the following procedures:
Execute the Maintenance Installation JCL Using SMP/E on page 8.
Execute the Maintenance Installation JCL for a Non-SMP/E Installation on page 8.
7-8 Connect:Express z/OS Administration Guide
Note: The following example is a representation. Your content may vary, slightly.
Jobname Description
------- -----------
CXSMPEP SMP/E PTF RECEIVE and APPLY JCL Job Stream
CXACPTP SMP/E PTF ACCEPT JCL Job Stream
The following table lists the members that are generated in the $CX.N42300A.Pnnnnnn.JCL file.
This appendix describes the Connect:Express user libraries which provide examples to help you customize and
automate Connect:Express.
User Libraries
The following table lists and describes the Connect:Express user libraries. Each library is discussed in detail in
the sections that follow.
Library Description
C:X INSTLIB Contains JCLs and PROCedures models for subsystem installation, VSAM definitions and
migrations from previous version.
C:X SAMPLIB Provides examples of user exits and batch processes, as well as assembly and COBOL.
C:X SAMPOPT Provides examples of optional features such as the Utilities package.
C:X MACLIB Provides DSECTs that you can use in any applicable module or exit, and compile and link for any
product upgrade.
C:X PARMLIB Provides examples of edit files for parameter extensions, such as SYSX25 and SYSSNA for
alternate address parameters, or SSLCFG, SYSSSL, and DN control files.
C:X SYSJCL Provides JCL skeletons that Connect:Express uses to run jobs like Unload/Reload.
C:X SYSPRM Provides examples of edit files for parameter extensions, including selection members for PDS
UNLOAD PROCs and EDCICONV procs.
A-2 Connect:Express z/OS Administration Guide
C:X DISTLIB
This library contains files that you use for your first installation of Connect:Express. This library includes the
following files:
CXINST Clist for product installation
CXIPTF Clist for maintenance installation
CXISSN Clist for monitor definition
Components used by installation Clists
C:X INSTLIB
This library contains edit files that you can use to install and customize Connect:Express, and includes the
following installation material:
ISPF customization
VSAM directory definitions
Directories migration
MONITOR/ANM/APM/AFM/EAS/ATM procedures
VTAM samples
Security recommendations
Appendix A / Connect:Express User Libraries A-3
C:X SAMPLIB
This library contains examples that you can use to automate general procedures like user exits and transfer
requests. The following screen shows part of the contents of the $$$$SAMP file with the module name syntax
and a brief description.
C:X SAMPOPT
This library contains examples that you can use to automate procedures using optional features like
Connect:Express Utilites and CICS. The following table lists part of the contents of the $$$$SAOP file with
the module name syntax and a brief description.
L1GFI..., P1GFI... Includes examples of parameters for these Connect:Express Utilities option programs.
L1USR... Includes examples of user exits for these Connect:Express Utilities option programs.
C:X MACLIB
The MACLIB contains DSECTS that can be used in user programs or exits. The table below lists the module
name syntax in the MACLIB and the program in which they can be used.
M3.. Assembler DSECTS for creating macros with the C:X CICS-OPTION
Note: The reference DSECT is always in ASSEMBLER. If it is not furnished in COBOL, copy the
ASSEMBLER DSECT and use the 'M1COBASM' ISPF EDIT MACRO to create the COBOL copy
structure.
C:X PARMLIB
This library contains edit files used to create Connect:Express parameters extensions such as alternate
addresses, planned transfers, and Partner lists. After you modify these files, they must be refreshed. Examples
of initialization parameters such as SYSIN and CXPLEX files are also provided. Some of the files included in
Appendix A / Connect:Express User Libraries A-5
the *PARMLIB* are listed below with the DDNAMES by which they are referenced in the JCL cards of the
Connect:Express address spaces.
Module Description
£AFMFTPE FTP identification extension referenced by the AFMFTPE DD card of the AFM JCL.
£EVENT Planned transfers. This file is referenced by the SYSEVT DD card in the TOM JCL.
£LIST Partners list. This file must be in a library referenced by the SYSPRM DD card in the TOM JCL.
£MANAGER Manager CXPLEX file. This file is referenced by the CEXPLEX DD card in the TOM JCL.
£PRMETB3 ETEBAC3 card. This file is referenced by the PARMETB3 DD card in the APM JCL.
£PRMFTPL FTP list customization. This file is referenced by the PARMFTPL DD card in the EAS JCL.
£SERVER Server CXPLEX file. This file is referenced by the CEXPLEX DD card in the TOM JCL.
£SYSX25 X25 alternate addresses. This file is referenced by the SYSX25 DD card in the TOM JCL.
£SYSSNA SNA alternate addresses. This file is referenced by the SYSSNA DD card in the TOM JCL.
£SYSTCP TCP/IP alternate addresses. This file is referenced by the SYSTCP DD card in the TOM JCL.
£SYSEXT L1B2PDIX exit list. This file is referenced by the SYSINEXT DD card in the TOM JCL.
£SYSUE1 L1GFIUE1 parameters. This file is referenced by the SYSUE1 DD card in the APM and EAS JCL.
£SYSCE1 L1GFICE1 parameters. This file is referenced by the SYSCE1 DD card in the TOM and AFM JCL.
DNCFG05 DN control member of a file referenced by the ANMSSL DD card of the ANM JCL.
SSLCFG05 SSL configuration member of a file referenced by the ANMSSL DD card of the ANM JCL.
SYSSSL SSL configuration selection member of a file referenced by the ANMSSL DD card of the ANM
JCL.
C:X SYSJCL
This library contains JCL skeletons used by Connect:Express. After you modify these files, they must be
refreshed. This library is referenced by the SYSJCL DD card in the TOM JCL. The files included in the
*SYSJCL* are listed below with a short description.
File Description
$JOBREL1 Job card for reloading a PDS data set. This file must only be customized once.
$RELOAD1 Execution parameters for reloading a PDS data set. Connect:Express uses this file as a model to
build the actual job.
$JOBUNL1 Job card for unloading a PDS data set. This file must only be customized once.
$UNLOAD1 Execution parameters for unloading a PDS data set. Connect:Express uses this file as a model to
build the actual job.
$JOBREL2 Job card for reloading a VSAM data set. This file must only be customized once.
$RELOAD2 Execution parameters for reloading a VSAM data set. Connect:Express uses this file as a model
to build the actual job.
$JOBUNL2 Job card for unloading a VSAM data set. This file must only be customized once.
A-6 Connect:Express z/OS Administration Guide
File Description
$UNLOAD2 Execution parameters for unloading a VSAM data set. Connect:Express uses this file as a model
to build the actual job.
$JOBREL3 Job card for reloading a USER data set. This file must only be customized once.
$RELOAD3 Execution parameters for reloading a USER data set. Connect:Express uses this file as a model
to build the actual job.
$JOBUNL3 Job card for unloading a USER data set. This file must only be customized once.
$UNLOAD3 Execution parameters for unloading a USER data set. Connect:Express uses this file as a model
to build the actual job.
$JOBREL4 Job card for reloading a SYSOUT data set. This file must only be customized once.
$RELOAD4 Execution parameters for reloading a SYSOUT data set. Connect:Express uses this file as a
model to build the actual job.
$JOBUNL4 Job card for unloading a SYSOUT data set. This file must only be customized once.
$UNLOAD4 Execution parameters for unloading a SYSOUT data set. Connect:Express uses this file as a
model to build the actual job.
$JOBREL5 Job card for reloading an EDCICONV processed data set. This file must only be customized
once.
$RELOAD5 Execution parameters for reloading an EDCICONV processed data set. Connect:Express uses
this file as a model to build the actual job.
$JOBUNL5 Job card for unloading an EDCICONV processed data set. This file must only be customized
once.
$UNLOAD5 Execution parameters for unloading an EDCICONV processed data set. Connect:Express uses
this file as a model to build the actual job.
C:X SYSPRM
This library contains edit files that you can associate with the JCL Skeleton from the *SYSJCL* library. It also
includes examples for selecting members for PDS UNLOAD DELETE/DEFINE for VSAM RELOAD, and
From/To parameters for EDCICONV UNLOAD/RELOAD. This library is referenced by the SYSPRM DD
card in the TOM JCL.
Appendix B
This appendix describes error codes and messages from the Connect:Express application.
Error Codes
The error codes section lists and explains the types of return codes that you may encounter with
Connect:Express. Return codes identify errors and can come from the network, system, Connect:Express, or
the transfer protocol you are using. You can then correct errors based on their origin. The sections below list
system return codes (SRC), network return codes (NRC), Connect:Express return codes (TRC), and protocol
return codes (PRC).
Note: If an error is not listed, press the Help key <PF1> two times when you are on a return code screen.
This will display information about the origin of the return code. From the TSO/ISPF screens in
Connect:Express, you can also type: 'TRC tttt', or 'PRC ppp' for direct Help or 'RC' for general 'C:X
RETURN CODES' Help.
concerned and the xx and yy variables depend on the current link. The table below identifies the xx and yy
return codes for each link type.
SNA LU0, LU2 VTAM return code and FEEDBACK2 (RPLRTNCD, RPLFDBK2)
Note: If xx = X'FF,' the error is from an internal component of a local or remote ANM.
‘AA’ describes an error detected by the ANM when executing a service request from the TOM or APM address
space. It is called the Action field. ‘BB’ describes an error detected from the Network by the ANM. It is called
the Event field. The table below lists the possible values of AA and BB.
Code Description
= 01 Function failed
= 02 LOSTERM detected
= 04 TPEND detected
= 80 Sequence error
= 08 DISCONNECT detected
= 40 TIME-OUT detected
= 80 CLOSE detected
When xx=FF, the FFyy return codes are generally issued only by X.25 handler. The following table describes
the possible values for yy codes in this case.
Code Description
Code Description
= 04 SVC was successfully opened but SMN level session establishment failed (SMN inactive or
IDNUM error).
Code Description
CC = 80 UNBIND received
= 81 TPEND detected
= 82 DFASY detected
= 83 RECEIVE rejected
= 84 RECEIVE error
= 85 LOSTERM detected
= 86 OPNSEC error
= 87 GENACB error
= 89 GENRPL error
= 8A OPNDST error
= 8B SEND error
= 8C GETMAIN rejected
WARNING: The TRC field can be set for a remote TRC. This means that there will be NO local errors, only
remote errors. The remote Partner must be a Connect:Express monitor, otherwise when the
TRC equals 0000, the error was detected on the remote side.
B-4 Connect:Express z/OS Administration Guide
The example below shows how the remote TRC is processed internally.
The low order bytes indicate the type of TRC. The following programs have to consider this detection method
if the TRC is local or remote:
User exit
Journal inquiry utility, read function
Request control table scanning utility
The table below shows the ranges and groupings of Connect:Express return codes (TRC).
5000 – 5999 Error detected by the protocol during any negotiation process
F000 – F999 Error detected by TOM Plex Supervisor (Fxxx is equivalent to 2xxx)
2024 Reserved
2033 Partner or file cannot be added (PCT is full) – PCT/FCT add failed
2048 Reserved
2049 Reserved
2050 Reserved
2052 Reserved
2079 Reserved
2098 Connect:Express /dsn access denied by RACF, see LOG and SRC
2099 Reserved
2100 Reserved
2107 Reserved
2108 Reserved
2109 Reserved
2110 Reserved
2111 Reserved
2112 Reserved
2129 Reserved
2162 Unused.
† Check your Asset Protection file and call support for a new one. Authorized option are shown under ISPF '0.O'.
Appendix B / Error Codes and Messages B-11
† Check your Asset Protection file and call support for a new one. Authorized option are shown under ISPF '0.O'.
3 Z01 Allocation†
3 Z02 Deallocation†
† Check the APM log for z/OS DYNALLOC RBX WTO messages and for DYNALLOC error codes '0210'/'020C.'
L1APMDYA will show who holds this data set.
Appendix B / Error Codes and Messages B-13
3 Z92 Invalid LRECL. The record length of the file received doesn’t match the file definition.
3 Z93 Invalid BLKSIZE. The files block size is does not match the file definition.
3 Z94 Invalid RECFM. The format of the file received doesn’t match the file definition.
† Check the APM log for z/OS DYNALLOC RBX WTO messages and for DYNALLOC error codes '0210'/'020C.'
L1APMDYA will show who holds this data set.
Code Description
4 0RC Error in beginning transfer user exit (Return Code=RC from user exit)
4 iRC Error in transfer user exit (Return Code=RC from user exit) (i from 1 to 3)
4 6RC Error in application server exit (connection, selection), Return code=RC from user
4 9RC Error in end transfer user exit (Return Code=RC 01:90 from user exit). See the Administration
Guide for more information.
Code Description
X=4 Security
Code Description
Code Description
Code Description
7 Z01 Allocation
Appendix B / Error Codes and Messages B-15
Code Description
Code Description
Code Description
A X20 Reserved
X=8 reserved
000 0000 OK
301 0000 Invalid local identification PI (4) Error detected by local or remote addressee
304 0000 Invalid remote identification PI (3) Error detected by local or remote addressee
310 0000 Network error (+ NRC) Detected locally, can be on both sides
The next sections describe the PRC and TRC that you can receive during the connection and file selection
phases. During these phases, the automatic retry process may be activated depending on the PRC received.
Refer to the Administration Guide for more information.
The PRC code is issued by the remote Partner. The local TRC code issued is 2077, as long as the retry process
is operating. It changes to 2076 when the process is aborted and the Partner is disabled. If the RESTART option
is YES in the Partner directory, then the retry procedure is never stopped unless you disable the Partner.
Some connection return codes invoke the call retry procedure activation. For PeSIT, the default T1B2PCOD
entry contains the codes as indicated in the tables below.
0000 0000 OK
The next sections show the PRC and TRC that you can receive during the connection and file selection phases.
During these phases, the automatic retry process may be activated depending on the PRC received. Refer to the
Administration Guide for more information.
1007 4. . .
1008 4. . .
1009 4. . .
1099 2. . . 5. . . 6. . . 9. . . 4. . . miscellaneous
Messages
This section lists WTO messages issued by the Monitor, the APM, and the ANM, as well as SYSLOG
messages from the Monitor and APM.
Appendix B / Error Codes and Messages B-27
Time stamp-subsystem Name (TOM8)–message number (046)–message type (I),TEXT. Message types are
standard IBM message types as shown in the table below.
Message Description
W Warning
E Error
I Information
The following table lists the WTO messages issued by the monitor.
Code Description
Code Description
Code Description
Reason Description
Code
Code Description
Reason Description
Code
Code Description
Reason Description
Code
Code Description
Reason Description
Code
Code Description
Reason Description
Code
Code Description
Reason Description
Code
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
dtsm123I ????????.????????.????????.????????
Explanation: DSN of dtsm121I.
System action: None.
User action: None.
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
‡ Refer to Appendix D of the Administration Guide, Initialization Parameters, for a description of the SYSIN file.
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Code Description
Symbol(s) Substitution
? return code
c class
cccc CPU-ID
d direction
dddddd date
dsn data-set-name
hhhhhh hour
l link type
llllllll lu-name
nn number
o option
pp percent
pppp PRC
Symbol(s) Substitution
ssss SRC
uuuuuuuu userid
xxxxxxxx function
The following table lists SYSLOG messages issued by the Monitor by product/function.
Message Comment
START MESSAGES
AFM INITIALIZATION COMPLETE ASID=nnnnn PORT=nnnnn SESSION (nnnn1/nnnn2) The AFM is listening incoming
calls on PORT=nnnnn, nnn1
sessions input and nnnn2
sessions output are available.
PARAMETERS OF JOB: jjjjjjjj RUN=o CPU=xxxx The SYSIN and CXPLEX files
PLEX PARAMETERS OF JOB: jjjjjjjj have already been listed.
CONNECTION ESTABLISHED WITH LOCAL: llllllll Check the SNA link between
CONNECTION CLOSED WITH LOCAL: llllllll Local and Global (TOMACB=
CONNECTION FAILED WITH LOCAL: llllllll NRC=nnnnnn nnnnnnn parameter in the SYSIN file).
REQUEST MESSAGES
Normal Request
Appendix B / Error Codes and Messages B-59
Message Comment
REQUEST rrrrrrrr <- ffffffff ppppppppp (d) SRC=0000 TRC=0000 PRC=0000 This is the normal sequence
REQUEST rrrrrrrr <- jjjjjjjj ACCEPTED (o) of messages, depending on
AFM INCOMING FTP SESSION (nn/nn) OPENED WITH pppppppp (xxx.xxx.xxx.xxx) the type of file.
AFM OUTGOING FTP SESSION (nn/nn) OPENED WITH pppppppp (xxx.xxx.xxx.xxx) PU, VU, SU, UU files are
REQUEST rrrrrrrr COMMUNICATION OPENED (d) WITH pppppppp lid processed with Unload job
REQUEST rrrrrrrr ffffffff TRANSFER ACCEPTED APM nn EFF nn before transfer and Reload
REQUEST rrrrrrrr HSM AUTOMATIC RECALL ffffffff SRC=ssss job after transfer.
REQUEST rrrrrrrr HSM AUTOMATIC RECALL PROCESSING FOR DSN dsn
REQUEST rrrrrrrr/ffffffff/pppppppp JOBnnnnn UNLOAD STARTED
REQUEST rrrrrrrr/ffffffff/pppppppp JOBnnnnn UNLOAD ENDED
REQUEST rrrrrrrr ffffffff TRANSFER STARTED APM nn EFF nn
REQUEST rrrrrrrr ffffffff TRANSFER RESTARTING APM nn EFF nn
REQUEST rrrrrrrr TRANSMITTING -> pppppppp FILE ffffffff RECORDS nnnnnnn
REQUEST rrrrrrrr RECEIVING <- pppppppp FILE ffffffff RECORDS nnnnnnn
REQUEST rrrrrrrr ffffffff pppppppp SRC=ssss TRC=tttt PRC=pppp
REQUEST rrrrrrrr ffffffff TRANSFER ENDED TRC=0000L APM nn EFF nn
REQUEST rrrrrrrr/ffffffff/pppppppp JOBnnnnn RELOAD STARTED
REQUEST rrrrrrrr/ffffffff/pppppppp JOBnnnnn RELOAD ENDED
REQUEST rrrrrrrr JOB jjjjjjjj SUBMITTED
End Transfer
TRANSFER DURATION hhmmss, RESTART NUMBER: nnn ,NUMBER OF S/R: nnnnnnn The TSO user is notified only
COMMUNICATION CLOSED (d) WITH: pppppppp APM nn EFF nn if the transfer is done
AFM INCOMING FTP SESSION (nn/nn) CLOSED WITH pppppppp(xxx.xxx.xxx.xxx)
TRC=????
AFM OUTGOING FTP SESSION (nn/nn) CLOSED WITH pppppppp(xxx.xxx.xxx.xxx)
TRC=????
SE ’ffffffff REQ rrrrrrrr TRANSFER ENDED’,USER=(uuuuuuu),LOGON
End Request
Abnormal Request
INCOMING REQUEST REJECTED rrrrrrrr SRC=ssss TRC=tttt PRC=pppp This message is generally
issued when an input call is
not resolved. For example an
X25 call packet has been
received and session
interrupted.
Message Comment
REQUEST rrrrrrrr COMMUNICATION POSTPONED BY ppppppp,RETRY IN nn MIN lid The automatic retry process
REQUEST rrrrrrrr COMMUNICATION NOT OBTAINED ppppppp,RETRY IN nn MIN lid is running from STIMEV= and
REQUEST rrrrrrrr RETRY WITH PARTNER pppppppp, NEW LINK : l STIMOC= parameters
AFM OUTGOING FTP SESSION (nn/nn) POSTPONED WITH pppppppp (xxx.xxx.xxx.xxx) declared in the SYSIN file.
RC=????? TRC=???? PRC=???? When all possible retries that
AFM OUTGOING FTP SESSION (nn/nn) NOT OBTAINED WITH pppppppp are possible have been done
(xxx.xxx.xxx.xxx) RC=????? TRC=???? PRC=???? (all alternate addresses failed
for the current link), next link
type is selected.
REQUEST rrrrrrrr COMMUNICATION REJECTED BY pppppppp PRC=pppp lid No automatic retry process is
AFM INCOMING FTP SESSION (nn/nn) REJECTED WITH pppppppp running because it has never
(xxx.xxx.xxx.xxx) TRC=???? been activated or the
AFM OUTGOING FTP SESSION (nn/nn) REJECTED WITH pppppppp (xxx.xxx.xxx.xxx) automatic retry process is
RC=????? TRC=???? PRC=???? stopped at the end of the
REQUEST rrrrrrrr COMMUNICATION ABORTED WITH pppppppp, PARTNER HELD possible links. if needed add
the PRC received in
T1B2PCOD, and ACR=YES
in partner definition.
REQUEST rrrrrrrr ABORT <- pppppppp SRC=ssss TRC=tttt PRC=pppp These are different ways of
REQUEST rrrrrrrr SESSION ERROR : AAAAAAAA NRC=nnnnnn nnnnnn cutting a session. A protocol
REQUEST rrrrrrrr SESSION DISCONNECTED SRC=ssss TRC=tttt PRC=pppp message may abort the
session or a network anomaly
can occur (check the NRC
codes).
REQUEST rrrrrrrr NOT xxxxxxx SRC=ssss TRC=tttt PRC=pppp You probably passed a
command that is not allowed
by the status of this request
(for example restarting a not
interrupted request, purging a
request during negotiation
phase are not allowed).
REQUEST rrrrrrrr <- ffffffff ppppppppp (d) SRC=ssss TRC=tttt PRC=pppp If the trc is null, the problem
REQUEST rrrrrrrr <- jjjjjjjj REJECTED has probably been detected
REQUEST rrrrrrrr WITH PARTNER pppppppp UNSUPPORTE D LINK : I on the remote side. If the
REQUEST rrrrrrrr ffffffff ERROR DURING SELECTION TRC=ttttL PRC=pppp TRC=ttttL this is a local error,
REQUEST rrrrrrrr REJECTED SRC=ssss TRC=ttttL PRC=pppp if the TRC=ttttR this is a
REQUEST rrrrrrrr ffffffff SUSPENDED TRC=ttttL PRC=pppp remote error.
REQUEST rrrrrrrr ffffffff INTERPT./PURGED BY SERVER TRC=ttttL PRC=pppp
REQUEST rrrrrrrr ffffffff INTERPT./PURGED BY CALLER TRC=ttttL PRC=pppp
REQUEST rrrrrrrr ffffffff WILL BE RESTARTED TRC=ttttL PRC=pppp
REQUEST rrrrrrrr/ffffffff/pppppppp JOBnnnn TRANSFER INTERRUPTED (?)
REQUEST rrrrrrrr NO AUTOMATIC RESTART BY T1B2PCOD, PRC=ppp ’protocol id’ This message is issued if a
connection or file selection
error. If needed add this PRC
in T1B2PCOD, and
ACR=YES in the partner
definition.
Appendix B / Error Codes and Messages B-61
Message Comment
SECURITY xxxxx o r15/r0 uuuuuuuu gggggggg ffffffff dsn This DSN was not found or
SECURITY-ADHOC INIT o r15/r0 uuuuuuuu gggggggg found in error or mismatching
Allocation Control
REQUEST rrrrrrrr ffffffff xxxxxxxx FAILED DSN=dsn This DSN was not found or
REQUEST rrrrrrrr ffffffff LOC/CHECK FAILED DSN=dsn found in error or mismatching
REQUEST rrrrrrrr ffffffff ALLOC FAILED DSN=dsn E..I..E..I..S... E/I = DYNALLOC error/info
primary+secondary codes, S
= SMS error code
REQUEST rrrrrrrr ffffffff xxxxxxxx ADVISED DSN=dsn An option is advised for this
file, in file directory
REQUEST rrrrrrrr ffffffff DATA SET ENQUEUED BY uuuuuuuu cccc Enqueue detected for the
requested dsn
Auxiliary Protocol
Change
Message Comment
Anomaly
REQUEST rrrrrrrr AUTOMATIC COMMAND NOT RESOLVED Check the start or end
command defined for the file.
LOCAL REQUEST QUEUE RCT pp % FULL The RCT size is define by the
EXTERNAL REQUEST QUEUE RCT pp % FULL RQEMAX= parameter of the
SYSIN file.
ANM HANDLER ABNORMALY TERMINATED SRC=ssss TRC=tttt PRC=pppp Check the return codes.
Check the network resource
involved, and restart the
handler when the problem is
fixed.
AFM INITIALIZATION FAILED ASID=nnnnn RC=nnnnn Check the return code. Check
the configuration (Started
task, TCP/IP, RACF …)
End Connect:Express
Code Description
Code Description
Code Description
Code Description
Code Description
Description
Description
Code Description
Code Description
Code Description
Monitor Commands
This appendix lists and describes monitor commands that you can use to activate or deactivate resources.
The following tables list actions and monitor commands for each resource type.
C-2 Connect:Express z/OS Administration Guide
Initialization Parameters
This appendix identifies the SYSIN parameters for Connect:Express and describes the parameters that are
required for Connect:Express to work as a stand-alone, a Plex manager, or a Plex server, and the optional
parameters that you can use to increase resource productivity and to take advantage of advanced features.
SYSIN Parameters
Connect:Express can be started as a stand-alone, a Plex manager, a Plex server, or a local TOM, but only the
stand-alone and the Plex Manager are in charge of monitoring transfers. This is called a global TOM as
opposed to a local TOM.
You set Connect:Express configuration parameters in the SYSIN file. Then, you must define the ANM and at
least one APM to manage transfers. In a SYSPLEX configuration, the Plex manager processes the SYSIN file
as a stand-alone monitor, and the Plex server only uses the parameters it needs.
ACTEXT 4 alpha The ACTEXT parameter of CONT makes it possible to ignore a return code from a
characters user exit (UEXJNL=) other than 0. The Monitor deactivates the exit.
The ACTEXT parameter of STOP makes it possible to stop Connect:Express if the
user exit (UEXJNL=) ends with a return code other than zero. If this return code is
between 64 and 128, Connect:Express places an 80-character message in the
SYSLOG file that is returned by the exit through the communication area.
Examples:
CONT, STOP
D-2 Connect:Express z/OS Administration Guide
ADHOCN Y, N, or U If ADHOCN is set to Y, the TSO AD HOC request is allowed, with mandatory RACF
user and password to be transmitted with the request to the remote Partner. This
RACF facility is available for protocol number 5 (PeSIT-E) only, and with another
Connect:Express.
If ADHOCN is set to N, the TSO AD HOC request is not permitted for incoming or
outgoing transmissions. This is the default.
If ADHOCN is set to U, the TSO AD HOC request is allowed, with optional RACF user
and password to be transmitted with the request to the remote Partner. This is the
UNSAFE mode. For incoming calls you can use the RACFUD= field as a default
RACF user.
ANMPRC 6 to 8 ANMPRC is the name of the start procedure for the auxiliary network manager. You
alphanumeric can use characters 1 to 8 to generate a PROCSTEP name.
characters Example:
ANMPRC=TOM3ANM
Results in:
S TOM3ANM.TOM3ANM
APLNUM 1 to 2 numeric This parameter can be described in two forms. In the first form, APLNUM indicates the
character number of applications or address spaces which can be connected to the Monitor.
Each address space receives the end of transfer notifications. The maximum
authorized value is 64.
Examples: 16, 4
- or -
2 + 2 numeric This second form enables you to indicate two values separated by a comma and
characters placed between brackets. The first parameter indicates the number of applications (1
to 64) as described in the first form. The second parameter indicates the number of
entries stacked (1 to 32) for each application. If the previous form is used, the default
is 8. Each entry uses 512 bytes of CSA. The application table and the stack are
initialized only after an z/OS IPL, or if "$LOAD$" has been issued during the previous
session of the CONNECT:Express Monitor.
Example: (2,10)
APMPRC 6 to 8 APMPRC is the name of the started procedure for an auxiliary protocol manager.
alphanumeric Characters 1 to 6 are used with the APM number to generate a different PROCSTEP
characters name per task.
Example:
APMPRC=TOM3APM
Results in:
S TOM3APM.TOM3AP01 for APM number one...
AUTHDS= 1 TO 44 AUTHDS= is the data set name of the Asset Protection File.
alphanumeric
characters
CMDPRE 1 alphanumeric CMDPRE is the unique prefix character of the subsystem command. All commands
characters intended for the Monitor can be transmitted by MODIFY or through the subsystem
feature.
Examples:
F TOMJOB,P APM=01 or
+P APM=01
See Appendix C for a list of monitor commands.
Appendix D / Initialization Parameters D-3
DAPM01 1 to 14 DAPMxx=(x/nn/xyz) DAPMxx defines the auxiliary protocol manager resource where
alphanumeric xx can assume values 01 to 08. The standard license enables two APMs. The first
characters one is mandatory. It is possible to increase the number of APMs. If you want to use
more than two APMs, you have to modify the license contract.
The first field, x, defines the submission of the APM and can assume the value E, H,
or O. For DAPM01, only E and H are valid.
E – APM must be started during the initialization of Connect:Express.
H – APM must not be started during initialization, but can later be submitted by
command.
O – APM is not used and cannot be submitted.
The second field, nn defines the number of protocol servers or effectors which can be
initialized in this APM. It is stated as two numeric bytes (01 to 16).
Note: If you have huge user exits, you may have to specify less than 16 effectors to
avoid ABEND80A/ABEND106 in the APM region.
The third field, xyz, defines transfer classes. In the following example, the APM is
started by Connect:Express at initialization with 16 servers for ABCDEFG class
requests. DAPM01=(E/16/ABCDEFG)
DPCSID 8 alphanumeric DPCSID is the symbolic name given to the Connect:Express Monitor. Partners use
characters this name for identification when the session begins. This is your Partner name.
Examples:
NEPTUNE, BACKUP01, PSRTOM3
FCTADD 2 numeric If FCTADD is equal to zero, no update of the file directory is dynamically transmitted
characters to the Monitor tables. Updates are only taken into account for the next hot or cold start
of the Monitor.
If FCTADD is not equal to zero, all updates of the File directory under TSO/ISPF are
dynamically transmitted to the file table (FCT) in the Connect:Express Monitor and are
available for use. The following conditions are necessary.
• Connect:Express is active.
• There is no request for this file.
A message is displayed if the UPDATE cannot be sent to the FCT. It is recorded in the
File directory and is taken into account at the next hot or cold start of the Monitor.
The value of FCTADD represents the maximum number of new entries in the File
directory which can be sent dynamically to Connect:Express.
Examples: 00, 33, 99
HFSDIR 17 alphanumeric HFSDIR is the major index of temporary UNIX files allocated by Connect:Express
characters when unloading and reloading EDCICONV-processed HFS files, ended by '/'.
Example:
/u/paris/Cexpress/
MAJIND 17 alphanumeric MAJIND is the major index of temporary files allocated by Connect:Express when
characters unloading and loading partitioned, VSAM-type, or EDCICONV-processed files.
Examples:
PSR.PSR, PSR
MAXSRQ 2 numeric MAXSRQ is the maximum number (up to 64) of IEFSSREQ issued simultaneously by
characters TSO users or batch JOBs using "L0B2Z20."
Examples: 08, 12, 16
MSGPRX 4 alphanumeric MSGPRX represents the four prefix characters used in messages transmitted by the
characters Monitor.
Examples: TOM1, TOM2, TOMP, and so on.
PCTADD 2 numeric If PCTADD is equal to zero, no update of the Partner directory is sent to the Monitor
characters tables. Updates will be taken into account at the next hot or cold start of the Monitor.
If PCTADD is not equal to zero, all the UPDATES of the Partner directory under
TSO/ISPF are dynamically sent to the Partners Control Table (PCT). The following
conditions must be present.
• Connect:Express must be active
• There is no request for this Partner.
A message is displayed if the UPDATE cannot be sent to the PCT. It is recorded in
the Partner directory and is taken into account at the hot or cold start of the Monitor.
The value for PCTADD represents the maximum number of new entries in the Partner
directory which can be dynamically sent to Connect:Express.
Examples: 00, 22, 99
RMFLOG Y or N If RMFLOG is set to Y, Connect:Express sends RMF records. This measures the
Connect:Express system utilization.
If RMFLOG is set to N, Connect:Express does not produce RMF records.
RQEMAX 4 numeric RQEMAX represents the maximum number of requests in the Request Control Table
characters (RCT). This value includes the possible number of requests pending, those in
progress, and those which have been interrupted. The requests which have been
successfully executed are deleted from the RCT. The maximum number of requests
cannot be greater than 1024.
Examples: 0512, 1024
SMFREC 3 numeric SMFREC is the user SMF record number assigned to Connect:Express. Enter 000 if
characters you do not want these records.
Examples: 240, 250, 000
SMSSDB Y or N SMSSDB tells the Monitor which method to use when computing the blocksize.
If "Y" is specified, the blocksize is computed by SMS, otherwise Connect:Express
computes the blocksize, based on the volume where the received file will reside.
Allocation in bytes, Kilo bytes or Mega bytes can be used only if SMSSDB=Y.
STIMEV 2+2 This parameter includes two mandatory fields separated by a comma and placed
numeric between brackets.
characters The first field is the number of minutes between two call attempts.
Examples: (06,..) or (15,..)
The second parameter is the number of minutes after which Connect:Express restarts
a local request that was interrupted following a network incident, or a local request
that was rejected by the Partner with an error code defined in the T1B2PCOD table.
Examples: (..,05) or (..,00)
Appendix D / Initialization Parameters D-5
STIMOC 2 numeric This parameter is used with the STIMEV parameter and defines the maximum
characters number of attempts for calling a Partner or restarting a request. STIMOC represents
the maximum number of call attempts on one link to another Monitor. If the call is not
successful after a time equal to the first parameter of STIMEV * STIMOC, then one of
the following will occur:
• A new link is processed
• The Partner is disabled (All alternate links have been processed and ACR=no in
the Partner definition.)
If ACR=NO, in the Partner definition, the TRC code is set to 2076 and processing
stops. If ACR=YES, the retry and restart processes continue until the transfer is
successful.
STIMOC represents the maximum number of attempts for a transfer request. If the
transfer is not accepted after a time equal to the second parameter of
STIMEV * STIMOC, then the request is disabled with a status of ERROR
SELECTION.
Examples: 06, 04, 02
TOMACB 8 alphanumeric TOMACB is the name of the VTAM application allocated to the Monitor for SNA
characters sessions with local Monitors of the same cross-domain. These Monitors ensure
transmission of requests from one machine to the central monitor by a defined VTAM
prefix of link. This parameter is only used in a local/global Connect:Express environment. If
APLPFX Connect:Express is operating alone, TOMACB must be coded with the value NONE.
(6) + 00 Examples: TOMAPLID, MASTLTOM, ANMAPP00
TOMLCL 2 numeric TOMLCL indicates the number of simultaneous SNA sessions (1 per local
characters Connect:Express) with a limit of 16. This parameter is used only in a local/global
Connect:Express environment. If Connect:Express is operating alone (TOMACB =
NONE), TOMLCL must be coded with the value 00.
Examples: 00 ..... 16
UEXJNL 1 to 8 UEXJNL is the name of the user exit routine which receives control for each end of
alphanumeric transfer. Control is also given at INIT and TERM of Monitor. Sample user exits can be
characters found in the Connect:Express SAMPLIB. L1B2PDIX in the *SAMPLIB* EX#DIX is a
driver which receives a SYSIN file (SYSINEXT) with a list of user exits. You must
place the module to be run in the library defined by the SYSLIB card of the
CONNECT:Express Monitor. The setting is NONE if this exit is not implemented.
Examples: L1B2PDIX, NONE, or MYJNL
UPRCPI 8 alphanumeric UPRCPI is the name of a user procedure to be started after correct initialization of
characters Connect:Express. This parameter must be coded with the value NONE, if it is not
used.
Examples: UPRCPI=USERCPI
UPREND 8 alphanumeric UPREND is the name of a user procedure to be started after correct termination of
characters Connect:Express. This parameter must be coded with the value NONE, if it is not
used.
Examples: UPREND=USEREND
WRKUNT 8 alphanumeric WRKUNT is the unit name Connect:Express uses to allocate temporary files created
characters when unloading and loading partitioned or VSAM-type files.
Example: SYSALLDA
APLPFX 6 alphanumeric This required parameter is the 6-character prefix of the VTAM application
characters name used by the ANM. The complete name comes with a 2-digit suffix
number, from 01 to 07. See Appendix E, Definition of VTAM Resources.
Examples:
APLPFX=ANMAPP:
ANMAPP01 SNA LU0 X-DOMAIN
ANMAPP02 X.25NPSI DATE handler
ANMAPP03 X.25NPSI PCNE
ANMAPP05 3270
ANMAPP06 X.25NPSI GATE
ANMAPP07 LU6.2
MAXEXT 3+3 numeric This parameter has two mandatory fields separated by a comma and
characters placed between brackets, and describes the rules for extending buffers.
The first value is the number of possible simultaneous extensions. The
second value is the maximum buffer length. The extension of a buffer is
acquired by the ANM during initialization. The APM requests the
extended buffer from the ANM when protocol negotiations result in a
message length more than the STDMSG parameter. This must be
related to the MESSAGE SIZE fields in the T1B2PSxx session tables.
Example: MAXEXT=(016,128)
MCHNBR 2 numeric This parameter is the number of multi-channel lines handled by the ANM.
characters The maximum is 32.
STDMSG 2 numeric This parameter is the standard network buffer length to be acquired by
characters the ANM at initialization.
Example: STDMSG=04
X.25 Parameters
X.25 parameters are mandatory if MCHNBR is greater than zero. Each MCH must be defined with the
subparameters described in the following table.
MCHMSC 1 alphanumeric Optional. This parameter is the X.25 network selection code (MCH). This
character parameter permits you to identify the MCHs which access the same X.25
network. It is referred to in the Partner directory. Leased or switched
point-to-point lines with X.25 protocol must be considered as a distinct X.25
network.
Example: MCHMSC=A
MCHNAM 1 to 8 Required. This parameter corresponds to the MCH macro name in the
alphanumeric NCP.
characters
MCHPKS† 4 numeric Required. This value specifies the size of the X.25 packets for this
characters subscription.
Appendix D / Initialization Parameters D-7
MCHRTR 2+2 numeric This optional parameter has two mandatory fields separated by a comma
characters and placed between brackets. Indicates the occurrences and time (in 30
seconds) of the MCH reactivation which is performed automatically if the
MCH is lost.
Example: MCHRTR=(05,02)
MCHTYP 1 alpha character Required. Indicates the type of MCH (D=DATE, G=GATE).
MCHVCN† 3 numeric characters Required. Specifies the number of generated switched virtual circuits for
this MCH.
MCHWDS† 2 numeric characters Required. Indicates the size of the X.25 packet window for this subscription
(=MCH).
MCHXLA 1-15 characters Optional. This is the local X.25 address of a specific MCH. The Partner
local address, if it exists in the directory definition, is added at the end.
TCP/IP Parameters
The TCP/IP parameters are shown in the following table.
TCPORG 4+8 alphanumeric The TCPORG parameter defines the TCP/IP stack and access method.
characters Two parameters are specified between brackets and the first parameter is
fixed. ‘HPNS’ is for the IBM standard socket interface. 'SOE' is for the IBM
Open Edition interface. The second parameter indicates the job name of
the TCP/IP stack running on the system. This is valid for both IBM or
Computer Associates software.
Example: (HPNS,TCPIPJOB), (SOE,)
NOTE: Previous definitions are still supported (ITL31,ACSS,4096) for TCP
ACCESS and (IBM3.1,TCPIPJOB).
TCPPRT 5 numeric characters The TCPPRT parameter defines the port number on which the ANM listens
for PeSIT and ETEBAC3 incoming calls.
TCPPRO 5 numeric characters The TCPPRO parameter defines the port number on which the ANM
listens for ODETTE-FTP incoming calls.
SSL Parameters
The SSL parameters are shown in the following table.
SSLOPT 1 alpha character N/Y: Determines if SSL is used or not, No is the default. 'Y' requires a
minimum number of parameters among the SSL parameters shown
below.
SSLCFG 1 alpha character N/Y: This parameter enables the use of the SSL configuration files,
defined in the ANMSSL file. This enables you to configure multiple SSL
profiles and to activate DN control.
SSLKRG 1 to 44 alphanumeric Name of the RACF Keyring associated with the ANM. This parameter
characters excludes SSLDTB and SSLPSW parameters.
D-8 Connect:Express z/OS Administration Guide
SSLDTB 1 to 44 alphanumeric Name of the HFS database in which certificates are stored. This
characters parameter requires SSLPSW and excludes SSLKRG..
SSLPSW 8 alphanumeric Password to access the HFS database in which certificates are stored.
characters
SSLCER 1 to 34 alphanumeric Label of the local certificate defined in he HFS database or the RACF
characters keyring. It can include blanks. This parameter is optional, the default of
the database or keyring is used.
SSLPRT From 1 to 65535 TCP/IP port number for inbound PeSIT SSL calls.
numeric
SSLUDF 2 to 16 hexadecimal X25 user data expected from PeSIT SSL Clients. The number of
characters characters must be even. Example : SSLUDF=AB02
SSLPRO From 1 to 65535 TCP/IP port number for inbound Odette SSL calls.
numeric
SSLUDO 2 to 16 hexadecimal X25 user data expected from Odette SSL Clients. The number of
characters characters must be even. Example : SSLUDF=AB02
SSLSAO 1 to 5 numeric X25 sub address expected from Odette SSL Clients.
characters
SSLTRC 1 numeric character 0/1 - '0' is the default. '1' activates the environment trace of the SSL
handler. The trace is written in a SYSPRINT file of the ANM.
SSLTIM 1 to 6 numeric Number of seconds during which the SSL session identifier is kept. The
characters default is 86400 seconds.
SSLTL1 1 alpha characters N/Y: this parameter defines if TLS V1 protocol is supported. default is
Yes.
SSLVE3 1 alpha characters N/Y: this parameter defines if SSL V3 protocol is supported. default is
Yes.
SSLVE2 1 alpha characters N/Y: this parameter defines if SSL V2 protocol is supported. default is No.
SSLCIP 2 to 32 hexadecimal Cipher suite: indicates preferences from options supported by z/OS SSL
characters services. The number of charaters must be even. The default is the z/OS
SSL services default :
050435363738392F303132330A1613100D0915120F0C0306020100
Example: SSLCIP=09060504
Appendix D / Initialization Parameters D-9
ACTEXT 4 alpha The ACTEXT parameter of CONT makes it possible to ignore a return code from
characters a user exit (UEXJNL=) other than 0. The Monitor deactivates the exit.
The ACTEXT parameter of STOP makes it possible to stop Connect:Express if
the user exit (UEXJNL=) ends with a return code other than zero. If this return
code is between 64 and 128, Connect:Express places an 80-character message in the
SYSLOG file from the exit through the communication area.
Examples:
CONT, STOP
APLNUM 1 Numeric This parameter can have two forms. In the first form, APLNUM indicates the number of
character applications (address spaces) connected to the Server. This address space receives the
end of transfer notifications. The maximum authorized value is 8.
Examples:
4, 8
NOTE: Applications are connected to the sub-system. You can connect as many
applications to each server as to the manager. For example, if 4 applications can be
connected to each server or to the manager and 4 servers are active, 20 applications can
be connected to the monitor through the SYSPLEX.
- or -
1+2 Numeric In the second form, APLNUM lets you indicate the number of applications and the number
character(s) of stacked entries (1 to 32) for each application. If the previous form is used, the default is
8. Each entry uses 512 bytes of CSA. The application table and the stack are initialized
only after an z/OS IPL or if "$LOAD$" has been issued during the previous session of the
Connect:Express Monitor.
Examples:
(4, 8) or (24,16)
CMDPRE 1 alphanumeric CMDPRE is the unique prefix character of the subsystem command. All commands
character intended for the Monitor can be transmitted by MODIFY or through the subsystem feature.
Examples:
F TOMJOB,P APM=01
or
+P APM=01
Note: Only some commands are processed by the server, like $LOAD$ and SNAP. See
Appendix C for a list of monitor commands.
MAXSRQ 2 Numeric MAXSRQ is the maximum number (64) of IEFSSREQ issued simultaneously by TSO
characters users or batch JOBs using "L0B2Z20".
Examples: 08, 12, 16
Note: This parameter applies to the local subsystem image.
MSGPRX 4 alphanumeric MSGPRX represents the four prefix characters used in messages transmitted by the
characters Monitor.
Examples: TOM1, TOM2, TOMP, and so on.
D-10 Connect:Express z/OS Administration Guide
TOMACB 8 alphanumeric TOMACB is the name of the VTAM application allocated to the Monitor for SNA
characters sessions with local Monitors of the same cross-domain. These Monitors ensure
prefix of transmission of requests from one machine to the central monitor by a defined VTAM
APLFX link. (See Appendix E, Definition of VTAM Resources.) This parameter is only used in a
(6) + 00 local/global Connect:Express environment. If Connect:Express is operating alone,
TOMACB must be coded with the value NONE.
Examples: TOMAPLID, MASTLTOM, ANMAPP00
TOMLCL 2 numeric TOMLCL indicates the number of simultaneous SNA sessions (1 per local
characters Connect:Express) with a limit of 16. This parameter is only used in a local/global
Connect:Express environment. If Connect:Express is operating alone (TOMACB =
NONE), TOMLCL must be coded with the value 00.
If TOMACB=NONE _TOMLCL=00
Examples: 00 ..... 16
DAPM02 1 to 14 Standard
alphanumeric Example: DAPM02=(H/16/Z)
characters In this example, the APM is not started by Connect:Express at
initialization, but can be submitted later by Connect:Express through an
operator command with 16 servers for class Z requests.
AFMALL 1 alphanumeric This parameter is used to manage the LIST and NLIST commands received from FTP
character clients, and the files a client is authorized to transfer.
If AFMALL=N, the response to LIST and NLIST will consist of all file definitions that are
available to the current FTP Client, excluding definitions available for ALL Partners. The
file definitions (screen 2/5) which has the Client name in the ‘TRANSMITTING
PARTNER’ or ‘RECEIVING PARTNER’ fields will be selected. The file definition that has
a Partner list in one of these two fields is selected if the client is in the list. The client is
authorized to transfer $$ALL$$ files.
If AFMALL=Y, the response to LIST and NLIST will consist of all file definitions that are
available to the current FTP Client, including definitions available for ALL partners
($$ALL$$ or * in the Transmitting Partner or Receiving Partner fields).The client is
authorized to transfer $$ALL$$ files.
If AFMALL=S, the response to LIST and NLIST will consist of all file definitions that are
available to the current FTP Client, excluding definitions available for ALL Partners. The
file definitions (screen 2/5) which has the Client name in the ‘TRANSMITTING
PARTNER’ or ‘RECEIVING PARTNER’ fields will be selected. The file definition that has
a Partner list in one of these two fields is selected if the client is in the list. The client is
NOT authorized to transfer $$ALL$$ files.
Example: AFMALL=Y
AFMPRC 6 to 8 AFMPRC is the name of the started procedure for the auxiliary FTP manager.
alphanumeric Example:
characters AFMPRC=TOM3AFM
Results in:
S TOM3AFM.TOM3AFM
D-12 Connect:Express z/OS Administration Guide
AFMPRF 8 alphanumeric The AFMPRF parameter indicates the general file profile used for incoming FTP
characters transfers.This symbolic name must correspond to a file directory entry. If an FTP client
request doesn’t specify the file profile, the default for this Partner is used. If no default
profile is defined in the FTP Partner entry, this general default name is used.
Example: FTPDEF
HTTPLST 3 fields This parameter is used with the Connect:Express HTTP option. It is composed of 3
(6,5,5) subparameters, separated by a comma, and placed between parenthesis. They provide
the default options for sending the list to the http user. The first subparameter indicates
if a list must be sent (LIST) or (NOLIST). The second subparameter indicates if the list
contains the files control table (FCT) definitions or not (NOFCT), the third subparameter
indicates if the list contains hold requests (RCT) or not (NORCT). The second and third
subparameters are omitted if the first subparameter is NOLIST. See the HTTP Option
Guide for more information about implementing http list rights.
Examples: (NOLIST,,), (LIST,NOFCT,RCT)
UEXFTS 1 alphanumeric These optional UEXF.. fields are the default names of beginning and end of transfer
UEXFTE character exits. UEXFTS is for transmit-start-exit, UEXFTE is for transmit-end-exit, UEXFRS
UEXFPS is for receive-start-exit, and UEXFRE is for receive-end-exit. If any UEXF.. is
UEXFPE specified, and no name is set in the corresponding field of the current File Entry
definition, then this exit is used. If NONE is specified in the File Directory definition,
NO exit is used not even the UEXF.. default exit. For example, you can use these
parameters for installing the Utilities option L1GFIUE1 general exit and make it
available for most files.
UPRFCT 1 alphanumeric UPRFCT can be set to Y to allow any z/OS/CLIST command to be executed from
character command fields of a file directory entry.
If UPRFCT is set to N, no command is executed, and an informational message is
issued. This parameter is optional, and the default value is Y.
Appendix D / Initialization Parameters D-13
LRECLT 1 alphanumeric The LRECLT parameter provides extra control for the file allocation parameter
character received from a remote transmitter. The Record Length parameter received from a
sender may or may not be checked.
If LRECLT=Y, the LRECL defined in the file entry for creating the file, or the LRECL
of a pre-allocated file, must match the LRECL parameter sent by the transmitter.
If LRECLT=N, no verification is performed. This means that by combining LRECLT
and RECFMT parameters, you can receive a fixed record length file into a variable
record length file or receive a variable record length file with your own maximum
record length that can be different from the transmitter’s maximum record length.
The verification is done during transfer of the file, and the length of each record
received must be consistent with the allocation LRECL .
RECFMT 1 alphanumeric The RECFMT parameter provides extra control for the file allocation parameter
character received from a remote transmitter. The Record format parameter received from the
sender may or may not be checked.
If RECFMT=Y, the RECFM defined in the file entry for creating the file or the
RECFM of a pre-allocated file, must match the RECFM parameter sent by the
transmitter.
If RECFMT=N, no verification is performed. This means that by combining LRECLT
and RECFMT parameters, you can receive a fixed record length file into a variable
record length file or receive a variable record length file with your own maximum
record length that can be different from the transmitter’s maximum record length.
The verification is done during transfer of the file, and the length of each record
received must be consistent with the allocation LRECL.
ODTUDF 1 to 4 This is the X25 User Data Field expected for ODETTE FTP incoming calls. When
alphanumeric Connect:Express receives this string in the X25 Call packet, it assumes that the
characters caller is an ODETTE FTP Partner. The ODTUDF parameter is processed before the
ODTSAD described below.
Note: The first character must be é (hexadecimal "C0").
Example: éODT
ODTSAD 1 to 8 numeric This is the X25 sub-address expected for ODETTE FTP incoming calls. When
characters Connect:Express receives this string in the X25 Call packet, it assumes that the
caller is an ODETTE FTP Partner. The ODTSAD parameter is processed after the
ODTUDF described above.
Examples: 9 , 45
E E E SYSCHK SYSIN
D E D SYSCHK SYSIN
O E E SYSIN SYSIN
E D E SYSCHK SYSIN
D D D SYSCHK SYSIN
O D D SYSIN SYSIN
This appendix provides definitions of the VTAM resources for Connect:Express. It includes definitions of an
application major node, a logmode, a switched major node for X.25, an interpret table for transparent PAD,
and an X25NPSI definition for X.25 links.
Application Description
ANMAPP This is the value of the APLPFX= Connect:Express parameter that you set. All the applications
used by ANM have the same 6-character prefix coded in the APLPFX initialization parameter of
Connect:Express. It is user-definable.
ANMAPP00 This is an optional application name. It is only needed if Connect:Express global-local functions
are in use and if TOMLCL does not equal zero. To use ANMAPP00, the TOMACB parameter of a
global Connect:Express must refer to the application. This application is used by the
Connect:Express address space.
ANMAPP01 This is the ACB name of the ANM SNA application-to-application handler for transfers through an
SNA network.
ANMAPP02 This is the ACB name of the ANM DATE CTCP which handles switched virtual circuits on X.25
links dedicated to the ANM.
ANMAPP03 This is the ACB name of the ANM PAD/PCNE handler which manages data transfer on X.25 links
dedicated to the ANM.
ANMAPP05 This is the ACB name of the ANM 3270 handler which manages sessions with TOMPC running
on PCs using a 3270 emulation card.
ANMAPP06 This is the ACB name of the ANM GATE CTCP which handles switched virtual circuits and
manages data transfer on X.25 links, shared with other applications.
ANMAPP07 This is the optional ACB name of the ANM LU6.2 handler. You must estimate the EAS,
AUTOSESS, DSESLIM, DMINWL, and DMINWR parameters based on your environment.
E-2 Connect:Express z/OS Administration Guide
Connect:Express Logmodes
The logmode must be specified for LU6.2 Partners and can be specified for 3270 TEDPC and SNA
application-to-application Partners in the COS table. LOGTOM is the logmode table example with standard
ANM logmodes. The screen below shows examples of standard ANM logmodes.
LOGTOM MODETAB
***********************************************************************
* ANM SNA APPLICATION-TO-APPLICATION LOGMODE *
SNAHND01 MODEENT LOGMODE=SNAHND01, X
FMPROF=X'03', X
TSPROF=X'03', X
PRIPROT=X'B0', X
SECPROT=X'B0', X
SRCVPAC=X'02', X
SSNDPAC=X'02', X
PSNDPAC=X'02', X
COMPROT=X'0040'
***********************************************************************
* ANM LU6.2 HANDLER LOGMODE *
* FOR INDEPENDENT LU *
LU6P2I01 MODEENT LOGMODE=LU6P2I01, X
FMPROF=X'13', X
TSPROF=X'07', X
PRIPROT=X'B0', X
SECPROT=X'B0', X
COMPROT=X'50B1', X
RUSIZES=X'8585', X
TYPE=X'00', X
PSERVIC=X'060200000000000000000300', X
ENCR=B'0000'
Appendix E / Definition of VTAM Resources E-3
***********************************************************************
* ANM LU6.2 HANDLER LOGMODE *
* FOR INDEPENDENT LU *
LU6P2I02 MODEENT LOGMODE=LU6P2I02, X
FMPROF=X'13', X
TSPROF=X'07', X
PRIPROT=X'B0', X
SECPROT=X'B0', X
COMPROT=X'50B1', X
RUSIZES=X'8989', X
TYPE=X'00', X
PSERVIC=X'060200000000000000000300', X
ENCR=B'0000'
***********************************************************************
* ANM LU6.2 HANDLER LOGMODE *
* FOR DEPENDENT LU *
LU6P2D01 MODEENT LOGMODE=LU6P2D01, X
FMPROF=X'13', X
TSPROF=X'07', X
PRIPROT=X'B0', X
SECPROT=X'B0', X
COMPROT=X'50B1', X
RUSIZES=X'8585', X
TYPE=X'00', X
PSERVIC=X'060200000000000000000000', X
ENCR=B'0000'
***********************************************************************
* ANM LU6.2 HANDLER LOGMODE *
* FOR DEPENDENT LU *
LU6P2D02 MODEENT LOGMODE=LU6P2D02, X
FMPROF=X'13', X
TSPROF=X'07', X
PRIPROT=X'B0', X
SECPROT=X'B0', X
COMPROT=X'50B1', X
RUSIZES=X'8989', X
TYPE=X'00', X
PSERVIC=X'060200000000000000000000', X
ENCR=B'0000'
MODEEND
END
E-4 Connect:Express z/OS Administration Guide
The control unit shown in the PC Connection Type can be real, PC-emulated, or a black box such as a protocol
converter. The z/OS Connect:Express expects a 3270 Extended Data Stream from the PC connection.
Appendix E / Definition of VTAM Resources E-5
LINE ...
PU
(termname) LU ...,DLOGMOD=D4C3278x,...
3270 Non-SNA BSC Defined by the NCP/EP generation input stream, including:
LINE...
CLUSTER...
3270 SNA-SDLC Local Defined in a VTAMLST major node and the node is defined as:
PU ...
(termname) LU ...,DLOGMOD=D4A3278x,...
3270 Non-SNA Local Defined in a VTAMLST major node and the node is defined as:
The switched major node must have as many PU/LU pairs as the number of SVCs on the corresponding X.25
link. The IDNUM values are the default values computed during generation of the NCP.
Note: The LOGTAB parameter specifying the Interpret table name is necessary and only valid for PAD links
on MCH in GATE=GENERAL or GATE=NO.
INTPSRTM INTAB
LOGCHAR APPLID=(APPLICID,ANMAPP01),SEQNCE=' PESIT'
LOGCHAR APPLID=(APPLICID,ANMAPP01),SEQNCE=' A '
LOGCHAR APPLID=(APPLICID,ANMAPP01),SEQNCE=' R '
ENDINTAB
END
The first byte of the SEQNCE parameter value must be binary 0 (hex on). The PAD Partner can call on any
X.25 link, even one not seen by the ANM.
Appendix E / Definition of VTAM Resources E-7
Definition of X25NPSI
An X25NPSI definition is shown in the following example. In the definition of MCH130, the parameter
PAD=TRANSP enables PAD links on this X.25 link (GATE=GENERAL). MCH131 is dedicated to the ANM.
Connect:Express supports PCNE and PAD LLC types.
Example:
************************************************************************
* *
*--------------------------------------------------------------------- *
* ADR LINE LU MCH SPEED CVC CVP NUMBER USER SWITCHED *
*--------------------------------------------------------------------- *
* 022 MCH130 XU13022 9600 8 1 192081379 PSR GATE *
* 023 MCH131 XU13023 9600 8 1 192081926 PSR DATE *
* *
************************************************************************
X25BUILD MCHCNT=9, NUMBER OF MCHS *
IDNUMH=03, IDNUM FOR PAD = 00XXX *
SNAP=NO, NO INTERNAL TRACE *
TYPSYS=OS, SYSTEM OS/VS *
MODEL=3725, COMM. CONTROLLER NAME *
MAXPIU=4K, *
VERSION=V4
X25NET NETTYPE=1, TRANSPAC NETWORK *
CPHINDX=4, 4 MACRO X25VCCPT *
OUHINDX=2, 2 MACRO X25OUFT *
DM=YES LAPB
X25VCCPT INDEX=1, DEFINE VCCPTIT ENTRY *
MAXPKTL=128, MAX PACKET LENGTH *
VWINDOW=3 TRANSMIT/RECEIVE WINDOW
.
.
X25OUFT INDEX=1 DEFINE OUFTIT ENTRY
.
.
Continued
E-8 Connect:Express z/OS Administration Guide
*----------------------------------------------------------------------*
* *
* MCH130-ADDRESS 022 - *
* *
* CHARACTERISTICS: SVC NUMBER.......... 8 *
* RATE................ 9600 *
* WINDOW (FRAME)...... 7 *
* DELAY............... 1600 *
* WINDOW (PACKET)..... 3 *
* PACKET SIZE......... 128 *
* TAXATION RULE....... NON *
* *
*----------------------------------------------------------------------*
MCH130 X25MCH ADDRESS=022, LINE INTERFACE ADDRESSES *
LCGDEF=0(7), LOGICAL CHANNEL GROUP IS 0 TO 7 *** *
FRMLGTH=131, FRAME LENGTH (128 + 3) *
MWINDOW=7, FRAME WINDOW *
LLCLIST=(LLC0,LLC2,LLC3,LLC4,LLC5), PCNE,PSH,GATE PAD *
GATE=GENERAL, GATE FUNCTION SUPPORTED *
PAD=TRANSP, TERMINALS SUPPORTED VIA THE PAD *
SUBADDR=YES, SUBADDRESSING IS USED ON THIS LINK *
LLC0=0, PCNE *
LLC2=2, PSH *
LLC3=3, QLLC *
LLC4=4, GATE *
LLC5=5, PAD *
TPTIMER=2.5, X25 T1 TIMER IN SECONDS *
TDTIMER=2, TIMER TO WAIT FOR ND RETRIES *
NPRETRY=10, NUMBER OF RETRIES WHEN TPTIMER ELAPSE*
NDRETRY=2, NUMBER OF (TP*NP) RETRIES *
DBIT=NO, D BIT NOT USED IN PCNE *
LUNAME=XU13022, MCH LU NAME *
PUNAME=XP13022, MCH PU NAME *
LCN0=USED, LOGIC PATH 0 USED WITH XPAC *
NCPGRP=G13X250, *
PKTMODL=8, SEQUENCE PACKETS: MODULO 8 *
PROTCOL=LAPB, LAPB RECOMMEND. *
STATION=DTE, THIS PHYSICAL LINK IS A DTE *
ANS=CONT, *
OWNER=HOST02, *
TRAN=NO NO ASCII TRANSLATION
LCG0 X25LCG LCGN=0 LCG NUMBER FOR SUBSEQUENT VC
************************************************************************
* *
* LOGICAL CHANNEL 0-07 CVC *
* *
************************************************************************
*
L13X250 X25VC LCN=(0,7), LOGICAL CHANNEL ** *
VCCINDX=1, ENTRY IN VCCPTIT TABLE *
IDNUMT=A02E, IDNUM ATTRIBUTION *
TYPE=SWITCHED, SVCs *
CALL=INOUT, INCOMING AND OUTCOMING CALLS *
MAXLU=1, MAX LU NUMBER *
NCPGRP=G13CVC0, CVC GROUP NAME *
OWNER=HOST02, *
OUFINDX=1 ENTRY IN OUFTIT TABLE
.
Continued
Appendix E / Definition of VTAM Resources E-9
*----------------------------------------------------------------------*
* *
* MCH131-ADDRESS 023 -
* *
* CHARACTERISTICS: SVC NUMBER.......... 8 *
* RATE................ 9600 *
* WINDOW (FRAME)...... 7 *
* DELAY............... 1600 *
* WINDOW (PACKET)..... 3 *
* PACKET SIZE......... 128 *
* TAXATION RULE....... YES *
* *
*----------------------------------------------------------------------*
MCH131 X25MCH ADDRESS=023, LINE INTERFACE ADDRESSES *
LCGDEF=0(7), LOGICAL CHANNEL GROUP IS 0 TO 7 *
FRMLGTH=131, FRAME LENGTH (128 + 3) *
MWINDOW=7, FRAME WINDOW *
LLCLIST=(LLC0,LLC5), PCNE,PSH,PAD *
GATE=DEDICAT, DATE FUNCTION SUPPORTED *
PAD=TRANSP, PAD CMNDS UP TO USER *
TPTIMER=2.5, X25 T1 TIMER IN SECONDS *
TDTIMER=2, TIMER TO WAIT FOR ND RETRIES *
NPRETRY=10, NUMBER OF RETRIES WHEN TPTIMER ELAPSE*
NDRETRY=2, NUMBER OF (TP*NP) RETRIES *
DBIT=NO, D BIT NOT USED IN PCNE *
LUNAME=XU13023, MCH LU NAME *
PUNAME=XP13023, MCH PU NAME *
LCN0=USED, LOGIC PATCH 0 USED WITH XPAC *
NCPGRP=G13X251, *
PKTMODL=8, SEQUENCE PACKETS: MODULO 8 *
PROTCOL=LAPB, LAPB RECOMMEND. *
STATION=DTE, THIS PHYSICAL LINK IS A DTE *
ANS=CONT, *
OWNER=HOST02, *
TRAN=NO NO ASCII TRANSLATION
LCG1 X25LCG LCGN=0 LCG NUMBER FOR SUBSEQUENT VC
************************************************************************
* LOGICAL CHANNEL 0-07 CVC *
************************************************************************
L13X251 X25VC LCN=(0,7), LOGICAL CHANNEL ** *
VCCINDX=1, ENTRY IN VCCPTIT TABLE *
IDNUMT=A01E, IDNUM ATTRIBUTION *
TYPE=SWITCHED, CVC *
CALL=INOUT, INCOMING AND OUTGOING CALL (DATE) *
MAXLU=1, MAX LU NUMBER *
NCPGRP=G13CVC1, CVC GROUP NAME *
OWNER=HOST02, *
OUFINDX=1 ENTRY IN OUTFIT TABLE
.
************************************************************************
* X25END MACRO *
************************************************************************
X25END LSTUACB=YES,X25VTAM=YES
END
E-10 Connect:Express z/OS Administration Guide
Appendix F
This appendix describes the DD Names used by Connect:Express in different address spaces.
DDNAMES
The following tables describe the JCL files that Connect:Express uses for initialization, processing, and
logging. The DDNAMES are listed for each type of address space.
DDname Description
SYSIN A card-type file which contains Connect:Express and ANM execution parameters. See Appendix
D for detailed information about the SYSIN file.
CXPLEX A card type file which contain SYSPLEX configuration parameters. See Chapter 1 of this guide for
more information about the Sysplex Environment.
SYSFIL The File directory in the form of a VSAM KSDS file. It is initialized during installation of
File directory Connect:Express, and it contains characteristics about the data to be transferred.
SYSPAR A Partner directory in the form of a VSAM KSDS file. It is initialized during installation of
Partner directory Connect:Express and contains information about other Connect:Express hosts that your host can
do transfers with.
SYSCHK A checkpoint file in the form of a sequential file. It is initialized during the installation of
Connect:Express, and is used by Connect:Express to write its internal tables each time they are
modified. SYSCHK is read during a hot start to restore tables to their state before interruption. To
increase integrity, this file can be duplicated by the DDNAME file *SYSCHK2* and allocated to
another volume.
SYSLOG A trace of transfer events in the form of a sequential file. It is initialized during installation of
Connect:Express. You can use a wrap-around file or a SYSOUT file. The *SYSLOG* records all
the events related to requests and transfers. See Appendix B for a list of SYSLOG messages
issued by the monitor.
SYSMSG A SYSOUT file that contains messages sent by Connect:Express. These messages can be
generated during Connect:Express initialization, when it stops, or when an error occurs. See
Appendix B for a list of WTO messages issued by the monitor.
F-2 Connect:Express z/OS Administration Guide
DDname Description
SYSPRT A SYSOUT file where the processed SYSIN cards are summarized.
SYSPRTX A SYSOUT file where the processed CXPLEX cards are summarized.
SYSRCY A sequential file that is initialized during Connect:Express installation. It records requests from
local users when Connect:Express is not up. This file is called the Recovery file.
SYSPRM A PDS file which contains members used for PDS unload using member selection and Partner
lists.
SYSEVT Describes a card-type file. It contains planned transfer requests and can be empty. See the
member #EVENT in *PARMLIB* for an example.
SYSJCL Contains model JCL members that are executed during specific types of transfers.
SYSPCH A SYSOUT file (INTRDR) which is read by JES, and used by Connect:Express to submit jobs to
JES for execution.
SYSANM A card-type file containing the ANM initialization parameters. The parameters are read and
controlled by the Connect:Express Monitor program, PIB2P000 from the Connect:Express SYSIN
file and written in the *SYSANM* file.
SYSSNA (optional) A card-type file which combines LU name and Partner name parameters. This option can be
implemented if an alternate LU name is used to accept incoming calls from this Partner or sends
outgoing calls to this Partner. If the LU name is replaced by the asterisk (*) character, no incoming
control is performed. It is also possible to remove controls on calls by Connect:Express/PC 3270
by coding in the first parameter and keyword (LU2BYPAS). See member #SYSSNA in
*PARMLIB* for an example.
SYSX25 (optional) A card-type file which combines all X.25 addressing parameters and the Partner name.
This option can be implemented when alternate X.25 addresses are used to accept incoming
calls from this Partner or to send outgoing calls to this Partner. If the X.25 address is replaced by
the asterisk (*) character, no control is done for an incoming call from this Partner. See member
#SYSX25 in *PARMLIB* for an example.
SYSTCP (optional) A card-type file which combines all TCP addressing parameters and the Partner name. This
option can be implemented when alternate TCP/IP addresses are used to accept incoming calls
from this Partner or to send outgoing calls to this Partner. If the TCP address/host is replaced by
the asterisk (*) character, no control is done for an incoming call from this Partner. See member
#SYSTCP in *PARMLIB* for an example.
SYSINEXT A card-type file used by L1B2PDIX standard exits driver, UEXJNL=L1B2PDIX (see *SAMPLIB*
(optional) EX#DIX).
SYSCE1 A card-type file used by the L1GFICE1 optional connection exit, included in the Utilities option.
(nonstandard option)
OUTCE1 A output type file used by the L1GFICE1 optional connection exit, included in the PAC option.
(nonstandard option)
SYSPRINT Required when using the IDCAMS functions with the L1GFICE1 utility.
Appendix F / JCL Files for the Connect:Express Monitor F-3
DDname Description
SYSPR20 Required when using the API L0B2Z20 module through the L1GFICE1 utility.
SYSPROC Required when implementing the job submission functions of the L1GFICE1 utility.
DDname Description
SYSIN A card file containing the ANM initialization parameters. This file is written by the TOM Address
(SYSANM file) space before starting the ANM.
ANMSSL A PDS file containing the SSL configuration files, SSLCFG, the Dn control files and the SSL
configuration selection file, SYSSSL. required if SSLCFG=Y in the SYSIN file of TOM address
space
SYSCFG Reporting file of the SSL profiles and SYSSSL files loading process
DDname Description
CHKMODEL This template provides information about the structure of the checkpoint file and where to create
it. The request number is included in the data set name of the checkpoint file.
SYSMSG A SYSOUT file that contains messages sent by the APM. These messages can be generated
during Connect:Express initialization, when it stops, or when an error occurs. See Appendix B for
a list of WTO messages issued by the APM.
SYSLOG A trace of transfer events in the form of a sequential file that is initialized during the installation of
Connect:Express. You can use a wrap-around file or a SYSOUT file. The *SYSLOG* records all
the events related to requests and transfers. The information found there supplements the TOM
AS SYSLOG information. See Appendix B for a list of SYSLOG messages issued by the APM.
SYSPRINT This is required when using the IDCAMS functions with the L1GFIUE1 utility.
SYSPR20 This is required when using the API L0B2Z20 module through the L1GFIUE1 utility.
SYSPROC This is required when implementing the job submission functions of the L1GFIUE1 utility.
F-4 Connect:Express z/OS Administration Guide
DDname Description
SYSUE1 A card-type file used by the L1GFIUE1 optional file exit. The L1GFIUE1 is included in the Utilities
option.
DDname Description
SYSLOG Shows the execution parameters that the AFM processed from its SYSPARM file.
AFMLOG A trace of FTP events in the form of a SYSOUT file. Do not change the DSCB. This information
supplements the TOM AS SYSLOG information. The AFMLOG messages are described in the
FTP Guide.
SYSPARM The AFM SYSIN file. This is a card-type file which contains the AFM execution parameters.
MIFPARM A card-type file which contains parameters for communications with the monitor. Do not change
this file.
SYSCE1 A card-type file used by the L1GFICE1 optional connection exit, included in the Utilities option.
(nonstandard option)
OUTCE1 A output type file used by the L1GFICE1 optional connection exit, included in the PAC option.
(nonstandard option)
SYSPRINT Required when using the IDCAMS functions with the L1GFICE1 utility.
SYSPR20 Required when using the API L0B2Z20 module through the L1GFICE1 utility.
SYSPROC Required when implementing the job submission functions of the L1GFICE1 utility.
DDname Description
SYSPRINT Required when using IDCAMS functions from the L1GFIUE1 utility.
SYSPR20 Required when using the API L0B2Z20 module through the L1GFIUE1 utility.
Appendix F / JCL Files for the Connect:Express Monitor F-5
DDname Description
SYSPROC Required when implementing the job submission functions of the L1GFIUE1 utility.
SYSUE1 A card-type file used by the L1GFIUE1 optional file exit. The L1GFIUE1 is included in the Utilities
option.
This appendix describes how to use the Auxiliary Trace Manager services.
ATM Messages
ATM messages are prefixed by the string 'ATM' and the Monitor subsystem number. The following list
explains the messages you may find in the ATM SYSLOG file.
Code Description
Code Description
Code Description
JESJCLIN 1 PSRAT4 X 2
JESMSGLG JES2 2 PSRAT4 X 2
JESJCL JES2 3 PSRAT4 X 52
JESYSMSG JES2 4 PSRAT4 X 2
$ INTTEXT JES2 5 PSRAT4 A 0
SYSLOG PSRAT4 104 PSRAT4 V 0
R0042562 PSRAT4 110 PSRAT4 A LOCAL 83
A9323570 PSRAT4 111 PSRAT4 A LOCAL 84
R0042601 PSRAT4 112 PSRAT4 A LOCAL 191
R0042602 PSRAT4 113 PSRAT4 A LOCAL 188
R0042604 PSRAT4 114 PSRAT4 A LOCAL 191
R0042605 PSRAT4 115 PSRAT4 A LOCAL 106
R0042607 PSRAT4 116 PSRAT4 A LOCAL 191
R0042608 PSRAT4 117 PSRAT4 A LOCAL 188
R0042610 PSRAT4 118 PSRAT4 A LOCAL 191
R0042611 PSRAT4 119 PSRAT4 A LOCAL 188
The trace files are written in XML format. The general structure respects the following rules:
Inbound and outbound messages are identified by a number. For example: <IN_nnnnn> </IN_nnnnn> or
<DATA_IN_nnnnn> </DATA_IN_nnnnn>. Messages are associated with a time stamp
<TIME>hh:mm:ss:cc </TIME>.
Negotiation and transfer synchronization messages are delimited by <IN_nnnnn> and <OU_nnnnn>; file
data messages are delimited by <DATA_IN_nnnnn> and <DATA_OU_nnnnn>.
Protocol commands are delimited by <CMD> </CMD: they are developed according to the protocol
syntax (PeSIT and Odette).
Data messages are delimited by <MSG> </MSG>.
Data and negotiation messages exchanged are displayed in a SNAP format, with three columns:
hexadecimal view, EBCDIC view, and ASCII view.
Connect:Express fields that are used during file transfer refer to the table shown in “Connect:Express
Fields” on page G-16. They are displayed after negotiation is ended for the field.
Appendix G / Using Protocol Traces G-5
<TRACE ID=R0042562>
<OU_nnnn >
<TIME>hh:mm:ss:cc</TIME>
<CMD>
Protocol command as sent, in a SNAP format
</CMD>
<Commande 2>
<param1>value</param1>
<param2>value</param2>
<param3>value</param3>
<paramn>value</paramn>
</Commande 2>
</OU_nnnn >
<DAT_OU_nnnn >
<TIME>hh:mm:ss:cc</TIME>
<MSG>
Data message as sent, in a SNAP format
</MSG>
</DATA_OU_nnnn >
</TRACE>
<TRACE ID=R0044683>
<PESIT CLIENT>
<REQN>00044683</REQN><PNAM>O1X01847</PNAM><PROT>PESIT</PROT><TYPL>TCP</TYPL>
<TCPA>127.000.000.001</TCPA><TCPH></TCPH>
<OU_0001><TIME>08:12:34:79</TIME><CMD>
00000000 001B4020 00110303 03073704 03010737 06010107 03002010 160100
</CMD>
<CONNECT>
<PI003 L=003>030737</PI003>
<PI004 L=003>010737</PI004>
<PI006 L=001>01</PI006>
<PI007 L=003>002010</PI007>
<PI022 L=001>00</PI022>
</CONNECT>
</OU_0001>
<IN_0002><TIME>08:12:34:88</TIME><CMD>
00000000 000E4021 11120601 01070300 2010
</CMD>
<ACONNECT>
<PI006 L=001>01</PI006>
<PI007 L=003>002010</PI007>
</ACONNECT>
</IN_0002>
<TDIR></TDIR><LFID>SIT00011</LFID><LPHN>PSR$REC.PS.F080.MEGA</LPHN><FSIZ>0000000
<OU_0003><TIME>08:12:34:98</TIME><CMD>
00000000 007DC011 12000914 03030307 37040301 07370B01 0C0C0532 32323232 0D02AE
00000020 10010211 01011902 0FD01E0D 20015025 08534954 30303031 3128042A 0204EE
00000040 0E330C39 37313230 39303935 38353963 2C404040 40404040 40404040 404040
00000060 40404040 40404040 40404040 40404040 40404040 40404040 40400000 00
</CMD>
<CREATE>
<PI009 L=020></PI009>
<PI003 L=003>030737</PI003>
<PI004 L=003>010737</PI004>
<PI011 L=001>0C</PI011>
<PI012 L=005>3232323232</PI012>
<PI013 L=002>AE8B</PI013>
<PI016 L=001>02</PI016>
<PI017 L=001>01</PI017>
<PI025 L=002>0FD0</PI025>
<PI030 L=013></PI030>
<PI032 L=001>50</PI032>
<PI037 L=008>SIT00011</PI037>
<PI040 L=004></PI040>
<PI042 L=002>04EE</PI042>
<PI050 L=014></PI050>
<PI051 L=012>971209095859</PI051>
<PI099 L=044>ààààààààààààààààààààààààààààààààààààààààà </PI099>
</CREATE>
</OU_0003>
<IN_0004><TIME>08:12:35:14</TIME><CMD>
00000000 000FC030 11000203 00000019 020FD0
</CMD>
<ACREATE>
<PI002 L=003>000000</PI002>
<PI025 L=002>0FD0</PI025>
Continued
Appendix G / Using Protocol Traces G-7
</ACREATE>
</IN_0004>
<NMGS>04048</NMGS><SYNC>00032+16</SYNC><FAPI>010737030737000C22222971209095859</
<OU_0005><TIME>08:12:35:19</TIME><CMD>
00000000 0006C014 1200
</CMD>
<ORF>
</ORF>
</OU_0005>
<IN_0006><TIME>08:12:35:22</TIME><CMD>
00000000 000BC033 11000203 000000
</CMD>
<AORF>
<PI002 L=003>000000</PI002>
</AORF>
</IN_0006>
<OU_0007><TIME>08:12:35:22</TIME><CMD>
00000000 0006C002 1200
</CMD>
<WRITE>
</WRITE>
</OU_0007>
<IN_0008><TIME>08:12:35:22</TIME><CMD>
00000000 000EC036 11000203 00000012 0100
</CMD>
<AWRITE>
<PI002 L=003>000000</PI002>
<PI018 L=001>00</PI018>
</AWRITE>
</IN_0008>
<FBYT>000000001000</FBYT><FNRB>000000012798</FNRB>
<OU_0009><TIME>08:12:43:04</TIME><CMD>
00000000 0006C008 1200
</CMD>
<TRANSEND>
</TRANSEND>
</OU_0009>
<IN_0010><TIME>08:12:43:63</TIME><CMD>
00000000 000BC037 11000203 000000
</CMD>
<ATRANSEND>
<PI002 L=003>000000</PI002>
</ATRANSEND>
</IN_0010>
<OU_0011><TIME>08:12:43:63</TIME><CMD>
00000000 000BC015 12000203 000000
</CMD>
<CRF>
<PI002 L=003>000000</PI002>
</CRF>
</OU_0011>
<IN_0012><TIME>08:12:43:65</TIME><CMD>
00000000 000BC034 11000203 000000
</CMD>
<ACRF>
<PI002 L=003>000000</PI002>
</ACRF>
</IN_0012>
<OU_0013><TIME>08:12:43:67</TIME><CMD>
00000000 000BC013 12000203 000000
Continued
G-8 Connect:Express z/OS Administration Guide
</CMD>
<DESELECT>
<PI002 L=003>000000</PI002>
</DESELECT>
</OU_0013>
<IN_0014><TIME>08:12:43:73</TIME><CMD>
00000000 000BC032 11000203 000000
</CMD>
<ADESELECT>
<PI002 L=003>000000</PI002>
</ADESELECT>
</IN_0014>
<OU_0015><TIME>08:12:43:91</TIME><CMD>
00000000 000B4023 12110203 000000
</CMD>
<RELEASE>
<PI002 L=003>000000</PI002>
</RELEASE>
</OU_0015>
<IN_0016><TIME>08:12:43:96</TIME><CMD>
00000000 00064024 1112
</CMD>
<RELCONF>
</RELCONF>
</IN_0016>
</PESIT CLIENT>
</TRACE>
Continued
Appendix G / Using Protocol Traces G-9
<TRACE ID=R0044687>
<PESIT CLIENT>
<REQN>00044687</REQN><LNAM>GFIPSR4</LNAM><TYPP>OTHER</TYPP><PNAM>GFIPSR4</PNAM><
<TCPA>010.020.129.003</TCPA><TCPH>MVSB.CSG.STERCOMM.COM</TCPH>
<OU_0001><TIME>08:17:22:29</TIME><CMD>
00000000 D7C5E2C9 E3404040 C7C6C9D7 E2D9F440 D7E2D940 40404040
</CMD>
</OU_0001>
<IN_0002><TIME>08:17:22:34</TIME><CMD>
00000000 C1C3D2F0
</CMD>
</IN_0002>
<OU_0003><TIME>08:17:22:34</TIME><CMD>
00000000 00304020 00110307 47464950 53523404 07474649 50535234 05085053 522020
00000020 20200601 02070300 40031601 02170101
</CMD>
<CONNECT>
<PI003 L=007>GFIPSR4</PI003>
<PI004 L=007>GFIPSR4</PI004>
<PI005 L=008>PSR </PI005>
<PI006 L=001>02</PI006>
<PI007 L=003>004003</PI007>
<PI022 L=001>02</PI022>
<PI023 L=001>01</PI023>
</CONNECT>
</OU_0003>
<IN_0004><TIME>08:17:22:35</TIME><CMD>
00000000 001B4021 11120508 50535220 20202020 06010207 03004003 170101
</CMD>
<ACONNECT>
<PI005 L=008>PSR </PI005>
<PI006 L=001>02</PI006>
<PI007 L=003>004003</PI007>
<PI023 L=001>01</PI023>
</ACONNECT>
</IN_0004>
<TDIR>T</TDIR><TYPD>EBCDIC</TYPD><LPHN>PSR$REC.PS.F080.SHORT</LPHN><FSIZ>0000000
<FLAB>PSR$REC.PS.F080.SHORT</FLAB>
<USDS>pi99 répertoire</USDS>
<OU_0005><TIME>08:17:22 58</TIME><CMD>
00000000 0183C011 1200091C 03074746 49505352 34040747 46495053 52340B01 000C05
00000020 3144454C 0D02AE8F 10010111 01011902 07FE1E1A 20015025 15505352 245245
00000040 2E50532E 46303830 2E53484F 52542803 2A013932 1C330C30 35313232 313038
00000060 37323234 0C303030 30303030 30303030 303D0747 46495053 52343E07 474649
00000080 53523463 FE706939 392072E9 70657274 6F697265 20202020 20202020 202020
000000A0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
000000C0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
000000E0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000100 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000120 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000140 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000160 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000180 202020
</CMD>
Continued
G-10 Connect:Express z/OS Administration Guide
<CREATE>
<PI009 L=028></PI009>
<PI003 L=007>GFIPSR4</PI003>
<PI004 L=007>GFIPSR4</PI004>
<PI011 L=001>00</PI011>
<PI012 L=005>F1DEL</PI012>
<PI013 L=002>AE8F</PI013>
<PI016 L=001>01</PI016>
<PI017 L=001>01</PI017>
<PI025 L=002>07FE</PI025>
<PI030 L=026></PI030>
<PI032 L=001>50</PI032>
<PI037 L=021>PSR$REC.PS.F080.SHORT</PI037>
<PI040 L=003></PI040>
<PI042 L=001>39</PI042>
<PI050 L=028></PI050>
<PI051 L=012>051221081722</PI051>
<PI052 L=012>000000000000</PI052>
<PI061 L=007>GFIPSR4</PI061>
<PI062 L=007>GFIPSR4</PI062>
<PI099 L=254>pi99 répertoire
</CREATE>
</OU_0005>
<IN_0006><TIME>08:17:22 82</TIME><CMD>
00000000 0113C030 11000203 0000000D 02AE9019 0207FE63 FE706939 392072E9 706572
00000020 6F697265 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000040 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000060 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000080 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
000000A0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
000000C0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
000000E0 20202020 20202020 20202020 20202020 20202020 20202020 20202020 202020
00000100 20202020 20202020 20202020 20202020 202020
</CMD>
<ACREATE>
<PI002 L=003>000000</PI002>
<PI013 L=002>AE90</PI013>
<PI025 L=002>07FE</PI025>
<PI099 L=254>pi99 répertoire
</ACREATE>
</IN_0006>
<USDR>pi99 répertoire</USDR>
<FAPI>GFIPSR4 GFIPSR4 F1DEL 0512
<NMGS>02046</NMGS><SYNC>00064+03</SYNC><FRLG>00080</FRLG>
<OU_0007><TIME>08:17:22 83</TIME><CMD>
00000000 0006C014 1200
</CMD>
<ORF>
</ORF>
</OU_0007>
<IN_0008><TIME>08:17:22 84</TIME><CMD>
00000000 000BC033 11000203 000000
</CMD>
<AORF>
<PI002 L=003>000000</PI002>
</AORF>
</IN_0008>
<OU_0009><TIME>08:17:22 84</TIME><CMD>
00000000 0006C002 1200
Continued
Appendix G / Using Protocol Traces G-11
</CMD>
<WRITE>
</WRITE>
</OU_0009>
<IN_0010><TIME>08:17:22 84</TIME><CMD>
00000000 000EC036 11000203 00000012 0100
</CMD>
<AWRITE>
<PI002 L=003>000000</PI002>
<PI018 L=001>00</PI018>
</AWRITE>
</IN_0010>
<TYPC>01</TYPC><COMP>NOCOMP.</COMP>
<OU_0011><TIME>08:17:22 87</TIME><CMD>
00000000 000DC008 12001B02 06E01C01 16
</CMD>
<TRANSEND>
<PI027 L=002>06E0</PI027>
<PI028 L=001>16</PI028>
</TRANSEND>
</OU_0011>
<FBYT>000000000002</FBYT><FNRB>000000000022</FNRB>
<IN_0012><TIME>08:17:23 12</TIME><CMD>
00000000 0012C037 11000203 0000001B 0206E01C 0116
</CMD>
<ATRANSEND>
<PI002 L=003>000000</PI002>
<PI027 L=002>06E0</PI027>
<PI028 L=001>16</PI028>
</ATRANSEND>
</IN_0012>
<OU_0013><TIME>08:17:23 12</TIME><CMD>
00000000 000BC015 12000203 000000
</CMD>
<CRF>
<PI002 L=003>000000</PI002>
</CRF>
</OU_0013>
<IN_0014><TIME>08:17:23 14</TIME><CMD>
00000000 000BC034 11000203 000000
</CMD>
<ACRF>
<PI002 L=003>000000</PI002>
</ACRF>
</IN_0014>
<OU_0015><TIME>08:17:23 14</TIME><CMD>
00000000 000BC013 12000203 000000
</CMD>
<DESELECT>
<PI002 L=003>000000</PI002>
</DESELECT>
</OU_0015>
<IN_0016><TIME>08:17:23 27</TIME><CMD>
00000000 000BC032 11000203 000000
</CMD>
Continued
G-12 Connect:Express z/OS Administration Guide
<ADESELECT>
<PI002 L=003>000000</PI002>
</ADESELECT>
</IN_0016>
<OU_0017><TIME>08:17:23:48</TIME><CMD>
00000000 000B4023 12110203 000000
</CMD>
<RELEASE>
<PI002 L=003>000000</PI002>
</RELEASE>
</OU_0017>
<IN_0018><TIME>08:17:23:53</TIME><CMD>
00000000 00064024 1112
</CMD>
<RELCONF>
</RELCONF>
</IN_0018>
</PESIT CLIENT>
</TRACE>
FTP Protocol
Example of trace, type=all, server mode. Some lines are truncated, the record length of the trace file is 170
characters.
The FTP list is considered both as part of the dialog (<Lnnnn> </Lnnnn>, and part of data transfer
(<DATA_OU_nnnnn>) that is only included if type=all. <MODL> variable indicates the list structure that is
used for building the list records if it was found in the PARMFTPL file.
Appendix G / Using Protocol Traces G-13
<TRACE ID=A8580827>
<FTP SERVER>
<PNAM>FTP4</PNAM><TCPA>010.087.015.082</TCPA><TCPH></TCPH>
<IN_0001><TIME>08:58:08:28</TIME><CMD>USER FTP4 </CMD></IN_0001>
<OU_0002><TIME>08:58:08:28</TIME><CMD>331 FTP4 password please ?
<IN_0003><TIME>08:58:08:43</TIME><CMD>PASS ftp4psw </CMD></IN_0003>
<USER>FTP4</USER><DFID>FTPGCZ</DFID><DPHN>&EXTDSN</DPHN>
<OU_0004><TIME>08:58:09:17</TIME><CMD>230-FTP4 User logged on at Connect:Exp
<IN_0005><TIME>08:58:09:34</TIME><CMD>CWD FTPF </CMD></IN_0005>
<OU_0006><TIME>08:58:09:34</TIME><CMD>200 CWD Command received.
<IN_0007><TIME>08:58:09:49</TIME><CMD>PWD </CMD></IN_0007>
<OU_0008><TIME>08:58:09:49</TIME><CMD>257 "FTPGCZ " is current profile.
<IN_0009><TIME>08:58:09:65</TIME><CMD>HELP </CMD></IN_0009>
<OU_0010><TIME>08:58:09:65</TIME><CMD>214-The Connect:Express FTP commands are:
PASS, PASV, PORT, PWD, QUIT,*REIN,*REST, RETR, *RMD 214-*RNFR,*RNTO, SITE,*SM
implemented 214- 214-TYPE may be ASCII, EBCDIC, IMAGE 214-STRU may be RECORD,
PE, *LIST, *PWD, RETR, SITE, STOR, STOU, *TRC 214- 214-CONNECT:Express keyword
from monitor. 214-Profile = symbolic file name defined in the monitor directory
<IN_0011><TIME>08:58:11:43</TIME><CMD>TYPE A </CMD></IN_0011>
<OU_0012><TIME>08:58:11:43</TIME><CMD>200 Data type is ASCII , Format is NON PRI
<IN_0013><TIME>08:58:11:59</TIME><CMD>PORT 10,87,15,82,16,125 </CMD></IN_0013>
<OU_0014><TIME>08:58:11:59</TIME><CMD>200 PORT Command executed.
<IN_0015><TIME>08:58:11:74</TIME><CMD>LIST </CMD></IN_0015>
<PNAM>FTP4</PNAM><USER>FTP4</USER>
<MODL>&MBX. &DDN. &NOT &FLG
<OU_0016><TIME>08:58:11:92</TIME><CMD>125 LIST Command accepted.
<L0015>FTP4 $AA FTPSEND!PSR$REC.PS.F080.SHORT
<L0016>FTP4 $ABMAB FTPSEND!PSR$REC.PS.F080.SHORT
<L0017>FTP4 $APPLIC FTPSEND!PSR$REC.PS.F080.SHORT
<L0018>FTP4 $BENCMPH FTPSEND!PSR$REC.PS.F080.SHORT
<L0019>FTP4 $BENCMPM FTPSEND!PSR$REC.PS.F080.SHORT
<L0020>FTP4 $BENCMPV FTPSEND!PSR$REC.PS.F080.SHORT
<L0021>FTP4 $BENCMP0 FTPSEND!PSR$REC.PS.F080.SHORT
<L0022>FTP4 $BENS01 FTPSEND!PSR$REC.PS.F080.SHORT
<L0023>FTP4 $BENS02 FTPSEND!PSR$REC.PS.F080.SHORT
<DATA_OU_0017><TIME>08:58:11:99</TIME><MSG>
00000000 46545034 20202020 20202024 41412020 20202020 20202020 20202020 202020
00000020 20202020 20202020 20204654 5053454E 44215053 52245245 432E5053 2E4630
00000040 302E5348 4F525420 20202020 20202020 20202020 20202020 20202020 202020
Continued
G-14 Connect:Express z/OS Administration Guide
Etebac3 Protocol
Example of trace, type=all, client mode. Some lines are truncated, the record length of the trace file is 170
characters:
<TRACE ID=R0044715>
<ETEBAC3 CLIENT>
<REQN>00044715</REQN><TYPP>-ETB-</TYPP><PNAM>GFIPSR41</PNAM><PROT>ETEBAC</PROT><
<TCPA>010.020.129.003</TCPA><TCPH>MVSB.CSG.STERCOMM.COM</TCPH>
<FAPI>A 0080 ETEBRECVETEBAC3 PSR</FAPI>
<TDIR>T</TDIR><LFID>ETEBEMIS</LFID><LPHN>PSR$REC.PS.F080.SHORT</LPHN><FRLG>00080
<OU_0001><TIME>08:35:50:17</TIME><CMD>A 0080 ETEBRECVETEBAC3 PSR</CMD></OU_
<IN_0002><TIME>08:35:50:35</TIME><CMD>OK</CMD></IN_0002>
<DATA_OU_0003><TIME>08:35:50:38</TIME><MSG>
00000000 5BF9F461 F0F261F0 F340F1F8 7AF4F17A F3F840D7 E2D9F0F0 F0F44040 F8F3C2
00000020 40E3D6D4 F440D5D9 C1C3C540 406140F9 F461F0F2 61F0F340 F1F87AF4 F17AF3
00000040 40D7E2D9 F0F0F0F4 4040F8F3 C2C14040
</MSG></DATA_OU_0003>
<DATA_OU_0004><TIME>08:35:50:39</TIME><MSG>
00000000 5CC1C161 D4D461D1 D140C8C8 7AD4D47A E2E240E4 E4E4E4E4 E4E4E440 C3C3C3
00000020 40E2E2E2 E240D6D6 D6D6D6D6 406140C1 C161D4D4 61D1D140 C8C87AD4 D47AE2
00000040 40E4E4E4 E4E4E4E4 E440C3C3 C3C340E2
</MSG></DATA_OU_0004>
<DATA_OU_0024><TIME>08:35:50:40</TIME><MSG>
00000000 5CC7E2D6 F1E7E7E7 E7E7E7E7 E7404040 40404040 40404040 40404040 404040
00000020 40404040 40404040 40404040 40404040 40404040 40404040 40404040 404040
00000040 40404040 40404040 40404040 40404040
</MSG></DATA_OU_0024>
<FBYT>000000000002</FBYT><FNRB>000000000022</FNRB>
<OU_0025><TIME>08:35:50:40</TIME><CMD>FF</CMD></OU_0025>
<IN_0026><TIME>08:35:50:67</TIME><CMD>OKF</CMD></IN_0026>
</ETEBAC3 CLIENT>
</TRACE>
Appendix G / Using Protocol Traces G-15
<TRACE ID=R0051008>
<ETEBAC3 SERVER>
<REQN>00051008</REQN><TYPP>-ETB-</TYPP><PNAM>GFIPSR41</PNAM><PROT>ETEBAC</PROT><
<TCPA>010.020.129.003</TCPA><TCPH>MVSB.CSG.STERCOMM.COM</TCPH>
<IN_0001><TIME>04:54:25:46</TIME><CMD>A 0080 ETEBRECVETEBAC3 PSR</CMD></IN_
<FAPI>A 0080 ETEBRECVETEBAC3 PSR</FAPI>
<TDIR>R</TDIR><LFID>ETEBRECV</LFID><LPHN>PSR$TST.ETEB.GFIPSR41.D051222.A0051008<
<OU_0002><TIME>04:54:25:57</TIME><CMD>OK</CMD></OU_0002>
<IN_0003><TIME>04:54:25:83</TIME><CMD>FF</CMD></IN_0003>
<FBYT>000000000002</FBYT><FNRB>000000000022</FNRB>
<OU_0004><TIME>04:54:25:84</TIME><CMD>OKF</CMD></OU_0004>
</ETEBAC3 SERVER>
</TRACE>
Odette Protocol
Example of trace, type=all, client mode. Some lines are truncated, the record length of the trace file is 170
characters:
<TRACE ID=R0044711>
<OFTP CLIENT>
<REQN>00044711</REQN><LNAM>GFIPSR4O</LNAM><TYPP>OTHER</TYPP><PNAM>GFIPSR4O</PNAM
<TCPA>010.020.129.003</TCPA><TCPH>MVSB.CSG.STERCOMM.COM</TCPH>
<IN_0001><TIME>08:28:05:12</TIME><CMD>
00000000 494F4445 54544520 46545020 52454144 59200D
</CMD>
</IN_0001>
<OU_0002><TIME>08:28:05:12</TIME><CMD>
00000000 58314746 49505352 344F2020 20202020 20202020 20202020 20202050 535220
00000020 20202033 32373536 4259594E 30303520 20202020 00000000 00000000 0D
</CMD>
<SSID><LEV>1</LEV><CODE>GFIPSR4O</CODE><PSWD>PSR</PSWD><SDEB>32756</SDEB><SR>B</
SSID>
</OU_0002>
<IN_0003><TIME>08:28:05:12</TIME><CMD>
00000000 58314746 49505352 344F2020 20202020 20202020 20202020 20202050 535220
00000020 20202033 32373536 4259594E 30303520 20202020 00000000 00000000 0D
</CMD>
<SSID><LEV>1</LEV><CODE>GFIPSR4O</CODE><PSWD>PSR</PSWD><SDEB>32756</SDEB><SR>B</
</SSID>
</IN_0003>
<TDIR>T</TDIR><FAPI>GFIPSR4O GFIPSR4O FICTST
0080</FRLG><FSIZ>000000000057</FSIZ>
<OU_0004><TIME>08:28:05:29</TIME><CMD>
00000000 48464943 54535420 20202020 20202020 20202020 20202020 2020204E 202020
00000020 20202020 30353132 32313038 32383035 20202020 20202020 47464950 535234
00000040 20202020 20202020 20202020 20202020 20474649 50535234 4F202020 202020
00000060 20202020 20202020 20204630 30303830 30303030 30353730 30303030 303030
</CMD>
<SFID><DDN>FICTST</DDN><RSV1>N</RSV1><DATE>051221</DATE><TIME>082805</TIME><USER
0057</FSIZ><REST>000000000</REST></SFID>
</OU_0004>
<IN_0005><TIME>08:28:05:53</TIME><CMD>
00000000 32303030 30303030 3030
Continued
G-16 Connect:Express z/OS Administration Guide
</CMD>
<SFPA><ACNT>000000000</ACNT></SFPA>
</IN_0005>
<TYPP>OTHER</TYPP><NMGS>32756</NMGS><SYNC>00005</SYNC><COMP>COMPRESS</COMP><TYPD
<DATA_OU_0006><TIME>08:28:05:56</TIME><MSG>
00000000 44165BF9 F461F0F2 61F0F340 F1F87AF4 F17AF3F8 40D7E2D9 43F001F4 42400F
00000020 F3C2C140 E3D6D4F4 40D5D9C1 C3C54240 176140F9 F461F0F2 61F0F340 F1F87A
Connect:Express Fields
The trace files show the values that Connect:Express uses during execution of the file transfer, after protocol
negotiations and Connect:Express decisions, for example: identifications, network addresses, synchronization
parameters, network message size, physical file name, and user fields.
These values are shown according to the list of delimiters below:
Keyword Description
Keyword Description
FSIZ File size provided by the sender before transfer, for allocation
This appendix describes how you can define long names for files and IP hosts.
//SYSIN DD DISP=SHR,DSN=PROD.CEXPRESS.SYSIN(TOM4)
//SYJNL DD DISP=SHR,DSN=PROD.CEXPRESS.TOM4JNL
//SYLOG DD SYSOUT=V,HOLD=YES
//ENVVAR DD DISP=SHR,DSN=PROD.CEXPRESS.ENVVAR(TOM4)
The environment variable process can issue WTO messages prefixed by ‘ZVAR’, as shown in the example
below, where the error is that the file record format is variable.
These messages can be issued by any address space that processes variables, APM , ANM, AFM ou EAS.
When a syntax error is detected, the process issues a warning and continues. The following example shows that
a syntax error has been detected at line 00003 of the ENVVAR file: no ‘>’ character has been found.
If the variable cannot be resolved due to a syntax error, or because no corresponding definition exists, the
process continues without resolving it.
Option 0 of TSO/ISPF interface enables the operator to access the ENVVAR file. Use option’S’ to edit the file,
updates are dynamically available.
<var>value to replace
The string ‘var’ can contain 1 to 8 characters , including blanks, excluding ‘>’. The string <var> must be placed
in the name you want to extend : ‘value to replace’ will replace it when processed.
Variables are processed in the following situations :
1. •Transfer of an HFS file – data set name processed in APM for PeSIT and Odette, or EAS for Ftp.
2. •TCP/IP connection with host name – processed in ANM or AFM depending on the protocol.
Appendix H / Using Environment Variables H-3
Message Description
ZVAR004E OPEN ENVVAR ERROR The ENVVAR record format is invalid. The cause is
indicated. The file transfer is not interrupted, but
variables are not resolved
ZVAR006W ENVVAR SYNTAX ERROR While processing, a syntax error has been detected –
the error type and the line number are indicated. All
possible variable resolution are completed.
ZVAR007W OVERFLOW, STRING While processing, an overflow has been detected : the
TRUNCATED result is more than 256 characters long : the result is
truncated, the process stops.
ZVAR009W VARIABLE NOT FOUND The variable shown in the message has no definition in
the ENVVAR file. All possible resolution are
completed
Examples of Use
You can use environment variables in the Dsn local field of the symbolic file definition for an HFS file, in the
IP HOST field of the partner definition for a TCP/IP partner , and in the Remote Dsn/Pi99 field of the file
definition or the transfer request . You can request the variable resolution in the screen using a command VAR.
H-4 Connect:Express z/OS Administration Guide
Index
C DISTLIB A-2
SAMPLIB A-3
SAMPOPT A-4
T
T1B2PCOD 3-17
Security
Control 3-2 Technical support 6-16
Encryption 3-35 Termination 2-13
Interface 2-22
Network security 3-35 Timers 3-46
Overview 3-30 TOM
Parameters 3-30 Exits processed in 2-16
Symbolic security 3-30 Initialization interface 2-13
System security 3-34
Trace
User exits 3-35
Auxiliary Trace Manager G-1
Selection Running a network trace 6-8
Failure 4-9 With user exits 6-2
Interface 2-22
trace
Server exits 2-26 Etebac G-14
SRC B-1 Odette G-15
U
User access control 2-8
User exits
Applications of 2-7
Controlling transfers with an application 2-7
Conventions 2-5
Definition 2-1
Linking information with 2-26
Maintaining control of file allocation 2-8
Overview 2-2
Read/Write 2-35
Sending sections of a file 2-8
Sequence 2-6
Server exits 2-26
Standard 2-1
TRC from User Exits B-13
User Libraries. See also Libraries.
V
VTAM
Resources E-1
W
Workfiles 3-21
WTO messages
Issued by the ANM B-67
Issued by the APM B-62
Issued by the monitor B-27
Index-6 Connect:Express z/OS Administration Guide