IBM Mainframe Forum

Need an advise how to retrieve from a COBOL/C a VCON variable
declared as ENTRY in an assembly language module?

Sample:
Assembly Language Program TEST1 declated ENTRY VAR as vcon
Assembly Language Program TEST2 access GLOBAL variable from TEST1 by just using V(VAR)

PROGRAM ASM : TEST1.ASM
ENTRY VAR
VAR DS (VARIABLE)C
TSRMAX EQU *


PROGRAM ASM : TEST2.ASM
L R6,VARADDR
**VCON AREA
VARADDR DC V(VAR)

If I have to replace TEST2 with a COBOL or C, how do I retrieve vcon global variable "VAR" declared in TEST1.ASM?

Presumably the two assembler programs are linkedited together?

Perhaps if you can describe how the VAR is used, and why the second assembler program might be going away?

There will be nothing documented in the COBOL manual for this. If the two programs were not linkedited together, you'd need to use the LOAD macro and probably have an ALIAS for VAR. Hit the C manual and discover if it has some "load" available, i suppose.

There are two, possibly three, incorrect ideas here.

1. The ENTRY Assembler instruction defines an external symbol. Period. Full stop. End of story.
2. An Assembler V type address constant specifies the address of an external symbol. Period. Full stop. End of story. How the external symbol is resolved is immaterial. Just so long as the symbol is available to the Binder. This is completely correct.
   Select all

   MODA     CSECT
            ENTRY MODATAB
            ...
   MODATAB  DC    0C'0'
            ...
            END   ,
   
   MODB     CSECT
            EXTRN MODATAB
            ...
   MODAADDR DC    V(MODA)
   TABADDR  DC    A(MODATAB)
            ...
            END   ,
   
3. Many lazy programmers regard a V type address constant as a simple way to combine an EXTRN Assembler instruction and an address constant. They do so at their peril. Unfortunately this is not discussed in reference material. The external symbol specified by a V type address constant should only specify an external symbol of code arranged as a true subroutine. These lazy programmers usually get away with ignoring this restriction, but sooner or later - most likely later - their program will fail.

BillyBoyo wrote:Presumably the two assembler programs are linkedited together?

Perhaps if you can describe how the VAR is used, and why the second assembler program might be going away?

There will be nothing documented in the COBOL manual for this. If the two programs were not linkedited together, you'd need to use the LOAD macro and probably have an ALIAS for VAR. Hit the C manual and discover if it has some "load" available, i suppose.

Thanks BillyBoyo, It is just a requirements to change TEST2 from ASM to COBOL or C.

steve-myers wrote:There are two, possibly three, incorrect ideas here.

1. The ENTRY Assembler instruction defines an external symbol. Period. Full stop. End of story.
2. An Assembler V type address constant specifies the address of an external symbol. Period. Full stop. End of story. How the external symbol is resolved is immaterial. Just so long as the symbol is available to the Binder. This is completely correct.
   Select all

   MODA     CSECT
            ENTRY MODATAB
            ...
   MODATAB  DC    0C'0'
            ...
            END   ,
   
   MODB     CSECT
            EXTRN MODATAB
            ...
   MODAADDR DC    V(MODA)
   TABADDR  DC    A(MODATAB)
            ...
            END   ,
   
3. Many lazy programmers regard a V type address constant as a simple way to combine an EXTRN Assembler instruction and an address constant. They do so at their peril. Unfortunately this is not discussed in reference material. The external symbol specified by a V type address constant should only specify an external symbol of code arranged as a true subroutine. These lazy programmers usually get away with ignoring this restriction, but sooner or later - most likely later - their program will fail.

Hi Steve-Myers, Thanks. Given the requirements that I have to rewrite TEST2 from ASM to CBL, is there any reference or sample you can suggest? tried COBOL / C / LE references but no luck. Thanks in advance.

What little you're telling us is far too generic. For example, does the external symbol in the Assembler program define a second routine that is called by other modules, or does it define data? The purpose of the external symbol is very important.

I do very little mainframe C, but something like this defines two external symbols for programs.
Now if the intent is to define data, I think something structured like this will define an external data area.
For me, Cobol in any environment is about as visible as the other side of the moon, so someone else should be able to assist you.

Unless you can also re-write TEST1 as COBOL and use a GLOBAL in COBOL, I don't think you're going to get too far on what we know.

If you answer the questions, it may help, but COBOL doesn't have a natural way of just picking up a VCON that is user-defined.

We need to know what TEST1 and TEST2 are doing, and what the purpose of VAR is. Even then, C and Assembler, perhaps PL/1, may be your only options.

I think this person is being set up to fail. He clearly knows very little about Assembler, and does not appear to know very much about Cobol or C. If he does not know very much Assembler how can he translate the business rules in place in the Assembler to Cobol or C primitives?

steve-myers wrote:What little you're telling us is far too generic. For example, does the external symbol in the Assembler program define a second routine that is called by other modules, or does it define data? The purpose of the external symbol is very important.

I do very little mainframe C, but something like this defines two external symbols for programs.

Select all

 int pgm1( ... )
  {
   ...
  }
 int pgm2( ... )
  {
   ...
  }

Now if the intent is to define data, I think something structured like this will define an external data area.

Select all

 int data = 5;
 int pgm1( ... )
  {
   ...
  }

For me, Cobol in any environment is about as visible as the other side of the moon, so someone else should be able to assist you.

Hi, again, thank you very much.. It defines data. I don't have any problem accessing VCON define as procedure as I tested it successfully.