#### ABI JCL

REQUIREMENTS

##### JANUARY 2000

# Table of Contents

Establishing a Communication
Session.................................................... 3

Logon
Statement..............................................................................
4

Basic Job Control
Language.................................................................
4

JOB Statement (Record 1)
......................................................... 5

JOB Statement (Record 2)
......................................................... 6

EXECUTE
Statement...............................................................
7

Data Definition (DD)
Statement................................................... 7

ABI Data
Records....................................................................
8

End of Date (/\*) Statement
...................................................\... 8

Logoff
Statement..............................................................................
8

Sysout
Classes.................................................................................
8

Controlling Sysout
Queues...................................................................
9

Logging On Only to Pick Up
Output........................................................ 10

Automatic Printer or Punch
Restart......................................................... 10

Data Center
Interface..........................................................................
11

**Establishing a Communication Session**

Communications between the ABI user and the Customs host computer is
accomplished via JES2 Remote Job Entry (RJE). RJE requires strict
adherence to 377x Synchronous Data Link Control (SDLC) protocols.
Customs strongly recommends the use of an "off-the-shelf" RJE emulator
software package. There are many commercially available RJE emulators; a
list of known ABI software vendors is available from your ACS Client
Representative. Users wishing to write their own communications software
*must* consult IBM manual GA27-3145:COMPONENT DESCRIPTION FOR THE 3776
AND 3777 COMMUNICATION TERMINALS and strictly follow data formats and
protocols outlined to ensure successful communication with the Customs
Data Center.

After a request for a new ABI connection is made through the user's
client representative, a technical support representative from the Data
Center may contact the user point-of-contact to ensure parameters
specified on the Customs computer (for example buffer size) match
specifications on the user's system. If the user is using a
pre-configured system from an ABI software vendor or the user has
previously established an RJE connection he wishes to copy, Data Center
personnel will use a "look alike" remote specification to create the new
remote definition.

The communications parameters required by the U.S. Customs Service Data
Center for ALL clients' SDLC/377x RJE packages are:

## STATION ADDRESS: = 01

This may also be referred to as the "cluster address", "poll address",
"PU address", ...

## NRZI: = No

This may be identified at "NRZ = Yes"

## COMPRESSION: = Yes

Compression must be "On" whether the client's package has this setting
by default or as a codable option.

There are other communication parameters which are unique for each RJE
site and which must be set up in the client's software package. The most
important of these is:

## EXCHANGE ID (XID): = nnn,xxxxx

This may also be referred to as the "station block id" and is actually
two parameters combined.

The first parameter (nnn) is a three-digit field known as the "id block
(idblk)". The "idblk" describes the device type of the client's RJE
system. This parameter must be verified with Customs Data Center
communications personnel. (For an IBM System/36, the idblk = 03e. For an
IBM AS/400, the idblk = 056. For most other systems, the idblk = 017.)

The second parameter is a five digit field known as the "id number
(idnum)". The "idnum" must be UNIQUE FOR EACH CLIENT RJE SITE. It is
assigned by Customs communications personnel when the client's RJE
definition is created within the Customs HOST at the request of the
client representative. The client representative will convey the "idnum"
information to the client.

**Logon Statement**

To initiate a communications session with the Customs Data Center, the
LOGON statement is required. The LOGON statement is set up in a client's
RJE communications software. The LOGON statement must be formatted as
follows:

**LOGON APPLID(JES2AS1) DATA(RMTnnnn,,password)**

The number "nnnn" is the SDLC remote number, and "password" is the
eight-digit password. Both are assigned to the client's RJE by the
Customs Data Center and will be conveyed to the client by their assigned
ACS client representative. Note the mandatory TWO commas separating the
remote number and the password.

**Basic Job Control Language**

The following is the basic set of Job Control Language (JCL) needed for
a remote to submit an Automated Broker Interface (ABI) job to U.S.
Customs HOST computer using Customs 377x SDLC protocol. Customs uses the
file/record nomenclature to distinguish the different segments of the
JCL. Space fill all positions not identified as containing data.

