1996 HP1000 Guru Column Q: I have just installed my 6.2 RTE-A update and I am getting the following error on my 12040D mux console: IO Device error on LU 1 Reason is: Illegal request Request has been flushed I did not make any changes to my mux configuration or welcome file. What is causing this? A: The 12040D mux driver changed at 6.2 and this change is apparently incompatible with older D mux firmware. The solution is to replace the 12040D mux firmware with the latest 5.22 revision, part number 5181-8682. This problem has been seen with revision 5.02 and older firmware. This is good time to remind folks that they should check firmware revisions at least at each update to see if anything important changed. In this case, this behavior was not noticed on most systems, because they had current firmare. But many systems may have older firmware that may not be compatible with newer versions of the operating system. Chapter 3 of the RTE software Communicator contains revision information for both software and firmware. Q: I am using a NS/1000 system as a gateway between two LAN networks. I find that some systems cannot PING across the gateway. This worked before and the only change was updating to 6.2. Did something break? A: Unfortunately, yes something did break. It turns out the gateway machine has a problem with IP addresses of the form: xxx.xxx.000.xxx. The problem was traced to an error in the code which checked the IP address in order to determine which network to forward the packet to. The 000 in the third byte was misinterpreted as being an invalid address and the gateway would then drop the packet. A patch is available from the Response Center for this and other 6.2 problems. Q: For years I have been frustrated by PROMT and CM. PROMT is hardcoded to run at priority 3, which is high enough to interfere with some of my realtime high speed data collection. PROMT also schedules CM at a priority of 2, which aggravates the issue even more. Is this being looked at? A: Looked at and fixed! As of 6.3, you will be able to alter the priority of PROMT (and also CM) at link time. And the priority will stay that way. To change the priority of PROMT, RP it and set its priority with the PR command in the welcome file. Alternatively, you can use the LINK LK command to reset PROMT's priority permanently. This sets the priority of PROMT and indirectly, also CM. When PROMT schedules CM, it gives CM a priority one higher (one lower numerically) than it's own. So if PROMT is running at a priority of 10, it will give CM a priority of 9. This is only recommended if you need to lower the priorities of PROMT and CM for realtime considerations. In most cases, it is important for PROMT and CM to have high priorities so that they can interrupt processes and allow user control. If you want a pre-6.3 version with these changes, contact the Response Center. Q: I am using a block mode application for most of my user terminals. On occasion, one of the users will disconnect from the system without exiting the application, thus leaving the terminal port in block mode. I cannot get the terminal port reconfigured to line mode so that other users can logon to that port. Is their a way to set a disconnected port back to line mode? A: The usual way to reset a mux port to character mode is to use the HpCrtCharMode call. The way this call works is as follows: First the proper escape sequence is sent to the terminal to put the terminal into character mode. Next, a driver control request is issued to read the terminal straps, and set the driver to match the terminal straps. HpCrtLineMode and HpCrtPageMode behave similarly. The problem is these calls require that a terminal be connected for them to complete successfully. Note that these calls work on both 12040 mux ports or TELNET pseudo LUs. If you really want to reset a port to character mode in the absence of a connected terminal, the program in Listing 1 can be used. This program will simply set DVT word 20 to an octal 77, which configures the driver for character mode. Listing 1 --------- FTN7X,L,s * * Program to reset DVT20 to 77b (Character mode) * We simply obtain the address of DVT20 for the * given LU and write a 77B in that location in memory * program reset_port implicit none $alias /luta/='$LUTA',noallocate $alias crossload='.XLA',direct common /luta/luta integer lu,dv20,lutbl,Address_of_dvt,addr integer luta,CrossLoad, AddressOf,ixget,ixput integer iftty,int c Ask for terminal LU to reset write(1,*) 'Enter terminal LU:_' read(1,'(i3)') lu int = iftty(lu) if(int.eq.0) then write(1,*) 'LU not interactive' goto 999 endif c get address of lu table lutbl=crossload(luta) Address_of_dvt = ixget(lutbl+(lu-1)) dv20 = ixget(address_of_dvt+19) write(1,'("Value of DVT Word20 is ",o6)') dv20 addr = (address_of_dvt+19) write(1,*) 'Setting DVT20 to Octal 77 - Character Mode' c Note: IXPUT is undocumented and unsupported call ixput(addr,77b) write(1,*) 'Done!!' 999 continue end Q: I have been using the LP spooler on my 1000 to handle incoming print jobs from a 9000. This has all worked fine until recently when I changed the hostname on the 9000 from a single name, 'bones' to a fully qualified name, 'bones.mayfield.com'. Now the LP spooler can't seem to find the files to be printed on the 1000. When I look in the /usr/spool/lp/request/ subdirectory, I see filenames as follows: CA110BONES.MAYF DA110BONES.MAY and the LP spooler complains with: Lpout: No such file /usr/spool/lp/request/locallj/cA110BONES.M A: The LP spooler as written could only handle single field hostnames and only 8 characters max. Because ARPA standards allow multi-field hostnames, this defect has been corrected. Since the RTE file system uses the "." as a special character delimiting a filetype extension, what you will now see in the /usr/spool/lp/request/ directory are filesnames as follows, where the "." has been replaced with a ) : CA110BONES2)MAY DA1011BONES2)MAY A patch for this is available from the Response Center Q: Does HP have a RTE to HP-UX migration product? A: Yes, late last year HP introduced the B3888AA product which is a tool designed to aid in the porting of RTE-A FORTRAN code to HP-UX. The product consists of a Migration Analysis Tool, MAT, a Migrator program, FTNMIG and a Migration Library. MAT examines source code and provides statistics to help determine the amount of effort in porting the source to HP-UX. FTNMIG assists in the actual conversion process by converting code for use with f77 on the HP-UX host. The Migration Library contains over 100 HP-UX routines using the same calling sequence as RTE-A which can greatly reduce the time and effort to migrate a program. This product runs on HP-UX. It has been requested for either MAT or FTNMIG to run on RTE-A, but this most likely will not happen. I have successfully used the tool to migrate a 400 line FORTRAN program to HP-UX, with a minimum of effort. Only one RTE-A system call required manual editing in order to successfully compile and load the program. Other than that, FTNMIG performed all changes required. If you are interested in more information on the B3888AA product, contact you local HP Sales office, or call (408) 447-6622 for direct HP1000 product information. Q: I am trying to get a printer to work on my C MUX. I want to use XON-XOFF protocol, not ENQ-ACK. I have all the proper CN commands to disable ENQ-ACK and enable XON-XOFF. When I use a datascope to monitor the RS-232 line, I still see an ENQ coming from the MUX. What is wrong? A: This question brings up a curious fact about the 12040A/B/C MUXs. The MUX can perform what looks like a "double" ENQ-ACK. This is because both the driver AND the firmware can be told to ENQ-ACK independently of each other. The standard CN,lu,30B command will enable ENQ-ACK in the firmware. The driver can also be made to ENQ-ACK handshake via bit 0 of driver parameter 1.This is documented in the Driver Reference Manual, appendix J (part number 92077-90011) under driver parameters. The manual also states that you should NOT set bit 0 to enable ENQ-ACK It states to use bit 7 of the CN 30B. The confusion arises because all the default gen record files for the C Mux set bit 0 of DP1. Thus, the MUX driver is always set to ENQ-ACK handshake regardless of the CN,lu,30B command. Thus if you use the default gen record, the driver will ENQ-ACK. The following CN request will disable the driver ENQ-ACK by modifying DP1: CN,lu,44b,parm where parm is the desired value of DVP1. See Table 1 The following are the recommended DVT entries for HP terminals and printers on the C MUX: Terminal on a C MUX: dvt,/rte_a/%dd*00,M26XX,LU:130,DP:1:20004B,TX:57,- DP:5:CI:20040B:20040B:0,DP:9:CM:20040B:20040B:CM Printer on a C MUX: dvt,/rte_a/%dd*00,M2631,LU:131,DP:1:2,TX:57 With these gen records, you will be able to set/change the handshake protocol with CN30B/34B requests as needed. Table 1 Terminal Configuration Format in DVP1 ---------------------------------------------------------- Bit 15, PM, page marker bit 1 = Writes escape underscore on end of each write. 0 = Normal. Note: This bit tells the driver to append a non-displaying terminator at the end of each write. It is set using an EXEC 3 with function code 44B. Bit 14, ASCII bit 1 = 8 data bits (Katakana, Roman 8) 0 = 7 data bits (Normal, vs ASII) Bit 13, Termination bit 1 = Binary read only terminated by char count 0 = Binary read terminated by count or "CR" Bits 12 - 6, Not used Bit 5, FB, Flush Input Buffers (Multiplexer): 1 = Flush both MUX input buffers before issuing a terminal status request (CN 25B). 0 = Do not flush MUX input buffers before issuing a terminal status request. Bit 4, SE, Suppress Transmission Error Message (Multiplexer): 1 = Suppress issuing transmission error message in case of a buffer overflow on this port. 0 = Do not suppress issuing transmission error message in case of a buffer overflow on this port. Bit 3, Page strapping bit 1 = page strapping 0 = line strapping Bit 2, LF, controls Line feed for special character CR, if echo bit set in control word (required for multiplexer operation): 1 = Disable line feed (the MUX firmware takes care of line feed) 0 = Enable line feed Bit 1, FF, contains status of terminal Form Feed: 1 = Form feed enabled for terminal. 0 = Form feed not enabled for terminal. Bit 0, ENQ, contains status of ENQ/ACK Handshake: 1 = ENQ/ACK handshake enabled. 0 = No ENQ/ACK handshake. Do not use Bit 0 to enable ENQ/ACK when using DD*00 with MUX driver IDM00. Bit 7 of CN30B should be used on the MUX. ------------------------------------------------------------------- Q: I am trying to connect a modem to my 12040D mux and am having problems getting it to work. I am trying to set the baud rate to 9600 with the modem bit set in my CN30 call as follows: CI> CN,127,30B,020137B But when I do this, I get the following error: I/O device error on LU 127 The reason is: Invalid Request ( Bad Parameters ) Request has been flushed What am I doing wrong? A: What is not clear here is that by itself the 12040D mux cannot do any modem control. All eight ports on the mux only have pins 2, 3 and 7 active. The modem control lines, 6(DSR), 8(DCD) and 20(DTR) are all jumpered together in the panel, as are 4(RTS) and 5(CTS). Since there is no modem control available, you cannot set bit 13 (the modem bit) in the CN30 intialization command. A note in the Driver Reference Manual makes mention of this limitation. Modem control is only available on the A400 OBIO (ports B and C), the 12005 ASIC card or a 12040D with a 37214A Modem Card cage. The 37214A is a long obsolete card cage which takes the place of the 12040D 8 port mux panel, and allows the use of various internal and external modems and terminal connections, and has modem control capability. Since modem control is not available on the 12040D mux by itself, connecting a modem requires no special configuration. The port should be intialized as if a terminal were connected, and the modem is then connected using a 2/3 swap cable. The modem should be configured to assert DSR always. It is up the the user to manually disconnect the line when logging off. HPMDM cannot be used since modem control is not active, and HPMDM requires this. Q: What is RMTERM? A: RMTERM is a Remote Virtual Terminal program for A series systems. It has two main functions: 1: It allows serial access from a 10240D mux port on a host system, to a remote system via RS232. The remote system can have either a 12005, 12040A/D mux or OBIO. When you run RMTERM from the host, you become a virtual terminal to the remote system, through the D mux on the host cpu. The remote can actually be any computer you wish to communicate with. I have often usd RMTERM to dialout a modem on my RTE-A system to connect to a remote computer. 2: It allows downloading of memory based op-systems from a 12040D mux on a host system, to a 12005 or OBIO, VCP-enabled, port on a remote system. The remote system must have a 12005 or OBIO because RMTERM makes use of the %BCT command from VCP, which is not supported on the 8 channel mux. How to Use RMTERM ----------------- When you run RMTERM, you specify the LU for the communications link, and the baud rate. For example, CI> rmterm,126,9600 LU 126 is port six on the mux & 9600 baud CAUTION: Do not run RMTERM from the VCP terminal on the host, RMTERM needs the break key for its own purpose. You don't want to halt the the host. Either use a non system console terminal, or disable BREAK on the cpu. RMTERM then gives you a header showing the LU you are using and the baud rate. If you are connected to the VCP interface of a remote A Series you are now the VCP terminal on the remote. You can execute any VCP command, such as booting the system. To perform a download of a memory based op-system to the remote from the host use the following: CI> rmterm,126,9600 >>>> Run RMTERM Hit break on the terminal. You now have the following 4 options: 1. B = Break remote 2. L = Leave RMTERM program 3. D = Download to remote 4. Any other character to continue RMTERM To do the download, type: B (to make sure the remote computer is in VCP mode) Now hit break again, and type: D . RMTERM then prompts for the following: Type 1 file to download: -- Enter a type 1 filename resident on the host. Select code to boot from: -- Enter the select code of the IO card in the remote. RMTERM now tells you it has started the download, the time of day, and the memory size in blocks that is being downloaded. Downloading ARSTR took less than 5 minutes at 9600 baud. Points to Remember ------------------ 1. RMTERM only works FROM a 12040D mux or A400 OBIO mux. Both the terminal executing RMTERM and the communications port must be a D mux or OBIO. 2. For virtual terminal operation, remote can be 12005, OBIO or 12040A/B/C/D mux, or just about any other computer. 3. For downloading, remote must have a 12005 or a OBIO (A400), enabled for VCP. This is because the download makes use of the %BCT command from VCP, and the mux has never supported loading from cassette tape. 4. Documentation for RMTERM can be found in the RTE-A Driver Reference Manual, Appendix I. 5. RMTERM source code is shipped with RTE-A software and can be customized for use with other computers or black boxes. Q: What utilities are available for downloading ASCII files via the 12040D mux besides KERMIT or XMODEM? A: RMTERM can be used in conjunction with a contributed program called UDOWN, in order to download ASCII files via 12040D mux. Binary files can be downloaded by UUENCODEing them first, then using UUDECODE after they have been transferred. RMTERM is used to establish a remote connection via mux, and then UDOWN is used to perform the file transfer after configuring the remote mux port as described in the help file. The following is a description of UDOWN: ===================== UDown.hlp =============================== UDOWN is a simple program used to transfer files to a remote HP1000. Text files can be tranferred directly and binary files can be transferred by use of the UUENCODE and UUDECODE programs. UDOWN's main virtue is that it does not require anything special on the receiving end, other than a CI command file which is simple enough to be entered via the console. This is an example of the command file needed on the receiving end of the link used by UDOWN: ---------------------------------------------------------------------- * Download.cmd Rev.6100 ANT <:00218.1054> * This command file is used to configure the 8-channel MUX port for * use with UDOWN, the UUENCODE DownLoad utility. A MUX port is * required, as the FIFO is needed to keep up with the incoming data. * Edit the file as needed to specify the correct LU for the MUX * port that you are using. cn $LU 21b ,,,, turn off prompt cn $LU 34b 5 ,,,, CPU-CPU + Xon/Xoff cn $LU 33b 100000b ,,,, FIFO enabled sport $LU ,,,, just to verify that all is well co $LU /scratch/pu_me.uu d ,,,, and do the copy * <--- sending end runs UDOWN here ---> uudecode /scratch/pu_me.uu ,,,, decode from uu format pu /scratch/pu_me.uu ,,,, clean up a bit ---------------------------------------------------------------------- If you would like a copy of UDOWN, send email to me at my address below. Q: How much smaller is an A990 system file compared to an A900? I am tight on OS space and wonder whether upgrading to an A990 will help. A: Depends on whether the A900 is using the Rev 4 Base Set or not. If the A900 has the latest (Rev 4) Base Set firmware, then the system gen should contain the following two RPL files %RPL91 (or %RPL90) and RPL_A900_REV4.REL This fully implements all A900 firmware code. In this case, updating to an A990 system gen will NOT gain any OS space, as the A990 RPL, RPL_A990_CDS.REL (or RPL_A990.REL) is not any smaller. If you do not have the Rev 4 A900 Base Set, and you are using XMB.REL in the system gen, then updating to an A990 will gain you 241 words. This is the difference in size between the RPL_A990_CDS.REL and (%RPL91 + XMB.REL). Q: Does the PASCAL compiler have a line length limit? I seem to run into problems when my lines exceed 80 characters. I see no method for continuing lines as in FORTRAN using column 6. A: The HP1000 PASCAL compiler defaults to a line length of 80 characters. This can be changed with the compiler directive (option) $WIDTH . "char" can be in the range of 1 to 150. Q: My system seems to be filling up SAM rather quickly because of extremely high network broadcast traffic. I am not able to use the discard packet mode, because I am still running 5.27 NS. Is there something else I can do in the meantime, before I update to 6.2? A: Yes. In the interim, you can modify the packet filtering performed on the LANIC. If your 1000 system is configured for both 802.3 and Ethernet packets, then NSINIT sets the packet filter to 6. This allows Individual, Multicast and Broadcst packets to be received. You can change this value to 4, which will only allow Individual and Multicast addresses to be received. To change the packet filter use the following command cn 37B p1 -20465 where p1 is the desired value, for example, 4. Make sure this command is done after NS/1000 has been initialized. For more information, see the 12076A LAN/1000 LINK Node Manager's Manual, and the 12079A Direct Driver Access Manual. Q: What is the largest session number allowed by RTE-A? The Relocatable Library manual under GETSN indicates that the session number returned may be larger than 8 bits, but how much larger can it be. It seems I can pass any value I want when using CLGON to create a programmatic session. A: The actual limit is 319 (Note that the minimum programmatic session number is LastLu+1). GETSN will return an error (-1) if a value greater than 319 or less than (LastLu+1) is used. The problem with CLGON is that it does not check the number being passed to it. It assumes the programmer has used GETSN and validated the number being used. This is why you can actually create programmatic sessions larger than 319. These sessions can lead to unpredicatable behavior, including, in the worst case, a system crash. A crash can occur under the following conditions: 1) You create a programmatic session greater than 319 2) Your system size is just under 32767 words 3) You terminate the programmatic session. A crash can occur under these conditions because RTE keeps a bitmap in the operating system to keep track of active sessions. This bitmap is allocated by RTAGN as 20 words. Coincidentally, it is the very last thing in the 32 pages of the RTE-A OpSys. These 20 words equal 320 sessions (20 x 16 = 320) When a programmatic session is created, GETSN is responsible for setting the appropriate bit in the bitmap. When a session is terminated, either by KILLSES or a call to RTNSN, this bit needs to be cleared. The operating system does not validate the session number, so it goes ahead and clears the appropriate bit. If the session number is greater than 320, the bit is above the allocated bitmap. And if the system is just below the 32767 word limit, a memory wraparound can take place, and the A register (memory location 0) can be corrupted. This will crash the system. Not much fun to troubleshoot! Q: I need to transfer a binary file from a PC to the 1000 that has a record length of 1088 words. When I transfer the file using binary mode, the file on the 1000 winds up with a record length of 128 words. How do I do this? A: When transferring a binary file from a non-RTE machine, you must specify any desired file attributes. By default, FTP binary mode will create the target file as a Type 1, which means a fixed record length of 128 words. If you need a record length of 1088 words, you must specify a Type 2 file. For example: ftp> bin 200 Type set to I. ftp> get binary binary:::2::1088 200 PORT command successful. 150 Opening BINARY mode data connection for binary (2560 bytes). 226 Transfer complete. 2560 bytes transferred in 0.4 seconds [ 64.0 kbytes/second ] ftp>quit The file on the 1000 will look like this: CI> dl binary srn directory ::SYSTEM name blks recs rlen BINARY 10 1 1088 Q: I recently needed to restore some files from an old FST backup. When I did a DL of the FST tape, it contained the same file, "8", repeated hundreds of times. How did this happen and what can be done to recover a specific file from this tape? A: What happened here is when the backup was created, the FST command used was probably something like this: FST> BA /MYFILES/ 8 (Like a TF command, most likely) This is a legal FST BA command but the result is probably not what the user expected. Here is the syntax for the BA command: BAckup [] [] - Select files to backup. - mask descriptor for selection of disk files. - mask for destination file descriptor. - system master security code. The parameter can be any filemask. What this does is backup the files specified by "mask" and rename them "dest" In the example FST backup above, FST renamed all files in the directory /MYFILES to "8" on the tape. Older revisions of FST did not warn the user that the command entered would result in duplicate file names. Current versions of FST report the following if a BA command of the form: FST> BA /MYFILES/ 8 is used. FST reports the following: ** WARNING ** destination mask for BA command yields duplicates names. So that is what happened to create a tape with the same file name repeated. By the way, the intended usage of the parameter is for either of the following: 1) You are backing up a single file, and want the file name on tape to be different. 2) You want the directory path on the tape different than the source disk directory. For example: FST> BA /SW/REV_6P2/NS1000/ /NS1000/ will backup all the files in the subdirectory NS1000/ and put them on tape under /NS1000/ Now as for recovering a particular file of the tape. Since all the file names on tape are identical, the only way to differentiate a particular file is by the contents itself. This would mean restoring all the files and then looking at the individual files with GREP or EDIT for known data. If the contents of the desired file are binary data of unknown origin, you are probably out of luck. Restoring the files can be a very time consuming process. For example, here is a "bad" backup: FST> dl Format : FST Title : @ temp Created : Wed Feb 14, 1996 1:36:46 pm File paths and names File TEMP:::5:48:128 TEMP:::4:1:9 TEMP:::4:96:40 TEMP:::6:113:128 TEMP:::2:256:1024 TEMP:::4:96:36 In this case, you could restore a particular TEMP file by specifying the full namr as follows: FST> RE TEMP:::2:256:1024 1 files selected; 1 total Obviously, this can be a very time consuming process, and if there are multiple files with the same attributes, you'll have to play games with the D option, and perhaps performing a BR command to prevent overlaying a restored file that you want to save. At this point, it would depend how badly you needed to recover the data. A: I am trying to load a program for a different target system using the target systems snap file. I am getting the following undefined entry points: $IDEXT $IDNBR What am I doing wrong? A: Since these entry points only exist at revision 6.0 and later, what you are doing most likely is crossing the 5.27/6.0 boundary. If the target system who's snap file you are using is at 5.27 or earlier, you cannot load programs for this system on a 6.0 or later system by only using the snap file. You must also use the corresponding libraries for the target. What is happening here is the program is being loaded using 6.0 (or later) libraries, and these are referencing $IDEXT and $IDNBR, which are not being satisfied by the 5.27 (or earlier) snap file. Now, even if you were to use the 5.27 libraries with the 5.27 snap file on a 6.0 system, the resulting program would not be useable on the 5.27 system. The reason is LINK. If you use the 6.0 LINK, it will create a program file with the ID segment structure for a 6.0 system. This is not compatible with a 5.27 system. If you really want to LINK programs for 5.27 or earlier on a 6.0 or later system, you need the following: - 5.27 system snap file - 5.27 Libraries - 5.27 LINK (which may not work on 6.0 or later, I haven't tried this) Q: I don't exactly understand using the NAMED program for DNS with MAIL on my RTE-A system. Can you explain the basics? A: At the 6.0 release of RTE-A, Domain Name Service (DNS) support was added to the MAIL/1000 product for RTE-A. So let's first explain the basics of DNS. DNS is essentially a centralized lookup service used to resolve a system name to an IP address. In the HPUX world, it takes the place of the /etc/hosts file. In the absence of DNS, the local host would need an entry in the /etc/hosts file for any machine that the local host expects to communicate with. This is cumbersome, since it means that all machines have their own /etc/hosts file which needs to be kept up to date with new machines and addresses. A Domain Name Server is a machine that functionally replaces the individual /etc/hosts file with a centralized machine who's purpose is to resolve name to IP address. This DNS machine is then used by all systems for name-address resolution. A site may have one or more machines configured as Domain Name Servers. HPUX uses DNS for MAIL, telnet, ftp etc. On the 1000, we only implement DNS for MAIL. It is not supported by any other NS/ARPA service at this time. Now what is the purpose of NAMED? NAMED works in conjunction with a so called "full service" DNS by locally caching information obtained from the DNS. When you configure DNS service on the HP1000, you specify the IP address of either a DNS machine for your site, or the local 1000 system which is running NAMED. This is configured in /etc/resolv.conf. If you use the local 1000 as the nameserver, then NAMED handles requests for name/address resolution If NAMED has the address in cache, it then provides it to the requestor. If it does not, then it makes a request of the "full service" name server specifed in /etc/named.boot. The advantage of using NAMED should be apparent. Requests that have already been cached in NAMED won't require any extra network activity accessing the "full service" DNS. Q: Great, now I understand why I would use NAMED. What utilities are there that go along with Domain Name Service on the HP1000? Q: Besides NAMED, there are two other programs supplied with MAIL/1000 They are: NSLOOKUP and SIG_NAMED . NSLOOKUP is used to interactively interrogate the Domain Name Server for information. For example: CI> nslookup Default Name Server: hpwrcxe.mayfield.hp.com Address: 15.37.241.3 When NSLOOKUP is scheduled, he first reports the name and address of the default Name Server being used. You can then enter a system name or an IP address, and NSLOOKUP will report the results as follows: > mailhost Name Server: hpwrcxe.mayfield.hp.com Address: 15.37.241.3 mailhost.mayfield.hp.com canonical name = hpwcsdm.mayfield.hp.com hpwcsdm.mayfield.hp.com internet address = 15.3.32.17 Here we asked for a machine named mailhost and the DNS reported back the machine's canonical name and IP address. In this example, the information came from the full service DNS. How do we know that? Look what we get when look up mailhost a second time: > mailhost Name Server: hpwrcxe.mayfield.hp.com Address: 15.37.241.3 Non-authoritative answer: mailhost.mayfield.hp.com canonical name = hpwcsdm.mayfield.hp.com hpwcsdm.mayfield.hp.com internet address = 15.3.32.17 We get the same information, but this time, it is qualified as a "Non-authoritative answer" A Non-authoritative answer is obtained from NAMED's cache. Since NAMED's cache remains in memory until NAMED is restarted, or the system rebooted, it may be days or weeks since this information was obtained. If the IP address for mailhost were to change during this time, we would not be aware, since we still had the old IP address in cache. Thus this is a Non- authoritative answer. SIG_NAMED is used to interrogate NAMED, and has three possible options: kill - This does like it says, it shutsdown NAMED stats - This dumps statistics into file /scratch/named_stats dump - This dumps a listing of NAMED's cache to file /scratch/named_dump.db Here's a sample statistic file: named: Statistics listing generated Thu Apr 18, 1996 7:35:35 pm 6 queries received 2 queries forwarded (33%) 3 RR cache hits 0 non-existent RR cache hits 0 non-existent domain cache hits And here is the cache dump: named: Cache dump listing generated Thu Apr 18, 1996 7:36:55 pm mayfield.hp.com SOA `exit`.mayfield.hp.com [non-existent domain] hpwcsdm.mayfield.hp.com A 15.3.32.17 mailhost.mayfield.hp.com CNAME hpwcsdm.mayfield.hp.com 3.241.37.15.IN-ADDR.ARPA PTR hpwrcxe.mayfield.hp.com More details on NSLOOKUP and SIG_NAMED can be found in the MAIL/1000 Users Manual. Or you might check in your HPUX manuals since the functionality of these programs is virtually the same as on HPUX. Q: I have noticed that when the network activity on my site increases my RTE-A system sometimes runs out of SAM. Once the network activity falls off, the SAM usage returns to normal. This is beginning to impact system performance. Is there anything I can do? Q: Yes. Frequently this condition is caused by excessive broadcast packets on the network. By default, the lan card on the 1000 is usually configured to accept to these broadcast packets, and if there is enough traffic, it can cause the 1000 to run out of SAM. If broadcast packets are the problem, the solution is to change the packet filtering on the LAN card to not accept these broadcast packets. This can be accomplished as follows: Using Node Manager (NM): The RC command will display the current Packet Filter configuration as follows: NM> rc,,4 Read 802.3 Link Config of node 08-00-09-00-72-4C.... Receive Packet Filter 06 As you can see the packet filter is set to 6. The possible values are listed in Table 1 Table 1 Setting Categories of Packets node will accept ------------------------------------------------------------ 0 | Individual only (this is the card default) 1 | Individual + Promiscuous 2 | Individual + Broadcast 3 | Individual + Broadcast + Promiscuous 4 | Individual + Multicast 5 | Individual + Multicast + Promiscuous 6 | Individual + Multicast + Broadcast 7 | Individual + Multicast + Broadcast + Promiscuous ------------------------------------------------------------ A setting of 6 means the card will accept Individual, Multicast and Broadcast packets. To eliminate Broadcast packets, you can use a setting of 0 or 4. (Do not choose any setting that includes Promiscuous. Promiscuous means the LAN will accept any and all packets received. This can really eat up resources and cause network programs on the 1000 to receive packets not intended for them) Multicast is a method of sending a single packet to multiple machines simultaneously. To change the Packet Filter with NM, do the following: NM> sc,,4,0 Set 802.3 Link Config of node 08-00-09-00-72-4C.... Receive Packet Filter 00 Changing the packet filter using NM will only be effective until the system is rebooted. When NSINIT runs (assuming you are using NS/1000-ARPA 1000) it will reset the Packet to 6. You can add the following Control Request to your system welcome file, after NSINIT has executed, to set the packet filter on bootup: CI> CN,,37B,0,-20465, where: LU_OF_LAN = 12076 card's LU number 37B = Control request 0 = Desired Packet Filter -20465 = is a security code For more information on using Node Manager and Packet filtering, refer to the 12076A LAN/1000 Link Node Manager Manual. Information on LAN Driver control requests can be found in the 12079 LAN/1000 Link Direct Driver Access Manual (part number 12079-90001, no longer available as far as I can tell) Q: I need to replace an eight channel mux panel, but HP tells me it's no longer available. They recommended a newer panel and cable as a replacement. Will this work without any problem? A: Depends on the existing cable you are replacing. Since the baud rate generator assignment is accomplished via the cable hood on the mux card, you may need to make changes to either the wiring itself or the mux intialization commands in your welcome file. The following table shows the mux panel/cable combinations and the BRG wiring: Panel # Cable # BRG wiring ----------------------------------------------------- 12828-60001 * 12828-60002 BRG0 = Port 0 BRG1 = Port 1-7 12828-60001 * 12040-60002 BRG0 = Port 7 BRG1 = Port 0-6 28658-60005 28658-63005 BRG0 = Port 0 or 28658-63002 BRG1 = Port 1-7 * The 12828 panel has been obsoleted and is no longer supplied. As you can see if you are replacing a 12828-60002 cable with a 28658-63005 cable, the BRG wiring is the same. If you are replacing a 12040-60002 cable, you will either have to change the wiring in the hooded end (card end) or perhaps modify the CN commands you use to enable your mux. One additional coment about the 28658 mux panel: It does not supply +/- 12 Volts on pins 9/10. The 12828 panel had these voltages available, and these were occasionally used to power external, low current( less than 1 Amp) draw devices. If your application requires a low current source you will have to make provisions for this. Q: I have a BSD application that send data from a 9000 to the 1000 continuosly. Occasionally, the 9000 side shuts down the socket for no apparent reason. On the 1000 side I see the following in the NS Event log file: Error HP-TCP 33 0 75 161b INPRO/0 14011 14011 18 38 1 20101 20100 -31088 25605 -31088 25620 0 13 -12047 11 -32294 0 2 9 21309 0 0 0 8 The 14011 error is a bad checksum error. What is the problem? A. The problem is the HP1000 is not recognizing a 0 as a valid TCP checksum, and as such is dropping the packet. If the packet is retransmitted with a non-zero checksum, things will be OK It may be that the 9000 is counting dropped, or unacknowledged packets, and then closes the connection after X number of these. But the real solution is a patch for INPRO on the RTE-A system that does not reject packets with a checksum of 0. Contact the Response Center for a patch for 6.2 NS/1000. Q. The battery backup pack in my A990 computer is no longer holding a charge. I ordered a 1420-0304 battery pack, but the pack I received is much smaller in size than the battery pack I have. What is the difference? A. The 1420-0304 was supposedly obsoleted years ago and replaced by a new battery pack, part number 1420-0377. This new battery pack is physically larger than the old -0304 battery. Because of this the metal cover plate was also enlarged. Either battery should work, but if the computer has the -0377 battery, then it should be replaced with an -0377. If a -0304 battery is replaced with a -0377, then a larger cover plate, part number 12151-00056 must also be used. The 1420-0377 battery and cover plate (12151-00056) may be ordered as a kit, part number 5061-2545. Q. I am using DBUTL on my RTE-A system. When I try to use the CMNDO command stack, which was new at 6.1, DBUTL aborts with a UI error. This usually means a CPU hardware or firmware problem. But only DBUTL is affected. What gives? A. DBUTL has a problem when the command stack is utilized and you happen to be using a PC with Reflection as the terminal emulator. This problem is noted in an SR, but since the workaround (IE don't use Reflection, or if you do, don't use the command stack) is >>****** line 95 ********* ctrl U reads *** ctrl U ctrl U abor<< obvious, the SR is currently in a 'no-fix' status. Q. I am writing a C program that uses Extended EMA on an A990. I am finding inconsistent results and occasionally my program will memory protect. I am using the latest 6.2 revision of RTE and the latest C compiler. Normal EMA works fine. What is wrong? A. It turns out this is A990 Microcode bug. "C" language byte pointers into 'extended' EMA may not function correctly. When a C EMA byte pointer is dereferenced and used to read/write the last page of an extended EMA segment an incorrect address is returned, resulting in a local or stack location being read/written instead of the EMA location. The problem occurs only on the A990 while using 'extended' EMA/VMA and only when referencing the last page of an EMA segment. The problem occurs when using the .LBPC instruction that is emitted only by the the C compiler. The problem is caused by a defect in the .LBPC instruction in the A990 microcode. When .LBPC is requested to map in the last page of an 'extended' EMA segment it incorrectly returns a word address in the B register instead of the byte address. If the request is for any other page than the last page of each allocated EMA segment then the returned address is correct. A patch for the A990 firmware is available from the Response Center. It consists of a microcode patch file which is downloaded at boot. The firmware itself will most likely not be updated, since the microcode patch accomplishes the task. Q. I have an HPIB DDS drive on my RTE-A. Now that I no longer have a 7970 or 9144 to boot from I find that I cannot boot from the DDS. I get a loader error 560. Shouldn't this work? A. Yes this should work. The only requirements are the following 1) VCP firmware revision must be 4020 or greater This can be determined by looking at the B register from VCP at power up or after a %T command 2) The address switch on the DDS drive must be set to "8" and the tape then booted as address 3. For example, %BMT3027 Setting the address switch to 8 causes the DDS drive to identify itself as a 7980 tape which allows VCP to boot successfully. Q. I have attempted to upgrade my RTE-A system from 5.27 to 6.2 and ran into several problems. Can this be done? The 6.2 Communicator makes no mention of this. A. Yes it can be done. The major problem is the new utility KTEST which is required by the installation command files. If KTEST does not exist, RTE_INSTALL will load it. The problem arises on pre 6.0 systems. KTEST does not execute properly, and renders the subsequent installation command files unable to function. The solution involves generating and then booting a minimum 6.2 system, and then using that system to install the entire RTE-A/VCPLUS programs using RTE_INSTALL. This minimum 6.2 system needs the following programs: D.RTR CI CIX KTEST ASK LINK DERR LINDX MERGE MPACK Also useful are: DL LI A complete cookbook is available that describes all steps necessary to update a system from 5.27 to 6.2. It contains excerpts from all relevant Communicators. The cookbook is described in Support Line in document ID: SWT960515001 and is available via email. To obtain a copy of the cookbook send email to: Rte_Support@hpwrcxe.mayfield.hp.com Make the Subject: Cookbook Request A copy will be emailed directly to you. Q: I just discovered the existance of the PASSWORD command in GRUMP. Actually, one of my users discovered this for me, and in the process noticed he was allowed to change the password for any user on the system. Of course, he still needed to know the users password to be able to change it, but still, this behaviour doesn't seem right to me. Only superusers should be able to even attempt a PASSWORD command on other users. The PASSWORD command for normal users should be restricted to only allow them to change their own password, not the password of other users. A: Yes, this is true. GRUMP gives normal users the capability to change the password for any user on the system. The workaround for this is easy if you are using SECURITY/1000. It turns out that if SECURITY is being used, then a user must have a capability of 25 (still not super(31)) to use the PASSWORD command on other users. If a capability 20 user attempts the password command the following error is reported: GRUMP> PA WALT Capability level not high enough to perform PASSWORD command. So as long as users have a capabililty of less than 25, they will not be able to use the PASSWORD command. Otherwise, see the next question. Q: Can I change the capability level required to use the PASSWORD command in GRUMP and how is this done? A: Buried in the System Manager manual lies the complex answer to this question. To modify capability levels, requires the following: 1) EDIT the file: /vcplus/security.tbl This file contains all the default capability levels for system calls and commands. For the GRUMP commands, look around line 432 for the following: passwd 0 25 0 0 *change user password (1) Change the value 25 to 31. This is the required capability. 2) Run STGEN on this modified file as follows: CI> STEGN SECURITY.TBL - - - This will create the files: SECURITY.LST SECURITY.MAC SECURITY.REL 3) Regenerate your system, using this new SECURITY.REL in the System Messages section of your answer file. 4) Reboot using this new system file. This process can be used to modify any existing capabilities in SECURITY/1000. Q: Is it possible it create a RTE readable tape using 'dd' on a HP9000? A: Yes. Lets assume you have a FST archive file on a HP9000 system and need to move this to an HP1000 that has no network access. You can use dd on the 9000 to create a tape that will be readable by FST on the 1000. Use dd as follows: $ dd if=filename of=/dev/rmt/tapedrive obs=10240 where: filename is the FST archive file on the HP9000 tapedrive is the device file for the tape drive (Note: the DDS tape drives must be similar on both machines. If the 9000 tape drive uses compression, the 1000 tape drive must be capable of reading compressed tapes.) In this example, obs=10240 sets the output file block size to 10240 bytes. This only affects the performance, especially for dds tape drives. It is not required. Once dd has written the tape, this tape can be read using FST on the HP1000 just like any normal FST backup tape. Q: Is there a 'tail' utility for the 1000? A: New in the CSL this year is a tail program which emulates the HPUX version. Or you can use the following simple script: * * The following script runs LI on the specified file name * in $1, and displays the last 'window' (20 lines). * li -> /$l/ $1 * Q: We have a legacy HP1000 application written in PASCAL. We would like to utilize the new for 6.0 Multiple Shared EMA capability, but are having a hard time getting it to work from PASCAL. Are there any examples of this specifically for PASCAL? A: Yes. The HP1000 lab has come through with sample programs for PASCAL that use the new Shema model. The PASCAL programs require a FORTRAN subroutine. There are 2 Pascal programs that communicate through 2 shemas. Each contains Fortran routines that declare the common blocks and call RteAllocShema. Prog1 initializes the data, then calls exec(7) to wait for the second program to reset it. Prog2 calls exec(7) to wait for the first program to set the data. Listing of PROG1 ---------------- $CDS ON$ $HEAP 2$ PROGRAM prog1(input,output); label 99; const alloc_flags = 0; dealloc_flags = octal('40000'); { unlock } type int = -32768..32767; btype = packed array[1..16] of char; rec_t = record val : int; str : packed array[1..10] of char; end; ptr_rec = ^rec_t; flag_rec = record word1 : int; word2 : int; end; var p1 : ptr_rec; p2 : ptr_rec; err : int; flags : flag_rec; function xema1_alloc(flags : flag_rec; var err : int) : ptr_rec; external; function xema2_alloc(flags : flag_rec; var err : int) : ptr_rec; external; function RteReturnShema(addr : ptr_rec; flags : int) : int; external; procedure exec_7 $alias 'EXEC'$ (x:int); external; begin flags.word1 := alloc_flags; flags.word2 := 0; p1 := xema1_alloc(flags, err); if p1 = nil then begin writeln('prog1: init #1 failed, err=',err); goto 99; end; p2 := xema2_alloc(flags, err); if p2 = nil then begin writeln('prog2: init #2 failed, err=',err); goto 99; end; p1^.val := 11111; p1^.str := 'aaaaaaaaaa'; writeln('val #1 =', p1^.val); writeln('str #1 =', p1^.str); p2^.val := 22222; p2^.str := 'bbbbbbbbbb'; writeln('val #2 =', p2^.val); writeln('str #2 =', p2^.str); writeln('wait for prog #2 to finish, then type GO'); exec_7(7); writeln('val #1 =', p1^.val); writeln('str #1 =', p1^.str); writeln('val #2 =', p2^.val); writeln('str #2 =', p2^.str); flags.word1 := dealloc_flags; err := RteReturnShema(p1, flags.word1); if err <> 0 then writeln('prog1: dealloc #1 failed, err=',err); err := RteReturnShema(p2, flags.word1); if err <> 0 then writeln('prog1: dealloc #2 failed, err=',err); 99: end. Listing of PROG2 ---------------- $CDS ON$ $HEAP 2$ PROGRAM prog2(input,output); label 99; const alloc_flags = 0; dealloc_flags = octal('40000'); { unlock } type int = -32768..32767; btype = packed array [1..16] of char; rec = record val : int; str : packed array [1..10] of char; end; ptr_rec = ^rec; flag_rec = record word1 : int; word2 : int; end; var ptr1 : ptr_rec; ptr2 : ptr_rec; flags : flag_rec; err : int; function xema1_alloc(flags : flag_rec; var err : int) : ptr_rec; external; function xema2_alloc(flags : flag_rec; var err : int) : ptr_rec; external; function RteReturnShema(addr : ptr_rec; flags : int) : int; external; procedure exec_7 $alias 'EXEC'$ (x:int); external; begin writeln('wait for prog #1 to suspend, then type GO'); exec_7(7); flags.word1 := alloc_flags; flags.word2 := 0; err := 0; ptr1 := xema1_alloc(flags, err); if ptr1 = nil then begin writeln('prog2: alloc #1 failed, err=', err); goto 99; end; ptr2 := xema2_alloc(flags, err); if ptr2 = nil then begin writeln('prog2: alloc #2 failed, err=', err); goto 99; end; writeln('prog2: val #1 = ', ptr1^.val); writeln('prog2: str #1 = ', ptr1^.str); writeln('prog2: val #2 = ', ptr2^.val); writeln('prog2: str #2 = ', ptr2^.str); ptr1^.val := 99; ptr1^.str := 'cccccccccc'; ptr2^.val := 88; ptr2^.str := 'dddddddddd'; writeln('prog2: val #1 = ', ptr1^.val); writeln('prog2: str #1 = ', ptr1^.str); writeln('prog2: val #2 = ', ptr2^.val); writeln('prog2: str #2 = ', ptr2^.str); flags.word1 := dealloc_flags; err := RteReturnShema(ptr1, flags.word1); if err <> 0 then writeln('prog2: dealloc #1 failed, err=', err); err := RteReturnShema(ptr2, flags.word1); if err <> 0 then writeln('prog2: dealloc #2 failed, err=', err); writeln('prog2 done!!'); 99: end. Listing of Fortran subroutine ----------------------------- ftn7x $cds on integer*4 function eaddr(a) integer*4 a eaddr=a return end $ema /xema1/ c xema1_alloc will allocate an extended shema of 1 page integer*4 function xema1_alloc(flags, err) implicit none integer*4 flags integer*2 err integer*2 e1(1024,1) ! Space for sec shema #1, 1024words*1 page common /xema1/ e1 integer*2 size integer*2 RteAllocShema integer*4 eaddr size = 1 ! We will be sharing 1 page err=RteAllocShema('xema1name', size, e1, flags) if(err.ne.0) then xema1_alloc=0 else xema1_alloc=eaddr(e1) endif end $ema /xema2/ c xema2_alloc allocates another shema integer*4 function xema2_alloc(flags, err) implicit none integer*4 flags integer*2 err integer*2 e2(1024,1) ! Space for sec shema #2, 1024words*1 page common /xema2/ e2 integer*2 size integer*2 RteAllocShema integer*4 eaddr size=1 err=RteAllocShema('xema2name', size, e2, flags) if(err.ne.0) then xema2_alloc=0 else xema2_alloc=eaddr(e2) endif end LINK command file for PROG1 --------------------------- sz,32 em,,l es,xema1,2 es,xema2,3 li,pascal_cds.lib re,ppas1.rel re,pftn.rel en,prog1 LINK command file for PROG2 --------------------------- sz,32 em,,l es,xema1,2 es,xema2,3 li,pascal_cds.lib re,ppas2.rel re,pftn.rel en,prog2