Garbage in - garbage out

[Kevin Swanner]

I have a situation where the same piece of COBOL code, running on 4 different boxes (HP-UX 11.0), fails on 2 and succeeds on 2. The code reads from a large file and writes to smaller files. When the code fails, it is reading garbage and writing garbage. The kernel parameter, hpux_aes_override, on the failing boxes =0; on the successful boxes =1. When the parameter on one failing box was set to 1, the code failed...then a day or two later ran fine. The parm was set back to 0. The code ran fine.

Is this the kernel parameter I should be looking at? Is there something else that could be causing the problem? There are no system or COBOL error messages.

[Robert-Jan Goossens]

Hi Kevin,
hpux_aes_override

This value is part of the OSF/AES compliance. It controls directory creation on automounted disk drives. We recommend hpux_aes_override be set to 1. If this value is not set, you may see the following error message:

mkdir: cannot create /design/ram: Read-only file system.

This system parameter cannot be set using SAM. The kernel must be manually created. It is best to modify the other parameters with SAM first and then change this parameter second, otherwise SAM will override your 'unsupported' value with the default.
Robert-Jan.

ps
http://www.uwsg.iu.edu/hp/hpux-tune.html#hpuxaes

[A. Clay Stephenson]

I think you are looking in the wrong place. If this is a kernel parameter, how does it know to pick on just your COBOL application? I strongly suspect the problem lies in the code itself or in a library. Are all the boxes at the same patch level? Latest cumulative COBOL patches? Identical shared libraries?

I would make sure that all the compile and run-time warnings are enabled and turn off all optimization. These steps may help you to zero in on the problem.

[Martin Johnson]

Also check the patch levels on the boxes, especially those pertain to libraries.

HTH
Marty