Re: Addressing Question

[Tom Ross]

>Tom,
>
>We run our compiles using COBOL v4.2 as
>
>CBL. ...NODYN,RES,RENT,DATA(31)
>
>Run options via CEEOPTS is ALL31(ON) ..
>
>This for the caller, using AMODE(31) and RMODE ANY for the binder.
>
>We call like this call 'xx' using xx
>
>Does this imply AMODE switching ?

No.  AMODE switching is when an AMODE 31 program calls a separate executable
(Program Object or Load Module) that has AMODE 24, or from AMODE 24 to
to AMODE 31.  If the programs are bound together it is only possible to have
different AMODEsi if you have a Program Object with some segments AMODE 31
and other segments AMODE 24.  Load Modules have hte same AMODE for all entry
points.  Finally, COBOL dynamic CALL requires separate executables, and COBOL
dynamic CALL support mode switching in that case.  You can get COBOL
dynamic CALL 3 ways:
1) Call 'literal' with DYNAM compiler option
2) Call identifier  (DYNAM/NODYNA do not affect these)
3) >>CALLINTERFACE DYNAM
   Call 'literal'

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

All,

My intent was clarification for my old age. I went back and looked and I am
good.

Thanks all..

Scott

On Thu, Jan 5, 2017 at 10:24 AM scott Ford  wrote:

> Tom,
>
> Thx for you comment. I agree otherwise there is confusion.
>
>
> Scott
>
> On Thu, Jan 5, 2017 at 4:55 AM Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:
>
>
>
> >No. Your CALLs are static.
>
> >
>
>
>
> Bill,
>
>
>
> It would be helpful if you would quote enough of the message that you
>
> are replying to to provide context to what your "No" references.
>
>
>
> --
>
> Tom Marchant
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Tom,

Thx for you comment. I agree otherwise there is confusion.


Scott

On Thu, Jan 5, 2017 at 4:55 AM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:
>
>
>
> >No. Your CALLs are static.
>
> >
>
>
>
> Bill,
>
>
>
> It would be helpful if you would quote enough of the message that you
>
> are replying to to provide context to what your "No" references.
>
>
>
> --
>
> Tom Marchant
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Tom Marchant]

On Wed, 4 Jan 2017 16:24:12 -0600, Bill Woodger wrote:

>No. Your CALLs are static.
>

Bill,

It would be helpful if you would quote enough of the message that you 
are replying to to provide context to what your "No" references.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

This is what Frank said I think


Storage and its addressability

  Version 4.2.0  No other versions

When you run COBOL programs, the programs and the data that they use reside
in virtual storage. Storage that you use with COBOL can be either below the
16-MB line or above the 16-MB line but below the 2-GB bar. Two modes of
addressing are available to address this storage: 24-bit and 31-bit.

You can address storage below (but not above) the 16-MB line with 24-bit
addressing. You can address storage either above or below the 16-MB line
with 31-bit addressing. Unrestricted storage is addressable by 31-bit
addressing and therefore encompasses all the storage available to your
program, both above and below the 16-MB line.

Enterprise COBOL does not directly exploit the 64-bit virtual addressing
capability of z/OS; however, COBOL applications running in 31-bit or 24-bit
addressing mode are fully supported on 64-bit z/OS systems.

Addressing mode (AMODE) is the attribute that tells which hardware
addressing mode is supported by your program: 24-bit addressing, 31-bit
addressing, or either 24-bit or 31-bit addressing. This attribute is AMODE
24, AMODE 31, or AMODE ANY, respectively. The object program, the load
module, and the executing program each has an AMODE attribute. All Enterprise
COBOL object programs are AMODE ANY.

Residency mode (RMODE) is the attribute of a program load module that
identifies where in virtual storage the program will reside: below the
16-MB line, or either below or above. This attribute is RMODE 24 or RMODE
ANY.

Enterprise COBOL uses Language Environment services to control the storage
used at run time. Thus COBOL compiler options and Language Environment runtime
options influence the AMODE and RMODE attributes of your program and data,
alone and in combination:
*DATA*Compiler option that influences the location of storage for
WORKING-STORAGE data, I-O buffers, and parameter lists for programs
compiled with RENT.*RMODE*Compiler option that influences the residency
mode and also influences the location of storage for WORKING-STORAGE data,
I-O buffers, and parameter lists for programs compiled with
NORENT.*RENT*Compiler
option to generate a reentrant program.*HEAP*Runtime option that controls
storage for the runtime heap. For example, COBOL WORKING-STORAGE is
allocated from heap storage.*STACK*Runtime option that controls storage for
the runtime stack. For example, COBOL LOCAL-STORAGE is allocated from stack
storage.*ALL31*Runtime option that specifies whether an application can run
entirely in AMODE 31.


