Conference orarep::nomahs::dec_data_distributor

222.0. "HELP!!! LINKABORT - no clue" by ORAREP::VAXRIO::63198::CSANTOS (Claudia Nogueira - CSC/Brazil) Thu Jun 13 1996 12:00

	Hi,

	Need some help here!!!  We have a customer with a transfer that
	fails with LINKABORT...  I've checked all the logs ans no clues
	of what it could be... Any hints??  
	

				Thanks

					Claudia

	PS: The transfer works fine once in a while...


	Log files:

	NETSERVER.LOG
 	-------------


        --------------------------------------------------------

        Connect request received at 13-JUN-1996 11:26:40.58
            from remote process V2700D::"0=NS62"
            for object "SYS$COMMON:[SYSEXE]RDBSERVER.COM"

        --------------------------------------------------------

Running SYS$COMMON:<SYSEXE>RDBSERVER.EXE...
*** 13-JUN-1996 11:26:40.97 : *** 13-JUN-1996 11:26:40.97 :  been 
acknowledged
 V6.1-03 RdbServer: Keyword values negotiated between client and server...
    NETWORK_BUFFER_SIZE: 4096
    MESSAGE_VECTOR_RETURN_TYPE: Internal
 These keywords are client specific and are not transmitted:
    NETWORK_NUMBER_ATTACHES
    RCV_PREFETCH_ROWS
    SGS_PREFETCH_ROWS
  NS60         job terminated at 13-JUN-1996 11:32:03.36

  Accounting information:
  Buffered I/O count:             268         Peak working set size:  14640
  Direct I/O count:               205         Peak page file size:    67456
  Page faults:                   1132         Mounted volumes:            0
  Charged CPU time:           0 00:00:00.73   Elapsed time:     0 
00:05:23.15


---------------------------------------------------------------------------

	TRANSFER LOG

$!
$! This command procedure is always run when anybody on the entire system
$! logs in. It is equivalent to LOGIN.COM except that the instructions
$! contained herein are executed everytime anyone on the VMS system
$! logs in to their account.
$!
$! For interactive processes, turn on Control T, and set the terminal type
$!
$ mode = f$mode()
$ tt_devname = f$trnlnm("TT")
$ session_mgr_login = (mode .eqs. "INTERACTIVE") .and.  -
    (f$locate("WSA",tt_devname) .ne. f$len(tt_devname))
$ session_detached_process = (mode .eqs. "INTERACTIVE") .and. -
    (f$locate("MBA",tt_devname) .ne. f$len(tt_devname))
$ unknown_devtyp = (mode .eqs. "INTERACTIVE") .and. -
    (f$getdvi("sys$command","devtype") .eq. 0) 
$!
$ if (mode .eqs. "INTERACTIVE") .and. unknown_devtyp .and. .not. -


     (session_mgr_login .or. session_detached_process)
$ endif
$!
$ if (mode .eqs. "INTERACTIVE") .and. .not. -
     (session_mgr_login .or. session_detached_process)
$ endif
$ ED*IT :== EDIT/EDT
$ CLS :== SET TERM/WIDTH=80
$ DEL*ETE :== DELETE/CONFIRM
$ RDO :== MCR RDO
$ SQL :== MCR SQL$
$!
$! MicroVAX Support Removed from OpenVMS Alpha
$!
$! Place your site-specific LOGIN commands below
$!
$ SET VERIFY
$ SHOW = "SHOW"
$ RUN = "RUN"
$ LOGOUT = "LOGOUT"
$ SHOW PROCESS 

13-JUN-1996 11:30:43.59   User: NS62             Process ID:   000011BD
                          Node: V2700D           Process name: 
"DDAL_COPY_01   "

Terminal:           MBA7908:
User Identifier:    [NS62]
Base priority:      4
Default file spec:  DISCO02:[REPLAN.SNS62SIS.SNS62DCL]
$ DEFINE DDAL$CP_CONTINUE "SUCCESS"
$ DEFINE/TRANS=TERMINAL DDAL$TRANSFER_NAME SEQUAL_PARA_BDO
$ DDAL$CP_ACTION :== U
$ DDAL$CP_RETRY_ITERATION == 00
$ RUN DDAL$COPY_PROCESS

Product version:        DEC Data Distributor V6.0-0
----- 13-JUN-1996 11:30:44.24 ----- Process         
-------------------------
Process name:  DDAL_COPY_01                  Priority:  4                  
     
Username:  NS62                              UIC:  [NS62]                  
     
Nodename:  V2700D                            PID:  000011BD                
     
Privileges currently enabled:
    TMPMBX, NETMBX, BYPASS

Image privileges:
    SYSPRV, BYPASS, SYSLCK, SECURITY

Image name:
    V2700D$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DDAL$COPY_PROCESS.EXE

Transfer database = SYS$COMMON:[SYSEXE]DDAL$TR_DB
Transfer name     = SEQUAL_PARA_BDO                

Transfer option   = U (Replication update transfer)

11:30:44  %DDAL-I-READTRDEF, reading the transfer definition from the 
transfer *
11:30:46  %DDAL-I-ATTACHSDB, attaching to source database 
V2700D$DKA200:[REPLAN*
11:30:47  %DDAL-I-ATTACHTDB, attaching to target database BDO
11:30:49  %DDAL-I-STADATTRM, starting data transfer/modification
----- 13-JUN-1996 11:31:10.38 ----- Error           
-------------------------
%RDB-F-IO_ERROR, input or output error
-SYSTEM-F-LINKABORT, network partner aborted logical link

$ @DDAL$EPILOGUE 
V2700D$DKA200:[REPLAN.SNS62SIS.SNS62DCL]TRANSFERS_EPILOGUE.COM 
$ GOTO Skip_Comments
$ Skip_Comments:
$
$!  Save the return status from the DDAL$COPY_PROCESS image in 
DDAL$SAVE_STATUS.
$
$       DDAL$SAVE_STATUS :== %X012683A3


$       ON SEVERE_ERROR THEN GOTO Cleanup
$
$!  DEFINE DDAL$CP_CONTINUE based on the status value received from the
$!  DDAL$COPY_PROCESS image.
$!
$!  SUCCESS   = DDAL$COPY_PROCESS succeeded
$!  RETRY     = DDAL$COPY_PROCESS failed but should be retried
$!  PRO_RETRY = The prologue failed.  The transfer should be retried.
$!  PRO_FAIL  = The prologue failed.  The transfer should not be retried.
$!  FAIL      = Anything else should be a copy process failure that should 
not
$!              be retried.
$
$       IF DDAL$SAVE_STATUS .EQ. %X012683AB
$       ELSE
$           IF DDAL$SAVE_STATUS .EQ. %X012683A3
$           THEN

	...







	

    
    Claudia,
    
    Well, the netserver.log file gives no clue as to why the rdbserver
    process went away.  I suggest you consult with the Rdb engineers to see
    if there's some way to get more information logged in netserver.log.
    
    From that log file, it would seem that the RDBSERVER process actually
    got started.  If that were not the case, a timeout could have happened. 
    There is a time limit in DECnet for objects to establish a connection
    between client and server.  I think we have something about this in the
    Data Distributor handbook or installation guide.
    
    Claude

	Claude,

	Yes, the server process is started ok... I can see at the RDB
	monitor logfile that the connection to the database was fine,
	but for some reason the process ends up abnormaly.

	I'll cross poste it with the rdb notesfile...


			Thanks

				Claudia

    
    For the record, the customer was able to reproduce the problem without
    using Data Distributor.  It had something to do with a table with a
    complex trigger and function callouts.