Storr Consulting - sc520-nat013


Home	The Company	Publications	Products	Links	Tips

Tips, Tricks, and Techniques

Last update: 30 April 2004

NAT3009 - Response Code 9

Background, Analysis, Solutions

Details:

Background

Under NATURAL 2.2, customers may notice an increase in the number of NAT3009's in both their online and batch environments. This is due to NATURAL issuing all NAT3009's back to the user. Under NATURAL 2.1, some NAT3009/RSP009 messages were suppressed. However, as a result of a Change Enhancement request NATURAL 2.2 was designed to pass these errors back to the end-user.

Analysis

In order to decrease the occurrence of NAT3009's, it is important to determine the subcode of the NAT3009. The subcode will tell the customer the direct cause of the NAT3009 error, for example, this error could be caused by duplicate ETID's (subcode 64), LP being too too small (subcode 15), a valid non-activity timeout (subcode 3), etc. Please see the ADABAS Messages and Codes Manual for further details regarding the subcodes of the RSP009/NAT3009.
How can the subcode of the NAT3009/RSP009 be found? The subcode can the located in two ways:

Immediately after receiving the NAT3009/RSP009, execute the program: USR0610P in library: SYSEXT. It will display the subcode of the NAT3009/RSP009.
Bring ADABAS up so that command logging is initiated. Continue command logging until several NAT3009/RSP009's occur. Terminate command logging and review its output as outlined in the ADABAS Command Reference Manual to determine the subcode.

Solution Examples

If a NAT3009, subcode 64 is received, a duplicate ETID is the cause. To correct duplicate ETID's, ensure that users do not have multiple NATURAL sessions in progress at one time, or code ETID=' ' as a dynamic override when invoking NATURAL, (providing ETDATA is not/will not be utilized).

If a NAT3009, subcode 3 is received, an ADABAS non-activity time limit has been exceeded. This can be corrected by increasing TNAE, TNAX, or TNAA as appropriate. This situation can occur when NATURAL releases control to VSAM or DB2 for processing and the job does not return to NATURAL until after a non-activity time limit has been exceeded.

These are just two examples of recommended methods for correcting two of the most commonly seen NAT3009/RSP009 errors. Please refer to the Adabas Messages and Codes Manual for further information on RSP009 and its associated subcodes as well as the appropriate measures necessary to correct them.

More Info About NAT3009

Question

We have a batch job that is scheduled to run in the early hours of the morning. Every so often it fails with a Nat 3009. I should have the subcode in a few days (assuming that the job fails again, and assuming that this time I put USR0610N in the right place).

I've noticed that the last two times the job failed there were a number of jobs updating a number of Adabas tables running at the same time. This leads me to believe that the problem might be the Protection Area or the Hold Queue. The High-water mark for the Hold Queue is 2.5%, so that means that LP is probably the issue. I've pretty much eliminated duplicate ETIDs and timed-out UQEs, too.

So the first question is: Would I really see a response 9 for Hold Queue full? I know there's an error code for NISNHQ exceeded, so wouldn't I expect to see some sort of Hold Queue exceeded message? (I realize that Adabas figures that the most important thing to tell you is that something might have been backed out, but still.)

The second question relates to the fact that when I check out my Work allocation, I notice that part I is 14500 blocks, part II is 6600, and part III is 490, for a total of 21590 blocks. When I check out the Work dataset, it is 250 Cylinders. This is a 3390 device. I think there should be room for 33750 blocks altogether. Where's the missing space? Can I use ADADEF NEWWORK to fix it? If so, I get the impression that I just specify 'this old work' in my JCL. Can that be true?

We are running ADA533 and NAT226 under MVS/ESA (along with Security, Predict, Construct, Broker, Network, etc.)

Answer 1

Yes, the most likely cause of your RSP 9 is that you are running out of WORK PART I the LP area. This is specified in an ADARUN parameter with a max of 32K. There is no harm in setting this parm to the max but as you are aware you may need to increase your work dataset size.

You can also solve the rsp9's by getting the application to issue ET's more frequently.

WORK PART II is defined using the LWKP2 parameter. As per the operations manual:

The size (in blocks) of the ADABAS Work Part 2, which is used to hold intermediate ISN lists during Sx commands, can be controlled by this parameter. Work Part 2 size is calculated by ADABAS by the following formula:

(22 + 2 S TOPISN) / (Work blocksize - 16/3)

WORK PART III uses all the rest & needs at least 50 blocks for ADA to be able to initialize.

Answer 2

Another cause of rsp 9s is the issue of synch-points. We've at times had programs simultaneously abend with rsp 9s while an online is issuing its synch-point. If you look at your checkpoint file through AOS you can see if there were any SYNx's issued around the same time you are receiving rsp 9s. In that case, rearranging your job schedule may be all you need to do.

The subcode of rsp 9s that are caused by SYN5's is 2.

SYN5's will hold up new transactions until all pending ones are either ET'd or BT'd, which could take up until the TT time limit.