1997 HP1000 Guru Column Q: I am transferring an ASCII file from my RTE-A system using ftp, to a PC running NT. The file on the 1000 has records that are greater than 256 words (512 bytes). I find that the records are being truncated at 512 bytes. How do I override this limit? A: When transfering ASCII files using FTP, the default record length is 256 words(512 bytes). If a type 3 or 4 file on the 1000 has a record length greater than 256 words, transfering this file to a non-HP1000 system will truncate the record length to 256 words. To override the 256 word default when transfering an HP1000 file to a non-HP1000 system, you must specify the full namr of the source file. For example, if you have a file on the 1000 that looks like: size blks words recs rlen LONG.AS rw/r 4 24 24 402 1 400 To transfer the file using ftp on the 1000: ftp> put long.as:::4::400 long.as One would have thought that FTP would default to the attributes of the source file, but this is not the case. One must specify the attributes of the source to avoid record truncation. Q: I have increased the number of TELNET LUs in my system to 30. I know find that when my system gets busy, users are unable to logon. I have increased the number of TELNET LUs that HPMDM can handle. What else should I be looking for? A: NS/1000 has a configurable limit on the number of User programs that may be active at any one time. This limit is typically around 25. Thus if 25 TELNET LUs are concurrently connected, no more will be allowed until one or more terminates. This condition can be detected two ways: 1) The NS Event log file will record an error that looks like this INETD RsrceLim SIGMOD 2) The INETD log file, /etc/inetd.log will contain errors: NS error 122(4) scheduling TNS.T. If we look up a NS (NetIPC) error 122(4) we find this is a "Too many users". The number of user records is configured by NSINIT, and can be adjusted accordingly. Q: I have recently updated to 6.2 RTE & NS/1000. I also use the 12079A Direct Driver access for a LAN application written years ago. The problem I am know seeing is that the 1000 LAN no longer is able to receive a broadcast packet. Directly addressed packets still work. I shut down NS/1000, then my application works. What changed at 6.2 to cause this problem? A: It turns out that what changed was a bug in the LAN driver, ID*67, was fixed, which now brought to light a bug in the LAN firmware. NS/1000 enables ARP Packet Filter Mode by issuing the CN command to the driver. The driver then checks the revision of the firmware on the LANIC. If the revision of the LANIC firmware is = or > than 6100, then the firmware is instructed to enable ARP Packet Filter Mode. If the firmware is pre 6100, then the driver takes care of the ARP Packet filtering. The problem in the LANIC firmware is that when ARP Packet Filtering is enabled, it also blocks broadcast packets. Now for the reason 6.1 works: ID*67 (the LANIC Driver),when checking the revision of the LANIC firmware, would check if the the firmware was = 6100, not = or > than 6100. Thus with 6110 firmware, the revision test would say the card was old and the ARP Packet Filtering would be performed by the driver. Which works. There are two workarounds: 1) Disable ARP Packet Filtering via the CN command: CN,,36B,0,0 2) Install 2547 (old) LANIC firmware. Solution #1 means the system would NOT have any ARP Filtering, and thus could be impacted from a performance aspect. Solution #2 would mean the ARP Filtering could be enabled, and the driver would do it. But it would cause support issues, since the old 2547 firmware is not orderable. And of course solution #3 would be that the firmware be fixed. And solution #4 would be a 'special' modified ID*67 driver that would always do the ARP filtering itself, instead of in the firmware. This is a new problem, and as of this writing, no factory solution has yet been determined. 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: Use VSCSI. Assuming you already have at least one SCSI disk LU genned use the "UNITSIZE" command as follows: CI> VSCSI 25 VSCSI: UNITSIZE Information on SCSI disk UNIT containing LU 25: -------------------------------------------------------------- Number of PHYSICAL blocks on this unit: 2647080. Size of each PHYSICAL block on this unit: 512 bytes. This is equivalent to 5294160 RTE blocks ( 256 bytes per block) -------------------------------------------------------------- Then use the number of RTE blocks, 5294160 in this example, for creating your disk LUs. Q: Could you provide an updated list of the CI REVLEVEL values? The last list I have only goes up to 5270. A: Sure. Here is a list starting with 4010 through 6200: CI REVLEVEL OS Revision ---------------------------------------- <851022.1015> 4010 <870305.1535> 5000 <881004.1257> 5010 <900306.1214> 5020 <911121.1717> 5270 <921124.1404> 6000 <930804.1632> 6100 <950206.0858> 6200 Q: Great! Now, can you do the same for the timestamps of BOOTEX? A: Here we go: 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 SCSI-compatible bootex shipped with RTE-A 1:46 AM WED 2 DEC 1992 6000 6.0 ID segment change 1:46 AM THU 25 NOV 1993 6100 Booting Datapair can take long time if disk is down. 1:39 AM THU 4 MAY 1995 6200 LDR ERR 411 with non-zero SCSI passthrough fence fixed. Q: When is the next release of RTE-A expected? A: The next planned release is due early in 1997, and will be a patch release only. It will incorporate patches to existing problems. Q: Since upgrading to SCSI disks, I have been somewhat dismayed to see about the same performance as my old CS/80 HPIB disks. Comparing the specifications between the two leads one to expect the SCSI disk to out perform the CS/80 HPIB disks. Is there a reason why the performance is not greater, and can anything be done to fine tune the SCSI disk performance? A: One of the major differences between the newer SCSI disks and the older CS/80 disks is the physical sector size. From at least the 7900A disk drives of the early 1970s until recently, the physical sector size was 128 words (256 bytes). RTE relies heavily on this "constant", and to modify it would require extensive rework. Thus, when the SCSI project was undertaken, one of the major concerns was to make the larger sector sizes (512 bytes for the current hard drives and 1024 for the MO drives) transparent to the OS. To accomplish this, the SCSI card uses an on-board cache on a per channel basis. The management of this cache can result in either a performance increase or decrease depending on how the disk is utilized. Performance decreases due to the different sector sizes can be demonstrated by looking at the following comparison of the blocks: | 256 bytes | 256 bytes | 256 bytes | 256 bytes | ... ------------------------------------------------------------ | <---- SCSI Block 0 ----> | <---- SCSI Block 1 ----> | ... ------------------------------------------------------------ | RTE Block 0 | RTE Block 1 | RTE Block 2 | RTE Block 3 | ... ------------------------------------------------------------ Comparison of a 512 byte SCSI block with 256 byte RTE block When an RTE user wants to write to RTE Block 1, the following actions must occur: 1) SCSI block 0 is read 2) Part of the block is modified 3) The block is written back to disk When an RTE user wants to write 512 bytes to RTE blocks 1 and 2, the overhead becomes even more complex due to the activities required to read 2 SCSI blocks (1024 bytes total), modify the needed portions, and write the blocks back to disk. This problem can be avoided if all transfers are aligned such that they begin and end at SCSI block boundaries. Files can be forced to start at SCSI block boundaries by genning disk LUs so that the allocation unit times 256 bytes is equal to the SCSI block size. The current hard disks (C2212A and C2213A) have 512 byte blocks. This means an allocation unit of 2 will force all files on the disk to start at a SCSI block boundary. The allocation unit is the number of blocks represented by each bit in the bitmap at the the start of each CI volume. (The allocation unit is further described in Chapter 10 of the RTE-A System Design Manual, p/n. 92077-90013.) The bitmap has a fixed size of 8192 words (128k bits), and each bit specifies whether each allocation unit is used or free. A disk containing between 128k blocks and 256k blocks will have an allocation unit of 2. Note that in addition to having an allocation unit of 2 or more, the SCSI disk LU must also start at a SCSI block boundary to be aligned. Tests comparing SCSI disk transfers with the equivalent HPIB disk show that the HPIB disk will always outperform the SCSI drive when the RTE block is not aligned with the SCSI block. This penalty can become significant when buffer sizes are increased. As a result, in the following discussions when comparing the performance of HPIB disks with SCSI disks, we will always be referring to transfers that have RTE blocks aligned with SCSI blocks. Also, all transfers are an even number of RTE blocks. This ensures that both the beginning RTE block and ending RTE block are aligned with the SCSI block. Note that for SCSI block sizes of > 512 bytes, a larger transfer length will be required to maintain SCSI block alignment at both the starting and ending transfer points. The effect that increasing buffer sizes have on the performance depends on the type of file being transferred. For type 1 files, the HPIB and SCSI disks have comparable transfer rates until the reads or writes are greater than 16k bytes. For HPIB drives, buffer sizes >16k do not show an appreciable performance difference, whereas for SCSI drives buffer sizes up to 28k bytes continue to show performance increases. SCSI performance degrades when buffer sizes are increased beyond 28k due to an extra seek. Due to the size of cache and additional buffer management, performance will decrease for SCSI reads when block sizes are between 6k and 10k and for writes when block sizes are between 8k and 10k. For type 2 and greater files, disk performance is generally only slightly better for SCSI disks than HPIB disks when transfer sizes are greater than 10k. However, for some transfer sizes of less than 10k, HPIB drives may perform significantly better than SCSI drives.. In summary, when using SCSI drives, it is recommend that you use transfers that are SCSI block aligned. Starting block location can be forced to be SCSI block aligned by generating the disk larger than 128k blocks. Ending block can be forced to be SCSI aligned by specifying an appropriate transfer length. In general, performance will increase as transfer sizes (buffer sizes) increase. However, transfer size does not impact performance as much as SCSI block alignment does. In addition, when transfers are SCSI block aligned, performance differences between HPIB disks and SCSI disks are only slight unless the file is a type 1 file and the transfer sizes are between 16k and 28k. For user applications, we recommend that individuals do performance modeling in order to determine which transfer lengths are most appropriate for their applications. Q: We keep hearing about all the "year 2000" problems that according to certain "experts" are going to cause major chaos. How does the HP1000 handle the upcoming new millenium? What problems, if any, can we expect to encounter? A: First of all, the HP1000 has no inherent problem with the year 2000. Over the years, there have been several time related problems that have been corrected as they were encountered. What we will try to do in this article is describe what these problems are, what they affected and when they were fixed. This is in no way a comprehensive list, and certainly there could be unknown problems with different subsystems. The focus of this article will be RTE-A, since RTE-6 has no official support beyond 1999. When possible, we will make comparisons to RTE-6. First some background on how time is managed in RTE-A. All A Series CPUs have a Time Base Generator that 'ticks' every 10 milliseconds. These 'ticks' are accumulated in system entry point $TIME (and $TIME+1) as a double-integer. This value is then interpreted as the negative number of centiseconds until midnight. Entry point $TIME+2 is a second accumulator which counts the number of days since Jan 1, 1976. (In RTE-6, this is Jan 1, 1970) This value is then converted into the appropriate Day-month-year when needed. This theoretically means the maximum year in RTE-A is 2065, or 2155 if we treat $TIME+2 as a unsigned integer. File system timestamps are stored as double-integer values in the file's directory entry. This double-integer number is the number of seconds since 1970. This is the same in both RTE-A and RTE-6, for compatibility. So the maximum year for a file's timestamp is 2,147,483,647 seconds/(60*60*24*365) = approximately 2037. File Manager and type 0 files, (which have no actual timestamps) will appear with a timestamp of Jan 1,1970 when viewed by a program like FST which stores timestamp. As you can see, the maximum year for RTE and the file system is not the same, because of the way the information is stored. And it should be apparent that this scheme has no inherent problem when the year 2000 rolls around. The problems that have existed were caused by the interpretation of these numbers. And this inconsistency led to one of the problems we'll see later. Another date that appears in RTE-A is April 1, 1983. This is the release date of the original RTE-A (Previous versions of RTE-A were known as A.1) RTE-A introduced the hierarchical file system, CI and Code and Data Separation (CDS, which was actually sold as a separate product from RTE-A called VCPLUS). When an RTE-A system is booted, the default startup time is April 1, 1983. This date is placed in $TIME+2 by the RTE-A Generator program. Thus if one forgets to set the time on bootup, the clock starts at 12:00:00 AM on April 1, 1983. (For RTE-6 this date is December 1,1981. But sometime in the 1980's, this startup date was changed to be the current system time when the RTE-6 generator was run.) So what are the problems that have been encountered? Actually, they are very few in number. We will list these in order of apparent severity (our choice!) 1. Library routine FTIME, which is called to return the formatted ASCII time, was broken for the year 2000 and above. It was originally coded using 1900 as a hardcoded base. This caused FTIME to return the year as 19:0 for the year 2000, 19:1 for 2001 and so on. This was fixed in release 5.0. If you are using a release prior to 5.0, the easiest workaround is to simply relink any programs that call FTIME, and relocate a later version of FTIME from $BIGLB. This can be done in link as follows: link: RM,/Newer_libraries/$BIGLB.LIB,FTIME This will relocate just the module FTIME. The version of $BIGLB can be anything up to 6.2. 2. Prior to the 6.2 release of RTE-A, the time setting routine found in &TIME allowed the system time to be set to years up to 2144. Obviously, this was inconsistent with the file system max year. So as of 6.2, the TM command will only allow years from 1976 til 2037. Not normally a problem, since one wouldn't normally set the system time incorrectly. But if it is set incorrectly, it will cause FMP problems... 3. Years beyond 2037 are not valid for FMP timestamps. If the system time is set to a year beyond 2037, and a file is updated or created, certain masking functions will fail. Typical symptom is a DL will not find the file, yet EDIT or LI will display the file. The solution is to 1) Don't set the time incorrectly and 2) if you do, then reset the time correctly, and copy the file to update the timestamp. While on the subject of masking: We have tested timestamps in masks and as of 6.2 have not discovered any problems using date ranges in the year 2000+ range. This is not to say that earlier releases did not have a problem, we just are not aware of any. 5. There is a routine called DAYS70, contained in module &DLIB2 which failed for years 2000+. This routine is only used by MACRO, and thus should not be a major concern. This was fixed at revision 6.2 6. Two PASCAL routines, PAS.TIMESTAMP and PAS.TIMESTRING, do not handle the year 2000 correctly. This affects WH and LANVCP. This was fixed at revision 6.2 7. EDIT/1000's internal timestamp is also afflicted by a similar problem as FTIME above. It will display ":0" as the year for the year 2000 and so on. This problem was fixed in EDIT itself at 6.2. 7a. EDIT/1000's internal timestamp feature only displays 2 digits for the year. Thus starting in the year 2000, the timestamp will be <000101.000>. This will not be changed, due to possible adverse impact on existing code. 8. Now we're down to the really minor problems. The 6.0 Programmer's Reference Manual states that SETTM has a upper limit of 1999. This is incorrect, as the limit was really 2144. Of course that limit was subsequently made 2037 (at 6.2) to match FMP timestamps. Documentation was updated at revision 6.1. And now a word about Leap Year. Everyone knows that leap year occurs every four years, when the year is divisible evenly by 4. Thus the year 2000 is a leap year by this simple rule. But, there is a secondary leap year rule that states if the year is divisible by 4 AND by 100, then it is NOT a leap year. Thus 1900 was not a leap year and it follows that 2000 should not be a leap year. Many people are not aware of the Divide-By-100 rule. And even less are aware of the Divide-By-400 Rule: If the year is divisible by 400, then it is a leap year. This over rules the Divide-By-100 rule. Confused? Let's do it in FORTRAN: if (mod(year,4).eq.0) then if (mod(year,100).ne.0.or.mod(year,400).eq.0) then LeapYear = .TRUE. endif endif Other subsystems which have been tested to some degree include: FORTRAN - Fortran does not have intrinsic time/date routines. However, the date printed on the listings will roll to 1900 after the year 2027. BASIC - Routines TIMEDAY and TIMESTRING have been tested in the year 2010 - They worked fine. C - not tested yet Image-II - Only has two date functions, DATE and EDATE which both use a four digit year and have been tested to December 31 2037. It is our feeling that one of the largest impacts of the year 2000 may involve custom or third party application code that only uses two digits for the year. Obviously, when the year 2000 occurs the "number" will roll from 99 to 00 and all sorting using this number will fail when mixed with numbers before the year 2000. Q: Is any HP1000 information available on the Web? A: As a matter of fact yes. From the Hewlett Packard Web Site, located at: http://www.hp.com/ You will find HP1000 information located at: http://www.hp.com/computing/rte/ Also, we have implemented an email Autoreply node, which contains various technical articles, including archives of past HP1000 Guru columns. The address is: Rte_Support@hpwrcxe.mayfield.hp.com Just send a message with the word INDEX in the Subject. You will be sent an Autoreply with a list of articles available. Just follow the instructions. Q: I have done some testing of the A990 Time of Day clock and it appears to have a problem rolling to the year 2000. Is this a real problem? A: A problem has been discovered in the A990 Processor Time-Of-Day (TOD) clock. At midnite on Dec 31, 1999, the TOD clock does not rollover to the year 2000 correctly. After midnite on Dec 31, 1999, the TOD will report: Aug Jan 18, 1902 33:22:28 am If the TOD clock is subsequently set to a valid date in the year 2000 then everything works normally. At least until the year 3000. So the simple workaround for this problem is to make sure the TOD clock is reset via the CLOCK program, using the system time, after the year 2000 rollover occurs. The impact of this problem should be minor. Since the system clock (TBG) is much more accurate than the TOD clock, it has always been recommended that the TOD clock be synched to the system time periodically. The only scenario where this TOD clock problem would cause concern is if: 1) The year 2000 rollover occurs, and 2) The TOD clock is not reset, and 3) The system is rebooted, and 4) The system time is set from the TOD clock on bootup. In this case, the CLOCK program will return the following error: Error -1 when setting the system time; returning that value in $return1. and the system time will revert to April 1, 1983. If you are running 6.2 or 6.21 RTE-A, you can schedule a CRON job to execute at 12:00:01 Jan 1 2000 to reset the TOD clock. This CRON job would simply run the CLOCK program as follows: CLOCK A9 set If you are using 6.1 or earlier, you can time schedule the following program nightly at 12:01 AM to reset the TOD from the system time. This is recommended, and would eliminate the problem. ftn7x,l,s program settod(3,99), c This program simply schedules "CLOCK" to set the A990 c Time-Of-Day clock from the system time. This program is c time scheduled to run every midnite to sync the two. c c The TBG is more accurate that the TOD, thus we reset the TOD c every night. c implicit integer (a-z) integer*2 error,param(5) c ERROR=FmpRunProgram('XQ,clock,a990,set',param,clock) if (error.ne.0) then write(1,*) ' Error scheduling CLOCK ','Error is ' ,error stop endif end Then time schedule SETTOD as follows: (This should be done from the welcome file at bootup) CI> AT 12:1:1:01 am 24 h settod SR 5003373456 has been submitted for this problem. A hardware fix is not anticipated, since the problem has an easy workaround. Q: Is it possible to backup and restore an RTE-A system via LAN? A: This question has been asked many times, and though it has never been a "supported" backup strategy, it is feasible. It is also much more practical now thanks to the performance increases of NS/1000. These performance increases greatly speed up transferring files between systems. So lets dive right in. The fundamental pieces required are: 1) A full function memory-based system which includes NS/1000 and backup utilities. Memory based NS/1000 was supported as of the 5.2 release. 2) A host from which the RTE-A system can be booted. 3) A backup archive which contains everything necessary to rebuild the system. 4) Ideally, a command file which automates the entire process. The examples I will provide here are meant as an outline of the steps required. Obviously, every system is different and may require changes to what you see here. The concept remains the same. The key to the whole idea is having a memory based system, which includes NS/1000, and has all the utilities (FST, FPUT, CI etc) that are needed to install a system onto an empty disk. So lets start there. In order to have NS run in a memory based system requires that the system file include RAM disk. If your system does not currently have any RAM disk LUs generated in, you will need to do this. Refer to the SGI for details. At a minimum, two RAM disk LUs are needed. It is not necessary that your normal disk system have RAM disk, but the system/snap file for the memory based system must. Listing 1 shows a BUILD command file for the memory based system. This system requires 3072 pages (6144 Kbytes) of memory. LISTING 1 --------- BUILD command file ------------------ Comments !memsys::system::-192 Output file name answer.snp Snap file answer.sys System file yes Automatic partitioning 3072 Size in pages rp,/programs/drtr.run,d.rtr Required programs. rp /programs/derr.run,d.err | rp /programs/ci.run,cm | rp /programs/ci.run,start | st,,2 Define START as startup program rp /programs/nm2.run | rp /programs/uplin.run | rp /programs/inpro.run | rp /programs/outpro.run | rp /programs/inetd.run | rp /programs/rpmmn.run | rp /programs/nftmn.run | rp /programs/promt.run | rp /programs/logon.run | /e 2,mc Mount RAM disk LU 2 /programs/io.run Copy program files to /programs/li.run RAM disk /programs/fput.run | /programs/dl.run | /programs/wh.run | /programs/ci.run | /programs/cix.run | /programs/fst.run | /programs/fstp.run | /programs/ftp.run | /gen/ftpls.run Copy of LS.RUN since we /programs/ls.run don't have symbolic links. /programs/nsinit.run | /programs/mminit.run | /programs/rdate.run | /programs/systz.run | /programs/tnsrv.run | /programs/ftpsv.run | /programs/hpmdm.run | /programs/edit.run | /e | programs Name of directory on RAM disk /catalogs/>fs000 More files to copy /catalogs/inetd.c000 | /e | catalogs Name of directory on RAM disk /gen/welcome2.cmd More system files /gen/nsfile.nsin | /system/nsinit.msg | /system/nserrs.msg | /gen/"mess.txt | /gen/restore.cmd | /gen/ftpcmd.cmd | /gen/fstcmd.cmd | /e | system Name of directory on RAM disk /etc/inetd.conf More system files /etc/services | /etc/hosts | /e | etc Name of directory on RAM disk /m_users/logonprompt User files /m_users/ftp | /m_users/manager | /m_users/nogroup.grp | /m_users/masteraccount | /m_users/mastergroup | /m_users/system.grp | /m_users/jackg | /m_users/walt | /m_users/marc | /e | users Name of directory on RAM disk /e /e ------------------------------------------------ As you can see, key programs are RP'ed into memory, as in any typical memory based system, since these programs should never be removed. All other programs are placed into RAM disk, and are RP'ed as needed just like in a disk based system. Additionally, other files are also placed in RAM disk, particularly /SYSTEM, /ETC, /CATALOGS and /USERS. /USERS is optional. But without it, you cannot TELNET or FTP into the memory based system. I have included it here to illustrate how to build a fully functional NS memory-based system. A comment about the /M_USERS directory: There is no reason why one could not use the existing /USERS directory. I decided to create a new /USERS directory, called /M_USERS, and then use a modified GRUMP which acts on this directory. Why I did this I am not quite sure. But it works. In our disk based system, LU 12 is the boot LU and contains all critical directories: /PROGRAMS, /SYSTEM, /CATALOGS etc. This LU is backed up to an FST archive and then this archive is copied to another system using FTP. This is the ONLY backup. Make certain that a copy of the current Boot Extension (BOOTEX) file is included, I keep mine in the /SYSTEM directory. I use this other disk based system as both the boot source and the backup location for the FST archive. This system must be RTE-A if you plan to boot from it (Booting RTE-A from a 9000 is not supported). If you have no other 1000 on the network, then you will need an alternate medium from which to boot the memory based system. Listings 2 and 3 show the Welcome and NSINIT answer file used by the memory based system. You will note that since all required NS programs were RPed in the build, nothing else needs to be RPed prior to running NSINIT. The procedure used to recover the system using the memory based system is documented in LISTING 4, which is a command file used to perform all the steps. This command file exists in the SYSTEM directory of the memory based system. LISTING 2 --------- WELCOME file COMMENTS ------------ -------- * WELCOME2.CMD REV.6.2 for Brutus * set log = on * * cn,3,25b,200 Initialize and mount auxilary in,3,,ok RAM disk LU 3 for /SCRATCH crdir /scratch 3 prot /scratch rw/rw/rw * * wd /programs * * nsinit nsfile.nsin::system Initialize NS * hpmdm 79 ad Add TELNET LUs hpmdm 80 ad hpmdm 82 ad * * systz -s +8 Optional: Set time via rdate mamba HP9000 (6.2 only) * co "mess.txt::system 1 * * set log = off ex LISTING 3 --------- * DEFAULT.NSIN 91790-17088 REV.6200 <:00218.1452> * SOURCE : 91790-17088 * NSINIT Answer File * * * This is an NSINIT answer file to initialize NS-ARPA/1000 with a default * configuration. The configuration is a simple case for a node on a LAN with * no gateway. It does not include DS/1000-IV services. * * DO NOT EDIT THIS FILE TO ADD DS/1000-IV SERVICES, AS MORE INFORMATION IS * REQUIRED. * * This file is used by NSSTART_EZ.CMD. * *---------------------------------------------------------------------------- * NSINIT file: DEFAULT.NSIN 4:05 PM FRI., 6 MAY , 1994. * * Network Initialization Options: * 1: Build Output File. * 2: Build Output File & Initialize Network. * 3: Initialize Network. * 4: Shut Down Network Subsystem. * Enter an option number [(1)..4]: 3 * Initialize Network * * Enter the local node name. Format: name.domain.organization * (Each field may be 1..16 char). * Local Name: BRUTUS.HP.COM *++ Classes of Events to log ++* * 6: Resource limit exceeded * 5: Disaster (irrecoverable error) * 4: Error (severe, but recoverable error) * 3: Warning (unexpected event) * 2: Event message * 1: Internal State Information * * Enter the event classes to log, one per line. * [/D = 4, 5, and 6]. Type /E to end. * Event class: /E * Enter an event log file name [default = /system/ns_event.log]: * No EVENT logging since we said /E above. * Do you want to start NSTRC when NS is enabled [Y/(N)]? /D * Do you want Network File Transfer (NFT) [(Y)/N]? N *++ Network File Transfer (NFT) ++* * Default Buffer Size: 2048 Bytes * Transport Checksum Used: No * * Do you want to modify these values [Y/(N)]? * /D * *++ DS/1000-IV Compatible Services ++* * * Do you want any DS/1000-IV compatible services [Y/(N)]? /D *++ NS Nodal Information ++* * * Defaults are derived from previous responses. * Maximum number of active NS programs is: 24 * Maximum number of active NS sockets is: 77 * * Do you want to modify these values [Y/(N)]? /D *++ Nodal Registry ++* * * Maximum number of Connect-Site path reports is: 101 * (The above value is derived from previous responses.) * Maximum number of Nodal path reports is: 20 * * Do you want to modify these values [Y/(N)]? /D * Enter the maximum number of name records (the default is derived * from previous responses) [1..(50)..303]: /D *++ Transmission Control Protocol (TCP) ++* * * Initial Segment Size in bytes: 4096 * Retransmission Backoff Algorithm: Exponential * Retransmission Smoothing parameter Alpha: 9 * Retransmission Smoothing parameter Beta: 20 * Do you want to modify these values? [Y/(N)]: /D *++ DCN ++* * Enter information on this node for each Directly Connected Network. * Format: * * , <[subnet mask],> RTR, * , <[subnet mask],> 802/LAN/ETHERNET, * , , (E)/NE, <[station addr]> * * Where E = Enable, NE = do Not Enable. Type /E to end. * *DCN: 15.37.241.7,,LAN,,96 *DCN: /E ** Internal Use Only ** /e *++ GT ++* * Enter information for each Gateway (GT). * Format: * * , , * * Where: Dest IP Net = IP Address of any node on a remote net * Gateway IP = DCN IP Address of Gateway to use * Hops = Maximum allowed IP hops to Dest IP Net * Type /E to end. * *GT: /E * Enter the maximum number of Path Records for IP. The default is derived * from previous responses [6..(103)..200]: /D *+++ ADDRESS RESOLUTION +++* * Maximum number of active PCB Records: 10 * Retry interval timeout in centi-seconds: 100 * Proxy Nodal Registry Server: No * * Do you want to modify these values [Y/(N)]: /D * * Default IEEE-802 Multicast Addresses for Probe: * Target Address: 09-00-09-00-00-01 * Proxy Address: 09-00-09-00-00-02 * * Do you want to modify these values [Y/(N)]? /D * Enter the Network security code for this node [1..2 char]: NS * Enter the Network User's security code for this node [1..2 char]: NS *++ EMA Usage ++* * 3 pages available 1 pages used *+++ System resources required for this file +++* * DSAM Table size in words: 32146 * Number of RTE Class Numbers: 4 * Number of RTE Resource Numbers: 4 * SMB size in words: 0 * NSINIT successfully completed action BUILD. LISTING 4 --------- * * Command file to restore BRUTUS from an FST archive * kept on REMUS * * Procedure is as follows: * * 1) Boot BRUTUS via LAN from REMUS * %BDS37 * * This brings up a NS Memory-Based system * * 2) This command file will perform the following steps: * * a) Rename existing Ram Disk directories so that the disk based * directories on LU 12 can be restored with FST * * b) Initialize LU 12 * * c) Create directory structure on LU 12 * * d) FTP the FST archive, /BRUTUS/ARCHIVE.FST from REMUS * * e) Restore FST backup * * f) FPUT bootex to LU 12 * * 3) If things go wrong, you simply reboot the memory based system, * and start over. * * We set the WD to /PROGRAMS, so that we can access programs * after we change the directory name. * * wd /programs * * Rename directories that we will be restoring from the FST backup. * Since these are in RAM, we do not need to change them back, we * can simply reboot the memory based system. * rn /programs /p rn /system /s rn /etc /e rn /users /u rn /scratch /sc * * We next initialize the LU we wil be restoring, create a * /SCRATCH directory to hold the FST archive. Then create * necessary directories based on the backup. This step is not * required, since FST will generally put files back where they * came from, but it does avoid confusion. * in,12,768,ok * crdir /scratch 12 prot /scratch rw/rw/rw/ * crdir /programs 12 crdir /system 12 crdir /users 12 crdir /m_users 12 * * Next we FTP the FST archive over from the system it is stored * on. In this example, we have command files in the /S (renamed * from /SYSTEM) directory of the memory based system. * ftp -l/scratch/ftp.log -t/s/ftpcmd.cmd * * * Now we run FST and restore the files. * Echo ` ` Echo `Restoring system files` Echo ` ` * fst tr /s/fstcmd.cmd * Echo ` ` echo `Installing Bootex` Echo ` ` * * Re-install Bootex. If you have a FMGR boot LU, this would be * done with a FMGR DU command. * * fput /system/bootex 12 0 * Echo ` ` Echo `Finished' Echo ` ` Echo ` Ready to Reboot system from disk` Echo ` Hit Break, and type %BDC6027` Echo ` ` Echo ` ` * Listings 5 and 6 show the command files used to copy the archive file and then restore the backup using FST LISTING 5 --------- * * Command file used to get a FST archive file from a * remote system * * Run string: ftp -l/scratch/ftp.log -t/s/ftpcmd.cmd * as shown in RESTORE.CMD * open 15.37.241.3 user walt ***password get /brutus/archive.fst /scratch/archive.fst exit LISTING 6 --------- * Command file to restore from a archive file * * Run string: fst,tr,/s/fstcmd.cmd * as shown in RESTORE.CMD * mt /scratch/archive.fst re @ go *