RE: Cvt RPG III to RPG IV (ILE Concepts) -- RPG400-L

Hi Frank!

>Yes I have read the ILE Concepts manual.
>I attended an RPG ILE programming course at IBM.

I didn't convey my feelings well enough - I *am* sorry.  I'm trying to find
the places in the ILE Concepts manual that need reinforcement.  Exactly as
you say, reading dry text isn't always readily translatable into real world
working environments.

>Please tell me just where in the manual does
>it illucidate on how to convert OPM systems
>(with SQL) to ILE, and Oh 'by the way' watch
>out for these points.

It doesn't, and it can't.  There are far too many different programming
methodologies for IBM to write a blanket HOWTO.  But, there are certainly
places in the manual that can use some help!

>As new systems are designed from scratch
>it is possible to exploit ILE methodologies,
>but to retrofit these into old OPM programs
>is a hugh effort, and is hardly worth the
>return.

Well, I definitely hear the pain in your voice and I can tell you that ILE
is a learning curve for an old timer like me (1978, System/3).  The good
part is that I can also tell you that I now routinely use ILE in a decidedly
OPM environment without much trouble at all.

>I have not and cannot embrace ILE with my present
>systems.  The structure of the OPM RPG III programs
>is not designed with ILE concepts in mind.

That's probably true for almost all the RPG III code in use today.  There
are a handful of programmers who always wrote modular code, even within the
RPG III restrictions.

>If I am an ILE beginner I will be so for a
>long time, as long as the systems I support
>are not ILE based.

I have some good news; it isn't as hard as it seems at first!

>Even if I design bits and pieces with ILE
>concepts there will always remain a unwieldly
>conglomeration of OPM and ILE.

Well said, and if I may be so bold, I'd like to say that almost every system
I've run across has been an unwieldy conglomeration of every generation of
technologies and coding styles.  Adding ILE *does* add a new set of things
to consider, but for any business accustomed to external files,
understanding that _some of the attributes of the system lie outside the
source code_ should be easy to embrace.

>As for system standards what in ILE Concepts
>mentions these.

No mention.  A system standard depends entirely on your system.  Standards
that work well here may be impossible for your business to implement, and
vice versa.

>Does that mean that RPG shops will end
>up with constantly reinvented bits of
>code that almost do the same thing.


No different from today's situation.  How many people on mailing lists ask
for code samples?

>Oh by the way I would appreciate you shedding
>light on my misunderstandings, it is why I
>posted in the first place.

I am sorry that I came across so arrogantly.  I am not what anybody would
term an expert; rather I am trying desperately to teach people here how to
use RPG IV and ILE.  I am selfishly using your learning experience to help
here.  In return for hearing your experiences, I would like to create an
addendum if you will, to the ILE Concepts manual that would help beginners
(here and on the list.)

>RCLRSC is doing funny things, particularly
>if I do RCLRSC(*CALLER).  When I read the
>manual I get the impression that RCLRSC
>is basically obsolete and for RPGIV pgms
>only works in DFTACTGRP and if invoked
>from the top program in the call stack,
>but what is the top program.  I have a menu
>system that is OPM based and is usually the
>top non-system program in the call stack.

The first question to ask about this is: What funny things?  The next is:
Why use RCLRSC?  I'm looking for a bit of detail on the environment you're
in.  Regarding the manual, page 96 is reasonably clear about RCLRSC and
DFTACTGRP(*YES) - it works the same as on OPM programs.  Are you certain
that the programs trying to be reclaimed are in DFTACTGRP(*YES)?  Or perhaps
there are overrides that change the scoping to *JOB?

>I have to be really careful with SQL
>programs CRTSQLRPGI.  CLOSQLCSR( *ENDACTGRP)
>is the default whereas with CRTSQLRPG
>CLOSQLCSR( *ENDPGM ). Cursors are staying open
>when I expect them to be closed.

The default activation group never ends unless the job does.  This is a
typical misunderstanding that the ILE concepts book needs to hammer on.

>When the SQL cursors remain open and
>the file was locked with ALCOBJ
>occasionally the lock REMAINS even
>when the user has exited the program
>completely.

This is normal behaviour for ALCOBJ.  The lock lives for the duration of the
job unless you issue DLCOBJ.

>OVRDBF's can stop functioning, all it
>takes is for a program to be compiled
>into some other ACTGRP, but usually
>this is quickly visible in the call stack.

This is very true and is the major reason activation groups exist.  But you
should not be seeing this if all your programs run DFTACTGRP(*YES).

>[regarding activation groups] If one is
>not very careful with the system design
>and system standards one is going to have
>problems.  These problems are going to be
>manifest as application errors, but are
>really system issues and it will not be
>easily fixed by correcting a bit of coding.

OK.  Two things here.  The first is that any business without careful design
and standards is going to have problems.  We're just used to them, so they
don't seem so nasty.  Introduce a brand new programmer to a typical OPM
system and watch them curse until they work out all the kinks.  The second
is that the ILE problems are absolutely not system errors; they are, in fact
coding errors despite the fact that the activation group strategy is not
visible in the source code!

As I mentioned in the 'Activation groups for beginners' thread, programs
that run in the same AG need to be designed to share resources.  The thing
is that ILE is the runtime environment, but the source code is not.  This
isn't coming out as clearly as I would like.  Let me try an example that
everybody is familiar with: External printer files.  Stuff like page size,
form type, output queue and so forth are all attributes of the object, but
none of them are in the source code.  You set these attributes at compile
time.  When you write your DDS and RPG, you make implicit decisions based on
these 'invisible' attributes, and the source code indirectly reflects those
decisions.  So it is with activation groups.  You decide on a strategy, then
write your code to suit.

>I am in a Catch-22 here.  What is the system
>stardard I need to adopt, I wont know until I try
>something then changing the system standards
>can mean a lot of backtracking.

Not necessarily.  Knowing a bit more about your environment would help, but
do remember that the full power of ILE (especially multiple named activation
groups) is really only required for a very few applications.  The full blast
of flexibility does add *potential* complexity, but is it not necessary to
go whole hog in order to use ILE to your advantage.

Think about your OPM system today.  You're using only a single activation
group.  Does that need to change?  Like all programming, the answers to the
questions aren't absolute - they work better or worse for you than for me.
The best answer depends on your circumstances.
  --buck