I am trying to develop a technique to force a DSECT (describing some
private control block of mine) to stay synchronized with the
inline-constant and space-reserving versions of the same control block.
For example, for DSECT ABC with field definitions of
ABCIDDSCL4 Eyecat
Web: http://zosdebug.com
Facebook: http://www.facebook.com/arneycomputer
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gary Weinhold
Sent: Thursday, October 02, 2014 11:15 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Macro to
> The DSDC macro generates a labeled DS statements or unlabeled DC
> statements depending on &TYPE; its format is, for example:
Just a small point...
There is no actual requirement to use DS rather than DC in a DSECT. In
fact there are reasons to prefer DC. One reason is that the nominal value
Here's an example of how I would address this issue:
MYDATAMAP DSECT ,
MYFIELD1 DS [whatever]
MYFIELD2 DS [whatever]
...
MYDATAMAPZ DS 0X
MYDATAMAPL EQU MYDATAMAPZ-MYDATAMAP
...
MYSOMETHINGELSE {C|D}CSECT ,
...
MYEMBEDDEDINSTANCE DS 0D
DS XL(MYDATAMAPL)
...
MYCODE
On 2014-10-02, at 11:36, David Cole wrote:
> Here's an example of how I would address this issue:
> ...
> Basically, what I do when I want to create one or more embedded instances of
> a common data structure is this:
> * I create one map of the common data structure. (That map can be an en
Ref: Your note of Thu, 2 Oct 2014 12:14:37 -0400
You can do things like this using OPSYN to intercept standard
definitions (written using DC) and then generate modified
versions (using renamed copies of the original opcodes).
About 25 years ago, when I was younger and more energetic, I
spent sev
At 10/2/2014 02:12 PM, Paul Gilmartin wrote:
I wanted to generate a model (like MF=L) in my code CSECT; obtain
storage of suitable length, copy the model there; establish
addressability, perhaps with labelled/dependent USINGs, and store
values known only at run time into fields in the obtained
On 2014-10-02, at 12:44, Jonathan Scott wrote:
>
> Initialised dynamic structures are supported, either embedded
> within a contiguous area of initialised automatic storage or
> allocated individually. These are compiled as separate CSECTs
> but copied to dynamic storage when initialised, then th
On 2014-10-02, at 12:59, David Cole wrote:
> At 10/2/2014 02:12 PM, Paul Gilmartin wrote:
>> I wanted to generate a model (like MF=L) in my code CSECT; obtain storage of
>> suitable length, copy the model there; establish addressability, perhaps
>> with labelled/dependent USINGs, and store value
At 10/2/2014 04:13 PM, Paul Gilmartin wrote:
I got "multiple resolutions" because RSA appeared to overlap the 72
bytes of MYCODE prior to MODEL. If I had been able to set a lower
limit on the named using the problem wouldn't have occurred. Imagine:
M(MODEL,(MODEL,MODELZ)),EMBEDDEDINS
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
in your dynamic copy, a LARL R1,Field would still address it the
original CSECT.
Seems l
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 Gi
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 th
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 adj
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 (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)
>> (altho
On 2014-10-03, at 08:34, Ed Jaffe wrote:
> 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 f
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; may
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 support
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 r
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
> ra
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
>>btw, HLASM does warn about them.
>At that is very very good
And it is good that it is very very good about that. There is no warning
if you assemble with GOFF.
HLASM warns about them when not using GOFF because without GOFF it cannot
produce the data needed by the binder and loader to resol
Sorry for jumping in late.
I would like to return back to the original posters question after some
topic drift.
In our environment, we have a similar problem, that is:
if a parameter structure has to be defined consistently on both sides
(caller and
- external - called module), the caller ha
Gary,
I'm not sure whether there are any extant solutions.
My tuppence:
Create an XSECT macro that will AREAD source code until you reach a marker.
Have the XSECT macro re-emit all DC/DS/EQU statements (inlcuding a
leading DSECT) while saving them for later re-use.
Then when allocating an ins
28 matches
Mail list logo
