Data Management Library TRANSFER Installation and Management Guide Product Version Release ID Edition Being Updated Update 1 Edition Print Date Abstract TRANSFER C31 C30.08 Part Number 13198 Part Number 068837 April 1992 This manual provides reference material and guidelines for configuring, installing, and managing the TRANSFER delivery system.
Document History Edition Part Number Product Version Release ID Print Date First Second Third Fourth (Preliminary) Fifth Sixth (Preliminary) Update 1 Seventh Update 1 82322 A00 82322 B00 82522 A00 82522 B00 TRANSFER A04 TRANSFER A04 TRANSFER A05 TRANSFER B10 N/A N/A N/A N/A April 1983 December 1983 March 1985 June 1985 82522 C00 82492 TRANSFER B20 TRANSFER B40 N/A N/A October 1985 October 1986 22855 13198 068837 TRANSFER B40 TRANSFER C30 TRANSFER C31 N/A C30 C30.
New and Changed Information New and Changed This update package discusses TIMEWASRESET as both a parameter and an Information for Update argument when you start your TRANSFER delivery system. In addition, it describes a Package Number new TEXTSRV parameter, OKTOCREATE. 068837 Appendix A, “Define Files,” reproduces the define file descriptions for the C31 release of TRANSFER. The update package includes other minor technical and editorial changes.
New and Changed Information Section 6, “System Installation Procedures,” explains installing the new TRANSFER components described in Section 2.
New and Changed Information Appendix D gives an example of national language support softdocs—in this case, for German. Appendix E provides a new system installation example. This TRANSFER Installation and Management Guide corrects all known technical and editorial mistakes in the previous manual.
New and Changed Information vi 068837, Update 1 to 013198 Tandem Computers Incorporated
Contents New and Changed Information About This Manual xxi Notation Conventions Section 1 iii xxv Introduction TRANSFER Concepts 1-2 Packages 1-2 The TRANSFER Database and Depots System Management 1-7 Installation Concepts 1-8 1-4 Using ADMIN to Administer a TRANSFER System Section 2 1-10 The TRANSFER Environment Overview 2-1 Establishing the TRANSFER Environment 2-2 Developing TRANSFER Applications 2-2 System Configuration Requirements 2-3 The TRANSFER Database 2-5 Base TRANSFER Data Files 2-
Contents Section 3 The X400 Gateway Overview 3-1 X400 Messages 3-1 P1 Messages—General Message Handling 3-1 P2 Messages—Mail Messages 3-3 TRANSFER and P1 and P2 Messages 3-4 Management Domains 3-5 Administration Management Domain (ADMD) Private Management Domain (PRMD) 3-5 TRANSFER and Domains 3-5 The X400 Gateway Node 3-7 Gateway Depots 3-9 X400 Names Section 4 3-10 Preparing to Install a TRANSFER System Overview 4-1 Preparing a User-DSV 4-1 Preparing Files for Installation 4-2 Preparing SCREE
Contents Section 6 System Installation Procedures Overview 6-1 Installing a TRANSFER System 6-1 Customizing a TRANSFER System 6-2 Redefining a TRANSFER System 6-2 Defining and Initializing TRANSFER Components 6-3 Rules for Running Definition Programs 6-3 Base TRANSFER Definition and Initialization 6-4 PS MAIL 6530 Definition Procedure 6-8 PS MAIL 3270 Definition Procedure 6-10 PS MAIL TTY Definition Procedure 6-12 X400 Gateway Definition and Initialization 6-15 Definition Program File-Moving Procedure 6-1
Contents Section 7 Customizing a TRANSFER System Overview 7-1 Using Customizing Files 7-2 Customizing Server Classes 7-4 General PARAM Specifications 7-4 TRANSFER Scheduler (TSCHED) 7-7 Text Server (TEXTSRV) 7-10 TRANSFER Interactive Server (TISERV) 7-11 TRANSFER G-File Server (GFSERV) 7-13 TRANSFER Worker Server (TWORK) 7-14 TRANSFER Network Receiver (TRECV) 7-17 Customizing the TRANSFER X400 Gateway Servers 7-19 X400 Export Server (X400-EXPORTER) 7-19 X400 Import Server (X400-IMPORTER) 7-20 X400 Dat
Contents Screens Used for Depot Storage Statistics 9-12 Overview 9-12 Statistic Sampling 9-12 Displaying Depot Storage Statistics 9-13 Configuring the Parameters for Statistics Collection 9-14 The DEPOT STATISTICS CONFIGURATION Screen 9-17 Displaying the Screen 9-18 Field Descriptions 9-18 Function Keys 9-19 Example of Reconfiguring the Depot Statistics Facility Changing Parameters 9-22 Stopping TRANSFER and the SPREP Process 9-22 Controlling Individual Depots 9-22 The X400 GATEWAY ATTRIBUTES Screen Disp
Contents Screens Used for Monitor Functions 10-10 The SCHEDULER QUEUE SAMPLES Screen 10-10 Displaying the Screen 10-11 Field Descriptions 10-11 Function Keys 10-12 Using the SCHEDULER QUEUE SAMPLES Screen Interpreting the Numbers 10-13 The DATABASE SAMPLES Screen 10-15 Displaying the Screens 10-16 Field Descriptions 10-16 Function Keys 10-17 Using the DATABASE SAMPLES Screens Interpreting the Numbers 10-18 10-13 10-18 The FILE DETAIL Screen 10-19 Displaying the Screen 10-19 Field Descriptions 10-19 Fu
Contents Screens Used for Probe and Trace Functions 10-29 The SCHEDULER QUEUE SCAN Screen 10-29 Displaying the Screen 10-29 Field Descriptions 10-30 Function Keys 10-31 Using the SCHEDULER QUEUE SCAN Screen The FOLDER SCAN Screen 10-34 Displaying the Screen 10-34 Field Descriptions 10-35 Function Keys 10-35 Using the FOLDER SCAN Screen 10-32 10-36 The ITEM TRACE Screen 10-37 Displaying the Screen 10-37 Field Descriptions 10-38 Considerations 10-43 Function Keys 10-43 The RECIPIENT SELECT Screen 10-44
Contents Section 11 Managing a TRANSFER System Overview 11-1 System Control 11-1 Correspondent Names 11-1 X400 Domain Names 11-2 Controlling Priorities 11-3 Using Cleanup TAREQs 11-4 Item Retention Times 11-5 Idle Sessions 11-6 Configuration Changes 11-8 Moving TRANSFER Data Files 11-9 Starting the TEXTSRV and NAMESRV Programs Handling a TRANSFER Network 11-15 Notification of Problems 11-19 11-13 System Monitoring 11-20 PATHWAY Environment 11-20 Network Environment 11-20 System Performance 11-20 TMF En
Contents Section 12 Troubleshooting Overview 12-1 What to Do When Mail Is Not Delivered 12-1 What to Do About Poor Interactive Performance Partitioning TRANSFER Database Files Partitioning the Session File 12-9 12-5 12-9 Understanding and Using the Log Files 12-13 The Format for Log Entries 12-13 The TSCHED Log 12-15 The TWORK Log 12-17 The TRECV Log 12-19 Using the Logs for Troubleshooting 12-21 Using the X400 Gateway Logs 12-23 The X400 Exporter Log 12-23 The X400 Importer Log 12-26 Using the X400
Contents TRANSFER Server Messages B-41 TISERV Error Messages B-41 TWORK Error Messages B-41 TRECV Error Messages B-41 TSCHED Output File Error Messages TCHECK Utility Messages Appendix C B-42 B-57 Contents of the User-DSVs TRANSFER User-DSV C-1 X400 Gateway C-4 Appendix D MAIL6530 User-DSV C-4 MAIL3270 User-DSV C-4 MAILTTY User-DSV C-5 National Language Support Softdocs German Language Support SMGERMAN D-8 SAGERMAN D-11 D-1 Appendix E System Installation Example Sample System Description E-1
Contents Figures Figure 1-1. A Package 1-3 Figure 1-2. Relationship of Depots, Folders, Items, and Packages Figure 1-3. Installation Phases Figure 1-4. ADMIN MAIN MENU Screen Figure 1-5. TMANAGER MAIN MENU Screen Figure 2-1. Base TRANSFER Configuration Figure 2-2. Full-Screen Mail Client Configurations Figure 2-3. PS MAIL TTY Configuration 2-26 Figure 2-4. X400 Gateway Configuration 2-27 Figure 2-5. Example of Package Delivery 2-30 Figure 3-1. A P1 Message 3-2 Figure 3-2.
Contents Figure 10-7. DATABASE SAMPLES Screen, Page 2 Figure 10-8. FILE DETAIL Screen Figure 10-9. MONITOR CONFIGURATION Screen 10-19 Figure 10-10. LOG CONTROL Screen Figure 10-12. FOLDER SCAN Screen 10-29 10-34 10-37 Figure 10-14. RECIPIENT SELECT Screen 10-44 Figure 10-15. RECIPIENT DISPLAY Screen 10-48 Figure 10-16. X400 RECIPIENT Screen, Page 1 10-51 Figure 10-17. X400 RECIPIENT Screen, Page 2 10-54 Figure 11-1. Example of the ADMIN AGENT CONFIGURATION Screen 11-38 Figure 12-1.
Contents Table 7-8. X400-EXPORTER and X400-IMPORTER PARAM Specifications 7-21 Table 7-9. TDBSERV PARAM Specifications Table 9-1. National Languages Table 9-2. Character Maps Table 10-1. Commonly Defined Function Keys Table 11-1. Assigning New File Names Table 11-2.
Contents xx 068837, Update 1 to 013198 Tandem Computers Incorporated
About This Manual This manual provides guidelines for management of the TRANSFER delivery system on Tandem NonStop systems. System management of TRANSFER involves ensuring that the hardware and software configurations satisfy the requirements of TRANSFER. A system manager installs TRANSFER and monitors and controls TRANSFER when it is running. TRANSFER provides system and resource management tools to assist TRANSFER system managers with system monitoring and problem determination.
About This Manual Two manuals acquaint you with Tandem computer systems and the software that comprises the transaction processing environment. The Overview of Tandem Products introduces you to the hardware and software for NonStop systems. The Introduction to Tandem NonStop Systems introduces you to the NonStop system architecture. Two manuals are key for the daily running of your Tandem system.
About This Manual The Communications Utility Program (CUP) Reference Manual describes the CUP commands used to perform operations related to data communication lines and devices and network environments. The Subsystem Control Facility (SCF) Reference Manual describes the operation of SCF and how it is used to configure, control, and inquire about supported data communications subsystems. TRANSFER provides electronic mail delivery for TRANSFER clients supplied by Tandem.
About This Manual xxiv 068837, Update 1 to 013198 Tandem Computers Incorporated
Notation Conventions The following list summarizes the conventions for syntax presentation in this manual. Notation Meaning UPPERCASE LETTERS Uppercase letters represent keywords and reserved words; enter these items exactly as shown. Lowercase italic letters represent variable items that you supply. Brackets enclose optional syntax items. A group of vertically aligned items enclosed in brackets represents a list of selections from which you can choose one or none. Braces enclose required syntax items.
1 Introduction The TRANSFER delivery system is a high-level software product that provides reliable delivery of information to people, processes, and devices. TRANSFER can be run on a single system or across a network of systems. In a network, communication through TRANSFER does not depend on the immediate availability of the system where information is being sent. In addition, a particular recipient need not be available at the time information is transmitted.
Introduction TRANSFER Concepts TRANSFER Concepts The following paragraphs briefly review the concepts basic to the TRANSFER environment. TRANSFER delivers information from a sender to one or more recipients. Senders and recipients of information are called correspondents. A correspondent can be a person, an input or output device, or a process. Local correspondents are those at the same node or system; remote correspondents are those at other nodes in the network.
Introduction TRANSFER Concepts Figure 1-1. A Package Package Header Item ID 412 Package Header Sender's Correspondent Name Date and Time Delivery Parameters Recipient List Data Component List Item ID 8 Item ID 93 Item ID 8 Package Header Item ID 93 Component List Item ID 744 Item ID 106 Sender's Correspondent Name Date and Time Delivery Parameters Recipient List Data Item ID 744 Item ID 106 Memo to John From Jim 0100101110100 0101101000101 In response to your letter of July 19, 1991...
Introduction The TRANSFER Database and Depots Once a correspondent has sent a package, TRANSFER is responsible for seeing that each local and remote recipient receives it. At each node, a TRANSFER scheduler keeps track of packages to ensure that they are scheduled for delivery. When packages have been scheduled for delivery, TRANSFER asynchronous requesters see that packages are actually delivered to each recipient.
Introduction The TRANSFER Database and Depots In addition to folders and distribution lists that are associated with a private correspondent depot, TRANSFER also supports shared access to folders and distribution lists owned by an interest group. An interest group is a group of correspondents who have a common interest or function; these correspondents share access to group folders and can add their names to group distribution lists.
Introduction The TRANSFER Database and Depots Figure 1-2.
Introduction System Management System Management A system manager at each node in a network oversees the TRANSFER delivery system by performing these tasks: Installing TRANSFER Monitoring activity within the TRANSFER environment Setting up rules for the use of TRANSFER Coordinating the use of TRANSFER with system managers at other nodes Solving problems that occur while TRANSFER is running This manual is organized to help you install and manage TRANSFER.
Introduction Installation Concepts Installation Concepts To install and run TRANSFER, you need user-DSV subvolumes containing files Tandem provides and a configuration subvolume: A user-DSV is a subvolume on which resides a copy of the Tandem distribution subvolume with software for TRANSFER and clients supplied by Tandem. These are described in Section 4 and Appendix C.
Introduction Installation Concepts The installation phases are shown in Figure 1-3. The arrows show the flow of operations, the order in which the phases can occur. Any time redefinition occurs, configuration must follow. Stop always follows start, but either configuration or start can follow stop. Figure 1-3.
Introduction Using ADMIN Using ADMIN to Administrative functions within the TRANSFER environment are performed through Administer a the ADMIN program.
Introduction Using ADMIN Volume 1 of the TRANSFER Administration Guide, the Reference Manual, describes the depot-related functions that an administrator performs on behalf of the correspondents. These include registering correspondents; defining profiles; setting up agents; and handling folders, distribution lists, and interest groups.
Introduction Using ADMIN Figure 1-5. TMANAGER MAIN MENU Screen T9110C30 - 9JUL91 TMANAGER MAIN MENU SCREEN Monitor Functions F1 - Scheduler Queue Samples F2 - Database Samples F3 - Monitor Configuration Log Functions F6 - Dynamic Log Control Probe and Trace Functions F10 - Scheduler Queue Scan F11 - Folder Scan Folder: F12 - Item Trace Item Id: Utility Functions ——> Current Printer Location: SF14=Recover F15=Help F16=Return SF16=Exit BLOCK TMANAGER can also be run as a standalone PATHWAY program.
2 The TRANSFER Environment Overview The TRANSFER delivery system operates in an environment that includes the GUARDIAN 90 operating system, the PATHWAY transaction processing system, and the Transaction Monitoring Facility (TMF). If your system is part of an EXPAND network, information can be transported to and from the various nodes in the network. A TRANSFER system must be installed at each node where information is to be sent or received.
The TRANSFER Environment Establishing the TRANSFER Environment Queue Manager, an optional queueing facility that lets requesters add an entry in a queue and retrieve an entry from a queue for processing Queue Manager is a separate Tandem product that can be used independently of TRANSFER. It is automatically installed when you configure the TRANSFER X400 gateway.
The TRANSFER Environment System Configuration Requirements System Configuration Requirements When setting up TRANSFER on your system, you must consider several system configuration requirements, which are discussed in the following subsections. System Generation Requirements The system generation program (SYSGEN) establishes the hardware and software configuration for your system.
The TRANSFER Environment System Configuration Requirements Terminal Requirements Terminals that use PS MAIL 6530 and the ADMIN and TMANAGER applications supplied with Base TRANSFER must be Tandem 6530 terminals or compatible terminals. Terminals that use PS MAIL 3270 must be IBM 3270 terminals or compatible terminals. PS MAIL 6530 or PS MAIL 3270 users of the EDIT function must have their terminals configured in ITI mode.
The TRANSFER Environment Base TRANSFER Data Files The TRANSFER Database Base TRANSFER Data Files At each node where TRANSFER is running, TRANSFER maintains a database of information about local correspondents. The database consists of a set of internal files used exclusively by TRANSFER. These files are created when you initialize Base TRANSFER. Base TRANSFER requires a set of data files that are internal files, completely controlled by TRANSFER. Here is a list of these files.
The TRANSFER Environment Base TRANSFER Data Files Recipient (RECIP) Contains the recipient names for packages posted at your node and the correspondent names at your node that are recipients of packages posted at other nodes. Item Descriptor (ITEMDESC) Contains descriptions of packages and items stored in depots at your node. Item Data (ITEMDATA) Contains the data in the packages and items described in the Item Descriptor file.
The TRANSFER Environment File Descriptions Remote Open Control (ROPENCTL) Used by the TWORK servers to control network OPEN requests. Network Traffic Logging (TRAFLOG) Logs the amount of network traffic that TRANSFER generates. The Textfile and the Character Map file are part of the Base TRANSFER distribution subvolume. Most of these files are configured as TMF audited files when Base TRANSFER is initialized.
The TRANSFER Environment File Descriptions Each interest group has at least two profiles: The TRANSFER group profile defines a variety of attributes for the group. The mail profile provides defaults for many functions during a session with PS MAIL 6530, PS MAIL 3270, or PS MAIL TTY. In addition, if a correspondent or group depot includes optional profiles, those profiles are also stored in the Profile file.
The TRANSFER Environment File Descriptions Folder File, Inverted Folder File, and IFOLDER1 File The Folder (FOLDER) file contains the part of a depot that identifies the items and packages in each of the folders belonging to that depot. This file is used to determine which items and packages are stored in a particular folder. When a correspondent is initially registered with TRANSFER, three folders are automatically created for the depot.
The TRANSFER Environment File Descriptions Recipient File The Recipient (RECIP) file contains the recipient names for all packages sent from your node as well as the recipient names in packages transported to your node from other nodes. A recipient name is a correspondent name, an interest group name, or a distribution list name. X400 recipient names are kept in the X400 Name file with all other X400 names.
The TRANSFER Environment File Descriptions Session File The Session (SESSION) file contains information about correspondents who have sessions currently in progress at your node. A unique session ID is associated with each active session. TRANSFER adds a record to this file when a correspondent starts a session and deletes that record when the session is terminated. During a session, every incoming interprocess communication (IPC) header is validated against the Session file.
The TRANSFER Environment File Descriptions Text File The Textfile (TEXTFILE) describes text that the TRANSFER system displays to users, as well as keywords that the TRANSFER system accepts from users. Text items include command keywords, error messages, the system trigger character, special folder names, and help text. The Textfile is not user-configurable; this file is released on the Base TRANSFER distribution subvolume.
The TRANSFER Environment X400 Gateway Files X400 Gateway Files The TRANSFER database provides the following files for the X400 gateway: If X400 is enabled on your node, the following file is automatically added to your TRANSFER database: X400 Name File (X400NAME) The X400 Name (X400NAME) file stores the X400 names that are associated with packages and distribution lists. Among the records it includes are the recipient types—P1, TO, CC, or BCC.
The TRANSFER Environment File Codes File Codes for TRANSFER Files File codes are reserved for TRANSFER files. These codes are returned in TRANSFER diagnostic messages. The codes and corresponding files are listed in Table 2-1. The NAME0 file, the DSDATA0 file, the INTGROU0 file, the IFOLDER1 file, the DEPSTATO file, and the alternate key files for the Time, Net, and Ready files do not have file codes. Table 2-1.
The TRANSFER Environment TMF Audited Files TMF Audited Files TRANSFER requires TMF to ensure the consistency of the TRANSFER database and to assure package delivery.
The TRANSFER Environment TMF Audited Files The command files for creating the database files are generated by the definition programs, described in Section 5. The file creation parameters in the command files set the AUDIT parameter for each database file as required by TRANSFER components to ensure database consistency and to guarantee package delivery.
The TRANSFER Environment TMF Audited Files You can elect to create the Session file as a nonaudited file. In general, configuring the Session file as a nonaudited file does not present any significant problems. A problem could occur, however, when a session is being established for a correspondent and a failure occurs; after recovery, an attempt to establish a session for that correspondent could be disallowed because of a session in progress.
The TRANSFER Environment Base TRANSFER Configuration TRANSFER TRANSFER includes PATHWAY terminal control processes (TCPs), server processes, Configuration terminals, and programs that control communications within the TRANSFER Overview environment. The processes required for your TRANSFER system depend, in part, on the TRANSFER components included in your system.
The TRANSFER Environment Base TRANSFER Configuration TRECV TRANSFER network receiver server. TRECV servers are allocated by TFRONTs to handle all incoming network operations. The TFRONTs assign a TRECV for remote TWORKs as needed. You must define the TRECV server class to have at least one member for every TFRONT pseudo-terminal you define at your node. TSCHED TRANSFER scheduler that schedules, controls, and tracks all TRANSFER activities that are performed independently of an application request.
The TRANSFER Environment Base TRANSFER Configuration TISERV TRANSFER interactive server, which provides the application interface with TRANSFER. This server is used in the TISERV and TISERV-ASYNC server classes for Base TRANSFER, and in the TTY-TISERV server class for PS MAIL TTY. TISERV must be licensed, using the FUP LICENSE command. TISERV-ASYNC servers are used by TAREQ pseudo-terminals to perform local package delivery.
The TRANSFER Environment Base TRANSFER Configuration Base TRANSFER includes the TRANSFER administrative programs, ADMIN and TMANAGER, which are full-screen clients. These clients add the following objects to the TRANSFER PATHWAY configuration: TRAN-TCP TRANSFER requester TCP that runs the ADMIN and TMANAGER programs. At least one TRAN-TCP must be defined; you usually do not need to have more than one. ADMIN TRANSFER administrator program.
The TRANSFER Environment Base TRANSFER Configuration The Base TRANSFER definition also defines the following process and TRANSFER names: Correspondent directory name This sets the directory name. All nodes in a network must use the same correspondent directory name if the nodes are to communicate with one another. The installation procedures provide CORR as the default name. PATHMON process name This sets the PATHMON process name under which the TRANSFER PATHWAY system is to run at your node.
The TRANSFER Environment Base TRANSFER Configuration Figure 2-1.
The TRANSFER Environment PS MAIL 6530 and PS MAIL 3270 Configurations PS MAIL 6530 and PS MAIL 3270 Configurations PS MAIL 6530 and PS MAIL 3270 are mail clients that provide mail exchange between terminals using a full-screen mode. Both clients use the same server classes defined with Base TRANSFER. Each, however, requires its own programs. PS MAIL 6530 and PS MAIL 3270 also use separate text servers: M6530-TEXT and M3270-TEXT.
The TRANSFER Environment PS MAIL 6530 and PS MAIL 3270 Configurations Note For remote logon, the systems must conform as follows: PATHMON names must match. If the local PATHMON name is different from the remote PATHMON name, remote logon fails with an error 7499 0014. Both nodes must run the same release of PS MAIL—both C30, for example—because the text files must match.
The TRANSFER Environment PS MAIL TTY Configuration PS MAIL TTY Configuration The PATHWAY configuration for PS MAIL TTY adds the following server classes to the TRANSFER PATHWAY configuration: TTY-TISERV—TRANSFER interactive server TTY-G-FILE—GFSERV program used to access GUARDIAN 90 files Figure 2-3 shows the PS MAIL TTY configuration. PS MAIL TTY requires two run files residing on the same subvolume. The files are the PSMAIL object-code file and file T9130CFG, a configuration file.
The TRANSFER Environment X400 Gateway Configuration TRANSFER X400 Gateway Configuration The PATHWAY configuration for the TRANSFER X400 gateway adds the following server classes to the TRANSFER PATHWAY configuration: X400-EXPORTER The X400 export server (X400-EXPORTER) handles messages being exported from TRANSFER to the X400 network. X400-IMPORTER The X400 import server (X400-IMPORTER) handles messages coming into TRANSFER from the X400 network.
The TRANSFER Environment X400 Gateway Configuration The TRANSFER X400 gateway is configured separately from Base TRANSFER; it has its own defaults configuration file for installation and redefinition. Sections 6, 7, and 8 tell you how to install, customize, and redefine the gateway. As Section 3 explains, TRANSFER nodes are grouped into a PRMD domain at configuration time. Each domain—or group of TRANSFER nodes—has a single TRANSFER X400 gateway node.
The TRANSFER Environment Concepts of Package Delivery Concepts of Package Figure 2-5 illustrates how the primary components of TRANSFER work together; Delivery processes other than those shown in the illustration can also be involved in package delivery. This figure shows communication between two correspondents at two different nodes: Mary at the \NY node and John at the \CHIC node.
The TRANSFER Environment Concepts of Package Delivery Figure 2-5. Example of Package Delivery \NY Node.Correspondent Mary 1 2 3 Name Directory Mary's Depot Mary 5 7 4 To John PS MAIL TTY From Mary Data TISERV 6 Ready File 8 10 TWORK TAREQ SubmitPackage TSCHED 9 11 \CHIC Node.
The TRANSFER Environment Concepts of Package Delivery 1. Mary and John are correspondents at different nodes in a network. 2. Each of them has a correspondent name registered in the TRANSFER name directory at the respective node. 3. Each of them has a depot in the TRANSFER database at the respective node. 4. The PS MAIL TTY client has a session in progress for Mary. 5. Mary has a package in her depot ready for delivery to John. 6.
3 The X400 Gateway Overview The TRANSFER X400 gateway allows TRANSFER correspondents to exchange messages with users of different message systems that are based on international X.400 standards. With the gateway, the format of a TRANSFER message is translated into a format defined by the recommendations for X.400 message handling systems. X.400 has its own architecture and protocols, but TRANSFER correspondents need not understand these as long as they know how to address X400 correspondents.
The X400 Gateway P1 Messages Figure 3-1 illustrates the format of a P1 message. Figure 3-1.
The X400 Gateway P2 Messages P2 Messages—Mail Messages The X.400 architecture uses a protocol called P2 to format mail messages. In TRANSFER terms, a nonmail message is a message that is not a P2 message. Each P2 message consists of a heading followed by a series of data blocks. The heading contains the message originator; primary, courtesy-copy, and blind-copy recipients; and other service information. Each body part can contain a different form of data, such as text, voice, or FAX.
The X400 Gateway TRANSFER and P1 and P2 Messages Figure 3-3 shows a P1 message with a P2 message as its content. Figure 3-3. A P2 Message in a P1 Message Envelope Heading Body Part Content Body Part Body Part 018 TRANSFER and P1 and P2 Messages TRANSFER, with its X400 gateway, allows clients to send packages of any type to X400 recipients.
The X400 Gateway Management Domains Management Domains The nodes in an X.400 system are organized into management domains. As a TRANSFER system manager, you encounter management domains when you install and configure your X400 gateway and in X400 recipient names. Each domain is a collection of nodes; these are connected through MTAs. There are two types of domains.
The X400 Gateway Management Domains Figure 3-4. An X400 Network Country B Country A PRMD Domain - TDM2 PRMD Domain - TDM1 \A1 \A2 \A3 \B1 \B2 Gateway 1 Gateway 2 TDM1 MTA TDM2 MTA \B3 PRMD Domain - TDM3 ADMD Domain \X1 \\B4 A1 ADMD-10 MTA \B5 Gateway 3 X.
The X400 Gateway The X400 Gateway Node The X400 Gateway The TRANSFER X400 gateway performs data mapping between TRANSFER-format Node messages and X.400-format messages. The gateway consists of five server classes: X400-EXPORTER The X400 export server (X400-EXPORTER) handles messages being exported from TRANSFER to the X400 network. This server class can run multiple processes. X400-IMPORTER The X400 import server (X400-IMPORTER) handles messages coming into TRANSFER from the X400 network.
The X400 Gateway The X400 Gateway Node Figure 3-5. An X400 Gateway Node Base TRANSFER TAREQ Gateway TRANSFER Database Server Import Server Export Server Queue Manager Queue File X.
The X400 Gateway Gateway Depots Gateway Depots A depot, the _X400_ depot, is defined at each gateway node. This depot is used when a message needs to be exported to a foreign X400 network. When a message to be sent to an X400 correspondent arrives at the local gateway node, the message is saved in the _X400_ depot’s INBOX folder for each X400 recipient. The message ID is placed on a queue, and the export server is informed that it has work to do.
The X400 Gateway X400 Names X400 Names X400 correspondent names are used as originator and recipient (O/R) addresses, which provide routing information for an X.400 message delivery system. O/R addresses are functionally like TRANSFER names, but they contain more attributes.
4 Preparing to Install a TRANSFER System Overview Before you use the TRANSFER installation procedures, you need to copy TRANSFER software files and prepare them for use. TRANSFER software arrives at your site on a Site Update (SUT) Tape. The product files on the SUT tape are grouped into distribution subvolumes (DSVs), the names of which appear on the last part of the packing list. These names are in the form Yxxxxzzz where xxxx is the product number and zzz is the release number—for instance, Y9110C30.
Preparing to Install a TRANSFER System Preparing a User-DSV Warning Make sure that you have successfully copied your text files (TEXTFILE for Base TRANSFER, TEXT6530 for PS MAIL 6530, and TEXT3270 for PS MAIL 3270). If you do not already have a text file, the text server creates a dummy file consisting of only a header record of 12288 bytes. Do not merely pull over the SCREEN COBOL library files. You must copy the text file.
Preparing to Install a TRANSFER System Preparing SCREEN COBOL Object Libraries Preparing SCREEN A TRANSFER configuration includes SCREEN COBOL object libraries provided by COBOL Object Tandem with TRANSFER software and can also include user-written SCREEN Libraries COBOL object libraries. The libraries provided by Tandem reside on your user-DSVs and are available to the installation procedures. The installation procedures by default assign the libraries to TCPs.
Preparing to Install a TRANSFER System Preparing SCREEN COBOL Object Libraries TCLPROGThe installation procedures have definition parameters that specify userwritten SCREEN COBOL object libraries (referred to as TCLPROGs in PATHWAY commands). A Base TRANSFER definition parameter specifies the agent TCLPROG, which contains user-written SCREEN COBOL agents. A definition parameter is available to specify a user-extension TCLPROG for each mail client—PS MAIL 6530 or PS MAIL 3270.
5 Defining a TRANSFER System Overview When you define your TRANSFER system, you provide the information from which your TRANSFER system is initialized and configured. The information in the definition is processed by programs that generate files you use to install and control the system. To define a TRANSFER system, you must enter configuration information in define files. The source for a define file is a default file provided with the installation procedures.
Defining a TRANSFER System Define File Descriptions Define File The define file descriptions consist of commented listings of the default files. The Descriptions parameters are described in the order in which they appear in the files. Optional parameters not included in the default file are described at the end of each file listing. There are two types of parameters—reconfigurable and initialization.
Defining a TRANSFER System Define File Descriptions Figure 5-1 shows a sample part of the Base TRANSFER default file. Figure 5-1. Sample Base TRANSFER Defaults File (TRDEFLTS) -- TRDEFLTS File -- This file contains the default values for the -- keyword parameters used to define Base TRANSFER. * * * -------------- RECONFIGURABLE PARAMETERS -------------TRUserDSV $vol.subvol TRPathmonCpu TRPwayLocation TRPwayHomeTerm TRPwayLog1 [CPUA] $SYSTEM.SYSTEM [Home_Term] $S.#PWAY.
Defining a TRANSFER System Define File Format Define File Format A comment is specified by leading double hyphens (--). Any text in a line following the double hyphens is considered a comment. Special directions for configuring parameters are set off by asterisks. A keyword parameter name begins with the two-character component ID. The remainder of the name consists of uppercase and lowercase letters describing the entity the parameter defines.
Defining a TRANSFER System Define File Format Figure 5-2 illustrates the format for a sample parameter name. This parameter can have multiple specifications; it terminates in a number to identify multiple specifications. Figure 5-2.
Defining a TRANSFER System Preparing the Define Files Preparing the Define The TRANSFER installation procedures provide default files from which you create Files define files. A default file for each component that you have purchased is included on the TRANSFER distribution subvolume (DSV). The DSV for each component contains the software for that component. Following the instructions in Section 4, “Preparing to Install a TRANSFER System,” copy the DSVs to your own user-DSVs.
Defining a TRANSFER System Preparing the Define Files Figure 5-3 illustrates the creation of the define file for Base TRANSFER. Default file TRDEFLTS is copied from the TRANSFER user-DSV to the configuration subvolume TRANCNFG and is renamed DEFINETR. The define file is then ready for editing. Figure 5-3.
Defining a TRANSFER System Editing Define Files Editing Define Files When editing the define files, you can change default parameter values to values you want to use for your system, delete inapplicable optional parameters, and add optional parameters as needed. The only part of a keyword parameter name that you can change is a terminating number. Parameter values have different forms according to value type.
Defining a TRANSFER System Naming Conventions Naming Conventions You must use certain naming conventions in naming TRANSFER and PATHWAY objects. Following these conventions, process names are automatically generated from name specifications entered in the define files.
Defining a TRANSFER System Simple TRANSFER Names Simple TRANSFER Names A simple TRANSFER name can have a maximum of 32 characters. These characters must be chosen from the name character set configured for TRANSFER, as discussed later in this section. The character sets in effect for a particular TRANSFER system apply to all nodes on which the system is running.
Defining a TRANSFER System TRANSFER X400 Domain Names TRANSFER X400 Domain Names TRANSFER X400 names are functionally like simple TRANSFER names, but they contain more attributes to provide routing information. An X400 user refers to a TRANSFER correspondent by specifying the TRANSFER system domain as part of the X400 name.
Defining a TRANSFER System National Language Support National Language Support You can use TRANSFER not only in English but also in several other national languages. PS MAIL 6530 and PS MAIL 3270 users can see screen labels, the names of the TRANSFER special folders, error messages, help text, and the names of the TRANSFER special folders in their native language. For example, a German user can refer to INBOX, OUTLOG, and WASTEBASKET as EINGANGSPOST, AUSGANGSPOST, and PAPIERKORB.
Defining a TRANSFER System National Language Support Character Maps A character map is a set of rules for internally representing characters in the base character sets. These rules map—establish a correspondence between—the code that the terminal uses to represent each character on the keyboard or screen to the internal character. These maps are customized to support the characters used in the corresponding national language.
Defining a TRANSFER System PATHWAY Process Names PATHWAY Process Names PATHWAY process names specified in define files must follow the rules for naming PATHWAY processes. In assigning names, you must consider the additional character that can be appended to the name during name generation (described later in this section) for a PATHWAY object with multiple process definitions. The process-name generation conventions apply to the process names you specify.
Defining a TRANSFER System PATHWAY Process Names If you use this name specification and specify three TRAN-TCPs, the process names generated are $ZTTA, $ZTTB, and $ZTTC. If you specify only one TRAN-TCP, only $ZTTA is generated. To change the names, enter a new root and specify a beginning character and an ending character. The beginning and ending characters can be either letters or digits, but both must be of the same type—for example: P:Z or 5:9.
Defining a TRANSFER System PATHWAY Process Names Server classes $ZTA0 through $ZTA9—TISERV-ASYNC $ZTE0 through $ZTE9—EMSERV $ZTF0 through $ZTF9—FORMAT $ZTG0 through $ZTG9—G-FILE $ZTP0 through $ZTP9—PROCESS-SERVER $ZTR0 through $ZTR9—TRECV $ZTT0 through $ZTT9—TISERV $ZTW0 through $ZTW9—TWORK Client server classes $ZCTA—M6530-TEXT (text server for PS MAIL 6530) $ZCTB—M3270-TEXT (text server for PS MAIL 3270) $ZCC0 through $ZCC9—TTY-TISERV $ZCD0 through $ZCD9—TTY-G-FILE TCP processes $ZCIA through $ZCIZ—M3270
Defining a TRANSFER System Name Generation for PATHWAY Objects Name Generation for PATHWAY Objects The installation procedures use a convention for generating multiple names for terminals and TCPs for the PATHWAY system. You do not enter these names; the names are assigned by the definition programs. These names, however, appear in files that configure, start, and stop the PATHWAY system.
Defining a TRANSFER System Process Priority Assignment Table 5-2 gives process priority values. Table 5-2.
6 System Installation Procedures Overview Installing a TRANSFER System TRANSFER provides procedures that you use to install your TRANSFER delivery system. This section begins with an overview of the installation procedures; it then describes the procedures for installing different components of your TRANSFER system. You must have a named TACL running on your system in order to install TRANSFER. You install a TRANSFER system in phases. The phases and their functions include the following: 1.
System Installation Procedures Overview 5. Stop Stop uses files generated by the definition programs to stop your PATHWAY system. The XSTOP program shuts down the PATHWAY system and stops all TRANSFER processes that continue after the shutdown. 6. Redefinition Redefinition uses the system descriptions you provide in the define files to generate files that configure, start, and stop the PATHWAY system. Redefinition provides for modifying definitions of existing TRANSFER components.
System Installation Procedures Rules for Running Definition Programs Defining and You define and redefine the TRANSFER components by executing the definition Initializing TRANSFER programs. Components The components that create uninitialized data files require both definition and initialization. Initialization applies to the component the first time you install the component in your TRANSFER system or any time you wish to reinitialize the data files for the components.
System Installation Procedures Base TRANSFER Definition and Initialization Base TRANSFER Definition and Initialization Base TRANSFER is the only mandatory component of a TRANSFER system. Installation of Base TRANSFER requires that you run the program CDTRDEF to generate command files for configuring, starting, and stopping Base TRANSFER— including ADMIN and TMANAGER. For an initial definition, the installation also generates files for initializing Base TRANSFER data files.
System Installation Procedures Base TRANSFER Definition and Initialization INITIAL provides for initializing Base TRANSFER data files. Specify INITIAL when you first install Base TRANSFER or when you wish to reinitialize the data files. The Base TRANSFER data files must not exist. REDEFINE provides for changing reconfigurable parameters for Base TRANSFER for an existing TRANSFER system. REDEFINE is optional and is assumed if you specify neither REDEFINE nor INITIAL.
System Installation Procedures Base TRANSFER Definition and Initialization The files generated on the configuration subvolume are: GTRCNFG, which contains the Base TRANSFER PATHWAY configuration, including ADMIN and TMANAGER GTRCOOL, which contains PATHCOM commands that start all servers in the PATHWAY system in alphabetical order by server class name (START SERVER *) and invokes TAREQ-TCPs, TRAN-TCPs, and terminals GTRUPDT, which contains TACL macros that update certain name directory parameters, once for
System Installation Procedures Base TRANSFER Definition and Initialization GTRINIT Obey File The GTRINIT obey file contains the commands that invoke programs to create and initialize TRANSFER data files. The GTRINIT file is written to the configuration subvolume by definition program CDTRDEF if you specify INITIAL in the execution command.
System Installation Procedures PS MAIL 6530 Definition Procedure PS MAIL 6530 Definition Procedure PS MAIL 6530 is an optional component of a TRANSFER system. Installation of PS MAIL 6530 requires that you run the CDMLDEF program to generate command files for configuring, starting, and stopping PS MAIL 6530. Before you install PS MAIL 6530, you must install Base TRANSFER.
System Installation Procedures PS MAIL 6530 Definition Procedure Example Here is an example of how you run the CDMLDEF program: 1> RUN transfer-dsv.CDMLDEF /OUT $S.#mlout,NOWAIT/ trancnfg This command specifies that program CDMLDEF resides on the TRANSFER userDSV, and that define file DEFINEML resides on subvolume TRANCNFG. CDMLDEF writes the generated files to subvolume TRANCNFG and the listing to the spooler file #MLOUT. NOWAIT returns immediate control to the terminal while execution continues.
System Installation Procedures PS MAIL 3270 Definition Procedure PS MAIL 3270 Definition Procedure PS MAIL 3270 is an optional component of a TRANSFER system. Installation of PS MAIL 3270 requires that you run the CDIMDEF program to generate command files for configuring, starting, and stopping PS MAIL 3270. Before you install PS MAIL 3270, you must install Base TRANSFER.
System Installation Procedures PS MAIL 3270 Definition Procedure Example Here is an example of how you run the CDIMDEF program: 1> RUN transfer-dsv.CDIMDEF /OUT $S.#imout,NOWAIT/ trancnfg This command specifies that program CDIMDEF resides on the TRANSFER user-DSV, and that define file DEFINEIM resides on subvolume TRANCNFG. CDIMDEF writes the generated files to subvolume TRANCNFG and the listing to the spooler file #IMOUT. NOWAIT returns immediate control to the terminal while execution continues.
System Installation Procedures PS MAIL TTY Definition Procedure PS MAIL TTY Definition Procedure PS MAIL TTY is an optional component of a TRANSFER system. Installation of PS MAIL TTY requires running the CDCMDEF program to generate command files for configuring, starting, and stopping PS MAIL TTY. Before you install PS MAIL TTY, you must install Base TRANSFER. CDCMDEF Program CDCMDEF The CDCMDEF program uses configuration information in the DEFINECM file to generate the command files for PS MAIL TTY.
System Installation Procedures PS MAIL TTY Definition Procedure Example Here is an example of how you run the CDCMDEF program: 1> RUN CDCMDEF /OUT $S.#cmout,NOWAIT/ trancnfg This command specifies that program CDCMDEF resides on the TRANSFER userDSV, and that define file DEFINECM resides on subvolume TRANCNFG. In this example the TRANSFER user-DSV is the current default subvolume. CDCMDEF writes the generated files to subvolume TRANCNFG and the listing to the spooler file #CMOUT.
System Installation Procedures PS MAIL TTY Definition Procedure If any file that CDCMDEF generates exists, CDCMDEF moves the file to a new subvolume, writes the newly generated file to the subvolume specified in the define file, and issues a message telling the location of the old, moved file. CDCMDEF moves the file as described in "Definition Program File-Moving Procedure" later in this section. Do not directly edit the files that CDCMDEF generates, which are secured O-OO to discourage editing.
System Installation Procedures X400 Gateway Definition and Initialization X400 Gateway Definition and Initialization The X400 gateway is an optional component of a TRANSFER system. Installation of the X400 gateway requires that you run the CDX4DEF program to generate command files for configuring, starting, and stopping the X400 gateway. For an initial definition, the installation also generates files for initializing X400 gateway data files.
System Installation Procedures X400 Gateway Definition and Initialization INITIAL provides for initializing the X400 gateway. Specify INITIAL when you first install the X400 gateway or when you wish to reinitialize the gateway. REDEFINE provides for changing reconfigurable parameters for the X400 gateway for an existing X400 gateway configuration. REDEFINE is optional and is assumed if you specify neither REDEFINE nor INITIAL.
System Installation Procedures X400 Gateway Definition and Initialization The files generated on the configuration subvolume are: GX4UPDT, which contains a TACL macro that is invoked by XCNFG when the TRANSFER system is being reconfigured GX4CNFG, which contains the PATHWAY configurations for the X400 gateway servers GX4COOL, which contains GUARDIAN 90 command interpreter commands used by XCOOL to cool start the TRANSFER X400 gateway part of the TRANSFER PATHWAY configuration GX4COOL can also be run as a s
System Installation Procedures X400 Gateway Definition and Initialization GX4INIT Obey File The GX4INIT obey file contains the commands that invoke programs to create and initialize the X400 gateway. GX4INIT invokes a special program, X4INIT, that initializes the gateway data files, creates the special X400 gateway depot, and configures the X400-EXPORT, X400IMPORT, X400-EXPORT-PROBLEM, and X400-IMPORT-PROBLEM folders for that depot as a place to save items that are exported and imported.
System Installation Procedures Definition Program File-Moving Procedure Definition Program File-Moving Procedure All the definition programs generate files in the configuration subvolume. If the generated files exist, the definition programs move the old files to another subvolume. When the definition programs move these files, they write newly generated files to the configuration subvolume and issue messages telling the location of the old, moved files.
System Installation Procedures Configuring TRANSFER —XCNFG Program Configuring After you have defined all the components of your TRANSFER system, you run the TRANSFER (XCNFG XCNFG program to configure all the defined components. This program is generated Program) by running the definition program for Base TRANSFER (CDTRDEF). XCNFG resides in the configuration subvolume. XCNFG is a TACL macro; you must have TACL running on your system in order to run XCNFG.
System Installation Procedures Configuring TRANSFER —XCNFG Program The automatically generated configuration files and corresponding components are: GTRCNFG—for Base TRANSFER, including ADMIN and TMANAGER GMLCNFG—for PS MAIL 6530 GIMCNFG—for PS MAIL 3270 GCMCNFG—for PS MAIL TTY GX4CNFG—for the X400 gateway For configuration processing to be successful, the configuration file for the components included in your system must reside in the configuration subvolume.
System Installation Procedures Starting TRANSFER —XCOOL Program Starting TRANSFER The XCOOL program starts all defined TRANSFER system components. This (XCOOL Program) program is generated when you run the definition program for Base TRANSFER (CDTRDEF) and resides in the configuration subvolume. XCOOL is a TACL macro; you must have TACL running on your system in order to run XCOOL.
System Installation Procedures Starting TRANSFER —XCOOL Program To start TRANSFER successfully, the cool-start files for the components you include in your system must reside in the configuration subvolume. If one of these files does not reside in the configuration subvolume, XCOOL assumes that the component should not be started. To start TRANSFER, XCOOL performs the following operations: Running Your Applications Server Startup Messages 1. Performs a cool start of the PATHWAY system. 2.
System Installation Procedures SPREP Program The SPREP Program Note SPREP is a TRANSFER program that initializes the depot statistics facility when statistics collection is first configured on a system or when the statistics configuration changes. This program is used in the A-STATS server class although it is not truly a server. When initialization is complete and statistics are being collected, SPREP automatically stops.
System Installation Procedures SPREP Program 3. Start other TRANSFER servers including A-STATS. The A-STATS server, which uses the SPREP program, can be started whenever other TRANSFER servers are. The A-STATS server should have the following values set: MAXSERVERS = 1 AUTORESTART = 0 When A-STATS stops, do not restart it unless an error was printed to its OUT file. In this case, fix the error and restart A-STATS.
System Installation Procedures SPREP Program The SPREP Log In order to monitor what might be long runs of SPREP—for instance, the first time you enable statistics on an existing system—you can define a log file in DEFINETR as follows: TRStatsPrepLog $C.#SPREP.LOG —Specifies the log file for SPREP. You can change the —default value to a device, process, or disk file. If —the disk file does not exist, SPREP creates it. —Optional, reconfigurable parameter.
System Installation Procedures SPREP Program Figure 6-1 shows an example of an SPREP log. Figure 6-1.
System Installation Procedures Initializing Special Depots Initializing Special After you start TRANSFER or particular components for the first time, you must Depots initialize special depots. The names that follow in parentheses are the default depot names; all these except the names for the PUBLIC depot (PUBLIC) and the X400 gateway depot (_X400_) are configurable.
System Installation Procedures Configuring the Model Depot Folder-order creation defaults, which are used as the default ordering criteria and item retention times for all folders the correspondent creates. Ordering criteria determines how items are stored in a folder and the presentation order used when the folder is scanned.
System Installation Procedures Configuring the Model Group Depot and the PUBLIC Depot Configuring the Model Group Depot and the PUBLIC Depot When a TRANSFER system is installed, you must also initialize two special depots for interest groups: The model group depot The PUBLIC group The Model Group Depot The model group depot is a special depot from which a system administrator can create other interest-group depots.
System Installation Procedures Configuring the Model Group Depot and the PUBLIC Depot Attributes of the INBOX special folder Ordering criteria Item retention time For information about managing item retention time, see Section 11. Language and character map for the name of the INBOX folder Section 9, ”Using ADMIN to Administer TRANSFER,” of this guide explains the language and character map. For information about configuring the model group depot, see the TRANSFER Administration Guide.
System Installation Procedures Configuring the Asynchronous Requester Depot Configuring the Asynchronous Requester Depot (_TRANSFER_) The TRANSFER correspondent profile for the asynchronous requester depot should always be set to the GUARDIAN 90 user ID that owns the TRANSFER data files. This value matches the one specified in the DEFINETR file with the parameter TRGUARDIANUserId. When the TRANSFER system is first installed, the profile is properly initialized.
System Installation Procedures Configuring the X400 Depot Configuring the X400 Depot (_X400_) When the TRANSFER X400 gateway is configured at a gateway node, the special depot _X400_ is created. This depot is used to hold messages that are being exported or imported and to retain those messages for a period of time. If the gateway imports a message that refers to another X.400 message, it checks for the TRANSFER equivalent of that other message.
System Installation Procedures Stopping TRANSFER—XSTOP Program Stopping TRANSFER The XSTOP program shuts down the TRANSFER PATHWAY system and stops any (XSTOP Program) processes that continue to run after the shutdown. XSTOP stops all components. This program is generated when you run the definition program for Base TRANSFER (CDTRDEF) and resides in the configuration subvolume. XSTOP is a TACL macro; you must have TACL running on your system in order to run XSTOP.
System Installation Procedures Stopping TRANSFER—XSTOP Program To stop TRANSFER, XSTOP performs the following operations: 1. Stops the PATHWAY system by issuing PATHCOM commands as follows: STOP TERM * ABORT TERM * STOP TCP * FREEZE SERVER * STOP SERVER * 2. Shuts down the PATHWAY system. 3. Stops servers and TCPs that continue running after the shutdown by issuing explicit GUARDIAN 90 command interpreter STOP commands. 4.
System Installation Procedures TRANSFER Initial Installation Summary TRANSFER Initial This installation summary provides a check list of the steps for the initial installation of Installation Summary a TRANSFER system. The list includes both optional and required steps, syntax for the procedures, and comments. If your TRANSFER system does not include particular components, omit the steps for defining those components.
System Installation Procedures TRANSFER Initial Installation Summary 8. Purge GTRINIT, GTRFUP, and GTRLOAD to reduce the possibility of accidentally repeating OBEY GTRINIT and destroying data files. 9. Enter this command: 4> RUN CDMLDEF /OUT $S.#MLDEF/ [$vol.]cnfg-subvol to define PS MAIL 6530. (CDMLDEF resides on the TRANSFER user-DSV.) 10. Enter this command: 5> RUN CDIMDEF /OUT $S.#IMDEF/ [$vol.]cnfg-subvol to define PS MAIL 3270. (CDIMDEF resides on the TRANSFER user-DSV.) 11.
System Installation Procedures TRANSFER Initial Installation Summary 18. Enter this command: 10> RUN XCOOL to cool start the TRANSFER PATHWAY system. (XCOOL resides on your configuration subvolume). 19. Initialize special TRANSFER depots. 20. Shut down the TRANSFER PATHWAY system to make sure that everything is written to the disk, using this command: 1> RUN XSTOP XSTOP resides on your configuration subvolume.
System Installation Procedures Configuring TRANSFER into an Existing PATHWAY System Installing TRANSFER A TRANSFER system does not have to run in a separate PATHWAY system; it can be in an Existing integrated into an existing PATHWAY system (referred to as a mixed PATHWAY PATHWAY System system). The XCNFG, the XCOOL, and the XSTOP TACL macros, however, assume that the TRANSFER system runs in a separate PATHWAY system.
System Installation Procedures Starting TRANSFER in a Mixed PATHWAY System Starting TRANSFER in a Mixed PATHWAY System To start the TRANSFER system in a mixed PATHWAY system, you mimic the functions of the XCOOL TACL macro. You cannot use the XCOOL macro because it attempts to start a separate PATHWAY system. The XCOOL macro executes the GxxCOOL PATHCOM obey files and initializes the depot statistics facility if it is configured. You start your TRANSFER system by doing the following: 1.
System Installation Procedures Stopping TRANSFER in a Mixed PATHWAY System 2. Execute the GxxCOOL obey files, beginning with GTRCOOL : 8> PATHCOM $pm =OBEY GTRCOOL where $pm is the PATHMON process name of your existing PATHWAY system. The GTRCOOL obey file must be executed first because certain servers have to be running before the rest of the system can be started. 3.
System Installation Procedures Stopping TRANSFER in a Mixed PATHWAY System 3. Replace each line entry that you copied from the GxxSTOP files to the new file, def, as follows: GxxSTOP Format Obey File Format #STOP $ZTTA == TRAN-TCP #STOP $ZTAA == TAREQ-TCP #STOP $ZTXT == A-BASE-TEXT STOP TRAN-TCP STOP TAREQ-TCP FREEZE A-BASE-TEXT STOP A-BASE-TEXT . . . . . . . . . . . . . . . . . . . .
7 Customizing a TRANSFER System Overview Customizing your TRANSFER system allows you to meet special needs at your site by changing the configuration generated by a definition program. You can change—or customize—that configuration by maintaining customizing files on the configuration subvolume.
Customizing a TRANSFER System Using Customizing Files Using Customizing Customizing files are edit-format files that reside on the configuration subvolume. Files You create the files and add PATHCOM commands that alter or delete configured PATHWAY objects, add user-written components, and control user-written components.
Customizing a TRANSFER System Using Customizing Files Maintain the configuration changes that you want applied to the TRANSFER configuration in file CUSTCNFG so that the changes can be applied each time you run program XCNFG. Maintain the appropriate start and stop commands in files CUSTCOOL and CUSTSTOP, respectively, for the components you add with CUSTCNFG.
Customizing a TRANSFER System Customizing Server Classes Customizing Server The server classes for TRANSFER are defined through PATHCOM commands in Classes installation files on the configuration subvolume. There is a file for each component you define for your TRANSFER system. To change the configuration, you must put PATHCOM ALTER commands in file CUSTCNFG on your configuration subvolume.
Customizing a TRANSFER System General PARAM Specifications Table 7-1. General PARAM Specifications (Page 1 of 2) Parameter/Default Definition MAXREQUEST Default = 300 Minimum = 1 Number of bytes in the server input buffer. This parameter also sets the maximum size for requests issued to the server by your applications. PS MAIL 6530 and PS MAIL 3270 require that this parameter value for TISERV be 3000 or greater. MAXREPLY Default = 3000 Minimum = 1 Number of bytes in the server output buffer.
Customizing a TRANSFER System General PARAM Specifications Table 7-1. General PARAM Specifications (Page 2 of 2) 7–6 Parameter/Default Definition DEBUGLOGFORMAT Default = FALSE Must be TRUE or FALSE Format for logging to the debug log file. Set this parameter to TRUE for logging in hexadecimal ASCII format or to FALSE for logging in binary format. DEBUGLOGLEVEL Default = 3 Severity of reply-code error necessary for debug logging to occur.
Customizing a TRANSFER System TSCHED TRANSFER Scheduler (TSCHED) The TRANSFER scheduler, A-TSCHED server class, is defined for Base TRANSFER with default parameter specifications. You usually assign the TSCHED log file through the TRTSchedServLog parameter in the DEFINETR file. You can also assign the TSCHED log file in TMANAGER. The following is a sample ASSIGN statement generated in GTRCNFG: ASSIGN LOG, $S.#TSCHED.LOG This file receives messages for all types of scheduler activity.
Customizing a TRANSFER System TSCHED Table 7-2. TSCHED PARAM Specifications (Page 1 of 2) Parameter/Default Definition CHECKSESSIONHOUR Default = 0 (midnight) Must be 0 through 23 Hour of the day when the Session file is checked for unused sessions to be terminated. If PARAM UNHOLD is TRUE, any held records on the Ready file are released from hold at this time. This parameter is used in conjunction with the IDLESESSIONDELAY parameter for TWORK .
Customizing a TRANSFER System TSCHED Table 7-2. TSCHED PARAM Specifications (Page 2 of 2) Parameter/Default Definition UNHOLD Default = FALSE Must be TRUE or FALSE Disposition of held items. A held item is one a TAREQ has flagged for no further processing by TSCHED because of an unrecoverable error that is often transient. Held items caused by transient conditions will likely be processed correctly if tried again later. Held items are checked at restart of TSCHED or at CHECKSESSIONHOUR.
Customizing a TRANSFER System TEXTSRV Text Server (TEXTSRV) ASSIGN parameters in GTRCNFG specify the DTCMAPS file and the Text file. The Text servers that use these ASSIGNs are A-BASE-TEXT for Base TRANSFER, M6530-TEXT for PS MAIL 6530, and M3270-TEXT for PS MAIL 3270. The following are sample ASSIGN statements that are generated in GTRCNFG for the DTCMAPS file and the Text file: ASSIGN DTCMAPS, $DISCA.TRNSFER1.DTCMAPS ASSIGN TEXTFILE, $DISCA.TRNSFER1.
Customizing a TRANSFER System TISERV TRANSFER Interactive Server (TISERV) Two additional PARAM specifications apply to TISERV configured in the TISERV and TISERV-ASYNC server classes. These PARAM specifications are listed in Table 7-4. Table 7-4. TISERV PARAM Specifications Parameter/Default Definition ITEMIDCACHE Default = 20 The number of IDs reserved by the server. Increase this number if your system creates a large number of items.
Customizing a TRANSFER System TISERV Using TISERV Outside the PATHWAY Environment Although most TRANSFER clients are written as SCREEN COBOL programs that execute within PATHWAY TCPs, you can start a TISERV process for use outside the PATHWAY environment with clients written in COBOL, FORTRAN, TAL, C, or Pascal. You must observe the following rules: TISERV must run with the same user ID as that used to initialize the TRANSFER database.
Customizing a TRANSFER System GFSERV TRANSFER G-File Server (GFSERV) Another parameter applies to GFSERV in addition to those described in the general PARAM specifications. This parameter is described in Table 7-5 and applies to GFSERV configured in either the G-FILE or the TTY-G-FILE server class. Table 7-5. GFSERV PARAM Specification Parameter/Default Definition ITEMIDCACHE Default = 20 The number of IDs reserved by the server. Increase this number if your system creates a large number of items.
Customizing a TRANSFER System TWORK TRANSFER Worker Server (TWORK) TWORK servers are used by TAREQs to perform all local operations (except for delivering packages and invoking agents) and to perform the receiving part of all network operations. You must define the TWORK server class to have at least one member for every TAREQ you define at your node; that is, the MAXSERVERS parameter must equal or exceed the number of TAREQ pseudo-terminals you define.
Customizing a TRANSFER System TWORK Table 7-6. TWORK PARAM Specifications (Page 1 of 2) Parameter/Default Definition MAXSEND Default = 4000 Maximum = 10000 Maximum number of bytes that can be sent to a TRECV in a single message. For a particular network operation, the maximum number of bytes that can be sent in a single message is the lowest value of either this parameter or the MAXREQUEST PARAM specification for the remote TRECV server class.
Customizing a TRANSFER System TWORK Table 7-6. TWORK PARAM Specifications (Page 2 of 2) 7–16 Parameter/Default Definition EXPANDPRIORITY Default = 0 Maximum = 150 Priority in the EXPAND line when transporting packages to remote TRECV processes and when there is remote cancellation. If a value of 0 is specified, SETMODE is not performed and the normal EXPAND default is used.
Customizing a TRANSFER System TRECV TRANSFER Network Receiver (TRECV) TRECV servers are allocated by TFRONTs to handle all incoming network operations. The TFRONTs assign a TRECV for remote TWORKs as needed. The TRECV server class definition can be modified; however, great care must be exercised to ensure that deadlocks do not occur while TRANSFER is running. The MAXSERVERS parameter value must equal or exceed the number of TFRONT pseudo-terminals you define.
Customizing a TRANSFER System TRECV Table 7-7. TRECV PARAM Specifications 7–18 Parameter/Default Definition LOGRECSPEROPEN Default = 10000 Number of lines written to the log file after which the file is closed and reopened. MAXNOWAIT Default = 3 Must be 1 through 15 Maximum number of messages that a TWORK can have outstanding to a TRECV before having to wait for a response.
Customizing a TRANSFER System Customizing X400 Gateway Servers Customizing the You also customize your TRANSFER X400 gateway servers to meet the special needs TRANSFER X400 of your TRANSFER X400 network. In addition to the general considerations for Gateway Servers customizing your TRANSFER system given earlier in this section, you need to define the parameters discussed in the following sections.
Customizing a TRANSFER System X400 Import Server X400 Import Server (X400-IMPORTER) TRANSFER X400 import servers are defined in PATHWAY only if the TRANSFER X400 gateway is configured. This server is responsible for translating an X.400-format message into the equivalent TRANSFER package so that an X400 correspondent can send a message to a TRANSFER correspondent. The import server does not have a requester. Import server processes look for work in the X400 queue file.
Customizing a TRANSFER System X400 EXPORTER and IMPORTER PARAMs PARAM specifications that apply to both the X400-EXPORTER server and the X400-IMPORTER server are listed in Table 7-8. Table 7-8.
Customizing a TRANSFER System TDBSERV X400 Database Server (TDBSERV) Two additional PARAM specifications apply to the TDBSERV configuration. These PARAM specifications are listed in Table 7-9. Table 7-9. TDBSERV PARAM Specifications X400 Queue Manager Servers (X400-EMSERV and X400WMSERV) 7–22 Parameter/Default Definition ITEMIDCACHE Default = 20 The number of IDs reserved by the server. Increase this number if your system creates a large number of items.
Customizing a TRANSFER System Examples of Customizing TRANSFER Examples of To customize the TRANSFER PATHWAY configuration, add PATHCOM ALTER Customizing commands to the CUSTCNFG file. Sample commands to alter the servers are listed TRANSFER below together with descriptions of the commands. TRANSFER scheduler (A-TSCHED server class) ALTER A-TSCHED & ,RESET ASSIGN LOG & ,(PARAM CHECKSESSIONHOUR 2) These commands turn off logging and change the idle session check time from 12 a.m. (default) to 2 a.m.
8 Redefining a TRANSFER System Overview Redefinition is the process of changing the TRANSFER configuration.
Redefining a TRANSFER System Sample Redefinition Sample Redefinition Assume that you have an existing system that includes components Base TRANSFER and PS MAIL TTY and that you want to add the X400 gateway. The steps for defining the new X400 gateway component and redefining the existing components are: 1. Edit any define file requiring changes. Make sure that the TRGatewayNode parameter in DEFINETR is defined. 2. Run the CDTRDEF program to redefine Base TRANSFER. 3.
Redefining a TRANSFER System Redefinition Summary Redefinition Summary This installation procedure summary outlines the steps for redefining, reconfiguring, installing, starting, and stopping a TRANSFER system. The following list includes both optional and required steps, syntax for the procedures, and comments. Note that the list does not include any component initialization step, which would be required if you redefine a system and include either the X400 gateway or the Queue Manager for the first time.
Redefining a TRANSFER System Redefinition Summary 11. Enter RUN XCOOL Cool starts the TRANSFER PATHWAY system (XCOOL resides in your configuration subvolume.) 12. Update special TRANSFER depots if required. 13. Shut down the TRANSFER PATHWAY system to make sure that everything is written to the disk, using this command: 1> RUN XSTOP XSTOP resides on your configuration subvolume.
9 Using ADMIN to Administer TRANSFER Overview ADMIN provides a set of screens that allow you, as system manager, to control the TRANSFER environment. The ADMIN screens that you use for system control are described in this section. The other ADMIN screens are discussed in the TRANSFER Administration Guide, Vol. 1, Reference Manual.
Using ADMIN to Administer TRANSFER Flow of the ADMIN System Control Screens Figure 9-1.
Using ADMIN to Administer TRANSFER TRANSFER SYSTEM CONTROL Screen The TRANSFER SYSTEM CONTROL Screen The TRANSFER SYSTEM CONTROL screen displays the time limits for delivery of messages sent from your node. Messages received from other nodes are not affected by the limits set for your node. Correspondents without system administrative write privileges can see a version of this screen that has no F8 for updating the values. Figure 9-2 illustrates the SYSTEM CONTROL screen. Figure 9-2.
Using ADMIN to Administer TRANSFER TRANSFER SYSTEM CONTROL Screen Duration Controls—Maximum Package Lifespan Use the Maximum package lifespan field to set the maximum duration that TRANSFER monitors messages sent from your node. Duration Controls—Minimum Delivery Window Use the Minimum delivery window field to set the minimum duration for delivery of messages sent from your node.
Using ADMIN to Administer TRANSFER Configuring Parameters for System Control Configuring the Parameters for System Control As system manager with administrative write privileges, you can control the following actions of your TRANSFER delivery system from the SYSTEM CONTROL screen. A user application can also call a UOW (unit-of-work) to set or change the parameters. The TRANSFER Programming Guide discusses these UOWs.
Using ADMIN to Administer TRANSFER Enabling External Objects Enabling External Objects The External Objects Enabled field on the TRANSFER SYSTEM CONTROL screen indicates whether external objects are enabled. External objects are GUARDIAN 90 files attached to TRANSFER messages where data can be kept, rather than in the TRANSFER database.
Using ADMIN to Administer TRANSFER Setting Language and Character IDs Setting Language and Character IDs The Language ID field specifies the default national language on the system, and the Character map ID field indicates the default code set used to map characters on the system. American English has a language ID of 01. Table 9-1 lists the languages that Tandem defines, along with the numbers that specify them. Your Tandem system analyst can tell you which versions are available to you. Table 9-1.
Using ADMIN to Administer TRANSFER Setting Language and Character IDs Tandem USASCII has a code set of 65301. Table 9-2 lists the character maps defined by Tandem and the values that indicate them. Positive values are used in programs written in languages other than TAL and SCREEN COBOL; negative values are used in programs written in TAL and SCREEN COBOL. Table 9-2.
Using ADMIN to Administer TRANSFER Determining Interest Groups Determining Interest Groups The Interest Group Creation Privileges field indicates what user privileges are required for creating an interest group at the local node. An interest group is a group of correspondents who have a common interest or function; these correspondents share access to group folders and can add their names to group distribution lists. A value of C means that any local correspondent can create an interest group.
Using ADMIN to Administer TRANSFER SESSIONS IN PROGRESS Screen The SESSIONS IN The SESSIONS IN PROGRESS screen displays correspondent names for all sessions PROGRESS Screen that are currently active. You use this screen to trace a session that has accidentally been left running or to make sure that a correspondent has no sessions running when you want to delete that correspondent. If a correspondent has more than one session, the correspondent’s name is listed for each.
Using ADMIN to Administer TRANSFER SESSIONS IN PROGRESS Screen Function Keys The bottom of the SESSIONS IN PROGRESS screen lists the functions that you can perform by pressing the indicated keys. Get the previous page of the SESSIONS IN PROGRESS screen by pressing PREV PAGE. Get the first page of the SESSIONS IN PROGRESS screen by pressing SF1. Get the next page of the SESSIONS IN PROGRESS screen by pressing NEXT PAGE. Recover the SESSIONS IN PROGRESS screen to its previous state by pressing SF14.
Using ADMIN to Administer TRANSFER Screens Used for Depot Statistics Screens Used for TRANSFER can collect statistics telling you how much storage is being used for each Depot Storage depot on the system. These depot storage statistics provide important information for Statistics both individual correspondents and system managers; for example: Correspondents can use them to decide how to use their depots efficiently. Administrators can use them to charge correspondents for the data they are saving.
Using ADMIN to Administer TRANSFER Screens Used for Depot Statistics Each snapshot of depot storage represents depot statistics information for a set time period, or sample interval. Using the configuration parameters, you, as system manager with your administrative write privileges, can control the timing of the snapshot, naming the hour and minute you want statistics to be collected and the interval at which you want the samples to be taken. For example, if the base time is set to 1:30 a.m.
Using ADMIN to Administer TRANSFER Configuring Parameters for Statistics Collection Configuring the Parameters for Statistics Collection TRANSFER permits three ways of configuring the parameters for collecting depot storage statistics: A configuration program, CDTRDEF, allows these parameters to be entered through the Base TRANSFER define file, DEFINETR. You configure the depot statistics facility with this program only when you initialize a TRANSFER system.
Using ADMIN to Administer TRANSFER Configuring Parameters for Statistics Collection The oldest statistic collected is overwritten when the number of samples collected is greater than the configured number of samples; in this example, when week eleven’s storage statistic is recorded, week one’s storage statistic disappears. The minimum number you can specify is 1; the maximum number of samples and averages combined is 58.
Using ADMIN to Administer TRANSFER Configuring Parameters for Statistics Collection STANDARD ITEM COUNTING indicates that every instance of an item saved in a depot is counted.
Using ADMIN to Administer TRANSFER DEPOT STATISTICS CONFIGURATION Screen The DEPOT STATISTICS CONFIGURATION Screen There are two versions of the DEPOT STATISTICS CONFIGURATION screen: one that allows all users to view the current configuration for storage statistics and one that allows you, with your administrative write privileges, to set the next configuration for depot storage statistics.
Using ADMIN to Administer TRANSFER DEPOT STATISTICS CONFIGURATION Screen Displaying the Screen From the ADMIN MAIN MENU screen, press SF3 to display the DEPOT STATISTICS CONFIGURATION screen. Field Descriptions The DEPOT STATISTICS CONFIGURATION screen presents you the following fields for entering data and for displaying information. Current Config The Current Config column gives the current settings for collecting statistics on the running TRANSFER system.
Using ADMIN to Administer TRANSFER DEPOT STATISTICS CONFIGURATION Screen Number of Samples (Per Average) The Number of Samples (Per Average) field indicates how many samples are collected for each depot. Number of Averages The Number of Averages field indicates how many averaged samples are saved. Standard Item Counting The Standard Item Counting field, when set to YES (the default), indicates that the same item is accounted for in a depot’s statistics every time it is saved in the depot.
Using ADMIN to Administer TRANSFER Example of Reconfiguring the Depot Statistics Facility Example of Reconfiguring the Depot Statistics Facility As the system manager, you decide that you need to collect statistics once a week for a quarterly report and keep track of them for a year. Figure 9-5 illustrates the existing configuration on the DEPOT STATISTICS CONFIGURATION screen. Figure 9-5.
Using ADMIN to Administer TRANSFER Example of Reconfiguring the Depot Statistics Facility 7. Do not change the Standard Item Counting default because counting only one incidence of an item takes more system resources than you are willing to use. 8. Press F8 to update the values. After you stop the TRANSFER system and bring it up again, the new configuration takes effect. Figure 9-6 illustrates the new configuration on the DEPOT STATISTICS CONFIGURATION screen. Figure 9-6.
Using ADMIN to Administer TRANSFER Changing Parameters Changing Parameters If you are keeping previous samples and you change any of the other configuration parameters, the samples you have collected are backed up to another file called the DEPSTATO file the next time that you run XCOOL. (These old statistics are accessible through the OLD STATISTICS screen.) TRANSFER keeps only one set of old statistics. If a DEPSTATO file already exists, it is purged.
Using ADMIN to Administer TRANSFER X400 GATEWAY ATTRIBUTES Screen The X400 GATEWAY The X400 GATEWAY ATTRIBUTES screen displays the X400 name attributes for your ATTRIBUTES Screen local gateway node. When correspondents send packages through the TRANSFER X400 gateway to nodes that are not on TRANSFER systems, their X400 correspondent names have these attributes. If foreign correspondents want to send packages to this node, they need to include these attributes when addressing their messages.
Using ADMIN to Administer TRANSFER X400 GATEWAY ATTRIBUTES Screen Field Attributes The X400 GATEWAY ATTRIBUTES screen displays information in the following fields; you cannot enter data on the screen. Gateway Node The Gateway Node field displays the name of the Tandem system node that connects to the external, X.400-based public network. Country The Country field displays the country in which your local node is located. ADMD The ADMD field displays your Administration Management Domain.
10 TMANAGER Overview TMANAGER offers tools to help system managers run their TRANSFER delivery systems; it consists of three parts: The TMANAGER screen interface, which gives you a set of screens for doing a variety of tasks in managing TRANSFER The TMANAGER application provides monitoring, log control, and tracing capabilities at the local node. When you choose a function by pressing a function key listed on the TMANAGER MAIN MENU screen, TMANAGER displays the appropriate screen.
TMANAGER TMANAGER Screens Figure 10-1.
TMANAGER TMANAGER Screens For screens that have more than one page, page numbers appear in the upper right corner of the screen. Regardless of the language and character set used by ADMIN, TMANAGER uses English and US ASCII. Function Keys Each TMANAGER screen lists the function keys on your terminal keyboard that are valid for that screen and the task requested by each key. An unshifted function key is identified by the letter F and the number of the key (for example, F16).
TMANAGER TMANAGER Screens Advice Messages TMANAGER uses the bottom line on each screen to return advice messages: an error message with its accompanying error number, a warning message, or a confirmation message that acknowledges the completion of an operation. Error messages display an accompanying error number and usually a detail code. TMANAGER client error numbers are in the 5200-5299 range. System management server (SMSERV) errors fall in the 6400-6499 range.
TMANAGER Accessing TMANAGER Accessing TMANAGER You can access TMANAGER by pressing SF2 from the ADMIN MAIN MENU screen. You can also run the TMANAGER program in your TRANSFER PATHWAY system; you get TMANAGER from PATHCOM, which is the command interface to the PATHWAY transaction processing system. You begin your TMANAGER session by using the TMANAGER MAIN MENU screen.
TMANAGER LOGON Screen The LOGON Screen You use the LOGON screen to log on to TMANAGER unless TMANAGER is integrated with another application; in that case, the MAIN MENU screen is the first TMANAGER screen to appear. Figure 10-3 illustrates the LOGON screen. Figure 10-3. TMANAGER LOGON Screen T9110C30 - 9JUL91 TMANAGER LOGON SCREEN CORRESPONDENT NAME: PASSWORD: Copyright Tandem Computers Incorporated 1986, 1987, 1989 SF14=Recover F15=Help F16=Logon Type correct name and password. Then press F16.
TMANAGER Logging On to TMANAGER Logging On to TMANAGER If you run TMANAGER as a standalone program, you access the LOGON screen from PATHCOM. From your command interpreter, type: TACL 1> PATHCOM $process-name $process-name is the name of the PATHMON under which your TRANSFER system is running. PATHMON is the central monitoring process in a PATHWAY system. With most TRANSFER systems, the default process name is $TRPM.
TMANAGER MAIN MENU Screen The MAIN MENU The TMANAGER MAIN MENU screen displays a list of the TMANAGER functions Screen you can request and the function keys you press for performing them. This screen is not only the starting point for every TMANAGER session but also the transition for moving from one TMANAGER function to another.
TMANAGER MAIN MENU Screen the alarm thresholds at which TMANAGER notifies you of a given event. You can also enable and configure the active alarm feature provided by TSAMPLE. Log Functions Log Functions allow you to control logging parameters and log file locations used by the TSCHED, TWORK, AND TRECV servers.
TMANAGER SCHEDULER QUEUE SAMPLES Screen Screens Used for Monitor Functions You use several TMANAGER screens for monitoring: the SCHEDULER QUEUE SAMPLES screen, the DATABASE SAMPLES screens and the related FILE DETAIL screen, and the MONITOR CONFIGURATION screen. The SCHEDULER The SCHEDULER QUEUE SAMPLES screen allows you to monitor the activity of QUEUE SAMPLES TRANSFER scheduler queues.
TMANAGER SCHEDULER QUEUE SAMPLES Screen Figure 10-5 illustrates the SCHEDULER QUEUE SAMPLES screen. Figure 10-5.
TMANAGER SCHEDULER QUEUE SAMPLES Screen Totals The Totals field gives the total number of samples at the given time. Function Keys The SCHEDULER QUEUE SAMPLES screen lists the tasks you can perform from this screen by pressing the indicated function keys. Sample Queue (F1) selects the queue name—READY, TIME, NET or HELD— specified by the cursor position and retrieves the most recent queue sample data for that queue.
TMANAGER Using the SCHEDULER QUEUE SAMPLES Screen Using the SCHEDULER QUEUE SAMPLES Screen The SCHEDULER QUEUE SAMPLES screen initially displays the four most recent queue samples collected by TSAMPLE for the READY queue. You can select any of the other queues by placing the cursor next to the queue name and pressing F1 for the Sample Queue function. The Queue field in the top left corner of the screen shows the name of the queue currently displayed.
TMANAGER Using the SCHEDULER QUEUE SAMPLES Screen Remote Shipment entries occur only if there was a failure while processing a submit entry that required shipment to a remote node. The count for Remote Shipment work goes up and down depending on whether remote systems are available. If a remote system is not available, the entry is placed in the NET queue for retry later. Remote shipment requests in the NET queue are entries that have been tried previously when the remote system was not available.
TMANAGER DATABASE SAMPLES Screen The DATABASE The two DATABASE SAMPLES screens display statistics that the TRANSFER SAMPLES Screen asynchronous system-management server, TSAMPLE, gathers for TRANSFER database files. They tell you the file code, the percent of file capacity used, and the current end of each file (EOF); in addition, you see whether each file is partitioned.
TMANAGER DATABASE SAMPLES Screen Figure 10-7 illustrates the second page of the DATABASE SAMPLES screens. Figure 10-7.
TMANAGER DATABASE SAMPLES Screen Partitioned The Partitioned column tells whether the file is partitioned. EOF The EOF column records the number of bytes at the end of the file Function Keys The DATABASE SAMPLES screens lists the tasks you can perform from these screens by pressing the indicated function keys. Later Sample (F4) moves you forward in time to retrieve more recent database sample information for all the files displayed.
TMANAGER Using the DATABASE SAMPLES Screen Using the DATABASE SAMPLES Screens The left of each screen lists the logical file name of each TRANSFER database file that TMANAGER monitors. The last two files on Page 2 of the screen, the P1MsgID file and the P2MsgID file, are displayed only if the node is a TRANSFER X400 gateway node. The top of the screen displays the time of the current sample.
TMANAGER FILE DETAIL Screen The FILE DETAIL Screen The FILE DETAIL screen displays detailed, current information for a selected TRANSFER database file. Figure 10-8 illustrates the FILE DETAIL screen. Figure 10-8. FILE DETAIL Screen TMANAGER FILE DETAIL SCREEN File: \FIGGY.$M8.TMAILDBA.PROFILE Partition Location \FIGGY.$M8.
TMANAGER FILE DETAIL Screen Partition Location The Partition Location field gives you the system, volume, and subvolume where the file or file partition is located. If only one partition is displayed, the file is not partitioned. %Full The %Full field gives you the percent of the file capacity used. MaxSize MaxSize, or maximum size, is the number of bytes that can be contained in the partition (or unpartitioned file) if all extents are fully allocated.
TMANAGER FILE DETAIL Screen Function Keys The FILE DETAIL screen lists the tasks you can perform from this screen by pressing the indicated function keys. Detail (F7) gets detailed information for the file named in the File field. You can specify any local or remote file. Print (F9) prints the current screen. Output goes to the location specified in the Current Printer Location field on the TMANAGER MAIN MENU screen. Recover (SF14) recovers the screen to its last state.
TMANAGER MONITOR CONFIGURATION Screen The MONITOR The MONITOR CONFIGURATION screen allows you to configure sample intervals CONFIGURATION for the TRANSFER asynchronous system-management server, TSAMPLE; to set Screen thresholds for alarms; and to enable an active alarm notification feature. No samples are taken until you configure values on the MONITOR CONFIGURATION screen. The MONITOR CONFIGURATION screen displays the current sample intervals and threshold settings for the local node.
TMANAGER MONITOR CONFIGURATION Screen Active Alarm Log Location You use the Active Alarm Log Location field to specify the location of your notification log file. Database Sample Interval You use the Database Sample Interval field to set the interval for database sampling. Queue Sample Interval You use the Queue Sample Interval field to set the interval for queue sampling. Database Threshold You use the Database Threshold field to set the threshold for database file capacity.
TMANAGER Using the MONITOR CONFIGURATION Screen Using the MONITOR CONFIGURATION Screen You can specify a database sample interval and a queue sample interval in minutes (M), hours (H), or days (D), with units from 0 to 9999. A zero indicates infinity, or no sample interval. The minimum nonzero interval for both the database sample and the queue sample is 15 minutes. The default for both is 0 (infinity).
TMANAGER Sample Monitor Configuration Considerations in Configuring TMANAGER Consider the following as you configure TMANAGER monitoring: TSAMPLE counts the records in the READY, TIME, and NET queues based on the queue sample time interval. If the time interval is set to a low number (such as 15 minutes) and the queues have a large number of records (such as 20,000), the TSAMPLE server constantly reads the queues and can contend with TRANSFER operations.
TMANAGER Sample Monitor Configuration Database Threshold: 80% The database threshold depends on how full you want any part of the database to grow before raising an alarm. Queue Thresholds: Queue Work MaxValue 1 1 3 4 4 4 1 10 1 1 3 5 20 1000 10 1 1 1 Tandem recommends monitoring the READY and HELD queues; normally you do not need to monitor the TIME file. Monitoring the NET queue can alert you to potential network problems.
TMANAGER LOG CONTROL Screen Screen Used for Log The second part of the TMANAGER MAIN MENU screen lists the LOG CONTROL Functions screen that lets you change TMANAGER logging functions. Dynamic log control allows you to alter logging operations for the TSCHED, TWORK, and TRECV servers.
TMANAGER LOG CONTROL Screen Logging Records Per Open The Log Records Per Open field specifies the number of lines written to the log file after which the file is closed and reopened. The default is 10000. Log File Location The Log File Location field contains the GUARDIAN 90 file name of the log file location. Function Keys The LOG CONTROL screen lists the tasks you can perform from this screen by pressing the indicated function keys. Print (F9) prints the current screen.
TMANAGER SCHEDULER QUEUE SCAN Screen Screens Used for TMANAGER provides screens to help you answer a correspondent who asks, "What Probe and Trace happened to the package I sent?" You use several of these screens for analyzing Functions problems with item transport and delivery: the SCHEDULER QUEUE SCAN screen and the FOLDER SCAN screen, with their related ITEM TRACE screen; and the RECIPIENT SELECT screen, with its related RECIPIENT DISPLAY and X400 RECIPIENT screens.
TMANAGER SCHEDULER QUEUE SCAN Screen Field Descriptions The SCHEDULER QUEUE SCAN screen presents you the following fields for entering data and for displaying information. READY TIME NET HELD You select the queue you want to scan by marking the queue in this list with your cursor. Item ID The Item ID field gives the ID of the item to be scanned. Current Queue The Current Queue field gives the queue currently being scanned. Creator The Creator field gives the creator name associated with the entry.
TMANAGER SCHEDULER QUEUE SCAN Screen Function Keys The SCHEDULER QUEUE SCAN screen lists the tasks you can perform from this screen by pressing the indicated function keys. First Page (SF4) displays the next 13 entries or occurrences of the selected item to be processed. Next Page (NEXT PAGE) displays the subsequent 13 entries or occurrences of the selected item in their processing order.
TMANAGER Using the SCHEDULER QUEUE SCAN Screen Using the SCHEDULER QUEUE SCAN Screen When you select the Queue Scan function from the MAIN MENU screen, the SCHEDULER QUEUE SCAN screen displays the first 13 entries in the READY queue, unless you enter an item ID on the MAIN MENU screen. In that case, the first 13 entries for that item ID in the READY file are displayed and the Item ID field at the top of the screen is filled in.
TMANAGER Using the SCHEDULER QUEUE SCAN Screen Type of Work is one of 16 types of work represented by the entry, as follows: 1: 2: 3: 4: 5: 6: 7: 8: Note Submit Package Cancel Package Local Delivery Local Package Expiration Remote Shipment Remote Cancel Certify Package Delete Item 9: 10: 11: 12: 13: 16: 1001: 9999: Delivery Ends Unsave Item Delete External Object Translation Requested Receipt Notification Nonreceipt Notification End Session Invalid Function Code Delete Item deletes an item from the TRA
TMANAGER FOLDER SCAN Screen The FOLDER SCAN The TMANAGER FOLDER SCAN screen provides one way that correspondents can Screen trace a package and determine its current status in the TRANSFER delivery system. They can scan a given folder and select an item to obtain detailed information. The desired folder can be specified from either the TMANAGER MAIN MENU screen or the FOLDER SCAN screen. If it is a private folder, the current correspondent must own the folder that is to be scanned.
TMANAGER FOLDER SCAN Screen Field Descriptions The FOLDER SCAN screen presents you the following fields for entering data and for displaying information. Folder The Folder field at the upper left of the screen displays the folder currently being scanned. Creator The Creator field gives you the first 20 characters of the name of the creator of the item. Subject The Subject field displays the first 36 characters of the subject line of the item.
TMANAGER Using the FOLDER SCAN Screen Using the FOLDER SCAN Screen The FOLDER SCAN screen displays up to 12 folder items on each screen. You can press NEXT PAGE and PREV PAGE to view other items in the current folder. The Folder field at the upper left of the screen displays the folder currently being scanned. To scan another folder, type the name of the desired folder and press F11. You can enter the name of a shared group folder if you are a group member.
TMANAGER ITEM TRACE Screen The ITEM TRACE The ITEM TRACE screen displays detailed information about the status of a given Screen item based on the information available at the local node. Figure 10-13 shows the ITEM TRACE screen. Figure 10-13. ITEM TRACE Screen TMANAGER ITEM TRACE SCREEN Item Id: -2350, 191, 0, 7, -21125, 0 Package Header: Y Sent: 1990-11-12 04:37:45 Item Size: 0 Creator: HOLE_TORBEN @OAK Folder Entry Owner: AUSTEN_JANE @BATH Subject: More help, please....
TMANAGER ITEM TRACE Screen Field Descriptions Except for the Item Id field, the fields on the ITEM TRACE screen are for displaying information only. Item Id The Item Id field gives the ID of the selected item. Package Header If the item is a package header, Package Header is set to Y for yes; if not, it is set to N for no. Sent The Sent field tells you the date and time that the item was submitted. If the item was not submitted for delivery, this field contains zeros.
TMANAGER ITEM TRACE Screen Item Type The Item Type field indicates the type of the item, as defined by Tandem. Users can define other item types.
TMANAGER ITEM TRACE Screen Application Id The Application Id field gives the ID of the application that created this item. The range of application IDs that can invoke an agent must be between 0 and 9999.
TMANAGER ITEM TRACE Screen X400 Orig The X400 Orig (X400 originated) field is set to Y (yes)if the item was imported by the TRANSFER X400 gateway; N (no) indicates that the item was not imported. Converted The Converted field is set to Y (yes) if this is an X400 message that was converted before being imported by the TRANSFER X400 gateway; N (no) indicates that the item was not converted before being imported.
TMANAGER ITEM TRACE Screen Defer Submit The Defer Submit field indicates whether the transport of packages can be deferred to other nodes until a specific time. Created The Created field gives the date and time that the item was created. Earliest Delivery Earliest Delivery is the earliest date and time that the package can be delivered. Expires Expires is the date and time at which the item expires. If the expiration date and time are not set, this field contains zeros.
TMANAGER ITEM TRACE Screen Considerations Consider the following as you view the ITEM TRACE screen: The item ID is displayed in a format like that for TSCHED and TWORK item-ID logging. You must enter item IDs in the same format: n, n, n, n, n, n where n is an integer in the range -32768 to 32767. The integers must be separated by a comma and exactly one space. To get information for another item, enter that item ID in the Item Id field and press F12.
TMANAGER RECIPIENT SELECT Screen The RECIPIENT The RECIPIENT SELECT screen and its related RECIPIENT DISPLAY and X400 SELECT Screen RECIPIENT screens provide a complete list of TRANSFER recipients for a specified package. You can learn the delivery status of each local recipient, as well as whether the package has been sent from the local node to remote recipients. Figure 10-14 shows the RECIPIENT SELECT Screen. Figure 10-14.
TMANAGER RECIPIENT SELECT Screen Options The Option field offers you the following options for selectively retrieving records. Y (yes) selects the option; N (no) suppresses the option. Get Exact selects the recipient record that exactly matches the name specified in the Starting Recipient Name field. Ignore Suffix retrieves all recipient records for the given recipient, regardless of what suffix might be appended to the recipient name.
TMANAGER RECIPIENT SELECT Screen Original Recip Original Recip specifies whether the recipient was an original recipient of the package or whether the recipient name came from a distribution list. Local Dlist Local Dlist indicates whether the recipient is a local distribution list. Local Corr Local Corr indicates whether the recipient is a local correspondent. Remote Recip Remote Recip indicates whether the recipient is defined at a remote node.
TMANAGER RECIPIENT SELECT Screen Function Keys The RECIPIENT SELECT screen lists the tasks you can perform from this screen by pressing the indicated function keys. Start Showing Recips (F4) calls the RECIPIENT DISPLAY screen, to display the first recipient record that matches the entry in the Starting Recipient Name field. Restore Defaults (SF4) restores the default screen values that were originally displayed.
TMANAGER RECIPIENT DISPLAY Screen The RECIPIENT The RECIPIENT DISPLAY screen displays detailed information for an individual DISPLAY Screen recipient. It initially displays the first recipient that matches the search criteria that you specify on the RECIPIENT SELECT screen. You can successively retrieve additional recipient names by pressing F5. Press F4 to redisplay information for the first recipient. Recipient records are ordered in ascending order by system name.
TMANAGER RECIPIENT DISPLAY Screen Field Descriptions The RECIPIENT DISPLAY screen displays information in the following fields. Recipient Name The Recipient Name field at the top of the screen contains the fully qualified correspondent name of the current recipient (unless you specified a local recipient name without the node). If the name includes _X400_ @ gateway node (n1,n2,n3), the recipient has received the item through the TRANSFER X400 gateway.
TMANAGER RECIPIENT DISPLAY Screen Function Keys The RECIPIENT DISPLAY screen lists the tasks you can perform from this screen by pressing the indicated function keys. Show First Recip (F4) displays the first recipient record that matches the selection on the RECIPIENT SELECT screen. Show Next Recip (F5) displays detailed information for the next recipient in the selected set. Print (F9) prints the current screen.
TMANAGER X400 RECIPIENT Screen The X400 RECIPIENT The X400 RECIPIENT screens provide a list of the X400 recipients for the current item Screen ID. The X400 recipient information is split across two screens. The first page of the screen displays a breakdown of each X400 address into its X400 O/R fields. The second page of the screen displays the free-form name and domain-defined attributes. These screens are for display purposes only.
TMANAGER X400 RECIPIENT Screen Field Descriptions—Page 1 The first page of the X400 RECIPIENT screen displays information in the following fields. Country through Organization Name The fields in the top half of the screen are elements of the O/R address used by the OSI/MHS system. See the Tandem OSI/MHS Configuration and Management Manual for definitions. Recipient Type Recipient Type indicates the type of recipient record: 323 is a CC (Courtesy Copy) Recipient. 324 is a BCC (Blind Copy) Recipient.
TMANAGER X400 RECIPIENT Screen Receipt Notify Receipt Notify is a status flag; Y indicates that notification of receipt is set. Non-Rcpt Notify Non-Rcpt Notify is a status flag; Y indicates that notification of nonreceipt is set. Return IP Msg Return IP Msg is a status flag; Y indicates that return interpersonal message is set.
TMANAGER X400 RECIPIENT Screen You get the second page of the X400 RECIPIENT screen by pressing the NEXT PAGE key. Figure 10-17 shows the second page of the X400 RECIPIENT screen. Figure 10-17.
TMANAGER Configuring TMANAGER Configuring Besides the TRANSFER interactive server, TISERV, and the TRANSFER text server, TMANAGER TEXTSRV, two additional TRANSFER servers must be configured for TMANAGER: SMSERV and TSAMPLE. You alter the ASSIGNs and PARAMs through PATHCOM in the same way that you handle all TRANSFER servers. SMSERV SMSERV is the interactive system-management server for TRANSFER. All standard TRANSFER server ASSIGNs and PARAMs are supported by SMSERV.
TMANAGER Configuring TMANAGER The PARAM WRITEENABLE, if found and TRUE, causes TSAMPLE to write the generated database samples to the DBSAMPL file and generated queue samples to the QSAMPL file. If the WRITEENABLE PARAM is either not TRUE or not found, the database and TSCHED queues are monitored and you get an alarm message, but no samples are written. When you configure this option, consider that you can save storage by not writing the samples to a file, while still providing an active alarm.
TMANAGER Installing and Managing TMANAGER Installing and The TRANSFER installation procedures automatically configure the SMSERV and Managing TMANAGER TSAMPLE server classes in the TRANSFER PATHWAY configuration, create the DBSAMPL and QSAMPL files, and add the required Namespace entries to the Configuration Directory. In addition, the installation procedures add a program for the standalone version of TMANAGER to the base TRANSFER PATHWAY configuration. (TMANAGER is also accessible from the ADMIN client.
11 Managing a TRANSFER System Overview Once the TRANSFER delivery system is running, you want to check TRANSFER to ensure that the system is operating smoothly. Several Tandem software products are used to control and monitor TRANSFER and your TRANSFER applications. System Control To control the TRANSFER delivery system you need to establish rules for running TRANSFER and to solve problems as they arise.
Managing a TRANSFER System X400 Domain Names X400 Domain Names Before any exchange of messages with a foreign X.400 network can take place, you need to define and initialize an X400 gateway node. Many factors determine which node you choose as the gateway node, such as: The effect of increased message traffic and message storage Connections to outside X.
Managing a TRANSFER System Controlling Priorities Controlling Priorities You can make your TRANSFER system more efficient by controlling the priorities of the jobs it performs. You can manipulate job priority by controlling the parameters for package delivery, by restricting the time when work with low priority is processed, and by using cleanup TAREQs for housekeeping tasks. Setting Package Delivery Parameters When a package is sent, several parameters are involved in the actual delivery.
Managing a TRANSFER System Using Cleanup TAREQs Restricting the Priority Window You can restrict the processing of work with priorities lower than a specified value to within a specific window of time. For example, you can allow work with a priority of 50 or less to be handled only between 8 p.m. and 5 a.m., freeing the system to concentrate on higher-priority work during the other hours.
Managing a TRANSFER System Item Retention Times You configure cleanup TAREQs in the DEFINETR file, explained in Section 5. Cleanup TAREQS do not replace regular TAREQs. Regular TAREQs must always be configured. Be sure to adjust the number of TISERV-ASYNC and TWORK servers to compensate for the extra TAREQs. Item Retention Times You can manage the disk space and scheduling resources used by TRANSFER by managing item retention time.
Managing a TRANSFER System Idle Sessions When initializing the model depot and model group depot, be aware of the initial profile values for item retention time that Tandem provides and the options to change the values: The default value provided by Tandem for the depot and the group-depot profile item retention time attribute is infinity. Lower this value when initializing the model depot to set a constraint for correspondent and group depots.
Managing a TRANSFER System Idle Sessions Example The following example uses the default PARAM values: the TSCHED CHECKSESSIONHOUR PARAM is set to 0, meaning midnight, and the TWORK IDLESESSIONDELAY PARAM is set to 24. Friday 14:00 SMITH_JOHN logs on to TRANSFER. 16:00 JONES_MARY logs on to TRANSFER. 17:00 John goes home for the weekend, but he forgets to log off. 17:15 Mary goes home for the evening; she also forgets to log off. Saturday 00:00 Both sessions have been idle for about seven hours.
Managing a TRANSFER System Configuration Changes Configuration Changes After TRANSFER has been initialized, you might want to change some of the configuration data defined at your node. Information about configuration changes appears in Section 7, “Customizing a TRANSFER System”; in Section 8, “Redefining a TRANSFER System”; and in the following subsection, “Moving TRANSFER Data Files.
Managing a TRANSFER System Moving TRANSFER Data Files Moving TRANSFER Data Files TRANSFER data files follow particular rules that allow TRANSFER software to use the files. The rules must be maintained when the files are moved. The rules for the files and the steps required to move the files are described in the following paragraphs. These rules and steps use the term “name” to refer to a fully qualified file specification that includes the volume, subvolume, and file name ($vol.subvol.filename).
Managing a TRANSFER System Steps for Moving TRANSFER Data Files Steps for Moving TRANSFER Data Files To move TRANSFER data files, follow these steps (not all data files require all steps): 1. Stop TRANSFER. 2. Move the actual data files. You can use the File Utility Program (FUP) either to rename or to duplicate the files. If you move an alternate key file (for the DSDATA, INTGROUP, IFOLDER, NAME, NET, READY, or TIME primary key files), use FUP to alter the affected primary key file.
Managing a TRANSFER System Storing New Names with the NALOAD Program Storing New Names with the NALOAD Program To move the Base TRANSFER data files other than the name directory files, you must use the NALOAD program to change the TRANSFER configuration entries stored in the Name files. To use the NALOAD program, follow these steps: 1. Stop all TRANSFER processes except the NAMESRV and TEXTSRV programs (the A-NAME and A-BASE-TEXT server classes), or start only the NAMESRV and TEXTSRV programs.
Managing a TRANSFER System Storing New Names with the NALOAD Program Table 11-1 summarizes the new file names that you can specify for the configured names. The actual file-name portion of .new-file-name does not have to be the name in the list. For example, you can specify a name other than PROFILE for the Profile file. If, however, you retain the listed file names, the files and corresponding functions in the TRANSFER system are easy to identify. Table 11-1.
Managing a TRANSFER System Starting the TEXTSRV and NAMESRV Programs Starting the TEXTSRV and NAMESRV Programs To run the NALOAD program and the TCHECK utility, which is described later in this section, all TRANSFER servers except the Text server (TEXTSRV program) and the Name server (NAMESRV program) must be stopped. The Text server must be running before you start the Name server.
Managing a TRANSFER System Starting the TEXTSRV and NAMESRV Programs An obey file for running the NAMESRV program looks like this: :ASSIGN TEXTSRV, $text-server process name :PARAM BACKUPCPU 1 :RUN $SYS.TRAN.NAMESRV /IN $DATA.TRAN.DSDATA,& out $S.#logfile, NAME $T, NOWAIT, CPU 0/ :DELAY 5 SEC $text-server is the process name of the Text server. If you accepted the default names when you initialized TRANSFER, this parameter is $ZTXT. $SYS.TRAN is the volume and subvolume of the TRANSFER user-DSV. $DATA.
Managing a TRANSFER System Network Traffic Logging Handling a TRANSFER Network Two features help you handle traffic between nodes in your TRANSFER network. You can determine how much network traffic TRANSFER generates, and you can set the priority for your EXPAND line. Network Traffic Logging The TRANSFER TWORK and TRECV processes can write network traffic information to a file, which can then be accessed to provide an ENFORM report for a given node.
Managing a TRANSFER System Network Traffic Logging Current top-level item creator name The ITEM-CREATOR field helps identify the package that is being transported. If there are component items, they are added to the transport, but only the top-level item is identified. Current top-level item subject record The SUBJECT field helps identify the package that is being transported. If there are component items, they are added to the transport, but only the top-level item is identified.
Managing a TRANSFER System Creating the Traffic Log Creating the Traffic Log. The name of the file to be used as the network traffic log is communicated to the TWORK and TRECV processes through an ASSIGN. The file must be created before the processes start up. If the ASSIGN is not specified, logging does not occur. If the ASSIGN is specified and the file does not exist or if there is some other problem opening the file, no logging occurs.
Managing a TRANSFER System Creating the Traffic Log If you get this message, resolve the problem and stop and restart the servers. The most common problems are that the file specified does not exist or that the file name was specified incorrectly. If there is a problem writing to the file, the servers report the following message each time the error occurs: Error nnn writing to the traffic log file yyyyy. where nnn is the file error number and yyyyy is the file name.
Managing a TRANSFER System TWORK EXPAND Priority TWORK EXPAND Priority You can control your network operations by setting the priority for the EXPAND line when transporting packages to remote TRECV processes. You configure the TWORK EXPAND priority either through the DEFINETR file, explained in Section 5, or with the PARAM EXPANDPRIORITY. The value of this PARAM is passed to the setmode procedure, which is EXPAND line priority.
Managing a TRANSFER System System Monitoring System Monitoring Various Tandem software products help you monitor the TRANSFER delivery system. Tasks are routinely performed by various individuals at each node in the network. A system administrator monitors sessions currently in progress through the ADMIN application. A system operator takes TMF online dumps of the TRANSFER database files. A system manager monitors the overall activity within the TRANSFER environment.
Managing a TRANSFER System System Monitoring TMF Environment TMFCOM, the command interface to the Transaction Monitoring Facility (TMF), allows you to monitor and control TMF, to perform online dumps of the TRANSFER database files, and to recover the database files after a system failure. As a system manager, you establish the initial TMF configuration. TMFCOM can then be used to display the status of operations within TMF and to perform other transaction control operations.
Managing a TRANSFER System System Recovery and Maintenance System Recovery and Recovery of your TRANSFER system after a catastrophic failure is a two-phase Maintenance operation. The TMF autorollback or rollforward procedures must be performed to return the audited files in the TRANSFER database to a consistent state. The files used by the TRANSFER scheduler must then be regenerated; the TSRBLD utility is provided with TRANSFER to perform this operation.
Managing a TRANSFER System System Recovery and Maintenance The commands to execute XIINIT are as follows: :ASSIGN TEXTSRV, $text-server :PARAM NAMESPACE $name-server.correspondent-directory :RUN $volume.subvol.XIINIT $text-server is the process name of the Text server. If you accepted the default names when you initialized TRANSFER, this parameter is $ZTXT. name-server.correspondent-directory is the Name server process name and the correspondent directory name.
Managing a TRANSFER System TSRBLD Utility TSRBLD Utility The Ready, Time, and Net files are used by the TRANSFER scheduler in the process of delivering packages. These files are not TMF audited files; the entries in these files must be regenerated after a failure that requires TMF recovery. The TSRBLD utility, which is run after the TMF rollforward or autorollback process has been completed, rebuilds the three scheduler files.
Managing a TRANSFER System TSRBLD Utility The commands for running TSRBLD are as follows: :ASSIGN TEXTSRV, $text-server :PARAM REBUILDWANTED TRUE :PARAM NAMESPACE $name-server.correspondent-directory :RUN $volume.subvol.TSRBLD / out $location-name / $text-server is the process name of the Text server. If you accepted the default names when you initialized TRANSFER, this parameter is $ZTXT. $name-server.correspondent-directory is the Name server process name and the correspondent directory name.
Managing a TRANSFER System TCHECK Utility TCHECK Utility Running TCHECK regularly ensures that inconsistencies in the Base TRANSFER data files at any given time are minimized. You must stop all TRANSFER servers except the Text server and the Name server in order to run TCHECK. The TCHECK utility locates and adjusts discrepancies in the Base TRANSFER data files.
Managing a TRANSFER System TCHECK Divisions TCHECK Divisions TCHECK treats the TRANSFER database as having seven logical sections. It allows the user to specify which section or combination of sections are to be checked during program execution. The TCHECK directives that describe these database sections can be supplied as PARAM messages or as RUN command parameters. Table 11-2 summarizes these directives. Table 11-2.
Managing a TRANSFER System TCHECK Divisions TMANAGER also uses this six-digit format for item IDs. If you do not enter an item ID, TCHECK checks the first item in the file. If you do not enter an item count, TCHECK processes to the end of the item data file. Note If you enter the BREAK key at the confirmation prompt, TCHECK interprets BREAK as a negative response. TCHECK aborts the TMF transaction and all updates are backed out.
Managing a TRANSFER System TCHECK and SPREP TCHECK and SPREP The TCHECK directives affect the SPREP program in the following ways: If any one of the following directives is TRUE, both depot and item statistics are recalculated the next time SPREP is run (usually at the next XCOOL): CHECKALL CHECKEXTOBJS CHECKITEMS If any one of the following directives is TRUE, only depot statistics are recalculated the next time SPREP is run (usually at the next XCOOL): CHECKDEPOTS CHECKDISTLISTS CHECKFOLDERS CHECKGROUPS
Managing a TRANSFER System TCHECK Commands TCHECK Commands The following are the commands for running TCHECK: :ASSIGN TEXTSRV, $text-server [ :PARAM directives ] :RUN $volume.subvol.TCHECK [ /run-options/ ]& [ directives ] $text-server is the process name of the Text server. If you accepted the default names when you initialized TRANSFER, this parameter is $ZTXT. $volume.subvol is the volume and subvolume on which TCHECK resides.
Managing a TRANSFER System TCHECK Commands AUTOFIXERRORS [ TRUE ] [ FALSE ] says whether TCHECK requires operator confirmation before correcting errors encountered. The default is TRUE. If AUTOFIXERRORS is set FALSE, the operator is asked to confirm file changes at the end of the run. At least one action must be specified as follows: CHECKALL or CLEANSESSIONSONLY or one or more of the other CHECK directives. CHECKALL [ TRUE ] [ FALSE ] directs TCHECK to examine every data file.
Managing a TRANSFER System TCHECK Commands CHECKFOLDERS [ TRUE ] [ FALSE ] directs TCHECK to examine the files that hold folder and inverted folder information and folder contents pointers. It does not check the items referenced by the folder pointers. The default is FALSE. CHECKITEMS [ TRUE ] [ FALSE ] [ item-count ] directs TCHECK to examine the file that holds the items referenced by the folder file.
Managing a TRANSFER System TCHECK Examples TCHECK Examples The following examples show how you can use TCHECK to check your Base TRANSFER data files: CLEANSESSIONSONLY RUN TCHECK CLEANSESSIONSONLY TRUE This run deletes all sessions and the contents of session-related folders, like the WASTEBASKET. It automatically corrects any errors that it encounters without recourse to the operator. This is the least time-consuming TCHECK option to run.
Managing a TRANSFER System System Administration—Agent Considerations System Administrative functions are generally performed through the ADMIN application, Administration which is described in Volume 1 of the TRANSFER Administration Guide, the Reference Manual. Section 9 of this manual, “Using ADMIN to Administer TRANSFER,” explains using ADMIN for system control and depot statistics.
Managing a TRANSFER System User-Supplied Modules A default agent configuration, the vacation agent configuration, and the print-ondelivery agent configuration are provided with TRANSFER and are accessible from ADMIN. You can provide an agent configuration for additional agents; in some instances, you might also be required to provide a module for deleting your agent configuration and the agent.
Managing a TRANSFER System User-Supplied Modules User-Supplied Profile Module The user-supplied profile module provides the means to include another profile in a depot. This profile contains information that is specific to TRANSFER applications implemented at your node. The user-supplied profile module, which displays one or more screens, is called by the ADMIN application when you press F10 from the MAIN MENU screen. This SCREEN COBOL module must be named ADMIN-PROFILEUSER.
Managing a TRANSFER System Configuring an Agent That Is a SCREEN COBOL Requester Configuring User-Written Agents A user-written agent can be a SCREEN COBOL requester or a PATHWAY server written in another programming language. The following paragraphs describe how to configure both kinds of agents. Configuring an Agent That Is a SCREEN COBOL Requester The following paragraphs describe steps for configuring a SCREEN COBOL agent.
Managing a TRANSFER System Configuring an Agent That Is a SCREEN COBOL Requester If you want your agent to accept a restricted range of application types, specify the range of application IDs in the next two fields. Again, IDs 100 through 999 are reserved for Tandem software. If your agent needs any special data, type this information for ENTER ANY DATA NEEDED BY THE AGENT ON THE FOLLOWING LINE.
Managing a TRANSFER System Configuring an Agent That Is a PATHWAY Server Configuring an Agent That Is a PATHWAY Server Many users write agents in languages other than SCREEN COBOL to take advantage of different functionalities available in other programming languages. These agents are PATHWAY servers and are installed as follows. 1. Add SET SERVER and ADD SERVER commands to your CUSTCNFG file on the configuration subvolume before running XCNFG to put all your system components together.
12 Troubleshooting Overview If you have a problem with the TRANSFER delivery system, you can take several steps to determine what is wrong. This section on troubleshooting suggests what to do when mail is not delivered or performance is poor. It describes how to use the log files to pinpoint the difficulty. It also tells you how to isolate your node from the network if you need to. What to Do When Mail If mail is not being delivered to your node, you can take certain steps.
Troubleshooting What to Do When Mail Is Not Delivered If you have used TMANAGER to change the server log file, the PARAM LOG location does not reflect the current log file; check TMANAGER instead. 1> pathcom $trpm = info server a-tsched SERVER A-TSCHED . . . OUT \XYZ.$TLOG PARAM LOGRECSPEROPEN "10000" ASSIGN LOG "$S.#LOG.TSCHED" PARAM NAMESPACE "$T.CORR" . . = Common problems include: The A-BASE-TEXT and A-NAME servers are not running. The database files do not have enough space. TMF is not running.
Troubleshooting What to Do When Mail Is Not Delivered The discussion on configuring TMANAGER in Section 10 of this guide tells you how to specify the amount of time a control record can exist in the ROPENCTL file before you get an alarm message warning you of a network problem. As a temporary solution when TWORKs are tied up by a network problem, you can do the following until the problem is fixed: PUP DOWN! the network line handlers.
Troubleshooting What to Do When Mail Is Not Delivered If the item is in a folder, from the TMANAGER MAIN MENU screen press F11 to get the FOLDER SCAN screen. Select the item with the cursor; then press F12 to get the ITEM TRACE screen and trace the item. From the ITEM TRACE screen, press F7 to get the RECIPIENT SELECT screen and then F4 to get the RECIPIENT DISPLAY screen for the first recipient. Check the status of the recipients.
Troubleshooting What to Do About Poor Interactive Performance What to Do About To tune and improve the interactive performance of your TRANSFER delivery Poor Interactive system—with the mail clients, for instance—do the following: Performance Check the status and the number of the TISERVs. Although each TISERV can support more than eight configured users, a TISERV can provide good response time for no more than five or six active users.
Troubleshooting What to Do About Poor Interactive Performance The STATUS TISERV,PROCESSES command gives you even more information, showing which TCPs have links to the servers: =status tiserv,processes SERVER #RUNNING TISERV 6 PROCESS $ZTT0 LINKER TAREQ-TCP3 M6530-TCP1 PROCESS $ZTT1 LINKER M6530-TCP2 TAREQ-TCP1 STATE RUNNING ERROR 3115 INFO 34 ERROR INFO #LINKS 2 WEIGHT 4 INFO 320 #LINKS 2 WEIGHT 6 LINK RANK 001 003 STATE RUNNING ERROR 3115 LINK RANK 001 001 If most of the server links are hi
Troubleshooting What to Do About Poor Interactive Performance In addition, define TISERV servers as STATIC servers so that the load on the servers is evenly distributed. In the DEFINETR file, the value you provide for the parameter TRTiservNumStatic determines the number of static TISERV server processes in the TISERV server class. (You must change the DEFINETR file and rerun the CDTRDEF and other CDxxDEF and XCNFG programs, as described in Section 8, “Redefining a TRANSFER System.
Troubleshooting What to Do About Poor Interactive Performance Check both the server OUT files (which default to the console) and the server logs to see if errors or retries are causing extra work. An error 4990 indicates timeouts and usually suggests a need for tuning or load balancing if the number of 4990 errors is excessive. The error subcode varies depending upon which file is experiencing the I/O timeout. You can ignore process timeouts from TISERV to TSCHED because these are only wakeup messages.
Troubleshooting Partitioning TRANSFER Database Files Partitioning If your TRANSFER system performs poorly because your database files are too large TRANSFER Database or because of heavy demand to access certain database files, some of these files can be Files partitioned. Partitioning should be done only by someone who understands file partitioning. Several of the TRANSFER database files lend themselves to partitioning, while others do not.
Troubleshooting Partitioning the Session File Two Secondary Partitions You can use a shortcut if you need only two secondary partitions. The first 12 bytes of the key can be used to partition the file. You need supply only your node number. The numbers of the key are as follows: [ 192, 0, 168, 235, 0, xx, 84, 32, 32, 32, 0, 1 ] [ 192, 0, 168, 235, 0, xx, 84, 32, 32, 32, 0, 2 ] with xx being your node number. The second partition needs to be approximately twice the size of the other partitions.
Troubleshooting Partitioning the Session File More Than Two Secondary Partitions To provide balanced partitioning for more than two secondary partitions on the Session file, you use a 14-byte partition key. To figure the values of the partition keys, use the FUP INFO STAT command on an existing Session file to determine the number of records in the file. Then divide the number of records in the file by the number of desired partitions.
Troubleshooting Partitioning the Session File Example of a File with 15 Secondary Partitions Here is an example of partitioning that gives you 15 secondary partitions. \MAILMN.$TMF5.TMAILDBA.
Troubleshooting Format for Log Entries Understanding and The TRANSFER asynchronous processes generate logs that help you solve problems Using the Log Files with your delivery system. You can control the logging of these processes from the TMANAGER DYNAMIC LOG CONTROL screen, which is discussed in Section 10 of this guide. The Format for Log Entries The following example shows the format for log entries: \NODEA.$TSCH 89-02-27 11:22:37 [1]: information The entry tells you the following: \NODEA.
Troubleshooting Format for Log Entries Many log entries refer to a specific item by item ID, in the format: n, n, n, n, n, n where n is an integer in the range -32768 to 32767. The integers are separated by a comma and one space.
Troubleshooting TSCHED Log The TSCHED Log The TSCHED log contains not only actual TSCHED entries, but also entries for TFRONT and TAREQ, which cannot issue requests on their own because they are written in SCREEN COBOL. TSCHED Entries Entries that actually log TSCHED processing report the opens and closes of TSCHED. In addition, the log reports errors associated with these opens and closes. TFRONT Entries Entries for TFRONT log the banner message and report PATHWAY SEND failures.
Troubleshooting TSCHED Log Figure 12-1 shows an example of a TSCHED/TAREQ log. Figure 12-1. TSCHED/TAREQ Log \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.$TSCH \MONTAN.
Troubleshooting TWORK Log The TWORK Log The TWORK log tracks the work that a TWORK server does, including: The type of work: Recipient resolution Package expiration (local only) Package transport to remote nodes Package cancellation (both local and remote) Item unsave from folders Item deletion External object deletion Ending of sessions Generation of notifications—certification, receipt, nonreceipt Timed submission processing Repeated submission processing The object worked on, usually an item ID The beg
Troubleshooting TWORK Log Figure 12-2 shows an example of a TWORK log. Figure 12-2. TWORK Log \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.$ZTWO \MONTAN.
Troubleshooting TRECV Log The TRECV Log The TRECV log contains information about the status of items that are imported from other nodes. The log entries are grouped according to the part of an item being transported, including: Item descriptors Item data Recipients Components External objects Package submissions Package cancellations The groups are bracketed by TMF transactions.
Troubleshooting TRECV Log Figure 12-3 shows an example of a TRECV log. Figure 12-3. TRECV Log \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.$ZTRO \MONTAN.
Troubleshooting Using the Logs for Troubleshooting Using the Logs for Troubleshooting You most commonly use the asynchronous logs for solving problems in two ways: To determine what happened at a particular time Search the logs for the date and time. Limit your first search to the hour and minute. If you specify the second, you might not find an entry. If you specify only the hour, you might get a large area to go through; on a busy system, an hour can span many spooler pages of a log.
Troubleshooting Using the Logs for Troubleshooting If you need only a quick check of the status of events, you can assign a log to a paused terminal and watch it. As long as everything is running properly, the log can be disabled. If, however, problems arise, assign the log to a spooler location to provide more time for checking it. Although logs do fill quickly, you can lose valuable troubleshooting information if you leave logs off.
Troubleshooting X400 Exporter Log Using the X400 Gateway Logs The X400 Exporter Log If you have the TRANSFER X400 gateway installed on your system, you can use two additional logs to solve problems with your delivery system: the X400 exporter log and the X400 importer log.
Troubleshooting X400 Exporter Log Per-message indicators Deferred delivery date and time Trace information P1 routing recipients Status of export: successful or error code for failure Figure 12-4 shows an example of an exporter log.
Troubleshooting X400 Exporter Log Figure 12-4.
Troubleshooting X400 Importer Log The X400 Importer Log The X400 gateway importer translates X.400 P1 and P2 messages into TRANSFER items.
Troubleshooting X400 Importer Log Sensitivity Autoforwarded flag Processing the body parts of a P2: Text body parts Message body parts Encrypted body parts Creating items for these body parts and attaching them as component items Or, in the case of a Report Package or an IPN (Inter-Personal Notification), tracing the importer’s progress as it creates a STATUS package and fills in the appropriate fields Giving the final status of import : Success Requeue for retry Reject message (sends to the exporter to bu
Troubleshooting X400 Importer Log Importer logs contain three different formats of the PDU ID. Some OSI/MHS tools use a format divided into five fields, for instance: 0, 0, 41635, 1, 1021. The importer includes this form on every line during the processing of an X400 message. PDU ID is stored as a four-word integer. Some OSI/MHS tools use the decimal form of this four-word integer: 671289347240258. The importer includes this number on one line of output for each X400 message processed.
Troubleshooting X400 Importer Log Figure 12-5 shows an example of an importer log. Figure 12-5.
Troubleshooting Using the X400 Logs for Troubleshooting Using the X400 Logs for Troubleshooting In addition to the general suggestions for using logs given earlier in this section, you can use the X400 logs for troubleshooting your TRANSFER X400 gateway. Tracking a problem with either the exporter or the importer log is easiest if there was only one process in the server class running.
Troubleshooting Isolating a Node from the Network Isolating a Node from If you have a problem with TRECV or the network, you can isolate your node from the the Network network by taking the following steps. Do this if you have a backlog of local events in the READY queue that you want processed before you can solve the problem. 1. Stop the TFRONTs and the TRECVs to prevent packages from being received from other nodes. This does not affect the processing of locally generated events. 2.
Appendix A Define File Descriptions Define Files The define file descriptions consist of commented listings of the default files. The parameters are described in the order in which they appear in the files. Optional parameters not included in the default file are described at the end of each file listing. There are two types of parameters—reconfigurable and initialization. Reconfigurable parameters are parameters that you can change by redefining the TRANSFER component and reconfiguring the system.
Define Files TRDEFLTS File—Base TRANSFER TRDEFLTS File Here is a copy of the define file for Base TRANSFER, TRDEFLTS. (Base TRANSFER) ------------------ TRDEFLTS File This file contains the default values for the TRDEFLTS File This file contains the default values for the keyword parameters used to define Base TRANSFER. Before you install Base TRANSFER, copy this file to the Configuration subvolume creating the DEFINETR file. The keyword parameters are either initialization or reconfigurable parameters.
Define Files TRDEFLTS File—Base TRANSFER ?LET PathmonName ?LET TschedName ?LET NameServName = $TRPM; = $TSCH; = $T; -- Data_Subvol is the subvolume name where the TRANSFER Database files -- should be placed (or where they currently exist for REDEFINEs). ?LET Data_Subvol = [Initials]MDB; -- Data_Vol is the volume name where the TRANSFER Database files -- should be placed (or where they currently exist for REDEFINEs).
Define Files TRDEFLTS File—Base TRANSFER -------------- RECONFIGURABLE PARAMETERS -------------TRUserDSV $vol.subvol -- Specifies the user-DSV for Base TRANSFER. You -- must specify both volume and subvolume names. -- Required, reconfigurable parameter. --**************************************************** -- Delete the following cpu specification on a 1-cpu system. TRPathmonCpu [CPUA] -- Specifies the primary and backup CPU for the -- PATHMON process.
Define Files TRDEFLTS File—Base TRANSFER -- Specifies the security attribute for users who -- can issue PATHCOM commands for the TRANSFER system -- (generates the SET PATHWAY SECURITY command). The -- default value U sets local and remote access for -- the owner. You can change this value to any valid -- PATHWAY security attribute. -- Required, reconfigurable parameter. TRPwayMaxTcps 20 -- Specifies the maximum number of TCP descriptions -- for the PATHWAY system (generates SET PATHWAY -- MAXTCPS command).
Define Files TRDEFLTS File—Base TRANSFER -- the default value to any value from 20 to 4095. -- Required, reconfigurable parameter. TRPwayMaxParams 100 -- Specifies the maximum number of PARAM -- specifications for all server classes (generates -- SET PATHWAY MAXPARAMS command). You can change -- the default value to any value from 20 to 4095. -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER -- default value to any value from 0 to 4095. -- Required, reconfigurable parameter. TRMinPriority 128 -- Specifies the minimum priority for all TCPs and -- servers in the TRANSFER system. You can change the -- default value to another valid process priority. -- The value you specify must be at least 10 less than -- TRMaxPriority (below). -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER -- $vol must be a valid name specification that -- generates unique volume names within your system. -- The volume names must be 6 or fewer characters long -- to ensure network access. TRExtobjsFileSecurity NUUU -- Specifies the file security for external objects -- which are owned by the TRANSFER guardian user id. -- You can change the default value to any -- valid GUARDIAN 90 file security with the exception -- that READ and WRITE securities cannot be SUPER.SUPER.
Define Files TRDEFLTS File—Base TRANSFER -- **** Define TRANSFER ADMIN/TMANAGER TCP (TRAN-TCP) **** TRTranTcps 1 -- Specifies the number of ADMIN/TMANAGER TCPs. -- While multiple TCPs can be configured, there -- is no need to ever have more than one such TCP. -- Required, reconfigurable parameter. TRTranTcpNames $[Initials]RA:B -- specifies the name for the ADMIN/TMANAGER TCP. -- You can change the default value to any valid -- PATHWAY process name range. -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER TRTareqTcps 1 -- Specifies the number of TAREQ-TCPs for the TRANSFER -- PATHWAY system. You can change the default value -- to any value from 1 to 99. This value determines -- the minimum number of process names that you must -- define for TAREQ-TCP processes. -- Required, reconfigurable parameter. TRTareqTcpNames0 $[Initials]AA:Z -- Specifies the process names for TAREQ-TCP -- processes.
Define Files TRDEFLTS File—Base TRANSFER -- Required, reconfigurable parameter. --**************************************************** --**** Define TRANSFER Asynchronous Requesters (TAREQ) pseudo-terminals TRTareqTerms 2 -- Specifies the number of TAREQ pseudo-terminals -- and the minimum number of TWORK and TISERV-ASYNC -- servers. You can change the default value to a -- value from 1 to 99. -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER -- You can change the default value to any value from -- 0 to 99. The value 0 disables delivery from other -- nodes. If you specify 0, you must also specify 0 -- for TRTrecvServs (later in the file). -- Required, reconfigurable parameter. -- TRX4GatewayNode \node -- The parameter TRX4GatewayNode specifies the node -- where packages addressed to foreign X400 recipients -- should be forwarded. -- Optional, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER -- TRTschedRestPriValue 0 -- Specify the priority restriction window and value. -- "Begin" is the hour when the window opens; "End" -- is the hour when the window closes. 0 means no -- restrictions, 24 means midnight. Valid values -- for "Value" are 0 to 9999.
Define Files TRDEFLTS File—Base TRANSFER -- **** Configure the System Management Server (SMServ) **** -- SMServ is a single process server class; only the Name, CPU -- Out file and optionally Debuglog parameters are accepted. TRSMServName $[Initials]SM -- Specifies the process name for the System Management -- server. You can change the default value to any valid -- PATHWAY process name.
Define Files TRDEFLTS File—Base TRANSFER TRStatsPrepOut [Server_Out] -- Specifies the OUT file for the Stats Prep (SPREP) -- process. You can change the default value to a -- device, process, or disk file. -- Required, reconfigurable parameter. TRStatsPrepLog [Server_Out] -- Specifies the LOG file for the Stats Prep (SPREP) -- process. You can change the default value to a -- device, process, or disk file. -- Optional, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER -- Specifies the log file for the Sampler server. You can -- change the default value to another process, a device, -- or disk file. If the disk file does not exist, TSAMPLE -- creates it. TRTSampleServDebugLog $S.#TSAMPLE.DEBUGLOG -- Specifies the debug log file for the TSAMPLE servers. -- You can change the default file to a device, process, -- or disk file. If the disk file does not exist, TSAMPLE -- creates it.
Define Files TRDEFLTS File—Base TRANSFER --**************************************************** -- Delete the following two cpu specifications on a 1-cpu system: TRTrecvServCpu0 [CPUJ] -- Specifies a primary and backup CPU pair for TRECV -- processes. Specify at least one CPU pair. You can -- insert additional parameters if you want to specify -- more CPU pairs. The parameter format is: -- TRTrecvServCpuN (P:Q) -- where N can be any number from 0 to 9; -- increment N by 1 for every parameter you insert.
Define Files TRDEFLTS File—Base TRANSFER -- for TRECV servers. TRTworkServs 4 -- Specifies the maximum servers for the TWORK server -- class. You can change the default value to a value -- from 1 to 99; however, the number must be greater than -- or equal to the number of TAREQ pseudo-terminals -- (TRTareqTerms + TRCleanupTareqTerms parameters). -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER --**************************************************** -- Delete the following two cpu specifications on a 1-cpu system: TRAsyncTiservCpu0 [CPUD] TRAsyncTiservCpu1 [CPUJ] --**************************************************** TRAsyncTiServOut TRAsyncTiServDebuglog [Server_Out] $S.#TISERVA.DEBUGLOG -- **** Define FORMAT Server Class **** TRFormatServs 2 -- Specifies the maximum number of server processes for -- the FORMAT server class.
Define Files TRDEFLTS File—Base TRANSFER --**************************************************** -- Delete the following two cpu specifications on a 1-cpu system: TRFormatServCpu0 [CPUE] -- Specifies a primary and backup CPU pair for FORMAT -- server processes. Specify at least one CPU pair. You -- can insert additional parameters if you want to -- specify more CPU pairs.
Define Files TRDEFLTS File—Base TRANSFER -- PS MAIL 6530, PS MAIL 3270, or FAXLINK -- cannot run in your TRANSFER system. -- Required, reconfigurable parameter. TRGFileServNumstatic TRGFileServNames0 1 $[Initials]G0:9 --**************************************************** -- Delete the following two cpu specifications on a 1-cpu system: TRGFileServCpu0 [CPUG] TRGFileServCpu1 [CPUH] --**************************************************** TRGFileServOut TRGFileServDebuglog [Server_Out] $S.#GFILE.
Define Files TRDEFLTS File—Base TRANSFER TRProcessServOut TRProcessServDebuglog [Server_Out] $S.#PROCESS.DEBUGLOG -- **** Define TRANSFER Interactive Server (TISERV server class) **** -- For parameters without notation, see the corresponding -- description for the FORMAT server class. TRTiservs 2 -- Specifies the maximum number of server processes for -- the TISERV server class. You can change the default -- value to any value from 1 to 99. -- Required, reconfigurable parameter.
Define Files TRDEFLTS File—Base TRANSFER TRTschedServName [TschedName] -- Specifies the process name for the TRANSFER scheduler -- at your node. You can change the default value to any -- valid PATHWAY process name. TRTextServName $[Initials]XT -- Specifies the Text server process name. You can -- change the default value to any valid PATHWAY process -- name. TRNameServName [NameServName] -- Specifies the Name server process name.
Define Files TRDEFLTS File—Base TRANSFER -- depot is not specified for a new group. You can change -- the default name to a valid simple TRANSFER name. TRSysAdminCorr SYS-ADMIN -- Specifies the correspondent for the system -- administrator depot created by the initialization -- procedure. This system administrator has both read -- and write privileges. You can change the default name -- to any valid simple TRANSFER name. TRInitOut $S.#TRAN.
Define Files TRDEFLTS File—Base TRANSFER -- time period for each depot storage statistics sample. -- (Ignored if TRStatsNumStats = 1.) -- This optional, initialization parameter must be present -- if TRStatsCollectStats is YES. TRStatsNumStats 7 -- This integer represents the number of storage statistics -- samples to be recorded for each depot. -- This optional, initialization parameter must be present -- if TRStatsCollectStats is YES.
Define Files TRDEFLTS File—Base TRANSFER TRDataFileSecurity OOOO -- Specifies the file security for all Base TRANSFER -- data files. You can change the default value to any -- valid GUARDIAN 90 file security with the exception -- that READ and WRITE securities cannot be SUPER.SUPER. TRProfileFile [Data_Vol].[Data_Subvol].PROFILE -- Specifies the file name for the Profile file. Enter -- the volume and subvolume names. You can change the -- default file name. TRSessionFile [Data_Vol].[Data_Subvol].
Define Files TRDEFLTS File—Base TRANSFER -- for the Interest Group file. Enter the volume and -- subvolume names. You can change the default file name. TRIattachFile [Data_Vol].[Data_Subvol].IATTACH -- Specifies the file name for the Inverted Attachment -- file. Enter the volume and subvolume names. You can -- change the default file name. -- This file must be specified, even if the external -- objects capability will not be enabled. TRExtobjsFile [Data_Vol].[Data_Subvol].
Define Files TRDEFLTS File—Base TRANSFER -- Specifies the file name for the Depot Statistics -- file. Enter the volume and subvolume names. You can -- change the default file name. TRX400NameFile [Data_Vol].[Data_Subvol].X400NAME -- Specifies the file name for the X400Name file. -- Enter the volume and subvolume names. You can change -- the default file name.
Define Files TRDEFLTS File—Base TRANSFER -- The code page ID is always 65300. The system's default -- code set ID can be 65301 through 65327, or 65330; the -- default is 65301 (Tandem US ASCII).
Define Files TRDEFLTS File—Base TRANSFER -9 Swedish -10 Finnish -11 Danish -12 Norwegian -13 Swiss French -14 Swiss German -- For the code page ID and the code set ID, see the -- description for the previous parameter.
Define Files MLDEFLTS File—PS MAIL 6530 MLDEFLTS File Here is a copy of the define file for PS MAIL 6530, MLDEFLTS. (PS MAIL 6530) ------------- MLDEFLTS File This file contains the default values for the keyword parameters used to define PS MAIL 6530. Before you install PS MAIL 6530, copy this file to the Configuration subvolume creating the DEFINEML file. You can alter all parameters by changing the parameter values in the DEFINEML file and running CDMLDef for REDEFINITION.
Define Files MLDEFLTS File—PS MAIL 6530 MLMailTcpNames0 $ZCMA:Z -- Specifies the process names for M6530-TCPs. You can -- insert in the file additional parameters if you need -- more process names generated. -- The parameter format is: --MLMailTcpNamesN $ZCMA:Z -- where --- N can be any number from 0 to 9; increment -- N by 1 for every parameter you insert. --- $ZCMA:Z must be a valid name specification -- that generates unique process names within -- your system. (See Process Name Generation.
Define Files MLDEFLTS File—PS MAIL 6530 -- See the preceding parameter for a description. -- Optional, reconfigurable parameter. -- **************************************************** MLTextServName $ZCTA -- Specifies the Text server process name. You can -- change the default value to any valid PATHWAY -- process name. -- **************************************************** -- Delete the following cpu specification on a 1-cpu -- system.
Define Files MLDEFLTS File—PS MAIL 6530 -- parameter. -- MLMailTcpSwap $vol -- Specifies the PATHCOM command SET TCP SWAP for -- the M6530-TCPs. You can enter only a volume -- name (not an individual file name) because this -- parameter can apply to multiple TCPs. The -- volume must exist. If you do not enter this -- parameter, the default is the volume specified -- for parameter MLUserDSV. Optional, -- reconfigurable parameter.
Define Files IMDEFLTS File—PS MAIL 3270 IMDEFLTS File (PS MAIL 3270 ) Here is a copy of the define file for PS MAIL 3270, IMDEFLTS. ------------- IMDEFLTS File This file contains the default values for the keyword parameters used to define PS MAIL 3270. Before you install PS MAIL 3270, copy this file to the Configuration subvolume creating the DEFINEIM file. You can alter all parameters by changing the parameter values in the DEFINEIM file and running CDIMDEF for REDEFINITION.
Define Files IMDEFLTS File—PS MAIL 3270 IMMailTcpNames0 $ZCIA:Z -- Specifies the process names for M3270-TCPs. You -- can insert in the file additional parameters if -- you need more process names generated. The -- parameter format is: --- IMMailTcpNamesN $ZCIA:Z -- where --- N can be any number from 0 to 9; increment -N by 1 for every parameter you insert. --- $ZCIA:Z must be a valid name specification -that generates unique process names within -your system. (See Process Name Generation.
Define Files IMDEFLTS File—PS MAIL 3270 -- See the preceding parameter for a description. -- Optional, reconfigurable parameter. -- **************************************************** IMTextServName $ZCTB -- Specifies the Text server process name. You can -- change the default value to any valid PATHWAY -- process name. -- **************************************************** -- Delete the following cpu specification on a 1-cpu -- system.
Define Files IMDEFLTS File—PS MAIL 3270 -- IMMailTcpSwap $vol -- Specifies the PATHCOM command SET TCP SWAP for -- the M3270-TCPs. You can enter only a volume -- name (not an individual file name) because this -- parameter can apply to multiple TCPs. The -- volume must exist. If you do not enter this -- parameter, the default is the volume specified -- for parameter IMUserDSV. Optional, -- reconfigurable parameter.
Define Files CMDEFLTS File—PS MAIL TTY CMDEFLTS File Here is a copy of the define file for PS MAIL TTY, CMDEFLTS. (PS MAIL TTY ) ------------- CMDEFLTS File This file contains the default values for the keyword parameters used to define PS MAIL TTY. Before you install PS MAIL TTY, copy this file to the Configuration subvolume creating the DEFINECM file. You can alter all parameters by changing the parameter values in the DEFINECM file and running CDCMDEF for REDEFINITION.
Define Files CMDEFLTS File—PS MAIL TTY -- you can include one additional parameter: --CMAlternateSubVolume2 $altvol2.subvol -- **** -- **** Define TRANSFER Interactive Servers used by PS MAIL TTY .. TTY-TISERV server class CMTiservs 2 -- Specifies the maximum number of server processes -- for the TTY-TISERV server class. All TTY-TISERV -- servers are static. You can change the default -- value to any value from 0 to 99.
Define Files CMDEFLTS File—PS MAIL TTY -- pair. You can insert additional parameters -- if you want to specify more CPU pairs. The -- parameter format is: --CMTiservCpuN (P:Q) -- where --- N can be any number from 0 to 9; increment -- N by 1 for every parameter you insert. --- P and Q are any valid CPUs in your system. --- CDCMDEF assigns processes to CPU pairs in -- ascending numeric order and starts over with CPU -- pairs if processes exceed pairs. Required, -- reconfigurable parameter.
Define Files CMDEFLTS File—PS MAIL TTY -- For parameters without notation see the -- corresponding description for TTY-TISERV server -- class (immediately preceding). CMGFileServs 2 -- Specifies the maximum number of server processes for -- the TTY-G-FILE server class. All TTY-G-FILE -- servers are static. You can change the default -- value to any value from 0 to 99. It is -- recommended that you configure a TTY-G-FILE for -- every eight to ten users.
Define Files CMDEFLTS File—PS MAIL TTY -- included in your PS MAIL TTY Define file DEFINECM. --- CMTiservProgidObject $vol.subvol.TISERV -- Specifies the volume, subvolume, and file to which -- CDCMDEF copies the TISERV object file from -- the Base TRANSFER user-DSV. You must enter both -- the volume and subvolume names. You can change -- the default file name. Reconfigurable -- parameter; required and applicable only if you -- specified YES for CMTiservNewProcess parameter.
Define Files X4DEFLTS File—X400 Gateway X4DEFLTS File (X400 Gateway) Here is a copy of the define file for the X400 gateway, X4DEFLTS. --------------------- X4DEFLTS File This file contains the default values for the Keyword parameters used to define the TRANSFER/X.400 Gateway. Before you install the Gateway, copy this file to the Configuration subvolume creating the DEFINEX4 file. THe keyword parameters are either initialization or reconfigurable parameters.
Define Files X4DEFLTS File—X400 Gateway X4TempFileSubvol subvol <4 character string> -- Specification for Item Retention Time for Import/Export -- folders. Units are days. Minimum is 14 days. X4ExImFolderRetention 14 -- Specifications for the Export Server server class. -- Log related parameters may be modified with TMANAGER.
Define Files X4DEFLTS File—X400 Gateway X4WaitServOut X4WaitServCpu X4WaitServDebuglog $0 (0:1) $S.#X4WM.DEBUGLOG -- Specifications for the Entry Manager server class X4EntryServs X4EntryServNumstatic X4EntryServNames0 X4EntryServCpu0 X4EntryServCpu1 X4EntryServOut X4EntryServDebuglog 1 1 $ZXQ0:9 (0:1) (1:0) $0 $S.#X4EM.
Appendix B Error Messages Several types of messages related to TRANSFER are listed in this appendix. These include messages issued by the TRANSFER definition programs (CDTRDEF, CDMLDEF, CDIMDEF, CDCMDEF, and CDX4DEF); startup messages issued by TRANSFER servers; messages written to output files by certain TRANSFER servers; and messages reported by TCHECK when data-file inconsistencies are detected.
Error Messages Definition Program Messages Error messages are listed in numeric order. Warning messages, which do not have numbers, are listed in alphabetic order following the error messages. 5901 Required configuration subvolume parameter was not entered Cause. The RUN command for the definition program must include the configuration subvolume on which resides the define file for the component being installed. See Appendix A for the parameter description. Effect. Definition program fails. Recovery.
Error Messages Definition Program Messages 5904 "parameter" is invalid; should be INITIAL or REDEFINE Cause. The INITIAL or REDEFINE parameter is specified incorrectly. The parameter indicates whether a component is to be installed for the first time or reconfigured. Effect. Definition program fails. Recovery. Correct the program RUN command and rerun the definition program. 5905 file is required and cannot be opened error Cause. An error occurred when the editor tried to open file for READ access.
Error Messages Definition Program Messages 5910 Invalid parameter for keyword: "subvolume" Cause. The subvolume name specification is invalid. If the specification includes a system, the system must be local. Effect. Definition program fails. Recovery. Correct the parameter value and rerun the definition program. 5911 Initial definition requested but data-file already exists Cause. You specified an initial definition run, but the indicated data file already exists. Effect. Definition program fails.
Error Messages Definition Program Messages 5914 Invalid parameter for keyword: "security" Cause. The file security specified is invalid for the indicated keyword.
Error Messages Definition Program Messages 5917 Invalid TCLPROG for keyword: "name" Cause. Either you did not specify a valid, fully qualified SCREEN COBOL object library name (TCLPROG) for the parameters TRAgentTclProg or TRUserTclprog, or the library does not exist. Effect. Definition program fails. Recovery. Correct the parameter, or ensure that the library exists; then rerun the definition program. 5918 Invalid simple TRANSFER name for keyword: "name" Cause.
Error Messages Definition Program Messages 5923 Invalid parameter for keyword: "process-name" Cause. The value specified for the process name is invalid. Specify process names by using one of the following formats: $AXXX specifies a single process name where A can be any letter and X can be any letter or number. The Xs are optional. $AXXx:y specifies a range of process names where A and X are defined as above but where x and y indicate a name range.
Error Messages Definition Program Messages 5926 static-servers > max-servers Cause. You specified a number of static servers greater than the maximum number of servers you specified within the server class. static-servers has the suffix Numstatic; max-servers has the suffix Servs. Effect. Definition program fails. Recovery. You must either increase the quantity of servers specified or decrease the number of static servers; then rerun the definition program.
Error Messages Definition Program Messages 5929 Invalid parameter for TRGUARDIANUserId: "user-ID" Cause. The GUARDIAN 90 user ID is invalid; the format is: group-id,user-id where group-id and user-id are integers from 0 through 255. Blanks are not allowed. Effect. Definition program fails. Recovery. Correct the parameter value and rerun the definition program. 5930 TRMaxPriority < TRMinPriority Cause. The maximum priority specified in the define file for Base TRANSFER is less than the minimum priority.
Error Messages Definition Program Messages 5933 max-servers < number-of-terminals Cause. The number of servers specified with max-servers is less than the number of terminals specified with number-of-terminals. The number of servers must always be greater than the number of terminals. Effect. Definition program fails. Recovery. Either decrease the number of servers or increase the number of terminals. Then rerun the definition program. 5934 Invalid parameter for keyword: "parameter" Cause.
Error Messages Definition Program Messages 5936 No server defined: keyword-1 is 0 and keyword-2 is "NO" Cause.
Error Messages Definition Program Messages 5942 Invalid parameter for keyword ‘value’ Cause. The value you specified for either TRSystemCharMapId or TRSystemLangCmapId was invalid. Effect. Definition program fails. Recovery. Correct the parameter value and rerun the definition program. 5945 keyword 1 is ‘value’, but keyword 2 not entered Cause. CDTRDEF decides whether keyword 2 is required or optional, based on the value of keyword 1.
Error Messages Definition Program Messages 5951 Unable to move old installation files to subvolume Cause. The definition program was unable to move an existing file to a new subvolume. Effect. Definition program fails. Recovery. Check the user ID that owns the old installation files listed on the configuration subvolume. For the move to occur, these files must belong to user ID specified in TRGUARDIANUserid. Then rerun the definition program. 5952 Unable to create installation files on subvolume Cause.
Error Messages Definition Program Messages 5998: keyword has already been set Cause. You entered a parameter in your define file more than once. Effect. Definition program fails. Recovery. Delete all but one occurrence of the parameters, and rerun the definition program. 5999 INTERNAL ERROR (description) Cause. An internal error has occurred in a definition program. Effect. Definition program fails. Recovery.
Error Messages Definition Program Messages Warning Messages WARNING: server keyword is 0; PS MAIL will always newprocess this Cause. keyword can be either CMTiservs or CMGFileServs. You specified 0 for the number of servers to be configured within the PATHWAY environment; PS MAIL always starts a new server, outside PATHWAY, for its exclusive use. Effect.. This is a warning message. Recovery.
Error Messages Definition Program Messages WARNING: file-list The following files have been created: Cause. A fatal error occurred while EDIT was processing the files generated by the definition program. The files in the list were created before the fatal error occurred; these files are incomplete, however, and you should not try to use them to install the component. Effect. This is a warning message. Recovery. Purge any files that were created, rectify the problem, and run the definition program again.
Error Messages Definition Program Messages WARNING: server keyword is 0; some Tandem clients require this Cause. The keyword indicates a server that a client requires to run. Effect. This is a warning message. Recovery. Mail clients PS MAIL 6530 and PS MAIL 3270 require at least one server of the indicated type. ADMIN requires at least one help server.
Error Messages Common Server Startup Messages Server Startup If a TRANSFER server has a problem when it starts up, it issues an message. The Messages following subsection lists, in alphabetic order, startup error messages that are common to many servers. In addition, various servers issue particular error messages when they have individual problems. These specific startup error messages are listed in alphabetic order, by server, following the list of shared messages.
Error Messages Common Server Startup Messages Error XXXX opening TFile XXXXXXXX. Cause. The indicated GUARDIAN 90 error occurred. Effect. The server abends. Recovery. Refer to the GUARDIAN 90 error number displayed. External objects enabled without assigned subvolume. Cause. You have enabled an external object without assigning a subvolume. Effect. External objects cannot be used. Recovery. Correct the TRANSFER configuration. External objects enabled without assigned volumes. Cause.
Error Messages Common Server Startup Messages Invalid NAMESPACE Parameter - XXXXXXXXXXXXXX. Cause. Your NAMESPACE parameter is incorrect. Effect. The server abends. Recovery. Correct the TRANSFER configuration. Invalid value for configuration name XXXXX. Cause. External objects are not configured Y (yes) or N (no). Effect. External objects cannot be used. Recovery. Correct the TRANSFER configuration. Unable to perform upshift due to internal error. Cause.
Error Messages GFSERV Startup Messages GFSERV Startup Messages The GFSERV server can issue the following message if it encounters a problem on startup: IOEdit unable to unable to obtain I/O segment space Cause. IOEdit could not get adequate I/O segment space. Effect. The server abends. Recovery. You probably need to provide more memory for your system.
Error Messages SMSERV Startup Messages SMSERV could not open the GTRSTOP file Cause. The GTRSTOP file is missing from the TRANSFER configuration subvolume. Effect. The server abends. Recovery. Ensure that the GTRSTOP file is in the TRANSFER configuration subvolume. SMSERV could not open the Item Descriptor Cause. The Item Descriptor file is incorrectly secured. Effect. The server abends. Recovery. Ensure that the Item Descriptor file is correctly secured. SMSERV could not open the Itemdata File Cause.
Error Messages SMSERV Startup Messages SMSERV could not open the Session File Cause. The Session file is incorrectly secured. Effect. The server abends. Recovery. Ensure that the Session file is correctly secured. SMSERV could not open TFILE Cause. TMF is not enabled. Effect. The server abends. Recovery. Ensure TMF is up and running. SMSERV unable to initialize blocked files Cause. Either the disk is disabled, or the TRANSFER database is secured incorrectly. Effect. The server abends. Recovery.
Error Messages STBINIT Startup Messages Unable to open TIME File - error: XXXX Cause. The indicated GUARDIAN 90 error occurred. Effect. The server abends. Recovery. Refer to the GUARDIAN 90 error number displayed. STBINIT Startup Messages The STBINIT server can issue the following messages if it encounters problems on startup: Error XXXX,XXXX finding configuration name for X400 subvols. Cause. The indicated GUARDIAN 90 error occurred. Effect. The server abends. Recovery.
Error Messages STRINIT Startup Messages STRINIT Startup Messages The STRINIT server can issue the following message if it encounters a problem on startup: XXXX opening the traffic log file. Cause. The indicated GUARDIAN 90 error occurred. Effect. Traffic log disabled. Recovery. None. STWINIT Startup Messages The STWINIT server can issue the following messages if it encounters problems on startup: Could not open remote open control file continuing. Cause. The remote open control file does not exist.
Error Messages STWINIT Startup Messages NETTIMEOUT PARAM too low, adjusting to 300 seconds. Cause. You get this message if NETTIMEOUT PARAM is less than 300 seconds. Effect. This is only a warning message. Recovery. No action is necessary. Unable to allocate extended data segment, abending. Cause. Memory is inadequate. Effect. The server abends. Recovery. You probably need to provide more memory for your system. Unable to use extended data segment, abending. Cause. Memory is inadequate. Effect.
Error Messages Gateway Startup Messages X400 Gateway Startup Messages C2000 When the definition program is run to create the obey and command files for installing the TRANSFER X400 gateway, the definition program issues a message when it encounters an error. The following error messages can appear for the Exporter and Importer. Error 4035 retrieving NUMTDBSERVERS parameter Cause. The NUMTDBSERVERS parameter was not defined for this server. Effect.
Error Messages Gateway Startup Messages C2006 Couldn’t start a session, error nnnn Cause. The indicated error occurred when this server attempted to start a TRANSEFER session for the Gateway depot _X400_. Effect. The server stops after generating this message. Recovery. Determine why TRANSFER was unable to start the session; make sure that TMF is running. C2007 Couldn’t open console $0 (required by X.400) Cause. This server was unable to open file $0. Effect.
Error Messages Gateway Startup Messages C2011 X.400’s PRMD did not match TRANSFER’s; s1 vs. s2 Cause. The OSI/MHS definition of the TRANSFER gateway did not match the definition defined in the DEFINEX4 file. The string denoted by s1 is what the MHS expects the PRMD be, and the string s2 is what was defined for the TRANSFER gateway. Effect. The server stops after generating this message. Recovery. Correct either definition to match the other.
Error Messages Gateway Startup Messages C2014 Error nnnn when trying to get X.400 MTA process name from queue Cause. The Exporter server had the indicated error when looking for a queue entry that the MTA will create. Effect. The server pauses and then tries again. No useful processing can occur until it is successful at retrieving the queue entry. Recovery. Determine why the Exporter server encountered the error.
Error Messages Gateway Startup Messages C2017 sgDisconnect failed with error ptserrorcodes Cause. The close of the MTA process failed for the reason indicated by the error code. The value part of the ptserrorcodes field can have the following values: 1 2 3 4 5 6 7 8 9 MTA busy no transaction invalid file number process unavailable invalid PDUID send failed close failed bad password no gateway Effect. This problem is ignored. Recovery. No action is required.
Error Messages Gateway Startup Messages C2021 Couldn’t open Queue Wait Manager proc, error nnnn Cause. The server got error nnnn when trying to open a server in the process name range proc. Effect. The server pauses and then tries again. No useful processing can occur until it is successful at opening a Queue Wait Manager server process. Recovery. Make sure that the Queue Wait Manage server(s) is running, and that the process names are correct.
Error Messages Gateway Startup Messages C2026 Open on semaphore file gave error nnn, continuing Cause. The server had the indicated error when opening a semaphore file. Effect. The server continues, but it cannot use a semaphore file. This file is used to prevent timing conflicts between multiple Exporter processes or between multiple Importer processes. Recovery. Correct the problem indicated by the error number. C2027 PDU store rejected because it is nn%% full Cause.
Error Messages Gateway Startup Messages C2033 Error nnn on write to X400-EMSERV Cause. The server got error nnnn when doing a WRITEREAD to the Queue Entry Manager server. Effect. The server retries the WRITEREAD and continues. Recovery. Determine why the server got error nnnn and correct the problem. C2034 Error nnn on write to X400-WMSERV Cause. The server got error nnnn when doing a WRITEREAD to the Queue WAIT Manager server. Effect. The server retries the WRITEREAD and continues. Recovery.
Error Messages Gateway Startup Messages C2039 Error was: errortext Cause. If error C2021 is reporting a C runtime error, this message indicates the text for that error. See description of error C2021. Effect. See description of error C2021. Recovery. See description of error C2021. C2040 Error was: errortext Cause. If error C2022 is reporting a C runtime error, this message indicates the text for that error. See description of error C2022. Effect. See description of error C2022. Recovery.
Error Messages Gateway Startup Messages C2045 Error was: errortext Cause. If error C2034 is reporting a C runtime error, this message indicates the text for that error. See description of error C2034. Effect. See description of error C2034. Recovery. See description of error C2034. C2046 Error was: errortext Cause. If error C2035 is reporting a C runtime error, this message indicates the text for that error. See description of error C2035. Effect. See description of error C2035. Recovery.
Error Messages Gateway Startup Messages C2049 Error from PTS interface: ptserrorcodes Cause. The server was trying to reopen an MTA process. The server got the indicated error when trying to initialize access to the PDU store. Effect. The server pauses and then looks again for an MTA queue entry. Recovery. Correct the problem indicated in the values field of the error message. See description of error C2016 for the meaning of this field. C2050 Error from PTS interface: ptserrorcodes Cause.
Error Messages Gateway Startup Messages C2054 Invalid value sss for NUMQUEUEMGRS parameter Cause. The string sss is not a valid number. Effect. The server stops after generating this message. Recovery. Correct the PARAM parameter in the Pathway configuration for the Queue Entry Manager servers. C2055 Error 4035 retrieving NUMQUEUEMGRS parameter Cause. The NUMQUEUEMGRS parameter was not defined for this server. Effect. The server stops after generating this message. Recovery.
Error Messages Gateway Startup Messages C2061 Internal inconsistency Cause. An internal inconsistency was detected while attempting to open an MTA process. Effect. The server stops after generating this message. Recovery. Report this error to the system analyst and restart the server. C2062 Failed to delete unacceptable MTA queue entry Cause. The MTA queue entry was no longer valid, but an attempt to delete it failed. Effect. None; the server continues. Recovery.
Error Messages Gateway Startup Messages C2066 Error nnnn enqueueing MTA’s ADMIN QUEUE entry Cause. The Exporter had error nnnn when trying to put an MTA queue entry back into the queue. Effect. The server continues. If, however, there are multiple Exporter server processes, they might not be load-balanced across the available MTAs because they all see the same MTA queue entry. Recovery. Determine why error nnnn occurred and correct the problem. C2067 Error nnnn getting X400 configuration names Cause.
Error Messages TRANSFER Server Messages TRANSFER Server TRANSFER servers write various types of messages to their output files; these files are Messages defined in the PATHWAY configuration. The server output files can be examined for errors that have occurred and for purposes of tracking the activity of the TRANSFER servers. Any server that detects a problem with a file writes an error message to the output file indicating the error and the file name and gives a trace of the P register (calling sequence).
Error Messages TSCHED Output File Error Messages TSCHED Output File Error Messages The output file for the TRANSFER scheduler (TSCHED) can include error messages that indicate problems encountered by TSCHED as well as problems encountered by a TRANSFER asynchronous requester (TAREQ pseudo-terminal) or TRANSFER receiver front end (TFRONT pseudo-terminal). The following subsection lists some of the more common TSCHED, TAREQ, and TFRONT error messages that can appear in the TSCHED output file.
Error Messages TSCHED Output File Error Messages Lookup^config TSCHED-PROCESS at xxxx failure nn/nn Cause. Your TSCHED has been unable to find the TSCHED process name for another system at the indicated node. Two different situations can cause this message to appear: 1. Your TSCHED is trying to find a TSCHED at another system in order to have that TSCHED assign a TRECV to one of your TWORKs. The network operation of TWORK is inserted into the Net file for later assignment. 2.
Error Messages TSCHED Output File Error Messages NonStop Failure: Procedure nn, Kind nn, Code %nn Cause. One of the TSCHED NonStop routines has failed unexpectedly. Effect. TSCHED aborts. Recovery. Please report the numbers to your Tandem system analyst or the Online Support Center (formerly the Customer Assistance Center). NonStop return number not 0 through 3 Cause. The CHECKPOINTMANY procedure indicated that a takeover, but 8:15 of the status word did not contain 0, 1, 2, or 3. Effect. TSCHED aborts.
Error Messages TSCHED Output File Error Messages OPENERLIMIT reduced to number because of insufficient LCB space Cause. TSCHED was unable to obtain space for all LCBs required for the number of openers requested. Effect. The opener limit is reduced. Recovery. If the number is considered too large by your system manager, the OPENERLIMIT parameter should be reduced. PARAM xxxx invalid Cause. You gave the indicated PARAM a bad value Effect. TSCHED aborts. Recovery.
Error Messages TSCHED Output File Error Messages Set^name^space fails Cause. An obscure initialization error occurred Effect. TSCHED aborts. Recovery. Ensure that your name server and its files are correct and try again. Spurious nowait IO completion Cause. TSCHED-to-TSCHED input and output is done on a nowait basis. TSCHED has received notification of completion of an input and output operation for which it was not waiting. Effect. TSCHED aborts. Recovery.
Error Messages TSCHED Output File Error Messages TSCHED has not been given the correct process name Cause. Your TRANSFER configuration determines the process name that your TSCHED is to have; this is so that other processes in TRANSFER can find TSCHED. TSCHED verifies that the process name expected by other processes has been given to TSCHED. Effect. TSCHED aborts. Recovery. Restart TSCHED with the correct process name. TSCHED TAKEOVER by CPU nn Cause.
Error Messages TSCHED Output File Error Messages Unable to reservelcbs (nn, nn), proceeding ... Cause. At startup time, TSCHED issues a RESERVELCBS GUARDIAN 90 call using the RESERVESENDLCBS and RESERVERECEIVELCBS PARAM specifications; the default value for both of these parameters is 0. The indicated numbers are the values that TSCHED passed to RESERVELCBS. Effect. TSCHED operates normally. Recovery. This message is for your information only. Unexpected error nnn on file $volume.subvolume.
Error Messages TSCHED Output File Error Messages [nn]:CALL error: nnnn, nnnnn Cause. The TAREQ received an unexpected error return from a CALL statement. The indicated numbers are from the special registers TERMINATION-STATUS and TERMINATION-SUBSTATUS, respectively. Effect. The TAREQ instructs TSCHED to hold the assignment on which the TAREQ was working and asks TSCHED for a new assignment. Recovery. Refer to the CALL statement description in the PATHWAY SCREEN COBOL Reference Manual.
Error Messages TSCHED Output File Error Messages [nn]:Could not obtain configured name for: [nn]:xxxxxxxxxxxxxxxxxxxxxxxx [nn]:UOW xxx failure: nnnn/snnnn in xxxx [nn]:*ERROR* will DELAY and retry Cause. The TAREQ encountered an unexpected error while trying to obtain needed information about your configuration via the GET-CONFIG-NAME UOW.
Error Messages TSCHED Output File Error Messages [nn]:*ERROR* Log entry from agent BEGIN [nn]:Depot: xxxxx [nn]:Agent: xxxxx [nn]:Text supplied by agent: xxxxx [nn]:*ERROR* Log entry from agent END Cause. The TAREQ has invoked the indicated agent during a delivery to the indicated depot, and the agent has responded that the TAREQ should log an error for the agent. Effect. The TAREQ then proceeds normally. Recovery. Refer to the agent to understand the error.
Error Messages TSCHED Output File Error Messages [nn]:*ERROR* SCREEN COBOL agent abused transaction id Cause. A SCREEN COBOL agent issued a transaction control statement other than RESTART-TRANSACTION. Effect. If no transaction is still in effect, the TAREQ starts a new one. The TAREQ then proceeds normally. Recovery. The responsible agent can be determined only from the log file. [nn]: *ERROR* TAREQ cannot operate Cause.
Error Messages TSCHED Output File Error Messages [nn]:*ERROR* TMF is not running Cause. The TAREQ received a TERMINATION-STATUS of 3 from the ON ERROR clause of a BEGIN-TRANSACTION statement. Your TMF is not operating at your node. Effect. The TAREQ executes the EXIT program. Recovery. See that TMF is operating at your node. [nn]:HOLDing item snnnnn,snnnnn,snnnnn,snnnnn,snnnnn,snnnnn Cause.
Error Messages TSCHED Output File Error Messages [nn]:RESTART error: nnnn/nnnnn Cause. The TAREQ encountered an unrecoverable problem during package delivery and attempted too many restarts. The indicated numbers are from the special registers TERMINATION-STATUS and TERMINATION-SUBSTATUS, respectively;. Effect. The delivery record was put on hold in the READY file by TSCHED. Recovery. Refer to the CALL statement in the PATHWAY SCREEN COBOL Reference Manual.
Error Messages TSCHED Output File Error Messages n]:UOW xxx failure; snnnn/snnnn in xxxx Cause. The TAREQ has encountered a UOW error for which it has no suitable recovery code. The xxx and xxxx are internal TAREQ mnemonics; the xxxx indicates the TAREQ module; the xxx indicates the particular UOW within the module. Check the TRANSFER Reference Manual to see which UOW is affected. Effect. The TAREQ retries the operation appropriately at least once; excessive retries cause the TAREQ to hold the assignment.
Error Messages TSCHED Output File Error Messages xxxx file is wrong revision level Cause. The indicated TSCHED file (Ready, Time or Net) has a control record whose revision level is incompatible with this version of TSCHED. Your configuration is bad. Effect. TSCHED aborts. Recovery. Correct your configuration.
Error Messages TCHECK Utility Messages TCHECK Utility The TCHECK utility locates and adjusts inconsistencies in the TRANSFER database. Messages When an inconsistency is found, TCHECK corrects the inconsistency and puts out a descriptive message. This section lists TCHECK messages in alphabetic order.
Error Messages TCHECK Utility Messages **** Configured value for EXTOBJS-ENABLED altered to N The EXTOBJS-ENABLED alias contained a value other than Y or N; TCHECK altered the record to N (disabled). **** Configured value for NODE-VERSION added The value for NODE-VERSION was missing from the correspondent directory; TCHECK created the record using the version code of the current system.
Error Messages TCHECK Utility Messages **** Damaged block structure adjusted in recipient file for item ID: snnnn snnnn snnnn snnnn snnnn snnnn The internal TRANSFER block structure for the indicated item in the Recipient file was damaged. TCHECK adjusted the block structure to make the blocks usable; some recipient records might have been deleted. **** External object descriptor deleted An external object descriptor record was found that has no attachments; TCHECK deleted the record.
Error Messages TCHECK Utility Messages **** Extra external object found An external object file was found that has no attachments; purge the file after TCHECK has completed its updates. **** Extra external object list record - parent does not exist An external object list record was found in the item descriptor file for which there is no parent record; TCHECK deleted the record and dissolved all attachments that refer to that record.
Error Messages TCHECK Utility Messages **** Extraneous folder records - item does not exist Records found in the Folder and Inverted Folder files corresponded to a nonexistent item; TCHECK deleted the records. **** nnnn Extraneous IFOLDER records - folder does not exist Records found in the Inverted Folder file did not belong to a folder in the TRANSFER name directory; TCHECK deleted the records.
Error Messages TCHECK Utility Messages **** Extraneous Session folder records Extraneous records corresponding to session-related folders were found in the Folder and Ifolder files; TCHECK deleted the records. **** FOLDER record contains incorrect item-id Folder name: xxxxx.xxxxx Incorrect Item ID: snnnn snnnn snnnn snnnn snnnn snnnn Correct Item ID: snnnn snnnn snnnn snnnn snnnn snnnn The specified record in the Folder file did not have the same item ID as the corresponding record in the Ifolder file.
Error Messages TCHECK Utility Messages **** IFOLDER record contains incorrect item-id Folder name: xxxxx.xxxxx Incorrect Item ID: snnnn snnnn snnnn snnnn snnnn snnnn Correct Item ID: snnnn snnnn snnnn snnnn snnnn snnnn The specified record in the Ifolder file did not have the same item ID as the corresponding record in the Folder file. TCHECK updated the record in the Ifolder file with the correct item ID. **** IFOLDER record missing for item snnnn snnnn snnnn snnnn ..snnnn snnnn from folder xxxxx.
Error Messages TCHECK Utility Messages **** Mail System Control Record missing The mail system control record was missing from the Profile file; TCHECK created the record using the same defaults used by the TRANSFER initialization programs. **** Next filename to assign updated The NEXT-FILENAME-TO-ASSIGN field in the item descriptor file’s control record was incorrect; TCHECK updated the record to avoid file naming conflicts.
Error Messages TCHECK Utility Messages **** xxxxx missing Either the model depot or the TAREQ correspondent’s depot was missing from the TRANSFER name directory; TCHECK created the depot using the same defaults used by the TRANSFER initialization programs. **** xxxxx missing for depot xxxxx INBOX, OUTLOG, or WASTEBASKET was missing from the TRANSFER name directory at the indicated depot; TCHECK created the special folder with time-saved, ascending-sequence, and allow-duplicates for ordering criteria.
Appendix C Contents of the User-DSVs Appendix C describes the files on the user-DSVs for a TRANSFER delivery system. A user-DSV is a copy of the files provided by Tandem on a distribution subvolume (DSV).
Contents of the User-DSVs TRANSFER User-DSV PS MAIL 6530 installation files CDMLDEF Definition program for PS MAIL 6530 MLDEFLTS Defaults files for PS MAIL 6530; provides the default configuration for the component PS MAIL 3270 installation files CDIMDEF Definition program for PS MAIL 3270 IMDEFLTS Defaults files for PS MAIL 3270; provides the default configuration for the component PS MAIL TTY installation files CDCMDEF Definition program for PS MAIL TTY CMDEFLTS Defaults files for PS MAIL TTY;
Contents of the User-DSVs TRANSFER User-DSV TAREQDIR SCREEN COBOL object directory for TAREQ TCHECK TRANSFER data file checker TEXTCOM Program to load text into a Text file TEXTFILE Help and error message file for Base TRANSFER, ADMIN, and TMANAGER TEXTSRV Text server TISERV TRANSFER interactive server; must be licensed TRANCOD SCREEN COBOL object code for ADMIN and TMANAGER TRANDIR SCREEN COBOL object directory for ADMIN and TMANAGER TRECV Network receiver server TSCHED TRANSFER schedul
Contents of the User-DSVs MAIL6530 and MAIL3270 User-DSVs X400 Gateway The TRANSFER DSV also contains the files for running a TRANSFER X400 gateway. The X400 gateway translates messages so that TRANSFER correspondents can communicate with X.400 users. EXPRTSRV Exporter server; translates TRANSFER messages into X.400format messages IMPRTSRV Importer server; translates X.
Contents of the User-DSVs MAILTTY User-DSV MAILTTY User-DSV The MAILTTY-DSV contains files for running and documenting the PS MAIL TTY client. T9130COD PS MAIL TTY command file T9130MSG PS MAIL TTY message file T9130OBJ PS MAIL TTY object file T9130CFG Run-time configuration file This file is automatically generated when you define or redefine the PS MAIL TTY component. PS MAIL TTY uses the generated file at run time to determine which servers to use for the mail session.
Contents of the User-DSVs MAILTTY User-DSV Figure C-1. Sample PS MAIL TTY Run-Time Configuration File * * * * If PS MAIL TTY is to create TISERV and GFSERV as new processes outside PATHWAY, their locations are specified in the following two parameters; otherwise, NONEWPROCESS is specified. * Location of PROGID TISERV for newprocess or "NONEWPROCESS" NONEWPROCESS * Location of PROGID G-File Server for newprocess or * "NONEWPROCESS" NONEWPROCESS * Location of PS MAIL TTY message and commands files \FIGGY.
Appendix D National Language Support Softdocs To help you specify the character set and map for your version of PS MAIL 6530 or PS MAIL 3270, Tandem provides a set of programs. These programs are available on the DSV for each language; softdocs provide installation and usage instructions. Appendix D includes the source-text from one of the languages, German, as an example: SMGERMAN is used to initiate German PS MAIL and SAGERMAN is used to initiate ADMIN to run with the German character set.
National Language Support Softdocs German Language Support SOFTWARE RELEASE DOCUMENT Product Name: GERMAN language support Product Number: T1103C20 Date: 28 February 1991 Required Hardware: NonStop System Required Firmware: None Required Software: T9131C20 20APR90 IPM or later PS MAIL 6530 General Information: 1) This is the release of the PSMAIL german language support to be used with T9131C20 20APR90 or later PS MAIL 6530.
National Language Support Softdocs German Language Support This DSV contains SCOBOL source code for each of the PS MAIL 6530 and the ADMIN starter programs. The programs can either be used directly or can be used as guidelines where PS MAIL is called from within a user written program. Installation Instructions: 1) Installation procedures should be performed after configuring TRANSFER.
National Language Support Softdocs German Language Support In order to run this step you will need to cool start the TRANSFER system. VOLUME RUN XCOOL ! This cool starts TRANSFER PATHCOM =ADD PROGRAM M6530-GERMAN1,LIKE M6530-1, TYPE T16-6530(INITIAL MAIL-GERMAN, TCLPROG ) etc for M6530-2 for as many as configured.
National Language Support Softdocs German Language Support 3) For base TRANSFER and PS MAIL 6530 it is necessary to combine together the textfiles for all the required languages into a single textfile. This is done using the SORT with the following parameters:FROM .ZNLGERMN.textfile FROM .ZNL.textfile ! FROM .ZNL.textfile ! repeat for each additional language required ASC 1 FOR 10 UNSIGNED TO .
National Language Support Softdocs German Language Support TRANSFER Name Character Mappings: 1) Not all characters are displayable or keyable on all terminals. This is especially true in international networks or where more than one language is available on a system. For CORRESPONDENT NAMES, DISTRIBUTION LIST NAMES and FOLDER NAMES only, TRANSFER allows these normally unreachable characters to be displayed and keyed on inappropriate terminals.
National Language Support Softdocs German Language Support 6) 7) For 653X terminals configured for SVENSK/SUOMI (Print with SWEDISH/FINNISH printer) accent representation s SHARP ACUTE CEDILLA GRAVE TILDE DIAERESIS LIGATURE CIRCUMFLEX SLASH NUMBER SIGN (#) SINGLE QUOTE (') CURRENCY SIGN($) PERCENT SIGN (%) EQUALS SIGN (=) COLON (:) PLUS SIGN (+) GREATER THAN (>) SLASH (/) example # 'a $c %a =N :E A+E >I /O - German sharp s or beta a-acute French c-cedilla a-grave Spanish N-tilde E-diaresis Danish A
National Language Support Softdocs SMGERMAN SMGERMAN SMGERMAN is the program that you use to initiate German PS MAIL. IDENTIFICATION DIVISION. PROGRAM-ID. MAIL-GERMAN. ** To start PS-MAIL-6530 using:* Language 3 German * Code Page -236 European Languages * Code Set -232 Tandem ASCII - German * * N.B. This program may be modified from the above three options * to cater for different circumstances. * DATE-COMPILED. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. T16. OBJECT-COMPUTER. T16.
National Language Support Softdocs SMGERMAN * * * * * * -229 (65307) - TANDEM ASCII FOR DANISH/NORWEGIAN -206 (65330) - ISO 8859.1 -205 (65331) - TANDEM HEBREW 01 IPC-HDR. * copy IH-IPC-HDR of GCOB *?SECTION IH-IPC-HDR,TANDEM * Definition IPC-HDR created on 12/01/86 at 14:26 05 IH-IPC-HDR. 10 IH-REQUEST-CODE PIC S9(4) COMP. 88 IH-STOP-ON-WARNING Value is -1. 88 IH-STOP-ON-ERR Value is -2. 88 IH-DO-ALL-UOWS Value is -3. 10 IH-PW-REPLY-CODE REDEFINES IH-REQUEST-CODE PIC S9(4) COMP.
National Language Support Softdocs SMGERMAN 10 FILLER PIC X. 01 LANGUAGE-AND-CHAR-SET. * copy LANGUAGE-ID of GCOB * copy CHAR-SET-ID of GCOB * * * * Definition LANGUAGE-ID created on 12/01/86 at 14:25 ------------------------------------------------------------------Identifier for a language. ------------------------------------------------------------------05 LANGUAGE-ID PIC 9(4) COMP.
National Language Support Softdocs SAGERMAN IPC-HDR, LANGUAGE-AND-CHAR-SET, SYSTEM-NAME, LOG-BACK-ON-FLAG. EXIT-PROGRAM. EXIT PROGRAM. SAGERMAN SAGERMAN is the program that you use to initiate ADMIN to run with the German character set. IDENTIFICATION DIVISION. PROGRAM-ID. GERMAN-ADMIN. * * To start PS-MAIL-ADMIN using:* Language 3 German * Code Page -236 European Languages * Code Set -232 TANDEM GERMAN terminal * Banner "DEUTSCH Version" * * N.B.
National Language Support Softdocs SAGERMAN * * * * * * * * * * * * -235 -234 -233 -232 -231 -230 -229 (65301) (65302) (65303) (65304) (65305) (65306) (65307) - TANDEM TANDEM TANDEM TANDEM TANDEM TANDEM TANDEM ASCII ASCII ASCII ASCII ASCII ASCII ASCII FOR FOR FOR FOR FOR FOR FOR USA UK FRENCH GERMAN SWEDISH/FINNISH SPANISH DANISH/NORWEGIAN -206 (65330) - ISO 8859.1 -205 (65331) - TANDEM HEBREW 01 LS-LOGON-BANNER * * * * * * * * PIC X(18) VALUE "DEUTSCH Version".
Appendix E System Installation Example This example shows a TRANSFER system installation and illustrates the following tasks: Installing a test TRANSFER system consisting of Base TRANSFER and PS MAIL 6530 Adding a user-written client and agent to the system Making changes after the system is up and running Sample System The sample is a test system that will eventually coexist with a production system at the Description same installation.
System Installation Example Sample System Description Console The console is named $CONSOLE. Spooler collector The spooler collector is named $S. System ID The system ID is 1,30. User-Written Components The sample system contains a user-written client and agent, both of which are SCREEN COBOL requesters (for the descriptions, see “Sample Client” and “Sample Agent” in the TRANSFER Programming Guide.).
System Installation Example Steps to Install the System Steps to Install the To install Base TRANSFER and PS MAIL 6530, the system manager follows these System steps. Step 1: Get the DSV First, the system manager obtains the user distribution subvolumes (user-DSVs) from the installation subvolumes (ISVs), volume.ZTRANSFR and volume.ZMAIL653, and copies them to $DISKZ.TRANDSV. The products to be installed are: Base TRANSFER, with product number T9110 and prefix TR.
System Installation Example Steps to Install the System Step 4: Edit DEFINE Files The next step is to edit the DEFINE files and look for values that must be replaced or changed to produce the new configuration. DEFINETR File Modifications First, the system manager goes through the DEFINETR file for Base TRANSFER and makes the following changes: Sets TRUserDSV to the name of the DSV for the TRANSFER software: $DISKX.TRANDSV in the example. SetsTRGuardianUserId to a user ID for the test system.
System Installation Example Steps to Install the System Separately changes the process names for PATHMON, the Name server, and the TRANSFER Scheduler server by modifying the ?LET commands at the beginning of the DEFINETR file as follows: ?LET PathmonName = $TXPM (Changed from $TRPM) ?LET TschedName = $TXTS (Changed from $TSCH) ?LET NameServName = $TXNS (Changed from $T) DEFINEML File Modifications Next, the system manager goes through the DEFINEML file for PS MAIL 6530 and makes the following chang
System Installation Example Steps to Install the System These messages mean that no system is running with the same process names as the ones in the system being started. The system manager ignores them. When Base TRANSFER has been initialized, the system manager purges the GTRINIT file to prevent someone from accidentally running it and purging the database.
System Installation Example Steps to Install the System Step 11: Add Correspondents When the TRANSFER system is brought up, there is only one correspondent in the system: SYS-ADMIN. To test information delivery, at least one more correspondent is needed.
System Installation Example Steps to Change the System Steps to Change the If the system manager later wants to change any components of the system, here are System the steps to follow: 1. Run XSTOP to stop the TRANSFER system. 2. Make the changes. The changes usually involve changing the values for reconfigurable parameters or altering the PATHWAY configuration by adding PATHCOM commands in the CUSTCNFG file. In addition, the system manager might want to add more clients or agents to the system.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 1 of 9) -- TRDEFLTS File -------------- COMMON VALUES -------------?LET Server_Out ?LET ?LET ?LET ?LET ?LET ?LET ?LET ?LET ?LET ?LET CPUA CPUB CPUC CPUC CPUE CPUF CPUG CPUH CPUI CPUJ = = = = = = = = = = = $0; (0,1); (1,2); (2,3); (3,4); (4,5); (5,6); (6,7); (7,8); (8,9); (9,10); -------------- RECONFIGURABLE PARAMETERS -------------TRUserDSV $diskx.trandsv TRPwayLocation $SYSTEM.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 2 of 9) TRPwayMaxPrograms 30 TRPwayMaxExternalTcps 10 TRMinPriority 128 TRMaxPriority 148 -- **** Configure External Objects **** TRExtobjsEnabled NO -- TRExtobjsVolume00 $vol -- TRExtobjsFileSecurity NUUU -- TRExtobjsSubvolPrefix EOD TRAgentTclprog $diska.tranext.cust TRTranTclprog $vol.TRANCNFG.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 3 of 9) --**** Define TRANSFER Asynchronous Requesters (TAREQ) pseudoterminals TRTareqTerms 1 -- TRTareqTcpSwap $vol -- TRTareqTcpGUARDIANSwap $vol -- TRTareqTcpMaxterms 20 -- TRCleanupTareqTerms 2 -- **** Define TRANSFER Receiver Front End (TFRONT) pseudoterminals TRTFrontTerms 2 TRX4GatewayNode \node TRTschedServCpu [CPUD] TRTschedServOut [Server_Out] TRTschedServLog $S.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 4 of 9) TRNameServOut [Server_Out] -- **** Configure the System Management Server (SMServ) **** TRSMServName $TXSM TRSMServCpu [CPUG] TRSMServOut [Server_Out] TRSMServDebugLog $S.#SMSERV.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 5 of 9) TRTrecvServNames0 $TXR0:9 TRTrecvServCpu0 [CPUJ] TRTrecvServCpu1 [CPUA] TRTrecvServOut [Server_Out] TRTrecvServLog $S.#TRECV.LOG TRTrecvServDebuglog $S.#TRECV.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 6 of 9) TRAsyncTiservCpu0 [CPUD] TRAsyncTiservCpu1 [CPUJ] TRAsyncTiServOut [Server_Out] TRAsyncTiServDebuglog $S.#TISERVA.DEBUGLOG -- **** TRFormatServs 2 TRFormatServNumstatic 1 TRFormatServNames0 $TXF0:9 TRFormatServCpu0 [CPUE] TRFormatServOut [Server_Out] TRFormatServDebuglog $S.#FORMAT.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 7 of 9) TRProcessServHometerm $myterm TRProcessServNames0 $TXP0:9 TRProcessServCpu0 [CPUI] TRProcessServCpu1 [CPUA] TRProcessServOut [Server_Out] TRProcessServDebuglog $S.#PROCESS.
System Installation Example Sample Base TRANSFER Define File Figure E-1. Base TRANSFER Define File (Page 8 of 9) TRModelCorr MODEL-DEPOT TRModelGroup MODEL-GROUP TRSysAdminCorr SYS-ADMIN -- **** Initial Depot Statistics Parameters **** TRStatsCollectStats NO TRStatsCountWhenExamined NO TRStatsStartTime 00:00 TRStatsSampleTime 1D -- **** DATA BASE FILES **** E–16 TRNameFilesSubVolume diska.
System Installation Example Sample Base TRANSFER Define File Figure E-1.
System Installation Example Sample PS MAIL 6530 Define File Sample PS MAIL 6530 Define File Figure E-2 shows the PS MAIL 6530 define file. Note that the [Server_Out] variable was initialized to $0 during DEFINETR processing. Figure E-2. PS MAIL 6530 Define File -- MLDEFLTS File -------------- RECONFIGURABLE PARAMETERS -------------- -- MLUserDSV $diskx.trandsv MLUserTclprog $vol.TRANCNFG.
Glossary ADMD. See Administration Management Domain. ADMD name. The name of the ADMD that is assigned to a TRANSFER correspondent; the ADMD name comes from the configuration parameters when the X400 gateway is installed on a node. All TRANSFER correspondents registered on nodes grouped into the same domain have the same ADMD name. ADMIN. An application that allows administrators to perform administrative tasks for correspondents, interest groups, distribution lists, folders, and the TRANSFER system.
Glossary Bulletin board. A folder for an interest group. Group members can read items in the group bulletin board folder and save items to the bulletin board for other members to read. Character map. A set of codes that establishes the correspondence between the native form of a character and a character in the base character set. In effect, this map is a set of rules for encoding or representing characters in that set.
Glossary Default model depot. The depot whose profiles are copied when a model depot is not specified for a new correspondent. The default model depot is established when TRANSFER is initialized. Default model group depot. The group depot whose profiles are copied when a model depot is not specified for a new group. The default model group depot is established when TRANSFER is initialized. Defaults file. A file that contains keyword parameters and default values to be used as the source of a define file.
Glossary Depot storage old statistics. Displayed on the OLD STATISTICS screen, the samples taken for the preceding configuration period if the depot storage facility was keeping previous samples. Depot storage statistic. The byte count of data stored in a depot. This data includes item data, external objects, and distribution list records. The storage statistic can reflect a current or a past storage amount for the depot. Depot storage statistics.
Glossary Foreign domain. An X400 domain outside the TRANSFER network. FOSERV. Format server, used in the FORMAT server class to format screen data internally for the PS MAIL 6530 and PS MAIL 3270 clients. FPSERV. File Utility Program (FUP) server, which is invoked by the TISERV, TWORK, and GFILE to create and copy external objects. It is not configured as a PATHWAY server class. Fully qualified correspondent name.
Glossary IPC header. The first entry in an IPC. The header in an IPC request establishes processing conditions. The header in an IPC reply indicates what occurred during processing. IPC interface. The means by which a client communicates with TRANSFER. Item. A collection of information that has a unique identity and that consists of an item descriptor and zero or more data records.
Glossary Name server (NAMESRV). A TRANSFER process that manages the TRANSFER name directory. Name space. The database managed by the TRANSFER name server. It contains lists of all correspondents on a node of a TRANSFER system, all distribution lists and folders owned by those correspondents, and the relationships between all correspondents and the distribution lists and folders they own. It also contains entries for most of the configuration entities defined in the system.
Glossary OUTLOG folder. A special folder, automatically created for each correspondent, where PS MAIL automatically files a copy of each message a correspondent sends. Messages stay in the OUTLOG for the length of time configured, usually 24 hours. The OUTLOG cannot be deleted. P1. X.400 protocol used to format and route messages through the X400 network. P1 message. An X400 message that consists of an envelope and its content.
Glossary PRMD name. The name of the PRMD that is assigned to a TRANSFER correspondent; the PRMD name comes from the configuration parameters when the X400 gateway is installed on a node. All TRANSFER correspondents registered on nodes grouped into the same domain have the same PRMD name. PRMD names are required for X400 messages coming into a TRANSFER system; PRMD names are optional for X400 messages exported from a TRANSFER system. Process. A running program. Profile.
Glossary READY queue. One of the four queues for which TSAMPLE collects—at configurable intervals—counts of work scheduled. The READY queue contains requests that are ready for processing. Recipient. A correspondent to whom a package is delivered. Recipient list. The names of correspondents, interest groups, and distribution lists that are to receive a particular package. The recipient list is an attribute of the package and applies only to the package for which the recipient list is created.
Glossary Simple name. A name used either by itself or in combination with other simple names to identify a correspondent, folder, distribution list, or a named instance of an item. A simple name can have a maximum of 32 characters, which must be chosen from the name character set in effect for TRANSFER. Site Update Tape (SUT) . The tape on which Tandem ships its software for installation.
Glossary TCHECK utility. A program you run regularly to locate and adjust inconsistencies in the TRANSFER data files. TCP. Terminal control process. Text server (TEXTSRV). A TRANSFER server that stores and retrieves various kinds of text. For instance, the text server handles such input text as command words and their abbreviations, keywords, and the names of objects. It also handles such output text as prompts, screen field labels, error messages, and help information.
Glossary TRANSFER asynchronous requester (TAREQ). A collection of SCREEN COBOL programs that handles the actual delivery of a package to a depot. These programs are supplied by Tandem and run within a standard PATHWAY TCP. The asynchronous requester locates the recipients of a package, delivers the package to local depots, and transports the package to remote nodes for delivery by their asynchronous requesters. TRANSFER database.
Glossary UA (User Agent). The functional object that represents the user in the X400 message handling system. It interacts directly with the user, prepares messages, and submits messages for routing to their destinations. UAs also reply, retrieve, and forward messages for the user. Unit-of-work (UOW). An elementary operation to be performed by the TRANSFER interactive server; in the queue management environment, an elementary operation to be performed by an Entry Manager or the Wait Manager.
Glossary X400 depot. A depot defined at each X400 gateway node. This depot is used when a message needs to be exported to a foreign X400 network. When an message to be sent to an X400 correspondent arrives at the local gateway node, the message is saved in the _X400_ depot’s INBOX folder for each X400 recipient. The message ID is placed on a queue, and the export server is informed that it has work to do. X400-EMSERV.
Index A A-BASE-TEXT 7-10 A-NAMESRV 2-19 A-STATS 2-20 A-TSCHED 2-19, 7-7, 11-6, 12-1 ADMD defined 3-5 example 3-5 field 9-24 name conventions 5-11 described 3-10 must match name on MTA 2-28 ADMIN See also DEPOT STATISTICS CONFIGURATION screen, SESSIONS IN PROGRESS screen, TRANSFER SYSTEM CONTROL screen, X400 GATEWAY ATTRIBUTES screen accessing 2-1 administrative privileges 1-10 AGENT CONFIGURATION screen 11-38 configuration 2-21 definition and installation 6-4 delivery time, controlling 9-5 depot statistics
Index Agent configuration examples PATHWAY server 11-39 SCREEN COBOL requester 11-38 implementation considerations 11-34 profile 2-8 selection value 10-40 supplied by Tandem print-on-delivery 11-34 vacation 11-34 user-supplied PATHWAY server 11-35, 11-39 SCREEN COBOL requester 11-35, 11-37, 11-38 AGENT CONFIGURATION screen 11-38 Application ID 10-40 running 6-23 ASSIGNs debug log 7-4, 7-19 DTCMAPS 7-10 logging specifications 11-17 NAMESRV 11-14 Queue Manager 11-9 resetting 7-23 Text file 7-10 TEXTSRV 11-11
Index B Base TRANSFER A-BASE-TEXT 7-10 CDTRDEF 6-1 components 2-18/22 configuration 2-18/22 data files See Data files define file descriptions A-2/30 defined 2-1 defining 6-4/7 GTRCNFG 6-21, 7-1 GTRCOOL 6-22 GTRINIT 6-1 GTRSTOP 6-34 includes ADMIN 2-1, 6-4 includes TMANAGER 2-1, 6-4 initializing 6-3 installation example 6-5 required 2-1, 6-4 TRDEFLTS 5-6, A-2/30 $ZT process name 5-15 Blind-copy recipient 3-3 C CDCMDEF 6-1, 6-12, 6-21 CDIMDEF 6-1, 6-10 CDMLDEF 6-1, 6-8 CDTRDEF 6-1, 6-4/6, 6-21, 11-2 CDX4DEF
Index CHECKFOLDERS 11-27, 11-32 CHECKGROUPS 11-27, 11-32 CHECKITEMS 11-27, 11-32 CHECKPROFILES 11-27, 11-31 CHECKSESSIONHOUR 7-8, 10-14, 11-6 CHECKX400RECIPS 11-27, 11-32 CLEANSESSIONSONLY 2-17, 11-31 Cleanup TAREQ 10-13, 11-4 Client, $ZC process name 5-15 CMDEFLTS 5-6, A-39/43 CODEPAGEID 7-10 Communications Management Interface (CMI) 11-20 Communications Utility Program (CUP) 11-20 CONFIG 10-55 Configuration See also Integrating TRANSFER into existing PATHWAY system agent 11-34 Base TRANSFER 2-18/22 consi
Index Configuration (continued) X400 gateway 2-27/28 XCNFG program 6-1, 6-20/21 See also XCNFG Controlling delivery time 9-5 CORR 2-22 Correspondent foreign (X400) 3-5 local 1-2 naming conventions 11-1 privileges 1-10 profile 2-7 remote 1-2 X400 names 3-10 Courier defined 2-2 turning on suffixes 6-29 CUSTCNFG 6-2, 6-20, 7-2 CUSTCOOL 6-2, 7-2 Customizing defined 6-2 examples 7-23 files See also individual file names CUSTCNFG 6-2 CUSTCOOL 6-2 CUSTSTOP 6-2 GCMCNFG 7-1 GIMCNFG 7-1 GMLCNFG 7-1 GTRCNFG 7-1 GX4CN
Index Customizing (continued) X400 gateway servers 7-19/22 X400-EMSERV 7-22 X400-EXPORTER 7-19, 7-21 X400-IMPORTER 7-20, 7-21 X400-WMSERV 7-22 CUSTSTOP 6-2, 7-2 D Data files and TCHECK 11-26 assigning new names 11-12 Character Map (DTCMAPS) 2-6 codes 2-14 Data Base Sample (DBSAMPL) 2-6 Depot Statistics (DEPSTAT) 2-6 Depot Statistics (DEPSTATO ) 2-6 Directory Services Data (DSDATA) 2-5 Directory Services Data (DSDATA0 ) 2-5 Distribution List (DISTLIST) 2-5 External Objects (EXTOBJS) 2-6 Folder (FOLDER) 2-5,
Index Data files (continued) Profile (PROFILE) 2-5 Queue Sample (QSAMPL) 2-6 Ready (READY) 2-6 Ready (READY0) 2-6 Recipient (RECIP) 2-6, 12-9 Remote Open Control (ROPENCTL) 2-7 rules that govern 11-9 Session (SESSION) 2-6, 2-16, 12-9 Text (TEXTFILE) 2-6 Time (TIME) 2-6 Time (TIME0) 2-6 X400 Name (X400NAME) 2-13 X400 Queue (X400QUEU) 2-13 X400QUEU file 2-13, 12-9 Database and TCHECK 11-27 determining size 11-3 files See also individual file names list of 2-5/7 partitioning 12-9/12 initializing 11-22 no dupl
Index Define file CMDEFLTS 5-6 editing 5-8 explained 5-1 file descriptions, definition of 5-2 format 5-4 IMDEFLTS 5-6 MLDEFLTS 5-6 preparing 5-6 sample parameter name 5-5 source for 5-1 TRDEFLTS 5-6 X4DEFLTS 5-6 Define file descriptions Base TRANSFER A-2/30 CMDEFLTS A-39/43 IMDEFLTS A-35/38 MLDEFLTS A-31/34 PS MAIL 3270 A-35/38 PS MAIL 6530 A-31/34 PS MAIL TTY A-39/43 TRDEFLTS A-2/30 X400 gateway A-44/46 X4DEFLTS A-44/46 DEFINETRX4 11-2 Definition See also Base TRANSFER, Define files, PS MAIL 6530, PS MAIL
Index Delivery concepts 2-29 setting parameters 11-3 status 10-49, 10-52 time, controlling 9-5 window, minimum 9-4, 9-5 Depot See also Depot statistics facility asynchronous requester 6-32 created when Base TRANSFER initialized 2-8 ID 1-5 initializing special See individual depot names model (MODEL-DEPOT) 2-22, 6-28/29 model group (MODEL-GROUP) 2-22, 6-30/31 name 2-22 public group (PUBLIC) 2-22, 6-31 structure 1-5 system-administrator 2-22, 6-28 X400 3-9, 6-33 XIINT to initialize 11-22 DEPOT STATISTICS CON
Index Depot statistics facility (continued) parameters for statistics collection BASE TIME 9-14 caution in changing 9-22 COUNT ITEMS WHEN EXAMINED 9-14 methods 9-14 must restart TRANSFER to change 9-17 NUMBER OF AVERAGES 9-15 NUMBER OF SAMPLES (PER AVERAGE) 9-14 restarting TRANSFER to change 9-14 SAMPLE INTERVAL 9-14 STANDARD ITEM COUNTING 9-16 reconfiguring, example of 9-19/21 sample interval 9-13, 9-14, 9-18 sampling statistics 9-12 screens 9-12/22 Depot Statistics file (DEPSTAT) 9-12, 9-15 DEPSTAT file
Index E Error See also Appendix B 1003 12-2 3115 12-2 4990 12-8 6127 6-25 network traffic logging 11-17 SMSERV 10-4 SPREP 6-27 TMANAGER 10-4 Error messages definition program B-1/17 server output file B-41/56 server startup common B-18/20 GFSERV B-21 SMSERV B-21 STBINIT B-24 STRINIT B-25 STWINIT B-25 X400 gateway B-27/40 TCHECK B-57/65 TISERV B-41 TRECV B-41 TSCHED B-42/56 TWORK B-41 EXPAND 2-1, 2-3, 11-19, 12-19 EXPANDPRIORITY 7-16, 11-19 Expiration window, minimum 9-4, 9-5 External objects 2-10, 9-4, 9-6
Index F File audited 2-7, 2-13, 2-15 codes 2-14 default 5-1 fully qualified name 11-9 partitioned 10-18, 10-20, 12-9/12 text 4-2 threshold 12-4 File codes 2-14 FILE DETAIL screen 10-19/21 File-moving procedure 6-19 Folder See also FOLDER SCAN screen configuring special-folder names 2-9 file 12-12 ID 1-5 ordering criteria 6-29 ordering discipline 6-29 ordering sequence 6-29 FOLDER file 2-5, 2-9 Folder file (FOLDER) 12-9 FOLDER SCAN screen 10-34, 10-36 FORMAT 2-25 FOSERV 2-19 FPSERV 2-20, 4-2 G G-FILE 2-25 G
Index GMLCNFG 6-9, 6-21, 7-1 GMLCOOL 6-9, 6-22 GMLSTOP 6-9, 6-34 Group See also Interest group model depot 2-22 profile 2-8 PUBLIC depot 2-22 GTRCNFG 6-6, 6-21, 7-1 GTRCOOL 6-6, 6-22 GTRFUP 6-5 GTRINIT 6-1, 6-3, 6-5, 6-7 GTRLOAD 6-5 GTRSTOP 6-6, 6-34, 10-55 GTRUPDT 6-6, 6-21, 11-18 GUARDIAN 90 clearing parameter values 6-3 files, as external objects 2-10, 9-6, 11-9 ID and asynchronous requester depot 6-32 for file-name resolution 10-24, 10-28 for user-DSV files 4-2 remote 2-3 GX4CNFG 6-17, 6-21, 7-1 GX4COO
Index I IATTACH file 2-6, 2-10 ID See also GUARDIAN 90 application 10-40 as database pointer 9-19 character map 5-13, 9-4 code-set other than SCREEN COBOL and TAL 9-8 depot 1-5 folder 1-5 item 1-5, 10-32, 10-38, 10-43, 11-24, 11-27 language 5-13, 9-4, 9-7 SCREEN COBOL code-set 9-8 session 2-11 TAL code-set 9-8 Idle sessions example 11-7 how to use to control system 11-6 IDLESESSIONDELAY 7-15, 11-6 IFOLDER 2-5, 2-9, 12-9 IFOLDER1 2-5, 2-9 IMDEFLTS 5-6, A-35/38 INBOX 2-9, 6-29, 6-31, 6-33, 9-14, 11-6 Initial
Index Installation See also Integrating TRANSFER into existing PATHWAY system concepts 1-8/9 example E-1/18 install Base TRANSFER first 6-8, 6-10, 6-12, 6-15 INSTALL program 4-1 named TACL required 6-1 preparing for 4-1/4 sample system Base TRANSFER define file E-8 description E-1 PS MAIL 6530 define file E-18 steps to change E-8 steps to install E-3 summary 6-36/38 Installation Subvolume (ISV) 4-1 Integrating TRANSFER into existing PATHWAY system cannot use XCONFG 6-39 cannot use XCOOL 6-40 cannot use XST
Index Item component 1-2 defined 1-2 delete 10-10, 10-33 ID 1-5, 10-32, 10-38, 10-43, 11-24, 11-27 retention time 6-28, 11-5 tracing 10-32, 10-36, 12-3 See also ITEM TRACE screen type 10-39 unsave 10-10, 10-33 Item Data file (ITEMDATA) 12-9 Item Data file auditing 2-16 Item Descriptor file (ITEMDESC) 12-9 ITEM TRACE screen 10-37/43 ITEMDATA file 2-6, 2-10, 2-16 ITEMDELETEDELTA 7-15 ITEMDESC file 2-6, 2-10 ITEMIDCACHE 7-11, 7-13, 7-15, 7-22 L Languages See National language support Licensing user-DSV files
Index Log (continued) TSCHED 7-7, 10-27, 12-15 TSRBLD running with 11-24 running without 11-24 TWORK 7-14, 10-27, 12-17 X400 export server 7-19, 12-23 X400 import server 7-20, 12-26 LOG CONTROL screen 10-27/28 Logon remote to ADMIN 2-21 remote to PS MAIL 2-24 LOGRECSPEROPEN 7-7, 7-8, 7-15, 7-18 M M3270-TEXT 7-10 M3270-TEXT server 2-24 M6530-TCP 2-24, 5-17 M6530-TEXT 7-10 M6530-TEXT server 2-24 Mail if not delivered 12-1/4 profile 2-8 MAXEXTERNALTCPS 2-21, 2-24 Maximum package lifespan 9-4, 9-5 MAXLINKS 7-5
Index Model depot and XIINT 11-22 configuring 6-28/29 item retention time 11-6 mail profile 6-29 special folder attributes 6-29 TRANSFER correspondent profile 6-28 Model group depot and XIINT 11-22 configuring 6-30/31 item retention time 11-6 MONITOR CONFIGURATION screen 10-22/26 Moving TRANSFER data files assigning new file names 11-12 rules 11-9 steps 11-10 storing new names with NALOAD program 11-11 MR group 3-7 MTA 2-28, 3-3, 11-2 MULTILAN 4-2 N NALOAD 11-11, 11-13 Name See also Naming conventions asyn
Index Name (continued) simple TRANSFER 5-10 system 2-3 verification of, remote 2-7 NAME file 2-5, 2-7, 11-9 NAME0 file 2-5, 2-7 NAMEFILE 10-55 NAMESPACE 7-5, 7-8, 10-57 NAMESRV and TCHECK 11-26, 11-28 description of 2-19 exception to prefix rule 5-15 obey file 11-14, 11-22 PARAM specifications 7-4 Naming conventions 5-9 PATHWAY process 5-14 PATHWAY server 5-14 simple TRANSFER name 5-10 X400 name 5-11 National language support configuring character set 5-13 described 5-12 languages available 5-12 programs s
Index Network controlling OPEN requests 2-12 monitoring 11-20 performance, improving 12-4 status 12-2 traffic logging configuring the traffic log 11-18 creating the traffic log 11-17 logging file 11-15 Network Traffic Logging file (TRAFLOG) 2-12 NUMQUEUEMGRS 7-21 NUMSTATIC 7-19, 7-20 NUMTDBSERVERS 7-21 O Object libraries hints for preparing 4-3/4 supplied by Tandem 4-3 user-written 4-3 OKTOCREATE 7-10 OPENERLIMIT 7-8 OSI/MHS system 3-7 OUTLOG 2-9, 6-29 P P1MSGID file 2-13 P2MSGID file 2-13 Package defined
Index PARAMs BASE TIME 9-14 CHECKSESSIONHOUR 11-6 COUNT ITEMS WHEN EXAMINED 9-14 DEBUGLOGLEVEL 12-30 EXPANDPRIORITY 11-19 general 7-4 GFSERV 7-13 IDLESESSIONDELAY 11-6 NUMBER OF AVERAGES 9-15 NUMBER OF SAMPLES (PER AVERAGE) 9-14 RESTRICTPRIORITYBEGIN 11-4 RESTRICTPRIORITYEND 11-4 RESTRICTPRIORITYVALUE 11-4 ROPENCTLTIME 10-56 SAMPLE INTERVAL 9-14 SAMPLETIME 10-55 STANDARD ITEM COUNTING 9-16 TDBSERV 7-22 TEXTSRV 7-10 TIMEWASRESET 6-22, 6-25 TISERV 7-11 TRECV 7-17/18 TSCHED 7-7/9 TWORK 7-14/16 WRITEENABLE 10-
Index PATHWAY configuring servers 11-35, 11-39 integrating TRANSFER into existing system 6-40/42 object-name generation 5-17 priority values 5-17/18 process name changing 5-16 conventions 5-14 generation 5-14/16 server name 5-14 servers as agents 11-35, 11-39 system monitoring 11-20 Print-on-delivery agent 11-34 Priority controlling 11-3 EXPAND 11-19 PATHWAY process 5-17/18 restricting window 11-4 Private Management Domain See PRMD PRMD defined 3-5 example 3-5 field 9-24 limits 3-5 name conventions 5-11 de
Index PS MAIL 3270 CDIMDEF 6-1 configuration 2-24/25 define file descriptions A-35/38 defined 2-1 definition procedure 6-10/11 GIMCNFG 6-21, 7-1 GIMCOOL 6-22 GIMSTOP 6-34 IMDEFLTS 5-6, A-35/38 installation example 6-11 logon, remote 2-24 M3270-TCP 2-24 M3270-TEXT 7-10 M3270-TEXT server 2-24 server classes, required 2-25 user-DSV C-4 PS MAIL 6530 CDMLDEF 6-1 configuration 2-24/25 define file descriptions A-31/34 defined 2-1 definition procedure 6-8/9 GMLCNFG 6-21, 7-1 GMLCOOL 6-22 GMLSTOP 6-34 installation
Index PS MAIL TTY CDCMDEF 6-1 CMDEFLTS 5-6, A-39/43 configuration 2-26 define file descriptions A-39/43 defined 2-1 definition 6-12/14 GCMCNFG 6-21, 7-1 GCMSTOP 6-34 installation example 6-13 security across network 4-2 T9130CFG C-5 T9130CFG configuration file 2-26 TTY-G-FILE server 2-26 TTY-TISERV server 2-26 user-DSV C-5 Pseudo-terminal cleanup TAREQ 11-4 defined 2-18 TAREQ 2-18 TFRONT 2-18 PSSERV 2-19, 4-2, 6-32 Public group depot (PUBLIC) and XIINT 11-22 configuring considerations 6-31 description of 2
Index Queue Manager and X400 servers 3-7 automatically installed with X400 gateway 2-2, 2-13 defined 2-2 file names 11-9 X400 gateway requirement 2-3 QUEUEMGRNAMES0 7-21 QUEUEMGRNAMES1 7-21 QUEUEMGRNAMES2 7-21 QUEUEWAITMGR 7-21 R Ready file (READY) 2-6, 2-11, 11-24 READY queue 10-10, 10-25, 10-26, 10-29, 10-32 READY0 file 2-6 RECIP file 2-6, 2-10 Recipient See also RECIPIENT SELECT screen, RECIPIENT DISPLAY screen, X400 RECIPIENT screen blind-copy 3-3 name 2-10, 10-49 type 10-45, 10-49, 10-52 X400 name 2-1
Index Remote correspondent 1-2 logon on to ADMIN 2-21 logon on to PS MAIL 2-24 passwords 2-3 shipment entries in NET queue 10-14 verification of names 2-7 Requester 11-38 RESERVERECEIVELCBS 7-8 RESERVESENDLCBS 7-8 RESTRICTPRIORITYBEGIN 7-9, 11-4 RESTRICTPRIORITYEND 7-9, 11-4 RESTRICTPRIORITYVALUE 7-9, 11-4 Retention time, item 11-5 RMTTSCHEDHOLD 7-16, 12-4 ROPENCTL 11-9, 12-2 ROPENCTL file 2-7, 2-12 ROPENCTLTIME 10-56 S SAMPLETIME 10-55 Scheduler See also Queue, SCHEDULER QUEUE SCAN screen, TSAMPLE, TSCHED
Index Server See also individual server names and SPREP program 6-24 and TRANSFER configurations 2-18/20 as agent 11-39 class 5-16 client 5-16 configuring for TMANAGER 10-55 customizing 7-4 in PATHWAY 7-5 logs permitted 12-1 naming conventions 5-14 output file messages B-41/56 outside PATHWAY 7-5 single-process 5-15 starting order 6-24, 11-11, 11-13, 11-14, 11-22, 11-26 startup error messages common error messages B-18/20 considerations 6-24 GFSERV error messages B-21 SMSERV error messages B-21 STBINIT err
Index SPREP See also Depot statistics facility and NAMESRV 6-24 and TEXTSRV 6-24 and XCOOL 6-24 defined 2-20, 6-24 error 6127 6-25 errors written to log 6-27 log 6-24, 6-26/27 must be configured 6-24 running 6-24/25 status, checking 12-1 stopping 9-22 TIMEWASRESET 6-25 uses A-STATS server class 2-20, 6-24 Start defined 1-8 example 6-22 files GIMCOOL 6-22 GMLCOOL 6-22 GTRCOOL 6-22 GX4COOL 6-22 functions 6-1 server order 6-24, 11-11, 11-13, 11-14, 11-22, 11-26 XCOOL program 6-1, 6-22/23 See also XCOOL Startu
Index STRINIT B-25 STWINIT B-25 Subsystem Control Facility (SCF) 11-20 Suffixes 6-29 SUT 4-1 SYS-ADMIN 2-22 SYSGEN 2-3 System administration See also ADMIN through TISERV System configuration requirements SYSGEN 2-3 terminal 2-4 TMF 2-4 X400 gateway 2-3 System control changing configuration 11-8 controlling priorities restricting priority window 11-4 setting package delivery parameters 11-3 using cleanup TAREQs 11-4 correspondent names 11-1 housekeeping 11-4 idle sessions 11-6 item retention time 11-5 movi
Index System monitoring files 2-11 network environment 11-20 PATHWAY environment 11-20 system performance 11-20 TMF environment 11-21 System name do not change 2-3, 11-8 must be unique 2-3, 11-8 System number do not change 2-3, 11-8 must be unique 2-3, 11-8 System recovery and maintenance TCHECK utility 11-26 TMF recovery 11-22 TSRBLD utility 11-24 XIINIT utility 11-22 System trigger 2-12, 5-10 T T9130CFG 6-13, C-5 TAREQ and package delivery 2-29 and TSCHED log 12-15 cleanup 10-13, 11-4 pseudo-terminal 2-1
Index TCHECK and depot statistics 11-29 and item statistics 11-29 and ITEMDESC recovery 2-16 and SPREP 11-29 and TSRBLD 11-26 cleaning out session file 2-17 commands 11-30 database inconsistencies, adjusting 10-14 described 11-26 directives 11-27 divisions 11-27 error messages B-57/65 examples 11-33 running 11-28 stopping servers to run 11-13 TCP as TRANSFER component 2-18 M3270 2-24 M6530 2-24 processes 5-16 TAREQ 2-18 TRAN 2-21 TDB-SERV 2-27, 3-7, 5-15 TDBSERV 7-22 TDBSERVERNAMES0 7-21 TDBSERVERNAMES1 7-
Index TEXTSRV and configuring TMANAGER 10-55 and NALOAD program 11-13 and TCHECK 11-26, 11-28 and XIINT program 11-22 ASSIGN parameter specified 7-10 description of 2-19 PARAM specifications 7-4 PS MAIL, defining for 2-25 TFRONT and TSCHED log 12-15 pseudo-terminal 2-18 TRECV servers, allocating 7-17 Time file (TIME) 2-6, 2-11, 9-5, 10-25, 11-24 TIME queue 10-10, 10-25, 10-29, 10-32 TIME0 file 2-6 Timestamp problem 6-25 TIMEWASRESET argument 6-22, 6-25 TIMEWASRESET PARAM 6-22, 6-25 TISER 10-55 TISERV admin
Index TMANAGER See also individual screen names accessing 2-1, 10-5 advice messages 10-4 Base TRANSFER, part of 2-1 configuration 2-21 configuring 10-55/56 DBSAMPL file, handling when full 10-57 definition and installation 6-4 described 10-1 errors 10-4 function keys 10-3 help, getting 10-4 installing 10-57 logging on 10-7 LOGON screen 10-6 MAIN MENU screen log functions 10-9 monitor functions 10-8 probe and trace functions 10-9 utility functions 10-9 managing 10-57 QSAMPLE file, handling when full 10-57 r
Index TMF and TWORK log 12-17 AUDIT parameters 2-16 audited files 2-15 configuring 2-4 monitoring 11-21 recovery 11-22 required 2-2, 2-3 TMFCOM 11-21 TRAFLOG file 2-7, 2-12 TRAN-TCP 2-21, 5-14 Transaction Monitoring Facility See TMF TRANSFER applications, developing 2-2 TRANSFER asynchronous requester See TAREQ TRANSFER delivery system administrator privileges 1-10 tasks 1-11/12 components 2-1/2 concepts 1-2/5 customizing 7-1 data files See Data files database 1-5, 2-5, 9-19 defined 1-1 manager 1-10 more t
Index TRECV and LOG CONTROL screen 10-27 and package delivery 2-29 and pseudo-terminal definitions 2-18 description of 2-19, 7-17/18 error messages B-41 network traffic information, writing 2-12 network traffic log 11-15 PARAM specifications 7-17, 7-18 troubleshooting 12-1, 12-19 TRGUARDIANUserID 6-32 Troubleshooting checking G-FILE server 12-7 checking TISERV 12-5 isolating node from network 12-31 mail not delivered 12-1/4 partitioning database files 12-9/12 poor interactive performance 12-5/8 TRECV log 1
Index TSCHED alarm notification 10-24 and LOG CONTROL screen 10-27 and package delivery 2-29 description of 2-19, 7-7/9 error messages B-42/56 exception to prefix rules 5-15 expired sessions, checking for 11-6 log 7-7 moving entries 10-14 PARAM specifications 7-4, 7-7/9 troubleshooting 12-15 TSRBLD and TCHECK 11-26 and TMF recovery 2-11, 2-16 and XIINT program 11-22 description of 11-24/25 queue files, rebuilding 10-14 TTY-G-FILE 2-26 TWORK and LOG CONTROL screen 10-27 and package delivery 2-29 and TRECV 2
Index User-DSV components 4-1 creating 4-1 default define files 5-1 defined 1-8 files 4-2 PS MAIL 3270 C-4 PS MAIL 6530 C-4 PS MAIL TTY C-5 TRANSFER C-1/3 warning 4-2 X400 gateway C-4 User-supplied ADMIN modules 11-36 agent configuration modules 11-35 agent deletion modules 11-35 profile 2-8 profile modules 11-36 system control modules 11-36 TMANAGER modules 11-36 V Vacation agent and asynchronous requester depot 6-32 supplied by Tandem 11-34 W WASTEBASKET 2-9, 6-29, 9-13, 11-6 Windows, minimum delivery an
Index X400 See also X400 gateway, X400 RECIPIENT screen, X400 GATEWAY ATTRIBUTES screen defined 3-1 depot and XIINT 11-22 configuring 6-33 folders 6-33 domain See ADMD See PRMD example of network 3-5 exporter log 12-23 foreign correspondent 3-5 importance value 10-41 importer log 12-26 logs 12-23/30 names ADMD 2-28, 3-10, 5-11 and TRANSFER names 3-10 conventions 11-2 country 3-10, 5-11 default values stored in Profile file 2-8 implications of changing 11-2 O/R 3-10, 10-51 organization 3-10 personal 3-10 PR
Index X400 gateway CDX4DEF 6-1 configuration 2-27/28 define file descriptions A-44/46 defined 3-1 definition and initialization 6-15/18 files 2-13 files for gateway node 2-13 GX4CNFG 6-21, 7-1 GX4COOL 6-22 GX4INIT 6-1 GX4STOP 6-34 installation example 6-16 node architecture 3-7 choosing 11-2 one per domain 3-5 recipient name field 10-49 relation to domain 2-28 special folders 3-9 _X400_ depot 3-9 requires initialization 6-3, 6-15 server classes 3-7 See also individual server names servers customizing 7-19/
Index X400-EXPORTER and queue file 2-13 customizing 7-19, 7-21 described 3-7 description of 2-27 X400-IMPORT 6-33 X400-IMPORT folder 3-9 X400-IMPORT-PROBLEM 6-33 X400-IMPORT-PROBLEM folder 3-9 X400-IMPORTER and queue file 2-13 customizing 7-20, 7-21 described 3-7 description of 2-27 X400-WMSERV 2-27, 3-7, 7-22 X400NAME file 2-13 X400QUEU file 2-13 X4ADMDName 11-2 X4ADMDName parameter 5-11 X4Country 11-2 X4Country parameter 5-11 X4DEFLTS 5-6, 5-11, A-44/46 X4PRMDName 11-2 X4PRMDName parameter 5-11 XCNFG 6-1
Index Special characters $T 5-15 $TRPM 2-22, 5-15 $TSCH 5-15 $Z4T0 through $Z4T9 5-15 $ZC 5-15 $ZT 5-15 $ZX 5-15 _TRANSFER_ 2-22, 6-32, 11-22 _X400_ 3-9, 6-33, 11-22 068837 Tandem Computers Incorporated Index–41
