topic Re: ecp and tdc in Operating System - OpenVMS

ecp and tdc

Paul Coviello — Tue, 10 May 2005 12:56:23 GMT

Hi we are running 7.3-2 and I installed TDC I'm about to install the ECP but a little confused (what else is new) anyways... reading thru the install guide it mentions that if you previously installed ECP you need to reboot and then to run the IVP you need a reboot, so do you need a reboot if the above is not true?

also I'm questioning the need to install the collector since I installed TDC...

thanks

Paul

Re: ecp and tdc

Karl Rohwedder — Wed, 11 May 2005 00:40:06 GMT

I think when ECP is installed for the 1st time no reboot is required.
The new ECP (V5.5A) can read TDC-collector files (on V8.2 there is no ECP collector anymore).

regards Kalle

Re: ecp and tdc

Volker Halle — Wed, 11 May 2005 00:58:40 GMT

Paul,

according to the ECP WEB page, on V7.3-2 you can collect data with either TDC (V2.1 or higher) or ECP Data Collector. Note: the current version of ECP is V5.5A (MAR-2005).

A reboot should only be required, if you would be running a previous version of the ECP data collector (drivers can't be reloaded on OpenVMS Alpha).

I've used ECP V5.5 and TDC_RT V2.1-69 on V8.2 and found one disadvantage: you can't analyze data from the currently running collection.

Volker.

Re: ecp and tdc

Sebastian Bazley — Wed, 23 Nov 2005 07:18:20 GMT

Also tried getting data using TDC EXTRACT while a collection is running, and get the same problem.

Backup/ign=int allows one to create a copy, which can then be used by TDC EXTRACT (could it be used by ECP?), but that's not exactly an idea solution ...

Re: ecp and tdc

Sebastian Bazley — Wed, 23 Nov 2005 07:35:17 GMT

Just found another solution.

Before starting the collection:

$ define decc$file_sharing enable

This can be added to:

SYS$COMMON:[TDC]TDC$DETACHED_PROLOG.COM

Re: ecp and tdc

Jan van den Ende — Wed, 23 Nov 2005 09:25:03 GMT

Paul,

in my name,
give Sebastian _FULL_ points!
I never before heard of that setting (my own oversigh maybe), but this simple setting will mo doubt have MUCH wider applicability, and just offhand I can recall half a dozen cases where I would have been SO happy with it!

Proost.

Have one on me.

jpe

Re: ecp and tdc

Sebastian Bazley — Wed, 23 Nov 2005 11:27:12 GMT

Thanks!

I came across the description of DECC$FILE_SHARE originally in some Java documentation, but it (and a load more) are described in

HP C
Run-Time Library Reference Manual for OpenVMS Systems

See

1.6 Enabling Compaq C RTL Features Using Feature Logical Names

[this may have moved]

Unfortunately the URL I have no longer works...

Re: ecp and tdc

John Gillings — Wed, 23 Nov 2005 16:33:51 GMT

>re: $ define decc$file_sharing enable
>I can recall half a dozen cases where
>I would have been SO happy with it!

Be very careful with this, and all other "feature logical names". They tend to be double edged swords, usually with the "bad" edge much bigger and more dangerous that the "good" edge!

As should be obvious, enabling file sharing underneath an application that is assuming exclusive access is not necessarily a good idea. In this case the file in question is probably just a stream of data points, so chances are it's OK. But in the general case, you can't be so sure.

On the other hand, the data collector may be somewhat performance sensitive. Will the cost of file sharing push it outside it's performance envelope?

Think about it. If this were a universal magic wand that made any C program cooperatively share its data files, with no downside, it would be the default, and we wouldn't even bother having a switch for it, yes?

In general, you should not have programs whos correctness depends on specific (non-default) settings of feature logical names. They're timebombs waiting to fail.

Re: ecp and tdc

John Gillings — Wed, 23 Nov 2005 16:40:30 GMT

>With DECC$FILE_SHARING enabled, all files
>are opened with full sharing enabled
>(FAB$M_DEL | FAB$M_GET | FAB$M_PUT | FAB$M_UPD).
>This is set as a logical OR with any
>sharing mode specified by the caller.

Just thought of a good illustration of why this might be a very BAD idea for some applications. Suppose I'm using a file as an interprocess lock. Maybe not the best application design, BUT it's prefectly valid, and should be reliable. If some "hand of God" stomps on my fopen flags, enabling things I thought were disabled, my application is toast!

Re: ecp and tdc

Sebastian Bazley — Thu, 24 Nov 2005 05:53:38 GMT

Very good points.

We have used the file_share logical, but so far only to give read access in Perl programs. This is a lot simpler than using vmsopen(shr='put', etc).

Re: ecp and tdc

Sebastian Bazley — Thu, 08 Dec 2005 12:12:15 GMT

I raised the issue of TDC not allowing access to its output file on ITRC.

The response says that the file has some headers and internal links that are updated at every snapshot. So the file share trick may not always work, and coordination would be tricky.

==

There is an example client in the OpenVMS technical journal at:

http://h71000.www7.hp.com/openvms/journal/v5/intro-to-performance-data-collector.pdf

that can be used to create hourly files.

For concurrent access, one could write a consumer to write the data in a "sharable" manner. Normal data collection could be disabled if not required.