[MOPSRV.DOC] January 1991 RSTS/E Version V10.0-L MOP Server Version V1.1-12 RSTS/E MOP Server NOTE: The following contact info is out of date and will no longer work Written by Terry Kennedy Operations Manager, Academic Computing Saint Peter's College 2641 Kennedy Blvd Jersey City, NJ 07306 (201) 435-0252 terry@spcvxa.spc.edu terry@spcvxa.bitnet OVERVIEW: RSTS/E MOP Server performs the following functions: o Provides the operating software for DECservers upon request by the server. o Receives crash dumps from DECservers upon request by the server. Such crash dumps are in the proper format for analysis by DEC software support. o Logs all requested and successful load/dump requests to the system console (in DECnet/E event format) and to a log file. RSTS/E MOP Server can be configured to accept or reject requests from servers not in the configuration file. This can be used to restrict loading to a subset of the servers configured on the Ethernet. Additionally, a user-configurable delay is available so that a supported load host has a chance to load the server first, with RSTS/E MOP Server assuming a backup mode of operation. The default load image name for the server is supported via a mapping table which maps the image name requested by the server into a valid RSTS/E file specification. INSTALLATION INSTRUCTIONS: Network distribution is via mailing of the sources and documentation. Thus, network distribution does not contain object or executables. If you receive a tape, there will be a single directory containing all the re- quired files. Steps necessary to install mopsrv: o Copy the entire distribution into a disk directory. This can be a /NO- USER account. I suggest one of the reserved-for-customer-use [0,*] directories. o Define the MOP$ logical: $ ASSIGN/SYSTEM _SY:[somewhere] MOP$: o If you received the distribution as ASCII text (no binaries included), you will need to create the MOPSRV.TSK programs. To do this, you will need the Basic-Plus-2 Version 2 compiler. This is done by invoking the MOPSRV.COM procedure: $ @MOP$:MOPSRV You NEED NOT do this step if you received your distribution on tape or via DECnet. o Edit the file MOP$:MOPSRV.CNF to tailor the configuration for your site. This is where you select the supported servers, etc. A configu- ration entry consists of a keyword letter, followed by a space, fol- lowed by a value for the keyword. A sample configuration file is supplied on the distribution kit. A brief discussion of each item follows: H - Host system DECnet address and name. This information is passed to the server when loading is complete. The host name is displayable by issuing the server command "SHO SERVER STATUS". If this host is not on a DECnet, use 0.0 as the host address and some convenient identifica- tion for the host name. Example: H 3.4 SPC11D S - Server identification record. The first field is the server Ether- net address in octet format. This information appears on a barcode label near the Ethernet connector on the server. The second field is the DECnet node number of the server. The third field is the DECnet node name of the server. The node number field is for logging purposes only. The node name field is used for logging, as well as for naming crash dump files received from the server. Example: S 08-00-2B-05-E5-C4 2.1 LT2001 W - Wildcard load flag. Can be either Y or N. If Y, all servers will receive load/dump support regardless of whether they appear in a S configuration record or not. If N, servers not listed in an S configu- ration record will not receive load/dump support from this host. If set to Y and the server is not listed in an S configuration record, crash dumps will be stored using the last three octets of the server Ethernet address as the filename. Example: W Y M - Load image mapping. The first field is the name of the load image as requested by the server. The second field is the RSTS/E file speci- fication for the load image. This mapping is needed since server load images are typically 9 character names which may not be unique in the first 6 positions. The RSTS/E file specification may contain a device and/or PPN specification, or may contain a logical name. It must be a file which exists on the local node. Typically, the load images are stored in the MOP$: directory as well. Note that servers such as the DECserver 550 do not specify a load image name when requesting a load. In such a case, MOPSRV will fabri- cate a load image name consisting of the server Ethernet address. For example, a server with Ethernet address 08-00-2B-11-22-33 would appear to be requesting image 08002B112233.SYS, which would then be translat- ed through an M record to a RSTS/E file specification. Thus, each server can have a unique load image, or they can be mapped to a single load image. Example: M PR0801ENG.SYS MOP$:DS200.SYS D - Delay before responding. Delay the specified number of seconds before responding to a load/dump solicit message. This gives a VAX system time to respond. Useful if you wish to normally load from a supported host, but want to use the RSTS/E system as a backup when the VAX is down. A value of at least 15 is needed to allow the VAX to reliably respond. Values greater than 30 are not generally useful, as the server will time out the request after 30 seconds. Note that this delay is only made when a load/dump solicit message is received - if the request was made explicitly to this host, no delay will be used. Example: D 0 E - Specify an alternate Ethernet device, protocol, or block size. This parameter allows the user to override the default Ethernet param- eters. This function should never be needed, but is provided for debugging purposes. For more information, consult the program source. L - Defines the logging level desired. Level 0 logs all events, and is suggested for your initial installation. Level 1 logs all events except load/dump solicit messages. Any load/dump processing by this system will still be logged. This is a good value to use if you have a busy network with lots of servers loading (and dumping?) that you don't want to know about. If you select this level, you whould proba- bly turn off wildcard load/dump support (with "W N") or this server will try to load/dump anyway. Level 2 supresses all logging informa- tion. Example: L 0 Q - Terminates the scan of the configuration file. Example: Q o Ensure that the protection code of MOPSRV.TSK is <232>, as follows: $ PIP MOP$:MOPSRV.TSK<232>/RE o Edit the system startup file [0,1]START.COM to assign the MOP$ logical and start the MOPSRV job running: ASSIGN/SYSTEM _SY:[somewhere] MOP$: RUN MOP$:MOPSRV o Load the DECserver software appropriate to your server(s) into the location and filename specified by the configuration file M record(s). If you are running RSTS/E Version 10.0 or higher, you can simply use BACKUP to restore the load image from the VMS DECserver load kit and then rename it. If you are running an earlier version of RSTS/E, BACKUP will not be able to directly read the VMS DECserver load kit as the block size is too large. You will have to make other arrangements to obtain a RSTS/E copy of the load kit. [NOTE: The license for the server software is included with the server when you purchase the server from Digital. No license is required to purchase a server load kit. If you have any questions about the licensing of server software, please contact your local Digital office.] MOPSRV EVENT LOGGING: MOPSRV records load/dump messages to the system console (KB0:) in DECnet/E message format. These messages are also stored in the MOPSRV logging file, MOP$:MOPSRV.LOG. Solicit messages will always be logged, regardless of whether the MOP Server is configured to load/dump the server making the request and regard- less of the presence/absence of the appropriate load file. This is useful for determining the server address or load image name for a server you want to add load/dump support for. A sample Solicit message is shown below: Event type 0.3, Automatic line service Occurred 06-Jul-90 03:14 AM on node 3.4 (SPC11D) Circuit UNA-0, Load, Solicited, Node = 2.1 (LT2001) File = PR0801ENG.SYS, Operating system Ethernet address = 08-00-2B-05-E5-C4 Request messages are logged when the DECserver selects this MOP Server host as the host to perform the load/dump operation. Load requests are always preceded by a solicit; dump requests may not be. Event type 0.3, Automatic line service Occurred 06-Jul-90 02:48 AM on node 3.4 (SPC11D) Circuit UNA-0, Load, Requested, Node = 2.6 (LT2006) File = PR0801ENG.SYS, Operating system Ethernet address = 08-00-2B-0A-FD-30 Success messages are logged when a load or dump operation has success- fully completed. As soon as the MOP Server has displayed the Success mes- sage it is free to process requests from another server. Event type 0.3, Automatic line service Occurred 06-Jul-90 02:48 AM on node 3.4 (SPC11D) Circuit UNA-0, Load, Successful, Node = 2.6 (LT2006) File = PR0801ENG.SYS, Operating system Ethernet address = 08-00-2B-0A-FD-30 ERROR CONDITIONS: The MOP Server will normally be idle in an XE or XH state. If you see it in an HB state or receive DECnet event 5.15 (Receive failed - user buffer unavailable) messages, the server has died for some reason. If you ATTACH to the MOPSRV job, you will receive an error message which should be forwarded to me for analysis. During development I experienced several "Device hung or write locked" messages when trying to communicate with the Ethernet portal. Since the documentation states that this indicates a system hardware or software problem, and it was repeatable on several different processors, I suspect some problems with the RSTS/E Ethernet driver. I have not seen any of these problems since the code was completed, however. If the server encounters an unexpected error, it will write a small amount of debugging information to the file MOP$:MOPSRV.DMP. When reporting a problem, please include the information in that file. Note that the MOPSRV dump file is entirely different from terminal server dump files, which are also stored in the MOP$: directory. RESTRICTIONS: The MOP Server is single-threaded, unlike the server on VAX/VMS sys- tems. Thus, if a number of servers simultaneously request service (such as after a power failure), some of them may give timeout messages. The MOP server will get around to loading them after it has finished it's current request. With 12 servers (DS200/250 mix), all servers were simultaneously initialized. Within 5 minutes, all were re-loaded. If you have multiple RSTS hosts running the MOP Server available, they will automatically dis- tribute the loading task equitably. There is no support for configuring server load images which are only host-configurable, such as the DECserver 550 software. The load image will have to be configured on an appropriate host and then loaded onto the RSTS/E system(s) for downloading. Further, it is important to remember to update all hosts which load such servers, in order to have a consistent configuration, whenever the load image is modified or updated. KNOWN PROBLEMS: o This is Version 1.1. All problems reported against V1.0 have been corrected. Feel free to report new bugs or desired features to me for future work. OPTIONAL SOFTWARE: An additional program named CNODE is also supplied on the kit. It provides functionality similar to the VMS CONNECT NODE command. When run, it prompts the user for the name of the node to connect to, which must be in the MOPSRV.CNF configuration file. It then attempts to establish a remote console session to the server's virtual management console. If the console is in use by another user, an error message is displayed. Other- wise, the user is connected to the console. Pressing Control-D will termi- nate your remote console connection. CNODE may be defined as a system command (CCL), in which case the serv- er's node name may be specified on the command line. CNODE may be rebuilt by executing the command: $ @MOP$:CNODE Note that CNODE (like MOPSRV) is single-threaded. However, while MOPSRV will only respond to external load/dump requests, you can use CNODE to attempt to connect to a server that doesn't exist. This will cause your job to hang. To recover, log into another port and use the REMOVE/JOB command to remove the hung CNODE job. The reason this occurs is because the RSTS/E Ethernet driver does not have a "read with timeout" function, and thus the job stalls in an XE (or XH) state. It was felt that the occasional incon- venience outweighed the system impact of using no-wait Ethernet reads.