Sponsored Links
Sponsored Link

sponsored links

Collapse

Announcement

Collapse
No announcement yet.

MCH1202 RPGLE fix

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

  • MCH1202 RPGLE fix

    Hi guys, I have an old RPGLE program which reads an input file and writes an output file, it does several operations inside and move data from the input to the output based on some business rules. this program runs but in the log it records several messages Decimal data error MCH1202.. how can I fix it, because it writes several joblogs with a huge number of pages. I want to catch it and to not write anymore this decimal data error.

  • #2
    I just found something interesting, it is possible to use a parameter in the compile command, FIXNBR(*ZONED)? I just want to do not receive anymore the error in the joblogs

    Comment


    • #3
      Why not fix the cause of the error?

      FIXNBR will probably help but whether it will give you the results you want depends on the type of error. I don't recall if the error is still logged or not - you'd have to check that.

      You don't say exactly where the error occurs, but if it is on the actual input operation it can be avoided by using DS I/O. i.e. define a Data Structure using LIKEREC for the input file and then do:

      READ fileName DSName;

      That will prevent an error on the read and then you can use MONITOR to catch errors on moving the fields to the output record and fix each field in error appropriately.

      Comment


      • #4
        I have some fields from the input file read inside the program with some null values into the fields, it contained "++++++++++++++" value... and if I do eval myfield during the debug it shows zero.. so, I thought to fix the data into this input file, how can I update the fields with this issue? I want to do before the call of this RPGLE program, so when this program will run it will have a correct file to process, this program is called from an CLLE, so I thought to do the update here, what do you think?
        however the records with this issue is not processed corectly inside the RPGLE so.. I want to update with zero or eliminate before, do you think it is feasible?

        Comment


        • #5
          You haven't told us the cause of the decimal data errors, so we can't exactly tell you how to fix them.

          I think Jon is assuming (and he's probably right) that this is using the old program-described file paradigm of writing blanks for any field that isn't used in a program. When those blanks are read by a different program (that assumes the field is numeric) it gets decimal data errors. The proper fix, in that case, is to modify the programs that are writing blanks so that they now write packed zeroes, so that the field values are actually valid numbers.

          I haven't seen that problem in over 20 years... but, you did say this was an old program.

          Is that what's happening? If not, please tell us what *is* causing the problem. Thanks!

          Comment


          • #6
            the issue is from a file feed by some programs for which I can not see the sources because there are part of the core application, it's not something custom, so, it is used a core file, feed with data, to create a work-file with some condition to avoid this issue, in the CPYF is used a criteria to exclude some records which could generate decimal data error but as it seems it's not enough, we have another more records which generates decimal data error. so what I want to do is to fix the data into the work-file, because it is already an attempt to correct data but it's not enough and I don't want to investigate what records with what specific criteria might be the cause of the decimal data error because in the future it might appears others and all I want is to delete/update all the records in the work-file which are not good, as I saw I can use an intermediate file generated by a query, with WRKQRY and to ignore the decimal data error and after this step to copy those data into the work-file used further, what do you think? and how it will be ignored the decimal data error in the file created by the query? thanks a lot for your quick responses

            Comment


            • #7
              I have no experience with using WRKQRY.

              One approach that should work well is the one that Jon described... assuming you're able to write this in RPG IV, read the data into a data structure, check the numeric fields to make sure they are valid, and if not valid, replace them with zeroes. Then write the work file from that.

              Another approach (the one we used to use 20+ years ago) is to read the fields in character format as a program-described file and check those, then write the results as proper numbers.

              Comment


              • #8
                You may also use SQL: Convert the numeric field(s) into hex and scan the result for Blanks:
                Code:
                Select a.*
                   from YourFile
                   Where HEX(YourNumFld) like '%40%';
                You may even be able correct it in this way:
                Code:
                Update YourFile
                   Set YourNumFld = 0
                   Where HEX(YourNumFld) like '%40%';

                Comment


                • #9
                  Thanks Brigitta, I think I'll do with your idea, so with this conversion I'll catch only the records that have blank into the numeric field right? so, in hex only the blank is composed by '40'?

                  Comment


                  • #10
                    Birgitta is probably asleep as she's in Germany and it now midnight.

                    <<Edited>> I misread the SQL. Biggest issue will be having to code for each and every field. Personally I'd do it with RPG unless you are certain that it is only blanks that are causing the issues.
                    Last edited by JonBoy; June 7th, 2018, 06:17 AM.

                    Comment


                    • #11
                      understood, thanks a lot

                      Comment

                      sponsored links

                      Collapse

                      Working...
                      X