TABLE OF CONTENTS

The Purpose Of This Document

1.0 Overview

2.0 Specifications Of The DFT Interface

• 2.1 The Dataset for Outgoing Transactions
• 2.2 The Datasets for Incoming Files
• 2.2.1 The Incoming Transactions Dataset
• 2.2.2 The Invalid Transactions Dataset
• 2.2.3 The Validation Reports Dataset
• 2.2.4 The Interface Reports Dataset
• 2.2.5 The Interface Logs Dataset
• 2.2.6 Archiving and Emptying Datasets
• 2.3 Transaction Record Lengths

3.0 DFT Parameters

• 3.1 Guidelines for Logon Using FTP
• 3.1.1 Parameters in Logon Using FTP
• 3.1.2 Examples for Logon Using FTP
• 3.2 Guidelines for Logon Using TN3270 Emulation
• 3.2.1 The Standard 3270 Emulation Login Process
• 3.2.2 Parameters in Logon Using TN3270 Emulation
• 3.2.3 Examples for Logon Using TN3270 Emulation
• 3.3 Guidelines for Data Set Names
• 3.3.1 Examples for Data Set Names
• 3.4 Testing the DFT Interface
• 3.5 Becoming DFT-Ready

The Purpose Of This Document

This document is provided in response to a request from States at the May 1999 Administration for Children and Families (ACF) Users Group Conference for guidance on system logon parameters and dataset naming conventions. This document provides guidance on the naming conventions of datasets that will be utilized on the State Child Support Enforcement System (CSES) for the CSENet Direct File Transfer (DFT) initiative. This document includes specifications on the file transfer process between the CSENet host and the State CSES. Also provided is guidance for completing the "CSE System Logon Parameters" and "Dataset Names" sections of the State Profile that will be forwarded at a later date. The State Profile is the vehicle for States to provide the CSENet team with the necessary information to successfully implement DFT. The State Profile reflects all information the CSENet team has been provided by the State.

Table of Contents

1.0 Overview

The purpose of CSENet is to automate the transmission of interstate child support transactions between State CSE systems. This automation occurs through a combination of hardware, software, and communication lines.

CSENet currently consists of:

• a central network server, referred to as the CSENet host;
• one CSENet computer, or workstation, in each State, Puerto Rico, Guam, and the Virgin Islands;
• AT&T FTS2000 phone lines connecting each CSENet computer to the CSENet host;
• software on the CSENet host and workstation.

To become a fully automated CSE system using CSENet, a State connects its CSENet workstation to its CSE network, and uses this connection to transmit interstate child support transaction files to and from the workstation. This file transfer process is referred to as the CSENet "interface". The transactions in files sent to the workstation are checked for accuracy against the transaction format described in the CSENet Interface Guidance Document (IGD), Release 3.1.

The exchange of transactions via CSENet in fully automated CSE systems is as follows. A transaction file is sent from a CSE system to the State’s CSENet workstation via the State’s interface. The transactions in this file are checked for accuracy by workstation software, and valid transactions are forwarded to the CSENet host. The CSENet host routes the transactions to the receiving States’ CSENet workstations. Transactions are then transmitted from the workstations to the receiving States’ CSE systems via each State’s interface.

In order to take advantage of new technologies and meet Year 2000 (Y2K) compliance, the existing CSENet will be replaced in August 1999 with CSENet DFT. The new method of exchanging transactions via CSENet DFT will be as follows. A transaction file will be picked up from a CSE system by the CSENet host. The transactions in this file will be checked for accuracy by host software. Invalid transactions will be returned to the sending CSE system, and valid transactions will be sent to the receiving States’ CSE systems.

A detailed description of the new CSENet DFT interface is provided in this document.

Section 2.0 outlines the specifications of the CSENet DFT interface.

Section 3.0 lists the information needed from a State for the DFT interface.

Section 4.0 describes how to test the DFT interface in a State.

All CSENet files transferred via the DFT interface require a designated location on the CSE system in which to be placed. On IBM mainframes, files are referred to as "data sets" or "datasets". On other types of mainframes, these files are referred to as "directory location and filename". Because CSENet files will be located on an IBM mainframe on most CSE systems, CSENet files on CSE systems will be referred to as "datasets" in this document.

The process of setting the parameters of a dataset, such as the maximum record length and permission to read and write to it, is known as "allocating" the dataset. On operating systems using regular files rather than datasets, files are not allocated, but certain permissions are necessary in order to read and write to a file. In this document, allocating a dataset means setting up all permissions and parameters necessary in order for the CSENet host to be able to read and write to the dataset.

