Conference orarep::nomahs::rdb_60

4967.0. "RMUBCK$ASSIGNED_DBF +58C" by M5::BLITTIN () Mon Jan 27 1997 14:43

    
    RDB 6.1; VMS 6.2 (VAX)
    TZ86 on HSJ004
    
    Customer backing up db using two tapes on a TZ86 loader with
     
     rmu/backup/online/rewind/log/crc=checksum/block=32768 dbname -
    	mua3:db.rbf,mua4:
    
    and getting bugchecked with 
    
      RMUBCK$ASSIGNED_DBF +58C
      SYSTEM-F-ROPRAND, reserved operand
    
    If he reruns the job, it is successful.  Had been doing single thread
    backup with no problem.
    
    Thank you....
    
    =====================================================================
    
    Additional bugcheck info...
    
    ***** Exception at 0010FC70 : RMUBCK$ASSIGN_DBF + 0000058C
    %SYSTEM-F-ROPRAND, reserved operand fault at PC=0010FC70, PSL=03C00000
    
    	Handler = 00000000, PSW = 0000, CALLS = 0, STACKOFFS = 0
    	Saved AP = 7FD4905C, Saved FP = 7FD49020, PC Opcode = 05
    	120 bytes of stack data from 7FD48FA8 to 7FD49020:
    7FD48FB87FD48FD00000000294D3764D  0000   'Mv�..... .�. .�.'
    00000012000000027FD4959800000004  0010   '......�.........'
    00000454000000030300000100411688  0020   '..A.........T...'
    0088804800883C1003C000000010FC70  0030   'p�....�..<..H...'
    00000008008889C000888768008882B8  0040   ' ...h...�.......'
    00000244000002440000024400000008  0050   '....D...D...D...'
    00000000000022000000024800000244  0060   'D...H...."......'
                    00888020008889B0  0070   '�... ...'
    
    
    Saved PC = 80000014 : S0 address
    No arguments
    ----------------------------------------------------------------
    	Handler = 0010FF55, PSW = 0000, CALLS = 1, STACKOFFS = 0
    	Saved AP = 7FD49564, Saved FP = 7FD49528, PC Opcode = D0
    SR2 = 00000000
    SR3 = 0041217C: 00000000 00000000 00000000 00000000 06D29250 05B002B0
    06D29250
    SR4 = 00411688: 41168800 00000000 7FD49564 7FD49528 00000000 00885E20
    006FBC10
    SR5 = 00000000
    SR6 = 006F3810: 00000FF4 000003E8 00000005 00000C31 0000015D 415D02BA
    00000000
    SR7 = 00411930: 009904A8 C222AE80 00000000 00000000 0000003D 544F4F52
    534D4452
    SR8 = 0087BC10: 00000202 02022000 0087DDE0 0087DDCC 0087DD90 00878950
    00883C10
    SR9 = 0087AB60: 0087AF58 00000036 0087AF10 00000036 00000000 00000000
    00000000
    SR10 = 0069C610: 00000FEF 00000FEC 00000005 00020FD1 0000015E 00010001
    00000000
    SR11 = 000002BA: 20132D20 4C552120 53492054 554F454D 49545F4E 574F4454
    55485320
    
    

>    RDB 6.1; VMS 6.2 (VAX)

	if this is really 6.1 (with no ecos or anything), then
I'd
first encourage the customer to upgrade to the latest 6.1 release
(6.1A I think).  We've fixed plenty of memory corruptions since
6.1 was shipped. Will it solve this particular problem?  No way
to know for sure.

                       <<< Note 4967.0 by M5::BLITTIN >>>
                         -< RMUBCK$ASSIGNED_DBF +58C >-

Bob, does it work if he does not use /ONLINE?  Does it usually fail if he
does use /ONLINE?

liz

    
    Don't think so, but I'll ask.  Doubt that the ct (att wireless) wants
    to kick the users out...but it may be worth a shot to identify the
    problem.  I'll ask...
    
    Thank You....

    
    Additional info...
    
    The ct has a duplicate job that backs up another db (same size,
    version) to the same loader (diff tapes) using same command stream
    that runs fine.  
    
    On the one that fails, if he runs the backup interactively, it works
    fine.  He has changed tapes units (in command procedure) without
    any success.  If he plays (resubmits the job), it will eventually
    work after several (8-10) resubmissions.
    
    Both jobs are run from the same batch que at different times. 
    Currently at RDB V6.1-3...has the eco-4 savesets and has applied
    them to his dev system.  
    
    Again...process worked until he went from a single tape backup to
    a multiple(2) tape backup process.

    re: .4
    
    CT reported that job that had been failing, has run for the past
    several days, and then failed.  Again, another process that uses the
    same command, diff db, runs fine all the time.  Both dbs were converted
    from 4.1 to 6.1 at the same time (relatively speaking). The only
    difference between the two processes is that the one that works is
    submitted first (few minutes before the second (failure) one). CT is
    going to switch these to see if it makes any difference.  CT will also
    be upgrading to 6.1a