COBOL can talk to any legal assembler program. But it can only manipulate data below the bar.
Scenario one: COBOL program creates records in memory and passes them to assembler program, which does something with them that involves above the bar memory. That will work. Scenario two: COBOL program calls assembler code which retrieves data from above the bar and copies it into a buffer provided by the COBOL program. That will work. Scenario three: COBOL program calls assembler code which finds data above the bar and passes its address to the COBOL program. That will not work. (Technically, that would sort-of work, but the COBOL program would have no way of "seeing" the data and manipulating it. All it could do is pass the address to some other assembler program.) Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 12:37 PM To: [email protected] Subject: Re: 64bit All, C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I am just using 64bit storage to store/retrieve data that should work? Scott ford www.identityforge.com from my IPAD > On Oct 17, 2014, at 2:11 PM, Don Poitras <[email protected]> wrote: > > In article <CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com> you wrote: >> I was interpreting Scott's question as how can above-the-bar memory >> be used directly by COBOL. > > Which is why Peter was confused. No such support currently exists. > While there's been a lot of talk about AMODE 64 COBOL, it's not there today. > >>> On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson <[email protected]> wrote: >>> Perhaps I misunderstood the problem. >>> >>> Whether called by the system, Cobol, or anything else, an HLASM >>> routine can get any storage that its authorization allows it to. >>> That includes storage below the bar, above the bar, and in data >>> spaces. The routine can switch in and out of any AMODE that its >>> RMODE allows (e.g., an RMODE 31 program better not "SAM24"). >>> >>> The caller needs to provide parameters in the form that the HLASM >>> routine wants (or conversely the HLASM routine needs to accommodate >>> the parameters that the caller provides; this is probably the easier approach). >>> >>> If you need the calling routine to then be able to deal with the >>> storage above 2G, that's a different matter entirely. >>> >>> Peter Relson >>> z/OS Core Technology Design > > -- > Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive > [email protected] (919) 531-5637 Cary, NC 27513 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
