Home The Company Publications Products Links Tips

Tips, Tricks, and Techniques

Last update: 30 April 2004

Response Code 44 during update (NAT3044)

Question from Robert Lee, F&A, City of Houston

I added several new fields and superdescriptors in one of our adabas file. I tested this file with simple Natural program using READ and DISPLAY in report mode. It worked o.k.. After I inserted UPDATE SAME next to the DISPLAY statement. The error 3044 showed up and pointed to the UPDATE statement. I checked the DDM and FDT with sysdic. There are no difference.

Answer from Kevin E. Yaussi, Kansas Farm Bureau

  1. (Least likely case). If you use synonyms in your DDM (i.e. ADABAS field "AA" is named "CAR" and also "AUTO") and you reference both of those field names in your program, the format buffer will contain ADABAS field "AA" twice (which is OK if you're just reading). However, a update format buffer that contains the same ADABAS field name more than once is invalid and will generate rsp. 44.

  2. (My guess is this one). Your DISPLAY statement contains the name of a super-de. Once again, this is fine if you're just reading the file. However, a update format buffer that contains an ADABAS field name for a super-de is a no-no (since you can't update the super-de directly) and will generate rsp. 44.

As you might guess, we've run into this before. Hope this helps.

Wayne Campos, Data Administrator, Citizens Utilities - Public Services Sector, wrote

I think that the problem is either

  1. a field is apprearing more than once in your ADABAS Format Buffer (This is okay for reads but not for updates.) or
  2. the format buffer contains a superfield.

Jerry Austin wrote

Natural allows you to include a superdescriptor in the view of your file in structured mode or to refer to it in reporting mode DISPLAY statements, etc., (this was not true earlier), but only for read access, not updating.

I'd just omit the SAME and include the specific fields to be updated in your UPDATE statement. ADABAS will rebuild the superdescriptor from the component fields if any of them are modified.

To use UPDATE SAME, you'd have to do a GET, move the modified values to the fields with a reference to the GET line number, then UPDATE SAME referring again to the GET.

A.A.Costanza, DBA, Newsday, Melville, NY wrote

Since the NAT3044 points to format buffer, I would check to see if there are duplicate variable names which when using SYNONYM's in Predict sometimes may happen. Look for duplicate DB names when doing a LIST FILE from Natural. Another possibility could be how the combination of READ and DISPLAY statements generate the format buffer (STARTING FROM ... TO...).

Natural may be creating a conditonal format buffer which is not valid for an UPDATE command.

Robert Lee's Solution

Thanks to all of the people assisted on this issue. You guys pointed out the right place. The program did display one superdescriptor. After I removed the super from the display statement, it works. I assumed all fields were data field when programmer asked my help on his program. I thought it might be file problem. This really scared me. Because I implemented the file modification in production already. This file has 20 million records. Thanks again!

Top Page

Back to NATURAL Tips, Tricks, Techniques -- Overview