Obtaining "Maximum Observed Processes:"

[Jack Trachtman]

One of the lines in the Autogen report is "Maximum Observed Processes:". I wanted to use this value in a report I'm creating so I looked through AUTOGEN.COM. I can find the line where the above info gets displayed, but can't find how it's obtained.

How can I programmatically get the value for "Maximum Observed Processes:"?

TIA

[Duncan Morris · Accepted solution]

Jack,

"AUTOGEN collects feedback during the SAVPARAMS phase by executing
the image SYS$SYSTEM:AGEN$FEEDBACK.EXE. AUTOGEN writes feedback
information to the file SYS$SYSTEM:AGEN$FEEDBACK.DAT. This file
is then read during the GETDATA phase."

So, not done by DCL.

You could try parsing output from SDA

SDA> clue mem /stat

depending upon your o/s version. See attched example.

Volker, or others, may have simpler shortcuts to the specific global cell holding the information.

Duncan

[Hoff]

The easiest way here is a tool or local process that performs periodic polling (your own code or potentially via MONITOR /RECORD data possibly related to T4 use or otherwise configured), though you can interpolate this value based on the system accounting or auditing data. By counting login and logout activity.

[Jon Pinkley]

Jack,

The system cell that tracks this is pms$gl_proccntmax, but it does not account for the NULL or SWAPPER "processes". So you must add 2 to get the value that AGEN reports.

AGEN$FEEDBACK.DAT has a record PROCESSES_PEAK that has the value that will be reported as "Maximum Observed Processes:" in SYS$SYSTEM:AGEN$PARAMS.REPORT

OT$ search SYS$SYSTEM:AGEN$PARAMS.REPORT "Maximum Observed Processes:"
Maximum Observed Processes: 145
OOT$ search sys$system:agen$feedback.dat proc
PROCESSES_PEAK = 145
MAXPROCESSCNT_CUR = 962
OT$ analyze/system

OpenVMS (TM) system analyzer

SDA> eval @pms$gl_proccntmax + 2
Hex = 00000000.00000091 Decimal = 145 DYN$C_NET_NODE_IDS
SDA>

[Shilpa K]

Hi Jack,

I ran the agen$feedback.exe image mentioned by Duncan Morris manually:

$ run SYS$SYSTEM:AGEN$FEEDBAK.EXE

It generated a file SYS$SYSROOT:[SYSEXE]AGEN$FEEDBACK.DAT

The parameter "PROCESSES_PEAK" in the file SYS$SYSROOT:[SYSEXE]AGEN$FEEDBACK.DAT contains the value reported by the autogen utility for "Maximum Observed Processes".

I have copied below the code that I used for reading the PROCESSES_PEAK:

$ search SYS$SYSROOT:[SYSEXE]AGEN$FEEDBACK.DAT PROCESSES_PEAK -
/output=sys$scratch:PROCESSES_PEAK.OUT/nowarning/nolog
$ if f$message($STATUS, "SEVERITY") .eqs. "%S"
$ then
$ open/read input sys$scratch:PROCESSES_PEAK.OUT
$ read input PROCESSES_PEAK
$ close input
$ endif
$!
$ delete/noconfirm sys$scratch:PROCESSES_PEAK.OUT;*
$ PROCESSES_PEAK = f$element(1,"=",PROCESSES_PEAK)
$!
$ show symbol PROCESSES_PEAK

OpenVMS System Manager's manual says the AGEN$FEEDBAK.EXE image can be run manually.

Regards,
Shilpa

[Jon Pinkley]

Just FYI, the value displayed for "Maximum Processes" by

SDA> clue mem/stat

is the "unadjusted" value of pms$gl_proccntmax, and is two less than what AGEN$FEEDBACK.DAT has for "PROCESSES_PEAK".

Not real significant, but if you are wondering why they don't agree, the reason is that AGEN$FEEDBACK adds 2 to account for the two process that are never created, the NULL process and the SWAPPER.

Jon

[Shilpa K]

Sorry, I had wrongly reported the image name. The correct image:

SYS$SYSTEM:AGEN$FEEDBACK.EXE

Regards,
Shilpa

[Jack Trachtman]

Thanks all - I always enjoy learning something new about VMS.

I've decided to use Jon's info w/the PIPE cmd to get the info. Something along the lines of:

pipe (write sys$output "eval @pms$gl_proccntmax + 2" ; write sys$output "exit" ) | ana/sys | search sys$pipe "Decimal = " | (read sys$pipe x ; def/job jack &X )

[John Gillings]

Jack,

I'm not sure what language you intend to use "programmatically". If you're prepared to hard code an address (possibly version dependent), this can be done directly from DCL without the need for privilege. (Both SDA and AUTOGEN mechanisms suggested require privilege).

This is a fairly general hack applicable to many system cells, as most are protected USER READ.

