Re: Move S/36 to AS/400

Jeff,

>OCL to CL, yes.  But sorts don't _need_ to be converted to logical
>files.  Sorts work just fine on the AS/400.

Except when they use substitution expressions to dynamically alter
in-line sort specs instead of static statements (either inline or in
another source member).  Unfortunately, almost all of my S/36 sorts
were prefaced by prompt screens allowing the operator to select a sort
sequence and specify multiple record selection criteria.  In my
experience, these did not work just fine with FMTDTA. :(

The simpler the OCL, the easier the conversion. 

But part of the problem is OCL should not just be translated to its CL
equivalence.  You'll end up with something likely to be harder to
maintain than the OCL, and no better performance. 

For example, using library lists can often replace what was
accomplished using substitution expressions in LABEL parameters of
FILE statements.  Converting those to OVRDBF instead would be a mess
compared to using library lists.

It was also common to build and delete files in OCL, which is
relatively resource expensive on the 400 compared to the S/36.

My point is you need to decide what the OCL is trying to do, and
decide how to code that in CL instead of just converting the OCL to CL
equivalence.  You wouldn't want to change a series of DELETEs of
alternate indexes followed by a COPYDATA/DELETE/RENAME and BLDINDEX to
the CL equivalents.  You'd want to just put in a RGZPFM.  (But you'd
also have to watch out for the COPDATA removing logically deleted
records having a code in a certain position, etc.)

Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---