2015-2016 FASTER FIRN2 Data File Transfer

FLORIDA AUTOMATED SYSTEM FOR TRANSFERRING EDUCATIONAL RECORDS
FLORIDA DEPARTMENT OF EDUCATION
OFFICE OF APPLICATION DEVELOPMENT AND SUPPORT (OADS)

Effective: August 1, 2015
Revised: July 1, 2016

Use of File Transfer Program

This appendix discusses SNA file transfer methods. See Chapter 10 for a discussion of TCP/IP file transfer.

File Transfer Program, FTP, is a general purpose VTAM application that can be used to transmit fixed or variable length files between any two SNA connected IBM MVS or non-MVS sites. The only prerequisites are that VTAM is active and that FTP has been started at both the sending and the receiving sites.

FTP can be used to transmit many types of files, including VSAM ESDS (VSE, MVS), VSAM KSDS (VSE, MVS), with insert, replace, or delete options, SAM tape files (VSE), and QSAM files (MVS). Other dataset types can be transformed into one of the above arrangements of data, and then transmitted using FTP. Further, FTP supplies a dataset-handler-user-exit which provides support for file organizations not directly supported by FTP. FTP provides flexibility among the dataset types by allowing for dynamic allocation at both the sending and receiving locations. The blocksize of the dataset received may be different from that of the dataset sent. Likewise, data may be transmitted from or to different types of storage.

FTP is designed to give high performance by transferring datasets from the sending to receiving volumes without intermediate spooling, and by compressing data records, thereby reducing the amount of data sent. Also FTP incorporates a recovery feature which negates the need to retransmit an entire file should the communication link fail.

As users of the FASTER system, you will encounter one or both types of FTP: IBM's NetView File Transfer Program for MVS, Version 2 (NetView FTP MVS V2, which runs at NWRDC), or
IBM's File Transfer Program version 2, release 2 (FTP V2) generally executed locally by user institutions.

Use of NetView File Transfer Program

NetView FTP MVS V2 is an application program that uses the rules of IBM's System Network Architecture (SNA) to send and receive datasets. For MVS nodes it is the successor of IBM's File Transfer Program Version 2 Release 2 (FTP V2.2). Version 2 integrates all functions of the Advanced Function Feature (AFF). NWRDC operates NetView FTP MVS V2.

NetView FTP MVS nodes can transfer to and from other nodes running NetView FTP MVS AFF, or NetView FTP MVS, or FTP V2.2 with the compatibility PTF(s) installed (contact your IBM Support Center for information regarding the PTF(s) applicable to your operating system). The level of communication can only be on the level of the less sophisticated of the two transfer programs. This means that only functions available to the less sophisticated of the two programs may be utilized.

In NetView FTP MVS the submission of a file transfer request is a process that is separate and independent of the actual processing of the file transfer. The segment which handles the file transfer request (the queue handler) must be started before any other NetView FTP MVS component can work. The component that transfers the file (a server) works independently of the queue handler.

NetView FTP MVS functions as follows:

