Hi Martin,
Yes - you can do that.
You wouldn’t run the IBM binder though, we would do the “binding”;
that is, we don’t post-process the binder output, we actually do the binding.
The result would be VSE-unloaded phase sitting an FB80 file.
So, you could do all your assemblies on z/OS (producing either
GOFF or OBJ files), feed them into our linker and produce
an unloaded VSE phase.
This "unloaded phase" starts with a record that indicates
some of the attributes, and is then basically followed by
a stripped-down object deck where most of the linking
has been done.
Alternatively - you could run our linker in its “pre-linking”
mode to combine all of the objects together and produce
a single output “blob”. In this mode, all of the input
GOFF objects would be converted to old-style OBJ objects.
I use the term “blob” because the result is not a single object
file, but a concatenation of the input objects (possibly
converted from GOFF.) You could then send that
to VSE for processing by the VSE linker.
The VSE linker is notorious for mis-processing larger-than-4K
PRV definitions too (at least some older ones were), so there
is an option to have our pre-linker handle that for you, so that
the VSE linker would only “see” non-PRV-related relocations.
(older CMS has the same issue.) We can also map long-names
to short ones if that is desirable (and even give you control
of that mapping function via an EXIT, or on cross-platform
hosts via a shared-library/DLL.)
Thus - we have a way for using GOFF objects in
“older” situations, for people who have that requirement.
You can either let us do the “binding”, or let the native
linker do it and let us process-it-down for you.
- Dave R. -
> On Jan 5, 2016, at 11:49 AM, [email protected] wrote:
>
> Dave,
>
> let me see if i have this right-
>
> one can use the HLASM on z/OS (it's there anyway) and
>
> then use your "binder/linker" to produce stuff that can then be
> processed by LNKEDT in z/VSE
>
> (I omitted the obvious step of running binder in z/OS to produce a
> loadable module)
>
> --
> Martin
>
> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> more at http://www.picapcpu.de
>
