Using NS 3000/iX Network Services HP 3000 MPE/iX Computer Systems Edition 4 Customer Order Number 36920-61000 36920-90008 E0594 Printed in: 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. Introduction to NS 3000/iX Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NS Node Name Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARPA Domain Name Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example RFA Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Terminal Access: VT vs. RFA. . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 DSCOPYMSG intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 6 RPMGETSTRING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RPMKILL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Configuring for Command Broadcast . . . . . . . . . . . . . . . . . . . . . . . Sample LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NEWLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . .
Contents Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LET Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures Figure 1-1 . OSI Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Figure 1-2 . Opening Several Remote NS 3000/iX Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Figure 2-1 . Virtual Terminal Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Figure 5-1 . Three-Node Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables Table 5-1. Conflicting DSCOPY Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Table 5-2. DSCOPY Options Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Table 6-1. NSINFO Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Table 6-2. NSINFO Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface This document is for persons wishing to program or interactively use NS 3000/iX network services. The network services (NS) enable HP 3000 systems and other NS-compatible systems to communicate with each other and share resources. Audience This manual is intended for interactive users as well as programmers. In order for you to use NS 3000/iX, you should be familiar with some of the more common MPE/iX commands and intrinsics.
Note to HP 9000 users: beginning with HP-UX release 10.0, DSCOPY and NetIPC are no longer supported on HP-UX.
1 Introduction to NS 3000/iX NS 3000/iX is the name of Hewlett-Packard’s software services for linking multi-vendor computer equipment including MPE/iX based HP 3000 processors. The Network Services (NS) run in conjunction with Hewlett-Packard link products that consist of both hardware and software.
Introduction to NS 3000/iX Network Architecture Network Architecture A network architecture specifies the transmission tasks of distinct hardware and software modules or layers. The architecture of NS 3000/iX is based on the seven-layer OSI (Open Systems Interconnection) model (Figure 1-1) developed by the International Standards Organization (ISO). One of the purposes of having a layered architecture is to make the complexities of data communications transparent to the high-level user.
Introduction to NS 3000/iX Network Architecture When a message is sent from one node to another in a network, it is first passed down through the architectural levels at the source node. That is, it is transferred from the control of one protocol entity to the control of the next. At one of the middle layers, the message is broken down into packets. At the lowest layer, the packets are sent across the physical communications link.
Introduction to NS 3000/iX Network Services Network Services NS 3000/iX is the name of Hewlett-Packard’s interactive and programmatic user-level, network services. All of these services are listed below and are fully documented in this manual: • Virtual Terminal (VT) creates an interactive session for you on another system in the network, making your terminal appear as though it were directly connected to the other system.
Introduction to NS 3000/iX Network Names Network Names When each computer system is configured as part of an NS 3000/iX network, it is assigned a unique node name. You use this node name to log on to each computer system. Node names can be in either NS node name syntax or ARPA domain name syntax as explained in the following sections. For people using NS node name syntax, the NS names work the same as in the versions prior to MPE/iX 4.0.
Introduction to NS 3000/iX Network Names You can find full details on node names, environment IDs, and remote file designations in the chapters on “Virtual Terminal” and “Remote File Access” in this manual. For convenient reference, the syntax for node names and environment IDs is given here. node[.domain[.organization]] envname[.domain[.
2 Virtual Terminal In order to issue interactive commands to a remote operating system or to a subsystem available on a remote computer, you must establish a session on the remote node. The Virtual Terminal service (VT) makes the fact that the session is remote almost entirely transparent. You enter commands and receive system/subsystem responses at your local terminal just as if your session were local.
Virtual Terminal Figure 2-1 Virtual Terminal Service In addition to your local session, you can also create multiple remote sessions on your own local node or on remote nodes. Optionally, you can configure your own remote prompts, so that you can identify each remote environment by its prompt. In order to create a remote session, you can use either REMOTE :nodename followed by a logon, or, you can use DSLINE nodename followed by a REMOTE HELLO user.acct.
Virtual Terminal DSLINE Command DSLINE Command Defines the attributes of a remote environment. Syntax DSLINE [envID ] [[envID=]nodename][;SERVICES][;DSLINE option]... [#Lenvnum ] Use Available In Session? Yes In Job? Yes In Break? Yes Programmatically? Yes Breakable? No Capabilities? None Parameters envID An environment ID—that is, a character string representing a specific session on a remote node. For NS names, the environment ID itself may optionally be qualified as follows: envname[.
Virtual Terminal DSLINE Command unless overridden in a later DSLINE command. These defaults can be reset by the RESET option, which is described below. Default: the specified nodename (which then becomes an environment ID) or, if nodename is omitted as well, the environment specified by the last DSLINE or REMOTE command. nodename When you are using NS names, the nodename is the name assigned to the remote node when it is configured into the NS 3000/iX network.
Virtual Terminal DSLINE Command COMP or NOCOMP (default is NOCOMP) Enables or disables data compression to the remote environment. The compression only affects NFT and RFA transmissions. If data compression is in effect, sequences of repeated characters (such as blanks) are translated into more compact form before transfer. They are decompressed after arrival at their destination. For a discussion of RFA compression, refer to “RFA Compression” in Chapter 3, “Remote File Access.
Virtual Terminal DSLINE Command prompt will return to the one you set with SETVAR HPPROMPT. For an example, refer to the discussion under the REMOTE command. LOGON= logonsequence TRACE= traceoptions Specifies a logon sequence for the remote system, which can be used by NFT and RPM in order to create a temporary session on the remote node. (See the NFT and RPM chapters of this manual for a discussion of when this logon will take effect.) The logon sequence must include all necessary passwords.
Virtual Terminal DSLINE Command For further information on tracing, see the NS 3000/iX Operations and Maintenance Reference Manual. NOTE The following dslineoptions are obsolete and are ignored in all cases (if used, a warning message is printed): EXCLUSIVE, FROMADDR=, FROMADR=, LINEBUF=, LOCID=, NOQUEUE, OPEN, PHNUM=, QUEUE, REMID, SELECT=, TOADDR=, and TOADR=. Description The DSLINE command defines the attributes of a remote environment.
Virtual Terminal DSLINE Command Pattern Before Rel 4.0 After Rel 4.0 @ Selects all EnvIDs with default domain & organization. Select all NS EnvIDs with default domain and organization and all ARPA domain EnvIDs. @.@ Selects all EnvIDs with default organization. Select all NS EnvIDs with default organization and all the ARPA domain EnvIDs with at least one “.”. @.@.@ Select all EnvIDs Select all NS EnvIDs and all the ARPA domain EnvIDs with at least two “.”. @.@.@.
Virtual Terminal DSLINE Command ENVIRONMENT 2: SYS4.DETROIT.MYCO=SYS4.DETROIT.MYCO ENVIRONMENT 5: X1.DETROIT.MYCO=SYS4.DETROIT.MYCO ENVIRONMENT 7: ROBERT=ROBERT.CUP.MYCO.COM ENVIRONMENT 9: X2=ROBERT.CUP.MYCO.COM ENVIRONMENT 11: BOB=BOB(ROBERT.CUP.MYCO.COM) ENVIRONMENT 13: X3=BOB(ROBERT.CUP.MYCO.COM GENERIC ENVIRONMENT X@ :DSLINE @.@.@ **lists all NS environments and ARPA domain environments with at least two “.” ** ENVIRONMENT 2: SYS4.DETROIT.MYCO=SYS4.DETROIT.MYCO ENVIRONMENT 5: X1.DETROIT.MYCO=SYS4.
Virtual Terminal DSLINE Command :DSLINE @.@.@ **lists all the NS environments and ARPA domain EnvIDs with at least two “.”s ** ENVIRONMENT 2: BOB.TEST.TEST=BOB(ROBERT.CUP.MYCO.COM) ENVIRONMENT 15: SYS3.CHICAGO.MYCO=SYS3.CHICAGO.MYCO GENERIC ENVIRONMENT X@ :DSLINE @.@.@;CLOSE **closes all the NS envs and ARPA domain EnvIDs with at least two “.”s. ** ENVIRONMENT 2: BOB.TEST.TEST=BOB(ROBERT.CUP.MYCO.COM) ENVIRONMENT 15: SYS3.CHICAGO.MYCO=SYS3.CHICAGO.
Virtual Terminal REMOTE HELLO Command REMOTE HELLO Command Creates a session on a remote node. Syntax DSLINE [:envID ] [ {envID }] [:[envID=]nodename][ logon [;DSLINE={[envID=}nodename}] [envnum ] [ {#Lenvnum }] Use Available In Session? Yes In Job? Yes In Break? Yes Programmatically? Yes Breakable? No Capabilities? None Parameters envID An environment ID—that is, a character string representing a specific session on a remote node.
Virtual Terminal REMOTE HELLO Command assumed. The default environment for a REMOTE command is the one most recently referenced in a DSLINE or REMOTE command. nodename When you are using NS names, the nodename is the name assigned to the remote node when it is configured into the NS 3000/iX network. This name may optionally be qualified in the format node[.domain[.organization]]. The default domain and organization are those of the local node.
Virtual Terminal REMOTE HELLO Command may be given immediately after the REMOTE or after DSLINE=. If the environment information is given in both places, the specification following REMOTE takes precedence. If no environment information appears in either place, the default environment assumed is the one most recently referenced by a REMOTE or DSLINE command.
Virtual Terminal REMOTE HELLO Command :REMOTE:CHEKHOV HELLO ANTON.PLAYS HP3000 / MPE/iX A.01.00 FRI, MAY 1, 1994, 4:26 PM ENVIRONMENT 3: CHEKHOV.DCL.DETROIT :REMOTE **allows use of environment** 4. The REMOTE HELLO command may be issued in two parts, with the HELLO portion following the remote prompt which is returned. The environment specification may appear in a previous DSLINE command, as in method 1, or immediately after the REMOTE, as in method 3.
Virtual Terminal Releasing a Remote Environment Releasing a Remote Environment The method that you use to release a remote environment depends upon the way it was initially created: 1. If the environment was defined by a DSLINE command, it can be released only by a corresponding DSLINE;CLOSE command. 2. If the environment was defined in a REMOTE HELLO command, it can be released by either a REMOTE BYE command or a DSLINE;CLOSE command. 3.
Virtual Terminal Releasing a Remote Environment DSLINE MODELT REMOTE HELLO HENRY.FORD DSLINE;CLOSE ABORT THE REMOTE SESSION ON MODELT.DCL.DETROIT?YES SESSION ABORTED BY SYSTEM MANAGEMENT Method 2 REMOTE HELLO MARIE.SYS5;DSLINE=RADIUM REMOTE BYE or REMOTE:RADIUM HELLO MARIE.SYS5 REMOTE BYE Method 3 :DSLINE MODELA :REMOTE HELLO HENRY.FORD :BYE **implicit :DSLINE;CLOSE executed** or :REMOTE HELLO HENRY.FORD;DSLINE=MODELA :BYE or :REMOTE:MODELA HELLO HENRY.
Virtual Terminal REMOTE Command REMOTE Command Allows commands to be executed in a remote environment. Syntax REMOTE [:[envID][command ] [envnum] Use Available In Session? Yes In Job? Yes In Break? Yes Programmatically? Yes Breakable? No Capabilities? None Parameters envID The environment ID representing an established session on the remote node. This environment ID may be an actual node name.
Virtual Terminal REMOTE Command If a command parameter is included in the REMOTE command line, the remote operating system executes it and restores control to the local operating system. The local prompt reappears on your terminal screen. For example, at the MPE/iX prompt (which is shown for clarity), type the following command (user input is bold): :REMOTE LISTF **default environment** . .**list of file names from .
Virtual Terminal Using DSLINE and REMOTE Within Programs Using DSLINE and REMOTE Within Programs Both the DSLINE and REMOTE commands can be executed within a program using the COMMAND intrinsic. You can set up environment attributes, log on remote sessions, and issue remote commands from within a program. For the format of the COMMAND intrinsic, refer to the MPE/iX Intrinsics Reference Manual. NS 3000/iX maintains separate default environments for each process within a job or session.
Virtual Terminal Using DSLINE and REMOTE Within Programs of execution of the processes. Also, if one process is already executing a REMOTE command to a remote session, a REMOTE command to the same remote session from another process will fail. Concurrent execution of REMOTE commands by multiple processes within the same job or session is not supported. This applies whether the processes are communicating with the same or different remote sessions.
Virtual Terminal Reverse Virtual Terminal Reverse Virtual Terminal The Reverse Virtual Terminal (Reverse VT) service allows an application program to receive information from and send information to terminals located on other systems. All the systems involved must be connected via NS 3000 connections (either NS 3000/V or NS 3000/iX). The Reverse VT service must be initiated from the system on which the application resides.
Virtual Terminal Reverse Virtual Terminal Because the VTERM option is specified, the application program communicates with the remote terminal by way of the Virtual Terminal rather than by way of Remote File Access. In both VT and RFA, the remote terminals function as non-session I/O devices. With RFA, you have to create a remote session on the node where the terminal resides.
Virtual Terminal Using the Remote Subsystem from a Batch Job Using the Remote Subsystem from a Batch Job While in a batch job, you can establish a remote session by using the DSLINE or REMOTE HELLO command. The job streamed may be similar to the following (local and remote prompts are shown for clarity): JOB USER.ACCOUNT :DSLINE REMOTE2 :REMOTE HELLO RUSER.
Virtual Terminal BREAK BREAK Pressing [BREAK] while a remote command is being executed suspends execution of the command and returns control to the environment from which you issued the command. For example, if you enter a command from a remote prompt, and then press [BREAK], the system will return your remote prompt. When an application program is suspended by [BREAK], the system will return the prompt that was last issued before the program was run.
3 Remote File Access The Remote File Access service (RFA) allows you to access remote files and devices. By using RFA you can, among other things, create, open, read, write, and close a file that resides on a remote HP 3000. Since the remote “file” may be a peripheral device, you can, for example, read from a tape mounted on a remote system or print local data on a remote printer.The Remote File Access facility uses the same MPE/iX file system intrinsics as are employed on a local system.
Remote File Access RFA Compression RFA Compression Remote File Access (RFA) allows for data compression. RFA data compression can provide faster data transfer, especially over a slow link and when the file being remotely accessed has large records with repeated characters.To invoke data compression for the RFA service, specify the keyword, COMP, in the DSLINE command. The COMP keyword compresses both NFT and RFA data associated to the remote environment specified in the DSLINE command.
Remote File Access FILE Command FILE Command Specifies a formal designator that may be used to represent a remote file or device in a subsequent command or intrinsic. (Also known as a file equation.) Syntax [=*formaldesignator [=$NEWPASS [=$OLDPASS FILE formaldesignator [=$STDIN [=$STDINX [=$STDLIST [=filereferenc[:nodespec]{,filedomain] [;DEV=[[envname]#][device][,outpri][,numcopies]] [;VTERM] [;ENV=envfile[:nodespec]] [;option] . . .
Remote File Access FILE Command $BACK indicates that the file resides one “hop” back toward your local system. This is legal only if the FILE command is issued in a remote session created by a REMOTE HELLO. The $BACK specification is equivalent to DEV=# (without an environment name). In either case, the file is accessed through the existing session. filereference The actual name of the file in the form: file[/lockword][.group[.account]]. filedomain The file domain: NEW or OLD or OLDTEMP.
Remote File Access FILE Command Description For Remote File Access purposes, the FILE command can be used to specify a formal designator for a remote file or device. You can use this formal designator to reference the remote file in a subsequent command or intrinsic call. If an environment ID is used to indicate the location of the file, it must be specified in a DSLINE or REMOTE command before you can use RFA.
Remote File Access RESET Command RESET Command Cancels file equations. Syntax RESET {formaldesignator } {@ }] Use Available In Session? Yes In Job? Yes In Break? Yes Programmatically? Yes Breakable? No Capabilities? None Parameter formaldesignator A formal file name in the form: file[.group[.account]][:nodespec], for which a FILE command has previously been issued. The nodespec portion is either an environment ID indicating the location of the file or $BACK.
Remote File Access Interactive Access Interactive Access In order to access a remote file or device interactively, you must first issue a FILE command that specifies the remote location of the file. However, you cannot indicate the location directly in the MPE/iX command or subsystem command that accesses the file. Example 1 Let’s say that you wish to print a text file named DOCUMENT on a line printer connected to a remote HP 3000 computer. You are editing the text file on your local system.
Remote File Access Interactive Access two nodes whose domains and organizations are different: configure the remote machine (using NMMGR; NM capability required), so that its network directory includes two entries: 1)localnode.localdomain.localorganization, and 2) localnode.remotedomain.remoteorganization. For example, if you were to issue a DSLINE from node A.LAB.CND to node B.SJ.CA, you would have to add the following entries to the network directory of node B.SJ.CA: A.LAB.CND A.SJ.
Remote File Access RFA Programmatic Access RFA Programmatic Access Once an environment has been established on the remote node, a local application program can access remote files by calling standard MPE/iX file system intrinsics (or by using the input/output procedures specific to the language in which the program is written).
Remote File Access RFA Programmatic Access :FILE X:NODEB=X:NODEC . . . FOPEN 9X:NODEB,...): You can call the MPE/iX FFILEINFO intrinsic to retrieve information about a remote file. In the FFILEINFO intrinsic, ITEM 61 returns the environment ID of a remote file’s location — over an NS link. If the file is located on your local system, ITEM 61 returns a blank. The condition codes for the file system intrinsics retain their normal meanings. Network connection errors return a CCL condition code.
Remote File Access FPARSC Intrinsic FPARSC Intrinsic Parses a file designator and determines whether it is syntactically correct. Syntax FPARSE (string,result[,items][,vectors]) Parameters string (input) Byte array, by reference. The file designator that is to be parsed. The string can be terminated by any non-alphanumeric character except a slash, period, colon, underscore, or dash (/, ., :, _, -). result (output) Array of two 16-bit integers, by reference.
Remote File Access FPARSC Intrinsic vectors (output) Array of 16-bit integers, by reference. Gives offset and length information that indicates the parse of the file string. Each element of the array is a 16-bit integer; each pair of elements corresponds to a portion of the string, in the same order as the items in the items array.
Remote File Access FPARSC Intrinsic Example 1 items Array (item code) Vectors Array (offset, length) 1 0, 8 5 32, 19 3 18, 5 4 24, 7 2 9, 8 0 0.51 In the second example, the file string is *FILENAME:CASH. Example 2 items Array (item code) Vectors Array (offset, length) 1 1, 8 2 0, 0 3 0, 0 4 0, 0 5 10, 4 0 0.15 In the third example, the file string is $OLDPASS.
Remote File Access Example RFA Program Example RFA Program What follows is a Pascal program that writes some test data to a remote file, reads the data back from the remote file, and sends the received data to a remote printer to be printed. An environment has been established on the remote node. Prior FILE commands have been issued for the formal file designators representing the remote disk file and remote printer. These file equations specify the remote location of the files.
Remote File Access Example RFA Program for i := 1 to 9 begin readln (remfile,test2); writeln (remprint,test2); {pick up listing on remote line printer and check output} end; end {program rfaprog}.
Remote File Access Remote Terminal Access: VT vs. RFA Remote Terminal Access: VT vs. RFA Both VT and RFA can be used to access remote terminals. In either case, a FILE command or FOPEN call must indicate that the file in question is actually a remote terminal. If you specify the VTERM option in the FILE command or the device parameter of the FOPEN call, the terminal will be accessed through Reverse VT rather than RFA. In both cases the remote terminal functions as a non-session I/O device.
Remote File Access RFA/RDBA Automatic logon RFA/RDBA Automatic logon A REMOTE HELLO is no longer necessary before using RFA. This is useful if your system does not support the Virtual Terminal service. Overview RFA requires a remote session when accessing or creating remote files to provide the file system security of the remote user. This session is referred to as an “environment.
Remote File Access RFA/RDBA Automatic logon With the remote file still open, issue a REMOTE:NODE1 HELLO user2.acct2 to log on a VT session. The remote session for VT will be completely independent of the remote session for RFA even though both sessions are operating under the same DSLINE environment. All VT commands will be executed under user2.acct2. All RFA intrinsics (including new FOPENs) will be under user1.acct1. This will continue until the last remote file on the NODE1 environment is closed.
4 Remote Database Access Remote Database Access (RDBA) is a Network Service in which you use TurboIMAGE/3000 intrinsics and utilities to access and update TurboIMAGE data bases located on remote HP 3000s. TurboIMAGE is a Hewlett-Packard database management system. TurboIMAGE intrinsics are sent to the remote node and executed in the remote environment. The database must reside on an HP 3000 (MPE V or MPE/iX based) since other IMAGE products are not fully compatible with TurboIMAGE/iX.
Remote Database Access RDBA Access Methods RDBA Access Methods There are three ways to open a remote TurboIMAGE database within a program: • Identify the database as a remote file in a prior FILE command; for example, FILE dbname=dbname:envID; • Use the COMMAND intrinsic to include the FILE command information in your program • Create a database-access file that supplies the command, a DSLINE command, and a REMOTE HELLO command.
Remote Database Access RDBA Access Methods The database-access file has the following general format: FILE dbname;DEV=envId# DSLINE envid locuser.locacct=HELLO remuser.remacct More than one local/remote logon sequence equation may be included in the file. When you call DBOPEN with the database-access file name, a remote session is established for the remote user that has been “equated” with your local logon name.
Remote Database Access RDBA Access Methods DSLINE LEO REMOTE HELLO NSUSER.NSACCT REMOTE RUN QUERY.PUB.SYS >DATA-BASE=databasename> For more information on TurboIMAGE and QUERY, see the TurboIMAGE Data Base Management System Reference Manual, especially the sections entitled “Using a Remote Database;” and also see the QUERY/3000 Reference Manual.
5 Network File Transfer Network File Transfer (NFT) is the network service that copies disk files. The files may be copied to the same computer or from one computer in a network to another. You can use Network File Transfer to transfer a file between any two systems in an NS 3000/iX network, even if both of those systems are remote from your own. You can also use it for purely local transfers on a single HP 3000.
Network File Transfer Three-Node Model Three-Node Model NFT transfers files according to the model shown in Figure 5-1. There are three logical participants in the file transfer activity: initiator, producer, and consumer. This model is called the three-node model. According to the three-node model, the initiator, located on the system where the transfer originated, receives the request and initiates the transfer.
Network File Transfer File Copying Formats File Copying Formats NFT uses two file copying formats: Transparent Format and Interchange Format. Transparent Format When files are copied from a source file node that is the same type of computer as the target file node (for example, if they are both HP 3000s or HP 9000s), the files are copied using a format called Transparent Format. Transparent Format does not alter a file’s attributes, but simply copies the file.
Network File Transfer File Copying Formats When a file is copied using Interchange Format, it is translated into Interchange Format at the source system before it is copied to the target system. At the target system, it is mapped from Interchange Format into the target system’s file format. Interchange Format’s standard file attributes enable the target computer to map the source file into a target file with attributes that match the source file’s as closely as possible.
Network File Transfer DSCOPY DSCOPY Transfers or copies a disc file from one node to another (or within a single node). Syntax DSCOPY [sourcefile [sfileloc] [to [targetfile] [tfileloc][;opt]]] [+[sfileloc] [to [tfileloc][;opt]. . .] [+opt[;opt]... Use Available In Session? Yes In Job? Yes In Break? No Programmatically? No Breakable? No Capabilities? None Parameters sourcefile The name of the file to be transferred, optionally including qualifiers.
Network File Transfer DSCOPY Here are some syntactically correct examples of HP 3000 source file location specifications: :ENV1 ,NODEA ,NODEA [NSUSER/PASSWD.NSACCT] :NODEA ,ENV1[NSUSER.NSACCT] : :ENV1 [] If delim and location are omitted, then the default is the global source file location specification or, if there is no global specification currently in effect, the local node name. (For an explanation of global specifications, see “Using Global Specifications” later in this chapter.
Network File Transfer DSCOPY The targetfile may also be a formal file designator defined in a prior file equation. If the targetfile is referenced by a formal designator, the targetfile must be preceded by an asterisk. A file equation can also redirect the targetfile to the temporary domain by specifying the disposition directive “;TEMP” in the file equation. The default disposition for the targetfile is the permanent domain.
Network File Transfer DSCOPY NOTE The descriptions of the options listed below assume that the transfers are between two HP 3000s (producer and consumer nodes) only. To learn what defaults, options, and syntax to use to transfer files between PCs and HP 3000s, refer to the User Guide for HP PC Network Services. There is no limit to the number of options that you can specify for a single DSCOPY request. Each option must be separated by a semicolon. Some options conflict with each other.
Network File Transfer DSCOPY If you do not specify this option, and if the HP 3000 source file is ASCII, then the HP 3000 target file will be ASCII. BIN (binary) Specifies that records contain binary information and that ASCII null characters (all zeros) will be used as padding when fixed-length records are created. BIN transfers files using Interchange Format. BIN can be used with the STRIP option to remove null padding from the ends of records.
Network File Transfer DSCOPY The restart record is the record in the restart ID file to which the restart ID will be written. Note that this record will be overwritten by NFT. The restart ID will be the first 1 or 2 characters in the record. The default is 0, the first record in the file. CLEAR Clears all global specifications previously issued in the current interactive DSCOPY session.
Network File Transfer DSCOPY If you do not specify this option, and if the source file is a direct access file (such as an RIO file), then the target file will be a direct access file. FCODE= sourcefilecode FIX (fixed) Gives the file code for the source file. In order to copy a privileged file (for example, a TurboIMAGE data base), you need to supply the appropriate negative file code in this option. The resulting target file will be given the same file code.
Network File Transfer DSCOPY can be specified using the RSIZE option.) FSIZE causes files to be copied using Interchange Format. If you do not specify this option, then the target file length will be the same as the source file length. INT (Interchange) Causes file or files to be copied using Interchange Format.
Network File Transfer DSCOPY If you do not specify this option, DSCOPY will display information about the success of the file transfer, such as source and target file names and target file lengths. REP (replace) Causes an existing target file to be purged and replaced by a copy of the source file. If the target file does not exist, a new file will be created. If you do not specify this option, existing target files will not be replaced.
Network File Transfer DSCOPY specifies the maximum size record allowed in the file. If DSCOPY must truncate records to adhere to the specified recordsize, it will issue a warning. RSIZE causes files to be copied using Interchange Format. If you do not specify this option, then target-file records will be the same length as source-file records. SDEV= source_device Names the disc device on the source node from which the source file should be obtained.
Network File Transfer DSCOPY TDEV= target_device Names the disc device on the target node to which the target file should be written. You can specify alternate disc devices for a KSAM file pair in the TDEV= option by enclosing a pair of device names, separated by a comma, in quotation marks. If you do not specify this option, then the disc device will be given the device class name DISC in the target system’s device I/O configuration file.
Network File Transfer Summary of DSCOPY Options Summary of DSCOPY Options Table 5-2 summarizes the available DSCOPY options. Refer to the syntax description earlier in this chapter for a full description of the effects of each option listed. Table 5-2 DSCOPY Options Summary Option Name Description APP * Appends source file to existing file specified as target file. ASC * Causes target file to contain ASCII data. BIN * Causes target file to contain binary data.
Network File Transfer Summary of DSCOPY Options Option Name Description STRIP * Removes padding from records in target file. TDEV = target_device Specifies disc device to which target file will be written.
Network File Transfer Using DSCOPY Using DSCOPY The following notes describe the function of DSCOPY and explain its operation in special situations: Required Access. Read and lock access is required for any file you want to copy with DSCOPY. If you do not have both read and lock access to the file, DSCOPY will issue a file security violation error message. Interactive Use. When you enter a DSCOPY command, NFT becomes interactive and displays the prompt DSCOPY.
Network File Transfer Using DSCOPY Lockwords. If the sourcefile has a lockword, and the target file is implied, then the targetfile will get the same lockword as the sourcefile. If a targetfile already exists, and you want to give it a new lockword, you must specify the targetfile and its lockword. Message Files. MPE/iX message files must be transferred in Transparent Format. They will not be copied if Interchange Format is used; thus they can be copied to HP 3000 systems only. KSAM Files.
Network File Transfer Using DSCOPY For example, to have NFT read file transfer requests from the file FILE1, at the MPE/iX prompt, enter: FILE DSCOPYI=FILE1 followed by DSCOPY Transfer requests are normally read from the file DSCOPYI, which by default is set to $STDIN(X)— the user’s terminal in an interactive session. NOTE If any global specification is specified in the DSCOPY command line, DSCOPY will ignore the file equation for DSCOPYI and subsequently enter the DSCOPY subsystem.
Network File Transfer Using DSCOPY When used with DSCOPY, wildcard characters can be used to specify HP 3000 file names only; they cannot be used to specify group or account names. The characters # and ? can be used to specify source file names only. The character @ can be used to specify both source and target file names, but can be used only once, with no other characters surrounding it, to indicate a set of target file names.
Network File Transfer Using DSCOPY 4. The DSCOPY subsystem is terminated. All specifications except file names may be made global in this manner. A new SDEV or TDEV specification, or “SDEV=” or “TDEV=” without a device name, clears a previous global source or target device. The only way to clear MOVE, COMP, or QUIET is to use CLEAR. If all source and target parameters are omitted, or if the command begins with + (global), you will receive a subsystem prompt consisting of the string DSCOPY.
Network File Transfer Using DSCOPY primary file is $STDLIST (the terminal in the case of sessions, the system line printer in the case of streamed jobs). The secondary file is a file or device with the formal designator DSCOPYL. The QUIET option suppresses all information regarding the success of file transfers except error messages. Primary output to $STDLIST is disabled if the opt parameter of the DSCOPY intrinsic is set to 0,1, or 2; otherwise, primary output is enabled.
Network File Transfer Using Checkpoint and Restart with DSCOPY Using Checkpoint and Restart with DSCOPY If you specify CHECKPT in the DSCOPY command line, the file transfer will occur normally, but an additional handshake sequence will occur between the source and target HP 3000 systems at periodic intervals (optionally specified by you). If a failure occurs, it is then possible to restart the transfer from the point where the last handshake took place.
Network File Transfer Using Checkpoint and Restart with DSCOPY intermediate failure occurs, the files will not be purged. Therefore, transfers that fail and are not restarted to a successful completion will leave restart files unpurged; NFT will not purge unused restart files. Similarly, for generic transfers a permanent file called GENSETx, where x is a number from 0 to 9, is created to hold the list of files to be transferred on the producer node.
Network File Transfer Using Checkpoint and Restart with DSCOPY Troubleshooting After Using CHECKPT and RESTART If a restart returns an error, some possible explanations might be: 1. One or more of the necessary files for restarting has been lost or corrupted, that is, NFTRxx, GENSETx, or NFTSCRxx, or the source or target files. 2. The transfer did not progress past the negotiation stage before it was aborted. 3.
Network File Transfer Using Checkpoint and Restart with DSCOPY Remote to Local In the next example we assume that a remote session has been established on REMNODE and that no global tfileloc specification is in effect.
Network File Transfer Using Checkpoint and Restart with DSCOPY CHECKPT and RESTART Examples Following are examples of how to use CHECKPT and RESTART: 1. The following example shows checkpointing being initiated for an IMAGE dataset file. The checkpoint interval is the default (5 minutes). The restart ID will not be written to a file, but will be written to $STDLIST if QUIET has not been specified or if output has not been disabled. :DSCOPYSFILE;TFILE:REMNODE[REMUSER.REMACCT]; CHECKPT=;FCODE=-401 2.
Network File Transfer Programmatic NFT Programmatic NFT The following subsections describe intrinsics that can be used to perform file transfers from within programs. Two intrinsics are available: DSCOPY, which performs the same function as the interactive DSCOPY command, and DSCOPYMSG, which writes a message indicating the outcome of the transfer request.
Network File Transfer DSCOPY Intrinsic DSCOPY Intrinsic Transfers or copies a file from one node to another (or within a single node). Syntax DSCOPY (opt,spec,result) Parameters opt (input) 16-bit integer, by reference. Enables/disables the primary output (to $STDLIST) and determines whether to continue after first transfer failure.
Network File Transfer DSCOPY Intrinsic 3 DSCOPY terminates after first failure. Use of command file spec enabled. Primary output disabled. 4 All transfers attempted. Use of command file spec disabled. Primary output enabled. 5 DSCOPY terminates after first failure. Use of command file spec disabled. Primary output enabled. 6 All transfers attempted. Use of command file spec enabled. Primary output enabled. 7 DSCOPY terminates after first failure. Use of command file spec enabled.
Network File Transfer DSCOPY Intrinsic error set (off). The lower-order bits give the actual NFT error number in one or the other error set. Thus there are three NFT error sets. The result parameter containing these error numbers is interpreted correctly by the DSCOPYMSG intrinsic. Refer to the NS 3000/iX Error Messages Reference Manual for these error messages. The second word of the array represents the number of files that were successfully copied.
Network File Transfer DSCOPYMSG intrinsic DSCOPYMSG intrinsic Writes a message that corresponds to the result code returned by a DSCOPY intrinsic call. Syntax DSCOPYMSG (result,fnum,r) Parameters result (input) Two-element array of 16-bit integers, by reference. The result is returned by the DSCOPY intrinsic. If the value in the first word is zero, then the file transfer was successful. Otherwise, the value indicates the error that occurred.
Network File Transfer Programming Language Considerations Programming Language Considerations The DSCOPY and DSCOPYMSG intrinsics are SPL procedures that may be called by programs written in other languages. Following are appropriate data types and calling sequences for the different languages available. (Other data types are sometimes possible.) SPL In SPL, opt, fnum, and r may be integers; spec must be a logical array; and result may be a logical array.
Network File Transfer Programming Language Considerations Pascal In Pascal, opt, fnum, and r may be 16-bit integers; spec may be a packed array of characters or a string (a legal type in HP Standard Pascal); and result may be an array of 16-bit integers.
Network File Transfer Programmatic NFT Examples Programmatic NFT Examples The following programs, in COBOL and Pascal, illustrate single and multiple file transfers via the DSCOPY intrinsic. They also call the DSCOPYMSG intrinsic to print an error message if necessary. The multiple-file-transfer examples use transfer specifications that are read from a file with the formal designator DSCOPYI.
Network File Transfer Programmatic NFT Examples 003000 PROCEDURE DIVISION. 003100 BEGIN. 003200 CALL "DSCOPY" USING OPT, SPEC, RESULT. 003300 IF RESULTS(1) > 0 CALL "DSCOPYMSG" USING RESULT, FNUM, R.} 003400 STOP RUN. COBOL: Multiple Transfer In this application, the opt parameter is set to one (1). DSCOPY terminates after first failure. Primary output is disabled. The command file spec for multiple transfers cannot be used.
Network File Transfer Programmatic NFT Examples Pascal: Single Transfer In this application, the opt parameter is set to four (4). All transfers will be attempted. Primary output is enabled. The command file spec for multiple transfers cannot be used. The spec parameter contains the full text of the transfer specification, including all parameters and options, and is terminated by an ASCII null character. $standard_level 'hp3000', uslinit$ program pcopy (input,output); type small_int = -32768..
Network File Transfer Programmatic NFT Examples Pascal: Multiple Transfer In this application, the opt parameter is set to two (2). All transfers will be attempted. Primary output is disabled. The command file spec for multiple transfers is enabled. The spec parameter contains the “COPYFILE” name terminated by an ASCII null character. The “COPYFILE” must exist prior to execution of the program. $standard_level 'hp3000', uslinit$ program pcopy2 (copyfile); type small_int = -32768..
6 Intrinsics for Node and Environment Status Following are descriptions of the two intrinsics described in this chapter — NSINFO and NSSTATUS: NSINFO returns information about NS environments and your local node. NSSTATUS returns information about services, servers, and NS users on local or remote nodes.
Intrinsics for Node and Environment Status NSINFO Intrinsic NSINFO Intrinsic This intrinsic is used to programmatically obtain information about NS environments that have been created in your session. These are environments created by either a DSLINE envID, or a REMOTE HELLO...;DSLINE=envID command. This intrinsic also allows you to obtain some information about your local node (such as the local node name).
Intrinsics for Node and Environment Status NSINFO Intrinsic envnum (input/output) 16-bit integer, by reference. Specifies environment by environment number. See the discussion for an explanation of the use of envID, envIDlength, and envnum. status (output) 16-bit integer, by reference. If the intrinsic call was successful, 0 is returned. Otherwise, an environment error number is returned. NOTE The following parameters appear in pairs to identify an item of data.
Intrinsics for Node and Environment Status NSINFO Intrinsic Figure 6-1 NSINFO Trace Information Data Structure Service number Number identifying what service this trace information on record pertains to. 0 = All services 1 = VT 2 = NFT 3 = RFA 4 = RDBA 5 = RPM TS If the service is being traced, this value is 1; otherwise, this value is 0. TT If the transport is being traced, its value is 1; otherwise, its value is 0. 6. establishment event 16-bit integer.
Intrinsics for Node and Environment Status NSINFO Intrinsic 8. NFT service 16-bit logical. If true (odd), a process in this job or session has requested NFT service on some environment. This item is independent of the environment specified by envID or envnum. 9. prompt length 16-bit integer. Length of the following prompt string, in bytes. This item must precede item 10. 10. prompt 8-byte character array. String to be used as the REMOTE mode prompt. Item 9 must precede this item. 11.
Intrinsics for Node and Environment Status NSINFO Intrinsic 26. list environments length 16-bit integer. Contains the number of envnums entered into the array supplied in item 27. If 0 is returned then no environments matched generic environment ID. This item must precede item 27. 27. list environments 36. local node ARPA domain name length 37. local node ARPA domain name 38. IP address 112 Array of 100 16-bit integers.
Intrinsics for Node and Environment Status NSINFO Intrinsic Description The NSINFO intrinsic is used to obtain information associated with environments defined in a job or session. There are two different ways that this intrinsic may be called. In the first method, envID/envnum define the specific environment or generic environment for which information is desired. In the second method, envID specifies the node name for which node-specific information is desired.
Intrinsics for Node and Environment Status NSINFO Intrinsic Table 6-1 NSINFO Errors Error Number Meaning 0 No error. Successful return from NSINFO. 1 Required parameter missing. Either the envID and envIDlength or the envnum;status must be specified. 2 Invalid itemnum value. 3 item parameter without a corresponding itemnum parameter. 4 itemnum parameter without a corresponding item parameter. 5 Invalid envID syntax. The correct syntax is envID.domain.organization.
Intrinsics for Node and Environment Status NSINFO Intrinsic Error Number Meaning 39 The organization part in a node name or envID is missing. 40 The organization part in a node name or envID does not begin with an alphabetic character. 41 The organization part in a node name or envID is longer than 16 characters. 42 The organization part in a node name or envID contains a non-alphanumeric character 44 NS transport not started. To start NS transport execute the NETCONTROL START command.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic NSSTATUS Intrinsic The NSSTATUS intrinsic returns information about services, servers, and NS users on local or remote nodes. This information is equivalent to the data displayed by NSCONTROL STATUS.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic itemnum i (Input) 16-bit integer, by value. Item number identifying the item of data to be retrieved. item i (Output) Data type varies. By reference. Array in which data identified by itemnum i will be returned. Required parameter if itemnum i present. Itemnum/item parameters must appear in pairs. Up to five items of information can be retrieved by specifying one or more itemnum/item pairs. Data Items 1.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Figure 6-2 Service List Data Structure Figure 6-3 Service List Entry Data Structure 118 Chapter 6
Intrinsics for Node and Environment Status NSSTATUS Intrinsic 2. server list 2000-byte character array (output). List of all servers installed on the indicated node. Format for the list is given in the data structures shown in Figure 6-4, Figure 6-7, and Figure 6-8. Server List Fields Number of Server Types The number of Server Type Lists returned. Server Type List See the description of the fields under item 12. Figure 6-4 Server List Data Structure 3. user list 2400-byte character array (output).
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Figure 6-5 User List Data Structure Figure 6-6 User List Entry Data Structure 5. service local 16-bit integer. Returns a value indicating one of the following conditions: -1 0 1 2 = = = = Named Named Named Named service service service service not installed. not remote. local. is monitor. NM capability is not required.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic 6. service server 8-byte character array. Name of server associated with named service. If the named server is not available, then eight ASCII spaces are returned. NM capability is not required. 7. min servers 16-bit integer. Minimum number of servers for the named server type on the indicated node. A returned value of -1 implies that the named server does not exist. 8. max servers 16-bit integer.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Create With Debug Number of Servers Server Entry If 0, servers are not created with the debug option. If 1, servers are created with a debug breakpoint. The number of active and reserved servers for this type. One for each active and reserved server process. Format of the data structure of each server type entry is shown in Figure 6-8. Server Entry Fields Server PIN The process ID number for the server.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Figure 6-7 Server Type List Data Structure Figure 6-8 Server Entry Data Structure 13. user.acct 26-byte character array. The user and account for the named session on the indicated node. If the named user is not present, then 26 ASCII spaces are returned. 14. job number 16-bit integer. The job number for the named session on the indicated node. If the specified session is not present, then -1 is returned. 15.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic 16. user type 16-bit integer. Returns a value indicating one of the following conditions: 1 = Named user is not present. 0 = Named user is remote. 1 = Named user is local. 17. num environments 16-bit integer. Number of active environments for the user on the indicated node. If the named user is not present, then -1 is returned. 18. environment list 2400-byte character array (output). List of environments for the user on the indicated node.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Figure 6-10 Env List Entry Data Structure 19. autologon supported 16-bit integer. Returns a value indicating one of the following conditions: -1 = Named service not installed. 0 = Named service does not support autologon. 1 = Named service supports autologon. 29. autologon enabled 16-bit integer. Returns a value indicating one of the following conditions: -1 = Named service not installed. 0 = Autologon is off for the named service.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Figure 6-11 Initiator’s Information Format Description For items 1 through 3, the name and namelength parameters are ignored. For items 4 through 6, the name and namelength parameters specify the service for which NSSTATUS information will be returned. For items 7 through 12 the name and namelength parameters specify the server type.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic NSSTATUS Intrinsic Examples 1. Determine if the VT service is started on the local node: Name := ‘VT’; NameLength:=2; ItemNum:=4; NSSTATUS (Name, NameLength, , , Status, ItemNum, VtStarted); If the VT service is started, VtStarted will be set to 1; otherwise it will be set to -1 or 0. 2.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic NSSTATUS (Name, NameLength, , , Status, ItemNum, InitiatorInfo); If the intrinsic returns without an error then the following information will be in the InitiatorInfo record. InitiatorInfo.JobType --- 1 { indicates Session} InitiatorInfo.JobNum --- 1 { session num } InitiatorInfo.Ldev --- 20 { logical device numb of #S1 } InitiatorInfo.LocRem --- 1 { local session. not a VT session} InitiatorInfo.Logon --- 'MANAGER.
Intrinsics for Node and Environment Status NSSTATUS Intrinsic Error Number Meaning 7 Expected a job or session number. 8 Non-numeric character in the job or session number. 9 Expected “#” as first character in Name parameter. 10 Bounds violation. 11 Unknown or invalid node name. 12 Node name specified without node name length. 13 Node name length specified without node name. 14 Communications error occurred with the remote NSSTATUS server.
7 Remote Process Management Remote Process Management (RPM) is a network service wherein a process using RPM intrinsics can create and terminate other processes. A created process can exist either on the same node as the creator or on another node. You can schedule a created process to be either dependent or independent of its creator. If a created process is independent, it can continue to execute even after its creator has expired.
Remote Process Management Common RPM Parameters Common RPM Parameters The following discussion of the flags and result 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. Normally an option is invoked if the appropriate bit is on (that is, set equal to 1).
Remote Process Management RPMCONTROL RPMCONTROL Controls the execution of an existing process that was created by an RPMCREATE. Syntax RPMCONTROL (pd [,location][,loclen],reqcode [,wrtdata][,wrtlen] [,readdata][,readlen][,flags][,result]) Parameters pd (input) 16-byte array, by value. Eight word program descriptor identifying the remote process to access. location (input) Character array, by reference. Character string identifying the node on which the remote process resides.
Remote Process Management RPMCONTROL Description This intrinsic is used to control a remote process that was created with an RPMCREATE request. The only RPM control requests defined are suspend and resume. Its calling sequence is similar to that of IPCCONTROL. The pd and reqcode parameters are the only required parameters. To control a remote process from a process which is not its creator, the location and loclen must be specified.
Remote Process Management RPMCREATE RPMCREATE Creates and activates a process and, if necessary, creates a remote session for that process to run in. Process Handling (PH) capability is required. Syntax RPMCREATE (progname,namelen [,location][,loclen][,login][,loginlen] [,password][,passwdlen][,flags][,opt][,pd][,result]) Parameters progname (input) Character array, by reference. The name of the program for which a process is to be created. namelen (input) 32-bit integer, by value.
Remote Process Management RPMCREATE • flags [1] (input). Causes the calling process to wait in this intrinsic call until the new process terminates. (The RPMCREATE call will complete only after the new process finishes executing.) • flags [2] (input). Causes RPM to create a process using RPM protocols from HP’s software release UB Delta 1 or earlier. In software release UB Delta 1 or earlier, RPM flags 3 and 30 are not supported. • flags [3] (input).
Remote Process Management RPMCREATE option parameter should conform to the value of the item parameter in the CREATEPROCESS intrinsic. Default: primary entry point. • Program parameter (code 22002, 2-byte integer). The data portion of this parameter contains an integer value used to transfer control information to the new process. The word will be accessible on the stack of the new process at location Q-4. This parameter corresponds to item number 2 of the MPE/iX CREATEPROCESS intrinsic.
Remote Process Management RPMCREATE 10 = Group Library, then Account Public Library, then System Library. • bit 9 — NOCB bit. If on, file system control blocks are established in an extra segment. If off, control blocks may be established in the Process Control Block Extension (PCBX) area. Default: off. This bit should be set on if the new process uses a large stack. • bits 7 and 8 — reserved for MPE; should be off (00). • bits 5 and 6 — STACKDUMP bits.
Remote Process Management RPMCREATE The contents of this option parameter should conform to the value of the item parameter in the CREATEPROCESS intrinsic. Default: The value specified in the program file • Initial dlsize (code 22005, 2-byte integer). The data portion of this parameter contains an integer (DB–DL) denoting the size, in words, of the user-managed stack area bounded by the DL and DB values. This parameter corresponds to item number 5 of the MPE/iX CREATEPROCESS intrinsic.
Remote Process Management RPMCREATE parameter in a DSLINE command or the login parameter of RPMCREATE), output requests will be directed to the empty file $NULL. • Info string (code 22011, n-byte array). The data portion of this parameter contains an information string that is passed to the new process. This string will be accessible on the new process’s stack at a byte address that is stored at location Q-5. If this option is included, you must also include the Info string length option (22012).
Remote Process Management RPMCREATE Normally, RPMCREATE allows only one remote process per remote session. Bit 30 of the RPM flags parameter allows multiple RPM remote processes in a remote session. This session-sharing option of RPM is only available in HP’s software release UB delta 2 or later. The only required parameters are progname, namelen, location, and loclen. (The intrinsic is option variable.
Remote Process Management RPMCREATE remote process and then do not abort the remote session, you can subsequently issue commands in the remote session. See “Releasing a Remote Environment” in the “Virtual Terminal” chapter of this manual. RPMCREATE can also create a new process on the local node.
Remote Process Management RPMCREATE Using $STDIN and $STDLIST in a Precreated VT Session Beginning with MPE/iX release 2.2, remote RPM slave processes can post interactive I/O to $STDIN and $STDLIST through a precreated VT session. This allows interactive I/O from remote programs to appear on a local terminal. Before creating an RPM slave, use the REMOTE HELLO command to create a remote session. After the session is established, you can use the RPMCREATE command to create an RPM son in the remote session.
Remote Process Management RPMCREATE • data associated with the option entries (variable length). Each 8-byte option entry, in turn, consists of the following fields: • option code (2-byte integer); • offset (relative to the base address of the opt parameter) indicating the location of the data for this option entry (2-byte integer); • length, in bytes, of the data (2-byte integer); • unused (2 bytes).
Remote Process Management RPMGETSTRING RPMGETSTRING Allows a created process to retrieve information strings passed to it by its creator in the RPMCREATE call. Syntax RPMGETSTRING (rpmstring,rpmstringlen,result) Parameters rpmstring (output) Character array, by reference. The string passed in the opt parameter of the RPMCREATE call that created this process. rpmstringlen (input/output) 32-bit integer, by reference. The maximum byte length allowed for the rpmstring.
Remote Process Management RPMGETSTRING Created process: RPMGETSTRING (RpmString1, Length1, Result); RPMGETSTRING (RpmString2, Length2, Result); RPMGETSTRING (RpmString3, Length3, Result); For another illustration of the use of this intrinsic, see the program examples at the end of this chapter.
Remote Process Management RPMKILL RPMKILL Terminates a process created by the RPMCREATE intrinsic. Process Handling (PH) capability is required. Syntax RPMKILL ( pd[,location][,loclen][,result]) Parameters pd (input) 16-byte array, by value. The program descriptor returned by the RPMCREATE intrinsic. location (input) Character array, by reference. The node name or environment ID indicating where the process to be killed is located. loclen (input) 32-bit integer, by value.
Remote Process Management ADDOPT 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. Refer to “Common Parameters” for more information on the structure of this parameter. entrynum (input) 16-bit integer, by value. Indicates which entry is to be initialized. The first entry is entry zero.
Remote Process Management ADDOPT ADDOPT (opt, 0, 8, 2, data_offset); {first entry is entry zero, option code 8; entry’s data area contains a 2 byte integer specifying an offset from data parameter address} IPCSEND (cd, data, dlen, , opt, result); {sends data located at offset from data address specified in opt} INITOPT and ADDOPT allow you to initialize the opt parameter for use in another intrinsic. These auxiliary intrinsics make the structure of the opt parameter largely transparent.
Remote Process Management INITOPT INITOPT Initializes the opt parameter so that entries may be added. Syntax INITOPT (opt,eventualentries[,result]) Parameters opt (output) eventualentries (input) result (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. 16-bit integer, by value. The number of option entries that are to be placed in the opt parameter.
Remote Process Management 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) result (output) 16-bit integer, by value.
Remote Process Management RPM Program Examples RPM Program Examples The following two Pascal programs illustrate the use of the RPM intrinsics. The first program creates a new process (the second program) on a remote node. It also creates a remote session for the second program to run in. At the same time, it passes strings containing a socket name and a node name to the remote process. This information enables the second program to establish a connection to the first.
Remote Process Management RPM Program Examples • opens a data file; • executes a loop in which it: • reads a line of data from the data file; • stores the length (number of bytes) of the data in the first part of the message; • stores the data itself in the second part of the message; • sends the message on the connection, including the message length as the first two bytes of the message; • after all the data is transmitted from the data file, sends a “last message” that will be recognized by the receivin
Remote Process Management RPM Program 1 RPM Program 1 $standard_level 'HP3000', uslinit$ program creator (input,output); const maxdata = 2000; maxname = 20; type smallint = -32768..32767; datatype = packed array [1..maxdata] of char; nametype = packed array [1..maxname] of char; byte = 0..255; var calldesc : integer; result : integer; progname : packed array [1..15] of char; location : packed array [1..16] of char; login : packed array [1..25] of char; flags : packed array [0..
Remote Process Management RPM Program 1 else writeln('IpcErrMsg result is ', newresult:1); terminate; end; procedure check ( result : integer); {error procedure} begin if result << >> 0 then leave (result); {failed} end; {error handling procedure} {The following procedure receives one message that was sent via an ipcsend call. It assumes that the length (number of bytes) of the message was sent as the first 2 bytes of data and that the length value does not include those 2 bytes.
Remote Process Management RPM Program 1 else rlen := 0; end; { procedure receive } begin {creator} {create call socket, then name it} ipccreate ( 3, 4, , , calldesc, result); check (result); {error procedure} {call socket, TCP protocol} socketname := 'MYSOCKET'; ipcname (calldesc, socketname, 8, result); check (result); {place rpmstring with socket information in opt parameter} prompt('What is the name of your local node? '); readln(datastr); len := strlen(datastr); strmove(len,datastr,1,nodename,1); fgin
Remote Process Management RPM Program 2 RPM Program 2 $ standard_level 'HP3000', uslinit$ program creature(datafile); {"datafile" must be an already existing file} const maxdata = 2000; maxmsg = maxdata + 2; maxname = 20; maxloc = 20; type byte = 0..255; shortint = -32768..32767; datatype = record len : shortint; msg : packed array[1..maxdata] of char; end; nametype = packed array[1..maxname] of char; loctype = packed array[1..
Remote Process Management RPM Program 2 begin {creature} {get the creator process's socket name and node name, one at a time, from the rpmstrings} rpmstringlen:= maxname; rpmgetstring (socketname, rpmstringlen, result); socknmlen := rpmstringlen; strmove (socknmlen, socketname, 1, strdata, 1); rpmstringlen := maxloc; rpmgetstring (nodename, rpmstringlen, result); nodenmlen := rpmstringlen; setstrlen(strdata,0); strmove(nodenmlen, nodename, 1, strdata, 1); {look up socket name to get destination descriptor}
8 NetCI NetCI is a network command interpreter that enables you to more efficiently manage and operate the systems in a network. It allows you to execute MPE commands (or UDCs) and to run programs on any node from one location. It lets you automatically establish remote sessions on several nodes and then broadcast commands to selected MPE V and MPE/iX nodes. NetCI also allows you to redirect input and output, sequentially execute commands on multiple nodes, and gather data from multiple nodes.
NetCI How to Use NetCI How to Use NetCI There are many applications in which you can use NetCI to help access multiple HP 3000s on the network.
NetCI Running NetCI Running NetCI To run NetCI from the MPE prompt, enter the following: :RUN NETCI.PUB.SYS Now press [Return]. After MPE accepts the RUN command, NetCI displays a message similar to the following message: NetCI/iX A.00.00 (c)Copyright Hewlett-Packard Co. 1994 NetCI then displays the NetCI prompt. This prompt tells you that you are in NetCI. You can now execute MPE commands and UDCs, and run programs on any node. Before you do so, you must configure the nodes and logon information.
NetCI Commands Commands You may enter any NetCI command at the NetCI> prompt. However, before you execute any MPE command, you must specify the name of the node and then the MPE command. To execute a NetCI command, enter NetCI>SHOWLIST To execute an MPE command, enter NetCI>K SHOWJOB which displays the status information for all jobs/ sessions/scheduled jobs on node or list K.
NetCI NetCI Security NetCI Security The same file security is provided for the NetCI configuration file as other MPE files. The HP 3000 account structure provides security at the account, group, and file levels. You can alter file level security so that only certain types of access are allowed to the configuration file. NetCI provides further security in the configuration file by encrypting all passwords that are part of the logon information to a node. Passwords are never displayed.
NetCI Configuring Network Data Configuring Network Data Figure 8-2 shows an internetwork that includes three networks (NET1, NET2, and NET3) connected together. We will use NET3 as the sample LAN network for our discussion. NET3 shows six nodes connected together by a LAN. NetCI is installed on node K, which is the management node.
NetCI Configuring Network Data Node Names Each node in the network is identified by its NS 3000 node name. Any node may be added to the NetCI configuration and identified in NetCI by a unique NetCI node name. The NetCI node name may be the NS 3000 node name or another NetCI name you want to assign to the node. Each NetCI node name is associated with a logon session on a node. You can have several logon sessions established on one node but each session must have an individual NetCI node name.
NetCI Configuring Network Data to configure node A with its logon session in NET1 as PORT. If the NS 3000 node name is not a unique node name in the internetwork, the node name following ;dsline=NS nodename option must be a fully-qualified node name, nodename.domain.organization. Whenever you want to establish a session on node A in NET1, you simply need to specify PORT instead of the fully-qualified NS 3000 node name.
NetCI NEWNODE NEWNODE Adds a node and its logon information to the user’s NetCI configuration. Syntax NEWNODE node logon[;dsline=NS nodename] Parameters node NetCI name or identifier for the node to be added. The NetCI name may be a maximum of 15 characters. logon Node’s logon identification which is a valid logon sequence in the form: username[/userpass].acctname[/acctpass][,groupname] [/grouppass].
NetCI NEWNODE This example adds nodes with logon sessions to the NetCI configuration. NetCI>NEWNODE K OPERATOR.SYS/NET3K NetCI>NEWNODE Y OPERATOR.SYS/NET3Y NetCI>NEWNODE I OPERATOR.SYS/NET3I NetCI>NEWNODE J OPERATOR.SYS/NET3J NetCI>NEWNODE L OPERATOR.SYS/NET3L NetCI>NEWNODE H OPERATOR.SYS/NET3H Since the ;dsline= NS nodename option is not specified after the logon information, the NetCI name for each node will be the actual NS 3000 node name.
NetCI ALTNODE ALTNODE Changes the NetCI node name and logon information in the user’s NetCI configuration for an NS 3000 node. Syntax ALTNODE node logon [;dsline=NS nodename] Parameters node NetCI name of the node whose logon information is to be changed. logon New logon identification which is a valid logon sequence in the form: username[/userpass].acctname[/acctpass][.
NetCI ALTNODE NetCI>ALTNODE CHABLIS OPERATOR.SYS/NET3K;DSLINE=L You still need to enter the user logon information even though you are only changing the remote environment. The NetCI node CHABLIS now refers to a session on NS 3000 node L instead of node Y (which was the previous configuration).
NetCI PURGENODE PURGENODE Deletes a node and its logon information from the user’s NetCI configuration and from any list of which the node is a member. Syntax PURGENODE node Parameters NetCI name of the node to be deleted from configuration and from all lists of which that node is a member. node Example This example deletes node J from the data base.
NetCI SHOWNODE SHOWNODE Shows the node’s logon information and the lists of which the node is a member. Syntax SHOWNODE node Parameters NetCI name of the node whose information is to be displayed. If you want to display the information for all nodes in the NetCI configuration, specify node SHOWNODE @ Discussion Passwords are not displayed for security reasons. Example This example shows the logon information and the lists of which node Y is a member.
NetCI SHOWNODE You can then use the SHOWLIST command to 1) display all the nodes belonging to a list, 2) check whether you correctly added a particular node to or deleted a node from a list, 3) verify whether a list is deleted, or 4) display all lists. Refer to the commands on the following pages for more specific details. When you broadcast or execute a command on a list, you execute the command sequentially on each node on the list. If a node is down, execution will continue to the next node on the list.
NetCI NEWLIST NEWLIST Creates a new list in NetCI configuration. Syntax NEWLIST list Parameters Name of the new list to be created in the NetCI configuration. The list identifier may be a maximum of fifteen characters. list Discussion The new list must be created before you can add nodes to the list.
NetCI ALTLIST ALTLIST Adds nodes to or deletes nodes from a list. Syntax ALTLIST {ADD} list nodes {DEL} Parameters ADD Adds a node to a list. DEL Deletes a node from a list. If you delete the last node from the list, the list will still exist in the configuration with no node members. list Name of the list to which a new node is to be added, or from which an existing member node is to be deleted. nodes Name of the nodes to be added to or deleted from the list.
NetCI PURGELIST PURGELIST Deletes an existing list from the NetCI configuration. Syntax PURGELIST list Parameters Name of the list to be deleted. list Discussion This command deletes the name of the list and the configuration specifying which nodes are members of the list.
NetCI SHOWLIST SHOWLIST Displays the names of the nodes included in a list. Syntax SHOWLIST list Parameters Name of the list whose member nodes are to be displayed. If you want to display all lists and the nodes on each list, specify list NetCI>SHOWLIST @ Examples Example 1 This example displays the nodes belonging to a specific list. NetCI>SHOWLIST LIST1 LIST1 Nodes on list: H I K This example displays all the lists and the nodes belonging to each list.
NetCI Saving Your NetCI Configuration Saving Your NetCI Configuration Your NetCI configuration is automatically saved in the file called NCICNFG. This file will reside on the default or home group (where you were logged on when you configured NetCI). If you log on to a group in which NetCI’s configuration is not located, you will receive a warning message but still be able to run NetCI. It is recommended that you keep a backup copy of the NetCI configuration file under another file name.
NetCI Executing Remote Commands Executing Remote Commands NetCI automatically establishes a session on a node when a remote command is executed. Simply specify after the NetCI> prompt the NetCI node or list name followed by the NetCI or MPE command. NetCI will establish a session on the NS 3000 node associated with the NetCI node name, or on the nodes belonging to the list. This eliminates your having to log on remotely to each node when executing commands and running programs.
NetCI Executing Remote Commands List Prompt You can also specify a list name against which a script file, command, or program can be executed. After the prompt, enter the list name and command. For example, when you enter CHABLIS>LIST1 SHOWJOB the SHOWJOB command sequentially executes on all nodes that are members of LIST1 (which includes nodes H, I, and K). It also eliminates your having to log on and execute the SHOWJOB command on each node.
NetCI Command Operation Modes Command Operation Modes The prompt indicates the command operation mode in which you are presently operating. The command operation mode that is in effect at any one time may be the • NetCI mode which is indicated by the NetCI> prompt • MPE mode which is indicated by a node or list name prompt. NetCI Mode You are in the NetCI mode when the NetCI> prompt is displayed. Only NetCI commands may be entered in this mode.
NetCI Interrupting Processing (Using [BREAK]) Interrupting Processing (Using [BREAK]) On MPE/iX machines, type [BREAK] twice to return to the MPE prompt. On MPE V machines, type [BREAK] once to return to the MPE prompt. Pressing [BREAK] sends a signal to NetCI to interrupt the process. This signal also passes through a “virtual” terminal to the remote process so that both the local and remote processes are suspended. To resume the local process, type RESUME which displays the current NetCI> prompt.
NetCI Special Considerations When Using DSLINE Special Considerations When Using DSLINE NetCI establishes DSLINE connections in quiet mode. Thus, no messages or prompts will be forwarded to your terminal while a connection is being established. If the remote node prompts for information (for example, password or termtype), the terminal or user would not know that a response is expected. No response would be sent, and the remote node connection will hang.
NetCI Failed Connections Failed Connections A session will be established on a node when you execute a command. However, a session will fail to be established when the link or node is down (not operating properly) or the configuration data is incorrect. NetCI maintains a record of all attempted logon sessions that failed. If you attempt to execute a command again on the failed node before 15 minutes have elapsed, NetCI will not attempt the execution.
NetCI Redirecting NetCI Input and Output Redirecting NetCI Input and Output NetCI allows you to easily redirect input and output instead of using $STDIN and $STDLIST. You redirect input through script files and output through log files. Figure 8-3 shows NetCI installed on node K with input and output passing through a virtual terminal configured on the remote nodes. Commands are transmitted over network connections through VT and are executed on the remote nodes.
NetCI Scripting (Redirecting Input) Scripting (Redirecting Input) Scripting gives you the capability to store a sequence of commands and data in a file to be used as input into NetCI. You execute the script file with the PLAY command to sequentially perform operations instead of issuing a series of commands. Refer to the following pages for more information on the PLAY command. You may execute PLAY in either the NetCI or MPE mode.
NetCI PLAY PLAY Executes a block or sequence of commands in a script file. Syntax [list/node] PLAY [times] file parms Parameters list/node Name of a list of nodes, or the NetCI name of a specific node on which a script file is to be executed. All MPE and NetCI (when preceded by a slash) commands in the script file will be executed on this list or node. If you do not specify a list or node name, only NetCI commands will be executed.
NetCI PLAY Examples Example 1 This example shows the PLAY command executing a script file named SCRIPT1 on default node K. The parameter, FINANCE, will be used whenever !1 is encountered in the file since this is the first parameter specified after the file name. Refer to the following page for more information. K>PLAY 2 SCRIPT1 FINANCE The script file will be executed two times, and data will be gathered each time.
NetCI Writing and Executing Script Files Writing and Executing Script Files A script file includes all commands, flow control statements, and data that allow you to remotely access and perform operations on nodes. To execute the script file, it must reside on the management node on which NetCI is installed. Creating a Script File You can create a script file with any text editor while you are at the MPE colon prompt or from within NetCI.
NetCI Writing and Executing Script Files Table 8-1 Reserved Characters Reserved Characters Substituted String !u Current user name !g Current group name !a Current account name !h Home node !n Current or default node on which execution is occurring !! Indicates an exclamation mark and not a substitution for a parms value or string Special Slash Character When a script file is executed on a node or list, the MPE mode is in effect.
NetCI Writing and Executing Script Files %comment show NetCI nodes' %comment and lists' configu%comment ration adds comment that this file will list the NetCI configuration for the NET3 network. %log logfile1 redirects output to log file called LOGFILE1. A slash does not need to precede the NetCI command since you will be in a NetCI mode. Refer to the LOG command discussed later in this section. %shownode @ displays the NetCI configuration for all nodes.
NetCI Writing and Executing Script Files exit exits program. This is a subsystem command to exit the listdir5 program. %/logreset resets output back to the screen. Refer to the LOGRESET command discussed later in this section. SCRIPT2 runs a program that lists attributes according to groups and users for an account called FINANCE. We know this information is for the FINANCE account because !1 references the first parms value specified in PLAY. The output will be stored in the log file called LOGFILE2.
NetCI IF Statement IF Statement The IF statement controls the execution of a block of commands or a single command depending on whether the expression (or condition) is true. The IF statement consists of the reserved word IF, an expression (condition), commands, the reserved word ELSE and other commands which are optional, and the reserved word ENDIF. When NetCI executes an IF statement, the following occurs: 1. NetCI evaluates the expression which is the condition. 2.
NetCI IF Statement Discussion You may nest both IF and WHILE statements in script files. A maximum of 20 IF statements and 20 WHILE statements (for a total of 40 statements) may be nested together within the same script file.
NetCI INC Statement INC Statement The INC statement increases the value of a variable by one. Syntax INC variable Parameters variable Specifies the variable to which the value is assigned. This variable must begin with an alpha character. Discussion If the value of the variable is 32,767, an error message will display.
NetCI LET Statement LET Statement The LET statement assigns a value to a variable, or a variable to a variable. The LET statement consists of the equal sign which is an assignment operator. It does not indicate equality but is a signal that the value or variable on the right of the equal sign be assigned to the variable on the left. Syntax LET variable = value Parameters variable Specifies the variable to which the value is assigned.
NetCI WAIT Statement WAIT Statement The WAIT statement returns control to the next command after waiting the specified number of seconds. Syntax WAIT seconds Parameters seconds Specifies the number of seconds before the next command is executed. The number must be a positive integer not greater than 32,767. Discussion If you want to wait longer than the maximum number of seconds allowed, specify the WAIT statement as many times as needed.
NetCI WHILE Statement WHILE Statement The WHILE statement executes commands repeatedly as long as a given expression is true. The WHILE statement consists of the reserved word WHILE, an expression (condition), commands, and the reserved word ENDWHILE. When NetCI executes a WHILE statement, the following occurs: 1. NetCI evaluates the expression which is the condition. 2.
NetCI Logging (Redirecting Output) Logging (Redirecting Output) Logging allows you to store in a log file all output from a process or operation that takes place on configured nodes. You can redirect output to a log file with the LOG command and direct output solely to the screen with the LOGRESET command. These two commands may be used either inside or outside a script file. Refer to the pages that follow for more information on these two commands.
NetCI Logging (Redirecting Output) Figure 8-5 Logging Activated 200 Chapter 8
NetCI LOG LOG Redirects the output of a process or operation to a log file. Syntax LOG file Parameters Name of the file where output is to be stored. This file name is one of the following fully qualified file names: file • file • file.group.
NetCI LOGRESET LOGRESET Resets NetCI so that output appears only to the screen. Syntax LOGRESET Example This example shows how LOG redirects output to a log file called FILE1. LOGRESET then resets the output back to the screen. If output is not reset back to the screen, output will continue to be directed to FILE1. NetCI>LOG FILE1 . . .
NetCI Scripting and Logging Scripting and Logging NetCI redirects both input and output when scripting and logging are used simultaneously. When output is redirected, remember the following: 1. During execution of the script file, the output mode specified in the script file is always in effect. If the script file does not specify an output mode, the mode prior to script file execution remains in effect. 2. After execution of the script file, the output mode prior to execution takes effect again.
NetCI Scripting and Logging Figure 8-6 Scripting and Logging Activated (Example 1) Example 2 Figure 8-7 first shows logging being activated by input from the keyboard. Output is to the screen and to a log file called FILE1. Since you may need to interactively respond to the output, it will also be displayed to the screen. Next, you execute a script file called SCRIPT1 with PLAY.
NetCI Scripting and Logging Figure 8-7 Scripting and Logging Activated (Example 2) Example 3 Figure 8-8 first shows logging being activated by input from the keyboard. Output is to the screen and to a log file called FILE1. Since you may need to interactively respond to the output, it will also be displayed to the screen. Next, you execute a script file called SCRIPT1 with PLAY. While the script file is executing, input is from the script file and output is to FILE1.
NetCI Scripting and Logging Figure 8-8 Scripting and Logging Activated (Example 3) Example 4 Figure 8-9 first shows logging being activated by input from the keyboard. Output is to the screen and to a log file called FILE1. Since you may need to interactively respond to the output, it will also be displayed to the screen. Next, you execute a script file called SCRIPT1 with PLAY.
NetCI Scripting and Logging Figure 8-9 Scripting and Logging Activated (Example 4) Chapter 8 207
NetCI Sample Applications Sample Applications The following are sample NetCI applications that you can develop to use in a production environment. You can write a script file containing applicable commands, flow control statements, and data that will automatically perform different operations on multiple remote nodes. Sample Script File 1 This application summarizes the network configuration for each node in NET3 of our sample internetwork.
NetCI Sample Applications We will then assign all the nodes in NET3 to this list with the ALTLIST command. NetCI>ALTLIST ADD NET3 H,L,K,J,I,Y We can verify this by entering the SHOWLIST command at the NetCI prompt: NetCI>SHOWLIST NET3 NET3 Nodes on list: Y I J K L H Before executing the script file, we should create a disc file with a bigger record size so there will be no data overflow.
NetCI Sample Applications The INSTALL script file contains the following commands: %dsline local=!1 file equation for the node defined as local. The referenced node will be specified with the PLAY command. %newgroup newvers creates a new group called newvers on the node. %dscopy runs the DSCOPY subsystem. prog.newvers:local [operator.sys] to @.NEWVERS;REP specifies that the target file will have the same file name as the source file.
NetCI Sample Applications %run prog.applic;info = “showversion” checks that the converted file has been converted for use with the new version of software. %tellop...**applic: version a.01.01 installed & ready** displays a message that the current software version has been successfully installed and is ready for use. We are now ready to execute the script file, INSTALL, on all nodes in NET3 of our sample internetwork.
NetCI Sample Applications The CONFJOB job file contains the following commands and data: !job net3,operator.sys/net3k;hipri;pri=cs;outclass=epoc,13 !comment this will print the system configuration report !file conflist=sysinfo;dev=pp;env=elite.hpenv.sys !run sysinfo.prv.telesup out pp title “NET3” all exit !eoj The job file, CONFJOB, will run a program on the node or list that you specify with the PLAY command. This program called SYSINFO will generate a report listing the node's configuration.
NetCI Sample Applications %/logreset resets output back to the screen. We are now ready to execute the script file, NODCONF, on any node. For example, to execute the script file on node L, enter NetCI>L PLAY NODCONF which will generate the system configuration listing for node L. To execute the script file on all nodes in NET3, enter NetCI>NET3 PLAY NODCONF which will generate the system configuration listing for NET3.
NetCI Sample Applications %/endwhile We are now ready to execute the script file, SYSOP, on any node. Before we execute the script file, we must interactively assign a value (the current time) to the variable called “hour”. To set the current time, enter NetCI>LET HOUR=X (X is current hour, for example, 6 for 6 A.M.) After specifying the current time, we are now ready to execute the SYSOP script file.
NetCI Troubleshooting NetCI Troubleshooting NetCI The first step in troubleshooting NetCI is to look at the error message returned by NetCI. In order to understand the error message, refer to the “NetCI Error Messages” section in the NS 3000/iX Error Message Reference Manual for the possible causes of the error and recommended recovery actions). If NetCI returns a specific error message, find it in the manual, try to understand the cause of the error, and take the action recommended.
NetCI Troubleshooting NetCI 216 Chapter 8
A Migration From NS 3000/V to NS 3000/iX Network Services This Appendix discusses the migration from NS 3000/V to NS 3000/iX network services. If your system currently uses DS/3000, please consult Appendix B, “Migration From DS/3000 to NS 3000/iX Network Services.” For network management (configuration) migration, refer to the NS 3000/iX Configuration Planning and Design Guide.
Migration From NS 3000/V to NS 3000/iX Network Services Differences Between NS 3000/V and NS 3000/iX Differences Between NS 3000/V and NS 3000/iX NS 3000/iX is a compatible subset of NS 3000/V, the powerful networking software available on the MPE V/E based members of the HP 3000 family. Special Note on Terminal Echo When communicating between an MPE/iX based node an MPE V based node, if echo ever gets turned off, proceed as follows: 1. Issue a colon (:) to return to your local node. 2.
Migration From NS 3000/V to NS 3000/iX Network Services Error Messages: NS 3000/V to NS 3000/iX Error Messages: NS 3000/V to NS 3000/iX To learn about NS 3000/iX error messages and recovery procedures, refer to the NS 3000/iX Error Messages Reference Manual.
Migration From NS 3000/V to NS 3000/iX Network Services Conversion Checklist: NS 3000/V to NS 3000/iX Conversion Checklist: NS 3000/V to NS 3000/iX The following checklist is to help you with migrating NS 3000/V software to NS 3000/iX on MPE/iX: 1. Identify applications using Program-to-Program Communications (PTOP). PTOP is not supported, so any PTOP applications must be modified so that they can run on an MPE/iX based machine.
B Migration From DS/3000 to NS 3000/iX Network Services This Appendix discusses the migration from DS/3000 to NS 3000/iX. If your system currently uses NS 3000/V, and you are migrating to NS 3000/iX, refer to Appendix A, “Migration From NS 3000/V to NS 3000/iX Network Services.” For network management (configuration) migration, refer to the NS 3000/iX Configuration Planning and Design Guide.
Migration From DS/3000 to NS 3000/iX Network Services Differences Between DS/3000 and NS 3000/iX Differences Between DS/3000 and NS 3000/iX DS is an acronym for Distributed Systems. NS is an acronym for Network Services. An NS 3000/iX link product is required in addition to the NS 3000/iX Network Services. A DS installation can consist of 1) hardwired point-to-point links, 2) point-to-point modem links on either dial-up or leased telephone lines, 3) X.25 network links, and 4) satellite network links.
Migration From DS/3000 to NS 3000/iX Network Services Differences Between DS/3000 and NS 3000/iX • 3000 to 1000 or DEXEC calls are not supported. • Program-to-Program communication (PTOP) is not available. To convert your PTOP applications to NetIPC and RPM, please refer to the NetIPC 3000/iX Programmer’s Reference Manual. Changed Features The features that changed from DS 3000 to NS 3000/iX are as follows: • DSLINE ldev# (for DS device) is replaced by DSLINE envID or DSLINE envnum.
Migration From DS/3000 to NS 3000/iX Network Services Error Messages: DS/3000 to NS 3000/iX Error Messages: DS/3000 to NS 3000/iX To learn about NS 3000/iX error messages and recovery procedures, refer to the NS 3000/iX Error Messages Reference Manual.
Migration From DS/3000 to NS 3000/iX Network Services Conversion Checklist: DS/3000 to NS 3000/iX Conversion Checklist: DS/3000 to NS 3000/iX Identify applications using Program-to-Program Communications (PTOP). PTOP is not supported, so any PTOP applications must be converted so that they can run on an MPE/iX based machine. If you wish to convert your PTOP applications so that they can run on NetIPC and RPM, refer to the conversion procedures in the NetIPC 3000/iX Programmer’s Reference Manual.
Index Symbols $BACK precautions when using, 52 A ADDOPT, 148 architecture network, 16 ARPA domain name syntax, 20 Automatic logon for RFA and RDBA, 61 B BACK how to use, 47 precautions when using, 49 breaking a file transfer, 88 C cancelling file equations, 50 closing a remote session remote environment, 35 COMMAND intrinsic Remote Database Access, 64 create a session, 21 D database access file, 64 DBCLOSE intrinsic Remote Database Access, 64 DBOPEN intrinsic Remote Database Access, 64 DBUTIL utility Remot
Index Remote Data Base Access (RDBA), 18 Remote Database Access, 63 remote environment allowing use of by issuing REMOTE command, 37 closing, 35 defining attributes, 26 Remote File Access example, 58 interactive access, 51 programmatic access, 53 purpose, 45 Remote File Access (RFA), 18 REMOTE HELLO command, 31 Remote Hello Command network commands required before using, 33 Remote Process Management common parameters, 132 created processes, 140 defined, 131 dependent and independent processes, 142 session
