Reading Locked log file

[Daniel Wepplo]

Hi,

We have a VMS server running a machining cell in our facility (OpenVMS Alpha Version V8.3)

I’m interested in reading a log file that is recording all of the cell activities and interfacing it with the monitoring software we have on our other machines (windows based).

The problem is I can’t read the log file since it is being written to by an application.

I don’t have access to the source code for this application – it was written in Fortran in 1991 and the builder doesn’t have it anymore.

Is there some way to read this log file or pipe it to another file?

I did come across a listing in the HP FAQ for creating a backup of a locked file:
To examine log files that are in use, use the OpenVMS DCL command BACKUP/IGNORE=INTERLOCK to back them up to a text file, as in the following example:

$ BACKUP/IGNORE=INTERLOCK PWRK$LOGS:NETBIOS_DOROTHY.LOG; -
_$ PWRK$LOGS:NETBIOS_DOROTHY.TXT

The average log file has around 1500 events every 24 hours. I don’t need “real time” but I would like to limit the delay to a couple of minutes.

Is this the only way I can see the contents is forcing a backup copy?

If you have a solution and it will require more than an email I'm interested in hearing any proposals.

Thanks for any advice or help,

Dan

[Robert Gezelter]

Dan,

The conundrum of lost/missing sources can present challenges.

BACKUP/IGNORE=INTERLOCK is problematic. It will allow precisely the data that is currently on disk to be copied. This may or may not be valid. As a general rule, files are buffered, and BACKUP/IGNORE=INTERLOCK does precisely what it says, it ignore the interlocks. It does not, for example. force a buffer flush. For a variety of reasons, it is probably not the best of ideas to rely on /IGNORE=INTERLOCK in this context.

There are however, other ways that this particular problem can be solved. One such example involves writing the log file to a mailbox, where it can then be written to an actual disk file in a more friendly fashion, and perhaps displayed in a useful status display.

As usual, "the devil is in the details". There is likely a wealth of detail in this situation. Before trying a solution, I strongly a deep review of what is known about the code, perhaps by an outsider with experience in this context. I "have been there, and done that", it seems like a simple thing, but there can be complications. Experience can be a hard teacher, outside expertise may be able to avoid some of the potholes. [Disclosure: My firm does offer such services, as do several other frequent contributors to this forum].

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

[abrsvc]

My turn to agree with Bob.

There are many ways to attack this problem. First a few questions:

1) Was this application specifically written for your company or is it a commercial package?

2) Vendor/supplier of the product?

3) Do you only have the executable images or some type of installation package as well?

As Bob stated, there are ways to "trick" the application. I have a utility that will read a mailbox and perform various tasks. Relatively simple to do and easily modified. Can you give us an idea of the types of records being written into the logfile that you need to trace?

Disclosure: I too provide this type of service as do others here.
DansabrservicesATyahooDOTcom

[Hein van den Heuvel]

What is it worth to your company to solve this problem? Time, Money, Maintenance-nightmares, A little risky behavior?

Anyway... I can see some solutions.

1) IFF the application listens to a logical name for the output file, then you can define that to go to a mailbox and have a slave program relay the messages to a shared log.
Below my signature a simple MACRO program to to just that along with a simple fortran program I used to test this.

2) Use Attunity's relatively new RMS Change Data Capture. This allows you to 'tag' files by name, and have all change captured and made available through SQL (odbc, jdbc) queries on a staging area. That's not for free, but it opens a world of opportunities besides solving this problem. Contact Attunity, or me for details.

3) FORRTL intercept using John Gillings FAKE-RTL.

4) A hack I made to clone the file header, set the EOF, spawn copy to grab the avaiable data. This works, but only captures the full buffers which is probably not good enough.
It is useful/handy to get some insight in long running programs logs.

5) ANALYZE/SYSTEM or comparable tools to look directly in the program's RAB amd RMS buffers to distill the last written record from there. Not as hard as it sounds.

Summary of the problems with such uncooperative log....

