Oppolzer - Informatik / Blog

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 has to define it as a static or
automatic structure using DC definitions with init, and the called program
should define a DSECT, identifying it with some parameter address register,
which it gets from the register 1 parameter address list.

To support this, we constructed so called "address list macros", which are
generated from a repository. The address list macros are generated in different
target languages (ASSEMBLER, PL/1, C), because the languages can be mixed
freely.

In the normal case, the name of the address list macro is the same name as the
name of the module which implements the service, that is, the address list is
the interface to the module. In special cases, several modules share the same
interface and the same address list macro.

ASSEMBLER considerations:

Of course, the definitions inside the address list macro are not normal DS or DC
instructions, but macro calls that are expanded to DS or DC according to the
needs of the environment. To do this, the address list macros have parameters
like DEF=NO/YES, CALL=NO/YES, INIT=NO/YES and so on; by specifying these
parameters, the different variants of the address list macros are selected.

All adress list macros of the same name and version are guaranteed to match,
regardless of the target language (ASSEMBLER, PL/1 or C). This is because they
are generated from the same source (repository) and the three generating
programs are guaranteed to take care of - for example - the different alignment
strategies of the three languages.

And: the address list macros have eyecatchers and version informations included,
of course; these informations can be checked at runtime. There is even the
possibility to upgrade lower versions of interfaces to higher versions on the
fly, if desired and technically possible (then for a certain time frame there is
no need to move all existing callers to the new version of the interface, but
some can stay on the old version ... you can change the callers to the new
version step by step).

If you want to know more about those techniques, please feel free to
contact me offline.

Kind regards

Bernd



Am 02.10.2014 18:14, schrieb G.W.:
> 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
> ABCID    DS    CL4               Eyecatcher
> ABCLEN   DS    AL2               Length of ABC
> ABCLVL   DS    AL2               ABC modification level
> ABCDATA  DS    F                  Some binary data
> ABCL     EQU   (*-ABCID)
>
> I would like to be able to generate in-line constants:
> label1   DS    0F
>          DC    CL4'EYEC'
>          DC    AL2(ABCL)
>          DC    AL2(1)
>          DC    F'0'
> ABCL     EQU   (*-label1)
>
> and space:
> label2   DS    CL(ABCL)
>
> The DSDC macro generates a labeled DS statements or unlabeled DC
> statements depending on &TYPE; its format is, for example:
> ABCEYE   DSDC  CL4,C'ABCD','EYECATCHER',&TYPE
> ABCLEN   DSDC  AL2,(ABCBLKLN),'LENGTH OF THIS CONTROL BLOCK',&TYPE
>
> Although I started work on this with a macro I call DSDC, I was
> wondering if I'm reinventing the wheel.   Is there a model for this
> out there?
>
> Any suggestions are welcome.
>
> G.W.
>