RE: SQL - File staying locked.

Actually, I just realized that I didn't have to make program A ActGrp(*NEW)
in plan step #1 because if the RPG ILE programs are ActGrp(*CALLER), they
will be in the default activation group.  Therefore, RCLRSC would take care
of these open files as well since they would be in the default activation
group.  A simple test verified this.  It shouldn't hurt to specify
ActGrp(*NEW) though anyway should it?  It could possibly help when we look
at open files through the WRKACTJOB to see the different activiation group.
Then we know we should be looking for an ILE RPG program.  I heard there
might be some performance issues this way but it is not like the programs
are called hundreds of times.  I am hoping the pain you are talking about
by mixing ILE and OPM deals with expecting files to have the previous
overrides, trying to share files, etc.  Our main ActGrp(*NEW) ILE program
is simple (no overrides, etc) so I don't expect to run into any problems.
As cautious as I am and as important as this program is (the EDI receive
job), I don't want to take risks.  So, maybe I should get rid of the
ActGrp(*NEW) and use ActGrp(*CALLER)?
There is not a reason I can't convert the programs to ILE, Joe, but there
are reasons I shouldn't.  I think most, if not all, are due to our
environment.
1. There are dozens of programs called from this program and hundreds of
possible programs called.  A majority of these are dead but we have not
gotten around to cleaning them up.  The WRKACTJOB > 5 > 14 doesn't show the
programs that opened the files.  There are more important projects to deal
with.
2. A majority of the programs were written in RPG III by the AS/SET CASE
tool years ago.  The RPG code that AS/SET generates is at least 3 times the
size and complexity that normal RPG programmers write.  Although the new
AS/SET might support converting to ILE.  I just don't really know AS/SET
very well and I don't have the time right now.  No one is supposed to be
writing with AS/SET anymore but BPCS is still written by AS/SET and EDI was
written years ago with AS/SET (their familiarity at the time) so there is
all this non-BPCS code written by AS/SET.  I think the BPCS goal was to
make their own language so you wouldn't have to specifically be an RPG,
COBOL, whatever programmer.  Nowadays I think it is pretty simple to learn
RPG IV though.  I don't think BPCS has any incentive to drop AS/SET since
it would encourage calling support.  Basically, converting the ASSETIZED
RPG source is like a total rewrite in RPG IV in order to make it easy to
read by programmers.  You also need to make sure that once you change the
generated source, you delete the AS/SET source or your changes will be lost
with the next possible change in AS/SET.  AS/SET even has their own screen
designer like SDA.  No nice CODE Designer we all like.  Ugh!!  I think we
are getting into most of the other midrange lists for this one though so I
will leave it there.
3. Time constraints.  Kind of a result of reason #1.

In a perfect world it would be a piece of cake but the past comes up to
haunt us.
Sound like the perfect spot for a nice quote or a Chinese proverb.  :)

Thanks,
Craig Strong

** Joe wrote:
> From: craigs@xxxxxxxxx
>
> Instead of making sure there were no programs with *endactgrp,
> the plan is:
> 1. Use ActGrp(*NEW) for program A then make sure program B or C is
*CALLER
> if true ILE.  This takes care of files opened by ILE SQL.
> 2. Execute RCLRSC.  This cleans up files opened by OPM SQL.

I don't know for sure, Craig, but I've always been told that mixing OPM and
ILE in this way is guaranteed to cause some pain.  Is there a reason you
can't convert your programs to ILE?

Joe