Is it possible to detect of COMO or DIVERT.OUT are redirecting output from within code?

I have some utilities that utilise COMO and/or DIVERT.OUT to  capture screen output for logging and processing.

I am working on another utility that I want to run these utilities and capturing the screen output they create, for logging purposes.

What I am hoping to find is a mechanism by which I can detect if COMO or DIVERT.OUT are actively redirecting output so I can temporarily direct output somewhere else and then restore it's output redirection.

Has anyone had luck doing this sort of output gymnastics just using native functions, or any had-crafted functions for that matter?

Hi Gregor,

You could use PORT.STATUS PID 9999 FILEMAP to see if they're open (I think it needs to be from the uv account with su privileges) or lsof/Linux (but that may not show files in the rotating file pool) or you could possibly monitor real-time file changes to your output files to check if they're being actively updated. Maybe using Python (watchdog) , Nodejs (fs.watchfile) or directly using an OS library utility (eg inotify/FileSystemWatcher).

Hi Stuart

Those are all possibilities, but I'm not sure they would be suitable for use by the PID that has started the COMO recording (their output being included into the COMO recording).

The scenario that I am needing to deal with is this:

Main line program "A" calls subroutine "A"

Subroutine "A" runs "COMO ON {id}" to start a new COMO recording. It then does it's processing, executes program "B" and does more processing that produces output. It then runs "COMO OFF" to close the recording of it's activities.

In program "B" part of the logic needs to use "DIVERT.OUT ON" to capture TCL or OS level activity to an item in a different file.

As soon as the "DIVERT.OUT" command is run the COMO recording for subroutine "A" is stopped. When the "DIVERT.OUT OFF" command is run by program "B" there is no resumption of the subroutine "A" COMO recording, meaning that subroutine "A" loses all it's output from the execute of program "B" onwards.

To solve this will require the ability to detect the presence of the active COMO/DIVERT.OUT recording within program "B" and resume it once program "B"'s DIVERT.OUT ON-OFF block has completed.

A SYSTEM(nn) value with the account, file, Id and options (tty on/off, file on/off) of the current DIVERT.OUT activity would be ideal.

I think I will have to create a wrapper for this myself.

Gregor,

Sounds like you could just change sub A to use DIVERT.OUT instead of COMO? Then you can restart recording after sub B.

Cheers

The issue is that it is not possible to detect when a recording is active.

So without having that knowledge it becomes very messy to know IF a previously active recording needs to be resumed.

As it seems I will have to make code changes I think there is value in providing a routine that manages the detection, suspension and resumption of existing recordings automatically. that way I don't need to re-create the resumption logic in every routine that starts a COMO and calls or executes other programs.

I have some utilities that utilise COMO and/or DIVERT.OUT to  capture screen output for logging and processing.

I am working on another utility that I want to run these utilities and capturing the screen output they create, for logging purposes.

What I am hoping to find is a mechanism by which I can detect if COMO or DIVERT.OUT are actively redirecting output so I can temporarily direct output somewhere else and then restore it's output redirection.

Has anyone had luck doing this sort of output gymnastics just using native functions, or any had-crafted functions for that matter?