Table of Contents

2.0 Specifications Of The DFT Interface

To use the full functionality of the DFT interface, six datasets need to be allocated on each CSE system. Sections 2.1 through 2.3 describe how the DFT interface will read from and write to these datasets.

There is no plan for the DFT interface to send any files to CSE systems other than those described in this section. Every attempt has been made to provide at least as much information to a State as is provided by an existing CSENet-workstation-to-State-CSE-system interface.

The following steps provide brief description of how the CSENet host will transmit files to and from CSE systems using the DFT Interface. This is included to provide State engineers a complete picture of how the interface will interact with the CSE system’s datasets.

1. Retrieve the Outgoing Transactions dataset.

2. Append any incoming transactions to the Incoming Transactions dataset.

3. Append any invalid transactions to the Invalid Transactions dataset.

4. Append any validation reports to the Validation Reports dataset.

5. Empty the Outgoing Transactions dataset by uploading an empty file into it.

6. Append the Interface Report to the Interface Reports dataset.

7. Append the Interface Log to the Interface Logs dataset.

Table of Contents

2.1 The Dataset for Outgoing Transactions

A dataset is needed on the CSE system for all outgoing transactions. Outgoing transactions are those to be sent to other States. To be successfully forwarded to other States by the CSENet host, transactions in this dataset need to be in the format described in the CSENet Data Block Layouts for Direct File Transfer (DFT), dated May 14, 1999.

After downloading the Outgoing Transactions dataset, the CSENet host will upload an empty file into it to prevent receiving duplicate transactions from the State.

It is recommended that the CSE system append new transactions to the Outgoing Transactions dataset. Appending is recommended because this will allow for the CSENet host to pick up multiple days of transactions from the CSE system if previous transaction file transfers failed.

Table of Contents

2.2 The Datasets for Incoming Files

The DFT interface attempts to upload five files to the CSE system. In order for these files to be successfully uploaded, a dataset needs to be allocated for each file. If a dataset has not been allocated but the CSENet host has the permission to create it, the host will write a file to the dataset thereby creating it. Because the dataset was not allocated, though, the default system parameters will be used for the dataset rather than parameters specific to the dataset.

If your State prefers not to receive any of these files, do not allocate the dataset, or give permission to the CSENet host to create it, and it will not be uploaded.

The DFT interface will attempt to upload files into five datasets:

1. Incoming Transactions dataset
2. Invalid Transactions dataset
3. Validation Reports dataset
4. Interface Reports dataset
5. Interface Logs dataset.

The DFT interface will append new data to the datasets described in this section. Appending ensures that the CSENet host will never overwrite the data in a dataset before the CSE system is able to process it.

Note that the datasets for the Interface Reports and Validation Reports can contain multiple reports because the DFT interface appends to them. In order to process these datasets, a method for recognizing multiple reports is necessary.

Sections 2.2.1 through 2.2.5 describe how the CSENet host writes to the datasets for incoming files. Section 2.2.6 addresses the archiving and emptying of these datasets.

Table of Contents

2.2.1 The Incoming Transactions Dataset

The Incoming Transactions dataset will contain all CSENet transactions from other States. Transactions placed in this dataset by the CSENet host will be in the format described in the CSENet Data Block Layouts for Direct File Transfer, dated May 14, 1999.

Table of Contents

2.2.2 The Invalid Transactions Dataset

The Invalid Transactions dataset will contain formatted lists of transactions from your State in which errors were found by the CSENet host. The format for the Invalid Transactions Report can be found in the CSENet Data Block Layouts for Direct File Transfer, dated May 14, 1999.

Table of Contents

2.2.3 The Validation Reports Dataset

The Validation Reports dataset will contain Validation Reports consisting of formatted information about the number of transactions from your State checked for errors by the CSENet host.

The following is an example of a Validation Report that can be uploaded to a CSE system:

VALIDATION REPORT

Created: Jun 15 14:00

For File Received: Jun 15 13:57

file_byte_size=8825

#validated_transactions=900

#errored_transactions=5

#errors_found=8

Table of Contents

2.2.4 The Interface Reports Dataset

The Interface Reports dataset will contain Interface Reports consisting of formatted information about CSENet files transferred by the DFT interface.

The following is an example of a DFT Interface Report that can be uploaded to a CSE system:

CSENET INTERFACE REPORT

Monday, June 24, 1999 at 15:56:07

#transactions_from_State=1555

#bytes_in_transactions_from_State=2019400

#transactions_to_State=1605

#bytes_in_transactions_to_State=1904888

