Understanding where your reports will print can be a real challenge. If you know the rules, you'll be able to follow the trail to the end--even in the S/36 Environment.

Brief: The first half of this article covers basic printing internal rules that apply to all AS/400 applications. You'll learn how printer files and overrides interact to control the characteristics of printed output. You'll also learn how values in your job description, user profile, workstation device description and system values control where your output prints. In the second half of the article, the special considerations for printing in the S/36 Environment are discussed in detail.

It's not surprising that some S/36 programmers have expressed frustration with the "simple" job of producing a report on the AS/400. On the S/36, your RPG program sends your printout to an output file with a device type of PRINTER. If no special printing options are needed, you don't even have to specify a PRINTER statement in your OCL. Although there are many elements involved in actually getting the output printed, programmers hardly ever have to deal with them. On the AS/400, getting a report to print can seem like a trek to the North Pole. There are multiple objects that you must understand to control when and where printed output is produced. In order to print a report, there must be a print file, an output queue, a print writer and, finally, a device description for the physical printer device.

The S/36 Environment (S/36E) is designed to keep differences between the S/36 and the AS/400 to a minimum to ensure easy application migration from the S/36. Therefore, printing in the S/36E attempts to reproduce the effect of OCL running on the S/36. A better understanding of native printer support and the special rules that apply in the S/36E will put you in control of printed output.

As a practical matter, you might not care about S/36E printer internals at all. Generally, internals describe what really happens inside the operating system. Understanding internals can help you to understand why your application software reacts to a combination of system values, overrides and HLL programming the way it does. This understanding makes it possible to use those internal manipulations to your advantage and to get the results you want every time.

In order to really be in control of how your S/36E output prints, it is important to understand how S/36E printer support works. A knowledge of the underlying native AS/400 printer functions is also necessary. The native functions are the tools that IBM's S/36E programmers use to create the special printing conditions in the S/36E. I'll discuss some details that are particularly relevant to understanding how S/36E printer support interacts with native printer support in this article. For an overview of native printer support, refer to "Printing on the AS/400" (MC, December 1991).

NATIVE OVERVIEW

Printer File

Any application that generates printed output must open a printer file. This AS/400 object (type *FILE) contains the set of default attributes used when generating printed output. For example, the default lines and characters per inch are set up by building printer files for each set rather than being defined for the device as they are on the S/36. This means that you could set up printer controls that you use frequently by building printer files for each set rather than overriding them on a program-by-program basis. If you are familiar with style sheets used by many word processing programs, the concept is similar.

The name of the printer file is specified in the program's F-spec. On the S/36, the F-spec (with Device = PRINTER) is the only entry required to define a report, so you never have to deal with the printer file explicitly. The default values on the S/36 are obtained from the configuration for the physical printer used.

On the AS/400, if your program contains an F-spec with a PRINTER device for a file named REPORT, a printer file named REPORT must exist where native data management can find it. If you want your printout to have a page length of 66 lines per page, you would specify this in the printer file. It is not automatically assumed based on the physical printer you are using. Printer files are created with the Create Printer File (CRTPRTF) command and changed with the Change Printer File (CHGPRTF) command. As we'll see later, the S/36E creates "dummy" objects to supply OS/400 with the required elements which are not explicitly defined in S/36 programming.

Printer File Overrides

Once a printer file is created, you can temporarily change the attributes with a printer file override. This is one way AS/400 programmers can avoid creating lots of printer files. By using the Override Printer File (OVRPRTF) command, you can change the attributes of the output to accommodate a variety of forms and printer-specific attributes, without changing the printer file permanently or having multiple printer files for each program or printer on the system. You can simply use QPRINT (or any other file you choose) and change the attributes as necessary for each report. This is similar to the use of PRINTER OCL statements to modify the standard output format on the S/36. Overrides are very powerful on the AS/400. You need to know how they work to understand the native and S/36E support.

Overrides of printer files come in two flavors:

1. The *PRTF override, which overrides any and all printer files regardless of name.

