topic Re: T4 files... in Operating System - OpenVMS

T4 files...

Rich Hearn — Wed, 29 Oct 2008 13:24:25 GMT

Hi all,

I have not been able to find a specific forum on T4, so I'll ask my question here. I want to "clean up" the left-over files T4 leaves on my disk (.uue's, .logs, .png's), but haven't found any documentation (faq, steve lieman's writeup) stating if the files are needed for anything in particular or what their function (by type) is.

Any info would be appreciated
Tnx,
Rich

Re: T4 files...

Hein van den Heuvel — Wed, 29 Oct 2008 18:52:25 GMT

Personally I purge all the T4 stuff away from the VMS box and only manage it on PC's, transferring a month at a time.

So I have the current month's CSV's and the last full month. Any prior CSV are zipped up and moved over to PCs, put on a fixed drive as well as a removable drive just in case.

I can understand and support a daily managemen Email with yesterdays usage pictures (.png) but that't all for those. Zap!

fwiw,
Hein.

Re: T4 files...

John Gillings — Wed, 29 Oct 2008 23:08:20 GMT

Rich,

If you're running the latest T4, the only files you should see are ZIPs. The "core" files are:

T4_node_date_start_end_COMP.ZIP
T4_node_date_start_end_DAT.ZIP

_COMP.ZIP contains
T4_node_date_start_end_COMP.CSV
T4_node_date_start_end_DISK.CSV

in a cluster it will also have
T4_node_date_start_end_SCS.CSV

and in a fibre channel environment also
T4_node_date_start_end_EVA.CSV

_DAT.ZIP contains _FCM.DAT and _MON.DAT

If your T4 directory contains other stuff, then you either generate it yourself (eg, PNGs are probably from CSVPNG, which isn't run automatically), or your system crashed and the post processing phase of the collector didn't get run.

Most of the data can be reconstructed from the _MON.DAT file, so if you're really desperate for space, you can delete everything except the _DAT.ZIP (but before you take my word for it and do anything irreversible, experiment with the files you have to make sure you keep everything you need to reconstruct the stuff you need)

I've attached a command procedure I use to post process T4 data if the standard procedure doesn't clean up (we do a lot of testing that involves deliberately crashing nodes, so we get junk left over fairly regularly). I'm fairly sure I wrote it based on the post process section of the standard T4 collector, but it could be a standard component of the T4 kit.

Re: T4 files...

Rich Hearn — Wed, 29 Oct 2008 23:08:26 GMT

Hein,

Thank you for your response. I appreciate reading how you're working with these files. I would assume that as long as one keeps the .csv's all the other files can safely be discarded after a month or so. That gives me an idea how I'll go about handling them.

Thanks again,
Rich

Re: T4 files...

John Gillings — Wed, 29 Oct 2008 23:18:56 GMT

Sorry,

I forgot the post process contains a reference to our "site callout" procedure to define the set of processes of interest. The standard T4 kit requires you to hard code this into 2 or 3 different procedures.

Since I don't like having the same information coded in multiple places, I've abstracted it into a procedure which defines global symbols for the process list and the collector name. We run (slightly) modified versions of T4$COLLECT and T4$NOW which reference the site callout.

Re: T4 files...

Rich Hearn — Thu, 30 Oct 2008 02:27:06 GMT

John,

Thank you for responding to this. I'm running T4 v4.3 - I don't know if that's the latest or not, but I've got *.cvs,*.png,*.uue,*.zip (I don't recall the others and I'm not vpn'd in to check) I get these types of files generated daily as well as the *comp.zip and *chart.zip's that get e-mailed to me.

I probably do not have T4 set up properly for my cluster. I'll check on it tomorrow when I get in. I thank you for the attachment - I do have lots of room (for now), but I know how that stuff goes - time goes by and you wish you had kept up with it.

I'll get back after I can check the systems

Tnx agn,
Rich

Re: T4 files...

Rick Dyson — Thu, 30 Oct 2008 12:20:56 GMT

Just an observation that I found and reported long ago and I believe, as of the most recent 4.3 release, T4 still has as a feature.

If your node name is 6 char long and you use ODS-2, there are several files generated by T4 that have file names that are too long and will fail to be created at start time. Thus you won't be able to collect that data.

My submitted solution was to use a different time tag (YYYY-MM-DDD) that is shorter then the T4 default. It also allows the files to be displayed in time order in the directory (but that is personal taste!). I also had to drop a character here and there in the file names. E.g., SUBP ==> SUB, etc.

Rick

Re: T4 files...

Rich Hearn — Thu, 30 Oct 2008 14:33:31 GMT

John,

I went back & checked on my install log, I did not find any indication of an error.

btw: with much chagrin, when I went back and re-read T4_readme.txt *through to the end*, I found the list of the files that I originally asked about. Apologies to the developers for my askin'.

I trust I can del the *uue* files since they're normally only used for e-mail - yes?

Rick

>If your node name is 6 char long and you use ODS-2, there are several files generated by T4 that have file names that are too long and will fail to be created at start time.

My node names *are* 6 char & I *do* use ODS-2, but haven't noticed any losses. I do get *comp,*dat,*mon, plus the .zips for them (.uue too) - maybe it was fixed?

I'm running vms v8.3 and I've got files like

T4_CACHE1_30OCT2008_0001_2359_SUBP_EWA0.LOG

as well as others. This is good to know though. I'll check some log files and see if I can find anything "of interest".

Thank you both for your time and experience
Rich

Re: T4 files...

Rick Dyson — Thu, 30 Oct 2008 14:47:36 GMT

Hmm... I wonder if they changed the time stamp and I didn't notice. Wasn't it "30-OCT-2008" instead of "30OCT2008" in the recent past? The longer one makes that example file name be 41 characters long (ODS-2 has 39 max, right?). But dropping the hypens does gain you the 2 characters you need. Maybe I missed that fix in v4.3.

rick

Re: T4 files...

Rich Hearn — Thu, 30 Oct 2008 17:56:25 GMT

Rick,

I'd have to say that they "slid that one in" and it's not an obvious one; one might even say it was an "elegant" fix - they made it the 39 char limit. My files are "un-touched"...

Rich

Directory $1$DGA63:[VMS$COMMON.SYS1.T4$DATA]

CACHE1.HTM;18 2 29-OCT-2008 00:00:04.50 CACHE1_1.PNG;18 12 29-OCT-2008 00:00:05.21 CACHE1_2.PNG;18 7 29-OCT-2008 00:00:05.27 CACHE1_6.PNG;18 13 29-OCT-2008 00:00:05.33 CACHE1_8.PNG;18 13 29-OCT-2008 00:00:05.39
CACHE1_9.PNG;18 11 29-OCT-2008 00:00:05.44
T4$COLLECT_CACHE1.LOG;20
82 29-OCT-2008 23:59:00.59 T4_CACHE1_28OCT2008_0001_2359_COMP.UUE;1
3245 29-OCT-2008 00:00:22.08 T4_CACHE1_28OCT2008_0001_2359_COMP.ZIP;1
2281 29-OCT-2008 00:00:05.64
T4_CACHE1_28OCT2008_0001_2359_DAT.ZIP;1
23929 29-OCT-2008 00:00:07.86 T4_CACHE1_30OCT2008_0001_2359_FCM.DAT;1
2256 29-OCT-2008 23:59:01.40 T4_CACHE1_30OCT2008_0001_2359_LCK7.CSV;1
83 29-OCT-2008 23:59:01.39 T4_CACHE1_30OCT2008_0001_2359_NETM_EIA0.CSV;1
125 29-OCT-2008 23:59:01.51 T4_CACHE1_30OCT2008_0001_2359_NETM_EWA0.CSV;1
125 29-OCT-2008 23:59:01.45 T4_CACHE1_30OCT2008_0001_2359_NETM_EWB0.CSV;1
125 29-OCT-2008 23:59:01.48
T4_CACHE1_30OCT2008_0001_2359_SUBP_EIA0.LOG;1
10 29-OCT-2008 23:59:01.44 T4_CACHE1_30OCT2008_0001_2359_SUBP_EWA0.LOG;1
10 29-OCT-2008 23:59:01.38
T4_CACHE1_30OCT2008_0001_2359_SUBP_EWB0.LOG;1 10 29-OCT-2008 23:59:01.40
T4_CACHE1_30OCT2008_0001_2359_SUBP_FCM.LOG;1 154 29-OCT-2008 23:59:01.34
T4_CACHE1_30OCT2008_0001_2359_SUBP_LCK7.LOG;1 6 29-OCT-2008 23:59:01.32
T4_CACHE1_30OCT2008_0001_2359_SUBP_MON.LOG;1 1 29-OCT-2008 23:59:01.27
T4_CACHE1_30OCT2008_0001_2359_SUBP_XFC.LOG;1 6 29-OCT-2008 23:59:01.31
T4_CACHE1_30OCT2008_0001_2359_XFC.CSV;1
74 29-OCT-2008 23:59:01.35 T4_CHARTS_CACHE1.UUE;18
75 29-OCT-2008 00:00:28.42
Total of 24 files, 32655 blocks.
CACHE1::DISK$INFSYS:[RJHEARN]_>