> On Jan 5, 2016, at 4:25 PM, Paul Gilmartin > <[email protected]> wrote: > > On 2016-01-05 13:57, Dave Rivers wrote: >> >> 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. >> > Doesn't work if SMP/E packaging is required. But I think (I may never have > tried) > that SMP/E is GOFF-savvy.
Yeah - if you’re going down the SMP/E road then we do have _other_ approaches. You can do the pre-linking with our tools, and then we can generate individual object decks from each input object deck (these output decks would have undergone GOFF->OBJ conversion.) You can then keep the individual object decks and even do comparisons between releases to see which items need participate in an SMP/E update. On cross-platform hosts, we fill up a directory with the individual objects. On z/OS it is a PDS. And there are exits/shared-libraries/dll entries so you can control the names of the resulting object decks, etc… You can then keep the individual object decks and even do comparisons between releases to see which items need participate in an SMP/E update. It’s possible with this facility to automatically generate the list of changed CSECTs and only ship out those in your SMP/E maintenance. > >> 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… >> > Absent ALIGN(16), Assembler doesn't know how many slack bytes to generate. > > It ain't your father's OS/360. Oh yes - for sure… but if you put the ALIGN(16) in the DSECT, and then the USING reg isn’t 16-byte aligned, what the assembler did vis-a-vis slack bytes isn’t going to be correct. So, perhaps it’s better to disallow the ALIGN(16) - or perhaps it’s better for the ALIGN(16) to mean “I know what I’m doing, assembler you need to assume that my USING will be correctly aligned”…. I dunno… I get the idea this isn’t a “new” problem though - would you have the same issue for, say, the 8-byte alignment requirement of an ECB; or the same requirement for some instruction operands? If the operand is a field of a DSECT, would it be up to the assembler to produce “slack bytes’ (how can it, since it doesn’t know the address) or up to the programmer to guarantee proper alignment? I would guess that whatever was decided for that issue would be the guiding precedent here? - Dave R. - -- [email protected] Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