2. An explicitly named override which can be used to override a specific printer file.

In either case, you can override the printer file selected with the attributes of a different printer file or with specifically coded attribute keywords. The scope (or duration) of any override is limited to the program that creates it during the execution of that program. Unless it is explicitly deleted using the Delete Override (DLTOVR) command, it stays in effect for all programs called by the program that issued the OVRPRTF command. The override will be removed automatically when the original program ends.

It is also valid to have different overrides for the same file in different programs at the same time. This can make things pretty confusing. When one program calls another, the overrides of the calling program are imposed on the called program. However, the called program may also override the same printer file. Because the calling program takes precedence, this will not make any difference unless the lower level program changes a different parameter of the printer file. In this case both overrides can be in effect at the same time. The second set of overrides will end when the called program ends.

This is markedly different from the PRINTER OCL statement on the S/36 which allowed only a single level of overrides to the default values. If a procedure changed the characteristics of the printout using PRINTER OCL outside a LOAD/RUN OCL pair, the override would remain in effect until the job step ended. If an INCLUDEd procedure attempted to run a PRINTER OCL statement for the same file, an error would occur.

Since AS/400 overrides can exist in different levels of an application, it's important to understand how they interact. File overrides are merged together when a file is opened, whether by program initiation of an RPG program or by an explicit OPEN operation in COBOL. The overrides are merged for each possible parameter. In the case of conflicts, the highest, or oldest, program wins. This means that if the calling program and the called program conflict, the calling program attributes are used. Although it is possible to change how overrides are merged (for example, by using SECURE(*YES)), we will limit our discussion to the default processing. The hierarchy of called and calling programs is referred to as a program stack. You can observe your program stack by running the Display Job (DSPJOB) command:

DSPJOB OPTION(*PGMSTK)

What you'll see is a list of programs as illustrated in 1. The most recently called program is at the bottom of the program stack.

What you'll see is a list of programs as illustrated in Figure 1. The most recently called program is at the bottom of the program stack.

To illustrate how printer attributes are resolved at the printer file level, consider the following scenario.

PGMA contains the printer override:

 
 OVRPRTF FILE(REPORT) + 
    LPI(6) CPI(15) + 
    PAGESIZE(66) OVRFLW(60) 

PGMA also contains a call to PGMB which contains the printer override:

 
 OVRPRTF FILE(REPORT) + 
     LPI(8) FORMTYPE(ABC) 

The result of these two overrides merged at open time would be:

 
 OVRPRTF FILE(REPORT) + 
    LPI(6) CPI(15) + 
    PAGESIZE(66) OVRFLW(60) + 
    FORMTYPE(ABC) 

PGMB calls an RPG program, PGMC, which contains an F-Spec for REPORT. The output produced will conform to the merged overrides. 2 illustrates how the overrides were merged. The merged override does not apply back to any printed output produced by PGMA; this output will be printed on default forms at 6 LPI and 15 CPI with a page length of 66 and an overflow line of 60.

PGMB calls an RPG program, PGMC, which contains an F-Spec for REPORT. The output produced will conform to the merged overrides. Figure 2 illustrates how the overrides were merged. The merged override does not apply back to any printed output produced by PGMA; this output will be printed on default forms at 6 LPI and 15 CPI with a page length of 66 and an overflow line of 60.

Add Another Factor

An RPG or other HLL program can modify certain printer file attributes. For example, the L-spec in an RPG program can specify the page length and overflow line. In this case, the parameters from the program have less importance than the override (but more than the printer file definition). In the scenario illustrated in 2, adding an L-spec to PGMC has no effect. However, the L-spec entry would be merged with overrides if those particular parameters had not been coded on the OVRPRTF command.

An RPG or other HLL program can modify certain printer file attributes. For example, the L-spec in an RPG program can specify the page length and overflow line. In this case, the parameters from the program have less importance than the override (but more than the printer file definition). In the scenario illustrated in Figure 2, adding an L-spec to PGMC has no effect. However, the L-spec entry would be merged with overrides if those particular parameters had not been coded on the OVRPRTF command.

