Ref: Your note of Thu, 2 Oct 2014 14:03:07 -0600
I should have clarified that I use RSECT for code and constants
and CSECT for initialised dynamic areas, and I assemble with
NORENT, so the RSECT areas are checked for reentrancy but the
CSECT areas are not.
Jonathan Scott
IBM Hursley, UK
Paul
FWIW, while DSNQLEN is surely wrong (and as far as I can tell is not used
in our code), this macro is designated as not a programming interface.
The magic number 176 is the age-old size of a SWA block.
Peter Relson
z/OS Core Technology Design
1/2 of the people may be using Facebook, but that is now mostly just older
adults, so that is probably a good way to get old farts like us to respond.
On Thu, 10/2/14, ASSEMBLER-LIST automatic digest system
lists...@listserv.uga.edu wrote:
Subject:
At 00:13 -0400 on 10/03/2014, Steve Smith wrote about Re: Macro to
generate DS or DC:
Your colleague may have been time-traveling... it's not an old
assembler, it's the new one that allows addressing across CSECTs,
with relative addressing. So, while LA R1,Field would generate the
address
At 10/3/2014 08:18 AM, Peter Relson wrote:
The magic number 176 is the age-old size of a SWA block.
Yes, of course... But it still is a magic number.
Peter Relson
z/OS Core Technology Design
Dave Cole
Occasional P.I.T.A
On 10/3/2014 6:22 AM, Robert A. Rosenberg wrote:
I can see how the displacement between CSECTS can be computed by the
Assembler but this displacement can be wrong once the object deck is
link-edited/bound since the order of the CSECTS are not fixed. Unless
the LARL references RLDs (and thus
John Ehrman pointed this out a while back... I was surprised myself. If
you list the RLD map, you can see that there are indeed entries generated
for cross-section relative references.
btw, HLASM does warn about them. I'm not sure why; maybe because the old
linkage editor doesn't support them
On 2014-10-03, at 07:21, David Cole wrote:
At 10/3/2014 08:18 AM, Peter Relson wrote:
The magic number 176 is the age-old size of a SWA block.
Yes, of course... But it still is a magic number.
Heck. 44 is a magic number (also 1/4 of 176). How many
places hard-code it instead of using a
btw, HLASM does warn about them.
At that is very very good
I'm not sure why; maybe because the old linkage editor doesn't support them
so does the latest LNKEDT in z/VSE (nor long names nor alias nor GOFF
nor split mode nor RSECT nor RENT nor I could go on for a longer list)
(although
On 2014-10-03, at 09:17, Steve Smith wrote:
John Ehrman pointed this out a while back... I was surprised myself. If
you list the RLD map, you can see that there are indeed entries generated
for cross-section relative references.
btw, HLASM does warn about them. I'm not sure why; maybe
On 10/3/2014 8:36 AM, Paul Gilmartin wrote:
Would the programmer be well-advised to use Binder ORDER commands lest
SMP/E service reorder CSECTs and move a target out of relative addressing
range?
Unnecessary. LARL and its ilk have an addressing range considerably
wider than the largest
At 10/3/2014 11:15 AM, Paul Gilmartin wrote:
On 2014-10-03, at 07:21, David Cole wrote:
At 10/3/2014 08:18 AM, Peter Relson wrote:
The magic number 176 is the age-old size of a SWA block.
Yes, of course... But it still is a magic number.
Heck. 44 is a magic number (also 1/4 of 176).
On 2014-10-03 10:42, Ed Jaffe wrote:
On 10/3/2014 8:36 AM, Paul Gilmartin wrote:
Would the programmer be well-advised to use Binder ORDER commands lest
SMP/E service reorder CSECTs and move a target out of relative addressing
range?
Unnecessary. LARL and its ilk have an addressing range
On 10/3/2014 1:10 PM, Paul Gilmartin wrote:
Oops! I had thought program objects could be up to 16M;
relative addressing limited to +-1M. Which is wrong?
(Both?)
You might be thinking of 20-bit (i.e., long) displacements, which have
a range of 1M (512K in each direction). LARL and its ilk
Program objects may, currently, be only as much as 1 gigabyte in
size. Load modules must be less rthan 16 megabytes in size.
John Gilmore, Ashland, MA 01721 - USA
On 2014-10-03 14:40, Ed Jaffe wrote:
On 10/3/2014 1:10 PM, Paul Gilmartin wrote:
Oops! I had thought program objects could be up to 16M;
relative addressing limited to +-1M. Which is wrong?
(Both?)
You might be thinking of 20-bit (i.e., long) displacements, which have a
range of 1M
On 10/3/2014 2:35 PM, Paul Gilmartin wrote:
Does RMODE(SPLIT) work between RMODE(24) and RMODE(64)? That
could very quickly get a 4GiB reach.
No.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
I should be happy to see it work between AMODE(31) and AMODE(64), but
IBM appears to have judged that implementing it wouldn't be worth the
trouble. Too few people would make use of it.
I am not entirely sure what making it work [only] between AMODE(24)
and AMODE(64) would mean; but, as EJ has
And of course the (I LE 8) and (J LE 8) should have used 3 and not 8 as
the limit. Forgot to edit that from the actual code, which does use 8, but I
tried to simplify for my question here.
Peter
-Original Message-
From: IBM Mainframe Assembler List
19 matches
Mail list logo
