Announcement

Collapse
No announcement yet.

Error info from data-into

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

  • Error info from data-into

    I recently wrote a web service that uses data-into with Scott's parser to map a bunch of JSON variables from the request into data structure subfields. It works great, except I don't know how to extract and report specifics when the parsing fails. The scenario I'm mainly trying to cover is numeric overflow. Let's say the request contains a 2-digit number intended for a 1-digit subfield. The only message in the job log is this:

    Message . . . . : The document for the DATA-INTO operation does not match the RPG variable; reason code 8.
    ...
    8. The document contains data that cannot be successfully assigned to the RPG variable. The RPG status code associated with the failure is 103.

    I'd at least like to be able to report which JSON variable had an invalid value. Does the parser put that information somewhere I can retrieve it?

  • #2
    Since it says the RPG status is 103, you can see the actual error message by doing this:
    Code:
    DSPMSGD RANGE(RNX0103) MSGF(QRNXMSG)
    You ask if the parser can provide more detailed error information, but... in this case the parser doesn't know about the error. The parser understands the JSON document, but it does not understand your RPG variables -- that's handled by RPG (inside the data-into opcode) itself rather than the parser. So it doesn't have any way to know the names, lengths or sizes of your RPG variables, or that they will produce an error.

    That said, you can run a trace of the data-into parser by setting an environment variable like this:
    Code:
    ADDENVVAR ENVVAR(QIBM_RPG_DATA_INTO_TRACE_PARSER) VALUE(*STDOUT)
    You set that before you call your RPG program. When the program runs, it will see that variable and print details about what's happening to the screen. These details include the names of each JSON field encountered, and it's value. So at the point that the program stops, you can look at the last name reported, and -- most likely -- that will be the field that it's failing on.

    Comment


    • #3
      Just to add to Scott's answer but in the early days of XML-INTO IBM used to recommend that any variables that might be subject to such errors be made larger than needed. That way the process will complete fully and your own validation can be applied to determine the exact details of the problem. Just a thought.

      Comment


      • #4
        Thanks! I added the environment variable to my httpd.conf and verified it's in the CGI job. Now for the embarrassing part... how do I view stdout? The CGI job has no spoolfiles after reproducing the error.
        Display Environment Variable
        Name . . . . . . . . . : QIBM_RPG_DATA_INTO_TRACE_PARSER
        Value . . . . . . . . . : '*STDOUT'

        Comment


        • #5
          The error message gives the exact subfield that got the error. For example

          Code:
          Cause . . . . . : While parsing a document for the DATA-INTO operation, the
          parser found that the document does not correspond to RPG variable "ds" and
          the options do not allow for this. The reason code is 8. The exact subfield
          for which the error was detected is "ds.info(1).num2".
          That doesn't indicate the exact JSON data for the subfield, but it should be possible to figure it out.

          Comment


          • #6
            If the job is running in batch, the stdout output goes to a QPRINT spool file when the job ends.

            Comment

            Working...
            X