#errors_in_error_file_to_State=55

#bytes_in_error_file_to_State=6550

#bytes_in_validation_report_to_State=184

Table of Contents

2.2.5 The Interface Logs Dataset

The Interface Logs dataset will contain Interface Logs consisting of unformatted, detailed output from the interface file transfers that is useful for interface debugging.

Table of Contents

2.2.6 Archiving and Emptying Datasets

Because the datasets described in this section are appended to rather than overwritten, these datasets will eventually grow large unless they are emptied. It is recommended that State CSE systems should archive, or back up these datasets on a regular basis, usually once a day, and then empty them. The archiving and emptying of these datasets will usually occur directly before they are processed by the CSE system batch jobs. Many State CSE systems currently archive between 3 and 30 days of CSENet datasets.

Table of Contents

2.3 Transaction Record Lengths

For the datasets described in Sections 2.1 and 2.2, the State needs to allow for variable record lengths. Currently, individual transactions can range from 127 bytes to a maximum of 8481 bytes. The maximum transaction length will increase in the near future as more data fields and blocks are added. Transaction files can contain an unlimited number of transactions.

Table of Contents

3.0 DFT Parameters

Certain interface parameters are unique to each State, such as dataset names and logon variables. These parameters are defined by your State and must be programmed in the CSENet host to affect interstate communications. Your CSENet State Technical Representative is collecting this information. A summary of the information provided by your State will be forwarded to you under separate cover for review and verification.

Section 3.1 provides guidelines for completing the "Logon Using FTP" section of the State Profile. This section applies only to States in which the method of logging in to the CSE system with the DFT interface will be File Transfer Protocol (FTP).

Section 3.2 provides guidelines for completing the "Logon Using TN3270 Emulation" section of the State Profile. This section applies only to States in which the method of logging in to the CSE system with the DFT interface will be TN3270 emulation.

Section 3.3 provides guidelines for completing the "Data Set Names" section of the State Profile.

Section 3.4 provides guidelines for testing the DFT interface.

Section 3.5 outlines the steps necessary for a State to become DFT-ready.

Table of Contents

3.1 Guidelines for Logon Using FTP

This section provides guidance in defining the parameters in the "Logon Using FTP" section of the State Profile. This section needs to be completed by States in which the method for logging in to the CSE system with the DFT interface will be FTP.

Section 4.1.1 describes the parameters in the "Logon Using FTP" section, and section 4.1.2 provides examples of how the parameters should be defined.

Table of Contents

3.1.1 Parameters in Logon Using FTP

In the "Logon Using FTP" section of the State Profile:

• "User-ID" is the user-ID, or name, the CSENet host will use to log in to the CSE system for the DFT interface.
• "Password" is the password the CSENet host will use to log in to the CSE system for the DFT interface.
• "FTP Actions" are any actions required during the DFT Interface FTP in your State. For example, when an FTP to a CSE system IBM mainframe is performed, dataset names used in sending and receiving files are usually incorrectly prefixed with the log-in user-ID, unless it is stripped off with a "cdup" command.

Table of Contents

3.1.2 Examples for Logon Using FTP

The information below provides an example of how a State should define the parameters in the "Logon Using FTP" section of the State Profile.

User-ID cse1net99

Password wel5come9

FTP Actions cdup99

Table of Contents

3.2 Guidelines for Logon Using TN3270 Emulation

This section provides guidance in defining the parameters in the "Logon Using TN3270 Emulation" section of the State Profile. This section needs to be reviewed by States in which the method for logging in to the CSE system with the DFT interface will be TN3270 emulation.

Section 3.2.1 describes the standard 3270 emulation login process which should aid in understanding how the parameters in the "Logon Using TN3270 Emulation" section will be used.

Section 3.2.2 describes the parameters in the "Logon Using TN3270 Emulation" section.

Section 3.2.3 provides examples of how parameters in the "Logon Using TN3270 Emulation" section should be defined.

Table of Contents

3.2.1 The Standard 3270 Emulation Login Process

The process for a TN3270 login to the CSE system mainframe from the CSENet host will be the same as, or similar to, logging in to the CSE system mainframe from a PC with a network connection to the mainframe. Though the TN3270 login process is unique to each CSE system, there are similarities in the process between CSE systems. The standard process of logging in to a CSE system mainframe using 3270 emulation login is described below.

The Standard 3270 Emulation Login Process:

