× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I shouldn't step between my betters, especially now that I see from a
different post that Joe and Buck had a different situation in mind than my
post in the "Procedures are FUN!" thread. But the technique I described in
that post may still have relevance.

I had problems when I paid attention to the compiler's warning message and
closed the file because IBM says you shouldn't leave a file open in a NOMAIN
module. According to an IBMer that I heard at COMMON in Minneapolis (sorry I
can't remember who), there is very little performance penalty because the
access path is still open in the activation group--it is only flagged as
closed. I wish I could remember the reason the IBMer gave for saying the
file should be closed, but I can't.

So when I first tried closing files in NOMAIN modules, I discovered that
when I CLOSE the file in the service program and another program lower in
the call stack running in the same activation group also uses that file, it
sees the file as closed, too. We haven't run into any problems with our
early service programs that leave files open. But we started using the
technique I outlined in the thread "Procedures are FUN!" because we can't
see how using it to follow IBM's recommendation can hurt. Here's Buck's
subprocedure modified (with * before each added line) to implement the
technique:

     p getrec          b                   export
     d getrec          pi
*    d CloseSrc        S                 N

      /free
       if not %open(qrpglesrc);
         open qrpglesrc;
*        CloseSrc = *ON;
       endif;

       read src;
*      if CloseSrc;
*        close qrpglesrc;
*      endif;
       return;

      /end-free
     p

It may be that this technique does not fix the exact problem Joe faced
because I haven't designed an application that way. But I have successfully
used it in non-OPM MAIN modules with USROPN files, too. Maybe those with
more programming experience can share some warnings about using this
technique. But we have noticed no penalty for using it in our shop. And it
does shorten the compiler listing on NOMAIN modules.

Wishing I was in Denver, waiting for correction,
Roger Mackie

-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
Sent: Monday, October 14, 2002 14:40
To: rpg400-l@midrange.com
Subject: Subprocedures and files (was: Procedures are FUN!)


>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
-snip-
>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 am clearly not the brightest bulb in the pack, and don't understand the
problem.  Here is code that to me appears to match your scenario.  I get no
errors with it when I call it repeatedly from the command line.  Could you
doctor it up to match your failing scenario so that I could understand the
pitfall you're describing?

     h/copy qrpglesrc,stdhspec
      * dbgview(*list) tgtrls(*current)

     fqrpglesrc if   e             disk    usropn
     f                                     rename(qrpglesrc: src)

     d getrec          pr

      /free
       callp getrec();
       *INLR = *On;
      /end-free

     p getrec          b                   export
     d getrec          pi

      /free
       if not %open(qrpglesrc);
         open qrpglesrc;
       endif;

       read src;
       return;

      /end-free
     p


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.