Can COBOL pass an address in memory?
Jim Van Sickle
Oops...thought of an easier way:
CALL subprogram USING BY CONTENT ADDRESS OF area-name.
This from the VS COBOL II Application Programming Guide for MVS and CMS.
Jim Van Sickle wrote:
>
> PH,
> Define your variable to contain the address as USAGE POINTER (or USAGE COMP)
> then SET pointer-varialbe TO ADDRESS OF area-name.
> Cheers :-)
>
> PH wrote:
> >
> > Has anyone written COBOL code that could do this?
> >
> > A COBOL program (new) that builds a formatted data array must link to a PL1
> > program (existing) and pass it (via COMMAREA) the address of the array. The
> > PL1 program needs the pointer to access the array in memory.
> >
> > Has anyone used COBOL to pass a pointer/address?
>
--
***********************************************
* Jim Van Sickle <mailto:jim...@ibm.net> *
* Manager, Operations and Tech Support *
* United Retail, Inc. *
*---------------------------------------------*
* visit my meager web site at: *
* <http://mypage.ihost.com/jimswebsite/> *
***********************************************
William
PH wrote:
>
> Has anyone written COBOL code that could do this?
>
> A COBOL program (new) that builds a formatted data array must link to a PL1
> program (existing) and pass it (via COMMAREA) the address of the array. The
> PL1 program needs the pointer to access the array in memory.
>
> Has anyone used COBOL to pass a pointer/address?
Thank you
rbr...@access.digex.netx
On 25 Sep 1997, PH wrote:
> Has anyone written COBOL code that could do this?
>
> A COBOL program (new) that builds a formatted data array must link to a PL1
> program (existing) and pass it (via COMMAREA) the address of the array. The
> PL1 program needs the pointer to access the array in memory.
>
> Has anyone used COBOL to pass a pointer/address?
>
>
>
>
COBOL can pass anything it can swallow.
(Sorry, I couldn't *pass* that one up.)
Jim Van Sickle
PH,
Define your variable to contain the address as USAGE POINTER (or USAGE COMP)
then SET pointer-varialbe TO ADDRESS OF area-name.
Cheers :-)
PH wrote:
>
> Has anyone written COBOL code that could do this?
>
> A COBOL program (new) that builds a formatted data array must link to a PL1
> program (existing) and pass it (via COMMAREA) the address of the array. The
> PL1 program needs the pointer to access the array in memory.
>
> Has anyone used COBOL to pass a pointer/address?
--
PH
Michael C. Kasten
Jim Van Sickle wrote:
>
> Oops...thought of an easier way:
>
> CALL subprogram USING BY CONTENT ADDRESS OF area-name.
>
> This from the VS COBOL II Application Programming Guide for MVS and CMS.
>
> Jim Van Sickle wrote:
> >
> > Define your variable to contain the address as USAGE POINTER (or USAGE COMP)
> > then SET pointer-varialbe TO ADDRESS OF area-name.
Warning: when you code SET ptr-variable TO ADDRESS OF area-name,
area-name must reside in the LINKAGE SECTION. You can't directly
take the address of something in WORKING-STORAGE.
I assume the same is true when you code USING BY CONTENT ADDRESS OF
area-name, but I haven't tried it. In any case the original posting
said the pointer had to be passed via a COMMAREA, so this trick
doesn't apply here anyway.
If you need the address of something in WORKING-STORAGE, you can
pass it to a mindless subroutine which takes the address of one
parameter and returns the address in the other. It's annoying to
have to do such a silly thing, but that's life.
I'm assuming IBM Cobol II. At least two other dialects that I know
of handle pointers differently.
My Web pages contain a fuller discussion of pointers in Cobol II.
Michael C. Kasten mc...@swbell.net
http://home.swbell.net/mck9/cobol/cobol.html
William Murray
In article <342AE4...@swbell.net>,
"Michael C. Kasten" <mc...@swbell.net> wrote:
>Jim Van Sickle wrote:
>>
>> Oops...thought of an easier way:
>>
>> CALL subprogram USING BY CONTENT ADDRESS OF area-name.
>>
>> This from the VS COBOL II Application Programming Guide for MVS and CMS.
>>
>> Jim Van Sickle wrote:
>> >
>> > PH,
>> > Define your variable to contain the address as USAGE POINTER (or USAGE
COMP)
>> > then SET pointer-varialbe TO ADDRESS OF area-name.
>
>Warning: when you code SET ptr-variable TO ADDRESS OF area-name,
>area-name must reside in the LINKAGE SECTION. You can't directly
>take the address of something in WORKING-STORAGE.
>
>I assume the same is true when you code USING BY CONTENT ADDRESS OF
>area-name, but I haven't tried it. In any case the original posting
Aloha PH, Jim, and Michael,
Something about PH's original post sounded a warning bell in my mind: namely
"link" and "COMMAREA". Could PH be talking about a CICS LINK problem? If so,
doesn't he have to pass the array in the COMMAREA directly or define the data
outside of COBOL program (in a GETMAIN or storage queue)? I'm an "old hand"
at COBOL but CICS is relative new to me, so please feel free to elaborate or
correct me if I'm wrong.
Bill Grover
Pardon my apparent ignorance, having worked mainly in HP3000 shops, but
doesn't COBOL by default/definition pass all variables by reference? I
know that all of the programs I wrote this happened. Thanks for your
time.
William wrote:
> I'm sorry for my ignorance, but can you tell me what a PL1 program is?
>
> Thank you
--
Bill Grover
Systems Manager
EU Services, Inc.
649 N Horners Ln
Rockville, MD 20850-1299
Phone : 301-424-3300 x396
FAX : 301-838-9639
E-Mail: eus...@ix.netcom.com
jzi...@acucobol.com
In article <01bcc9c7$14c28ae0$7502...@dev117.isdev.ctt.com>,
"PH" <ph...@juno.com> wrote:
>
> Has anyone written COBOL code that could do this?
>
> A COBOL program (new) that builds a formatted data array must link to a PL1
> program (existing) and pass it (via COMMAREA) the address of the array. The
> PL1 program needs the pointer to access the array in memory.
>
> Has anyone used COBOL to pass a pointer/address?
Another consideration...
Memory management, at the system level, will swap memory reside data
items from one location to another. This means that data item addresses
refer to specific physical memory locations, as opposed to logical
locations. Systems supporting memory management provide support of the
use of handles to access physical memory locations. The memory
management subsystems update physical addresses as items are relocated in
memory, or swapped out (temporarily) to virtual memory on disk. Unless a
memory resident data item is "locked", meaning that the memory management
subsystem doesn't relocate the item, use of pointers between calls can
produce unreliable and unpredictable results. For this reason, if the
system you are working with permits the use of handles (a logical
pointer) their use is recommended. Otherwise, confirm that your system
support locking of data items, often resulting in the item being storage
in the system's data memory area, as opposed to the application's data
memory sector. This will assure the address you are working with, will
dependably access the data your application is dependent upon. Final
point...if using locking, assure that the lock is performed prior
obtaining the item's physical address...for obvious reasons.
Happy programming!
James H. Zisch, Systems Engineer
Acucobol, Inc.
www.acucobol.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
John L. Mindock
Bill Grover wrote:
>
> Pardon my apparent ignorance, having worked mainly in HP3000 shops, but
> doesn't COBOL by default/definition pass all variables by reference? I
> know that all of the programs I wrote this happened. Thanks for your
> time.
>
>
COMMAREA (in the receiving program), the ADDRESS of the data area needs
to be passed, instead of the name of the data area (as we did in the
good ol' days). I just spent the better part of a week figuring that
out. As a final humility blow, I hunted down a manual, and there it was
in black and white:
CICS/ESA Application Programming Guide, p. 36:
If a COMMAREA is used, its address must be passed to the LINK command.
John
Michael C. Kasten
William Murray wrote:
>
> In article <342AE4...@swbell.net>,
> "Michael C. Kasten" <mc...@swbell.net> wrote:
[snip]
> >Warning: when you code SET ptr-variable TO ADDRESS OF area-name,
> >area-name must reside in the LINKAGE SECTION. You can't directly
> >take the address of something in WORKING-STORAGE.
> >
> >I assume the same is true when you code USING BY CONTENT ADDRESS OF
> >area-name, but I haven't tried it. In any case the original posting
> (snip)
> >
> >Michael C. Kasten mc...@swbell.net
> >http://home.swbell.net/mck9/cobol/cobol.html
>
> Aloha PH, Jim, and Michael,
>
> Something about PH's original post sounded a warning bell in my mind: namely
> "link" and "COMMAREA". Could PH be talking about a CICS LINK problem? If so,
> doesn't he have to pass the array in the COMMAREA directly or define the data
> outside of COBOL program (in a GETMAIN or storage queue)?
[snip]
(posted and mailed)
Um, yeah, you're probably right <big sheepish grin>. It's been about
seven years since I did CICS and my reflexes were off.
What Mr. Murray is referring to is the following:
You can easily pass a pointer thru a COMMAREA to another program.
However, by the time that other program receives it, the pointer may
no longer be valid or even usable, depending on the fate of the
memory to which the pointer points.
If program A passes control to program B via XCTL (I think that's
the right magic word), then Program A is no longer active by the
time program B starts running. If the memory resides in program A's
WORKING-STORAGE, then some other unrelated task may be using it for
something else.
You might have better luck with LINK, since program A waits around
for program B to finish. But I wouldn't count on it. CICS probably
does weird things with memory management, changing BLL cells and
who knows what else.
Storage queues? Maybe, if you configure them the right way. That's
too exotic for me to comment on.
GETMAIN? By all means. Memory allocated via GETMAIN remains allocated
for the duration of the task, or until you free it with a FREEMAIN.
There's also an option to let it remain allocated beyond the end
of the task.
See also the posting by James H. Zisch of Acucobol.
Paul Knudsen
On Thu, 25 Sep 1997 13:18:12 -0400, William <d...@fie.edu> wrote:
>
>I'm sorry for my ignorance, but can you tell me what a PL1 program is?
>
>Thank you
HAR HAR HAR!!! ROFL!!!!! Wait...you *were* kidding...right?
Bill Lynch
As my very first instructor in my first IBM class (my first job after
college was with IBM) said, "it all depends". Your reference to XCTL vs.
LINK assumes that the data being passed is in the XCTLing program's
working storage, which disappears when the program isn't used (res
count=0?). As someone else pointed out earlier, there's no way to get
the address of a data item in w-s in Cobol. In my experience, the things
we're passing the address of don't disappear over a LINK or XCTL,
typically they're records we've read or pass areas we've formatted.
BTW, if you're using CICS's ability to LINK across regions, the address
is completely useless (no way to address the memory in the other address
space (in Cobol, anyway!)). We've done a lot of this in the past few
years and pass the record or work area itself in the COMMAREA.
Hope this is helpful,
Bill Lynch
David
>Jim Van Sickle wrote:
>>
>> Oops...thought of an easier way:
>>
>> CALL subprogram USING BY CONTENT ADDRESS OF area-name.
>>
>> This from the VS COBOL II Application Programming Guide for MVS and CMS.
>>
>> Jim Van Sickle wrote:
>> >
>> > PH,
>> > Define your variable to contain the address as USAGE POINTER (or USAGE COMP)
>> > then SET pointer-varialbe TO ADDRESS OF area-name.
>
>Warning: when you code SET ptr-variable TO ADDRESS OF area-name,
>area-name must reside in the LINKAGE SECTION. You can't directly
>take the address of something in WORKING-STORAGE.
>
>I assume the same is true when you code USING BY CONTENT ADDRESS OF
>area-name, but I haven't tried it. In any case the original posting
>said the pointer had to be passed via a COMMAREA, so this trick
>doesn't apply here anyway.
>
>If you need the address of something in WORKING-STORAGE, you can
>pass it to a mindless subroutine which takes the address of one
>parameter and returns the address in the other. It's annoying to
>have to do such a silly thing, but that's life.
>
>I'm assuming IBM Cobol II. At least two other dialects that I know
>of handle pointers differently.
>
>My Web pages contain a fuller discussion of pointers in Cobol II.
>
>Michael C. Kasten mc...@swbell.net
>http://home.swbell.net/mck9/cobol/cobol.html
michael,
thank you for pointing this out. from reading the first post, i felt
this was not a problem until someone mentioned the POINTER construct.
passing pointers is possible, but requires a subprogram to calculate
and return to calling module. certainly a possibility if needed.
also, i don't feel the original problem was well defined. cobol by
default passes addresses. my take is that pl/1 program is capable of
using the passed address directly from a simple 'CALL USING...'
statement. i fear we're solving the already-solved....
David d.s....@ix.netcom.com
____________________________________