Subroutine selection when called from a test program

I am trying to confirm how U2 handles this inherently:

• 1st run a program from my own MY.BP  ex: "RUN MY.BP TEST.PGM" 
• TEST.PGM calls a subroutine, ex: TEST.SUB(arg1),  that exists in both the account's BP (cataloged in VOC) and a special version in MY.BP.O

1. 1. will U2 first look at the VOC to execute the subroutine and then, if not found, look in MY.BP (where the original pgm was run from)
   2. will U2 1st try to run the MY.BP version, and if not found, run the one cataloged in the VOC
   3. or, must I name my version to be unique, ex: call TEST.BP.NELSON(arg1), to have it run my version

We often have a group of programs and subroutines that handle a process, and we are making changes to some of the subroutines, but not all.  Understanding the U2 rules of engagement would really help.

Nelson

I am trying to confirm how U2 handles this inherently:

• 1st run a program from my own MY.BP  ex: "RUN MY.BP TEST.PGM" 
• TEST.PGM calls a subroutine, ex: TEST.SUB(arg1),  that exists in both the account's BP (cataloged in VOC) and a special version in MY.BP.O

1. 1. will U2 first look at the VOC to execute the subroutine and then, if not found, look in MY.BP (where the original pgm was run from)
   2. will U2 1st try to run the MY.BP version, and if not found, run the one cataloged in the VOC
   3. or, must I name my version to be unique, ex: call TEST.BP.NELSON(arg1), to have it run my version

We often have a group of programs and subroutines that handle a process, and we are making changes to some of the subroutines, but not all.  Understanding the U2 rules of engagement would really help.

Nelson

Nelson,

I've been burmed by this - when someone removes a catalogued entry whoch they think is not eamted any more and the order of precedence means that it does not fail on invocation - it just runs a different program.causing a hidden failure. The same can happen if a program of teh same name is catalogued - possibly elsewhere - that sits in a higher order of precedence and hijacks the code you thought was being used.

As a suggestion, rather than having multiple versions of programs with the same name - whihc can be confusing at best -  have an array of subroutine names and use CALL @var to call specific individually named subroutine programs - and only have ONE version of any named program or subroutine catalogued in individual accounts.  You could also use a control flag to determine whether live or test program names are used as also illustrated below by a named common flag. - e.g.

COMMON /MODE/ RUNTIME.MODE

DIM S.SUBROUTINES(200)

MAT S,SUBROUTINES=''

EQU S.CUST.SUBR TO S.SUBROUTINES(1), S.PAYROLL.CALC.SUBR TO S.SUBROUTINES(20, etc.....

OPEN '',RUN.MODE;'SYSTEM.PARAMS' to F.PARAMS ELSE STOP 'CANNOT OPEN F.PARAMS'

MATREAD S,SUBROUTINES FROM F.PARAMS,'SYSTEM.SUBROUTINES'  ELSE STOP 'CANNOT READ SYSTEM.SUBROUTINES FROM SYSTEM.PARAMS'

...

...program logic

...

CALL @S.CUST.SUBR(arg1,arg2,arg3...)

Regards,

JJ

I am trying to confirm how U2 handles this inherently:

• 1st run a program from my own MY.BP  ex: "RUN MY.BP TEST.PGM" 
• TEST.PGM calls a subroutine, ex: TEST.SUB(arg1),  that exists in both the account's BP (cataloged in VOC) and a special version in MY.BP.O

1. 1. will U2 first look at the VOC to execute the subroutine and then, if not found, look in MY.BP (where the original pgm was run from)
   2. will U2 1st try to run the MY.BP version, and if not found, run the one cataloged in the VOC
   3. or, must I name my version to be unique, ex: call TEST.BP.NELSON(arg1), to have it run my version

We often have a group of programs and subroutines that handle a process, and we are making changes to some of the subroutines, but not all.  Understanding the U2 rules of engagement would really help.

Nelson