Skip to main content

How to get an error when CALL a program that doesn't exist

  • May 26, 2016
  • 4 replies
  • 0 views
D

I have a COBOL program that calls the next program in a series of programs (in house transactional system). It calls a program using this syntax:


CALL NEXT-PROG USING blah blah blah

NEXT-PROG is the next program in the series.

most of the time this works great. We have this in a RUNUNIT, so we isolate what is being run. However, we recently ran into a problem. The program being called had the headers mixed up. It's an abort routine, and it should only be called if another program error-ed out. This program wasn't being executed, although it compiled. During our conversion process this program had a copybook put in front of the PROGRAM-ID, forcing the system to not recoginze it. First lines looked like this:

      $SET CHECKNUM
       REPOSITORY.
           COPY CONNECTIONCLASSESREPOSITORY.
       IDENTIFICATION DIVISION.
       PROGRAM-ID. TPR365S-017.
The call is executed, but the return value is always 0, even when the program isn't recognized, and no code is executed.

Is there something I can do, or a directive to set, to get an error when the program doesn't exist, is improper, or otherwise won't execute? Right now the program acts like it executed normally, return-code is 0.

    4 replies

    Chris Glazier
    Forum|alt.badge.img+2

    I have a COBOL program that calls the next program in a series of programs (in house transactional system). It calls a program using this syntax:


    CALL NEXT-PROG USING blah blah blah

    NEXT-PROG is the next program in the series.

    most of the time this works great. We have this in a RUNUNIT, so we isolate what is being run. However, we recently ran into a problem. The program being called had the headers mixed up. It's an abort routine, and it should only be called if another program error-ed out. This program wasn't being executed, although it compiled. During our conversion process this program had a copybook put in front of the PROGRAM-ID, forcing the system to not recoginze it. First lines looked like this:

          $SET CHECKNUM
           REPOSITORY.
               COPY CONNECTIONCLASSESREPOSITORY.
           IDENTIFICATION DIVISION.
           PROGRAM-ID. TPR365S-017.
    The call is executed, but the return value is always 0, even when the program isn't recognized, and no code is executed.

    Is there something I can do, or a directive to set, to get an error when the program doesn't exist, is improper, or otherwise won't execute? Right now the program acts like it executed normally, return-code is 0.

    I am a bit confused. You say that you are using this within a RunUnit but that you are using a standard CALL statement to call the program. If it is within a managed RunUnit class instance then you should be calling it using the RunUnit::Call method.

    Also the syntax that you are using with REPOSITORY appears to be from an older style OO program that may be either managed or native.

    I am not sure that the return-code special register is a valid method of checking the success of a call statement. Normally if a program could not be found a RTS 173 error would occur. This could be trapped using exception handling in a try/catch block if you were using managed code.

    Can you please clarify what exactly it is that you are using along with a sample of the call statement being used?

    Thanks.

    Chris Glazier
    Forum|alt.badge.img+2

    I have a COBOL program that calls the next program in a series of programs (in house transactional system). It calls a program using this syntax:


    CALL NEXT-PROG USING blah blah blah

    NEXT-PROG is the next program in the series.

    most of the time this works great. We have this in a RUNUNIT, so we isolate what is being run. However, we recently ran into a problem. The program being called had the headers mixed up. It's an abort routine, and it should only be called if another program error-ed out. This program wasn't being executed, although it compiled. During our conversion process this program had a copybook put in front of the PROGRAM-ID, forcing the system to not recoginze it. First lines looked like this:

          $SET CHECKNUM
           REPOSITORY.
               COPY CONNECTIONCLASSESREPOSITORY.
           IDENTIFICATION DIVISION.
           PROGRAM-ID. TPR365S-017.
    The call is executed, but the return value is always 0, even when the program isn't recognized, and no code is executed.

    Is there something I can do, or a directive to set, to get an error when the program doesn't exist, is improper, or otherwise won't execute? Right now the program acts like it executed normally, return-code is 0.

    One additional item, you can also use the ON EXCEPTION clause with the CALL statement which will allow you to recognize when the call has failed and this works in both native and managed code.

    CALL prog-name

        ON EXCEPTION

               display "error on call".

    D

    I have a COBOL program that calls the next program in a series of programs (in house transactional system). It calls a program using this syntax:


    CALL NEXT-PROG USING blah blah blah

    NEXT-PROG is the next program in the series.

    most of the time this works great. We have this in a RUNUNIT, so we isolate what is being run. However, we recently ran into a problem. The program being called had the headers mixed up. It's an abort routine, and it should only be called if another program error-ed out. This program wasn't being executed, although it compiled. During our conversion process this program had a copybook put in front of the PROGRAM-ID, forcing the system to not recoginze it. First lines looked like this:

          $SET CHECKNUM
           REPOSITORY.
               COPY CONNECTIONCLASSESREPOSITORY.
           IDENTIFICATION DIVISION.
           PROGRAM-ID. TPR365S-017.
    The call is executed, but the return value is always 0, even when the program isn't recognized, and no code is executed.

    Is there something I can do, or a directive to set, to get an error when the program doesn't exist, is improper, or otherwise won't execute? Right now the program acts like it executed normally, return-code is 0.

    When I say I am using this within a rununit, this is the call that is made (this is in an aspx codebehind):

              perform using ts as type TransactionScope = new TransactionScope()

                  set myRunUnit to new MicroFocus.COBOL.RuntimeServices.RunUnit

                  try

                      invoke myRunUnit::Call("CALLNEXTTPR", NEXT-PROG, TDS-STORAGE, CONSTANT-STORAGE, TRANSACTION-STORAGE, UCT-SESSION)

                  catch excep

                      move "Y" to UCT-ABORT-CODE

                      display "CALLNEXTTPR RunUnit Error: " excep::Message

                  finally

                      invoke myRunUnit::StopRun()

                      set myRunUnit to null

                      if NOT UCT-ABORT-CODE = "Y"

                             invoke ts::Complete()

                      end-if

                  end-try

              end-perform

    CALLNEXTTPR is the program used to execute the next program in the sequence, stored in NEXT-PROG.

    In CALLNEXTTPR, the CALL that is used to execute the program is here:

              try

                  *> open sql connection to pass to TPR

                  PERFORM 9000-CONNECT-TO-DATABASE THRU 9000-CONNECT-TO-DATABASE-EXIT

                  CALL NEXT-PROG USING TDS-STORAGE, CONSTANT-STORAGE, TRANSACTION-STORAGE, UCT-SESSION, sc, tr

                  *> check the abort flag, if Y then don't commit

                  if UCT-ABORT-CODE NOT = "Y" then

                      perform 9000-COMMIT THRU 9000-COMMIT-EXIT

                  else

                      perform 9000-ROLLBACK THRU 9000-ROLLBACK-EXIT

                  end-if

              catch ex

    That CALL statement is not erroring out, when TPR365S-017 is compiled (successfully, but is not recognized as a program because the COPY REPOSITORY statement is in the wrong place). I would think that the CALL statement should error out, because that program isn't recognized. I did try the ON EXCEPTION statement too, still returned 0. I verified the return code as being 0, moving 1 to the return code before the CALL statement, and setting a breakpoint afterward.

    I am not seeing why the error isn't being thrown, I had seen in the documentation that it should be.

    Chris Glazier
    Forum|alt.badge.img+2

    I have a COBOL program that calls the next program in a series of programs (in house transactional system). It calls a program using this syntax:


    CALL NEXT-PROG USING blah blah blah

    NEXT-PROG is the next program in the series.

    most of the time this works great. We have this in a RUNUNIT, so we isolate what is being run. However, we recently ran into a problem. The program being called had the headers mixed up. It's an abort routine, and it should only be called if another program error-ed out. This program wasn't being executed, although it compiled. During our conversion process this program had a copybook put in front of the PROGRAM-ID, forcing the system to not recoginze it. First lines looked like this:

          $SET CHECKNUM
           REPOSITORY.
               COPY CONNECTIONCLASSESREPOSITORY.
           IDENTIFICATION DIVISION.
           PROGRAM-ID. TPR365S-017.
    The call is executed, but the return value is always 0, even when the program isn't recognized, and no code is executed.

    Is there something I can do, or a directive to set, to get an error when the program doesn't exist, is improper, or otherwise won't execute? Right now the program acts like it executed normally, return-code is 0.

    I cannot reproduce the problem that you are reporting. If the program you are calling truly does not exist then the try-catch or on exception is reporting the error for me and I get a RTS 173 on the call.

    I cannot get a program with the repository in front of the id division to compile without an error.so I cannot test this. If you wanted to catch the error in the top level program then you would need to reraise the exception as you are already handling it within the CALL NEXT-PROG.

    If you would like to pursue this further then I would recommend that you open up a support incident with customer care so we can test this using your actual code to see if we are able to reproduce the problem that way.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement