COBOL or C calling VCON



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

COBOL or C calling VCON

Postby rbarnach1 » Sat Sep 21, 2013 4:50 am

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?
rbarnach1
 
Posts: 7
Joined: Sat Sep 21, 2013 4:35 am
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL or C calling VCON

 

Re: COBOL or C calling VCON

Postby BillyBoyo » Sat Sep 21, 2013 5:36 am

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: COBOL or C calling VCON

Postby steve-myers » Sat Sep 21, 2013 5:41 am

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.
    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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: COBOL or C calling VCON

Postby rbarnach1 » Sat Sep 21, 2013 7:18 am

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.
rbarnach1
 
Posts: 7
Joined: Sat Sep 21, 2013 4:35 am
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL or C calling VCON

Postby rbarnach1 » Sat Sep 21, 2013 7:48 am

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.
    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.
rbarnach1
 
Posts: 7
Joined: Sat Sep 21, 2013 4:35 am
Has thanked: 0 time
Been thanked: 0 time

Re: COBOL or C calling VCON

Postby steve-myers » Sun Sep 22, 2013 1:06 am

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.
 int pgm1( ... )
  {
   ...
  }
 int pgm2( ... )
  {
   ...
  }

Now if the intent is to define data, I think something structured like this will define an external data area.
 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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: COBOL or C calling VCON

Postby BillyBoyo » Sun Sep 22, 2013 2:06 am

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: COBOL or C calling VCON

Postby steve-myers » Sun Sep 22, 2013 5:29 am

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
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: COBOL or C calling VCON

Postby rbarnach1 » Sun Sep 22, 2013 6:27 am

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.
 int pgm1( ... )
  {
   ...
  }
 int pgm2( ... )
  {
   ...
  }

Now if the intent is to define data, I think something structured like this will define an external data area.
 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.
rbarnach1
 
Posts: 7
Joined: Sat Sep 21, 2013 4:35 am
Has thanked: 0 time
Been thanked: 0 time


Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post