I  know understand 


Scott

On Wed, Jan 4, 2017 at 4:12 PM scott Ford  wrote:

> Huh,
>
>
> We are calling statically.
>
> Scott
>
> On Wed, Jan 4, 2017 at 4:07 PM Bill Woodger 
> wrote:
>
> ALL31(ON) is only relevant for dynamic CALLs, and it is as Frank has
> described - no switching, and if you CALL an AMODE(24), dynamically, you'll
> likely break.
>
>
>
> Your resultant loadmodule is less than 16MB, and, when loaded, fits within
> the available memory below the line. How close you are to exhausting that
> memory with a minor increase in storage is unknown from what you have said.
>
>
>
> You are "getting away with it".
>
>
>
> The map of the loadmodule, produced by the program binder, will confirm
> this.
>
>
>
> I think if you go over 16MB the binder will complain, but it has no way of
> knowing what memory is available of the 16MB for when your program is
> loaded, so you can have a loadmodule which binders successfully, but won't
> fit in the memory available - if you have a change which adds sufficient
> memory.
>
>
>
> You should be able to test this fairly easily. Find the size of the
> loadmodule, add storage so that it is close to, but not, 16MB, and try to
> load it.
>
>
>
> If no other handy methods, a quick "binary chop" will get a reasonable
> "maximum" size you can load, and you can compare your actual loadmodule
> size to that, to know how much leeway you have.
>
>
>
> If that is not enough leeway, you will have to make the assembler happy
> with 31-bit addressing which will allow you to fully binder greater than
> 16MB with everything static, or go with dynamic CALLs to the assembler and
> have LE do its work, using ALL31(OFF) so you get the switching.
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Huh,


We are calling statically.

Scott

On Wed, Jan 4, 2017 at 4:07 PM Bill Woodger  wrote:

> ALL31(ON) is only relevant for dynamic CALLs, and it is as Frank has
> described - no switching, and if you CALL an AMODE(24), dynamically, you'll
> likely break.
>
>
>
> Your resultant loadmodule is less than 16MB, and, when loaded, fits within
> the available memory below the line. How close you are to exhausting that
> memory with a minor increase in storage is unknown from what you have said.
>
>
>
> You are "getting away with it".
>
>
>
> The map of the loadmodule, produced by the program binder, will confirm
> this.
>
>
>
> I think if you go over 16MB the binder will complain, but it has no way of
> knowing what memory is available of the 16MB for when your program is
> loaded, so you can have a loadmodule which binders successfully, but won't
> fit in the memory available - if you have a change which adds sufficient
> memory.
>
>
>
> You should be able to test this fairly easily. Find the size of the
> loadmodule, add storage so that it is close to, but not, 16MB, and try to
> load it.
>
>
>
> If no other handy methods, a quick "binary chop" will get a reasonable
> "maximum" size you can load, and you can compare your actual loadmodule
> size to that, to know how much leeway you have.
>
>
>
> If that is not enough leeway, you will have to make the assembler happy
> with 31-bit addressing which will allow you to fully binder greater than
> 16MB with everything static, or go with dynamic CALLs to the assembler and
> have LE do its work, using ALL31(OFF) so you get the switching.
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Bill Woodger]

ALL31(ON) is only relevant for dynamic CALLs, and it is as Frank has described 
- no switching, and if you CALL an AMODE(24), dynamically, you'll likely break.

Your resultant loadmodule is less than 16MB, and, when loaded, fits within the 
available memory below the line. How close you are to exhausting that memory 
with a minor increase in storage is unknown from what you have said.

You are "getting away with it". 

The map of the loadmodule, produced by the program binder, will confirm this. 

I think if you go over 16MB the binder will complain, but it has no way of 
knowing what memory is available of the 16MB for when your program is loaded, 
so you can have a loadmodule which binders successfully, but won't fit in the 
memory available - if you have a change which adds sufficient memory.

You should be able to test this fairly easily. Find the size of the loadmodule, 
add storage so that it is close to, but not, 16MB, and try to load it.