**JOB Statement (Record 1)**

+------------+-----------------+---------------------------------------+
| **FILE 1,  |                 |                                       |
| RECORD 1** |                 |                                       |
+------------+-----------------+---------------------------------------+
| ######     | **Contents**    | **Name/Description**                  |
|  Positions |                 |                                       |
+------------+-----------------+---------------------------------------+
| 1‑2        | //              | Literal. Identifies this record as    |
|            |                 | JCL.                                  |
+------------+-----------------+---------------------------------------+
| 3‑10       | ABIRnnnn        | Job Name. ABIRnnnn identifies the     |
|            |                 | job. The 'nnnn' must be the same      |
|            |                 | remote number as used in the logon    |
|            |                 | procedure. It is the RJE remote used  |
|            |                 | to transmit the job. Use positions 7  |
|            |                 | through 9 for three digit remote      |
|            |                 | numbers leaving position 10 of the    |
|            |                 | record blank. Use positions 7 and 8   |
|            |                 | if the remote number is only two      |
|            |                 | digits long.                          |
+------------+-----------------+---------------------------------------+
| 12‑14      | JOB             | Literal. Identifies this record as    |
|            |                 | the JOB Statement.                    |
+------------+-----------------+---------------------------------------+
| 16‑27      | (1801,2413),    | Job Accounting Information. May       |
|            |                 | change in the future. Previous        |
|            |                 | accounting identifier (1801, 4221) is |
|            |                 | still acceptable. The character in    |
|            |                 | column 19 is a zero.                  |
+------------+-----------------+---------------------------------------+
| 28‑34      | BROKER,         | Literal. All clients including        |
|            |                 | importers, service bureaus, etc.      |
|            |                 | should use this literal.              |
+------------+-----------------+---------------------------------------+
| 35-42      | CLASS=Z,        | Job Class. The job class that the job |
|            |                 | will run in.                          |
+------------+-----------------+---------------------------------------+
| 43-57      | MSGLEVEL=(1,1), | Message Level. Sets the amount of     |
|            |                 | reporting that JES will return to the |
|            |                 | RJE station. Note the dangling comma  |
|            |                 | after this parameter that shows that  |
|            |                 | the JOB statement is continued on the |
|            |                 | next record.                          |
+------------+-----------------+---------------------------------------+

**JOB Statement (Record 2)**

+------------+-----------------+---------------------------------------+
| **FILE 1,  |                 |                                       |
| RECORD 2** |                 |                                       |
+------------+-----------------+---------------------------------------+
| **P        | **Contents**    | **Name/Description**                  |
| ositions** |                 |                                       |
+------------+-----------------+---------------------------------------+
| 1‑2        | //              | Literal. Identifies this record as    |
|            |                 | JCL to MVS.                           |
+------------+-----------------+---------------------------------------+
| 15‑25      | MSGCLASS=D,     | Message Class. This JCL results of    |
|            |                 | submitting this job will go to this   |
|            | MSGCLASS=0,     | sysout class. These are *not* the ABI |
|            |                 | data processing results for entry     |
|            | MSGCLASS=1,     | summaries, cargo releases, etc.       |
|            |                 |                                       |
|            | (use only one   | MSGCLASS=D suppresses returning       |
|            | of the above    | almost all the JCL results messages   |
|            | parameters, see | if the job successfully executes.     |
|            | the             | **MSGCLASS=D will return JCL results  |
|            | instructions)   | only when a problem occurs, and is    |
|            |                 | therefore the recommended             |
|            |                 | selection.** There is no known reason |
|            |                 | to use 0 or 1 except for trouble      |
|            |                 | shooting.                             |
|            |                 |                                       |
|            |                 | Use MSGCLASS=0 (zero) to have JCL     |
|            |                 | results returned if using PRINT       |
|            |                 | format.                               |
|            |                 |                                       |
|            |                 | Use MSGCLASS=1 (one) to have JCL      |
|            |                 | results returned if using PUNCH       |
|            |                 | format.                               |
+------------+-----------------+---------------------------------------+
| 26‑35      | USER=Rnnnn      | The user (remote number) of the RJE.  |
|            |                 | The 'nnnn' is the remote number       |
|            |                 | assigned to your remote (no leading   |
|            |                 | zeroes). Three digit remotes leave    |
|            |                 | position 35 (the last character)      |
|            |                 | blank. Two digit remotes leave        |
|            |                 | positions 34 and 35 (the last two     |
|            |                 | characters) blank.                    |
+------------+-----------------+---------------------------------------+

