Chapter Contents
Previous
Next
SAS/CONNECT User's Guide

Attachment Error Handling

Transfer Errors: Direct vs Indirect

When sending a message to a message queue, all attachments, along with the message, are transferred to the queue when the _send or _sendlist is invoked. The attachments are stored at the DOMAIN server until fetched by a user. If an error occurs while sending the attachments to the queue, neither the message nor the attachments will be delivered to the queue. In this scenario, the return code from _send or _sendlist will be set to _SEATTXF. This is an error indicating that neither the message nor the attachments were delivered because one or more errors occurred during attachment transfer.

When a message is sent by using direct messaging, only the attachment list, along with the message, is sent to the receiving side initially. The receiver is then responsible for determining, which (if any), attachments should actually be transferred. Because the message is delivered to the receiver before any attachments are actually transferred, an error that is encountered during the attachment transfer will not cause the _send to terminate.

If an error is encountered, the current attachment transfer is terminated, but the remaining attachments selected to be received are sent to the receiving side. If any errors are encountered during attachment transfer, the return code from _send or _sendlist will be set to _SWATTXF. This is only a warning that indicates which message was successfully sent, but one or more errors occurred during attachment transfer.

Accept Errors

When a message includes attachments, the receiver has the responsibility to determine (by using the _acceptAttachment method) which attachments are ultimately transferred. If an error is encountered during attachment transfer, the current attachment transfer is terminated, but the transfer continues with the next attachment in attachlist. If any errors are encountered, the return code from _acceptAttachment is set to _SWATTXF. This is only a warning, which indicates that one or more errors occurred during attachment transfer. This behavior is the same for both direct and indirect messaging.

Attachment Error Codes

To review what was mentioned above, a specific return code will be set if an error is encountered during attachment transfer.

When one of these scenarios occurs, the attachlist parameter passed to these methods will be updated. An additional named item, rc, will be added to each separate attachment list. The value of rc will be a numeric return code that can be used to determine what caused the error for this particular attachment transfer. The defined return codes (rc) include:

Input File Errors (error occurred on input file):
20 general I/O error
21 libname does not exist
22 memname does not exist
23 invalid or missing password
24 invalid data set option value
25 invalid data set option name
26 general error parsing data set options
27 error parsing WHERE statement
28 bad physical filename
29 file in use
30 file does not exist
31 invalid authorization for external file
32 general open error
33 error retrieving integrity constraints
34 variable name contains unsupported characters or is too long
35 key name contains unsupported characters or is too long.

Output File Errors (error occurred on output file):
80 general I/O error
81 LIBNAME does not exist
82 invalid or missing password
83 bad physical filename
84 file in use
85 file does not exist
86 invalid authorization for external file
87 general open error
88 file already exists
89 integrity constraint creation failure
90 integrity constraint error.

General and Miscellaneous Errors:
1 out-of-memory error
2 open of catalog by queue manager failed
3 catalog read error encountered by queue manager
4 catalog write error encountered by queue manager
5 index create failure
6 backwards compatibility failure
7 unsupported view; only SQL views supported.


Example

In the following example, one attachment is accepted into a non-existent library name: 

   /***************************************/
   /* Build one attachment list, att1.    */
   /***************************************/
att1 = makelist();
rc = setnitemc(att1, 1, "ATTACH_ID");
rc = setnitemc(att1, "NOEXIST", "OUTLIB");
rc = setnitemc(att1, "A", "OUT");

alist = makelist();
alist = insertl(alist, att1, -1);

call send(obj, "_acceptAttachment", 
          alist, rc);

   /***************************************/
   /* If error, dump out attachment list  */
   /* to view rc.                         */
   /***************************************/
if (rc NE 0) then
   call putlist(alist, "Attachment list 
                after accept:", 1);

After the accept method call, the attachment list alist has the following named items:

Due to an error, the attachment has an additional named item (rc) that is set to 81 to indicate that the output library does not exist. Similarly, when the sender returns from the _send or _sendlist, the attachlist parameter will be updated with the rc named item to reflect that the attachment transfer failed. 

att1 = makelist();
rc = setnitemc(att1, "SASUSER","LIBNAME");
rc = setnitemc(att1, "NAMES",  "MEMNAME");
rc = setnitemc(att1, "DATASET","TYPE");

attachlist = makelist();
attachlist = insertl(attachlist, att1, -1);

call send(cnctionObj, "_send", msgtype, 
          attachlist, rc, "Message One");

if (%sysrc(_SWATTXF) = rc) then do;
   call putlist(attachlist, 
                "attachlist after send", -1);
end;

Assuming that the attachment was accepted by the receiving side (as shown in the example) the attachment list (attachlist) after the send is updated with the rc named item to reflect that the attachment transfer failed.

Again, the attachment contains an additional named item (rc set to 81) to indicate any errors that occurred during the transfer.


Chapter Contents
Previous
Next
Top of Page

Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.