ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Problem with full OUTFILE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with full OUTFILE

    Hello, I need an advise what to do when outfile of DSPPGMREF command (for *all pgms in *libl) is getting full.
    I run some script in CL and save results to outfile QTEMP/QADSPPGM, but there are more than 9999 records and processing stops with MSGW waiting for response.
    Is there any way to pass through this? Something like parameter that creates outfile in size more than 9999 or automatic answer to message wait or automatic extend the outfile size?

    Thanks for help.

  • #2
    The standard defaults when many files are created is 10000 records with an additional 3 extents of 1000 records each.
    When an OS command creates and output file, it is created using a model file. For the DSPPGMREF command, the model file is QADSPPGM. If you issue a DSPFD against this, you will no doubt see the standard file creation values.
    You can change this using the CHGPF command to increase any of these values. Note though that an OS upgrade for instance will reset this back to the default values. You could also issue the CHGPF command in your CL program against the file created in QTEMP.

    Comment


    • #3
      One other solution would be to add a system reply list entry (ADDRPYLE SEQNBR(x) MSGID(CPFxxxx) RPY(I)) and change your job to first look to the system reply list to answer the file full message (CHGJOB INQMSGRPY(*SYSRPYL)).

      Comment


      • #4
        Use CRTDUPOBJ against QSYS/QADSPPGM to create a new file in whatever library you need. Use CHGPF to set the file attributes to be whatever you need. Then you can run DSPPGMREF using your new file as the OUTFILE(). That's perhaps how all "model" files should be used. If you allow DSPPGMREF to create the file, you'll have to contend with the attributes that are assigned by default.

        If at all possible, avoid making changes to any "model" file in QSYS. As unlikely as it may be, some new process (or one that's been around for decades) might expect the defaults.
        Tom

        There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

        Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

        Comment


        • #5
          Thanks for suggestions.
          When I discovered I dont have access to reply lists commands, I did similar thing to what tomliotta said. Just changed SIZE of QTEMP/QADSPPGM to *NOMAX and now it works great.
          I've also tried to use SNDRPY command wit RCVMSG to receive message from qsysopr queue but it does not affect messages ith *INQ type (like Member is full).

          Comment


          • #6
            Michael2442 wrote: "I've also tried to use SNDRPY command wit RCVMSG to receive message from qsysopr queue but it does not affect messages ith *INQ type (like Member is full)."

            Not sure how you were trying this, but this technique certainly works. Are you sure you had the right message key?

            Cheers,

            Emmanuel

            Comment

            Working...
            X