Re: [MI400] porting OS/400 compiler functionality to Windows...

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]


Hello NjÕl,

You wrote:
>I *thought* that CPF was written in MI, and that IBM rewrote most of
>CPF (~75%) when they made it OS/400.

If I recall correctly:

S/38 - CPF was written (mostly) in PL/MI.  MC was written in PL/MP.

CISC - XPF was written (mostly) in PL/MI.  xLIC was written in PL/MP.

RISC - XPF is written (mostly) in PL/MI.  SLIC is written in C++.

PL/MI and PL/MP are based on IBM's internal compilers which are all
deriviatives of PL/X which conceptually is a 'systems' version of PL/1.
PL/MI is like PL/1 with the ability to embed MI instructions.  A large
part of PL/MI coding involves finding the right macro and invoking it.
Note that these are real macros that GENERATE code as opposed to C macros
which are a trivial code replacement function.  IBM have macros to
generate data structures for internal control blocks, macros to add this,
remove that, call something else, macros that monitor exceptions, etc.

LPPs are mostly written in PL/MI or C with a few using "odd" languages
such as Pascal or Modula-2.  There were a few using COBOL and almost none
using RPG (there are certainly no IBM RPG LPPs now).  PL/MI is used for
existing products.  C or C++ is used for new products.

Rochester development is not done on AS/400 systems.  I think that is the
main reason AS/400 programming tools suffer a lack of focus (unless you
think using an unreliable PC operating system to write AS/400 code is an
improvement).  If Rochester programmers had to use SEU, SDA, etc. we would
have seen much more improvement in those tools.

The PL/xx compilers run on VM and generate an MI program template which is
sent to the an AS/400 via SNADS and received as a network file.  IBM have
tools that turn that template into a program object.  They also have tools
to block and unblock the translator, change state and domain, and all the
other good things necessary to build products.

The same process occurs for all AS/400 objects.  The source was stored as
parts on VM using a tool called IDSS (on which ADM appears to be based)
which was very S/38-like in its behaviour.  Development was done using
Xedit or dragged to AIX and edited there.   Program source was compiled on
VM and the template sent to an AS/400 for program creation and testing.
Other source such as commands, CL source,  DDS source, etc. was sent to an
AS/400 as a network job stream.

The C and C++ stuff is done on AIX workstations and I presume generates a
w-code template that complies with the Common Use Back End (CUBE)
specifications.  That CUBE template is sent to the AS/400 for final
compilation just like the various VisualAge cross-compilers do.

Needless to say there is a formal development process built over these
functions using Design Change Requests, Problem Tracking Reports,
inspections, testing, etc.

Given that IBM has slowly been removing VM from its networks over the past
few years I suspect that using VM for development has ceased and it is all
now based around AIX workstations and the Andrew File System with a Unix
source code control system generating the job streams.  Somehow I think
that AS/400 objects are still built the same way using job streams but
that the programmer tools have changed.  We'll only know if a current
developer from IBM feels like explaining the process.  I've been away too
long.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------