First determine the value of the symbol PMS$GL_PROCCNTMAX (this will need privilege, but it's once only for a particular version of OpenVMS - this is the virtual address of the cell you're interested in:

$ ANALYZE/SYSTEM
SDA> EVALUATE PMS$GL_PROCCNTMAX
Hex = FFFFFFFF.9D00EE10 Decimal = -1660883440 PMS$GL_PROCCNTMAX

(this is for OpenVMS V8.3-1H1)

Define a DCL Symbol with this value:

$ PMS$GL_PROCCNTMAX=%X9D00EE10

Note the value displayed by SDA is a sign extended 32 bit value, so just use the low 32 bits. Since it's in system space, the address is the same across all processes. It's also a compile time constant, so it will only change if the underlying system images change, which means a new version, or fairly serious patch.

Now, you can read the cell at that address using an FAO hack:

$ proccntmax= F$CVUI(0,32,F$FAO("!AD",4,PMS$GL_PROCCNTMAX))

This is the uncorrected value, so you may want to add 2.

A trick to write DCL which works for several different versions of OpenVMS... collect the different values for versions you want to support and define them like this:

$ PMS_PCM_IA64V831H1=%X9D00EE10
$ PMS_PCM_AlphaV732=%X81008BD8
$ PMS_PCM_AlphaV83=%X81C08FD0
$ Sym="PMS_PCM_"+F$GETSYI("ARCH_NAME")+F$GETSYI("VERSION")-"."-"-"
$ IF F$TYPE('Sym')
$ THEN
$ proccntmax= F$CVUI(0,32,F$FAO("!AD",4,'Sym'))
$ ELSE
$ WRITE SYS$OUTPUT "Unsupported version ''Sym'"
$ ENDIF


For a compiled programming language, you may be able to declare PMS$GL_PROCCNTMAX as an external image and link against the system base image. This will also be version dependent.

[Steve Reece_3]

If you want a portable and supported route (rather than poking around in Autogen and data structures that may or may not change in the future), you could always use F$GETJPI lexical calls to establish process numbers.
Repeated calls to it for a PID until it returns a blank, at which point you've passed through all of the processes on the system.
It may not be as efficient as using autogen's feedback, but it is a supported method of getting such data.

Steve

[Jon Pinkley]

RE: using repeated calls to F$getjpi

That won't measure the same thing. That will give you the number of processes present at the time you take the measurement. The PMS$GL_PROCCNTMAX cell is the highest process count seen since the system was booted. It is a bit like the different values displayed on a thermometer that displays the current temperature and the maximum temperature since it was last reset.

So if what Jack wants is the Max observed since system reboot, then the only time that using repeated f$getjpi (or f$pid which is what I really think Steve was thinking of) will return the same value as the PMS$GL_PROCCNTMAX derived value is when the measurement is made right at the time of the peak.

If you have Brian Schenkenberger's TMESIS SYMBOL loaded, then you can easily get the contents of any system executive cell

http://www.tmesis.com/SYMBOL/

$ symbol/set/local/exec PMS$GL_PROCCNTMAX
$ proccntmax= F$CVUI(0,32,F$FAO("!AD",4,PMS$GL_PROCCNTMAX))
$ show symbol proccntmax
PROCCNTMAX = 531 Hex = 00000213 Octal = 00000001023
$ analyze/system

OpenVMS (TM) system analyzer

SDA> eval @PMS$GL_PROCCNTMAX
Hex = 00000000.00000213 Decimal = 531 UCB$W_LMERRCNT+00003
SDA>
$

It probably isn't worth installing SYMBOL just for that purpose, but if you work with batch processes, SYMBOL is a really useful debugging tool.

Jon

[Hoff]

I haven't looked specifically for this, but T4 (based on MONITOR) should generate this value within its one-minute accuracy. Folks looking for this sort of detail also tend to love graphs, and T4 can generate graphs.

And I'd poll for this data, as there are other tasks that the periodic poller can also perform. I prefer to avoid linking against the kernel for these tasks, as that can be a maintenance issue after upgrades.

Or get yourself one of the available scheduling tools, something that OpenVMS itself should provide.

[Jon Pinkley]

As Hoff said, you may need to relink this when the o/s is upgraded. However, this is so small that it could be included in the command file that is generating the report and the .EXE created whenever the report is generated.

Download attachment, save as proccntmax.mar

If you prefer a different symbol name, modify the program (even if you aren't a MACRO programmer, it should be obvious what to change).

Compile, link, run. No privs needed.

OT$ write sys$output f$getjpi("","CURPRIV")
TMPMBX,NETMBX
OT$ macro proccntmax.mar
OT$ link/sysexe proccntmax
OT$ delete/symbol proccntmax
OT$ sho sym proccntmax
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
OT$ run proccntmax
OT$ sho sym proccntmax
PROCCNTMAX = "143"
OT$ ! This is the unadjusted value of the pms$gl_proccntmax cell (as a decimal string)

[Steve Reece_3]

As Hoff suggested, a poller can do other things too when it runs.
An example of another thing is to set up a logical for the maximum number of processes that the poller has seen.

Yes, I agree that it won't give the VMS internal value for the maximum number of processes, as seen by the feedback data.
BUT
It's supported, doesn't need relinking when VMS versions change, can be used on new or older versions with the same code.

I used F$GETJPI calls on systems that I supported with my former employers in the UK. The code's reliable and works on any version of VMS that they deploy and support (when I left we had systems on OpenVMS Alpha v7.1-2, v7.2, v7.3-1 and Integrity servers on 8.3 and 8.3-1h1).

[Hoff]

ps: If you have a support contract in force with HP, please consider asking HP to return the value from within pms$gl_proccntmax via sys$getrmi, sys$getsyi or another system service; ask HP to provide a mechanism that doesn't require kernel-mode code or periodic polling or other such.