For Programmers: Free Programming Magazines  


Home > Archive > Cobol > March 2006 > Linkage and Nested Subprograms









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Linkage and Nested Subprograms
LX-i

2006-03-22, 3:55 am

With this discussion about nested subprograms, there's something that's
bugged me, but I'm not sure how to get around it (or if it can be gotten
around). If I have a subprogram, that itself has nested subprograms,
only the "main" subprogram has the linkage section visible. Is there a
way to make all the nested subprograms have visibility of the "main"
subprogram's linkage section (short of defining it and passing it with
each call)?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
Frank Swarbrick

2006-03-22, 3:55 am

If you look at the example I posted earlier today you'll see that I defined
some of the "main" programs LINKAGE SECTION items as being GLOBAL. This
appears to allow the nested programs to have access to the outer program's
linkage section. Of course the way I used it and the way you appear to want
to use it are somewhat different, but I'm guessing it should still work.

ID DIVISION.
PROGRAM-ID. OUTERPGM.
DATA DIVISION.
LINKAGE SECTION.
01 FIELD-1 PIC X(80) GLOBAL.
PROCEDURE DIVISION USING FIELD-1.
CALL 'NESTED1'
EXIT PROGRAM.

ID DIVISION.
PROGRAM-ID. NESTED1.
PROCEDURE DIVISION.
DISPLAY FIELD-1
EXIT PROGRAM.
END PROGRAM NESTED1.
END PROGRAM OUTERPGM.

It's late, so I didn't test it, but it did compile with no errors or
warnings.

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
[color=darkred]
With this discussion about nested subprograms, there's something that's
bugged me, but I'm not sure how to get around it (or if it can be gotten
around). If I have a subprogram, that itself has nested subprograms,
only the "main" subprogram has the linkage section visible. Is there a
way to make all the nested subprograms have visibility of the "main"
subprogram's linkage section (short of defining it and passing it with
each call)?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine


Rick Smith

2006-03-22, 3:55 am


"LX-i" <lxi0007@netscape.net> wrote in message
news:ba95e$4420a10a$45491d7a$14101@KNOLO
GY.NET...
> With this discussion about nested subprograms, there's something that's
> bugged me, but I'm not sure how to get around it (or if it can be gotten
> around). If I have a subprogram, that itself has nested subprograms,
> only the "main" subprogram has the linkage section visible. Is there a
> way to make all the nested subprograms have visibility of the "main"
> subprogram's linkage section (short of defining it and passing it with
> each call)?


In COBOL 85, apparently not, except as an extension.
In COBOL 2002, yes, except not in factory, instance,
or method definitions. Where permitted, use GLOBAL
to make the linkage item available.

Example using Micro Focus COBOL 3.2.24 where it is
an extension. Note that ANS85 flagging was not used.
-----
$set ans85 nestcall
identification division.
program-id. main.
data division.
working-storage section.
01 item-to-pass pic x(12) value "linkage item".
procedure division.
begin.
display "in main program"
call "n-main" using item-to-pass
display "in main program"
stop run.
end program main.

identification division.
program-id. n-main.
data division.
linkage section.
01 item-to-pass pic x(12) global.
procedure division using item-to-pass.
begin.
display "in nested main program"
display item-to-pass
call "n-sub"
display "in nested main program"
exit program.
identification division.
program-id. n-sub.
procedure division.
begin.
display "in nested subprogram"
display item-to-pass
display "in nested subprogram"
exit program.
end program n-sub.
end program n-main.
-----



Pete Dashwood

2006-03-22, 6:55 pm


"LX-i" <lxi0007@netscape.net> wrote in message
news:ba95e$4420a10a$45491d7a$14101@KNOLO
GY.NET...
> With this discussion about nested subprograms, there's something that's
> bugged me, but I'm not sure how to get around it (or if it can be gotten
> around). If I have a subprogram, that itself has nested subprograms, only
> the "main" subprogram has the linkage section visible. Is there a way to
> make all the nested subprograms have visibility of the "main" subprogram's
> linkage section (short of defining it and passing it with each call)?
>

Sure, move the linkage parameters to a working-storage area defined as
EXTERNAL GLOBAL.(I do this in PowerCOBOL all the time).

(Some platforms might even let you apply these descriptors to Linkage
items... I'm not sure and I can't be bothered looking it up, so stick them
in WS; I KNOW that works... :-)

Pete.

> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ daniel@thebelowdomain ~
> ~ _____ / \ | ~ http://www.djs-consulting.com ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
>
> "Who is more irrational? A man who believes in a God he doesn't see, or a
> man who's offended by a God he doesn't believe in?" - Brad Stine