One major problem with exclusive write - locked files is that
1) they only write to disk when the buffer is full.
This could be dozens, if not hundreds of message in your case
2) They do not update the file EOF
The effect of that is that BACK/IGNO=INTER will not copy any data even if it was written out.
(I've lobbied for and /IGNOR=EOF for BACKUP and DUMP but not loudly enough).
3) There are no locks to jiggle or ast to trigger to force RMS to write out.
4) When using Fortran, the RMS FAB and RABs are dynamically allocated and filled in by the RTL, so you can not simply poke a bit in the image to flip on sharing.


Hope this helps some,
Send Email for more help beyond the scope of this forum.
Regards,
Hein van den Heuvel ( at Gmail )


$ type MAILBOX_TO_FILE.MAR
.psect data, wrt, noexe
buf: .blkb 32*1024
infab: $FAB fnm=mailbox_input,dnm=sys$login:.dat,fac=get
inrab: $RAB fab=infab,usz=32000,ubf=buf
outfab: $FAB fnm=log_output,dnm=sys$login:.log,fac=put,shr=put,fop=dfw,rat=cr
outrab: $RAB fab=outfab,rbf=buf

.psect code, nowrt, exe
.entry start,0
$OPEN fab=infab
blbc r0,error
$CREATE fab=outfab
blbc r0,error
$CONNECT rab=inrab
blbc r0,error
$CONNECT rab=outrab
blbc r0,error
loop:
$GET rab=inrab
blbc r0,end
movw inrab+rab$w_rsz, outrab+rab$w_rsz
$PUT rab=outrab
blbc r0,error
brw loop
end:
cmpl r0,#RMS$_EOF
beql succes
error: ret
succes:
movl #1, r0
ret
.end start


$ type log.for
character*80 blah
do while(.true.)
write(6,*)'Some data: '
read(5,*) blah
write (1,*) blah
end do
end
$ for log
$ lin log
$ cre/mail blah
$ show dev blah
MBA44389: Online
$ define for001 blah
$ run log
Some data:
one
Some data:
two

... second session ...

$ macr MAILBOX_TO_FILE
$ link MAILBOX_TO_FILE
$ defi mailbox_input MBA44389:
$ spa/nowai/proc="MAILBOX_TO_FILE" run MAILBOX_TO_FILE
$ open/read/write/share=write x log_output.log
$ ! Optionally READ x records
$ clos x
$ type log_output.log
one
two

[John Gillings]

Dan,

Depending on how the application opens the file, as Hein has suggested, you may be able to redirect the output to a mailbox, which you can catch and do with whatever you like. That's what I'd try first.

/IGNORE=INTERLOCK might works, but you'll have all kinds of nasty issues trying to find the real end of file. You also have no control over how long the application or language RTL will hold its buffers.

Another possibility might be to try and patch the file attributes in the application image, forcing it to SHARE=WRITE. Without sources or map file, that will be tricky, but not impossible.

A FAKE_FORRTL could be used to hijack the OPEN statement and force SHARE=WRITE. That might be easier than patching. Alternative would be to hijack the WRITEs and send a secondary record stream to another file, or to a mailbox.

Into the future... for anyone writing code that writes to a log file, SHARE=WRITE is probably a good idea!

[Hein van den Heuvel]

>> Depending on how the application opens the file, as Hein has suggested, you may be able to redirect the output to a mailbox.

It worked for me. It would not work if the filename used is not translated. For example a simple my.log would thwart the plan.

How to check ? analyze/system.
SDA> SHOW PROC /CHAN ... look for channel for log file for example "00B0".
SDA> SHOW PROC /RMS=(FAB,RAB,BDBSUM)
Look for the FAB which has that CHANNEL value in the STV field.
It should have the Filename used in FNA/FNS.
In my example:
FNA: 7ADEB728 FNS: 06 DNA: 00000000 DNS: 00 File name: FOR001

