Re: explicit close

[Jim Langston <jlangston@xxxxxxxxxxxxxxxx>]

In a library I had built in a different language on a different platform the 
program never had to
do a call to open the file, they would just call the procedures themselves.  
The procedures would
"look" to see if the file was open, if it wasn't it would open the file.  And 
then do it's thing and
return.

At the end of every program there would be a call to cleanup the open files.  
The cleanup would
go through the open files and close them all.  I remember I had built a public 
array to contain the
names of the open files.  There was another procedure that was actually called 
when any file was
opened that would add the name of the file to the bottom of the array and open 
the file.  The close
procedure the would simply do a for...next loop and close each of the open 
files until it got to a
blank entry, at which point it knew there were no more files open.  (Or perhaps 
I had it go though
the entire array, I don't quite remember).

This library was a convoluted thing with functions that called functions that 
called functions.

But, it made programming so fast.  I could whip out a program in nothing flat 
with a few lines of
code that would include my standard user interfaces, all the known files and 
everything.

Something that would take 200+ lines of code to do from scratch in a program 
would take maybe
5 lines.  I remember one in question.  Something like:

#include STDCALLS.INC
#include PUBLIC.INC

     ChgCust(NULL, UserSecurityLevel)

     Cleanup()

or the such.  I don't remember the exact format of the language (clipper, 
compiled dBase) but that
is close enough.

The best thing about the whole scheme is once I decided to change anything I 
would do it in the library
and be done with it, never have to change my programs at all.  Even though 30 
programs may call up
the Change Customer screen, I only had to change it once and everything was 
automatically changed.

In this language you did not have to recompile each program when you recompiled 
the library (directory
in AS/400 terms).  That made it a bit easier.  I only had to recompile my 
programs when I changed my
public variables or standard call headers.

Regards,

Jim Langston

Buck Calabro wrote:

> John Taylor wrote:
>
> >Each SrvPgm contains an initialization
> >and a clean-up procedure. The file
> >open logic is contained in the initialization
> >procedure, and the close logic is in the
> >clean-up procedure. Both are exported,
> >though rarely used by the caller.
>
> It's an interesting question:  Do we have getCustName do the open (in case
> the caller "forgot") or do we return a "not open" error and have the caller
> perform the proper initialisation?  I do the latter but I see the wisdom in
> the former, in which case I would indeed have getCustName call the public
> fileOpen procedure.
>
> >How the resources are closed depends
> >upon the type of caller. If the caller
> >is designed to run in a named or *NEW
> >activation group, then I rely upon the
> >destruction of the activation group to
> >close the resources. However, if the
> >caller runs in the *DFT ag, or QILE,
> >then I handle resource clean up
> >within the program itself.
>
> Sadly, this is a level of sophistication that many shops aren't ready for.
> It seems pretty straightforward once you've done an application this way,
> but that first step is a doosy!  John, what sort of programmers are in your
> shop?  We have a broad mix of mostly inexperienced folks peppered with
> S/36ers and a handful of S/38 - AS/400 folks.  I find that beginners are OK
> with explicit closes but the whole activation group thing gets by them.  I'm
> more than happy just to get service programs in production!
>
> Buck Calabro
> Aptis; Albany, NY
> "We are what we repeatedly do.
>  Excellence, then, is not an act, but a habit." --Aristotle
>
> Billing Concepts Corp., a NASDAQ Listed Company, Symbol: BILL
> +---
> | 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
> +---

+---
| 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
+---