Question OUTPUT TO../PUT Statement

[Kalan]

When an output stream is directed to a file with the OUTPUT statement, and characters are written to the stream with the PUT statement, the output file is created but some or all of the data is missing from the file.

UNBUFFERED option when the stream is opened for output. This will force each individual byte to be written to the file immediately. Even though its not writing the output to file. Also I have added an OUTPUT CLOSE statement to the code, after all statements that write to the output file. Closing the output stream at the earliest opportunity force any remaining data in the output buffer to be written to the file and frees up the associated resources. But still its failing to write the output to file. There is no error reported in appserver log.

Could you pls advice me the reason of possibilities on failure case?

Thanks,
Alan

 

[TheMadDBA]

Are you using a STREAM or just the default stream? Do you have multiple processes using the same output file name?

 

[Kalan]

Hi MDBA, Thanks, it was just only one single stream that I defined DEFINE STREAM stLog. and used this OUTPUT STREAM stLog. No other streams exists and shared this STREAM stLog output filename.

 

[TheMadDBA]

Are you using PUT STREAM stLog ? Other than that or the code not actually running those PUT lines nothing should stop writing to the file (assuming the appserver user has write permissions to that file/dir).

UNBUFFERED will slow things down but allow you to see the file as it is written instead of in chunks (1k-8K depending on OS). Once you close the output all data is written with either option.

Could you be overwriting the same file over and over again and not using APPEND?

 

[Kalan]

Hi MDBA, I was using APPEND, however system has created the file but not writing any content over there. More over, I was using session:temp-directory to create the output file in temp directory location, so I believe appserver user should have the permission to that file/dir. Thanks for your prompt reply.

 

[TheMadDBA]

So one of a few things is happening...

1) You aren't specifying the stream name on the PUT
2) Your code isn't actually executing certain lines of code that you think it is
3) The data in character fields is longer than the default format and it is being truncated (to fix this you need to use put unformatted or fix the format strings).

Good luck

 

[TomBascom]

Of course a lot of time wasted guessing could be saved by a simple "show us the code"....

Reading carefully I don't think that Kalan has answered "Do you have multiple processes using the same output file name?" He does reference this being a log file for app server based code. To me this positively screams that multiple processes are writing to the log file. And that will indeed result in missing data. And garbled lines.

Attempting to write shared log files with "OUTPUT TO" is an exercise in frustration and futility because Progress does not have any sort of "line buffered" atomic operation. You have unbuffered (one character at a time) and buffered (block size is some number of kilobytes) to pick from. Neither works for the purpose.

 

[Kalan]

Hi Tom, Yes, I confirm that multiple processes are not using the same file. Appserver log I mean that we specify the log file in progress explorer to report the errors. By the way, Is there any reason that if the program is run on batch job queue then there might be the issue not writing the messages into output file? My apologies due to length of code I am unable to show it here. - Thanks.

 

[TomBascom]

You did not say anything about appserver logs. You said "... so I believe appserver user should have the permission to that file/dir."

If you are actually writing to the appserver's log then you are begging for trouble because the appserver is also writing to that log.

However I doubt that. What is the name of the file that you are writing to?

 

[Cringer]

Judging by the lack of solution, and the raft of questions, I suspect it might be a good idea for you to take the time to help us to help you please Kalan. You say your code is too long to post. Fair enough. Can you take some time to simplify it and post the simplified code?

 

[Kalan]

Many thanks guys, I will simplify the code to highlight it here soon. Thanks Tom for reminding that appserver log process also using the same file.

 

[TomBascom]

The appserver processes do use a particular log file.

BUT IT SHOULD NOT BE "the same" as what your programs are using. That is one of the reasons why I asked you the name of your log file.

I repeat my question:

What is the name of the file that you are writing to?

 

[Kalan]

Hi Tom, The name of the log file I write to CallLog1234<DATETIMESTAMP>.TXT. BTW, If the program runs in batch job, will it make any hassle to write into log file?

 

[TomBascom]

Is "CallLog1234" really the base name? That looks suspiciously faked.

What is the granularity of <DATETIMESTAMP> ? Days? Hours? Minutes? Seconds? Milliseconds?

The good news is that this is not the app server log file. So you are not messing that up.

The not so good news is that this is not a unique file name. Using a datetimestamp does not ensure that two processes do not try to simultaneously write to it. In an app server environment that is certainly possible.

Running as a batch job makes no difference.

 

[Kalan]

Hi Tom, <DATETIMESTAMP> meant for HHMMSS. Since I create this log file for my support tasks I use the standard CallLog<CallNumber>. Thanks for confirming that batch job will not make any difference on this.

 

[Kalan]

Hi Tom, <DATETIMESTAMP> meant for HHMMSS. Since I create this log file for my support tasks I use the standard CallLog<CallNumber>. Thanks for confirming that batch job will not make any difference on this.

 

[TomBascom]

You have code running in an appserver context writing to a potentially shared file (there is nothing that ensures that this file name is unique) . You should expect that output will be at least occasionally garbled.