reload_system_release of 12.7LDD_STANDARD produces an error file

[Gary Dixon]

When reloading from 12.7LDD_STANDARD tape, a reload error file was created. The console shows:

Input tape label:   M-> 12.7LDD_STANDARD

Mounting tape 12.7LDD_STANDARD for reading
1627.7  RCP: Attached tapa_02 for Initializer.SysDaemon.z
1627.7  RCP: Note (tapa_02) - 12.7LDD_STANDARD,sys
CONSOLE: ALERT
1627.7  RCP: Mount Reel 12.7LDD_STANDARD without ring on tapa_02 for Initializer.SysDaemon.z
attachTape selected unit 2
TAPE: unit is read only
Mounted Multics volume "12.7LDD_STANDARD" (recorded at 800 BPI), on device tapa_02
Error file attached to file ">reload_dir>reload.06/14/21.1629.ef".
End of reel encountered.

The actual .ef file cannot be displayed until system is fully up in ring 4. I had to force SysAdmin.* access, adjust bit count on the .ef file, to display its contents.

cwd >reload_dir
r 16:58 0.033 10


ls -dtcm

Segments = 2, Lengths = 26.

06/14/21 16:29  r w    0  reload.06/14/21.1629.ef
04/01/17 21:14        25  !BBBKLLcGDZxdbN.reload.map

Multisegment-files = 2, Lengths = 704.

06/14/21 16:34       365  !BBBKQCGZjnDFJm.reload.map
04/01/17 21:30       339  !BBBKLLcGGZmxpj.reload.map

r 17:10 0.053 0

sa **.ef rw *.SysAdmin
r 17:01 0.034 0

abc reload.06/14/21.1629.ef -ch
r 17:12 0.013 0

pr **.ef

                    reload.06/14/21.1629.ef       06/14/21  1712.4 mst Mon


hcs_$list_dir_fast: Allocation could not be performed. >library_dir_dir>include
backup_load_dir_list: Allocation could not be performed. >library_dir_dir>inclu
\cde
r 17:12 0.030 0

A quick comparison between GHM >ldd>include and the same directory on the reloaded system shows
segment count and total records used in >ldd>incl on GHM versus my just-upgraded system are identical.

I have no idea what might be causing the Allocation failure. What is hcs_$list_dir_fast?

This problem deserves more investigation.

[Gary Dixon]

reload_system_release is supposed to replace any files in the target directory with perhaps-revised files coming from the system tapes being reloaded. New files read from tape are stored in the target directory. If any existing file in the directory has a name which conflicts with file names from the tape, then those conflicting names are removed from the existing entry. If the existing file has same names as the entry being loaded from tape, that existing entry is finally deleted when its last name deleted. All of this happens during normal reloading.

But reload_system_release also triggers use of the -trim control argument, which causes any existing entry with in a directory with names not found on any tape entry to be deleted after all files are reloaded from tape into the directory. This pruning process is carried out for each directory being reloaded. The reloader has already constructed a list of branches and file names coming from the tape for that directory. After tape entries are reloaded into the dir (as described in above paragraph), it calls hcs_$list_dir_fast to get a list of all entries in the directory with all of their names. Its prune subroutine then sorts these lists and compares them. Any name found on a directory entry which did not come from the tape is deleted. Any entry found in the directory whose final name is deleted (had no names coming from a tape entry) is removed from the directory (file or sub-dir is deleted).

The .ef file described above is reporting an error returned by hcs_$list_dir_fast. If there is insufficient room in the area argument passed to that routine, then the call to hcs_$list_dir_fast fails. So the entire prune operation is skipped (as if -notrim had been specified). For >ldd>include, there are evidently so many entries in the directory that the area argument is not large enough to hold all these structure allocations. Since backup_load_dir_list.pl1 has passed an entire segment (65536 words long) as the area, and since areas used in ring-0 are not extensible, there is no way to provide a larger area to hcs_$list_dir_fast. Therefore, the entire call to list >ldd>include entries fails. No trimming of excess entries is performed on >ldd>include.

This means if include files are ever DELETED from >ldd>include as part of a change request, those includes will not get deleted by any existing site that uses reload_system_release to update their system libraries to the new release contents.

Luckily, files are seldom (if ever) deleted from >ldd>include. So the error being reported (though obscure in nature) has no adverse impacts on the reload_system_release mechanism.

Correction of this error would require inventing a new mechanism for deciding which files need to be pruned from a directory being reloaded. The new algorithm might involve adding a new entrypoint to the hardcore star.pl1 routine that returns only names of all entries in a directory, without structures describing each entry. These names could then be compared with names loaded from the tape. Existing names that didn't match could be pruned from the directory without reference to a structure describing the entry itself.

However, since this problem has only been seen on >ldd>include; and since files and entry names are seldom removed from >ldd>include, correcting this error may not be worthwhile.