Conference pamsrc::objectbroker

1371.0. "OBB 2.7-11 BANK.EXAMPLE5 does not make it." by EMNTAL::STADELMANN (Sepp @ZUO 760-2609) Mon Feb 17 1997 07:18

    Windows NT Server V4.0 (Server Pack 2)
    OBB 2.7-11 CLD
    
    OpenVMS 6.2
    OBB 2.7-11 CLD
    CXX 5.0
    
    on OpenVMS trying to @MAKE [.BANK.EXAMPLE5]
    
    the @make simply fails producing the following LOG file under Batch
    and ON-LINE.
    
^G		 "Batch login"

  17-FEB-1997 13:02:06
setting OBB to AXP/BANK5 project!
%DCL-I-SUPERSEDE, previous value of OBB_REPOSITORY has been superseded
  FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]

Building BANK5 application
  for Alpha AXP  (using IEEE-float)
  compiling and linking in production (nondebug) mode
  using installed ObjectBroker software

symbol working_dir currently defined as
  FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]

Logical OBB_REPOSITORY is not defined; will be defined as
  FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]BANK5.ir

======== Creating Context Object from BANK5.col . . .
$ APPL/BRO LOAD CONTEXT_OBJECT BANK5.COL /USER
$ APPL/BRO SHOW CONTEXT_OBJECT /USER

CONTEXTOBJECT

    TABLE OBB_DEFAULT_TABLE
        OBB_REPOSITORY : OBB_STRING =
            "bank5.ir";
    END TABLE

END CONTEXTOBJECT

 
========  Inserting UUID's into IDL file . . .
$ APPL/BRO GENERATE UNIQUE_IDENTIFIER /IDL_FILE=BANK.idl
 
========  Creating Repository (BANK5.ir) from IDL . . .
$ APPL/BRO LOAD REPOSITORY_OBJECT BANK.IDL /CREATE
 
========  Creating IML file from repository . . .
$ APPL/BRO COMPILE -
    BANK.idl  -
    /DEFAULT=IMPLEMENTATION=BANK5.IML
 
========  Loading IML file into repository . . .
$ APPL/BRO LOAD REPOSITORY_OBJECT BANK5.IML
 
========  Creating MML file from repository . . .
$ APPL/BRO compile -
     BANK.idl,BANK5.iml -
     /DEFAULT=MAPPING=BANK5.mml
 
========  Loading MML file into repository . . .
$ APPL/BRO LOAD REPOSITORY_OBJECT BANK5.MML
 
========  Generating Client Stubs from repository . . .
$ APPL/BRO compile  -
     BANK.idl  -
     /EXTERNAL -
     /STUB=(TYPECODES=BANK5TC.C,CLIENT=tempcs.c)
 
========  Generating Dispatcher from repository . . .
$ APPL/BRO compile  -
     BANK.idl,BANK5.iml  -
     /DISPATCHER=BANK5SD.C
 
========  Compiling Client . . .
$ CC /FLOAT=IEEE BANK5C
$ CC /FLOAT=IEEE BANK5TC
 
========  Compiling Server . . .
$ CC /FLOAT=IEEE BANK5S
$ CC /FLOAT=IEEE BANK5SM
$ CC /FLOAT=IEEE BANK5SD

#define TC_BANK_ERR_TYPES TC_330856df_0
..........................^
    
    %CC-W-MACROREDEF, The redefinition of the macro "TC_BANK_ERR_TYPES"
    conflicts with a current definition because the replacement lists
    differ.  The redefinition is now in effect. at line number 85 in file
    FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]BANK5SD.C;3

#define TC_BANK_WrongAcctId TC_330856df_1
............................^
    
    %CC-W-MACROREDEF, The redefinition of the macro "TC_BANK_WrongAcctId"
    conflicts with a current definition because the replacement lists
    differ.  The redefinition is now in effect. at line number 88 in file
    FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]BANK5SD.C;3

#define TC_BANK_InsuffFunds TC_330856df_2
............................^
    
    %CC-W-MACROREDEF, The redefinition of the macro "TC_BANK_InsuffFunds"
    conflicts with a current definition because the replacement lists
    differ.  The redefinition is now in effect. at line number 89 in file
    FBE1:[STADELMANN.PROJ.OBB.BANK5.AXP]BANK5SD.C;3 
    
    $exit:             !
    all errors come here directly $ close/nolog infile $ close/nolog
    outfile $ if working_dir_defined then deas working_dir $ save_verify =
    f$verify(00) 
    %SYSTEM-F-ABORT, abort STADELMANN   job terminated at
    17-FEB-1997 13:02:49.10 
  
    Accounting information: Buffered I/O count:           
    1845         Peak working set size:  12496 Direct I/O count:              
     891         Peak page file size:    51408 Page faults:                  
    9719         Mounted volumes:            0 Charged CPU time:          
    0 00:00:27.56   Elapsed time:     0 00:00:43.28
    
    

    forget to say it makes it on the NT system.
    
    Do I need a better Compiler for OpenVMS then DEC C V5.0-003 ?
    
    Sepp,

The SPD says DEC C++ 5.0 for OpenVMS VAX or OpenVMS Alpha.

    Further to that BUG reported in .0 but still belonging to BANK EXAMPLE5
    the deffered synchronous invocation.
    
    I have setup for CL & SV on the same machine and
    I Have setup for CL & SV on two machines
    The bug is the same.
    
    Note: I made the .0 reported BUG disappering by adding 2 lines to the
    makefile
    $ on severe_error then goto exit
    $ on error then goto exit
    This keeps the VMS command procedure make.com going for warnings
    (yet this is my workarround it has delivered 2 working executables.)
    
    So, when I tested the EXAMPLE5 and when ever I enter to use an existing
    account but the account does actually not exists the client hungs up.
    
    Back to my observation/problem:
    I have stept through the server code, it does setup an exception and
    returns for every account ID which can't be found. 
    
    So the server code is correct when ever an account is not found.
    
    when look at the client code
    
    /* Get the the response    
    
    do {
       status = CORBA_Request_get_response (request, /* request object
                                            &ev,
    				CORBA_RESP_NO_WAIT); /* invoke flags
    obb_sleep(1);
    } while (status == OBB_INV_NORESP);
    
    the CORBA_Request_get_response returns for every invocation at every
    second, for ever the status as 76264490 which is OBB_INV_NORESP
    
    This goes on for ever.
    
    My question:
    
    What is wrong? 
    
    The server has set an exception which is not seen at the client.
    
    At least CORBA_Request_get_response returns 
    OBB_INV_NORESP and therefor prevents the loop from exiting. 
    
    Is an exception enforced by the server not worth to result in a
    different return value by CORBA_Request_get_respond?
    
    Is some TRY {
    
    } CATCH ALL {
    
    }
    missing in the client to over come this situation.
    
    Is this behaviour of CORBA_Request_get_response by Design wanted ?
     
    How can I find out that the propper exception has returnd to the client
    and that just CORBA_Request_get_respons is not working and that I have
    to use a TRY CATCH blocks ?
    
    Also, I think it could help when this is fixed for the next release.
    
    Sepp,
    
    

    The looping problem is the same as 2411 in the development notes 
    conference; bank5 needs to register a typecode lookup rtn. I have
    entered this along with the compile warnings - bank5 should use
    external typecodes for both client and server.