×
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.
Hi David,
On 9/8/2010 8:46 AM, David FOXWELL wrote:
We have converted a number of OPM that were needed by an application
that runs in a named ACTGRP. Obviously, we have recompiled with
ACTGRP(*CALLER).
I don't understand what you mean. You say "named ACTGRP", then
immediately say "obviously, ACTGRP(*CALLER)". Huh? How is this
obvious? Is it a named actgrp, or is it *caller?! Or is it *CALLER
and being called from a named actgrp?
If I understand correctly, we can expect that unpredictable results
may occur in the applications where previously the programs were
OPM?
No, I don't agree with this at all.
If (?!) your programs are indeed running in a named actgrp, then they
are ILE programs and will behave like ILE programs.
If your programs are running in OPM compatibility mode, i.e.
DFTACTGRP(*YES), then they should behave like OPM programs.
If your programs are compiled with DFTACTGRP(*NO) and ACTGRP(*CALLER)
and are called from the default activation group, you won't be able to
remove them from memory without ending the job -- but they'll still work
fine.
All of these are completely predictable. None of them are
"unpredictable results"
The only time you're likely to have unpredictable results is if you
create a *SRVPGM with ACTGRP(*CALLER), call it from the default
activation group, and then run RCLRSC. At that point, the results will
be somewhat unpredictable... but still predictable to an extent: you
won't be able to read/write your files, and the *SRVPGM will ultimately
crash with a weird error of some sort. The only unpredictable bit is
the error you'll receive. It might be a memory error, or it might be
something else... it'll be ugly.
As an Amazon Associate we earn from qualifying purchases.