Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

RPG Gets XML Boost in V5R4

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

  • RPG Gets XML Boost in V5R4

    ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
    ** This thread discusses the Content article: RPG Gets XML Boost in V5R40

  • #2
    RPG Gets XML Boost in V5R4

    ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
    nice option but when is IBM going to address the issue of MOVEA command?

    Comment


    • #3
      RPG Gets XML Boost in V5R4

      ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
      Bob, It looks like the new extensions will be helpful for implementing XML based Web Services. I think I get the picture for processing XML nodes, but what about processing node attributes? For example:
      Code

      Comment


      • #4
        RPG Gets XML Boost in V5R4

        ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
        Bob, The major problem is that EVAL-CORR is like a time bomb, waiting for some careless or inattentive maintenance programmer to modify one of the structures a bit for some reason, changing the fields that are corresponding. This problem is compounded by the fact that you have to read the compiler listing to tell you which fields are being referenced. (Who reads the listings of clean compiles.) No one could argue that EVAL-CORR adds to clarity, for only a detailed inspection of both structures reveals which fields will be affected. At best it is a shortcut that can easily return to bite you when least expected. Clarity is more important than brevity. Otherwise, why not always use the shortest data names we can think of? Seems odd that you think this is a good idea, but how awful it is to leave out coding an ‘A’ for an alpha field in DDS.

        Comment


        • #5
          RPG Gets XML Boost in V5R4

          ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
          tom, you won't have to do a detailed inspection of both structures. The compile listing will have a full summary of every field considered in both data structures, with an indication of how that field was handled. An example of what it will look like is in the Raw Code section. It's true that a change to one of the structures would cause the behaviour of the EVAL-CORR to change, but surely any change to a data structure would require the programmer to see how the data structure was being used. The alternative also gives opportunity for error: say you expect all the same-name fields from DS1 to be assigned to DS2, and you do all the assignments explicitly. Now a new field gets added to both data structures, but the programmer forgets to add an assignment line for that subfield. RPG already has a similar function to EVAL-CORR in the way it handles input and output fields. If you have two files both having field FLD1, you can read FILE1 and write to FILE2 without ever mentioning FLD1 in your program.
          Code

          Comment


          • #6
            RPG Gets XML Boost in V5R4

            ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
            Works the same way. A node or an attribute are specified the same way.

            Comment


            • #7
              RPG Gets XML Boost in V5R4

              ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
              Barbara, Thanks for the preview of the compiler listing. That is clear and will help. Personally, I would find the opcode most useful in one-time fix or conversion programs and in teaching and publication type examples and would proceed with caution elsewhere. I think as time goes on you will find it's one of those opcodes that is either loved or hated.

              Comment


              • #8
                RPG Gets XML Boost in V5R4

                ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
                Tom, I don't believe EVAL-CORR will have a love/hate relationship with RPG IV programmers. MOVE Corresponding in COBOL has been there for decades and interestingly, some COBOLers don't even know about it (including my High School COBOL teacher, if you can believe that!) It isn't bad, it is just new. Sure EVAL A = B is straight-forward. But EVAL-CORR (although I still prefer EVALMap) is certainly going to be a clear indication of what is happening on the instruction.

                Comment


                • #9
                  RPG Gets XML Boost in V5R4

                  ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
                  Bob, I'll have to yield to your knowledge of the RPG IV programming community on this one. Just as an FYI, for over 30 years some COBOLers treat the CORRESONDING verb in COBOL in the same category as GOTO and ALTER, so you can see where I've come to my conclusion. By the way, even lesser known are the ADD CORRESPONDING and SUBTRACT CORRESPONDING in COBOL. I wonder if these will be added in a future release of RPG IV.

                  Comment


                  • #10
                    RPG Gets XML Boost in V5R4

                    ** This thread discusses the article: RPG Gets XML Boost in V5R4 **
                    Bob: I'm tempted to comment on EVAL-CORR since it's the function I was working on when the reorg occurred 19 months ago. First, regarding the name. Sure, "EVAL-CORR" may not be the greatest name. But at the time, we went through a list of about a dozen possibilities, and this was the least awful of the choices. At least, the chosen name reflects the way the opcode works by moving corresponding subfields. Regarding the possible dangers in EVAL-CORR, I think I have to sympathize with Tom's concerns. Adding subfields to data structures may well result in hard to debug side effects. By seeing EVAL-CORR in a program, it's not necessarily clear exactly what's happening. The fact that what's being moved is described in the compile listing is little comfort if you don't bother reading the listings. (Who reads listings for successful compilations?) On the other hand, data structures are already inherently fraught with danger, and EVAL-CORR is no worse than existing DS functionality. Consider that there's no type checking done when assigning data structures. That's true even for qualified DS's. Since DS's are considered character variables by RPG, one DS is equally assignable to any other DS or character variable regardless of "type". (On the other hand again, few RPG programmers seem to think there's any need for additional strong type checking in the language! Maybe RPG programmers really like to debug difficult problems?) Why was EVAL-CORR added? This was deemed necessary by some in the RPG development team after the enhancement of DS I/O in V5R2 and V5R3. In traditional I/O, you can READ from one record and WRITE to another different record with no intervening moves of data since common global static variables are used for the fields. But with DS I/O, you don't have that luxury. You had to move the affected subfields one by one. Now, you can code a shortcut: READ into DS1, EVAL-CORR DS2=DS1, and WRITE from DS2. Will or should EVAL-CORR be used in other situations? Personally, I'm not sure. If you need to keep related information together, you should define a "template" DS, and define your working store using LIKEDS. EVAL-CORR has absolutely no benefit when assigning two DS's defined identically using LIKEDS. Bob, since your COBOL teacher didn't use MOVE CORRESPONDING, obviously he didn't have much use for it. Thinking about it now, I rather suspect EVAL-CORR might suffer the same fate. But it's obviously still too early to tell. Cheers! Hans

                    Comment

                    Working...
                    X