Re: Addressing Question

2017-01-06 Thread 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

Re: Addressing Question

2017-01-05 Thread 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

Re: Addressing Question

2017-01-05 Thread 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, > > > >

Re: Addressing Question

2017-01-05 Thread 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

Re: Addressing Question

2017-01-04 Thread 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

Re: Addressing Question

2017-01-04 Thread 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

Re: Addressing Question

2017-01-04 Thread 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

Re: Addressing Question

2017-01-04 Thread Frank Swarbrick
nt: 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 a

Re: Addressing Question

2017-01-04 Thread 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

Re: Addressing Question

2017-01-04 Thread 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. > >

Re: Addressing Question

2017-01-04 Thread 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

2017-01-04 Thread 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,

Re: Addressing Question

2017-01-03 Thread 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

Re: Addressing Question

2017-01-03 Thread 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

Re: Addressing Question

2017-01-03 Thread 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,

Re: Addressing Question

2016-12-28 Thread 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

Re: Addressing Question

2016-12-27 Thread 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

Re: Addressing Question

2016-12-27 Thread 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,

Re: Addressing Question

2016-12-27 Thread 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

Re: Addressing Question

2016-12-24 Thread 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

Re: Addressing Question

2016-12-23 Thread 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

Re: Addressing Question

2016-12-23 Thread 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

Re: Addressing Question

2016-12-23 Thread 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

Re: Addressing Question

2016-12-23 Thread 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

Re: Addressing Question

2016-12-22 Thread 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

Re: Addressing Question

2016-12-22 Thread 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

Re: Addressing Question

2016-12-21 Thread 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

Re: Addressing Question

2016-12-21 Thread 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

Re: Addressing Question

2016-12-21 Thread 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

Re: Addressing Question

2016-12-21 Thread 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

Re: Addressing Question

2016-12-21 Thread 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