This application was written over 15 years.
The environment is MF with latest NAT (4.2.5) and ADABAS.
One database (#10 for example) has the FUSER and another database (#20 for example) has all the applications’s files.
The code goes like this (simplified)
PGM1 reads a work file1
DECIDE on MONTH
include copycode READFILE ‘FILE1’
include copycode READFILE ‘FILE12’
This is copycode READFILE:
READ &1& MULTI-FETCH OF 1000 /* This file has more than 5M records
/* and must be read entirely
ACCEPT IF /* several conditions
WRITE WORKFILE 2
The batch job is abending with 3009, subcode 3, command S1 and pointing exactly to the line on PGM1 where the FETCH ‘PGM2’ takes places.
That indicates to me that NATURAL is doing a FIND on FUSER on database 10 to load PGM2, while PGM1 was reading FILE1 on database 20.
This production library has a parm TNAE (I believe) of 2. If I run the same job against a diferent library with TNAE of 3 (still same production environment, same FUSER and application’s files), the job rans fine.
My question is: Is there any rule that force you to create the FUSER on separate database? Performance? Security?
The DBA claims that the code is inneficiente, but the application itself does not require to access data across databases.
He insists that we must to use a 15yrs old “inhouse” solution of adding on PGM1, a callnat to a subp that does direct calls and close database 10 where the FUSER resides.
In 20+ years of SAG experience, I have never had to manage that and when I explained that to him, he said that most definetely every other installation that I have worked at, had the DBAs using some ADABAS and/or NATURAL userexit to manage, which it is exactly my point, where HIM the DBA should address, not the application.
Any feedback will be greatly appreciated.