AEP_1_SEC (8)

Notifies driver that one second has elapsed.

AEP_2_SECS (9)

Notifies driver that two seconds have elapsed.

AEP_4_SECS (10)

Notifies driver that four seconds have elapsed.

AEP_ASSOCIATE_DCB (12)

Associates a logical DCB with a physical DCB. Uses AEP_assoc_dcb structure. Sent when the ISP_ASSOCIATE_DCB service is called. A layer driver can specify additional logical volumes that are associated with a particular physical drive that the TSD cannot deduce for itself. These logical volumes need to be present in real mode as well as protected mode.

AEP_BOOT_COMPLETE (2)

Notifies driver to either unload or continue full operation. Uses AEP_boot_done structure. Sent when initialization is complete and at the end of loading, initializing, and registering a port driver. If the driver chooses to unload at this time it should return AEP_FAILURE in AEP_result. This deregisters and unloads the driver. No DDB pointer is passed with this call, so only one call is received. For instance a VSD can return failure if it has determined that it has not inserted itself in any one of the DCBs in the system.

AEP_CONFIG_DCB (3)

Configures physical device. Uses AEP_dcb_config structure. Sent during initialization so that all layer drivers have opportunity to examine the DCBs in the system, both physical and logical, typically created by port drivers. Made when each layer is initialized. Each layer driver can choose to insert itself in the call down list for the DCB if necessary. For example, a driver interested in seeing requests to a CDROM inserts itself in that DCB. A layer driver that satisfies a specific demand that is stipulated in the DCB dmd flags must turn off the demand bit, indicating to the layers above that the demand has been met.

AEP_CREATE_VRP (18)

Notifies driver that a VRP has been created. Uses AEP_vrp_create_destroy structure. Sent when a VRP goes into service, that is, when the IFSMGR determines that a VRP describes a newly mounted volume. VRPs are actually created any time a mount is attempted, but this message is not sent if the mount fails for any reason (among which is ERROR_VOLUME_EXISTS, a successful remount of a volume). The mounted volume must be a parent volume; this call is not issued when child volumes are successfully mounted. This call, made for symmetry with AEP_DESTROY_VRP, is is informational only, so any response is ignored.

AEP_DBG_DOT_CMD (11)

Notifies driver of parameters for .I debug command. Uses AEP_dot_command structure. Provides a means for debug "dot" commands entered by the user into the windows system debugger to be propogated to each layer. A layer can easily implement support for a "dot" command without having to directly interface with the debugger. Each layer receives a call for each debug command that begins with ".I". In this call, the AEP_d_c_pkeyword member is a pointer to the subkeyword typed by the user. For example, if the user types ".IXYZ", the subkeyword is "XYZ". The AEP_d_c_key_len member contains the length of this subkeyword. The AEP_d_c_flags member indicates which numeric parameters are present. example, if the user types ".IXYZ 1 46", the flag values AEP_NUM_1_PRES and AEP_NUM_2_PRES are set, and AEP_d_c_num_1 and AEP_d_c_num_2 contain the hexadecimal values 1 and 46, respectively.

AEP_DCB_LOCK (16)

Notifies driver that a logical DCB is about to be locked. Uses AEP_lock_dcb structure. Linked to the IRS_QUERY_VOLUME_LOCK service, this AEP call notifies layer drivers that the IFSMGR is servicing an exclusive volume lock. Sent to all layer drivers to determine whether there are any volumes that are associated with a volume that about to be locked. For example, if a compression driver determines that one of its host volumes is about to be locked, the driver needs to indicate all the compressed volumes associated with the host by setting bits in the AEP_d_l_drives member. This ensures that the IFSMGR will lock all the compressed volumes as well. The layer drivers should stop carrying out any operations (such as caching) that are not appropriate on a locked volume. Also see the AEP_DRIVE_REFRESH call and the AEP_drive_refresh structure.

AEP_DESTROY_VRP (19)

Notifies driver that a VRP has been deleted. Uses AEP_vrp_create_destroy structure. Sent when a VRP "goes out of service", that is, when the IFSMGR determines that the volume and any child volumes associated with the volume have been fully unmounted by the FSD that mounted them. This call is used, for example, by the DBLSPACE VxD to determine when it can dispose of its data structures for a particular set of child volumes. This call is informational only, so any response is ignored.

AEP_DEVICE_INQUIRY (6)

Gets device identification data. Uses AEP_inquiry_device structure. Intended for port drivers. The drive fills the DCB_product_id, DCB_vendor_id, and DCB_rev_level members. AEP_result can be set to AEP_NO_INQ_DATA to indicate no inquiry data available or AEP_NO_MORE_DEVICES to indicate that no more devices of this type exist.

AEP_HALF_SEC (7)

Notifies driver that 1/2 second has elapsed.

AEP_INITIALIZE (0)