If no other handy methods, a quick "binary chop" will get a reasonable 
"maximum" size you can load, and you can compare your actual loadmodule size to 
that, to know how much leeway you have.

If that is not enough leeway, you will have to make the assembler happy with 
31-bit addressing which will allow you to fully binder greater than 16MB with 
everything static, or go with dynamic CALLs to the assembler and have LE do its 
work, using ALL31(OFF) so you get the switching.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Frank Swarbrick]

I think its exactly the opposite.  "If the initial routine of the Language 
Environment application is AMODE 31, this setting indicates that no other 
routines in the application will be AMODE 24."


I'm thinking that if this option is set then there is no attempt to see if an 
AMODE switch is necessary.  It assumes there is not, since you have guaranteed 
(by setting this option) that all modules in this runtime are 31 bit.



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
scott Ford <idfli...@gmail.com>
Sent: Wednesday, January 4, 2017 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Addressing Question

Mike,

Thanks I thought so, additionally ALL31(ON) implies mode switching to me.


Scott


On Wed, Jan 4, 2017 at 2:52 PM Mike Schwab <mike.a.sch...@gmail.com> wrote:

> If all modules are linked into one load modules, the resulting member
>
> should have the most restrictive settings placed on the member.
>
>
>
> On Wed, Jan 4, 2017 at 4:24 PM, Bill Woodger <bill.wood...@gmail.com>
> wrote:
>
> > No. Your CALLs are static.
>
> >
>
> > --
>
> > For IBM-MAIN subscribe / signoff / archive access instructions,
>
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
>
>
>
> --
>
> Mike A Schwab, Springfield IL USA
>
> Where do Forest Rangers go to get away from it all?
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Mike,

Thanks I thought so, additionally ALL31(ON) implies mode switching to me.


Scott


On Wed, Jan 4, 2017 at 2:52 PM Mike Schwab  wrote:

> If all modules are linked into one load modules, the resulting member
>
> should have the most restrictive settings placed on the member.
>
>
>
> On Wed, Jan 4, 2017 at 4:24 PM, Bill Woodger 
> wrote:
>
> > No. Your CALLs are static.
>
> >
>
> > --
>
> > For IBM-MAIN subscribe / signoff / archive access instructions,
>
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
>
>
>
> --
>
> Mike A Schwab, Springfield IL USA
>
> Where do Forest Rangers go to get away from it all?
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Mike Schwab]

If all modules are linked into one load modules, the resulting member
should have the most restrictive settings placed on the member.

On Wed, Jan 4, 2017 at 4:24 PM, Bill Woodger  wrote:
> No. Your CALLs are static.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Bill Woodger]

No. Your CALLs are static.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Tom,

We run our compiles using COBOL v4.2 as

CBL. ...NODYN,RES,RENT,DATA(31)

Run options via CEEOPTS is ALL31(ON) ..

This for the caller, using AMODE(31) and RMODE ANY for the binder.

We call like this call 'xx' using xx

Does this imply AMODE switching ?


Scott




On Tue, Jan 3, 2017 at 4:46 PM Tom Ross  wrote:

> >>
>
> >>I think i am right in saying that RMODE(ANY) sees the program with
>
> >>RMODE(24) and
>
> >>its ok to execute and the I/O buffers are they 24bit or 31
>
> >>
>
> >>It seems unlikely that the calling program pays any attention to the
> RMODE
>
> >>
>
> >>of anything that it calls.
>
> >>
>
> >>It is up to the caller to meet the requirements of the callee. If the=20
>
> >>callee is AMODE 24, then it would be expected that any data passed
> from=20
>
> >>the caller to the callee be below 16M. That includes save area and=20
>
> >>parameter list.
>
>
>
> >Does COBOL actually have any support for AMODE-switching calls?
>
>
>
>
>
> Yes, if you use a feature called "COBOL dynamic CALL" then a library
> routine
>
> gets control and can do AMODE switching before you enter the called
> program.
>
> There are 3 ways to get COBOL CALL statements to be dynamic these days!
>
> DYNAM compiler option for CALL literal statements, CALL identifier
> statements,
>
> and the >>CALLINTERFACE compiler directive.
>
>
>
> Cheers,
>
> TomR  >> COBOL is the Language of the Future! <<
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Tom Ross]

