RE: Procedures are FUN!

Joe,

Can all the files be put into the module with the procedure?  This way, only
the procedure would need to open them and it could use %open to determine if
it was necessary.

Also, if a subprocedure will be used in more than one place it really should
be put into a service program.  This is something I believe you will want to
start doing from the beginning as it simplifies maintenance a great deal.

Scott Mildenberger

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Monday, October 14, 2002 1:10 PM
> To: rpg400-l@midrange.com
> Subject: RE: Procedures are FUN!
>
>
> Okay, now less than fun.
>
> I know that this isn't exactly cricket, but I tried to do
> something "clever"
> and got burned.
>
> In order to allow a gradual move from a called subprogram to
> a procedure, I
> thought I'd do the following:
>
> 1. Put all the primary code in a procedure
> 2. Export the procedure
> 3. In the subprogram mainline, simply put a call to the procedure
>
> This way, other modules could either call the procedure
> directly, or call
> the subprogram passing in the parameters.  I'd be able to
> wean my programs
> off of the subprogram call and onto the procedure one at a time.  This
> seemed like a good idea.
>
> Until I did this on a program with a file.  It seems that no
> combination of
> things I tried will allow me to intermix calls to a procedure
> and calls to
> the mainline.  I started out by getting "File already open or
> in error"
> (CPF4132) in the *INIT of the subprogram.  Next, I tried
> making the files
> USROPN, and opening them once in the subprocedure based on a static
> variable.  Still errors in the subprogram call.  I finally
> went so far as to
> check to see if the file was open using the %open BIF, and then if not
> attempting to open the file, but when I come through the
> mainline, I get
> CPF4132.
>
> Evidently, there is some mismatch between the *INIT and the
> procedure.  I'll
> just break the code into a callable subprogram which in turn calls the
> module, but I just thought I'd share this little bit of information.