Using C fgetpos and fsetpos on freopen'ed stdout

[John McL]

We would like to be able to read part of a log file where we've used freopen to redirect stdout into that log file. I've tried fgetpos to save position within the file and later fsetpos to reposition to there prior to reading all that's been written between these two calls. What I'm reading is not what was written and I can't find a problem with the code so it's time to check some assumptions.
Question: Is it possible to use these functions - fgetpos and fsetpos - on stdout when stdout has been redirected to a file?

[Hoff]

I don't use the position-setting calls. That written, they should work as documented, though C I/O and Unix I/O and OpenVMS I/O don't always line up.

There's an example program underneath the fgetpos entry in the C RTL help text.

These calls tend to operate best on Stream LF files, for instance. Confirm your file formats; the native RMS sequential file formats and the C formats do have some implementation differences, and don't always mix.

There's a library of C code that's tied into RMS here, which is the approach I usually use here:

http://labs.hoffmanlabs.com/node/1260

And I tend to toss the logging I/O directly at a log file rather than using redirection; makes things easier.

Check your ECOs, and your OpenVMS versions. Older versions had more problems here.

And on newer OpenVMS versions, there's a small forest of Unix compatibility logical name knobs that can need to be set, or set differently. Depending on what sort of Unix compatibility you need.

[John McL]

I got some fresh eyes on my code. We tried a few alternatives and found that the trick is to ensure that the freopen uses access mode "w+" (i.e. read and write).

Hoff I'll still have a good read of your notes about this IO.

I have say that the errors returned from C are not always very enlightening, but I guess there's not much that HP can do about that short of adding an argument to every function so that extended error codes can be returned.

[John Gillings]

John,

I have code that tracks many log files, using RFAs to remember where it was up to. All direct calls to RMS services (rather than trusting a language RTL to do what I really mean).

You must always open the file shared with update intent, even though you're only going to read. That forces RMS to ask the writer to flush buffers and update the EOF. In DCL it looks like this:

$ OPEN/APPEND/SHARE log targetfile
$ CLOSE log

This isn't necessary for process permanent, primary output files (like log files for batch processes) because they're subject to flushes controlled by SET OUTPUT_RATE.