Posts Tagged ‘Status Codes’

Contingent Allegiance Condition (CAC)

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:

2 comments - What do you think?  Posted by Greg - April 9, 2010 at 4:55 PM

Categories: Glossary   Tags: , ,

SCSI Status Codes

The SCSI Status Code is what comes back from the SCSI target at the end of every command, and sometimes before the command completes.  It informs the SCSI initiator if the command worked (successful) or didn’t work (unsuccessful).

Here is a list of the status codes and what they mean.  By the way, the small “h” behind each code means we are using hexadecimal (hex – base 16) notation.

00h – Good Status. The device server has successfully completed the task (command).

02h – Check Condition Status. This indicates that Sense Data is available and that a Contingent Allegiance Condition (CAC) may exits.  A CAC usually means that some kind of error has occurred.

04h – Condition Met. This code is returned for unlinked conditional commands, such as PREFETCH.  This means the command was successful.

08h – Busy. This means the device (logical unit) can not accept a command right now.  This condition is temporary and the command should be tried again.

10h – Intermediate. This is the same as a Good status (00h), except it is returned from a command that was part of a series of linked commands.  The last command in the series cannot have this status.

14h – Intermediate-Condition Met. Combination of 04h and 10h codes (see above).

18h – Reservation Conflict. The device or element is Busy because a reservation is in place.  Think of this as “Busy, because I am reserved”.)

22h – Command Terminated. This status code is now obsolete, but it was the result of a Terminate I/O Process message (that message is also obsolete).

28h – Task Set Full (was Queue Full). The Command Queue (task set) is full. You can think of this as “Busy, because my queue is full”.

30h – ACA Active. This code means that an Auto Contingent Allegiance (ACA) Condition exits in the task set.  A Clear ACA message is normally used to clear this condition.

40h – Task Aborted.  This means that a task has been aborted by another SCSI initiator (nasty) and the Task Aborted Status (TAS) bit is 1 (one) in the Control Mode page.  More info to come on mode pages.

If you have any specific questions about these status codes, or when and why they occur, leave a comment and we will get you hooked up.

Incoming search terms for the article:

Be the first to comment - What do you think?  Posted by Greg - April 2, 2010 at 7:30 AM

Categories: Glossary   Tags: