ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

"I" specification Equivalent translation in "D" Specification of RPGLE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • "I" specification Equivalent translation in "D" Specification of RPGLE

    Hi Friends,

    I am in the process of converting RPG program to RPGLE program. In this process, It necessiates an conversion of " I " specs to equivalent "D" specs equivalent.

    I specs - I FileRecordformat(Record name) 11 (record Id).
    (The record ID will be set ON, if we hit the record within the file which has the record format name matching here)

    Kindly let me know the equivalent syntax in D specs, if any.

    Thanks in advance,

    Regards,
    Prem

  • #2
    Re: "I" specification Equivalent translation in "D" Specification of RPGLE

    I specs are still valid in RPGLE...
    I'm not anti-social, I just don't like people -Tommy Holden

    Comment


    • #3
      Re: "I" specification Equivalent translation in "D" Specification of RPGLE

      Originally posted by tomholden View Post
      I specs are still valid in RPGLE...
      What tom said is 100% correct.

      If you truly want to lose the I specs you will need to convert to an externally defined file. There is no D spec equivalent to the I spec

      Best of Luck
      GLS
      The problem with quotes on the internet is that it is hard to verify their authenticity.....Abraham Lincoln

      Comment


      • #4
        Re: "I" specification Equivalent translation in "D" Specification of RPGLE

        If you did the sensible thing and did the initial conversion with IBM's free CVTRPGSRC (or even better the Linoma Tooolbox) then all this would have been done for you. No sense doing all the work by hand - that's just a make-work project.

        Comment


        • #5
          old post i realize but i'm researching converting I-specs and just don't see how CVTRPGSRC or Linoma Toolbox converter will convert I-specs for you. Like GLS400 said, the i-specs have to be externally defined and that cannot be done by a tool alone. CVTRPGSRC will only reformat the i-spec. Not sure how Linoma could determine proper externalizing either.

          Comment


          • #6
            1) The only conversion tools I am aware of that would convert I-specs are from way back in time and converted program described files to external descriptions. In other words they relate to early S/38 days and S/36 to AS/400 conversions. It is possible that Craig Rutledge has some functionality in his tooling but I doubt it.

            2) I haven't tried this but one approach would be to copy the existing I-specs and modify them to be a DS definition. That _would_ convert. You would then use program described files as now but would modify the I/O operations to use DS I/O. Not pretty but ...

            3) The OP's requirement was for cycle related functionality in the I-specs. The above approach would require manually coding to set the identifying indicator <shudder>.

            4) IBM have made it clear that the cycle (and hence I-specs) are not currently seen as part of RPG's future. As a result, Free-form declarations do not provide for any cycle related functionality.

            Comment


            • #7
              Well, seems i-specs can be converted fairly easily systematically - i just wrote a program to do it.

              Here?s a summary of how it works. (in ls#jhv)
              1. CALL PGM(CVTISPECS) PARM(a b c d e f g')
                1. ? source library of pgm externalizing
                2. ? source file of pgm externalizing
                3. ? source member of pgm externalizing
                4. ? the actual internally defined file name (on i-spec)
                5. ? library of object to reference for external names
                6. ? name of file objects for external names
                7. ? a simple mod marker for all commented/inserted lines of code
              2. Pgm mainline
                1. createNewSourceMember();
                  1. Copy source file into qtemp working space
                2. getReferenceObjectInfo();
                  1. retrieve external object info
                3. changeNewSourceMember();
                  1. examine i-specs for internal file name
                  2. look at start position and determine if corresponding start position from step b.
                  3. if not, skip
                  4. if so, comment out i-spec source line (include mod-marker and current date)
                    1. find all occurrences of internal name and comment out line (include mod-marker and current date)
                    2. insert new source statement replacing internal name with external name
              3. copyNewSourceMember();
                1. Copy qtemp working copy back to specified lib/file/mbr ? creating new member with a ?_? suffix and leaving original member untouched.

              Comment


              • #8
                You lost me here Jay.

                What "reference for external names" ? At what point is this created? And if it already exists why are there I-specs anyway? A sample would be useful here.

                I also wonder if this approach handles multiple/overlapping definitions. The existence of these is why it is often so hard to externalize I-spec type input.

                Comment

                Working...
                X