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 Gary Weinhold:
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.
Gary Weinhold
Data Kinetics, Ltd.
