Hi All,
Long time reader but first time needer. We have an issue that is filling up our log.bshell6.1 file nightly when a batch job tries to create invoices. It encounters an include function with an old style db.eq command that generates an error in the log. The script for the function has not changed since 1993 - tfgld4001 is the script. The table being accessed is tfgld004 and I see that this table had a new field added to it at on Dec 27, 2000. If I access this table with a normal select there is no error generated. Only the db.eq creates the error but does not prevent to continuation of the script in debug. My dBA seems to think that the error generation is new. I suspect this error has been ongoing for a long time. There is no way for us to know for sure without trying to get him to look at old log.bshell6.1 files from tape. Do you think a simple wide open convert to runtime (we have a solid test system to play with where this issue also exists) might solve the issue? Any suggestions would be greatly appreciated.:)
I have attached the error and the part of the script causing the issue.
Regards to all.

U can CRDD for table tfgld004 only and c if it works . It says error 2 meaning does not exist . Does the value of tfgld004 records become current or db.unbind statement gets executed .

Also porting set needs to be upgraded.

U can CRDD for table tfgld004 only and c if it works . It says error 2 meaning does not exist . Does the value of tfgld004 records become current or db.unbind statement gets executed .

Also porting set needs to be upgraded.

Hello Hitesh,
Thanks for your reply. Upon executing the db.eq the code generates an error message to the log.bshell6.1 and the code then jumps out of the 'if' clause and executes a second db.unbind statement on line 53 (as seen in one of the images I provided) There is a value in igld4001.tp.gld004 of 541824152 so I presume that the record has become current. Note that it is the only record in this table. I also deleted and inserted a new record with the same data that was previously stored there. It gave the same results. I will ask our admin to CRDD on that table alone on the test box to see what happens.

In such a case is it's the porting set issue . If u upgrade it, it may go .

If there is really an error , value of e after executing db.eq will become non-zero .

The only new field that got added to table tfgld004 is tfgld004.taut - Transaction type for Automatic Balancing. I guess if you can add this field to your table and do a CRDD, the error should go off.

Field: taut
pos: 294
type: str
len: 3
#:1

Regards,
Rajasekhar