Find Adabas file with Non-Descriptor field, DDM is N and Nat3113 error


I found that using natural find statement with non descriptor DDM(N) fields is faster than DDM(D) for descriptor.

After defined 3 fields in DDM as NON-Descriptors and run the batch successfully many times, then starting getting NAT3113 on/off with zero subcode, then setting off natural parms RCGET and RCFIND to avoid the error but did not work.

We felt that RCGET or RCFIND are not working properly or we missed something beyond Natparms setting.

notice, we still having superdescriptor field of the same three non-descriptor fields, we planning to turn off superdesc.

Herein prog ex:


any idea?


I am not sure that Adabas still works the way it used to for a search like the one you posted.

It used to be that a search like yours invoked the dreaded algorithm 4. This could lead to a large number of records being read, even though they did not satisfy the search. You could do a search of the Adabas documentation for the current search algorithms.

I would be willing to wager that a search such as


would be much slower than


Sorry, forgot to address your comment about a super descriptor.

Whether or not you have a super descriptor should not impact whether or not you have a 3113.

Have you tried something like:

super-descriptor = value-1 or= value-2

where value-1 is a compress of #SECONDARY-DATE-N and #REG-RENEWAL-DT and #REG-STATUS

and value-2 is a compress of #PRIMARY-DATE-N and #REG-RENEWAL-DT and #REG-STATUS


Thank you Steve,

I’m trying to eliminate specific super descriptor from adabas file and using NON-Descriptor fields instead.

my issue that we getting error 3113 and we do not know if the error because using super descriptor belonging non-descriptor fields while super descriptor still on the file DDM or issue about wrong display error message 3113 or RCGET and RCfind natural parms do not work and need more setting at mainframe.

A FIND with 3 descriptors can be time-consuming, but usually is preferred over a non-descriptor search because, according to the manual,

So your FIND acts something like

                               OR= #PRIMARY-DATE-N 

Performance is the result of how many records are on the file and how widely the descriptor values are distributed.

How big does *NUMBER get?

Regarding the 3113, are you deleting records within the FIND?

Good Morning Ralph,

I’m retrieving around 750k records of 12 million records that will meet non-descriptors criteria and program does not update or delete any records during program run time.

For error 3113, my job runs overnight during adabas backup time and other batch jobs that maybe will try to deal with(update/delete,…) one record or more during my run.

Also, there is possibility that between building temp inverted list when using NON-descriptors find and retrieve data view(AC), some records are deleted by other jobs cause error 3113.

if we added the below card to JCL may be will keep the job running even 3113:


your input is value.

The documentation states that RIAFTERUPDATE applies to update transactions, so it won’t help you.

I can understand your need to improve performance of this program. The FIND statement is recommended when retrieving a maximum of 100 records, otherwise Adabas incurs quite a bit of overhead. The FIND is taking so long to create its ISN list that other jobs are able to delete records before you can get to them. RCFIND=OFF would avoid the RC 113 errors, but you shouldn’t resort to that. The 113s are telling you that the FIND statement is the issue. You should be using a READ statement to retrieve your 750k records.

Try using that descriptor in a READ logical. If the descriptor does not include all three (non-descriptor field) components, use a WHERE clause for them.

We used RCFIND and RCGET before, but did not prevent error 3113.

We will proceed toward using find with non-descriptors and will add RIAFTERUPDATE=OFF
to prevent other jobs impact.

to get benefit of NON-descriptor, you must use it with find statement.


Also, we schedule run time after ADA backup.

last, will change the code to read physical where non-descriptors = specific value, if we are experimenting same error or on/off error.

the main purpose of using non-descriptor to drop super descriptor and improve the process with non descriptor.

Also, we ran find with non-descriptor in production 3 time without issue, exept last time only.

Consider using a simple READ PHYSICAL WHERE [non-descriptor criteria here]. For 750k records to be returned, your performance (especially if MULTI-FETCH is used) may be better than using the FIND.

Any criteria can be used in the WHERE clause as it is evaluated by Natural, not ADABAS, so it doesn’t use the descriptor indexes.

Sorry to potentially disagree Doug.

Suppose we compare the super-desc FIND with the READ physical; both with a MultiFetch of 10.

With the FIND, that has 750k records, one should see 75k Adabas calls.

With the READ PHYSICAL, with 12 million records, one should see 1.2 million calls.

The difference, of over 1 million calls, should be far greater than the manipulation of the inverted table for the super-desc FIND (which of course will not occur for the READ PHYSICAL.

However, if the file is not in (or close to being in) super-desc order, the bouncing around of the FIND (when the ISN list does not reflect physical sequence) could flip the preferred method to READ PHYSICAL.

Ahmed is trying to eliminate the superdescriptor from the Adabas file for whatever reason. So my comparison is based on using FIND with non-descriptors and READ PHYSICAL. Using the FIND will result in Adabas reading (likely a read physical) the file to determine all the ISNs in the ISN list (writing that list to WORK), then re-reading the file for each ISN to return the data to the caller. Using a READ PHYSICAL (as Ralph shows in the “your FIND acts like” sample code) makes only one pass through the data.

We haven’t been told why they want to eliminate the superdescriptor. They may have found that the superdescriptor index is quite volatile, with many updates to the contents of the super and this program is the last or only program that uses the super. Eliminating the super in this case would improve the performance of the updates compared to the relatively infrequent (my assumption) batch run that he is now trying to optimize without using the superdescriptor.

Unlike Ralph, I don’t think FIND should be limited to a max retrieval of 100 records. My rough rule of thumb is that the find should retrieve less than 20% of the file - more than that then a READ LOGICAL or PHYSICAL will typically outperform the FIND. The 20% came from testing various files and accesses and seeing that many files had about 5 records per block on average, so the FIND needs to save more I/Os than will be used by the READ to be the preferred access method. This is just a rough rule - YMMV - but helps point out an important rule of optimization: know your data. In the case in question, I thought the overhead of the complex non-descriptor search would be significant enough to make the READ approach worth testing.

My question is, why getting an error 3113 while no delete or update or recycle ISNs during inquiry program running. subcode is zero for that error.

I would suggest running the utilities to verify your associator entries, particularly to check that your address converter is valid. Use ADACHK to do a check of the associator.

If the check utilities find no issues, then I’d recommend a support request to follow up on the Adabas 113 response code.

Have you tried running the job with exclusive update control of the file? That should eliminate the possibility of 3113’s. However,
it may be the case that this would not go over well with the persons responsible for job scheduling. As noted in earlier posts by Ralph and Doug and I, when you use non inverted descriptors, there is a time consuming process during which Adabas is developing an ISN list. Only after the ISN list has been completed will Adabas begin reading the records on the ISN list. This process would likely be the source of the 3113’s. You probably have an ISN on your list that has been deleted from the file. Okay, this is just a guess.

Eliminating the use of non descriptors leaves two approaches.

The FIND of a super descriptor might still produce a 3113. Same reason as above. With 750k records on the ISN list there is too much time for a record to be deleted before you get to that record on the ISN list.

That leaves the READ command which has two possibilities. If you do a READ PHYSICAL with a WHERE clause you should be safe from 3113’s. However, this will be quite time consuming.
The second possibility is a READ LOGICAL by the super descriptor. This should also be safe from 3113s. It should also be more efficient (reading 750k records rather than 12 million).

I do not know why you are interested in getting rid of the super. Perhaps you could explain.