T4 Help

[Volker Halle]

Joshua,

you should be able to use $ @T4$SYS:T4$NOW while a T4 collection is running, to create a snapshot of the collected data. T4$NOW runs interactively in your process context - if that is instrumental to the problem.

Volker.

[Joshua Gould]

>>So - as shown in your initial question - why does the first T4Extr command fail silently in the context of the T4$COLLECT batch job, but not when executed interactively ?
>>
>>Take the commands executed interactively and run them in a batch procedure under the same user as T4$COLLECT is running.

Some insight, I'm still getting 4 records even running an hour.

(16:49:06) $ T4Aprc T4_ZEUS_02AUG2007_1547_1647_AcLg.Csv; T4_ZEUS_02AUG2007_1547_1647_Mon.Csv
APRC-I-STATS, 4 record(s) read from input and 4 records written to output ...

[Volker Halle]

Joshua,

try to interactively run $ @T4$SYS:T4$NOW while a T4 collection is running.

Also try to run the T4Extr ..._Mon.Dat command in a batch job under the same user as T4$COLLECT is running.

Always use the same account under which the T4$COLLECT batch job is running.

These 2 tests try to determine, if the problem running T4Extr against the *_Mon.Dat file at your node has something to do with process context (batch/interfactive, quotas, symbols, logicals).

T4Extr has - as it's a good tradition in real native OpenVMS tools - a debug logical:

$ define T4EXTR$DEBUG TRUE

Consider to use this logical in your tests, maybe even temporarily add it to T4$COLLECT.COM - at least when running T4Extr against the *_Mon.Dat file - then deassign the logical afterwards.

Volker.

[Willem Grooters]

First some background:
In certain cases MONITOR introduces time drift (a total of a few seconds in a 24 hour measurement) and this could be highly undesirable. Therefore, a special version of MONITOR is delivered with T4 that prevents this timedrft. In most cases however, this timedrift is not a problem.
This special version could cause your problems.
To prevent it from running, comment out the lines that DEFINE MONITOR ... - depending your hardware and VMS version, to use the VMS-native MONITOR.

[Joshua Gould]

Hello,

I did further testing on Friday and still baffled.

I guess the oddest thing we found was that I moved the extract for DISK ahead of COM. I ended up with a good Disk.csv and still with an empty COM.CSV.

[EdgarZamora_1]

Might you be running VMS 8.3 on Alpha? If so, I recommend waiting for the next version of T4 to come out or requesting a copy of the beta.

[Volker Halle]

Joshua,

could you try an explicit extract of all the relevant MONITOR classes ? Instead of

/Class=(All,NoScs,NoDisk,NoRms)

try

/Class=(NOALL,DLOCK,FCP,..)

Volker.

[Willem Grooters]

Joshua,

See thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1138290

It might be of help, if you're running 8.3 on alpha.
If so, send a request to the t4-people at HP, they could offer you a new version (in test)

WG

[Volker Halle]

Willem,

as far as I understand the problem discussed in this thread:

T4Extr of the *_mon.DAT producing _Mon.CSV fails when run in BATCH, but succeeds if run interactively afterwards.

I cannot see, how this could have something to do with the MONITOR not collecting data problem discussed in the other thread.

Volker.