All Packages  Class Hierarchy  Class Search  Index
package bmsi.sna

  Classes
  • FIFOSpooler
  • FMH_1
  • Gateway50
  • GatewayApp
  • GatewayConfig
  • JBMLU
  • JBMStatus
  • NetSpooler
  • PDIR
  • SCBInputStream
  • SCBOutputStream
  • SCSInputStream
  • Spooler
  • Submit
    •   Interfaces
  • JBMStatus.StateListener
  • SNA3770
  • SNADevice

    • BMS SNA Communications Overview

    Stuart D. Gathman, last update: Sep 13, 2000

    JBM Gateway 50 Support

    The Gateway 50 is a legacy protocol converter made by JBM Electronics. Since applications connect to it via a 10BaseT port, it is system independent. Unlike the Black Box AS/4, it supports multiple LUs and provides the full throughput available on the serial port.

    The main control class for the Gateway 50 is Gateway50. Each instance connects to a Gateway 50 on consecutive TCP ports. Each TCP port is routed to an SNA LU in the Gateway 50 configuration, and is controlled by an instance of the JBMLU class. The class overview for these two classes mentions the configuration settings needed by the Gateway 50.

    Gateway 50 Modem Connection

    The Gateway 50 is used in DTE port mode. Since the Gateway 50 rs232 connector is normally DCE, a G50 DTE adapter is needed to connect to a standard modem. The modem must support synchronous communications. The Gateway has no auto-dial support, so the modem must support "dial on DTR", or dialing through a second port. We use Penril modems which support dialing through a diagnostic port, or Multitech business modems which support synchronous dial on DTR (and are 1/4 the price of a Penril).

    If the communication is full duplex (so that the CTS,RTS signals can be jumpered), 8-wire UTP modular cable (used for 10baseT) can be used with RS232 modular adapter kits instead of the G50 DTE adapter with a modem cable. Wire the adapter kits with one each of types 8M and 9G below. Connect the 9G to the Gateway 50 and the 8M to the modem. 

          DB25    T Y P E S		
	wh-bk-rd-gr-yl-bl
color	| 8M | 9G |
--------+----+----+
BLU	| 17 | 23 |	for type 8M, jumper 4 - 9
ORA/WHT	|  8 |  4 |	for type 9G, jumper 8 - 20
BLK	|  2 |  3 |
RED	|  3 |  2 |
GRN	|  7 |  7 |
YEL	| 20 |  5 |
BRN/BLU	|  6 | 18 |
GRY	| 15 | 22 |	(for Serial# < 300, use 24 instead of 22)
    The Gateway monitors DSR, not DCD, for Activate PU. To detect loss of carrier, configure the modem so that DSR is true while the modem is on-line. This will work with both the G50 DTE and the modular adapters.

    XID Kludge

    The Gateway 50 hardwires the SNA XID in the application download. It is not configurable. Since we have multiple Gateway units on the USCS dialup SNA network, we have to patch the application download for each unit to the unique XID assigned by USCS. The GatewayApp class wraps a disk resident application download for the Gateway, and provides methods to inspect and change the XID. Here is the command line usage: 
    Usage:	java bmsi.sna.GatewayApp [-xXID] file1 [file2 ...]
	Reports the App ver and current XID for each listed file.
	-xXID	changes the XID of following files,
		XID is a hexadecimal number
    and here is some sample output: 
    $ java bmsi.sna.GatewayApp /tftpboot/j*.*
/tftpboot/jbmC1400.116: App Ver 04.XID2.116, XID 13c1400
/tftpboot/jbmgw50.115: App Ver 04.XID2.115, XID 139e028
/tftpboot/jbmgw50.116: App Ver 04.XID1.116, XID 139e028
/tftpboot/jbmgw50.bin: App Ver 04.XID1.116, XID 139e028
    The JBMStatus class can inspect the XID currently loaded in a Gateway 50. For example: 
    $ java bmsi.sna.JBMStatus fred:pebbles@g50 
Gateway at g50
  Firmware ver 04.XID1.118
  XID 139e028

    BOOTP and Gateway 50

    The Gateway 50 uses the IP address from its last configuration loaded. When the IP address is specified in the configuration, it does not use BOOTP unless you hold the reset switch down while turning it on. When moving a Gateway between networks, you should load the new configuration just before removing it from the old network. If you forget, or the configuration is incorrect, you'll need to reset while powering on.

    The Gateway uses only the IP address and Server address from the BOOTP data. It does not use home dir or boot file. On unix servers, you must set up the path /jbmgatew/jbmgw50/jbmgw50.bin as a link to the application binary, and add the line allow:/jbmgatew/jbmgw50 to /etc/tftpaccess.ctl for the reset to work.

    Mohammed tells me that by setting the unit and server IP address to zero in "Remote Access Information" and in Port/Ether/Hardware, the Gateway will query BOOTP for these addresses at reset or poweron. I tried this, and it does not work.

    Patching Gateway Config Files

    When not running MS Windows, it is difficult to run the DOS based configuration program. The GatewayConfig class parses and patches existing configuration files well enough to change the label and IP configuration. Further improvements will likely come soon.

    SNA/RJE Interface

    An RJE application should use the SNA3770 interface for greater flexibiliy. This is implemented by the Gateway 50 and BlackBox AS/4 classes. The Gateway 50 is cheaper and more capable than the AS/4, so the AS/4 will be phased out. However, future Gateway models or firmware may require separate implementation classes. By using only the SNA3770 interface, no changes to your application are required.

    Currently, the SNA3770 interface supports text data only. The Gateway 50 supports binary file transfer as well, and this will be supported through an extended interface later.

    Spooler

    The Spooler class provides a job queue and file spooled printer output.

    The NetSpooler class is a simple RJE server that uses Spooler to submit text files as jobs and spool print output to disk. It is 100% Java and should run on any JDK 1.1 compatible system.

    The FIFOSpooler class implements a spooler compatible with existing BMS SNA/RJE spooler programs. Signon, commands, and jobs are entered through a unix FIFO in a simple format. Console output is written to stdout, status messages to stderr. Printer output is written to a spool directory. It depends on a unix FIFO for submitting jobs, and is not 100% Java since is uses the BMS posix package.

    BUGS

  • Class Gateway50 knows when the modem connection is lost. It needs to tell Spooler so that it can shutdown or restart.
  • When Gateway50 shuts down, Threads for LUs that were never activated never terminate. For BMS customers this is typically LU6. We work around this by calling System.exit().
  • Too many FMH headers are reported in the log for console output, resulting in redundant "OUTPUT JOB STARTED" messages.
  • PDIR record does not include timezone. Will hardwire ET (where USCS mainframe resides), but should be configurable.
  • When phone disconnects during signon, main thread hangs waiting for confirmation.
  • When using a blind dial modem, the spoolers wait forever for PU Active. There needs to be a config option so that they will timeout in this case and try again after reset or terminate with an error.
    • The source for this package can be downloaded here (src.zip). The source includes bmsi.edi.FileSpool and bmsi.comm.Waitfor. These are BMS classes from other packages used by the Gateway interface.

    A ready to run package with all needed third party classes can be download here (netspool.jar). This still needs some documentation on how to set up job and output directories and signon files.

    In order to compile Waitfor, you will need the Lava Rocks package, or simply remove the DEBUG code in Waitfor which uses it.

    The Spooler class uses the Java General Library for its job queue. We still use JGL 1.1. For later versions, you will need to change the import statements.

    The FIFOSpooler class uses some process id methods from the Java POSIX package.