Although this does not cover every possible case of printer file overrides, it should help you to understand how they work. Later on I'll discuss the special case of S/36E interaction with printer file overrides.

Output Queue Selection

How many times have you said "Where the heck did my output go?" or "Why did it go THERE?!"? I know I did many times when I first moved to the AS/400. All spooled printed output goes to an output queue object (type*OUTQ)-which output queue it goes to is up to you. An output queue is simply a place output goes to wait to be printed; it is not necessarily connected to a physical printer at all. The spool file on the S/36 could be considered as a group of output queues, one for each printer.

When you configure a printer on the AS/400, the system automatically creates an output queue, giving it the same name as the printer. In addition, you can create other output queues with the Create Output Queue (CRTOUTQ) command. For example, programmers produce lots of printed output, most of which does not actually need to be printed. If you assign programmer's output to an output queue that is not attached to any printer, you can review the output before deciding if it should print.

Initial Parameter Values

When you first sign on, there are four places where the system can look to determine which output queue your printed output is assigned to:

1. Your Job Description (JOBD)

2. Your User Profile (USRPRF)

3. Your Workstation Device Descrip-tion (DEVD)-not applicable before V2R1

4. The system value QPRTDEV (system printer)

The JOBD, USRPRF and DEVD each contain two separate values that may affect printer assignment, the output queue (OUTQ) and the printer device (PRTDEV). We'll look at how the assignment may change after sign-on a bit later, but first it is important to clearly understand how the initial values are assigned.

The distinction between the output queue and the printer device is vital to understanding how an actual printer is assigned on the AS/400. These are two separate values which need not be related in any way. Determining which value is actually used will be discussed later.

OS/400 will determine the two values when you sign on and will modify them as needed based on overrides you enter or run from within other jobs. The determination to use one value or the other is only made when you actually generate some type of printed output and it is based on the values at that moment in time.

First I'll show you how the values are determined at job initiation.

OUTQ Value

The output queue parameter is considered resolved if it contains one of the following:

1. *DEV

2. A valid output queue object name

When you sign on, the first object interrogated is your job description (JOBD). If your job description contains a specific output queue name or the special value *DEV in the output queue parameter, no further processing is needed. For example, either of the following statements could be used to set the OUTQ parameter for a job description.

 
 CHGJOBD JOBD(HOFSHA) + 
    OUTQ(PGMRHOLD) 

or

 
 CHGJOBD JOBD(HOFSHA) + 
    OUTQ(*USRPRF) 

The second example does not resolve the OUTQ value directly. Based on the special value *USRPRF, OS/400 examines your user profile in order to resolve a value for OUTQ. (Remember that this is still an initial value and may be affected by changes later on.)

3 shows all the possible alternate paths that can be followed to determine an initial value for the OUTQ parameter. Every time you see a value in a stop sign in the figures, the parameter is resolved and no further processing takes place.

Figure 3 shows all the possible alternate paths that can be followed to determine an initial value for the OUTQ parameter. Every time you see a value in a stop sign in the figures, the parameter is resolved and no further processing takes place.

If the special value *WRKSTN is encountered, then the device description (DEVD) object is checked. The final value which is stored in the OUTQ parameter for later reference is either *DEV or the name of an output queue object.

The longest path required to resolve the OUTQ parameter examines three objects to determine the correct value:

The job description (JOBD) contains the special value *USRPRF which leads to the user profile (USRPRF).

The user profile contains the special value *WRKSTN leading to the device description (DEVD).

The device description must contain one of the two valid values: *DEV or an output queue object name.

PRTDEV Value

The PRTDEV value uses the same type of logic as we saw for OUTQ. When sign-on processing is complete, PRTDEV must contain the name of a DEVD for a printer. When a printer DEVD is defined, an output queue of the same name is automatically created. The PRTDEV value points at the output queue associated with the printer. 4 shows the possible paths this logic may take.

