(edited 27-aug-91 /cgg) (chapter 1) (Disk and Tape Formats\DTF_CHAP)

RT--11 stores files under assigned file names on file-structured volumes. RT--11 volumes that are file-structured include all disks, diskettes, and magtapes.

Disks and diskettes are directory-structured volumes; they have a series of directory segments at the beginning of the volume. The directory segments contain entries describing the names, lengths, and creation dates of files on the volume. Because the directory is at the beginning of the volume, you can access any file, no matter where it is located, without reading any other files. For this reason, directory-structured volumes are sometimes called random-access or block-replaceable volumes.

Magtapes are file-structured volumes that do not have a directory at the beginning of the volume. While they do store some directory information at the beginning of each file, you must read the entire volume to obtain all the information about all the files. Because you must read the files in order, one after the other, magtapes are also called sequential-access volumes.

This chapter shows how RT--11 stores files on both random-access and sequential-access volumes. It also describes the contents of a volume directory and shows how to recover information from a random-access volume whose directory is corrupted. (Random-Access Volumes\DTFRAV_SEC)

A random-access volume consists of a series of 256(10)-word blocks where blocks 0 through 5 are reserved for system use and cannot be used for data storage. The volume directory begins at block 6. (DTFRAV_FIG) shows the format of a random-access volume.

(Random-Access Volume\DTFRAV_FIG) (\MULTIPAGE) (POSTSCRIPT\S561C1DTFRAV_FIG.EPS\31) (Home Block\DTFHBL_SEC)

Block 1 of a random-access volume, called the (home block\bold), contains information about the volume and its owner. (DTFHBL_FIG) and (DTFHBL_TAB) show the home block format and contents.

(Home Block Format\DTFHBL_FIG) (POSTSCRIPT\S561C1DTFHBL_FIG.EPS\15) (Home Block Contents\DTFHBL_TAB) (KEEP) (4\6\8\18) (Field\Location\Contents\Default) (a\000--201(8)\Bad block replacement table\) (b\204--251(8)\INITIALIZE/RESTORE data area\) (c\252--273(8)\BUP information area\If BUP volume: "BUQ" and 9 spaces; binary volume number in byte 266(8)) (d\700--701(8)\(Reserved for Digital)\000000) (e\702--703(8)\(Reserved for Digital)\000000) (f\722--723(8)\Pack cluster size\000001) (g\724--725(8)\Block number of first directory segment\000006) (h\726--727(8)\System version\Radix--50 "V3A") (i\730--743(8)\Volume Identification\"RT11A" and seven spaces) (j\744--757(8)\Owner name\12(10) spaces) (k\760--773(8)\System Identification\"DECRT11A" and four spaces) (l\776--777(8)\Checksum\ ) The checksum computation conforms to the (FILES-11 On-Disk Structure Specification). It is a simple additive checksum of all the other words in the home block and is computed according to the following algorithm: MOV Header__address,R0 CLR R1 MOV #255.,R2 10$: ADD (R0)+,R1 SOB R2,10$ MOV R1,@R0

The contents of all other areas in the home block are undefined and reserved for future use by Digital. (Directory Structure)

The directory consists of a series of two-block segments. Each segment is 512(10) words long and contains information about files such as name, length, and creation date. A directory can have from 1 to 31(10) segments. You can display the default number of directory segments on an initialized volume by issuing the DIRECTORY/SUMMARY command. You can change the size of the directory area during volume initialization by specifying the number of directory segments. Use the INITIALIZE/SEGMENTS:n command, or DUP with the /Z/N:n options. (See the (SUG_BOOK) for more information on the INITIALIZE command. See the (INS_BOOK) for a patch that changes the default number of segments.)

In general, you require more segments if you need to store many small files on a large volume. However, the minimal number of segments reduces the size of the directory area and you obtain more space to store large files on a smaller volume. The default number of directory segments is a compromise.

Each directory segment consists of a five-word header plus a number of entries containing file information. Each segment ends with an end-of-segment marker. (DTFVDF_FIG) shows the general format of a volume directory segment.

(Volume Directory Segment Format\DTFVDF_FIG) (POSTSCRIPT\S561C1DTFVDF_FIG.EPS\8) (Directory Segment Header Format)

Each directory segment contains a five-word header, which leaves the remaining 507(10) words of the two-block segment for directory entries. (DTFDHW_TAB) describes the contents of the header words.

(Directory Segment Header Words\DTFDHW_TAB) (KEEP) (2\8) (Word\Contents ) (1\The total number of segments in this directory. The valid range is from 1 through 31(10). If you do not specify the number of segments you require when you initialize the volume, DUP uses the default number of segments for that volume. ) (2\The segment number of the next logical directory segment. The directory is a linked list of segments and this word is the link between the current segment and the next logical segment. If this word is 0, there are no more segments in the list. ) (3\The number of the highest segment currently in use. RT--11 increments this counter each time it opens a new segment. Note that the system maintains this counter in word 3 of the header only for the first directory segment. It completely ignores the third word of the header of the other segments.) (4\The number of extra bytes per directory entry, always an unsigned, even octal number. See (DTFDEF_SEC) for more information.) (5\The block number on the volume where the actual stored data identified by this segment begins.) (Directory Entry Format\DTFDEF_SEC)

The remainder of the directory segment consists of one or more directory entries followed by an end-of-segment marker. (DTFDEF_FIG) shows the format of a directory entry.

(Directory Entry Format\DTFDEF_FIG) (POSTSCRIPT\S561C1DTFDEF_FIG.EPS\19)

The first word of each directory entry is the status word, which describes the condition of the file identified by that directory entry. The high-order byte of the status word contains information on the current state of file. The low-order byte can identify a file class. (DTFDSW_FIG) shows the format of the status word and (DTFDSW_TAB) describes the contents.

(Directory Entry Status Word Format\DTFDSW_FIG) (POSTSCRIPT\S561C1DTFDSW_FIG.EPS\2) (File Type)

RT--11 uses three kinds of directory entries to describe the type of file: (UNNUMBERED) tentative entries empty entries permanent entries

You can think of the three types of entry as describing areas that are categorized as temporary data, available space on the volume, or permanent data. The volume directory contains at all times sufficient entries to describe the entire volume.

A (tentative file \bold)is a file that is in the process of being created. When a program issues the .ENTER programmed request, for example, it creates a tentative file. The program must issue a .CLOSE programmed request to make the tentative file permanent. If you do not eventually close a tentative file, the system deletes it. The DIR utility program lists tentative files that appear in directories as (<)UNUSED> files.

An (empty entry \bold)defines an area of the volume that is available for use. Thus, when you delete a file, you obtain an empty area. DIR lists an empty area as (<)UNUSED>, followed by its length.

A (permanent file \bold)is a tentative file that has been closed with the .CLOSE programmed request. Permanent files are unique -- that is, only one file can exist with a specific name and file type on a volume. If another file exists with the same name and type when the program closes the current tentative file, the monitor deletes the first file as part of the .CLOSE routine, thus replacing the old file with the new file. DIR lists permanent files that appear in directories by their file names, file types, sizes, and creation dates.

The file class information in the low byte of the status word either marks a file as having particular characteristics or identifies the file as a member of a particular group of files. At present, only one bit is used; the rest are reserved for future use by Digital.

