- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Generating a looping process
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 05:52 AM
тАО08-30-2007 05:52 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 06:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 07:04 AM
тАО08-30-2007 07:04 AM
Re: Generating a looping process
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 07:19 AM
тАО08-30-2007 07:19 AM
Re: Generating a looping process
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 07:49 AM
тАО08-30-2007 07:49 AM
Re: Generating a looping process
>>>
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 08:59 AM
тАО08-30-2007 08:59 AM
Re: Generating a looping process
$ 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 09:17 AM
тАО08-30-2007 09:17 AM
Re: Generating a looping process
I have what I need to test the OpenView monitoring policy.
Thanks again.
-Tom Wolf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 10:06 AM
тАО08-30-2007 10:06 AM
Re: Generating a looping process
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 11:54 AM
тАО08-30-2007 11:54 AM
Re: Generating a looping process
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!