topic Re: FREE_RSN on alpha ? in Operating System - OpenVMS

FREE_RSN on alpha ?

Wim Van den Wyngaert — Wed, 01 Sep 2004 04:25:04 GMT

Does anyone has the program free_rsn for alpha ? Or something equivallent that can free programs in MUTEX state ?

Wim

Re: FREE_RSN on alpha ?

Ian Miller. — Wed, 01 Sep 2004 05:28:27 GMT

when a process is shown in MUTEX state on show system it can be for various reasons most of which are nothing to do with MUTEXes. The commonest reason is waiting for a pooled quota.

SDA sometimes shows a more accurate display of the state and can certainly be be used to determine what the problem is.

AMDS/Availability manager can be also used to determine the cause and (in the case of quota waits) may be able to fix it.

You may also find my SDA extention at
http://eisner.encompasserve.org/~miller/pwait$sda008.zip
helpful (hopefully :-).

Re: FREE_RSN on alpha ?

Wim Van den Wyngaert — Wed, 01 Sep 2004 05:31:20 GMT

Ian,

I have all things in place to monitor the quota and yes in my case, it is bytlm.
I have amds but when the process is inmutex, the increase of the quota is not coming thru.
(sybase server)

Wim

Re: FREE_RSN on alpha ?

Ian Miller. — Wed, 01 Sep 2004 05:41:31 GMT

is AMDS successfully changing the quota?
RMDRIVER can report problems via OPCOM messages on the target system.

Re: FREE_RSN on alpha ?

Wim Van den Wyngaert — Wed, 01 Sep 2004 05:43:37 GMT

Ian,

Yep. Opcom reported "process xxx modified".
But the quota remained the same.

Wim

Re: FREE_RSN on alpha ?

Jan van den Ende — Thu, 02 Sep 2004 04:24:20 GMT

Wim,

Yes, I know the "fun" with Sybase. There is some kind of memory leak, so however big you give it quota (and you do that in the startup, because it is started with RUN/NOUAF/) you WILL run out.
We decided to simply restart it each night (we blame it on ported, badly written U*X software).

Now, IF you hang in MUTEX caused by BYTLM exhausted, AND you want to free it, AND you are sure you can do this WITHOUT typo's, then SDA & DELTA can help you out.

It is DEFINITELY at your own risk, but we have on occasion been VERY glad with it.
(In a previous life, working with ICL DME, there was a utility with similar functionallity. It was named DYNAMITE just to make you aware what you were playing with. Would also have been a better name for DELTA).

Okay, now, if you want to try it anyway:

1.
Get PID of offending process.
2.
STOP /ID it. This will have no visible effect, but it delivers to the process the request ( = order ) to commit suicide as its first action, whenever 'first' may arrive.
3.
ANAL/SYST
sda> set proc/id=
sda> show proc.
look for Event flag wait mask & JIB address.
If they are NOT the same, then stop, this will not help you, the problem can NOT be helped with this
4.
sda> read sys$loadable_images:sysdef
5.
sda> format JIB
look at the field JIB$B_FLAGS
if your problem is unsufficient bytlm, the value should be "01"
if not: STOP!!! the problem is NOT what this procedure can cure.
6. Note the fields JIB$L_ORG_BYTLM, JIB$L_BYTLM, and JIB$L_BYTCNT.
Note the hex address & the hex value for them.
7. In your notes, increase each of them by the same, eg. hex 10000.
Those are the values we're gonna deposit, in the above order. Wrong order may well lead to system crash.

8.spawn
run DELTA

>>> you are now looking at the raw internal memory!

type EXACTLY
00010001:1;m
(that is 3 Zeroes, a One, 3 Zeroes, a One, a Colon, a One, a Semicolon, a One)

response will be 00000001

Now DELTA is in WRITE MODE. ANY typo may well corrupt internal data structures.

Examine the contents of an address by typing FFFFFFFF ( 8 F's) followed by the address followed by a slash "/"
(8 F's on AXP only, that's the extra 32 bits)
DELTA will respond with the contents of that address
>>>> do NOT use the return key!!!!

Now enter your calculated new hex value for this field.

Repeat this for the 3 fields in the correct order.

EXIT

8.
Logout (of spawned proc)
sda>show proc will show added BUFIO count/limit
9.
'release' the process, the execute its next instruction ( DELPRC)
Almost anything will do, eg
sda> sho proc/chan

sda>sho proc -- probably already gone.

But: let me finish be warning again!
ANY typo in DELTA can cause ANY unwanted effect!!

but the again:
there were several times when I was very glad to be able to do this!

hth

Jan

Re: FREE_RSN on alpha ?

Wim Van den Wyngaert — Thu, 02 Sep 2004 04:32:56 GMT

Thanks Jan but seems to risky to execute in production. If we have the problem in test I will try it.

On the Sybase level I think you are wrong.
I investigated it too and found that the documentation is no longer valid.

I found new rules (never implemented because Sybase team is not interested in solving the problem).

DIOLM : add the number_of_user_connections to the old formula
BYTLM : add the number_of_user_connection * 20000 to the old formula

And above all : check with lexicals that you got what you asked (or more, but how is Sybase handling that ?).

Restarting every night is not an option on out site.

Wim

Re: FREE_RSN on alpha ?

Ian Miller. — Thu, 02 Sep 2004 05:04:04 GMT

The procedure with SDA & DELTA does work but is only worth doing on a system without AMDS due to the possibility of error.

I'm curious about the previous statement
"Opcom reported "process xxx modified".
But the quota remained the same."

This appears to be saying the AMDS fix did not change the BYTLM quota which is curious.

What FREE_RSN.MAR appears to do for processes in a MWAIT state waiting for BYTLM is add the value of the system parameter MAXBUF to the BYTLM quota limit and remaining amount. You are doing a similar thing with AMDS.