The (prefix block\bold) bit indicates that the file contains at least one prefix block. Prefix blocks are optional information blocks that precede a file's information blocks and begin at logical block 0 of a file. The utility or application using the prefix blocks must set bit E.PRE in the status word, create the prefix blocks, and maintain them. RT--11 provides no special support for prefix blocks.

Any utility that needs to store information about a file with the file can use prefix blocks. All previous and current utilities and applications can continue to read and write files without regard for prefix block functionality. Prefix block functionality need not concern you unless you write an application that uses it.

The structure of prefix blocks reserved for use by RT--11 and the recommended structure for user applications is as follows: (unnumbered) The low byte of the first word of the first prefix block contains the number of prefix blocks in the file.

The high bit of the high byte indicates whether the prefix blocks were created by distributed RT--11 software of a user application. If the high bit is clear (0), distributed RT--11 software created the prefix blocks; if set (1), a user application created them. The second and third words of the first block contain a Radix--50 format identifier. Subsequent words in the prefix blocks are application-dependent.

(DTFDSW_TAB) lists the valid values for the bytes of the status word and their meanings. All undefined bits in the directory entry status word remain reserved for Digital.

(Directory Entry Status Word Values\DTFDSW_TAB) (3\8\8) (Value\Mnemonic\Meaning) ((3\LEFT)High Byte Values, Expressed as a Word) (000400(8)\E.TENT\Tentative file.) (001000(8)\E.MPTY\Empty area. RT--11 does not use the name, file type, or date fields in the directory entry for an empty area.) (002000(8)\E.PERM\Permanent file.) (004000(8)\E.EOS\End-of-segment marker. RT--11 uses this marker to determine when it has reached the end of the directory segment during a directory search. Note that an end-of-segment marker can appear as the last word of a segment. It does not have to be followed by a name, file type, or other entry information.) (040000(8)\E.READ\Protected by monitor from write operations from .WRITE request; not protected from any special function operations or deletions.) (100000(8)\E.PROT\Protected permanent file (see (DTFFPT_SEC)). Only a permanent file can be protected.) ((3\LEFT)Low Byte Values, Expressed as a Word) (000020\E.PRE\Prefix block indicator. Indicates the presence of at least one prefix block in this file.)

The second, third, and fourth words in a directory entry contain the file name and file type in Radix--50. For empty area, RT--11 normally ignores these words. However, the DIR /Q option (or the monitor DIRECTORY command with the /DELETED option) lists the names and file types of deleted files.

The fifth word in a directory entry contains the total file length, which consists of the number of blocks the file occupies on the volume. Attempts to read or write outside the limits of the file result in an end-of-file error.

The sixth word in a directory entry contains the channel number and sometimes the job number as well. RT--11 uses this information only for tentative files. A tentative file is associated with a job in one of two ways, depending on which RT--11 monitor is running. (SJ)

In the SJ environment, the low byte of the sixth word of the entry holds the channel number on which the file is open. This number enables the monitor to locate the correct tentative file for the channel when a program issues the .CLOSE programmed request.

(SJ) In the FB and XM environments, as with SJ, the The low byte of the sixth word of the directory entry contains the channel number. The high byte of the sixth word contains the number of the job that is opening the file. The job number is required to identify the correct tentative file during the .CLOSE operation. It is also necessary because several jobs can have files open using the same channel number. ()RT--11 uses the sixth word (job number and channel number word) only when the file is tentative. Once the file becomes permanent, RT--11 no longer uses the word. The function of the sixth word while the file is permanent is reserved for future use by Digital.

The seventh word of a directory entry contains the file's creation date. When a program creates a tentative file by issuing the .ENTER programmed request, the system moves the system date word into the creation date slot for the entry. The date word is 0 if you did not enter a date with the DATE monitor command.

User programs can take advantage of the (Age) bits (bits 14 and 15) to extend the directory date by 32(10) year increments. Support for Age bits is not available in any RT--11 monitor or utility, but is included in the DATE/DATE4Y, IDATE, IDCOMP, and IGTDIR subroutines and functions. The base year for calculation is incremented by the Age bit values (0-3) and is 1972, 2004, 2036, and 2068, respectively. (DTFDDW_FIG) shows the format of the date word.

(Date Word Format\DTFDDW_FIG) (POSTSCRIPT\S561C1DTFDDW_FIG.EPS\4)

Normally, directory entries are seven words long, but by using DUP with the /Z:n option, you can allocate extra words for each entry when you initialize the volume. The fourth word of the directory header contains the number of extra bytes you specify. Although DUP lets you allocate extra words, RT--11 provides no means to easily manipulate this extra information. Any program that needs to access these words must perform its own operations on the RT--11 directory. In addition, programs that manipulate the directory should use bit test (BIT) instructions, rather than compare (CMP) instructions. (File Protection\DTFFPT_SEC)

RT--11 provides a mechanism to prevent a file from being deleted. A file is protected when the high bit of its status word is set. Only permanent files can be protected. You can protect and unprotect files by using the PIP /R option or the monitor RENAME command. Note that a protected file is (not\bold) protected against modification, only against deletion. For more information, see the (SUG_BOOK). (Sample Directory Segment\DTFSDS_SEC)

The directory listing shown in (DTFDL1_FIG) describes an RX50 diskette with 10 files.

(Directory Listings\DTFDL1_FIG) DIRECTORY/FULL DU0: 12-Jul-88 SWAP .SYS 27 03-Sep-86 RT11XM.SYS 107 03-Sep-86 (<) UNUSED > 93 DUX .SYS 5 03-Sep-86 PIP .SAV 30 03-Sep-86 DUP .SAV 49 03-Sep-86 DIR .SAV 19 03-Sep-86 KED .SAV 58 03-Sep-86 MACRO .SAV 63 13-Nov-87 LINK .SAV 49 03-Sep-86 CREF .SAV 6 13-Nov-87 (<) UNUSED > 280 10 Files, 413 Blocks 373 Free blocks DIRECTORY/SUMMARY DU0: 11-Jul-88 10 Files in segment 1 4 Available segments, 1 in use 10 Files, 413 blocks 373 Free blocks

(DTFDSG_FIG) shows the contents of segment 1 of the diskette directory, obtained by dumping absolute block number 6 of the volume.

(RT--11 Directory Segment\DTFDSG_FIG) (\MULTIPAGE) (POSTSCRIPT\S561C1DTFDSG1_FIG.EPS\47) (POSTSCRIPT\S561C1DTFDSG2_FIG.EPS\32)

To find the starting block of a particular file, first find the directory segment containing the entry for that file. Then, take the starting block number in the fifth word of that directory segment and add the length of each permanent, tentative, and empty entry in the directory before your file. For example, in (DTFDSG_FIG) the permanent file RT11XM.SYS begins at block number 51(8) on the volume; word 5 shows 16(8) and the previous entry, SWAP.SYS, is 33(8) blocks long. (File Storage on Random-Access Volumes)

RT--11 uses the three types of directory entry mentioned previously to completely describe the contents of a random-access volume. All files reside on contiguous blocks. There are advantages and disadvantages to this method of storing data.

When data is stored in contiguous blocks, I/O is more efficient. Transfers to large buffers are handled directly by the hardware for certain disks; seeks between blocks and program interrupts between blocks are eliminated. File data is processed simply and efficiently since the data is not encumbered by link words in each block. Routines to maintain the directory are relatively small because the directory structure is simple. File operations, such as open, delete, and close, are performed quickly with few disk accesses, because only the directory must be accessed, and not additional bitmaps or retrieval pointers.