Initializes driver and interface. Uses AEP_bi_init structure. Sent during the registration of a layer driver. In the case of a port driver registration, the IOS checks to see if the initialization was successful. If so, the IOS sends an AEP_DEVICE_INQUIRY function to the driver. If the AEP_DEVICE_INQUIRY is successful, the IOS sends an AEP_CONFIG_DCB call to all the layer drivers. It then repeats the AEP_DCB_INQUIRY call. In the case of a SCSI port driver, the IOS makes as many inquiries as is specified in AEP_bi_i_max_target member returned in the AEP_INITIALIZE call. Also in the case of SCSI, the scan order can be specified in the AEP_bi_flags member. If AEP_BI_FL_SCSI_SCAN_DOWN is set, the scanning is done in the reverse order. The driver can also set AEP_BI_FL_SEND_CONFIG_AGAIN in AEP_bi_flags. If this is set, the IOS repeats the whole sequence of AEP_INITIALIZE, AEP_DEVICE_INQUIRY, and AEP_CONFIG_DCB again. This is typically not needed as IOS will call the port driver again if the port driver controls more than one controller. Note that in the case of a non-SCSI port drivers, the IOS sends down as AEP_DEVICE_INQUIRY until the driver sets AEP_NO_MORE_DEVICES in the AEP_result member. If the result of the AEP_DEVICE_INQUIRY is AEP_NO_INQ_DATA, the next location is inquired and there is no config call sent out.

AEP_IOP_TIMEOUT (5)

Notifies driver that timeout member in an IOP has been decremented to zero. Uses AEP_iop_timeout_occurred structure. Once an IOP is issued to the IOS using the IOS_SendCommand service, a 15 second timer is started on the IOP. Unless the input and output is done and the IOP is released within 15 seconds, this timer goes to zero and all layer drivers are notified using this AEP call.

AEP_MOUNT_NOTIFY (17)

Notifies driver that a volume has been mounted. Uses AEP_mnt_notify structure. Sent when the IFSMGR has successfully mounted a new volume, but before the operation which caused the mount has been completed. Intended to be used by drivers that create child volumes from special files on the volume (for example, a DBLSPACE driver which causes CVFs to appear as volumes). The driver should find such files and prepare them for mounting. Can also be used by other drivers that want to know when a new volume is mounted.

A driver can carry out one of these valid responses: 1. Associate the original volume with a different drive, for example, move the original volume from drive A to drive H. In this case, if the target drive is already in use, IFSMGR attempts to unmount the current volume for that drive. 2. Return a bitmap of child volumes to mount. The low-order bit corresponds to drive A and so forth. For each bit in the bitmap, the IFSMGR will send a mount child volume command to the same FSD that mounted the original volume. The child volumes and their parent (the original volume) share the same VRP; this is the mechanism by which the relationship among the volumes is maintained. 3. Return a bitmap set to zero. The IFSMGR takes no additional action regardless of any change in the drive number.

When moving a volume, either or both the original volume's effective and actual drives may be changed. For example, drive G is the host for DBLSPACE drive E, E and G are swapped (meaning if there were no compressed drive E, G would be known as E), and G is also host for another compressed drive H. E, G, and H are all visible in real mode. The user's first access may touch any of these drives first. Whichever drive letter is used first, G will be the first drive mounted. Thus, the Compressed Volume Manager will respond that the drive's effective name is really G and its actual name is really E.

AEP_PEND_UNCONFIG_DCB (21)

Notifies driver that a DCB is about to be removed. Uses AEP_dcb_unconfig_pend structure. First AEP function sent to a driver when a DCB is being destroyed. Upon receiving this function call, layer drivers are expected to stop and prevent all further input and output to the device.

AEP_REAL_MODE_HANDOFF (13)

Notifies driver that INT 21h vector is about to be hooked by the IFSMGR. Uses AEP_rm_handoff structure. Sent just prior to the INT 21h vector being hooked by the IFSMGR (in response to the IRS_rm_handoff function). Notifies the layer drivers that this is the last chance to carry out INT 21h function calls through MS-DOS.

AEP_REFRESH_DRIVE (20)

Uses AEP_drive_refresh structure. Informs the layer drivers that an exclusive lock on the volume specified in AEP_d_r_drive is being released. At this point, all on disk file system related data structures could have been moved. For more information about exclusive volume locking, see .

AEP_SYSTEM_CRIT_SHUTDOWN (1)

Indicates a system critical shutdown. Uses AEP_sys_crit_shutdown structure. Broadcast to the layer drivers at Sys_Critical_Exit time.

AEP_SYSTEM_SHUTDOWN (14)

Indicates a system shutdown. Uses AEP_sys_shutdown structure. Broadcast to the layer drivers at System_Exit time.

AEP_UNCONFIG_DCB (4)

Removes configuration of physical device. Uses AEP_dcb_unconfig structure. Sent when a DCB is being destroyed. A layer driver can carry out any action necessary to prepare for the removal of the DCB. For example, if the driver has inserted itself into the calldown of the DCB, it can decrement its internal count of DCBs. Layer drivers typically use such an internal count to determine whether they have inserted themselves into any DCBs. This helps the driver determine the appropriate actioon to take when it receives a subsequent AEP_BOOT_COMPLETE function.

AEP_UNINITIALIZE (15)

Uninitializes driver and interface. Uses AEP_bi_uninit structure. Broadcast during the process of deallocating a DDB. Port drivers respond by freeing or deallocating any resources that they may have allocated to handle input and output to the corresponding controller. (For port drivers, there is typically one DDB per controller.) For example, a driver should free IRQ and port trappings when it receives this call. Note that the DDB is part of the standard AEP header.

AEP_SUCCESS (0)

No error occurred.

AEP_FAILURE (-1)

Error occurred.

AEP_NO_INQ_DATA

No inquiry data available.

AEP_NO_MORE_DEVICES

No more devices of this type exist.