Last Updated: Thursday, November 25, 1999 10:34 PM
KP
My recommendation, or 2 cents worth, is that new installations, or installations with resources, put in a fiber backbone with 10BaseT home cableing. The reason for this is that you get 100Mbs through the backbone and, if you want to 100Mbs to the desktop(100BaseVG). Also, UTP provides the advantage of star topology, isolating most problems to the node level.
BR
One caveat to the above: on the 10-base T cabling, when installing any new cable, put in category 5 wiring AND make sure your connectors are category 5 compliant as well. you need BOTH to eventually pull 100MBs around the network, and category 5 is not that much more expensive than category 3 and is certainly a lot less than repulling new wire when you need the added bandwidth.
CM
One key point for either 10BaseT or Thick is the amount of bandwidth there is and how much you can actually use. One number I hear fairly consistently is 30% busy on ethernet. Much above that and performance goes quickly to the trash heap.
So, figure it out. 10Mbits/Sec = 1.25 Mbytes/Sec. 1.25Mbytes/Sec @ 30% = 0.375 Mbytes/Sec available throughput.
If you're going to put a 50 gig server on, you better have multiple network paths into it, have it on an FDDI channel, or have fairly low access.
Can use either coax (bnc connectors), twisted pair, or fiber (fddi) media. Interface card (lanic) comes with all MPE/iX (RISC) systems; can be bought separately for MPE/V systems (part of the ThinLan Link product - it includes both hardware and tcp/ip software).
Requires token ring cards for 3000 (must be purchased separately). Built-in support for this interface in FOS networking software (MPE/iX).
Requires fddi interface card for 3000 (must be purchased separately). Built-in support for this interface in FOS networking software (MPE/iX).
RG
Need to watch the inbound and outbound buffer pools to be sure they don't overflow. Increase as needed.
Requires an X.25 interface card for 3000 (must be purchased separately). For MPE/V systems an INP card was used with appropriate software.
Serial networking on classic HP3000s can be accomplished by control of modems on ATP/ADCC ports. MPE/iX systems only have serial ports on external DTC boxes, which are much more difficult to control for fancy low-level I/O work. [MPE/iX boxes do include a remote console port - a serial port built into the cpu - some models have more than one; but these ports are prone to all kinds of problems when anything other than plain terminal i/o is run on them... even terminal-emulator file-transfers are prone to difficulty on many of these ports.]
Where can one find Kermit, Xmodem, and other PC-HOST file-transfer programs?
GC
www.columbia.edu/kermit/
CB
Kermit source in C and SPL, as well as object code (WRQ Labelled format) are available on ftp.3k.com. XMODEM object code for MPE is also there (in WRQ Labelled format).
In general, routers pass higher-level networking traffic (ip/ipx/appletalk and above -- on the OSI 7 layer model). Bridges carry lower-level protocols, including low-level broadcasts and routing queries. In practice, many modern models are hybrids (sometimes called "brouters") and can be configured to handle mixes of traffic levels. Routing is usually a slower operation as more intelligence is required; routers usually interpret the packets travelling over the wire and only pass those packets which the device on the other end of their router-link might need. Bridges on the other hand usually just pass all traffic coming in to all the other (outbound) interfaces; since there is no lookups or interpretations they can do this much faster, often at full interface speed (or close to it).
I understand MPE/iX will permit routable DTCs in some future version (Mid '95). I thought I saw a discusion reguarding the rules of using this feature: Will I be able to route both old and new DTCs? Only new? Only old? Can I mix them? If so, what are the rules.
JK
According to the new HP DTC Planning Guide:
Routable AFCP allows HP3000 Series 900 systems to connect to DTCs across a routed IP network. A front-end DTC acts as a protocol converter, converting UDP/IP to AFCP and vice-versa. The front-end DTC and its manager must be on the same LAN as the HP3000 system. [...snip...]
The DTC 72MX, DTC 16MX, or ARPA Telnet Express may be used as a front-end DTC. The DTC 72MX, DTC 16MX, DTC 16, or DTC 48 (with memory extension) may be used as a remote DTC. A Domain Name Server is needed to resolve addresses.
It requires MPE/iX 5.0 and OV DTC Manager 14.2.
JL
In case anyone else besides me noted the obvious omission of the DTC16iX from the list, I'll save you the time of asking: the Response Center confirmed that the 'iX does not and will not support RAFCP - either as a front-end or remote.
I also asked if there were an upgrade kit from iX to MX and was told that there is none.
BG
I asked the same question of my SE and got the following reply:
..... You will only need a new DTC (DTC72) on your local segment (the one the HP3000 is on ).
WRS
The purpose of this DTC is to strip the IP header and send the remaining AFCP (unroutable) information to the 3000.
BG
All the remote DTC's can be on other segments and can be DTC 48's. There is a catch however, the remote DTC's will need to "see" the Openview Workstation at the "MAC" level in order to get their downloads. This means that you will need to enable bridging on the router. Some routers allow selective bridging (only a select number of MAC addresses allowed to pass), and this is the desired way to go, so as to not defeat the whole purpose of routing. An alternative to this is having an Openview Workstation on each segment were there are DTCs.
As an additional datapoint, The DTC/RX can download through a router (it uses TFTP) and may offer an alternative.
There are certain features of DTC configuration which could not be accomplished from the host-based configuration interface; perhaps the most popular of these capabilities is the ability to allow a port to "switch" or select different hosts to connect to. (DTCs can connect to HP3000s using AFCP[and other] low level protocols, as well as via telnet to any host that accepts inbound telnet connections.)
As of MPE/iX 5.5, the host-based configuration facility has been greatly enhanced, making much of the configuration process much easier (and may support switchable ports?)
JD
With OpenView DTC Manager, a DTC port can be configured as one of three types - terminal, printer, or host. If configured as a host port, the port can be accessed via telnet to the DTC's IP address at a specific TCP port number, as calculated by the following formula (taken from HPSL document N2X94121300C (http://support.mayfield.hp.com/kdb-bin/wwwsdoc.pl?DOCID=N2X94121300C)):
( ( ( 32 * dtc_board_number ) + dtc_port + 1 ) * 256 ) + 23
So, for example, for a dtc at IP address 199.8.123.123 to connect to port 2 on board 0 you would use "telnet 199.8.123.123 791".
Once this port is accessible via telnet, if it is cabled to another DTC port which is configured as a normal terminal, then the incoming telnet can be passed serially to a DTC> prompt, or if switching is not enabled, pass directly to the default destination for that port. If the destination is an MPE/iX system, then we have effectively translated from telnet to rs232 to AFCP, providing a means for a user with telnet but not NS/VT capability to access the MPE/iX system from the network, without a Telnet Access Card in the DTC.
Miscellaneous supplemental notes:
The cable connecting the two DTC ports does *not* need to be crossed (i.e. null-modem).
Recommend not using speed sensing on either port, but rather just set them both to 19200bps.
The serial link between DTC ports is the slowest link in the chain here, so even if the telnet user has a T1 line, they'll only get 19200bps throughput.
Only one telnet connection per port at a time. If a second user tries to connect, they'll appear to get connected but will not receive any prompts.
Some obvious security concerns are raised by this configuration. NS/VT provides a certain level of 'security by obscurity', while telnet access is more widely understood and available.
Disconnecting from the telnet session is not automatic. Upon logging off the session will be left at a new logon prompt. Most telnet clients use ^] to escape back to a telnet> prompt, from which a 'quit' command usually closes the connection.
See the paper at http://www.3k.com/ under the documentation section for detailed instructions on how to connect an HP3000 to the Internet.
JK
If you have (a) existing Internet connectivity to a Unix/HPUX/similar system, it is relatively trivial. If not, see related questions. If yes, you want MPE/iX 4.0 or higher, and enable DNS by setting up the proper entries in NET.SYS (RESLVCNF.NET, HOSTS.NET, etc) and enable Ethernet framing and ARP protocols in NMMGR. That's it. Experience and user feedback indicates you are best to "ignore" Probe names for this purpose and stick with ARPA domain names for Internet use.
Point your RESLVCNF nameserver entry to an existing DNS-capabile node, and configure a "default neighbor gateway" in NMMGR to the IP address of your router.
This can be done in MPE/V and pre-4.0 MPE/iX but requires manual maintenance of your NSDIR file - these systems do not have DNS resolver clients so you must manually enter every system you wish to connect to.
If you have DTC Manager, the same holds true; use probe names for the DTC-to-host connections, use ARPA names otherwise. (See Telnet FAQ).
In NMMGR, select open config, then NS, then unguided config, then goto netxport, then goto NI, select your LAN interface from the list and hit ENTER, select GOTO Internet, select your router (if already there - if not, make up a name for it and hit Add); on the next screen you provide the IP address of the router, and under "IP Network Address" select "@" - IP MAsk (blank), Hops (any number). Hit SAVE DATA, home cursor and type "utility" and hit enter, then select "validate" then "validate netxport". You'll need to either stop/restart the network, or enter
:netcontrol update=internet;net=lan1
^^^^use whatever your lan interface is called
to get the changes to take affect.
DH,CB
Part of knowing how to make a decent firewall is knowing what services are there to firewall. I've compiled a list of services I've found and what sockets they are on. (services.net.sys format) echo 7/tcp # Echo echo 7/udp # discard 9/tcp sink null # Discard **I discard 9/udp sink null # **I daytime 13/tcp # Daytime **3 daytime 13/udp # Daytime **3 qotd 17/tcp quote # Quote of the Day **3 chargen 19/udp ttytst source # **I chargen 19/tcp ttytst source # **I ftp-data 20/tcp # File Transfer Protocol (Data) ftp 21/tcp # File Transfer Protocol (Control telnet 23/tcp # Network Host access client smtp 25/tcp # Simple Mail Transfer Protocol **3 time 37/tcp timeserver # Time time 37/udp timeserver # domain 53/tcp nameserver # Domain Name Service client domain 53/udp nameserver # Domain Name Service client tftp 69/udp # Trivial File Transfer Protocol gopher 70/tcp # gopher client/server **3 finger 79/tcp # Finger client/server **3 httpd 80/tcp # World Wide Web client/server hostname 101/tcp # hostname client **3 pop2 109/tcp # pop2 server **3 pop3 110/tcp # pop3 server **3 ntp 123/udp # Network Time Protocol nmbp 137/udp # Samba name services smbp 139/tcp # Samba server snmp 161/udp # SNMP snmpt 162/udp # SNMP Trap syslog 514/tcp # syslog daemon lpd 515/tcp # lpr/lpd printing client/server **3 DAServer 987/tcp # Image/sql remote access # NS Services Ports nsloop 1260/tcp # NS Loopback nft 1536/tcp # NS Network File Transfer (DSCOP vt 1537/tcp # NS VT (message mode) rvt 1538/tcp # NS Reverse VT ptop 1540/tcp # NS Process to Process comm. pxp 1541/tcp # IPC Registry rpm 1542/tcp # NS Remote Process Management avt 1570/tcp # NS VT (stream mode) rfa 2560/tcp # NS Remote File Access nsstat 2564/tcp # NS Status Server pds 5696/tcp # hdspns 5697/tcp # Information Access Service hcs 5710/tcp # Cooperative Service iasql 7489/tcp # Information Access/SQL Service hpip 7490/tcp # Client/Server AllBase Service * client services connect out (from) the HP 3000, servers accept connections into the HP 3000. ** Not all services are available on all systems - some require optional programs (contributed or purchased) **I denotes services available on MPE/iX 5.5+ using the inetd daemon. **3 denotes services available from third party software packages.
Enabling DNS (requires MPE/iX 4.0 or above):
(1) Insure you have Ethernet and ARP enabled in NMMGR on the link. This flag is in the "NETXPORT.NI.niname" screen.
(2) Edit RSLVSAMP.NET and HOSTSAMP.NET to fit yourself and save them as RESLVCNF.NET and HOSTS.NET accordingly. You must define your nameserver's IP addresses in RESLVCNF and you can define more than one.
(3) In NMMGR, define "Default Neighbor Gateway" to point to the router. This is on the "NETXPORT.NI.niname.INTERNET.gatename" screen and you should have the IP address of your router (or gateway), and in the table of "reachable networks" you want an IP address of "@". This gateway address must be on your local IP network unless you have some other gateways or proxy services going.
(4) Be sure to fill in your "real" ARPA Domain address in NMMGR even if it is different from your "probe" name. The probe name is in the main screen after you open the config file. The ARPA domain name is in the initial NS configuration screen. THIS MUST MATCH YOUR DNS INFORMATION.
(5) Always establish Internet connections by the ARPA domain name. Unless you've made some extensive and unnecessary manual directory creation to make the names accessible, using the probe name will fail (unless, of course, the two are the same).
At this point I think you will need to reboot; I don't think all of these changes can be applied by a NETCONTROL UPDATE (but I could be wrong!).
DSCOPY (a system to system file copying system) that only works between HP systems (HP3000s and HP9000s - though support on HP9000s ended recently) is part of HP's NS/3000 package. NS/3000 is a purchasable product and is becoming of only marginal utility. HP intends that more "open" protocols like FTP take its place.
For it's faults, DSCOPY does handle HP3000 to HP3000 file transfers much easier (and accurately) than FTP currently does (DSCOPY knows about all the proprietary HP3000 file attributes and automatically preserves them).
RM
:DSCOPY O1234.OUT.HPSPOOL,OTHERHP[user.acct];FOO :SPOOLF FOO;PRINT;DEV=LP
For a long time FTP had to be purchased as part of the "Arpa Services/3000" package; but as of MPE/iX 5.0 both the client and server are bundled in the operating system. FTP allows you to send and receive files between systems over a network. HP3000's FTP has some extensions to allow the preservation of HP3000 file attributes, but it usually takes some manual specification on the client side.
CR2
There are some serious security issues with FTP (File Transfer Protocol) and the HP3000, especially for those who rely on Security/3000.
What is FTP?
FTP is a protocol defining how files are transferred from one computer to another. FTP is also the name of a program used to move files that uses the File Transfer Protocol. With the FTP program you can copy files from your PC to a HP3000 or from a HP3000 to a UNIX host. This is the same FTP you use on the Internet.
FTP facts:
1). MPE/iX 5.0 gives you all the services needed to run FTP. 2). Out-bound FTP can be run by executing the FTP program. 3). In-bound FTP can be run only if a "monitor" job is running for FTP. 4). A valid logon name (MGR.Pnnn, etc.) must be known.
In-bound (FTP'ing to a HP3000) Security Issues:
1). If in-bound FTP is enabled, any user on the Internet can access your system without entering passwords if you do not take precautions. In-bound FTP does not execute logon UDCs. Any user that does not have either a MPE user or account password (LISTUSER @.@;PASS) can be used to gain FTP access to the HP3000 without entering a password. Security/3000 passwords are not used since these are executed with a logon UDC.
2). Once a user has gained FTP access, they can not only retrieve (get) files, they can also replace (put) files. They can not retrieve or replace databases or KSAM files. They can replace some executable programs, UDCs and other files.
In-bound FTP precautions:
1). Don't enable in-bound FTP. In-bound FTP is not automatically enabled. It will only go into action if you enable it. (STREAMX JFTPSTRT.ARPA.SYS).
2). If you enable it, modify the job so that any in-bound FTP access will require a MPE user and/or account password. Modify line 37 of JFTPSTRT.ARPA.SYS to read:
RUN ftpmon;info="password"
You should also add SF capability to the user FTP.SYS
This obviously is more secure than no password, but by enabling in-bound FTP you still give the opportunity for someone to access your system by entering a correct password.
3). Enabling in-bound FTP is not necessary as you can use out-bound FTP and "get".
Minisoft's Network File Transfer
Security issues also exist with Minisoft's Network File Transfer (FTJOB.NFT.MINISOFT). If you are using this, any Minisoft NFT user can gain FTP access to your HP3000 without entering a password. It appears that regular FTP users can not access your HP3000 as Minisoft's NFT is using a different port number. However, if they know to use this port number, they will have access.
Minisoft has not yet addressed the security issue with their NFT.
Do I need in-bound FTP?
No, you do not need in-bound FTP on your HP3000.
KS
The file BLDPARMS.ARPA.SYS contains the default parameters for inbound FTP transfers to the 3000. The first three lines of the file look like this (the file has more, but the rest is comment; only first three lines are read). Note that default for ASCII files is an 80-byte record like you are ending up with.
;REC=-80,,F,ASCII;DISC=204800 ;REC=-256,,V,BINARY;DISC=204800 ;REC=,,B;DISC=16384000
As long as you don't violate limits of the MPE BUILD command, you can change these defaults as you wish (at least I think the BUILD command limits are the only ones you have to be concerned about).
You can also make local copies of this file and point at that by doing:
FILE BLDPARMS.ARPA.SYS=myfile
RFA was a part of the NS/3000 (Network Services) package for HP3000s. It allows a program to open files on other (networked) HP3000s as if they were local files. Simple file equates can specify :FILE x=y;DEV=nodename#disc or fopen could be passed "environmentname#filename" to open files, after which all read/write/update actions could be performed as if the files were local. Even Image databases could be accessed this way, and there is even a facility to create what looks like a local database, but which in reality is a pointer to a database on another system. Applications could run without modification on what appeared to be a local database which actually accessing a database on another system. Neat, though often slow because of significant overhead built into the filesystem. (This feature is called "RDBA" and is a subset of RFA.)
NFS is a means to access files and directories on other (networked) systems. Common in the Unix world (and inherited in the PC/Windows world) NFS is also available for the HP3000 through software developed by Quest and marketed and supported by HP. Users can "mount" remote file systems, and access files on remote systems as easily as local files.
printing to printers on remote systems requires:
In MPE/iX release 5.5, users are able to print directly to printers on their network equipped with JetDirect cards; you'll configure these printers as (pseudo) spooled printers on the 3000 using a special config tool/command file provided with MPE. A configuration file called "NPCONFIG.PUB.SYS" contains control information for the actual printers - including their IP addresses and TCP port numbers. Look for sample configuration files called "NPSAMP@.PUB.SYS" which you can use as a basis for your own setup.
The big caveat; HP *really* wants you to use JetDirect cards for remote printing from your HP3000. The built-in network printing capability in MPE/iX 5.5 "supports" only HP Jetdirect cards. Part of this requirement is the fact that the network printing solution makes extensive use of the SNMP network status options that the Jetdirect card supports (and most other network printing cards do not). An (undocumented?) workaround for some network printer cards is to add a "snmp_enabled=FALSE" setting to the printer's entry in the NPCONFIG file. This disables the SNMP controls used, but also means that you lose page-level recovery and other printer control features.
If you need LPR/LPD remote printing, you'll need to look up one of the third-party spooler vendors. Check the vendor/product directory on this site for a list of vendors and products.
A freeware solution (if you only have *1* network printer) is the IPS spooler program from SMM Ltd. which runs on MPE/iX 4.0 and later. You can pick this package up in the public domain software area of this web site.
CB
*You need a (relatively recent) version of R1 (Reflection)
1) Using your web browser, save the file from jazz to your local pc/mac
[In some broswers you just click on the link; other browsers you may
have to click the right-mouse button on the link to download]
2) Using R1, select file-transfer, hit the "Setup" button, then pick the
"WRQ/Reflection" folder/card, and make sure "transfer type" is "binary".
3) then select the "attributes" button on that screen.
Under "File Attributes" set the following boxes:
Blocking Factor:[ 1]
File code: [1030]
(leave the others blank)
Domain should have "permanent" selected
Record type should have "binary" selected (this is not the default)
File type should have "standard" selected
Record format should have "fixed" selected (this is not the default)
then select "ok" to close the attributes window
and "ok" again to get back to the file transfer window
4) Name the destination file and transfer it to the host. When the transfer
is complete, the file will be an executable NMPRG file.
Enjoy...
3k Associates provides the only native SMTP/MIME (Internet mail standard) mail server for HP 3000s; NetMail/3000. NetMail/3000 provides SMTP/MIME compatible e-mail for HP terminal or emulator users, as well as batch jobs. 3k also provides an SMTP/MIME mail gateway for HPDesk sites (called DeskLink), and a POP2 and POP3 mail server for mail clients like Eudora, Microsoft Exchange or Outlook, Pegasus, or Netscape. 3k also offers a API (application programming interface) package where you can initiate e-mail messages, retrieve messages, and query the mail directory from your own applications. Get info or a free demo of the mail package from http://www.3k.com/ .
3k has released a FREE 2-mailbox version of NetMail/3000 - fully Internet capable (no expiration). Get it off our web site at http://www.3k.com/
Now, any HP3000 running MPE/iX 5.0 or later can e-mail to any SMTP compatible system(s) - including the Internet.
There exists a freeware mail client (which requires a 'smart' smtp server) from Telamon at their web site. This client allows you to do simple message "sending" (no receiving).
Sendmail has also been ported to the HP3000. Mark Bixby's web site has the entire distribution which you can retrieve.
CB
HP3000's with LanLink software (or any MPE/iX 5.0 or later system) include
the incoming VT(virtual terminal) protocol server. This allows telnet-like
connectivity, though the protocol (VT) is just different enough from telnet that
to VT to an HP 3000, you'll need special software. [MPE/V systems also require
an optional lan card; MPE/iX systems all include lan cards standard]
To
VT into an HP 3000, you use:
1) From another HP 3000 (equipped with
NS/3000) the :DSLINE command
2) From a PC or Mac equipped with a lan
card/connection to the same network as the 3000;
-A TCP/IP stack
on the PC/Mac
-A terminal emulator package that includes VT
(virtual terminal) capability; WRQ's Reflection, Unison/Tymlabs' Business
Session, Minisoft's MS92, or HP's AdvancedLink
3) From an HP9000; use the
vt3k program
4) From other Unix systems; pick up a copy of the freeware
"freevt3k" program from http://www.anime.net/freevt3k/ (there
is also a FAQ on freevt3k there)
Some important notes/warnings about inbound NS/VT access to your HP 3000. Incoming connections come in on tcp port 1537 or 1570 (depending on the type/revision of accessing client. Be sure to restrict these ports in your firewall/router if your 3000 can be accessed from the Internet. When you bring up network services on your 3000, the vtserver comes up by default (you may not even be aware that you're presenting a ":" login prompt to anyone on your network).
Telnet on the HP3000
[MPE/iX systems]
No, not directly. Currently (in the world of RELEASED software at least) CB HP3000s can't be telnet'd INTO. The supported means of using telnet to connect to a HP3000 actually has you telnet'ing to a DTC with a telnet access card in it; this DTC then makes the equivalent of a DTC direct- connect (serial) connection into your HP3000. (Actually the connection uses the ACP/ADCP low-level protocol, and the resultant session is indistinguishable from a hard-wired DTC-terminal connection.)
***** Inbound telnet *is* available in MPE/iX 5.5 running under the inetd job.
RG
Telnet server on MPE 5.5 with PP3 is fully functional and works well (although there is a cpu hit, especially compared to DTC connections).
CB
Note that the telnet access card is an optional piece of hardware (it costs $$$), and if you plan on using it you must also plan on using Openview DTC manager to configure the DTC (you can't configure it using host-based configuration aka NMMGR).
For the technically minded, the problems with this solution are that, unlike host-based solutions, people telnet'ing in must telnet to a different IP address (NOT the IP address of the host computer, but the IP address of the DTC). This is not usually a big issue, as most people specify hosts by name (rather than address) but it can lead to confusion if you implement OTHER host-based services on the 3000 (like FTP or SMTP-email or Gopher...). There are also limits to the number of concurrent sessions each card can handle, and overflows (when you exceed the max# of connections for one card) must be handled by other cards (with other IP addresses).
Another possibility is the contributed NQTELNET program written by Eric Schubert of Notre Dame. NQTELNET is a host-based telnet server which will handle basic terminal operations (but not block-mode apps).
Description/info below provided by Eric Schubert (author): "Free software, no warranty: user assumes all responsibility." VERSION.: 94.9.6 (Works on MPE/iX 4.0) FEATURES: (1) Obtains Telnet Client Terminal type using sub-negotiations and switches into VT100 emulation mode automatically if termtype is not "hpterm". (2) Server negotiates client for non-echo (*Line*) mode after login, (3) Client can negotiate echo mode or non-echo mode anytime (allowed), (4) Menu controlled login (does not default to MPE access), (5) User login Limit bouncer (1 to 100 users config) (6) *Unattended* Terminal Time-out (config to any value on server), (7) Virtual Session "login" using NS3000 (optional), (8) Server activity/trace log prints to $stdlist. GENERAL LIMITATIONS: () General: This server uses an MPE Message file interface between the server and user application program. This results in some problems with user programs that open LDEV numbers directly or check whether the input is an interactive pair. Maximum I/O record length to 256 bytes, the default size of the message files. However, source is provided for the user to make changes for their particular needs. The author is not responsible for code modifications. LOOPBACK must be enabled. Tested software that works with either VT100 or HPTERM telnet clients without user program modification (the stuff we telnet out of our HP3000) using the NS/3000 logon option: ---- QUAD TRANSACT character mode screen Many MPE commands work (the CI thinks it is in batch mode!) except LDEV specific ones, such as "DSLINE". ...I'm sure many more... ---- SPECIFIC LIMITATIONS: (1) Terminal emulation of VT100 clients is limited to absolute cursor positioning, character screen control (home, clear, next page, etc.) and text highlights (blinking, inverse, etc.) (2) Some Telnet clients mis-behave when echo is turned off. NQTELNET allows the user to enable echo mode anytime using ctrl-a. (4) Uses a standard AFS login format, such as: Login: xxxxxxxx (max 8 chars) Password: xxxxxxxx (optional, max 8 chars)
The "xxxxxxxx" identifier must be equated to an HP LOGON within the server job/session. HP logons are never used to enter host server.
(7) Virtual Sessions are only created under NS/3000 "DSLINE" command. Otherwise, inbound connections use processes under one common logon.
Any enhancements/comments welcome, send Email: eric.j.schubert.1@nd.edu
NQTELNET is a contributed (free) package and available via anonymous ftp from opus.admin.utc.edu.
CB
The light at the end of the tunnel is that HP has announced that all customers on support will receive a *free* (aka 'bundled') telnet server which will run entirely on the HP3000 (software only) and will be made available at some point after the 5.0 PUSH release.
LH
The TELNET/iX product consists of two parts, a client, which provides outbound functionality, and a server, which provides inbound. The name was changed from Host-based Telnet to TELNET/iX because people thought that "host-based Telnet" was a product to provide host management and configuration of the DTC TAC (which is functionality that TELNET/iX does not provide). TELNET/iX will be implemented entirely in software on the HP3000; neither a DTC nor a PC (OVDTCMGR) are needed. TELNET/iX is a part of the Well Behaved in a UNIX Environment Solution Team.
CLIENT:
The TELNET/iX Client provides outbound functionality from an HP3000 to a server host that supports the TELNET protocol. There is no additional NMMGR configuration. Also, a new manual, "HP TELNET/iX Client User's Guide" (Customer Order Number 36957-90152), has been written.
SERVER:
The TELNET/iX Server will provide inbound functionality from any TELNET client to an HP3000, similar to the DTC TAC functionality. The DTC TAC product will continue to be offered for customers with a lot of TELNET traffic as the DTC TAC solution offloads the host CPU.
CB
An important note about telnet; telnet is a generic networking protocol used to communicate between a user and a remote host. It does NOT define terminal emulation sequences. In fact, though any telnet client can connect to any host supporting inbound telnet, if you try to run applications on the remote host that don't support the terminal type you're using (or that which the telnet client you're using emulates) you're out of luck. This is especially an issue to HP3000 sites. Most applications on 3000s today (especially V/Plus) require that the user running them be on an HP terminal (or that their emulator program do a REAL good job of emulating a HP terminal). However, most free (or commonly available) telnet clients out there DON'T do HP terminal emulation. In fact, most do only generic ANSI/ASCII displays or emulate DEC's VT100 or VT2xx family of terminals. V/Plus apps won't like a VT100 terminal, so if your users trying to log in need to run your fancy HP apps, better either make sure they have a telnet client that emulates HP terminals, or that all the applications they CAN run are compatible with whatever they're using.
Now, for OUTBOUND telnet;
Right from your 3000, you can run the contributed (by Dave Elward of Taurus Software) telnet client program and initiate a telnet connection to any remote host with no special hardware or software. It requires LanLink software on the 3000, which you already have if you have any kind of networking software (NS/3000 or FTP); if you don't, you'll be getting it free with the 5.0 PULL release so not to worry. Dave's telnet client can be run from the MPE prompt and allows you to open a connection (using the telnet protocol) to a remote system, log in to that system, and execute commands as if you were logged in locally. (just like the :DSLINE/:REMOTE commands from NS.)
Dave's telnet program is free and is available via anonymous ftp from opus.admin.utc.edu or ftp.3k.com. Dave's telnet client is a native mode application and will run one MPE/iX 4.0 or beyond (maybe some older MPE versions as well?)
Also coming with the 5.0 PUSH release (or sometime shortly after?) will be a host-resident telnet client, so you have your choice.
Also, if you're using OpenView DTC Manager and your DTC datecodes are recent (>=3118?) then any serially connected terminal user can be allowed (if the port is switchable) to telnet to a remote host (any reachable host that supports inbound telnet).
[MPE/V systems]
Inbound telnet (host based!) as well as a MPE/V based telnet client are available from The Wollongong Group; WIN/TCP for MPE/V. The package includes a telnet server (host based) and client, ftp server and client, and an HPDesk to SMTP gateway.
Through the availability of FTP, Telnet, SMTP, NFS, and other protocols brought to us from the Unix world, HP3000s can easily interoperate with Unix systems of all flavors.
HP offers Netware/iX - a native (MPE) version of the Netware server. It allows all the functionality of pc-based versions with the notable exception of NLMs (there are no MPE NLMs). Also, users have noted that the performance never approaches that of a dedicated high-end PC server, but the additional accessibility of files (shared between MPE and PCs) and the ability to share printers on the HP 3000 with PCs on the network.
Newer HP3000 models include a built-in CDROM drive. Intended primarily as a medium to distribute MPE releases, some software was also developed to allow the CD to be accessed over a network - intended to allow shared access to the LaserRom (CD manual set). A neat idea, but as the client software requires TSRs and DOS-based networking stacks, modern PCs with Winsocks (typically dll-based now) could not access them. On top of that, the few sites that tried the software reported that performance was not good and a PC based server was much more economical (and efficient).
To talk to other network processes from MPE, you have two APIs from which to choose; NetIPC (proprietary to HP3000s but callable from all MPE-based programming languages), and the newer "open" Berkeley sockets interface, callable only from "C". Both perform basically the same function, and in fact call the same low-level routines, though the Berkeley sockets API does allow access to UDP-based functions which NetIPC does not.
SS
"HP Sockets" is the short form for the product called "Software Integration Sockets". I view it as a method of pasting together applications that don't know about each other, potentially across machines in a network. As such, you can describe (via a meta language) the data structures of two programs (perhaps binary, perhaps ASCII (e.g.: from a report generator), and it will generate conversion code. It does data conversion (e.g., ascii to binary or packed decimal) and understands the data types/structures used by FORTRAN, COBOL, C, & Pascal. It also handles asynchronous messaging between machines, if necessary.
NetIPC is a programmatic interface to call networking (socket) routines from a programming language on the 3000. Socket routines allow inter- system data transfers. NetIPC allows most of the same functionality of berkeley sockets (BSD) but is a proprietary calling interface invented by HP. A notable exception is that NetIPC does not allow access to UDP/IP primitives where BSD does.
BSD is a programmatic interface to call networking (socket) routines from a programming language (designed to be called by 'C' programs). socket routines allow inter-system data transfers. BSD is commonly used on a variety of platforms (coming from the Unix world) but is not easily accessed from languages other than 'C'. BSD allows access to both TCP/IP and UDP/IP protocols.
The NSINFO intrinsic (when called with $BACK as nodename) will return the nodename of the machine from which the logged-on user is connected (for users logged in via network connections over a TCP/IP network) You'll get an error from NSINFO if you're not a VT session.
EL
If you are interested in IP address and have the 5/94 edition of the "Using NS3000/iX Network Services" manual, it documents item #38 that can be used to retrieve an IP address associated with an NS environment. All NS services (VT as well) have a predefined environment "$BACK" that refers to the originator of the connection (i.e. one hop back). If you as for item #38 on environment $BACK, you will get the IP address.
ER
Just do an: SNMPGET ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.(the ip address) or an SNMPGET at.atTable.atEntry.atPhysAddress.2.1.(the ip address) both of the above nicely return the media address.
Explanation on HPSTDIN_ and HPVT_ CI-variables
EL
Due to lack of help text and multiple customer requests, here's a
detailed explanation of those CI variables set by the VTSERVER
process on MPE/iX 5.5 and later. These same variables appear
in some earlier versions of MPE/iX, providing that appropriate
NS services patches have been applied.
Note that as the number of 3rd party VT providers has increased,
not all previous versions will be able to properly identify all
client types. New client types have been added all the time,
latest additions in a yet unreleased patch (NSSED78A).
03/18/1996 Eero Laurila - HP CSY Networking lab, NS services, VT.
Variable Types
==========================================================
R READ ONLY variable (cannot be modified).
W READ/WRITE variable (can be modified).
JCW A standard MPE/iX JCW.
I Integer format.
B Boolean format (TRUE/FALSE).
S String (ASCII) format.
(NP) Not programmatically accessible. They may be
accessed through the COMMAND or HPCICOMMAND
intrinsics, but not with the HPCIGETVAR,
HPCIPUTVAR, and HPCIDELETEVAR intrinsics.
HPSTDIN_... CI-variables
========================
These variables are intended to be variables that could be set by any type
of connection to the HP 3000 system. As such, they are named using a very
generic name HPSTDIN_..., only reflecting the fact that the only thing they
describe is how and where from the access to file $STDIN was established.
Although NS/VT is currently the only subsystem on HP 3000 using these
variables, it should be noted that they are intended for wider use and
should convey no VT specific information - HPVT_ variables are for that
purpose. Should other subsystems desire to convey some of their own
internal information in CI-variables, they should allocate their own
and start all variable names with "HP" to avoid conflicts with customers'
own variables and to conform to HP's predefined CI variables naming
conventions.
Variable Type Definition Initial Value
--------------------- ---- ---------- -------------
HPSTDIN_ACCESS_TYPE S Type of connection used to gain NS/VT
access to file $STDIN. Currently
only VT sets this variable, i.e.
the only setting at this point
of time is the initial value.
Other values that were discussed
for this variable were such as
X.25 PAD, DIRECT, MODEM etc.,
however, no other subsystem than
VT currently sets this variable.
HPSTDIN_TERMINAL_TYPE S Describes the terminal type as 10 (T_BLOCK(3))
the VTSERVER process sees it
(i.e. what has been reported for
the terminal type from the
remote side) as well as VT's
internal terminal type VT has
mapped the actual termtype into.
Contents of this variable is as
follows:
NN (text(MM)), where:
NN = actual terminal type number
shown with MPE/iX - MPE/iX
connections, where both
machines are running VT-
protocol version nine(9) or
greater. Set to zero for
all other types of clients.
This information was added
to initial VT-negotiation
and was not conveyed in
previous versions of VT.
VT protocol version 9 was
introduced in patches:
MPE/iX 4.0 : NSSDDP3
MPE/iX 5.0 pull: NSSDDQ0
MPE/iX 5.0 push: NSSDDQ3
and their successors.
text = VT internal mapping to
which all terminal types
are folded.Possible values:
T_UNKNOWN
T_BASIC
T_SCROLL
T_BLOCK
T_DATA_ENTRY
(from 0..4,correspondingly).
MM = internal numeric value
corresponding to mapped
termtype string(this is the
integer value assigned to
above enumeration by the
pascal compiler).
HPSTDIN_TRANSPORT_TYPE S Describes the underlying network TCP/IP
transport type used to carry the
data between the HP3000 host and
the client.
Other values that were discussed
for this variable were such as
ADCP/AFCP (DTS terminal I/O),
SPX/IPX (Netware clients),
Appletalk (Appletalk clients),
SNA (IBM/SNA connections)
BSC (IBM/BSC connections)
etc.
however, no other subsystem than
VT currently sets this variable.
HPSTDIN_NETWORK_NODE S Describes the name of the node No default.
as appropriate depending on the
type of network and transport in
use (NS, SNA, Netware, Appletalk
etc. networks).
Note that at the moment no other
subsystem than NS/VT sets this
variable, i.e. the only type of
nodename that will be seen in
this variable is what the VT-
client sends to the HP 3000 (NS
nodenames).
HPSTDIN_NETWORK_ADDR S Describes the network address of No default.
the $STDIN accessor in a format
appropriate to the type of
network and transport in use. In
case of TCP/IP network (and a VT
client), this field will contain
the IP-address of the remote
computer accessing $STDIN.
Note that at the moment no other
subsystem than NS/VT sets this
variable, i.e. the only type of
network address that can be seen
in this variable is an IP-
address.
HPSTDIN_LINK_ADDR S This variable is intended to not set yet...
be used for showing the level-1
address of the client (or the
closest to HP 3000 host network
device) sending link level data
frames to the HP 3000.
Currently this information is
not available to the VTSERVER
process and thus the variable is
set to "not set yet...".
The variable has been allocated
so that when/if the network
transport makes this information
available to a process, this is
where it would be stored.
The link address should be
displayed in format appropriate
to the type of networking h/w
in use. For LAN networks this
CI-variable would contain the
station (or MAC) address, for
other networks their correspon-
ding level-1 address.
HPVT_CLIENT_... CI-variables
============================
These variables are specific to NS/VT service and will be set by the
VTSERVER process on VT connections only.
Variable Type Definition Initial Value
--------------------- ---- ---------- -------------
HPVT_CLIENT_VENDOR S Shows the vendor-id that was No default.
sent to the VTSERVER process in
the first VT negotiation packet
from the remote VT-client. As
of 3/1996 the following VT-
client vendor-id's are known and
defined in NS services(5.0 patch
level NSSED78A or later):
VENDOR_UNDEFINED
HEWLETT_PACKARD
UNISON_BUSINESS_SESSION_FOR_WINDOWS
UNISON_BUSINESS_SESSION_FOR_MACINTOSH
WRQ_CONNECTION_3000_FOR_DOS
WRQ_CONNECTION_3000_FOR_MACINTOSH
WRQ_CONNECTION_3000_FOR_WINDOWS
SLC_IX_CONNECT_FOR_HPUX
SLC_IX_CONNECT_FOR_SCO_UNIX
SLC_IX_CONNECT_FOR_SUN
MINISOFT_FOR_DOS
MINISOFT_FOR_WINDOWS_16_BIT
MINISOFT_FOR_WINDOWS_32_BIT
ATTACHMATE_0
HPVT_C ...all the way to
ATTACHMATE_9
HPVT_CLIENT_OPSYS S Shows the operating system on No default.
top of which the remote VT-
client reports to be running.
The following operating systems
are recognized in NS/VT service:
CLIENT_OS_UNKNOWN
MPE_IX,
MPE_VE
RTE
UNIX,
BASIC
MS_DOS
IBM
MACINTOSH_OS
SUNOS4
SUNOS5
SCO_UNIX
Note that this item (as well as
some other ones) gets set to
what the client reports to the
VTSERVER, i.e. if the client
sends us incorrect information,
that will be shown here as sent
from the client. The VTSERVER
has no way of finding out what
the real value is/should be.
Also,in addition to the OS type,
MPE/iX - MPE/iX connections with
VT protocol version 9 or greater
also communicate the OS user
version and the processor type
the OS is running on. For
example, a possible value for
MPE/iX-MPE/iX connection is:
"MPE_IX C.50.00 - SERIES 967SX"
HPVT_CLIENT_MODE S Shows the type of the VT-client No default.
in use. This variable gets set
to indicate whether the connec-
tion was established through the
VT stream-mode TCP SAP (port
#1570), or the message-mode SAP
(#1537). Possible values are:
MESSAGE_MODE
STREAM_MODE
HPVT_CLIENT_TCP_PORT S Shows the TCP SAP (port#) that No default.
was allocated on the client side
for this VT connection. This
number is also known as the
socket address in use. Values
in this string variable are in
range of legal socket addresses,
i.e. positive short (16 bit)
integers 1..65535. The variable
contains an ASCII representation
of the shortposint value.
HPVT_CLIENT_LDEV_NUM S Valid only when the client is No default.
another MPE/iX system running VT
protocol version 9 or greater.
When set, this variable reports
the MPE logical device (LDEV)
number in use on the remote side
for the session connecting to
this machine. This can be used
to trace back to the initiator
of the session.
HPVT_CLIENT_JOB_NUM S Valid only when the client is No default.
another MPE/iX system running VT
protocol version 9 or greater.
When set, this variable reports
the session or job number on the
remote machine that initiated
this VT-session. This can be
used to trace back to the
initiator of the session.
HPVT_CLIENT_JOB_NAME S Valid only when the client is No default.
another MPE/iX system running VT
protocol version 9 or greater.
When set, this variable reports
the session or job name on the
remote machine that initiated
this VT-session. This can be
used to trace back to the
initiator of the session.