×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Roger Harman wrote:
Just wondering what ramifications there are or stumbling blocks people
have encountered in switching from compiling CL programs from OPM (CLP)
to ILE (CLLE).
Depends. If you use DFTACTGRP(*YES) (which is the default on the
CRTBNDCL command, as well as PDM opt 14) then there's no run-time
problems that I'm aware of.
The only stumbling blocks I've run into:
a) RTVCLSRC no longer works.
b) STRISDB no longer works (no big loss!! Use STRDBG, System Debugger,
or WDSC debugger -- all of them are better anyway.)
c) To find out the source file/member the program was compiled from, you
have to use DSPPGM and drill down into the module details.
If you use DFTACTGRP(*NO) then the CL program behaves like an ILE
program instead of being an OPM-lookalike. This can be problematic in
some cases.
a) Program is not deactivated until the actgrp ends (though, in CL
that's hard to even detect.)
b) Override scopes might have to change.
c) Open scope on OPNQRYF or OPNDBF might have to change.
d) Commitment definitions might have to change.
e) RCLRSC might have to be omitted or removed differently depending on
the other programs your CL calls, and how they work.
Is it worth the effort? Problems in the transition where there is a mix
of OPM CL's & RPG's in the job stream?
That's the tricky part, isn't it? There's really no incentive to
upgrade to ILE CL unless you want to use ILE features. It has two
commands that OPM did not... CALLPRC and COPYRIGHT. Not really a big deal!
But, with DFTACTGRP(*YES), there's really no compatibility issues. The
issues come with ILE functionality...
midrange.com
