jt400 program call - can very large strings be passed as parameters? - IBM AS400

This is a discussion on jt400 program call - can very large strings be passed as parameters? - IBM AS400 ; I would like to know if it is possible from jt400 (in any version :-S) to submit an arbitrarily long string as an input parameter to a program call, and get another arbitrarily long string back as an output parameter? ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: jt400 program call - can very large strings be passed as parameters?

  1. jt400 program call - can very large strings be passed as parameters?


    I would like to know if it is possible from jt400 (in any version :-S)
    to submit an arbitrarily long string as an input parameter to a
    program call, and get another arbitrarily long string back as an
    output parameter?

    It is - naturally - a question of passing XML back and forth where we
    previously have solved this for asyncronouos processes by writing file
    members. I just though "oh, why not?" and cannot immediately see any
    limiting text in the jt400 documentation or source code.

    I know the length of the input parameters at call time but not the
    output parameters.

    As others must have had a similar problem earlier, I would like to
    know if there is any who have experiences to share?

    The bugger to call will most likely be written for the occasion in
    non-ILE COBOL (don't ask), but if it is easier in other languages I am
    all ears

    Thanks in advance.
    --
    Thorbjørn Ravn Andersen


  2. Re: jt400 program call - can very large strings be passed as parameters?

    How big are we talking? XML can get quite large, and there is a limit
    (32k?) on the size of a String in Java. OPM COBOL also limits the size
    of parameters, but I can't remember offhand what the maximum length
    is.

    It doesn't make any difference to the ProgramCall class what language
    the AS/400 program is written in, so OPM COBOL would be fine. However,
    parsing XML in COBOL is not a trivial task - C, C++, or RPG would
    serve you better.

    For asynchronous communication though, a DTAQ (or an MQ Queue) would
    seem to be a better solution to the problem; otherwise you'll be
    waiting for the COBOL program to complete before the Java program
    continues.


  3. Re: jt400 program call - can very large strings be passed as parameters?

    On second thoughts, why not write the whole thing in Java? Why go out
    to COBOL (or any other language) at all?


  4. Re: jt400 program call - can very large strings be passed as parameters?

    "walker.l2" writes:

    > How big are we talking? XML can get quite large, and there is a limit
    > (32k?) on the size of a String in Java. OPM COBOL also limits the size
    > of parameters, but I can't remember offhand what the maximum length
    > is.


    To my understanding there is no other limitation than it must fit in a
    2Gb segment (as String.length() returns int which is 32 bits
    including sign).

    > It doesn't make any difference to the ProgramCall class what language
    > the AS/400 program is written in, so OPM COBOL would be fine. However,
    > parsing XML in COBOL is not a trivial task - C, C++, or RPG would
    > serve you better.


    We have a rudimentary Cobol parser which do the job - the calling Java
    process massage the XML into a parsable format.

    Our only issue is getting the data back and forth.

    > For asynchronous communication though, a DTAQ (or an MQ Queue) would
    > seem to be a better solution to the problem; otherwise you'll be
    > waiting for the COBOL program to complete before the Java program
    > continues.


    As in this particular case we will implement a webservice which needs
    to return a result, that will be just fine

    Thanks for your responses.
    --
    Thorbjørn Ravn Andersen

  5. Re: jt400 program call - can very large strings be passed as parameters?

    "walker.l2" writes:

    > On second thoughts, why not write the whole thing in Java? Why go out
    > to COBOL (or any other language) at all?


    Unfortunately not an option as our legacy system is written in Cobol.
    At one point or another we need to get the data over the border.

    As you may have guessed my job is gluing various web capabilities on
    the legacy system - I love it

    --
    Thorbjørn Ravn Andersen

  6. Re: jt400 program call - can very large strings be passed as parameters?

    On Feb 19, 2:34 pm, Thorbjoern Ravn Andersen
    wrote:
    > "walker.l2" writes:
    > > On second thoughts, why not write the whole thing in Java? Why go out
    > > to COBOL (or any other language) at all?

    >
    > Unfortunately not an option as our legacy system is written in Cobol.
    > At one point or another we need to get the data over the border.
    >
    > As you may have guessed my job is gluing various web capabilities on
    > the legacy system - I love it
    >
    > --
    > Thorbjørn Ravn Andersen


    I'd check the online COBOL docs for parameter lengths. The way I would
    do this is make the COBOL program have 4 parameters: Input string,
    input length, output string, output length. Have the COBOL program set
    the output length and you can then the Java program will know how much
    data was sent.

    Another approach would be what I did to write a web service for our
    tax software (an ancient version of Vertex): A Java app takes the SOAP
    message and breakes it down into the individual parameters. I then
    call a very small program I wrote to deal with the tax software
    (basically just set up data structures which is something Java stinks
    at and does some implementation specific things) for each order line
    and returns results to the web service.

    Matt


  7. Re: jt400 program call - can very large strings be passed as parameters?

    matt.haas@thomsonlearning.com writes:

    > tax software (an ancient version of Vertex): A Java app takes the SOAP
    > message and breakes it down into the individual parameters. I then
    > call a very small program I wrote to deal with the tax software
    > (basically just set up data structures which is something Java stinks
    > at and does some implementation specific things) for each order line
    > and returns results to the web service.


    Java is not that bad at it, you just need to write a string padder and
    a string cutter to assemble and disassemble blobs.

    But it is not the issue here - there is a basic decision that the
    interface to this feature is an xml-file which in this particular case
    is delivered over SOAP.

    I'll grab our Cobol guru tomorrow and see what he thinks about this
    issue. I'd just prefer to use a well-used path instead of hacking
    through the wilderness a few meters off to the left


    --
    Thorbjørn Ravn Andersen

  8. Re: jt400 program call - can very large strings be passed as parameters?

    Thorbjoern Ravn Andersen wrote:

    > The bugger to call will most likely be written for the occasion in
    > non-ILE COBOL (don't ask), but if it is easier in other languages I am
    > all ears



    I'd have no question about COBOL as the choice... but OPM COBOL? Why
    limit it to a language environment? ILE COBOL would be a far better
    choice with less requirement for concern about lengths. Advancing
    through arbitrary numbers of memory addresses is a lot easier with pointers.

    And the program code would still be COBOL.

    --
    Tom Liotta
    http://zap.to/tl400

  9. Re: jt400 program call - can very large strings be passed as parameters?

    Tom Liotta writes:

    > I'd have no question about COBOL as the choice... but OPM COBOL? Why
    > limit it to a language environment? ILE COBOL would be a far better
    > choice with less requirement for concern about lengths. Advancing
    > through arbitrary numbers of memory addresses is a lot easier with
    > pointers.


    I sincerely have no idea why, but that is what I've been told

    Probably it is a matter of intertia - why change stuff if it works?
    --
    Thorbjørn Ravn Andersen

  10. Re: jt400 program call - can very large strings be passed as parameters?

    > I'd have no question about COBOL as the choice... but OPM COBOL? Why
    > limit it to a language environment?


    Perhaps for the same reason we're still writing OPM COBOL here - it
    works, and management don't want to pay to retrain the whole team in
    ILE.


  11. Re: jt400 program call - can very large strings be passed as parameters?

    > To my understanding there is no other limitation than it must fit in a
    > 2Gb segment (as String.length() returns int which is 32 bits
    > including sign).
    >

    Looks like you are right (perhaps I'm remembering the limitations of
    an early JVM implementation).
    As far as COBOL goes, I've found one reference that suggests a 3Mb
    size limit for passed parameters, so if you need more than this a
    UserSpace object may be appropriate instead.

    > Our only issue is getting the data back and forth.
    >
    > > For asynchronous communication though, a DTAQ (or an MQ Queue) would
    > > seem to be a better solution to the problem; otherwise you'll be
    > > waiting for the COBOL program to complete before the Java program
    > > continues.

    >
    > As in this particular case we will implement a webservice which needs
    > to return a result, that will be just fine
    >

    I still recommend a queue based solution - the Java system writes
    messages to Q1, the COBOL program is triggered by the arrival of a
    message on Q1 and writes the output to Q2, the Java system key reads
    the response from Q2. I think you will find this easier to test, and
    if something odd happens in the COBOL program (such as it goes into
    MSGW) you can avoid / gracefully handle timeouts on the Java system.
    However, a DTAQ will only allow you 64,512 characters though which
    might be too small for an XML message (an MQ queue would allow 100Mb).


  12. Re: jt400 program call - can very large strings be passed as parameters?

    "walker.l2" writes:

    > I still recommend a queue based solution - the Java system writes
    > messages to Q1, the COBOL program is triggered by the arrival of a
    > message on Q1 and writes the output to Q2, the Java system key reads
    > the response from Q2. I think you will find this easier to test, and
    > if something odd happens in the COBOL program (such as it goes into
    > MSGW) you can avoid / gracefully handle timeouts on the Java system.
    > However, a DTAQ will only allow you 64,512 characters though which
    > might be too small for an XML message (an MQ queue would allow 100Mb).


    Would this approach work well with multiple simultaneous connections?
    (Not likely in this case, but perhaps in the next).

    We have previuosly seen hanging connections when the backend went away
    (which is also a pain in production) so I will definitively need to
    implement a wrapper which deals nicely with server timeouts anyway.

    Thank you for sharing your experiences!

    --
    Thorbjørn Ravn Andersen

  13. Re: jt400 program call - can very large strings be passed as parameters?

    > Would this approach work well with multiple simultaneous connections?
    > (Not likely in this case, but perhaps in the next).
    >

    It works very well with MQ and triggers - your 'client side' (i.e. the
    Java system) can make multiple simultaneous requests that merely place
    requests on the queue ready for a single COBOL job on backend (rather
    than spawning multiple COBOL jobs). The trigger activates a single
    instance of the COBOL program which can read and process all the
    messages on the queue. The 'client side' then key reads responses.
    (Also, you can wrap the MQ stuff up in JMS calls if you want to hide
    the undelying messaging architecture.)

    With DTAQs, I don't think you can trigger, so you have to have a
    backend job checking the queue at frequent intervals for requests.
    Also, commit control is more awkward with DTAQs than with MQ. On the
    other hand, DTAQs come free with OS/400, MQ doesn't (but it might be
    bundled with WAS, I'm not sure).

    > We have previuosly seen hanging connections when the backend went away
    > (which is also a pain in production) so I will definitively need to
    > implement a wrapper which deals nicely with server timeouts anyway.
    >

    As you suggest, the real nasty 'gotcha' is not when the backend fails
    gracefully (i.e. returns with some kind of failure message), but when
    the backend hangs on a LCKW or MSGW etc. which is very difficult to
    deal with on the Java side when you are waiting for programCall.run()
    to complete.

    A queue gives you flexibility because you can code "get my reply from
    the queue, return in xx seconds if no reply is available" or "get my
    reply from the queue" coupled with a loop to test for whether any
    reply was found. The 'client-side' can then detect and deal with bad
    behaviour more easily.


    As I mentioned before, testing and debugging can be easier with queues
    too: you don't have to have both parts active and working at the same
    time; and you can store test messages on a separate queue, and copy
    them across to the 'request queue' every time you want to do a
    regression test.

    > Thank you for sharing your experiences!
    >

    Glad to be of help - a lot of my job is webifying legacy COBOL apps
    too.


  14. Re: jt400 program call - can very large strings be passed as parameters?

    If you go down the MQ route, there's a really neat trick you can use
    if you are exchanging fixed-format messages (not XML though, so it
    won't help you here): since you can represent the contents of an MQ
    message as a byte[], and you can represent a record on an AS/400 file
    as a byte[], you can write DDS purely to represent your message
    formats (you never actucally read from or write to the file). This
    means you can access the various parts of the message by 'named
    column' rather than by 'character offsets', which avoids a lot of
    nasty 'off by 1' index errors and padding issues.


  15. Re: jt400 program call - can very large strings be passed as parameters?

    To my best knowledge jt400 allocates the storage needed for parameters
    at call time.
    Because of that you need to know the length of the return parameter at
    call time.... or allocate a huge buffer (maximum size) for all calls...

    ----- Original meddelelse -----
    Fra: Thorbjoern Ravn Andersen
    Dato: 19-02-2007 15:26
    > I would like to know if it is possible from jt400 (in any version :-S)
    > to submit an arbitrarily long string as an input parameter to a
    > program call, and get another arbitrarily long string back as an
    > output parameter?
    >
    > It is - naturally - a question of passing XML back and forth where we
    > previously have solved this for asyncronouos processes by writing file
    > members. I just though "oh, why not?" and cannot immediately see any
    > limiting text in the jt400 documentation or source code.
    >
    > I know the length of the input parameters at call time but not the
    > output parameters.
    >
    > As others must have had a similar problem earlier, I would like to
    > know if there is any who have experiences to share?
    >
    > The bugger to call will most likely be written for the occasion in
    > non-ILE COBOL (don't ask), but if it is easier in other languages I am
    > all ears
    >
    > Thanks in advance.


+ Reply to Thread