1995 HP1000 Guru Column Q. If a program is scheduled to run at an absolute start time, and then to run at a relative offset of say, once an hour, resetting the system time sometimes changes the absolute start time, and some times not. What is going on here? A. If one changes the system time PRIOR to the FIRST execution of the program, the program's ABSOLUTE scheduled runtime is NOT altered. Subsequent to the first execution, the program is now scheduled to run every hour, RELATIVE to the first execution. If the system time is now changed, the RELATIVE runtime is maintained at one hour, thus the absolute runtime is altered to maintain the one hour offset. The system determines if a program is scheduled ABSOLUTELY or RELATIVELY by examining bit 15 of word 18 of the ID segment The following example shows what is happening: Program DataPartition CodePartition Name Prio PC Seg Size Status Size Status Program Status -------------------------------------------------------------------- Session 70 Superuser WALT CI 51 17722c 1 26 in 51 sh waiting for WH Shared EMA used: Environment 70 WH 5 12323 18 in scheduled TEST 5 0 18 dormant Will run in 6 minutes at 10:00:00:000 AM, every hour. -------------------------------------------------------------------- Wed Oct 5, 1994 9:54 am TEST has been scheduled to run at 10 AM, exactly and then every hour thereafter. If we change the system time before 10 AM: CI> TM OCT 5 1994 9:56:00 AM We see that TEST is still scheduled at EXACTLY 10 AM Program DataPartition CodePartition Name Prio PC Seg Size Status Size Status Program Status ----------------------------------------------------------------- Session 70 Superuser WALT CI 51 17722c 1 26 in 51 sh waiting for WH..A Shared EMA used: Environment 70 WH 5 12323 18 in scheduled TEST 5 0 18 dormant Will run in 4 minutes at 10:00:00:000 AM, every hour. ----------------------------------------------------------------- Wed Oct 5, 1994 9:56 am After 10 AM we see the following: Program DataPartition CodePartition Name Prio PC Seg Size Status Size Status Program Status ----------------------------------------------------------------- Session 70 Superuser WALT CI 51 17722c 1 26 in 51 sh waiting for WH Shared EMA used: Environment 70 WH 5 12323 18 in scheduled TEST 5 0 18 dormant Will run in 54 minutes at 11:00:00:000 AM, every hour. -------------------------------------------------------------------- Wed Oct 5, 1994 10:06 am Note that TEST is scheduled to run at EXACTLY 11 AM. Now we adjust the system time again, and examine TEST's scheduled run time: CI> TM oct 5 1994 10:30:00 am Wed Oct 5, 1994 10:30:00 am Program DataPartition CodePartition Name Prio PC Seg Size Status Size Status Program Status ----------------------------------------------------------------- Session 70 Superuser WALT CI 51 17722c 1 26 in 51 sh waiting for WH Shared EMA used: Environment 70 WH 5 12323 18 in scheduled TEST 5 0 18 dormant Will run in 43 minutes at 11:13:13:370 AM, every hour. ----------------------------------------------------------------- Wed Oct 5, 1994 10:30 am Now we see that TEST is no longer scheduled at exactly 11 AM, but has been shifted to maintain the one hour offset from the initial runtime. Note that WH does not show whether the program is absolutely or relatively scheduled. This is the way it is documented to work in the Users Manual under "TM". If you have processes that you want time scheduled absolutely, then what you need is "cron", which will be available with the 6.2 release of RTE-A. cron on RTE-A will be very similar to cron on HP-UX, allowing absolute runtime scheduling. Q. I have just installed a new 12076A LANIC in my A900 system. When I bring up NS1000, NSINIT reports the following error: ** (4101) NSINIT: Error storing Station Addr. Driver Reports:10. and ** (4102) NSINIT: Error Registering MCAST Address. Driver Reports:10. I don't see this problem with an older card. What has changed? A. The firmware on the LANIC card was updated at 6.1. A side effect of this firmware update is that not only must the 12076A LANIC be connected to the MAU and LAN cable BEFORE NSINIT runs, but the MAU must also supply the SQE (Heartbeat signal) This is usually controlled via a configuration switch on the MAU. If the 12076A LANIC detects the absence of the SQE (Heartbeat signal), the error 10 is reported. An SR (5003215079) has been filed to correct this. The following changes were made to the LAN firmware: 1. Modified the LAN firmware to improve the performance a. Reduced the instructions in the Interrupt Service Routines. b. Bypassed some State Machine states. c. Returned the card response as soon as possible. (This fixes a potential 10B driver error) 2. Supported the discard ARP mode on the card. A new subfunction 36B - ARP packet filter mode, is added for the LAN driver to enable or disable the ARP packet filter mode. If this mode is enabled, either the LAN driver (LAN firmware prior to 6100) or the card (LAN firmware revision 6100 & 6110) will discard ARP request packets with target IP addresses that do not match the local IP address. Note that the firmware does not require 6.1 software. But only the 6.1 software will be able to use packet filter mode. The revision 6100 12076A firmware was found to have a problem, thus the current revision is 6110. The new ROMs are available in kit form as 12076-60003. The new part numbers are 12076-81009 & 12076-81010. Notes: 1) There should be no compatibility issues with new firmware and older software drivers. 2) NSINF, L can be used to determine the revision of the LAN firmware. The following shows part number/revision history: Part number Revision (decimal) Notes --------------------------------------------------------------- | 12076-81004/5 | 2547 | Original release | | | | | | 12076-81007/8 | 3136 (6100 OCTAL) | Should have been | | | | 6100 DECIMAL | | 12076-81009/10 | 6110 | Current | --------------------------------------------------------------- Q. What are the latest supported SCSI disks and MO drives for RTE-A? A. The following are the newest additions to the list of supported SCSI peripherals: C2550B HP Model 1300T 1.3-GB Optical Subsystem C3040R/T Series 6000 2GB SCSI Mass Storage System C3041R/T Series 6000 4GB SCSI Mass Storage System C3044U 2GB Single-Ended SCSI Disk Expansion Kit These are currently supported on RTE-A revision 6.1. Testing for support on revision 6.0 is being done and may be completed by the time you read this. Note: For customers on older revisions who are NOT ON SUPPORT and wish to move to Rev 6.1, it will be necessary for them to re-purchase the O/S software (P/N = 92077A). Other products/mechanisms are slated for testing, and will be added to the list of supported products as soon as all necessary testing has been successfully completed. Q: I have my own RTE-A Driver written for a custom IO card. This was written many years ago on an A600 processor. I now find that this same driver does not work correctly on the A990 Processor. It appears to be a timing problem. Is the speed of the A990 versus the A600 causing my problem? A: When writing I/O drivers, it is often necessary to set up a timing loop while waiting for an interface card to acknowledge receipt of the last command. Typically, if the loop is exited before the card acknowledges receipt of the command, the driver then sets an error condition alerting the calling program that an error has occurred. Most often timing loops fall into one of two categories: those that fall through the loop based only on the number of iterations through the loop and those that wait for the flag flip flop on the I/O card to be set (or cleared). Typically the latter type will also have a counter associated with the loop to prevent waiting for the flag forever. Here are some examples: Example 1: lda count isz a jmp *-1 ... continue Example 2: lda count ina,sza,rss jmp error sfs card skip if flag set jmp *-3 ... continue In the first case, the driver writer has determined that a certain amount of time must elapse before proceeding beyond the loop. The length of time is determined by the value of "count" and the execution times for the "isz" and "jmp" instructions. The execution times are CPU-dependent so, usually, the driver designer will set up count based on the CPUID or on the worst case scenario (i.e., set count large enough so that even on the fastest A-Series - previously the A900 - enough time will elapse before proceeding). Since the A990 is now much faster than the A900, these types of loops may now fail if "count" is not adjusted. In the second case, the driver is waiting for the flag to be set. The driver writer has determined that there is an error if the flag has not been set in "count" iterations through the loop. The value of "count" again is dependent on the CPUID and the instruction execution times. In addition, the behavior of the I/O card is understood such that the driver writer knows the maximum time the card will need to set the flag. Based on that information, the value of "count" can be determined. In an effort to minimize the effects of moving drivers from other A-Series CPU's to the A990, the timing has been changed for the Skip if Flag Set (SFS) and Skip if Flag Clear (SFC) instructions. This is not only because the A990 has a faster CPU cycle time than the A900, but also because the behavior of the instructions has been modified. Let's describe the timing of the SFS and SFC instructions on the A900 first. The SFS instruction decides whether or not to skip, based on the value of the flag. If the instruction decides to skip, then the skip is taken, and the next instruction is fetched immediately. If the instruction decides not to skip, a check is made to see if the currently executing instruction has the same opcode as the previous SFS instruction. If this is true, the machine waits an extra amount of time before fetching the next instruction. The reason for this behavior is that if the previous SFS instruction has the same opcode as the current SFS, then there is a good chance that the computer is in a "skip flag set" loop, waiting for some I/O process (DMA, for example) to complete. The skip on flag microcode runs so fast that it would keep the I/O backplane too busy with I/O instruction broadcasts, instead of letting much DMA traffic occur. Therefore, the microcode slows itself down to free up more bandwidth on the I/O backplane. The SFC instruction on the A900 does not have this extra wait, even when the current SFC opcode is the same as the previous SFC opcode. It was assumed that no programmer would write a loop that used the SFC instruction to wait for DMA to complete. The SFS instruction on the A990 has the same behavior as on the A900. That is, if the current SFS opcode is the same as the previous SFS opcode, an extra amount of waiting is done. The SFC instruction on the A990 now includes the same extra wait as the SFS instruction. Again, the extra wait only occurs if the skip is not taken, and the current skip flag opcode is the same as the previous flag. The amount of time the instruction waits was calculated so that the entire time spent in the "SFS loop" is as close as possible to that spent on an A900. The desired effect is to minimize the number of changes to drivers when moving from previous A-Series processors to an A990. Here is a table to help clarify matters: A900 A990 SFS, skip If same opcode, If same opcode, not taken wait extra time wait extra time SFS, skip Don't wait Don't wait taken SFC, skip Don't wait If same opcode, not taken wait extra time SFC, skip Don't wait Don't wait taken Q: I am trying to install the LP Spooler on my 6.1 ARPA/1000 system. I get undefined externals when linking RLPOUT and RLPDAEMON. I checked the .lod files, and have referenced the networking libraries. Am I missing something? A: Yes, you are missing the Berkeley Sockets Library, which is required for linking RLPOUT and RLPDAEMON. Unfortunately, the BSD_CDS.lib library is not included with ARPA/1000. If you have the NS-ARPA/1000 product, then you could use the BSD_CDS library from there. In the future, the BSD library may be included with the ARPA/1000 product. In the meantime, if you want to use the LP Spooler with remote HP-UX machines, you can obtain the BSD library from the Response Center. This will enable you to link RLPOUT and RLPDAEMON. Q: For several years I have been experiencing a problem with the RS program. It consistently fails with a RUNTIME ERROR 601. This problem has persisted over several different system updates. The program itself has been compared to a functioning copy on another system (The load maps are identical). What else should I be looking for? A: Problems that are unique to a particular SYSTEM, and that reoccur over several revisions certainly indicate a problem that is UNIQUE to the SYSTEM in question. So what is UNIQUE to a particluar system? Well, certainly the location and system manager are unique. Another uniqueness is the hardware itself. In this particular case, the solution was discovered almost accidentally in the SYSTEM generation ANSWER FILE. The RTE-A Generator program is very forgiving and will not always report an error when in fact an INCORRECT sequence of commands are given. The problem in this answer file was a missing "END" statement in the System Messages section of System Common. re,/TE_A/%msgtb end re,/RTE_A/%$m000 end <---------This END was missing re,/VCPLUS/security.rel end end Regenning with the correction solved the problem of RS aborting with RUNTIME ERROR 601. Sometimes a close examination of the system answer file, and comparing it to the sample supplied with RTE-A may be the only way to find the problem. Sent 2/13/95 Q: I am using the following program to create a symbolic link for a file /DEV/TTY0 to point to the system console. When the program then opens and writes to the symbolic link, it does not send the output to LU 1, and it appears to corrupt the link file. What am I doing wrong? Here's the program: ------------------ ftn7x,s program slink implicit none integer i,err integer dcbslink(16),dcb(144) integer FmpOpen,FmpClose,FmpWrite,FmpMakeSLink if (FmpMakeSLink(dcbslink,err,'1','/DEV/TTY0').lt.0) goto 76 if (FmpOpen(dcb,err,'/DEV/TTY0','rwl',1).lt.0) goto 76 write(1,*) err if (FmpWrite(dcb,err,16HHello, world... ,16).lt.0) goto 76 75 goto 77 76 call FmpReportError (err,'/dev/tty0') 77 err = FmpClose (dcb,err) end A directory list of the link file shows the following: lrw----r-- 1 walt nogroup 1 Feb 6 14:49 tty0 -> hello, world A: The problem with this program is the FmpOpen call. Though you are passing FmpOpen the name of a symbolic link file, you DO NOT want to use the 'l' option. The 'l' option is used only when you want to open the symbolic link file itself. In this case, since you want to open the destination, LU 1, do not use the 'l' option. The FmpOpen should look like this: if (FmpOpen(dcb,err,'/DEV/TTY0','rw',1).lt.0) goto 76 This will "open" LU 1 and the FmpWrite will "do the right thing" Q: For years, my system disk configuration has included a 400 track LU 16 and a 943 track LU 17. This is the way the original RTE-A Primary system was configured. I see now that the 6.1 Primary has changed the track map so that LU 16 is 4096 tracks. Since I boot from LU 16/17, is there any way to reconfigure these LUs without using a second disk as a temporary boot LU? I only have the one disk on my system. A: Yes this can be done. It will require planning and adequate freespace on the disk in order to move /SYSTEM and /PROGRAMS to an LU that resides past LU 16/17 Perhaps a 'picture' of the disk configuration would help: Current configuration: LU #TRACKS CONTENTS ---------------- 16 400 BOOTEX 17 943 /SYSTEM & /PROGRAMS (Boot LU) 18 320 /USERS 19 266 /SCRATCH 20 352 misc 21 2229 misc 22 821 misc 23 5413 misc For example, lets say we want to reconfigure LUs 16-17 as a single LU, using LU 23 as our temporary boot LU. The steps are as follows: 1) Perform an ASAVE of LU 16 and 17 2) Create a /TARGETPROGRAMS and /TARGETSYSTEM on LU 23, making sure there is enough freespace to hold the files from /PROGRAMS and /SYSTEM. FOWN can be used to determine how large these directories are. 3) Copy /PROGRAMS and /SYSTEM to /TARGETPROGRAMS and /TARGETSYSTEM respectively. 4) Regenerate your system to combine LU 16 and 17 into one 1343 track LU, eliminating LU 17. DO NOT change any parameters for any other disk LUs, especially LU 23 in this example. Place the new system and snap file in /TARGETSYSTEM. 5) Create a boot command file that RPs programs from /TARGETPROGRAMS, and references the new system and snap and swap file in /TARGETSYSTEM. Place this boot command file in /TARGETSYSTEM. 6) Reinstall BOOTEX (on LU 16) to mount LU 23: (Assumes FMGR LU 16) INSTL Enter snap file,system file,destination file,lu,source file New_snap_file,New_system_file,BOOTEX:-32767:16,23,/RTE-A/bootex 7) Boot the new system using the boot command file created in step 5 8) Once the system is booted successfully, you must re-initialize the new LU 16 as either FMGR or CI, whichever you want. For a CI volume: CI> IN,16,768 (768 to reserve room for BOOTEX) For a FMGR cartridge: FMGR: MC,16 FMGR-103 FMGR: IN,,-16,16,LU16 (or whatever CRN you want) FMGR: At this point, you should have a large empty LU 16 with BOOTEX still intact( the IN commands above WILL NOT destroy BOOTEX) If in doubt simply run INSTL again to make sure. To now make LU 16 the boot LU perform the following steps: (similar to above, only reversed) 1) Create a /PROGRAMS and /SYSTEM on LU 16. 2) Copy /TARGETPROGRAMS and /TARGETSYSTEM to /PROGRAMS and /SYSTEM respectively. 3) Reinstall BOOTEX (on LU 16) to mount LU 23: For a CI LU 16: INSTL,New_snap_file,New_system_file,0,16,/RTE-A/bootex For a FMGR LU 16 INSTL Enter snap file,system file,destination file,lu,source file New_snap_file,New_system_file,BOOTEX:-32767:16,16,/RTE-A/bootex 4) Boot the new system using your original boot command file. Your system should now be as it was, but with LUs 16 and 17 combined. One word of caution: Once you start this procedure, carry it through to completion, since if the system is accidentally turned off or halted in the middle, it may not reboot. If this does happen, use your bootable ARSTR and restore the ASAVE made in step 1. Q: How does the HP1000 Guru manage his system backups? A: This is a question that every system manager must ask himself. Bill Hassell once said, "There are two types of computer users: those who have lost data and those who are going to someday lose data". A clearly defined, consistent backup strategy will go a long way to making such loss relatively painless. The HP1000 family of systems has had a plethora of backup utilities available over the years. I won't delve into all of these, rather I will describe the method I use to make backing up an RTE-A system simple, effective and best of all automatic. The two primary questions about backup strategy are HOW and how OFTEN. The first question will be the focus of this discussion, the second is generally answered by asking yourself how much data can you afford to lose. In my case, I don't want to lose any data so I backup every night. First of all, the system I am using is an A990 running 6.1 RTE-A. I have several tape devices available, and currently I am using a 1.3 Gbyte DDS drive. The advantages to using the DDS should be obvious: Speed, storage capacity of the media and physical storage space the tapes require. I can carry my entire system backup in my shirt pocket. Not recommended while bicycling. In order to recover from a catastrophic system disk failure, an ASAVE backup is the easiest and best way to recover. It is possible to reconstruct a system from a fully equipped memory based system and a full FST backup. But it certainly requires more preparation and effort. (Note: The 6.1 Primary system is installed in this fashion, but it includes a custom program, !RESTORE, in the memory based system which performs all the work). In my case, I simply perform an ASAVE of ALL disk LUs after any major system update/regen, or every 2 months. And of course, I have a WORKING memory based system in order to recover in the event I lose my boot disk. Second, I backup files nightly using FST. I initially create a FST backup tape, using a mask including the "B" qualifier, and the C option (See example 2). This performs an incremental backup using the backup bit, and then clears the backup bit. Subsequent backups are then Appended to this tape nightly. My nightly backup is time scheduled from the welcome file to run at 1 AM, via a program (See example 1) This program performs an FST backup using a command file (See example 2), logging the results to a file, and then using MAIL/1000, mails the FST logfile to me. This way, when I come in in the morning, I expect to have Email from my system with the result of the overnight backup. I do this on several systems, with the mail being sent to my central RTE-A system where I read all my Email. In this way, I never have to remember to check the logfile, it just appears in my Email. I can then review it for any problems, and delete the message. The files that are being backed up, via /cmdfiles/fst_cmd.cmd, can be easily modified. The example shows a simple @.@.eb which backs up all files, everywhere, checking for and clearing the backup bit. In actuality, on my systems, I backup selected directories. Example 1 ----------- FTN7X,l program nitly_fst c cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc c c NITLY is time scheduled nightly and performs an incremental c FST backup of all files that are new or have the backup bit set c A fresh FST is started AFTER a full system ASAVE is performed c c See file fst_cmd.cmd::cmdfiles for set of files being c backed up. c cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc c implicit integer(a-z) integer param c c Schedule FST with transfer file to perform backup c call FmpRunProgram('fst,tr,fst_cmd.cmd::cmdfiles',param,back) c c Schedule SENDMAIL to mail FST log file c call FmpRunProgram('sendmail,-k,/temp/fst.log',param,sendmail) c c Schedule EDIT to clean up the log file for next time c call FmpRunProgram('edit,/temp/fst.log|4,$k/|er',param,edit) end -------------- Example 2 --------- * FST backup command file * * This script performs an incremental backup of all * files nightly to DDS tape on REMUS. * * Full ASAVE peformed when appropriate, ll /walt/fst.log a ti REMUS Incremental backup mt 5 Quiet Append Clear Keep ba @.@.eb Go ----------------------------------- A consistent backup procedure will go a long way towards minimizing any data loss when it occurs. Sent 4/13/95 <:00218.1053> Q: I have recently upgraded to 6.0/6.1 revision of RTE-A. Since that time I have had various programs, for instance DL or LS, abort with a Memory Protect, or other error. Sometimes the program doesn't give any error, but it does not give the expected result. Sometimes other running programs are aborted with an EM82 error. These are all CDS programs. Is CDS broken at 6.0? A: Well, something is broken, but it turns out it is not CDS. But it is definitely related to CDS. A CDS program can be linked as a shared program. In fact, this is a primary feature of CDS programs, that multiple copies can all share the same code partition in memory, and each user has a unique data partition. This scheme is managed via a table in the operating system known as the Shared Program table. And like almost every table in RTE-A it's size is determined by a parameter in the generation answer file. The table consists of a 5 word entry for each shared program, and the maximum number of shared programs is specifed with the SP command in the generation. For example, a command of SP,5 will allocate a table of 25 words, and will allow up to 5 concurrently executing shared programs. Now you may be wondering what happens if, in this example, a 6th shared program is run. What happens is the operating system detects that there is no room in the shared program table, reports a FMP error -241, and then runs the program Unshared. Note that if the program is scheduled from a CI,RU command the FMP error -241 will not be displayed. If the program is RPed from CI, then the FMP error will be reported by D.ERR as follows: CI> rp dl Can only run unshared. File: DL; Program: DL At 6.0, ID segment changes were made. One of the biggest changes was the creation of ID segment extensions, which reside in XSAM. Prior to 6.0, the entire ID segment (48 words) resided in the operating system. In order to accomodate the EMA/VMA enhancements at 6.0, the ID segments needed to increase in size. Since operating system size is always a concern, it was decided to move some of the ID segment information (the newly coined "extension") to XSAM. This also made the OS portion of the ID segment smaller (45 words). So significant changes had to be made to IDRPL to create these new ID segments/extensions, and ALL programs had to be relinked at 6.0 since the previous ID segment format is not compatible with 6.0. Now the problem: When IDRPL detected that the Shared Program Table was full, and proceeded to RP the program as Unshared, he "forgot" to also intialize the ID segment extension in XSAM. Now since the ID segment extensions in XSAM are not dynamically allocated, rather they are reserved at the beginning of XSAM, a program now has ID segment extension data from whatever program PREVIOUSLY was using that same ID segment. Thus the results will be unpredictable. Not only that, if the PREVIOUS program was using SHEMA, since this information is contained in the ID segment extension, then when the incorrectly RPed program terminates, the OS may incorrectly update the SHEMA table, leading to potential EM 82 errors. In one case, the SHEMA table In-System count was decremented to 0, and because the SHEMA partition was not locked, the system deallocated the SHEMA partition of an active SHEMA program. Not very nice! The easy workaround is to make sure you never exceed the maximum shared programs. The standard generation answer file has 30 shared programs allowed, which should be adequate. The problem can occur when you are trying save OS space and reduce this value to 5 or less, or you have a lot of shared CDS applications. This problem exists in both 6.0 and 6.1 and a fixed version of IDRPL is available. Q: I am trying to setup anonymous FTP access to my RTE-A system. For security, I only want user anonymous to have access to a disk which contains the LS program and not have access not have access to all of /PROGRAMS. I cannot get LS to work. A: The problem is when LS is run from within FTP, FTPSV is looking for FTPLS. So to make this work, the LU that user anonymous has access to should contain a directory, for instance, /PUB that contains FTPLS.RUN. ALso, make /PUB the home directory for user anonymous. You can now use 'anonymous FTP' to the 1000 and have controlled access to files and programs. Q: RTE-A now supports 4 Gb DDS tapes with compression. How do I turn on compression, and what kind of compression ratio can I expect? I don't see any command in FST to enable compression, in fact, the SD command doesn't do anything and always returns 0 for the density. A: Right, FST does not have anyway to set compressed mode for the DDS tape drive. Nor can it tell you if the drive has compression enabled. But nevertheless, it is supported and works using a control command documented in the Driver Reference manual. It's the same command used for setting the density and compressed mode for 7980S SCSI drives. First a comment on density: DDS drives don't support changing density so they are genned with DP2 = 0. This is how the system can tell if a 7980S or DDS tape drive is present. If it is genned as 0, it cannot be changed to any non zero value, though no error is reported. If DP2 is genned to a non-zero value, it cannot be changed to 0, the the driver will reject any attempt to set it to 0. So how do we enable compression? With the same CN command we have used for setting density on streaming tape drives. To enable compression on a DDS tape drive use the following command CN,,15B,, Where Density is 0 for the DDS. (800/1600/6250 for the 7980S) And compression has the following meanings: 0 - Use device defaults 1 - Enable compression -1 - Disable compression The DDS drives with compression have hardware configuration switches internal to the mechanism. These switches are used to determine the following characteristics: Device default: Compressed or Standard Control: Changeable or Not By default, the tape drive should come set for Standard mode, changeable. The amount of compression depends upon the data being stored. Typical compression ratios range from 2 to 3 times, in other words anywhere from 4 to 6 Gbtyes of data can be saved to a 2 Gb DDS tape. Here's a testimonial from a long time RTE user testing a DDS drive with a 2 Gbyte (90Meter) tape: "I put 10 complete full backups on a 90 Meter tape using compression. It ran out of tape on the 11th append. Each full backup was reported by FST to be 573,127,680 bytes. That's a total of 5,731,276,800 bytes with some tape left over, but not enough for another full backup." A: What are the physical limits on disk/LU sizes for RTE-A nowadays? Are we still limited to 32k tracks and 512 Mbyte? Q: No. As of 6.1, larger disk LUs are supported by the SCSI disk drivers and also by the file system. For SCSI disks, the following limits apply: Maximum Maximum Tracks Sectors/Track ------------------------ 65,534 256 This allows for a LU of about 4,096 Mbyte. But FMP limits the number of sectors per track to a maximum of 128, so a file system LU has a maximum size of about 2,048 Mbyte. Additionally, old FMGR disk LUs are still limited to 64 blocks per track, or about 1,024 Mbyte. CS80 disk drives still have a limit of 32,767 tracks, but can have 128 blocks per track, so the maximum LU for a CS80 disk (and file system volume) is now 1,024 Mbyte. Q: So what is the largest DISK drive I can configure on a RTE-A system? A: As mentioned previously, the absolute largest LU that can be configured is 4Gb. And since we have a maximum of 255 LUs the theoretical largest disk drive that can be configured would be about 1,020Gb. Of course, FMP limits disk LUs to be between 1 and 63, and 2 Gb, so for FMP, the maximum disk size would be about 126Gb. In case you were wondering, the starting block parameter is not even an issue, because we run out of LUs first. The starting block of a disk LU is a two word value (unsigned integer) so can be in the range 0 - (65536*65536) or 4,294,967,296 blocks. This is about 1,024Gb. Q: Is there a way to submit an HP1000 or HP-RT SR via Email? A: Yes. If you would like to submit a Service Request via e-mail, send a message to: sr_submit@hpwrch.mayfield.hp.com This is a valid address for all SRs having to do with the HP1000 operating system as well as HP-RT and Real-Time HP-UX products such as GFoX, Softbench Link/1000 or the new Migration Tools. If you do not have e-mail you can mail the request to your local Response Center. Contact your local sales office for the postal address. Or if you have a support contract with the Hewlett-Packard Response Center, you can call through the same channels that you would use to ask a question. The Response Center will verify the problem and submit the Service Request reporting the problem to the lab. You can submit Service Requests (SRs) to report a problem or request an enhancement to a product. When submitting an SR, please provide the following information so it can be processed without delay. If the information is not complete, it will affect the timeliness of the response. Real Time Product Service Request Information --------------------------------------------- User name: Company name: Response Center Handle (if you have one): Mailing Address: E-mail Address (if you have one): Phone number: Is this a request for enhancement or report of a defect? System type: 9000 model 74Xrt, 9000 model, or 1000 A/M/E/F series? Operating system: HP-RT, RTE-A, or RTE-6 Operating system revision: RTE: 6.1 or 6100 HP-UX: 9.0X HP-RT: A.02.01 Product: RTE-A, RTE-6, HP-RT, OTSrt, BPNrt, GFoX, etc. Have any patches been installed on the system that has the problem? If so, what are the SR numbers associated with them? Summary of Service Request: For problem reports- Provide detailed information that will enable the lab to duplicate the problem. A short piece of code demonstrating the problem is a great advantage. If you are sending e-mail, you can create a shar package containing all necessary files for HP-RT issues. or For enhancement requests- Describe exactly what you would like to see in detail. Impact to your business: For problem reports- Describe how this problem impacts your business by selecting one of the options below. Please feel free to add your comments describing the impact. - Are you unable to use the product? - Do you require a temporary solution? - Are you able to use the product with limitations? - Are you only slightly inconvenienced? For enhancement requests- Describe how incorporation of this request would affect your business. How would your application be improved? What benefits would you see if this request were incorporated? How would you be affected if it were not incorporated? You will be sent an e-mail message or letter containing a reference number for each problem or enhancement to the product submitted. This number can be used to refer to the problem to obtain status at a later date. Q: Now that we have a program, A990FWID, that works fine for the A990, how about a version for other A Series? Particularly the A900 so I can tell if I have Rev4 firmware or not. A: Here you are. There are two sources, FWID.FTN is the main and CHIPS.MAC is the subroutine that calls the .fwid instruction. This program will return the following information: - CPU type (A400,A600,A700,A900, A990) - Six lines of revision information for the firmware. - If on an A900, whether the firmware is Rev4 or not. For example, on an A900 with Rev4 firmware, you will see the following: CPU Model is A900 Product #: 0 Octal Revision: 011404 Product #: 1 Octal Revision: 011404 Product #: 2 Octal Revision: 005004 Product #: 3 Octal Revision: 005004 Product #: 4 Octal Revision: 006004 Product #: 5 Octal Revision: 006004 Congratulations, you have rev4 f/w Figure 1 FWID.FTN ------------------ c The .fwid instruction allows a program to obtain a number c identifying the processor's firmware revision. On the A900 c the base set firmware is divided into 6 banks of 1k microwords c each. When the .fwid instruction is executed, the B register c specifies the bank (0-5) and the A register returns two bytes c of identification information. The lower byte contains the ROM c package revision and the upper byte contains the revision for c the specific bank. The package revision is incremented only when c all banks of the firmware are modified. Package numbers 0, 1, c and 2 were used for A900s without CDS. The package number was c changed to 3 when CDS support was added and changed to 4 for the c latest firmware update. c c The Communicator lists the part numbers for all the firmware c revisions along with a brief description of the modifications. c Previously, there was no way to match the part numbers c with the values returned by the FWID instructions. The following c table provides this correlation. Bank is the B register input c to FWID. The A register output is shown in decimal, octal and hex. c c Part Numbers Bank Dec. Octal Hex c ----------------------- ---- ---- ----- ------ c 12201-80024 to 29 0,1 7,3 3403b 0x0703 c 12201-80030 to 35 2,3 7,3 3403b 0x0703 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80024,44,26-29 0,1 8,3 4003b 0x0803 c 12201-80030 to 35 2,3 7,3 3403b 0x0703 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80045 to 50 0,1 9,3 4403b 0x0903 c 12201-80030 to 35 2,3 7,3 3403b 0x0703 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80045 to 50 0,1 10,3 4403b 0x0903 c 12201-80030 to 35 2,3 7,3 3403b 0x0703 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80060,53-55,61,62 0,1 11,3 5403b 0x0B03 c 12201-80030 to 35 2,3 7,3 3403b 0x0703 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80060,53-55,61,62 0,1 11,3 5403b 0x0B03 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80036 to 41 4,5 7,3 3403b 0x0703 c c 12201-80060,53-55,61,62 0,1 11,3 5403b 0x0B03 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80070 to 75 4,5 8,3 4003b 0x0703 c c 12201-80076 to 81 0,1 13,3 6403b 0x0D03 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80070 to 75 4,5 8,3 4003b 0x0803 c 12201-80084 to 89 0,1 14,3 7003b 0x0E03 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80070 to 75 4,5 8,3 4003b 0x0803 c c 12201-80090 to 95 0,1 15,3 7403b 0x0F03 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80070 to 75 4,5 8,3 4003b 0x0803 c c 12201-80096 to 101 0,1 17,3 10403b 0x1103 c 12201-80063 to 68 2,3 8,3 4003b 0x0803 c 12201-80070 to 75 4,5 8,3 4003b 0x0803 c c 12201-80103 to 108 0,1 19,4 11404b 0x1304 c 12201-80109 to 114 2,3 10,4 5004b 0x0A04 c 12201-80115 to 120 4,5 12,4 6004b 0x0C04 FTN7X Program fwid integer revision,product,cpu,cpuid revision = 0 product = 0 c Note the order of cpu number is the order in which the c computers were introduced. The A600- was the first c the A900 came before the A600+ and so on. c cpu = cpuid() if (cpu.eq.10) Write(1,*) 'CPU Model is A990 ' if (cpu.eq.7) Write(1,*) 'CPU Model is A400 ' if (cpu.eq.5) Write(1,*) 'CPU Model is A600+' if (cpu.eq.4) Write(1,*) 'CPU Model is A900 ' if (cpu.eq.3) Write(1,*) 'CPU Model is A700 ' if (cpu.eq.2) Write(1,*) 'CPU Model is A600-' do while (i.le.5) call chips (product, revision) write (1,100) product,revision product = product + 1 i =i + 1 enddo if (cpu.eq.4.and.revision.gt.3075) write(1,*) / 'Congratulations, you have rev4 f/w' if (cpu.eq.4.and.revision.le.3075) write(1,*) / 'Sorry, you do not have rev4 f/w' 100 format ("Product #: ",i2," Octal Revision: ",o6) end Figure 2 CHIPS.MAC -------------------- macro nam chips,7 ent chips ext .entr mic fwid,105301b,0 Product nop Revision nop chips nop jsb .entr def Product ldb @Product Product number to be identified. fwid Get rev # sta @revision Return the revision number. jmp @chips end Q: Earlier this year, you described a problem that manifested itself when using revision 6110 of the 12076A LAN firmware. The problem was a NSINIT error: ** (4101) NSINIT: Error storing Station Addr. Driver Reports:10. and ** (4102) NSINIT: Error Registering MCAST Address. Driver Reports:10. What is the status of this problem? A: At the time it was believed to be a problem with the 6110 firmware, since the previous 2547 firmware did not exhibit this behaviour. Subsequently, it was found that the failure only occured when the SQE or so-called Heartbeat was not present. SQE is supplied by the MAU and serves as a Signal Quality Error indicator. Some LAN transceivers allow this signal to be turned OFF by the user. Ethernet transceivers typically do not supply SQE. The 12076A LANIC Installation Manual (p/n 12076-90001) documents the differences between 802 and Ethernet transceivers, and also describes the so called Ethernet stub cable which must be used when connecting to existing Ethernet hardware. This cable is supplied with the 12076A as option 001. One of the differences with the Ethernet cable is a jumper in the LANIC hood, called the "Ethernet sense jumper". It simply grounds pin 24 to pin BB. This jumper "tells" the LANIC firmware that we have Ethernet hardware, and the firmware will not expect the SQE signal. This will allow NS to work. Node Manager will perform a successful Loopback test in the absense of SQE with the Ethernet cable. Chapter 2 of the 12076A manual describes the two cables. The part numbers for the two cables are as follows: 12076-63001 IEEE 802 LANIC will expect SQE 12076-63002 Ethernet LANIC will NOT expect SQE If you are using Ethernet hardware, you must use the -63002 cable to prevent the firmware from expecting SQE. IEEE 802 is the recommended standard to use. The 12076-63001 cable can be modified to work in the absence of SQE by opening the card hood connector and connecting a jumper wire between pins 24 and BB Q: Is there an easy way to have MAIL/1000 synchronize addressbook.mail files between systems without having to manually copy the file or write a program? A: Yes, there is an easy way, using the file '/mail/admin/nitely.cmd'. If this file exists, MAIL will excecute it at midnight every night. This file can contain any commands you might wish executed. For example, you might use it to copy the addressbook.mail file to other systems in your network, using DS Transparency or FTP. You could even use it to perform nightly system backups, instead of writing your own program as I showed you last time. Here are some sample commands: Figure 3 Nitely.Cmd --------------------- * * File /mail/admin/nitely.cmd * * The following will copy the address file from the local node * overwriting the existing file at node 1 and node 2. * co /mail/admin/addressbook.mail /mail/admin/addressbook.mail>node1 d co /mail/admin/addressbook.mail /mail/admin/addressbook.mail>node1 d * * * FTP copy the addressbook file * ftp /cmdfiles/ftp.cmd * End of nitely.cmd Figure 4 Ftp.Cmd ------------------- Contents of: /cmdfiles/ftp.cmd open chekov user manager hp put /mail/admin/addressbook.mail ex Q: Whenever I update my system and rename directories, such as /libraries, I seem to run into problems. If I logout and login, things work the way they should. It seems I cannot just rename my directories without logging off and on. What gives? A: If you have a given PATH set, and the directory pointed to by that PATH is renamed, either with RN or MV, then the PATH information is ALSO changed. For example: CI> path 1 UDSP #1: /WALT/ [current WD] /PROGRAMS/ CI> rn /programs /targetprograms CI> path 1 UDSP #1: /WALT/ [current WD] /TARGETPROGRAMS/ One can see that PATH 1 followed the name change. This can be convenient in this example, since now /TARGETPROGRAMS contains the former /PROGRAMS and your PATH 1 will find them. A problem can occur, however, if you are using PATH 3 for your libraries. For example: CI> path 3 UDSP #3: /LIBRARIES/ CI> rn /libraries /old_libraries Renaming /LIBRARIES to /OLD_LIBRARIES.DIR ... [ok] CI> path 3 UDSP #3: /OLD_LIBRARIES/ If your system answer files specifies the following for libraries: li,#3/ li,#3/ ..etc you are relying on PATH 3 referring to /LIBRARIES, which it doesn't anymore. This can cause confusion. If you logoff, and logon again now PATH 3 will point to /LIBRARIES again since it is set each time you logon. I am not aware of any other system that dynamically changes PATH settings. There is also one slight inconsistency in RTE concerning the working directory: CI> wd Working directory is /WALT CI> pwd /walt CI> mv /walt /walts CI> wd Working directory is /WALTS CI> pwd /walt PWD still shows the original working directory, where wd shows the new name. Q: I always struggle when trying to transfer relocatable files to my 1000 using a 9000 machine as a go between. Even when the two machines are connected together, I seem to always run into problems with file types and timestamps. What is the best way to transport RTE files via a 9000? A: The best way to transfer these files is via an FST disk archive. This will maintain the file type information, so when the files are restored to an HP1000 they will be in the correct format and also will have the original file timestamp information. This can be used later to verify what you have installed. To create the desired FST archive follow these steps: 1. Set your working directory to the desired location: CI> wd //...etc 2. Run FST to create an ARCHIVE file of the desired files: CI> FST FST> mt /scratch/archive FST> ba @ 20 files selected FST> go FST> ex All of the desired file are now in one archive file. It can be copied to tape in tar format and restored to an HP9000. Or the file can be FTP'ed to the desired location. When the file is restored onto the HP1000, it is still an archive file. To restore it to original individual files, use FST: CI> fst FST> mt 24 FST> re @ /scratch/archive FST> go FST> un FST> mt /scratch/archive FST> re @ //@ FST> go FST> ex This will restore the files, maintaining all the file attributes. This is the best way to move files between systems. Q: I have updated from DS/1000-IV to NS/1000, using DS/1000 compatible services. I have a program that accesses the NRV table in the operating system, but now that program no longer works. How can I access the NRV table when running NS/1000? A: In NS/1000, the larger DS tables were moved from SMB (System Memory Block) to DSAM. SMB is the memory in the system map that is specified by the MB command when the system is generated. DSAM is the shared memory area used by NS. It is allocated as a SHEMA by the MMINIT program with the name #DSAM. During initialization, the name is changed to ,,,DS. After initialization DSAM is accessed through map set 6 using cross map instructions. To access DSAM, a program must be in privileged mode and have map set 6 in its working map. This is done by the routine DS_EnterCritical. In addition to setting the data2 map to 6, DS_EnterCritical uses a dispatch lock or a resource number lock to synchronize access to DSAM by the NS programs. When a program is finished with DSAM, it must call DS_LeaveCritical to restore its original working map and release the lock. In most cases the dispatch lock is used. The resource number is used only when a critical program has a CDS segment fault or it is being run with symbolic debug and it is stopped in a critical region. In the latter case, debug will report an SR violation, but you can continue to debug the program. Programmers should read chapter 12 of the RTE-A Programmer's Reference Manual to understand the consequences of privileged mode and dispatch lock. The time a program spends between calling DS_EnterCritical and DS_LeaveCritical should be minimized. Because Fortran uses the data2 map to access constant strings in code space one must use the $CLIMIT 32767 directive or be sure that constant strings in code space are not accessed between calling DS_EnterCritical and DS_LeaveCritical. Here are the calling sequences for DS_EnterCritical and DS_LeaveCritical: call DS_EnterCritical(wkmap, error) wkmap - integer*2 - output Returns the program's working map register. error - integer*2 - output Returns a non-zero value if the call fails. Error codes can be found in the NS-ARPA/1000 Error Messages and Recovery Manual, page 6-18, Memory Manager Log Message Codes. call DS_LeaveCritical(wkmap) wkmap - integer*2 - input The working map register value returned by DS_EnterCritical. NRV table --------- NS NRV TABLE FORMAT: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +------------------------------------------------+ | DS Node Number | +------------------------------------------------+ | Timeout | Reserved |Format levl| +------------------------------------------------+ |C | Reserved | T | N | Communication Link LU | +------------------------------------------------+ | IP Address word one | +------------------------------------------------+ | IP Address word two | +------------------------------------------------+ For NS, the T bit and the IP address have been added to each NRV entry The T bit is 1 if the link is non-router (non-DS), ie LAN. #NRVS - This routine is available in both DS and NS. Given a DS node number (router address in NS terminology) or a negative link LU, it will return most of the information from the NRV entry. Macro calling sequence: JSB #NRVS DEF RETRN DEF NODE [ DEF TIMOT ] [ DEF LEVEL ] [ DEF NAYBR ] [ DEF NNODE ] [ DEF LINKT ] ; For NS only RETRN ; returns here if node not found B="07" ; A = LU, B = index in table Fortran calling sequence: $alias nrv_search='#NRVS', noabort call nrv_search(node[,timot[,level[,naybr[,nnode[,linkt]]]]],*99) call abreg(lu, index) ! normal return . . . 99 continue ! error return node - integer*2 - input DS node number or negative lu to search for. timot - integer*2 - output - optional Master timeout. naybr - integer*2 - output - optional Non-zero if node is a neighbor to local node (N bit). nnode - integer*2 - output - optional Returned node number. Used when a negative LU is input. linkt - integer*2 - output - optional - NS only Non-zero if non-DS link (T bit) lu - integer*2 - output - returned in A register Link lu. index - integer*2 - output - returned in B register Index of entry in NRV table. With the exeception of the LINKT parameter #NRVS works the same on both NS and DS systems. The NS version calls DS_EnterCritical and DS_LeaveCritical, so the program must not be 'critical' when calling #NRVS. The following routines are available in NS only. A program must be critical when calling them. Fetch_NRV_Index - Returns the five word NRV table entry given the table index. Fetch_NRV_IP - Returns the NRV entry and index given the IP address. Fetch_NRV_Router - Returns the NRV entry and index given the router address (DS node number). Fetch_MA_Index - Returns the 10 word MA table entry given the index. Fetch_MA_Node - Returns the MA table entry and index (in B register) given the node number (router address). This one uses the NOABORT type of return. The value returned in the A register is meaningless. Usage: $alias fetch_ma_node, noabort integer*2 nrv_entry(5), index, node, ma_entry(10), error integer*4 ip_addr call fetch_nrv_index(index, nrv_entry) call fetch_nrv_ip(ip_addr, nrv_entry, index, error) call fetch_nrv_router(node, nrv_entry, index, error) call fetch_ma_index(index, ma_entry) call fetch_ma_node(node, ma_entry, *) The message accounting table format is the same for NS and DS. #NRVS and Fetch_MA_Node are in NSLIB.LIB and NSLIB_CDS.LIB. The others are in NSSYS.LIB and NSSYS_CDS.LIB. Here is a sample program : ftn7x $climit 32767 $alias nrv_search='#NRVS', noabort $alias fetch_ma_node, noabort program test implicit none integer*2 parms(5), node, lu, index, wkmap, error, + ma_entry(10),dummy logical found call rmpar(parms) ! get node number from runstring node = parms(1) call nrv_search(node,*90) ! search NRV for this node call abreg(lu, index) write(1,*) 'Node', node, ' Lu =', lu, ' NRV index =', index ! get the MA table entry call ds_entercritical(wkmap, error) if (error .eq. 0) then found = .false. call fetch_ma_node(node, ma_entry, *80) call abreg(dummy, index) found = .true. 80 call ds_leavecritical(wkmap) else write(1,*) 'Enter critical error =', error end if if (found) then write(1,*) 'MA index =', index, + ' Status =', iand(ma_entry(2), 3b) else write(1,*) 'Node not found in MA table.' end if stop 90 write (1,*) 'Node', node, ' not found in NRV' end