One of the most challenging aspects of the PC inte· gration program was the provision of a remote boot capability for MS-DOS. In organizations where there are large numbers of PCs, remote boot allows the system manager to maintain the end ,user's PC envi ronment from a centralized boot service. Our prin cipal goal, then, in developing remote boot was to provide the ability to boot any vendor's PC over the network. Since each PC vendor distributes its own variant of MS·DOS, it followed that if we achieved this goal, then no modifications to the operating sys tem wou ld be required.
Our initial implementation was designed to sup port the VAXmate product and PCs equipped with the Digital Ethernet PC Network Adapter (DEPCA) . In both cases the maintenance operation protocol (MOP) boot code exists in read-only memory (ROM). The PC triggers the remote boot process by issuing a MOP system boot request which is serviced by a VAX boot server process. The boot server downloads a network loader program to the PC. The network loader is an Intel assembler program encapsulated in an RSX task image wrapper. The loader's function is to load DOS from the network . The network loader is a permanently resident part which contains the random-access memory (RAM) data link, the LAST transport, the LAD software , and a transient control program to drive the load process.
Since MS-DOS can only be booted from drives A or C, we had to provide a low-level disk emu lation by means of INT 1 3 H that would emulate drive A during
the boot process. This emulation is the function of the LAD/LAST software in the network loader.
Once the network loader is resident in the PC, it must relocate its permanent pan into an area that will not be overwritten by MS-DOS while the PC is running. On a VAXmate system , the loader achieves this relocation by copying the code into the 1 28- kilobit (Kb) network RAM. On a PC, the size of phys ical memory is reduced by the size of the permanently resident code (approximately 17Kb) , and then the code is relocated to high memory just below the 640Kb boundary. The network loader must next find the name of the boot disk service for the PC . This name is determined by convening the 48-bit Ethernet hardware address (which is guaran teed to be unique) to its ASCII representation, e .g., 08-00-2B-08-41 -3C. This name is then used to con nect to a vinual disk which has been formatted as an MS-DOS bootable floppy disk.
The network loader reads the DECnet-DOS data base from which it gets the data link configuration parameters . If no database exists, the system defaults are used.
Finally, the loader reads the boot block from the vinual disk and transfers control .o the bootstrap loader contained in the boot block. The bootstrap loader uses the BIOS !NT 1 3 H calls to read MS-DOS from the boot device. These calls are intercepted by the LAD ! NT 1 3 H handler. Thus access to the vinual disk is transparent to the bootstrap loader. The last step in the process is to restOre the real drive A, since at this point drive A is mapped to the vinual disk.
Perfo
rmance
This section describes several techniques imple mented tO enhance the performance of both the file and disk server. These techniques were required to provide service response times similar to those seen when an application is running from a local hard disk on the PC .
One of the major differences between the MS-DOS and VMS systems is the manner in which file header information is stored on both systems. DOS stores the header information in the directOry, whereas the VMS system stores this information in the file header. Thus DOS has access to this i nformation as soon as the directory is read into memory. On the VMS system , however, additional 1/0 must be per formed to read the fi le headers. Thus a DOS direc tory command generates high overhead on a VMS system . The file server therefore had tO minimize system overhead when enumerating directory entries and also make directOry operations nonblocking to other PCs using the file server. To accomplish this, the file server makes QIO calls to XQP rather than
so
using the SPARSE and SSEARCH functions in R.MS. This technique also aiJows the file server to obtain the file header information used by the SCHKPRO sys tem service when determining the user's access rights to a file.
A second technique which improves fi le access speed is the provision of a read-ahead cache in the file server. Many PC applications process files sequen tially; the file server automatically detects this access mode and uses a double-buffered prefetch algorithm to read data from the file before it has been requested by the client . This prefetch resu lts in fewer 1/0 requests since the file server prefetches the maximum amount of data that can be returned to the client in one message (8Kb) . The algorithm also increases data throughput speeds since the next read request from the client can normally be satis fied with data already in memory.
The disk server i s not cognizant of the fi le system on the vinual disk and attempts to reduce disk IjO by using a write-through cache. Like the file server, the disk server prefetches data into the cache. Data is purged from the cache based on a least-recently used algorithm. Since the disk server is imple mented as a VMS device driver and the cache is stored i n nonpaged dynamic memory, the response to client I/0 requests is fast.
Overall client performance can be improved by judicious use of the file and disk server in a hybrid combination. In many instances applications can be shared for read-only access by multiple clients through the disk server. Moreover, the data on which the application is operating can be shared for read-write access through the file server. This pani tioning can also result in higher numbers of PCs being supponed by the server, since the disk server overhead is much lower than the file server.
References
DECnet-DOS Programmers Reference Manual (Maynard: Digital Equ ipment Corporation, Order No. AA-EI346C-TV, April 1 988) .
IBM PC Network, PC Adapter Manual (Boca Raton : 113M Corporation, Reference No. 6322505 , Septem ber 1984) .
IBM Personal Computer Seminar Proceedings, vol. 2, no . 8 (October 1984 ) .
IBM Token-Ring Network, PC Adapter Manual (Research Triangle Park: 113M Corporation, Reference No. 69X7830, June 1986) .
P. Mierswa , D. MittOn, and M. Spence, "The DECnet DOS System," Digital Technical journal (September 1986) : 108- 1 16.