>>
>>I think i am right in saying that RMODE(ANY) sees the program with
>>RMODE(24) and
>>its ok to execute and the I/O buffers are they 24bit or 31
>>
>>It seems unlikely that the calling program pays any attention to the RMODE
>>
>>of anything that it calls.
>>
>>It is up to the caller to meet the requirements of the callee. If the=20
>>callee is AMODE 24, then it would be expected that any data passed from=20
>>the caller to the callee be below 16M. That includes save area and=20
>>parameter list.

>Does COBOL actually have any support for AMODE-switching calls?


Yes, if you use a feature called "COBOL dynamic CALL" then a library routine
gets control and can do AMODE switching before you enter the called program.
There are 3 ways to get COBOL CALL statements to be dynamic these days!
DYNAM compiler option for CALL literal statements, CALL identifier statements,
and the >>CALLINTERFACE compiler directive.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Bill Woodger]

As I understand it, Scott's COBOL programs are all 31-bit addressing. It is the 
Assembler programs which are not.

If any of the COBOL programs happened to be located outside the 24-bit range of 
addresses, the thing would stop working, or certainly not work as expected, as 
return-address and the address of the save-area would be subjected to a bit of 
stripping.

This could easily be tested, as even with Enterprise COBOL V3.1, a single 16MB 
field could be defined, which would then ensure that any return-address or 
save-area would be outside the 24-bit addressability.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Clark Morris]

[Default] On 27 Dec 2016 14:21:57 -0800, in bit.listserv.ibm-main
bill.wood...@gmail.com (Bill Woodger) wrote:

>Thanks. I think you are probably "getting away with it". Since you are not 
>using any data from a COBOL program, that DATA(31) is not an issue. I suspect 
>in your bindered program, the COBOL programs are always "below the line", so 
>the return-address is not getting accidentally truncated. I think if you were 
>to what a 16MB table into the initial COBOL program that the binder would 
>complain. If not, you'd get a run-time problem of some type. 

COBOL programs have been handling DATA(31) since COBOL for MVS and VM
and in the LE versions.  DATA(24) is unusual.  Limits have gradually
been relaxed and so for Enterpris 5.1 a single data item can be 1
billion bytes minus 1 or 999,999,999 bytes so unless the program has
been compiled AMODE(24) there wouldn't be a problem.  I just checked
using Google to the appropriate IBM page.

Clark Morris
>
>I guess we'd need to see the binder output to confirm.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Bill,

I will have to look, you may be right, I am on vacation, thank god...
As a ISV we have been very busy..

Scott

On Tuesday, December 27, 2016, Bill Woodger  wrote:

> Thanks. I think you are probably "getting away with it". Since you are not
> using any data from a COBOL program, that DATA(31) is not an issue. I
> suspect in your bindered program, the COBOL programs are always "below the
> line", so the return-address is not getting accidentally truncated. I think
> if you were to what a 16MB table into the initial COBOL program that the
> binder would complain. If not, you'd get a run-time problem of some type.
>
> I guess we'd need to see the binder output to confirm.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Bill Woodger]

Thanks. I think you are probably "getting away with it". Since you are not 
using any data from a COBOL program, that DATA(31) is not an issue. I suspect 
in your bindered program, the COBOL programs are always "below the line", so 
the return-address is not getting accidentally truncated. I think if you were 
to what a 16MB table into the initial COBOL program that the binder would 
complain. If not, you'd get a run-time problem of some type. 

I guess we'd need to see the binder output to confirm.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Bill,

Data is not shared, the called assembler routines in question perform
extracts from a DB output to a file. Then the assembler routine returns.
Peter was kind enough to answe my question. We run DATA(31) ALL31(ON) and
of course routines have been working for a long time.

Scott

On Tuesday, December 27, 2016, Bill Woodger  wrote:

> What is the value of the Language Environment option ALL31? With
> ALL31(OFF), an LE run-time routine will deal with AMODE switching between
> CALLs.
>
> If any of the Assembler programs are accessing data from the COBOL
> programs, those COBOL programs should be DATA(24) (you claim DATA(31).
>
> Can you be explicit about what you mean by "self-contained"? If the
> Assembler programs are CALLed with no parameters and, for instance, just
> start up some type of service, then, as long as the Assembler program
> doesn't get to garble the return-address, you can ignore any interaction
> between COBOL and Asm. Is that what you have? If not, please describe it
> more clearly, including answers to the questions previously asked.
>
> All you CALLs are static, then we'd just absolutely love to see your
> output from the binder. Perhaps after answers to the above.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Bill Woodger]