One disadvantage of this method of storing data is that a volume can become fragmented, requiring a squeeze operation to consolidate its free space. Another is that once a file is closed, a running program cannot easily increase its size. Only a small number of output files can be opened simultaneously, even on a large volume, unless the limits of the file sizes are known in advance. Finally, this scheme precludes the use of multiple and hierarchical directories.

(DTF2PF_FIG) shows a simplified diagram of a random-access volume that has a total of 250(8) blocks of space available for files after blocks 0 through 5 and the directory are accounted for. The volume in the figure has two permanent files and one empty area stored on it.

(Random-Access Volume with Two Permanent Files\DTF2PF_FIG) (POSTSCRIPT\S561C1DTF2PF_FIG.EPS\3)

When you create a file, your program must specify a size for the file in the .ENTER programmed request. If you know the exact number of blocks required, you can use that number in the request. RT--11 will use a best-fit algorithm and attempt to put the file in a free space that exactly matches the size requested or, failing that, in the free space that most closely matches the size requested.

If you do not know the actual size, as is often the case, the space you specify should be large enough to accommodate all the data possible. Two special cases for the .ENTER programmed request let you do this easily. In the first case, a length argument of 0 allocates for the file either one-half the largest space available, or the second largest space, whichever is bigger; in the second case, a length argument of --1 allocates the largest space possible on the volume.

The monitor creates a tentative file on the volume with the length you specified. The tentative file must always be followed by an empty area to enable the system to recover unused space if less data is written to the file than you originally estimated. (DTF1TF_FIG) shows an example of a tentative file whose allocated size is 100(8) blocks. Note that the total amount of space on the volume, 250(8) blocks in this case, remains constant.

(Random-Access Volume with One Tentative File\DTF1TF_FIG) (POSTSCRIPT\S561C1DTF1TF_FIG.EPS\3)

Suppose, for example, that while the file is being created by one program, another program enters a new file, allocating 25(8) blocks for it. The volume would appear as shown in (DTF2TF_FIG). Remember that every tentative file must be followed by an empty area.

(Random-Access Volume with Two Tentative Files\DTF2TF_FIG) (POSTSCRIPT\S561C1DTF2TF_FIG.EPS\3)

When a program finishes writing data to the volume, it closes the tentative file with the .CLOSE programmed request. RT--11 then makes the tentative file permanent. The length of the file is the actual size of the data that was written. The size of the empty area is its original size plus any unused space from the tentative file.

(DTF4PF_FIG) shows the same volume after both tentative files are closed. The first file's actual length is 75(8) blocks, and the second file's length is 10(8) blocks.

(Random-Access Volume with Four Permanent Files\DTF4PF_FIG) (POSTSCRIPT\S561C1DTF4PF_FIG.EPS\3)

Because of this method of storing files, it is impossible in RT--11 to extend the size of an existing file from within a running program. To make an existing file appear to be bigger, you can read the existing file; allocate a new, larger tentative file; and write both the old and the new data to the new file. You can then delete the old file.

The CREATE/EXTENSION command (DUP /T option) is an easy way to extend the size of an existing file. However, to use this option, you must have an empty file with sufficient space in it immediately following the data file. (Size and Number of Files)

The number of files you can store on an RT--11 volume depends on the number of segments in the volume's directory and the number of extra words per entry. If you use no extra words, each segment can contain 72(10) entries. However, the maximum number of entries includes three that are reserved by the operating system and not available to the user. These three entries in each segment are for end-of-segment, empty (but reserved), and a reserved entry for use when creating a tentative file. Therefore, the maximum number of usable entries per directory segment is 69(10).

The maximum number of directory segments on any RT--11 volume is 31(10). Use the following formula to calculate the theoretical maximum number of directory entries, and thus, the maximum number of files. 512 - 5 31 * ------- - 3 7 + N

N represents the number of extra information words per directory entry. If N is 0, the maximum number of files you can store on the volume is 2242(10).

Note that all divisions are integer and the remainder should be discarded.

If you store files sequentially (that is, one immediately after another) without deleting any files, roughly one-half of the theoretical maximum number of files will fit on the volume before a directory overflow occurs. This situation results from the way RT--11 handles filled directory segments.

When a directory segment becomes full and it is necessary to open a new segment, the monitor moves approximately one-half of the directory entries of the filled segment to the new segment. Thus, when the final segment is full, all previous segments have approximately one-half of their total capacity. See (DTFSPS_SEC) for a detailed explanation of how RT--11 splits a directory segment.

If you add files continually to a volume without issuing the SQUEEZE monitor command, you can use the following formula to compute the maximum number of entries, and thus, the maximum number of files. S (M - 1) * - + S 2

M represents the maximum number of segments.

S can be computed from the following formula: 512 - 5 S = ------- - 3 7 + N

N represents the number of extra information words per entry.

You can realize the theoretical total of directory entries (see the first formula, above) by compressing the volume (using the DUP /S option or the monitor SQUEEZE command) when the directory fills up. DUP packs the directory segments as well as the physical volume. (Splitting a Directory Segment\DTFSPS_SEC)

Whenever RT--11 stores a new file on a volume, it searches through the directory for an empty area that is large enough to accommodate the new tentative file. When it finds a suitable empty area, it creates the new file as a tentative file followed by an empty area, sliding the rest of the directory entries down to make room for the new entry. (DTFSNF_FIG) shows how RT--11 stores a new file as a tentative file followed by an empty area.

(Storing a New File\DTFSNF_FIG) (POSTSCRIPT\S561C1DTFSNF_FIG.EPS\20)

This procedure works properly as long as the empty entry and the entries following it can move downward. However, if the segment is full, the monitor must split the segment, if possible, to store the new entry. (DTFFDS_FIG) illustrates a directory segment that is full.

(Full Directory Segment\DTFFDS_FIG) (POSTSCRIPT\S561C1DTFFDS_FIG.EPS\17)

First, the monitor checks the header for the number of segments available. If there are none, a (directory full) error results and the monitor cannot store the new file. You can squeeze the volume at this point to pack the directory segments and try the operation again.

If there is another directory segment available, the monitor divides the current segment by first finding a permanent or tentative entry near the middle of the segment and saving its first word. In place of the first word, the monitor puts an end-of-segment marker. It then saves the current link information, links the current segment to the next available segment, and writes the current segment back to the volume.

Next, the monitor restores the first word of the middle entry to the copy of the segment that is still in memory, and restores the link information. It slides the middle entry and all the entries following it to the top of the segment. Then, the monitor writes this segment to the volume as the next available segment. Finally, the monitor reads segment 1 into memory and updates the information in its header. At this point, control passes to the top of the .ENTER routine, and the monitor begins its search again for a suitable empty entry to accommodate the new file.

Figures (DTFDBS_FIG\VALUE) and (DTFSPS_FIG\VALUE) summarize the process of splitting a directory segment. In this example, segment 1 was the only segment in use. It contained an empty entry but did not have room for a tentative entry in addition to the empty one. After the split, segments 1 and 2 are both about half full.

(Directory Before Splitting\DTFDBS_FIG) (POSTSCRIPT\S561C1DTFDBS_FIG.EPS\20)
(Directory After Splitting\DTFSPS_FIG) (POSTSCRIPT\S561C1DTFSPS_FIG.EPS\17)

