NetIPC 3000/XL Programmer’s Reference Manual HP 3000 MPE/iX Computer Systems Edition 3 Manufacturing Part Number: 5958-8600 E1089 U.S.A.
Notice The information contained in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Hewlett-Packard shall not be liable for errors contained herein or for direct, indirect, special, incidental or consequential damages in connection with the furnishing or use of this material.
Contents 1. NetIPC Fundamentals NetIPC Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming, Socket Registry and Destinations . . . . . . . . . . .
Contents Calls Affecting the Remote Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 HP 3000 to HP 1000 NetIPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 HP 3000 to HP 9000 NetIPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 HP 3000 to PC NetIPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents IPCCONNECT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 IPCLOOKUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-System Considerations For TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP 3000 to HP 1000: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP 3000 to HP 9000: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Program 4A (SNMIPC1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Program 4B (SNMIPC2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 A. IPC Interpreter (IPCINT) Using IPCINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 Comparison of IPCINT to Programmatic NetIPC . . . . . . . . . . . . . . . . .
Contents PSERVER: Sample PTOP Slave Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 RCLIENT: Sample NetIPC/RPM Master Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 RSERVER: Sample NetIPC/RPM Slave Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 E. C Program Language Considerations C Program Language Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 10
Figures Figure 1-1. Telephone Analogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1-2. IPCCREATE (Processes A and B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1-3. IPCNAME (Process B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1-4. IPCLOOKUP (Process A). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1-5.
Figures 12
Tables Table 1-1. Descriptor Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 2-1. NetIPC Calls Affecting the Local Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Table 2-2. NetIPC Calls Affecting the Remote Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Table 2-3. Cross-System Calls (HP 3000 — HP 1000). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Table 2-4.
Tables 14
Preface Network InterProcess Communication (NetIPC) is a set of programmatic calls that can be used to exchange data between peer-to-peer processes on the same or different nodes in an Hewlett-Packard NS network. Any process can initiate communication, and any process can send or receive messages by means of common intrinsics. NetIPC 3000/XL is a version of NetIPC that can be used in programs written for MPE XL based computer systems.
• Appendix A , “IPC Interpreter (IPCINT),” describes how to use the IPCINT software utility which provides an interactive interface to the NetIPC intrinsics used for programmatic access to X.25 level 3. • Appendix B , “Cause and Diagnostic Codes,” lists the possible cause and diagnostic codes generated by NS X.25 packets.
1 NetIPC Fundamentals Network Interprocess Communication (NetIPC) is a facility that enables processes on the same or different nodes to communicate with each other using a series of programmatic calls. NetIPC 3000/XL can be purchased as part of any NS 3000/XL link product. It provides access to the Transmission Control Protocol (TCP), the Transport Layer protocol used in NS 3000/XL link products. Over an NS X.25 network, NetIPC provides access to X.25 protocol features at level 3.
NetIPC Fundamentals NetIPC Concepts NetIPC Concepts The following paragraphs describe the concept of sockets, and the NetIPC terms used to describe a NetIPC connection. Sockets NetIPC uses a data structure called a socket to create a connection to a NetIPC process on another system. Even though this process may reside upon the same node, the process that receives the NetIPC call is known as a remote system.
NetIPC Fundamentals NetIPC Concepts Virtual circuits are the basis for interprocess communication. Once a virtual circuit is established, the two processes that created it may use it to exchange data. Two processes pass data only through VC sockets, not through call sockets. For example, a process may use one call socket to establish multiple VC sockets; these VC sockets are then used to communicate with different processes.
NetIPC Fundamentals NetIPC Concepts resulting destination descriptor, like a telephone number, is then used to direct a caller to a particular destination. Descriptors NetIPC processes reference three types of descriptors: 1) call socket descriptors, 2) destination descriptors, and 3) virtual circuit socket descriptors. Descriptors are returned to processes when certain NetIPC calls are invoked (see Table 1-1).
NetIPC Fundamentals NetIPC Concepts Table 1-1 Descriptor Summary Type of Descriptor Parameter Name Description Returned as Output From Call socket descriptor calldesc Refers to a call socket. A call socket is used to build a VC socket. IPCCREATE IPCGET Destination descriptor destdesc Refers to a destination socket. A destination socket points to addressing information that is used to direct requests to a certain call socket at a certain node.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Using NetIPC for Interprocess Communication The following paragraphs describe the tasks for using NetIPC for process-to-process communication in programs which are: • Establish a connection. • Send and receive data over the connection. • Shut down the connection. These discussions are based on access to level 4 (TCP) but most principles apply to direct access to level 3 (X.25). Information specific to X.25 is noted in the discussion.
NetIPC Fundamentals Using NetIPC for Interprocess Communication the process has created. This call socket descriptor is then used in subsequent NetIPC calls. Figure 1-2 IPCCREATE (Processes A and B) PROCESS A PROCESS B Call Socket Descriptor Call Socket Descriptor 2. Naming a Call Socket Process B associates a name with its call socket by calling IPCNAME (see Figure 1-3). When a call socket is named, this information is placed in the socket registry at the local node.
NetIPC Fundamentals Using NetIPC for Interprocess Communication 3. Looking Up a Call Socket Name Process A must reference the call socket of Process B by its name in the call to IPCLOOKUP to “look up” the name of the call socket in the socket registry at the node where Process B resides. IPCLOOKUP returns a destination descriptor in its destdesc parameter (see Figure 1-4). The destination descriptor indicates the location of the destination call socket which is owned by Process B.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Figure 1-5 IPCCONNECT (Process A) PROCESS A PROCESS B Call Socket Descriptor Call Socket Descriptor SOCKET REGISTRY “NAME” Destination Descriptor VC Socket Descriptor 5. Receiving a Connection Request Using the call socket descriptor returned by its IPCCREATE call, Process B calls IPCRECVCN to receive any connection requests. In this example, Process B receives a connection request from Process A.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Figure 1-6 IPCRECVCN (Process B) PROCESS A PROCESS B Call Socket Descriptor Call Socket Descriptor SOCKET REGISTRY “NAME” Destination Descriptor VC Socket Descriptor VC Socket Descriptor 6. Checking the Status of a Connection Process A calls IPCRECV using the VC socket descriptor returned by its IPCCONNECT call. IPCRECV returns the status of the connection (successful/unsuccessful) initiated by IPCCONNECT.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Figure 1-7 IPCRECV (Process A) PROCESS A PROCESS B Call Socket Descriptor Call Socket Descriptor SOCKET REGISTRY “NAME” Destination Descriptor VC Socket Descriptor VIRTUAL CIRCUIT CONNECTION VC Socket Descriptor Connection Establishment Summary The following discussions summarize the methods for establishing connections using NetIPC intrinsics.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Figure 1-8 Establishing a Connection (Summary) PROCESS A PROCESS B IPCCREATE IPCCREATE IPCNAME IPCLOOKUP IPCCONNECT IPCRECVCN IPCRECV 1) Create call socket 2) “Look up” name 3) Request connection 4) Check status of connection 1) Create call socket 2) Name call socket 3) Receive connection request Connection Establishment Using IPCDEST Figure 1-9 illustrates the sequence of NetIPC calls that is used to establish a virtual circuit conne
NetIPC Fundamentals Using NetIPC for Interprocess Communication Figure 1-9 Using IPCDEST PROCESS A PROCESS B IPCCREATE IPCCREATE IPCDEST IPCCONNECT IPCRECVCN IPCRECV 1) Create call socket 2) Create destination descriptor 3) Request connection 4) Check status of connection 1) Create call socket 2) Receive connection request Sending and Receiving Data Over a Connection Once a virtual circuit connection is established, the two processes can exchange data using the NetIPC calls IPCSEND and IPCRECV.
NetIPC Fundamentals Using NetIPC for Interprocess Communication TCP Access For TCP access, all data transfers between user processes are in stream mode. In stream mode, data is transmitted as a stream of bytes with no end-of-message markers. This means that the amount of data received in an individual IPCRECV is not necessarily equivalent to the amount of data sent in an IPCSEND call. In fact, the data received may contain part of a message or even several messages sent by multiple IPCSEND calls.
NetIPC Fundamentals Using NetIPC for Interprocess Communication Shutting Down Sockets and Connections The NetIPC call IPCSHUTDOWN releases a descriptor and any resources associated with it. IPCSHUTDOWN can be called to release a call socket descriptor, a destination descriptor, or a VC socket descriptor. Because system resources are being used whenever descriptors exist, you should probably release them when they are no longer needed.
NetIPC Fundamentals Using NetIPC for Interprocess Communication To ensure that no data packets are lost before the clear packet is sent, the D bit option can be set in the last IPCSEND. This assures end-to-end acknowledgment of this message before issuing the IPCSHUTDOWN to clear the virtual circuit. Another method to ensure no lost packets is to send an unimportant message as the last message. The following example shows the calling sequence you would use.
NetIPC Fundamentals Using NetIPC for Interprocess Communication termination request, and may also contain data to be processed by Process B. Process A then calls IPCRECV. • Process B receives the message from Process A with a call to IPCRECV and sends a “confirmation message” to Process A via IPCSEND. This message contains data that indicates to Process A that it is okay to terminate the connection, and may also contain data to be processed by Process A. Process B then calls IPCRECV.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Direct Access to Level 3 (X.25) Features The following features of direct access to level 3 (X.25) with NetIPC are described in this section: • Supports switched virtual circuits (SVCs) and permanent virtual circuits (PVCs). • Provides access to the call user data (CUD) field in call packets. • Provides access to X.25 addresses in call packets. • Creation of a catch-all socket which can be used to accept data packets with no CUD or unrecognized CUD.
NetIPC Fundamentals Direct Access to Level 3 (X.25) request for a connection can be accepted (whether or not the server protocol relative address exists). A catch-all socket receives incoming call requests that do not match any other given protocol relative address. One catch-all socket can be defined for each X.25 network. As an example, two programs communicating over an SVC can be designated as the requester and server. Both programs need to be running in order for communication to occur.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Figure 1-10 SVC Requestor Processing Example 1) IPCCreate 2) IPCDest 3) IPCConnect 4) IPCRecv 5) IPCSend 6) IPCRecv 7) IPCShutdown X.25 Protocol CALL REQUEST CALL CONFIRM DATA DATA CLEAR REQUEST CLEAR CONF SVC Server Example Figure 1-11 shows the order of NetIPC calls used for a server program and the X.25 packets generated as a result of the calls. The calls outlined in Figure 1-11 perform the following functions: 1.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Figure 1-11 SVC Server Processing Example 1) IPCCreate 2) IPCRecvcn 3) 4) IPCRecv 5) IPCSend 6) IPCRecv 7) IPCShutdown X.25 Protocol INCOMING CALL REQUEST CALL ACCEPTED DATA DATA CLEAR REQUEST CLEAR CONF Permanent Virtual Circuits (PVCs) Permanent virtual circuits are defined as two DTEs with a logical association permanently held by the network.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Note that these steps do not show how to synchronize data transfer between the two programs, and do not include error checking, or the intrinsic calls required for adding options and special user capabilities.
NetIPC Fundamentals Direct Access to Level 3 (X.25) • Connecting to a catch-all socket. Using IPCCREATE, you can identify a socket as a catch-all socket. All incoming calls with a protocol relative address specified in the CUD that does not match any given protocol relative address are routed to the catch-all socket. Only one catch-all socket may be defined for each X.25 network on each node. For an incoming call with a protocol relative address specified, NetIPC checks if the address matches one created.
NetIPC Fundamentals Direct Access to Level 3 (X.25) If the connection is accepted, up to 128 bytes of call user data may be placed in the call confirmation packet using IPCRECVCN. Once accepted, the virtual circuit is open and can be used as a virtual circuit that does not have fast select. The side that closes the connection can send 128 bytes of clear user data in the clear packet using the IPCSHUTDOWN call. Figure 1-13 is an example of the sequence of calls used with fast select, no restriction.
NetIPC Fundamentals Direct Access to Level 3 (X.25) If the connection is rejected, up to 128 bytes of clear user data may be put in the clear packet using IPCSHUTDOWN. Figure 1-14 is an example using fast select with restriction. Figure 1-14 Fast Select Restricted LOCAL IPCCONNECT (fast select no restriction) (128 byes of CUD) NETWORK REMOTE CALL 128 bytes CUD IPCRECVCN (defer conn.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Facility Field The X.25 facility field is built from the facility set configured with NMMGR. With direct access to X.25 level 3, the facility field can be appended with facilities specified in the opt parameter of the IPCCONNECT intrinsic. The values for the facilities used must follow the X.25 recommendation.
NetIPC Fundamentals Direct Access to Level 3 (X.25) Access to X.25 Protocol Features The NetIPC intrinsics provide access to the following X.25 protocol features: • Send and receive interrupt and reset packets. You can request the X.25 protocol to send an interrupt or reset packet with IPCCONTROL. When used in this way, the IPCCONTROL intrinsic will not return until the appropriate confirmation packet is received by X.25. • Set no activity timeout.
NetIPC Fundamentals NetIPC Between MPE-XL and MPE-V Systems NetIPC Between MPE-XL and MPE-V Systems NetIPC applications can be written to communicate between MPE-V and MPE XL-based HP 3000s with the following considerations: • In addition to the X.25 features supported on MPE-V, NetIPC on MPE XL systems supports the following: — Fast select facility — Ability to append, generate and examine the facility field in call packets — Directly specifying the remote host X.25 address or PVC number.
2 Cross-System NetIPC A cross-system application refers to NetIPC communication between processes running on computers of different types. Cross-system NetIPC is supported using access to the Transmission Control Protocol (TCP) only. This chapter explains what NetIPC calls using TCP access need to be considered for a cross-system application between an HP 3000 and HP 1000 and between an HP 3000 and HP 9000 (Series 300 or 800).
Cross-System NetIPC Software Required Software Required For cross-system NetIPC to function properly, the software revision codes must be as follows: • NS/1000 software revision code 5.0 or greater for the HP 1000. • NS 3000/XL Release 1.2 or later for the HP 3000. • LAN/9000 Series 800 Release 2.1 or later for the HP 9000 Series 800. • NS-ARPA Services Release 6.2 or later for the HP 9000 Series 300. • Revision B.00.01 for the personal computer.
Cross-System NetIPC Calls Affecting the Local Process Calls Affecting the Local Process There are two categories of calls when considering cross-system NetIPC communication — local and remote. Calls made for the local process do not directly affect the remote process. The local NetIPC calls are used to set up or prepare the local node for interprocess communication with the remote node. That is, the resulting impact on the local calls is only to the local node.
Cross-System NetIPC Calls Affecting the Local Process The intrinsics listed in Table 2-1 affect only local processes and therefore have no adverse affects if used in a program communicating with an unlike system (e.g., an HP 3000 program communicating with an HP 1000 program). However, keep in mind that the calls (even those of the same name) differ between system types. The following are some local call differences of which you should be aware: • Maximum number of sockets.
Cross-System NetIPC Calls Affecting the Remote Process Calls Affecting the Remote Process Table 2-2 lists the NetIPC calls affecting communication with the remote process.
Cross-System NetIPC Calls Affecting the Remote Process Table 2-3 Cross-System Calls (HP 3000 — HP 1000) NetIPC Call Cross-System Considerations IPCLOOKUP No differences that affect-cross-system operations. IPCRECV Receive size (dlen parameter) — Range for the HP 3000 is 1 to 30,000 bytes. Range for the HP 1000 is 1 to 8,000 bytes. Although the ranges are different, cross-system communication is not affected.
Cross-System NetIPC Calls Affecting the Remote Process HP 3000 to HP 9000 NetIPC The NetIPC calls affecting cross-system communication with the remote process have the following differences. Checksumming, send and receive sizes, range of permitted TCP protocol addresses for users, and socket sharing. Table 2-4 lists the NetIPC calls affecting the remote process and summarizes the cross-system considerations.
Cross-System NetIPC Calls Affecting the Remote Process Table 2-4 Cross-System Calls (HP 3000 — HP 9000 NetIPC Call Cross-System Consideration IPCRECVCN Checksumming — When the ipcrecvcn() call is executed on the HP 9000 node, checksumming is always enabled. Send and receive sizes — The HP 3000 send and receive size range is 1 to 30,000 bytes. The HP 9000 send and receive size range is 1 to 32,767 bytes. Although the ranges are different, cross-system communication is not affected.
Cross-System NetIPC Calls Affecting the Remote Process HP 3000 to PC NetIPC The NetIPC calls affecting cross-system communication with the remote process have the following differences: checksumming, send and receive sizes, range of permitted TCP protocol addresses for users, and socket sharing. Table 2-5 lists the NetIPC calls affecting the remote process and summarizes the cross-system considerations.
Cross-System NetIPC NetIPC Error Codes Table 2-5 Cross-System Calls (HP 3000 — PC) NetIPC Call Cross-System Considerations IPCRECVCN Checksumming — With PC NetIPC, the TCP checksum option cannot be turned on. But if the HP 3000 requires it, the TCP checksum is in effect on both sides of the connection. Send and receive sizes — The HP 3000 send and receive size range is 1 to 30,000 bytes. The PC send and receive size range is 1 to 65,535 bytes.
Cross-System NetIPC Program Startup Program Startup NetIPC itself does not include a call to schedule a peer process. In programs communicating between multiple HP 3000 systems, you can use the Remote Process Management (RPM) call, RPMCREATE, to programmatically schedule program execution. However, RPM between HP 3000 and HP 1000 systems, and between HP 3000 and HP 9000 systems, is not currently supported by Hewlett-Packard. Instead, you must manually start up each NetIPC program on its respective system.
Cross-System NetIPC Program Startup PC NetIPC Program Startup To manually start up a PC NetIPC program, enter the NetIPC program name at the MS-DOS prompt. To execute from within MS-Windows, copy the NetIPC program files to your Windows directory and double click the mouse on the executable file.
3 NetIPC Intrinsics The information contained in this chapter is organized as follows:. • Programming Considerations: describes programming considerations for using NetIPC on an MPE XL computer system. • Common Parameters: provides details about the structure of the flags, opt, data, and result parameters which are common to many of the NetIPC calls.
NetIPC Intrinsics Programming Considerations Programming Considerations Compatibility vs. Native Mode Compatibility mode allows you to run application programs compiled on an MPE V computer system on an MPE XL computer system without change. Native mode refers to application programs compiled and executed on an MPE XL computer system. NetIPC applications written for MPE V based HP 3000s can be migrated to MPE XL HP 3000s (series 900s) and run in compatibility mode as follows.
NetIPC Intrinsics Programming Considerations Capabilities Some NetIPC intrinsics require special capabilities if you use the functions described below. User-specified Protocol Addressing NetIPC intrinsics IPCCONNECT, IPCCREATE, and IPCDEST allow you to specify protocol relative addresses. Addresses in the range 30767 to 32767 decimal (%74057 to %77777) can be used without special capabilities. In privileged programs you can specify protocol relative addresses between 1 and 30766 decimal (%1 and %74056).
NetIPC Intrinsics Common Parameters Common Parameters The flags, opt, data, and result parameters are common to many NetIPC intrinsics. Remote Process Management intrinsics also use these parameters, with the exception of the data parameter. The following discussion of these parameters may help to clarify the more condensed information given under each intrinsic. Flags Parameter The flags parameter is a bit representation, 32 bits long, of various options.
NetIPC Intrinsics Common Parameters — Reserved (2 bytes). • data associated with the option entries (variable length). If the parameter is declared as a simple byte array, it must be large enough to contain 4 bytes for the first two fixed-length fields, 8 bytes for each option entry, plus the actual data. That is: 4 + 8 * numentries + datalength NOTE Use of certain opt parameter options may result in the loss of portability between different Hewlett-Packard systems.
NetIPC Intrinsics Common Parameters Figure 3-2 Option Entry Structure. Byte 0 option code 1 2 offset 3 4 data length 5 6 7 Data Parameter The data parameter is defined as a byte array. It can be in one of two formats: either holding the actual data or in a vectored format. In the case of vectored data, the data parameter does not contain actual data but rather the addresses from or to which the data will be gathered or distributed.
NetIPC Intrinsics Common Parameters Figure 3-3 Data Location Descriptor — Vectored Data Compatibility Mode Native Mode Byte Byte 0 0 descriptor type 1 1 descriptor type = 4 2 2 byte length DST 3 3 4 4 byte offset 5 5 6 6 byte length native mode address 7 7 8 (64 bits) 9 10 11 Compatibility Mode In compatibility mode, the data location descriptor is eight bytes long and consists of four 2-byte fields.
NetIPC Intrinsics Common Parameters • byte length of the vectored data. Native Mode In native mode, the data location descriptor is 12-bytes long. It contains two 2-byte fields and a 64-bit native mode address. The DST field is unnecessary because DSTs do not exist in native mode.
NetIPC Intrinsics Summary of NetIPC Intrinsics Summary of NetIPC Intrinsics Table 3-1 lists and summarizes the function of each of the NetIPC intrinsics. Table 3-1 NetIPC Intrinsics Intrinsic Function ADDOPT Adds an option entry to the opt parameter. INITOPT Initializes the opt parameter so that entries may be added. IPCCHECK Returns the number of the last recorded NetIPC error for a call or VC socket.
NetIPC Intrinsics NetIPC Reference Pages NetIPC Reference Pages The following pages provide syntax and usage information for each of the NetIPC intrinsics. The reference pages are organized alphabetically by NetIPC intrinsic name. ADDOPT Adds an option entry to the opt parameter. Syntax ADDOPT (opt,entrynum,optioncode,datalength,data[,result]) Parameters opt (input/output) Record or byte array, by reference. The opt parameter to which you want to add an entry.
NetIPC Intrinsics ADDOPT Description The ADDOPT intrinsic specifies the values of an opt parameter’s option entry fields and adds any associated data. The intrinsic also updates the size of the opt parameter. The parameter must be initialized by INITOPT before options are added by ADDOPT.
NetIPC Intrinsics INITOPT INITOPT Initializes the opt parameter so that entries may be added. Syntax INITOPT (opt,eventualentries,[result]) Parameters opt (output) Record or byte array, by reference. The opt parameter which is to be initialized. Refer to “Common Parameters” for more information on the structure of this parameter. eventualentries (input) 16-bit integer, by value. The number of option entries that are to be placed in the opt parameter. result (output) 16-bit integer, by reference.
NetIPC Intrinsics IPCCHECK IPCCHECK Returns the number of the last applicable error. Syntax IPCCHECK (descriptor [,ipcerr][,pmerr][,result] Parameters descriptor (input) 32-bit integer, by value. The call socket or VC socket descriptor for which the error is to be reported. A zero value indicates the last call socket or VC socket descriptor referenced. ipcerr (output) 32-bit integer, by reference. The error code of the last recorded NetIPC error. pmerr (output) 32-bit integer, by reference.
NetIPC Intrinsics IPCCONNECT IPCCONNECT Requests a connection to another process. Syntax IPCCONNECT ([calldesc],destdesc[,flags][,opt],vcdesc[,result] Parameters calldesc (input) 32-bit integer, by value. A call socket descriptor for a call socket belonging to this process. Required for X.25 level 3 access. For TCP access, if -1, or if omitted, a call socket is created temporarily to establish the connection. destdesc (input) 32-bit integer, by value. Destination descriptor.
NetIPC Intrinsics IPCCONNECT handled at the link level and is not normally required at the user level. Checksumming is only used for connections between nodes and is not used for connections within the same node. Enabling checksumming may reduce network performance. Recommended value: 0. opt (input) Record or byte array, by reference. A list of options, with associated information. Possible options are: • call user data (code=2, length=n, n bytes) (input). For access to the X.25 protocol only.
NetIPC Intrinsics IPCCONNECT previously specified maximum receive size, then the new value is ignored. • address option (code=128, length=2; 2-byte integer) (input). (TCP only.) This option specifies the source port address of the connection request. Addresses in the range (octal) %74057 to %77777 can be used without special capabilities. • facilities set name (code=142, length=8, packed array of 8 characters) (input). For access to the X.25 protocol only.
NetIPC Intrinsics IPCCONNECT Description The IPCCONNECT intrinsic is used to establish a VC socket (for a virtual circuit) to another process. The calling process must first create a call socket for itself and obtain the destination descriptor of a call socket belonging to the other process. A successful result means that the connection request has been initiated.
NetIPC Intrinsics IPCCONNECT X.25 Considerations IPCCONNECT used over a switched virtual circuit causes the X.25 protocol to send a call request packet to the node and process described by the destination socket. Over a permanent virtual circuit (PVC), a reset packet is sent. The opt parameter CUD field is sent as the CUD field in the call request packet. Based on the setting of the opt protocol flags “no address” flag, the user has access to either 12 or 16 bytes in the CUD field.
NetIPC Intrinsics IPCCONNECT HP 3000 to HP 1000: Checksumming — TCP checksumming will be enabled for both sides of the connection if it is enabled by either side for HP 3000 to HP 1000 cross-system communication. On both the HP 3000 and HP 1000 checksumming can be enabled by setting bit 21 in the flags parameter. Send and receive sizes — The HP 3000 send and receive size range is 1 to 30,000 bytes. The HP 1000 send and receive size range is 1 to 8,000 bytes.
NetIPC Intrinsics IPCCONTROL IPCCONTROL Performs special operations. Syntax IPCCONTROL (descriptor,request[,wrtdata][,wlen][,readdata][,rlen] [,flags][,result)] Parameters descriptor (input) 32-bit integer, by value. Either a call socket descriptor or a VC socket descriptor. request (input) 32-bit integer, by value. The value supplied indicates what control operation is to be performed. • 1 = Enable nowait (asynchronous) I/O for the specified call socket or VC socket descriptor.
NetIPC Intrinsics IPCCONTROL select facility has been used, the maximum length is 128 bytes. — code 145 — (X.25 only.) This option field defines the part of the facility field to be appended to the facility field built using the received facilities. The maximum length of this field is 109 bytes. This buffer has to follow the X.25 recommendation and is appended to the facility field built based on the information contained in the call request. • 10 = Send a reset packet (X.25 only.
NetIPC Intrinsics IPCCONTROL The type of packets returned are: — 10 = Clear packet received — 11 = Reset packet received — 12 = Interrupt packet received If no event is reported, readdata contains zeros. If the error was caused by a clear packet, the connection is lost, and the user must use IPCSHUTDOWN to clear the connection. There is no wrtdata associated with this request. • 13 = Set no activity timeout (X.25 only.) This request is only valid on connection sockets.
NetIPC Intrinsics IPCCONTROL field built based on the information contained in the call request. • 256 = Enable nowait receives; disable nowait sends. • 257 = Enable nowait sends; disable nowait receives. • 258 = Abort outstanding nowait receives. • 259 = Enable user-level NetIPC tracing. This request causes NetIPC intrinsic calls (both initiation and completion of I/O requests) to be traced. — code 131 — Indicates that the data portion of the wrtdata parameter contains the trace file name.
NetIPC Intrinsics IPCCONTROL wrtdata (input) Record or byte array, by reference. If the request is to change the default timeout, (request code 3 or 262) the value in the first two bytes of the wrtdata buffer will become the new timeout, in tenths of a second. A zero value indicates an indefinite timeout: a call to IOWAIT returns only after the next I/O request completes. If the request is to enable tracing, (request code 259) or for X.
NetIPC Intrinsics IPCCONTROL Description The IPCCONTROL intrinsic is used to perform various special operations on sockets. This intrinsic is option variable. All requests require the descriptor and request parameters except request 14 which requires request and readdata only. The timeout requests (code 3 or 262) also require the wrtdata parameter. For tracing, socket address requests, and the local node name, information may be returned in the readdata buffer.
NetIPC Intrinsics IPCCONTROL Table 3-3 readdata Meanings Descriptor Type Address Meaning call socket port address of socket (for TCP, length=2 bytes) connection from IPCCONNECT local port address of connection socket (for TCP, length=2 bytes) connection from IPCRECVCN remote port address of connection socket in bytes 0 and 1, remote internet address of node in bytes 2 through 5. (6 bytes total length) Condition codes returned by this intrinsic are: • CCE — Succeeded.
NetIPC Intrinsics IPCCONTROL X.25 Considerations Common errors returned by IPCCONTROL in result are: SOCKERR SOCKERR SOCKERR 0 59 65 SOCKERR SOCKERR SOCKERR SOCKERR SOCKERR 67 107 160 170 171 Request completed successfully. Socket timeout. Connection aborted by local protocol module. Connection failure detected. Transport is going down. Incompatible with protocol state. Error with use of fast select facility. Invalid facility field opt record entry.
NetIPC Intrinsics IPCCREATE IPCCREATE Creates a call socket for the calling process. Syntax IPCCREATE (socketkind[,protocol][,flags][,opt],calldesc[,result]) Parameters socketkind (input) 32-bit integer, by value. Indicates the type of socket to be created. The only type that a user process may create is: 3 = call socket. It is used for sending and receiving connection requests. protocol (input) 32-bit integer, by value. Indicates the protocol module which the calling process wishes to access.
NetIPC Intrinsics IPCCREATE connections that can be queued to a call socket. The default value is 7. • address option (option code=128, length=n; n-byte array), (input). Allows users to specify the socket’s protocol relative address rather than having NetIPC allocate an address. The format of this address is defined by the protocol, for TCP and X.25 protocol access, the address is a 2-byte array. For X.25, you must either specify a protocol relative address, or identify the socket as catch-all.
NetIPC Intrinsics IPCCREATE Description The IPCCREATE intrinsic creates a call socket, returning a call socket descriptor. A call socket descriptor is an identifying number which may be used in other NetIPC intrinsic calls. A process may own a maximum of 64 (call and VC) sockets. If a socket has been given away (via the IPCGIVE intrinsic), it is included in this total until another process takes it (via IPCGET). Only the socketkind and calldesc parameters are required.
NetIPC Intrinsics IPCCREATE If no match is found, the incoming call is routed to the catch-all socket if one has been defined. If the CUD address does not match any of the call sockets and no catch-all socket has been defined, the incoming call is cleared. the cause field of the clear packet is set to 0 and the diagnostic is 64. The catch-all socket can be defined by setting the opt protocol flags catch-all socket flag (bit 2). Only one catch-all socket can be defined per directly-connected network.
NetIPC Intrinsics IPCDEST IPCDEST Creates a destination descriptor. Syntax IPCDEST (socketkind[,location][,locationlen],protocol, protoaddr,protolen[,flags][,opt],destdesc[,result]) Parameters socketkind (input) 32-bit integer, by value. Defines the type of socket. The only type user processes can create is: 3 = call socket. location (input) Character array, by reference. The name of the node (either node or node.domain.organization) on which the destination socket is to be created.
NetIPC Intrinsics IPCDEST protolen (input) 32-bit integer, by value. The length in bytes of the protocol address. flags 32 bits, by reference. A bit representation of various options. No flags are currently defined. opt (input) Record or byte array, by reference. A list of options, with associated information. • destination network address (code = 16, length=n, n byte buffer) (input). (X.25 only.
NetIPC Intrinsics IPCDEST Description The IPCDEST intrinsic creates a destination descriptor that contains routing information for sending data to another process. This intrinsic is option variable. The required parameters are: socketkind, protocol, protoaddr, protolen, and destdesc. Condition codes returned by this intrinsic are: • CCE — Succeeded. • CCL — Failed. • CCG — Not returned by this intrinsic. This intrinsic cannot be called in split stack mode.
NetIPC Intrinsics IPCDEST IPCERRMSG Returns the NetIPC error message corresponding to a given error code. Syntax IPCERRMSG (ipcerr,msg,len,result) Parameters ipcerr (input) 32-bit integer, by value. A valid NetIPC error code. msg (output) Character array, by reference. The NetIPC error message corresponding to the given error code. len (output) 32-bit integer, by reference. The length (in bytes) of the error message. The maximum is 80 bytes. result (output) 32-bit integer, by reference.
NetIPC Intrinsics IPCGET IPCGET Obtains a VC socket or call socket descriptor that has been given away by another process. Syntax IPCGET (givename,nlen,flags,descriptor,result) Parameters givename (input) Character array, by reference. The temporary name assigned to the socket when it was given away. It is up to 16 characters long. nlen (input) 32-bit integer, by value. The length in bytes of the specified name. flags 32 bits, by reference. A bit representation of various options.
NetIPC Intrinsics IPCGIVE IPCGIVE Gives away a VC socket or call socket descriptor, making it available for use by other processes. Syntax IPCGIVE (descriptor,givename,nlen,flags,result) Parameters descriptor (input) 32-bit integer, by value. The VC socket or call socket descriptor to be given away. givename (input/output) Character array, by reference. A name which will be temporarily assigned to the specified socket. The process which obtains the socket must request it by this name.
NetIPC Intrinsics IPCGIVE need to create its own call socket and engage in the NetIPC connection dialogue in order to communicate with Process C. All the parameters are required. When a socket is given away, it is assigned a new, temporary name. This name is either specified by the user or assigned by the NetIPC facility. It continues to exist only until the socket is obtained by another process or destroyed. The other process uses this name in a call to IPCGET, not IPCLOOKUP.
NetIPC Intrinsics IPCLOOKUP IPCLOOKUP Obtains a destination descriptor for a named call socket. Use with TCP access only. Syntax IPCLOOKUP (socketname,nlen[,location][,loclen][,flags],destdesc [,protocol][,socketkind][,result]) Parameters socketname (input) Character array, by reference. The name of the socket. nlen (input) 32-bit integer, by value. The length in bytes of the specified socket name. Maximum is 16. location (input) Character array, by reference.
NetIPC Intrinsics IPCLOOKUP protocol (output) 32-bit integer, by reference. A number identifying the protocol module with which the socket is associated: The only protocol available to user processes is: 4 = TCP. socketkind (output) 32-bit integer, by reference. A number which identifies the socket’s type: 3 = call. result (output) 32-bit integer, by reference. The error code returned; zero if no error. Description The IPCLOOKUP intrinsic is used to gain access to a named socket.
NetIPC Intrinsics IPCNAME IPCNAME Associates a name with a call socket descriptor. Syntax IPCNAME (calldesc,socketname,nlen,result) Parameters calldesc (input) 32-bit integer, by value. The call socket descriptor to be named. socketname (input/output) Character array, by reference. The name (maximum of 16 characters) to be assigned to the socket. If the nlen (name length) parameter is zero, an 8-character name is randomly assigned and returned in the givename parameter.
NetIPC Intrinsics IPCNAMERASE IPCNAMERASE Deletes a name associated with a call socket descriptor. Syntax IPCNAMERASE (socketname,nlen,result) Parameters socketname (input) Character array, by reference. The socket name, bound to a socket, which is to be removed. nlen (input) 32-bit integer, by value. The length in bytes of the specified socket name. Maximum is 16. result (output) 32-bit integer, by reference. The error code returned; zero if no error.
NetIPC Intrinsics IPCRECV IPCRECV Receives a response to a connection request, thereby completing a connection, or receives data on an existing connection. Syntax IPCRECV (vcdesc[,data][,dlen][,flags][,opt][result] Parameters vcdesc (input 32-bit integer, by value. The VC socket descriptor, a number identifying the VC socket belonging to this process through which the data will be received. data (output) Record or byte array, by reference.
NetIPC Intrinsics IPCRECV completes. This flag has no effect if waited I/O is used. • flags [25] — discarded (output). (X.25 only.) This flag indicates that the call user data, or the facility field were present, but that some or all had to be discarded. This can occur if no call user data receive option was specified or if either field is too short to hold all of the data. • flags [26] — more data (output). This flag indicates that there may be more data to be received after completion of this IPCRECV.
NetIPC Intrinsics IPCRECV opt (input) Record or byte array, by reference. A list of options, with associated information. The following options are defined: • call user data receive (code 5, len=n; n bytes) (output). This option provides a buffer for the return of the call user data (CUD) field if you are using the fast select facility. If call user data is present, but this option is not supplied, then the discarded flag (flags bit 25) will be set.
NetIPC Intrinsics IPCRECV NOTE If using nowait I/O and opt array options that generate output, the array must remain intact until after IOWAIT completes. Otherwise, the array area will be overwritten or (if the area has been deleted from the stack) an error will occur. result (output) 32-bit integer, by reference. The error code returned; zero if no error. NOTE When nowait I/O is used, the result parameter is not updated upon completion of an intrinsic.
NetIPC Intrinsics IPCRECV and updated (with the “more data” flag off or on) when IOWAIT completes. The data parameter will then contain the data received. Only one nowait receive may be outstanding on a single connection. The returned dlen parameter (or the IOWAIT tcount parameter in the case of a nowait request) shows how many bytes of data were actually received in the data parameter. This amount may be different from what you requested.
NetIPC Intrinsics IPCRECV X.25 Considerations In receiving a response to a connection request, the option field returns the facility field and the call user data (CUD) field. With fast select, up to 128 bytes of call user data may be returned in the call user data receive buffer (opt 5). A single IPCRECV call returns data for one message only. If the “more data” flag is set, the complete message has not been received.
NetIPC Intrinsics IPCRECV Table 3-8 TCP Urgent and More Data Bit Combinations Urgent More Data Meaning 0 0 Should never happen. (The receipt of normal data in stream mode causes more data to be set.) 0 1 Normal receive, no urgent data. 1 0 Urgent data received, no more urgent data. 1 1 Urgent data received and more is pending.
NetIPC Intrinsics IPCRECV On the PC, you can specify the maximum receive size of the data buffer through the got array in the IPCCONNECT call. This determines what the maximum value the dlen parameter can be for any IPCRECV call. PC NetIPC has no option array defined in IPCCONNECT. This does not affect cross-system communication. The maximum receive size of the data in the buffer on the HP 3000 will determine the receive size buffer on the PC.
NetIPC Intrinsics IPCRECVCN IPCRECVCN Receives a connection request on a call socket. Syntax IPCRECVCN (calldesc,vcdesc[,flags][,opt][,result]) Parameters calldesc (input) 32-bit integer, by value. Call socket descriptor. The socket descriptor for a call socket belonging to this process. vcdesc (output) 32-bit integer, by reference. The returned VC socket descriptor, a number identifying a VC socket belonging to this process through which data can be sent or received.
NetIPC Intrinsics IPCRECVCN Checksum enabled by either IPCCONNECT or TCP (remote or local) configuration overrides a 0 setting (checksum disabled) for this flag. Checksum error checking is handled at the link level and is not normally required at the user level. In fact, checksumming is only used for connections between nodes and is not used for connections within the same node. Enabling checksum may reduce network performance. Recommended value: 0. • flags [25] — discarded (output). For X.
NetIPC Intrinsics IPCRECVCN return of the call user data (CUD) field from an X.25 packet. If call user data is present, but this option is not supplied, the discarded flag [25] is set. If the buffer is not long enough to contain the data, the data is truncated and the discarded flag is set. • calling node address (code=141, length=8; 8-byte array) (output). An output parameter that is used to contain the address of the requestor.
NetIPC Intrinsics IPCRECVCN — calling node address available (bit 16, output). (X.25 only.) This flag indicates that the calling node X.25 address was present. • Facility field (code=145, length=n, n bytes) (output). (X.25 only.) This option provides a buffer for the return of the facility field. If the facility field is present, but this buffer is not supplied, then the discarded flag (bit 25) is set.
NetIPC Intrinsics IPCRECVCN IPCRECVCN and the IOWAIT intrinsic calls. NetIPC also retains the flags parameter. The only required parameters are the calldesc and vcdesc parameters (option variable). Condition codes returned by this intrinsic are: • CCE — Succeeded. • CCL — Failed. • CCG — Not returned by this intrinsic. Condition codes returned by the call to IOWAIT are: • CCE — Succeeded. • CCL — Failure in NetIPC (for example, resource problems, VC socket descriptor bounds) or protocol module.
NetIPC Intrinsics IPCRECVCN Protocol-Specific Considerations The following Table 3-9 outlines parameters that are specific to the particular protocol you are accessing. Table 3-9 IPCRECVCN Protocol Specific Parameters Parameters TCP X.25 0 Protected connection n/a 21 Enable checksum n/a 25 n/a Discarded 3 Maximum send size n/a 4 Maximum receive size n/a 5 n/a Received CUD 141 Calling node’s IP address Calling node’s X.
NetIPC Intrinsics IPCRECVCN Common errors returned by IPCRECVCN in result are: SOCKERR 0 SOCKERR 59 SOCKERR 107 Request completed successfully. Socket timeout. Transport is going down. A complete table of SOCKERRs is included in Chapter C , “Error Messages.” TCP The calling process may also specify whether checksumming is to be employed by the protocol modules (i.e., TCP) that support it.
NetIPC Intrinsics IPCRECVCN receive size is 100 bytes. HP 3000 to PC NetIPC Checksumming — With PC NetIPC, the TCP checksum option cannot be turned on. But if the HP 3000 requires it, the TCP checksum is in effect on both sides of the connection. On the HP 3000, enabling/disabling checksumming with NetIPC intrinsics allows you to override the checksumming decision made during network transport configuration for this particular process.
NetIPC Intrinsics IPCSEND IPCSEND Sends data on a connection. Syntax IPCSEND (vcdesc,data,dlen[,flags][,opt],result) Parameters vcdesc (input) 32-bit integer, by value. The VC socket descriptor, a number identifying the VC socket belonging to this process through which the data will be sent. data (input) Record or byte array, by reference. Contains the data to be sent or a list of data descriptors (maximum of two) indicating the locations from which the data will be gathered.
NetIPC Intrinsics IPCSEND • data offset (code=8, length=2; 2-byte integer) (input). Compatibility mode (CM) only. An offset in bytes from the data parameter's address indicating the actual beginning of the data. HP recommends that you do not use data offset if data descriptors are used to point to another location from which data should be obtained. • protocol flags (code=144, length=4; 4-byte buffer) (input). This option contains 32 bits of protocol-specific flags.
NetIPC Intrinsics IPCSEND is NOT applied to the pointer in the descriptor). This may lead to unexpected results. If this intrinsic is called in nowait mode, the address of the data is passed to the TCP protocol module. The contents of the data buffer will have been read when IOWAIT completes. As many as 7 nowait sends may be outstanding on a connection. Condition codes returned by IPCSEND and IOWAIT are: • CCE — Succeeded. • CCL — Failed. • CCG — Not returned.
NetIPC Intrinsics IPCSEND A complete table of SOCKERRs is included in Appendix C , “Error Messages.” TCP The urgent data bit of the protocol flags option (opt parameter) is used to inform TCP that the data to be sent should be marked urgent. This will not cause the data to be delivered out of band, and the receiver of this data will not know of urgent data that is pending until a receive is posted.
NetIPC Intrinsics IPCSHUTDOWN IPCSHUTDOWN Releases a descriptor and any resources associated with it. Syntax IPCSHUTDOWN (descriptor[,flags][,opt][,result] Parameters descriptor (input) 32-bit integer, by value. The socket to be released. May be a call socket, destination, or VC socket descriptor. flags 32 bits, by reference. A bit representation of various options. The following flag is defined: flag [17] — (TCP only.) graceful release of connection. opt Record or byte array, by reference.
NetIPC Intrinsics IPCSHUTDOWN Description The IPCSHUTDOWN intrinsic permits the creating process to close a call socket or a VC socket descriptor or to release a connection. The descriptor is the only required parameter (option variable). IPCSHUTDOWN can be called to release a call socket descriptor, a destination descriptor, or a VC socket descriptor. Since systems resources are used up as long as call sockets and destination sockets exist, you should release them whenever they are no longer needed.
NetIPC Intrinsics IPCSHUTDOWN data network (PDN), the cause may not be transmitted to the remote node. When used with direct access to level 3, the intrinsic IPCSHUTDOWN can only be called in waited mode. The intrinsic will not return until the request is completed. X.25 direct access to level 3 does not support the graceful release bit. As a suggestion, to ensure that no data packets are lost before the clear packet is sent, use the D bit option in the last IPCSEND.
NetIPC Intrinsics IPCSHUTDOWN • Data is being sent from the connection. This could occur, for example, if IPCSEND was called in nowait mode and has not yet completed. Cross-System Considerations For TCP The following are cross-system programming considerations for this intrinsic: HP 3000 to HP 1000: Socket shut down — The HP 3000 provides a graceful release flag (flag 17) that is not available on the HP 1000. Do not set the graceful release flag on the HP 3000.
NetIPC Intrinsics OPTOVERHEAD OPTOVERHEAD Returns the number of bytes needed for the opt parameter in a subsequent intrinsic call, not including the data portion of the parameter. Syntax optlength := OPTOVERHEAD(eventualentries[,result]) Parameters optlength (returned function value) 16-bit integer. The number of bytes required for the opt parameter, not including the data portion of the parameter. eventualentries (input) 16-bit integer, by value.
NetIPC Intrinsics READOPT READOPT Obtains the option code and argument data associated with an opt parameter argument. Syntax READOPT (opt,entrynum,optioncode,datalength,data,result) Parameters opt (input) Record or byte array, by reference. The opt parameter to be read. Refer to “NetIPC Intrinsics/Common Parameters” for information on the structure and use of this parameter. entrynum (input) 16-bit integer, by value. The number of the option entry to be obtained. The first entry is number zero.
NetIPC Intrinsics READOPT result (output) 16-bit integer, by reference. The error code returned; zero if no error. Description If the data field is not large enough, then as much data as the user asked for will be returned and SOCKERR 173 will be returned indicating more data is available. A second call to READOPT could get all the data.
NetIPC Intrinsics Asynchronous I/O Asynchronous I/O In order to perform nowait (asynchronous) socket I/O on an HP 3000, a process must use the MPE XL IOWAIT and IODONTWAIT intrinsics. IOWAIT and IODONTWAIT behave in the same way except that, in the first case, the calling process must wait until the I/O operation is complete; in the second case, control is immediately returned to the calling process. One of these intrinsics must be called at some point after a nowait I/O request.
NetIPC Intrinsics Asynchronous I/O Steps for Programming with Asynchronous I/O The following summarizes the steps to follow to have your program perform asynchronous I/O: • Create the call or VC socket with IPCCREATE, IPCCONNECT, or IPCRECVCN. • Enable nowait I/O with IPCCONTROL. • Make a IPCRECVCN, IPCRECV, or IPCSEND NetIPC call on the socket. The call will be asynchronous. • Check the result code returned by the call to see if an error occurred when the call was initiated.
NetIPC Intrinsics IO[DONT]WAIT IO[DONT]WAIT Initiates completion operations for a nowait I/O request. Syntax fnum := IO[DONT]WAIT ([filenum][,target][,tcount][,cstation]) Parameters fnum (returned function value) 16-bit integer. The socket/VC socket descriptor for which an I/O request has completed. Zero indicates no completion. If there are any nowait file access requests outstanding, and if the filenum parameter is zero, the returned function value may be an actual file number.
NetIPC Intrinsics IO[DONT]WAIT If a nowait IPCSEND, IPCRECVCN, or IPCRECV request is issued, the data and flags parameters (if specified) must exist when IOWAIT or IODONTWAIT is called. In other words, these parameters must be global to both the IPC intrinsic that initiates the request and the IO[DONT]WAIT that attempts to complete the I/O. All parameters are optional (option variable).
NetIPC Intrinsics IO[DONT]WAIT 130 Chapter 3
4 NetIPC Examples This chapter contains sample programs using NetIPC for both TCP access and X.25 (level 3) access: • Example 1 (programs 1A and 1B) present an example of how to set up and use a connection (virtual circuit) for TCP access. The two programs, running on different nodes, open communication via call sockets. They then establish a connection (using VC sockets) and send and receive data over this connection. Finally, they terminate their connection.
NetIPC Examples Example 1 Example 1 In the first two programs (1A and 1B), the lengths of the data messages are not known. The sending side (Program 1A) includes the length of each message as the first two bytes of each message it sends. The receiving side (Program 1B) executes two IPCRECV loops for each message: first to receive the length and then to receive the data.
NetIPC Examples Example 1 • sends a “termination confirmation message” in response to the termination request; • receives a result parameter value of 64 (“REMOTE ABORTED CONNECTION”) in response to a receive request; • releases its VC socket. Program 1A $standard_level 'HP3000', uslinit$ program connection_example1 (input,output); const maxdata = 2000; maxmsg = maxdata + 2; maxname = 20; maxloc = 20; type smallint = -32768..32767; datatype = record; len : smallint; msg : packed array[1..
NetIPC Examples Example 1 procedure procedure procedure procedure procedure procedure ipcconnect; ipcrecv; ipcsend; ipcshutdown ipcerrmsg; ipccontrol; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; {error handling procedure} procedure leave(result: integer); var msg: string[80]; i, len, newresult: integer; begin ipcerrmsg(result, msg, len, newresult); if newresult = 0 then begin setstrlen(msg, len); writeln(msg); {print error message} end else writeln('IpcErrMsg result is ', newresult:
NetIPC Examples Example 1 readln(strdata); {read message} data.len := strlen(strdata); {store message length} strmove(data.len, strdata, 1, data.msg, 1); {store message} ipcsend(vcdesc, data, data.len+2, , ,result) {send message with length as first 2 bytes} if result <> 0 then leave(result); {failed} end; {connection shutdown procedure} data.len := 4; data.
NetIPC Examples Example 1 procedure terminate; intrinsic; {NetIPC intrinsic declarations} procedure procedure procedure procedure procedure procedure procedure procedure ipccreate; ipcname; iprecvcn; ipcrecv; ipcsend; ipcshutdown; ipcerrmsg; ipccontrol; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; {error handling procedure} procedure leave(result : integer); var msg: string[80]; i, len, newresult: integer; begin ipcerrmsg(result, msg, len, newresult); if newre
NetIPC Examples Example 1 begin dlen := head_len - i; ipcrecv( connection, tempbfr, dlen, , , errorcode ); if errorcode = 0 then strmove(dlen, tempbfr, 1, header_len.byte, i+1); i := i + dlen; end; if errorcode = 0 then begin rlen := header_len.word; i := 0; while (i <> rlen) and (errorcode = 0) do { get the message } begin dlen := header_len.
NetIPC Examples Example 1 strmove(len, data, 1, datastr, 1); if datastr <> 'END?' then writeln (datastr); end until datastr = 'END?'; {print data received} {connection shutdown procedure} if datastr = 'END?' then writeln('END received'); data := 'Y'; ipcsend( vcdesc, data, 1, , , result ); {confirmation message} writeln('Y sent'); if result <> 0 then leave(result); receive(vcdesc, data, len, result ); if result = 64 then ipcshutdown(vcdesc) else leave(result ); end.
NetIPC Examples Example 2 Example 2 This pair of programs show the differences in compiler options for writing NetIPC programs to run in compatibility mode and native mode. The programs are designated vector1 and vector2. You can compile them in either compatibility mode or native mode as described in the comments preceding the programs.
NetIPC Examples Example 2 TYPE flags_type msg_type = set of 0..31; = packed array [1..80] of char; netipc_data_desc = packed record { This structure contains a maximum $if 'native_mode'$ d_desc_type1 : shortint; d_desc_len1 : shortint; d_desc_dataptr1 : globalanyptr; of two data descriptors.
NetIPC Examples Example 2 procedure procedure procedure procedure procedure procedure procedure ipcerrmsg; ipcget; ipcgive; ipcrecv; ipcrecvcn; ipcsend; ipcshutdown; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; intrinsic; begin $if 'native_mode'$ writeln ('example program vector1 to show vectored data operation in Native Mode'); $else$ writeln ('example program vector1 to show vectored data operation in Compatibility Mode' ); $endif$ { specify the address of the local socket } adrs[0
NetIPC Examples Example 2 vd.d_desc_type1 := DESC_TYPE; vd.d_desc_type2 := DESC_TYPE; flags := [ F_VECTORED ]; { Receive the message in a double vector } messag1 := ' '; { 46 } messag2 := ' '; { 46 } vd.d_desc_len1 := 27; { max we are willing to receive } vd.
NetIPC Examples Example 2 writeln ('dlen was not = 21'); { Check that the correct data was received } expect := 'Abaracadabara magic!'; error := false; for i := 1 to dlen do if messag1[i] <> expect[i] then error := true; if error then begin writeln ('did not receive expected data, got:'); writeln ( messag1 ); end; { Clean up and shutdown } { shutdown the local connection descriptor } ipcshutdown ( cd_local, , , result ); if result <> 0 then writeln ('ipcshutdown cd_local failed'); { shutdown the local socke
NetIPC Examples Example 2 TYPE byte = 0..255; shortint = -32768..32767; CONST $if 'native_mode'$ DESC_TYPE = DESC_LEN = $else$ DESC_TYPE = DESC_LEN = $endif$ F_VECTORED } } 4; 12; { descriptor type for 64b ptr } { length of NM vector descriptor} 0; 8; { descriptor type for CM stack } { length of CM vector descriptor} = 31; TYPE flags_type location_type msg_type { this is one byte long { this is two bytes long { vectored data } = set of 0..31; = packed array [1..50] of char; = packed array [1..
NetIPC Examples Example 2 flags: result: result16: i: messag1: messag2: expect : vd: error: location: flags_type; integer; shortint; integer; msg_type; msg_type; msg_type; netipc_data_desc; boolean; location_type; { { { { { { { { { { flags parameter back from IPC call back from opt calls loop counter for messages for printed messages for printed messages expected message vectored data desc set if an error occurred other programs location node } } } } } } } } } } adrs: packed array [0..
NetIPC Examples Example 2 location := 'bigblue'; ipcdest ( 3, location, 7, 4, adrs, 2, , , dd, result ); if result <> 0 then writeln ('ipcdest failed ' , result ); { Connect to the local socket using the destination descriptor.
NetIPC Examples Example 2 if messag1[i] <> expect[i] then error := true; if error then begin writeln ('did not receive expected single vector data, got:'); writeln ( messag1 ); end; { send a double vectored message to the local side messag1 := 'Abaracadabara '; messag2 := 'magic!'; vd.d_desc_len1 := 15; { byte size of message vd.
NetIPC Examples Example 3 Example 3 Example 3 includes a pair of programs designated requester (X25CHECK) and server (X25SERV) using direct access to X.25 at level 3. These programs must be compiled in compatibility mode. The X.25 features used in these programs are the set supported on MPE-V. Example 4 uses the additional X.25 features supported on MPE XL. The program functions are described in the comments included with the program listings.
NetIPC Examples Example 3 data : packed array [1..
NetIPC Examples Example 3 {*****************************************************************} { } { SOURCE : CHECK } { } { DESCRIPTION : } { Simplified version. } { This program checks that connections to remote nodes or even } { to local node can be actually achieved. It also allows to } { estimate the performances of the network. It communicates with } { program X25SERV that runs on remote nodes. } { X25CHECK sends 10 times a message to the remote server which } { echoes them back.
NetIPC Examples Example 3 end; {check} {----------------------INIT_desc-----------------------------------------} { Create call descriptor with dedicated protocol relative address } { Create destination desc to connect with the server } {------------------------------------------------------------------------} PROCEDURE init_desc ( var rc : rc_type); var j, prot_addr : shint; opt : opt_type; net_name, node_name : string [8]; net_name_len, node_name_len : shint; begin {----------------------------------} { C
NetIPC Examples Example 3 begin {------------------------------------} {Creation of the destination desc } {------------------------------------} writeln; prompt ('Enter the name of the node you want to check >> '); readln (node_name); node_name_len := strlen(node_name); prot_addr := c_prot_addr_server; IPCDest(3,node_name,node_name_len,2,prot_addr,2,,, p_dest_desc,result); if result <> 0 then begin check (result,i_dest); rc := no_dest_desc; end;{else dest} end;{else create} end;{else addopt} end;{else addo
NetIPC Examples Example 3 else begin writeln ('CALL CONF packet received ...'); writeln; end; {------------------------------------} { The connection is now opened.
NetIPC Examples Example 3 i := i+1; end;{else send} end;{while} p_transit_time := timer - chrono; end;{data transfer} {-------------------------SHUTDOWN-----------------------------------} { PURPOSE : Shutdown call, destination and vc descriptor } { according to the value of rc.
NetIPC Examples Example 3 BEGIN p_retry := false; repeat rc := done; INIT_DESC (RC); if rc = done then begin CONNECT (rc); if rc = done then begin DATA_TRANSFER (rc); end; end; SHUTDOWN; until p_retry = false; END. {} Program 3B (X25SERV) {******************************************************************} { } { SOURCE : X25SERV } { } { DESCRIPTION : } { } { The purpose of that program is to answer to a remote program } { X25CHECK which verifies that the connections have been actually } { established.
NetIPC Examples Example 3 IPCErrmsg (result,msg,msg_len,r); setstrlen(msg,msg_len); if r <> 0 then begin writeln('Can''t get the error message'); QUIT (123); end{if} else begin writeln('X25SERV: error occurred during initialization of the'); writeln(' server with the following identification:'); writeln (msg); QUIT (125); end;{else} end;{if} END;{check_init} PROCEDURE create_descriptor; var prot_addr : shint; opt : opt_type; net_name : name_type; net_name_len : shint; wrtdata : shint; begin {create_descript
NetIPC Examples Example 3 PROCEDURE echo; var opt calling_address i, option_code, addr_len, data_len buffer buffer_len begin {echo} : opt_type; : packed array [1..16] of nibble; : shint; : buffer_type; : integer; {------------------------------------} { Initialize an option field to get } { the calling node address. } {------------------------------------} Initopt (opt,1); Addopt (opt,0,c_calling_add_code,8,calling_address,r); {------------------------------------} { Wait for a connection request.
NetIPC Examples Example 3 {------------------------------------} { Echo the same buffer. } {------------------------------------} IPCSend (p_vc_desc,buffer,buffer_len,,,result); if result = 0 then i:=i+1; end;{if} end; {while} end; end;{echo } PROCEDURE shutdown_connection; var buffer : buffer_type; buffer_len : integer; begin {------------------------------------} { End of connection.
NetIPC Examples Example 4 Example 4 Example 4 is a pair of programs designated SNMIPC1 and SNMIPC2 using direct access to X.25 level 3. These programs can be compiled in native mode. The program comments describe which of the X.25 features are used in these sample programs. Program 4A (SNMIPC1) (************************************************************************) (* This program pair, SNMIPC1 and SNMIPC2, tests X25 features including:*) (* *) (* 1. Call User Data up to 128 bytes *) (* 2.
NetIPC Examples Example 4 CONST X25 CUD_MAX = = 2; 128; (* X25 protocol (* number bytes of CUD *) *) VAR sd_local: integer; (* local socket descriptor cd_local: integer; (* local connection descriptor optioncode: shortint; (* optioncode return from readopt optlen: integer; (* opt length dlen: integer; (* data length flag: packed array[1..4] of byte; (* flags parameter x25_flags: packed array[1..
NetIPC Examples Example 4 writeln ('initopt for ipccreate failed'); (* add the option for Catch_all Socket : bit 2 *) flag[1] := 32; (* flag : 01000000000000000000000000000000 *) flag[2] := 0; flag[3] := 0; flag[4] := 0; addopt ( opt, 0, 144, 4, flag, result16 ); if result16 <> 0 then writeln ('addopt for ipccreate catch-all failed'); (* add network name *) net_name := 'direct'; addopt ( opt, 1, 140, 6, net_name, result16 ); if result16 <> 0 then writeln ('addopt for ipccreate network name failed'); writeln
NetIPC Examples Example 4 if result16 <> 0 then writeln('addopt IPCRECVCN x25 flags failed', result16); (* set deferred flags for receive connection : bit 18 *) flag[1] := 0; (* flags : 00000000000000000100000000000000 *) flag[2] := 0; flag[3] := 32; flag[4] := 0; (* deferred *) writeln; writeln('***** IPCRECVCN deferred'); ipcrecvcn ( sd_local, cd_local, flag, opt, result ); if result <> 0 then writeln ('ipcrecvcn failed', result); (* check receive CUD *) optlen := CUD_MAX; readopt(opt,0,optioncode,optlen,
NetIPC Examples Example 4 writeln; (* check X25_flag : 000000010000000000000000000000000 *) optlen := 4; readopt(opt,3,optioncode,optlen,x25_flags,result16); if result16 <> 0 then writeln('readdata failed (X25_flags) ', result16:1); if (x25_flags[1] <> 1) and (x25_flags[2] <> 0) and (x25_flags[3] <> 0) and (x25_flags[4] <> 0) then writeln('error fast select flag should be set'); (************************ IPCCONTROL ***********************************) (* set pass parameter for IPCCONTROL *) initopt(wdata, 2
NetIPC Examples Example 4 begin if msg[i] <> (i mod 100) then writeln ('receive error data : #',i:1,' ',msg[i]); i := i + 1; end; (************************ IPCSEND *************************************) (* Now send a single vectored message to the local side *) data := 'ok last one.
NetIPC Examples Example 4 Program 4B (SNMIPC2) (************************************************************************} (* This program pair, SNMIPC1 and SNMIPC2, tests X25 features including:*) (* *) (* 1. Call User Data up to 128 bytes *) (* 2. fast select *) (* 3. special facilities *) (* 4. catch all socket *) (* 5. transfer of 2000 bytes packet *) (* 6. no address flag *) (* 7. deferred connection acceptance *) (* 8.
NetIPC Examples Example 4 dd: integer; (* destination descriptor *) dlen: integer; (* data length *) optlen: integer; (* opt length *) optioncode: shortint; (* option code *) flag : packed array[1..4] of byte; (* flag *) x25_flags: packed array [1..4] of byte; (*x25_flags parameter *) result: integer; (* back from IPC call *) result16: shortint; (* back from opt calls *) i: integer; (* loop counter for messages *) msg : packed array[1..
NetIPC Examples Example 4 net_name := 'direct'; (* add the option for NETWORK NAME *) addopt (opt, 0, 140, 6, net_name, result16); if result16 <> 0 then writeln('ipccreate addopt failed', result16); writeln; writeln('##### IPCCREATE '); ipccreate ( 3, X25, , opt, sd_remote, result ); if result <> 0 then writeln ('ipccreate of remote socket failed', result); (***************************** IPCDEST **********************************) (* Get the destination descriptor to the local socket from the remote *) (* s
NetIPC Examples Example 4 (* this sets the "no_address" flag; and allows to access 128 bytes of CUD *) (* with fast select *) x25_flags[1] := 0; (* X25_flags : 00000000000000001000000000000000 *) x25_flags[2] := 0; x25_flags[3] := 64; x25_flags[4] := 0; addopt(opt, 0, 144, 4, x25_flags, result16); if result16 <> 0 then writeln ('addopt for ipcconnect x25_flag failed',result16); (* add call_user_data_send *) for i := 1 to CUD_MAX do cud[i] := i; addopt(opt, 1, 2, CUD_MAX, cud, result16); if result16 <> 0 the
NetIPC Examples Example 4 optlen := 50; addopt(opt, 1, 145, optlen, sf,result16); if result16 <> 0 then writeln('addopt IPCRECV sf failed ', result16:1); writeln; writeln('##### IPCRECV '); ipcrecv ( cd_remote, , , ,opt, result ); if result <> 0 then writeln ('ipcrecv to complete connection failed ',result); (* check receive CUD *) optlen := CUD_MAX; readopt(opt, 0, optioncode, optlen,cud,result16); if result16 <> 0 then writeln('CUD readopt failed ', result16:1); if optlen <> CUD_MAX then writeln('CUD leng
NetIPC Examples Example 4 if dlen <> 12 then writeln('receive data length error (length = ',dlen:1,')') else begin expect := 'ok last one.
A IPC Interpreter (IPCINT) The IPC interpreter (IPCINT) is a software utility provided with the NS X.25/XL link product. IPCINT can be used as a learning tool for programmers and as a troubleshooting tool by network administrators. IPCINT executes NetIPC intrinsics one at a time in response to commands typed at the keyboard. IPCINT can only be used for X.25 direct access to level 3.
IPC Interpreter (IPCINT) Using IPCINT Using IPCINT To use IPCINT you must have an NS X.25 link up and running on a local HP 3000 node and on a remote node. In order to exercise the intrinsics between nodes, the remote node must be running either IPCINT or an X.25 direct access to level 3 server program. You must have NA or NM capability to run IPCINT. To use IPCINT you enter RUN IPCINT.NET.SYS at the MPE XL prompt. At the IPCINT prompt (>) you can enter a NetIPC intrinsic abbreviation or EX to exit.
IPC Interpreter (IPCINT) Comparison of IPCINT to Programmatic NetIPC Comparison of IPCINT to Programmatic NetIPC The following examples show the difference between programmatic access and IPCINT used to execute the IPCCREATE intrinsic. Example: Programmatic Access to X.25 For a program using direct access to X.25 level 3, a call to IPCCREATE can be specified as follows: IPCCREATE (3,2,,opt,calldesc,result) The value 3 for parameter socketkind specifies a call socket.
IPC Interpreter (IPCINT) Syntax of IPCINT Syntax of IPCINT The following paragraphs describe the syntax of IPCINT commands. This includes: • Abbreviations for the intrinsics. • Pseudovariables for socket descriptors. • Prompts for parameters. • Call user data field. Abbreviated Intrinsic Names The IPCINT program uses abbreviations for NetIPC intrinsics. Table A-1 shows the supported IPC intrinsics and the IPCINT abbreviations.
IPC Interpreter (IPCINT) Syntax of IPCINT Pseudovariables Three pseudovariables are used by IPCINT to store the most recently assigned socket descriptors as follows: Pseudovariable -------------C D V socket descriptor ----------------call destination virtual circuit The pseudovariable names can be overridden by the user. Prompts for Parameters When you enter the IPCINT abbreviation for the selected intrinsic, IPCINT prompts you for the required parameter values which you then enter from the keyboard.
IPC Interpreter (IPCINT) Sample IPCINT Session Sample IPCINT Session The following example describes the steps to create a call socket, send and receive data over a connection, and then close the socket using IPCINT on a local node. This sample session assumes a remote node is also using IPCINT. The remote node running IPCINT sends the local node a message as described in step 7. The steps below follow the SVC requestor processing example in Figure 1-10 in Chapter 1 , “NetIPC Fundamentals.
IPC Interpreter (IPCINT) Sample IPCINT Session Step 3 Execute the IPCDEST intrinsic by entering DEST at the prompt. You are prompted for the remote Node name (location) where the destination socket will be created. In this example, RAINBOW is used. If you leave the node name prompt blank, you will be prompted for the remote X.25 address expressed in hexadecimal. Enter a protocol relative address (protoaddr) in the decimal range 30767 to 32767 for the remote address. In this example, 31000 is used.
IPC Interpreter (IPCINT) Sample IPCINT Session In the example, the statement, “No address in CUD” refers to the fact that you requested full access to the CUD.
IPC Interpreter (IPCINT) Sample IPCINT Session bit set (opt code 144, bit 19 and bit 18) are defaulted to no (N). Data offset (opt code 8) defaults to none.
IPC Interpreter (IPCINT) Sample IPCINT Session (8) SHUT Descriptor (32 bit integer /C/D/V): V Reason code (16 bit integer): 100 Call User Data (128 chars) : -----> Executing : IPCSHUTDOWN Step 9 Exit from the IPCINT program by entering EX at the prompt.
B Cause and Diagnostic Codes Cause and diagnostic can be read from X.25 packets using NetIPC intrinsics. The following tables show possible cause and diagnostic codes generated by the X.25 XL system access product. These codes are a subset of the CCITT (1984 X.25 recommendation) specified values.
Cause and Diagnostic Codes Diagnostic Codes in X.25 Clear Packets Diagnostic Codes in X.25 Clear Packets The following lists the diagnostic codes (in decimal) sent and received in X.25 clear packets. You can include cause and diagnostic codes with the IPCCONTROL or IPCSHUTDOWN intrinsics that will be included in the clear packet sent by the X.25 protocol. This function is only available with SVCs.
Cause and Diagnostic Codes Diagnostic Codes From a Remote Host Diagnostic Codes From a Remote Host The following table lists diagnostic codes from a remote MPE XL system that could be received on the local system. Table B-2 X.25 Diagnostic Codes From a Remote Host Diagnostic Code Meaning/Cause 48 Inactivity timer expired. 65 Facility not allowed. 70 Incoming call barred.
Cause and Diagnostic Codes Diagnostic Codes From a Remote Host 184 Appendix B
C Error Messages This appendix includes the mapping of X.25 SOCKERRs to protocol module errors, and the complete table of possible NetIPC errors (SOCKERRs). In the IPCCHECK intrinsic, both socket errors (SOCKERRs) and the corresponding protocol module errors (pmerrs) are returned. The following SOCKERRs are mapped to pmerrs. Other SOCKERRs can be returned to NetIPC with a corresponding pmerr of zero (0).
Error Messages SOCKERR 106 MESSAGE: PMERR = 4 Intrinsic : IPCCREATE CAUSE: ADDRESS CURRENTLY IN USE BY ANOTHER SOCKET. — The requested protocol relative address is already used by another process through another IPCCREATE call. ACTION: Use another protocol relative address or wait for previous process to release its call socket. SOCKERR 107: MESSAGE: PMERR = 7 Intrinsic : IPCCREATE, IPCRECV, IPCSEND, IPCCONTROL, IPCRECVCN CAUSE: TRANSPORT IS GOING DOWN. — A NETCONTROL STOP command has been issued.
Error Messages SOCKERR 143 MESSAGE: PMERR = 14 Intrinsic : IPCCONNECT CAUSE: INVALID FACILITIES SET OPT RECORD ENTRY — The facility set passed as a parameter has not been found in the internal facility set table. ACTION: Use one of the facility sets defined in the configuration or add a new one. SOCKERR 146 MESSAGE: PMERR = 10 Intrinsic : IPCRECV CAUSE: RESET EVENT OCCURRED ON X.25 CONNECTION. — An unsolicited reset packet was received.
Error Messages NetIPC Errors NetIPC Errors This section includes NetIPC error messages (SOCKERRs) and the form for submitting a service request (SR). SOCKERRS NetIPC are (32-bit) integers that are returned in the result parameter of NetIPC intrinsics when the intrinsic execution fails. (A result of 0 indicates that the intrinsic succeeded.
Error Messages NetIPC Errors 7 MESSAGE: ERROR DETECTED IN flags PARAMETER. CAUSE: An unsupported bit in the flags parameter was set, or a nonprivileged user set a privileged bit. ACTION: Verify that the proper bits are specified in the flags parameter. Bit numbering is from left to right (0..31). 8 MESSAGE: INVALID OPTION IN THE opt RECORD. CAUSE: An unsupported option was specified in the opt record, or a nonprivileged user attempted to specify a privileged option.
Error Messages NetIPC Errors 16 MESSAGE: OUT OF PATH DESCRIPTORS OR PATH DESCRIPTOR EXTENSIONS. CAUSE: Transport’s Path Cache or Path Descriptor table is full. ACTION: Contact your operator to see if the table can be expanded. 18 MESSAGE: FORMAT OF THE opt RECORD IS INCORRECT. CAUSE: NetIPC was unable to parse the specified opt record. ACTION: Check your INITOPT and ADDOPT calls. 19 MESSAGE: ERROR DETECTED WITH MAXIMUM MESSAGE SIZE OPTION.
Error Messages NetIPC Errors 27 MESSAGE: REQUIRED PARAMETER NOT SPECIFIED. CAUSE: A required parameter was not supplied in an option variable intrinsic call. ACTION: Check your calling sequence. 28 MESSAGE: INVALID NAME LENGTH. CAUSE: Specified name length was too large or negative. ACTION: Check your name length parameter. Shorten the name if necessary. 29 MESSAGE: INVALID DESCRIPTOR. CAUSE: Specified descriptor is not a valid socket, connection, or destination descriptor.
Error Messages NetIPC Errors 35 MESSAGE: ATTEMPT TO EXCEED LIMIT OF NAMES PER SOCKET. CAUSE: A socket can have only four names; the caller attempted to give it a fifth. ACTION: Use no more than four names. 36 MESSAGE: TABLE OF NAMES IS FULL. CAUSE: Socket registry or give table is full. ACTION: Shut down unused sockets, call IPCNAMERASE on any sockets that no longer need to be looked up, or get given sockets. See “Submitting an SR” at the end of this appendix. 37 MESSAGE: NAME NOT FOUND.
Error Messages NetIPC Errors 44 MESSAGE: NO RESPONSE FROM REMOTE REGISTRY SERVER. CAUSE: No reply was received from the remote registry process. This is often due to the remote node not having initialized its transport. ACTION: Contact your operator. If unable to resolve the problem, see “Submitting an SR” at the end of this appendix. 46 MESSAGE: UNABLE TO INTERPRET RECEIVED PATH REPORT.
Error Messages NetIPC Errors 55 MESSAGE: EXCEEDED PROTOCOL MODULE'S SOCKET LIMIT. CAUSE: Protocol module being used cannot create any more sockets. ACTION: Contact your operator; the limit may be configurable. 57 MESSAGE: ATTEMPT TO EXCEED LIMIT OF NOWAIT SENDS OUTSTANDING. CAUSE: User tried to send data too many times in nowait mode without calling IOWAIT. ACTION: Call IOWAIT to complete a send. The limit is 7. 58 MESSAGE: ATTEMPT TO EXCEED LIMIT OF NOWAIT RECEIVES OUTSTANDING.
Error Messages NetIPC Errors 65 MESSAGE: CONNECTION ABORTED BY LOCAL PROTOCOL MODULE. CAUSE: Local protocol module encountered some error which caused it to abort the connection. ACTION: Call IPCSHUTDOWN to clean up your end of the connection. See “Submitting an SR” at the end of this appendix. 66 MESSAGE: INVALID CONNECTION DESCRIPTOR. CAUSE: Supplied value is not that of a valid VC socket (connection) descriptor. ACTION: Check the value being given. 67 MESSAGE: CONNECTION FAILURE DETECTED.
Error Messages NetIPC Errors 76 MESSAGE: INVALID TIMEOUT VALUE. CAUSE: Value specified for the timeout is negative. ACTION: Modify the value. 77 MESSAGE: INVALID WAIT/NOWAIT MODE. CAUSE: Mode of socket cannot be used. ACTION: Use IPCCONTROL to specify correct mode. 78 MESSAGE: TRACING NOT ENABLED CAUSE: Attempted to turn off trace when tracing was not on. ACTION: Remove the call. 79 MESSAGE: INVALID TRACE FILE NAME. CAUSE: Requested trace file name is not valid.
Error Messages NetIPC Errors ACTION: None, but no NetIPC or protocol module errors are available. 85 MESSAGE: INVALID SOCKET ERROR NUMBER. CAUSE: IPCERRMSG was called with an invalid NetIPC error code. ACTION: Check the value being passed. 86 MESSAGE: UNABLE TO OPEN ERROR CATALOG SOCKCAT.NET.SYS. CAUSE: The error message catalog does not exist, it is opened exclusively, or the caller does not have access rights to the file. ACTION: Notify your operator.
Error Messages NetIPC Errors ACTION: See “Submitting an SR” at the end of this appendix. 96 MESSAGE: INTERNAL BUFFER MANAGER ERROR. CAUSE: Attempted use of the buffer manager by NetIPC or the protocol module resulted in an error. ACTION: See “Submitting an SR” at the end of this appendix. 98 MESSAGE: INVALID DATA SEGMENT INDEX IN VECTORED DATA. CAUSE: Data segment index value in the vectored data array is not valid. ACTION: Check the value being supplied.
Error Messages NetIPC Errors ACTION: See “Submitting an SR” at the end of this appendix. 106 MESSAGE: ADDRESS CURRENTLY IN USE BY ANOTHER SOCKET. CAUSE: Address being specified for use is already being used. ACTION: If you are a privileged user trying to specify a well known address, try again later. If you are nonprivileged, then see “Submitting an SR”. 107 MESSAGE: TRANSPORT IS GOING DOWN. CAUSE: The transport is being shut down. ACTION: Call IPCSHUTDOWN on all sockets and destination descriptors.
Error Messages NetIPC Errors 114 MESSAGE: CREATION OF SOCKET REGISTRY PROCESS FAILED. CAUSE: Socket registry program missing. ACTION: Contact your HP representative for assistance. 116 MESSAGE: DESTINATION UNREACHABLE. CAUSE: The transport was unable to route the packet to the destination. ACTION: Notify your operator. 117 MESSAGE: ATTEMPT TO ESTABLISH CONNECTION FAILED. CAUSE: Protocol module was unable to set up the requested connection.
Error Messages NetIPC Errors ACTION: Remove the cause by making the number positive or smaller in value. 127 MESSAGE: UNABLE TO READ ENTRY FROM OPT RECORD. CAUSE: The option record indicates that the entry is not valid or the buffer supplied by the user was too small to hold all of the data. ACTION: Check entry number, make sure the option record has not been written over and check output buffer length. 131 MESSAGE: PROTOCOL MODULE DOES NOT HAVE SUFFICIENT RESOURCES.
Error Messages NetIPC Errors 151 MESSAGE: COULD NOT OBTAIN A SEMAPHORE. CAUSE: The attempt to obtain a semaphore before sending a message to the protocol module failed. ACTION: See “Submitting an SR” at the end of this appendix. 153 MESSAGE: SOCKET IS ALREADY IN USE. CAUSE: A single socket per network interface can be created with the catch-all capability. ACTION: Wait for catch-all socket to be released. 155 MESSAGE: INVALID X.25 FLAGS OPT RECORD ENTRY.
Error Messages NetIPC Errors 165 MESSAGE: INVALID ADDRESS LENGTH. CAUSE: An invalid address length was specified in the opt parameter. ACTION: The address length is 2 bytes (for non-privileged users). 166 MESSAGE: CONNECTION NOT IN VIRTUAL CIRCUIT WAIT CONFIRM STATE. CAUSE: Attempt was made to accept or reject a connection that is open or in the process of closing. ACTION: Use flags parameter in IPCRECVCN to defer acceptance or rejection of the connection request.
Error Messages Submitting an SR Submitting an SR For further assistance from Hewlett-Packard, document the problem as an SR (Service Request) and forward it to your Hewlett-Packard Service Representative. Include the following information where applicable: • A characterization of the problem. Describe the events leading up to and including the problem. Attempt to describe the source of the problem. Describe the symptoms of the problem and what led up to the problem.
Error Messages Submitting an SR — The HP 36923 Central Bus Programmable Serial Interface Installation and Reference Guide for the Point-to-Point link. • Issue the LINKCONTROL linkname; STATUS= for each link. Retain the output for your Hewlett-Packard representative to further analyze. • Document your interim, or “workaround” solution. The cause of the problem can sometimes be found by comparing the circumstances in which it occurs with the circumstances in which it does not occur.
Error Messages Submitting an SR 206 Appendix C
D Migration From PTOP to NetIPC and RPM The PTOP (Program-to-Program communication) service is available on DS/3000 and NS 3000/V. It is a master-slave protocol wherein a master process creates a slave process on a remote node, the master sends data-exchange requests to the slave, and the slave accepts or rejects the master requests. The NetIPC (Network InterProcess Communication) and RPM (Remote Process Management) services are available on NS 3000/V and NS 3000/XL.
Migration From PTOP to NetIPC and RPM Creating Remote Processes Creating Remote Processes With PTOP, the creation of the slave process and the set up of the communications channel is done by the POPEN call in the master and the first GET and ACCEPT (or REJECT) calls in the slave. The POPEN call specifies the remote node’s location, the name of the program on the remote node to be created, and various process-creation parameters.
Migration From PTOP to NetIPC and RPM Creating Remote Processes 20000) for the socket name and the local node name. (These will be used by the slave program to set up the virtual circuit connection.
Migration From PTOP to NetIPC and RPM Creating Remote Processes Creating Remote Processes: In the Slave Program To convert the PTOP intrinsic listed below, perform the following steps. Syntax ifun := GET [([itag][il][,ionumber] • Call RPMGETSTRING twice to get the master’s socket name and node name. • Create a TCP call socket by using the IPCCREATE intrinsic. • Call IPCLOOKUP to look up the master’s socket, using the master socket name and node name passed in the RPM strings.
Migration From PTOP to NetIPC and RPM Exchanging Data Exchanging Data The PTOP data-exchange calls are master-slave. The master initiates an exchange by calling PWRITE (to send data to the slave), PREAD (to receive data from the slave) or PCONTROL. The slave calls GET to receive the request and ACCEPT to perform the actual data movement into or out of its buffer. Each of these operations may also exchange a tag between the master and the slave.
Migration From PTOP to NetIPC and RPM Exchanging Data Exchanging Data: In the Master Program To convert the PTOP intrinsic listed below, perform the following steps. lgth := PREAD (dsnum,target,tcount[,itag] • If the slave requires a master function, send the PREAD request function (=2) on the virtual circuit to the slave. • If the slave requires the requested data length, send tcount on the virtual circuit. • If a tag is specified, send the master tag on the virtual circuit.
Migration From PTOP to NetIPC and RPM Exchanging Data Syntax PWRITE(dsnum,target,tcount[,itag] • If the slave requires a master function, send the PWRITE request function (=3) on the virtual circuit to the slave. • If the slave requires the requested data length, send tcount on the virtual circuit. • If a tag is specified, send the master tag on the virtual circuit.
Migration From PTOP to NetIPC and RPM Exchanging Data Syntax ifun := GET [([itag][,il][,ionumber] • If the slave requires a master function, receive a one byte master function number from the virtual circuit from the master. • If the slave requires the request length, receive the length from the virtual circuit. • If a tag is specified, receive the master tag from the virtual circuit. To convert the PTOP intrinsic listed below, perform the following steps.
Migration From PTOP to NetIPC and RPM Terminating Processes Terminating Processes The final phase is the termination of the slave process, and the shutting down of the communications channel between the master and the slave. With PTOP, both of these functions are performed by the PCLOSE intrinsic. With NetIPC and RPM, the process termination is done by RPMKILL, while the channel is shut down by IPCSHUTDOWN. In both PTOP and NetIPC/RPM, clean up on the slave is done automatically upon its termination.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application Example: Client-Server Application The following sets of programs illustrate the principles for converting a PTOP application to use NetIPC and RPM. The sample application is a simple name server, where you run a client program that creates a server on the node that contains a data file. The client program sends names to the server. The server looks up the names in the data file and returns associated information to the client.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application PCLIENT: Sample PTOP Master Program $standard_level 'HP3000', uslinit$ program pclient( input, output ); {-------------------------------------------------------------------} { } { PCLIENT: Sample PTOP Master Program } { } {-------------------------------------------------------------------} { } { PURPOSE: } { The PCLIENT and PSERVER programs illustrate the use of the PTOP } { service to implement a simple name server application.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application label 1; {for error exit } const maxnodelength = 51; {all lengths in bytes} maxproglength = 24; namelength = 20; infolength = 60; ccg = 0; {condition codes } ccl = 1; cce = 2; type shortint = -32768..32767; msgtype = packed array[1..30] of char; var location: packed array [1..maxnodelength] of progname: packed array [1..maxproglength] of name: packed array [1..namelength ] of info: packed array [1..
Migration From PTOP to NetIPC and RPM Example: Client-Server Application readln( name ); if name <> 'EOT' then begin PWRITE( dsnum, name, -namelength ); if ccode <> cce then ERROR( 'PWRITE to server failed.', PCHECK(dsnum) ); length := PREAD( dsnum, info, -infolength ); if ccode = cce then {ACCEPT} writeln('Client data is: ', info ) else if ccode = ccg then {REJECT} writeln('Client data could not be found.') else {ccode = ccl} ERROR( 'PREAD from server failed.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application PSERVER: Sample PTOP Slave Program Standard_level 'HP3000', uslinit$ program pserver( input, output } {-------------------------------------------------------------------} { } { PURPOSE: } { The PCLIENT and PSERVER programs illustrate the use of the PTOP} { service for a simple name server application. See the PCLIENT } { program for details.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application begin filename := 'DATAFILE '; reset( datafile, filename ); found := false; while not found and not eof(datafile) do begin readln( datafile, name, info ); if name = reqname then found := true end; end; {FIND_NAME} begin {-------------------------------------------------------------} { Each pass of this loop GETs one master request and ACCEPTs } { or REJECTs the request, based on the type of request.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application begin {----------------------------------------------------} { ACCEPT the name from the PWRITE. This name will } { be used in the case for the following PREAD. } {----------------------------------------------------} ACCEPT( , name ); if ccode <> cce then ERROR( 'ACCEPT for PWRITE failed', PCHECK(0) ); end; end; until false; 1:{error exit} end.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application RCLIENT: Sample NetIPC/RPM Master Program $standard_level 'HP3000', uslinit$ program rclient( input, output ); {---------------------------------------------------------------------} { } { RCLIENT: Sample NetIPC/RPM Master Program } { } {---------------------------------------------------------------------} { } { PURPOSE: } { The RCLIENT and RSERVER programs illustrate the use of the RPM } { and NetIPC services to implement a simple n
Migration From PTOP to NetIPC and RPM Example: Client-Server Application { RPMCREATE RSERVER on server } { node ----------------------> RPMGETSTRING clientsock } { IPCRECVCN socket 1 RPMGETSTRING clientnode } { . IPCCREATE socket 2 } { . IPCLOOKUP clientsock, } { . clientnode, } { . dest } { . <-----------------------IPCCONNECT socket 2, dest } { . ----------------------> IPCRECV } { IPCNAMERASE clientsock IPCSHUTDOWN socket 2 } { IPCSHUTDOWN socket 1 IPCRECV name } { get name .
Migration From PTOP to NetIPC and RPM Example: Client-Server Application info: opt: rpmflags: progdesc: buf: clientnodelength: loclength: prognamelength: socketdesc: vcdesc: status: result: envnum: i: procedure procedure procedure procedure procedure procedure procedure procedure procedure procedure procedure procedure procedure packed array packed array packed array array [1..
Migration From PTOP to NetIPC and RPM Example: Client-Server Application {----------------------------------------------------------------} { RECV receives a specified number of bytes from the virtual } { circuit (vc) connection. This compensates for the stream mode } { operation of NetIPC on the HP 3000, where an IPCRECV can return} { less than the requested number of bytes. The loop in RECV } { calls IPCRECV to receive the next chunk of data, until the } { requested amount of data has been received.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application loclength := 0; while location[loclength+1] <> ' ' do loclength := loclength + 1; progname := 'RSERVER'; prognamelength := 7; {-------------------------------------------------------------} { Set the dependent flag for the RPMCREATE. This causes the } { the server to terminate if the client terminates, or if the } { connection between them fails.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application IPCSEND( vcdesc, name, namelength, , , result ); if result 0 then ERROR( 'Send to server failed.', result ); RECV( vcdesc, buf, 1, result ); if result <> 0 then ERROR( 'Receive from server failed.', result ); if ord(buf[1]) = indaccept then begin RECV( vcdesc, buf, infolength, result ); if result <> 0 then ERROR( 'Receive from server failed.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application RSERVER: Sample NetIPC/RPM Slave Program $standard_level 'HP3000', uslinit$ program rserver( input, output ); {-------------------------------------------------------------------} { } { RSERVER: Sample NetIPC/RPM Slave Program } { } {-------------------------------------------------------------------} { } { PURPOSE: } { The RCLIENT and RSERVER programs illustrate the use of the NetIPC } { and RPM services to implement a simple name se
Migration From PTOP to NetIPC and RPM Example: Client-Server Application {----------------------------------------------------------------} { ERROR prints an error message and an associated NetIPC or RPM } { result code. It terminates the program by going to the error } { exit. Any NetIPC objects (sockets or virtual circuits) will } { be deleted upon termination.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application begin filename := 'DATAFILE '; reset( datafile, filename ); found := false; while not found and not eof(datafile) do begin readln( datafile, name, info ); if name = reqname then found := true end; end; {FIND_NAME} begin {-------------------------------------------------------------} { Retrieve the client's socket name and node name, passed as } { RPM strings.
Migration From PTOP to NetIPC and RPM Example: Client-Server Application if result <> 0 then ERROR( 'Couldn't shut down dest.', result ); {-------------------------------------------------------------} { Each pass of this loop receives one name from the client, } { and looks up the name. If the name is found, an accept } { indication is sent back to the client, followed by the name } { information. If the name is not found, a reject indication } { is returned to the client.
E C Program Language Considerations This appendix contains programming language differences that affect how NetIPC intrinsics are used in programs written in C programming language.
C Program Language Considerations C Program Language Differences C Program Language Differences Parameters The data (char^) data in IPCSEND and IPCRECV in C programs to designate a long pointer.
Glossary A address A numerical identifier defined and used by a particular protocol and associated software to distinguish one node from another. address key address resolution address resolution In NS networks, the mapping of node names to IP addresses and the mapping of IP addresses to subnet addresses. ASCII American National Standard Code for Information Interchange. A character set using 7-bit code used for information interchange among data processing and data communications systems.
CCITT Consultative Committee for International Telephony and Telegraphy. An international organization of communication carriers, especially government telephone monopolies, responsible for developing telecommunication standards by making recommendations. The emphasis is on “recommendations”; no carrier is required to adhere to a CCITT recommendation, although most do so in their own interests. receiving it. The resulting overflow data is lost. See also flow control. closed user group An X.
DTC/X.25 Network Access The software that resides on the Datacommunications and Terminal Controller (DTC). To configure access to an X.25 network, you must configure two software components, the X.25 XL System Access (residing on the HP 3000 host and configured through use of NMMGR software) and the DTC/X.25 Network Access (configured on the OpenView Windows Workstation through use of the OpenView DTC Manager software).
facility set A facility set defines the various X.25 connection parameters and X.25 facilities that can be negotiated for each virtual circuit on a per-call basis. fast select An optional packet-switching network facility by which user data may be transmitted as part of the control packets that establish and clear a virtual connection. FCS Frame Check Sequence. A sequence of bits generated by X.25 at Level 2 that forms part of the frame and guarantees the integrity of its frame's content.
H host-based network management Method of managing asynchronous communications for HP 3000 Series 900 computers. All of the control software is configured on a single MPE XL host and is downloaded to the DTCs that are managed by that host. With host-based management, there is a permanent relationship between each DTC and the host, and terminal users can access only the single MPE XL system that owns the DTC their terminal is connected to. host computer The primary or controlling computer on a network.
network portion of the IP address identifies a network, and the node portion identifies a node within the network. ISO International Organization of Standards. An international federation of national standards organizations involved in developing international standards, including communication standards. L LANIC See Local Area Network Interface Controller. LANIC Self-Test A ROM-based program on a LANIC card that tests and reports the status of the LANIC hardware. LAP-B Link Access Protocol Balanced.
M M bit More data bit. Setting this bit in a DATA packet indicates that at least one more DATA packet is required to complete a message of contiguous data. modulo Value used as the counting cycle for determining the send sequence number (N(S)) of frames sent across an X.25 network. MPE XL MultiProgramming Executive XL. The operating system of the HP 3000 Series 900 computers. The NS3000/XL network services operate in conjunction with the MPE XL operating system. multiplexer MUX.
information among nodes in the network. The HP 3000/XL Network Services include RPM, VT, RFA, RDBA, and NFT. network subscribed facilities A set of parameters that the user chooses when he subscribes to the X.25 network; they include Flow Control Negotiation, Use of D-bit, Throughput Class Negotiation and Extended Packet Sequence Numbering. NFT Network File Transfer. The network service that transfers disc files between nodes on a network. NI See network interface. NMCONFIG.PUB.
NS 3000/XL A Hewlett-Packard data communication product that provides networking capabilities for MPE XL based HP 3000 minicomputers. NS 3000/XL consists of a link and network services. NS 3000/XL Link Software and hardware that provides the connection between nodes on a network. Some of the NS 3000/XL links available are the ThinLAN 3000/XL Link and its ThickLAN option, the DTC/X.25 XL Network Link, the NS Point-to-Point 3000/XL Link, and the StarLAN 10 3000/XL link.
PAD profile Terminal or printer profile that specifies the configuration characteristics for PAD-connected devices. PDN Public data network. A data communication network whose services are available to any user willing to pay for them. Most PDNs use packet switching techniques. port An outlet through which a device can be connected to a computer, consisting of a physical connection point and controlling hardware, controlling software, and configurable port characteristics.
PVC Permanent Virtual Circuit. A permanent logical association between two physically separate DTEs that does not require call set-up or clearing procedures. PXP See Packet Exchange Protocol. the frame. When choosing this value, factors like the line speed and maximum frame size should be taken into account. RFA Remote File Access. A network service that allows users to access file and devices on remote nodes. Q Q bit Qualified bit.
transmitter. As a result, fast transmission speeds (above 9600 bps) are attainable. Retransmission Timer (T1) so that there is no doubt about the link's state. system configuration The way you tell MPE XL what peripheral I/O devices are attached to the DTC and what parameters are required for system operation. topology The physical arrangement of nodes in a network. Some common topologies are bus, star, and ring.
U unacknowledged frame number (K) The number of frames that can be transmitted without receiving an acknowledgment from the destination address. When this number (K) frame is reached, the same K frames are retransmitted. Virtual Terminal A network service that allows a user to establish interactive sessions on a node. VPLUS Software used to generate screens such as those displayed by NMMGR. unedited mode See transparent mode. V-Series (V.
X.25 address The X.25 address provided by the network administration if you are connected to a Public Data Network (PDN). X.25 address key An X.25 address key is a label that maps a node's IP address to its X.25 address and its associated X.25 parameters. You have a combined maximum of 1024 X.25 address keys in the SVC and PVC path tables. X.25 LUG address X.25 address of a node belonging to a LUG. X.25 XL System Access he software that works in conjunction with the DTC/X.
Index A ADDOPT, 66 asynchronous I/O, 126 cross system, 48 programming with, 127 B blocking calls enable in IPCCONTROL, 76 C call data in IPCRECVCN, 109 call socket, 18 creating, 23 descriptors, 20 looking up a name, 24 naming, 23 call user data, 38 in IPCCONNECT, 71 in IPCCONTROL, 77, 78 in IPCSHUTDOWN, 119 no address flag, IPCCONNECT, 72 protocol relative address, 38 call user data flag in IPCRECV, 101 calldesc, 23 calling node address flag in IPCRECVCN, 110 in IPCRECVCN, 109 catch-all socket, 39 in IPCCR
Index E end-to-end achnowledgement in IPCSEND, 116 end-to-end acknowledgement, 101 establishing a connection using IPCDEST, 28 using IPCNAME, 27 example compatibility mode, 139 native mode, 139 TCP, 132, 139 using NetIPC, 131 vectored I/O CM and NM, 139 X.25, 148, 159 exchanging data TCP, 30 X.
Index inIPCRECV, 100 nowait I/O enable in IPCCONTROL, 76 nowait receives enable in IPCCONTROL, 79 nowait sends disable in IPCCONTROL, 79 enable in IPCCONTROL, 79 O opt parameter, 60 option entry structure, 60 structure, 60 option entry structure, 60 option variable, 58 OPTOVERHEAD, 60, 123 P packets types returned in IPCCONTROL, 78 PAD flag in IPCRECVCN, 109 PC NetIPC Program Startup cross-system, 56 permanent virtual circuit, 37 preview data flag in IPCRECV, 100 Privileged Mode, 19 Program Startup, 55 PC,
Index Transmission Control Protocol TCP, 18 Transport Layer, 18 U urgent data in IPCRECV, 101 in IPCSEND, 116 V VC socket, 18 descriptors, 20 vcdesc, 20 vectored data, 62 in IPCSEND, 115 vectored data flag in IPCRECV, 100 virtual circuit, 18 establishing a connection, 22 W well-known name, 23 X X.
