NOTE: Any capability, utility, super utility, or configuration option, marked by * is due for availability in EDT-ACSLS 8. I. Intro to TSM, EDT, & ACSLS Interaction TSM requires of the library the ability to: - mount a volume - dismount a volume - eject a volume to a export station - query the status of a volume - release a volume to a scratch tape pool TSM communicates to EDT by starting an elmdt child process, opens a pipe, and sends through a string containing a command, a library name, and additional fields in support of these commands. EDT, at its simpliest, translates the commands onto ACSLS and then translates the results back to TSM. A configuration example for TSM is shown in the guide, "EDT TSM Interaction", showing a basic setup: - define an external library definition referenced by "libname". - define the library path to the EDT executable elmdt - define a device class, setting the drive type, associating it with the library, and setting mount control variables. - define storage pools, associating them with the device class and setting max scratch limit. - creating and activating a management policy to backup and archive to the storage(s) pools. Two big differences in setting up TSM for an external library type: - no need to define drives. - no library inventory checkin. Whenever EDT is sent a command, a libname always is included. The libname matches that of the libname given to a TSM external library definition. EDT matches this libname to that defined in a library description in the config file elm.conf. A library description starts with the entry, LIBRARY libname, and ends with the entry END. In the description is: - libtype - license key - diagnostic and message setup - ACSLS scratch tape poolID - map of ACSLS driveIDs and system device files. - SSI API overrides. - assorted optional behavior. This library description controls the behavior of EDT setting needed definitions to talk to ACSLS and a host of other functionality, showing EDT does more than simply translate between TSM and ACSLS. EDT communicates with ACSLS via the SSI API, residing on the host as daemons ssi and mini_el. See guide, "SSI API" for information on how to set up the SSI startup file and explanations on extended functionality. EDT's Control Center aids in the setup and configuration of EDT and setup and start of the SSI API. Especially helpful in TSM LAN-Free client environment where there are multiple EDT nodes to be configured. II. Drive Sharing amongst Multiple TSM Servers, TSM LAN-Free Clients, & Any Other Application. EDT can share the drives: - amongst TSM LAN-Free clients accessing drives via EDT. - multiple TSM servers accessing drives via EDT. - any application requiring access to the drives. (assuming app knows how to share drives) Availability of a drive is judged on it's status being available, state online, it can be reached through a system device handle, and that it can be locked. If there is no drive available, EDT checks for availability every 10 seconds up till the user set timelimit sent with the mount command. If no drive comes available, the mount times out. Through EDT config options, MOUNT_NO_WAIT, you can choose to not wait for an available drive, and MOUNT_WAIT_TIME, you can adjust the rate of the interrim availability check. TSM needs little tuning to work with EDT in a drive sharing environment. There are several mount control variables associated with A TSM device class that control how long EDT waits to get access to a volume or an available drive, how long a volume sits idle in a drive, and how many concurrent mount processes are allowed. Refer to the guide, "EDT TSM Interaction", topic "Mount Control Variables". EDT itself needs little special tuning or consideration to operate in the drive sharing environment. Topics with pertinent options: - Acsls Scratch Pools - Guidelines and Options: scratch pool consolidation. - Mount Traffic Control: minimizing clashes over available drives. - Versatility of Operation for Volumes Not in Library or Found in Drive: LAN-Free clients waiting for a volume in a drive. III. Mixed Media Environment TSM uses its device class to set the devicetype it controls, the format, as well as setting mount control variables already mentioned. The device class is associated with an external library definition. This makes for some easy guidelines to set up in a mixed media environment. - In TSM create a device class to handle each distinct drive type, tying each to a separate library definition. - Configure EDT with a library description each with a libname matching one of the TSM library definitions. - In each lib description, assign drives of a like drive type corresponding to that of the device class associated with the lib description. - Create a separate ACSLS scratch pool for each available media type. - Define a scratch poolID to a library description that has drives compatible with the media type you plan on placing in the scratch pool. IV. Acsls Scratch Pools - Guidelines and Options. ACSLS allows up 65534 scratch pools to be defined and used. For EDT, we only ask that whatever pool you list in a library description is populated with volumes that are media type compatible with the drive type in that description. It is possible to load a scratch pool with any and all media types, but you will be adding needless confusion. You may run out of volumes compatible with your drive type, and as long as the total number of vols in the pool remains above the low water mark, you see no warning that you are running low on scratch volumes. Therefore, we recommend one storage pool for each distinct media type. In a multiple TSM server environment, there is no need to have separate pools for each server. You can do so, but each pool can be accessed by any and all servers. Consolidating the pools in this manner reduces time in assigning scratch volumes to pools. One pool for each distinct media type, and each server can draw from the same set of pools. In the case of TSM LAN-Free clients consolidating pools makes the most sense, as you can have many clients each accessing ACSLS through EDT. There are a number of utilities that assist with the use of scratch pools. The super utility elm_insert_scratch will at the same time, initiate the insert operation and assign the vols to an appropriate scratch tape pool.* The elm_filter_vols utility allows you to extract a list of volumes from TSM in many varying ways. Using this list with the super_utility elm_volrpt or set scratch will insure that no vols in use by TSM are found in the scratch tape pools. V. Device High Availability With the emergence of SAN, it is very easy to have multiple data I/O paths to the same drive, each path hopefully across different adaptors. EDT can handle these multiple paths with ease. You can define DRIVE entries in a library description each featuring a different device file. Example: DRIVE /dev/rmt0 ACS_0,0,0,1 DRIVE /dev/rmt5 ACS_0,0,0,1 When EDT selects a drive for mount it performs a test open on the drive. If the first device refuses to open, the second device file is accessed, and so on until all devices listed have been tested. If the mount is forced to wait, and again comes to a drive through which it previously could open no device file, on mount re-attempts, this drive is ignored. All EDT interaction with the device can be stopped by using the disable label option and the option DRIVE_DISABLE TEST_OPEN which stops the test open EDT performed prior to the mount. VI. Drive Selection Policies By default, EDT seeks to access drives in the order they are listed in a library description. EDT processes each of these drives seeking the first encountered drive that has status available, state online, can be locked, and finally accessed through a device file. This top down approach is not the most suitable for your needs. EDT features a host of drive selection policies that can be used alone or in combination. Drive Randomization - spreads wear evenly across the drives. Preferred Drive Number Allows choosing a subset of drives ahead of others. Used in tandem with randomization. Close LSM Minimizes movement between lsms. The drives in the lsm in which a volume resides are given preference. Drives in the next closest lsms follow. Preferred LSM First select drives in the named preferred lsm. Drives in the next closest lsms follow. LSM Mapping By default The physical layout of the lsms is assumed to be a chain with beginning and ending points and vol pass through ports between lsms. lsm 0 - lsm1 - lsm2 - lsm 3 - lsm 4 .... lsmn LSM Mapping allows you to override this layout, and create your own. You list an entry for each lsm and its corresponding next closest lsms. In fact, you can list out the lsms in any order you desire. There is no limit as far as being able to follow any lsm layout. Far too may to list here. See LSM Map layouts. Effective Policy Combinations: Drive Randomization, Preferred Drive Number Close LSM, Drive Randomization Maintain close lsm drive selection and randomize drive selection in each lsm. Close LSM, Drive Randomization, Preferred Drive Number The close lsm pattern holds, the drives in each lsm are split into subsets with the preferred drives to be chosen ahead of the other drives in the lsm, and each subset of drives is randomized. Preferred LSM, Drive Randomization Maintain preferred lsm drive selection and randomize drive selection in each lsm. Preferred LSM, Drive Randomization, Preferred Drive Number The preferred lsm pattern holds, the drives in each lsm are split into subsets with the preferred drives to be chosen ahead of the other drives in the lsm, and each subset of drives is randomized. LSM mapping can be added to any of the above four. VII. Minimizing Volume Movement between LSMs The close lsm drive selection policy seeks to reduce movement between lsms for a mount request for a private volume. EDT also features a built in ability to insure that a volume selected for scratch mount request follows that same drive selection policy.* As a general policy, load scratch volumes as close as possible to the drives in which they will be used. EDT also features a super utility elm_eject that allows for placing preference on the cap(s) in the lsm in which a volume is located.* EDT also recommends that on dismount, you accept ACSLS default behavior to dismount vol into close available home location. Resist the temptation to choose any option to have the vol returned to the exact home location from which it was taken for the mount. The fact is that as drives become maximal occupied, mounts will result in vol movement between lsms. It is guaranteed that you increase this movement by saying return the vol to its starting home location. If movement between lsms must be zero: - Keep drives of a like type confined to one lsm. - Insert media compatible with the drives into the lsm. - Use a scratch pool occupied with volumes in that lsm. VIII. Mount Traffic Control TSM has the potential to issue a large number of mount requests at the same time. For instance in forcing data from a disk storage pools out to tape, you can potentially use all drives available up to the mount limit. Each mount request sees the same drive status and seeks to access the same drives. This can cause some unnecessary traffic as one or more processes get rejections and have to try again on another drive. You can serialize the mount requests by turning on the SERIALIZE_LOCK option. The serialization is handled as first-in first-out. As soon as one mount process gains access to a drive and prior to the mount request, the next mount request is allowed to be serviced. When serialized, if the mount process seeking to gain access is made to wait for an available drive, then all queued mounts wait. You may wish to set the TSM mountwait timelimit lower than the default 60 minutes, 5 minutes is the minimum allowed, or choose not to wait at all using EDT option MOUNT_NO_WAIT. This places preference on quicker service of mounts, allowing TSM to make the decision for active operation to quit or retry. If the preference is on getting access to a drive, leave the TSM mountwait timelimit relatively high. The time that an EDT process waits for a drive is the combination of serialization time and the time actively looking and waiting for a drive. For occasions of simultaneous mount requests, if the first mount times out, the subsequent waiting mounts do not automatically also timeout. EDT guarantees they have at least one chance to gain access to a drive. Another and simple method of controlling traffic through to ACSLS is to adjust the EDT MOUNT_WAIT_TIME. While waiting to gain access to an available drive, EDT will restrict its polling rate to ACSLS based on this value. The default value is 10 seconds. The EDT mountwait time can be used alone or in tandem with serialization to really help control the flow of traffic from the client node to the ACSLS server. In a multiple TSM server environment, you can reduce clash over availability of drives between servers by: - Mount serialization on each TSM server and extend the EDT mounwait. - Set the EDT mountwait period to a prime number and leave at least 5 seconds difference from server to server. For instance, extend the overall mount wait time to 30 seconds but actually set a server to 29, another to 23. - Add the EDT option REFRESH_DRVINFO, refresh drive information. If two or more processes clash over trying to gain access to a drive, wait and get fresh drive information. Not only can ACSLS get overloaded, but the SSI API can also suffer under heavy work load. If you have more than one TSM server operating on your client node, configure the SSI API to to start multiple ssi daemons, each servicing one TSM Server, refer to the guide, "SSI API", topic "Multiple SSI APIs". IX. Drive Clearing Capability Especially in a drive sharing environment, it is important to keep drives highly available for use by any client. This is also true for any singular server that can have multiple operations vying for access to drives. A backup may be going on at the same time as as a restore, reclamation, what have you. Doing the utmost to insure that drives are cleared as quickly as possible, insures as many TSM operations as possible can complete. EDT features a number of internal drive clearing capabilities. See the following topics: - Locking Drives: identifying drives needing to be cleared. - Mount and Dismount Failure Recovery. TSM when starting up, sends indication to EDT that it is initializing. EDT can check the drives in the library and any drive previously locked by the TSM Server is cleared and unlocked. This is handy if TSM locked up & had to be rebooted or the client host has to be rebooted. Refer to EDT config option CLEAR_DRIVES_START. - You must insure that the SSI API is up running prior to TSM initializing. See guide, "SSI API", topic "API Startup at System Boot". - If the API is not running, when TSM initializes you will experience unnecessary hanging as EDT will take approximately 5 minutes to find that the API can not be reached. And this hang will occur for each external library definition needing to be initialized. Furthermore, TSM will try to initialize each of these libraries once every 2 and half minutes. For ultimate drive clearing action, EDT's drive clear super utility combined with Control Center gives you the best coverage as it remains independent of each node. When a client is up and active, Control Center as part of a scheduled maintenence, will call to the clients elm_drive_clear super utility and perform a "safe" drive clear. This means that each drive in use by the client must have an active controlling elmdt process, and if not the drive is cleared out. If a the TSM server on a client is down or the client is found to be offline, Control Center will clear the drives belonging to that client. If clearing a drive manually, you will have to query for drive locks and include the lockid in the dismount request. Issue a dismount and once the drive is cleared, remove the lock from the drive with a drive unlock command. Reference utilities: acsls_qlockdrive, acsls_qdrive, acsls_dismount, and acsls_unlockdrive. Easing the collection of drive status, drive locks, vol status, super utility elm_drvrpt performs a number of queries collecting and corelating the data for ease of presentation. Automating and simplifying clearing out a drive, use the super utility elm_drive_clear. It can be used to target a particular drive, and perform the tasks necessary to get the drive to an available state. It has a force mode so that even if a drive status shows available, a dismount is still forced against the drive. This comes in handy when the library and the ACSLS database are out of sync. X. Locking Drives - Behavior and Benefits Once a drive is seen as available and online, EDT locks the drive for the duration of the mount, unlocking after the drive has been successfully dismounted. EDT uses the ACSLS drive lock mechanism and can be seen by issuing a query drive lock through either ACSLS cmd_proc, locally through EDT utility acs_qlockdrive or super utility elm_drvrpt. EDT uses a unique format to form the userID associated with a drive lock. Typically the userID is based on the client hostname, but EDT expands this to: hostname.libname.PID hostname: Client hostname or EDT config option CLIENTID. libname: libname as defined as an external library to TSM and matching a library description libname in the EDT config file elm.conf. PID: process id of the elmdt process controlling the mount request. Locking a drive with the unique userID provides a number of benefits: - Reserves use of drive for your client. - Easily identify what client and application is using a drive. - Gauge use of drives by EDT at any given time. Especially handy in a TSM multi-server environment, when seeking to gauge work loads and drive use distribution amongst servers. - Eases identification of a drive that needs to be cleared. - The only reason that EDT would leave a lock on a drive is if the drive could not be dismounted either through drive error, library error, communication error, TSM failure, client host failure. - The lock points you to the client host, you can test the TSM server seeing what it believes is mounted. You can check EDT by seeing if the controlling elmdt process is still actively using the drive, or if the controlling process hit an error on dismount, reported error to TSM, and then exited. XI. Versatility of Operation for Volumes Not in Library or Found in Drive. Upon mount request, if a volume is found not to be in the library, the default is to tell TSM that the volume is unavailable. TSM will mark the volume as unavailable, and an administrator will have to update the TSM volume access to readwrite for the volume to be eligible for mount. Perhaps you have been using TSM's Move Media to have primary data volumes located out of the library in order to make room for more volumes. - EDT can be configured to allow for a grace period to get the required volume into the library; refer to config option, VOL_NOT_IN_LIBRARY. - EDT will wait up until the timelimit passed in with the mount request; refer to TSM-EDT interaction: device class mountwait. - You can also adjust the polling rate out to ACSLS, refer to the config option MOUNTWAIT. - Enable message class MENT type TOPN, or message sev level 5, or specifically message 350 to see tape operator notification. Example: <6008> EDT0350 SEV 5 03-24-2004 04:13:54 Insert Vol 123456 into Library acsls_m_estab_vol_status.cpp (173) For a volume already found in a drive, the default response is to cancel the mount request. In a TSM LAN-FREE environment, clients can use the same volumes to store their data. They can seek to access the volume at the same time. - You can elect to have EDT wait to access the volume; refer to EDT Config: VOL_IN_DRIVE. - The timelimit and polling rate are adjusted the same as for waiting for a volume not in the library. - Note that you can elect to use TSM collocation which specifies clients store data on separate volumes. You can also choose to return library error or volume unavailable of a volume is already found in a drive. XII. Mount and Dismount Failure Recovery If a mount or dismount request fails for any reason EDT features advanced diagnostics: On mount: - Detects if requested volume made it to drive, and takes control of the volume. If control can not be taken, EDT seeks to clear the drive. - Detect if HSC (LIb Station) has placed a queued volume into our drive and if so, issue drive clear. - Detect if Library and ACSLS database are out of sync. ACSLS updates its database that volume is in drive until after the library the completes task. If error occurs prior to commit, ACSLS will think the drive is still available and the volume is still in the home slot. Volume has potential to become lost, being assigned status Missing or Absent if the volume is attempted to be accessed by the robot. EDT detects this discrepancy and issues a drive clear. If successful, ACSLS "rediscovers" the volume. On dismount: - Detects if a volume is stuck in a drive, and it is toggling status between in use and available. If seen as available, a mount attempt fails in an unflattering fashion, as the robot seeks to stuff a volume into a drive that is really in use. EDT detects this state, and leaves the drive occupied and the lock stays on the drive so it can no longer be accessed. You can also optionally configure retries on failed mount and dismount through the EDT config options, MOUNT_LFR_RETRY and DISMOUNT RETRY. You can configure the number of retries and specify error codes on which to trigger retries or retry on all errors. There is also an option that forces the drive into "diagnostic" operation, so that no further attempts to dismount or mount onto the drive will be allowed. refer config options MOUNT_LFR_KEEP_DRIVE_LOCKED and DISMOUNT KEEP_DRIVE_LOCKED. EDT will still seek to access the drive for data I/O, but when done with the volume, will not dismount and will leave the drive locked. This is only necessary if an error condition has been detected that has shown that any further attempt to dismount the drive could force library into error state or offline. Rare occurrence, and this is not a fix for the error, rather it stops any real damage from occurring. Judging a volumes status prior to the mount is an important gauge to the success or failure of a mount request. It has been stated that EDT allows you to choose how to respond to a volume found in a drive. That said, it is not generally considered to be a good thing if a volume is found in a drive, and you are asking for its mount. How did it get there? If TSM Lan-Free setup and you are letting clients share volumes, fine. But otherwise, it could be that the volume is in the drive left by a failed previous mount or dismount, and TSM is asking to retry. It could be that someone else has mistakenly taken a hold of your volume. Perhaps it mistakenly got assigned back to the scratch pool, as part of someone adding volumes to the scratch pool as part of a range. EDT will attempt to access a volume that is found in a drive. - If the drive is unlocked, we ask no questions as to how it got there, just that it is ours and we need it. Therefore if you need to perform some administrative task on the volume, disable access to the volume though TSM, update vol 123456 access=unavailable, or put a lock on the drive prior to mounting the volume. EDT can detect if the drive is actively open for data I/0 and will leave the drive alone is so detected. - If EDT finds the volume in a locked drive by another EDT client on your node, EDT can gauge if the controlling elmdt process is active and if not, issue a drive clear, wait and seek to mount the volume in a drive locked by your client. - If EDT finds the drive locked by another client node, either cancel by default or follow optional override behavior. Each client can police itself, but not other clients. For complete coverage you need the combined efforts of super utility elm_drive_clear and EDT's Control Center. * EDT will soon be able to work with ACSLS volume locks. This will enable an additional level of security, insuring that no server can get access to a volume owned by TSM, either by malicious intent or accident. It is planned that the volume locking capability be: - An optional configuration. - Can be switched on retroactively and volumes can be locked as they are accessed. Or you will be able to easily lock volumes owned by a TSM Server in one operation. - Can easily be switched off and volumes owned by a TSM Server switched off in one easy operation. - Work with EDT's super utility elm_volrpt, to lock and unlock volumes, test for ownership discrepancies, and removing owned volumes from any scratch pools. XIII. Communications Check and Retry. Built into every command issued by EDT out to ACSLS features the ability to detect communication failure and retry. - This capability is enabled with the config option COMM_CHECK_TIMEOUT. - Upon detecting an error, EDT starts polling the ACSLS server every 30 seconds up to the timeout value set in the option. - If connection is reestablished, EDT will reattempt the command that failed, and if successful continue with the interrupted operation. - On retry, EDT intelligence allows for any command that may have completed but the response was interrupted prior to getting back to EDT. This is an extremely important detail if a command dictated a physical change of state: mount, dismount, eject, lock, vary online/offline. EDT's Communications check and retry can work hand in hand with EDT's Path Watch. - Path watch allows for configuring an monitoring multiple communication paths to the ACSLS server. - If the main communication path fails, Path Watch can switch over EDT to a new set of EDT config files servicing the SSI API that can reach the ACSLS server. - Any new EDT process will automatically be routed to the new API. - Any existing EDT process waiting to reestablish contact, senses that the EDT config has changed and will then post queries out over the new path. By default, ahead of each major operation, mount, dismount, eject, query, and release, EDT checks that the ACSLS Server can be contacted and that the library is in a state to accept new requests. If not, EDT will start polling the ACSLS server, seeking to establish contact up to a minimum limit of 5 minutes up to the timelimit sent in with a mount command. This proactive server check can be turned off with the config option, DONT_ESTAB_COMM. XIV. Flexibility and Capability of the SSI API In this document, it has been described how the SSI API can be configured to start multiple APIs and configured to work over alternative communication paths. There are even more capabilities such as fixed port firewall support, that add up to EDT being able to use the SSI API, maximizing out its flexibility and capability. For full explanation of these capabilities and configuration, see the guide, "SSI API". XV. Variety and Availability of ACSLS Utilities. Installed with EDT in the subdirectory util, there is a host of utilities each running a basic ACSLS command. Each utility imitates a command that can be run from the ACSLS command line interface, cmd_proc, that resides on the ACSLS Server. The output of each utility is programmed to look like that seen through the command line interface. The advantage of having these utilities available on the EDT client, is - The local access of commands to use in custom maintenance scripts. - Testing particular command error. - Quickly testing the communication path to the ACSLS server with acsls_qserver. - Able to operate on lists of volumes obtained from the TSM server, acsls_eject, acsls_setscratch. The syntax of each utility is obtained by typing in the utility name and hitting enter. Each utility has the capability to use any of the configuration options associated with the SSI API. To see the API overrides, enter the option "-e" with the utility and hit enter. For explanation of the SSI API config options and utilities see the guide "SSI API". XVI. Autolabel Function: Behavior and Error Detection. After a volume has been mounted, EDT opens the drive and attempts to read the label on the tape. The drive is expected to be labeled with a standard IBM tape label, either 80 byte record with first 4 characters VOL1, followed by a tape mark, or the full label 3 80 byte records, VOL1, HDR1, HDR2, followed by a tape mark. If this a scratch mount request, EDT can detect if the tape condition is such that it can be labeled. EDT can detect blank media, garbage data on the tape, incorrect block size on tape, or if the label is incomplete in size or content. In all these cases, EDT will write a valid label on a tape. EDT writes the short label, VOL1,TM, or the config option EXTENDED_LABEL forces the write of a full label, VOL1,HDR1,HDR2,TM. The label check can be turned off with the config option, DRIVE_DISABLE LABEL. One thing to note. If you turn off the labeling with the assumption it will speed up the mount process, you are mistaken. It will speed up the response time of EDT back to TSM, but TSM then seeks to open the drive and verify the label. The access time at that point is the same. In addition, if you turn off autolabel you will have to insure scratch volumes are already labeled. Some tapes do come from the manufacturer with a standard label either short or extended label. Otherwise, you will have to use the elm_label utility to label scratch vols prior to assigning them to the scratch pool. EDT can also detect error on the label read and can diagnose: media fault, drive hardware error, drive open error, wrong vol in drive, and write protection error. Depending on the error, EDT takes the following recovery action: OPEN ERR: Error occurred on drive open. Dismount the volume, if scratch mount request return volume to pool, return LIBRARY_ERROR to TSM. The result is that TSM tries upwards of 3 additional times to get the volume mounted. You can adjust the drive open timeout limit with the EDT config option, DRIVE_OPEN_TIMEOUT. DRIVE_ERR: Error indicates hardware failure, same as OPEN_ERROR. WRONG_VOL_ERR: Label mismatch. Internal label does not match barcode. Error is treated the same as open error and drive error. It could be possible that some one replaced the barcode labels on a set of volumes that already had internal labels. MEDIA ERR: Dismount the volume, return VOLUME_UNAVAILABLE for private mount request, return LIBRARY_ERROR for scratch mount request. TSM on the private volumes will mark the volumes as unavailable, and on the scratch mount requests will again request the mount of a scratch volume or cancel, depending on the TSM process requesting volume mount(s). WRPROTECT_ERR: A mount request was made, readwrite access, and the volume was found to be write protect enabled. treated like MEDIA_ERROR. EDT allows you through config options to change the default recovery behavior from one type for any other. In addition you can change any of the defaults to the following: FORCE_LABEL: Error occurred on read, but force the labeling. SAFE_ERR: Dismount vol, do not return any scratch vol to a pool, return LIBRARY_ERR to TSM, insuring no vol is marked unavailable, and upwards of 3 retries are attempted. STOP_ERR: Dismount vol, do not return any vol to a scratch pool, return VOLUME_UNAVAILABLE to TSM, insuring that process is stopped. Private vol is marked as unavailable. Example: A volume error condition is causing DRIVE_ERR on the read. In this case the volume if a scratch mount request is placed back into the scratch pool, where it could continue to create havoc. Upon seeing this error occur, you could easily switch the behavior to MEDIA_FAULT insuring that the vol is not returned to scratch status. You could think of this as a work around until it can be found out why a volume would cause a drive to return sense code hardware failure for what is clearly being caused by a errant volume. LABEL_RECOVERY READ DRIVE_ERR MEDIA_ERR Example: Tape written by 9940C latter used by 9940A as a scratch vol, returns a media fault error on the label read due to the older model drive not being able to handle the higher density written by the 9940C. Configure EDT to ignore media fault and force the write of the label. LABEL_RECOVERY READ MEDIA_ERR FORCE_LABEL EDT also allows you to key off of the errno and define the recovery behavior. This is handy if an error occurs and there is no valid sense data returned on which to gauge the nature of the error. For instance, say an older model drive can not read the format of a newer drive and gives back errno 6 and no valid sense. You could configure to recognize as an error to force the label: LABEL_RECOVERY READ ERR_6 FORCE_LABEL The methods of changing recovery behavior and targeting specific errnos to define a recovery behavior can be used together. Whichever method is listed first takes precedence over the other. Per the examples, if you had an error that gave you errno 6 and sense data indicating media failure, the recovery behavior would be determined by the first encountered entry. LABEL_RECOVERY READ ERR_6 FORCE_LABEL LABEL_RECOVERY READ MEDIA_ERR FORCE_LABEL XVI. Advanced Diagnostics EDT features diagnostic capability that can be activated through EDT configuration. Diagnostic print statements are output to to standard error or to the file named in a config option. Each diagnostic statement features the process PID, date and time stamp, diagnostic statement, source file name and lineno. Different classes can be enabled that allow you to tune the diagnostics to catch the error: - drive ioctls. - autolabel functionality. - functional call level to ACSLS. - memory calls. - serialization locks. - process identification. - conversions and config file access. - libtype entry level: conversion of TSM to ACSLS, combining ACSLS commands to carry out required tsk. - elm level: config initialization, mount wait, portal for autolabel, and director of mount serialization. Not only the EDT executable elmdt that TSM calls can produce diagnostics, but every utility and super utility also features this capability by including the verbose option "-v". XVII. Advanced Message Service. EDT features advanced Message service that can be activated through EDT configuration. Messages are output to to standard error or to the file named in a config option, to system syslog, or sent to an email account. Each message features the process PID, message number, severity level, date and time stamp, message statement, source file name and lineno. You will see in the configuration of messages that the flexibility allows you to enable messages by class, type, range, specific numbers, severity levels, and even to change or create new severity levels. And even further, you can disable by range or specific errno. The message classes represent different levels of processing in EDT, and they are then broken down into types within each class. These types allow you to focus on memory errors, conversion errors, command error, operation notification, and process information. Severity levels are listed as: 1 - Critical error 2 - Error 3 - Warning 4 - Information 5 - Tape Operator console See the guide, "EDT ACSLS Messages" for greater detail on how to set up messages.