We have a problem that cropped up: our developers suddenly could not “stow” their programs in adabas. We did find the checkpoint file was close to being full and refreshed it, but that didn’t resolve the problem.
Here’s what we’ve narrowed it down to;
If anyone tries to perform a stow one particular program, it simply hangs there, no errors returned, nothing. And while it is hung nobody else can stow in any of the databases…we have to kill the hung processes’ pid to get going again. Any one seen this type of behaviour before? Any help would be appreciated.
Normally a ADADBM DB=… DELCP=… should be used for this. But I don’t think that this is the cause of the error.
A few questions:
A SAVE of a program works, doesn’t it?
Do you use predict? I would check, if the predict-file is OK.
Natural programs are not stowed in an Adabas database on OpenSystems, they are kept in the file system !
If Pre-dict or Natural Security are involved, issue an ADAOPR DI=HQ and DI=UQ_FULL to see what this particular user is doing.
You’re right, we tested that a save would work, but a cat or stow wouldn’t. We don’t use Predict. It struck me as being odd that one hungup stow process would stop everyone from stowing - oh, and we did get an “internal error 998” message out of it.
But your explanation “save works but cat doesn’t” sounds like a predict error. If predict is installed and a stow/cat is done, the so-called XREF-information is written into the predict-file (which is located in ADABAS).
For a quick test, you can turn this option off by typing “XREF OFF” on the Natural command line. Then stow an object and see what happens. Maybe Natural wants to store into a predict-file that is corrupt or doesn’t exist…
Try checking the FILEDIR.SAG and the GP permissions inside your fuser. If the user doesn’t have write permissions you’ll receive a 82.