The PRTDEV value uses the same type of logic as we saw for OUTQ. When sign-on processing is complete, PRTDEV must contain the name of a DEVD for a printer. When a printer DEVD is defined, an output queue of the same name is automatically created. The PRTDEV value points at the output queue associated with the printer. Figure 4 shows the possible paths this logic may take.

The PRTDEV parameter in any of the objects interrogated-JOBD, USRPRF or workstation DEVD-may contain the special value *SYSVAL. This special value directs OS/400 to set PRTDEV to the output queue associated with the printer DEVD object specified by system value QPRTDEV, which is the system printer. So for the PRTDEV parameter, the longest possible path at sign-on is:

JOBD contains the special value *USRPRF.

USRPRF contains the special value *WRKSTN.

Workstation DEVD contains the special value *SYSVAL.

Set the parameter to the system value found in QPRTDEV.

The point of the preceding discussion is that the system will derive a value for both OUTQ and PRTDEV and stop after an explicit value can be determined.

Once the job is started, the JOBD, USRPRF, DEVD and system value are not checked again. The job values are stored and can be changed with the Change Job (CHGJOB) command.

Working Together

When you actually generate spooled output on the AS/400, the printer file (including any overrides) tells the system how to format and direct the printed output. The output will be sent to an output queue. Whether or not that output queue is currently attached to a writer for a physical printer device is not a factor.

If the output queue is explicitly defined as a printer file parameter, there is no need to reference the job parameters or the DEV parameter of the printer file (DEV for the printer file is the equivalent of PRTDEV for the job). However, the printer file may contain a special value of *JOB (the default) or *DEV for the OUTQ parameter. In this case, one or both of the job parameters may be needed. This is also the point at which OUTQ and PRTDEV may connect. Up until the point when printed output is actually generated, the values are maintained completely separately.

There are two very important rules for output queue selection:

1. The printer file, with all overrides merged, is checked first. In many cases the result will be that job parameters are not examined at all.

2. The OUTQ parameter has more strength than the PRTDEV(or DEV) parameter for both the printer file and the job.

The end result must be the name of an output queue object. There are only two valid possibilities:

1. An output queue may be named explicitly.

2. The DEVD for a printer may be referenced. In this case, the system will use the output queue created when the printer device description was created.

The determination of the correct output queue begins with the OUTQ parameter of the printer file (including all merged overrides). If an explicit OUTQ object is not coded for the file, one of two things may occur:

1. If the OUTQ parameter contains the special value *DEV, the DEV parameter of the file is checked next. The DEV parameter of the file may contain the name of a printer DEVD object. In this case, the printed output will be sent to the output queue with the same name as the DEVD for the printer. It is important to remember that printed output always goes to an output queue. Actually getting that output printed is a separate function. Again, refer to "Printing on the AS/400" (MC, December 1991) for the relationships between output queues and physical printers.

2. If the OUTQ parameter contains the special value *JOB (the default), then the OUTQ parameter for the job is checked next. This follows the rule that the OUTQ parameter always takes precedence over the PRTDEV or DEV parameter. If the job OUTQ is an output queue object, processing is complete; if it contains the special value *DEV, the DEV parameter of the file is the next item checked. This sequence follows the rule that the file always takes precedence over the job.

5 illustrates the possible paths for determining the output queue. The longest possible path is:

Figure 5 illustrates the possible paths for determining the output queue. The longest possible path is:

File OUTQ value is *JOB; check the job OUTQ value.

Job OUTQ value is *DEV; check the file DEV value.

File DEV value is *JOB; check the job PRTDEV value which must be a DEVD object for a printer. The output will be sent to the output queue associated with that printer.

Just remember, the system looks at the file and its merged attributes for direction. It simply follows the trail until an OUTQ can be determined and stops.

S/36 ENVIRONMENT SUPPORT

Some Basic Rules

The S/36E support ensures that S/36 rules are enforced on the AS/400. All of the printed output is generated through native printer support. The special functions the S/36E provides fall into three major categories:

