Maybe I'm totally wrong, but the reason for this suggestion
"you should IMO not require a current release"
is, that I have the feeling that there are some people out there that still use
old compilers on platforms that I am not familiar with - today - for example, VM
I am in the z/OS business exclusively since almost 15 years now, and we had the
current z/OS PL/1 compilers most of the time - only recently, we are a bit
behind schedule (3.9 - the current release is 4.4).
I have the impression that it's not a good idea for a public domain software to
require the latest release of PL/1.
@D.: as I understand your post, you will support older compilers, but the
newer compiler will be required for the PL/1 glue code ... and that would not be
necessary with the C glue code solution.
Am 26.02.2014 19:03, schrieb Bernd Oppolzer:
> Hi D.,
> just interested:
> how will the PL/1 interface to the C package be presented to the users?
> As source code, or precompiled?
> I've had no time so far to look at the distribution that Z.A.
> on his website, if it is source code that still has to be compiled on
> or any other format. If it is C source code - and the COBOL interface
> maybe COBOL source code - then you should also distribute your PL/1
> solution as source code.
> But in this case, you should IMO not require a current release. That's
> I would suggest a C glue function which builds a PL/1 compatible
> that can be handled by very old PL/1 compilers, too.
> When you do this, you don't even need to distribute PL/1 source code,
> nor executables. Only some C glue code, and a description, how to use
> this modified interface to the original C package from some "vintage"
> Kind regards