What is the value of the Language Environment option ALL31? With ALL31(OFF), an 
LE run-time routine will deal with AMODE switching between CALLs.

If any of the Assembler programs are accessing data from the COBOL programs, 
those COBOL programs should be DATA(24) (you claim DATA(31).

Can you be explicit about what you mean by "self-contained"? If the Assembler 
programs are CALLed with no parameters and, for instance, just start up some 
type of service, then, as long as the Assembler program doesn't get to garble 
the return-address, you can ignore any interaction between COBOL and Asm. Is 
that what you have? If not, please describe it more clearly, including answers 
to the questions previously asked.

All you CALLs are static, then we'd just absolutely love to see your output 
from the binder. Perhaps after answers to the above.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Peter Relson]

Dale Smith's append had some very good info.

(snips)
COBOL programs today are always AMODE 31.
and
COBOL programs can call AMODE 24 programs
and
IGZ0033S
An attempt was made to pass a parameter address above 16 megabytes to 
AMODE(24) program program-name.
(end-snips)

Leads me to think that we might be talking about a call-by-module-name to 
a program via some system-assisted linkage (as opposed to via external 
reference within the load module / program object).
And it leads me to think that COBOL must be doing something like a BLDL to 
find out what the AMODE is, prior to generating (for example) LINK to give 
control to the program.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Brian Westerman]

While the DCB has been required below the line, the program itself need not be 
AMODE24.  Simply stated, programs that use DCBs can be located above the line 
but the actual DCBs must be located below the line.  Make sure to code DCBE or 
you will not get the desired results.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Dale R. Smith]

On Fri, 23 Dec 2016 10:07:28 -0500, scott Ford  wrote:

>Peter,
>
>Thank you  for the explanation . I am trying to understand what i am seeing
>..
>My exposure to LE has been through writing in Cobol since 3.4 but I want to
>know more to
>broaden my techniques. Looks like i have some reading to do.
>
>Regards,
>Scott
>
>On Fri, Dec 23, 2016 at 9:38 AM, Peter Relson  wrote:
>
>> >i know i can re-locate the DCBS above the line. I
>>
>> No you don't know that. DCBs are required to be below 16M. AMODE is not
>> relevant.
>>
>> I have no idea how COBOL "calls" another module. I don't believe that LE
>> has any support for calling modules in AMODE 24.
>> You can obviously accomplish doing a "LINK" of your own. And you can
>> accomplish getting storage below 16M .
>>
>> It seems somewhat unlikely that you can get the language to do a BASSM or
>> to get the language to do a BSM to return.
>>
>> Peter Relson
>> z/OS Core Technology Design

COBOL Calls are basically the same as the Assembler CALL Macro, no AMODE 
switching occurs.  COBOL programs today are always AMODE 31.  RMODE can be set 
via Compiler Parm or via the Binder of course.  The default for the RMODE COBOL 
Compiler option is AUTO, which means make the program RMODE ANY if the RENT 
option is also specified, if NORENT them make the RMODE 24.  The DATA COBOL 
Compiler option specifies where COBOL Working Storage is allocated if the RENT 
option is specified, it has no affect if NORENT is specified.  The default for 
DATA is 31 to allocate the storage above the line.

COBOL programs can call AMODE 24 programs if no parameters are passed or the 
parameters are below the line.  If any above the line parameters are passed, 
you will most likely get a U4038 ABEND and message IGZ0033S will be issued. 
 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea900/cs00470.htm

IGZ0033S
An attempt was made to pass a parameter address above 16 megabytes to AMODE(24) 
program program-name.

Explanation
An attempt was made to pass a parameter located above the 16-megabyte storage 
line to a program in AMODE(24). The called program will not be able to address 
the parameter.

System action
The application was terminated.

Programmer response
If the calling program is compiled with the RENT option, the DATA(24) option 
may be used in the calling program to make sure that its data is located in 
storage accessible to an AMODE(24) program. If the calling program is compiled 
with the NORENT option, the RMODE(24) option may be used in the calling program 
to make sure that its data is located in storage accessible to an AMODE(24) 
program. Verify that no linkedit, binder or genmod overrides are responsible 
for this error.
---

The other option not mentioned above would be to change the called program to 
run AMODE 31 so it can access parameters above the line.  Because you are not 
currently passing parameters to the called program, you are not having any 
problems calling it.

