EGL Development User Group

EGL Development User Group

EGL Development User Group

The EGL Development User Group is dedicated to sharing news, knowledge, and insights regarding the EGL language and Business Developer product. Consisting of IBMers, HCL, and users, this community collaborates to advance the EGL ecosystem.

 View Only
  • 1.  MQ Linkage information in RBD

    Posted Tue May 19, 2015 03:09 AM

     

    Hello,

    In VAGen  MQ application needs the following linkage information to access MQ message.

    :calllink applname=elaq* linktype=dynamic dllname=csomqc32 bitmode=32 parmform=oslink. 

    How to map these  values into RBD ?  The platform is Windows/Java.    

     

    dwkey


  • 2.  Re: MQ Linkage information in RBD

    Posted Tue May 19, 2015 03:22 PM

    Hi Chao,

    Add a new EGL part type Linkage Option in the EGL Build Descriptor.  Looks in the attached image.

    applname as pgmName

    linktype as localcall

    dllname as library

    bitmode is not support

    parmform as parmform

    Regard,

    Hsieh

     

    Hsieh


  • 3.  Re: MQ Linkage information in RBD

    Posted Tue May 19, 2015 05:52 PM

    L.H.,

    Take a look at this section of the EGL Programmer's guide.   I think it will answer the question.

    http://www-01.ibm.com/support/knowledgecenter/SSMQ79_9.1.1/com.ibm.egl.pg.doc/topics/pegl_mq_linkage_options_tsk.html

    If issues, let me know.

    markevans


  • 4.  Re: MQ Linkage information in RBD

    Posted Fri July 03, 2015 11:47 PM

     

    Hi Hsieh and Mark,

     

    I  wrote a simple EGL MQ program, MQputP, to put a message into MyQM:MyLocalQ ( MQ : V8.0.0.0.0  in same machine )  . 

     

    I can debug EGL in RBD and run EGL/Java in Javeruntime OK, but I didn't specify linkage.  

     

    My EGL source archive file and runtime trace  file are attached.   

    L.H.Chao


  • 5.  Re: MQ Linkage information in RBD

    Posted Sun July 05, 2015 03:08 PM

    Hi Chao,

    Maybe the problem is on the case sensitivity

     

    resourceAssociations="RA">
    </BuildDescriptor>
    <ResourceAssociations name="RA">
        <association fileName="myLocalQ">
            <win>
                <mq systemName='MyQM:MyLocalQ'/>
            </win>
        </association>
    </ResourceAssociations>

     

     

    vgj.ra.mylocalq.systemName=MyQM:MyLocalQ

    vgj.ra.mylocalq.fileType=mq
    vgj.ra.mylocalq.conversionTable=

     

    You can change it to same one.

    Hsieh


  • 6.  Re: MQ Linkage information in RBD

    Posted Mon July 06, 2015 03:03 PM

    L.H,

    There are two ways to do MQ access in EGL.  This is from the Knowledge Center at the following link:

    EGL supports calls to WebSphere MQ message queues in two ways:

    • You can use EGL-specific keywords like add and get next. In this case EGL handles all the details of generating WebSphere MQ API calls.

    • You can write WebSphere MQ API calls directly, to support older programs.

    VAGen also offered both ways by the time it went out of support.

     

    The linkage tables are used for the direct WebSphere MQ API calls since the programs are calling out to supplied programs (Dlls in windows, etc).

    The resource association (if not using defaults) entries are used for the "add" and "get next" method (i.o statements).

     

    So... in the code sample, the i/o statements are used, so no linkage table is required.

     

    For a migration where MQ API calls were used in old VAGen code, then go look at the link I provided earlier.  It has samples of what is needed for the linkage table. 

     

    If you are writing new MQ code, I would strongly recommend you use the file i/o option. 

     

    Mark

    markevans


  • 7.  Re: MQ Linkage information in RBD

    Posted Wed July 22, 2015 04:41 PM

     

    Hi Mark and Hsieh,

    Update on the problem status.  

    If EGL/MQ program runs on the same machine with MQ server, it can put messages into local queue fine. 

    Customer is trying to run EGL/MQ on MQ client environment to consolidate the MQ servers . 

    The MQ-provided IVP  sample  runs OK to put message into remote server queue from MQ client,

    so I will continue to work with customer to solve the remote queue access problem.

    Any hints/suggestions are very welcome.  

     

    L.H.Chao


  • 8.  Re: MQ Linkage information in RBD

    Posted Wed July 22, 2015 05:26 PM

    L.H,

     

    thanks for the update.

     

    I think the only approach is start with what kind of errors they are getting.  There are too many possibilities.   Possibilities include authority, missing classes, missing server configurations, etc.

     

    I would suggest running with the EGL Java Runtime trace turned on (vgj.trace.type and vgj.trace.device.option).   You might need the more detailed information.

     

    Mark

    markevans


  • 9.  Re: MQ Linkage information in RBD

    Posted Wed July 29, 2015 12:57 AM

     

    Mark,

    The vgtrace file produced on MQ client environment is below.

    The reason code ' 2058 ' means the invalid Queue manager name :  SGUQM1.  but the MQ IVP program runs OK

     to access the remote queue in the same QM : SGUQM1.   

    Any other possible error to cause EGL 0756E '2058' ,  

    Any suggestions ?  or go PMR ?   

    Environment setting :  

    CSOLINKTBL=C:\mqic32.lkg

    MQSERVER=SGUQM1.SVRCONN/TCP/10.8.60.110(1417)

    mqic32.lkg

    :calllink applname=elaq* library=csomqc32 linktype=csocall parmform=commptr  remotecomtype=direct remoteapptype=nonvg contable=CSOJ950. 

     

    (15:08:47> *** Jul 24, 2015, 3:08:47 PM ***(15:08:47>  (15:08:47> RunUnit: MQTSTP(15:08:47> Version: 9.1(15:08:47> System: WIN     (15:08:47> User Properties: null, Program Properties: null, RunUnit Properties: file:/D:/FGBS_SERVER_EGL/F905_EGL/EGLRun/rununit.properties(15:08:47>  > cso.linkageOptions.CSOLINKTBL=mqic32.lkg(15:08:47>  > vgj.jdbc.default.database=jdbc:db2://fgbs5:50005/F905DB02:retrieveMessagesFromServerOnGetMessage=true;timestampformat=1;(15:08:47>  > vgj.jdbc.default.database.commitControl=noAutoCommit(15:08:47>  > vgj.jdbc.default.database.user.id=db2admin(15:08:47>  > vgj.jdbc.default.database.user.password=?(15:08:47>  > vgj.jdbc.drivers=com.ibm.db2.jcc.DB2Driver(15:08:47>  > vgj.jdbc.pstmt.cache.size=-1(15:08:47>  > vgj.nls.code=ENU(15:08:47>  > vgj.nls.currency.location=NONE(15:08:47>  > vgj.properties.version=5.1(15:08:47>  > vgj.ra.SWTVSF.fileType=seqws(15:08:47>  > vgj.ra.SWTVSF.system=win(15:08:47>  > vgj.ra.cmnbrq.conversionTable=(15:08:47>  > vgj.ra.cmnbrq.fileType=mq(15:08:47>  > vgj.ra.cmnbrq.systemName=SGUQM1:EAI.SGU.RQ(15:08:47>  > vgj.ra.cmnbrs.conversionTable=(15:08:47>  > vgj.ra.cmnbrs.fileType=mq(15:08:47>  > vgj.ra.cmnbrs.systemName=SGUQM1:EAI.SGU.RS(15:08:47>  > vgj.ra.cmnbrs1.conversionTable=(15:08:47>  > vgj.ra.cmnbrs1.fileType=mq(15:08:47>  > vgj.ra.cmnbrs1.systemName=SGUQM1:EAI.SGU.RS2(15:08:47>  > vgj.trace.device.option=2(15:08:47>  > vgj.trace.device.spec=d:\temp\egl_trace905.out(15:08:47>  > vgj.trace.type=-1(15:08:47> NLS code: ENU (ENU), Locale: en_US (null)(15:08:47> Trace to: d:\temp\egl_trace905.out, level: -1(15:08:47> java.class.path: D:\FGBS_SERVER_EGL\F905_EGL\EGLRun\fda7.jar;D:\FGBS_SERVER_EGL\F905_EGL\EGLRun\db2jcc.jar;D:\FGBS_SERVER_EGL\F905_EGL\EGLRun;D:\FGBS_SERVER_EGL\F905_EGL\lib_EGL;d:\FGBS_SERVER_EGL\F905_EGL\dll;C:\IBM\WSMQ\Java\lib\com.ibm.mqjms.jar;C:\IBM\WSMQ\Java\lib\com.ibm.mq.jar;.;C:\PROGRA~1\IBM\SQLLIB\java\db2java.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc.jar;C:\PROGRA~1\IBM\SQLLIB\java\sqlj.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cu.jar;C:\PROGRA~1\IBM\SQLLIB\bin;C:\PROGRA~1\IBM\SQLLIB\java\common.jar(15:08:47> java.library.path: D:\IBM_JDK\sdp\jdk\jre\bin\default;D:\IBM_JDK\sdp\jdk\jre\bin;C:\Windows\system32;C:\Windows;D:\FGBS_SERVER_EGL\F905_EGL\dll\CR_dll;C:\IBM\SDP\jdk\jre\bin;d:\FGBS_SERVER_EGL\EGLRuntimes\Win32\bin;d:\FGBS_SERVER_EGL\F905_EGL\;d:\FGBS_SERVER_EGL\F905_EGL\EGLRun;d:\FGBS_SERVER_EGL\F905_EGL\dll;C:\IBM\WSMQ\Java\lib;C:\Program Files\Microsoft Visual Studio\VC98\Bin;C:\Program Files\Microsoft Visual Studio\VC98\Include;C:\Program Files\Windows Resource Kits\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\PROGRA~1\CA\SHARED~1\SCANEN~1;C:\IBM\WSMQ\bin;C:\IBM\WSMQ\tools\c\samples\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL;.(15:08:47>  (15:08:47>  .--> com.hncb.fgbs.troubleshoot.mq.MQTSTP.main(15:08:47>  . --> com.hncb.fgbs.troubleshoot.mq.MQTSTP.MQTSTP-MAIN(15:08:47>  . .--> com.hncb.fgbs.troubleshoot.mq.MQTSTP.add-data(15:08:47> Looking up file object for record cmnbrs using logical file name "CMNBRS"...(15:08:47> File object for record cmnbrs could not be found.(15:08:47> Creating new file object for record cmnbrs using logical file name "CMNBRS"...(15:08:49> Mapped logical file CMNBRS to physical file "SGUQM1:EAI.SGU.RS" for record cmnbrs.(15:08:49> ==> ADD cmnbrs, INPUT DATA LENGTH = 0(15:08:49> Opening file "SGUQM1:EAI.SGU.RS" in write mode for record cmnbrs...(15:08:49> EGL0756E ADD:cmnbrs I/O fail ,reason :MQJE001:completion '2',reason code   '2058'。。(15:08:49> EGL0002I The error occurred in MQTSTP add-data (15:08:49>  . <-- com.hncb.fgbs.troubleshoot.mq.MQTSTP.add-data(15:08:49>  .<-- com.hncb.fgbs.troubleshoot.mq.MQTSTP.MQTSTP-MAIN(15:08:49>  <-- com.hncb.fgbs.troubleshoot.mq.MQTSTP.main(15:08:49> endRunUnit MQTSTP (normal termination) with returnCode=0

     

    L.H.Chao


  • 10.  Re: MQ Linkage information in RBD

    Posted Wed July 29, 2015 09:06 AM

    L.H.,

    First of all, you don't need the linkage table at all.  You are using EGL file i/o to do the MQ PUT (Add) and Get (get).  So it only needs a resource association and not any linkage table info.

    Next, I think the problem could be similar to a problem I had seen when people were trying to access a remote queue from the debugger.   The problem was the client was not able to find the Queue Manager.   Attached is a document with sample code where you set the

     

    Code Samples:

     

    External type for the MQEnvironment object

     

    ExternalTypeMQEnvironment typeJavaObject

        {JavaName = "MQEnvironment", PackageName = "com.ibm.mq"}

        staticchannel string;

        statichost string;

        staticport int;

    End

    where these fields have the following meaning.

    MQEnvironment.hostName

    For client connections, set this to the name of the host that hosts the queue

    manager. Since this host name is used for a TCP/IP connection to the

    machine on which the queue manager is running, the value is not case

    sensitive. For example:

    MQEnvironment.host = "machinename.dmain.com" ;

     

    _ MQEnvironment.channel

    This is the name of the channel for client connections. The value of this field

    is case sensitive. Typically it is the name of the Server Connection Channel

    under the queue manager. It is a bidirectional link that enables MQI calls and

    responses between the client and the queue manager.

    For client connections, set it to be the name of the server connection channel

    under the queue manager to which the application is attempting to connect.

     

    For example:

    MQEnvironment.channel = "JAVA.CLIENT.CHNL";

    _ MQEnvironment.port

    The port number is an optional field. By default the client would attempt to

    connect to the queue manager on the port number 1414 of the host. Port

    number 1414 is the port number used by MQSeries listeners by default. If the

    port number is different from the default, you can specify the port number

    using the MQEnvironment.port field. For example:

    MQEnvironment.port = nnnn;

     

    _ MQEnvironment.userId, MQEnvironment.password

    The userId and password fields are blank by default. You can specify a user

    ID and password by setting the values of the userId and password fields. For

    example:

    MQEnvironment.userId = "userXYZ" ;

    MQEnvironment.password = "password" ;

     

    Program/Function logic

     

    This sets static fields so you do not have to instantiate MQEnvironment. You should be able to set the static fields and then make the MQ calls.

     

    So declare the MQEnvironment external type,

     

    //variable declaration

    env MQEnvironment;

     

     

    and then in the function,

     

    env.port = 1414;

    env.host = "machinename.dmain.com";

    env.channel = "JAVA.CLIENT.CHNL";

     

    //mq call

    get mqRec

    And then just set the name to QM:Queue in the resource association.

     

     

    markevans


  • 11.  Re: MQ Linkage information in RBD

    Posted Mon August 03, 2015 11:51 PM

     

    Hi Mark,

     

    Customer has proved it's working by using the sample below. Thanks ! 

    Does customer need to change all its migrated-EGL/MQ code in this pattern to make it work in MQ client environment ?  

     

    program MQCSamp type BasicProgram {}                env MQEnvironment;    mqrec mqRec;    function main()                env.port = 1417;        env.host = "10.8.60.110";        env.channel = "SGUQM1.SVRCONN";        mqrec.message = "Gary Test";        add mqRec;    end        endexternalType MQEnvironment type JavaObject{JavaName = "MQEnvironment", PackageName = "com.ibm.mq"}    static channel string;    static host string;    static port int;endrecord mqRec type MQRecord{queueName = "mqrec", openQueueExclusive = no}    3 message char(30);end

     

    L.H.Chao


  • 12.  Re: MQ Linkage information in RBD

    Posted Tue August 04, 2015 09:11 AM

    L.H,

     

    Glad to hear it works.

     

    At this time, yes..each program that wants to connect needs to add this code.   i would assume it only has to be in the program that does the first connect in a rununit.

     

    My suggestion would be to put it in its own function or even a library that is invoked so that if the values change only that library would need to be regenned.

     

    We do have some old RFE's to make this info able to be specified externally (Resource Association or something like that).   While there are older ones....if you want to submit another RFE... feel free. 

     

    Mark
     

    markevans