A user, batch job or application program submits a file transfer request to the queue handler. The queue handler puts the request onto a queue with a status of waiting.
An active server issues an OBTAIN command to the queue handler, who selects a file transfer request and passes it to the server.
The local server attempts to start a VTAM session with an active server at the remote node that was specified in the request. The local and the remote servers then determine which is the sending server and which is the receiving server. If requested, security information is checked and required datasets are dynamically allocated.
The sending server then opens the dataset to be sent.
If requested, the receiving server establishes security and, if required, dynamically allocates required datasets.
The receiving server opens the receiving dataset.
The local server updates the request queue status to active.
The sending server reads records from the input dataset (or from the data-set-handler-module, if appropriate), compresses the data in the manner requested, and packs it into data request units (RU's). When the request unit is full, the sending server passes it to VTAM, which directs its transport to the receiving server.
The receiving server decompresses the data back to its original form, writes the data to the output dataset (or requests your dataset-handler-routine to handle the data) and updates the checkpoint/restart dataset.
Steps 8 and 9 are repeated until end of file is reached on the input dataset.
When the transfer of data is complete, the sending server closes the input dataset and the receiving server closes the output dataset. Both servers deallocate their datasets, and write out summary information. One of the servers terminates the VTAM session.
The local server updates the queue request status to finished. The local server may now issue another OBTAIN queue handler command.

Note that of the above steps, only the first is performed by the user. The rest are automatic functions of the machine in which the user is running. The following are some specific requirements for FTP/V2 to communicate with NetView/FTP:

A compatibility PTF (program temporary fix) is required if your copy of FTP/V2 is to communicate with NetView/FTP. Contact the IBM Support Center for information about the PTF required for your operating system.
Transfer parameters must be specified by the FTP/V2 batch job entirely. The interface for NetView/FTP-to-FTP/V2 does not allow specification of parameters to be split between nodes or defined at both nodes as with two FTP/V2 jobs.
Dynamic dataset allocations must be used to define the dataset being received/sent at the NetView/FTP site. This means that xFILEID='...dsn...' must be specified instead of xFNAME=ddname in the FTP/V2 parameters. Disposition, DCB and space information can be provided using the following parameters: xTDISP, xUNIT, xVOLSER, xRECFM, xLRECL, xBLKSIZE, xSPCUNIT, xSPCPRIM, and xSPCSEC. Note that the "x" in each instance is either "S" (send) or "R" (receive).
NetView FTP may be executed in either batch or continuous operation (re-entrant) mode. The major difference between NetView batch and NetView re-entrant is that NetView FTP re-entrant runs continuously and is available during all normal production work hours. It does NOT require any batch job execution at NWRDC. NetView batch at NWRDC must be executed in Class F.
If executed in re-entrant mode, NWRDC security parameters must be specified for the dataset that is to be accessed by the NWRDC NetView/FTP. To do this, the FTP/V2 job must contain the parameter xSECURP=(acct, password), where acct is the LOGONID for NWRDC access and password is the password for that account. In the FTP/V2 job, you must code the SSECURP parameter to receive data from NWRDC or specify the RSECURP to send data to NWRDC.
Communication with NetView/FTP is started by the execution of the FTP/V2 program.

NetView FTP may be executed in either batch mode or in re-entrant mode at NWRDC. Versions of FTP being used by institutions connected to FIRN2 are generally File Transfer Program (FTP) Version 2, Release 2. They will operate the FASTER system with NetView FTP running in batch mode at NWRDC.

Use of File Transfer Program Version 2, Release 2
with NetView FTP Running in Batch Mode

Before initiating an FTP transmission, it is prudent to insure that the SNA link between the two data centers is operational. If your terminal has full SNA capability (i.e., you can logon to applications at the remote data center), you can check the line's functionality by attempting to logon to an application, such as CICS, at the remote data center. Alternatively, there is another way to insure the SNA link is active, and at the same time reduce the necessity to ever execute a wait time. This method requires that the transmitting site submits a job to execute at the receiving site to route control language statements to the internal reader which are submitted as a job back to the transmitting site for execution. This job initiates FTP at the receiving site and the transmitting site. This way, no FTP job is begun at either site unless both data centers are active.

The following is the JCL needed to transmit data from a DOS/VSE site and have it received and cataloged at a NetView MVS site (NWRDC) using the method described above. The first step executes the program IEBGENER at NWRDC and submits (via the MVS internal reader) a jobstream to begin the execution of FTP at the DOS/VSE site, the sending site. The second step invokes the execution of NetView FTP in batch mode at NWRDC. Step 1 is designed to prevent the user from starting FTP on their end if NWRDC is not operational. By doing it this way, the transmitting site does not have to be concerned about FTP timing out on its end because of not being able to communicate with the NWRDC.

//*Step One - Startup of FTP Sending Module at Transmitting DOS/VSE Site
//*
* $$ JOB JNM=jobname,XDEST=NWR,LDEST=nodename....etc. DOS/VSE parameters
//jobname JOB (nwrdc acct#),'programmer name',CLASS=F,TIME=(,10)
/*PASSWORDppppp
//STEP1 EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=A
//SYSUT2 DD SYSOUT=(,INTRDR)
//SYSUT1 DD DATA,DLM='##'
//*
//* The next two statements are used to enter a job on a network node for
//* transmission to another network node. JES2 at NWRDC does not process or
//* check the data for JES2 validity. All data after the /*XMIT statement is
//* transmitted to the specified destination. The node specified as the
//* destination receives all of the data following the /*XMIT statement as a
//* job to be acted upon.
//*
//NETJOBCD JOB
/*XMIT nodename DLM='/&'
//*
// JOB FTPSEND
// EXEC DVGFTP,SIZE=AUTO

XMODE=S	*/transmission mode (send, receive)
RUSIZE=2048	*/request unit size
SLU=CFC1FTPS	*/sending logical unit
RLU=NWR1FTPR	*/receiving logical unit
RESTART=NO	*/restart parameter
TIME=30	*/wait time for partner to be active
SFTYPE=sending file type	*/sending file type
SFILEID= 'DSN.TOBE.SENT'	*/sending file name
RFTYPE=receiving file type (at NWRDC)	*/receiving file type
RFILEID='DSN.TOBE.RECEIVED'	*/receiving file name

RTDISP=CAT
RRECFM=xx,RLRECL=xxx,RBLKSIZE=xxxxxRUNIT=xxxx,RSTORCLS=SCFNSTD
//*RSPCUNIT=TRK,RSPCPRIM=xx,RSPCSEC=xx
//*SPACE=space allocation..tracks or cylinders
/&
##
//*Step Two - Startup of NetView FTP at the Receiving MVS Site (NWRDC)
//*
//STEP2 EXEC NWRNVFTP
//CONTROL DD *
LUNAME=NWR1FTPR
/*
* $$ EOJ

You will need to modify the JCL provided above by replacing the following fields with valid values:

jobname - 1 to 8 characters job name
programmer name - 1 to 20 characters programmer name
nwrdc acct# - valid account number at NWRDC
ppppp - password associated with the NWRDC account number
nodename- network 3 character site identifier
xx - logical record length, record format, volume serial number, etc. to be supplied by user

The example control language above executes a program called DVGFTP at the transmitting (DOS/VSE) site. Note that in order to use the NWRNVFTP procedure at NWRDC, the user must add certain control parameters to the default ones defined. This can be done by defining a //CONTROL DD as follows:

//CONTROL DD *
LUNAME=NWR1FTPR

In order to reverse the process, so that the DOS/VSE site is the receiving site and the MVS site is the sending site, it is necessary to change the following control parameters: XMODE, SFILEID, and RFILEID at the local site, reverse the SLU and the RLU, and update the SFTYPE and RFTYPE.

The next JCL example is what is needed to transmit data from one MVS site (NWRDC) and have it received and cataloged at another MVS site (NERDC). The procedure is the same as previously described.

//* Step One - Send Jobstream executed at Transmitting MVS Site
//*
//jobname JOB (nwrdc acct#),'programmer name',CLASS=F,TIME=(,10)
/*PASSWORD ppppp
/*ROUTE PRINT NWR.Rxx
//SEND EXEC NWRNVFTP
//CONTROL DD *

LUNAME=NWR1FTPS

*/sending logical unit

//
//*
//* Step Two - Receive Jobstream executed at the Receiving Site (NERDC)
//*
//jobname JOB (nerdc acct#),'programmer name',CLASS=A,TIME=(,10)
/*ROUTE PRINT NWR.R17
/*ROUTE XEQ NER
/*PASSWORD ppppp
//RECEIVE EXEC NERFTP
//EXFTP.SYSIN DD *
XMODE=R
RUSIZE=2048
SLU=NWR1FTPS
RLU=NER1FTPR
RESTART=NO
TIME=30
SFTYPE=sending file type
SFILEID='NWR.FILE.TOBE.SENT'
RFTYPE=receiving file type
RFILEID='name of file to be created at NERDC'
RTDISP=CAT
RRECFM=xx,RLRECL=xxx,RBLKSIZE=xxxxxRUNIT=xxxx,RSTORCLS=SCFNSTD
//*RSPCUNIT=TRK,RSPCPRIM=xx,RSPCSEC=xx
//*SPACE=space allocation..tracks or cylinders
//

In order to reverse the process so that NWRDC is the receiving site and NERDC is the transmitting site, it is necessary to change the same control parameters as in the DOS/VSE to MVS example, i.e., XMODE, SFILEID, and RFFILEID at both sites, reverse the SLU and the RLU and the NetView LUNAME, and update the SFTYPE and RFTYPE.

//* Step One - Receive Jobstream executed at NWRDC
//*
//jobnameJOB (nwrdc acct#),'programmer name',CLASS=F,TIME=(,10)
/*PASSWORDppppp/*ROUTE PRINT NWR.Rxx
//SEND EXEC NWRNVFTP
//CONTROL DD *

LUNAME=NWR1FTPR

*/receiving logical unit

/*
//*
//*Step Two - Send Jobstream executed at NERDC
//*
//jobname JOB (nerdc acct#),'programmer name',CLASS=A,TIME=(,10)
/*ROUTE PRINT NWR.R17
/*ROUTE XEQ NER
/*PASSWORDppppp//RECEIVE EXEC NERFTP
//EXFTP.SYSIN DD *
XMODE=S
RUSIZE=2048
SLU=NER1FTPS
RLU=NWR1FTPR
RESTART=NO
TIME=30
SFTYPE=sending file type
SFILEID='INPUT.TOBE.SENT.TONWR'
RFTYPE=receiving file type
RFILEID='OUTPUT.FILE.TOBE.CATLG.ATNWR'
RTDISP=CAT
RRECFM=xx,RLRECL=xxx,RBLKSIZE=xxxxxRUNIT=xxxx,RSTORCLS=SCFNSTD
//*SPACE=space allocation..tracks or cylinders
/*

NWRNVFTP and NERFTP are cataloged job control language procedures that reside in the procedure libraries at NWRDC and NERDC, respectively. Both procedures make use of default control statements that are defined in the source libraries at NWRDC and NERDC. As in the DOS/VSE to MVS site example, certain control parameters must be added to the default ones or the user may choose to override all the parameters defined in the source library.

Use of File Transfer Program V2 with NetView File
Transfer Program Running in Continuous Operation Mode

For ease of operation and maintenance, naming conventions have been established for the definition of the sending and receiving logical unit names in the VTAM cross domain application tables. In order to send or receive multiple datasets at the same time, more than one queue handler and more than one server are defined at NWRDC. Use the following when executing NetView FTP MVS V2 at NWRDC in a re-entrant mode only :

NWRFPUB1	is the remote logical unit name when a school district is sending data to NWRDC, and is the local LU when a school district is receiving data from NWRDC; and
NWRFEDS1	is the remote logical unit name when a college or university is sending data to NWRDC and is the local LU when a college or university is receiving data from NWRDC.

Copies of FTP installed at your local site bear different names. Those institutions who transfer data using FTP V2.2 may choose to use NetView FTP running in continuous operation mode (re-entrant) rather than NetView FTP batch as their communications partner at NWRDC. This simplifies the transfer process. While the FASTER System does not automatically generate the required job control statements necessary for execution, it is a simple matter to modify the FTP V2.2-to-NetView FTP Batch job control language that is generated by the system.

Figure E-1 is an example of the job control language required to send records from a VSE site running FTP V2.2 to NWRDC NetView FTP re-entrant. Parameters, which need to be modified before submitting the job, are shown as bold characters enclosed in question marks.

Rather than the single job needed to post records (whether it be requests or responses) when using FTP/V2-to-NetView FTP/BATCH, two jobs are required when using FTP/V2-to-NetView FTP/RE-ENTRANT. The job flows for FTP/V2-to-NetView FTP/RE-ENTRANT communication are as follows:

An FTP/V2 job which executes at your site to send the data to NWRDC for posting. (See Figure E-1.)
A second job executes at NWRDC that, in its first step, deletes those existing datasets generated in the next step. The next step then posts requests (SRTS01) or responses (SRTS03). NOTE: This job cannot be submitted until after you verify that your FTP/V2 job has completed successfully. The third NWRDC step submits a job to the internal reader to execute FTP/V2 at your site for receiving a copy of the error records. The corresponding NWRDC step to send the copy of the error records to your local site is required when running FTP/V2-to-NetView FTP/BATCH but is not required when communicating using FTP/V2-to-NetView FTP/RE-ENTRANT. Therefore, delete this step, along with any conditional referbacks to this step, when modifying FTP/V2-to-NetView FTP/BATCH JCL to run for FTP/V2-to-NetView FTP/RE-ENTRANT.

FIGURE E-1

* $$ JOBJNM=FTPSEND,CLASS=A
// JOB FTPSEND
//*---------------------------------------------------------------------------------
//* SEND JOB EXECUTING AT YOUR VSE SITE
//*---------------------------------------------------------------------------------
// DLBL INPUT,'?YOUR.DATASET.TOBE.SENT?',,VSAM,CAT=?YOURVSAMCAT?
// EXEC DVGFTP,SIZE=AUTO

XMODE=S	*/ TRANSMISSION MODE(SEND,RECEIVE)
RUSIZE=2048	*/ REQUEST UNIT SIZE
RUNUMCR=200	*/ NBR RU'S BEFORE CHECKPOINT
RLU=NWRFPUB1	*/ NWR'S NETVIEW LU NAME
SLU=?YOUR-SITE-LU?	*/ LOCAL SENDING LU
RESTART=NO	*/ RESTART PARAMETER (YES,NO)
SFTYPE=VSAM	*/ FILE TYPE OF FILE TO BE SENT
SFNAME=INPUT	*/ LOCAL DSN OF FILE TO BE SENT
RFTYPE=SAM	*/ FILE TYPE OF RECEIVED FILE
RFILEID='?DATASET.TOBE.RECEIVED.ATNWR?'	*/ NWR DSN OF FILE TO BE RECEIVED
RSECURP=(?NWRACCT,NWRPASSWD?)	*/ NWR SECURITY INFORMATION
RTDISP=CAT,	*/ CATALOGUE RECEIVED DATASET
RRECFM=FB,RLRECL=?LLL?,RBLKSIZE=?BBB?	*/ RECEIVING LENGTH & BLOCKSIZE
RUNIT=SYSDA,RSTORCLS=SCFNSTD	*/ NWR STORCLASS TO HOLD DATA
RSPCPRIM=?PPP?,RSPCSEC=?SSS?	*/ PRIMARY & SECONDARY SPACE IN
RSPCUNIT=TRK	*/ TRACKS

//*---------------------------------------------------------------------------------
//* REPLACE PARAMETERS ENCASED IN ?'S
//*---------------------------------------------------------------------------------

Figure E-2 is an example of the job control language required to receive records at a VSE site running FTP V2.2 from NWRDC NetView FTP re-entrant. Parameters, which need to be modified before submitting the job, are denoted by bold characters enclosed in question marks.

FIGURE E-2

* $$ JOBJNM=FTPRECV,CLASS=A
// JOB FTPSEND
//*---------------------------------------------------------------------------------
//* RECEIVE JOB RUNNING AT YOUR VSE SITE
//*---------------------------------------------------------------------------------
// DLBL OUTPUT,'?YOUR.DATASET.TOBE.RECEIVED?',,VSAM,CAT=?YOURVSAMCAT?
// DLBL DVGCR,'?YOUR.CHECKPOINT.RESTART.FILE?',,VSAM,CAT=?YOURVSAMCAT?
// EXEC DVGFTP,SIZE=AUTO

XMODE=R	/* TRANSMISSION MODE(SEND,RECEIVE)
RUSIZE=2048	/* REQUEST UNIT SIZE
RUNUMCR=200	/* NBR RU'S BEFORE CHECKPOINT
SLU=NWRFPUB1	/* NWR'S NETVIEW LU NAME
RLU=?YOUR-RECEIVE-LU?	/* LOCAL RECEIVING LU
RESTART=NO	/* RESTART PARAMETER (YES,NO)
SFTYPE=SAM	/* FILE TYPE OF FILE TO BE SENT
SFILEID=?NWR.DATASET.TOBE.SENT?'	/* NWR DSN OF FILE TO BE SENT
SSECURP=(?NWRACCT,NWRPASSWD?)	/* NWR SECURITY INFORMATION
RFTYPE=VSAM	/* FILE TYPE OF RECEIVED FILE
RFNAME=OUTPUT	/* REFERENCE NAME FILE TO BE SENT

//*---------------------------------------------------------------------------------
//* REPLACE PARAMETERS ENCASED IN ?'S //*---------------------------------------------------------------------------------

When extracting records from the System (whether these be requests or responses) the job flow for FTP/V2-to-NetView FTP/RE-ENTRANT communication is as follows:

A job is executed at NWRDC that, in its first step, deletes those existing datasets which will be generated in the next step. The second step then extracts requests (SRTS02) or responses (SRTS04) from the System.
The third step of the NWRDC job submits to the internal reader a job to execute FTP/V2 at your site to receive a copy of the requests or response records (see Figure E-2). Note that the IEBGENER step to submit the class F execution of the corresponding NWRDC send job needed to send the copy of the request or response records to your local site is required in an FTP/V2-to-NetView FTP/BATCH job but is not required in an FTP/V2-to-NetView FTP/RE-ENTRANT communication. Therefore, delete this step, along with any conditional referbacks to this step, when modifying FTP/V2-to-NetView FTP/BATCH JCL to run for FTP/V2-to-NetView FTP/RE-ENTRANT.
If there were interdistrict or secondary response records extracted, a fourth step edits (SRTS03A) these records for potential non-fatal errors.
If request records were extracted, a fifth step prints the extracted Header Records (SRST11); if interdistrict or secondary responses were extracted, the final step prints the interdistrict or secondary transcripts (SRTS12IS); and/or if postsecondary responses were extracted, the final step prints postsecondary transcripts for the extracted records (SRTS12P).

Recovery/Restart

A user-requested restart can be initiated only if the user restarts any copies of FTP that were running when the transfer stopped and specifies the RESTART=YES option at the sending site. A checkpoint/restart record would have been written during a previous transmission.

A checkpoint/restart record is written to the checkpoint/ restart data set (DVGCR) whenever a user-defined number (RUNUMCR) of request units has been received and successfully written to the output data set. Once a RESTART=YES session has been started, the sending FTP requests information to be sent from the receiving FTP. The sending FTP then transmits data from the input dataset for those records whose relative record number is greater than the record number received from the checkpoint/restart data. Note that a checkpoint/restart dataset need not be defined in a NetView FTP MVS job, since it would have been defined in the jobstream that defined the server that is to process the request.

Common FTP Errors and Their ResolutionThe following are some errors frequently encountered when executing FTP and some guidelines to follow to resolve them.

"Session not started during wait time limit of 30 minutes." An FTP session executing at an FTP V2.2 location did not receive a response from its partner session (defined in the control statements) within the specified wait time.

Make sure both sites are active.
Resubmit both jobs.

"Error on inquire application status VTAM cross domain connection to other node is not established or logical unit name is not an application name".

Contact the system programmer at the other node to insure that the logical unit name is defined in the cross domain table and is active.
Resubmit both jobs.

"VTAM open error for logical unit: ACB error code = 5A".

Make certain that the logical unit name has been correctly typed and agrees with the cross domain table entries.
Resubmit both jobs.

If both jobs are submitted to the requestor, but the NetView FTP jobs abends before transmission is begun, the other FTP V2.2 job will execute in a wait state for a specified amount of time.

Edit the JCL procedure originally submitted.
Strip off the JCL for the job which is currently executing in a wait state.
Correct whatever caused the job to abend (JCL error, dataset not found, dataset already cataloged, etc.)
Resubmit the job.

RJE Access to JES2 Hosts via FIRN2
Operational Procedures

Access to FIRN2 JES2 hosts, such as CFRDC, NWRDC, NERDC, or Dade Public Schools is availablel through Terminal and Host Interfaces. The RJE Terminal Interface communicates with the RJE workstation (or, more typically, workstation emulator), while the RJE Host Interface communicates with a host data center running JES2.

Most RJE workstation emulation programs are written with the assumption that the RJE site will be in DIRECT communication with the JES2 host via leased line or direct dialup. The workstation emulator will typically transmit a signon record to the host in order to identify itself and establish communication with JES2. In a networking environment such as FIRN2 the JES2 signon record does not contain sufficient information for the RJE Terminal Interface to establish a workstation-to-host connection. The Terminal Interface requires a network signon record to identify the destination host.

The code (computer program) for the RJE Terminal Interface was written with the understanding that many RJE workstation emulation programs will, as their first action, transmit the host signon record. The Terminal Interface will store the host signon record and will wait two minutes for the workstation to transmit a network signon record before flushing its buffers and reinitializing. After receiving the network signon record, the Terminal Interface will forward the host signon record to the appropriate FIRN2 RJE Host Interface, which will, in turn, forward it to the JES2 host. If the host accepts the signon record, the Host Interface sends a CALL COMPLETED message, along with any host greeting messages, to the workstation (via the Terminal Interface, of course). At this point the RJE workstation emulation program will be in communication with the JES2 host. All subsequent messages transmitted by the workstation will be forwarded by the RJE interfaces to the host.

In certain cases it is not necessary for the workstation to transmit a network signon record. Specifically, when the computer executing the workstation emulator is connected to a FIRN2 Tymnet engine, mini engine, or micro engine directly by RS232C cables (including a "cross-over" cable, which enables the connection of two communication ports which are configured for connection to a modem); the Terminal Interface can be programmed to activate a stored network signon record when the workstation's communication port becomes active. This is known as a "PVC" (Permanent Virtual Circuit) logon.

If the RJE interfaces cannot successfully complete the connection to the JES2 host, a message is transmitted to the workstation. See below for discussion of such messages and problem determination. The general procedure for access to a JES2 host via FIRN2 can be summarized as follows:

Begin execution of your RJE workstation emulation program.
(DIAL UP ONLY) Dial the nearest FIRN2 RJE dialup phone number (these numbers are listed in Appendix D). Listen for a high pitched tone followed by a lower pitched tone and then switch from voice mode to data mode. NOTE: you must use a synchronous half-duplex 4800 bps dialup modem, such as the Racal-Vadic VA4840, in conjunction with a voice/data telephone, such as the Racal-Vadic VA871.
Transmit the JES2 signon record.
Transmit the network signon record (within two minutes after transmitting the JES2 signon record).
You should receive a CALL COMPLETED message and a JES2 (host) greeting message within 45 seconds. The JES2 greeting message will look something like this:
99.99.99 $HASP200 RMTn STARTED ON LINEn NODE nnn
You are now in communication with JES2 and can send jobs and commands and can receive printer and punch output.
When you are ready to signoff of the JES2 host, transmit the signoff record as card reader data*. You should receive a CALL CLEARED message.
Terminate your workstation emulator.

*NOTE: many RJE workstation emulators will automatically transmit the host signoff record when the emulator is terminated. Consult the emulator's documentation to see if this is the case for your emulator, or call the vendor.

Format of JES2 signon record:

Column	Value	Description
1	/*SIGNON	Signon command
16	REMOTEn or RMTn	Where n is the RMTID (up to three digits with NO LEADING ZERO)
25	RJEDIAL	Line password at NWR & NER
73	xxxxxxxx	Password for RMT n

NOTE : Under JES2, RJE workstations are referred to as RMTs (ReMote Terminal). All RMTs are assigned a unique number, referred to as a RMTID.

Format of network signon record.

/$NETCMD SIGNON username;password

FIRN2 RJE usernames usually take the format hhhRMTnn, where hhh is the host (CFR,NER,NWR) and nn is the RMTID that your workstation uses when communicating with the JES2 host. For example, if you are accessing NWR and have been assigned a RMTID of 75, the username would be NWRRMT75. If the password for NWRRMT75 is MOONSHINE, the network sign-on record would look like this:

/$NETCMD SIGNON NWRRMT75;MOONSHINE

The format of JES2 signoff record is:

/*SIGNOFF

Problem Determination

After beginning execution of your RJE workstation emulation program, it reports a communication problem.

CAUSE:	There may be a phone line problem between your site and the terminal interface, or the terminal interface has crashed.
ACTION:	Call FIRN2

After transmitting the network signon record, nothing at all happens or you get: LINK CLEARED

CAUSE:	The RJE interfaces could not complete the circuit.
ACTION:	Call FIRN2

After transmitting the network signon record you get: HOST NOT AVAILABLE THROUGH NET

CAUSE:	The RJE Host Interface has probably crashed.
ACTION:	Call FIRN2

After transmitting the network signon record you get: HOST OUT OF PORTS

CAUSE:	Either the host is down or all of the available connections between the FIRN2 RJE host interface and NWR JES2 are currently in use by other workstations.
ACTION:	Try again after twenty minutes. If you get the same message, call FIRN2.

After transmitting the network signon record you get: CALL COMPLETED CALL CLEARED

CAUSE:	JES2 has rejected your signon.
ACTION:	Check your /*SIGNON record for syntax. If correct, call FIRN2.

While connected to the JES2 host, you get a CALL CLEARED.

CAUSE:

Either the JES2 host has gone down or logged you off, or there has been a problem in one of the RJE interfaces, or an internal FIRN2 communications problem has caused your connection to be lost.

(NOTE: NWR uses a twenty-five minute inactivity timer. If a RMT transmits no commands or jobs, or receives no output, for twenty-five minutes, that RMT is automatically logged off).

ACTION:

Restart your emulator program, and try to re-establish connection with the JES2 host. If unsuccessful, call FIRN2.

Some Useful JES2 Commands

NOTE: In all examples 'xx' is the workstation's RMTID. If your RMTID is a single digit, DO NOT key in a leading 0.

Command	Description
$DU,RMTxx	will show the status of the RMT and all of its devices (printer, punch, reader). An ACTIVE status means that the device is sending/receiving data, an INACTIVE status means that the device is idle, and a DRAINED status means that the device is shut down and requires a Start command before it can be used.
$DU,Rxx.PR1	shows printer status.
$DU,Rxx.RD1	shows reader status.
$DU,Rxx.PU1	shows punch status.
$SRxx.RD1	starts the reader.
$SRxx.PR1	starts the printer.
$SRxx.PU1	starts the punch.
$PRxx.RD1	"drains" the reader.
$PRxx.PR1	"drains" the printer.
$PRxx.PU1	"drains" the punch.
$DF	shows the output spooled for RMTxx, by form type
$DJ1-9999	shows the status of all jobs associated with the RMT, including those awaiting execution.
$BRxx.PR1,10	will backspace the printing job by 10 pages.
$ERxx.PR1	will restart the currently printing job.

* For 2780/3780 sites, commands must be preceded by /*... , ex:

/*$DJ1-9999 - syntax for display job command on 2780/3780