-- 
Dale R. Smith

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Peter,

Thank you  for the explanation . I am trying to understand what i am seeing
..
My exposure to LE has been through writing in Cobol since 3.4 but I want to
know more to
broaden my techniques. Looks like i have some reading to do.

Regards,
Scott

On Fri, Dec 23, 2016 at 9:38 AM, Peter Relson  wrote:

> >i know i can re-locate the DCBS above the line. I
>
> No you don't know that. DCBs are required to be below 16M. AMODE is not
> relevant.
>
> I have no idea how COBOL "calls" another module. I don't believe that LE
> has any support for calling modules in AMODE 24.
> You can obviously accomplish doing a "LINK" of your own. And you can
> accomplish getting storage below 16M .
>
> It seems somewhat unlikely that you can get the language to do a BASSM or
> to get the language to do a BSM to return.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Peter Relson]

>i know i can re-locate the DCBS above the line. I

No you don't know that. DCBs are required to be below 16M. AMODE is not 
relevant.

I have no idea how COBOL "calls" another module. I don't believe that LE 
has any support for calling modules in AMODE 24.
You can obviously accomplish doing a "LINK" of your own. And you can 
accomplish getting storage below 16M .

It seems somewhat unlikely that you can get the language to do a BASSM or 
to get the language to do a BSM to return.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Peter:

The reason I asked was that we have been running this STC for a long time
in Cobol with
AMODE(31), RMODE(ANY) and it was performing calls to Assembler modules,
these modules are
AMODE(24),RMODE(24) and were performing I/O to QSAM files  apparently with
no issues. But in all our cases nothing is
passed.  A file is built and the Assembler sub-program returns back to the
caller. We read the file , etc. In our case we built socket messages ..

Part of the reason for my question is that if i wanted to run the Assembler
programs as AMODE(31), RMODE(31) i know i can re-locate the DCBS above the
line. I have several examples. But isnt still some of the DCB control
blocks below the line ?

If not can you be so kind as to explain the difference...

Thank You

Scott

On Thu, Dec 22, 2016 at 8:39 AM, Peter Relson  wrote:

> 
> I think i am right in saying that RMODE(ANY) sees the program with
> RMODE(24) and
> its ok to execute and the I/O buffers are they 24bit or 31
> 
>
> It seems unlikely that the calling program pays any attention to the RMODE
> of anything that it calls.
>
> It is up to the caller to meet the requirements of the callee. If the
> callee is AMODE 24, then it would be expected that any data passed from
> the caller to the callee be below 16M. That includes save area and
> parameter list.
>
> Does COBOL actually have any support for AMODE-switching calls?
>
> If this was assembler, and you were an AMODE 31 program and you LINKed to
> some other program via LINKX, you would need to know the AMODE of that
> program in order to accommodate its needs. This is a reason that LINKing
> to an AMODE 64 program is not accepted unless you have told LINKX
> AMODE64OK=YES which to some extent is intended to let you acknowledge that
> you have provided a 144-byte save area (or whatever the potentially AMODE
> 64 routine might need in order to save registers).
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Peter Relson]

I think i am right in saying that RMODE(ANY) sees the program with
RMODE(24) and
its ok to execute and the I/O buffers are they 24bit or 31


It seems unlikely that the calling program pays any attention to the RMODE 
of anything that it calls.

It is up to the caller to meet the requirements of the callee. If the 
callee is AMODE 24, then it would be expected that any data passed from 
the caller to the callee be below 16M. That includes save area and 
parameter list.

Does COBOL actually have any support for AMODE-switching calls?

If this was assembler, and you were an AMODE 31 program and you LINKed to 
some other program via LINKX, you would need to know the AMODE of that 
program in order to accommodate its needs. This is a reason that LINKing 
to an AMODE 64 program is not accepted unless you have told LINKX 
AMODE64OK=YES which to some extent is intended to let you acknowledge that 
you have provided a 144-byte save area (or whatever the potentially AMODE 
64 routine might need in order to save registers).

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Sam Siegel]

Look at the load library directory listing for the calling module in
question. It may show up as amode 24 and rmode 24.



On Dec 21, 2016 5:17 PM, "scott Ford"  wrote:

