sponsored links

Collapse

Announcement

Collapse
No announcement yet.

xml-into doesn't clear the DS??

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

  • xml-into doesn't clear the DS??

    Using the following statement
    Code:
    dcl-ds Items qualified dim(100);
    dcl-c OPTIONS const('doc=file case=any allowextra=yes allowmissing=yes path=');
    dcl-c ITEM_PATH const('folder/subfolder/');
    
    xml-into Items %xml(xmlfile: OPTIONS + ITEM_PATH);
    Just discovered "the hard way" that xml-into DOES NOT initialize the DS. I guess I "assumed" it operated like other eval statements. I have a call into IBM to confirm, but WOW!

  • #2
    IBM development has confirmed. They recommend using the COUNTPREFIX option - which is OK. Personally I don't like having "leftover data" in my program variables.

    So I took his suggestion and created an RFE to add a "clear" option to XML-INTO.

    This is the first one I've submitted, so please be kind. I would appreciate any votes:
    http://www.ibm.com/developerworks/rf...e&CR_ID=104125

    Comment


    • #3
      Originally posted by gwilburn View Post
      IBM development has confirmed. They recommend using the COUNTPREFIX option - which is OK. Personally I don't like having "leftover data" in my program variables.

      So I took his suggestion and created an RFE to add a "clear" option to XML-INTO.

      This is the first one I've submitted, so please be kind. I would appreciate any votes:
      http://www.ibm.com/developerworks/rf...e&CR_ID=104125
      I'm having a problem understanding why you would expect it to. Just INZ on the DS as normal. You obviously haven't shown us the full definition of the DS so I don't know where your problem was - but the number of Items would be in the DSDS count for the statement you show.

      allowmissing=yes is a very dangerous practice which is why I guess IBM suggested you use countprefix. Back in V5R4 we had no choice but to use it, but now you can avoid it easily.
      Last edited by JonBoy; April 25th, 2017, 07:20 AM.

      Comment


      • #4
        Originally posted by JonBoy View Post

        I'm having a problem understanding why you would expect it to. Just INZ on the DS as normal. You obviously haven't shown us the full definition of the DS so I don't know where your problem was - but the number of Items would be in the DSDS count for the statement you show.

        allowmissing=yes is a very dangerous practice which is why I guess IBM suggested you use countprefix. Back in V5R4 we had no choice but to use it, but now you can avoid it easily.
        The DS is initialized... that only clears it the first time you use it within the program. This DS is for line items of a specific order. The program reads a list of orders, looping through requesting line items for each specific order.

        I get what your saying about allowmissing=yes. I could take that out. And I understand the usage of countprefix - I've just never used it. Not sure what you mean by "DSDS".

        Regardless, I see no reason why the DS receiving XML data should retain any data from a prior XML-INTO operation.

        Comment


        • #5
          Originally posted by gwilburn View Post

          <snip>

          I get what your saying about allowmissing=yes. I could take that out. And I understand the usage of countprefix - I've just never used it. Not sure what you mean by "DSDS".

          Regardless, I see no reason why the DS receiving XML data should retain any data from a prior XML-INTO operation.
          For DSDS read PSDS - Sorry to confuse you.

          You seem to accept that it currently retains any INZ values. You also specify allowmissing=yes - so what would you expect to happen if (say) the original initialization included a non-default value and the related element was not present? Some people deliberately pre-load the DS with default values for optional elements. More importantly you have the option of issuing a clear or reset prior to invoking XML-INTO again which seems to me the a better approach as it retains flexibility.

          There are (as far as I know) three other op-codes that load data into a DS without changing all fields in the DS - EVAL-CORR and READ/EXFMT with result DS. XML-INTO is consistent with those behaviours.

          There's more of an argument for your feature when using %Handler because then there is no ability to specify default values for the DS that the handler receives.

          Comment


          • #6
            Originally posted by JonBoy View Post

            For DSDS read PSDS - Sorry to confuse you.

            You seem to accept that it currently retains any INZ values. You also specify allowmissing=yes - so what would you expect to happen if (say) the original initialization included a non-default value and the related element was not present? Some people deliberately pre-load the DS with default values for optional elements. More importantly you have the option of issuing a clear or reset prior to invoking XML-INTO again which seems to me the a better approach as it retains flexibility.

            There are (as far as I know) three other op-codes that load data into a DS without changing all fields in the DS - EVAL-CORR and READ/EXFMT with result DS. XML-INTO is consistent with those behaviours.

            There's more of an argument for your feature when using %Handler because then there is no ability to specify default values for the DS that the handler receives.
            For me it was simple logic... one of the elements in ITEM DS is a character field (Part_Nbr)... if it's blank I stop looping through the DS. Probably not the best way to code it, but in reality I should never receive an order line where that element is missing.

            To address the bold above... I disagree completely. Very few opcodes require us to "clear" the variable before using (re-using) it. Yes, MOVE and MOVEL - absolutely. But we are supposed to be moving free-format coding. MOVE and MOVEL are "history" and replaced with EVAL (or the implied eval), which does clear the variable. IMHO the "most flexible" would be to have an OPTION value as my RFE states.

            Having said that... you likely have coded more XML handlers that I. And I'm always looking to improve my coding... So how would improve my XML-INTO logic?

            1. Removing allowmissing=yes
            2. Adding the countprefix? Or using PSDS?
            3. Using that integer to loop through ITEM DS

            Comment


            • #7
              Originally posted by gwilburn View Post

              <snip>

              Having said that... you likely have coded more XML handlers that I. And I'm always looking to improve my coding... So how would improve my XML-INTO logic?

              1. Removing allowmissing=yes
              2. Adding the countprefix? Or using PSDS?
              3. Using that integer to loop through ITEM DS
              Not sure what you meant by "bold" because I don't see any but ...

              That is exactly what I would do yes.

              Use the PSDS count when you can - which is basically when XML-INTO targets an array as the INTO variable and that is the loop level. Use countprefix when the array is nested within a larger document. For example line items within an order. Also use countprefix when there are optional elements.

              By the way - I agree that the "modern" RPG approach means that when we move data to a variable the whole variable changes. But the key word to me is _when_. Think about EVAL-CORR - it only changes the matching fields - it doesn't initialize the non-matching fields. Think about EXFMT wth result DS - only the input capable fields will change. When you use XML-INTO surely it is the same thing? Only the items found get chaged.

              Comment


              • #8
                Originally posted by JonBoy View Post

                Not sure what you meant by "bold" because I don't see any but ...

                That is exactly what I would do yes.

                Use the PSDS count when you can - which is basically when XML-INTO targets an array as the INTO variable and that is the loop level. Use countprefix when the array is nested within a larger document. For example line items within an order. Also use countprefix when there are optional elements.

                By the way - I agree that the "modern" RPG approach means that when we move data to a variable the whole variable changes. But the key word to me is _when_. Think about EVAL-CORR - it only changes the matching fields - it doesn't initialize the non-matching fields. Think about EXFMT wth result DS - only the input capable fields will change. When you use XML-INTO surely it is the same thing? Only the items found get chaged.
                Thanks for the advice...

                My personal opinion is that XML-INTO is NOT the same as the other two examples. Maybe someone who has used XML parsers in other languages could chime in.

                Regardless, I see no harm in having an option to initialize the DS. It only adds flexibility to the operation (and elminates lines of code).

                Comment


                • #9
                  Maybe someone who has used XML parsers in other languages could chime in.
                  I'm not aware of any other XML parser that works like XML-INTO where it moves a document into a pre-defined data structure that has the same structure. So it's hard to compare to other languages, because none of them work this way.

                  There are languages where a new structure/array is created by the XML parser on-the-fly. JavaScript/Node does this, and I believe PHP does (though it has been awhile since I've coded PHP, so I might misremember) but in these cases, you don't have a predefined structure that it populates, instead it creates a new one based on the structure of the XML. Since the structure didn't exist prior to parsing, you can't really compare it to XML-INTO.

                  So... really nothing to compare it to.

                  As for the idea of XML-INTO clearing the structure, there are several reasons this would not be ideal:

                  1) You'd throw away any values placed with INZ() or calcs prior to the XML-INTO. INZ() has a lot of really powerful capabilities, and I'd hate to lose them in order to set everything to blanks/zeroes.

                  2) There are times when not everything comes from an exact match of the XML document. The path= option on XML-INTO lets us parse a piece of the document at a time, so part of it can be placed in one area of the DS, and part in another area of the DS. Very similar to the way EVAL-CORR can be used to combine data from two different data structures into one. This is a very powerful/handy ability.

                  3) At this point: Backward compatbility would be broken. Many people rely on the way it works today, so changing it would break their programs.

                  Of course, for #3, you could add an option like XML-INTO(C) so that it only clears if you added this extender. But... why? What value does this serve -- you could just as easily do RESET or CLEAR of the DS on the line before the XML-INTO.

                  In the many years (I think 11 years, now/) that XML-INTO has been available to use, I have not heard anyone make such a big deal about this. Sure, I've seen one or two people surprised by it, but once they discovered it didn't initialize the structure, they were fine... they were like "okay, no big deal, I'll just initialize it". I'm not understanding why this is suddenly such a problem.

                  Comment


                  • #10
                    Originally posted by Scott Klement View Post

                    Of course, for #3, you could add an option like XML-INTO(C) so that it only clears if you added this extender. But... why? What value does this serve -- you could just as easily do RESET or CLEAR of the DS on the line before the XML-INTO.

                    In the many years (I think 11 years, now/) that XML-INTO has been available to use, I have not heard anyone make such a big deal about this. Sure, I've seen one or two people surprised by it, but once they discovered it didn't initialize the structure, they were fine... they were like "okay, no big deal, I'll just initialize it". I'm not understanding why this is suddenly such a problem.
                    I was surprised by it as well. And that is exactly how I handled it (clearing the DS).

                    I honestly was surprised when IBM suggested I open an RFE. This led me to believe that it may be surprising quite a few people.

                    Comment


                    • #11
                      I tend to not assume anything - clear the DS before you use the XML-INTO.

                      Comment


                      • #12
                        When IBM suggests opening an RFE, it doesn't imply that this is something that comes up often. It just means that it's not a bug, so to (possibly) get it changed, you have to open an RFE.

                        Comment

                        Working...
                        X