Implementing const in COBOL
mshetty
Does COBOL have a mechanism of passing values as constants even if
they are being passed BY REFERENCE.
I mean I have to pass a variable BY REFERENCE by I don't want the
called program / sub-program to modify the value of the variable.
Something like a const char *a; in C. Here, even though a is passed by
reference it's values cannot be modified.
Thanks and Regards,
M Shetty
William M. Klein
matches what you are asking about.
Passing a parameter
BY CONTENT
actually passes an "address" of an unmodifiable version of the passed
parameter.
--
Bill Klein
wmklein <at> ix.netcom.com
"mshetty" <msh...@mail.com> wrote in message
news:bfbb8fd4.0110...@posting.google.com...
Binyamin Dissen
:>Does COBOL have a mechanism of passing values as constants even if
:>they are being passed BY REFERENCE.
:>I mean I have to pass a variable BY REFERENCE by I don't want the
:>called program / sub-program to modify the value of the variable.
I fail to understand why you don't want to do by VALUE. That does exactly what
you want.
:>Something like a const char *a; in C. Here, even though a is passed by
:>reference it's values cannot be modified.
You can move it to a work field which will not be used by the calling program
and pass it by reference, but I fail to understand the problem you are
addressing.
--
Binyamin Dissen <bdi...@dissensoftware.com>
Binyamin Dissen <bdi...@netvision.net.il>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Edwin Earl Ross
<value>. Consequently, values in data items are not protected; they are
always variables. If you pass by reference, any data item within that
linkage item may be changed by the subroutine.
"mshetty" <msh...@mail.com> wrote in message
news:bfbb8fd4.0110...@posting.google.com...
William M. Klein
Standard.
Today, in any ANSI/ISO conforming compiler passing a parameter BY CONTENT
most definitely DOES prohibit the subprogram from modifying the calling
program's storage (but does "look like" BY reference to the subprogram).
BY VALUE is added in the next Standard, and most (many?) existing compilers
already support this. It put the "value" of the data-item "on the stack".
(Check your specific compiler's documentation for whether it is already
supported and what its semantics are).
The next Standard introduces
>>Define compilation-variable "value"
which I believe is almost exactly identical to the C #define function.
(There will also be CONSTANT entries in the next Standard)
Again, check with your specific COBOL vendor on when (if not already) they
plan on providing this functionality. (Some already support it - but with
different syntax)
--
Bill Klein
wmklein <at> ix.netcom.com
"Edwin Earl Ross" <Edwi...@yahoo.com> wrote in message
news:jd%D7.3495$3t1.74...@newssvr30.news.prodigy.com...
Grinder
"Binyamin Dissen" <post...@dissensoftware.com> wrote in
message news:nuf0utsoo3v5l2f1n...@4ax.com...
> On 31 Oct 2001 05:27:51 -0800 msh...@mail.com (mshetty)
wrote:
>
> :>Does COBOL have a mechanism of passing values as constants
even if
> :>they are being passed BY REFERENCE.
>
> :>I mean I have to pass a variable BY REFERENCE by I don't
want the
> :>called program / sub-program to modify the value of the
variable.
>
> I fail to understand why you don't want to do by VALUE. That
does exactly what
> you want.
If the argument is a pointer to something other than an
intrisic--like an array, struct or object, you might not want to
have to copy that whole block of date (even if you could.) Yet,
you would want to guard against an assignment of that pointer in
the called routine.
Chris Glazier
CONTENT ...
This causes a copy of the data item to be passed by reference and
therefore the original item will be protected. In Some COBOL
implementations (like Net Express) you can directly use a literal in
the USING and it will automatically be converted to BY CONTENT.
"Edwin Earl Ross" <Edwi...@yahoo.com> wrote in message news:<jd%D7.3495$3t1.74...@newssvr30.news.prodigy.com>...
Howard Brazee
On 1-Nov-2001, chris....@microfocus.com (Chris Glazier) wrote:
> Standard COBOL does have this mechanism, it is: CALL ...USING BY
> CONTENT ...
I am a big advocate of COBOL's practice of using English language terms, but
for some reason, I always have to translate the other way - from COBOL to
computerese when I do a CALL.. USING BY.
Russell Styles
workbench 3.1 (16 bit).
In a subprogram I accidently put a group item referenced in the
procedure division using in
working storage instead of linkage. Everything passed into the subprogram
just fine, but when I exited, the data in the calling program was unchanged.
I do not know if this is a bug or feature, but it was annoying at the
time.
Since this was undesirable at the time, I have not tried this with Netx.
"Chris Glazier" <chris....@microfocus.com> wrote in message
news:260cd566.01110...@posting.google.com...
KNe...@home.com
>
> In a subprogram I accidently put a group item referenced in the
>procedure division using in
>working storage instead of linkage. Everything passed into the subprogram
>just fine, but when I exited, the data in the calling program was unchanged.
>
> I do not know if this is a bug or feature, but it was annoying at the
>time.
>
> Since this was undesirable at the time, I have not tried this with Netx.
>
storage group item...or the "main" (program that made the call) had
the group item? I'm guessing that you mean the subprogram, which
would make sense to me. The sub program will change the data in the
working storage section, but once control is returned to the "main"
program...that group-level-item (the one in the working storage
section of the subprogram) would no longer exist. The group item in
the main program would remain unchanged since it was not passed
correctly to the sub program. You could do a simple
"Move ws-group-level-item To linkage-section-group-level-item."
That would allow the linkage section group level item to be "changed".
I'm not sure why you would ever want to do it that way.
If you indeed put the group item in the linkage section of the "main"
program, it would indeed reside in memory while the sub program is
executing. If you were using a debugger to view that group level item,
then you would see it that there is a value in it. However, the
working storage group-level-item in the subprogram would be the
value(s) changed. Not the linkage group level items. Why? Because you
didn't pass the group level item correctly.
If you call a program using a four byte field, then as long as you
have a field that four bytes can reside in, the compiler may not care
about it being a working storage field. If however, you try to link
that program and you do not have a field to put the four bytes in, I
am guessing the compiler would flag it. That's my guess as to what
happened. I could be wrong.
I would think of it as a feature and not a bug.
Richard Plinston
>
> >
> > In a subprogram I accidently put a group item referenced in the
> >procedure division using in
> >working storage instead of linkage.
> >
> storage group item...or the "main" (program that made the call) had
> the group item?
I understood him to mean both had this in W-S (instead of LIMKAGE
SECTION in the sub-program).
> but once control is returned to the "main"
> program...that group-level-item (the one in the working storage
> section of the subprogram) would no longer exist.
Strictly speaking W-S in a CALLed program doesn't cease to exist until
it is CANCELed.
KNe...@home.com
<rip...@Azonic.co.nz> wrote:
>KNe...@home.com wrote:
>>
>> >
>> > In a subprogram I accidently put a group item referenced in the
>> >procedure division using in
>> >working storage instead of linkage.
> > >
>> Do I understand this to mean that the subprogram had the working
>> storage group item...or the "main" (program that made the call) had
>> the group item?
>
>I understood him to mean both had this in W-S (instead of LIMKAGE
>SECTION in the sub-program).
>
Right. Naturally they would both have group-level items in w-s...of
course...what was I thinking. I must've had a couple last
night...hehe.
>> but once control is returned to the "main"
>> program...that group-level-item (the one in the working storage
>> section of the subprogram) would no longer exist.
>
>Strictly speaking W-S in a CALLed program doesn't cease to exist until
>it is CANCELed.
Oh wow, that's cool. I didn't know that. I always thought after
control returned to the main, all the fields in the subprogram
magically disappeared. I just read up on the cancel statement. I never
encountered it before.
Donald Tees
You might also want to take a look at the "INITIAL" verb for use in the
subroutine. You can do the same thing there, so that the mainline does not
have to be aware of the fact that the subroutine does not retain it's values
from call to call. Compiling the subroutine with the INITIAL statement has
the same effect as using the CANCEL after each call.
Donald.
Robert Sales
USING header is definitely a feature, and documented in the Language
Reference Manual. I think this was originally added for compatibility with
some dialect or other, but is actually quite useful (and efficient) for
purely input parameters.
--
Robert Sales, Micro Focus
"Russell Styles" <RWST...@worldnet.att.net> wrote in message
news:45rE7.152927$3d2.5...@bgtnsc06-news.ops.worldnet.att.net...
William M. Klein
The INITIAL attribute in the PROGRAM-ID paragraph "guarantees" that each
time the subprogram is called, that its storage items are placed into
"initial state" (not kept from the last time).
The INITIALIZE verb (or statement) may be used in either a subprogram or a
main program to place a specific 01-level into "initial state". This is NOT
what actually happens (as filler and unnamed items are NOT impacted by the
INITIALIZE statement) - but it is "similar" to what happens.
--
Bill Klein
wmklein <at> ix.netcom.com
"Donald Tees" <donal...@sympatico.ca> wrote in message
news:5DUE7.35737$6h5.3...@news20.bellglobal.com...