> Sam:
>
> CBL option is nodyn and statically linked ..
> Our CBL options are :
>
> CBL NOC(E),FLAG(W),DATA(31),NODYN,RES,RENT,MAP,SSR
> CBL NOZWB,NUM,NOTERM,NOVBREF,X,APOST,LIB,LIST
>
> Regards,
> Scott
>
>
> On Wed, Dec 21, 2016 at 6:38 PM, Sam Siegel  wrote:
>
> > Scott - Is any data passed via linkage?  Are the programs dynamically
> > loaded and dynamically called?  Or are they statically linked and
> > called?
> >
> > Sam
> >
> > On Wed, Dec 21, 2016 at 3:34 PM, scott Ford  wrote:
> > > Sam,
> > >
> > > I see what you saying, the program's being called are
> > self-contained..they
> > > execute perform data extract functions , close the file and return
> > >
> > > Scott
> > >
> > > On Wednesday, December 21, 2016, Sam Siegel  wrote:
> > >
> > >> I think that the AMODE(24) is of more concern.  Depending on how they
> > >> are invoked and/or how the entry/exit logic works, they may only be
> > >> using 24-bit addresses.  This would be a problem if a buffer was
> > >> passed to them with a valid 31-bit address.
> > >>
> > >> On Wed, Dec 21, 2016 at 2:15 PM, scott Ford  > >> > wrote:
> > >> > All:
> > >> >
> > >> > I have a dumb question ...we have a STC running AMODE(31)
> RMODE(ANY)
> > and
> > >> > written in
> > >> > LE Cobol 4.2  we also run DATA(31) , my question is we call several
> > sub
> > >> > programs which are
> > >> > AMODE(24) and RMODE(24) and they work and have been working for a
> long
> > >> time.
> > >> > Several of these Assembler programs are doing I/O. My question is
> why
> > ...
> > >> >
> > >> > I think i am right in saying that RMODE(ANY) sees the program with
> > >> > RMODE(24) and
> > >> > its ok to execute and the I/O buffers are they 24bit or 31
> > >> >
> > >> > Sorry for the dumb question, everyone..
> > >> >
> > >> > Regards,
> > >> > Scott
> > >> >
> > >> > 
> > --
> > >> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >> > send email to lists...@listserv.ua.edu  with the
> > message:
> > >> INFO IBM-MAIN
> > >>
> > >> 
> --
> > >> For IBM-MAIN subscribe / signoff / archive access instructions,
> > >> send email to lists...@listserv.ua.edu  with the
> message:
> > >> INFO IBM-MAIN
> > >>
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Sam:

CBL option is nodyn and statically linked ..
Our CBL options are :

CBL NOC(E),FLAG(W),DATA(31),NODYN,RES,RENT,MAP,SSR
CBL NOZWB,NUM,NOTERM,NOVBREF,X,APOST,LIB,LIST

Regards,
Scott


On Wed, Dec 21, 2016 at 6:38 PM, Sam Siegel  wrote:

> Scott - Is any data passed via linkage?  Are the programs dynamically
> loaded and dynamically called?  Or are they statically linked and
> called?
>
> Sam
>
> On Wed, Dec 21, 2016 at 3:34 PM, scott Ford  wrote:
> > Sam,
> >
> > I see what you saying, the program's being called are
> self-contained..they
> > execute perform data extract functions , close the file and return
> >
> > Scott
> >
> > On Wednesday, December 21, 2016, Sam Siegel  wrote:
> >
> >> I think that the AMODE(24) is of more concern.  Depending on how they
> >> are invoked and/or how the entry/exit logic works, they may only be
> >> using 24-bit addresses.  This would be a problem if a buffer was
> >> passed to them with a valid 31-bit address.
> >>
> >> On Wed, Dec 21, 2016 at 2:15 PM, scott Ford  >> > wrote:
> >> > All:
> >> >
> >> > I have a dumb question ...we have a STC running AMODE(31)  RMODE(ANY)
> and
> >> > written in
> >> > LE Cobol 4.2  we also run DATA(31) , my question is we call several
> sub
> >> > programs which are
> >> > AMODE(24) and RMODE(24) and they work and have been working for a long
> >> time.
> >> > Several of these Assembler programs are doing I/O. My question is why
> ...
> >> >
> >> > I think i am right in saying that RMODE(ANY) sees the program with
> >> > RMODE(24) and
> >> > its ok to execute and the I/O buffers are they 24bit or 31
> >> >
> >> > Sorry for the dumb question, everyone..
> >> >
> >> > Regards,
> >> > Scott
> >> >
> >> > 
> --
> >> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >> > send email to lists...@listserv.ua.edu  with the
> message:
> >> INFO IBM-MAIN
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu  with the message:
> >> INFO IBM-MAIN
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Sam Siegel]

