.PAGE SIZE 30,108 .LM25;.RM85;.P5,1;.AP;.NONUMBER;.hyphenation .C;AN IMPLEMENTATION OF VAX-IBM COMMUNICATIONS .B1;.C;Dr. DAVID J. SLATER .C;JOSEPH L. BINGHAM .C;JANET L.##BARGH .C;MANTECH##INTERNATIONAL .C;ALEXANDRIA, VIRGINIA .B3;.C;^&ABSTRACT\& .B1;This paper describes a system supporting communications between a VAX-11/780 and a large IBM 370 installation. The system consists of a DEC DUP11 synchronous interface and the DEC 2780/3780 protocol emulator software augmented by procedures written in DCL, FORTRAN and VAX-11 MACRO. The system handles the generation and submission of JCL to the IBM 370 and the classification and disposition of files from the IBM 370. A significant feature is its ability to allow non-privileged users to execute highly privileged command procedures without compromising the security or integrity of the VAX. .B3 .PAGE SIZE 10000,52 .LM0;.RM52 .c;^&INTRODUCTION\& .B2;The resources used to implement this project were: .NJ;.LM 3;.LIST 1 '.';.le;The DUP11 synchronous interface with a suitable telephone line and modems to provide the necessary hardware for supporting 2780/3780 communications. .le;The 2780/3780 protocol emulator software for the basic control structure to use a DUP11 on a VAX-11. The emulator software is designed to be used at three levels: DCL, RMS or QIO (device driver). .le;Several systems programmers with a variety of experience but little communications experience and no 2780/3780 experience for the DCL, FORTRAN and MACRO programming. .END LIST;.LM0;.J We chose to interface with the emulator software at the DCL level. This decision was dictated by pressure to get the system up and running and by the lack of sufficient familiarity with the 2780/3780 protocol to comfortably work at a lower level. Time pressure also dictated that some procedures be written in DCL when FORTRAN or MACRO would have provided more efficient operation. .B2;.c;^&USER PERCEPTION OF THE SYSTEM\& .B2;^&The nonprogrammer (TSO) user view\&. A group of nonprogrammer users who are accustomed to an IBM TSO environment is the major user group supported. These users query a large data base (about 12.6 Gbytes) on the IBM 370 and require support on a 24 hour per day, 7 day per week basis. They submit 400 jobs through the VAX in a typical day. The system provides them with a TSO-like environment and up to date IBM 370 job status information. They previously had to contend with a severely overloaded TSO system but now get better response with only minor changes in their operating procedures. .B1;^&The IBM 370 Programmer User View\&. The system also supports a group of IBM 370 programmers. These programmers do most of their program development via terminal and telephone connection to the IBM 370, but direct their output to the VAX. Although compared to the DATA#100 which was replaced, there is some delay in getting printer output there are some advantages in having the capability of easily reviewing files prior to printing them. Also, some files are later transferred to another IBM installation. .B2.c;^&SYSTEM STRUCTURE\& .b2;A given application may be implemented in either a hierarchical or a heterarchical structure but some applications seem naturally to fall into one or the other for the most straightforward design. The system being described is heterarchical. Its five main modules do not call each other and they communicate by modifying the environment, specifically by depositing files for another module to process or by setting or clearing flags. Most user programs have a hierarchical structure. That is, there is one main program which calls subroutines to do specific tasks. Modules in this type of structure are invoked explicitly when needed and generally receive data as arguments passed as part of the calling scheme. There is, however, a significant quantity of software which is heterarchical in structure. That is, the system consists of several independent modules which monitor the environment and when there is something in their area of responsibility to be done, do it. The modules in this type of structure can be categorized as event driven and they typically communicate by modifying the environment. Examples of heterarchical programs are operating systems where the modules might be JOB__CONTROL, PRSYMB, OPCOM, ERRFMT, etc. and in an artificial intelligence system where the modules might be SENTENCE ANALYZER, QUESTION ANALYZER, THEOREM PROVER and DATA BASE HANDLER. The modules of a heterarchical structure are sometimes called daemons. .B2;.c;^&SYSTEM MODULES\& .B2;Three of the five modules making up the system are command procedures which resubmit themselves to a batch queue whenever they run, one is invoked by the LOGIN.COM of the TSO users and one is invoked by a user, an operator or a systems programmer as required. The modules are: .NJ;.LM 3;.LIST 1 '.' .le;AUTOSTART, a periodically running command procedure which checks the status of the line to the IBM 370 site and signs on if necessary. .le;TSOSIM which is invoked by the tso users LOGIN.COM and runs a package of COBOL programs which simulate a TSO environment and construct JCL decks for transmission to an IBM 370. The user is logged out upon completion of his session. .le;MONITOR which consists of a FORTRAN program, several DCL procedures and a couple of MACRO routines. This program also runs in a LOGIN.COM prompting for a command, then parsing, recognizing and passing it to DCL for execution. .le.;JOBSUB which is another periodically running command procedure. JOBSUB senses the presence of a JCL deck which is ready to be sent to the IBM 370 and constructs and submits an appropriate command procedure to the RJE queue. .le;FILEREC, the third periodically running command procedure which classifies the files as transmission acknowledgements, IBM 370 job status information or user files and handles them accordingly. .END LIST;.LM0;.J .B1;.c;^&SYSTEM ACTION AND DATA FLOW\& .B2;^&Nonprogrammer (TSO) Users\&. When TSO users log on to the VAX they execute a command procedure which runs the TSOSIM module. This module was adapted from the program they ran directly on the IBM 370 prior to transferring to this system and provides them with a familiar environment. The JCL decks are produced with a file name constructed to be unique for the interactive session and with a .SJE extension. Users may produce numerous JCL decks in one session with each being available for transmission to the IBM 370 as soon as it is completed. When the session is complete or if an error is encountered the user is logged off. JOBSUB periodically scans the directory and when it finds a closed .SJE file it: .NJ;.LM 3;.LIST .le;assigns a version number which is used for files related to this transaction as it proceeds through the system, .le;renames the .SJE file to .RJE, .le;writes a command procedure to transmit the JCL file to the IBM 370, and .le;submits the command procedure to the RJE queue. .END LIST;.LM0;.J .i5 The unique name and version number combination is used to insure that each job is transmitted once and only once and so that used command procedures can delete themselves. When the job gets to the top of the RJE queue for execution the command procedure runs the 2780/3780 emulator software to send the JCL deck to the IBM 370. The IBM 370 responds with a one line acknowledgement message. (Printout for these jobs normally goes to various other sites.) .B1;^&IBM 370 Programmer Users\&. The IBM 370 programmers using this system direct their printer output to the VAX as a remote unit. The VAX receives all of the incoming files under the same filename, mixed in with the acknowledgement messages and the IBM 370 job status reports. Since VMS allows only about sixty versions of a file before dropping the oldest versions and the files accumulate rapidly it is necessary to handle them expeditiously. The processing is done by the FILEREC module which varies its resubmission interval depending on the level of activity on the RJE line. When FILEREC runs it scans each received file and classifies it as (1)#a job acknowledgement, (2)#an IBM 370 job status report, or (3)#an incoming user file and takes the following action: .NJ;.LM 3;.LIST 1 '.' .le;Job acknowledgements are put in a single file which is printed once a day. .le;Status reports are separated into four types (DA, DN, DQ and DU) and are available on the VAX for review by the IBM users. .le;User files are copied to a directory coded in the name field of the job card if the sender desires to keep a copy of the file on the VAX and the original is printed and deleted. .END LIST;.LM0;.J .B2;.c;^&SYSTEM MONITOR\& .B2;^&Functions\&. The monitor provides the following functions for use by general users and operators. Systems programmers use the module for diagnosing problems but generally need an account without its restrictions for correcting problems. .NJ;.LM 3;.LIST 1 '.' .le;Access to incoming files, status files, and the ACK.DAT file. Modified versions of the DCL DIRECTORY, TYPE, PRINT, DELETE and EDIT/READONLY commands are available. The modifications are (1)#the directory is hardwired to the RJE directory, (2)#the file name defaults to REC.DAT (since that is the most frequent name used) and (3)#a range of versions numbers may be specified for the TYPE, PRINT and DELETE commands. eg PRINT 5 10 prints REC.DAT;5 through REC.DAT;10. .le;The capability of sending HJ, AJ, CJ and OJ commands to the IBM 370 (hold job, release job, cancel job and output job) and of submitting a JCL deck to the RJE queue. .le;START, STOP, STATUS and TEST commands for monitoring or manipulating the remote line. .END LIST;.LM0;.J A parsing and recognizing routine similar to the one on the Spring 1980 VAX DECUS tape [FILETOOLS]CHARCHK.FOR is used to decode and reform the command. The user is required to input only the characters necessary to uniquely define a command recognized by the system. Entering an unrecognized command causes the program to display the list of recognized commands. .B2;^&Keeping the MONITOR Privileges Under Control\&. The MONITOR is a highly privileged process. The START command requires privileges the System Manager does not want to give to anybody and several other commands need several privileges. In order to make the MONITOR available to non-privileged users the following steps were taken: .NJ;.LM 3;.LIST 1 '.' .le;It runs as a LOGIN.COM with no exit from the procedure except the LOGOUT command. This is accomplished by: .NJ;.LIST 1 '+' .le;setting the NOCTLY flag in the user authorization file, .le;not allowing the default for SYS$DISK to be used (it can be modified at login with /DISK=anything) and .le;handling errors without exiting (using SET NOON or ON ERROR THEN $something benign, remembering that the ON ERROR condition has to be reset after each use.) .END LIST;.J .le;The set of recognized commands is selected to control the access and power of the user and no action is taken on an unrecognized command. eg. SET DEFAULT is not a recognized command; the DIRECTORY, TYPE, PRINT and EDIT commands have the directory hardwired. .END LIST;.LM0;.J .B2;.c;^&INTERESTING SOLUTIONS\& .B2;^&Writing Command Responses to a File\&. There are several instances where a component needs information easily accessible through a DCL command but that command has no /OUTPUT= qualifier. For instance we want to know if there is a current job in the RJE queue before trying to stop or start the line, we need to know if BSC$XJA0 exists and what its PID is before killing it. The solution, of course, is to assign SYS$OUTPUT to a file and execute the command. The file can then be read to obtain the information needed. A command procedure illustrating this technique follows. .literal $! $! Start of KILLKEEP.COM $! $! This procedure checks the 'P1' queue for any jobs $! with a name beginning with KEEPUP or SIGN and $! deletes them. The purpose is to insure that the $! SIGNON, SIGNOFF or KEEPUP to be submitted will $! be the only such job in the queue. $! $ OPEN/WRITE QKILLKEEP QKILLKEEP.DAT $ ASSIGN/USER_MODE QKILLKEEP SYS$OUTPUT $ SHOW/QUEUE/ALL 'P1' $ CLOSE QKILLKEEP $! $ OPEN QKILLKEEP QKILLKEEP.DAT $ READ QKILLKEEP LINE $LOOP: $ READ/END_OF_FILE=EOF QKILLKEEP LINE $ IF 'F$LOCATE(" KEEPUP",LINE) .EQ. - 'F$LENGTH(LINE) .AND. 'F$LOCATE(" SIGN",LINE) - .EQ. 'F$LENGTH(LINE) THEN $GOTO LOOP $! $! Delete jobs containing ' KEEPUP' or ' SIGN' $! $ IDPOS = 'F$LOCATE("Job",LINE) + 3 $ ID := 'F$EXTRACT(IDPOS,5,LINE) $ WRITE SYS$OUTPUT "KILLKEEP.COM is deleting"- "the following job from the ''P1' queue:" $ WRITE SYS$OUTPUT "''LINE'" $ SET NOON $ DELETE/ENTRY='ID' 'P1' $ SET ON $ GOTO LOOP $! $EOF: $ CLOSE QKILLKEEP $ DELETE QKILLKEEP.DAT.* $! $! End of KILLKEEP.COM $! .end literal .B1;^&Writing [SYSEXE]REMOTE Responses to a File\&. The form of the above assignment requires modification to get the REMOTE program to write to a file. The following DCL excerpt illustrates a sequence which scans the answer to a SHOW LINE command in order to take appropriate action. .literal $! $! Start of 0083856T.COM;306 $! $SET DEFAULT DRA0:[DUP11] $ASSIGN QLINE.DAT SYS$OUTPUT $OPEN/WRITE QLINE.DAT SYS$OUTPUT $RUN SYS$SYSTEM:REMOTE SHOW LINE $CLOSE QLINE.DAT $DEASSIGN SYS$OUTPUT $RUN SYS$SYSTEM:FIX QLINE.DAT QLINE.DAT 100 $OPEN QLINE QLINE.DAT $READ/END_OF_FILE=EOF QLINE LINE $READ/END_OF_FILE=EOF QLINE LINE $CLOSE QLINE $DELETE QLINE.DAT.* !with job limit of one, * is ok $IF 'F$LOCATE("line not on",LINE) .EQS. - 'F$LENGTH(LINE) THEN $GOTO LINEON . . . $RUN SYS$SYSTEM:REMOTE SEND SIA0:[TSOUSER]008656T.RJE;306 .end literal Also indicated is another problem in trying to read the output of REMOTE. The output is a single record which is too long for a DCL read. (Running it through the program FIX truncates the record to 100 bytes which is more than sufficient for the use indicated.) .B2;^&Constructing Temporary Command Procedures\&. A command procedure sending a file over the RJE line needs the name of the .RJE file. Since we used a unique file name for each file and DCL will not substitute into a non-command line, there was a problem. Our solution was to write a unique, temporary command procedure for each transmission. The required translation then occurs inside the WRITE command at the time this file is written. Note that if you want to substitute in the temporary command procedure there is another problem. It is difficult (translation: we can't find a way to do it) to pass the substitution operator through a WRITE command. It substitutes at that time and that is that. A excerpt from another command procedure illustrates a way around this problem. .literal $! $! Start of RJESUB2.COM $! $OPEN/WRITE COM 'P1'.COM;'P2' $WRITE COM "$!" $WRITE COM "$! Start of ''P1'.COM" $WRITE COM "$!" $WRITE COM "$SET DEFAULT DRA0:[DUP11]" $! $!We resort to a mixture of WRITE and TYPE commands $! to produce the command procedure since we some- $! times want to substitute and sometimes do not $! want to substitute in strings in " marks. $! $ASSIGN COM SYS$OUTPUT $TYPE SYS$INPUT $DECK $ASSIGN QLINE.DAT SYS$OUTPUT $OPEN/WRITE QLINE.DAT SYS$OUTPUT $RUN SYS$SYSTEM:REMOTE SHOW LINE $CLOSE QLINE.DAT $DEASSIGN SYS$OUTPUT $RUN SYS$SYSTEM:FIX QLINE.DAT QLINE.DAT 100 $OPEN QLINE QLINE.DAT $READ/END_OF_FILE=EOF QLINE LINE $READ/END_OF_FILE=EOF QLINE LINE $CLOSE QLINE $DELETE QLINE.DAT.* !with job limit of one, * is ok $IF 'F$LOCATE("line not on",LINE) .EQS. - 'F$LENGTH(LINE) THEN $GOTO LINEON . . . $EOD $WRITE COM "$RUN SYS$SYSTEM:REMOTE" $WRITE COM "SEND SIA0:[TSOUSER]''P1'.RJE;''P2'" .end literal (Note that this excerpt is from the command procedure which wrote the preceeding example. Lines written with the TYPE command were passed literally and those written with the WRITE command had substitution performed.) .B2;^&Assigning Permanent Process Logical Names in an Image\&. Process logical names created by a user image using the SYS$CRELOG system service are created in user mode and disappear when the image exits. This is unsatisfactory if you are using logical names to communicate between an image and the commmand procedure running it. A MACRO subroutine was written to do the SYS$CRELOG in exec mode. The name will then be entered on the supervisor mode table and will be permanent. Another solution using CLI call-back is on the fall 1980 VAX DECUS tape in the [UTILITIES] subdirectory. .B2;^&Changing the Priority of a Running Process\&. The detached process created by REMOTE (BSC$XJA0) runs at the priority set by the SYSGEN parameter DEFPRI. In order to keep running on a busy system BSC$XJA0 needs a much higher priority. In attempting to get it to run satisfactorily on our busy system we tried .NJ;.LM 3;.LIST 1 '.' .le;bumping its priority in the sign-on command procedure after setting the transmit and receive characteristics on the line. But by that time we were usually receiving a file and hitting the line with a priority change frequently caused the line to come down. So we tried .le;sending the sign-on, bumping the priority and then running REMOTE again to set the receive characteristics. This worked until our VAX got so busy that it sometimes would not send the sign-on at the default priority. So we tried .le;increasing the DEFPRI SYSGEN parameter. This helped BSC$XJA0 but it also boosted the priority of all of the batch jobs on the VAX. Compute bound batch jobs completely took over the CPU. So we finally tried .le;the following sequence of commands: .nf;.nj $RUN SYS$SYSTEM:SYSGEN USE ACTIVE SET DEFPRI 8 WRITE ACTIVE $RUN SYS$SYSTEM:REMOTE SET (transmit characteristics) SET SHARED/QUEUE=RJE SEND (sign-on card) WAIT $RUN UPASUB (boosts BSC$XJA0's priority to 20) $RUN REMOTE RECEIVE RJE,etc $RUN SYS$SYSGEN:SYSGEN USE ACTIVE SET DEFPRI 4 WRITE ACTIVE .f;.j This roundabout way of doing things seems to do the job. .END LIST;.LM0;.J .b2;.c;^&OTHER PROBLEMS\& .B2;^&Line Noise\&. Line noise causes the line to go down 5-10 times a day. If we did not have the AUTOSTART module there would be a continual hassle trying to keep the line up. .b2;^&Communicating with different IBM systems\&. The system described communicates with an IBM 370 running HASP. We have a need to communicate with another IBM 370 running JES2. The commands, status report formats and received file formats are different under JES2. Therefore, two separate RJE systems must be implemented and maintained or the second operation must continue to be manual. .b2;^&Response of REMOTE to problems.\&. The REMOTE program takes the line down if it senses a serious problem. However, there have been instances of problems not bringing the line down and files have been transmitted into the bit bucket. We have not been able to determine what sequence of events causes the problem but we have minimized its impact by putting a WAIT command after the SEND command. This causes the job to time out without appearing to have been transmitted. The command procedure keeps resubmitting itself until the line goes down for some other reason. Some problems which result in a file not being transmitted (e.#g. "file not found") nonetheless return a normal status. An interactive user would get a message but a command procedure has nothing to test to trigger corrective action. .b2;^&The Telephone Support Center\&. We had poor luck getting timely or cogent answers from the TSC regarding 2780/3780 questions. They did help with some of the command idiosyncrasies and did finally send a patch for the rename function through the local Digital office but it took them a long time to admit that there was a problem with the rename function. On such things as the priority of the detached process or the inconsistent status returns from the REMOTE program their answers were of little help. .b2;.c;^&CONCLUSION\& .B2;The RJE system described has been running for about six months with no significant modifications. Manual intervention has seldom been necessary and users get good response from the VAX. .b2;.c;^&REFERENCES\& .B1;.lm 3;.nj;.LIST .le;^&VAX-11 2780/3780 Protocol Emulator User's Guide\&, Order number AA-H473A-TE .le;^&VAX/VMS Command Language User's Guide\&, Order number AA-D023B-TE .le;^&VAX/VMS Guide to Using Command Procedures\&, Order number AA-H782A-TE .END LIST;.LM0