File source for SQLRPGLE compiled object - IBM AS400

This is a discussion on File source for SQLRPGLE compiled object - IBM AS400 ; Hello. i don't know if this has already asked. I do some google search but was unable to get a clue on it. We got a in-house written set of proc that allow selective recompile of our in-house developed app ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: File source for SQLRPGLE compiled object

  1. File source for SQLRPGLE compiled object

    Hello. i don't know if this has already asked. I do some google search
    but was unable to get a clue on it.

    We got a in-house written set of proc that allow selective recompile of
    our in-house developed app basing on PF/PGM/Mdule/SRVPGM modification.

    After a long period of nice work (we wrote it back in the 4.2.0 days),
    it suddendly stopped to recompile SQLRPGLE-generated programs.

    I was on the way of rewriting it using more 'elegant' approch when i
    notice that the souce data retrived from the "List program Informatio"
    API (QBNLPGMI/QBNLSPGM) didn't point to the original source
    Library/file/member, but to an intermediate SQL-generated member in qtemp.

    This causes (a) the program inability to get the correct source type and
    (b) cannot compile from a non-existant source.

    I do some check with old prog in my work lib, and it came out that up to
    5.1.0 the source retrieved from API was correct, but up to 5.3.0/5.4.0
    it retrieves the faul value.

    May anyone tell me if there's a parameter to change to get the correct
    vaue or any other hint that can be used in order to retrive it
    post-compile ???

    Thanks

  2. Re: File source for SQLRPGLE compiled object

    Obelix-it wrote:

    > We got a in-house written set of proc that allow selective recompile of
    > our in-house developed app basing on PF/PGM/Mdule/SRVPGM modification.
    >
    > After a long period of nice work (we wrote it back in the 4.2.0 days),
    > it suddendly stopped to recompile SQLRPGLE-generated programs.
    >
    > I was on the way of rewriting it using more 'elegant' approch when i
    > notice that the souce data retrived from the "List program Informatio"
    > API (QBNLPGMI/QBNLSPGM) didn't point to the original source
    > Library/file/member, but to an intermediate SQL-generated member in qtemp.
    >
    > This causes (a) the program inability to get the correct source type and
    > (b) cannot compile from a non-existant source.
    >
    > I do some check with old prog in my work lib, and it came out that up to
    > 5.1.0 the source retrieved from API was correct, but up to 5.3.0/5.4.0
    > it retrieves the faul value.
    >
    > May anyone tell me if there's a parameter to change to get the correct
    > vaue or any other hint that can be used in order to retrive it
    > post-compile ???


    The information is available in current releases as it was in previous
    releases. However, the methods used to retain it might have changed.

    The commands used to compile the programs might have been run
    differently. Since I don't know the exact sequence that was used at your
    site before V5R1, I can't compare it to how they were executed since V5R1.

    In order to maintain the module source information, it is necessary to
    cause the SQL preprocessor to generate its source into a known source
    file rather than having it generate into a QTEMP source file and letting
    it compile from there.

    I don't have SQL available where I am right now, so I can't bring up the
    commands to verify how parms must be set. But the idea is to use the
    option not to generate a bound program, e.g., *NOGEN.

    The preprocessor can generate the source, and it stops at that point.
    You then can run a normal CRTRPGMOD or CRTBNDRPG from the permanent source.

    Also, it's possible that before V5R1, the programs were compiled as OPM
    rather than ILE.

    I realize that none of that is helpful. I just hope it gives you ideas
    on what might be done in the future. For now, I think that any debug
    info -- *LIST for example -- in the program might be the best clue.

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

  3. Re: File source for SQLRPGLE compiled object

    Thomas ha scritto:
    > Obelix-it wrote:
    > The information is available in current releases as it was in previous
    > releases.

    But they are non exactly correct informations...

    >> However, the methods used to retain it might have changed.


    My fault, didn't explain enough.

    Everything from 'our' side remain the same. We move to ILE back in te
    4.2.0 time (we do this proc just because OPM and ILE pgm behaviour
    differently).

    We have an strinct inside policy so that all item compiled with PDM
    option 14 (except from Module and SRVPGM, obviously).

    And still,the retrieving API is there from 2.3.0 or about. And still, if
    IBM make changes, i expect the API to reflect this.

    So, this was not something not exactly depending by our side.

    Finally, however, i got it: in the 5.3.0 a new parm was added to
    CRTSQLRPGI : RPGPPOPT(). We have this set up to *LVL2 to be able to
    compile source with multiple nested /copy. As a side-effect, however,
    the creating object result in having its source reference incorrect.

    I don't think IBM will fix this (i neither thik they consider it a
    bug...) so i will have to go around this...

    If anyone have any idea on how to fix this (maybe that the API for
    changin object may allow this ref to be changed??) it would be
    appreciated: i was starting to think about tampering 'roud with exit
    point and so forth...




  4. Re: File source for SQLRPGLE compiled object

    So the information retrieved by the API is the original source
    file.mbr referenced by the CRTSQLRPGI, *except* when using the newer
    parameter RPGPPOPT(); i.e. a value other than *NONE is specified? And
    presumably [defaulting or] specifying *NONE mimics prior release behavior?

    Simply presuming the issue will not be considered a defect will leave
    one wanting resolution; as apparently is the case here. At least by
    reporting the problem to the IBM service, a specific answer could be
    obtained [best documented in an APAR as to why; if not referenced in
    docs already], rather than simply assuming the answer is already
    decided. If there are no docs to state so, then as far as anyone knows,
    the development team does not even know that the condition [as a
    perceived problem] exists.

    FWiW: Just as there are the binder APIs [being used] to list program
    information, there may be some Binder APIs that enable setting the
    source file and member information [at/after create time]. The
    preprocessor compiles that are done by the SQL precompiler are really no
    different than how one would create their own preprocessor using the
    binder APIs. An InfoCenter search for _ qbn* api _ gives some other
    retrieve APIs as well as others that might be worth review. In the
    RPGPPOPT() however, the RPG compiler is apparently being invoked as a
    preprocessor to a preprocessor, so perhaps the lack of consistency was
    an oversight.

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    Obelix-it wrote:
    > <>
    > Finally, however, i got it: in the 5.3.0 a new parm was added to
    > CRTSQLRPGI : RPGPPOPT(). We have this set up to *LVL2 to be able to
    > compile source with multiple nested /copy. As a side-effect, however,
    > the creating object result in having its source reference incorrect.
    >
    > I don't think IBM will fix this (i neither think they consider it a
    > bug...) so i will have to go around this...
    >
    > If anyone have any idea on how to fix this (maybe that the API for
    > changing object may allow this ref to be changed??) it would be
    > appreciated: i was starting to think about tampering 'round with exit
    > point and so forth...


+ Reply to Thread