Typing Logfiles

[Wanda Ravenscroft]

Good Morning,

I have a developer who's written a service using Cobol on OpenVMS. When this program was written in C and was a background process, the logfile could be typed out without a problem so the data could be viewed. Now that we've rewritten it in Cobol as a service that is picking up messages from a Websphere MQ Queue, we're having problems doing this. Options we've been given are to Close and then Open the file in Extend mode every so many records or reduce the disk cluster size so the allocated log file blocks will be filled sooner and can be typed.

Both of these options seem way too extreme. Does anybody have an easier solution as to how we may accomplish this?

Thoughts and advise are much appreciated.

Wanda

[Steven Schweda]

What's COBOL for (C's) fflush() or (RMS's)
$FLUSH?

[Wanda Ravenscroft]

I'm being told we have a SYS$FLUSH command. This was the format of the command:

CALL "SYS$FLUSH" USING BY VALUE THE_POINTER_TO_THE_RAB

[labadie_1 · Accepted solution]

Wanda

You may be interested by the trick detailed by John Gillings in this thread
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=629558

which lets you view the logfile.

[Dean McGorrill]

Hi Wanda,
It looks like your doing your own rms open. check the fab. check that fab$b_shr has fab$v_shrget set. look at the rms manual for $open, there may be others. look also at $update $write. if the C code did
its own open, check what settings it has
for rms bits. Hope this helps -Dean

[Robert Gezelter]

Wanda,

My leading suspect would be that the file is opened for exclusive use. Without looking at the code, it is hard to be precise.

Certainly, ensuring that the file is opened for sharing (admittedly with a single writer), and flushing the buffers on a periodic (timed) basis (timers and ASTs are excellent for this to simplify the logic, as I have mentioned in my DECUS presentations on using the AST facility), should allow use of the TYPE command to display the file (as you already do for batch jobs).

- Bob Gezelter, http://www.rlgsc.com

[Wanda Ravenscroft]

An OPEN/READ/SHARE/WRITE command has resolved the DCL part of our problem. I'm thinking the SYS$FLUSH will solve the COBOL part of our problem, but we don't have a good example to go by and the HELP isn't providing any good examples on how this is used. Can anybody provide an example on how we would go about using SYS$FLUSH?

Thanks

Wanda

[Dean McGorrill]

I don't know cobol, but in basic it would look something like...

status% = sys$flush(RAB by ref,[err by ref],[suc by ref])

where err and suc would be optional completion routines. status would have
the return status (r0) also located in
the rab, rab$l_sts. hope this helps!

[Hoff]

Haven't tried this specific case in COBOL, but the following is where I would dig...

If the log file is opened for shared read, you should not have to deal with the log flush operation -- this is very likely what the C code was doing. (Details of sharing output log files in C are over in the FAQ.) As for your case here, I'd probably look for and try something like OPEN OUTPUT mumble WITH LOCK ALLOWING READERS mumble -- or some such -- in your existing procedure division? When sharing is turned on, RMS deals also with the stuff in flight for you.

The brute-force option is to have the COBOL code call the (working) C code for its log I/O. That's certainly feasible.

[Richard J Maher]

Hi Wanda,

Just checking that: -
"When this program was written in C and was a background process,"

was the log file of which you speak the sys$output of the background process? (and now it's not?)

Otherwise, what did the C declaration look like?

Cheers Richard Maher

[John Gillings]

Wanda,

You don't need an explicit FLUSH, you just need to open the file from COBOL allowing shared write access. This is not the default. Something like:

OPEN OUTPUT yourfile ALLOWING WRITERS.

(not sure if "WITH LOCK" is required).

Now when another process opens the file with write intent, RMS will force your COBOL process to flush the output and update the EOF. The advantage is the output is always up to date when you want it, but work is only done when required, rather than a periodic flush, where you do more work than necessary, and still have a potential latency.

If you do want/need to perform direct RMS functions on COBOL files, you can obtain the RAB and/or FAB in a supported (but, obviously, not portable) manner using routines DCOB$RMS_CURRENT_RAB or DCOB$RMS_CURRENT_FAB. See Appendix E of the COBOL Reference Manual for details.

[Hein van den Heuvel]

Hi Wanda,

[ Fancy meeting you here !]
I'm 99% sure to be in STL early next week, so we can go over some optionss.

The easiest way to go really is to 'allowing readers' in Cobol, that shoudl be all that is needed. Be sure to apply deferred write otherwise you'll get an IO per display.

Cobol is likely to use non-record IO for noshared output, in which case the SYS$FLUSH trick you are considering will not work.

Still, if you want example of getting to a RAB from Cobol and using them froa SYS$FLUSH call then check out my directories on VRXDEV::[DIGITAL.HEIN]. There are probably examples floating around from last year (LOCK.COB? UNSHIP.COB?)

My Cobol trace tool (Bob H!) may help to see some gory details if needed.

Did you already try CONVERT/SHARE to see the data?

Cheers,
Hein.

[Wanda Ravenscroft]

Thank-you to everyone for your responses. Responses received by Hein van den Heuval and Labadie were the answers. We had to put an open/read/share/write in the DCL and we had to use the sys$flush in the Cobol. Additional thanks to Hein for stopping by while at the office and talking with us personally with some addtional suggestions and looking at what we were dealing with. Much appreciated.

Wanda