Difference in line sequential file buffering between OCDS and SE.

Problem:

A customer reported a problem that after upgrading from OCDS 4.1.40 to SX 4.0 SP2, the application which writes to a line sequential file the records couldn't be seen - it's as if the buffer on the file is far too big.

In this particular problem a number of MQ interface programs write to logfiles. These interfaces allow the application to communicate with other systems on other servers. The interface programs are running in the background all day long and the only way to see if they are active/working is to check the logfiles which are updated every 15 seconds. On OCDS this worked, viz. the files got updated regularly. However with SX the logfiles are not being updated directly and it can be 30 minutes before the physical file is updated - which sounds like stuff is still in the buffer. Is there a way to get the old functionality back? I looked at SEQDATBUF, but the default is 4096, and the SX 5.0 docs say that the *minimum* is 4096, so I can't see a way of dropping that value.

Resolution:

The problem was that the file was being opened with the following statement :

               OPEN EXTEND INTAUDLOG

1: The file is opened exclusively. You can prove this by writing a simple program with the same SELECT and OPEN statements. In one session, run the first instance of the program and leave it waiting for input with the file still open. In another window, run the same program again. On the open it should get a 9/65 if the file is locked by the other process.

2: It would seem that under OCDS, even if files were open exclusively, the data was flushed to disk after every write operation. In SX however, we buffer the input for better performance only when the file is opened exclusively.

Therefore, the only way to open a line sequential file for sharing is to:

1: open it EXTEND

2: Specify the LOCK MODE MANUAL clause in the SELECT statement