Conference clt::cms

2481.0. "ACCVIO when reference copy on." by CSC32::EHA (Flip) Wed Apr 16 1997 12:12

    Hello,
    
    I have a customer that is having a problem verifying a library under
    specific conditions.  If the user has the reference copy turned on for
    the library, they get an ACCVIO and a regester dump:
    
%CMS-I-VERREF, referemce copy for element
PUB4:[CONFIG.PROJECTS.SERPOS.ELEMENTS]
0112.ZIP verified
%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual adderss=0249FA80,
PC
=0008B7F2, PSL=03C00000

  Improperly handled condition, image exit forced

    Signal arguments		Stack contents

    Number = 00000005		02487A40
    Name   = 0000000C		009C872A
	     00000005		000CC108
	        .
		.
		.
    
    I can get the rest of the dump if you want.
    
    When they set the /noref on the library, the verify succeeds.  Now for
    something realy strange.  When they verify specific files, the verify
    is successful.  When they group the files together, they get strange
    results:
    
$ cms verif 009%.*, 01%%.*   !Fail at 0113
$ cms verif 01%%.*           !Passed
$ cms verif 0096.*,0098.*,0099.*, 01%%.*   !Passed
$ cms verif 0095.*, 0096.*,0098.*,0099.*, 01%%.*   !Fail at 0113
$ cms verif 0095.*, 0096.*,0098.*,0099.*, 010%.*, 011%.*, 012%.*, 013%.*   !Fail 
at 0113
$ cms verif 0095.*, 0096.*,0098.*,0099.*, 010%.*, 0112.*, 0119.*, 012%.*, 013%.* 
  !Fail at 0131


    I have the size of the files, but I don't know if this is a listing of
    the delta files or the actual fetched files.
    
0000.W61;1              106
0016.W61;1              810
0018.W61;1              371
0019.W61;1              133
0020.W61;1             7167
0021.W61;1            16817
0025.W51;1              306
0026.W51;1              429
0029.W51;1              305
0029.ZIP;1              154
0033.W51;1              635
0035.W51;1              269
0036.W51;1             1187
0037.W51;1              594
0038.W51;1              148
0039.W51;1              832
0040.W51;1              111
0042.W51;1              645
0043.W51;1              592
0044.W51;1              365
0045.W51;1              345
0047.W51;1              177
0056.W61;1             4257
0065.W61;1             5254
0066.W61;1              574
0067.W61;1             7393
0068.DS4;1              282
0069.DS4;1              326
0070.DS4;1              267
0071.DS4;1              321
0072.DS4;1               58
0073.DS4;1               10
0075.W61;1              461
0086.W61;1              468
0089.W61;1             1476
0095.W61;1             1182
0096.W61;1            46342
0098.W61;1              249
0099.ZIP;1              235
0100.W61;1              472
0101.W61;1               99
0102.W61;1             4921
0112.ZIP;1               57
0113.W61;1            13025      <<<--- failed when all elements verified
0119.W61;1              895
0123.W61;1             1687
0125.W61;1             4360
0126.DS4;1              304
0128.W61;1            16396
0129.EXE;1             6126
0130.W61;1             1903
0131.W61;1             9332      <<<--- failed one of the group tests
0134.W61;1             2684

Total of 53 files, 163914 blocks.
    
    Originaly I thought that the problem had something to do with the
    library being maintained with a CMS version prior to 3.5, but it still
    happens after they upgraded to CMS 3.8-2 on a VAX.  The files in
    question are word perfect files, but are in valid RMS formats.  
    
    What questions/information do you need from the customer and what
    suggestions can I pass to them?
    
    I have suggested that they set the elements that have been failing to
    /noref untill we have a better answer.  I haven't received word on how
    that is working. 
    
    Thank you!
    Al

Hi Al,
    
Sorry for not replying quickly,

I think the problem may be caused by corrupted libraries. Do you know what 
version of CMS they used to create original element ? Did they clean up 
their library before they upgraded to CMS 3.8-2. 
    
I don't know if this help but they may try deleting the reference copy of the 
specific files (Note: not the element), then use CMS verify/repair to recreate 
the reference copy.

-James

    James,
    
    They have deleted the reference copies and re-created them using the
    VERIFY/REPAIR.  They still have the problem after the reference files
    are fetched through the verify command. 
    
    As to the version of CMS that created the library, I/they think it was
    3.5-1 or 3.4 of CMS. 
    
    Sorry there is no better information at this time.
    
    Thanx!
    Al

    Hi Al,
    
    Can we take a look their library ?
    
    -James

    James,
    
    I am trying to get their library now.  Will take this offline.
    
    Thanx!
    Al