Re: as400 command parameters reference - IBM AS400

This is a discussion on Re: as400 command parameters reference - IBM AS400 ; f3l wrote: > I would like to know if anyone's got an as/400 command reference like > this: > > command1 parameters > command2 parameters > ... > command1000 parameters > > ex. > RUNQRY QRYFILE((filename)) RCDSLT(*yes/*no) etc etc etc ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Re: as400 command parameters reference

  1. Re: as400 command parameters reference

    f3l wrote:
    > I would like to know if anyone's got an as/400 command reference like
    > this:
    >
    > command1 parameters
    > command2 parameters
    > ...
    > command1000 parameters
    >
    > ex.
    > RUNQRY QRYFILE((filename)) RCDSLT(*yes/*no) etc etc etc



    Since command parameters can change for different releases, and even
    PTFs, and since commands might or might not exist on a system depending
    on what products are installed, and since anyone can create commands at
    any time as well as change existing ones, there is no practical
    reference other than the CL Reference Guide for _each_ release.

    However, beginning with V5R1, there is an API that will retrieve command
    parameter info to XML --

    Retrieve Command Definition (QCDRCMDD) API
    http://publib.boulder.ibm.com/infoce...s/qcdrcmdd.htm

    The link is for V5R4.

    Tom Liotta
    http://zap.to/tl400

  2. Re: as400 command parameters reference

    Tom Liotta writes:

    > However, beginning with V5R1, there is an API that will retrieve
    > command parameter info to XML --
    >
    > Retrieve Command Definition (QCDRCMDD) API
    > http://publib.boulder.ibm.com/infoce...s/qcdrcmdd.htm


    We are trying to make Java invocations look as much as possible as a
    CL commands.

    Have anyone seen things to make java behave similar to the stuff
    above? (I have not researched this, so it might be a silly question
    :-} )
    --
    Thorbj°rn Ravn Andersen

  3. Re: as400 command parameters reference

    If that's what you want to do, why not wrap the Java by calling it from
    inside a small CL program? That way you can mask the 'strangeness' of
    Java from those comfortable with normal *PGM objects.


  4. Re: as400 command parameters reference

    "walker.l2" writes:

    > If that's what you want to do, why not wrap the Java by calling it from
    > inside a small CL program? That way you can mask the 'strangeness' of
    > Java from those comfortable with normal *PGM objects.


    I just wanted to see if I could do it without a CL wrapper

    --
    Thorbj°rn Ravn Andersen

  5. Re: as400 command parameters reference

    Now I have had some time to think about this I'm not so sure it is a
    good objective.
    A Java program is significantly different from a CL / RPG / COBOL
    program, so 'hiding' the fact that the called program is in Java might
    lead to problems in the future. Also, I imagine you don't have a lot of
    calls to Java programs to worry about do you? (Java generally fits best
    for long-running applications, other languages are better for short,
    repeatedly run, programs.)


  6. Re: as400 command parameters reference

    "walker.l2" writes:

    > Now I have had some time to think about this I'm not so sure it is a
    > good objective.
    > A Java program is significantly different from a CL / RPG / COBOL
    > program, so 'hiding' the fact that the called program is in Java might
    > lead to problems in the future. Also, I imagine you don't have a lot of
    > calls to Java programs to worry about do you? (Java generally fits best
    > for long-running applications, other languages are better for short,
    > repeatedly run, programs.)


    We have a large body of legacy code conforming to internal standards
    where I supply java programs which solve some specific problem to our
    Cobol programmers, and I have no experince in writing CL wrappers.

    I would therefore make it as similar as possible to existing programs
    to make it easier on our legacy programmers who don't do java.

    That's all.

    --
    Thorbj°rn Ravn Andersen

  7. Re: as400 command parameters reference

    What worries me is that if you hide the fact that a Java program is
    being used, you might find it gets misused (i.e. called frequently,
    resulting in a big overhead from the creation of a new JVM each time).
    But there can sometimes be advantages to wrapping the Java in CL.
    Below is a sample wrapper (although here Java parameters are read from
    a DTAARA, they could just as easily be passed to the CL program as part
    of the call):

    PGM PARM(&ERROR)
    /* PARAMETER PASSED IN */

    /* *└Declare variables for passed in parameters
    */
    DCL VAR(&ERROR) TYPE(*CHAR) LEN(1)
    /* *└Declare variables for progress messages
    */
    DCL VAR(&PROGRESS) TYPE(*CHAR) LEN(132) /* +
    Progress indicator for messages */
    /* *└Declare variables for library availability
    */
    DCL VAR(&CLASSPATH) TYPE(*CHAR) LEN(200)
    DCL VAR(&IN_LIBRARY) TYPE(*CHAR) LEN(10)
    DCL VAR(&OUT_PATH) TYPE(*CHAR) LEN(100)
    DCL VAR(&OUT_NAME) TYPE(*CHAR) LEN(10)

    /* *└Global monitor for messages. Go to TAG1 if detected
    */
    MONMSG MSGID(CPF0000 MCH0000) EXEC(GOTO CMDLBL(TAG1))

    /* ---------------------------------------------------------------- */
    /* *└Produce Start Message
    */
    CHGVAR VAR(&PROGRESS) VALUE('XKXC011 - Start of +
    program')
    SNDPGMMSG MSGID(KGM0009) MSGF(XMSGF) MSGDTA(&PROGRESS) +
    TOPGMQ(*EXT) MSGTYPE(*STATUS)
    SNDMSG MSG(&PROGRESS) TOMSGQ(MRUNQ XKXRUNQ) +
    MSGTYPE(*INFO)

    /* ---------------------------------------------------------------- */
    /* *└Set up the (Job Level) environment variables */

    /* *└Set up QSH to raise a QSH0005 if the exit code is greater */
    /* *└than zero. This is trapped by the MONMSG and causes this */
    /* *└program to abort. */
    ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE('Y') +
    REPLACE(*YES)
    /* *└Set up the Java classpath */
    RTVDTAARA DTAARA(XKXSTAT (101 200)) RTNVAR(&CLASSPATH)
    ADDENVVAR ENVVAR(CLASSPATH) VALUE(&CLASSPATH) +
    REPLACE(*YES)

    /* *└Set up the parameters for the Java call */
    RTVDTAARA DTAARA(XKXSTAT (301 7)) RTNVAR(&IN_LIBRARY)
    RTVDTAARA DTAARA(XKXSTAT (310 12)) RTNVAR(&OUT_PATH)
    RTVDTAARA DTAARA(XKXSTAT (325 10)) RTNVAR(&OUT_NAME)

    ADDENVVAR ENVVAR(IN_LIBRARY) VALUE(&IN_LIBRARY) +
    REPLACE(*YES)
    ADDENVVAR ENVVAR(OUT_PATH) VALUE(&OUT_PATH) +
    REPLACE(*YES)
    ADDENVVAR ENVVAR(OUT_NAME) VALUE(&OUT_NAME) +
    REPLACE(*YES)

    /*--------------------------------------------------------------*/
    /* *└Run Java Program */

    STRQSH CMD('java +

    com.mycompany.standalone.TravelDatabaseUploadRe+
    formatter $IN_LIBRARY $OUT_PATH $OUT_NAME')
    /* ---------------------------------------------------------------- */
    EOJOK:
    /* *└Normal end of job
    */
    CHGVAR VAR(&ERROR) VALUE(' ')
    CHGVAR VAR(&PROGRESS) VALUE('XKXC011 - normal end +
    of job')
    SNDPGMMSG MSGID(KGM0009) MSGF(XMSGF) MSGDTA(&PROGRESS) +
    TOPGMQ(*EXT) MSGTYPE(*STATUS)
    SNDMSG MSG(&PROGRESS) TOMSGQ(MRUNQ XKXRUNQ) +
    MSGTYPE(*INFO)

    GOTO CMDLBL(ENDCLPGM)

    /* ---------------------------------------------------------------- */
    /* *└Error message found by global monitor of messages
    */
    TAG1:
    SNDPGMMSG MSGID(KGM0003) MSGF(XMSGF) MSGDTA('XKXC011') +
    TOPGMQ(*EXT) MSGTYPE(*STATUS)
    SNDPGMMSG MSGID(KGM0003) MSGF(XMSGF) MSGDTA('XKXC011') +
    TOMSGQ(MOPERQ XKXRUNQ)

    /* ---------------------------------------------------------------- */
    /*└Controlled abend of program */
    ABEND:
    CHGVAR VAR(&ERROR) VALUE('E')
    SNDMSG MSG('XKXC011 has failed') TOMSGQ(MRUNQ +
    XKXRUNQ MOPERQ) MSGTYPE(*INFO)

    /* ---------------------------------------------------------------- */

    /* ---------------------------------------------------------------- */
    ENDCLPGM:
    ENDPGM


  8. Re: as400 command parameters reference

    "walker.l2" writes:

    > What worries me is that if you hide the fact that a Java program is
    > being used, you might find it gets misused (i.e. called frequently,
    > resulting in a big overhead from the creation of a new JVM each time).


    No need. We are aware of this fact, and as I have understood the V5R4
    version of Java or the coming ones will have shorter invocation time
    even of large amount of bytecode.

    We only use Java for stuff not easily done in Cobol, like https
    communication, image transformation (wrote a TIFF to PDF conversion
    the other day) and XML validation and transformation.


    > But there can sometimes be advantages to wrapping the Java in CL.
    > Below is a sample wrapper (although here Java parameters are read from
    > a DTAARA, they could just as easily be passed to the CL program as part
    > of the call):


    Thanks. I'll forward your post to my CL-savvy colleague

    --
    Thorbj°rn Ravn Andersen

  9. Re: as400 command parameters reference

    > We only use Java for stuff not easily done in Cobol,

    Same here. We do prints, batch processing etc. in COBOL (with some
    embedded SQL); and online / real-time applications in Java (JSPs are so
    much easier than subfiles!).

    > Thanks. I'll forward your post to my CL-savvy colleague


    Be aware that you don't need to use ENVVARs. You can pass the
    parameters directly on the 'Java' command. But since we wanted to use
    QIBM_QSH_CMD_ESCAPE_MSG we standardised on ENVVARs.

    You can use RCVMSG to retrieve the Java exit code returned by the
    QSH005 message:
    RCVMSG MSGTYPE(*LAST) RMV(*NO) MSGDTA(&MSGDTA) MSGID(&MSGID)
    IF (&MSGID = \'QSH0005\') CHGVAR &RTNCODE %BIN(&MSGDTA)

    You might also want to look at the following ENVVARs:
    QIBM_QSH_CMD_OUTPUT and QIBM_SYSTEM_ALWMLTTHD.

    And ADDLNK can be useful for setting the classpath. For example:
    ADDLNK OBJ(\'/QIBM/ProdData/Java400/jdk118/lib\') NEWLNK(IFS_ALIAS)
    ADDENVVAR ENVVAR(CLASSPATH)
    VALUE(\'IFS_ALIAS/a_jar.jar:IFS_ALIAS/another_jar.jar\') REPLACE (*YES)


  10. Re: as400 command parameters reference

    "walker.l2" writes:

    > Same here. We do prints, batch processing etc. in COBOL (with some
    > embedded SQL); and online / real-time applications in Java (JSPs are so
    > much easier than subfiles!).


    I have found that the JavaServer Faces framework gives much, much more if you would
    like to build non-trivial webapplications (multi-page wizards, simple
    data structure lookup etc), but it has a rather steep learning curve.

    > And ADDLNK can be useful for setting the classpath. For example:
    > ADDLNK OBJ(\'/QIBM/ProdData/Java400/jdk118/lib\') NEWLNK(IFS_ALIAS)
    > ADDENVVAR ENVVAR(CLASSPATH)
    > VALUE(\'IFS_ALIAS/a_jar.jar:IFS_ALIAS/another_jar.jar\') REPLACE (*YES)


    I use a different approach, namely by embedding all necessary jars in
    the deployed jar, and using the one-jar classloader to start the whole
    show (with the fjep plugin in eclipse). This makes the logistics much
    simpler.

    Work has begun to get this included by default in Eclipse 3.3

    --
    Thorbj°rn Ravn Andersen

  11. Re: as400 command parameters reference

    > I have found that the JavaServer Faces framework gives much, much more if you would
    > like to build non-trivial webapplications (multi-page wizards, simple
    > data structure lookup etc), but it has a rather steep learning curve.
    >

    Thanks for the tip. At the moment I'm busy converting stuff over from
    WebSphere 5.0 & JDK 1.3.1 to WebSphere 5.1 & JDK 1.4.2, but I'll try to
    have a look at JSF when I'm done.


  12. Re: as400 command parameters reference

    "walker.l2" writes:

    > Thanks for the tip. At the moment I'm busy converting stuff over from
    > WebSphere 5.0 & JDK 1.3.1 to WebSphere 5.1 & JDK 1.4.2, but I'll try to
    > have a look at JSF when I'm done.


    May I ask what the differences are between the two? My immediate
    guess would be that things would work unchanged, but apparently it is
    not so.

    Generally we have found that sticking with Tomcat for web applications
    give the fewest problems when needing to deploy to other web containers.

    --
    Thorbj°rn Ravn Andersen

  13. Re: as400 command parameters reference

    The main issues we had with the migration were:

    NumberFormatExceptions being thrown where they weren't previously.
    XML parsers returning RuntimeExceptions when they used to wrap those in
    SAXExceptions.
    The java.util.Currency class conflicting with our own Currency class
    (because of sloppy 'import java.util.*' statements)

    Now that we have switched over, we're also retrofitting our home-grown
    logging framework to interact with the java.util.logging classes.

    On the plus side, WebSphere 5.1 runs much faster in WDSCi than
    WebSphere 5.0 did. And we didn't need to make any configuration changes
    to the WebSphere server instances themselves. All in all it was easier
    than the previous migration (from 3.5 to 5.0). Hopefully the next
    migration (to 6.1 or later) will be even more painless.


  14. Re: as400 command parameters reference

    "walker.l2" writes:

    > The java.util.Currency class conflicting with our own Currency class
    > (because of sloppy 'import java.util.*' statements)


    When I started working with Eclipse I found its behaviour of
    explicitly listing each and every class in an import statement rather
    annoying (as opposed to using import ...* statements).

    This has changed as import statements are now per default folded away
    (you don't see them in the editor), and I found the disambiguity
    essential to avoid problems like those you describe.

    Eclipse can fix imports on all source files in one go, so you may want
    to let it go on your source once just to get this settled.

    Other IDE's may do so to, I just use Eclipse on a daily basis.

    > Now that we have switched over, we're also retrofitting our home-grown
    > logging framework to interact with the java.util.logging classes.


    I have found the logging-classes to be less flexible to log4j, and we
    therefore currently still use log4j but will migrate to the Apache
    Jakarta project commons-loggins, as it will use one of several logging
    frameworks available transparently.

    --
    Thorbj°rn Ravn Andersen

  15. Re: as400 command parameters reference

    We use WDSCi (the AS/400 tailored version of Eclipse), and find it a
    very powerful tool. As you say, refactoring is easy. (It's the
    retesting that takes the time!)

    Apparently WebSphere 6.0 uses java.util.logging, so that's why we went
    down that route (hopefully it will save us some pain at the next
    migration).


  16. Re: as400 command parameters reference

    > I have found that the JavaServer Faces framework gives much, much more if you would
    > like to build non-trivial webapplications (multi-page wizards, simple
    > data structure lookup etc), but it has a rather steep learning curve.


    I've had a chance to take a quick look at JSF. It seems like something
    for the EJB crowd - very powerful, but overkill for a lot of projects.
    Our apps are small-medium sized, and servlets & JSPs do the job for us
    (we are considering migrating some polling jobs over to Message Driven
    Beans though). But thanks for suggesting ot.


  17. Re: as400 command parameters reference

    "walker.l2" writes:

    > I've had a chance to take a quick look at JSF. It seems like something
    > for the EJB crowd - very powerful, but overkill for a lot of projects.


    I partly agree. The major reason why I prefer it over struts is that
    it allows me to create complete, complex pages without providing any
    HTML myself, except some CSS-hints here and there, and just manipulate
    the value beans as appropriate.

    Basically, if you don't groan at coding/decoding parameters for each
    request, you are not ripe for stuff like this

    --
    Thorbj°rn Ravn Andersen

+ Reply to Thread