On Sun, 7 Jun 2009 09:16:40 -0400, Peter Relson wrote:
>
> HLASM could have a restriction such as 16M on
>the cumulative size of CSECTs within a single assemly unit (I have no idea
>if that is the case)
>
Once I enable GOFF, the restriction vanishes, not only for the cu
CSECTs are restricted to 16MB only if you generate traditional OBJ
object files, because its length and address fields are 3 bytes long.
As Peter said, the total length in a single assembly will be less
than 16M.
*BUT* if you specify the NOTHREAD option you can have as many very
larget CSECTs as y
On Sat, 6 Jun 2009 15:27:52 -0700, Edward Jaffe wrote:
>Paul Gilmartin wrote:
>> By experiment, I discover that HLASM won't let me create a CSECT
>>> 16MiB. It won't let me create a program with multiple CSECTs
>> totalling >16 MiB(?!) Sigh.
>
>Are you using GOFF?
>
GOFF is the solution.
Thanks
>... when IEFBR14 is used to delete a data set ...
>Haven't we agreed here that IEFBR14 doesn't delete data sets? Hasn't
>IBM learned this yet?
To my way of thinking, the statement in the preview is correct and
accurate. (Almost) Everyone at some point or other *uses* an EXEC
PGM=IEFBR14 job to
In article you wrote:
> On Fri, 5 Jun 2009 16:18:07 -0500, Rick Fochtman wrote:
> >
> >"In z/OS V1.11, support is added for data tables contained in load
> >modules and program objects to be placed above 2 GB. A new ADDR64
> >
At 11:13 -0500 on 06/06/2009, Paul Gilmartin wrote about Re: EXEC
Above the Bar (Was Large Page Support):
Nearby in the same document:
... when IEFBR14 is used to delete a data set ...
Haven't we agreed here that IEFBR14 doesn't delete data sets? Hasn't
IBM learned this
Paul Gilmartin wrote:
By experiment, I discover that HLASM won't let me create a CSECT
16MiB. It won't let me create a program with multiple CSECTs
totalling >16 MiB(?!) Sigh.
Are you using GOFF?
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
L
>>read-only data tables.
>
>Maybe so From the z/OS 1.11 preview:
>
That's at:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS209-029
>"In z/OS V1.11, support is added for data tables contained in load modules
>and prog
On Fri, 5 Jun 2009 16:18:07 -0500, Rick Fochtman wrote:
>
>"In z/OS V1.11, support is added for data tables contained in load
>modules and program objects to be placed above 2 GB. A new ADDR64
>
>constraint relief. I'll hav
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Friday, June 05, 2009 5:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: EXEC Above the Bar (Was Large Page Support)
> -Original Message-
> From: IBM Mai
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman
> Sent: Friday, June 05, 2009 4:18 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EXEC Above the Bar (Was Large Page Support)
> That one reply about
---
Maybe so From the z/OS 1.11 preview:
"In z/OS V1.11, support is added for data tables contained in load
modules and program objects to be placed above 2 GB. A new ADDR64
parameter on the LOAD macro supports loading
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Friday, June 05, 2009 1:09 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EXEC Above the Bar (Was Large Page Support)
>
> Maybe so Fr
On Fri, 5 Jun 2009 11:54:29 -0500, McKown, John wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
>> Sent: Friday, June 05, 2009 10:34 AM
>> To: IBM-MAIN@bama.ua.edu
>>
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe
> Sent: Friday, June 05, 2009 12:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EXEC Above the Bar (Was Large Page Support)
>
> There are already
There are already facilities available for sharing data above the bar, why
would IBM want to create an "LPA" which cannot contain executable code? How
long would it take for some yahoo to put code there and try to execute it?
>>> "McKown, John" 6/5/2009 12:54 PM >>>
> I could see a use for loa
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Friday, June 05, 2009 10:34 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EXEC Above the Bar (Was Large Page Support)
>
> On Thu, 4 Jun 2
On Thu, 4 Jun 2009 18:33:35 -0500, Rick Fochtman wrote:
>Jim, a completely different question: can you give us any idea or hint
>when we can expect to use executable code above the bar?
>
Dream on.
But it must happen, sooner or later.
But IBM might not preannounce it.
>In my shop, we have progr
4 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: EXEC Above the Bar (Was Large Page Support)
> >
> > Jim, a completely different question: can you give us any
> > idea or hint
> > when we can expect to use executable code above the bar?
> >
>
> >
>
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman
> Sent: Thursday, June 04, 2009 6:34 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: EXEC Above the Bar (Was Large Page Support)
>
> Jim, a completely
Rick,
You don't need full fledged "executable code above the bar" for what you have
described.
You could use the SHARE/UNSHARE functions of IARVSERV added to IARV64 - in
other
words a 64-bit IARVSERV (i.e., captured storage grande).
That could be a WHOLE lot easier for IBM to ship than execu
Jim, a completely different question: can you give us any idea or hint
when we can expect to use executable code above the bar?
In my shop, we have programs that are executed literally thousands of
times per day and program fetch is a significant part of the time
involved. Adding these program
22 matches
Mail list logo
