Cpe3452

[GLS400]

Hi All:

I'm using a customized version of Scott Klement's send email programs to send messages/attachments via email.
It has been working great for at lease 5 years.

I just got a request to process a file of > 110 records where each record will generate an email.

While in test my email program blows up on the second running of the group of 110 with CPE3452.

                                                                              
Message ID . . . . . . :   CPE3452       Severity . . . . . . . :   10        
Message type . . . . . :   Escape                                             
Date sent  . . . . . . :   04/22/15      Time sent  . . . . . . :   14:52:19  
                                                                              
Message . . . . :   Too many open files for this process.                     
Cause . . . . . :   An attempt was made to open more files than allowed by the
  value of OPEN_MAX.  The value of OPEN_MAX can be retrieved using the        
  sysconf() function. 

If I sign off and back on i can run the 110 thru but it blows up on the second run (probably around the 200th email).

I can't determine how to view or set the OPEN_MAX value.
I can't even determine what files are open (they are in the IFS).

IBM's manual has "pseudo code" but that seems to be written in Java.

#include <stdio.h>
#include <unistd.h>
#include <errno.h>

main() {
  long result;

  errno = 0;
  puts("examining OPEN_MAX limit");
  if ((result = sysconf(_SC_OPEN_MAX)) == -1)
    if (errno == 0)
      puts("OPEN_MAX is not supported.");
    else perror("sysconf() error");
  else
    printf("OPEN_MAX is %ld\n", result);
}

[B]Output:[/B]
examining OPEN_MAX limit
OPEN_MAX is 200

Any suggestions as to a starting point would be appreciated. I'm at V6R1.

Thanks in advance
GLS

[john.sev99]

Re: Cpe3452

To me, the issue isn't the OPEN_MAX value, rather it appears your process isn't closing the files once it's finished with them. That's evident if things work after you sign off/on again. I'd revisit your code and ensure the close() function is closing each file correctly.

[GLS400]

Re: Cpe3452

Hi John:
I agree the close function was not operating correctly and I have since corrected that.

I guess my point was why should i need to write a program (much less a java program) to view/change something that should be a system value?
Obviously i did not state that in my origional post

GLS

[Scott Klement]

Re: Cpe3452

I agree the close function was not operating correctly and I have since corrected that.

This was the problem. By default, the system allows you to have 200 descriptors (which are often referred to as 'files', but technically can be sockets, pipes or files) open at once. So if you aren't closing things, they stay open and eventually you hit that 200 maximum. If your program is working correctly, I can't see why you'd ever need more than 5-10 open at once (at the most!)

I guess my point was why should i need to write a program (much less a java program) to view/change something that should be a system value?
Obviously i did not state that in my origional post

The code you posted is C code (not Java). I don't see why you need to view/change this value, and therefore don't understand why you're asking this question?

[tomliotta]

Re: Cpe3452

I guess my point was why should i need to write a program (much less a java program) to view/change something that should be a system value?

You can use RPG if you wish. The IBM example is C, which would generally be the "standard" language for this kind of stuff. It's not a 'system value' because it's not a "system" value. That is, it's something that was kind of inherited when Unix features were needed. Also, there are (at least) two different _SC_OPEN_MAX values. One is intended for QShell, and the other applies to PASE.

In RPG, the example from IBM might look something like this:

     h dftactgrp( *no )

      * for sysconf()
     d SC_ARG_MAX      c                   0
     d SC_CHILD_MAX    c                   1
     d SC_CLK_TCK      c                   2
     d SC_NGROUPS_MAX...
     d                 c                   3
     d SC_OPEN_MAX     c                   4
     d SC_STREAM_MAX   c                   5
     d SC_TZNAME_MAX   c                   6
     d SC_JOB_CONTROL...
     d                 c                   7
     d SC_SAVED_IDS    c                   8
     d SC_VERSION      c                   9
     d SC_CCSID        c                   10
     d SC_PAGE_SIZE    c                   11
     d SC_PAGESIZE     c                   12

     d result          s             10i 0 inz
     d rc              s             10u 0 inz

     d p1              s             10i 0 inz
     d oMax            s             10u 0 inz

     d errNo@          s               *   inz
     d errNo           s             10i 0 based( errNo@ )

     d sysconf         pr            10i 0 extproc( *CWIDEN : 'sysconf' )
     d  p1                           10i 0 value

     d openMax         pr            10i 0 extproc( *CWIDEN : 'DosSetRelMaxFH' )
     d  p1                           10i 0
     d  p2                           10u 0

     d getErrNo        pr              *   extproc( '__errno' )

      /free
       result = sysconf( SC_OPEN_MAX );
       // Alternative API:
       rc     = openMax( p1 : oMax );

       if ( result = -1 );
          errNo@ = getErrNo ;
          if ( errNo = 0 );
             dsply 'OPEN_MAX is not supported.' ;
          else ;
             dsply 'sysconf() error' ;
          endIf ;
       else ;
          dsply ( 'OPEN_MAX is ' + %char( result ));
          // Alternative value:
          dsply ( 'Also:       ' + %char( oMax   ));
       endIf ;

       *inlr = *on ;
       return ;
      /end-free

The coding is longer in RPG mostly because the IBM C example makes use of a group of #include references. Those could be done similarly for RPG, and some actually exist in QSYSINC. But it's easier here simply to put everything in the source.

I left out the use of puts(), printf() and perror() since they really aren't relevant. (Also, I've never actually needed perror(), so I haven't worked how to handle the stderr part in RPG properly yet.) I also included the use of a different API -- DosSetRelMaxFH() -- to show that it can return the same value. DosSetRelMaxFH() can set a higher or lower value for SC_OPEN_MAX in a job. It seems likely that only certain types of server jobs would ever need more 200 file descriptors to be open at the same time in a program, so the API has only rare usage.

[GLS400]

Re: Cpe3452

Thanks Tom
GLS