**EXECUTE Statement**

  --------------- ----------------- ----------------------------------------
  **FILE 1,                         
  RECORD 3**                        

  **Positions**   **Contents**      **Name/Description**

  1‑2             //                Literal. Identifies this record as JCL.

  3‑7             STEP1             Step Name. STEP1 is the name of this
                                    step within the execution of the job.

  10‑13           EXEC              Literal. Identifies this as an EXECute
                                    statement.

  16‑22           ABIPR02           PROC Name. Identifies the PROCedure that
                                    this job will execute.
  --------------- ----------------- ----------------------------------------

**Data Definition (DD) Statement**

  --------------- ----------------- ----------------------------------------
  **FILE 1,                         
  RECORD 4**                        

  **Positions**   **Contents**      **Name/Description**

  1‑16            //                Literal. Identifies this as the SYSUT1
                                    dataset defined within the ABIST01 step
                                    of the PROC. The character in column 8
                                    is a zero.

  19‑22           DD                Literal. Identifies this record as a DD
                                    (Data Definition) statement.

  22              \*                Literal. The asterisk in this context
                                    indicates that data immediately follows
                                    this statement.
  --------------- ----------------- ----------------------------------------

# ABI Data Records

  --------------- ----------------- ----------------------------------------
  **FILE 1,                         
  RECORD 5**                        

  **Positions**   **Contents**      **Name/Description**

  1‑80            ABI Data          Put the control and data records for ABI
                                    here (e.g., A, B, Y, Z records, etc.).
                                    Refer to the CATAIR (Customs and Trade
                                    Automated Interface Requirements) for
                                    the format of these records.
  --------------- ----------------- ----------------------------------------

**End of Data (/\*) Statement**

  --------------- ----------------- ----------------------------------------
  **FILE 1, LAST                    
  RECORD**                          

  **Positions**   **Contents**      **Name/Description**

  1‑5             /\*EOF            Literal. Identifies the end of the
                                    dataset defined by the previous DD
                                    statement. This does not change. This
                                    must be the last record in this file.
  --------------- ----------------- ----------------------------------------

**Logoff Statement**

Customs 377xSDLC protocol may use any of a variety of procedures to
disconnect called "logging off". These procedures are not discussed in
detail because they are normally unique to the client's SDLC
communications software. An unformatted "LOGOFF" command may alternately
be used to terminate the communications session.

### Sysout Classes

Customs 377xSDLC protocol support multiple sysout classes. This allows
Customs to segregate data to help users selectivity receive ABI output.

The default sysout class is 0 (zero). This is standard 377x PRINT format
(132 possible characters per line). An option in the system allows a
client to retrieve data in PUNCH format (80 characters per line limit).
PUNCH formatted output is returned in sysout class 1 (one). Since all
ABI output uses only 80 characters per line, the PUNCH output option may
allow the most efficient data retrieval. Any client wishing to use PUNCH
format must inform their client representative.

Liquidation notices and Notices of Extension/Suspension can be
segregated from the rest of the print or punch output. The client
representative must update the Customs ABI profile records to provide
this capability. Such notices will then be returned in sysout class P if
print format is used or sysout class K if punch format is used. All
other output will be returned in either sysout class 0 (zero) for print
or sysout class 1 (one) for punch.