The above can also be used to determine whether Fortran IO is used, or something else. For now I've been assuming native fortran IO was used, but that could be wrong.

>> /IGNORE=INTERLOCK might works, but you'll have all kinds of nasty issues trying to find the real end of file.

I don't think it will do you any good. Sorry.

>> You also have no control over how long the application or language RTL will hold its buffers.

With the same ANALYZE/SYSTEM, looking at the RAB and BDBSUM you can determine that Fortran does NOT buffer but hands directly to RMS where the record just sits in the buffer until that buffer is full or the process stoptted. With the RFA (VBN) from the RAB and the BDBSUM info one can readily confirm.


>> Another possibility might be to try and patch the file attributes in the application image, forcing it to SHARE=WRITE.

Again, no can do at the RMS level.
Also, the Open could be implied. No call.
And the fortran open option are presented as a list, almost like a TLV. The list is static in psect $LITERAL$, but it would be tricky to inject a fresh option if not already present.

>> A FAKE_FORRTL could be used to hijack the OPEN statement and force SHARE=WRITE.

IF open is used.

One may have to intercept DFOR$WRITE_SEQ_LIS and look for the right LUN.

IF Fortran IO is used for the log file.

>> That might be easier than patching. Alternative would be to hijack the WRITEs and send a secondary record stream to another file, or to a mailbox.

Yes.

>> Into the future... for anyone writing code that writes to a log file, SHARE=WRITE is probably a good idea!

Yes. With Deferred Write (Fortran Default) the (performance) price is small and the functional change 'priceless'.

Attunity's RMS-CDC would be neat solution, but too big a hammer. I've been lobbying them softly for make just the RMS intercept part avialable.
I'll use this example as an other reason.
( That is... if RMS IO is indeed used :-)

fwiw,
Hein

[labadie_1]

Dumb question, have you tried a

$ set output_rate=00:00:05
or such before launching your Fortran Program ?

[John Gillings]

Gerard,

> $ set output_rate=00:00:05

That will only work if the process is running in a batch job, and the output sent to SYS$OUTPUT (ie: written to the batch log file). Given the log in question is NOSHARE, I don't believe it's a batch log.

[John Gillings]

Dan,

Another (slim?) possibility... I don't have a FORTRAN compiler to check. Sometimes you can use a process permanent shared file to establish sharing. Again it depends on how your program opens its output file. If it's a logical name, this might work.

Assuming Hein's example, try:

$ OPEN/WRITE/SHARE=WRITE FOR001 LOGFILE.LOG
$ RUN LOG

if the program hooks onto the PPF, it will be writing to LOGFILE.LOG, which DCL has established as shareable.

Now, from your other process, you can force an update with:

$ OPEN/APPEND/SHARE=WRITE LOG LOGFILE.LOG
$ CLOSE LOG

The file can now be read up to the EOF at the time of the OPEN/APPEND. Repeat the OPEN and CLOSE each time you want the file up to date.

Even if your program specifies a complete file specification, you might be able to patch the image to turn it into a logical name. For example, suppose the image contains the filename as a constant string:

'SOMEDEV:[SOMEDIR]SOMEFILE.TYPE'

You could patch the image, replacing file specification punctuation with (say) "_" to make it look like a logical name. The above would become:

'SOMEDEV__SOMEDIR_SOMEFILE_TYPE'

Your PPF OPEN is then:

$ OPEN/WRITE/SHARE=WRITE SOMEDEV__SOMEDIR_SOMEFILE_TYPE SOMEDEV:[SOMEDIR]SOMEFILE.TYPE

Strings like this are usually relatively easy to identify and patch in an image file, since you're not changing string lengths.

[John McL]

Dan, I suggest that you bite the bullet and replace the software. Having software but no source is a business risk. Potentially your company is using machines that are more powerful than necessary because you have no means of optimising the code, taking advantage of new concepts or making additions that become mandatory.

