Suppressing Print Output

[Guest.Visitor]

Is there a way to override a printer file to prevent the print output from being generated (similar to INHWRT on a database file)? I have a situation where I call an RPG program many times from within the same batch job. Each call to the RPG program results in a spooled file. This past weekend I found out the maximum number of spooled files per job is 9999 before the job halts! Short of modifying the called program, is there another way to suppress print file output? Thanks.

[Guest.Visitor]

You could condition the file with an external indicator (U1 - U8). Dave

[D.Handy]

Joe, <font color=blue>Short of modifying the called program, is there another way to suppress print file output?</font> Without modifying the called program, the only thing I can think of would be to use OVRDBF to override the print file to a database file (likely in QTEMP). A common misconception is that OVRDBF is only for overriding DB file attributes. It actually stands for Override with Data Base File. Thus is can override a PRTF to a DB file or whatever. Lots of possibilities here, if you think about it. Other OVRxxx commands are similar. You will want to create the PF first, maybe something like this: <pre> CRTPF QTEMP/NULLPRTF RCDLEN(132) OVRDBF printfile QTEMP/NULLPRTF LVLCHK(*NO) INHWRT(*YES) run application program(s) DLTF QTEMP/NULLPRTF </pre> Doug

[Guest.Visitor]

That would work, but I'd have to modify the called program for that, no? Wouldn't I need to condition each write to the print file? Thanks.

[Guest.Visitor]

It sounds like that will work - I'll give it a try. Thanks Doug.

[Guest.Visitor]

No, just the print file itself. This is done on the "F" specs. The setting of external switches can be done in CL using the CHGJOB command and the SWS parameter. Dave

[Guest.Visitor]

The suggestion to use OVRDBF sounded promising, but I haven't gotten it to work. I received the message: Message ID: CPF5152 Severity : 50 Message : Record format HEADER not in member NULLPRTF. Cause : The record format name, HEADER, that was specified on the get interface is not in member NULLPRTF file NULLPRTF in library QTEMP. Recovery : Specify the name of a record format that is used by member NULLPRTF and try your request again. My print file is externally described, with three formats: HEADER, DETAIL and EOJ. So it appears the file I'm overriding to (NULLPRTF) needs to match the format(s) of the file I'm overriding.

[Guest.Visitor]

Thanks Dave. I'll try your suggestion.

[Guest.Visitor]

In the 400, as far as I know, there is no equivalent to //SYSOUT DD DUMMY but many times I've had to create a work-around. bobh

[J.Pluta]

My print file is externally described, with three formats: HEADER, DETAIL and EOJ. So it appears the file I'm overriding to (NULLPRTF) needs to match the format(s) of the file I'm overriding. You are correct. You might try doing an OVRDBF LVLCHK(*NO), although I think it's still going to look for the three record formats. If that's the case, I think you have to create three physicals (each one with a format matching one of the record formats of your print file) and then a logical over those three physicals. I think that will work. There are probably other somewhat more elegant solutions, but that should work for a start. <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit

[D.Handy]

Joe, <font color=blue>The suggestion to use OVRDBF sounded promising, but I haven't gotten it to work. </font> Hmm. It's been a long time since I had to use it. Prior to the availability of so many API's, it was one technique for converting system commands with *PRINT but no *OUTFILE support to pseudo-outfiles. Now I prefer to use APIs. I ran a simple test against QPRTLIBL prtf and the DSPLIBL *PRINT command prior to my original post, and it ran fine. Even the INHWRT(*YES) kept records from being added (and without it records were added). Using DSPFD QPRTLIBL it shows there are four record formats in the file (unlike QSYSPRT which has just one). Yet it won't list the data on the record formats. Trying to do so results in CPF3053 saying rcdfmt info is not available because the prtf "was created without the where used section". Sorry, I *thought* this would work for you. Maybe it has to do with the prtf device type? The QPRTLIBL example is *SCS; is yours *IPDS or *AFPDS? I could see why (perhaps) *SCS might be the only type supported. If this technique won't work, then AFAIK you'll need to change the program source. As mentioned elsewhere, it is not necessary to condition each output, just the F-spec itself. The idea of a multi-format LF over three physicals with the proper format names may work too, but sounds like too much of a Rube Goldberg operation for my taste. Then you'd also need to put a format selector program on the LF to tell it which physical file should receive the record just so the INHWRT could suppress it. Unless the INHWRT kept the LF from needing the format selector program. (Haven't tried it.) Sorry for the bum lead. FWIW, it *does* work in some cases. <g> Doug

[Guest.Visitor]

My printer device is *SCS as well, so I'm mystified (nothing new!). I tried your example and it worked exactly as you said. I guess I'm going to have to roll my sleeves up, take my feet off my desk and modify a bit of code. Thanks for your time.