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.
> 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. 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? 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? What if the programmer needs PRVs in more than one (up to 3) RMODES? 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. When are load modules still required? I suppose whenever the PDSE task isn't available. Does CMS support program objects in BFS? What's the alternative? -- gil