1. First, a login screen with a particular prompt is seen and then one or more keys are entered at the prompt. This brings up the second screen and prompt.
2. At the second screen and prompt, usually for a user-ID, the appropriate keys are entered. This brings up the third screen and prompt.
3. At the third screen and prompt, usually for a password, the appropriate keys are entered. This brings up the fourth screen and prompt.
4. At the fourth screen and prompt, usually the word "Ready", the appropriate key(s) are entered, usually an "Enter" key. This brings up the fifth screen.
5. The fifth screen is usually a group of asterisks "***" indicating that the user is successfully logged in to the CSE system, and the system is ready for commands such as file transfers.

Table of Contents

3.2.2 Parameters in Logon Using TN3270 Emulation

In the "Logon Using TN3270 Emulation" section of the State Profile:

• "SNA_Prompt" parameters are the prompts on the screens the CSENet host will see when logging in to the CSE system mainframe using TN3270 emulation.
• "SNA_Keys" parameters are the keys the CSENet host should enter at each SNA_Prompt.

Table of Contents

3.2.3 Examples for Logon Using TN3270 Emulation

The information below provides an example of how a State could define the parameters in the "Logon Using TN3270 Emulation" section of the State Profile. On your State Profile, define only the number of SNA_Prompt and SNA_Key parameters required for the CSENet host to log in to your CSE system. The number of these parameters required for your State could be more or less than the example below illustrates.

For these parameters, an "Enter" key is represented as an "@E".

SNA_Prompt_1: ACTIVE WAITING FOR LOGON9

SNA_Keys_1: LOGON TSOA@E999

SNA_Prompt_2: ENTER USERID ---999

SNA_Keys_2: cse1net@E9999

SNA_Prompt_3: PASSWORD ===>999

SNA_Keys_3: wel5come@E9999

SNA_Prompt_4: ***99999

SNA_Keys_4: @E99999

SNA_Prompt_5: READY9999

Table of Contents

3.3 Guidelines for Data Set Names

This section provides guidelines for completing the "Data Set Names" section of the State Profile. Since Section 2 of this document describes the datasets in the "Data Set Names" section, no further explanation of these datasets will be provided here.

When providing dataset names, use the dataset, or file, naming conventions required by your CSE system.

If your State requests that different datasets be used for testing your State’s interface, please provide test datasets.

Section 3.3.1 provides examples of how datasets in the "Data Set Names" section should be defined.

Table of Contents

3.3.1 Examples for Data Set Names

The information below provides an example of how a State should define the parameters in the "Data Set Names" section of a State Profile.

Outgoing Transactions Dataset Name: PROD.CSENET.ASYS.SEND9

Incoming Transactions Dataset Name: PROD.CSENET.ASYS.RECV9

Incoming Invalid Transactions Dataset Name: PROD.CSENET.ASYS.ERRORS9

Incoming Validation Reports Dataset Name: PROD.CSENET.ASYS.VALID9

Incoming Interface Reports Dataset Name: PROD.CSENET.ASYS.REPORT9

Incoming Interface Logs Dataset Name: PROD.CSENET.ASYS.LOG99

Table of Contents

3.4 Testing the DFT Interface

This section provides guidance for testing the DFT interface in your State. It is recommended that the Interface Test below be performed to validate the interface parameters provided in the State Profile for your State.

The Interface Test:

1. Log in to your CSE system using the parameters defined in your State Profile under "Logon Using FTP" or "Logon Using TN3270 Emulation".
2. Pick up/receive a file from the Outgoing Transactions dataset.
3. Append a file to the five Incoming datasets.
4. Send an empty file into the Outgoing Transactions dataset.

The files you use for the Interface Test can contain any type of data, though it is recommended you use files with multiple large records. The purpose of testing here is only to confirm the ability of the CSENet host to log in to your CSE system and to read and write to your State’s DFT datasets.

Please ensure that the data received in your CSE system’s CSENet datasets from the Interface Test above appears as it needs to on your CSE system. In particular, make sure the correct record lengths are set for the records in the datasets.

Soon after your CSENet State Technical Representative receives the State Profile, the interface to your State will be fully tested again by the CSENet host.

Table of Contents

3.5 Becoming DFT-Ready

Your State will be fully ready for CSENet DFT when the following steps are completed:

• the CSENet communication lines are set up to your CSE network;
• the CSENet DFT router is configured in your CSE network;
• the interface to your State has been fully tested;
• your State programming is completed to meet the CSENet transactions format in the DFT Record Layout document;
• all required programming has been completed on the new CSENet host; and
• transactions received on the CSENet host from your State have been validated for accuracy by the CSENet host software and/or transactions sent by the CSENet host to your State have been successfully processed by your CSE system.