Scott - Is any data passed via linkage?  Are the programs dynamically
loaded and dynamically called?  Or are they statically linked and
called?

Sam

On Wed, Dec 21, 2016 at 3:34 PM, scott Ford  wrote:
> Sam,
>
> I see what you saying, the program's being called are self-contained..they
> execute perform data extract functions , close the file and return
>
> Scott
>
> On Wednesday, December 21, 2016, Sam Siegel  wrote:
>
>> I think that the AMODE(24) is of more concern.  Depending on how they
>> are invoked and/or how the entry/exit logic works, they may only be
>> using 24-bit addresses.  This would be a problem if a buffer was
>> passed to them with a valid 31-bit address.
>>
>> On Wed, Dec 21, 2016 at 2:15 PM, scott Ford > > wrote:
>> > All:
>> >
>> > I have a dumb question ...we have a STC running AMODE(31)  RMODE(ANY) and
>> > written in
>> > LE Cobol 4.2  we also run DATA(31) , my question is we call several sub
>> > programs which are
>> > AMODE(24) and RMODE(24) and they work and have been working for a long
>> time.
>> > Several of these Assembler programs are doing I/O. My question is why ...
>> >
>> > I think i am right in saying that RMODE(ANY) sees the program with
>> > RMODE(24) and
>> > its ok to execute and the I/O buffers are they 24bit or 31
>> >
>> > Sorry for the dumb question, everyone..
>> >
>> > Regards,
>> > Scott
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu  with the message:
>> INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu  with the message:
>> INFO IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[scott Ford]

Sam,

I see what you saying, the program's being called are self-contained..they
execute perform data extract functions , close the file and return

Scott

On Wednesday, December 21, 2016, Sam Siegel  wrote:

> I think that the AMODE(24) is of more concern.  Depending on how they
> are invoked and/or how the entry/exit logic works, they may only be
> using 24-bit addresses.  This would be a problem if a buffer was
> passed to them with a valid 31-bit address.
>
> On Wed, Dec 21, 2016 at 2:15 PM, scott Ford  > wrote:
> > All:
> >
> > I have a dumb question ...we have a STC running AMODE(31)  RMODE(ANY) and
> > written in
> > LE Cobol 4.2  we also run DATA(31) , my question is we call several sub
> > programs which are
> > AMODE(24) and RMODE(24) and they work and have been working for a long
> time.
> > Several of these Assembler programs are doing I/O. My question is why ...
> >
> > I think i am right in saying that RMODE(ANY) sees the program with
> > RMODE(24) and
> > its ok to execute and the I/O buffers are they 24bit or 31
> >
> > Sorry for the dumb question, everyone..
> >
> > Regards,
> > Scott
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Addressing Question

[Sam Siegel]

I think that the AMODE(24) is of more concern.  Depending on how they
are invoked and/or how the entry/exit logic works, they may only be
using 24-bit addresses.  This would be a problem if a buffer was
passed to them with a valid 31-bit address.

On Wed, Dec 21, 2016 at 2:15 PM, scott Ford  wrote:
> All:
>
> I have a dumb question ...we have a STC running AMODE(31)  RMODE(ANY) and
> written in
> LE Cobol 4.2  we also run DATA(31) , my question is we call several sub
> programs which are
> AMODE(24) and RMODE(24) and they work and have been working for a long time.
> Several of these Assembler programs are doing I/O. My question is why ...
>
> I think i am right in saying that RMODE(ANY) sees the program with
> RMODE(24) and
> its ok to execute and the I/O buffers are they 24bit or 31
>
> Sorry for the dumb question, everyone..
>
> Regards,
> Scott
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Addressing Question

[scott Ford]

All:

I have a dumb question ...we have a STC running AMODE(31)  RMODE(ANY) and
written in
LE Cobol 4.2  we also run DATA(31) , my question is we call several sub
programs which are
AMODE(24) and RMODE(24) and they work and have been working for a long time.
Several of these Assembler programs are doing I/O. My question is why ...

I think i am right in saying that RMODE(ANY) sees the program with
RMODE(24) and
its ok to execute and the I/O buffers are they 24bit or 31

Sorry for the dumb question, everyone..

Regards,
Scott

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN