STOP/ID for process in LEF

[Ruslan R. Laishev]

Hello Martin,

No, WASD (8.4.x) was in last case. Before this it was POP3 server, MadGoad MX5.x /Local agent...

[labadie_1]

Ruslan

could you post the result of

$ set term/wid=132
$ prod sh prod/fu
$ prod sh hist /fu

And may be you should just take a crash, and send it to your support center :-)

[Ruslan R. Laishev]

I opened a ticket with HP-support and made two (2!!) crash from >>> of my production system - they said: "it's an application's problem"... Now, I'm just puzzled... and asked: "what I can do with process in LEF" at all... :(

[Willem Grooters]

Ruslan (and others)

A few very stupid ideas, but who knows....

* Is there ANY application running in your cluster that uses some resource named "Appender" within it's code? Lock management would know, I guess.
* Assuming APPENDER is locked when a file is to be extended (or created) - which is obvoius given it's name: From the listings, I can conlcude the file accessed is HTTPDLOG. What would happen if ONE process tries to do this twice - in separate threads, for instance? Then it would indeed be an application problem (shouldn't happen), but I's expect it to happen in that program, not in alternating ones....
* Same assumption: Could it be that there is actually a problem on another disk, if for some reason the resource is not freed....
* A long time ago I had a problem with locks as well: Requested a EX lock, wait until all other processes gave free and then get it. But the Blocking AST's released the lock and requested it directly - since there were still granted locks in that (non-EX) mode, these were granted directly. The EX lock was never granted for that reason. The mechanism of granting locks is clearly explaned in the Big Black Book for VAX/VMS (VMS internals and Data structures) but I guess the same principle still is valid.


Willem

[Ruslan R. Laishev]

Willem,
some other think: 27 efn is IMP$C_SYNCEFN (according to 7.3 sources).

$ search $2$DUA100:[000000.V73.RMS.LIS]*.* IMP$C_SYNCEFn
******************************
$2$DUA100:[000000.V73.RMS.LIS]RM0CACHE.LIS;1

00000C43 8652 $WAITFR_S EFN=#IMP$C_SYNCEFN ; Wait for flag to get set
0000147A 11918 ; IMP$C_SYNCEFN (27) of the next process waiting for
00001497 11966 MOVZBL #IMP$C_SYNCEFN, R3 ; Get event flag number to set
IMP$C_SYNCEFN = 0000001B X

******************************
0000068D 5815 $WAITFR_S EFN=#IMP$C_SYNCEFN ; Wait for flag to get set
IMP$C_SYNCEFN = 0000001B

...

Call Frame at 00000000.7B0FDBF8
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.80154920 SYS$WAITFR_C
Return address on stack = FFFFFFFF.804A74D4 RMS+574D4

Registers saved on stack
------------------------
7B0FDC18 00000000.00002200 Saved R2 DLL$_NO_SUCH_ENTITY+0015C
7B0FDC20 00000000.00000000 Saved R3
7B0FDC28 FFFFFFFF.8CA32C30 Saved R13 RMS+C5830
7B0FDC30 00000000.7B0FDE18 Saved R29
SDA>

Possible call frame at 00000000.7B0FDC28
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.804A7460 RMS+57460

SDA>
Possible call frame at 00000000.7B0FDC60
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.804A67F0 RMS+567F0

SDA>
Possible call frame at 00000000.7B0FDCA0
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.804A5550 RMS+55550

SDA>
Possible call frame at 00000000.7B0FDCE0
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, No Jacket, Native
Procedure Entry: FFFFFFFF.804C7700 RMS+77700

SDA>
Possible call frame at 00000000.7B0FDCF8
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, No Jacket, Native
Procedure Entry: FFFFFFFF.804CFCF0 RMS+7FCF0

SDA>
Possible call frame at 00000000.7B0FDD28
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, No Jacket, Native
Procedure Entry: FFFFFFFF.804CBDA0 RMS+7BDA0

SDA>
Possible call frame at 00000000.7B0FDD48
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, No Jacket, Native
Procedure Entry: FFFFFFFF.804C60F0 RMS+760F0

SDA>
Possible call frame at 00000000.7B0FDD90
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, No Jacket, Native
Procedure Entry: FFFFFFFF.804C5550 RMS+75550

SDA>
Possible call frame at 00000000.7B0FDDB8
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, Jacket
Procedure Entry: FFFFFFFF.80099A00 EXE$CMODEXECX_C

SDA>
Possible call frame at 00000000.7B0FDDE0
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.804B4B20 RMS+64B20

SDA>
Call Frame at 00000000.7B0FDE18
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.8049B158 RMS+4B158
Return address on stack = FFFFFFFF.80067AC4 EXE$KP_START_C+002A4

Registers saved on stack
------------------------
7B0FDE38 FFFFFFFF.8CA2FF30 Saved R13 SYS$CVT_FILENAME+00360
7B0FDE40 00000000.00000000 Saved R29
SDA>
SDA> sho call/next
%SDA-E-NOTINPHYS, 00000000.00000000 : virtual data not in physical memory
SDA>



PS:I cannot found APPENDER in all WASD sources.

[Hein van den Heuvel]

Hey there, I'm afreaid I haven't found the time to follow this this discussion at the level of detail it needs.

Just want to confirm that RMS indeed uses a lock called 'APPENDER' to faciliate multiple writers to a shared sequential file. It is a cached lock used to offload the rms filelock of which it is a child and which manages the current end-of-file block + byte which are ofcourse criticl in knowing where to write next.

As the attentive reader can see in the crashdump log, those locks are help in executive mode and cn not ohave a confict with userlocks. (If user starts to take out those locks in that mode they darn well know they are asking for trouble).

Again, I did not read all details but if you believe not did I check the patch you mentioned earlier, but it sounds like you might have run into a new problem and you might want to wrap up the essential details from this topic, a couple of sda logs, a rught appliction status and submit the lot to support.

Cheers,
Hein.

[Ruslan R. Laishev]

Hello Hein,
ticket was opened, and hidden answer from HP-support I posted here. I had installed F11 ECO...

Hein, is there something which I can check with SDA myself?

[Ruslan R. Laishev]

Hi All!

Just FYI, there is a RMS ECO is related to the problem in testing...