Generating a looping process

[Tom Wolf_3]

Hello, I'm an OpenVMS novice and I'm trying to generate a looping process to test the functionality of an OpenView Operations for Windows monitoring policy. The policy checks for looping threads on an OpenVMS server and generates an event when one is found.

Can anyone provide detailed instructions on how to create a looping process on an OpenVMS server? We're running VMS 7.3-2 on an Alpha machine.

Any help would be appreciated.


Thank you.

Tom Wolf

[Karl Rohwedder · Accepted solution]

What about a simple DCL procedure:

$ 1: goto 1

loops like a charm...

regards Kalle

[Jan van den Ende]

Tom,

A word of warning on Kalle's procedure: execute it at prio 0 , or risk NOT being able to EVER stop it without hitting the big red one.

If the OV finds Kalle's, try one a little (not much) less simple.

$1:
$ wait 0:0:0.01
$ goto 1

This wil wait 1/100th of a second before repeating itself.
Good monitors should at least find this as well, and then you can try for the limits of sensitivity.

Proost.

Have one on me.

jpe

[Jon Pinkley]

Jan,

While the recommendation to set proc/prio=0 prior to executing a looping DCL procedure is a good one, I don't think it would prevent other processes from getting any CPU time unless it was run at realtime priority, even on a single processor system.

Is there something you know from experience that I am not aware of?

Jon

[Jan van den Ende]

Jon,

>>>
I don't think it would prevent other processes from getting any CPU time unless it was run at realtime priority
<<<

Strickly speaking, you are right.

But _IF_ such procedure runs at interactive priority, (on a single-CPU system) it is VERY rough competition for anything else.

I have had to deal with something like it (a loop through about half a dozen native DCL commands), and it took about 15 minutes to enable ALTPRI & set my prio to 9.
After that I could fairly quick find the culprit and lower its prio to zero. Things started moving aging, so I could determine that it was indeed in a tight PC loop.

I killed the process, and inspected the DCL.
I forgot the details, but IIRC, a variable was set in local scope, and setting it globally to another value did not create an exit :-)

Bottom line: I grew allergic for tight loops without IO or WAITs.

fwiw

Proost.

Have one on me.

jpe

[Hoff]

And here's a little Macro32 executable program that loops until interrupted, and a DCL wrapper that builds and runs the image at low priority until interrupted by ^Y...


$ macro/object=loop.obj sys$input:
.entry go,^m<>
10$: brb 10$
.end go
$ link loop
$ authpri = f$getjpi("0","AUTHPRI")
$ set process/prior=0
$ set control=y
$ write sys$output "Press Ctrl/Y to exit the loop"
$ on control_y then goto done
$ run loop
$done:
$ set process/prior='authpri'
$ exit

[Tom Wolf_3]

Thanks to all that responded.
I have what I need to test the OpenView monitoring policy.

Thanks again.

-Tom Wolf

[Jon Pinkley]

I am not sure how OpenView checks for looping processes. It if checks for processes with high CPU utilization, then the proposal of using a loop with a 1/100 second wait is very likely not to generate enough usage for it to notice.

I fact, I just tested the command procedure on the slowest box we have, an AlphaServer 2000 4/233 (uniprocessor) running OpenVMS V7.3-2 with the following results via ^T

$ @scr:looper
DELTA::JON 17:20:14 (DCL) CPU=00:00:01.89 PF=616 IO=1215 MEM=112
DELTA::JON 17:20:16 (DCL) CPU=00:00:01.89 PF=616 IO=1216 MEM=112
DELTA::JON 17:20:17 (DCL) CPU=00:00:01.89 PF=616 IO=1217 MEM=112
DELTA::JON 17:20:19 (DCL) CPU=00:00:01.90 PF=616 IO=1218 MEM=112
DELTA::JON 17:20:21 (DCL) CPU=00:00:01.90 PF=616 IO=1219 MEM=112
DELTA::JON 17:20:22 (DCL) CPU=00:00:01.90 PF=616 IO=1220 MEM=112
DELTA::JON 17:20:24 (DCL) CPU=00:00:01.91 PF=616 IO=1221 MEM=112
DELTA::JON 17:20:26 (DCL) CPU=00:00:01.91 PF=616 IO=1222 MEM=112
DELTA::JON 17:20:29 (DCL) CPU=00:00:01.91 PF=616 IO=1223 MEM=112
DELTA::JON 17:20:32 (DCL) CPU=00:00:01.92 PF=616 IO=1224 MEM=112
Interrupt

$

DELTA is a satellite with no disk except a local page/swap disk, and has 128MB of memory, so I think this is a fair representation of an unusably slow machine for any serious use. However, the looper with 0.01 sec wait barely increments the CPU time.

Just as a note, CPU time accounting is not accurate for processes that use less than a tick of CPU before going into a voluntary wait. That is one reason that things like MONITOR get charged less CPU time than they actually use.

While running a CPU bound process at priority zero will affect performance on the machine, it isn't going to be terrible. About the only thing it will do is prevent the idle process from being able to clear free pages for the dzero page cache, an other low priority processes.

My whole point is that I don't think the looper with wait state is going to be detected by any tool that is looking at CPU time utilization as its means of detecting a looping process.

But Jan it right. If you have someone running many instances of compute bound processes at interactive priority on a uniprocessor system, things get sluggish, especially if quantum is set to 20.

Jon

[John Gillings]

It shouldn't be necessary to reduce the priority of a truly CPU bound process below normal interactive priority, unless you've been messing with the SYSGEN parameters that adjust the priority boosting mechanism (QUANTUM, DORMANTWAIT, PIXSCAN and IOTA).

By default processes which are voluntarily entering wait states will quickly receive priority boosts, and will therefore preempt the CPU bound process at lower priority. CPU bound process will not be granted any priority boost, and will therefore remain with current=base priority. Having many CPU bound processes will have the effect of raising the effective interactive priority, as all "normal" processes will naturally get boosted above the priority of the CPU bound processes.

Quite a few years ago, an "expert" published a recommendation that DORMANTWAIT be set to its maximum value in order to "improve VMS performance". Nonsense! The effect was to disable priority boosting, which could result in priority lockouts from CPU bound processes. The classic was a batch job starting at priority 3, getting as far as taking out a lock on the root bucket in SYSUAF, and then being starved of CPU by interactive processes running at priority 4. Thus preventing further logins.

On a system with default priority boosting parameters, there should be no danger whatsoever from starting numerous CPU loops such as the DCL or MACRO32 code posted here, even without delays, and on a single CPU system.

Those processes would simply become the idle loop instead of NULL, and the priority of the CUR process(es) will increase a few points (though on Alpha and Integrity systems, there could conceivably be a slight performance hit because the idle loop isn't generating zeroed pages)

I also agree with Jon, any monitor which detected a process with 1/100th second pause on each loop iteration as being CPU bound is just plain wrong!