A Contingent Allegiance Condition (CAC) is a SCSI “condition” that exists after there is some kind of problem. What I usually say during class is “these are big words for ‘Hey – We have an error.’ – or some other kind of problem”.
I often find that if you move the words around, it is easier to understand the concepts from the SCSI standards. Here is an example:
A Contingent Allegiance Condition is: a Condition (state) that is Contingent (dependent) upon the Allegiance (connection) between two entities, or components, in a SCSI-based system.
Now for the translation – and I will try to keep it short. In the universe of Storage Area Networking, which is almost entirely SCSI based, the first thing we have to do to be able to issue a command is to make a connection, between the Initiator, through the Target, and finally to the Logical Unit, or at least the code that represents the Logical Unit. Making this connection establishes what is called a Nexus – or I_T_L Nexus. I like to refer to a nexus as a “process ID” – or identifier – for every command within the system.
Since a storage area network, or even a relatively small parallel SCSI system can have multiple initiators, targets, and logical units, it is important to uniquely identify each command, or process, that is sent through the system. That way, we can keep track of all the commands that have been issued and reconnect them back with the original initiator that issued the command.
So that is where the “Contingent Allegiance” part of a CAC comes in – its all about the Nexus, and the connection that it represents.
Now the “Condition” part is simply a “state” that is not considered “normal”. You see, when everything works in a SCSI system, the normal “flow” is:
- Make a connection (establish a Nexus)
- Issue a command (from initiator to target)
- Process the command (Target moves data to or from storage, if needed)
- Receive GOOD status (00h code)
- Close the connection (Nexus “goes away”)
When something goes wrong, then you do NOT receive GOOD status – you most often get back a CHECK CONDITION status (02h code) from the target. This is how the initiator is informed that an error occurred.
The other part you are supposed to know is that the target has generated some sense data, which will explain why the error occurred. And this is where the CAC and Nexus part comes in – the target is supposed to keep the sense information based on the nexus, and that particular command.
What clears this Contingent Allegiance Condition? Normally it is when the same initiator issues another command to that same target and logical unit (remember – its all about the nexus). Usually, the next command is a REQUEST SENSE command, which retrieves the sense data from the device, and it can be decoded by the initiator. Based on this sense data, the initiator should take the appropriate recovery action. What action will the initiator take? The answer is – it depends. It depends on the content of the sense data.
Please let me know if you have any questions or comments.
Incoming search terms for the article:
SCSI Sense Data is the information that comes back from a target when either 1) a CHECK CONDITION Status has been received at the end of a Command (using an auto-sense mechanism), or 2) a REQUEST SENSE command has been issue by a SCSI Initiator.
Whenever I do my SAN training classes, this is one of the topics that I always cover – How to Decode SCSI Sense Data. Becoming a sense data decoder is not that difficult if you know the basic structure of the sense data and the 4 basic steps that I used to decode 95% (or more) of all the sense data that I see. Below are the basic steps.
Step 1 – Check the Sense Key. The Sense Key provides “basic” information about the error and is located in byte 2, bits 3-0, of the returned sense data.
Step 2 – Check the Additional Length field. This field is located in byte 7 and tells you how many more bytes of data are valid (after byte 7).
Step 3 – Check the Additional Sense Code (ASC) and Additional Sense Code Qualifier (ASCQ). These are bytes 12 & 13 of the returned sense data and provide more detailed information about the failure or error condition.
Step 4 – Check the Sense Key Specific Valid (SKSV) bit, which is located in bit 7 of byte 15. If that bit is on, it means that there is “even more” detail about the condition that caused the problem in bytes 15-17. You will have to plug it into another decode table, based on the Sense Key (from Step 1), but in some cases, this can point you to the exact bit and byte in error so that you can debug your problem.
These 4 basic steps can decode up to 95% of all the SCSI error conditions that you will ever see, but there can be even more details, depending on the SCSI device (disk drive, tape drive, etc.) that you are working with. Master these 4 steps and practice them whenever you can and you will become a SCSI Sense Data Decoder in a relatively short period of time. If you want to learn how to decode sense data even faster, just let me know and we can get you signed up.