After a directory segment splits, the monitor can store the new file in either the new segment or the old one, depending on which segment now contains the empty area. In (DTFSPS_FIG), the empty area is in segment 2.

Thus far, the link words seem superfluous since the segments are always in numerical order. However, consider a situation in which four segments are available: segment 1 fills and overflows into segment 2; segment 2 fills and overflows into segment 3; segments 1, 2, and 3 are half full, and they are linked in the order in which they are located on the volume (blocks 6, 10, and 12). The picture changes if you delete a large file from segment 2, leaving a large empty entry, and add a lot of small files to the volume. Segment 2 now fills up and overflows into the next free segment, segment 4, so that the links become visibly significant: segment 1 links to 2, segment 2 links to 4, and segment 4 links to 3 because segment 2 previously linked to 3. (DTFDLK_FIG) illustrates this example.

(Directory Links\DTFDLK_FIG) (POSTSCRIPT\S561C1DTFDLK_FIG.EPS\14)

The process of splitting a directory segment in half when it is full may seem unnecessarily complicated. In fact, if many files are simply copied to a disk, a (directory full) error will occur when the directory is only half full. A squeeze will be required to consolidate the half-full directory segments before more files can be copied to the disk. However, splitting a directory segment reduces the amount of directory entry shuffling that occurs as files are added and deleted on a volume, thereby improving overall efficiency.

Refer back to (DTFDBS_FIG). Assume the empty entry between PERMANENT-5 and PERMANENT-6 represents 100(8) blocks of free disk space and that directory splitting is not done. If a program makes a directory entry for a new 25(8)-block file, the directory entry for the file PERMANENT-7 must be moved to directory segment 2 to make room in segment 1 for the entry for PERMANENT-5A and an empty entry of 75(8) blocks. If the program makes another directory entry for another 25(8)-block file, the file PERMANENT-6 must be moved to segment 2 to make room for the entry PERMANENT-5B and an empty entry of 50(8) blocks. In other words, each time a new directory entry occurs in segment 1, segment 2 must be updated as well, requiring an extra disk read and write.

If a directory segment is split when full, however, this problem does not occur as readily. Consider (DTFSPS_FIG) and observe what has happened. When a program creates the new 25(8)-block file PERMANENT-5A, only directory segment 2 must be updated. No directory shuffling is required. If the file PERMANENT-4 is deleted and replaced with two or more files, directory segment 1 has room to accommodate the new file entries. Because directory splitting moves several directory entries from one segment to another at one time, any given directory operation is far less likely to require access to more than one directory segment. Directory splitting reduces dramatically the number of disk accesses required, on average, and improves overall directory efficiency. (How to Recover Data When the Directory Is Corrupted)

One of the most frustrating experiences a programmer can have is to lose data on a volume because a block in the volume directory becomes bad or because another user writes over the directory. Usually, the files on the volume are intact, but the directory entries for some of the files have been destroyed. This section presents some guidelines you can follow to recover as much data as possible from a volume with a corrupted directory. (Examine Segment 1)

First, determine whether segment 1 of the directory is bad. Remember, segment 1 occupies physical blocks 6 and 7 of the volume. To examine segment 1, mount the volume and issue the DIRECTORY command.

If you get an immediate (?MON-F-Directory I/O error )or (?MON-F-Dir I/O err )message, you know that segment 1 is bad. This leaves you with two alternatives: you can reformat and reinitialize the volume (the volume is reusable if a bad block scan shows no bad blocks in the directory area); or, if you are desperate to recover the data on the volume, you can open the volume in non-file-structured mode with TECO and search for data that resembles source code or other ASCII information that looks familiar. This kind of search is a tedious process; you probably shouldn't even consider it unless you have a video terminal to use with TECO. See (DTFRBS_SEC) for information on removing a file from the volume.

If the DIRECTORY monitor command gives you at least a partial directory listing, you will be able to recover some of the information from the volume by issuing the DIRECTORY/SUMMARY monitor command. The /SUMMARY option lists information up to but not including the bad segment. To recover as many files as possible, you must repair the directory by linking around the bad segment. (Follow the Chain of Segments)

Use SIPP to open the volume in non-file-structured mode. Look first at location 6000(8), which is the start of the header for directory segment 1. It contains the total number of segments available. Location 6002(8) contains the number of the next segment, and location 6004(8) shows the highest segment in use. (To review the directory header words and their meanings, see (DTFDHW_TAB).)

To find the absolute location of the next segment, multiply the link word by 2000(8) and add 4000(8). For example, if the link word is 2, the next segment starts at location 10000(8) on the volume. Chain your way through the segments by opening the next segment and following its link word. As you go, make a worksheet for the link information, according to the format shown in (VFFW4S_FIG). Continue chaining until you have accounted for all the segments. Remember that segment 1 is always the first segment -- that is, nothing links to it. The last segment has does not link and contains 0.

(Worksheet for a Directory Chain with Four Segments\VFFW4S_FIG) (POSTSCRIPT\S561C1VFFW4S_FIG.EPS\12)

In (VFFW4S_FIG), segment 3 must link to 0 -- that is, it is the last segment since all the others have been accounted for already. To repair this directory, modify the header of segment 4 so that the link word contains 0 instead of 3. This eliminates segment 3 from the chain. (DTFRGS_SEC) describes how to remove the files from the volume.

(VFFW9S_FIG) shows a more complicated example. In this case the bad segment is not the last one in the directory.

(Worksheet for a Directory Chain with Nine Segments\VFFW9S_FIG) (POSTSCRIPT\S561C1VFFW9S_FIG.EPS\19)

In a situation of the kind shown in (VFFW9S_FIG), you can follow the chain from segment 1 through segment 8, which points to the bad segment. To continue from that point, enter in the left column the lowest segment number not yet accounted for and follow its link. Remember, if a segment links to 0, it is the last segment in the directory. Continue until all the segments are accounted for in the left column.

When you finish, the number that is missing from the right column is the segment to which the bad segment links. In (VFFW9S_FIG), this is segment 6. As in the previous example, use SIPP to link around the bad segment. In this case, change the link word in segment 8 to point to segment 6, thus removing segment 7 from the chain. (Remove the Data from the Good Segments\DTFRGS_SEC)

Once you have eliminated the bad segment by linking around it, you are ready to save the files whose entries appear in the good segments. Use the monitor COPY command to copy the files to a good volume. The following command, for example, copies all the files from one diskette to another: (COPY DU2:*.* DU3:(RET))

This procedure removes all the files from the volume except those whose entries appear in the bad segment. (Remove the Data from the Bad Segment\DTFRBS_SEC)

You can sometimes save files whose entries appear in the bad segment by using SIPP and DUP. If, when you open the segment with SIPP, block 1 of the segment is unreadable, you should probably stop because chances are that even if block 2 of the segment is readable, it contains old data that is not valid.

If you can read block 1, decode the header and the entries according to the diagram in (DTFDEF_FIG). Continuing with SIPP, try to locate the files on the volume. ((DTFSDS_SEC) explains how to locate a file on the volume.) Once you establish the starting and ending blocks of a specific file, run DUP and use the following command sequence to transfer the file to a new volume: (output-filespec=input-volume:/G:startblock/E:endblock/I/F)

You can use the following keyboard monitor command to achieve the same results: (wide) (COPY/DEVICE/FILES input-volume/START:startblock/END:endblock output-filespec)