### Controlling Sysout Queues

The system standard default is for Customs to automatically send all
data in all sysout queues when a client logs on to the Customs system.
Users can control the sysout classes they receive by making the
following changes to the JCL (also referred to as "Selective
Retrieval"). This technique *must* be used if a client has been set up
to retrieve liquidations in a separate sysout class (coordinate with
your client representative). The technique is also useful if a client
wants to send data to Customs before receiving output; though Customs
377xSDLC protocol does permit sending and receiving data simultaneously
(full duplex).

Example commands notes in this section assume that a print device is
being used to receive data. If a punch device is used, substitute PU for
PR in all examples.

The client must instruct the Customs computer system to "unset" the
sysout class whenever they do *not* want output sent. Use the following
command to do this.

/\*\$TPR1,Q=X Sets the sysout class to X. This effectively 'unsets' the
last specified sysout class. Automatic sending of output data will not
occur until the sysout class is reset as detailed below.

The client will use the following two commands whenever they want the
Customs computer system to send data. The client must be logged on. Do
*not* send these commands in the middle of a 'file' (e.g., file 1). The
two commands are most often sent together.

/\*\$TPRI,Q=0 Specify the sysout class in position 11. '0' (zero) or 'P'
(liquidations) for print, '1' (one) or 'K' (liquidations) for punch.
This command sets the Customs spooler to prepare to send data in the
sysout queue specified after the Q =. Data transmission may not begin
until after the next command (start) is sent.

/\*\$SPR1 Starts the printer to receive data for the specified class.
The client will start receiving data from the sysout queue specified by
the TPR1 command.

At this point the system will send the data for the sysout class
specified above. After receiving the data, send any new input data to
Customs (e.g., file 1) or logoff.

Use of this modified JCL must be coordinated with the client
representative. Failure to do so may cause unpredictable receipt of
unwanted output when logged on to the Customs system, especially if the
system "goes down" between the last logoff and the current logon.

### Logging On Only to Pick Up Output

The client may want to log on to the Customs computer *only* to pick up
output. This can be done in one of two ways, depending on whether or not
the client is controlling sysout queues as discussed in the previous
section.

If controlling sysout queues, the client will log on, send the commands
to set and start the printer (instead of file 1), and then log off. If
not controlling sysout queues, the client can simply log on and wait
(without sending file 1). The Customs HOST will send output (if any
exists) soon after the client logs on. The client can then log off with
sending file 1.

### Automatic Printer or Punch Restart

One important feature of SDLC RJE is that the host system will set a
printer or punch device to a *drained* status whenever the host has data
to transmit to the remote device, but the device is not ready to
receive. This often occurs immediately after a remote has completed
logging on to the system, but has not yet enabled the print or punch
logical unit (LU) to receive data. When a printer or punch is drained,
the host system will not attempt to send any data to the device until it
is manually restarted. A start command (as discussed under *Controlling
Sysout Queues*) must be issued to restart the drained device (namely
/\*\$SPR1 or /\*\$SPU1).

To automatically restart a drained device, Customs recommends users send
a start command immediately after the printer or punch LU has been
enabled to receive data. Note that a start command issued against an
active printer or punch will have no effect.

### Data Center Interface

There are various times when a client makes a request of a client
representative that requires that involvement of the Customs Data
Center. Depending on the circumstances, the client representative may
handle all contact with the Data Center, or may ask the Data Center
personnel to communicate directly with the client.

The client representative must inform the Data Center if a client wants
to use the PUNCH output option. The Data Center will then modify the
profile for that remote to use the PUNCH format.

The client representative should inform the Data Center if a client
wants to control sysout queues. The Data Center will configure the
client's remote to require the start printer command (/\*\$SPR1) before
the Customs HOST will send data to the client's RJE. This configuration
is commonly known as 'draining' the printer. If this is not done, the
HOST may send data to the client's RJE before the client has an
opportunity to set the sysout class.