Conference orarep::nomahs::rdb_60

Getting a few of these in 6.1-04.  Was it fixed in 6.1A or 7?  Cant find it in
the rel notes.

	Cheers,
		Rich.

This problem is actually an AXP/VMS problem with the "C" runtime library.

The problem has been worked-around in Rdb7 but the fix has not been back-ported
to earlier versions.  (I had to write my own super-efficient "quick sort"
algorithm, so the back-port should not be too hard when I have the time :-)

Rick

  <<< Note 3278.18 by NOVA::R_ANDERSON "Oracle Corporation (603) 881-1935" >>>
                            -< Fixed in Rdb7 only >-

>>(I had to write my own super-efficient "quick sort"
>>algorithm, so the back-port should not be too hard when I have the time :-)

Rick, you continue to amaze me!

Thanks, Liz, your pretty cool too!
	
	Rick Virr.
 
I spoke to the customer who was getting this bugcheck.  They hadn't seen the
problem with thier rdb7 development system, but were getting a new show stats
bugcheck at kutdis$analyz_lck_actrtn + edc.  

One of those days..... This has been bugged as 460661.

>I spoke to the customer who was getting this bugcheck.  They hadn't seen the
>problem with thier rdb7 development system, but were getting a new show stats
>bugcheck at kutdis$analyz_lck_actrtn + edc.  

I think this has been fixed in ECO1, but I'd have to see the actual bugcheck
dump to be sure...

Rick

<<< Note 3278.20 by UKVMS3::RVIRR "Syntax is all the money collected at the church from sinners." >>>
                     -< Rick, you continue to amaze me!
 >-

>>Thanks, Liz, your pretty cool too!
	
>>	Rick Virr.
 
Very funny :-).

Rick,

>> I think this has been fixed in ECO1....

This is one of our sites testing the new beta of 7.0.1!  Your more than welcome
to take a look at the bugcheck, I'll post it if you want.
 
They've just got the latest version of the eco released about a week ago and
they havent reported this problem since.

	Cheers,
		Ric(k).  

>This is one of our sites testing the new beta of 7.0.1!  Your more than welcome
>to take a look at the bugcheck, I'll post it if you want.

No way!  (just kidding)

Can you please email me the bugcheck or post a pointer to it (DO NOT post the
bugcheck in this notesfile!!!).

Rick

Rick,
	Its bugged as 460661, but if you want a peek its in:
UKVMS3::DISK$RDB2:[RVIRR.COPY_FILES.854032]prob.fil and RMUBUGCHK.DMP.
That would be most appreciated.  The customer was a bit upset to discover that
we'd solved one show stats bugcheck only to find another!

Just after the bugcheck a distributed process started to stall.  We looked at
LMCP which failed to show the active transaction (we've applied the relavent AXP
patches).  We tried the show stats again, another bugcheck, only after we killed
this process did the show stats work.
 
The customer was understandably worried (as all thier transactions are
distributed), hence the sev 2 bug.

	Cheers,
		Ric.

    I hardly think a SHOW STATS bugcheck can be called a priority 2
    problem.  
    
    Also, RMU/SHOW STATS bugchecks can hardly be linked to
    a distributed process stalling - that's stretching things a bit.
    
    IMHO.
    
    Rick

    Just for future reference, the bugcheck in .25 is the
    KUTDIS$ANALYZ_LCK_ACTRTN bugcheck, NOT the KUTDIS$SORT_FIO_SUM_ACTRTN.
    
    I still have not seen a KUTDIS$SORT_FIO_SUM_ACTRTN since I fixed it
    for Rdb7 ECO1.
    
    A fix for the KUTDIS$ANALYZ_LCK_ACTRTN bugcheck is forth-coming.
    
    Rick

    >Just after the bugcheck a distributed process started to stall.  We
    >looked at
    >LMCP which failed to show the active transaction (we've applied the
    >relavent AXP
    
    It looks like the stalled distributed process is causing the SHOW STATS
    bugcheck.  A fix for this problem is being tested.
    
    Rick