RE: Sys/36 re-engineering.

["Richard B Baird" <rbaird@xxxxxxxxxxxxxxxxxxxxx>]

I would be very careful with any tool that converts OCL to CL.  It's been
years since I looked at it, but back then, the target/400 tool made a mess
of that conversion.   Maybe it has improved since, but I have my doubts.

It would generate sometimes as many as 20 CL statements for each OCL
'equivelent', and it didn't differenciate between single and repeated
lines, such as a group of // if active- statements.

a simple 10-20 line OCL procedure could generate a 400 line CL monstrosity,
that was very difficult to decifer.

Thier implementation of 'if active' btw, didn't even work.  it tried to
lock the object exclusively, and monitor for the 'can't do it' message,
then, regardless, unlocked the object.  problem is, program objects aren't
locked when they run - only a copy of the program is used and locked, not
the original.  so, it generated 10 lines of CL, that didn't even do what it
was supposed to do.

IMO, there just is no substitute to looking at the 'intent' of the OCL, and
re-engineering it to as400 techniques.  many many OCL statements have no 1
to 1 as/400 equivelents, and many techniques standard to the 34/36 are
non-standard and poorly implemented on the 400.   (delete, bldfile,
bldindex,
#gsort, if active, if dataf1, etc.)

------original message------
From: Jamie Coles <jcoles@origsoft.com>

<snip>
> ...RPG400 and create DDS specs and convert OCL to CL.
<snip>