>
> To add to Paul's "idleness" - here's some idle answers :-)
>
> Paul Gilmartin <[email protected]> wrote:
>
> On 2016-01-05, at 06:14, Peter Relson wrote:
> >
> > We have never, to my knowledge, encountered any downside to using GOFF. Is
> > there any?
> >
> Cross-assembling for non-IBM OSes on non-IBM hardware. (But that doesn't
> concern you.) It may even be necessary to drop back to Linkage Editor
> because load modules produced by Binder are subtly incompatible.
Why would cross-assembling be a down-side to using GOFF, you can
produce GOFF object decks on any platform. Just assume an FB80
file (like HLASM does under USS) and *poof* - you're good to go.
>
> > If that thought is correct, I'd suggest that someone consider asking for a
> > way to identify that SECTALGN apply only to DSECTs (and thus might be an
> > assembler directive that would not need to make its way into the GOFF).
> >
> Is the Binder even aware of DSECTs? Oh, of course. Pseudo Register Vector,
> manifested by CXD/DXD instructions.
A CXD/DXD isn't the same as a DSECT... (although a DSECT could contain
a field that is one of these to allocate space, there's no "relocation"
in a DSECT.)
>
> Hmmm. Idle musings. Does Binder optimize storage in the PRV, minimizing
> slack bytes as HLASM does with the literal pool by allocating the largest
> objects first. Can the programmer control the order of entries in the PRV
> with Binder ORDER statements?
The Binder does "pack" items in the PRV to eliminate "holes". It simply
sorts them by size/alignement. This isn't under control of the programmer
via any ORDER-like statements.
>
> What RMODE for the PRV? Of course that's determined at runtime by the
> call to STORAGE. But can the assembler programmer communicate to the
> runtime code that 24, 31, or 64 bit addressability is required? Something
> in the reply to CXD?
The PRV is allocated at runtime by the program, so the program is
responsible for deciding "where" it goes.
An offset in the PRV is either 4-bytes or 8-bytes (via Q-con or
QD-con relocations.) So, if your PRV size is under 2G you can
stick with 4-byte Q-CONs. You simply add the binder-provided
Q-CON value to the start of your allocated memory. It's up
to you to do the addition, so if your program is going to allocate
the PRV above-the-bar, the addition (of even the 4-byte value)
needs to be 64-bit aware.
Of course, the binder is going to need to assign offsets
in the PRV as it does the linking... practical limitations
might arise from the binder implementation (if, for instance,
the binder's PRV-offset-counter were only 4 bytes long, then
the PRV size would be limited to 2G.)
>
> What if the programmer needs PRVs in more than one (up to 3) RMODES?
There is only one PRV per load-module... The binder assigns
offsets to DXDs from the object files and keeps a running total
to provide the total required size for the CXD relocation. There
is only one "running total" for the load module, so only one
PRV per load module.
>
> What limit is there on the size of the PRV? Load modules were limited
> to 16MiB. Does this apply alike to program objects and PRVs? Decades
> ago, CMS limited the PRV to 64 KiB (perhaps 32)? has this restriction
> been lifted.
Well - the PRV is really limited by the size of memory you can allocate,
and perhaps, the offset you can generate in a Q-CON/QD-CON.
The limitation from CMS was an artifact of the linker, not the
runtime environment (I'd guess the space for the table that the linker
allocated to do the PRV management?)
Also - older versions of CMS (and VSE?) had bugs in their linker
when the PRV went over 4K, so the practical limit there was 4K
(unless you get some other tool to handle the PRV for you.)
- Dave Rivers -
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
