IBM webMethods Hybrid Integration

IBM webMethods Hybrid Integration

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Expand all | Collapse all

NAT0935 Conflicting number of parameters Run Time error

  • 1.  NAT0935 Conflicting number of parameters Run Time error

    Posted Fri April 22, 2005 10:37 PM

    I am making an RPC call to Natural Subprogram from ASP.NET.

    I get the following run time error when I invoke the program.

    I did check it calling with 8 parameters, it works fine. When I pass
    9 parameters it throws me following runtime error.
    When Calling with 8 parameters Natural program is changed to accept 8 parameters
    When Calling with 9 parameters Natural program is changed to accept 9 parameters

    Run Time error

    SoftwareAG.EntireX.NETWrapper.Runtime.XException: 10140935: BRKN3339 9999 NAT0935 Conflicting number of parameters (Subprogram BRKN3339/MOSAICSD/1/17). Lib=MOSAICSD,Pgm=BRKN3339,(NATURAL Error Info: Program=BRKN3339,Error=0935,Line=9999,Status=O,Level=01).

    Call in ASP.NET goes something like this

    using SoftwareAG.EntireX.NETWrapper.Runtime;
    using SoftwareAG.EntireX.NETWrapper.Generated.brkn3339;

    Broker broker = new Broker(“XXX.XXX:4000”);
    Service srvc = new Service(broker,“XXX/XXXX/XXXXX”,"MOSAICSD ");
    srvc.Timeout=120;
    MOSAICSD bclient = new MOSAICSD(srvc);

    // Invoke the program

    bclient.BRKN3339(‘List of parameters go here seperated by comma’);


    #webMethods
    #EntireX
    #Mainframe-Integration


  • 2.  RE: NAT0935 Conflicting number of parameters Run Time error

    Posted Sat April 23, 2005 07:49 PM

    when you change and restow the subprogram for 9 parameters, is the Natural RPC server picking up the new version? That is, is the server running with a local buffer pool or a global that is not shared with the region where the subprogram was stowed from?

    If this is the problem, you can restart the server to get a fresh local buffer pool and pick up the new instance. Longer term, you may want to either use a global buffer pool shared with your development environment or set up a subprogram / rpc call to the API function USR0340 to flush the buffer pool for you (without restarting the RPC server).

    If you are using a local buffer pool for your Natural RPC Server, be sure to use the LBPNAME=localbp in the NTOS macro as the allows the NTASKS threads of the server to share the same local buffer pool.


    #EntireX
    #Mainframe-Integration
    #webMethods