SET HOST /LOG logfile

[Michael Moroney]

Quick question: Is there an equivalent to SET HOST 0/LOG=whatever.log that allows someone to examine "whatever.log" by typing it while the SET HOST session is still active? Also, is there any way for an application to get a logged terminal session by assigning a channel to a terminal and doing $QIOs to it. This is similar to SET HOST/LOG but initiated differently.

[Hoff]

1: Probably easier to use a client-side widget such as the screen utility or VCS. Alternatively, there are widgets such as peek and spy that can probably be pressed into service.

2: Your host I/O is aimed away from the host and toward the terminal, and not in toward the host from the terminal. Which means something akin to a pseudo-terminal would be one way to do this.

Poke around and there are some other screen-scraping tools around.

I recall that somebody posted one such tool in response to an other recent thread; I'd suggested pseudo-terminals in that thread, so you have a search target.

[Hein van den Heuvel]

I suspect you would have to roll your own using the Psuedo Terminal Driver.
A good starting point would be: SYS$COMMON:[SYSHLP.EXAMPLES]ALPHA_LOGGER.C
There may well be others out there.

SET HOST/LOG is RTPAD opening a log file non-shared. No RMS locks to poke to get it to flush, just a file system lock.
For RMS it uses the default settings which are often 16KB buffers, and it does not have a (timer based) flush. So the process might never write to disk untill the end.

So if you know you want to 'see' the data on the disk, then you may want to issue SET RMS/BLOCK=1. This will force an IO for every 512 bytes of data. You can then uses DUMP (in a round-about-way to find the LBN's) to see the data on the disk.

I own a tool which can 'clone' the locked file into an other file for a sneak peak, but it can only clone what is out there, not what is still in the process memory.

For desperate, or just one-off support inverstigation, cases you could of course also use SDA to directly peak into the process RMS memory.
This is not too too hard.
$ANALYZE/SYSTEM
SDA> SET PROC
SDA> SHOW PROC/RMS=(RAB,BDBSUM)

The RBF/RSZ in the RAB will describe the last record put out there.

The RFA in the RFA will describe the VBN + byte-offset where to expect the last data in the blcok buffer.

The VBN field in the BDBSUM will indicate the block range for the buffer. The ADDR field will point to the data in memory.

SDA>examine ;
... enjoy!


Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Michael Moroney]

Thanks. This will be for an ongoing need, so I need more than SDA. Pseudoterminals appear to be what I need, and some searching has revealed some code that can be adapted, and it has the icky pseudoterminal portion of the code already written.

What I will come up with is something that sits between a pseudoterminal and a (real) terminal that acts very much like SET HOST/LOG 0, except the log file will be sharable, it will work both ways (that is, one can open a channel to the FTAx: device and data written to it will be logged as well as being able to "log in" on the FTAx: pseudoterm), and, of course, no need for network stuff. Hein's SET RMS/BLOCK=1 may be a stopgap if CONVERT/SHARE or BACKUP/IGNORE=INTERLOCK can read the SET HOST log file.

[Hein van den Heuvel]

>> if CONVERT/SHARE or BACKUP/IGNORE=INTERLOCK can read the SET HOST log file.

Sorry, no go.
CONVERT will refuse to open the file.
BACKUP will honor the EOF mark, which is at 0.
BACKUP badly needs an /IGNORE=EOF, but suggestions to that extent have not been folowed up. I'll Email you something, but O do not want to send it to 'the world' (that's a joke just for Mike).

Hein.

[John Gillings]

Michael,

First question, yes, there is a way, but it's a bit klunky - use process permanent files.

$ OPEN/WRITE/SHARE mylog whatever.log
$ SET HOST 0/LOG=mylog

Output from the session is now written to the log file "whatever.log" as shared access.

As Hein says, the EOF won't be updated unless necessary, so TYPE or even CONVERT/SHARE don't help, BUT you can update the EOF with the sequence:

$ OPEN/APPEND/SHARE tmp whatever.log
$ CLOSE tmp

from any process with appropriate access to the file. This includes the session being logged. (but it gets a bit confusing if you TYPE the log file - it's also exponential growth, so be careful!).


The EOF is now up to date, and commands like TYPE and SEARCH will work up to that point in time. The EOF will be set at the end of the CLOSE, so if you do it from the session being logged, the CLOSE command will be visible.

Obviously this isn't something you can do after the session has started, and you need a cooperative target.


Second question... you can't capture the activity on a terminal with ordinary $QIOs. Although you can open a channel to a terminal with SHARE privilege, an I/O operation will only go to one destination. So if you read from the terminal, you will "steal" input from the user, preventing it from going to the logged in process.

There are various utilities around for capturing screen sessions. They have names like "SPY" or "WATCH". They do stuff at driver level to intercept I/O. They're also notorious for crashing systems, so be careful. You may find freeware, but I think there are also some commercial offerings.

[Wim Van den Wyngaert]

Almost 20 years ago there used to be a product called VIDEO. It allowed to log all activity and also to replay it (as if recorded with a video). You could also take control of the terminal. Don't know what if it still exists.

Wim

[Jess Goodman]

After you have the log file open read-shared using John Gillings' method:

$ OPEN/WRITE/SHARE mylog whatever.log
$ SET HOST 0/LOG=mylog

Then you can use a DCL READ/WRITE loop to "type" out the file without first setting the file's EOF.

Attached is SHARED_TYPE.COM, a DCL procedure I wrote for this purpose almost 20 years ago.
It will type out data from a read-shared file even if the EOF still shows as 0.

[John Gillings]

re: Jess,

>Then you can use a DCL READ/WRITE loop
>to "type" out the file without first
>setting the file's EOF.

That's the slow way! It's sufficient to OPEN/APPEND/SHARE then CLOSE the file.

[Hoff]

Ten seconds with a hot soldering iron, anyone?

Tapping a serial line is trivial, and monitors are around if you're not inclined to solder your own T.