Reading Locked log file

[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.