1998 HP1000 Guru Column Q: In the last column we described a problem with the A990 TimeOfDay clock, where it did not rollover to the year 2000 correctly. We now have a better solution than the one described. A: A patch has been created that essentially solves the problem. The problem with the A990 TOD clock is that it was never designed to handle CENTURIES. It has alarm registers which are being used to STORE the century value. Of course, since these are static registers, the 2000 rollover means nothing to them. The patch involves a change to the A990 Clock routine that reads the time. If the system time/date are after the year 2000, ReadA990Clock will detect the incorrect century, and first Write the correct date/time to the TOD clock, then perform the Read of the A990 TOD clock. This essentially masks the problem til the year 3000. A patch is available from the Response Center, or via Email AutoReply to: Rte_Support@hpwrcxe.mayfield.hp.com Set the Subject of your message to: SR373456 You will be sent a file containing the instructions for loading the included uuencoded patch. Q: Speaking of patches, are there any other patches to 6.21 that we should be aware of? A: The only patch (as of Nov 1,1997) for 6.21 is the above TOD clock patch. Q: I have installed 10.30 HPUX and now I find that I cannot ftp to my 6.2 system any longer. This worked fine at 10.20. Is this a new problem? A: Yes, this was discovered during testing of 10.30 HPUX and 6.2 RTE-A. Installing the 6.21 (or patches onto 6.2) solves the problem. The assumption made is that the problem is casued by the number of TCP/IP option bytes (greater then 4). Q: I have been using MAIL/1000 for years with virtually no problems. Lately, though, it seems I have been receiving email messages that appear to be truncated. Sentences end in mid word. What gives? A: Yes, I have also seen this and been extremely annoyed by it! The root problem is that MAIL/1000 cannot handle lines that exceed 256 characters. Incoming mail with lines greater than 256 characters are truncated. This problem is field as an SR and perhaps a fix will be forth coming. My theory on why this is becoimg more of a problem is because of the proliferance of Web and PC based mailers. Many of these mailers use a form for creating mail messages that wrap long lines rather than inserting a CR-LF after 80 characters. Those of us still using terminals and terminal emulators, and use the RETURN key don't see this problem. And another problem with MAIL/1000: When you use the Reply or Forward function, this truncates the text lines to 128 characters! Beware... Q: I am trying to use a NS node name of the form: 7eleven.hp.com NSINIT complains that this is an illegal name. Is there a workaround? A: According to the RFCs for NodeNames, they must not start with a numeral. Thus 7eleven is not a legal nodename. It can be used however. NSINIT will not accept it interactively. But if you edit the NSINIT answer file manually, and then run NSINIT, it will give you an error 212, but go ahead and initialize NS with the invalid name. Q: I am using FIFO mode on my mux LUS, with per character scheduling. I have always preferred this as it allows commands to be executed with first obtaining a prompt via the RETURN key. Now that I am using TELNET connections, I know that per character scheduling is not available, but I am not able to get FIFO to work at all. Is something broken? A: Normal FIFO mode requires using the break key to obtain the system's attention. It is possible you are using a terminal emulator or PC that does not send the BREAK to the remote system. This is true for hpterm windows on HPUX. It may be something configurable in the emulator. Q: I am using FST and TF to make tar compatible tapes to move files to a UNIX system. I am finding that some text files are not being converted. They wind up as one long record on the UNIX machine. Why is this happening? A: Text files on the HP1000 can be either type 3 or 4. Type 4 are true text files and are converted by FST/TF by replacing the CR/LF with the newline character. Type 3 files on the 1000 typically contain text, but they can also contain binary data (example: RTE-A SNAP file). Type 3 files are not converted by FST or TF. If you have type 3 text files and need them converted, they must first be copied to a type 4 file. Q: I would like to monitor disk freesapce and have a report sent to me using MAIL/1000. How can I do this? A: Here is a simple script that does what you want. As of 6.2 RTE-A you can also put this in a CRONTAB file to be scheduled at a desired interval. echo hJ frees +m edit `free,| To: walt| Subject: Disk Report| |sc|$|-9|,$k/|er sendmail free This command file does the following 1) Home cursor and clear display 2) Run FREES +m 3) Runs EDIT and captures the output of FREES written to console, and adds the email header lines TO: and SUBJECT: 4) Runs SENDMAIL to mail the file. A CRONTAB entry would look as follows: 0 0 * * 1 ci /cmdfiles/free.cmd This will schedule CI every Monday, and execute free.cmd Q: Now that we are using the LP spooler is there a way to direct output that goes to an LU (using SP) to the LP spooler? A: The only supported way to do this would be to Spool the LU desired to a file, and then use LP to print the file. Example: CI> sp,on,6,filename | Spool output to filename (do not use default spoolfile name, this would cause SP to attempt to print as soon as spooling is stopped.) ....send prints to LU 6 CI> sp,of,6 | Turn off spooling to LU 6 CI> lp,filname | Print spoolfile. Gedanken, a third party consultant, also has a LU redirection driver available. Contact Gedanken at (408) 867-6040 or email to sales@gedanken.com That's all for this time! Q: Where can I find the current end of support dates for HP1000 hardware? A: The latest information can be found on the HP1000/RTE Home Page at http://www.hp.com/computing/rte This information is accurate as of the publication date, but is subject to change. Q: I am trying to replace the power supply in a 20 slot A900 computer. The replacement supply looks different, and on top of that, it won't work when installed. What's the problem? A: The answer to this question requires a bit of history: The original 440W (420W) Power Supply for the 20 Slot A Series computers was sourced from Boschert. This power supply had two optional plug in cards: The 12157A Battery backup and the 12158A 25KHz module. The following table lists the part numbers for these power supplies: New Part Rebuilt Note - reason for change --------- --------- --------------- 0950-0873 0950-0875 Original 0950-0893 0957-0002 Modified to support 25KHz module 0950-1648 0957-0002 Mechanical change 0950-1671 0957-0012 Bettering mounting Around 1987, the Boschert supply was replaced with a newly designed supply from Yokogawa Electric Works, the so called YEW supply. This power supply became a direct replacement for the Boschert supply *and* included both the Battery Backup and 25KHz modules as standard equipment. Here are the YEW power supply part numbers: New Part Rebuilt Note - reason for change --------- -------- ---------------- 0950-1841 0957-0028 Original YEW supply 0950-1962 0957-0041 Screw on bottom bracket, instead of riveted 0950-2039 0957-0047 Battery discharges irrepairably 0950-2100 0957-0051 Fused ON/OFF switch At the time, both the 0957-0012 (Boschert) and the 0957-0051 (YEW) supplies were available. Of course, the YEW supply would work in place of the Boschert, but because the Boschert supplies DID NOT come with Battery Backup or 25KHz, they were not always a viable replacement for a YEW supply. Also, in order for the Boschert supply to *work* without the Battery backup module, a jumper PCA is required. The exchange Boshert Supplies did not include this vital jumper card. Here's where the problem started: Some time in the early 1990s, a decision was made to *combine* the replacement 0957-0012 with the 0957-0051 power supplies. The problem now became one of getting the proper supply to replace a YEW. Ordering a 0957-0051 no longer guaranteed you would receive a YEW supply. You could receive a Boschert If a Boschert supply is used in place of a YEW, two problems exist: 1) The Boschert supply WILL NOT come up because there is no jumper board 2) If a jumper board were found (they were obsoleted years ago), the Boschert supply would *work*, but if the system required Battery Backup or 25KHz, you were in trouble. By the time this mistake was realized, the pipeline was already mixed and the last Boschert part number, 0957-0012 now pointed to the 0957-0051 number. And there were MORE Boschert supplies extant. So the solution was to assign a new part number, 0957-0282, that would guarantee getting a YEW power supply. So the bottom line is this: If you are replacing a Boschert Power supply you can use the 0957-0051 part number. This assumes you will physically move the jumper or the Battery Backup module to the replacement supply. If you are replacing a YEW supply, or a Boschert that has a dead Battery Backup or 25KHz module, you need a 0957-0282. (The reason for this is the Battery Backup and 25KHZ modules are no longer available, thus requiring a YEW replacement.) Q: I am updating to 6.2 from 6.0. When linking SP, (part of VCPLUS) I get undefined sysmbols. What has changed? A: At 6.1, SP was rewritten significantly, and as a result now requires that the library $FNDLB be searched. Most systems already had $FNDLB as part of the default libraries in the gen, but not all. So the answer is to add "Lib $FNDLB" to the list of system libraries in the answer file. Look at the sample answer file, /RTE_A/PRIMARY.ANS. Q: I am using a PC as an email client. When I receive an email containing a uuencoded RTE patch file, the PC insists on "seeing" the uuencoded patch file as a binary attachment. This prevents me from saving the uuencoded patch as a text file, since the PC wants to "decode" it for me. Is there anyway to get around this? A: I have seen this behavior when using Netscape Messenger on my PC. Apparently, either the Mail server or the client itself are "seeing" the line: begin 666 filename and deciding that, aha, this is a uuencoded binary. Which is perfectly reasonable if the binary was intended for the PC. But in this case we only want to save the file as a text file for transfer to the 1000. The obvious answer is, don't use the PC as a mail client, use the 1000! I don't know of any way to make the PC client save the uuencoded attachment as the text file it really is. The only workaround I have used is as follows: After creating the uuencoded file on the 1000, and before mailing, edit the line: begin 666 filename and remove the "b" in begin. Now the PC won't think it's a uuencoded attachment. You can now save the email om the PC as a text file, transfer it to the 1000, reinsert the "b" and uudecode it. This presumes the sender can do this for you before mailing the file. Q: What is the difference in HP1000 versus IEEE Floating Point format? A: Here are the formats: HP Floating Point format (two words) ______Normalization bit | V <------------------ Mantissa -------------------------------> bit: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ----------------------------------------------------------------------- |Sign|N.|1/2|1/4|1/8| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | wd | | | | | |---|---|---|---|---|---| ---| ---| ---| ---|-----| #1 | | | | | |16 |32 |64 |128|256|512|1024|2048|4096|8192|16384| ----------------------------------------------------------------------- <---------------- Mantissa ---------------------------> bit: 15 14 13 12 11 10 9 8 (next line->) ----------------------------------------------------------------------- | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 || |-----|-----|----- |----- |----- |------ |------ |------ || continue--> |32768|65536|131072|262144|524288|1048576|2097152|4194304|| ----------------------------------------------------------------------- <-----------Exponent-----------> bit: 7 6 5 4 3 2 1 0 -------------------------------------- || 6 | 5 | 4 | 3 | 2 | 1 | 0 |Exponent| ||2 |2 |2 |2 |2 |2 |2 |sign | word || | | | | | | | | #2 -------------------------------------- IEEE (VAX) Floating Point format (two words) |<------ Biased Exponent------->||<------- Mantissa ------------>| bit: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ----------------------------------------------------------------------- |sign| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 ||1/2|1/4|1/8|1/16|1/32|1/64| 1 | wd | |2 |2 |2 |2 |2 |2 |2 |2 || | | | | | |--- | #1 | | | | | | | | | || | | | | | |128 | ----------------------------------------------------------------------- <----------------------------Mantissa -----------------------> bit:15 14 13 12 11 10 9 8 7 6 5 (next line->) ---------------------------------------------------------------------- | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |---|---| ---| ---| ---| ---|-----|-----|-----|----- |------|continue--> |256|512|1024|2048|4096|8192|16384|32768|65536|131072|262144| ---------------------------------------------------------------------- <------------ Mantissa ---------------> bit: 4 3 2 1 0 ---------------------------------------- | 1 | 1 | 1 | 1 | 1 | |----- |------ |------ |------ |------ | word |524288|1048576|2097152|4194304|8388608| #2 ---------------------------------------- That's all for now.