Delpen macro

[Jthoma01]

Anybody out there have a location or example of the delpen macro? This macro used to be on the DSN site. You have a process that is suspended. You pull a value out of SDA with an examine pcb command and insert into the macro. you run it and it resets the delpen bit and the subsequent stop/id kills the process and frees up all its resources. I've seen this work on dtr user processes hung on a database and tape drives hung.

[Robert Brooks_1]

What problem are you attempting to solve?

Simply clearing pcb$v_delpen is NOT sufficient to solve the problem I'm guessing you're faced with.


-- Rob (VMS Engineering)

[John Gillings]

News to me!

Interesting concept, I suppose the theory is the $DELPRC code path sees the DELPEN bit set and exits. By clearing the bit, you give $DELPRC a second chance to delete the process and hope it manages to work the second time.

Somewhat Microsoftian logic - keep repeating the same behaviour and hope for a different outcome (I think that's someone's definition of insanity ;-).

I've searched archives which should include all of what used to be in DSN and not found anything that looks like a match.

If you really want to try it (WARNING, one false step will crash your system), you want bit PCB$V_DELPEN in field PCB$L_STS. If you want to bypass all the proper operating system to find and synchronize access to the PCB, you can use SDA to determine the address of PCB$L_STS:

SDA> SET PROCESS/INDEX=process-index
SDA> READ SYSDEF
SDA> EVAL PDB+PCB$L_STS

Check if DELPEN is set (mask value is %X20), then write some MACRO code to dive into CMKRNL and clear it.

I'm deliberately NOT giving you actual code, because if you don't understand how to do it from that description, you really shouldn't be attempting it! Sorry.

Just a reminder - there are an infinite number of ways to crash your system while trying to do this kind of thing, and very small number of ways to get it right.

I agree with Bob that it's extremely unlikely that this method will succeed - if it worked, every support engineer on the planet would know about it, and there would be a SET PROCESS/NODELPEN command in DCL.

[Volker Halle]

Jthoma1,

welcome to the OpenVMS ITRC forum.

The process might not actually be in SUSP state (check with $ SHOW SYSTEM), but might be in process deletion/rundown, preventing certain utilities to obtain information from that process.

The process is most likely hung due to some un-finished IO-operation or resource problem. The 'OpenVMS way' would be to try to diagnose the situation to find what's preventing the process from being deleted. SDA is your friend. There is also the PWAIT$SDA SDA extension (see OpenVMS Freeware), which can help diagnose hung processes.

Once the situation is understood, it may be possible to clean up the process by satisfying the condition, it may be waiting for.

Volker.

[Jthoma01]

Oh yes I'm aware of this kind of moving around between OpenVMS design intentions. Yes it seems like insanity that you try something and hope and keep doing the same thing. This macro came from mission critical support John Fischer. We used to get DTR users who would control/y out of their session because they would be walking the database and thought their process hung or whatever. After that I would get a lock on the db. I would attempt to stop/id the process and it would rwast. Now I've got a production system with a hung database and the only way to clear it is reboot. Sounds like Windows response. But the mission critical folks supplied us with this macro and the instructions and it worked every time without crashing. So somebody somewhere knew what in OpenVMS was hanging and knew what to provide to attempt to clear without a reboot. I have also used it with hung tape drives also. If a processes is hung due to a unfinished I/O then who wrote that code and did not use a timeout in the qiow call. At any rate since the sda commands you all have listed doesn't have the set proc/id= command followed by the examine pcb;100 then I will try and see if I can find John Fischer's new e-mail address and ask him. I may also have this on a tape. If so I will post it back so you can see. Thanks for the input

[Ian Miller.]

Very much depends on the state of the process as to if clearing the delete pending bit and trying again works.

It would be interesting to see this program.

It is best to investigate the current state of the process before doing STOP/ID. Parhaps you can post the result of
SDA> SHOW PROCESS/ID=x

[Volker Halle]

If the intention is JUST the clearing of the DELPEN bit in PCB$L_STS of the offending process, this can 'easily' be done with DELTA:

You need the IPID (Internal PID) of the process:
SDA> SET PROC/IND=
SDA> SHOW PROC

and the S0 address of PCB+PCB$L_STS
SDA> READ SYSDEF
SDA> EVAL PCB+PCB$L_STS

and - of course - CMKRNL privilege

and good nerves, if you want to try this on a running system ;-)

WARNING: THIS CAN CRASH YOUR SYSTEM, if you make any mistakes while in DELTA in kernel mode. Try it on a test system first, to get used to the way DELTA behaves. DELTA is documented in the OpenVMS Delta/XDelta Debugger Manual.

$ RUN SYS$SHARE:DELTA
ipid;1M
pcb_sts_va/nnnnnnnn nnnnnnnx
exit
$

ipid is the 8-digit HEX IPID of the process
pcb_sts_va is the S0 address obtained with the above EVAL
nnnnnnnx is nnnnnnnn minus 2 (= PCB$L_STS with PCB$M_DELPEN = 2 cleared). Do NOT try this, if the DELPEN bit (=bit 1) is NOT set.

Volker.

[David B Sneddon]

A Google search of delpen +macro reveals the
following...

http://vmsone.com/~decuslib/vmssig/vms94a/dsj/mnowat.dsj

which seems to do what you describe.
You don't mention platform...

Dave

[Ian Miller.]

I understand what the referenced program does and it will work for some conditions but not all. It does say in the program that it can causes crashes.

[Richard J Maher]

Hi Ian,

>It does say in the program that it can >causes crashes.

and you feel the need to repeat that because?

I'm sure your sheriff's badge has already been shown, just wondering where the added value is?

Regards Richard Maher