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, mar...@pi-sysprog.de 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 >