1992 HP1000 Guru Column ========================================================================= Q: I have a 650/A Optical disk drive connected on a 12016 SCSI to my A Series. I am getting occasional timeouts. Is there a fix? A: Several problems have been reported with timeouts on SCSI disc drives. Both the SCSI drivers and the SCSI firmware have been fixed to solve these problems. Another potential problem is the firmware in the 650/A. There is newer firmware for the 650/A which has solved problems with timeouts. Contact your local CE to have the firmware in the disk checked, if the drivers and 12016 firmware have already been updated. Q: Speaking of new SCSI drivers, what revision are we up to now, and what do I need to be able to boot from my SCSI disk? A: As of November 1991, the current revision of the SCSI drivers is 5250. (Note the new convention for revision codes). This revision solves numerous bugs and also adds BOOT capability. To summarize changes required for SCSI boot: 1) New VCP ROMS (Rev 4021) 2) New SCSI card firmware, 12016-80009 (replaces 12016-80005) Should be noted that the card must be a -60101 to support boot. 3) New SCSI drivers, DDQ30 and IDQ35 revision 5250. 4) New BOOTEX revision 5250 For customers who have purchased the 12016A SCSI card already and would like to obtain the new drivers, MCSY has set up a special SCSI Hotline. Call 1-800-643-2120. They are set up to ship kits that contain everything you need to add boot capability to your existing 12016A SCSI card. Q. I have heard that older A series computers cannot be updated to SCSI boot. Is this true? A. All A Series processors can be updated to support SCSI boot, with the exception of A900 cpu's that have OLD Cache Control cards. These old Cache Control cards can be identified by the part number 12203- 60001 or 12203-60004 on the card itself. The problem is these old cards use 24 pin ROMS and the SCSI boot ROMS are 28 pin. The Cache Control card can be exchanged for a new one. (Part number you want is 12203-69018) Q: So, what are these new revision codes, like 5240? A: For the next release, for example the 5.24 NS/1000, the following format is used for the revision code: Revision 5240 Where 5 = Major revision 2 = Minor revision 4 = Sub Minor revision 0 = Patch level The decimal point has been deleted to allow addition of the new Patch level. This will allow for better tracking of patches for specific modules. Q: I have a C1511A HPIB DDS tape drive on my RTE-A system. Can I load my memory based ARSTR from the DDS, or do I need to keep my 7980 just so I can load ARSTR? A: Yes, you can boot from the DDS DAT tape drive. The trick is to set the address switch on the DDS tape drive to "8". This sets the actual HPIB address to 3 and also makes the DDS identify itself as a 7980 tape drive. Now VCP will recognize it and you can boot ARSTR. (Note that VCP must be revision 4020 to boot the 7980 or DDS) Your VCP boot command would be something like this: %BMT3027 This assumes select code 27 for the HPIB card. Q. I have a C1511A DDS tapoe drive on my RTE-6 system. When I try to write to the tape, I sometimes get a IO Not ready message. Other tapes don't have the problem. What gives? A. The problem here is the tapes that fail are probably BLANK. There is an SR that describes a problem writing to new BLANK DDS tapes. As long as the tape has been previously written to, then it will work fine. Of course, this means you have to a DDS tape on some other A Series or 9000 system. Q: I have installed the new D mux drivers from the 5240 NS/1000 software. Now when I run SPORT, the device drivers show revision 5.24, but the interface driver, ID800, is listed as 5.4. Is this correct? A: No, all the serial drivers should be 5240 (5.24). This is a problem in the way SPORT reports the driver revisions. This has been fixed and patched drivers, plus a patched HpCrtLibF for SPORT are available from the Response Center. The patched drivers are revision 5241. Q: I am trying to update to the 5240 NS/1000, so I can use block mode TELNET. During the gen, I am getting two undefined externals: $CLWRT and $KILLSPOOL. $CLWRT is supposed to be in %EXEC, and I'm using the %EXEC that came with the 5240 NS/1000. What's the problem? A: Most likely you are on a 5.1 RTE-A system. 5240 NS/1000 is only supported on 5.2 RTE-A. The general rule is that a given revision of NS/1000 is supported only on RTE-A of the same revision, or one revision back. Perhaps a table would help clarify this: RTE-A Rev: Supports NS Revs: --------- ----------------- 5000 5000 and 5005 5010 5010 and 5016 5020 5020 and 5240 Any other combinations are not supported, and may not even work. ============================================================================ Q. I am trying to install a 9133H 20 Mbyte disc drive on my A900. I have it genned correctly according to the generation manual, yet when I try to mount the single LU, I get a Reject Error 400B, which says I exceeded the address bounds of the device. What am I doing wrong? A. Take the top cover off the 9133. On the controller PCA (top board), there is a jumper near the middle labeled 256 or 1K. This is the sector size. For RTE, this jumper must be in the 256 position. If you must move the jumper, then you will need to reformat the disc (using FORMC) before mounting it. Some 9000's and PC's allow different sector sizes. HPIB discs on RTE must be 256 byte sectors. Q. According to the INETD.HLP file, INETD has the capability to disallow particular remote systems from accessing particular services on a host system. I am trying to prevent a user from FTP'ing in to my 1000. I have not been successful at this. Is there a way to accomplish this? A. At this time, INETD can only be used to disallow SMTP traffic or custom servers. This is because NS/1000 does not use INETD as it's primary monitor/dispatcher on the LAN. Since it has no control over FTPMN, it has no way of limiting FTP access. Q. Speaking of INETD, does it log any errors and if so where? I am trying to debug a custom server I am writing. A. INETD logs errors to a file called "INETD.LOG::SYSTEM". Errors will always be logged by default. If you want to log all connections on your particular service, you can do this using the "-l" flag in your INETD.CONF configuration file. For example: smtp stream tcp nowait root /programs/smtp.run -l smtp in your INETD.CONF file will log all connections on the smtp port for MAIL to INETD.LOG::SYSTEM. For more information on INETD, see the file INETD.HELP supplied with the MAIL/1000 software. Q. Can the automatic error logging by INETD be disabled? A. There is an undocumented runstring option to INETD that allows you to disable all logging. To do this, use the following runstring: XQ,INETD,-l 0 This will prevent INETD from logging any errors. Note that this will not allow for troubleshooting any server problems you may encounter, thus this option should be used with care. Q. What is the easiest way to use DEBUG on my server program? A. Probably the simplest thing would be to put an EXEC 7 at the beginning of your server, and then schedule debug on the server after it has been cloned by INETD. INETD will always attempt to clone the server so you can't make it a system utility, nor can you RP it. Q. I am trying use a personal MAIL.RC file to setup my own environment. I have the file in my logon working directory, but when I run MAIL, it does not execute MAIL.RC. What am I doing wrong? A. This is probably due to a minor misconception about logon working directory. The logon working directory is not your "Home" directory automatically (like in UNIX). Your "Home" directory must be set with a PATH 0 / command. This should be put into a logon startup command file with GRUMP, then MAIL will find your MAIL.RC file. Q. Speaking of MAIL.RC, I have a global MAIL.RC file in /MAIL/ADMIN. I can't get "signature" or "ignore" to work. What gives? A. Certain commands don't make sense to use in a global MAIL.RC, such as "signature" (since that usually is a PERSONAL thing). But the "ignore" command won't work either and that is NOT necessarily personal. This has been reported and should be fixed in the next release of MAIL. Q. How can I have MAIL/1000 forward messages automatically, like the UNIX ".forward" ? A. Easy. Just put the recipient address in the /mail/admin/addressbook.mail file. The addressbook.mail file will behave just like a .forward file in UNIX. The best way to manage addressbook.mail is to have a central system that has a complete addressbook file, which is maintained and downloaded to ALL systems periodically. That way all users will receive their MAIL on the system they want, no matter which system actually receives the message. Q. When I send long messages, (greater than 10,000 bytes) between my 1000 and a Pyramid machine, I sometimes get a NetIPC 64,"Unable to reach remote handler" error. When the 1000 gets this error, the Pyramid doesn't think the 1000 received the message, so it resends the message over and over. Is there anything I can do? A. The problem could be that the Pyramid is "over-running" the 1000. SMTP on the 1000 has a 100 byte internal buffer for receiving MAIL messages. There is also a corresponding buffer in DSAM for the data as it is received by the 1000. This buffer size can be increased with INETD using the "s" and "r" flags in INETD.CONF as follows: smtp stream tcp nowait root /programs/smtp.run -rs 2000 2000 smtp This should help prevent "over-runs" or timeouts by allowing DSAM to buffer larger "chunks" of the messages. See the file INETD.HLP for more information on INETD flags. Q. I am adding a new SCSI disc to my RTE-A system. I used the total useable blocks as specified in the manual that came with the disc, but that number is apparently incorrect. Is there an easier way than trial and error to determine the size of a particular SCSI disc? A. Yes, there is a very easy way. Just interrogate the drive itself! The following is a sample program that will return the total blocks and the block size for a SCSI disc drive. Simply pass it any SCSI LU on the disc in question. ftn7x,q,s,c program Disc_Size(3,99) >,SCSI Disc Size sense <:00218.1052> implicit none integer*2 ! variables > Crt, > Status, > TLog integer*4 TotBlocks integer*2 ! arrays > ScsiLu(0:1), > Ibuf(0:39), > Obuf(0:39), > CDB(0:4) equivalence (TotBlocks,Ibuf(0)) Data > Crt / 1 /, ! talk to the user terminal > ScsiLU / 0,10000b /, ! set the Z bit > CDB / 22400b, ! Op code = 25h, LUN = 0 > 0, ! > 0, ! > 0, ! > 0 / ! 0 *------------------------------------------------------------------ call Rmpar(Ibuf) ScsiLU(0) = Ibuf(0) ! get the test LU call HpZDefObuf(Obuf) ! declare formatter buffer call xluex(1,ScsiLU,IBuf,12,CDB,-10) ! read medium size call abreg(Status,TLog) ! get short status call Rmpar(Obuf) ! get extended status c call HpZdumpbuffer(Crt,Ibuf,18,-1) ! display the data TotBlocks = TotBlocks+1J write (1,8000) ScsiLU(0),TotBlocks,ibuf(3) 8000 Format ("The drive containing LU ",i2," has ",i9," blocks", & " of ",i4," bytes each.") end *------------------------------------------------------------------------ Q. I am trying to link my application programs and am getting a link VM33 error. This implies I am running out of disc space for the backing store file for LINK. Yet my /scratch LU has plenty of space. What else can I look at? A. LINK will usually use /scratch for it's backing store file, but if a FMGR LU has been defined as the scratch cartridge in the boot command file, then LINK will use that first. To eliminate the FMGR scratch LU, use the "SC,0" command in the boot command file to reset $SC to 0. If you encounter an error with the "SC,0" command, such as "Bad LU", this means your BOOTEX file is older than 5.1. Prior revisions of BOOTEX did not allow resetting $SC to 0. The workaround then is to put a fresh copy of the system file (one that has not been booted) on your boot LU, remove the "SC,xx" command from your boot command file and then reboot. Now you won't have a scratch cartridge, and LINK will use /scratch. Q. What is the file RPL_A900_REV4.REL used for? A. At 5.2, a new RPL file (/RTE_A/RPL_A900_REV4.REL) was shipped. This RPL corresponds to the A900 Base Set Service Note (2139A-30). The A900 base set was updated to fix the cross map/move byte instructions. Before this fix, the affected MBxx instructions were implemented in software (they were commented out of the A900 RPL file). This was the purpose of XMB.REL in the A900. If you have the latest A900 base set and you want to execute the MBxx instructions out of firmware instead of software, use the RPL_A900_REV4 file in ADDITION to the RPL90/91 files, and do not use XMB.REL. The easiest way to determine what revision base set is installed is to look at the part numbers of the ROMs. The latest revision part numbers are 12201-80103 through 12201-80120. These are located on the sequencer PCA. If you need to update the ROM's call your local HP representative. This is a free upgrade if you are on HP hardware support. Q. I know about the CI "revlevel" command. How about a list of the corresponding OS revisions versus CI's timestamp. A. Here's a list that goes back to 4.1: OS Revision CI REVLEVEL ------------------------------------ 4.1 <:00218.1052> 5.0 <:00218.1052> 5.1 <:00218.1052> 5.2 <:00218.1052> ============================================================================ Q: I am running VSCSI on my 12016A SCSI card. It fails the RAM test with the following error: No such directory ZRAMTST.HEX What directory is it missing? Where is it supposed to be? A: You do not have a directory called /SCSI. The RAM test in VSCSI requires that the file ZRAMTST.HEX be located in one of following directories: /PROGRAMS /SYSTEM /SCSI working directory Also, the file ZLPBK.HEX is required for the LOOPBACK test to work. Note that both of these files were left out of the 5270 RTE-A distribution tapes. You can use the files from a previous SCSI software directory. Q: I tried to order a DS1000 direct connect extension cable, 91712A but my local office says they are obsolete. Can I get the parts to build my own? A: Yes. In fact, the 91712A product is ordereable as part number 5061-3437. This is a 75 Meter extension cable. If you need a longer cable the following parts are required: Connectors: (formerly 91713A). 1251-0293 (male) and 1251-0431 (female). Cable: (formerly included in 91714A 300 Meter cable) 8120-3096 (sold per foot) Q: Is there a way to prevent HPMDM from logging messages to the system console constantly? A: Use the QUIET option with HPMDM as follows: CI> hpmdm qu (Note: HPMDM ? does not show this option, but it does exist) This will disable logging of messages to the system console. To re-enable logging, use the VERBOSE option. CI> hpmdm ve Q: I am loading MAIL/1000 and I am getting undefineds during link. What is wrong? A: Two common causes of undefined entry points when linking MAIL are: 1) If you DO NOT have DS1000 or NS/ARPA1000 on your system, the following load command files need to be edited: M1KSS.LOD and NOTIFY.LOD These files are both in directory /RTE_A/MAIL Uncomment the line that relocates the following module: DUMMYDS.REL This module contains dummy entry points for DEXEC, DSEXT and GNODE to satisfy M1KSS and NOTIFY. Both load command files contains comments indicating the need to relocate this module when DS (or NS) is not installed on the system. 2) If you are using the ARPA1000 product only, you will need to search the following libraries when linking SMTP and INETD: NSLIB.LIB NSLIB_CDS.LIB The ARPA installation does not create any libraries for you. NS/ARPA1000 does create libraries, so NS systems should not have a problem loading MAIL with the default load files. Q: Is the 7980S, SCSI interface version 7980 supported on RTE-A? How do I gen it in? A: Yes, the 7980S is supported. A new DDQ24 driver and GEN record file is available to support the 7980S. DDQ24_GEN.REL New gen record to support 7980S SCSI tape drive. DDQ24.REL Support select density control request for 7980S. The DVT for the 7980S would look as follows: dvt,/rte_a/ddq24_gen.rel,M7980,lu:5,dp:1:4 Note that Driver Parameter 2 is now the default density and is set to 6250 by DDQ24_GEN.REL It can be changed like any DD*24 tape with a CN,lu,15b, command Also, DDQ30_GEN.REL has been updated for the new 1.3 Gbyte and the 422 Mbyte disc drives. These files are available through your local CE or Response Center Q: I have just installed the 5260 DEBUG to use with the C compiler and noticed that the CDS version (new for 5260) aborts with a VM82 error. What's the problem? A: An incorrect relocatable file was shipped on the Symbolic Debug/1000 version 5260 tape. The CDS_DEBUG.REL file will cause a VM82 error when debug is invoked. The incorrect file has a date stamp of 910912.0327. The workaround is to use the DEBUG.REL file instead of the CDS_DEBUG.REL file. The DEBUG.REL file contains the normal version of debug. The CDS_DEBUG.REL file contains a release of debug that improves performance and disk space requirements. A patch containing the correct CDS_DEBUG version is available from your local CE or Response Center. The corrrect file has a date stamp 911028.2100. Q: I have multiple 650 MO discs on my systems. Some are genned as single LU's and some have multiple LU's per surface. I have noticed that I sometimes do not have to re-initialize a disc when moving it between systems. Why is this and is it a problem? A: When using the removable media of the MO drive it is recommended that you label the media with the LU layout that you used for that device. This is particularly important when exchanging information between systems using the MO removable media. The reasons for this have always existed, but until the recent SCSI GEN records were developed, the problem didn't show up quite as severely. The following situation illustrates the problem: System 1 - genned with 2 x 128-Mbyte LUs. The first 2 LUs look like: LU 1 LU 2 | Bit Map ..... Volume Header | Bit Map ..... Volume Header | System 2 - genned with 1 x 256-Mbyte LUs. The first LU looks like: LU 1 | Bit Map ................................... Volume Header | Notice how the Volume Header of LU 2 on System 1 lines up with the Volume Header of LU 1 on System 2. When you move the disks from one system to the other, you may not neccessarily get the "No valid directory. OK to initialize [N]?" message from CI when you try to mount an LU. This is because a valid volume header was found. Also, you may actually be able to access some of the files. However, the bit map will not be valid for the entire LU. So, it is important to keep track of which system the removable MO disk came from. SR# 4700-921676 has been filed to enhance D.RTR to have the Root Directory point to the Volume Header. That way a check can be made to make sure that the Root Directory and the Volume Header point to each other. This way the above situation won't occur. This change has been made in the 5270 D.RTR. Be aware that the checking can only be done for volumes that were intialized with the 5270 D.RTR. ------------------------------------------------------------------------- In last months column, there was a Q/A on the CI "REVLEVEL" command. Due to a minor EDIT'ing snafu, incorrect datestamps were accidentally listed. Here's the correct info, updated for 5270 also! The CI command "REVLEVEL" will give you the revision level of CI. The following table shows CI REVLEVEL's and the corresponding Operating System revision. Note that this is for a system with the CDS version of CI. CI REVLEVEL OS Revision ---------------------------------------- <851022.1015> 4010 <870305.1535> 5000 <881004.1257> 5010 <900306.1214> 5020 <911121.1717> 5270 Q: I have just installed my A990 update, and there was a YELLOW sheet of paper describing a D mux problem. What's the scoop? A: Since the A990 is a significantly faster processor than previous A-Series computers, timing loops within drivers will now execute faster and possibly fall through to a timeout error condition. The problem is that a timing loop within the driver executes much faster on the A990 so that too many requests get sent to the 12040D card during the initialization process. The workaround is described in a note (as follows) that is being shipped with every A990: The workaround is to send a control 6 request (CN lu 6) to a MUX LU before a request has been sent to any port on that MUX. For example, if you have a MUX with LUs 40 to 47 associated with ports 0 to 7, respectively, issue a "CN 40 6" command before issuing any other MUX initialization commands to any MUX ports on that card. This should be done once for each D-Mux card in your system... The note goes on to give an example of the CN commands that might be found in a typical WELCOME file. The whole point is that the CN 6 command is unbuffered. The timing loop only becomes important when too much traffic gets backed up on the mux at initialization. The first communication between the driver and the mux is much more than just one request (it's a whole conversation), so making the first request unbuffered allows that conversation to complete before the command file continues. If that workaround is not adequate you can contact the Response Center ( assuming you are on support) for patched drivers plus a online patch program that will "fix" the mux driver on-line. (Saves a gen and reload!) As a final point, make sure you have the latest D mux firmware. Previous revisions, especially 5.02, have a problem when used as the system console on the A990. Current firmware is 5.2, the part number is 5180-7300. If you are on HP hardware support, you can get new firmware from your CE. Q: Are there new RPL files for the A990? A: Yes, but they are not shipped with the A990 update tape. They are included with the 5270 release of RTEA and VCPLUS. The files are RPL_A990.REL and RPL_A990_CDS.REL. When updating an A900 to the A990 you should no longer need to use XMB.REL in the gen, if you were before. The A990 is supported on RTEA revision 5.2 without needing to regen. Of course, until you update to 5270, you won't have the updated firmware features of the 990 processor. ========================================================================== Q. For security reasons, I would not like anyone else to be able to reboot my system. I know about break disable and autoboot, but these mean the system console and cpu need to be inaccessible to the users, otherwise they could just power fail it. Is there a way to have a "bootstrap" loader like in the "old days"? A. Sure. You can utilize BOOTEX as a "bootstrap" by storing it onto a removable media, such as a floppy or magtape. You would then load and execute BOOTEX from this media to boot your system, then take the tape (or floppy) with....now no one but YOU can reboot the system. In order to load and execute BOOTEX from a device OTHER than the device where the system is actually located requires "loading" BOOTEX, then modifying the A register, and then "running" BOOTEX. For instance, you have a CS80 disc at address 2, select code 27 where you normally boot from: %BDC2027 You have a tape drive at address 4 on select code 30. Simply store a copy of your INSTL'ed BOOTEX to a tape, using CI to "COpy" it. To boot your system using the BOOTEX on tape, you would do the following: %LMT4030 This loads BOOTEX from tape, and stores the boot command file name in VCP Now modify the A register to reflect the true boot disc: VCP> A 004030 002027 A 002027 VCP> (BOOTEX reads the A register and will use that address, instead of what is INSTL'ed in BOOTEX's base page. If you do not change the A register, BOOTEX will read that into it's base page) Now "run" BOOTEX: VCP> %R Your system should boot normally, using your boot command file. Once you have verified this works, you can remove the BOOTEX from your disc and use the tape "bootstrap" to boot your system. Q. Speaking of BOOTEX, I am always confused by the parameters you need to pass INSTL. Since 6.0 will require updating BOOTEX, how about a quick rundown on INSTL and required parameters. A. Here's INSTL's runstring: INSTL,snap file,system file,destination file,lu,source file,[option] where: option = N - No console, E - Enable CS/80 timeout retry Snap and System file -------------------- The SNAP and SYSTEM file are the actual RTAGN output files, which normally are the same files (or preferably copies) that are specified in your boot command file. Both of these can be left out, INSTL will use the currently booted system in memory. So, if you are not changing any disc LU parameters, you can leave these out. Destination file ---------------- The destination file is the name of the file where the NEW bootex is written. This file can be located in any directory on your system BUT IT CAN ONLY BE USED TO BOOT YOUR SYSTEM IF IT IS AT CYLINDER 0 HEAD 0 SECTOR 0 on the first LU on your disc. (Or a VCP file offset therefrom) If the first LU on your disc is a FMGR cartridge, then this file is normally named "bootex:-32767" Note that the security code MUST be given if INSTL is to OVERWRITE this destination file. This bootex file should be the FIRST file as displayed by a "FMGR" "DL" command. If the first LU on your disc is a CI volume, my recommendation would be to put the destination bootex onto the /SYSTEM directory, then use FPUT to put the "INSTL'ed" bootex into the reserved area of your CI volume. Note that FPUT only "puts" the bootex file, it does not do anything to it. This method serves two purposes: It gives you a backup of BOOTEX, and allows examining the BOOTEX file, since it is not accessible by the file system when it is in the reserved area of a CI volume. LU --- The "LU" parameter is the actual disc LU that contains your system and snap files specified in your boot command file. It does not have to be the same LU where BOOTEX is, though it can. It is the LU that BOOTEX will mount to find your system and snap file. It can be ANY LU on the same disc. If it is a CI volume, the default directory is /SYSTEM, and the default boot command file is BOOT.CMD If it is a FMGR LU then the default boot command file is SYSTEM. This LU is commonly called the "Boot LU". Source bootex ------------- The source bootex is the one supplied in the RTE-A relocatables directory. This file will be copied, and modified according to your boot LU parameters, to "Boot destination". This parameter can be left out and INSTL will assume the destination is a valid bootex and simply update the information for your boot LU. When updating to 6.0, of course, you will not want to leave this out, since a 6.0 BOOTEX is required to boot a 6.0 system. Options ------- "Options" were new at 5020. Setting option to 'N' is for console-less systems (no LU 1 genned) This will prevent BOOTEX from writing any messages to the console. For BOOTEX, the VCP terminal is automatically mapped to LU 1; if the 'N' option is used, LU 1 is bit-bucketed. Setting option 'E' will enable CS80 retries. This was done so that an auxiliary disc would not be downed if it were MC'ed by BOOTEX before it was ready. Setting option 'E' will allow for 16 retries before a CS80 disc is downed. Q: What exactly gets modified in BOOTEX by INSTL? A: Words 140B through 153B contain driver parameters 1-8 and interface type and select code info for the Boot LU. These locations are all NOP's in the source BOOTEX and get 'installed' by INSTL. INSTL also makes appropriate changes for the 'NC' and 'E' options. If these Boot LU parameters are not valid, or do not match the actual disc LU in your system, BOOTEX will display the following message: "CANNOT MOUNT DISC, MAY NEED TO RUN INSTL" This message is rather ambiguous, since you cannot run INSTL if you cannot boot the system. If you see this message, it usually means reload, if you do not have a alternate BOOTEX to boot with. Q: My system has LU's 16 and 17 as both CI volumes. My Boot LU is 17 and BOOTEX is on LU 16. Can INSTL put BOOTEX directly into the reserved area of LU 16? A: No. This is a case where the two step INSTL and FPUT is required. In order for INSTL to place the destination BOOTEX into a reserved area, the destination file parameter must be 0. The Boot LU in this case is 17, which means there is no way for INSTL to understand that the destination is actually on LU 16. It will assume the destination and the Boot LU are the same and attempt to put BOOTEX onto LU 17. Again, use INSTL and put BOOTEX on your /SYSTEM directory, then use FPUT to move it to LU 16's reserved area. Q: I am having a problem with the system scheduling a monitor program. The program is in /PROGRAMS, and is the correct version for the system I am running. What else could be wrong? A: Check your welcome file for any 'wd' commands. If you set a working directory in the welcome file, this becomes the 'system' working directory and will be searched first for any programs the system needs to schedule. You may find an 'old' copy of the monitor program in this directory. Q: Is there a way to determine the current MAIL/1000 configuration without relying on the contents of MAIL.CF? A: Yes. RMAIL can be used as follows to display the current MAIL/1000 configuration: CI> rmail ?? rmail at hpwrcxe.mayfield.hp.com (75) since Wed Sep 2, 1992 8:17:17 am log file /mail/admin/traffic.log error log file /mail/admin/error.log retrying queue every 30 mins, until 72 hrs elapse notify: notify %u New mail from %f - %t gateway host is hpwcsvp.hp.com The (75) is the local machines DS node number, the time is the last time RMAIL was started. Using the command 'RMAIL in' will not update this time. Q: Will the A990 work on a 5.1 RTE-A system? How about 5.0? A: Yes, it probably will work, but it is not supported. We have booted both 5.0 and 5.1 on a A990, and other than mux problems at startup, it seems to work. Again, for support, you need to be at least at 5.2 revision RTE-A. ============================================================================= ------------------------------------------------------------------------------ Q: I would like to know if it is possible to forward mail to an HP 1000 on a DS network from a UNIX host through an HP 1000 gateway? UNIX Host (From Here) | | LAN ------------------------- LAN | | HP 1000 Gateway | | HDLC| |HDLC | | HP 1000 -- HP 1000 (to here) A: Yes, it can be done. To simplify things slightly, the address must contain a destination host name which the gateway 1000 has in its /system/nodenames file. The "upper-level" domain info must be the same as for the gateway 1000; for example, if the gateway is "gway.apgea.army.mil" then the DS hosts could be named "ds-1.apgea.army.mil" and "ds-2.apgea.army.mil". File /system/nodenames on gway must have entries for "ds-1" and "ds-2". There are two ways to form addresses which will get mail to those hosts: #1. Create Domain Name Service info for the two hosts which tell the Internet to send mail destined to these hosts to "gway" for forwarding, using the MX (Mail eXchanger) resource record. An address may then be of form: user@ds-1.apgea.army.mil An Internet host which sees this address will consult the DNS and find an entry similar to: ds-1.apgea.army.mil preference = 10, mail exchanger = gway.apgea.army.mil It will then pass the mail to gway (assuming this host is reachable from the outside world), who will then pass the message to ds-1. #2. Embed the routing in the address. The address will be in format: user%ds-1@gway.apgea.army.mil An Internet host will pass the message to gway, who will split off the host after the "magic percent", and route the message to that host. Q: I'm having a hard time using Mail/1000 to reply to messages from a particular user on another mail system. The "From:" header looks like: From: John Q. Public Mail/1000 tends to say "Unknown mailbox 'John'" or reports a syntax error. A: The "From:" address above is actually illegal, and is causing Mail/1000 some confusion. The problem is the dot after the middle initial, which is invalid RFC-822 syntax, believe it or not. The standard is pretty silly on this point, and many mailers implement a special case around this problem, since it is so prevalent. Unfortunately, Mail/1000 at 5.2 doesn't do this. What really should happen is the mailer which generates the message is to notice the invalid character and add RFC-822 quoting around the offending character. The most common means of doing this is to stick double-quotes around the entire real-name field: From: "John Q. Public" But some mailers don't do this. Mail/1000 can't at 5.2, either, but it knows it can't; that's why it only generates addresses in the alternate for format: From: public@large.marge.com (John Q. Public) ... which is legal. At 6.0, Mail/1000 can generate either address format, and will automatically quote any illegal characters in the real-name field. Some folks on UNIX who run mailers with this problem put quotes around their real name in the /etc/passwd file to get around it. Q: Every once in awhile I get something like this in my error.log file: smtp error logged May 29 3:48 pm NetIPC 59: Request timed out [sending data] Host: 128.155.23.47; From: ? I gather something is trying to contact my system, but is confused. Is there any way to find out where it's coming from? A: If you have a host nearby which runs Domain Name Service (DNS) you can use a utility such as nslookup to query the DNS for the name of the host for the IP address reported: $ nslookup > set type=ptr > 47.23.155.128.in-addr.arpa Name Server: hpcuoa.cup.hp.com Address: 15.255.208.3 47.23.155.128.in-addr.arpa name = vab02.larc.nasa.gov > If all this isn't obvious to you (!) then see the manuals or RFC's for the DNS. For some reason, SMTP is receiving a NetIPC timeout when trying to answer the connections initiated by this host. It could be that: 1. The network is too slow. The default SMTP timeout is 5 minutes, which is fairly long, but it is conceivable that requests could time out over a very slow link. 2. Your host is unable to talk to the remote host for some reason. Here at HP, this often happens because the network routers squelch IP packets from closed-subnet machines (which includes almost all HP hosts) which are destined for the outside world. 3. The remote client is aborting the mail transfer before your host has a chance to respond, and TCP is not detecting the aborted connection. Both #1 and #2 can be debugged in part via "ping". If you suspect cause #1, you can up the NetIPC timeout used by SMTP. In /system/inetd.conf, add flag "-t 15" after the "smtp" in the runstring portion of the SMTP definition to increase the timeout to 15 minutes. For example: smtp stream tcp nowait root /programs/smtp.run smtp -t 15 ... and then re-initialize inetd with "inetd -c". This will up the timeout for incoming mail only. To increase it for outgoing mail, add the flag to the "service" entry in /mail/admin/mail.cf: service smtp smtp -t 15 ... and then re-initialize Rmail with "rmail in". If you wish to talk to someone at the remote host to find out what's going on, try mailing to: postmaster@vab02.larc.nasa.gov (assuming mail can work between the two systems, of course!). Address "postmaster" is always supposed to work, by mandate of RFC-822. An alternate address is of the domain administrator for larc.nasa.gov: larcnet@ns.larc.nasa.gov You can find this out by deciphering the SOA RRs for the domain from nslookup: > set type=soa > larc.nasa.gov Name Server: hpcuoa.cup.hp.com Address: 15.255.208.3 larc.nasa.gov origin = ns.larc.nasa.gov mail addr = larcnet.ns.larc.nasa.gov serial = 3000442 refresh = 1800 (30 mins) retry = 300 (5 mins) expire = 3600000 (41 days 16 hours) minimum ttl = 86400 (1 day) The "mail addr" field contains a domain-name-ish value, where the first word is the local-part of the Internet mail address, and the remaining words are the domain-part. Therefore, the first dot (.) should be replaced with an at-sign (@). Q: I need to modify my mail domain from a three-level domain, such as: myhost.hp.com to a four-level one: myhost.mysite.hp.com What do I need to do, and what are the consequences? A: To make the change: 1. Edit /mail/admin/mail.cf, changing the value of the "domain" keyword to "myhost.mysite.hp.com". 2. Check your /mail/admin/domainalias.cf file, updating any aliases which rely on being automatically qualified by ".hp.com", since these will now be qualified by the new domain. For example, if there's a local machine which you wish to still call "foo.hp.com" and there's a domainalias.cf entry of form: zippy : =foo which sets an alternate name "zippy" for "foo", then these names now need to be qualified with ".hp.com", since this will no longer happen automatically. One insidious case of this is when the host already has an alias set up for the four-level domain, such as: myhost.mysite.hp.com : =myhost.hp.com ... in which case this definition should be deleted, since it is likely to cause a loop on this host, with recursive addressing. 3. Check your /mail/admin/addressbook.mail file, as well as all local #0/addressbook.mail files, performing the same sort of updates to the addresses therein. 4. Re-initialize Rmail. The only real side effect the change should have is that you can no longer mail to addresses of form: user@host.hp.com by simply specifying: user@host Instead, an address such as: user@host.hp.com must be given. Q. I recently ran into a problem upgrading the D mux firmware on my system. After installing the latest firmware, BOOTEX would no longer "talk" to my mux. The problem was traced to a pre-release (patched) version of BOOTEX. Can you provide a list of the datecodes of BOOTEX and their corresponding revisions? A. Sure. The following table lists the BOOTEX timestamps and corresponding RTE-A revisions: BOOTEX Timestamp Revision Notes: ------------------------ -------- --------------------------- 11:21 PM TUES 4 FEB 1986 2540/4.0 Mux at select code 20 works 5:36 PM MON 3 NOV 1986 4010 Bootex grows to 768 blocks for D mux and Datapair support 7:57 AM THU 1 OCT 1987 5000 ID segment change from 4010 7:24 PM WED 30 NOV 1988 5010 Speed sense disable works 1:23 AM SAT 21 APR 1990 5020 Support for console-less systems 1:51 PM FRI 23 AUG 1991 5250 First SCSI-compatible bootex 1:19 AM WED 8 JAN 1992 5270 Latest SCSI-compatible bootex Any timestamps in between the above are most likely a patched or pre-released version, and may NOT work properly with later revision software or D mux firmware. Depending on whether BOOTEX is on a CI volume or FMGR cartridge, two methods are used to display the BOOTEX file: For FMGR cartridges, you can simply use the LI command as follows: CI> LI,BOOTEX:-32767:CRN (-32767 is the security code) This will list the first record of BOOTEX and show the timestamp on the right side of the display. For CI volumes, BOOTEX is in the reserved area and cannot be listed from CI. The easiest method to list BOOTEX is to load BOOTEX from disc and then use the VCP to list memory. For example: VCP> %LDC for example...(use YOUR bootstring, just replace the B with the L) This will load BOOTEX and return to VCP. Now set the M register to 0 and list memory as follows: VCP> M 002340 100 VCP> M 000100 VCP> L Again, the timestamp will be displayed on the right side of the screen. Thanks to Todd Poyner from the HP1000 lab for the Mail/1000 hints.