Program: LOADND Logs in a disk and updates the ZCPR3 system Named Directory (NDR) to reflect the directory names (if any) for the target disk. LOADND is copyright by A. E. Hawley January 30, 1987. It may be freely distributed, but it must not be sold either separately or as part of a package without the written consent of the author. The author may be reached via electronic mail at the Ladera Z-Node in Los Angeles, 213-670-9465, or through the Lillipute Z-Node in Chicago at 312-649-1730. LOADND is released for beta test through the Z-system users group Z-SIG on January 30, 1987 by the author. Author: Al Hawley, Ladera Z-Node, (213) 670-9465 VERSION HISTORY: 1.2 - 01/31/87 - by AEH Added error and progress reporting routines. The progress reporting messages respond to the ZCPR3 Quiet command. (A computer, like a wife, should not chatter about things that you're not interested in!) The HELP screen reflects current choice of key command letter options, which are user definable by setting the value of those parameters in a data area. Parameters which can be changed to customize the program were moved to a data area near the start and marked with ascii labels that show up with ZDM or other debuggers. For most customization, it is not necessary to reassemble the program - just use the debugger to make changes to the byte(s) following the markers. See CUSTOMIZATION, below. 1.1 - 01/25/87 - BY AEH Name Change only. Change from DSKNDR to LOADND to better reflect the program function and relation to other programs which perform operations on the system NDR. The other programs are EDITND (V1.0, Jan87) and SAVEND (to be released in Feb87). EDITND edits the resident Named Directory buffer; SAVEND copies the resident Named Directory buffer to a disk file suitable for reloading with LDR.COM. 1.1 - 12/26/86 - by AEH - Replaced the first routine in INIT: which tests for valid Z3ENV definition. The original routine tested for a zero address (inadequate). The new routine tests for equality of the 'Z3ENV' strings which occur at the beginning of a ZCPR3 utility and the environment descriptor. If they don't match, installation is required. 1.0 - 12/17/86 - Initial version. Previous similar pgm: LDSK 1.1 by Wilson Bent PROGRAM FUNCTION: Logs in a disk and updates the ZCPR3 system Named Directory (NDR) to reflect the directory names (if any) for the target disk. New Directory Names for the target drive are obtained from one of two sources. The first source is an existing file on the target disk. The name of that file is specified in the abbreviated FCB labeled 'ndrfls:'. The default file specification is *.NDR. The second source is (as in LDSK) the list of filenames specified in the FCB labeled 'dashfn:'. The current default specification is '-*.*', i.e. those filenames whose first character is a '-' character. WHY IS IT NEEDED? In a ZCPR3 system, Named Directories can be used instead of or in addition to the Disk/user form of specifying user areas in the systems mass storage. Directory names are stored in a system buffer from a file whose type is .NDR. The buffer is usually loaded at cold boot time along with other initialization procedures. Subsequently, a new set of names (contained in another can be created (or old ones modified) through use of the MKDIR utility. Although this is an efficient and useful system, there arises a problem which many users have recognized: Suppose you have a system with 2 floppy drives, A and B. The NDR file contains names for BOTH drives. If you switch disks in one of the drives, you may need a new set of directory names. So you can make another NDR file and load it. However, the number of combinations (=number of NDR files!) becomes quite large if you have very many different types of application disks! What is needed is a method of dynamically changing the entries in the system NDR buffer for just one drive. The new names for THAT drive should come from file(s) on the new disk. UPDATE FROM AN *.NDR FILE Most of my floppy disks are bootable; they contain Z-system on the system tracks, and the required system modules on the data tracks. The SYS.NDR file presumes the disk is in drive A (the boot drive), and the directory names for drive A are appropriate for that disk. Those entries are what one would want in the system NDR (with the appropriate drive designator) when that disk is inserted in some other drive. So I started the LOADND program with the purpose of solving the problem described above by installing the (drive A) entries from the NDR file on the disk in the system NDR buffer. During the installation, the 'A' is changed to the letter appropriate to the drive which contains the disk. UPDATE FROM DASHFILES There is another method of designating directory names; an unique character is used as the first byte of a filename in each directory. That filename (without the first character and ignoring the type field) is then taken as the directory name. If a '-' is the first character, then the name appears near the top of a sorted directory listing. Such files are called 'dashfiles'. In this documentation, the term is used even when some other character (like '!', for instance) is the first character. Wilson Bent, Jr. seized on these names as a method of solving the NDR problem; his well-executed program, LDSK, searches the target disk for dashfiles and uses them to update the system NDR. CREDIT: LDSK came to my attention after I had already designed LOADND for accessing NDR files on a target disk. LOADND owes much to Wilson Bent for many of his ideas which were incorporated for handling dashfiles. Because of differences in program flow and data structuring, it was easier for me to incorporate his good work into LOADND than to make a revision to LDSK. CUSTOMIZATION At (approximately) location 010Ch in LOADND.COM there are some user-settable parameters. Each is preceded by a label whose last character is '>'. The byte(s) immediately following the '>' are the parameters which may be changed (a debugger can be used). label: byte(s) notes: DIRLTR> - The first char of files used to identify a user area. '-',usually NDROPT> N The option letter used to specify getting names from an .NDR type file KEEP> A Only names for drive 'A' in the NDR file will be used for the update. This is usually appropriate. Change it if your situation is different. THIS IS NOT THE SAME AS THE TARGET DRIVE IN THE COMMAND LINE! NDRFILE> 0????????NDR Prototype fcb for finding NDR files DASHFILE> 0-?????????? Prototype fcb for selecting marked files The last two are the first 12 bytes of data for an fcb. Don't change the leading '0'! The '?' characters can be changed to anything you wish in order to restrict the filenames/types searched for on the target disk. The '-' is not actually used; that letter is filled in by the program from the value at DIRLTR>. HIGHLIGHTS of LOADND 1) LOADND is a ZCPR3 utility. Standard structure, command syntax, and HELP functions are provided. The HELP function describes command syntax using the ACTUAL name of the program (in case you have renamed it!), and also shows the defaults for arguments; the default for the drive is always displayed as the currently logged drive. Since modification of system facilities is dangerous in general, the wheel byte is checked and non-privileged users are denied the use of LOADND. 2) Either dash-files, or an .NDR (or other) file can be used to specify the new directory names. The choice of which to use (or which to try first if both types are used) is determined by a byte near the beginning of the program. This default choice can be modified with a debugger, by reassembly, or by an option on the invoking command line. 3) Complete restructuring of the code permits flexibility in making changes (improvements?) 4) Because of the use of dynamically assigned buffers, LOADND permits the processing of system Named Directory Buffers of any size. LOADND command line syntax: LOADND [[:]] [/