• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Much Ado About an Override

    March 2, 2005 Ted Holt


    Just when I think I’ve seen it all, along comes something unexpected. A dedicated reader of this column, one of the several Davids who writes me regularly, recently sent me an email with a line of CL code and the question, “Why does this work?”

    This is the CL command:

    OVRDBF FILE(REPORT) TOFILE(QSYSPRT)
    

    If nothing appears out of kilter, then take a look at the following RPG file specs:

    Fqsysprt   o    f  132        printer oflind(*inof)
    Freport    o    f  132        printer oflind(*inov)
    

    Or, if you prefer, the COBOL equivalent from the environment division:

    Select print1 assign to printer-qsysprt.
    Select print2 assign to printer-report.
    

    That’s right. REPORT and QSYSPRT are printer files, but the command is Override with Database File.

    Today is as good as any day to take a closer look at overrides. After all, judging from some of the code I’ve had to work on, the override commands seem to be among the few that some programmers seem to know.

    When the operating system is called on to run a program, it has to go through certain preliminary steps, one of which is resolving all file references. If there are overrides, the system honors those, but let’s forget about overrides for the moment. In this example, the system looks for files REPORT and QSYSPRT. If there is a file named REPORT, the program attempts to allocate it to the program. The strange thing is that REPORT does not have to be a printer file. The same is true for QSYSPRT, of course.

    If you’re interested, take it for a test drive. Flesh out the RPG or COBOL program and compile it:

    Fqsysprt   o    f  132        printer oflind(*inof)
    Freport    o    f  132        printer oflind(*inov)
    C                   eval      *inlr = *on
    C                   except
    Oqsysprt   e                        1
    O                                              'qsysprt test'
    Oreport    e                        1
    O                                              'report test'
    

    Identification division.
    Program-ID.    Prt002A.
    
    Environment division.
    Configuration section.
    Input-output section.
    File-control.
        Select print1 assign to printer-qsysprt.
        Select print2 assign to printer-report.
    
    Data division.
    File section.
    FD  Print1.
    01  Print1-rec.
        05  Msg1  pic x(132).
    FD  Print2.
    01  Print2-rec.
        05  Msg2  pic x(132).
    
    Procedure division.
    Main-paragraph.
        Open output print1 print2.
        Move "Print1" to Msg1.
        Write Print1-rec after 1.
        Move "Print2" to Msg2.
        Write Print2-rec after 1.
        Goback.
    

    Yes, I had to be sure that it worked the same way in COBOL too. I didn’t try C. Does anybody use C for report generation?

    Create a program-described database file in QTEMP:

    CRTPF QTEMP/REPORT RCDLEN(132)
    

    Make sure that QTEMP is higher in the library list than any other library that contains a file called REPORT. Call your program. Take a look at the REPORT file in QTEMP:

    DSPPFM QTEMP/REPORT
    

    You should see the output from your program. The operating system didn’t care that the RPG program thought it was writing to a printer file, but REPORT was a database file instead. Check the output produced by your job. You’ll see a spool file produced by QSYSPRT.


    If one or more overrides are in effect for the file NAME, the operating system will apply them. Clear (or delete) file QTEMP/REPORT, issue the OVRDBF command shown earlier, and call your program again. This time you’ll find two spool files, one for REPORT and one for QSYSPRT. The system used the database override to direct printer output to a printer file.

    From these two test runs, it is evident that OS/400 allows device independence where it makes sense. That is, you can override a printer file to a database file (in some circumstances), but you can’t override an input-capable database file to a printer file. And therein lies the answer to David’s question.

    The reason David found this oddity was that he needed to make a change to the override. I forget which parameter he had to change, but it was one of the parameters that are found in the Override with Printer File (OVRPRTF) command, such as COPIES or OUTQ. He replaced the OVRDBF command with an OVRPRTF command and everything was copacetic:

    OVRPRTF FILE(REPORT) TOFILE(QSYSPRT) COPIES(2)
    

    Click here to contact Ted Holt by e-mail.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Racksquared

    It’s time for IBM Power in the Cloud!

    Stop buying hardware and make the move to the cloud. It’s easier and more cost effective than you might think.

    • IBM Power in the Cloud
    • IBM Power Backup Solutions
    • IBM Power High Availability and DR solutions
    • IBM Power Colocation with Management and Monitoring

    Let’s talk about your business needs.

    Call: 855-380-7225
    Email: Sales@racksquared.com

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Linoma Boosts Security and Automation of Data Transfer Tool Core Imaging Targets the Paper Chase at OS/400 Shops

    Leave a Reply Cancel reply

Volume 5, Number 9 -- March 2, 2005
THIS ISSUE
SPONSORED BY:

Advanced Systems Concepts
iTera
WorksRight Software

Table of Contents

  • Embedding SQL in /free
  • Much Ado About an Override
  • Admin Alert: IBM Has Changed the +/- One Release Rule for V5R1 Upgrades

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • IBM Tweaks Some Power Systems Prices Down, Others Up
  • Disaster Recovery: From OS/400 V5R3 To IBM i 7.4 In 36 Hours
  • The Disconnect In Modernization Planning And Execution
  • Superior Support: One Of The Reasons You Pay The Power Systems Premium
  • IBM i PTF Guide, Volume 25, Number 13
  • IBM i Has a Future ‘If Kept Up To Date,’ IDC Says
  • When You Need Us, We Are Ready To Do Grunt Work
  • Generative AI: Coming to an ERP Near You
  • Four Hundred Monitor, March 22
  • IBM i PTF Guide, Volume 25, Number 12

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2023 IT Jungle