RE: cant save v5r1 rpg pgm to *prv release

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Hi Steve!

>But if your product was modular, that is
>each module is self contained, does
>not depend on the other modules ... your
>v8 database module would provide interfaces
>that could be used by a v7 code module.

Right on!  v8 servers provides interfaces to older clients as well as
exposing new interfaces to v8 clients.  The deal here isn't a v8 server
facilitating a v7 client, it's the other way round.  I have v7 servers and a
v8 client.  How can the v7 server know what the v8 client is going to want?
I need to write a pseudo-v7 client that makes a number of calls to existing
v7 functions and compile the information that way, instead of making the
simple, single v8 client call that the v8 code can do.  But what if the v7
database does not store the information I need to get at.  There's simply no
way to write a v7-compliant client.

I suspect the compiler is the same way.  It isn't like an assembler,
grinding out machine code.  It's more like C, calling system runtime
routines.  I'm The Boss in Toronto, and I decide to have the team build a
bif to decode a CSV string.  I set one group working on the runtime API and
another group working on the compiler to change the parsing routine to
recognise the new BIF, extract it's parameters, call that API and handle the
results.  I get two teams working in parallel.

So the implementation of my fictitious parsecsv is that a compile-time
parser creates CALLs to a runtime API, rather than creating machine code
targeted to a particular machine architecture (MI/NMI/RISC/CISC...)  This
way I can write the v5.2 runtime API and add support via PTF to prior
releases if I have to.

Then v5.3 comes along and somebody figures out a way to double the
performance of that BIF API, but it takes a new operation that only v5.3
has.  Now I can't PTF support back, because there's no place to get that
service, that machine operation.  So I can't compile my source code with the
new BIF to *PRV because there isn't a way for the compiler to call an
unavailable API (or even to emit machine code that uses the non-existent
machine operation.)

That's one reason I think the *PRV support simply calls the previous version
compiler.  Another reason is probably the 'if tree' they'd have to build
around every BIF, opcode and function in order to call the proper interface
for the proper target release.  eeeeeeeeeeee.

That's my guess, based on the problems I have supporting multiple releases.
I'd love to see George or Phil do an article on 'Inside The Lab: Anatomy of
a new BIF'.
  --buck