Configuration: One of the ways that the S/36E accommodates differences between OS/400 and the S/36 is by maintaining a configuration object in #LIBRARY. For example, the AS/400 supports printer and workstation names up to 10 characters in length. S/36 applications expect two-character names. To accommodate the differences, the S/36E maps the native 10-character names to two-character S/36E names in the configuration object. This object also contains printer defaults which the S/36 would specify as part of the configuration of the physical device.

Because native printer file support requires a printer file S/36E creates a printer file in #LIBRARY with the same name as the two-byte S/36 printer device.

Session printer: The S/36 defines a session printer as the printer associated with a workstation. There is a default value established by the workstation configuration which may be changed using FORMS OCL, the PRINT procedure (the procedure interface to FORMS OCL) or the SET procedure. S/36E makes the appropriate changes to the AS/400 job when FORMS OCL or SET is processed.

However, SET changes persist across sign-ons on the S/36. As a result, when a session printer is changed using the SET procedure, the S/36E also changes the default session printer value for the workstation. Prior to V2R1, this value was stored in the S/36E configuration object in #LIBRARY; V2R1M0 and higher releases store this information in the PRTDEV parameter of the native workstation DEVD object. FORMS OCL should be used when temporarily changing the session printer instead of the SET procedure. This will make recovery simpler if the job is canceled for any reason.

Run-Time Processing: In addition to starting the program specified in the LOAD statement, the S/36E RUN statement processor also generates any file overrides that are needed because of OCL statements. However, contrary to popular belief, the S/36E does not turn the PRINTER OCL statement into a OVRPRTF command and run the command. It calls the routines directly through an internal interface. This means that printer overrides generated by the S/36E take the same amount of time as OVRPRTF.

Because a PRINTER statement is not necessary to open a printer file on the S/36, the S/36E always generates a *PRTF override which generically overrides any printer file. Native printing doesn't know anything about the S/36E session default values, so this is where we specify them.

When a PRINTER OCL statement is processed, the printer file parameters are primed with the session default values. Then, they are overlaid with any parameters included in the PRINTER OCL statement. Any parameters set by PRINTER OCL, except CONTINUE-YES, persist only until the end of the job step.

Differences Between Native and S/36E

When you run an application in the S/36E, native printer support does the work; that's why we went through the details of how overrides are merged and output queues are determined under native rules. But, because the S/36 and the native AS/400 have slightly different printer data management rules, the S/36E provides additional support for the S/36 application.

Printer File Substitution: When you migrated to the AS/400 from the S/36, you had no idea that you needed to create printer files on the AS/400 in order to get your applications to work. Well, you don't have to. We'll put the printer files created for each printer device during configuration to work for you now.

When you run an S/36-compatible program under the S/36E, the overrides and program are merged to determine which printer file name to use. The name is passed to the S/36E, and if it is found, great, it's used. If the named printer file is not found, the S/36E looks to see for which printer device the output is destined. The printer file created for that device in #LIBRARY becomes the active printer file, and overrides caused by the program or PRINTER OCL can be applied.

Program Attribute Pro-cessing: On the S/36, the program attributes, such as L-spec entries for page length and overflow line, override the PRINTER OCL statement. This is the opposite of how a printer file override interacts with the program under native rules. For the S/36 compatibility, the S/36E ensures that the program's attributes are not overridden (either by OVRPRTF or by PRINTER OCL). The result is that, under native processing, adding an L-spec to PGMC in 2 has less power than adding the same L-spec to an S/36 program in the S/36E. In this particular case, the printer file parameters which would be affected by the L-spec have been coded in the OVRPRTF for PGMA. If PGMC is a native RPG program, an L-spec will not have any effect on how REPORT prints. For an S/36 program running in the S/36E, adding an L-spec can override entries in PRINTER OCL. In both native and S/36E, the L-spec overrides defaults defined for the printer file object.

