Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

DCL Command procedure output

 
Jim_McKinney
Honored Contributor

Re: DCL Command procedure output

Ever try

$ ccontrol stat xxxx -a0 "-L1"


where xxxx is your Cache config name? Filter leaving only the lines with "licenses" and you should see something like this.

$ pipe ccont stat xxxx -a0 "-L1" | sear sys$pipe licenses
Current Licenses available = 127
Minimum Licenses available = 125
Total Licenses available = 128

Maybe you want more info - maybe less. Filter as you choose. Then, just place that command line in a command procedure and "$ spawn/nowait" it from the terminal where your logged in...

$loop:
$ pipe ccont stat xxxx -a0 "-L1" | sear sys$pipe licenses
$ wait 00:15
$ goto loop
Hoff
Honored Contributor

Re: DCL Command procedure output

This looks to be a variation of standard user or standard license monitoring, looking for the most efficient allocation of license units, or some such MBA-ism.

It is easy to code the DCL to post up the periodic messages when invoked interactively, and to keep a running average over the day, and to accumulate min and max values by storing the data in an RMS file. (An RMS file does this nicely, and you can then run a tool to calculate the min, max and running_average, if your DCL doesn't preemptively write it.)

You could conceivably use a modified version of your existing DCL running in batch (forever) and (with basic RMS sharing) have your periodic query tool look at the most recent activity in the RMS indexed file.

Or your existing batch job can notify via OPCOM traffic; via REQUEST or REPLY messages.

If you want to make somebody that likes statistics happy, write the data as XML -- DCL can write XML nicely -- and pass the logs over to the statistician(s). (Run a web server on the OpenVMS box and you can serve up the data that way, too.)

Or code some tools on your mail client to receive and process and tabulate the data from the existing batch job. Various mail clients are programmable.

or both.

Having one piece of code doing both (and from batch) is rather more work. It's easier to have a "data collector" and a "data display" component, in my experience.

In aggregate, a baseline solution for this is probably about two hours of DCL coding and testing. If that. If you want graphics displays and CGI, a little more time.

Highlighted
Andy Bustamante
Honored Contributor

Re: DCL Command procedure output

T4 provides an excellent framework for monitoring a VMS system. The attachment has 2 command files to monitor and report on cache user licenses in T4 format. This can be included as a T4 collector so the data gets collected into one report file. If you need to check the status during the day, use convert to read the present file. For example:

$ pipe convert T4_MYNODE_30JUL2008_0000_2358_CACHE.CSV/share sys$output |
sort sys$pipe /key=(pos:10,siz:2) /nodup sys$output

provides a fast status check and quickly lets you know if a closer look is called for.

Using the T4 framework has the advantage of minimizing drift during monitoring generating samples at near regular intervals. Once data is collected you can use EXCEL, TLVIZ or CSVPNG to create graphic display suitable for the PowerPoint set.



Andy Bustamante
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net