Need parameters for LIB$SYS_TRNLOG

[abrsvc]

This is an old piece of code that is not documented and has latent problems. Does anyone happen to have the old info on this LIB$ call around? I think that this went away either in V4 or V5 of VMS. I just need to know the parameters.

Thanks,
Dan

[Hoff · Accepted solution]

Google is your friend.

http://zinser.no-ip.info/www/eng/vms/qaa/ltrnlog.htmlx

[Hein van den Heuvel]

Dan,

You may also want to read up on SYS$TRNLOG itself:

http://odl.sysworks.biz/disk$cddoc03jul11/decw$book/d32va205.p46.decw$book#627


Content page for the VMS Version 5.4 "VMS Obsolete Features Manual, August 1990"
http://odl.sysworks.biz/disk$cddoc03jul11/decw$book/d32va205.decw$book

Hein.

[abrsvc]

Thanks guys. Thats what I needed. I have the V3 doc set on fiche, but it is not easily accessible at the moment. The link is exactly what I needed.

Dan

[abrsvc]

Info found.

[Craig A Berry]

And since one would hate to be using an outdated version of the obsolete features manual, see also:

http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_obsolete_feat.pdf

available with all of the other archived manuals via:

http://h71000.www7.hp.com/doc/archived.html

[RBrown_1]

I checked the Obsolete Features manual as well, and found that while it does have SYS$TRNLOG, it does *not* have LIB$SYS_TRNLOG.

The entry for SYS$TRNLOG has a strong recommendation to replace SYS$TRNLOG whereever you find it.

[Hoff]

Some years ago, the obsolete features manual was itself declared (and I'm not making this up) obsolete.

[RBrown_1]

Judging by the title page, it was made obsolete before V6.1.

[John Gillings]

$TRNLOG was made obsolete at the introduction of the more general heirarchical logical name table structures with V4.0 sometime around 1984. Prior to that there were only SYSTEM, GROUP and PROCESS logical name tables.

The issue with $TRNLOG and derivatives is they may not behave the way you expect, as they will ignore anything not in SYSTEM, GROUP or PROCESS tables, and will not honour precedence changes defined by LNM$FILE_DEV. (By default the TRNLOG PROCESS table is implemented as a search list LNM$PROCESS, LNM$JOB)

Furthermore, the $TRNLOG is now implemented using the new LNM$ tables, so there may be cases where it doesn't conform 100% with the old behaviour (for example, "an old piece of code that is not documented and has latent problems."? ;-)

See:

$ SHOW LOGICAL/TABLE=LNM$SYSTEM_TABLE TRNLOG*

(LNM$SYSTEM_DIRECTORY)

"TRNLOG$_GROUP_SYSTEM" = "LOG$GROUP"
= "LOG$SYSTEM"
"TRNLOG$_PROCESS_GROUP" = "LOG$PROCESS"
= "LOG$GROUP"
"TRNLOG$_PROCESS_GROUP_SYSTEM" = "LOG$PROCESS"
= "LOG$GROUP"
= "LOG$SYSTEM"
"TRNLOG$_PROCESS_SYSTEM" = "LOG$PROCESS"
= "LOG$SYSTEM"

$ SHOW LOGICAL/TABLE=* LOG$*

(LNM$SYSTEM_DIRECTORY)

"LOG$GROUP" = "LNM$GROUP"
"LOG$PROCESS" = "LNM$PROCESS"
= "LNM$JOB"
"LOG$SYSTEM" = "LNM$SYSTEM"

These are the hacks used to replicate old behaviour. As you can see, the old fixed tables are defined in terms of LNM$ logical name tables. Theoretically you can mess with the LOG$ definitions to adjust how $TRNLOG translations work. Definitely not my recommendation!

Realistically, the only reason to still have $TRNLOG around is for binary images for which the code has been lost. Anything you have source for should be updated to use $TRNLNM, which is much more flexible, general and reliable.