Program Attribute Pro-cessing: On the S/36, the program attributes, such as L-spec entries for page length and overflow line, override the PRINTER OCL statement. This is the opposite of how a printer file override interacts with the program under native rules. For the S/36 compatibility, the S/36E ensures that the program's attributes are not overridden (either by OVRPRTF or by PRINTER OCL). The result is that, under native processing, adding an L-spec to PGMC in Figure 2 has less power than adding the same L-spec to an S/36 program in the S/36E. In this particular case, the printer file parameters which would be affected by the L-spec have been coded in the OVRPRTF for PGMA. If PGMC is a native RPG program, an L-spec will not have any effect on how REPORT prints. For an S/36 program running in the S/36E, adding an L-spec can override entries in PRINTER OCL. In both native and S/36E, the L-spec overrides defaults defined for the printer file object.

CONTINUE-YES Processing: By specifying the CONTINUE-YES parameter on the PRINTER OCL statement, printed output generated by successive job steps can be sent to a single spool file. Within this spool file, the attributes of page size, overflow and record length are allowed to change.

Native printer data management has a similar concept, sharing an open printer file within a job. The big difference here is that once the file is opened under native, no attributes are allowed to change.

The S/36E provides special support to change attributes dynamically within a spooled file. This processing is unique to the S/36E

support and has no native equivalent.

SPOOL-NO: Both native and S/36E applications allow SPOOL

(*NO), but the support for this parameter is different. For performance reasons, all print on the AS/400 is buffered before being sent to the printer. This caused some early problems with S/36 applications that wrote checks, used the printer commands to open cash register drawers and the like. The application would send less data than buffer size, and nothing would print/work until the program ended and closed the file. In V2R1, native supports a DFRWRT