For the first I'm thinking particularly of alignment faults but the same applies to compiler optimisations for new hardware. For the second I'm thinking not just of linking to your monitoring software but to any system that might make use of it. For the third it might be any legislation at all that impacts on the work.

Depending on what you are doing, tools like the memory-resident database + powerful API's from Vista Control System might be the kind of thing to look at. It's advantage in your situation is that you just have to sort out the data input system and the things that will make use of the data, in other words development should be fast. (NB. There's probably other companies that also provide similar tools or even off-the-shelf software that would suit your situation.)

[labadie_1]

John (Gillings)

I love your trick

replace
'SOMEDEV:[SOMEDIR]SOMEFILE.TYPE'
with
'SOMEDEV__SOMEDIR_SOMEFILE_TYPE'

You get rid of the string length problem when patching

:-)

[Tom Wade_1]

Take a look at RALF (Restricted Access to Locked Files). RALF is a set of simple routines that allow you to read a file that has been opened for write exclusively by another process. It comes with a PEEK program that is essentially a TYPE/OVERRIDE=INTERLOCK command, or you can use the routines from your own application.

We've used this approach for reading PMDF message files while they were being processed (RMS locked by the channel program). It might work for your log files.

www.tomwade.eu/software

[Hein van den Heuvel]

Tom, Thanks for posting RALF.
That should be handy for some applications.

Now RALF works as good, and as bad, as BACK/IGNO=INTERLOCK would work for a given file right, as is just uses FIB$V_NOLOCK in FIB$L_ACCTL right?

Notably it honors EOF, which in my experience it NOT updated, and still 0, more often than not for those locked files, so folks should not get their hopes up too high.
Just check with DUMP/HEAD/BLOC=COUNT=0
- EBK/FFB?
- Mapping pointers?

I suspect that what I wrote earlier in this topic still holds for RALF:

One major problem with exclusive write - locked files is that
1) they only write to disk when the buffer is full.
This could be dozens, if not hundreds of message in your case
2) They do not update the file EOF
The effect of that is that BACK/IGNO=INTER will not copy any data even if it was written out.
(I've lobbied for and /IGNOR=EOF for BACKUP and DUMP but not loudly enough).
3) There are no locks to jiggle or ast to trigger to force RMS to write out.

Thanks!
Hein

[Hoff]

RMS has arguably been in feature-stasis for probably a dozen years, and maybe longer. As good as it was and is, other databases and tools have advanced in those years.

In particular, RMS is not competitive with a modern database, and it contains no assists to allow an application to better coordinate on-line access from archiving tools such as BACKUP.

If you need reliable online backup of your application data or your log contents, then you must use a database with these capabilities, or rework or recode your application to deal with the various unfortunate limitations of RMS.

This can include having the application open the file for shared access (which is discussed in the OpenVMS FAQ and there are examples of this shared-access posted at various sites), and for better on-line backups and related, something akin to that Attunity RMS Change Data Capture interception product, more extensive work in the application, or a migration to RMS Journaling, or a move to a modern database.

Using a SQL or NoSQL database here will resolve this case, though that is not going to be easy nor pretty for an application that is currently using language-specific I/O (which uses RMS) nor applications which call directly into RMS.

As an alternative approach to overriding access into log files, it's also potentially possible to move the logs off of VMS and onto a server that can provide better access; to send the data (via syslog or other mechanisms) to a distributed log. (VMS doesn't support syslog, but there are ports around.) This too requires some application rework.

[Tom Wade_1]

>Now RALF works as good, and as bad, as >BACK/IGNO=INTERLOCK would work for a given >file right, as is just uses FIB$V_NOLOCK in >FIB$L_ACCTL right?

Hein is quite correct, and yes, it would offer the same amount of success as the backup command with respect to EOF.

In the case of PMDF messages it worked very well, as these files (one file per message) would have been created and closed earlier, and locked again when the channel program started processing them. For files locked while they are being created, it depends on how often they are flushed. The other advantage RALF might offer the OP is that it is implemented as an API which would allow it to be integrated into the monitor application.