When you have finished removing files from the volume, you can return it to another user (if someone wrote over the directory); or, you can reformat and initialize it (if there was a bad block in the directory area). If reformatting does not remove the bad block, label the volume clearly so you do not accidentally use it again. (BUP Volumes)

BUP-initialized disks are nonbootable RT--11 file-structured volumes with one directory segment and a special BUP identifier in the home block (see (DTFHBL_SEC)). Structurally, they are essentially identical to other RT--11 volumes. BUP, during restoration operations, checks for the special BUP identifier in the home block as part of its verification procedure to ensure that savesets consisting of multiple file sections are of the proper length and in the proper sequence.

(FLFBUP_SEC) describes the format of BUP savesets and file sections. (Large (Partitioned) Disks)

RT-11's directory structure allows a block number up to 16 bits (65,535(10)) long. Many of today's disks, however, have more than 65,535 blocks. To utilize the full capacity of these disks, RT--11 does (disk partitioning\bold).

Disk partition numbers allow RT-11 to use disks having more than 65,535 blocks. The disk partition number can be thought of as a high-order block number, as shown in (DTFMBN_FIG).

(MSCP Disk Block Number\DTFMBN_FIG) (POSTSCRIPT\S561C1DTFMBN_FIG.EPS\7)

If a disk has more than 65,535 blocks, the RT--11 device handler for that disk divides the disk into logical partitions of 65,535 (1\ Although RT-11 block numbers can be 0 through 177777(8), or a total of 65,536(10) blocks (200000(8), or 000000 in 16 bits since the 17th bit is lost), the size of a partition is defined as 65,535(10) blocks (177777(8)), with RT-11 block numbers 0 through 177776. This avoids the problem of 16-bit overflow when dealing with the partition size. Because the partition number is added onto the left of the RT-11 block number to give the MSCP block number, one block between each partition is unused. The list below gives the block numbers of the first three partitions: (#)

(Partition########Block Numbers\BOLD)

####0#######000000--177776, block 177777 unused

####1#######200000--377776, block 377777 unused

####2#######400000--577776, block 577777 unused ) blocks each. An RT--11 disk handler for a partitioned disk can, in theory, support up to 256 disk partitions. Therefore, the largest disk RT--11 can access has 256*65,535 blocks. To an RT-11 user, such a disk would appear to be 256 separate 65,535-block disks, each disk having its own directory.

Even though full MSCP supports block numbers of up to 32 bits, current RT--11 MSCP handlers for partitioned disks (for example, DU) support a block number of no more than 24 bits, because the handlers store the partition numbers as bytes. However, the partition number entries in the handler's translation table could be expanded to word entries if desired and 32-bit block numbers supported with no particular difficulty. Refer to (SIM_BOOK) for details of the format of the DU handler's translation table. (Interchange Diskette Format)

You can use the FILEX /U option (or the monitor COPY/INTERCHANGE command) to transfer data between RT--11 volumes and interchange diskettes. An interchange diskette, also known as an IBM floppy disk, consists of 77(10) tracks. Each track contains 26(10) sectors, and you can store one record of 128 or fewer characters per sector, using EBCDIC format.

Track 0 of the diskette is reserved for dataset labels, which are a form of directory. The functions of the sectors of track 0 are as follows.

Sectors 1 through 4 are reserved by IBM for system use. There are 80 blanks per sector.

Positions 1 through 13(10) of sector 5 are used to record the identity of an error track. Positions 1 through 5 contain (ERMAP \bold)to identify the sector as an error map. Sector 5 is not supported by RT--11.

Sector 6 is reserved by IBM for system use. It contains 80 blanks.

Sector 7 is the volume label. Positions 1 through 4 (bytes 0 through 3) contain (VOL1 \bold)in EBCDIC. This identifies the diskette as an IBM floppy. Within Digital, these four bytes identify the system that wrote the diskette. RT--11 stores (RT11 \bold)here. Other fields in sector 7 identify the diskette, its format, and its owner, and indicate whether or not the diskette uses standard labels. (DTFIS7_TAB) describes the contents of sector 7. (#)

(Interchange Diskette Sector 7\DTFIS7_TAB) (3\8\8) (Octal\Decimal\Byte Contents) (##0\#1\V) (##1\#2\O) (##2\#3\L) (##3\#4\1) (FIRST) (##4\#5\Bytes 5 through 10 contain the volume ID field. The ID consists of one to six digits or letters (left-justified); unused positions must contain blanks.) (#12\11\Access code. Must be blank to permit access to diskette.) (#13\12\Bytes 12 through 37 are reserved by IBM.) (#45\38\Bytes 38 through 51 contain the owner ID field. Not all systems use this field.) (#63\52\Bytes 52 through 76 are reserved by IBM.) (LAST) (114\77\Bytes 77 and 78 are the record sequence field, or interleave factor.) (115\78\Two blanks represent 1:1 interleave.) (116\79\Reserved by IBM.) (117\80\Label version field. (W \bold)indicates standard labels.)

Sectors 8 through 26 are the dataset labels. They are 40 words long and contain directory information. (DTFIS8_TAB) describes the contents of sectors 8 through 26. (#)

(Interchange Diskette Sectors 8 Through 26\DTFIS8_TAB) (3\8\8) (Octal\Decimal\Byte Contents) (##0\#1\H) (##1\#2\D) (##2\#3\R) (##3\#4\1) (##4\#5\Reserved.) (##5\#6\Bytes 6 through 13 contain the user name for the dataset (the file label).) (FIRST) (#15\14\Bytes 14 through 22 are reserved.) (#26\23\Bytes 23 through 27 contain the block/record length. The default is 80, but 128 is possible.) (#33\28\Reserved.) (#34\29\Bytes 29 and 30 contain two EBCDIC characters representing the track number of the beginning of data.) (#36\31\EBCDIC 0 (360(8)).) (#37\32\Bytes 32 and 33 contain two EBCDIC characters representing the sector number of the beginning of data.) (#41\34\Reserved.) (#42\35\Bytes 35 and 36 contain two EBCDIC characters representing the number of the last track reserved for this dataset.) (#44\37\EBCDIC 0 (360(8)).) (#45\38\Bytes 38 and 39 contain two EBCDIC characters representing the number of the last sector reserved for this dataset.) (#47\40\Reserved.) (#50\41\Bypass indicator.) (#51\42\Dataset security.) (#52\43\Write protect.) (#53\44\Blank for data interchange (100(8)).) (#54\45\Multi-volume indicator: C=Continued, L=Last, Blank=Not continued.) (#55\46\Bytes 46 and 47 contain the volume sequence number.) (#57\48\Bytes 48 and 49 contain the creation year (such as (80\bold)).) (#61\50\Bytes 50 and 51 contain the creation month.) (#63\52\Bytes 52 and 53 contain the creation day.) (#65\54\Bytes 54 through 66 are reserved.) (102\67\Bytes 67 through 72 contain the expiration date (in the same format as the creation date).) (110\73\Verify mark: V=Dataset verified, Blank=Not verified.) (111\74\Reserved.) (LAST) (112\75\Bytes 75 through 79 contain the number of the next unused track and sector within this dataset.) (113\76\Bytes 75 and 76 contain the track number.) (114\77\EBCDIC 0 (360(8)).) (115\78\Bytes 78 and 79 contain the number of the next unused sector.) (117\80\Reserved.) (Sequential-Access Volumes)

RT--11 magtape volumes are file-structured and sequentially accessed (not random-accessed). This section describes the magtape formats and file structures. At the end of this section is a procedure you can use to copy magtapes between the RT--11 and VMS operating systems. (Magtape Structure)

RT--11 supports two types of magtape formats. They are quite similar to each other and are both based on ANSI Standard X3.27--1978, (File Structure and Labeling of Magnetic Tapes for Information Interchange).

If you read or write files on a magtape using an RT--11 utility such as PIP, or from your own assembly-language program using .LOOKUP, .ENTER, .READ, and .WRITE, you use the file-structured magtape handler. File-structured magtape handlers contain the FSM, the file structure module. RT--11's file-structured magtape handler creates and recognizes tape labels on magtapes that it writes.

BUP, the backup utility program, bypasses the FSM in magtape handlers and uses its own file structure module. Therefore, if you write files on a magtape using BUP, the resulting tape will be somewhat different from one created using the file-structured magtape handler.

The following sections describe each tape format in detail. (RT--11 File-Structured Magtape Format)

This section describes the magtape format read and written by the file-structured magtape handler.

RT--11 file-structured magtape implementation includes the following restrictions. Features and restrictions for BUP-written magtapes are described in the (sum_book): (unNUMBERED) There is no EOV (end-of-volume) support. This means that no file can continue from the end of one tape volume to another volume. RT--11 does not ignore noise blocks on input. RT--11 assumes that data is written in records of 512(10) characters per block. The logical record size equals the physical record size. ()The hardware magtape handler (as opposed to the file-structured magtape handler) can read data in any format. You can also make use of .SPFUN programmed requests and the file-structured magtape handler to read tapes with data in a nonstandard format (see the (DEV_book) for details). The RT--11 utility programs, such as PIP, DUP, and DIR, can only read and write tapes in the standard RT--11 format of 512(10)-character blocks. RT--11 does not check access fields and therefore provides no volume protection.

(DTFFSM_FIG) is a dump of tape written by the file-structured magtape handler (FSM). The VOL1 block, however, is actually written by DUP (not by FSM) when you INIT the magtape. Prior to RT--11 Version 5.5, DUP and FSM always made label records of 512 bytes, but only the first 80 bytes were used. Characters in positions 81--512 were undefined. Magtape labels created in that format were not transportable to other operating systems, such as VMS.

Since V5.5, those label blocks are physically 80 characters (40 words) long, making them transportable to a VAX processor running the VMS operating system. The procedure to transport magtapes created by RT--11 to VMS is described in (FLF_RTVMS_SEC).

If necessary, a customization patch for DUP.SAV allows you to make old-style 256-word labels. If you use the patch, bytes 81--512 in VOL1 records (written by DUP) are initialized to spaces. Bytes 81--512 in HDR1 and EOF1 labels (written by FSM), however, are still undefined. Magtapes containing such labels are not transportable to VMS.

(FSM Magtape Label and Header Formats\DTFFSM_FIG) (wide\keep) *** MTFMGR: DB MU0:, 256. Words, (Base 8) *** 047526 030514 052122 030461 020101 020040 020040 020040 *VOL1RT11A * 020040 020040 020040 020040 020040 020040 020040 020040 * * 020040 020040 042040 041045 020040 020040 020040 020040 * D%BHAMILTON* 020040 020061 020040 020040 020040 020040 020040 020040 * 1 * 020040 020040 020040 020040 020040 020040 020040 031440 * 3* *** MTFMGR: DB MU0:, 256. Words, (Base 8) *** 042110 030522 042532 047522 042105 055056 055132 020040 *HDR1FILE.DAT * 020040 020040 051040 030524 040461 030040 030060 030061 * RT11A 00010* 030060 030060 030060 030061 020060 030060 030060 020060 *001000100 00000 * 030060 030060 020060 030060 030060 030060 042504 051103 *00000 000000DECR* 030524 040461 020040 020040 020040 020040 020040 020040 *T11A * ** Tape Mark ** DATA AREA - 256-word fixed-length blocks. These blocks are exactly the same as the disk files that they represent. ** Tape Mark ** *** MTFMGR: DB MU0:, 256. Words, (Base 8) *** 047505 030506 042532 047522 042105 055056 055132 020040 *EOF1FILE.DAT * 020040 020040 051040 030524 040461 030040 030060 030061 * RT11A 00010* 030060 030060 030060 030061 020060 030060 030060 020060 *001000100 00000 * 030060 030060 020060 030060 030060 030060 042504 051103 *00000 000007DECR* 030524 040461 020040 020040 020040 020040 020040 020040 *T11A * ** Tape Mark ** ** Tape Mark ** ** Tape Mark **

Note that the 000007 in the EOF1 label in (DTFFSM_FIG) indicates that there are 7 data blocks in the data area.

In the following examples, an asterisk (*) represents a tape mark. The structure of the actual tape mark depends on the encoding scheme that the hardware uses. A typical nine-channel NRZ tape mark consists of one tape character (23(8)) followed by seven blank spaces and an LRCC (23(8)). Consult the hardware manual for your own tape volume if the format of the tape mark is important to you.

A file stored on magtape has the following format: HDR1 * data * EOF1 * A volume containing a single file has the following format: VOL1 HDR1 * data * EOF1 * * * A volume containing two files has the following format: VOL1 HDR1 * data * EOF1 * HDR1 * data * EOF1 * * * A double tape mark following an EOF1 * label indicates logical end of tape. (Note that the EOF1 label is considered to consist of the actual EOF1 information plus a single tape mark.) A magtape that has been initialized has the following format: VOL1 HDR1 * * EOF1 * * * A bootable magtape is a multifile volume that has the following format: VOL1 BOOT HDR1 * data * EOF1 * * *

To create an RT--11 bootable magtape, you must copy the primary bootstrap by using the INITIALIZE/FILE:primboot command, where (primboot) is MBOOT for 8 bpi and TMSCP magtapes or MBOT16 for 16 bpi magtapes. The primary bootstrap is represented by (BOOT \bold)in the format given for a bootable magtape. It occupies a 256(10)-word physical block. The first real file on the tape must be the secondary bootstrap, the file MSBOOT.BOT. If the tape is designed to allow another user to create another bootable magtape, you should copy the primary bootstrap file (MBOOT.BOT or MBOT16.BOT) to the tape, as a file. (This is in addition to copying it into the boot block at the beginning of the tape.) More detailed instructions for building bootable magtapes are in the (sim_book).

The primary and secondary bootstraps inspect the I/O page for the presence of standard magtape volume registers to determine which type of magtape controller is available. Make sure that other peripheral volumes on your system do not use addresses in the I/O page normally used by another magtape controller. The bootstraps might attempt to use the magtape controller assigned to those addresses rather than the magtape controller actually installed on your system.

Each label on the tape (as shown in the formats of the various magtape structures) is a separate record, 80 bytes long, and each byte in the label contains an ASCII character. (That is, if the content of a byte is listed as 1, the byte contains the ASCII code for 1, not the octal value 1.) (DTFAML_TAB) shows the contents of the 80 bytes in the three labels. Note that with the older version of RT--11, the VOL1, HDR1, and EOF1 labels occupied a full 256(10)-word block each, of which only the first 80 bytes were meaningful. (#)

(RT--11 File-Structured Magtape Labels\DTFAML_TAB) (4\10\14\8) (CharacterPositioninLabel\Field Name\Lengthof Field\Contents) ((4\LEFT)Volume Header Label (VOL1)) (1--3\Label identifier\##3\VOL) (4\Label number\##1\1) (5--10\Volume identifier\##6\Volume label. If you do not specify a volume ID at initialization time, the default is RT11A(SP)) (11\Accessibility\##1\(SP)) (12--37\Reserved\#26\(Spaces)) (38--50\Owner identifier\#13\Positions 38--40 = D%B (This means tape was written by DEC PDP--11.) Positions 41--50 = Owner name. Maximum is 10 characters; default is (spaces).) (51\DEC standard version\##1\1) (52--79\Reserved\#28\(Spaces)) (80\Label standard version\##1\3) ((4\LEFT)File Header Label (HDR1)) (1--3\Label identifier\##3\HDR) (FIRST) (4\Label number\##1\1) (5--21\File identifier\#17\The six-character ASCII file name, dot, three-character file type. This field is left justified and followed by spaces. Do not pad the file name or type.) (22--27\File set identifier\##6\RT11A(SP)) (28--31\File section number\##4\0001) (32--35\File sequence number\##4\First file on tape has 0001. This value is incremented by 1 for each succeeding file. On a newly initialized tape, this value is 0000.) (36--39\Generation number\##4\0001) (40--41\Generation version\##2\00) (42--47\Creation date\##6\(SP) followed by (year*1000) + day in ASCII; (SP) followed by 00000 if no date. For example, 2/1/90 is stored as (SP)90032.) (48--53\Expiration date\##6\(SP) followed by 00000 indicates an expired file.) (54\Accessibility\##1\(SP)) (55--60\Block count\##6\000000) (61--73\System code\#13\DECRT11A(SP) followed by spaces.) (74--80\Reserved\##7\(Spaces)) (LAST) ((4\LEFT)First End-of-File Label (EOF1). This label is the same as the HDR1 label, with the following exceptions: ) (1--3\Label identifier\##3\EOF) (55--60\Block count\##6\Number of data blocks since the preceding HDR1 label, unless you issue an .SPFUN programmed request. If you issue .SPFUNs, the block count is 0. However, if the only special function operations you do are 256(10)-word .SPFUN writes, the block count is accurate.) (BUP Magtape Format)

The magtape format used by BUP, the Backup Utility Program, is not quite the same as the RT--11 file-structured magtape format used by PIP, DUP, and so on. BUP bypasses the file-structured magtape handler and writes its own tape labels. You can mount a magtape written by BUP on a VAX or other system that supports ANSI-format magtapes, and read the BUP saveset from the tape. Note, however, that VMS will read the entire BUP saveset as a single file. You have to extract individual RT--11 files from the saveset file with the VMS EXCHANGE utility.

(DTFBTF_FIG) and (DTFBML_TAB) illustrate the format of labels on a BUP magtape. Some of the contents in these records is fixed, while other parts are variable. For example, DECRT11BUP is always recorded in a BUP tape VOL1 label, but BACKUP.BUP is an arbitrary saveset name given by the user. Similarly, 88159 in the HDR1 record is a date code indicating that the file was made on the 159th day of 1988.

(BUP Magtape Label and Header Formats\DTFBTF_FIG) (wide\keep) VOLUME LABEL: 047526 030514 052122 052502 020120 020040 020040 020040 *VOL1RTBUP * 020040 020040 020040 020040 042504 051103 030524 041061 * DECRT11B* 050125 033065 020060 020040 020040 020040 020040 020040 *UP560 * 020040 020040 020040 020040 020040 020040 020040 020040 * * 020040 020040 020040 020040 020040 020040 020040 032040 * 4* HEADER_1 LABEL: 042110 030522 040502 045503 050125 041056 050125 020040 *HDR1BACKUP.BUP * 020040 020040 051040 041124 050125 030040 030060 030061 * RTBUP 00010* 030060 030061 030060 030061 020060 034070 032461 020071 *001000100 88159 * 030060 030060 020060 030060 030060 030060 042504 051103 *00000 000000DECR* 030524 041061 050125 033065 020060 020040 020040 020040 *T11BUP560 * HEADER_2 LABEL: 042110 031122 030106 030064 033071 030060 030465 020062 *HDR2F0409600512 * 030060 032460 033470 031064 030060 030060 030060 030060 *0005874200000000* 020040 020040 020040 020040 020040 020040 020040 020040 * * 020040 030060 020040 020040 020040 020040 020040 020040 * 00 * 020040 020040 020040 020040 020040 020040 020040 020040 * * ** Tape Mark ** FILE SECTION DATA AREA CONTAINING CONSECUTIVE DISK BLOCKS, BLOCKING FACTOR=8 (PHYSICAL RECORD SIZE=2048 WORDS, EACH RECORD CONTAINS EIGHT 256-WORD BLOCKS) ** Tape Mark ** END_OF_FILE_1 (OR END_OF_VOLUME_2) LABEL: 047505 030506 040502 045503 050125 041056 050125 020040 *EOF1BACKUP.BUP * 020040 020040 051040 041124 050125 030040 030060 030061 * RTBUP 00010* 030060 030061 030060 030061 020060 034070 032461 020071 *001000100 88159 * 030060 030060 020060 030060 031467 031464 042504 051103 *00000 007343DECR* 030524 041061 050125 033065 020060 020040 020040 020040 *T11BUP560 * END_OF_FILE_2 (OR END_OF_VOLUME_2) LABEL: 047505 031106 030106 030064 033071 030060 030465 020062 *EOF2F0409600512 * 030060 032460 033470 031064 030060 032460 033470 031064 *0005874200058742* 020040 020040 020040 020040 020040 020040 020040 020040 * * 020040 030060 020040 020040 020040 020040 020040 020040 * 00 * 020040 020040 020040 020040 020040 020040 020040 020040 * * ** Tape Mark ** [ ** Tape Mark ** ] if end of tape [ ** Tape Mark ** ] " " " " OR HDR1, if another file section begins. (#)
(BUP Magtape Labels\DTFBML_TAB) (4\10\12\8) (CharacterPositioninLabel\Field Name\Lengthof Field\Contents) ((4\LEFT)Volume Header Label (VOL1)) (1--3\Label identifier\##3\VOL) (4\Label number\##1\1) (5--10\Volume identifier\##6\Volume label. The label of the first volume of a BUP saveset is RTBUP; the label on the second volume is RTBU02, the third is RTBU03, etc.) (11\Accessibility\##1\(SP)) (12--24\Reserved\#13\(Spaces)) (25--37\Implementation identifier\#13\DECRT11BUPnnn, where nnn is a 3-digit version number. This identifier also appears in HDR1, EOF1, and EOV1 labels.) (38--51\Owner identifier\#14\(Spaces)) (52--79\Reserved\#28\(Spaces)) (80\Label standard version\##1\4) ((4\LEFT)File Header Label (HDR1)) (1--3\Label identifier\##3\HDR) (FIRST) (4\Label number\##1\1) (5--21\File identifier\#17\BACKUP.BUP plus seven spaces) (22--27\File set identifier\##6\RTBUP(SP)) (28--31\File section number\##4\0001) (32--35\File sequence number\##4\First file on tape has 0001. This value is incremented by 1 for each succeeding file. On a newly initialized tape, this value is 0000) (36--39\Generation number\##4\0001) (40--41\Generation version\##2\00) (42--47\Creation date\##6\(SP) followed by (year*1000) + number of the day in ASCII; (SP) followed by 00000 if no date. For example, (SP)88032 represents February 1, 1988.) (48--53\Expiration date\##6\(SP) followed by 00000 indicates no date.) (54\Accessibility\##1\(SP)) (55--60\Block count\##6\000000) (61--73\Implementation identifier\#13\DECRT11BUP560) (74--80\Reserved\##7\(Spaces)) ((4\LEFT)Second File Header Label (HDR2)) (1--3\Label identifier\##3\HDR) (4\Label number\##1\2) (5\Record format\##1\F (indicates fixed-length records)) (6--10\Block length\##5\04096) (11--15\Record length\##5\00512) (16\\##1\Reserved) (17--24\Saveset size in blocks\##8\Decimal value) (25--32\Next block number\##8\Decimal value; in the final EOF2 label, this number equals the saveset size.) (33--50\Reserved\#17\Spaces) (51--52\Offset length\##2\00) (53--80\Reserved\#27\Spaces) ((4\LEFT)First End-of-File Label (EOF1). This label is the same as the HDR1 label, with the following exceptions: ) (1--3\Label identifier\##3\EOF) (55--60\Block count\##6\Number of data blocks since the preceding HDR1 label, unless you issue an .SPFUN programmed request. If you issue .SPFUNs, the block count is 0. However, if the only special function operations you do are 256(10)-word .SPFUN writes, the block count is accurate.) (LAST) ((4\LEFT)Second End-of-File Label (EOF2)) (1--3\Label identifier\##2\EOF) (4\Label number\##1\2) (5\Record format\##1\F) (6--10\Block length\##5\04096) (11--15\Record length\##5\00512) (16\Reserved\##1\(SP)) (17--24\Saveset size\##8\) (25--32\Next block number\##8\) (33--50\Reserved\#17\Spaces) (51--52\Reserved\##2\00) (53--80\Reserved\#27\Spaces)

A backup saveset is recorded as one or more file sections. Only one file section for each tape volume is associated with a particular saveset.

EOV labels replace EOF labels when physical end-of-tape is encountered and a saveset continues on subsequent volume(s). In this case, the next volume always begins with the next saveset (file) section in sequence.

Label records are all 80 characters in length, both logically and physically.

VOL1 labels have the following characteristics: (unnumbered) The first volume in a saveset contains a VOL1 label that identifies the tape with name RTBUP. Subsequent volumes are identified with names RTBU02, RTBU03, and so forth. The implementation identifier is DECRT11BUPxxx, where xxx is a 3-digit version number. This identifier is also recorded in the HDR1, EOF1 and EOV1 labels.

Notes about HDR1, EOF1 and EOV1 labels: (unnumbered) Expiration date is not specified

Notes about HDR2, EOF2 and EOV2 labels: (unnumbered) Character position 16 is blank and reserved for future use. Character positions 17--24 contain an 8-digit saveset size in blocks. Character positions 25--32 contain an 8-digit "next" block number. This number equals the saveset size on the final EOF2 label. (RT--11/VMS Magtape File Interchange\FLF_RTVMS_SEC)

Because of changes that were made to how the FSM represents file names in the HDR1 and EOF1 label name fields, RT--11 magtapes are more compatible with the VMS operating system ANSI magtape implementation. The format change is backwards compatible with RT--11 utilities and, using the information provided below, allows text files to be transferred between the RT--11 and VMS operating systems.

Text files to be transferred between RT--11 and VMS must be enclosed in an RT--11 logical disk, as the logical disk file format is compatible with both operating systems and can be conveniently transferred in either direction by using magtape media.

The VMS EXCHANGE utility is used for format translation when files are transferred in either direction. Use EXCHANGE to create an RT--11 logical disk on a VAX computer when transferring files from the VMS system to RT--11. When transferring files from the RT--11 system to VMS, use EXCHANGE to convert files on the RT--11 logical disk from RT--11 format to VMS format. Because EXCHANGE utility characteristics could change with a future VMS release, you should consult the VMS documentation if any questions arise with using EXCHANGE.

The following example illustrates transferring files from a computer running RT--11 to a VAX computer running the VMS operating system: (numbered) Create and mount a logical disk of sufficient size to contain those files you want to transfer. Then, copy the files to the logical disk. In the following commands, (LOGDSK.DSK) is the logical disk, (LD0) is logical disk unit, and (dev:files.ext) are those files you want to transfer. You then copy the logical disk to an initialized magtape volume, (MU0): (.)(CREATE LOGDSK.DSK/ALLOCATE:nnnnnn) (.)(MOUNT LD0: LOGDSK.DSK) (.)(INITIALIZE LD0:) (.)(COPY dev:files.ext LD0:) (.)(INITIALIZE MU0:) (.)(COPY LOGDSK.DSK MU0:)

As an alternative, you could use the following BACKUP command to achieve the same result: (.)(BACKUP/INITIALIZE/NOQUERY dev:files.ext MU0:LOGDSK.DSK) Carry the magtape volume to the computer running VMS, mount the volume, log on to the VMS system, and enter the following: ($)( ALLOCATE MUA0:)

If the files were placed in LD0 by the COPY command, issue the following command: ($)( MOUNT/OVERRIDE=OWNER/BLOCKSIZE=512 MUA0: RT11A)

If the files were placed in LD0 by the BACKUP command, issue the following command: ($)( MOUNT/OVERRIDE=OWNER MUA0: RTBUP) After mounting MUA0, issue the following commands: ($)( COPY MUA0:LOGDSK.DSK *) ($)( EXCHANGE) (EXCHANGE>)( MOUNT/VIRTUAL LD: LOGDSK.DSK) (EXCHANGE>)( DIR LD:) (EXCHANGE>)( COPY LD: *.* *) (EXCHANGE>)( (CTRL/Z)) ($)( DISMOUNT MUA0:)

The following example illustrates transferring files from a VAX computer running the VMS operating system to a PDP--11 computer running RT--11: (numbered) Use EXCHANGE to convert and copy VMS format files ((vmsfiles.*)) to an RT--11 format logical disk file ((LOGDSK.DSK)): ($)( EXCHANGE) (EXCHANGE>)( INITIALIZE/CREATE LOGDSK.DSK/ALLOC:nnnnnn) (EXCHANGE>)( MOUNT/VIRTUAL LD: LOGDSK.DSK) (EXCHANGE>)( COPY vmsfiles.* LD:) (EXCHANGE>)( (CTRL/Z)) ($) Initialize and mount a magtape ((MUA0)), and specify a 512-byte blocksize: ($)( ALLOCATE MUA0:) ($)( INITIALIZE/OVERRIDE=OWNER MUA0: RTTAPE) ($)( MOUNT/BLOCKSIZE=512 MUA0: RTTAPE) Copy the logical disk file, (LOGDSK.DSK), to the magtape and dismount the magtape: ($)( COPY LOGDSK.DSK MUA0:) ($)( DISMOUNT MUA0:) Carry the magtape MUA0 to the RT--11 system and mount it. Transfer the logical disk file, (LOGDSK.DSK), to a disk with sufficient space, and then perform regular RT--11 operations to retrieve the files it contains. (End of Chapter)