Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!Tli@usc-eclb
From: Tli%usc-eclb@sri-unix.UUCP
Newsgroups: net.micro.cpm
Subject: Function 37
Message-ID: <15526@sri-arpa.UUCP>
Date: Sun, 22-Jan-84 02:36:00 EST
Article-I.D.: sri-arpa.15526
Posted: Sun Jan 22 02:36:00 1984
Date-Received: Wed, 18-Jan-84 07:32:59 EST
Lines: 66

From:  Tony Li <Tli@usc-eclb>


All right, if were really going to discuss this, let me give you a
copy of my source.  The following is the description of Function 37
from the CCP/M-86 manual.  Admittedly, this isn't the same as the CP/M
2.2 filesystem, but I would be surprised if there were any significant
differences.  Anyhow:

----------------------------------------------------------------------

			DRV_RESET

		Reset Specified Disk Drives

	Entry Parameters:

		Register CL : 025H (37)
			 DX : Drive Vector

	Returned Values:

			 AL : Return Code
			 BL : Same as AL

The DRV_RESET system call is used to programmatically restore
specified removable media drives to the reset state (a reset drive is
not logged in and is in Read-Write status). [Presumably there are no
files open on a drive which is not logged in. - Tony]  The passed
parameter in register DX is a 16-bit vector of drives to be reset,
where the least significant bit corresponds to drive A, and the
high-order bit corresponds to the sixteenth drive, labelled P.  Bit
values of 1 indicate that the specified drive is to be reset.  Refer
to Section 2.17 [CCP/M-86 1.0 Programmers Guide] for more information
regarding the use of this system call.

This system call is conditional under Concurrent CP/M-86.  If another
process has a file open on any of the drives to be reset, the
DRV_RESET system call is denied, and none of the drives are reset.

Upon return, if the reset operation is successful, DRV_RESET sets
register AL to 00H.  Otherwise, it sets register AH to 0FFH.  If the
BDOS Error mode is not in Return Error mode (refer to the F_ERRMODE
system call), the system displays an error message at the console
identifying the process owning the first open file that caused the
DRV_RESET request to be denied.

----------------------------------------------------------------------

Section 2.17 goes on to stipulate that "If all the open files on a
removable drive belong to the calling process, the process is said to
'own' the drive.  In this case, the file system performs a qualified
reset on the drive and returns a successful result.  This means that
the next time a process accesses this drive, the BDOS performs the
log-in operation only if it detects a media change on the drive."

----------------------------------------------------------------------

Conclusion: In the safest case, one should close all files before
performing a DRV_RESET.  However, if you do not, and your BIOS is
somewhat flakey about detecting a media change (or your hardware is),
you might not get the reset.  This would probably result in
destruction of the newly inserted media, as has been described by JEP.

Cheers,
Tony ;-)