Conference clt::sort32

306.0. "HYPERSORT -- ACCVIOs and bogus status" by CSC64::HENNING (A rose with no thorns) Mon Jun 02 1997 20:43

    Customer has reported that HYPERSORT is failing on OpenVMS Alpha V7.1. 
    He sees 2 types of problems.  I haven't reproduced problem 1 yet,
    because WSMAX on our V7.1 system is too low.  Will work on that.  I
    have reproduced problem 2 and see that it's been QAR'd to EVMS-RAVEN,
    #1088.  Am planning to IPMT both, but would like your comments first. 
    Any other previous reports of these symptoms?
    
    1  When his process's WSEXTENT=524288 (thanks to PQL_MWSEXTENT), SORT 
       fails with an ACCVIO:
    
       $ DEFINE SORTSHR SYS$LIBRARY:HYPERSORT.EXE
       $ SORT/KEY=(POS=1,SIZE=80)/STAT SYS$MANAGER:OPERATOR.LOG OUTPUT.DAT
    
       SYSTEM-F-ACCVIO, access violation, reason mask=00,
           virtual address=7AF77B10, PC=00000000 00099B0C, PS=0000001B
    
       Improperly handled condition, image exit forced
      
        Signal arguments:   Number = 0000000000000005
                            Name   = 000000000000000C
                                     0000000000010000
                                     000000007AF77B10
                                     0000000000099B0C
                                     000000000000001B
        Register dump:
        R0  = 000000000000000C  R1  = 0000000000A0BB30  R2  = 0000000000062D60
        R3  = 00000000000D6008  R4  = 00000000001092A0  R5  = 0000000000238820
        R6  = 0000000000000001  R7  = 0000000000000000  R8  = 0000000000000000
        R9  = 000000007FFAC410  R10 = 000000007FFAD238  R11 = 000000007FFCE3E0
        R12 = 0000000000000000  R13 = 000000007B0441E0  R14 = 0000000000000000
        R15 = 00000000009B4ED0  R16 = 00000000001092A0  R17 = 000000000012E390
        R18 = 00000000000D6008  R19 = 0000000000109290  R20 = 00000000000250F0
        R21 = 0000000000000000  R22 = 0000000000000000  R23 = 0000000000000000
        R24 = 0000000000000001  R25 = 00000000000250F0  R26 = 0000000000099AA0
        R27 = 0000000000062CF0  R28 = 0000000000000000  R29 = 000000007AF79AC0
        SP  = 000000007AF79AC0  PC  = 0000000000099B0C  PS  = 000000000000001B
    
      The same SORT completes w/o error when he deassigns SORTSHR:
    
      $ DEASSIGN SORTSHR
      $ SORT/KEY=(POS=1,SIZE=80)/STAT SYS$MANAGER:OPERATOR.LOG OUTPUT.DAT
    
                      OpenVMS Sort/Merge Statistics
      
        Records read:        77657         Input record length:       83
        Records sorted:      77657         Internal length:           85
        Records output:      77657         Output record length:      83
        Working set extent: 524288         Sort tree size:         78032
        Virtual memory:      15424         Number of initial runs:     0
        Direct I/O:            109         Maximum merge order:        0
        Buffered I/O:           11         Number of merge passes:     0
        Page faults:           998         Work file allocation:       0
        Elapsed time:  00:00:03.39         Elapsed CPU:      00:00:00.48
    
    2  If he decreases WSEXTENT to the value in his UAF record, the SORT
       completes but generates bogus statistics:
    
       $ SET WORK/EXTENT=16384
       $ SHOW WORK
       Working Set (pagelets)  /Limit=3594 /Quota=6752 /Extent=16384
       Adjustment enabled      Authorized Quota=6752 Authorized Extent=524288
       ...
    
       $ DEFINE SORTSHR SYS$LIBRARY:HYPERSORT.EXE
       $ SORT/KEY=(POS=1,SIZE=80)/STAT SYS$MANAGER:OPERATOR.LOG OUTPUT.DAT
    
                      OpenVMS Sort/Merge Statistics
    
        Records read:           0          Input record length:        0
        Records sorted:         0          Internal length:            0
        Records output:         0          Output record length:       0
        Working set extent: 16384          Sort tree size:             0
        Virtual memory:     22928          Number of initial runs:     0
        Direct I/O:           117          Maximum merge order:        0
        Buffered I/O:           4          Number of merge passes:     0
        Page faults:         4361          Work file allocation:       0
        Elapsed time: 00:00:03.39          Elapsed CPU:      00:00:00.48
    
        The output file is identical to the output file created by the
        successful sort in item 1 (SORTSHR not defined).
    
    
    Background info:
    
            Image Identification Information
    
                    image name: "HYPERSORT"
                    image file identification: "V03-001"
                    image file build identification: "X6C7-0040069227"
                    link date/time: 25-NOV-1996 21:54:10.34
                    linker identification: "A11-39"
    
    
    Thanks in advance!
    Mary
    

In regard to the problem with using the HYPERSORT image and trying to
display statistical summary information -

    The behavior the customer is seeing is correct.  This feature is currently 
    unsupported by the High-Performance Sort/Merge utility.  Differences 
    in behavior between the 2 utilities are documented in the OpenVMS 
    documentation in the sections pertaining to the Sort/Merge and 
    High-Performance Sort/Merge utilities.  

    Invoking HELP for the /STATISTICS qualifier of the SORT command also 
    displays information indicating that this is unsupported.  We will
    consider removing this restriction in a future release of OpenVMS.


			S. Lavigne

    Thank you!  If there are no other reports of the ACCVIO, I'll IPMT
    problem #1.