ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

SPECIAL file and UNIXCMD

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

  • SPECIAL file and UNIXCMD

    I am trying to use Scott Kelement's UNIXCMD (https://www.scottklement.com/unixcmd/) to compare text files on the IFS. I'm trying to do this in a loop, comparing a batch of files using DIFF.

    When a difference is found, I am able to read the results back, but then when I call CLOSE UNIX I get a "Child process ended with status 1" error.

    This is where I am stuck. I have tried reading to EOF on the special file, but this gives the same error when I try to close. When there is no difference in the files the call to close works fine, the problem only arises after reading a non-empty reply to the qsh program call. I've also tried the CMP command with the same results.

    I've stepped into the program with the debugger but the inner workings of UNIXCMD are above my pay grade so I could use some advice on where to look next.

  • #2
    What you are describing is the normal and correct behavior. Are you having some sort of problem?

    Comment


    • #3
      When I call close I get a RNQ1217 error message appeared during close. When I look at the job log the message before that error is cpf9999 Function check. RNX1217 unmonitored by UTLIVESRC at statement 0000002041, instruction X'0000' which points at the line of code where i'm calling CLOSE UNIX.

      Comment


      • #4
        It looks to me now that the return value from diff and cpm is considered an "error" when there is a difference in the files. When I was looking inside the RPG of UNIXPIPER4, the return was calling ReportError, which I had understood to mean that something had gone wrong and I did not understand. Have I got it now? If I monitor for the error back in my RPG and then re-open the UNIX command with my next diff everything works as expected.

        Comment


        • #5
          In the native IBM i environment, programs can end with no message or a completion message to indicate that they ran successfully. Or, they can end with an exception message (usually type=*ESCAPE) to indicate that they failed. The calling program can therefore always tell whether a program ended successfully because an exception message will cause the job to crash unless trapped with the CL MONMSG, RPG MONITOR, or another similar thing.

          Unix does not work the same way. In Unix, all programs end with an "exit status". Most of the time, an exit status of 0 means that they were successful, and anything else indicates an error occurred. But, this is just a "convention", any program can end with any exit status.

          Since it's not possible for UNIXCMD to be familiar with every Unix program and how its exit status works, it assumes that all programs follow the convention... that's the only way it can know if the program contained an error.

          "diff" does not follow this convention, however. It returns 0 for no differences, 1 for differences and >1 for error. Since it does not follow the normal convention, UNIXCMD will think that it is failing when differences are found. This is the expected behavior. You can use MONITOR to catch the error and can handle the error appropriately in your program. For example, you can use the results of MONITOR to detect whether or not the file had differences.

          So you see, this isn't a bug... it is the normal, expected behavior.

          Comment


          • #6
            Yes! Thanks for your replies Scott. After your first reply I dug into it a bit more and found some understanding. Your second reply solidified it for me.

            Thanks for the great software.

            Cheers.

            Comment

            Working...
            X