On Mon, Mar 5, 2018 at 12:51 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
It has to be system wide. It has to include every callable IBM object as well as all user callable objects.
You've mentioned this at least a couple times, and it's one of the
ways in which I think you are imagining that I am after something a
lot "stronger" than what I really am.
First, how does anything get linked at all today? Somewhere, somehow,
you have to specify an explicit path or library; or you have to agree
to use the library list; or you have to have some other kind of
agreed-upon convention. Point being, you never have to see all the
objects in the system to build whatever it is you're building. You
just have to be able to see the things you need. If something you need
exists, but is not found using the agreed-upon search method, then too
bad, you don't see everything that you need, and the build fails.
There is nothing wrong with this picture. Getting rid of redundant
boilerplate has no bearing on this picture.
So I am at a loss why you are hung up on a proper import mechanism
needing to be systemwide.
If what you mean is that every object would have to be rebuilt if it
were to participate in the new import mechanism, then sure (maybe).
But it was the same situation with OPM and ILE. You can still build
OPM programs. They still work. They can even coexist on the same
system as ILE programs. ILE is not "systemwide" in the sense that you
are describing. I don't see why you couldn't keep writing and building
ILE programs (or modules or service programs or what have you) exactly
as you do today; and someone else, on the same system, uses some
brand-new import mechanism that *your* ILE stuff hasn't opted into.
Her programs (probably) won't be able to use the new import mechanism
to link in your stuff, but that's OK.
Just a few other issues off the top of my head:
- Not only do the parameters have to be described but you also need all the other characteristics - CONST, VALUE, DATFMT, and on and on.
- How many signatures do we carry given optional parameters?
- What about C style functions with an "unlimited" number of parms? What does that signature look like?
- If extend the data to allow for passing of a DS array how do I constrain the number of elements passed?
- What do we do about languages like CL and COBOL that have no notion of prototyping? Stop RPG programmers from calling them via a CONST option that would allow for variance in field sizes?
I don't see any of those as "technical issues". Those are just a
matter of bikeshedding. Picking a syntax. Picking a serialization
format. Maybe picking semantics in some cases. But no tough nuts to
crack there. (Am I sounding like Dieter?)
John Y.
midrange.com
