12.07.2015 Views

SDISC Assembler Call - NetEx

SDISC Assembler Call - NetEx

SDISC Assembler Call - NetEx

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

H307IP NETEX ® User Interfacefor Unisys OS2200 & HMP/IX SystemsRelease 5.0Software Reference ManualMAN-REF-H307IP-04


Revision RecordRevisionDescription01 (01/90) Manual corresponding to release 1.0 released.02 (05/91) Manual updated to correspond to release 1.1. Added the following sections:“COBOL (ACOB) Interface”, “DASSIGN: xxx”, “MAPing NETEX Applications”,and “Utility/Test Programs”.03 (11/92) Revision Packet 460924-01 issued to clarify the descriptions of the siteid, cuaddr,and ssnm system parameters.04 (03/2001) First NESi version of the manual for H307IP, including support for general IP networks,SBCON (ESCON) channels, the NESiGate (IBM Netfinity) adapter, anddocumentation reformat using NESi documentation standards.Portions of text which have been changed or added at this revision are indicated by a bar (“⏐” in the margin.Minor editorial revisions are not indicated.© 2001 by Network Executive Software. Reproduction is prohibited without prior permission of NetworkExecutive Software. Printed in U.S.A. All rights reserved.The U.S. Department of Commerce restricts the distribution of technical information contained in this documentwhen exported outside the U.S. Therefore, careful attention should be given to compliance with all applicableU.S. Export Laws if any part of this document is to be exported.You may submit written comments using the comment sheet at the back of this manual to:Network Executive Software, Inc.Publications Department6420 Sycamore Lane, Suite 300Maple Grove, MN 55369USAComments may also be submitted over the Internet by addressing e-mail to:pubs@netexsw.comor, by visiting our web site at:http://www.netexsw.comAlways include the complete title of the document with your comments.MAN-REF-H307IP-04 Revision Record Page i


PrefaceThis manual describes the H307IP NETwork EXecutive (NETEX) Software for the Unisys 2200 Series operatingsystem. This manual corresponds to the version of NETEX referred to in the Revision Record.This manual is divided into the following sections:“Introduction” introduces NETEX and is intended for all readers. “Intertask Communication”, “NETEX RequestBlock”, “H307 <strong>Assembler</strong> Interface”, and “FORTRAN High Level Interface”, describe how to programusing NETEX and is intended for the application programmer. “Installation”, “User Exits”, and “ConfigurationManagement” describe NETEX installation and is intended for the systems programmer or whoever isinstalling NETEX, and the appendices include a list and description of the error codes and messages issued byNETEX.In this manual, the term “adapter” refers to the channel-attached interface between the Unisys host and theNETEX network.Readers are expected to be familiar with general concepts related to HYPERchannel or DX/E hardware.Readers are not expected to be familiar with NETEX before using this manual. However, an understanding ofprogramming and using the host operating system is required.Page ii Preface MAN-REF-H307IP-04


Reference MaterialThe following manuals contain related information.NumberTitle and Description460350 H301 Bulk File Transfer (BFX) Utility for Unisys Software Reference460257 H302T Print File Transfer (PFX) Transmitter Utility for Unisys Software Reference460495 H302R Print File Transfer (PFX) Receiver Utility for Unisys Software Reference460540 H303 USER-Access for Unisys 1100 User Guide460757 "C" Configuration Manager and NETEX Alternate Path Retry (APR) User Guide460280 NCT Loader Software Reference Manual460580 NETEX Application Programmer’s Interface Software Reference ManualMAN-REF-COSW NESiGate NETEX/IP Offload Channel-to-IP Gateway Reference ManualOther vendor’s manuals are listed below:From StorageTek:Number Title and Description460688 PB225/NB225 Host Interface for IBM or FIPS Channels Customer Reference Manual460910 PB250 ESCON Host Controller Installation and Reference Manual460527 HYPERchannel® Message Formats and Protocol EncapsulationMAN-REF-H307IP-04 Preface Page iii


Notice to the ReaderThe material contained in this publication is for informational purposes only and is subject to change withoutnotice. Network Executive Software is not responsible for the use of any product options or features not describedin this publication, and assumes no responsibility for any errors that may appear in this publication.Refer to the revision record (at the beginning of this document) to determine the revision level of this publication.Network Executive Software does not by publication of the descriptions and technical documentation containedherein, grant a license to make, have made, use, sell, sublicense, or lease any equipment or programsdesigned or constructed in accordance with this information.This document may contain references to the trademarks of the following corporations:Corporation Trademarks and ProductsNetwork Executive SoftwareStorage Technology Corp.IBM CorporationNETEX, BFX, PFX, USER-Access, NESiGateStorageTek, STK, Network Systems, HYPERchannel, HYPERbus,NSC, RDS, Link Adapter, DX, DXENetfinityUnisys CorporationUnisys, 1100, 2200, ClearPath, MASM, FTNThese references are made for informational purposes only.The diagnostic tools and programs described in this manual are not part of the products described.Notice to the CustomerThe installation information supplied in this document is intended for use by experienced System Programmers.Page iv Preface MAN-REF-H307IP-04


Document ConventionsThe following notational conventions are used in this document.Formatdisplayed informationuser entryUPPERCASEMIXedcaseboldlowercasevalueNo delimiterDescriptionInformation displayed on a CRT (or printed) is shown in this font.This font is used to indicate the information to be entered by the user.The exact form of a keyword that is not case-sensitive or is issued in uppercase.The exact form of a keyword that is not case-sensitive or is issued in uppercase,with the minimum spelling shown in uppercase.The exact form of a keyword that is case-sensitive and all or part of it mustbe issued in lowercase.A user-supplied name or string.Underlined parameters or options are defaults.The label of a key appearing on a keyboard. If "label" is in uppercase, itmatches the label on the key (for example: ). If "label" is inlowercase, it describes the label on the key (for example: ).Two keys to be pressed simultaneously.Required keyword/parameter.MAN-REF-H307IP-04 Preface Page v


Glossaryasynchronous: A class of data transmission service whereby all requests for service contend for a pool ofdynamically allocated ring bandwidth and response time.ASCII: Acronym for American National Standard Code for Information Interchange.buffer: A contiguous block of memory allocated for temporary storage of information in performing I/O operations.Data is saved in a predetermined format. Data may be written into or read from the buffers.code conversion: An optional feature in the adapter or host DX interface that dynamically converts the hostdata from one character set to another. An adapter configured with the code conversion has a special 1KRAM that is used for code conversion. This RAM can be loaded with any type of code (for example, ASCII,EBCDIC, et cetera).Configuration Manager: A utility that parses a text NCT file into a PAM file.Coprocessor NETwork EXecutive (CP NETEX): Resides on some types of Processor Interface (PI) boardsand uses the processing and storage capacity of the board. This allows minicomputer users to use NETEXwith minimal impact on host storage and processing.Data Exchange Unit (DX unit or DXU): A chassis containing a nucleus processor, multiple customerselectableinterfaces, and/or coprocessors.DX NETEX: A version of NETEX product specifically designed to operate from a DX unit, driven by softwarerunning on a host. DX NETEX resides on the P/NDNTx board.Fiber Distributed Data Interface (FDDI): An American National Standards Institute (ANSI)-specifiedstandard (X T9.5) for fiber optic links with data rates up to 100 Mbps. The standard specifies: multimodefiber; 50/125, 62.5/125, or 85/125 core-cladding specification; an LED or laser light source; and 2 kilometersfor unrepeated data transmission at 40 Mbps.header: A collection of control information transmitted at the beginning of a message, segment, datagram,packet, or block of data.host: A data processing system that is connected to the network and with which devices on the network communicate.In the context of Internet Protocol (IP), a host is any addressable node on the network; an IP routerhas more than one host address.Internet Protocol (IP): A protocol suite operating within the Internet as defined by the Requests For Comment(RFC). This may also refer to the network layer (level 3) of this protocol stack (the layer concernedwith routing datagrams from network to network).ISO: Acronym for International Standards Organization.link: (1) A joining of any kind of DX networks. (2) The communications facility used to interconnect twotrunks/busses on a network.Network Configuration Table (NCT): An internal data structure that is used by the NETEX configurationmanager program to store all the information describing the network.Network Configuration Table Loader (NCTL): An interactive NETEX application program used for configuringlocal or remote DX NETEX boards, updating their NETEX configuration parameters and/or NetworkControl Table. The NCT Loader takes a pamfile created by the Configuration Manager and transfers it to theNETEX Coprocessor through a NETEX connection.Page vi Preface MAN-REF-H307IP-04


NETwork EXecutive (NETEX): A family of software designed to enable two or more application programson heterogeneous host systems to communicate. NETEX is tailored to each supported operating system, butcan communicate with any other supported NETEX, regardless of operating system.NETEX can reside on the host, on a processor interface board (obsolete), or in a DX unit. The latter twocases use host-resident drivers as interfaces.NETEX is a registered trademark of Network Executive Software.Open Systems Interconnection (OSI): A seven-layer protocol stack defining a model for communicationsamong components (computers, devices, people, and et cetera) of a distributed network. OSI was defined bythe ISO.processor interface (PI): A PI interfaces a minicomputer with an adapter. The PI is a board(s) that containsa microprocessor and memory. The processor interface is generally installed in the host. Some types of PIscontain NETEX.path: A route that can reach a specific host or group of devices.TCP/IP: An acronym for Transmission Control Protocol/Internet Protocol. These communication protocolsprovide the mechanism for inter-network communications, especially on the Internet. The protocols arehardware-independent. They are described and updated through Requests For Comment (RFC). IP correspondsto the OSI network layer 3, TCP to layers 4 and 5.MAN-REF-H307IP-04 Preface Page vii


Table of ContentsRevision Record ..................................................................................................................................................iPreface ................................................................................................................................................................iiReference Material .......................................................................................................................................... iiiNotice to the Reader .........................................................................................................................................ivCorporation Trademarks and Products ...........................................................................................................ivNotice to the Customer ...................................................................................................................................ivDocument Conventions....................................................................................................................................vGlossary ..........................................................................................................................................................viTable of Contents........................................................................................................................................... viiiFigures ...........................................................................................................................................................xiiTables.............................................................................................................................................................xiiIntroduction........................................................................................................................................................1External Interface.............................................................................................................................................1Internal Interaction...........................................................................................................................................1NETEX Connections .......................................................................................................................................1Design Efficiency and Flexibility ....................................................................................................................2Block Segmenting............................................................................................................................................2Alternate Path Retry.........................................................................................................................................2User Exits.........................................................................................................................................................2Remote Operator Interface...............................................................................................................................2Basic I/O Flow.................................................................................................................................................2Host Based NETEX .........................................................................................................................................3IP NETEX........................................................................................................................................................3CP NETEX ......................................................................................................................................................3DX NETEX......................................................................................................................................................3NESiGate Offload NETEX..............................................................................................................................4NESiGate Offload NETEX............................................................................ Error! Bookmark not defined.NETEX and the ISO Model.............................................................................................................................4Session Layer Services ....................................................................................................................................6Transport Layer Services .................................................................................................................................6Network Layer Services...................................................................................................................................7Driver Sublayer Services .................................................................................................................................7Intertask Communication .................................................................................................................................8Session Layer Requests ...................................................................................................................................8General Concept of a Session ........................................................................................................................10Establishing a Session....................................................................................................................................12Data Transfer .................................................................................................................................................14Write/Read Data Transfer..........................................................................................................................14Concurrent Write and Read Data Transfer ................................................................................................15One-Way Data Transfer.............................................................................................................................17Page viii Contents MAN-REF-H307IP-04


Terminating a Session ................................................................................................................................... 20Normal Termination.................................................................................................................................. 20Abnormal Session Termination................................................................................................................. 21Programming Notes....................................................................................................................................... 22Handling Multiple Connections ................................................................................................................ 22Service WAIT Options.............................................................................................................................. 22Satellite Communication........................................................................................................................... 23NETEX Error Recovery Procedures ......................................................................................................... 23NETEX Request Block.................................................................................................................................... 25Rules for NRB Use........................................................................................................................................ 25NRB Fields.................................................................................................................................................... 25NRBSTAT ................................................................................................................................................ 26NRBIND ................................................................................................................................................... 27NRBLEN and NRBUBIT.......................................................................................................................... 27NRBREQ................................................................................................................................................... 28NRBNREF ................................................................................................................................................ 29NRBBUFA................................................................................................................................................ 29NRBBUFL ................................................................................................................................................ 29NRBDMODE............................................................................................................................................ 29NRBTIME................................................................................................................................................. 32NRBCLASS .............................................................................................................................................. 32NRBMAXRT ............................................................................................................................................ 32NRBBLKI and NRBBLKO ...................................................................................................................... 33NRBPROTA and NRBPROTL................................................................................................................. 34NRBRESV1 and NRBRESV2 .................................................................................................................. 34NRBPNAME (NRBOFFER) .................................................................................................................... 34NRBHNAME (NRBHOST)...................................................................................................................... 35NRBRESV3 .............................................................................................................................................. 35NRBUSER ................................................................................................................................................ 35NRBOSDEP.............................................................................................................................................. 35Creating an NRB ........................................................................................................................................... 35Duplicating an NRB ...................................................................................................................................... 35H307 <strong>Assembler</strong> Interface .............................................................................................................................. 36<strong>Assembler</strong> NETEX Request Blocks.............................................................................................................. 36<strong>Assembler</strong> Procedure Format ........................................................................................................................ 37Register Usage .......................................................................................................................................... 37<strong>Assembler</strong> Command Examples ............................................................................................................... 37SOFFER <strong>Assembler</strong> <strong>Call</strong>............................................................................................................................... 38SCONNECT <strong>Assembler</strong> <strong>Call</strong> ........................................................................................................................ 39SCONFIRM <strong>Assembler</strong> <strong>Call</strong>......................................................................................................................... 40SREAD <strong>Assembler</strong> <strong>Call</strong> ................................................................................................................................ 41SWRITE <strong>Assembler</strong> <strong>Call</strong> .............................................................................................................................. 42SCLOSE <strong>Assembler</strong> <strong>Call</strong> .............................................................................................................................. 43<strong>SDISC</strong> <strong>Assembler</strong> <strong>Call</strong>.................................................................................................................................. 44NETEX Procedure Code ............................................................................................................................... 45SWAIT <strong>Assembler</strong> <strong>Call</strong>................................................................................................................................. 46Multiple Activities .................................................................................................................................... 46Fortran Interface............................................................................................................................................. 47MAN-REF-H307IP-04 Contents Page ix


FORTRAN NETEX Request Blocks.............................................................................................................48SOFFR FORTRAN <strong>Call</strong>................................................................................................................................49SOFFR Entry Parameters ..........................................................................................................................49SOFFR Results ..........................................................................................................................................50SCONN FORTRAN <strong>Call</strong>...............................................................................................................................51SCONN Entry Parameters .........................................................................................................................52SCONN Results.........................................................................................................................................52SCONF FORTRAN <strong>Call</strong> ...............................................................................................................................53SCONF Entry Parameters..........................................................................................................................53SCONF Results..........................................................................................................................................53SREAD FORTRAN <strong>Call</strong> ...............................................................................................................................54SREAD Entry Parameters..........................................................................................................................54SREAD Results .........................................................................................................................................55SWRIT FORTRAN <strong>Call</strong>................................................................................................................................56SWRIT Entry Parameters ..........................................................................................................................56SWRIT Results ..........................................................................................................................................56SCLOS FORTRAN <strong>Call</strong>................................................................................................................................57SCLOS Entry Parameters ..........................................................................................................................57SCLOS Results ..........................................................................................................................................57SWAIT FORTRAN <strong>Call</strong> ...............................................................................................................................59<strong>SDISC</strong> FORTRAN <strong>Call</strong>.................................................................................................................................60<strong>SDISC</strong> Entry Parameters ...........................................................................................................................60<strong>SDISC</strong> Results ...........................................................................................................................................61FORTRAN Requestor Program Example......................................................................................................62COBOL (ACOB) Interface .............................................................................................................................64NRB Declaration............................................................................................................................................64NETEX <strong>Call</strong>ing Sequence .............................................................................................................................65Map Requirements.........................................................................................................................................65MAPing NETEX Applications........................................................................................................................66Driver Interface ...............................................................................................................................................67Introduction....................................................................................................................................................67Hardware Protocols........................................................................................................................................67Message Proper..........................................................................................................................................67Driver Directives............................................................................................................................................69Code Conversion .......................................................................................................................................69Assign Logical Address(Path) – DCONNECT .........................................................................................70Release Logical Address (Path) – DDISC.................................................................................................72Transmit Message and Data – DWRITE ...................................................................................................73Input Message and Data - DREAD...........................................................................................................74Obtain Driver Status – DSTATUS ............................................................................................................75Installation........................................................................................................................................................78Prerequisites...................................................................................................................................................78Pre-Installation...............................................................................................................................................78Installation Procedure ....................................................................................................................................78Step 1. Unload Tape ..................................................................................................................................78Step 2. Customize H307 ............................................................................................................................79Step 3. Define Network Configuration and Run the Configuration Manager ...........................................81Page x Contents MAN-REF-H307IP-04


Step 4. Load the PAM Using the NCT Loader ......................................................................................... 82Step 5. Verify Installation ......................................................................................................................... 82Step 6. Re-MAP current H300 Applications (optional)............................................................................ 82Sample H307IP System Configuration ..................................................................................................... 83User Exits ......................................................................................................................................................... 84USEREXIT1.................................................................................................................................................. 84Entry Conditions ....................................................................................................................................... 84Exit............................................................................................................................................................ 84USEREXIT2.................................................................................................................................................. 84Entry Conditions ....................................................................................................................................... 84Exit............................................................................................................................................................ 85User Exits Installation ................................................................................................................................... 85Utility/Test Programs...................................................................................................................................... 86NTXCONS .................................................................................................................................................... 86NTXEAT and NTXGEN............................................................................................................................... 87NTXOFFRS .................................................................................................................................................. 87NTXDATA.................................................................................................................................................... 87NTXOPER .................................................................................................................................................... 87Configuration Manager .................................................................................................................................. 89Using the Configuration Manager................................................................................................................. 89Configuration File ......................................................................................................................................... 90VERSION Statement ................................................................................................................................ 92LOCALNET Statement............................................................................................................................. 93TRUNK Statement.................................................................................................................................... 94HB Statement (obsolete) ........................................................................................................................... 95HOST Statement ....................................................................................................................................... 96ADAPTER Statement ............................................................................................................................... 98LINK Statement ...................................................................................................................................... 102PORT Statement...................................................................................................................................... 104END Statement........................................................................................................................................ 105Network Configuration Example ............................................................................................................ 106Appendix A. NRBSTAT Error Codes ......................................................................................................... 108H307IP User Interface Error Codes ............................................................................................................ 110Appendix B. ConfMang Messages ............................................................................................................... 113First Pass Configuration Messages.............................................................................................................. 113Second Pass Configuration Messages ......................................................................................................... 116MAKEPAM Processing Messages.............................................................................................................. 118Appendix C. Sysgen NODE Statements ...................................................................................................... 119P/NB22x or PB25x DX/Es or NesiGate Interfaces ..................................................................................... 119ESCON/SBCON Interfaces......................................................................................................................... 120Index............................................................................................................................................................... 121Comment Sheet.............................................................................................................................................. 126MAN-REF-H307IP-04 Contents Page xi


FiguresFigure 1. Basic I/O Flow.....................................................................................................................................3Figure 2. ISO Model Communication ................................................................................................................5Figure 3. NETEX and the ISO Model ................................................................................................................6Figure 4. General Concept of a Session............................................................................................................10Figure 5. Establishing a Session .......................................................................................................................12Figure 6. Write/Read Data Transfer .................................................................................................................14Figure 7. Concurrent SREAD and SWRITE requests .......................................................................................16Figure 8. One-Way Data Transfer .....................................................................................................................18Figure 9. Normal Session Termination..............................................................................................................20Figure 10. NETEX Request Block (NRB) Fields..............................................................................................26Figure 11. <strong>Assembler</strong> NRB Definitions.............................................................................................................36Figure 12. FORTRAN Example ........................................................................................................................63Figure 13. NETEX <strong>Call</strong> Sequence Format ........................................................................................................65Figure 14. Format of Message Proper ...............................................................................................................69Figure 15. Driver Status Format ........................................................................................................................75Figure 16. Sample H307IP Configuration .........................................................................................................83Figure 17. 16-bit DREF .....................................................................................................................................99Figure 18. NCT Example.................................................................................................................................107TablesTable 1 . ISO Model ...........................................................................................................................................4Table 2. User Exits and Their Functions ...........................................................................................................84Page xii Contents MAN-REF-H307IP-04


IntroductionThe Network Executive Software NETwork EXecutive (NETEX ® ) family of software products is used withnetwork hardware to enable two or more application programs (which may be on different host computers) tocommunicate with each other at multi-megabit speeds. The NETEX family of software consists of differentversions of NETEX for use with different operating systems, such as this version for use with the Unisys2200 Series. Network Executive Software also has utility programs available for use with NETEX, such asthe Bulk File Transfer (BFX'") utility, to simplify user programming to an even greater degree.The NETEX software resides as a stand-alone real-time program within each host involved in the communication.As an independent program, NETEX allows communications to take place at any time during hostoperations, independently of other functions in the system. The following subsections describe the characteristicsof NETEX and how NETEX uses the International Standards Organization guidelines for open systemsinterconnection.External InterfaceThe NETEX external interface for the application programmer is common for all versions of NETEX.NETEX provides eight requests for use in the programs that call NETEX. These calling programs may bewritten in assembly-level or high-level (such as FORTRAN) languages. NETEX programs written in highlevellanguages may be transported from one host to another (with some changes to account for different wordsizes and other machine architecture variations).NETEX also provides an operator interface that allows the monitoring and controlling of certain NETEXfunctions.Internal InteractionThe internal operation of all supported versions of NETEX are consistent and allow the different versions tointeract freely. Thus any program using NETEX may communicate with any other program on the networkthat is also using NETEX.To facilitate communication between hosts of different manufacture, NETEX supports code conversion.NETEX can call upon DX/Es, HYPERchannel, or NESiGate adapters to do code conversions and data assembly/disassembly(if the adapter has the code conversion option installed).NETEX ConnectionsTo communicate using NETEX, two calling programs first form a connection using a handshake protocol.NETEX then allows this pair of programs to communicate.NETEX allows multiple connections to be established at one time, and also allows one program to have multipleconnections simultaneously.NETEX also supports communications within a single host. A calling program may “connect” to anothercalling program in the same host and exchange information just as if network communications were takingplace.MAN-REF-H307IP-04 Introduction Page 1


Design Efficiency and FlexibilityThe NETEX design enables many applications on the same processor to share the use of the network facility.Programs calling NETEX can be written without regard to the other programs calling NETEX or other drivers.Once NETEX accepts data from the caller, it assumes responsibility for the delivery of the data to its destination.The NETEX subsystem on each host handles flow control, error recovery, and any other special considerationssuch as satellite links.NETEX is designed to optimize data transfer throughput using a high degree of “parallelism”. That is, undernormal circumstances, adapter I/O, NETEX buffer management, and user file I/O will all be taking place concurrently.This means that the effective data transfer rate will be as fast as possible (in the multi-megabitrange).Block SegmentingThe NETEX products provide block segmenting at the transport layer. NETEX will partition data into segmentsof a specified size for transmission across the network, and will reassemble the segments on the remotehost before delivering the data to the Session-layer calling program on the remote NETEX. This segmentingis transparent to the session user, but provides control of the transmitted block segment size (especially usefulfor satellite communication).Alternate Path RetryAlternate path retry provides the capability for connections to be automatically rerouted on different networkpaths when a failure on a path is detected. This rerouting takes place with no loss of data.User ExitsNETEX provides user exits at well-defined points within the NETEX subsystem for security and accountingpurposes. These exits are essentially “do-nothing” routines that may be replaced by user modules at installationtime. User exits exist before each request starts processing and after processing is complete. It should benoted that, because of the wide variety of user needs, NETEX does not create generalized security and accountinginformation, but allows user exits to provide for these needs.Remote Operator InterfaceNETEX provides a remote operator interface that allows users to issue NETEX operator commands to otherdefined NETEX hosts on the network. Other users may also be the remote operator for this NETEX. See“REMOTE Command” for more information. Security features are provided.Basic I/O FlowThe figure shows the basic I/O flow between two programs using host based NETEX. The calling programcommunicates with NETEX through the NETEX user interface. NETEX then uses the appropriate networkhardware to communicate with the calling program on the other processor.Page 2 Introduction MAN-REF-H307IP-04


Figure 1. Basic I/O FlowHost Based NETEXHost based NETEX is an architecture that is designed for implementation on very large mainframe computers,or on some smaller machines that cannot support the creation of a standard Network Executive Softwaredriver product. Host based NETEX exists on the machine as a subsystem (a separate program residing in amachine that all other users in the machine can call on to perform services). User tasks produce a NETEXrequest that is delivered to the independent NETEX program using an inter-task communications facility thatis provided by the host operating system. Data is moved so it is present in the NETEX program and the I/O isperformed in the NETEX program.Host based NETEX provides an administrative capability to the system programmers and system managers.Since the NETEX program performs all I/O, no data can be introduced on the network without first beingchecked by NETEX.Host based NETEX products are implemented in <strong>Assembler</strong>, ‘C’, and other languages.IP NETEXThis is the new generation of host-based NETEX products that provide support for standard IP networks,rather than HYPERchannel trunk and HCM/FDDI media only. These products are an extension of and retainall the features available in the previous generation of the host-based NETEX model.CP NETEXCoprocessor (CP) NETEX is very similar to host based NETEX, but is inside the StorageTek DX/E adapter.CP NETEX uses the processing capability of the PI, thus eliminating the drain on the host’s storage and processingcapabilities. A CP NETEX driver resides in the host to provide a programming interface to the CPNETEX. This architecture is now discontinued.DX NETEXThe NETEX product is similar to CP NETEX in that NETEX processing is removed from the host. TheNETEX program resides on the PDNT3 Coprocessor board in the DX/E in a HYPERchannel network environment.Only the Hxx7R NETEX Requester user interface program or an Hxx7 channel driver user interfacelibrary resides on the host.MAN-REF-H307IP-04 Introduction Page 3


NESiGate Offload NETEXThis NETEX product is similar to the DX NETEX product in that processing is removed from the host. TheNETEX program resides as either LAN Offload or Channel Offload software running in the NESiGateadapter. Only the Hxx7IP Requester or user interface program resides on the host. In this implementation,Hxx7IP.NETEX and the ISO ModelIn creating NETEX, Network Executive Software followed the guidelines set by the International StandardsOrganization (ISO) for Open Systems Interconnection (OSI). Open Systems Interconnection refers to the exchangeof information among terminal devices, computers, people, networks, and etcetera that are open tocommunication with one another.The ISO model is composed of seven layers. Each layer interacts only with adjacent layers in the model (seeTable 1). By using this modular structure, the internal function of each layer is self-contained and does notaffect the functioning of other layers.Table 1 . ISO ModelLayerApplicationPresentationSessionTransportNetworkData LinkPhysicalMajor FunctionsHigh level description of data to be transferred and the destination involvedSelect data formats and syntaxEstablish session connection, report exceptions, and select routingManage data transfer and provide NETEX-to-NETEX message deliveryPoint-to-point transfer, error detection, and error recoveryData link connection, error checking, and protocolsMechanical and electrical protocols and interfacesAlthough each layer physically interacts only with adjacent layers, each layer appears to communicate directlywith the corresponding layer of the other model. Figure 2 illustrates this concept.Page 4 Introduction MAN-REF-H307IP-04


Figure 2. ISO Model CommunicationNote:The corresponding layers appear to communicate directly as indicated by the lines with arrows, butactually they communicate only by progressing down through the layers of one model, through thephysical media, and up through the layers of the other model.Figure 3 shows that the DX/E unit’s HYPERchannel interface hardware and firmware or the NESiGate ChannelOffload adapter’s hardware and firmware form the lower two layers. The DX NETEX Coprocessor or theNESiGate LAN Offload software comprises the next three layers. The NETEX software provides completesession, transport, and network layer interfaces. This leaves the user free to write the application programsthat use NETEX or to use Network Executive Software utilities.MAN-REF-H307IP-04 Introduction Page 5


Figure 3. NETEX and the ISO ModelSession Layer ServicesAs the highest layer within NETEX (referring to the ISO model above), the NETEX session layer softwareprovides the general interface to the user’s application/utility program. The NETEX session layer servicesinclude: program-to-program connection using the best available network path, reading data, writing data,disconnection, and statistics gathering. The user requests these services using a standard NETEX RequestBlock (NRB) (containing parameters), and the NETEX requests described in “NETEX Session Services”.The session layer software implements user requests by requesting services from the underlying transportlayer.Transport Layer ServicesThe transport layer provides the actual data movement services for NETEX. This is an internal layer usedonly by the session service code, not the end user. It transmits and receives user data, along with internalprotocol information, to provide fast, efficient communications over the network. The transport layer accomplishesits function by performing services for the session layer software above it and by requesting servicesof the network layer below it.The transport software manages the network path chosen by the session software. The session user does notneed to be concerned with the actual hardware and software used to transmit data, nor with NETEX-to-NETEX message delivery. The transport layer sets up hardware and software tables, provides buffering, andestablishes linkages to manage the flow of information. Also, the protocol used by the transport layer softwareprovides true full-duplex communications between subsystems, permitting asynchronous reads andwrites. Because the transport layer provides a full-duplex operation, data can flow continuously, as long as itPage 6 Introduction MAN-REF-H307IP-04


is being supplied by the user. This keeps the communications link as busy as possible and assures timely arrivalof data to the user.Network Layer ServicesThe network layer software provides link independence for the higher layers of NETEX and assumes responsibilityfor keeping the network interfaces busy. This is an internal layer used only by the internal transportservice, not the end user. The network layer formats the message proper to route the data through the network.If the protocol information overflows the HYPERchannel message proper, the network layer splits thedata transmissions into two driver requests. The network layer also multiplexes network connections overcommon driver connections and manages those driver connections.Driver Sublayer ServicesThe driver sublayer software is the interface between the network sublayer and the physical network device.The driver converts network sublayer I/O for a particular network path into a form which is understandable tothe devices. The driver delivers and receives network messages and associated data to and from the networkadapters. The driver also allows retry and error recovery for network adapters, supports assembly/disassembly,and code conversion options, if these are provided by the adapter type and requested by theuser’s data mode parameter.MAN-REF-H307IP-04 Introduction Page 7


Intertask CommunicationNETEX is a subsystem that provides the application programmer with a means to perform intertask communication.Like other subsystems, users can call upon NETEX to perform services, provided NETEX residesin the host of each task that is communicating.To communicate using the session layer of NETEX, the calling programs must first establish a session connection.Once the session is established, data transfer may take place in a variety of ways, depending on theneeds of the calling programs. One important feature of NETEX is that NETEX uses internal error checkingand error recovery procedures, which are transparent for the user. This means that once NETEX accepts data,the user is assured of its delivery (except in the case of catastrophic failures, for example, a machine goingdown or a major problem with the communication line). Sessions may be terminated by either of the partiesat any time, although this should be done by mutual agreement.The purpose of this section is to explain the concepts of intertask communication using NETEX. The followingparagraphs introduce the session layer requests and the general concept of a session, and then describeestablishing a session, the data transfer process, terminating a session, handling multiple connections, satellitecommunication, error recovery procedures, and code conversion.Session Layer RequestsThere are eight active requests used by calling programs to call NETEX at the Session level. These requestsmust be issued in a logical order according to rules described in the following paragraphs. These eight requestsand a table called the NETEX Request Block (NRB) are the calling program’s interface to NETEX.The NRB is updated by the calling program when the program issues requests (either directly or via NETEX),and it is updated by NETEX when requests are completed by NETEX. The NRB is completely described in“NETEX Request Block”.Session layer requests may be issued in <strong>Assembler</strong> or FORTRAN. The formats of the requests in these languagesare provided in “H307 <strong>Assembler</strong> Interface” and “FORTRAN High Level Interface”. However, thefunctions of these requests are the same and are discussed in general terms in this section. Rules for using therequests are also provided in this sectionThe eight active NETEX requests, listed in the approximate order in which they are issued, are as follows.OFFERThis request makes a calling program utilizing NETEX available to another program on either a remotehost or the local host.CONNECTThis requests a session with a calling program that previously issued an OFFER. The program mayinsert values defining characteristics of the upcoming session in the NRB when this request is issued.This request may also write data to the OFFERing program provided the data does not exceed themaximum segment size specified by either the sending or receiving NETEX.CONFIRMThis request specifies the last step to establish the session. The host which initially issued the OFFERreplies to a CONNECT with the CONFIRM request if the characteristics of the session (data blocksize, etc.) specified in the CONNECT are accepted. This request may also write data to the otherprogram provided the data does not exceed the maximum segment size specified by either the sendingor receiving NETEX.Page 8 Intertask Communication MAN-REF-H307IP-04


WRITEThis request sends data to the other program. The WRITE request may only be used after a sessionhas been properly established. The WRITE request is an asynchronous service (the user is free tocontinue as soon as NETEX accepts the WRITE). A datamode may be specified to invoke code conversionand data assembly or disassembly.READThis request receives data that has been written by another program. The READ request is also usedto accept indicators such as CONFIRM, DISCONNECT, and CLOSE. The READ request is anasynchronous service, so the user may continue as soon as NETEX accepts the READ request.WAITThis request is specified as part of a request or as a separate request. WAIT suspends processing onthe issuing program until NETEX completes the previous request. In the case of WRITE,CONNECT, CONFIRM, CLOSE, or DISCONNECT requests, NETEX accepts the request quicklyand the issuing program can consider the request complete. In the case of READ and OFFER requests,the request doesn't complete until the other program issues a WRITE, CONNECT,CONFIRM, CLOSE, or DISCONNECT request, or the read timeout value is reached.CLOSEThis request specifies the last write operation for a connection. The CLOSE request is issued togracefully terminate a connection. It may contain data just like a WRITE request, but it also indicatesthat the sender is ready to terminate the connection. After the CLOSE is issued, incoming data maycontinue to be read, but no other messages may be written. When the other party in the connection issuesa CLOSE, the session is gracefully terminated.DISCONNECTThis request immediately terminates a connected session. The DISCONNECT request may be issuedby either program at any time. This request may also write data to the other program provided thedata does not exceed the maximum segment size specified by either the sending or receiving NETEX.Also, NETEX can not guarantee that data sent with a DISCONNECT will be read by the receivinghost.These requests are used during the session as described in the following paragraphs.MAN-REF-H307IP-04 Intertask Communication Page 9


General Concept of a SessionBefore explaining in detail how each part of a session is programmed, the following sections explain the generalconcept of a simple NETEX session.This figure shows a simplified example of a session where one program reads data from another.Figure 4. General Concept of a SessionThe following text describes the session flow shown above:1. <strong>Call</strong>ing program A1 in host A issues an SOFFER. his indicates that program A1 is available to serviceother calling programs.2. <strong>Call</strong>ing program B1 requires a file controlled by program A1. To initiate a data transfer session, programB1 issues an SCONNECT request. This request may contain data to be delivered to the offering program.3. When the SCONNECT completes (that is, when it is accepted by NETEX), program B1 issues anSREAD to prepare to receive program A1’s response to the SCONNECT.4. When the SCONNECT is received by the NETEX in A1’s host, the SOFFER completes with a ConnectIndication and with B1’s SCONNECT data in the buffer associated with A1’s SOFFER. If program A1Page 10 Intertask Communication MAN-REF-H307IP-04


finds the conditions associated with the SCONNECT acceptable, it responds by returning an SCONFIRMrequest.If program A1 finds any conditions associated with the SCONNECT to be unacceptable, it would<strong>SDISC</strong>ONNECT the session and may return data specifying the reason for the <strong>SDISC</strong>ONNECT. For example,if one program determines the other program does not have the proper security code for data inthat database, the session may be disconnected (<strong>SDISC</strong>ONNECT).The SREAD that program B1 previously issued now indicates program A1’s response. If program A1 issuedan SCONFIRM, the SREAD will show a Confirm indication along with the data sent with theSCONFIRM. If program A1 issued an <strong>SDISC</strong>ONNECT, the SREAD will complete with a Disconnectindication.5. The programs may now begin the data transfer. Program B1 issues an SREAD to prepare to receive datafrom program A1. Program A1 writes data to program B1. The SWRITE command is used until the lastdata is written. An SCLOSE is used to write the last data. Since we are only issuing one write request inthis example, the SCLOSE is used.6. After completion of the last data transfer, program A1 issues an SREAD to detect program B1’s next request.7. Program B1 issues an SCLOSE and the session is terminated. Both programs may perform disconnectfunctions (closing files, etcetera). Program A1 could then SOFFER itself as ready for another session.This is a simplified example of a session. The following sections describe how to program NETEX by describing(in detail) establishing a session, data transfer, and terminating a session.MAN-REF-H307IP-04 Intertask Communication Page 11


Establishing a SessionThe following figure is a flow chart showing how a connection is established using the session layer interface.Only steps which may occur in a normal process are shown in the figure. Other possibilities that are lesslikely to occur are discussed in the accompanying text.This figure references an NRB. An NRB (discussed in “NETEX Request Block”) is a block of parametersused to signal requests to NETEX and to return status to programs.Figure 5. Establishing a SessionThe following numbered items refer to the steps above. The steps are numbered to simplify the discussionand do not necessarily represent the exact order which the events occur.1. Program A prepares for the session by opening files and creating an NRB.2. Program A issues an SOFFER to make it available to other NETEX programs. The SOFFER may specifya data area for data associated with an upcoming SCONNECT.Page 12 Intertask Communication MAN-REF-H307IP-04


3. Program B is a program that needs to establish a session with program A. Program B must first open filesand create its own NRB.4. Program B then issues an SCONNECT. The SCONNECT may contain data such as a password5. Program B then checks the NRB to determine the status of the request. The NRB indicates one of thefollowing:• a request is in process• a request has completed successfully• the request has generated an errorThe session continues assuming the NRB indicated normal completion. If the NRB indicates that a requestis in process, it would have to be rechecked after a short delay. If the NRB indicates an error, theerror code would be logged and the session would not be established. The calling program should theneither try again to establish a session, or should act appropriately (such as closing files that were openedbefore the session was attempted).6. Program B expects program A to respond to the SCONNECT with a SCONFIRM or an <strong>SDISC</strong>ONNECT.Program B issues an SREAD which would detect program A’s response.7. Program A checks its NRB to see whether the SOFFER completes. The NRB indicates that program Bhas issued an SCONNECT.If the NRB indicates that an error occurred, program A will act appropriately (which could be disconnectingfrom this session and reissuing the SOFFER).A password may be required at this time. The password could be sent as data associated with theSCONNECT. After the SCONNECT is received, the password is examined. The password could beused to restrict access to certain files, restrict access by certain programs, or have other customized uses.If a program attempts to access restricted files or has an incorrect password, program A may issue an<strong>SDISC</strong>ONNECT and terminate the session.8. If all conditions associated with the SCONNECT are acceptable, program A issues a SCONFIRM to establishthe session. The SCONFIRM may contain data.9. Program A checks the NRB to make sure that the SCONFIRM was accepted by NETEX. If it was, programA will continue with the session. If NETEX did not accept the SCONFIRM, program A will eitherretry issuing the SCONFIRM or take other appropriate action.10. Program B checks the NRB to determine if the SREAD has successfully completed and to see what callprogram A issued. If program A had responded with a SCONFIRM, program B would continue with thesession. If program A had responded with an <strong>SDISC</strong>ONNECT, program B would have to examine thereason code associated with the <strong>SDISC</strong>ONNECT, and take the appropriate action.The previous discussion outlines the rules to be followed when establishing a NETEX session. It also introducesthe concept of using the NRB for communication with NETEX. After requests are issued, the NRB isexamined to see when NETEX completes the request. This may be done using the SWAIT request, or by periodicallychecking the NRB fields. The NRB fields are discussed in “NETEX Request Block”.MAN-REF-H307IP-04 Intertask Communication Page 13


Data TransferUnlike the rules for establishing a session, NETEX provides a lot of flexibility in how session requests areused for the data transfer process. The following sections describe two methods for programming data transfer.The first method is a basic data transfer technique, the second uses the more advanced technique of concurrentSWRITE and SREAD requests.Write/Read Data TransferThe following paragraphs describe the session requests that are used to transfer data in a straight-forwardway. Usually, calling programs use the SREAD and SWRITE requests to perform the data transfer. The figureshows how the calling programs perform the data transfer. SWRITE requests are issued by one programwhich must be received by an SREAD issued by the other program.Figure 6. Write/Read Data TransferThe following numbered items describe the steps in the figure above. The steps are numbered to simplify thediscussion and do not necessarily represent the exact order which the events occur.1. After a session has been established, program A issues an SREAD. The SREAD specifies the buffer forreceiving data.Page 14 Intertask Communication MAN-REF-H307IP-04


2. Program B issues an SWRITE. The SWRITE specifies where the data to be written is located and howlong it is.3. Program B checks the NRB to see if NETEX accepted the SWRITE or indicated an error.Once NETEX has accepted the data, NETEX will deliver the data unless a catastrophic loss of connectionoccurs.4. Program B issues an SREAD to detect program A’s next request.5. Program A received an updated NRB which indicates what program B has issued. In this case, programB has written data as program A expected. If the NRB word indicated an error, program A will act appropriately.If program B issued an <strong>SDISC</strong>ONNECT, program A will check the reason for the <strong>SDISC</strong>ONNECT andact appropriately.6. Program A is programmed to SWRITE some data back to program B. Program A issues an SWRITEspecifying the location of the data to be written.7. Program A verifies that NETEX accepted the SWRITE by checking the NRB. If the NRB indicates theSWRITE was not accepted, program A will act appropriately.8. Program B checks the NRB and determines what program A issued.Both programs continue with the data transfer until they have completed their functions.As when establishing a session, the SWAIT request may be used with other requests. Abnormal terminationsare discussed “Abnormal Session Termination” .Examples of programs are found at the end of “FORTRAN Interface”.Concurrent Write and Read Data TransferA more advanced method of data transfer uses read and write requests that are issued without expecting theother calling program to respond immediately. This type of technique is used for satellite communication,discussed in “Satellite Communication”, but it is also well-suited for local data transfer.Because NETEX will only accept one request using a specific NRB, two NRBs must be created by each programto perform concurrent read and writes. One NRB establishes the session, as previously described, and asecond is created before data transfer begins. The second NRB must be created as a copy of the first to ensurethat NETEX internal words are preserved.The figure shows how the programs perform the data transfer. As an example of what work the program isdoing, consider the following: Program A first requests data from program B. Program B then writes datauntil program A writes an acknowledgment or another message.Note:Program A does not respond to every SWRITE issued by program B. When program A has receivedwhat it needs, it terminates the session using the termination procedure discussed in “Terminating aSession”.MAN-REF-H307IP-04 Intertask Communication Page 15


Figure 7. Concurrent SREAD and SWRITE requestsThe following numbered items describe the steps above. The steps are numbered to simplify the discussionand do not necessarily represent the exact order which the events occur.1. After a session has been established, both programs create duplicate NRBs for the SWRITE requests.The NRBs created before the sessions were established are assumed to have been called RNRB, and willbe used with SREAD requests. New NRBs called WNRB are duplicates of the RNRB which will be usedwith the SWRITE requests2. Both programs issue an SREAD request to prepare to receive requests from the other program. TheRNRB is specified in the SREADs as the place for NETEX to respond to that request.3. Program A issues an SWRITE to program B. The SWRITE contains a request for specific data from programB. The WNRB is specified in the SWRITE as the place for NETEX to respond to that request.4. Program A checks the WNRB to see if NETEX accepted the SWRITE or indicated an error, and acts accordingly.Page 16 Intertask Communication MAN-REF-H307IP-04


5. Program B, which has been checking the RNRB or waiting for it to complete, receives the SWRITE fromprogram A. This SWRITE contains parameters which program B will use to determine what data to sendto program A.6. Program B issues another SREAD which will be “floating” while processing continues.7. Program B begins to SWRITE the data requested by program A. The WNRB is specified to monitor theSWRITE requests.8. Program B checks the WNRB to make sure NETEX accepted the SWRITE.9. Program A checks its RNRB and discovers the SWRITE issued by program B.10. Program A processes the files received. If program A has not yet received all the data it asked for in step3 and wishes to continue reading, it jumps to step 11. If program A wishes to respond to program B (tostop the transfer or to request other data), it jumps to step 12 and SWRITEs an appropriate message.11. Program A issues an SREAD to continue receiving information from program B.12. Program A SWRITEs an acknowledgment or a message to program B. Since program B has an SREADfloating, it will receive this SWRITE.13. Program B checks the RNRB. If the SREAD has completed (meaning program A has written something),program B continues with step 14. If the SREAD is still pending (or floating), Program B continuesWRITING data to program A by jumping back to step 7.14. Program B responds to program A’s SWRITE. This response could include starting to transmit otherdata, receiving an acknowledgment, recording a message, terminating the session, etcetera.15. The session is terminated normally when program A has received all the data it wanted, or by special requestof one of the programs. Session termination is described in “Terminating a Session”.The previous example demonstrates the technique of using SREAD and SWRITE requests concurrently.Waits should only be used after SWRITE requests when using this technique. Abnormal terminations are discussedin “Abnormal Session Termination”.One-Way Data TransferA typical use of NETEX is a one-way data transfer. The following figure shows how a one-way data transfercould take place. Programs A and B establish a session as described earlier in this section. Program A, whichwill receive data, creates a single NRB. Program B, which will send data, creates an RNRB (for monitoringSREAD requests) and a duplicate WNRB (for monitoring SWRITE requests).MAN-REF-H307IP-04 Intertask Communication Page 17


Figure 8. One-Way Data TransferThe following numbered items describe the steps in the figure above. The steps are numbered to simplify thediscussion and do not necessarily represent the exact order which the events occur.1. Program A issues an SREAD request to prepare to receive data.2. Program B issues an SREAD request to receive unexpected SWRITEs from program A. For example, ifprogram A were unable to receive more data, it could notify program B using a previously determined setof indicators. Normally, this SREAD would not complete until all the information has been transferred.3. Program B issues an SWRITE to transfer data to program A. An “End of Data” indicator is placed in thedata field with the last piece of information. Program B checks the WNRB to see if NETEX accepted theSWRITE or indicated an error, and acts accordingly.4. Program A checks the NRB to see if the SREAD completed. If it did not complete, program A continuesto check it. When the SREAD completes, program A processes the incoming information, and checks forthe “End of Data” indicator. If there is more data coming (indicator not set), program A issues anotherSREAD (step 1). If this is the last piece of information, program A continues with step 5.5. Program A issues an SWRITE acknowledging that all of the information has been received. (NETEX hasverified the integrity of the data.)6. Program B checks the RNRB. If RNRB is still in progress (because program A has not written anything),program B jumps back to step 3 and SWRITEs more data. If all data has been written, program B will issuean SWAIT to suspend execution until program A returns a response. When the RNRB completes,Page 18 Intertask Communication MAN-REF-H307IP-04


program B checks the data written by program A. Normally, this would be an acknowledgment of the lastpiece of data. In that case, program B would continue with step 7. If a problem is encountered, programB acts accordingly.7. Program B terminates the session. Terminating a session is described in the following section.In the previous example, SWAIT requests may be used freely by program A, but should generally be usedonly after SWRITE requests by program B. An SWAIT could be issued by program B to wait on the RNRBafter all data has been written.Abnormal terminations are discussed in the following section.MAN-REF-H307IP-04 Intertask Communication Page 19


Terminating a SessionNETEX sessions can terminate either normally or abnormally. A normal termination is planned by the programsinvolved. An abnormal termination is any unplanned termination of the session.Normal TerminationThis figure shows the exchange of session calls associated with normal (planned) termination. The steps arenumbered to simplify the discussion and do not necessarily represent the exact order which the events occur.Figure 9. Normal Session TerminationThe following numbered items refer to the steps in the figure above.1. Program A has a previously issued SREAD pending.2. Program B issues an SCLOSE. The SCLOSE takes the same form as an SWRITE request.3. Program B checks the NRB to verify that the SCLOSE was accepted by NETEX. If it was accepted, programB may close output files or perform other termination processing. No other NETEX write-type requests(except <strong>SDISC</strong>ONNECT) may be issued by program B during this session. If the SCLOSE is notaccepted, Program B must act appropriately (check if NETEX is down or if the other application is notthere).4. Program B issues an SREAD. Program A may still write data to program B, or program A may issue anSCLOSE or an <strong>SDISC</strong>ONNECT to terminate the session.5. Program A detects the SCLOSE.6. Program A issues an SCLOSE to terminate the session. Data may be associated with this request. ProgramA may issue any number of SWRITE requests before the SCLOSE.Page 20 Intertask Communication MAN-REF-H307IP-04


7. Program A checks the NRB to make sure that the SCLOSE completed successfully. Program A closesfiles and performs other termination processing.8. The SREAD issued by program B completes and the NRB indicates that the session has been terminated.Program B closes files and performs other termination processing.Abnormal Session TerminationThe program must be able to react to abnormal terminations. Sessions may be abnormally terminated by theother program or by NETEX.Sessions may be unexpectedly terminated by the other program for various reasons depending on how theprogram is written. Some typical reasons for immediate termination are as follows:• A program fails to provide the proper password or authorization for a session.• A program attempts to access data that it was not authorized to access.• The program detected an internal failure such as a program check.• A time limit was reached.• A program encountered problems issuing a request to NETEX.Some of these problems may be eliminated by reconnecting with the calling program.NETEX may terminate a session unexpectedly because of problems with the physical network or with a hostcomputer. This type of error may not necessarily be solved by simply reconnecting with this host. Alternativesshould be provided in the calling program.MAN-REF-H307IP-04 Intertask Communication Page 21


Programming NotesThe following sections provide supplemental information intended to make programming NETEX simpler.The following topics are discussed:• Keeping NETEX Active• Handling Multiple Connections• Service Wait Options• Satellite Communication• Error Recovery Procedures• Code Conversion OptionsHandling Multiple ConnectionsNETEX provides the capability for a program to be simultaneously connected to more than one other callingprogram. Requests coming from different connections are identified using the NRBNREF word of the NRB.NRBNREF contains a unique number assigned to a connection when it is established. The capability to handlemultiple connections enables the programmer to establish database server and requestor programs.Database server programs allow a network of hosts to use each other’s databases. A database server programsimply OFFERs itself to other hosts. When another host (a requestor) establishes a connection, the serverSREADs or SWRITEs files to or from its database as specified by the requestor.Database server programs may issue multiple offers (SOFFER) by specifying a different NRB with eachSOFFER. The offers (SOFFER) are completed in the order that they are issued. Many users on one machinemay issue multiple offers, if each is generated as though it were an individual host.Program B in the concurrent write/read example is an example of a simple database server. Program BSWRITEs the files program A requests, and then waits for more instructions. More sophisticated databaseservers could allow themselves to connect to several requestors at one time.Program A in the last example is a simple example of a database requestor.Service WAIT OptionsOn each session call, the user has the option to wait or not to wait for the request to complete. If waiting isdesired, then the “W” form of the call should be used. The User Request Manager will issue the wait on theuser’s behalf and return control to the user when the NRB is posted.The SWAIT request may be used to wait on a single NRB, a list of NRBs, or may be used to wait on zeroNRBs. The way to use the wait request depends on the situation.• If servicing a single connection where data moves logically in only one direction, use the wait option onthe requests.• If servicing multiple simultaneous connections, or a single connection where data flows both ways, useSWAIT(n) to wait on a list of NRBs.• When servicing both NETEX and a real-time application, use SWAIT(0) to wait on zero NRBs, thencheck the real-time device. When issuing an SWAIT on zero NRBs, check the NRBSTAT fields of theNRBs for the requests that you are interested in.Page 22 Intertask Communication MAN-REF-H307IP-04


The following points apply to waiting:• A request cannot be marked complete until it is waited on.• The NRB and the data buffer cannot be reused until the request is complete.Satellite CommunicationThe standard NETEX requests may be used when satellite communications facilities are a part of the network.NETEX was designed and implemented with the capability to recover from errors and lost messages usingprotocols which make the solving of these problems transparent to the user.Important: Because of the long propagation delay inherent in the satellite subsystem (approximately 600microseconds), you must keep the communications channel “full” of data. Do this by usingconcurrent SREADs and SWRITEs which transmit data in large amounts before having thewriting application stop to wait for an acknowledgment from the reading application. In thisway, data is transmitted rapidly and the propagation delay has less effect on performance.(This technique requires a large buffer area.)For example, if the calling programs acknowledge every block written in one direction with a correspondingacknowledgment written in the other direction, the propagation delay would have major impact. But, if anentire file is transmitted before an acknowledgment is returned, the effect of the propagation delay is minimized.Minimizing the effect of the delay in this manner must be balanced with the consideration that if there is acatastrophic failure of the link, NETEX, or the other host, there is no way to know how much unacknowledgeddata was successfully received.Determining the frequency of the checkpoint acknowledgments is an important consideration. This decisionmust be made by considering the needs of individual implementations.NETEX Error Recovery Procedures<strong>Call</strong>ing programs must be able to recover from errors identified by NETEX. These errors will be returnedwhen a NETEX operation does not complete successfully. The following sections describe the NETEX errorcodes and some common error recovery procedures.Error CodesWhenever a NETEX request is issued, the results of the request are returned in one or both of two NRB fields,NRBSTAT and NRBIND. These are located at the beginning of the NRB to make their subsequent examinationby high level language programs a simpler matter.NRBSTAT indicates whether an operation is in progress. If the operation is no longer in progress,NRBSTAT also indicates whether the operation completed successfully or not. NRBIND indicates the typeof information that arrived as the result of a read-type command (SREAD or SOFFER).When an operation is accepted by the NETEX user interface, the value of NRBSTAT is set to the local valueof -1. Thus, the sign of this word is an “operation in progress” flag for all implementations.If an operation completed successfully, NRBSTAT will be returned as all zeroes. If a read-type commandwas issued, then an “indication” will be set in NRBIND when the SREAD completes.If the operation did not complete successfully, then NRBSTAT will contain a standard error code.NRBSTAT is represented as a decimal number that is potentially as large as 2 15 -1 (32,767) The 2 16 bit is notMAN-REF-H307IP-04 Intertask Communication Page 23


used so that it may remain an “in progress” flag for the 16 bit machines. The error codes are listed and describedin 205.Common Error Recovery ProceduresThe following are commonly encountered errors with an explanation of how to recover from them:• Other program not there - Operators or users must coordinate the running of the two NETEX programs sothat one has not timed-out before the other has had a chance to establish a session.• Other program busy - Retry NETEX after a suitable delay.• NETEX requests out of sequence - Sessions must be completely established before write or read requestscan be issued. Sessions are established using the offer, connect, and confirm requests in that orderCode ConversionNETEX provides for common types of code conversion by using StorageTek hardware or NETEX softwarefacilities. The calling program uses the datamode (NRBDMODE) word of the NRB to specify either manualor automatic code conversion.If manual conversion is selected, the caller completely specifies which assembly/disassembly and code conversionfunctions will be used on both adapter output and adapter input. The caller must determine whichassembly/disassembly modes and code conversion tables are significant to the adapters.If automatic code conversion is selected, the caller simply specifies the source character set and the destinationcharacter set. NETEX then uses any code conversion hardware that is available, and carries out othercode conversion using software when necessary.Page 24 Intertask Communication MAN-REF-H307IP-04


NETEX Request BlockThe NETEX Request Block (NRB) is a block of parameters used to pass information between calling programsand NETEX. The NRB is the means by which programs and NETEX communicate with one another.The NRB is created by a calling program and may be updated by the program to pass information to NETEX,or NETEX may update the NRB to pass information to a program.Each time a program makes a request to NETEX, the program specifies an NRB to be associated with the request.NETEX passes status information about that request back to the program by way of the NRB. Therefore,only one NETEX request may use an NRB at one time. If concurrent read and write requests are used,or if a server program will be connected to more than one program at a time, several NRBs must be used.The use of the NRB fields vary slightly between the different levels of programmer interface. Specific differencesare described in the individual field descriptions that follow.Rules for NRB UseThe following principles are designed to make high level language use of NETEX somewhat transportablebetween machines.• Before initiating a connection, the user must clear the NRB, including the operating system dependentportion, to zeroes. When the connection is initiated, the user places whichever non-default values areneeded in the user part of the NRB, and invokes NETEX service. Once the connection is initiated, theuser must not change the OS dependent part of the NRB between calls to NETEX.• If the calling program is using the connection in a full duplex manner, the user will need to make a copyof the NRB to produce a “read NRB” and a “write NRB.” This copying operation is the copying of all 40fields of the NRB to another area, at a time when the NRB being copied is not active. If a second requestfor the same connection is issued from the copied NRB, the user interface must detect the condition andhandle that new part of the connection accordingly.• Many NRB values are specified in addressable units. An addressable unit is the amount of informationcontained in one memory location for that machine. For example, a CDC CYBER has an addressableunit of 60 bits, Unisys OS2200 is 36 bits, IBM and Digital are generally 8 bits, Tandem is 8 bits, and soon.NRB FieldsThe following figure shows the fields in the NRB. All NRB fields are one words long. The NRB containsforty fields.Many of the NRB fields are or could be updated by either the program or NETEX with every request. However,the fields NRBCLASS, NRBMAXRT, NRBBLKI, NRBBLKO, NRBRSV, NRBOFFER, andNRBHOST are associated with the session negotiation process. Information in these fields is updated byNETEX as their values change. These fields are initially specified during the OFFER and CONNECT requests.When the offering task receives the connect, the negotiated values are set in the offered NRB. Whenthe SCONFIRM is sent, the negotiated values are set in the NRB associated with the read of the SCONFIRMinformation. Subsequent attempts to change these fields will have no effect.MAN-REF-H307IP-04 NETEX Request Block Page 25


NRBINDNRBIND indicates the type of data received in response to a read, offer, or status request. If any of thoseread-type requests are issued, NRBIND will always receive a non-zero value.The values returned in NRBIND are:(1) Connect Indication(2) Confirm Indication(3) Normal data Indication(4) Expedited Data Indication(5) Close indication(6) Disconnect indication(7) Status indicationIf a write-type request (write, connect, confirm, close, or disconnect) is issued, the returned value of NRBINDis usually zero. If an error is returned to the write type request that means the connection is broken or wasnever established, then a Disconnect Indication (6) is set in NRBSTAT.If an operation did not complete successfully, then NRBSTAT will be set to a positive, non-zero value. IfNRBSTAT is non-zero, then NRBIND will have one of the following values:• If the error results in the loss of the connection or the connection not being established in the first place,then a Disconnect Indication (6) will be in NRBIND.• If the error means that the request could not be processed but the connection remains in effect, thenNRBIND will be set to zero.• If the data is “damaged” in input (for example, user buffer too small) then NRBIND will reflect the typeof data received.NRBLEN and NRBUBITNRBLEN and NRBUBIT together define the amount of useful data for input and output. NRBLEN specifiesthe number of bytes that are needed to contain the data. NRBUBIT specifies the number of bits in the lastbytes that are not significant information. This allows information to be sent on the network on a logical bitbasis without damaging the data.For example, suppose a CDC CYBER computer wants to send exactly 35 of its 60-bit CM words to an IBMprocessor and wants it returned at a later date. The CYBER user will specify NRBLEN=35 andNRBUBIT=0. Datamode will be bit stream. NETEX will record that 35*60=2100 bits of information wassent over the network. The IBM user will receive the information with NRBLEN=263 (bytes) (8*263=2104bits) and NRBUBIT=4 (bits). The IBM user could later specify the same length parameters on output andreturn precisely 35 CM words back to the CYBER.A second example involving character conversion: Suppose a CRAY wants to send 151 ASCII characters(8*151=1208 bits) to a Unisys and have them converted to Field-data. The CRAY user can specifyNRBLEN=19 (64 bit words) (64*19=1216 bits) and NRBUBIT=8 (bits) since seven characters will be in thetrailing CRAY word. The CRAY driver will send the ASCII over the network and record that 8*151=1208bits of information were sent. The Unisys will select sixth-word A/D mode and code conversion and determinethat (1208/8)*6=906 bits of information will result. It will report to the Unisys caller that NRBLEN=26(36*26=936) and NRBUBIT=30 so a single character will be found in the last of the 26 Unisys words.Note:Those programs that do not need the NRBUBIT can ignore its existence, knowing that handling theinformation specified by NRBLEN will ensure that all information sent by the other machine will bestored or processed.MAN-REF-H307IP-04 NETEX Request Block Page 27


Transmitting or receiving zero-length information is possible. Zero-length data is treated as a separate transmissionand is received at the other end in chronological order (as is any other data). On both the transmitand receive sides, NRBLEN will be set to zero.If NRBUBIT is non-zero, the unused bits are not set to zero or any other value by NETEX. The calling programmust handle any “garbage” that may be placed in the last word of the transfer.NRBREQNRBREQ is the request code that will be given to NETEX. This is a 16-bit binary value that contains thetype of request (example: SREAD) that NETEX is to perform.NRBREQ has the following format:Option Flags (4 bits)The option flags refer to optional processing that NETEX will perform on the request. These flags are bitsignificant. The bits are assigned (represented as hexadecimal numbers) as follows:0xxx Normal processing. NETEX will return control to the caller when NETEX has internallyqueued the request.1xxx to 7xxx Reserved8xxx WAIT. NETEX or the NETEX user interface is not to return control to the user programuntil the request is complete9xxx to Fxxx ReservedService Level (4 bits)The service level indicates whether the request is a SESSION, TRANSPORT, NETWORK, or DRIVER typeof request. The values are assigned (in hexadecimal) as follows:x0xx Session requestx1xx Transport requestx2xx Network requestx3xx Driver requestx4xx to xExx ReservedxFxx Reserved (effects Function values)Function (8 bits)The function indicates the specific type of request to be issued. The values are assigned (in hexadecimal) asfollows:xx01 Connectxx02 Confirmxx03 Writexx04 Reservedxx05 Closexx06 Disconnectxx07 to xx80 Reservedxx81 Offerxx82 Readxx83 StatusPage 28 NETEX Request Block MAN-REF-H307IP-04


xx84 to xxFF ReservedThe total request code is produced by combining the Option, Function, and Service Level. For example, consideran SREAD with wait processing. Wait processing is 8xxx, SREAD is a x0xx Service Level plus a xx82Function. This totals a 8082 (hexadecimal) request code.NRBNREFNRBNREF is the 16-bit, internal NETEX identifier that distinguishes this connection from all others maintainedby this copy of NETEX. When initial connect or offer requests are made at the Driver, Network, orTransport levels, this field must be filled in by the caller. If issued at the Session level, this value is assignedby NETEX when a connection is established. Only the lower 16 bits of the NRBNREF field are used. Thehigh order 16 bits must be zero.NRBBUFANRBBUFA contains the start of the data buffer to be used for either input or output requests. The user mustsupply a valid buffer address before each input or output request. For a write request, the contents of thisbuffer must be left unchanged until the associated NETEX write type request has completed. If a read requestis issued, then the contents of the buffer should be examined when the read request completes successfully.NRBBUFLOn input, NRBBUFL specifies the maximum size of the Pdata (ordinary data) that NETEX can store in thebuffer. This field is effectively ignored on output (NRBLEN and NRBUBIT are used to determine the actuallength of output data). This usage difference allows a NETEX user to associate an NRB with a single bufferand never change this field even if many READs and WRITEs are issued. NRBBUFL is specified in addressableunits.NRBDMODENRBDMODE is specified by the transmitting NETEX program on any write-type request (connect, confirm,write, close, or disconnect) that is issued at the session, transport, network, or driver level. NRBDMODE isalways specified as a 16-bit quantity. Datamode is forwarded through all layers of NETEX. When the receivingentity receives the data, the datamode specified by the transmitter (with possible modifications as describedbelow) is inserted into the NRB associated with the receiving SREAD or SOFFER request.There are two forms of datamode: manual and automatic.Manual DatamodeManual datamode allows complete specification of the assembly/disassembly and code conversion functionson both adapter output and adapter input. In the manual datamode, the caller has total control over the adapterfacilities. The user must determine which assembly/disassembly modes and code conversion tables are significantto the two adapters involved in the transfer. Refer to the appropriate adapter reference manuals forthe adapter being used.The datamode field is always in the “datamode” field of the driver protocol information to assist this incomingdriver function. When the data is received, each driver calculates the amount of useful information receivedbased on the incoming A/D mode specified and passes it up to the user read request. The read NRBwill contain exactly the same datamode field as specified by the transmitter when the original message wassent.MAN-REF-H307IP-04 NETEX Request Block Page 29


Manual datamode has the following format:’1’ The manual mode indicator “1” is in the high order bit.Outgoing A/DThese bits identify the data assembly/disassembly to be performed on data as it goes out ontothe network. This information is added to the “transmit data” function code when the userdata goes over the network.Outgoing Code ConvThese bits identify the code conversion to be performed on data as it goes out onto the network.This information is added to the “transmit data” function code when the user data goesover the network. This field is effectively unused since the A400 processor adapter does notsupport code conversion.’0’ A second manual mode indicator “0” is in the high bit of the low order byte.Incoming A/DThese bits identify the data assembly/disassembly to be performed on data as it goes from thenetwork to the receiving program. This information is added to the “input data” functioncode when the receiving driver gets the message from the network.Incoming Code ConvThese bits identify the code conversion to be performed on data as it goes from the networkto the receiving program. This information is added to the “input data” function code whenthe receiving driver gets the message from the network. This field will only be used if the receivinghost-processor adapter supports code conversion.Automatic DatamodeAutomatic datamode is designed for all common NETEX transfers. When automatic datamode is selected,the user identifies the source and destination character sets, and NETEX selects the appropriate assembly/disassemblyand code conversion. NETEX will perform code conversion only when the selected conversionis significant to the receiving machine. NETEX uses hardware code conversion whenever possible.Automatic datamode supports three conversion options:Bit StreamThe bit pattern sent is precisely reproduced in the destination machine.OctetEight-bit binary quantities are sent from one machine to another, using an 8-bit byte representationappropriate to each machine.CharacterCharacter information is sent from one machine to another with a full range of character assemblyand code conversion options.Page 30 NETEX Request Block MAN-REF-H307IP-04


The conversion options are selected in the NRBDMODE field. The automatic datamode has the followingformat in the NRBDMODE field:’0’ The automatic datamode indicator “0” is in the high order bit.Source Character SetThese bits identify the conversion option (from 2) of the data used in the write buffer of thetransmitter.’0’ The high bit of the low order byte is reserved.Destination Character SetThese bits identify the conversion option (from 2) of the data going to the destination program.For example, a conversion from EBCDIC (3) to ASCII (2) would be entered as thehexadecimal value of 0302 or decimal value of 770.Auto Datamode Character SetsIndicatorConversion Option0 Bitstream mode1 Octet Mode2 ASCII (8-bit)3 EBCDIC4 Reserved5 BCD (Honeywell)6 Field-data (UNISYS)7 Displaycode (CDC)The processing rules for automatic datamode are listed below:• The transmitting driver examines the source character set specified. The character set implicitly specifiesthe method used to represent those characters on the transmitting machine. The driver selects an A/Dmode so those characters will be sent over the network as an 8-bit quantity. If the code conversion memoryis installed, the transmitting driver will select a code conversion function to hardware convert thecharacter set before the information is sent over the network. If code conversion is used, the transmittingdriver sets source character set to the value of the destination character set in the datamode field of theoutgoing message proper.• The receiving driver always reads a message proper in “octet” mode. By examining the datamode fieldand determining that character data is being sent, it selects an A/D mode to convert the 8-bit quantitiescoming over the network to the bit configuration used by the destination character set. If code conversionhardware is installed and the source character set does not equal the destination character set in the messageproper, then the data is code converted on input. Following such conversion the source character setfield in datamode is set to the destination character set value before the datamode is passed up to the receivingcaller.MAN-REF-H307IP-04 NETEX Request Block Page 31


• If neither adapter has code conversion and the character sets in the datamode field are still not equal, thensoftware code conversion is performed and the two fields are set equal.• If the incoming driver determines that the destination character set is not “significant” on its own host (forexample, sending Field-data code to a PDP-11) then it treats the incoming character set as “octet mode”data and provides the user with the data along with an error code in NRBSTAT indicating that the datawas “damaged.”• If the destination character set is a 6-bit code, code conversion hardware is required on the adapter for the6-bit character machine.NRBTIMENRBTIME specifies the length of elapsed time that the associated read-type command is to remain in effect.If a time interval equal to the number of seconds in NRBTIME has elapsed and no data or connection informationhas arrived to satisfy the READ or OFFER, then the request will end with an error.If the value in NRBTIME is “0,” then the request will wait indefinitely.NRBCLASSNRBCLASS is a connection-negotiation parameter that defines the class of service (the type of protocol thatwill be used by the connection service.) The current definition of class is as follows:0 Use class determined by the Network Configuration Table (NCT) (see “Installation” ).1 Use Version 1 NETEX protocol. This protocol is obsolete2 Use Version 2 NETEX protocol. This protocol is used in all current products.All other values (or values that are not supported for a particular implementation) will return a “class not implemented”error.When an offer or connect completes, the value of this field should contain the protocol version actually negotiated.If Network or Transport services are selected and more than one protocol at this layer is concurrentlyavailable, then an installation default is returned. If Session services are requested, then the default returnedmay depend on the protocol desired by the remote host as determined in the local Network Configuration Table.NRBMAXRTNRBMAXRT (maximum rate) is a connection negotiation parameter that specifies the maximum data ratepossible for the connection. NRBMAXRT is used for Session and Transport levels only. This field is forinformational purposes only on the session layer.The NRBMAXRT value is based on the user’s specification or the physical characteristics of the links betweenthe two NETEX calling programs. This field is designed for those applications that wish to make limiteduse of communications media between destinations.The units of this field are expressed as a 32-bit positive quantity giving the speed of the link in 1000’s of bitsper second. Thus, a connection using a terrestrial link adapter whose line speed was generated as 230K bitsper second would have 230 placed in this field.Note:NRBMAXRT and the throttling concept only directly apply to the transmitting portion of agiven connection. The other party in the connection may be working with completely differentthrottling parameters and the corresponding program will have no direct way of knowingthe remote transmitter’s data rate parameters.Page 32 NETEX Request Block MAN-REF-H307IP-04


On completion of the offer or confirm request, this field will have a non-zero value that contains the maximumthroughput that is possible to the connection, based on the user’s original request and the characteristicsof the communications link between the two.NRBBLKI and NRBBLKONRBBLKI and NRBBLKO are connection negotiation parameters that specify the maximum amount of datathat the calling program expects to read or write at one time during the coming connection. This parametershould be provided with the connect or offer request. During the protocol negotiation process, the NRBBLKIof one program will be compared with the NRBBLKO (output maximum buffer size) specified at the otherend, and the lesser of the two values will be returned in the two respective fields.For the connecting program, the negotiated results will be returned in the NRB along with the confirm dataread following the connect. The offering program will receive the negotiated values on completion of the offerand hence may decide if the negotiated values are acceptable for the work at hand.The NETEX installation systems programmer must supply the following values controlling these buffer sizes:1. The default input and output block sizes to be used, if these are not specified (left zero) by the caller.2. The maximum input and output block sizes permitted by the installation.As an example of the block negotiation process: Program A issues a connect with NRBBLKI = 256 andNRBBLKO = 4096. The offering program B to which A will connect specifies 64K for both, allowing theconnector to set any reasonable value in these fields. When the offer completes, B sees NRBBLKO = 256and NRBBLKI = 4096, the minimum of the two sets of values. When A’s read following the connect completes,it will see NRBBLKI = 256 and NRBBLKO = 4096, which are the same values as B with the directionsreversed.If the connection established is a network or driver level connection, then NRBBLKO and NRBBLKI may beadjusted to reflect the maximum size of data block that may be sent as a datagram on the path specified by theconnect. If the application negotiated size is smaller than the maximum NPDU size, then the negotiated parameterswill be unchanged. If the maximum NPDU size is smaller, then this maximum size will be returnedin both NRBBLKI and NRBBLKO.Two default options are available with these fields. If a zero is specified in either one of these fields, then thevalue used for negotiation will be an installation supplied default that is provided at NETEX installation time.If the value in this field is the machine representation of -1, then the size used for negotiation will be themaximum size available for that installation, which is also a parameter specified at initialization time.Note: The values implied by zero or -1 will be used for negotiation of the connection block sizes.The actual size negotiated will be supplied in these fields on completion of the connect or offer.For Network layer requests, the NRBBLKI and NRBBLKO fields are used to inform the Network layer of themaximum amounts of Odata and Pdata that will be used to send and receive data in this connection. Theselimits are dependent on the following:• The buffer capacities generated in both the local and remote copies of NETEX.• The physical limitations of the media connecting the two hosts.When this NOFFER completes with a Connect Indication, then these fields will have the actual limits forOdata and Pdata size in the connection sent to them. Unlike other layers of NETEX service, the NetworkService will return the maximum that is available if the caller’s size request is not available. The caller mustscale its buffer sizes downward accordingly.MAN-REF-H307IP-04 NETEX Request Block Page 33


The maximum size of Pdata is specified in addressable units. The maximum amount of Odata is specified inoctets.NRBPROTA and NRBPROTLThe NRBPROTA and NRBPROTL are connection negotiation parameters that permit the application to provideOdata to the called layer of NETEX. NRBPROTA specifies the address of the buffer containing theOdata, and NRBPROTL specifies the number of octets of Odata in that buffer.When a write-type command is issued, the Odata provided (if any) will be added to the message, and eventuallydelivered as Odata to the receiving application’s read-type command. As a result, this is a second bufferthat is handled in a similar way to the Pdata that is specified by NRBBUFA and NRBLEN/NRBUBIT. Thereare some distinct differences that are as follows:• Odata is always sent and received in “octet mode,” which means it will be represented in the best way thatthe particular host can handle strings of 8-bit binary quantities (for example, 1/byte, 4/36-bit word, and soon).• The maximum amount of Odata that may be sent is limited. This maximum is installation dependent andmay typically be 256 bytes or less. Each version of NETEX will have a generated maximum on the numberof bytes of Odata that it is prepared to accept in incoming messages. In the Network, Transport, andSession levels, the maximum amount of Odata that may be sent or received will be the minimum of theOdata sizes generated on each host.Users should be warned that sending excessive amounts of Odata with normal transmissions may result in a“fissioning” of network messages, which increases network traffic and decreases network performance, oftenby a factor of two.Note: Not all implementations of NETEX support the use of Odata. Network Executive Software utilitiesdo not use Odata. Consult Network Executive Software personnel before using Odata to determinewhether it is available.On a write-type operation, no Odata will be sent if NRBPROTL is zero. If a non-zero length is specified,then the Odata will be transmitted along with the Pdata, if present. When the read takes place, the Odata willbe placed in the address specified by NRBPROTA and its incoming length will be set in NRBPROTL.NRBPROTL always contains the length of the Odata in octets, not “addressable units.”The protocol field has special significance when used with Driver level requests, in that the Odata containsthe network Message Proper, where the Pdata contains the Associated Data.NRBRESV1 and NRBRESV2NRBRESV1 and NRBRESV2 are reserved for possible future NETEX enhancements.NRBPNAME (NRBOFFER)Used with a session level request, NRBPNAME specifies the offered name (the name of the process to bematched when the offer and connect requests meet). Names of all processes are uppercase alphanumeric datathat are up to eight characters in length. Names less than eight characters long will be padded with blanks.Process names will be converted to the ASCII character set for transmission between hosts, so only thosecharacters that are significant in ASCII should be used during the name matching process.Page 34 NETEX Request Block MAN-REF-H307IP-04


NRBHNAME (NRBHOST)NRBHNAME specifies the symbolic name of the host computer that will be addressed to match an offer request.Names of all hosts are specified by the installation systems programmer. All host names are uppercasealphanumeric data that are up to eight characters in length. Names less than eight characters long should bepadded with blanks.NRBRESV3NRBRESV3 is reserved for possible future NETEX enhancements. Programs should leave binary zeroes inthese fields.NRBUSERThis field is reserved for users. Usually, it will be used to pass information to the User Exits that exist in Hostbased NETEX implementations. NETEX will not process this field in any way.NRBOSDEPNRBOSDEP is reserved for internal use. NETEX software uses this field to service and monitor the progressof NRB requests. The contents of these fields is maintained by NETEX during a session.If these fields are altered by the calling program, the results are unpredictable.Creating an NRBA single NRB should be created before a calling program OFFERs or CONNECTs to another program. TheNRB is 40 words long and should initially be zero-filled. Programs may create several NRBs initially.If several NRBs are required to service a single connection, they should be duplicated from the initial NRB,as described in the following sections.Duplicating an NRBDuplicating NRBs is necessary when using multiple NRBs within a session. By duplicating the NRB theconnection-negotiation parameters, the connection reference number, and the internal NRBOSDEP informationis preserved, allowing the duplicate NRB to be valid.To duplicate an NRB, wait until the initial CONNECT or OFFER has completed successfully, then copy theentire “working” NRB (40 words) to a blank NRB at a different location. The second NRB can now be usedfor NETEX requests.MAN-REF-H307IP-04 NETEX Request Block Page 35


H307 <strong>Assembler</strong> InterfaceThe MASM DEF element N2XDEFS contains a set of simple procedures designed to facilitate NETEX callsfrom assembler programs. These procedures and associated definitions can be made available to MASM bymeans of a $INCLUDE "N2XDEFS" statement in the program, and placing the N2XDEFS omnibus elementin an appropriate file in MASM's search hierarchy (ASM$PF, SI, SO, RO).The rest of this section describes the <strong>Assembler</strong> NRBs, the general Procedure format, and each NETEX assemblercall.<strong>Assembler</strong> NETEX Request BlocksThe MASM user builds an NRB by reserving a 40-word data area. Various members of this area will holdthe information to be transferred to NETEX, and others will contain the information that is returned byNETEX. If more than one NRB will be required to service a program, then several of these NRB areas mustbe reserved.NRB+0 NRBSTAT NETEX request status returned to userNRB+1 NRBIND Data type indication from OFFER/READNRB+2 NRBLEN Length of dataNRB+3 NRBUBIT Unused bit countNRB+4 NRBREQ User request codeNRB+5 NRBNREF NETEX ref number identifying connectionNRB+6 NRBBUFA Starting address of user dataNRB+7 NRBBUFL Length of user's bufferNRB+8 NRBMODE Datamode for write-type requestNRB+9 NRBTIME Read request timeout in secondsNRB+10 NRBCLASS Class of serviceNRB+11 NRBMAXRT Maximum data rate permittedNRB+12 NRBBLKI Max buffer size for input requestsNRB+13 NRBBLKO Max buffer size for output requestsNRB+14 NRBPROTA Odata addressNRB+15 NRBPROTL Odata length in octetsNRB+16 NRBRESV1 ReservedNRB+17 NRBRESV2 ReservedNRB+18 NRBPNAME Name of process to OFFER/CONNECT (8 bytes)NRB+28 NRBHNAME Name of destination host (8 bytes)NRB+22 NRBRESV3 ReservedNRB+23 NRBUSER Installation useNRB+24 NRBOSDEP Reserved for op system dependent informationtoNRB+39Figure 11. <strong>Assembler</strong> NRB DefinitionsPage 36 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


<strong>Assembler</strong> Procedure FormatAll of the NETEX assembler procedures have the following format,<strong>Call</strong>Parametersnxcall[W] nrb [err-return]nxcallThis is the procedure name. The name may be one of the following: SOFFER, SCONNECT,SCONFIRM, SWRITE, SREAD, SCLOSE, or <strong>SDISC</strong>. More information about each of theseNETEX procedures is presented later in this section.nxcallwIf this optional parameter is specified, return will not be made to the caller until the request has completed(NRBSTAT zero or positive). If not specified, return will be made immediately after preliminaryerror-checking of the request (by NETEX).nrbThis is the address of the NETEX request block (NRB) that is to be used with this procedure. Allrelevant fields must have been previously set or cleared in the NRB by the caller. NRBSTAT andNRBIND are always cleared by the procedure. This field may have the following form:U-field[,X-reg[,J-desig]]err-returnIf specified, this is optional parameter is the address to which control will be transferred if the requestcompletes with a nonzero return code (indicating an error). Note that this does not apply to the immediatereturn with an in-progress status (negative value).Register UsageAll calls use and destroy the minor register set. A0 contains the NRB address on return (except for SWAIT,where it is undefined).<strong>Assembler</strong> Command ExamplesThe following statements are sample NETEX calls:L,USOFFERWX9,NRB1X9SWRITE NRBW,,U WRITERRSREADWRDNRBA,,UMAN-REF-H307IP-04 H307 <strong>Assembler</strong> Interface Page 37


SOFFER <strong>Assembler</strong> <strong>Call</strong>The SOFFER call provides a means for a program desiring to accept a connection from a caller on the networkto post the availability of the service.Prior to issuing an SOFFER call, the user must provide an NRB (described in “NETEX Request Block”) to beused by the user interface. All NRB fields which are not defaults or have not been assembled into the NRBdata area(s) must be filled in by the program before calling NETEX. The areas used by the SOFFER call includethe following:NRBPNAME Name of process to offer.NRBBLKINRBBLKONRBTIMENRBBUFANRBBUFLNRBMAXRTMaximum buffer size for input requests (may be changed during the NETEX negotiationprocess).Maximum buffer size for output requests (may be changed during the NETEX negotiationprocess).Number of seconds before the request times-out.Starting address to receive data coining back with the other programs CONNECT request.Length of buffer to receive data coming back with the other programs CONNECT request.Maximum data transmission rate permitted in thousands of bits per second (may bechanged during the NETEX negotiation process).<strong>Call</strong>ParametersSOFFER[w] nrb [err-return]SOFFERThis is the procedure name.SOFFERWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with in-progress status (negative value).Page 38 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


SCONNECT <strong>Assembler</strong> <strong>Call</strong>The SCONNECT call provides a means for a program to request a session with a program that has previouslyissued an SOFFER.Prior to issuing an SCONNECT call, the user must provide an NRB (described in “NETEX Request Block”)to be used by the user interface. All NRB fields which are not defaults or have not been assembled into theNRB data area(s) must be filled in by the program before calling NETEX. The areas used by theSCONNECT call include the following:NRBPNAME Name of process requesting the connection.NRBHNAME Name of destination host to be connected to.NRBBLKINRBBLKONRBBUFANRBLENNRBUBITNRBMODENRBMAXRTMaximum buffer size for input requests (may be changed during the NETEX negotiationprocess).Maximum buffer size for output requests (may be changed during the NETEX negotiationprocess).Starting address of (optional) data to be transmitted to the other program with theSCONNECT request.Length of (optional) data to be transmitted with the SCONNECT request. Note that thismust not exceed the maximum segment size of either host.Unused bit count for (optional) data to be transmitted with the SCONNECT request.Datamode for making data intelligible for users on both endsMaximum data transmission rate permitted in thousands of bits per second (may bechanged during the NETEX negotiation process).<strong>Call</strong>ParametersSCONNECT[W] nrb [err-return]SCONNECTThis is the procedure name.SCONNTWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with an in-progress status (negative value).MAN-REF-H307IP-04 H307 <strong>Assembler</strong> Interface Page 39


SCONFIRM <strong>Assembler</strong> <strong>Call</strong>The SCONFIRM call provides a means for an offering program to confirm (to the connector) that the connectionhas been made and the block size, class, and any optional data are accept able to the offerer. A negativeresponse would be in the form of an <strong>SDISC</strong> (disconnect).Before issuing the SCONFIRM, an SOFFER must have completed successfully with a Connect Indication.The user must provide a NRB containing the information supplied by the previous SOFFER.Also prior to issuing an SCONFIRM call, the user must provide an NRB (described in “NETEX RequestBlock”) to be used by the user interface. All NRB fields which are not defaults or have not been assembledinto the NRB data area(s) must be filled in by the program before calling NETEX. The areas used by theSCONFIRM call include the followingNRBBUFANRBLENNRBUBITNRBMODEStarting address of (optional) data to be transmitted to the other program with theSCONFIRM request.Length of (optional) data to be transmitted with the SCONFIRM request. Note that this mustnot exceed the maximum segment size of either host.Unused bit count for (optional) data to be transmitted with the SCONFIRM request.Datamode for making data intelligible for users on both ends.<strong>Call</strong>ParametersSCONFIRM[W] nrb [err-return]SCONFIRMThis is the procedure name.SCONFIRMWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-return (optional)If specified, this field is the address to which control will be transferred if the request completes witha nonzero return code (indicating an error). Note that this does not apply to the immediate return withan in-progress status (negative value).Page 40 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


SREAD <strong>Assembler</strong> <strong>Call</strong>The SREAD call provides a means for a program to receive data from another host or an indication fromNETEX of an abnormal condition with the connection.Before an SREAD can be issued, a connection must be established. The NRB specified must have been usedfor a previous NETEX request for the particular connection, or a copy of another NRB that has been used toservice the desired connection. Defaults for unspecified parameters are the parameters existing in the specifiedNRB.Also prior to issuing an SREAD call, the user must provide an NRB (described in “NETEX Request Block”)to be used by the user interface. All NRB fields must be filled in by the program before calling NETEX, unlesspreviously used values are to be used again. The areas used by the SREAD call include the following.NRBBUFA Starting address of data area to be used for receiving data from the other program.NRBBUFL Length of user buffer to be used to receive data from the other program.NRBTIME Number of seconds before this request times-out.<strong>Call</strong>ParametersSREAD[W] nrb [err-return]SREADThis is the procedure name.SREADWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with an in-progress status (negative value).MAN-REF-H307IP-04 H307 <strong>Assembler</strong> Interface Page 41


SWRITE <strong>Assembler</strong> <strong>Call</strong>The SWRITE call provides a means for a program to transmit data to another calling program. Before anSWRITE can be issued, a connection must be established. The NRB used to issue the SWRITE must havebeen used by a previous request that serviced the desired connection, or it must be a copy of another NRB thathas serviced the connection. Defaults for unspecified parameters are the existing parameters in the specifiedNRB.Also prior to issuing an SWRITE call, the user must provide an NRB (described in “NETEX Request Block”)to be used by the user interface. All NRB fields which are not defaults or have not been assembled into theNRB data area(s) must be filled in by the program before calling NETEX. The areas used by the SWRITEcall include the following:NRBBUFA Starting address of data to be transmitted to the other program with the SWRITE request.NRBLEN Length of data to be transmitted with the SWRITE request.NRBUBIT Unused bit count for data to be transmitted with the SWRITE request.NRBMODE Datamode for making data intelligible for users on both ends.<strong>Call</strong>ParametersSWRITE[W] nrb [err-return]SWRITEThis is the procedure name.SWRITEWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with in-progress status (negative value).Page 42 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


SCLOSE <strong>Assembler</strong> <strong>Call</strong>The SCLOSE call provides a means for a program to transmit data to another calling program, and indicatethat this is the last data to be sent.Before an SCLOSE can be issued, a connection must be established. The NRB used to issue the SCLOSEmust have been used by a previous request that serviced the desired connection, or it must be a copy of anotherNRB that has serviced the connection. Defaults for unspecified parameters are the existing parametersin the specified NRB.After a program has issued an SCLOSE, no other data may be written by that program. If the other programhad previously issued an SCLOSE, the data is written and then the connection is gracefully disconnected. Ifthe other program has not issued an SCLOSE, it is still free to write data to the program that did issue theSCLOSE.Also prior to issuing an SCLOSE call, the user must provide an NRB (described in “NETEX Request Block”)to be used by the user interface. All NRB fields which are not defaults or have not been assembled into theNRB data area(s) must be filled in by the program before calling NETEX. The areas used by the SCLOSEcall include the following.NRBBUFA Starting address of data to be transmitted to the other program with the SCLOSE request.NRBLEN Length of data to be transmitted with the SCLOSE request.NRBUBIT Unused bit count for data to be transmitted with the SCLOSE request.NRBMODE Datamode for making data intelligible for users on both ends.<strong>Call</strong>ParametersSCLOSE[W] nrb [err-return]SCLOSEThis is the procedure name.SCLOSEWIf this optional call is specified, the return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with an in-progress status (negative value).MAN-REF-H307IP-04 H307 <strong>Assembler</strong> Interface Page 43


<strong>SDISC</strong> <strong>Assembler</strong> <strong>Call</strong>The <strong>SDISC</strong> (disconnect) call provides the means for any connected program to terminate a session. The requestis immediate and any data currently in transport may not be delivered. If data delivery is required, it isthe disconnector’s responsibility to wait for confirmation of previous SREAD or SWRITE commands by thecorresponding program before issuing the <strong>SDISC</strong> call.Before an <strong>SDISC</strong> can be issued, the user must provide an NRB that has been previously used to service thedesired connection, or a copy of an NRB used to service the connection.Also prior to issuing an <strong>SDISC</strong> call, the user must provide an NRB (described in “NETEX Request Block”) tobe used by the user interface. All NRB fields which are not defaults or have not been assembled into theNRB data area(s) must be filled in by the program before calling NETEX. The areas used by the <strong>SDISC</strong> callinclude the following.NRBBUFANRBLENNRBUBITNRBMODEStarting address of (optional) data to be transmitted to the other program with the <strong>SDISC</strong> request.Length of (optional) data to be transmitted with the <strong>SDISC</strong> request. Note that this must notexceed the maximum segment size of either host.Unused bit count for (optional) data tq be transmitted with the <strong>SDISC</strong> request.Datamode for making data intelligible for users on both ends.<strong>Call</strong>Parameters<strong>SDISC</strong>[W] nrb [err-return]<strong>SDISC</strong>This is the procedure name.<strong>SDISC</strong>WIf this optional parameter is specified, return will not be made to the caller until the request has completed.If not specified, return will be made immediately after preliminary error-checking of the request(by NETEX).nrbThis is the address of the updated NETEX request block that is to be used with this procedure.err-returnIf this optional parameter is specified, this field is the address to which control will be transferred ifthe request completes with a nonzero return code (indicating an error). Note that this does not applyto the immediate return with an in-progress status (negative value).Page 44 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


NETEX Procedure CodeThe code generated by the NETEX assembler procedures is as follows.L A5,nrb-address . request blockL A5,req-type . type of requestS AS,NRBREQ,AG . request codeSZ NRBRC,AG . clear return codeSZ NRBIND,AG . clear indicatorL A4,(NXIFLV,NTX$DBG) . interface level and 0-bankLXI,U Xll,NTX$COMN+l*/15 . into utility I-bankLBJ Xll.-1000 . call NETEXIf err-return was specified, the following results:TP nrbrc,a0 . request in progress?J $+3 . yesTZ NRBRC,A0 . error codeJ err-return . yes...Note that since the user’s utility I-bank and D-bank are debased by the NETEX call, the NRB and data buffermay not reside in these banks. NETEX must have these data areas “visible” in the user interface.MAN-REF-H307IP-04 H307 <strong>Assembler</strong> Interface Page 45


SWAIT <strong>Assembler</strong> <strong>Call</strong>The SWAIT procedure provides a means to wait for current NETEX operations to finish. Unlike the higherlevel language interfaces, this interface does not accept NRB’s to check.Instead, it is the responsibility of the assembly language user to check the status of the NRB’s when control isreturned.When SWAIT is called, it checks if any operations have completed since the last time control was returnedfrom an SWAIT call. If an operation completed, control is immediately returned to the caller. If no operationshave completed, the user is suspended until an operation completes.Because SWAIT “remembers” if any operation has completed since the last call, SWAIT may return with noapparent NRB completions. This occurs if the completion occurred after the user regained control and beforethe NRB’s were checked. The SWAIT code flags the completion and then the user processes the NRB. Onthe next SWAIT call, the completion flag is set and control is returned, but no new NRB’s have completed.The only current error which can be reported from an SWAIT is that NETEX is not currently running. In thiscase, the user can not be suspended and control is returned with the error status. If the user wishes to waituntil NETEX is up, the user should wait and try again until SWAIT returns with a good status. It is possiblefor the user to be aborted with a common bank reload error when NETEX starts up. This is a result of a call(SWAIT, SCONNECT, or SOFFER) reaching the common bank just as the reload occurs.There is only one WAIT request. It waits for completions at any call level. If the user is using SESSION andDRIVER requests, the SWAIT will wait for any SESSION request or any DRIVER request. For coding conveniencethe names SWAIT, TWAIT, NWAIT, and DWAIT are defined.<strong>Call</strong>ParametersSWAITerr-returnSWAITThis is the procedure name.err-returnThis required parameter is the address to transfer control to if the request completes with an error indication.The error status which normally would be returned in NRBSTAT is returned in A0. Currently,the only error is “NETEX is not running”.Multiple ActivitiesNETEX is designed to allow multiple user activities. It is common to have one activity to process all outputrequests and one for all input requests. There is no limit imposed by NETEX on the number of activities.As with the other interfaces, SWAIT allows multiple activities. There is an attempt to process requests in theorder that they were received, but it is common to have the last caller and the first call active if a completionoccurs just as the last caller calls. The assembly language interface and the higher level language interfacesare not compatible. The higher level language interfaces need to receive control on each completion. If boththe assembly and higher level interfaces are to be used, only one activity should be used. That activity shoulduse the SWAIT(-l) type interface and call the user’s assembly language completion routine for the assemblercompletions.Page 46 H307 <strong>Assembler</strong> Interface MAN-REF-H307IP-04


FORTRAN InterfaceNETEX includes a library of subroutines that are designed to be called by FORTRAN high level languageprograms. When the user makes a call to the user interface, he will supply the appropriate information, inparameter format, to pass to NETEX.FORTRAN programs written to use NETEX may be used on other machines that use NETEX, provided thatchanges are made to the program to account for different word sizes, etc. One such change is the data lengthused when reading and writing data. Data lengths are specified to NETEX as a number of addressable units.An addressable unit is the amount of information obtainable from a distinct memory location on a particularmachine. For UNIVAC, an addressable unit is one 36-bit word.There are two components that are used to establish working communications through NETEX: one or moreNETEX Request Blocks (NRBs) that must be supplied by the FORTRAN caller, and the NETEX-providedsubroutines that are used to invoke NETEX services. The NRB is described first, followed by the calls to thesubroutines. The calls are presented in the following order (the approximate order in which they are used).• SCONN• SCONF• SREAD• SWRIT• SCLOSE• SWAIT• <strong>SDISC</strong>The use of these calls is described in “Intertask Communication” on page 9 of this manual. A FORTRANexample of a program using NETEX follows the macro description in this section. The formats of the callsare presented using the conventions stated in the preface of this manual.MAN-REF-H307IP-04 FORTRAN Interface Page 47


FORTRAN NETEX Request BlocksThe FORTRAN user builds an NRB by declaring it to be an array of 40 INTEGER elements. Various membersof this array will hold the information to be transferred to NETEX, and others will contain the informationthat is returned by NETEX. If more than one NRB will be required to service a program, then several ofthese NRB arrays must be declared. Before these NRB arrays are used for any NETEX request, it is advisableto zero all the elements of the array. This will allow defaults for fields not explicitly used by the caller to takeeffect. Thus a sample declaration might be as follows.INTEGER RNRB(40), WNRB(40)DATA RNRB /40*0/DATA WNRB /40*0/The NETEX FORTRAN subroutines have the philosophy that arguments commonly passed to NETEX (suchas a data buffer address) will be passed as parameters to the subroutine. “Exotic” parameters to be passed toNETEX, such as maximum input block size, will be supplied by storing the desired value in the proper memberof the NRB array. When the request completes, the FORTRAN program directly accesses the desiredelements of the NRB array to determine if the operation completed properly. If NRB is declared as a 40 elementarray of integers, the elements of the array will be as shown in the following table.Element Type Name FunctionNRB(l) INTEGER NRBSTAT NETEX request status returned to userNRB(2) INTEGER NRBIND Data type indication from OFFER/READNRB(3) INTEGER WRELEN Length of dataNRB(4) INTEGER NRBUBIT Unused bit countNRB(5) INTEGER NRBREQ User request codeNRB(5) INTEGER NRBNREF NETEX ref no identifying connectionNRB(7) INTEGER NRBBUFA Starting address of user dataNRB(8) INTEGER NRBBUFA Length of users bufferNRB(9) INTEGER NRBMODE Datamode for write-type requestNRB(lO) INTEGER NRBTIME Request timeout in secondsNRB(ll) INTEGER NRBCLASS Class of serviceNRB(12) INTEGER NRBMAXRT Maximum data rate permittedNRB(13) INTEGER NRBBLKI Max buffer size for input requestsNRB(14) INTEGER NRBBLKO Max buffer size for output requestsNRB(15) INTEGER NRBRESV1 ReservedNRB(16) INTEGER NRBRESV2 ReservedNRB(17) INTEGER NRBPROTA Odata addressNRB(18) INTEGER NRBPROTL Odata length (octets)NRB(19) CHARACTER*8 NRBPNAME Name of process to OFFER/CONNECT (8b)NRB(21) CHARACTER*8 NRBHNANE Name of destination host (8 bytes)NRB(23) INTEGER NRBRESV3 ReservedNRB(24) INTEGER NRBUSER Installation useNRB(25) NRBOSDEP Reserved for op system dependent infotoNRB(40)Page 48 FORTRAN Interface MAN-REF-H307IP-04


SOFFR FORTRAN <strong>Call</strong>The SOFFR (offer) subroutine provides a means for a program desiring to accept a connection from a calleron the network to post the availability of the service. Before issuing an SOFFR call, the user must provide anNRB (described in "NETEX Request Block") to be used by the user interface. Also, NETEX must be activein the system.<strong>Call</strong> Operation ParametersCALL SOFFR[W] (nrb, buffer, length, timeou, pname)The following parameters were shown in the SOFFR call format. The parameters must be specified in the orderpresented. If parameters are omitted, the commas must still be used.SOFFRThis is the verb for the call. Either SOFER or SOFFRW must be specified.SOFFRWThis specifies that the calling program must wait for the call to complete before processing is resumed.nrbThis required parameter is the address of the NRB data area that is to be passed to NETEX.bufferlengthtimeoupnameThis optional parameter specifies the start of an array that is to receive data sent by the correspondingSCONNECT request.This optional parameter specifies is the length of the buffer (in addressable units - words for Unisys)that will hold the data sent by the corresponding SCONNECT. When called, length should containthe maximum size of the buffer. On return the NRBLEN (NRB(3)) field will contain the number ofaddressable units of information actually sent to the offering application. The data type of lengthshould be INTEGER.This optional parameter indicates the number of seconds that the OFFER request should remain outstanding.If no application connects during this interval, then the OFFER will end abnormally. Iftimeou is specified as zero, the OFFER will remain outstanding indefinitely.This optional parameter is the alphabetic name of the process to be offered to the corresponding callingprogram. The name offered is arbitrary, but must be known to the connecting program. Thisname may be provided as a CHARACTER*8 variable or as a string in the CALL statement if paddedwith blanks to eight characters in length.SOFFR Entry ParametersThe following NRB fields are used by SOFFR on entry.NRBBUFA Address for incoming PdataNRBBUFLLength of buffer to hold Pdata.NRBTIMENumber of seconds offer outstanding.NRBBLKO Maximum transmission size acceptable.NRBBLKIMaximum reception size acceptable.MAN-REF-H307IP-04 FORTRAN Interface Page 49


NRBMAXRTNRBPROTANRBPROTLNRBPNAMELimit on transmission speed.Address for incoming Odata.Length of buffer to hold Odata.Application name to offer.SOFFR ResultsThe following NRB fields are updated when SOFFR completes.NRBSTATSuccess/failure code.NRBINDContains Connect Indication.NRBLENLength of incoming Pdata.NRBUBITUnused bit count of Pdata.NRBNREF Sref assigned this connection.NRBBLKO Maximum transmission Pdata size.NRBBLKIMaximum reception Pdata size.NRBMAXRT Max transmission speed of path.NRBPROTL Length of Odata received.NRBHNAME Name of host where S-conn originated.NRBPNAME Name of application where S-conn originated.Page 50 FORTRAN Interface MAN-REF-H307IP-04


SCONN FORTRAN <strong>Call</strong>The SCONN (connect) call provides a means for a program to request a session with a program that has issuedan SOFFR. Before issuing the SCONN, an NRB must be provided for use by the user interface.<strong>Call</strong> Operation ParametersCALL SCONN[W] (nrb, buffer, length, datamd, pname, hname)The following parameters were shown in the SCONN call format. The parameters must be specified in theorder presented. If parameters are omitted, the commas must still be used.CALLThis is the required standard high level call instruction.SCONNThis is the verb for the call. Either SCONN or SCONNW must be specified.SCONNWThis indicates that the calling program should wait for the call to complete before processing is resumed.nrbThis required parameter is the address of the NRB data area that is to be passed to NETEX.bufferThis optional parameter specifies the start of an array that holds the user data that is to be sent to thecorresponding application.LengthThis optional parameter specifies the length of the data (in addressable units - words for Unisys) thatis to be sent to the corresponding application, to be presented with the completion of the correspondingapplication’s OFFER request. If no data needs to be sent to the other application, the length maybe set to zero. The data type of length should be INTEGER.datamdThis optional parameter specifies the datamode that is to be used to send the connect data to the correspondingapplication. The data type of datamd should be INTEGER. Refer to NRBDMODE in“NETEX Request Block” on page 25 for a discussion of the datamode parameter.PnameThis optional parameter specifies the alphabetic name of the process SOFFR'd by the correspondingcalling program. The name offered is determined by the other calling program. This name may beprovided as a CHARACTER*8 variable or as a string in the CALL statement if padded with blanks toeight characters in length.HnameThis required parameter specifies the alphabetic name of the host computer to be accessed to determineif the correct SOFFR is available. The “names” of the host computers in the network are determinedby the NETEX installation systems programmer. This may be provided as a CHARACTER*8variable or provided as a string in the CALL statement if padded with blanks to eight characters inlength.MAN-REF-H307IP-04 FORTRAN Interface Page 51


SCONN Entry ParametersThe following NRB fields are used by SCONN on entry.NRBBUFA Address of outgoing Pdata.NRBLENLength of outgoing Pdata.NRBUBITPdata unused bit count.NRBDMODE Datamode of Pdata.NRBBLKO Maximum transmission size acceptable.NRBBLKIMaximum reception size acceptable.NRBMAXRT Limit on transmission speed.NRLBPROTL Address for outgoing Odata.NRBPROTA Length of outgoing Odata.NRBHNAME Alphanumeric “host” name.NRBPNAME Alphanumeric “application” name.SCONN ResultsThe following NRB fields are updated when SCONN completes.NRBSTATSuccess/failure code.NRBNREF Sref (Session ID) assigned.Page 52 FORTRAN Interface MAN-REF-H307IP-04


SCONF FORTRAN <strong>Call</strong>The SCONF (confirm) call provides a means for an offering program to confirm (to the connector) that theconnection has been successfully completed. A negative response to an SCONN would be an <strong>SDISC</strong>. Beforeissuing the SCONF call, an SOFFR must have completed successfully by receiving an SCONN response.The calling program must provide a NRB with an NRBNREF relating to this session.<strong>Call</strong> Operation ParametersCALL SCONF[W] (nrb, buffer, length, datamd)The following parameters were shown in the SCONF call format. The parameters must be specified in theorder presented. If parameters are omitted, the commas must still be used.CALLThis is a required standard high level call instruction.SCONFThis is the verb for this call. Either SCONF or SCONFW must be specified. SCONFW specifies thatthe calling program must wait for the call to complete before processing is resumed.nrbThis required parameter is the address of the NRB data area that is to be passed to NETEX.bufferThis optional parameter specifies the start of an array that holds the user data that is to be sent to thecorresponding application.lengthThis optional parameter specifies the length of the data (in addressable units – Unisys words) that isto be sent to the corresponding application, to be presented with the completion of the correspondingapplication’s SREAD request. If no data needs to be sent to the other application, the length may beset to zero. The data type of length should be INTEGER.datamdThis optional parameter specifies the datamode to be used to send the connect data to the correspondingapplication. The data type of datamd should be INTEGER. Refer to NRBDMODE in“NETEX Request Block” for a discussion of the datamode parameter.SCONF Entry ParametersThe following NRB fields are used by SCONF on entry:NRBBUFA Address of outgoing Pdata (move mode).NRBLENLength of outgoing Pdata.NRBUBITPdata unused bit count.NRBDMODE Datamode of Pdata.NRBPROTA Address of outgoing Odata.NRBPROTL Length of outgoing Odata.SCONF ResultsThe following NRB fields are updated when SCONF completes:NRBSTATSuccess/failure code.MAN-REF-H307IP-04 FORTRAN Interface Page 53


SREAD FORTRAN <strong>Call</strong>The SREAD request provides a means for a program to receive data from another host. NETEX assumes thatthe calling program that wrote the data specified code conversion which makes it readable for the receiver.Before an SREAD can be issued, a connection must be established.<strong>Call</strong> Operation ParametersCALL SREAD[W] (nrb, buffer, length, timeou)The following parameters were shown in the SREAD call format. The parameters must be specified in theorder presented. If parameters are omitted, the commas must still be used.CALLThis is the required standard high level call instruction.SREADThis is the verb for this call. Either SREAD or SREADW must be specified.SREADWThis parameter specifies that the calling program must wait for the call to complete before processingis resumed.nrbThis required parameter is the address of the NRB data area that is to be passed to NETEX.bufferlengthtimeouThis required parameter specifies the start of an array that is to receive the data sent by the correspondingapplication’s SWRITE or SCONFIRM request.This required parameter specifies the length of the buffer (in addressable units - words for Unisys)that is to hold the data sent by the corresponding SWRITE. When called, length should contain themaximum size of the buffer. On return, the actual length input will be in NRBLEN (NRB(3)). Programsthat wish to work with the Unused Bit Count on input should examine the NRBUBIT field(NRB(4)). The data type of length should be INTEGER.This optional parameter specifies the number of seconds that the READ request should remain outstanding.If the corresponding application does not send data during this interval, then the READ willend abnormally. If timeou is specified as zero, then the READ will remain outstanding indefinitely.The programmer should take alternate path retry into consideration when specifying the timeoutvalue. Refer to “Overview”.SREAD Entry ParametersThe following NRB fields are used by SREAD on entry.NRBBUFA Address for incoming Pdata (move mode).RBBUFLNLength of buffer to hold Pdata.NRBTIMENumber of seconds offer outstanding.NRBPROTA Address for incoming Odata.NRBPROTL Length of buffer to hold Odata.Page 54 FORTRAN Interface MAN-REF-H307IP-04


SREAD ResultsThe following NRB fields are updated when SREAD completes:NRBSTATSuccess/failure code,NRBINDContains data type indication.NRBLENLength of incoming Pdata.NRBUBITUnused bit count of Pdata.NRBBLKO Maximum transmission Pdata size.NRBBLKIMaximum reception Pdata size.NRBMAXRT Maximum transmission speed of the path.If a CONFIRM was read, the following results:NRBHNAME Host connected toNRBPNAME Remote user name (RUNID).MAN-REF-H307IP-04 FORTRAN Interface Page 55


SWRIT FORTRAN <strong>Call</strong>The SWRIT (write) call provides a means for an application to transmit data to another calling program. Beforean SWRIT can be issued, a connection must be established.<strong>Call</strong> Operation ParametersCALL SWRIT[W] (nrb, buffer, length, datamd)The following parameters were shown in the SWRIT call format. The parameters must be specified in theorder presented. If parameters are omitted, the commas must still be used.CALLThis is a required standard high level call instruction.SWRITThis is the verb for this call. Either SWRIT or SWRITW must be specified.SWRITWThis specifies that the calling program must wait for the call to complete before processing is resumed.nrbThis required parameter specifies the address of the NRB data area that is to be passed to NETEX.bufferThis required parameter specifies the start of an array that holds the user data that is to be sent to thecorresponding application.lengthThis required parameter specifies the length of the data (in addressable units - words for Unisys) thatis to be sent to the corresponding application, to be presented with the completion of the correspondingapplication’s OFFER request. If no data needs to be sent to the other application, the length maybe set to zero. The data type of length should be INTEGER.datamdThis optional parameter specifies the datamode that is to be used to send the connect data to the correspondingapplication. The data type of datamd should be INTEGER. Refer to NRBDMODE in“NETEX Request Block” for a discussion of the datamode parameter.SWRIT Entry ParametersThe following NRB fields are used by SWRIT on entry:NRBBUFA Address of outgoing Pdata.NRBLENLength of outgoing Pdata.NRBUBITPdata unused bit count.NRBDMODE Datamode of Pdata.NRBPROTA Address of outgoing Odata.NRBPROTL Length of outgoing Odata.SWRIT ResultsThe following NRB fields are updated when SWRIT completes:NRBSTATSuccess/failure code.Page 56 FORTRAN Interface MAN-REF-H307IP-04


SCLOS FORTRAN <strong>Call</strong>The SCLOS (close) call provides a means for a calling program to transmit data to another calling programand to indicate that this is the last data to be sent. If the other program has already issued an SCLOS, the sessionis gracefully disconnected. Before an SCLOS can be issued, a connection must be established.<strong>Call</strong> Operation ParametersCALL SCLOS[W] (nrb, buffer, length, datamd)The following parameters were shown in the SCLOS call format. The parameters must be specified in theorder presented. All parameters are required.CALLThis is a standard high level call instruction.SCLOSThis is the verb for this call. Either SCLOS or SCLOSW must be specified.SCLOSWThis parameter specifies that the calling program must wait for the call to complete before processingis resumed.nrbThis required parameter is the address of the NRB data area that is to be passed to NETEX.bufferThis parameter required specifies the start of an array that holds the user data that is to be sent to thecorresponding application.lengthThis required parameter specifies the length of the data (in addressable units - words for Unisys) thatis to be sent to the corresponding application, to be presented with the completion of the correspondingapplication’s OFFER request. If no data needs to be sent to the other application, the length maybe set to zero. The data type of length should be INTEGER.datamdThis required parameter specifies the datamode to be used to send the connect data to the correspondingapplication. The data type of datamd should be INTEGER. Refer to NRBDMODE in“NETEX Request Block” for a discussion of the datamode parameter.SCLOS Entry ParametersThe following NRB fields are used by SCLOS on entry.NRBBUFA Address of outgoing Pdata.NRBLENLength of outgoing Pdata,NRBUBITPdata unused bit count.NRBDMODE Datamode of Pdata.NRBPROTA Address of outgoing Odata.NRBPROTL Length of outgoing Odata.SCLOS ResultsThe following NRB fields are updated when SCLOS completes.MAN-REF-H307IP-04 FORTRAN Interface Page 57


NRBSTATSuccess/failure code.Page 58 FORTRAN Interface MAN-REF-H307IP-04


SWAIT FORTRAN <strong>Call</strong>The SWAIT call provides the means to wait for the completion of NETEX requests. Control will be returnedto the SWAIT caller as soon as it is found that any one of the NRBs specified no longer has the “in progress”flag set. Return from the subroutine will be immediate if any one of the NRBs has completed before theSWAIT call.After control is returned, it is the responsibility of the calling FORTRAN program to determine which of theNRBs in the list has completed. This can be done by examining the NRBSTAT field of each of the NRBs.<strong>Call</strong>ers should note that more than one NRB may have completed before control is returned to the caller.<strong>Call</strong> Operation ParametersCALL SWAIT (nrbnum, nrb [,nrb…])The following parameters were shown in the SWAIT call format. The parameters must be specified in theorder presented. If parameters are omitted, the commas must still be used.CALLThis is a required standard high level call instruction.SWAITThis is the verb for this call.nrbnumThis required parameter indicates the number of NRBs to wait for. Control is returned after the completionof any calls/NRBs specified. If nrbnum is equal to 0, outstanding NRBs to the user are updatedfollowed by an unconditional return. If nrbnum is equal to -1, wait for any request issued bythis program to finish.nrbThis parameter (required if NRBNUM >0) indicates the address of one or more NRBs (the number ofNRBs specified in nrbnum) associated with the wait request. The nrb is not needed for SWAIT (-1)or SWAIT (0).MAN-REF-H307IP-04 FORTRAN Interface Page 59


<strong>SDISC</strong> FORTRAN <strong>Call</strong>The <strong>SDISC</strong> (disconnect) call provides the means for any connected application to terminate a session. Therequest is immediate and any data currently in transport may not be delivered. If data delivery is required, itis the disconnector’s responsibility to wait for confirmation of previous SREAD or SWRIT calls before issuingthe <strong>SDISC</strong>. Before an <strong>SDISC</strong> can be issued, the user must provide a NRB with an NRBNREF relating tothis session.<strong>Call</strong> Operation ParametersCALL <strong>SDISC</strong> (nrb, buffer, length, datamd)The following parameters were shown in the <strong>SDISC</strong> call format. The parameters must be specified in the orderpresented. If parameters are omitted, the commas must still be used.CALLThis is a standard high level call instruction.<strong>SDISC</strong>This is the verb for this call. Either <strong>SDISC</strong> or <strong>SDISC</strong>W must be specified.<strong>SDISC</strong>WThis specifies that the calling program must wait for the call to complete before processing is resumed.nrbThis required parameter is the address of the NRB data area that to be passed to NETEX.bufferThis optional parameter specifies the start of an array that holds the user data that is to be sent to thecorresponding application. Note that in the single case of <strong>SDISC</strong>, delivery of data is not reliable, althoughthe actual disconnection will always occur.lengthThis optional parameter specifies the length of the data (in addressable units - words for Unisys) thatis to be sent to the corresponding application, to be presented with the completion of the correspondingapplication’s SREAD request. If no data needs to be sent to the other application, the length maybe set to zero. The data type of length should be INTEGER.datamd (optional)This parameter specifies the datamode that is to be used to send the disconnect data to the correspondingapplication. The data type of datamd should be INTEGER. Refer to NRBDMODE in“NETEX Request Block” for a discussion of the datamode parameter.Upon completion of the <strong>SDISC</strong>, the connection will no longer exist. New commands against that connectionwill be rejected. An SOFFR or SCONN must be issued to establish a new connection.<strong>SDISC</strong> Entry ParametersThe following NRB fields are used by <strong>SDISC</strong> on entry.NRBBUFA Address of outgoing Pdata.NRBLENLength of outgoing Pdata.NRLBUBITN Pdata unused bit count.NRBDMODE Datamode of Pdata.NRBPROTA Address of outgoing Odata.Page 60 FORTRAN Interface MAN-REF-H307IP-04


NRBPROTLLength of outgoing Odata.<strong>SDISC</strong> ResultsThe following NRB fields are updated when <strong>SDISC</strong> completes:NRBSTATSuccess/failure code.MAN-REF-H307IP-04 FORTRAN Interface Page 61


FORTRAN Requestor Program ExampleFollowing is an example of a remote file access program. This program prompts the user for a record number,calls NETEX to obtain the information in the remote file, and displays a portion of the contents of therecord on the user's terminal.C **********************************************************************CC Remote File Access ProgramCC This program is designed to display records in the remoteC file controlled by a direct access file service program.C The program prompts the user for the record number neededC in the remote file, calls NETEX to obtain the informationC in the remote file, and displays a portion of the contentsC on the user's terminal.CC **********************************************************************CC FNRB is the 40 words needed for a NETEX request block.CINTEGER FNRB(40)CC NXDATA is the buffer of data exchanged with the remoteC program. NXDATA(1) contains the request type;C NXDATA(2) contains the record number, and the remainderC contains the 1K bytes of file information on return.CINTEGER NXDATA(258)DATA (FNRB(I),I=1,40) /40*0/CC Connect to the program. A password must be provided inC the first two words. The remote program is assumed toC reside on host `XYZ'. If connect fails for any reason, exit.CNXDATA(1) = 1234567NXDATA(2) = 7654321CALL SCONNW (FNRB,NXDATA,2,0,’SERVER ‘,LOOPBAK ‘)IF (FNRB(1).NE.0) GOTO 900CC Read connect confirmation. If other than a confirmationC is received, disconnect and exit. If confirm is not receivedC within 30 seconds, exit.CCALL SREADW (FNRB,NXOATA,256,30)IF (FNRBC1).NE.0) GOTO 800IF (FNRB(2).NE.2) GOTO 809CC Process queryC100 WRITE (6,110)110 FORMAT (‘ Enter record number as S digits:’)READ (6,120) IRECIF (IREC .EQ. 0) GOTO 806Page 62 FORTRAN Interface MAN-REF-H307IP-04


120 FORMAT (I5)CC Send request to remote program and wait for response.C Exit if response is not received within 30 seconds.CNXDATA(1)=0NXDATA(2)=IRECCALL SWRITW (FNRB,NXDATA,2,0)CALL SREADW (FNRB,NXDATA,256,so)CC Confirm that a data indication was returned and that theC NETEX read was OK; otherwise exit.CIF (FNRB(1).NE.0) GOTO 800IF (FNRB(2).NE.3) GOTO 800IF CNXDATA(l).EQ.0) GOTO 240WRITE (6,220)220 FORMAT (` NETEX read error.')GOTO 100CC Display a portion of the returned informationC to verify read.C240 WRITE (5,360) (NXDATA(I+2) ,I=1,24)300 FORMAT (3(8(1X,I10)/))GOTO 100CC End of run or abnormal result from NETEX.C Terminate the connection.C800 CALL <strong>SDISC</strong>W (FNRB,NXDATA,e,o)900 STOPENDFigure 12. FORTRAN ExampleMAN-REF-H307IP-04 FORTRAN Interface Page 63


COBOL (ACOB) InterfaceNRB DeclarationThe NRB (NETEX Request Block) is defined as a record in working storage. Usually it will be at the 01level, but this is not necessary.01 NRB02 NRBSTAT PIC 9(8) USAGE COMP02 NRBIND PIC 9(8) USAGE COMP02 NRBLEN PIC 9(8) USAGE COMP02 NRBUBIT PIC 9(8) USAGE COMP02 NRBREQ PIC 9(8) USAGE COMP02 NRBNREF PIC 9(8) USAGE COMP02 NRBBUFA PIC 9(8) USAGE COMP02 NRBBUFL PIC 9(8) USAGE COMP02 NRBDMODE PIC 9(8) USAGE COMP02 NRBTIME PIC 9(8) USAGE COMP02 NRBCLASS PIC 9(8) USAGE COMP02 NRBMAXRT PIC 9(8) USAGE COMP02 NRBBLKI PIC 9(8) USAGE COMP02 NRBBLKO PIC 9(8) USAGE COMP02 NRBPROTA PIC 9(8) USAGE COMP02 NRBPROTL PIC 9(8) USAGE COMP02 NRBRESVI PIC 9(8) USAGE COMP02 NRBRESV2 PIC 9(8) USAGE COMP02 NRBPNAME PIC X(8)02 NRBHNAME PIC X(8)02 NRBRESV3 PIC X(8) USAGE COMP02 NRBUSER PIC 9(8) USAGE COMP02 NRBOSDEP PIC 9(8) USAGE COMP OCCURS 16 TIMESPage 64 COBOL (ACOB) Interface MAN-REF-H307IP-04


NETEX <strong>Call</strong>ing SequenceIn order to communicate between independently compiled modules, ASCII COBOL supports the CALL andthe ENTER verb. Only the use of ENTER is supported in the NETEX interface. The use of this is outlinedbelow, and the format of each of the calls is indicated. All variables are full word integers except for thoselisted below.NRB This has the record format discussed abovePNAME This is an eight (8) character ASCII string. This is an application name used in an offer orconnect call.HNAME This is an eight (8) character ASCII string. This is a host name used in a connect call.The figure below shows an example of the format for the NETEX calls in the COBOL program. To get the‘wait’ type requests, append a ‘W’ at the end of each literal. For example, use COFFRW instead of COFFR.Note the use of CWRIT, etc., in the COBOL, interface instead of SWRIT, as referenced in this document.This is necessary to keep the FTN and COBOL, entry points separate, since both are used. A reference toCWRIT is accomplished by restructuring the FCOBOL argument list into a FTN argument list and then invokingthe SWRIT entry point.ENTER MASM 'COFFR' USING NRB, BUFFER, LENGTH, TIMEOU, PNAMEENTER MASM 'CCONN' USING NRB, BUFFER, LENGTH, DATAMODE, PNAME, HNAMEENTER MASM 'CCONF' USING NRB, BUFFER, LENGTH, DATAMDENTER MASM 'CWRIT' USING NRB, BUFFER, LENGTH, DATAMDENTER MASM 'CREAD' USING NRB, BUFFER, LENGTH, TIMEOUTENTER MASM 'CCLOS' USING NRB, BUFFER, LENGTH, DATAMODEENTER MASM 'CDISC' USING NRB, BUFFER, LENGTH, DATAMODEENTER MASM 'CWAIT' USING NRBCOUNT, NRB1, NRB2,… (UP TO 7)Figure 13. NETEX <strong>Call</strong> Sequence FormatMap RequirementsYou must include the relocatable NXICOB and N2XFTN to access H307 from an ACOB program.MAN-REF-H307IP-04 COBOL (ACOB) Interface Page 65


MAPing NETEX ApplicationsTo MAP a NETEX application, you must include the appropriate interface subroutine library:• N2XFTN for ASCII FORTRAN• N2XPAS for U of Md PASCAL• N2XPLS for PLUS, etc..See the sample MAP source elements MAPFTN and MAPMASM for guidance.Page 66 MAPping NETEX Applications MAN-REF-H307IP-04


Driver InterfaceIntroductionThe Driver Interface service allows a NETEX user to invoke driver functions without using the NETEX sessionservice. This eliminates typical “session” overhead by placing responsibility for driver control directlywith the user.NOTE: Driver level calls are NOT SUPPORTED for the NESiGate Interface.Hardware ProtocolsThe user is responsible for providing all the information required by the adapter to conduct messages across anetwork. A message consists of the “message proper” and, optionally, associated data. The message properis limited to a length of 64 8-bit bytes; associated data is limited to a length not to exceed the installation definedMaximum Block Out (MAXBO) value.Two new fields in the NETEX request block are used to pass information regarding the message proper. Themessage proper is provided by the user in storage designated by the address specified as NRBPROTA. Thelength of the buffer whose address is in NRBPROTA must be specified in field NRBPROTL.Message ProperMessages must follow the format described below to be properly interpreted and executed. The first eightbytes of the message are interpreted by the adapter to direct the message to the proper destination. Byte 8optionally may be used to indicate if the message is in a NETEX format, and if the message contains satellitelink information.• Byte 0 – Trunk Mask (HYPERchannel trunk protocol only)Bits 0-3 - Trunks to Try (transmit). These bits specify to the sending adapter which of the availabletrunks to try when transmitting this message and associated data. Bits 0,1, 2, and 3 correspond to trunks0, 1, 2, and 3 respectively. The adapter transmits the message on the first trunk available of those selected.Bits 4-7 - Trunks to Try (receive). These bits specify to the receiver which trunks to try when sending anactive frame to the transmitter. It is necessary that at least one trunk, common to each adapter, be selectedfor each transmission.• Byte 1 – ControlBit D - Exception message. This bit is checked when a message is input to the channel. If this bit is set,the INPUT MESSAGE operation is terminated with an ending status of “channel end”, “device end”, and“unit exception”. If the bit is not set, the INPUT MESSAGE operation is terminated with an endingstatus of “channel end”, and “device end”. In either case, the entire message is transmitted to the channel.The exception message has no effect on transmit messages.Bit E - Burst Mode. When this bit is set, the forced burst mode is enabled. In this mode of operation, thetransmitting adapter gains access to the trunk and maintains control until the end of the transmission. NoMAN-REF-H307IP-04 Driver Interface Page 67


Trends, internationale Entwicklungen und künftige Herausforderungenin der beruflichen RehabilitationAbbildung 3-14: Status-Quo-ParadigmaQuelle: Scott-Parker 1999, 6782


DCONNECT Entry ParametersThe following NRB fields are used by DCONNECT on entry:NRBNREF 16-bit parameter for path selection.NRBREQ Set by the procedure to DCONNECT.NRBDMODE If driver data buffering is required, bit 2**35 must be set in NRBREQ. In this case, themode for all reads on this DREF must be the same NRBDMODE as specified in thisDCONNECT request.DCONNECT ResultsThe following NRB fields are updated when DCONNECT completes:NRBSTAT Request status: -1 ‘in progress’; 0 ‘successfully completed’; otherwise a positive nonzeroNETEX error code results.NRBNREF The DREF assigned for this driver connection.MAN-REF-H307IP-04 Driver Interface Page 71


Transmit Message and Data – DWRITEThe driver takes transmission requests and sends them over the network in FIFO order. The driver caller isentirely responsible for the contents of the network message and its associated data. Because of the half duplexnature of the adapter, the driver will service input requests before output requests. Since a single hardwarepath through the network is specified in the call, retry over alternate routes is the responsibility of theapplication.H307 does not support intra-host driver-level requests. Information may be sent to another driver-level useron the same host only if a hardware path is available.Operation ParametersDWRITE[W] nrb [err-return]DWRITEThis is the required procedure name.DWRITEWIf specified, control will not return to the caller until the request is completed. Otherwise, return willbe made immediately after a preliminary error check of the request.nrbThis is the required address of the updated NETEX request block (NRB) that is to be used with theprocedure. This field may have the following form:U-field[,X-reg[,J-desig]]err-returnThis optional parameter is the address for transfer of control if the request completes with an error indicationin NRBSTAT.DWRITE Entry ParametersThe following NRB fields are used by DWRITE on entry:NRBNREF The DREF for the desired connection, as assigned by DCONNECT.NRBREQSet by the procedure to DWRITE.NRBPROTA Address of the message proper to transmit.NRBPROTL Length of the message proper to transmit.NRBBUFA Address of the associated data to transmit.NRBLENLength of the associated data to transmit.NRBUBITNot used; set to zero (always sends full words).NRBDMODE Specifies assembly/disassembly and code conversion.DWRITE ResultsThe following NRB fields are updated when DWRITE completes:NRBSTATRequest status: -1 ‘in progress’; 0 ‘successfully completed’; otherwise a positive nonzeroNETEX error code.MAN-REF-H307IP-04 Driver Interface Page 73


Exec status is the operating system status returned in word 3 or 4 of an I/O request packet (depending on theinterface).Sub-status is the operating system sub-status returned farther down in an I/O request packet (depending onthe interface).Adapter Type is the type of adapter and interface being used to service this connection. The current typesare as follows:0 PB140/NB140/A140 via IOARB1 PB140/NBl40/A140 via IOADH2 A142 via IOADH3 PB22x/NB22x/A22x via IOFEP4 PB22x/NB22x/A22x via IOAID5 PB140/NBl4O via IOAID6 A142 via IOAID7 PB22x/NB22x/A22x via IOAIDChannel Status Words are the actual status words returned by the I/O processor. For the IOFEP (SINCH)interface, these words are not available. For other interfaces the Processor and Storage manual for the processortype should be consulted for the number of channel status words and their formats. The request to obtaindriver statistics is communicated to NETEX by the DSTATUS macro call.Operation ParametersDSTATUS[W] nrb [err-return]DSTATUSWIf specified, control will not return to the caller until the request is completed. Otherwise, return willbe madenrbThis required parameter is the address of the updated NETEX request block (NRB) to be used withthe procedure. This field may have the following form:U-field[,X-reg[,J-desig]]err-returnThis optional parameter is the address for transfer of control if the request completes with an error indicationin NRBSTAT.DSTATUS Entry ParametersThe following NRB fields are used by DSTATUS on entry:NRBNREF The path index returned by DCONNECT.NRBREQSet by the procedure to DSTATUS.NRBBUFLThe maximum number of words of status to accept.NRBBUFA The address of the area where the status data is stored.DSTATUS ResultsThe following NRB fields are updated when DSTATUS completes:NRBSTATRequest status: -1 ‘in progress’; 0 ‘successfully completed’; otherwise a positivenonzero NETEX error code.NRBLENThe length of status received.Page 76 Driver Interface MAN-REF-H307IP-04


NRBUBITThe unused bits in the last word of status.MAN-REF-H307IP-04 Driver Interface Page 77


InstallationPrerequisitesThe prerequisites for installing and running H307IP are:• Unisys 1100 or 2200 processor running OS 1100 release 39R1 or higher (IOAID$ supported.)• A DX/E with at least one PB225/NB22x host interface and PDNTx/NDNTx NETEX or other supportedStorageTek supported hardware attached to a FIPS blockmux channel.Or a NESiGate Channel Offload adapter with the appropriate host interface installed.Pre-InstallationBefore using H307IP, the DX/E or NESiGate adapter(s) must be defined to the exec. See Appendix C fornotes on this procedure for the various types of hardware.Installation ProcedureThe following steps are required to install and run H307IP. They are described in detail below:1. Unload tape2. Customize3. Define your network configuration and run the Configuration Manager to build a PAM file4. Load the PAM using the NCT Loader5. Verify installation6. Re-map current applications (optional)Step 1. Unload TapeThe H307 installation tape contains several files. Only the first file is required to install H307IP.@ASG,TJ@CAT,P@COPY,GH307 TAPE,T,h307H2X,F///999H307TAPE,N2XThe second file is needed to build the NCT (ConfMang) and to load the NCT (NCTL) into the offloadNETEX.@CAT,P@COPY,GCONFIG,F///999H307TAPE,CONFIGThe third file (PASCAL) is only needed if you need to make changes to ConfMang or NCTL. To load it, enterthe following@CAT,P@COPY,G@SYMPASCAL,F///999H307TAPE,PASCALN2XPRT,,devicePage 78 Installation MAN-REF-H307IP-04


Step 2. Customize H307IPStep 2a. Modify System(s) Interface Configuration (Required)The multi-site configuration feature allows you to generate H307IP for all 1100/2200 systems with a singleBLD procedure. You can also gen a single H307IP on each system. The interfaces are defined for systems inthe BLD runstream on SYS statements. The format for this is:SYS siteid1 unitname1, 1stunit, numunits, hostname, ssnm [,Netex-GNA][unitname2, 1stunit, numunits, hostname, ssnm [,Netex-GNA] ]. (field-2 repeated for each hardware interface).SYS siteid2 … (SYS SGS repeated for each site to be configured)siteidThe 1100/2200 system siteid as configured in the OS1100 sysgen. If the settings do not match, theH307IP common bank will deny access to callers. This check may be disabled by changing the tagSITECHECK in N2XDEFSunitnameThe OS2200 device name of the first configured unit (e.g. HYPA00).1stunitThe device address of the first configured unit (usually 0)numunitsThe number of devices (subchannels) to be used by H307.hostnameIf there are multiple hosts sharing an offload NETEX, then this name can be used to distinguishSOFFRs made for the same process name on the hosts (e.g. BFXJS). This name would then match aHost Group name for this NETEX in the connecting NETEX NCT. This field can be left empty ifthere is only one host using the offload NETEX.ssnmThe interface name for specific allocation requests. It is one to four alphanumeric characters. If thisparameter is not defined, SSG returns an ERROR saying that the fifth parameter is missing. Thisvalue can be specified in the NRBSSNM field to select an interface.Netex-GNAThis field must be present for DX NETEX and omitted for NESiGate offload. It is a 4-byte octal ordecimal value corresponding to the DX/E GNA address configured in the DX/E. For example, if theNETEX GNA is 0101B3C0, this field would be: 1,1,0263,0300 or 1,1,179,192.Note:There must be exactly one SYS SGS for each system for which you are building an H307IP. If youprefer to do each build on its own system, then there should be only on SYS SGS in each build. Referto the sample configuration in Figure 6.Step 2b. Modify Site-Specific Parameters (Optional)If no changes to default parameter values are needed, you may skip to the next step.The following parameters may be changed at the top of module N2XDEFS (default value in parentheses):DATATO (30)MAN-REF-H307IP-04 Installation Page 79


Seconds to allow incoming data to remain in the adapter unread before disconnecting the session (SeeNRBDATO).MAXBLOCK (65535)Maximum words of Pdata to be sent or received in one request.MAXUSERS (16)Maximum simultaneous user programs with active sessions.All other parameters should be left as set.Step 2c. Insert User Exits (Optional)If no User Exits are required, you may skip to the next step. Otherwise, see “User Exits”.Step 2d. Rebuild H307IPTo make a site-specific version of H307IP, a build must be done.Examine the element BLD in the release file and modify as necessary for local filename conventions, and editas required.1. Enter the following command:@ADD N2X.BLDThis command will produce updated relocatables (in N2X) and absolute common bank (in TPF$). Youwill be asked to specify element(s) to assemble. The normal response is one of the following: ALL or@EOF2. Copy the new common bank(s) to your registered NCCB file. There will be one for each SYS specified,called N2X$$$siteidm, plus an N2X$COMN which is a copy of the first SYS's common bank. The entireCB file should be copied to each SYS system.For Example:@USE CB,SYS$*yournccbfile@COPY,A TPF$.,CB.3. Then the common bank must be reloaded and initialized on each system. If there was only one SYS configured,enter the following command:Note:@XQT N2X.RELOADIf there are multiple sites configured, each will have a common bank in CB called N2X$$$siteid. Thecommon bank for this system must be renamed:@CHG,AThen enter the following command:@XQT N2X.RELOADCB.N2X$$$siteid,.N2X$COMN“Step 3. Define Network Configuration and Run the Configuration Manager” and “Step 4. Load thePAM Using the NCT Loader” are only required when the offload NETEX is initially configured, andthen only after network configuration changes.Page 80 Installation MAN-REF-H307IP-04


Step 3. Define Network Configuration and Run the Configuration ManagerThe Configuration Manager program takes statements that describe the entire network and produces an outputfile known as the PAMFILE. This PAMFILE is used by NETEX for the physical addressing informationneeded to access a remote host. The PAMFILE is downloaded to the DX NETEX Co-processor or the NE-SiGate adapter by the NCT Loader.Note: The Configuration Manager attempts to process all columns of a control statement. Be sure that thereare no sequence numbers in columns 73-80; start in column one.Note: All Configuration Manager commands MUST be entered in uppercase.The following steps describe how to use the Configuration Manager.1. Create a network description for the Configuration Manager using the configuration statements describedin Configuration Manager Statements. There are several sample NCTs in the config file named, CONFand element/CONF.2. Start the Configuration Manager. The program will prompt for input control statements.@XQT CONFIG.CONFMANGThe control statements follow:NCT filenameThe NCT command reads the network configuration from the file name that must have been previouslyassigned.If you receive errors because of this step, correct the errors in the network configuration file and thenrerun the Configuration Manager.SELECT hostnameThe SELECT command is used to select which hosts should be used as destinations in generating thePAMFILE. If the SELECT statement is omitted, or if SELECT * is specified, all hosts are selected.If all hosts and groups defined in the configuration statements are desired as destinations, omit thecommand. If only selected hosts are to be defined to NETEX (allowing them to be used as destinations),list them using one or more SELECT statements. A group name may be specified in aSELECT statement as a hostname. Use a SELECT statement for each hostname within the groupname that you wish to use individually.DESELECT hostnameThe DESELECT command is used to deselect host and group names that should not be used as destinations.If any implicitly or explicitly SELECTed hosts are to be DESELECTed, list them using oneor more DESELECT statementsMAKEPAM hostname pamfileThe MAKEPAM command creates a PAMFILE for the specified host, writing it to the specified outputfile that must have been previously assigned. This command must be preceded by an NCT statementand any necessary SELECT or DESELECT statements. If there are no preceding SELECTstatements, then all hosts on the network are selected.If you receive errors because of this step, correct the errors in the network configuration file and thenrerun the Configuration Manager.EXITThe EXIT command stops the Configuration Manager.MAN-REF-H307IP-04 Installation Page 81


Step 4. Load the PAM Using the NCT LoaderThe PAMFILE created in the proceeding step by the Configuration Manager must be made available to theDX NETEX Co-Processor or the NESiGate adapter. The NCT Loader is used to accomplish this function.To execute the loader enter:@XQT N2x.NCTLThen, following the prompts, enter the following command.NCTL> LOAD pamfile hostnameWhere:pamfileThis is the name of the PAMFILE created when the MAKEPAM command was executed.hostnameThis is the name of the host, where the PAMFILE is located.For more information on loading the PAMFILE, see NCT Loader Software Reference Manual. For informationon error messages, see PDNT3/NDNT3 DX NETEX Co-Processor Customer Software Reference ManualNote: The “write-enable” micro-switch on the DX NETEX co-processor board must be selected when doingthe load operation, or the new NCT cannot be saved across a master-clear. If write-enable is not selected,NCTL will return an error 18 message.Step 5. Verify InstallationTo verify proper installation and configuration of the network and local host interface, run the supplied programNTXCONN. This program will do a simple connect to any specified host and report the result.@XQT N2X.NTXCONNThe program will prompt for host and process name. The process name can be a dummy for the test.Step 6. Re-MAP current H300 Applications (optional)If you have local or Network Executive Software applications that run with host NETEX (H300) they must bere-mapped if they are to run with H307IP. To do this, use the MAP symbolic, MAPFTN and MAPMASM, assamples.MASM programs must be reassembled to pickup the new common bank entry point.Note:It is not necessary to do this again if a change is applied to H307IP, unless the change is in a collectedinterface module (for example, N2XFTN, N2XPAS).Page 82 Installation MAN-REF-H307IP-04


Sample H307IP System ConfigurationFigure 16. Sample H307IP ConfigurationThen the SGS statements for “Step 2. Customize H307IP” might be:SYS U1100A N2A100,0,16,0000,N2A1, N2B200,0,16,0100,N2B2SYS U2200B N2B200,0,16,0100,N2B2, N2A100,0,16,0300,N2A1MAN-REF-H307IP-04 Installation Page 83


User ExitsH307IP provides user exits to allow installations to maintain additional control over the use of NETEX. Theexits provided are ‘dummy exits’ that may be modified by the local site. Table 3 lists the user exits and theirfunctions.Table 2. User Exits and Their FunctionsEntryUSEREXIT1USEREXIT2Functionreceives control before request is given to NETEX.receives control after request completesUSEREXIT1The USEREXIT1 exit is called before the request is given to the DX NETEX Co-processor or NESiGateChannel Offload software.The exit provides the site with some control over NETEX use. Individual requests can be validated or modifiedas desired, and subsequently they can be accepted or rejected.Entry ConditionsThe following registers are available on entry:X8address of the user’s NRBA0return addressA2-A5, R1-R2 may be destroyed by the exit routine.ExitIf the request is to be rejected, it is not given to the DX NETEX Co-processor nor to the Channel Offloadsoftware. A return code may be placed in the NRBSTAT field of the user’s NRB. NRBSTAT may be setpositive by the exit to indicate rejection.USEREXIT2The USEREXIT2 exit is called after a request has been completed by the DX NETEX Co-processor or NE-SiGate software.This exit provides the installation with some control over NETEX use. Individual requests can be validatedas desired, and subsequently they can be accepted or rejected.Entry ConditionsThis exit is called from the I/O completion routine. Any registers that are used must be saved and restoredbefore returning. The user’s NRB has been updated by the completion of the request except for thePage 84 User Exits MAN-REF-H307IP-04


NRBSTAT field. The address of the user’s NRB and the completion code that will later be placed in theNRBSTAT field is passed to the user exit.The following registers are available on entry:X8address of the user's NRB. The tentative return code is found in NRBCSTAT, X8A0return addressA2-A5, R1-R2 may be destroyed by the exit routineExitA new return code may be placed in the NRBCSTAT field of the user’s NRB.User Exits InstallationThe user exits are installed by adding the local code with a TCF to the @SSG stream, reassembling theN2XEXIT module and remapping the common bank using the normal BLD procedure previously described.MAN-REF-H307IP-04 User Exits Page 85


Utility/Test ProgramsNTXCONSThis program allows a user or operator to monitor messages and status of the local DX NETEX adapter, andany other host connected to NETEX with a remote operator interface enabled. It may be run demand orbatch.To execute this command demand, enter:@XQT[,options] N2X.NTXCONSNTXCONS has the following @ XQT options:K Use the KEYIN$ interface, not the AREAD$/APRINT$ interface.N Do not send output messages to PRINT$ file in addition to the requestorR Retain routing to last requestor. If this is set, unsolicited messages from the connected DX NETEXadapter will be sent to the last user who did a command via KEYIN$.NTXCONS will accept the following commands:CONNECT [host]DISCONNHDLS[n]HDLXHELPIFDISPLAYIFDR ssnmStart NTXCONS NETEX session. If host is omitted, the first locally attachedNETEX is used.Terminate NTXCONS NETEX sessionInitiate loopback server, on interface number n (if n is specified). This command willdisplay the hexadecimal DREF to be used as the target of a Host Driver Loopback(HDL) message from any NETEXThis command terminates loopback server.This command prints the HELP menu.This command displays the interface status.This command drains the interface (ssnm is the four-character name on the SYScard.)IFHA ssnm This command halts the interface (ssnm if the four-character name on the SYS card.)IFST ssnmThis command starts the interface (ssnm is the four-character name on the SYS card.)KILLThis command aborts NTXCONS.@EOFThis command exits NTXCONS.TRACEON/OFF This command sets and clears tracing for H307IP.Once connected, any NETEX command can be issued. If KEYIN$ is being used, the caller must have FULLor DISPLAY console privileges; if not, no validation of the caller is done.Note: The NTXCONS service is not currently available on the NESiGate platform.Page 86 Utility/Test Programs MAN-REF-H307IP-04


NTXEAT and NTXGENThis pair of programs provides a one-way data transfer and timing test between systems, either intra-host (viathe channel interface), or to/from the corresponding applications on the NETEX adapter. To use, first startthe NTXEAT program on the receiving system:@START N2X.EAT on a Unisys host, or ST EAT on the NETEX adapter.Next, execute the NTXGEN program on the sending system. To execute the NTXGEN program, enter thefollowing command:@XQTN2X.NTXGENThe system will prompt you for a string of parameters in fixed format, formatted like:bbbbb sssss 111 mmm rrrrr hhhhhhhhwhere:bbbbb specifies the number of blocks.ssssss specifies the size of each block (in words.)lllspecifies the number of loops.mmm specifies the mode, in decimal (that is, 257 = octet mode = 0101 hexadecimal.)rrrrr specifies the rate. (This parameter currently is ignored by H307.)hhhhhhhh specifies the hostname where NTXEAT is offered.After each completed loop, both programs will print elapsed time and bit rate.If the ‘F’ option is specified on the @XQT of NTXGEN and/or NTXEAT, the program will run real-time.NTXOFFRSThis program does a number of offers (50) with one second timeouts to cycle through the available subchannelsavailable to H307IP. To execute this command, enter:@XQTNTXDATAN2X.NTXOFFRSThe program is similar to both NTXEAT and NTXGEN. It connects to itself and writes blocks with a knownpattern and verifies the returned data. It is meant to verify the channel interface and accessibility of the offloadedNETEX in the adapter. To execute this command, enter:@XQTNTXOPERN2X.NTXDATAThe NETEX remote operator utility may be used to send a single command and receive the response from anyNETEX supporting the NTXOPER process: To execute this command, enter:@XQTN2X.NTOPERMAN-REF-H307IP-04 Utility/Test Programs Page 87


The program will respond with the following message:ENTER HOSTNAME OR BLANKS FOR THIS HOSTEnter the hostname you want NTXOPER to connect to, then enter any commands when solicited withREQUEST>Page 88 Utility/Test Programs MAN-REF-H307IP-04


Configuration ManagerNETEX provides a configuration manager that is used to describe the topology of the entire network. Oneconfiguration file defines the network for all hosts, so that there is no need to generate different files for eachhost.Using the Configuration ManagerThe Configuration Manager program (CONFMANG) is executed by the user “off-line” to NETEX. The outputof this process is a file of PAMs (Physical Address Maps, or network routes) that will be read by NETEXat initialization time, and also whenever the operator issues a LOAD NCT command.The output file, which may be an SDF file or program file element, is referred to as the PAMfile. The inputfile, or element, describing the network is referred to as the NCT, or CONFFILE.The following describes how to use the Configuration Manager.1. Create or update the CONFFILE. Use the Configuration statements described below. It may be helpfulto refer to the sample configuration in the file CONFIG.2. Execute CONFMANG, as follows:@xqt[,s]config.CONFMANGThe program prompts for the next command (NCT, DESELECT, EXIT, etc.) The command must be inuppercase letters.Note: The keyword ECHO may be used to display input lines as they are read. NOECHO disablesechoing. ECHO may also be set by using the S option.3. Enter the following: NCT CONFFILE or NCT file.CONFFILEThis starts the configuration processor using the NCT you specified (CONFFILE). If you receive errorsas a result of this step, enter EXIT to leave the configuration manager, correct the errors in your configurationfile, then return to Step 2.The configuration manager automatically generates all possible loopback paths (paths out one localadapter and in another). The host name given to the PAMs with all the loopback paths is NTXLCL. APAM is also created for each individual loopback path. The host name given to each one of these isNTXLCLnn, where nn is in the range 00 to 99. NTXLCL may be SELECTed or DESELECTed.Note: A warning message (CONF060E) is issued if there are no possible loopback paths. The messagereads as follows:No path from host hhhhhh to NTXLCL4. If all hosts and groups defined in the configuration statements are desired as destinations, omit this step.If only selected hosts are to be defined to NETEX (allowing them to be used as destinations), list themusing one or more SELECT commands. Enter the following:SELECT hostname hostname...This command names NETEX hosts (identified in the configuration statements) for which paths are to begenerated. If the SELECT command is omitted, or if SELECT * is entered, all hosts are used.If a small number of host destinations are to be omitted, enter:MAN-REF-H307IP-04 Configuration Manager Page 89


DESELECT hostname hostname...5. To generate the paths, enter:MAKEPAM hostname pamfile.hostnameThe hostname is the name of the “from host” or group, i.e. the host where the output file produced by thisprocess will be used. All paths generated will be printed. The output of this step is placed in omnibuselement hostname in the file PAMFILE, which must be made available to NETEX as NETEX$CONFIG.On the local system, hostname must match that on the HOST initialization statement. When NETEX isstarted, or LOAD NCT is requested, the omnibus element NETEX$CONFIG.host is accessed.6. To exit the configuration manager program: EXITConfiguration FileThe configuration file contains the configuration manager statements that describe the user’s network. Tenstatement types are used to describe this:• VERSION specifies the version number of this configuration file.• LOCALNET describes all equipment that is interconnected via one or more coaxial trunks. Statementsdescribing the equipment on that network follow the LOCALNET statement.• TRUNK specifies a coaxial cable that is used to connect adapters on the network. In the HYPERchannel10-Mbps network, the trunk is the same as the LOCALNET so it need not be specified.• HB specifies a bus that is used to connect adapters on a 10 Mbps HYPERchannel network (obsolete).• HOST describes a host processor that has a connection to the network via one or more processor adaptersor bus interface units.• ADAPTER specifies the address and characteristics of the processor adapter, DXU, or similar equipmentthat is attached to the HOST.• LINK describes a connection to another local network via a StorageTek link adapter.• PORT describes a communication interface from the LINK to a similar PORT on a differentLOCALNET.• END specifies the end of the network configuration.The syntax rules for these statements are as follows:• Statements can only be up to 64 characters in length.• The ASCII tab character is not recognized.• All reserved words MUST be in upper case. A reserved word is the name of a statement (e.g.,LOCALNET) or a parameter (e.g., TYPE).• All references to identifiers MUST be identical to the identifier. The same combination of upper andlower case must be used (e.g.,. TO = Beta references the label “Beta” NOT “BETA” or “beta” or anyother combination).• If a label is present, it must begin in the first character position of the statement, with no leading blanks.At least one space must separate the label from the statement type and the statement type from the parameters.If a label is missing, at least one blank must precede the statement type.• A comma “,” or a blank is used as separators within a line to delimit the parameters of each statement.• Continuation statements are denoted by at least one blank preceding the statement.• If an asterisk is detected in the first character position of the statement, the entire statement is treated as acomment.Page 90 Configuration Manager MAN-REF-H307IP-04


• The beginning of an in-line comment is identified by an asterisk (*). The portion of the line from the * tothe end is ignored. A line may be longer than 64 characters only if positions 64 to 80 are part of an in-linecomment initiated by an *.Note: References to P/NB140 also apply to A140, and those to P/NB22x also apply to A223.MAN-REF-H307IP-04 Configuration Manager Page 91


VERSION StatementThe VERSION statement specifies a site-dependent number assigned to the configuration file. Valid valuesare 0 through 255. If used, it must be the first statement in the file.The VERSION statement has the following format.Name Statement ParametersVERSIONnnnThe following control words are used in the VERSION statement.VERSIONThis is the verb for this statement,nnnThis operand contains optional value assigned to the configuration file.Page 92 Configuration Manager MAN-REF-H307IP-04


LOCALNET StatementThe LOCALNET statement defines the name of the local network. The term “local network” signifies Hosts,Adapters and Trunks sectioned into logical groups and separated by one of the high speed communicationslinks. The presence of a link does NOT necessarily mean that there are two local networks. A singleLOCALNET may have links connecting within itself. The first statement in the configuration file must be aLOCALNET statement. All TRUNK, HOST, ADAPTER, LINK, and PORT statements for that local networkmust follow the LOCALNET statement. The presence of a second LOCALNET statement, regardlessof the label, will begin the description of a second local network. At least one LOCALNET statement mustbe present in any network configuration.The LOCALNET statement has the following format:Name Statement Parameters[label] LOCALNET TYPE=HCThe following control words are used in the LOCALNET statement.labelThis optional label specifies the name of this local network. This label should be used to make theNCT more readable. The label may be any name desired by the user which is one to eight alphanumericcharacters long. It must be unique from all other labels in the network configuration. A typicallabel would be the site ID of the network which is referenced by remote sites.LOCALNETThis is the verb for this statement.TYPEThis required parameter specifies the type of local network to be described. HC stands for HYPERchannelnetwork.MAN-REF-H307IP-04 Configuration Manager Page 93


TRUNK StatementThe TRUNK statement identifies a “run” of coaxial cable used in a local HYPERchannel network. One trunkstatement must be present for each run. This statement is not specified in describing HYPERchannel-10 networks.Hardware connected to the trunk is identified in subsequent HOST and LINK statements. AllTRUNK statements in a HYPERchannel local network must immediately follow the LOCALNET statementand precede all HOST and LINK statements that define the usage of the trunks. The range of a trunk is a singlelocal network. A TRUNK defined in one LOCALNET may NOT be referenced in another.A trunk begins with a hardware terminator at some network adapter, proceeds through a series of adapters,and ends with another terminator on the last adapter. Each of these trunks is given a label so that NETEXsoftware can determine the trunk paths used to communicate with any other adapter on the network. Note thatthe label is required.The TRUNK statement has the following format.Name Statement ParameterslabelTRUNKThe following control words are used in the TRUNK statement.labelThis required label specifies the name of the trunk. The label may be any name desired by the userthat is from one to eight alphanumeric characters long. It must be unique from all other labels in thenetwork configuration. Typical labels are ALPHA, BETA, etc.TRUNKThis is the verb for this statement.Page 94 Configuration Manager MAN-REF-H307IP-04


HB Statement (obsolete)The HB statement identifies a run of coaxial cable (bus) used in a local HYPERchannel-10 network. Hardwareconnected to the cable is identified in subsequent HOST and LINK statements. All NB statements in aHYPERchannel local network must immediately follow the LOCALNET statement and precede all HOSTand LINK statements that define the usage of the bus. The range of an HB statement is a single local network.An NB defined in one LOCALNET may not be referenced in another.Each bus is given a label so that NETEX software can determine the paths used to communicate with anyother adapter on the network. Note that the label is required,The HB statement has the following format.Name Statement ParameterslabelHBThe following control words are used in the HOST statement.labelHBThis required label specifies the logical name of the network. The label may be any name desired bythe user which is from one to eight alphanumeric characters long. It must be unique from all other labelsin the network configuration.This is the verb for this statement.MAN-REF-H307IP-04 Configuration Manager Page 95


HOST StatementThe HOST statement provides NETEX with information about a particular host in the network. One HOSTstatement is required for each host in the network.The HOST statement must follow the LOCALNET and TRUNK statements for that local network. AllADAPTER statements describing the configuration of the host must immediately follow the HOST statement.Note that the label is required. The parameters TYPE, MODEL, and OS are for clarity only and may beomitted. The parameters GROUP and PROTOCOL are used as needed and may be repeated within a singleHOST statementThe HOST statement has the following format.Name Statement Parameterslabel HOST [TYPE = manufacture product line][MODEL = model number][OS = operating system name][GROUP - group name][PROTOCOL = n][RATE = nnk][OPTIONS = NOAPR]The following control words are used in the HOST statement.labelThis required label specifies the logical name of the host. This label is to be the same name specifiedin the HNAME field of user connections. The label may be any name desired by the user which isfrom one to eight alphanumeric characters long. It must be unique from all other labels in the networkconfiguration.HOSTThis is the verb for this statement.TYPEThis optional parameter specifies the physical characteristics of the HOST by defining the trade nameof the manufacturer’s CPU product line. This parameter should be used to make the NCT more readable.The “manufacturer_product_line” may be an alphanumeric string from one to eight characterslong.MODELThis optional parameter specifies the model number within the manufacturer’s product line. This parametershould be used to make the NCT more readable. The “model number” may be an alphanumericstring from one to eight characters long.OSThis optional parameter specifies the operating system running on the machine. This parametershould be used to make the NCT more readable. The “operating system name” may be an alphanumericstring from one to eight characters long.GROUPThis optional parameter specifies the logical name of a group of hosts that this HOST belongs to. Ifthis HOST fits into more than one group, this parameter may be specified as many times as needed.The “group name” may be an alphanumeric string from one to eight characters long.PROTOCOLPage 96 Configuration Manager MAN-REF-H307IP-04


RATEThis required parameter specifies the protocol level of NETEX that will be used between the twohosts specified in this route. All release 1.x NETEX products use only type 1 protocol. All release2.x NETEX products use either type 1 or type 2 protocol. All release 3.x NETEX products use onlytype 2 protocol. The following protocol-type codes are used with the PROT operand.1 = use type 1 protocol only2 = use type 2 protocol only (default)Check the release levels of the NETEX products used in your configuration. If any release 1.xNETEX is used, use PROT=1 for all routes to or from the release 1.x NETEX host. If any release 3.xNETEX is used, use PROT=2. If both type 1 and type 2 protocols are used, both PROT=1 andPROT=2 are explicitly used in the same HOST statement.This optional parameter specifies the limit on transmission rates to this host. The rate is expressed asa decimal number followed by K (kilobits per seconds).OPTIONSThis optional parameter specifies options that apply to the host. The only defined option is NOAPR,indicating that the host does not support Alternate Path Retry.MAN-REF-H307IP-04 Configuration Manager Page 97


ADAPTER StatementThe ADAPTER statement describes each adapter and Bus Interface Unit (BIU) to NETEX. The ADAPTERstatements for each adapter or BIU attached to a host must immediately follow the HOST statement.Name Statement Parameters[label] ADAPTER MODEL = nxxxNETADDR = xxSMGDREF = xx[SMGNREF – xxxx][CHANADDR = cuu][NUMADDRS = n][DEVNAME = device name]T0 = labelT1 = labelT2 = labelT3 = labelPORT = 0 | 1 | 2 | 3[ADAPT = label][INTRFACE = PIxx]The following control words are used in the ADAPTER statement.labelThis optional label specifies a symbolic name for the processor adapter or BIU. The label may be anyname desired by the user which is from one to eight alphanumeric characters long. It must be uniquefrom all other labels in the network configuration. It is helpful for operations if this is the same as theControl Unit name of the adapter.ADAPTERThis is the verb for this statement.MODELThis required parameter defines the type of equipment attached to the HOST. Only processor adaptersmay be specified. The model number begins with an “A” or “N” (adapter) or a “B” (BIU), followedby three decimal digits.NETADDRThis required parameter defines the hexadecimal network address of the adapter or BIU on the localnetwork. The operand “xx” consists of two hexadecimal digits that specify the eight-bit adapter orBIU address. It must be unique from all other NETADDRs in this specific LOCALNET. This operandis required in all ADAPTER macros.SMGDREFThis required parameter specifies the subaddress for this host’s session manager. The value correspondsto a specific subchannel or port for all input operations from the local adapter. It consists oftwo hexadecimal integer digits. The default value is “00”. PBl40/NBl40s require the 00 value. Forall other adapter types, this operand should be specified, because the value will not usually be 00.When specified, SMGDREF must be defined on all ADAPTER statements referencing the host.• For A142 Adapters and PB22x/NB22x interfaces on H307IP, SMGDREF must equal the samevalue as the two low-order hex digits from the CHANADDRS (for example, ifCHANADDRS=240, then SMGDREF= 40).Page 98 Configuration Manager MAN-REF-H307IP-04


CHANADDRS begins a range of addresses, NUMADDRS identifies the number of addresses inthis range. For example, if CHANADDRS = 240, and NUMADDRS = 4, then the range of addressescontains 240, 241, 242, and 243. For Unisys, SMGDREF=40 (from the first address inthe range - also the value of the two lower-order hex digits of the CHANADDRS). For IBMhost-based NETEX, SMGDREF can be derived from any of the values in the range. (By convention,it is usually the highest value in the range.)• For DX-NETEX, SMGDREF must be the two low-order hex digits of the lowest profiled address.• For P/NB40x adapters, SMGDREF is the sum of the PORT and the two low-order hex digits ofthe DREF (for example, if PORT= 1 and DREF = 2040, then SMGDREF = 41). The PORTnumber is one of the four ports (0, 1, 2, or 3) from the hard-wire hookup on the back of theadapter. The DREF is shown as a four-digit hexadecimal value in most NETEX displays. Itsvalue is derived in different ways, depending on which host-based system is involved.In general, the first two digits of the four-digit DREF are the physical unit number of the device.The second two digits are either the subchannel address (for channel adapters) or the path withtwo zero bits (for adapters with PORTs).Unit numberfor deviceDREF---- path --- 0 0Figure 17. 16-bit DREFWhen DREF is shown as a two-digit hexadecimal value, it is the second two digits of the fourdigits described above. Only the two-digit hexadecimal DREF is used for calculating thevalue of SMGDREF.SMGNREFThis optional parameter specifies the transport reference subaddress for this host’s session manager.This value corresponds to a specific process within a task specified by SMGDREF. It consists of fourhexadecimal digits. The default value is “FFFF”. This operand need not be specified unless the userwishes to change the default. Then the operand must be defined on all ADAPTER statements referencingthis host.There are no conditions at the present time which would require the user to change the default.Therefore, SMGNREF should not be used except for documentation in the configuration file, and inthat case it should be defined as “FFFF”.CHANADDRThis parameter, which is required only when using non-word channel adapters, specifies the lowestchannel unit address of a group of units to be used by the NETEX software. This channel unit addressmust be expressed as three or four hexadecimal digits, for example, CHANADDR = 3C0.Note: H307 does not use this value, but it may be needed if a common NCT is used with an IBMsystem.NUMADDRSThis parameter, which is required only when using A142 and PB22x/NB22x adapters, specifies themaximum number of adapter subaddresses that will be used by NETEX. The number of subaddressesmust be expressed as a decimal number from 2 to 64 (example: NUMADDRS = 32).OPTIONSThis optional parameter specifies several hardware options. This information will be stored as a bitmask; any options selected will set the corresponding bit in the mask. Defined options are as follows.8KMEM - 8K memory buffer is installed (obsolete).MAN-REF-H307IP-04 Configuration Manager Page 99


CODECONV - Hardware code conversion is installed. Note that this must be specified ifhardware code conversion is to be used.DEVNAMEThis parameter, which is optional except for H307, specifies a logical device name for this adapter.The “device name” may be from one to eight alphanumeric characters. The DEVNAME is requiredfor H307 (for adapters on the local host). It identifies the device name which NETEX will use to assignthe device. It must match the name assigned to the device in the OS2200 sysgen.For P/NB220 adapters, this is the lowest device which NETEX will use. The other device names aregenerated by incrementing the last nonblank character of DEVNAME. It is suggested that theDEVNAME end in at least one “0” digit.T0, T1, T2, and T3This required parameter defines the trunks that are attached to the network adapter. At least one operandmust be defined for each HYPERchannel adapter. As there are no TRUNK statements in defininga HYPERchannel 10-Mbps network, these parameters are not used in that context. The associatedlabels specify the label of a preceding TRUNK statement. The referenced TRUNK must be definedin this LOCALNET. The physical placement of the trunks in the back of the adapter is quiteimportant; T0 is the trunk interface on the left as one faces the back of the adapter, and T3 is therightmost trunk interface. If any of the four operands are missing, the adapter is assumed not to havea trunk interface in that position.Note:The hardware always scans from highest (T3) to lowest (T0). Proper configuration of thetrunks allows balance of the network traffic.PORTThis parameter which is required when using P/NB40x adapters only, specifies the port number towhich the associated HOST is attached. This operand is ignored unless MODEL=n4xx is specified inthe ADAPTER statement. This value is specified as a decimal integer. Valid port numbers are 0, 1,2, and 3 (decimal).ADAPTThis is required only if a single processor has more than one interface to a single P/NB40x adapter.This parameter is optional when using P/NB40x adapters. This value is specified as one to eight alphanumericcharacters.Of all the ADAPTER statements for a multi-port adapter, only one may have its label specified. Thatone will be referred to as the “main” adapter. The main adapter should not have its ADAPT parameterspecified. All subsequent ADAPTER statements referencing the main one must specify theirADAPT parameters to be the label of the main adapter. MODEL, NETADDR, and Tx parameters onsubsequent ADAPTER statements must agree with those parameters for the main ADAPTER definition.The ADAPTER statements may be in any order, but the main adapter must have a label specified.The ADAPT parameter is NOT used in defining a multi-task adapter. However, it may be used whendefining a multi-task, multi-part adapter. The following examples describe the same configuration intwo different ways to explain the ADAPT parameter when defining a multi-task, multi-port adapter.H1 HOSTmain ADAPTER MODEL=N400, NETADDR=01, T0=Alpha,PORT=l, SMGDREF=61H2 HOSTADAPTER MODEL=N400, NETADDR=61, T0=Alpha,PORT=1, SMGDREF=03H3 HOSTPage 100 Configuration Manager MAN-REF-H307IP-04


Another way:H1H2ADAPTERHOSTADAPTERHOSTADAPTERMODEL=N400, NETADDR=61, T0=Alpha,PORT=2, SMGDREF=02, ADAPT=mainMODEL=N400, NETADDR=61, T0=Alpha,PORT=1, SMGDREF=6l, ADAPT=mainMODEL=N400, NETADDR=61, T0=Alpha,PORT=1, SMGDREF=03, ADAPT=mainH3 HOSTmain ADAPTER MODEL=N400, NETADDR=01, T0=Alpha,PORT=2, SMGDREF=02INTRFACE (optional)This parameter, which is required when using P/NB40x interfaces, specifies the type of interface usedto connect the host to the P/NB40x interface. This operand is ignored unless MODEL=x400 is specifiedin the ADAPTER statement. This operand is not currently used by NETEX and therefore is forreadability only. The option may be any name desired by the user which is from one to eight alphanumericcharacters long.MAN-REF-H307IP-04 Configuration Manager Page 101


LINK StatementThe LINK statement is used to specify a network adapter or BIU on the current LOCALNET that is a gatewayto some other local network.Name Statement Parameters[label] LINK MODEL = nxxxNETADDR = nnT0 = labelT1 = labelT2 = labelT3 = labelPORT= 0 | 1 | 2 | 3[ADAPT = label]For non-SLS links only:[MODE710 = nn]The following control words are used in the LINK statement.labelThis optional label specifies a symbolic name for this link. The label may be any name desired by theuser which is from one to eight alphanumeric characters long. It must be unique from all other labelsin the network configuration. This label is optional unless this LINK statement is defining port 0 of amultiport x4xx link.LINKThis is the verb for this statement.MODELThis required parameter specifies the type of link adapter or BIU.NETADDRThis required parameter specifies the eight-bit hexadecimal address or addresses of the link adapter orBIU on the local network. The operand must be expressed as two hexadecimal digits. It must beunique from all other NETADDRs in this specific LOCALNET. In the case of the A710 adapter, itshould contain the same setting as is found on the back of the A710 adapter. The A710 is unique inthat the switch settings do not reflect the actual address of the adapter. One to eight ranges of 32 addressesare selected based on the bit pattern specified by the hexadecimal value in the switches,The S720 Satellite Link Subsystem (SLS) consists of two basic units: the A721 Transmit Adapter andthe A722 Receive Adapter. Only the S720 needs to be described in the configuration when definingan SLS. The S720’s NETADDR specifies the A721 network address. The corresponding A722ALWAYS has an address that is one greater than the A721. No other adapter on this local networkmay specify the same NETADDR as the A721 or A722. The A721 and A722 Adapters are implicitlydefined when the S720 is defined.The A715 link has as its NETADDR the address of the SLS in 720-mode. This represents a singleaddress, not two addresses as does the basic S720 link described above.P/NB70x links have as their NETADDR the base address used for SLS 720 mode operation (as withthe 715 units).T0, T1, T2, and T3These parameters, which are required when using A71x and S720 link adapters, define the trunks thatare attached to the link adapter. At least ONE operand must be defined for each link. The associatedPage 102 Configuration Manager MAN-REF-H307IP-04


labels specify the label of a preceding TRUNK statement. The physical placement of the trunks inthe adapter is quite important; T0 is the trunk interface on the left as one faces the back of the adapter,and T3 is the rightmost trunk interface. If any of the four operands are missing, the adapter is assumednot to have a trunk interface in that position.Note: AC715s are limited to two trunks. Most configuration manager routines require T3 and T2 tobe defined. However, physical connections of any combination of two trunks are allowed.MODE710This optional parameter specifies the eight-bit hexadecimal address that the 715 link will accept whenit is in 710-mode. This parameter is repeated for each address desired. If no address is to be acceptedin the 710-mode, this parameter may be omitted. The operand must be expressed as two hexadecimaldigits.A715 links that are not in 710-mode will default to SLS. If MODE710 is specified, both 710-modeand SLS-mode paths are generated.MAN-REF-H307IP-04 Configuration Manager Page 103


PORT StatementAt least one PORT statement must be supplied following each LINK statement. Port statements have twomajor functions: to identify the link adapter or BIU on the other side of the communications link, and to describecertain characteristics of the link.Each HYPERchannel communications link has two PORT statements that each describe one end of the link.Each of the two PORT statements follow the LINK statement that describes the link adapter configuration oneach end, and the two LOCALNET statements that describe the two local networks connected by the communicationsline. Note that the port lab is required.Name Statement Parametersport_lab PORT DEST = port_labRATE = nnKDELAY = nnnMSEGSIZE = nnnnThe following control words are used in the PORT statement.port_labThis specifies a symbolic name for this port and is required. The port lab may be any name desiredby the user which is from one to eight alphanumeric characters long. It must be unique from all otherlabels in the network configuration. This port lab is used in conjunction with the DEST=port_lab parameteron other PORT statements.PORTThis is the verb for this statement.DESTThis required parameter specifies the label of the PORT statement describing the other end of thecommunications link in another local network.RATEThis parameter which is required when using Axxx and S720 links, describes the communicationsspeed of the line in 1000 bits per second. This value is used by the NETEX software to plan forbuffer usage and buffer size requirements. RATE is expressed as a decimal number followed by “K”representing one thousand bits per second,DELAYThis parameter, which is required when using Axxx and S720 links, specifies the propagation delayof the communications line in milliseconds. The delay is expressed as the length of time needed for asignal to go from one end of the communications line to the other end. For terrestrial links of under30 miles, DELAY = 0 (the default) is acceptable. For longer terrestrial links, or satellite links thisvalue must be specified for optimum performance on the link. DELAY is expressed as a decimalnumber followed by “M” representing one millisecond. As a general rule, one msec. of delay is equalto 100 miles.SEGSIZEThis optional parameter specifies the maximum data transfer size in bytes for this link path.SEGSIZE is expressed as a as decimal number. The maximum for any HC-l0 link is 4096.Page 104 Configuration Manager MAN-REF-H307IP-04


END StatementThe END statement indicates the end of the Network Configuration statements. This must be the last networkconfiguration statement.The END statement has the following format.Name Statement ParametersENDThe following control words are used in the END statement.ENDThis is the verb for this statement.MAN-REF-H307IP-04 Configuration Manager Page 105


Network Configuration Example* Current Network Version Number (Site Dependent)VERSION 255** Describe Hyperchannel Network*HOME LOCALNET TYPE=HC** Define all trunks on the net (up to link)*ALPHA TRUNKBETA TRUNK** Define Hosts on ‘HOME’ Network*IBM HOST TYPE=IBM, MODEL=3033AP, OS=MVS,ADAPTER MODEL=A223, NETADDR=01, T3=BETA, T2=ALPHA,CHANADDR=270, NUMADDRS=4, SMGDREF=73ADAPTER MODEL=A223, NETADDR=02, T3=BETA, T2=ALPHA,CHANADDR=320, NUMADDRS=4, SMGDREF=23VAXA HOST TYPE=VAX, MODEL=8350, OS=VMSVAXA406 ADAPTER MODEL=A400, NETADDR=03, T3=BETA, T2=ALPHA,PORT=0, INTRFACE=PI218, SMGDREF=04** Link adapter connecting to AWAY Network*LINKMODEL=AC730, NETADDR=05, T3=BETA, T2=ALPHA,T3=BETA, MODE7l0=10, MODE710=11HOMEP PORT DEST=AWAYP, RATE=1544K, DELAY=0M** Link adapter (SLS) connecting to BUSNET Local Network*LINK MODEL=AC715, NETADDR=40, T3=ALPHA, T2=BETA,CHANLINK PORT DEST=BUSLINK, RATE=1544K, DELAY=0lM** Describe BUSNET Network*BUSNET LOCALNET TYPE=HCDELTA TRUNK** Define systems on the ‘BUSNET’ network*MINIA HOST TYPE=MICROVAX, OS=VMS, MODEL=2,ADAPT06 ADAPTER MODEL=N400, NETADDR=06, T0=DELTA,PORT=0, SMGDREF=0CADAPTO8 ADAPTER MODEL=N400, NETADDR=08, T0=DELTA,PORT=1, SMGDREF=00, ADAPT=ADAPT08MINIB HOST TYPE=MICROVAX, OS=VMS, MODEL=2,ADAPT08 ADAPTER MODEL=N400, NETADDR=08, T0=DELTA,PORT=0, SMGDREF=0C, SMGNREF=FFFF*Page 106 Configuration Manager MAN-REF-H307IP-04


* Link Adapter (SLS) Back to HOME*LINK MODEL=N715 NETADDR=07, T0=DELTA,BUSLINK PORT DEST=CHANLINK, RATE=1544K, DELAY=01M** Describe AWAY Network*AWAY LOCALNET TYPE=HCGAMMA TRUNK** Describe Hosts on the AWAY Network*UNISYS HOST TYPE=SPERRY, MODEL=2200/900, OS=0S2200,ADAPTER MODEL=A140, NETADDR=l0, T3=GAMMA, SMGDREF=00*PDP HOST TYPE=PDP11, MODEL=70, 0S=RSX11M,PDPADAP ADAPTER MODEL=A400, NETADDR=11, T3=GAMMA, PORT=0,INTRFACE=PI11, SMGDREF=08, SMGNREF=FFFF*VAXB HOST TYPE=VAX, MODEL=780, OS=VMS,ADAPTER** Link Back to HOME*LINKMODEL=N400, NETADDR=11, T3=GAMMA, PORT=1,INTRFACE=PI13, SMGDREF=61, ADAPT=PDPADAPMODEL=AC730, NETADDR=0A, T3=GAMMA,MODE710=01, MODE710=02, MODE710=03, MODE710=05,AWAYP PORT DEST=HOMEP, RATE=1544K, DELAY=0M** End DefinitionS*ENDFigure 18. NCT ExampleMAN-REF-H307IP-04 Configuration Manager Page 107


Appendix A. NRBSTAT Error CodesWhenever a NETEX request is issued, the results of the request are returned in one or both of two fields,NRBSTAT and NRBIND. These are located at the beginning of the NRB to make their subsequent examinationby high level language programs a simpler matter.NRBSTAT is designed to indicate if an operation is in progress, and whether it completed successfully or not.NRBIND is designed to indicate the type of information that arrived as the result of a read-type command(OFFER or READ).When the operation is accepted by the NETEX user interface, the value of NRBSTAT is set to the local valueof –1. Thus, the sign of this word is an “operation in progress” flag for all implementations.If an operation completed successfully, NRBSTAT will be returned as all zeroes. If a read-type commandwas issued, then an “indication” will be set in NRBIND.If the operation did not complete successfully, then NRBSTAT will contain a standard error code. NRBSTATis represented as a decimal number that is potentially as large as 2 15 -1 (32,767). The 2 16 bit is not used so thatit may remain an “in progress” flag on the 16-bit machines. The thousands digit denotes the origin of the error;the low order three digits specifically identify the error type. The codes for error origin are as follows:0xxx NETEX general; errors detected by the user interface that prohibit proper processingof the command09xx Reserved for implementation dependent errors in the user interface1xxx Driver level errors2xxx Transport level errors3xxx Session level errors4xxx Network level errors5xxx-8xxx Reserved for future NETEX functions90xx Reserved for errors returned by User Exits on the local host91xx Reserved for errors returned by User Exits on a remote host during the connectionprocess9200-32767 Reserved0xxx and 90xx errors can be returned to any user program that accesses NETEX services. Normally, an applicationthat accesses services at the session level will only receive those errors (3xxx) related to sessionservices. However, the principle within NETEX should be that if a level elects to abort the user’s requestbased on an error returned by a lower level of software, then the error code should be “rippled up” to the userrather than summarized at the higher level. For example, driver might report a “power off” or “not operational”status to transport in the event of an adapter failure. If transport decided that this error type shouldcause loss of communications, then the lxxx error would be returned to the user along with a Disconnect Indicationin NRBIND when the next user read command was issued.Following that, the second digit places the errors in categories.x0xxxlxxx2xxx3xxx4xxx5xxNETEX general or inconsistent NRB formatSpecification errors in parameters passed to a particular protocol levelHardware errorsRequests out of sequence and read timeoutsNETEX initiated disconnect errorsErrors during connectionPage 108 Appendix A. NRBSTAT Error Codes MAN-REF-H307IP-04


The error codes at each level have been made as common as possible. Thus, a 2103 error in transport wouldhave substantially the same meaning as a 3103 error in session, and a 1361 error would not be defined at (forexample) the Driver level if a 3361 error meant something entirely different at the Session level.Finally, some errors will cause the loss of the connection or will result in a connection not being establishedin the first place. Any status code that implies that the connection is no longer useful will have a 6 (DisconnectIndication) returned in NRBSTAT. Any attempts to issue further requests to that connection will have axl00 (no NREF) error returned to it. All errors that result in loss of the connection and a Disconnect Indicationin NRBIND are indicated by an asterisk (*) following the error code number.Note:A 0000 in field NRBSTAT means successful completion of NETEX request. A -l means that requestis still in progress.The following subsections describe the errors in numerical order starting with general NETEX errors, followedby driver, transport, and session level errors.MAN-REF-H307IP-04 Appendix A. NRBSTAT Error Codes Page 109


H307IP User Interface Error CodesThe following codes are H307IP user interface error codes. Refer to the NETEX Programmer’s ReferenceManual for additional NRBSTAT error codes.0000 Successful completion0001 Pdata was truncated. A read-type operation completed normally, but the buffer provided by theuser was not large enough to hold the data. NRBLEN and NRBUBIT reflect the amount of datareceived; however, the amount of data moved to the user’s buffer was only the amount specifiedin NRBBUFL. The status of the connection is not affected.0002 Invalid Pdata Buffer Address. NRBBUFL and NRBBUFA do not specify a block of storage thatfits entirely within the user’s addressable memory. The operation is suppressed. The status of theconnection is not affected0004 Invalid Request. The request code (NRBREQ) is not valid. The operation is ignored and thestatus of the connection is not affected.0005 Invalid Pdata Buffer Length. The buffer size specified (NRBBUFL for reads and NRBLEN forwrites) exceeds an implementation defined NETEX maximum. The operation is suppressed. Thestatus of the connection is not affected.0006 Invalid Odata Buffer Length. The buffer size specified in NRBPROTL exceeds an implementationdefined NETEX maximum. The operation is suppressed. The status of the connection is notaffected.0011 Odata was truncated. A read-type operation completed normally, but the Odata buffer providedby the user was not large enough to hold the data. NRBPROTL reflects the amount of data givento the user. The status of the connection is not affected.0012 Invalid Odata buffer address. NRBPROTL and NRBPROTA do not specify a block of storagethat fits entirely within the user’s addressable memory. The operation is suppressed. The statusof the connection is not affected.0010* No NREF specified. The user interface detected that the NREF is not valid. The probable causeis the lack of, or a failing, CONNECT or OFFER.0310 NRB for request is already in use. The user has attempted to re-use an NRB before a previousrequest with that NRB has completed. The request is rejected,0503* The number of users accessing H307IP has exceeded the MAXUSERS parameter. The session isrejected0903 NRBDMODE on a write-type request is not supported by the hardware and/or H307IP.0904* Maximum outstanding writes exceeded. The number of write requests outstanding against a singleconnection exceeds the maximum allowable of 1. The request is rejected. The status of theconnection is not affected.0905* Maximum outstanding reads exceeded. The number of read requests outstanding against a singleconnection exceeds the maximum allowable of 1. The request is rejected. The status of the connectionis not affected0907* Pending read request terminated because of an internally generated disconnect (e.g., <strong>SDISC</strong>) orexit by user.0908 Invalid SCB address in NRB. User probably over-wrote OS area of the NRB.Page 110 Appendix A. NRBSTAT Error Codes MAN-REF-H307IP-04


0911* Error on TRMRG$ request.0921 Output data transfer was truncated by the channel, generally because of a “stop-bit” in the datablock. Correct the data and re-start the transfer.0922 Code Conversion has not been done. A read request has completed but the data has not beencode converted because the DATAMODE specified an unsupported code conversion. The statusof the connection is not affected.0923 Interface is use was HALTed by operator.0930* N2X$COMN bank not configured for this system’s SITEID. Reload correct bank or rebuildH307IP with correct configuration statements.0932 Adapter memory unavailable. Buffer memory was not available in the DX/E unit to accept thisrequest and data. The status of the connection is not affected.0933* I/O error. Status 013 from exec. Adapter or path has been DOWNed by the operator.0934* I/O Error. An I/O error on the adapter host interface occurred during the processing of the request.The results of the request, and the status of the connection are unknown. It is recommendedthat the session be terminated.0935* I/O Error. Status 07, 11 from the exec. No sense bytes were returned on a Unit Check error.Verify that the adapter host interface is profiled for 32 sense bytes. If the adapter interface is configuredas HYPDEV rather than ARBDEV, refer to the Memo to Users for more information.0951* Allocation failed - setup channel program error. The connect or offer request has failed becausethe used interface detected that an I/O error occurred while executing the channel program tosetup the subchannels allocated for the path to the DX unit.0952* Allocation failed - Sense id is not correct. The connect or offer request has failed because theuser interface detected that the subchannels allocated for the path to the adapter did not respondcorrectly to a Sense ID operation. This indicates they are not subchannels to the adapter.0953* Allocation failed - abort failed. The connect or offer request has failed because the user interfacedetected an error aborting any sessions previously associated with the subchannels allocated forthe path to the adapter.0954* Allocation failed - invalid interface name. The connect or offer request has failed because theuser interface detected that NRBSSNM does not specify a valid interface name.0955* Allocation failed - unable to allocate units. The connect or offer request has failed because theuser interface was unable to allocate a pair of subchannels for the path to the NETEX adapter.The probable cause is that all the subchannels are offline or are all allocated to other sessions.0956* Attempt to ASG adapter device gave facility reject bit 1*/35. The probable cause is a wrong I/Oconfiguration for this system.0958* Allocation failed - the Sense Configuration data had no data for NETEX Co-processor or NESi-Gate Channel Offload software.1101 DWRITE invalid datamode. The datamode specified for this DWRITE request is invalid. Therequest is rejected. The status of the connection is not affected.1103 DWRITE invalid Odata length. The Odata length (NRBPROTL) specified for this DWRITE requestis invalid. The length of the message proper (NRBPROTL) MUST BE BETWEEN 8 AND64 BYTES INCLUSIVE. The request is rejected. The status of the connection is not affected.MAN-REF-H307IP-04 Appendix A. NRBSTAT Error Codes Page 111


1300 Driver Level - Read Time Out. A DREAD request timed out before any data was received forthis connection. The time value used for the timeout was in NRBTIME. No data was received.The status of the connection is not affected.1310 Driver Level - Read Data Time Out. Data that was received for this connection has been discardedbecause the application did not issue a read request for a period of time greater that thedata timeout period. The status of the connection is not affected.3300 Session Level - Read Time Out. A session level request (SREAD or SOFFER) timed out beforeany data was received for this session. The time value used for the timeout was in NRBTIME.No data was received. The status of the connection is not affected.3302 A request other than SCONFIRM or <strong>SDISC</strong> was received after a SOFFER completed.3310* Session Level - Read Data Time Out. Data that was received for this session has been discardedbecause the application did not issue a read request for a period of time greater than the datatimeout period (30 seconds). The session is terminated.Page 112 Appendix A. NRBSTAT Error Codes MAN-REF-H307IP-04


Appendix B. ConfMang MessagesFirst Pass Configuration MessagesThe following is a list of warning messages displayed by the configuration manager parser during pass one.These errors are not fatal and result in printing an error message and continuing the parse. All messages exceptCONF00I, CONF005, CONF006 and CONF029 set the NCT validation flag (ValidNCT) to FALSE.This flag is checked before accessing the NCT. The message, explanation, and action are discussed below.The actual value of the identifier will replace an identifier enclosed in single quotes (for example: “HOSTname”).CONF001I Parsing initiatedExplanation: This is only an informational message.System Action: Display message and continue processing.CONF002E Invalid configuration statementExplanation: An unrecognizable statement type was encountered. The statement that is invalid isdisplayed followed by the error message.System Action: Ignore card and get next one.CONF003E ‘name’ statement: ‘label’ encountered after LINK stint: ‘label’Explanation: A statement was encountered after a LINK statement. The order of these statements iswrong.System Action: Ignore statement, free up memory allocated to ‘name’ get next card.CONF004E TRUNK not previously definedExplanation: Tx = label was encountered in an ADAPTER or LINK statement and the trunk referredto by the label has not been defined.System Action: Ignore operand and scan for next one.CONF005I Syntax check halted; the following not checkedExplanation: An error was encountered that resulted in some code to be overlooked. The statementsfollowing this message are NOT checked for errors.System Action: Skip code until a key word is found. This is only a warning.CONF006I Syntax check resumed; the previous stmt checkedExplanation: A key word was encountered in the previous statement. The statement previous to thismessage is checked for errors.System Action: Inform user of code not checked. This is only a warning.CONF007E Statement missing label: ‘TRUNK | HOST | PORT’Explanation: The label is missing from the TRUNK, HOST or PORT statement.System Action: Ignore card and get next one.CONF008E Invalid operand: ‘operand’Explanation: An unrecognizable operand was encountered.System Action: Ignore operand and get next one.CONF009E Invalid network type: ‘operand’Explanation: An unrecognizable network type was encountered in the LOCALNET statement.System Action: Ignore statement and get next card.MAN-REF-H307IP-04 Appendix B. ConfMang Messages Page 113


CONF010E TYPE missing in LOCALNET statement: ‘network name’Explanation: The type operand was missing from the LOCALNET statement. It is required for allnetworks.System Action: Free up memory allocated to network and get next card.CONF011E NETADDR missing in ADAPTER/LINK statement: ‘label’Explanation: The NETADDR operand is missing from the ADAPTER or LINK statement. It is requiredfor all adapters/links.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF012E MODEL missing in ADAPTER/LINK statement: ‘label’Explanation: The MODEL operand is missing from the ADAPTER or LINK statement. It is requiredfor all adapters/links.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF013E TRUNK missing from ADAPTER/LINK statement: ‘label’Explanation: A trunk operand is missing from the ADAPTER or LINK statement. At least onemust be specified (and not more than 4). It is required for all adapters/links.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF014E CHANADDR missing in ADAPTER statement: ‘label’Explanation: The CHANADDR operand is missing from the ADAPTER statement. It is requiredfor PB22x/NB22x Adapters.System Action: Ignore statement, free up memory allocated to adapter and get next card.CONF015E RATE invalid in PORT statement: ‘rate’Explanation: An invalid rate was specified in a PORT statement.System Action: Ignore statement, free up memory allocated and get next card.CONF016E SMGDREF: ‘hexvalue’ must have rightmost 2 bits = PORT: ‘value’Explanation: A DREF was encountered that has the value ‘hexvalue’. The low-order 2 bits mustequal the port number ‘value’.System Action: Ignore statement, free up memory allocated and get next card,CONF017E DEST missing in PORT statement: ‘label’Explanation: The DEST operand is missing from the PORT statement. It is required for all adapters.System Action: Ignore statement, free up memory allocated to port and get next card.CONF018E RATE missing in PORT statement: ‘label’Explanation: The RATE operand is missing from the PORT statement. It is required for the A142Adapters.System Action: Ignore statement, free up memory allocated to port and get next card.CONF019E Invalid adapter model: ‘model’Explanation: The MODEL operand specified an invalid adapter model number in the ADAPTER orLINK statement.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF020E NUMADDRS encountered without CHANADDR: ‘label’Explanation: The NUMADDRS operand was encountered but no CHANADDR was previously defined.System Action: Ignore statement, free up memory allocated to adapter and get next card.CONF021E Invalid PORT number ‘number’Explanation: The PORT operand is out of the range 0..3 in an ADAPTER or LINK statement.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.Page 114 Appendix B. ConfMang Messages MAN-REF-H307IP-04


CONF022E Unexpected End of File EncounteredExplanation: The end of the configuration file was encountered before the completion of the parse.System Action: Exit from module.CONF023E TRUNK not meaningful in HYPERbus environment: ‘trunk name’Explanation: The TRUNK statement is not to be used in describing a HYPERbus network.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF025E Invalid hexadecimal character: ‘char’ in string: ‘string’Explanation: An invalid hexadecimal character was encountered.System Action: Ignore statement, free up memory allocated to adapter or link and get next card.CONF026E Invalid INTEGER: ‘number’Explanation: An invalid integer was encountered in parse.System Action: Ignore statement, free up memory allocated to PORT and get next card,CONF027E Invalid PROTOCOL level: ‘number’ on HOST: ‘HOSTname’Explanation: A protocol level was encountered that is not currently available.System Action: Ignore statement, free up memory allocated to HOST and get next card.CONF02SE ‘parameter name’ parameter previously defined as ‘name’Explanation: A parameter was previously encountered and defined to be ‘name’.System Action: Ignore statement, free up memory allocated and get next card.CONF029I Variable truncated: ‘variable’Explanation: A variable was encountered that is longer than the specified length for that variable.System Action: Truncate to specified length and continue. This is only a warning.CONF030E ‘name1’ statement: ‘label’ encountered before ‘name2’ statement: ‘label’Explanation: The statement specified by ‘namel’ was encountered before the statement specified by‘name2’. The statement label is specified by ‘label’.System Action: Ignore statement, free up memory allocated to HOST and get next card.CONF03IE Label: ‘label’ and ADAPT: ‘adapt’ may not both be specifiedExplanation: Both a label and an ADAPT parameter may not be specified for the adapter/link.System Action: Ignore statement, free up memory allocated and get next card.CONF033E token too long: ‘string’Explanation: A token was encountered that was longer than the maximum token length.System Action: Ignore statement, free up memory allocated and get next card.CONF034E Invalid Return CodeExplanation: An invalid return code was returned from the translator phase of SCANNER.System Action: Ignore statement, free up memory allocated and get next card.CONF070E Invalid SMGnref: ‘hexvalue’, should always = FFFFExplanation: An NREF was encountered with the value ‘hexvalue’. SMGNREFs should always be‘FFFF’.System Action: Ignore statement, free up memory allocated and get next card.CONF071E SMGDREF: ‘hexvalue’ must have rightmost 2 bits = PORT: ‘value’Explanation: A DREF was encountered with the value ‘hexvalue’. The low-order 2 bits must equalthe port number ‘value’.System Action: Ignore statement, free up memory allocated and get next card.CONF073E Invalid 710-mode address: ‘address’Explanation: The 710-mode address is not in the range ‘00’ - ‘EF’.System Action: Ignore statement, free up memory allocated and get next card.MAN-REF-H307IP-04 Appendix B. ConfMang Messages Page 115


CONF074E Invalid trunk (0,1) defined on 715 link ‘trunk’, NETADDR= ‘ad’Explanation: 715 links may only have trunks 2 and/or 3 attached.System Action: Ignore statement, free up memory allocated and get next card.CONF080E BUS not previously defined: ‘busname’Explanation: A BUS = parameter has been encountered, but the name does not match any previouslydefined HB statements.System Action: Ignore statement, free up memory allocated and get next card.CONF081E BUS not meaningful with “A” type adapter: ‘busname’Explanation: “A” type adapters may not be attached to a BUS.System Action: Ignore statement, free up memory allocated and get next card.CONF082E BUS missing in ADAPTER/LINK statement: ‘netaddr’Explanation: “B” type adapters must be attached to a BUS.System Action: Ignore statement, free up memory allocated and get next card.CONF083E Invalid SEGSIZE value: ‘value’Explanation: SEGSIZE as specified on a PORT statement is > 65535.System Action: Ignore statement, free up memory allocated and get next card.CONF087F Line length exceeds 64 charactersExplanation: The line that follows is longer than 64 characters.System Action: Edit the line to 64 characters.Second Pass Configuration MessagesA formal description of the pass two configuration errors follow. The actual value of the identifier will replacean identifier enclosed in single quotes (for example: ‘HOSTname’). All errors except CONF044,CONF046, CONF048, and CONF054, and CONF057 set the NCT validation flag (ValidNCT) to FALSE.This flag is always checked before accessing the NCT.CONF03SE Multiple adapters must have same ‘operand’ valueExplanation: A multi-port adapter was encountered with duplicate NETADDRs but the one of theother operands don't match in both statements.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF036E ADAPT operand: ‘operand’ must equal adapter label: ‘label’Explanation: A multi-port adapter/link was encountered with duplicate NETADDRs but theADAPT operand doesn’t match the previous label.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF037E Multi-port adapters must not have same PORTExplanation: A multi-port adapters was encountered with duplicate NETADDRs but the PORT operandsare not different.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF03SE Duplicate labels in configuration: ‘label’Explanation: An entity was encountered with the same label as a previously defined entity.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF039E No adapter specified for HOST: ‘HOSTname’Explanation: No adapter was specified for this host. At least one is required for each host.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF040E No SMGR specified for HOST: ‘HOSTname’Page 116 Appendix B. ConfMang Messages MAN-REF-H307IP-04


Explanation: No SMGR was specified for this host. At least one is required for each host.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF043E HOST: ‘HOSTname’ has GROUP name equal to real HOST name: ‘name’Explanation: A GROUP name was encountered that has the same name as a real HOST name.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF044I No PORT found with label: ‘label’Explanation: A DEST label was encountered and the PORT referred to by the label is not defined.System Action: Display error message and continue processing. This is only a warning message.CONF045E Invalid PORT linkage: ‘link model’,‘link model’Explanation: A PORT was encountered that is not a valid linkage to the PORT described in theDEST label. PORTs must connect LINKs of the same type except for x4xx links.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF046I No path from HOST ‘HOSTname’ to HOST ‘HOSTname’Explanation: There is no path connecting HOST A with HOST B. Communication between thesehosts cannot take place.System Action: Display error message and continue processing. This is only a warning message.CONF047E Missing a multi-port ADAPTER with the label: ‘label’Explanation: There is no adapter with the specified label; there must be for all x4xx adapter/links.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF048I The erroneous values are ‘value’ and ‘value’Explanation: An error was encountered in which these two values are incorrect.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF049E Multi-port adapters can’t have 2 labels ‘label’, ‘label’Explanation: An error was encountered in which these two values are incorrect.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF050E Multi-task adapters require unique SMGDREFsExplanation: On a multi-process host, two adapters were encountered with the same NETADDRand the same SMGDREF. The SMGDREF values must be different. See ADAPTER statement sectionfor details on multi-process hosts.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF051E Multi-task adapters require same PORT numbersExplanation: On a multi-process host, two adapters were encountered with the same NETADDRand different PORT numbers. The PORT values must be the same. See ADAPTER statement sectionfor details on multi-process hosts.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF053E Duplicate network address: ‘address’ in LOCALNET: ‘label’Explanation: An adapter other than model PB40x/NB40x was encountered which specifies the sameNETADDR as a previously defined adapter on the same network.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF054I The above NETADDR = an implicitly defined A722Explanation: The NETADDR specified in the above error message is the same as the A722 unit ofan S720 SLS.System Action: Display error message, continue processing. This is only a warning message to explainthe previous error further.CONF055E HOST: ‘name’ and HOST: ‘name’ in GROUP: ‘name’ need same protocolsMAN-REF-H307IP-04 Appendix B. ConfMang Messages Page 117


Explanation: All hosts in the same group must have specified the same session manager DREF.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.CONF057I Parsing completed VaIidNCT = ‘flag’, Errors = ‘number’, Warnings = ‘number’Explanation: This is only an informational message. The state of the ValidNCT flag is displayedalong with the number of error and warning messages encountered.System Action: Display message and continue processing.CONF072E Multi-task adapters require unique CHANADDRsExplanation: On a multi-process host, two adapters were encountered with the same NETADDRand the same CHANADDR. The CHANADDR values must be different. See ADAPTER statementsection for details on multi-process hosts.System Action: Display error message, set ValidNCT flag to FALSE and continue processing.MAKEPAM Processing MessagesThe errors that could be encountered in CONFgetPAM (while processing the MAKEPAM command) are asfollows. The actual value of the identifier will replace an identifier enclosed in single quotes (for example:‘HOSTname’).CONF058E HOST not defined in global configuration: ‘HOSTname’Explanation: The HOST specified was not found in the NCT.System Action: Generate error message. No PAM is returned to caller.CONF059E NCT is invalid, PAM cannot be builtExplanation: The parser has detected one or more errors, therefore, the PAM cannot be built.System Action: Generate error message. No PAM is returned to caller.CONF060E No path from HOST: ‘HOSTname’ to HOST: ‘HOSTname’Explanation: No path exists from the specified local host to the specified remote host.System Action: Generate error message. No PAM is returned to caller.CONF061E NCT is invalid, HOST Configuration cannot be builtExplanation: The parser has detected one or more errors, therefore, this entry cannot be built.System Action: Generate error message. No entry is returned to caller.CONF099I Path exists from HOST: ‘hostname’ to HOST: ‘hostname’Explanation: There is a route from the first ‘hostname’ to the second. Informational message only.System Action: Generate message and continue processing.Page 118 Appendix B. ConfMang Messages MAN-REF-H307IP-04


Appendix C. Sysgen NODE StatementsThe following are the SYSGEN node statements required to define NETEX adapters. Note that in newerUnisys systems this is now done by the ODB configuration.P/NB22x or PB25x DX/Es or NesiGate InterfacesA control unit sysgen statement example follows:NODE hypera IS ARBCU AND CONNECTS TO i1mod6 VIA SUB-CHANNEL 12The device sysgen statement example:NODE hypa,0 THRU hypa,3 ARE ARBDEV AND CONNECT TO hyperaThis statement configures devices hypa0, hypal, hypa2, and hypa3. In the preceding example, DEVNAME inthe NCT would be hypa0.hypera is the adapter name by which you wish to refer to this control unit.i1mod6 is the node name in the OS system for the block mux channel.12 This is the subchannel position occupied by this adapter. It is the (decimal) start address of thechannel interface module i1mod6.In the NETEX NCT, the ADAPTER CHANADDR field must correspond to this. For example, ifSUB-CHANNEL is 12, then CHANADDR is C0.This must also correspond to the switches on the device board of the adapter or the profiled controlunit address.The equipment type ARBCU and ARBDEV indicate that NETEX will be using the arbitrary device handler(IOAID$) to access the adapter. If SINCH is to be used instead (P/NB22x only), replace the equipment typeARBCU with HYPCU and ARBDEV with HYPDEV. Do not define the NETEX devices on HYPNET SGSs.When configured this way, NETEX may be configured to use either SINCH (A2225 EQU 1) or IOAID(A222S EQU 2). Non-NETEX applications (e.g., DDP) may use other adapter addresses, greater thanNUMADDRS, which require them to be SINCH devices.MAN-REF-H307IP-04 Appendix C. Sysgen NODE Statements Page 119


ESCON/SBCON InterfacesThe STK DX/E ESCON (PB25x) interface does NOT support offload NETEX and H307IP. The NESi-Gate ESCON interface DOES support H307IP.The ESCON (SBCON) interface attaches to a Unisys SBCON-CA channel adapter. Unisys supports onlycontrol unit 0. The sysgen is essentially the same as for the P/NB22x adapter; however, the channel to control-unitlink (CHlink or port in the ODB) must be 1 for a directly connected control unit, and equal to theoutput (device side) port number (decimal) if a director is used.Page 120 Appendix C. Sysgen NODE Statements MAN-REF-H307IP-04


IndexAabnormal termination ..........................................21ADAPTER Statement .......................................101ASCII ...................................................................vi<strong>Assembler</strong> <strong>Call</strong>SCLOSE ..........................................................44SCONFIRM.....................................................41SCONNECT....................................................40<strong>SDISC</strong>..............................................................45SOFFER ..........................................................39SREAD............................................................42SWAIT ............................................................47SWRITE ..........................................................43assembler interface..............................................37NRB.................................................................37procedure format .............................................38asynchronous........................................................viautomatic datamode.............................................30processing rules ...............................................31automatic datamode indicator .............................31Bbit stream conversion ..........................................30buffer....................................................................viCcharacter conversion............................................31COBOL (ACOB) Interface .................................67code conversion..............................................vi, 24Code Conversion.................................................72concurrent data transfer.......................................15Configuration File ...............................................93configuration manager....................................vi, 92Configuration Manager....................................... 84CONFMANG ............. See Configuration ManagerConfMang MessagesFirst Pass....................................................... 116Second Pass .................................................. 119Coprocessor NETwork EXecutive.See CP NETEXCP NETEX ........................................................... 3creating an NRB ................................................. 35Customize H307IP.............................................. 82DData Exchange Unit (DX unit or DXU) .............. vidata transferconcurrent ....................................................... 15one-way........................................................... 17write/read ........................................................ 14DCONNECT....................................................... 73DDISC ................................................................ 75Define Network Configuration ........................... 84destination character set...................................... 31DREAD............................................................... 77Driver Directives ................................................ 72Driver Interface................................................... 70driver sublayer services ........................................ 7DSTATUS .......................................................... 78duplicating an NRB ............................................ 35DWRITE............................................................. 76DX NETEX ..................................................... vi, 3EEND Statement ................................................. 108error recovery procedures................................... 23establishing a session.......................................... 12MAN-REF-H307IP-04 Appendix C. Sysgen NODE Statements Page 121


FFiber Distributed Data Interface (FDDI) .............viFORTRAN <strong>Call</strong>SCLOS............................................................ 60SCONF............................................................ 54SCONN........................................................... 52<strong>SDISC</strong> ............................................................. 63SOFFR ............................................................ 50SREAD ........................................................... 56SWAIT............................................................ 62SWRIT ............................................................ 58FORTRAN Interface........................................... 48NRB ................................................................ 49FORTRAN Program Example............................ 65Ggeneral concept of a session................................ 10HHardware Protocols ............................................ 70HB Statement...................................................... 98header...................................................................vihost.......................................................................vihost based NETEX ............................................... 3HOST Statement................................................. 99Iincoming assembly/disassembly......................... 30incoming code conversion .................................. 30Installation .......................................................... 81Pre-Installation................................................ 81Prerequisites.................................................... 81Procedures....................................................... 81Internet Protocol (IP) ...........................................viintertask communication....................................... 8IP NETEX............................................................. 3ISO.......................................................................viISO model............................................................. 4Llink........................................................................viLINK Statement ................................................105Load the PAM.....................................................85LOCALNET Statement.......................................96MMAKEPAM Messages......................................121manual datamode.................................................29manual mode indicator........................................30Map Requirements ..............................................68MAPing NETEX Applications............................69Message Proper ...................................................70multiple connections ...........................................22NNESiGate Offload NETEX ...................................4NETEXCP......................................................................3driver sublayer services.....................................7DX .....................................................................3host based ..........................................................3IP .......................................................................3NESiGate Offload .............................................4network layer services.......................................7session layer services ........................................6transport layer services......................................6NETEXISO model .........................................................4NETEX <strong>Call</strong>ing Sequence...................................68NETEX Procedure Code .....................................46NETEX request block ..............................See NRBNetwork Configuration Example ......................109Network Configuration Table (NCT)...................viNetwork Configuration Table Loader (NCTL)....vinetwork layer services...........................................7normal termination ..............................................20Page 122 Index MAN-REF-H307IP-04


NRB.....................................................................25creation............................................................35duplication.......................................................35fields................................................................25usage rules.......................................................25NRB fields...........................................................25NRBBLKI .......................................................33NRBBLKO......................................................33NRBBUFA ......................................................29NRBBUFL.......................................................29NRBCLASS ....................................................32NRBDMODE ..................................................29NRBHNAME (NRBHOST)............................35NRBIND..........................................................27NRBLEN.........................................................27NRBMAXRT ..................................................32NRBNREF.......................................................29NRBOSDEP ....................................................35NRBPNAME...................................................35NRBPROTA....................................................34NRBPROTL ....................................................34NRBREQ.........................................................28NRBRESV1 ....................................................35NRBRESV2 ....................................................35NRBRESV3 ....................................................35NRBSTAT.......................................................26NRBTIME.......................................................32NRBUBIT .......................................................27NRBUSER.......................................................35NRBBLKI ...........................................................33NRBBLKO..........................................................33NRBBUFA..........................................................29NRBBUFL ..........................................................29NRBCLASS ........................................................32NRBDMODE......................................................29automatic datamode ........................................ 30manual datamode ............................................ 29NRBHNAME (NRBHOST) ............................... 35NRBIND............................................................. 27NRBLEN ............................................................ 27NRBMAXRT...................................................... 32NRBNREF.......................................................... 29NRBOSDEP ....................................................... 35NRBPNAME ...................................................... 35NRBPROTA....................................................... 34NRBPROTL ....................................................... 34NRBREQ ............................................................ 28function........................................................... 28option flags ..................................................... 28service level .................................................... 28NRBRESV1........................................................ 35NRBRESV2........................................................ 35NRBRESV3........................................................ 35NRBSTAT .......................................................... 26NRBSTAT Error Codes.................................... 111NRBTIME .......................................................... 32NRBUBIT........................................................... 27NRBUSER.......................................................... 35NTXCONS ......................................................... 89NTXDATA......................................................... 90NTXEAT ............................................................ 90NTXGEN............................................................ 90NTXOFFRS........................................................ 90NTXOPER.......................................................... 90Ooctet conversion.................................................. 30one-way data transfer.......................................... 17Open Systems Interconnection (OSI) .................viioutgoing assembly/disassembly.......................... 30outgoing code conversion................................... 30MAN-REF-H307IP-04 Index Page 123


Ppath .....................................................................viiPORT Statement ............................................... 107processor interface (PI).......................................viiprogramming notes ............................................. 22RRebuild H307IP .................................................. 83Re-MAP current H300 Applications .................. 85remote operator interface...................................... 2rules for NRB usage............................................ 25SSample System Configuration ............................ 86satellite communication ...................................... 23SCLOSFORTRAN <strong>Call</strong> .............................................. 60SCLOSE<strong>Assembler</strong> <strong>Call</strong>................................................ 44SCONFFORTRAN <strong>Call</strong> .............................................. 54SCONFIRM<strong>Assembler</strong> <strong>Call</strong>................................................ 41SCONNFORTRAN <strong>Call</strong> .............................................. 52SCONNECT<strong>Assembler</strong> <strong>Call</strong>................................................ 40<strong>SDISC</strong><strong>Assembler</strong> <strong>Call</strong>................................................ 45FORTRAN <strong>Call</strong> .............................................. 63service WAIT options......................................... 22sessionabnormal termination...................................... 21normal termination.......................................... 20Session Layer Requests ........................................ 8CLOSE.............................................................. 9CONFIRM ........................................................ 8CONNECT ........................................................8DISCONNECT..................................................9OFFER ..............................................................8READ................................................................9WAIT ................................................................9WRITE ..............................................................9session layer services ............................................6SOFFER<strong>Assembler</strong> <strong>Call</strong> ................................................39SOFFRFORTRAN <strong>Call</strong>...............................................50source character set .............................................31SREAD<strong>Assembler</strong> <strong>Call</strong> ................................................42FORTRAN <strong>Call</strong>...............................................56SWAIT<strong>Assembler</strong> <strong>Call</strong> ................................................47FORTRAN <strong>Call</strong>...............................................62SWRITFORTRAN <strong>Call</strong>...............................................58SWRITE<strong>Assembler</strong> <strong>Call</strong> ................................................43SYSGEN node statements.................................122TTCP/IP................................................................ viitransport layer services..........................................6TRUNK Statement ..............................................97UUser Exits............................................................87User Exits Installation .........................................88user interface error codes ..................................113USEREXIT1 .......................................................87USEREXIT2 .......................................................87VVerify Installation ...............................................85Page 124 Index MAN-REF-H307IP-04


VERSION Statement...........................................95Wwrite/read data transfer ....................................... 14MAN-REF-H307IP-04 Index Page 125


Comment SheetNetwork Executive Software welcomes your comments about this publication. Please complete this form,including your name and address, and mail it to:Network Executive Software, Inc.Publications Department6420 Sycamore Lane, Suite 300Maple Grove, Minnesota 55369Comments may also be submitted over the Internet by addressing email to: pubs@netexsw.comAlways include the complete title of the document with your comments.Name: _________________________________________________________________________Company: _________________________________________________________________________Address: _________________________________________________________________________City, State: __________________________________________ Zip Code: _____________Publication Number and Revision: H307IP (Rel 5.0) NETEX User Interface ManualCOMMENTS:Page 126 Index MAN-REF-H307IP-04

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!