Re: Activation Groups & File Overrides

I don't think you are going to be able to get around having to call some
subroutine to close the file when you are done.  When you do I/O
yourself, like you are basically doing by using a subroutine for file I/O,
you are constraigned by the basic file operations, open the file, read
or write records, close the file.

How you decide to deal with closing the file is up to you, but you should
think about what would make it easiest in the long run.  You can either
call the same subroutine with some flag set stating what you want to do
to the file (open, read, write, update or close) or break them into
separate subroutines.  I have done it both ways in the past, for different
circumstances (although not in RPG).

There are advantages to both ways, in one subroutine, everything is in
the same spot and you only have to find the subroutine once to modify
it.  But, it can become quite huge and complex, so you'll need to break
it into separate subroutines internally anyway.  With multiple subroutines
you have to check for changes in each one separately.

Something else you may need to take into consideration, though, what
if two separate programs are both calling MOD1 (assuming MOD1
reads one particular file).  If one of the programs calls MOD1 to close
the file, the other program will bomb out.  How this is handled in OOPs
a lot of times is an open counter.  OpenCounter starts out 0, the first
program calls MOD1, the file is opened and OpenCounter becomes 1.
The second program calls MOD1 to open the file, since OpenCounter
is not 0, it doesn't attempt to open the file but return success and increase
OpenCounter to 2.  Now program1 finishes, and calls MOD1 to close
the file, MOD1 decreases OpenCounter to 1, see's it's not 0, returns
success and leaves the file open.  Program2 then calls MOD1 to close
the file, OpenCounter is decreased to 0, and since it's 0 the file is then
closed.

Just my 2 cents worth.

Regards,

Jim Langston


Buck Calabro wrote:

> Jon Erickson wrote:
>
> > I'm attempting to separate a common subroutine into its own module, (MOD1)
> > to be bound and callable from other programs/modules.
> >
> > The Module opens File1 for input.  I'd like to be able to call this module
> > repeatably without the file initialization overhead, yet not have to call
> > the module an additional time just to seton LR to close the file.
> >
> > Any insight appreciated..
>
> Is there a specific reason you decided against the extra call to close the
> file?  It seems to me that if the decision to close the file is made by
> MOD1's caller(s) then the caller(s) will need to know internal details of
> how MOD1 works (did MOD1 open the file successfully?)
>
> Moving closer to Utopia, MOD1 should have at least 3 procedures that are
> Public: Open, OperateOnFILE1Data, Close.  That way you can bundle the data
> and the code needed to manipulate it all in one place.  The ideal
> environment would have a separate procedure for each operation you need
> performed on FILE1's data: Read, Write, Update, Position, etc. instead of a
> global OperateOnFILE1Data.  This way, each procedure does one thing and one
> thing well.
>
> Not all of these procedures need to be public: if you need to total up the
> A/R for an account, you may have a public GetTotalAR(CustomerID: ARTotal)
> that calls the internal Read procedure.  This way you can separate the
> actual I/O from the processing.  If you decide to use ODBC or SQL tomorrow,
> you just change the I/O procedure and the rest of MOD1 is ready "as-is."
>
> That's my insight anyway.  And it's worth every penny you paid for it!  :-)
>
> Buck Calabro
> Aptis, Albany, NY
> +---

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