Frank Swarbrick

2006-03-22, 6:55 pm

A "problem" with EXTERNAL GLOBAL, at least on my compiler, is that each
program within the run unit must have it declared exactly the same. In
other words, if you have...

01 EXT-DATA EXTERNAL GLOBAL.
05 EXT-1 PIC X(80).
05 EXT-2 PIC X(80).

If you want to add an EXT-3, say, then you have to recompile all of the
programs that include EXT-DATA, even if they don't "care" about the
additional data.

Not sure what Daniel is trying to do to know whether or not your way would
be fine.

Anyway, my compiler allows a LINKAGE SECTION data-name to specify the GLOBAL
clause. Not sure if this is an IBM extension or part of the COBOL 85/89
standard...
5.3.8 GLOBAL Clause

The GLOBAL clause specifies that a data-name is available to every program
contained within the program that declares it, as long as the contained
program does not itself have a declaration for that name. All data-names
subordinate to or condition-names or indexes associated with a global name
are global names.

A data-name is global if the GLOBAL clause is specified either in the data
description entry by which the data-name is declared or in another entry to
which that data description entry is subordinate. The GLOBAL clause
X can be specified in the Working-Storage Section, the File Section, and the

X Linkage Section, but only in data description entries whose level-number
is 01.

In the same Data Division, the data description entries for any two data
items for which the same data-name is specified must not include the GLOBAL
clause.

A statement in a program contained directly or indirectly within a program
which describes a global name can reference that name without describing it
again.

Two programs in a run unit can reference common data in the following
circumstances:

The data content of an external data record can be referenced from any
program provided that program has described that data record.

If a program is contained within another program, both programs can refer to
data possessing the global attribute either in the containing program or in
any program that directly or indirectly contains the containing program.

Frank


"LX-i" <lxi0007@netscape.net> wrote in message
news:ba95e$4420a10a$45491d7a$14101@KNOLO
GY.NET...[color=darkred]
> With this discussion about nested subprograms, there's something that's
> bugged me, but I'm not sure how to get around it (or if it can be gotten
> around). If I have a subprogram, that itself has nested subprograms, only


> the "main" subprogram has the linkage section visible. Is there a way to


> make all the nested subprograms have visibility of the "main" subprogram's


> linkage section (short of defining it and passing it with each call)?
>

Sure, move the linkage parameters to a working-storage area defined as
EXTERNAL GLOBAL.(I do this in PowerCOBOL all the time).

(Some platforms might even let you apply these descriptors to Linkage
items... I'm not sure and I can't be bothered looking it up, so stick them
in WS; I KNOW that works... :-)

Pete.

> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ daniel@thebelowdomain ~
> ~ _____ / \ | ~ http://www.djs-consulting.com ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
>
> "Who is more irrational? A man who believes in a God he doesn't see, or a


> man who's offended by a God he doesn't believe in?" - Brad Stine





Pete Dashwood

2006-03-23, 7:55 am


"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:48dgc2FijvcdU2@individual.net...
>A "problem" with EXTERNAL GLOBAL, at least on my compiler, is that each
> program within the run unit must have it declared exactly the same.


And that is problematical.... how? :-)

Use a COPY book for these items and just bung them in where they're needed.

> In
> other words, if you have...
>
> 01 EXT-DATA EXTERNAL GLOBAL.
> 05 EXT-1 PIC X(80).
> 05 EXT-2 PIC X(80).
>
> If you want to add an EXT-3, say, then you have to recompile all of the
> programs that include EXT-DATA, even if they don't "care" about the
> additional data.
>

Not if EXT-1, EXT-2, etc... were 01 levels...

OR, if you simply defined an area for this and then redefined it as
required...

01 MY-COMMON-DATA EXTERNAL GLOBAL.
12 FILLER PIC X(512).
12 VARIOUS-BITS REDEFINES FILLER.
15 EXT-1 PIC X(80).
15 EXT-2 PIC X(80).

There is usually a way iof you want ot od something badly enough... :-)

> Not sure what Daniel is trying to do to know whether or not your way would
> be fine.
>
> Anyway, my compiler allows a LINKAGE SECTION data-name to specify the
> GLOBAL
> clause. Not sure if this is an IBM extension or part of the COBOL 85/89
> standard...


And it really doesn't matter, does it? :-)

If you ever have to 'transport' it (yeah, right.... ;-)), you'll simply
change it to suit the platform you are moving to and write it off as part of
the conversion cost...

<snipped reproduction of manual>

Pete.


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com