[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dec_data_distributor

Title:The Replication Option for Rdb
Notice:Product renamed to Replication Option for Rdb
Moderator:BROKE::PROTEAU
Created:Wed Mar 02 1994
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:287
Total number of notes:1231

216.0. "BAD_REQ_HANDLE" by ORAREP::VAXRIO::CSANTOS () Mon May 27 1996 12:11

    
    
    	Hi,
    
    
    	Why could a transfer be reporting BAD_REQ_HANDLE??
    
    
    				Thanks in advance
    
    						Claudia
    
    
    	Transfer log:
    
    $ set noon
    $ SET NOver     !    In�cio do SUAP.
    $ SHOW = "SHOW"
    $ RUN = "RUN"
    $ LOGOUT = "LOGOUT"
    $ SHOW PROCESS 
    
    27-MAY-1996 11:48:04.03   User: NS60             Process ID:   0000D791
                              Node: C28509           Process name:"DDAL_COPY_01   "
    
    Terminal:           MBA1686:
    User Identifier:    [SETINF,NS60]
    Base priority:      4
    Default file spec:  DISCO03:[REVAP.SNS60SIS.SNS60DCL]
    $ DEFINE DDAL$CP_CONTINUE "SUCCESS"
    $ DEFINE/TRANS=TERMINAL DDAL$TRANSFER_NAME NOPE_PARA_SEQUAL
    $ DDAL$CP_ACTION :== I
    $ DDAL$CP_RETRY_ITERATION == 00
    $ RUN DDAL$COPY_PROCESS
    
    Product version:        DEC Data Distributor V6.0-0
    
    ----- 27-MAY-1996 11:48:04.90 ----- Process -------------------------
    Process name:  DDAL_COPY_01                  Priority:  4                  
    Username:  NS60                              UIC:  [SETINF,NS60]          
    Nodename:  C28509                            PID:  0000D791               
    Privileges currently enabled:
        TMPMBX, NETMBX, BYPASS
    
    Image privileges:
        SYSPRV, BYPASS, SYSLCK, SECURITY
    
    Image name:
        C28509$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DDAL$COPY_PROCESS.EXE
    
    Transfer database = SYS$SYSROOT:[SYSEXE]DDAL$TR_DB
    Transfer name     = NOPE_PARA_SEQUAL               
    Transfer option   = I (Initial replication transfer)
    
    11:48:04  %DDAL-I-READTRDEF, reading the transfer definition from the transfer *
    11:48:06  %DDAL-I-ATTACHSDB, attaching to source database DKB100:[REVAP.SNS60SI*
    11:48:11  %DDAL-I-STOTRADEF, storing transfer definition in DKB100:[REVAP.SNS60*
    11:48:11  %DDAL-I-ALREDYSTO, transfer definition already stored in source datab*
    11:48:11  %DDAL-I-ATTACHTDB, attaching to target database BDO_SEQUAL
    11:48:13  %DDAL-I-STADATTRM, starting data transfer/modification
    
    11:48:14  %DDAL-I-LOARELDAT, loading data for relation RDB$VINTAGE
    
    11:48:21  %DDAL-I-DELRELDAT, deleting data for relation NOPE_PARA_SEQUAL
    ----- 27-MAY-1996 11:48:22.07 ----- Error       -------------------------
    %DDAL-E-ERRACCDSTDB, error occurred accessing the destination database
    -DDAL-E-SUPP, %RDB-E-BAD_REQ_HANDLE, invalid request handle
    
    $ @DDAL$EPILOGUE DKB100:[REVAP.SNS60SIS.SNS60DCL]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 :== %X0126839B
    $       ON SEVERE_ERROR THEN GOTO Cleanup
    $
                   ...
    
    
    
    Transfer:
    
    
    Definition for transfer NOPE_PARA_SEQUAL:
    Definer                 NS60        
    Type                    REPLICATION
    From                    DKB100:[REVAP.SNS60SIS.SNS60RDB]BDO.RDB
    To                      Existing BDO_SEQUAL
    Log file               
    DKB100:[REVAP.SNS60SIS.SNS60LOG]NOPE_PARA_SEQUAL.LOG
    No prologue file
    Epilogue file          
    DKB100:[REVAP.SNS60SIS.SNS60DCL]TRANSFERS_EPILOGUE.COM
    Move table
        Select All
                NOPE_DH_GRAVACAO,
                NOPE_IN_TIPO_TRANSACAO,
                PROD_CD_ID,
                PRCO_CD_COMP_PROD,
                PRME_CD_ID,
                MEEN_CD_ID,
                GRCP_CD_ID,
                CAPR_CD_ID,
                CAPR_CD_COMP_CARAC,
                GUME_CD_ID,
                UNME_CD_ID,
                NOTA_CD_ID,
                NOTA_NR_SEQUENCIA,
                NOTA_NR_LINHA
            From NOPE_PARA_SEQUAL
            Into NOPE_PARA_SEQUAL
     
    
    Protection for transfer NOPE_PARA_SEQUAL:
        (IDENTIFIER=[SETINF,NS60],ACCESS=SELECT+ALTER+DROP+DBCTRL)
        (IDENTIFIER=[*,*],ACCESS=NONE)
     
    Schedule for transfer NOPE_PARA_SEQUAL:
    No schedule found
     
    Status for transfer NOPE_PARA_SEQUAL:
    State                   SUSPENDED since 27-MAY-1996 12:12:35.37
    Last completion status  severe transfer failure; not retrying
    
    
    
T.RTitleUserPersonal
Name
DateLines
216.1Internal software errorBROKE::PROTEAUJean-Claude ProteauMon May 27 1996 14:2023
    
    Bad request handle is typically an error in the software, in this case
    in Data Distributor (or possibly in Rdb).  A request handle is an
    internally-generated, short-hand method of identifying a database
    request to the datbase management system.  When a request is compiled,
    the request handle should have a null value, indicating that it is free
    to be assigned to the request being compiled.  Once the request has
    been compiled, other database requests to do something with the
    request, such as, start the request, send parameters to the request,
    receive answers back from the database system via the request, etc.
    These require a request handle to tell the database system which
    compiled request to work with.  If the error occurs then it could mean
    that the request was never compiled (a null request handle value), that
    the request was prematurely discarded (released), or that the request
    handle value has somehow been overwritten with a bad value.
    
    I suggest that the latest version of Data Distributor 6.0 be obtained
    from Oracle.  The current shipping version is V6.0-11.  If you find
    that the problem still persists, please submit a formal problem report
    through the appropriate support channel, and we'll investigate the
    reason for the failure.
    
    	Claude
216.2We are Oracle support down here...ORAREP::VAXRIO::CSANTOSMon May 27 1996 14:3415
    
    
    	Customer is already running 6.0, so I guess, all I need are the 
    	patches for that version.  I'm the Oracle support here in Brazil
    	(here, Oracle has an agreement with DEC so we still support all the
    	products they got from us).  What the Rdb folks usually do is that
    	they copy the pacthes over a DEC system and I copy it from there,
    	could you please do the same??
    
    
    				Thanks a lot
    
    
    					Claudia
    				
216.3I've forwarded your requestBROKE::PROTEAUJean-Claude ProteauTue May 28 1996 10:5311
    
    Claudia,
    
    Please send our request to [email protected].  Steve is the manager
    for Data Distrutor (now being called the Rdb Replication Option).  I've
    been told that the updated version of our product is now shipping
    from Oracle.  However, I don't know how the product is made available
    to existing customers.  I've forwarded your note to Steve, but it would
    be a good idea for you to send mail to him directly.
    
    Claude
216.4Information on how to orderBROKE::PROTEAUJean-Claude ProteauWed May 29 1996 10:549
    
    Claudia,
    
    I've spoken to Regina Phelps, who handles submission of our kits for
    production.  She will send you mail explaining how you can obtain the
    latest revision of DDD 6.0.  Regina can be reached via the internet
    at [email protected].
    
    Claude
216.5Location of the V6.0-11 savesetsBROKE::PROTEAUJean-Claude ProteauWed May 29 1996 20:4626
Claudia,

The revised Data Distributor 6.0 kit is located on node BROKE in our VMS
development cluster:

Directory DD$DISK:[KIT.DDAL.V60-11]

The VAX savesets:

DDAL060.A;1             414/416     17-APR-1996 15:03:35.57
DDAL060.B;1            1404/1404    17-APR-1996 15:03:39.74
DDAL060.C;1            2772/2772    17-APR-1996 15:03:50.92

The Alpha savesets:

DDALA060.A;1            414/416     17-APR-1996 15:07:05.71
DDALA060.B;1           2430/2432    17-APR-1996 15:07:09.27
DDALA060.C;1           2772/2772    17-APR-1996 15:07:23.11

Total of 6 files, 10206/10212 blocks.

If you have a way to copy these savesets from our system, fine. go ahead.
If you can't, we might have to set up a directory on some other machine
from which you can transfer via ftp.

Claude
216.6Open area for Digital folks ...ORAREP::ACAR::ETESTDBThu May 30 1996 12:527
    The RDB folks have the following area "ORAREP::ORAREP2:[RDB_V60_KIT]" 
    open for us Digital folks.  Could you put your KIT on this node so we
    can copy them. 
    
    rgds,
    james delahunty
    
216.7Kits for Digital Internal GroupsBROKE::PROTEAUJean-Claude ProteauThu May 30 1996 15:2717
    Re 216.6:
    
    James,
    
    I spoke to some of the Rdb folks.  I was told that a special program
    was set up so that Digital internal engineering groups could obtain the
    Oracle Rdb kits from the ORAREP node as you described.
    
    This same mechanism is not yet in place for the Replication Option for
    Rdb (aka Data Distributor) product.  It was suggested that you contact
    Andy Schneider at DTN 381-1696.  Andy was the person, I was told, who
    set up the program.  There may be information about it in the
    ORACLE_PROGRAM.NOTES conference on node ORAREP.  I assume Andy will
    arrange something with my manager to make our kits available in the same
    way as was done for Oracle Rdb.
    
    Claude
216.8kit availability via ftpBROKE::PROTEAUJean-Claude ProteauThu May 30 1996 15:4128
Claudia,

As an Oracle employee, you should be able to use FTP to copy the Replication
Option for Rdb (formerly DEC Data Distributor) savesets from any of the follow-
ing machines:  MOKLOC, DEBIT, KREDIT, SQLRUS, QUILL.  The user account FTP_KITS 
will put you in the directory where the files currently reside.

[If you are a Digital employee reading this note, you will not be able to access
the kits in this way.  These machines are not accessible from the Digital Engin-
eering network.]

The saveset files are these:

The following three files consitute the savesets for Data Distributor V6.0-11
for OpenVMS VAX:

DDAL060.A;1             414/414     17-APR-1996 15:03:35.57
DDAL060.B;1            1404/1404    17-APR-1996 15:03:39.74
DDAL060.C;1            2772/2772    17-APR-1996 15:03:50.92

The following three files consitute the savesets for Data Distributor V6.0-11
for OpenVMS Alpha (note the extra 'A' in the names):

DDALA060.A;1            414/414     17-APR-1996 15:07:05.71
DDALA060.B;1           2430/2430    17-APR-1996 15:07:09.27
DDALA060.C;1           2772/2772    17-APR-1996 15:07:23.11

- Claude
216.9BROKE:: decnet address ?b-w005.be.oracle.com::ALLEMEERSCHIn Flanders fields ...Mon Jun 10 1996 09:157
    Hello Claude,
    
    What is the decnet address of node BROKE:: within Oracle ?
    
    Thanks a lot.
    
    _Luc
216.10HOTRDB::PMEADPaul, [email protected], 719-577-8032Mon Jun 10 1996 10:221
    It is 43.159
216.11thanks Paulb-w005.be.oracle.com::ALLEMEERSCHIn Flanders fields ...Wed Jun 12 1996 12:501