(*YES/*NO) parameter to indicate whether print buffering should take place. When SPOOL-NO is specified on the PRINTER OCL statement, the S/36E sets the value to DFRWRT

(*NO) to keep the data from being buffered.

You should also be aware that a print writer cannot be active for the printer you want to use for non-spooled output. Both the print writer and non-spooled printer support lock the printer device. If the print writer has it allocated, the non-spooled support can't get it and vice versa. In order to process PRINTER OCL with SPOOL-NO, you must run the End Writer (ENDWTR) command for the printer you want to use. When your SPOOL-NO processing is complete, run the Start Printer Writer (STRPRTWTR) command.

Combining Native OVRPRTF with S/36 Procedures

While OCL is maintained for S/36 application compatibility, it does not provide all of the functions available on the AS/400. For example, the font values you can specify in the OCL are bound by what can be specified as a one- byte, hexadecimal number (i.e., '01'X- 'FF'X). This gives you values from 1 to 255 decimal. The AS/400 can support many more fonts. One way to get access to this support would be to convert the entire application to native. A much simpler solution is to use the OVRPRTF command right in your S/36E procedure.

When you use this technique, you must pay attention to both native and S/36E rules. Probably the simplest way to do this is to remove your PRINTER OCL and use OVRPRTF(*PRTF) to control printer attributes within your S/36 procedure. If an L-spec is coded in an S/36 program, it will still take precedence over the OVRPRTF. If you do not explicitly delete the override with a Delete Override (DLTOVR) command, it will stay in effect until the first level (outermost) procedure ends. This means that any PRINTER OCL in a later job step or an included procedure may not take effect. 6 shows how the parameters of the PRINTER OCL statement map to parameters of the OVRPRTF command.

When you use this technique, you must pay attention to both native and S/36E rules. Probably the simplest way to do this is to remove your PRINTER OCL and use OVRPRTF(*PRTF) to control printer attributes within your S/36 procedure. If an L-spec is coded in an S/36 program, it will still take precedence over the OVRPRTF. If you do not explicitly delete the override with a Delete Override (DLTOVR) command, it will stay in effect until the first level (outermost) procedure ends. This means that any PRINTER OCL in a later job step or an included procedure may not take effect. Figure 6 shows how the parameters of the PRINTER OCL statement map to parameters of the OVRPRTF command.

Other Considerations when Mixing Native and OCL

Since the S/36E uses native data management to provide its functions, being able to mix native functions with S/36E functions makes the S/36E a very powerful place. However, you can sometimes get into trouble. Native rules are always in effect, they are merely superimposed with S/36E special processing in some cases. Therefore, the user profiles, job descriptions, workstation and printer device descriptions interacting with OVRPRTF (both native and generated by PRINTER OCL) and printer file definitions can get pretty confusing. Here are a couple of things to consider:

1. The SET procedure changes the PRTDEV parameter for your workstation DEVD. It is possible that this value will never be accessed during a job. Values in the JOBD, USRPRF and workstation DEVD are processed according to the rules illustrated in Figures 3-5. If the system never looks at the workstation PRTDEV parameter, your session printer may be different than you were expecting.

2. If you specify a device parameter on the PRINTER OCL statement, S/36E processing overrides the DEV parameter of the printer file. The resulting internal override is the equivalent of:

 
 OVRPRTF FILE(file name) + 
    DEV(printer name) 

If there is an explicit OUTQ value in either the file or the job (for example, based on the user profile), the device specified on the PRINTER OCL will never be used. Again you can refer to Figures 3-5; OUTQ parameters always override DEV parameters under native rules.

A Final Note

Although this is far from a complete discussion of AS/400 printer internals, by now I have hopefully unlocked some of the mysteries of printing on the AS/400 both in native and in the S/36 Environment. If you just know a few of the rules, you can be comfortable fairly quickly.

S/36 Environment Printing Internals

Figure 1 Simplified program stack

 
  Figure 1:  Simplified Program Stack 
 
  PGMA 
  PGMB 
  PGMC 
 
  S/36 Environment Printing Internals
 
 Figure 2   Printer file with merged overrides
 
 
  Figure 2:  Printer File With Merged Overrides 
 
  Unable to reproduce graphic. 
 
  S/36 Environment Printing Internals
 
 Figure 3-5 (unable to display graphics)
 
 
  S/36 Environment Printing Internals
 
 Figure 6   PRINTER OCL and OVRPRTF equivalents
 
 
  Figure 6:  PRINTER OCL and OVRPRTF Equivalents 
 
  // PRINTER              OVRPRTF 
 
  NAME-                   FILE() 
  DEVICE-                 DEV() 
  LINES-                  PAGESIZE(length width) 
  LPI-                    LPI() 
  CPI-                    CPI() 
  FORMSNO-                FORMTYPE() 
  ALIGN-YES               ALIGN(*YES) 
  ALIGN-NO                ALIGN(*NO) 
  SPOOL-YES               SPOOL(*YES) 
  SPOOL-NO                SPOOL(*NO) DFRWRT(*NO) 
  COPIES-                 COPIES() 
  CONTINUE-               SHARE() 
  PRIORITY-0              HOLD(*YES) OUTPTY(7) 
  DEFER-YES               SCHEDULE(*FILEEND) 
  HOLD-YES                SAVE(*YES) 
  HOLD-NO                 SAVE(*NO) 
  IGCCPI-5                IGCCPI(5) 
  IGCCPI-6.7              IGCCPI(*CONDENSED) 
  SOSI-NORMAL             IGCSOSI(*YES) 
  SOSI-SHIFT              IGCSOSI(*RIGHT) 
  SOSI-DROP               IGCSOSI(*NO) 
  TYPE-IGC                IGCDTA(*YES) 
  EXTN-OFF                IGCEXNCHR(*NO) 
  JUSTIFY-                JUSTIFY() 
  FONT-(hex)              FONT((decimal) *NONE) 
  DRAWER-                 DRAWER() 
  DRAWER-3                DRAWER(*E1) 
  ROTATE-                 PAGRTT() 
  TEXT-YES                PRTQLTY(*NLQ) 
  TEXT-NO                 PRTQLTY(*DRAFT) 
  EOFMSG-YES              FORMFEED(*CONT) 
  EOFMSG-NO               FORMFEED(*CUT) 

Also Read

Partner TechTip: End the Scourge of Ugly Forms!

Partner TechTip: The Pursuit of a Paperless Process

It's Just Another Day, But Do You Know What Your Reports Are Doing?