Hi!
Oh yes - there are several situations in GOFF that don’t translate.
In some cases there would be a warning/error.
But, for some situations if we’re doing the ‘linking’ - we can just handle it.
For example,
if you’re producing an unloaded VSE phase - that is one large object deck with
everything
already laid out, so we can apply the ALIGN(16) when laying it out. The VSE
linker
does very little with the result, most “linking” has been done. Same thing
for a TSO
transmit file (where we are doing all the linking.)
But, if we’re generating a regular OBJ file, then we will say “hey - that
won’t work” and
bail out.
By the way - I’m not sure I agree with ignoring an ALIGN(16) in a DSECT. The
assembler
can’t know what offset will be USEd for referencing the DSECT fields, and thus
can’t
make the assumption that the ALIGN(16) is at all meaningful. Of course, you
could also
make the claim that “hey - I’m telling you this DSECT will _always_ be 16-byte
aligned
with this ALIGN(16), so if it’s not, it’s my fault”. I can see both sides of
that…
- Dave R. -
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
> On Jan 5, 2016, at 3:46 PM, Paul Gilmartin
> <[email protected]> wrote:
>
> On 2016-01-05 12:35, Ed Jaffe wrote:
>>
>> I agree it would be nice to be able to insert a job step on the z/OS side to
>> transform a GOFF object into something consumable by z/VSE -- either object
>> deck or phase.
>>
> HLASM can generate either GOFF or traditional object format. You need GOFF
> only if
> you're using a feature not supported by traditional format, in which case
> transforming
> to traditional format sacrifices that feature.
>
> But an exception should be made for ALIGN(16) in DSECTs.
>
> What does Dignus do translating GOFF with ALIGN(16) to traditional object.
> It should issue at least a warning.
>
> -- gil
>
