ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

XML SAX parser detected error code 301 at offset 0?

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

  • XML SAX parser detected error code 301 at offset 0?

    I'm trying to get an old routine working written by someone who has retired. It uses XLM SAX on an IFS file (the only program on our system using XML SAX). The IFS file opens fine in a browser, but when I run the program the XML SAX routine reports back :

    Message . . . . : The XML parser detected error code 301.
    Cause . . . . . : While parsing an XML document for an RPG procedure, the
    parser detected an error at offset 0 with reason code 301. The actual
    document is Upload/RMAAL4.xml;

    Since the file opens in a browser, I assume the XML is valid....but oddly the XML parsing fails at offset ZERO! I can't find any reference anywhere to what this might mean. The code seems to be a copy/paste of various IBM examples, so all the parameters to the handler seem OK. I wonder if it's something else, and the XML parsing error is in fact a Red Herring??

    Any help gratefully received!

    Best wishes

    Vince

  • #2
    Well, according to: https://www.ibm.com/support/knowledg...c092507227.htm, that error code indicates:
    The %HANDLER procedure for XML-INTO or XML-SAX returned a non-zero value, causing the XML parsing to end.

    Cheers,

    Emmanuel

    Comment


    • #3
      My best guess is that this specific file contains a BOM (Byte Order Mark) that previous files did not or that this one has the wrong code-page and the OS is not removing it as it should. So - what is different about the source of this file?

      Have you looked at the file via EDTF? that would show you if there is a BOM present.

      Comment


      • #4
        I?ve never heard of a BOM! The file looked ok in wrklnk, but maybe that?s not the same thing!
        The file is emailed to us and we copy it to the IFS and process it from there, I?ve no idea how long it?s been failing for as luckily the data is fairly static, but now need fixing as part of another project. If there IS a BOM, how do you remove it?

        Comment


        • #5
          Try EDTF and see if anything shows up. Or simply look at the file on a PC with an editor that has a hex mode available.

          What is the code page (CCSID) for the file? It may be that it is not the correct value for XML-SAX.

          Comment


          • #6
            It was 1252 when on the IFS initially I think, ive tried copying it to a 1208 version and a 37 uk one, but neither seems to help. The annoying part is the XML SAX element can?t be debugged, so you can?t walk it through element by element.

            Comment


            • #7
              Don't copy it - that will just result in it attempting to make code page conversions which won't help if it should not have been 1252 in the first place. Instead try changing the code page to 1208 in-situ and see.

              I'm happy to take a look at the file for you if you can send it to me jon dot paris at partner400 dot com

              Comment


              • #8
                The BOM is a normal and expected part of Unicode. Don't remove it! Instead, find out what's happening, here... why on earth would a file marked as CCSID 1252 have a BOM? CCSID 1252 is Windows Latin-1, which isn't Unicode, it's an an old ASCII character set that not even Microsoft uses anymore. Something bad is happening here...

                Find the error in the file transfer process that is causing this file to be marked 1252 instead of (most likely) 1208, and fix it... that will solve the problem.

                Comment


                • #9


                  Many thanks for all the assistance....i think I've got to the bottom of it....sorry if this explanation is a bit vague, I don't fully understand XML-SAX and this program is the only one on our system that uses it!

                  The file is emailed in a zip file to our operators. They unzip it on their PC to the file RMAALL.XML

                  They then copy and paste it from there using windows explaorer to a mapped drive pointing at folder QDLS/UPLOAD

                  The file when displaying it's attributes via WRKLNK does show as 1252.

                  However, I noticed in the code a small fix from last December outside the XML-SAX code that checks the return code after the call to the handler. Here it cheks for return codes 302 etc to report relevant errors, but an 'other' had been added saying 'unknown xml error' and would end the program had been added for everything except the 'expected' errors. return code 301 fell into this.

                  In the program we have we seem to be using the XML-SAX to skip from tag to tag looking for ones that we we want, I think the program has something in the handler routine that seems to set a non-zero return value which causes the parser to end when the program thinks it's 'finished' so forces the parsing to end, returning a return code of 301 and this in turn now ends the program.

                  It does seem to extract data (I deliberately cleared a file, and after it ran I could see the file was re-populated)....

                  SO! If my reading is correct, the handler routine is setting a value on to end the parsing which causes the program to end, the side effect seems to be an 'error' message being reported, when in fact its deliberately done in order to terminate the processing.

                  Not sure if any of this makes sense, but it does seem as if the program works and the whole "The XML parser detected error code 301. " is a bit of a red herrring! A day of my life I won't be getting back!!!

                  Thanks again for taking the time to read my ramblings

                  Best wishes.

                  Vince

                  Comment


                  • #10
                    I doubt very much that this has anything to do with the handler routine...

                    The fact that you are using QDLS explains much of this. This is 1980's technology, here... meant to work in conjunction with PCs running MS-DOS. (Not even Windows 95... MS-DOS!!) So it makes sense that it's getting an outdated Microsoft CCSID.

                    Prior to running your RPG program that does XML-SAX, please run this command:
                    Code:
                    CHGATR OBJ('/QDLS/UPLOAD/whatever_it_is.xml') ATR(*CCSID) VALUE(1208)
                    Does that resolve the issue? The IBM i system is defaulting the file CCSID since Windows does not use them. It is picking 1252, which is wrong for this project... so you can change it before processing the file.

                    A better long-term solution might be to have a web application for transferring the file. The user could then just upload the file directly to your application which can create the file with the proper CCSIDs to begin with. You could then also process it immediately upon upload (as opposed to making the user run a separate program after copy/paste, or waiting for a scheduled batch job.) You'd have a lot more flexibility this way. Plus, you could get the file out of the godawful, slow, clumsy QDLS filesystem.

                    But, even if you don't want to improve the process, just running the above CL command before XML-SAX should sort things out.

                    Comment


                    • #11
                      Thanks very much Scott, this whole routine is pretty old, given the guy who wrote it retired 2 years ago!! I've got some xml stuff I've written using the IFS, but I've but never used QDLS...not sure if that's all that was available back then! I'll try the CHGATR tomorrow in the office and see if it helps, though bizarrely it is working (for it's limited needs), but the 'error' in parsing made me initially think the program wasn't working at all, but it seems it does.

                      Is there any reason this file couldn't be placed in a folder outside of QDLS, as long term that's probably better for processing and for transferring via a web solution as you say.

                      Thanks again for taking the time to reply and offer advice

                      Best wishes

                      Vince

                      Comment


                      • #12
                        Yes, I'd move it out of QDLS to somewhere else... I'm guessing that whomever chose that location did so because he was familiar with it. (Since he used XML-SAX, newer/better IFS locations were already available when he wrote this.) The only caveat might be that he's using QDLS specific code somewhere else in the process. So you'd need to find that (if it exists) and replace it with modern IFS code.

                        Comment


                        • #13
                          Hi again Scott, hopefully a final update!

                          I added the CHGATR, but the code 301 was still being reported, then checking the code again I FINALLY spotted this in the handler procedure:

                          // Finish at the end of the document
                          when event = *XML_END_DOCUMENT;
                          rc = -1;
                          *inlr = *on;
                          except end;


                          So when the XML END DOCUMENT is detected as an event, RC is set to -1 deliberately! I assume this means when the handler returns to the main SAX code this is when the return code 301 is set on, as according to IBM "The %HANDLER procedure for XML-INTO or XML-SAX returned a non-zero value, causing the XML parsing to end." which is true, as the procedure deliberately did it!
                          I've removed that from the program, and it still runs fine, but WITHOUT reporting a code 301 "error" now! I'm not why the person wrote it this way, but probably like myself he wasn't familiar with the XML SAX process, and as long as he got it working he wasn't too worried about rogue 'error' message.

                          It's been a bit of a learning curve for this for the one program we have using this opcode...but finally got SO?ME understanding of it.

                          Many thanks again for taking the time to explain some of this (while I knew it was an 'older' area of the system, I didn't know that QDLS went back THAT far!!)

                          Best wishes

                          Vince




                          Comment

                          Working...
                          X