GDDM V3R2 System Customization and Administration
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF | BOOK


The format of the nickname UDS

GDDM V3R2 System Customization and Administration
SC33-0871-02



------------------ General-use programming interface -------------------

   The syntax of a nickname UDS is as follows:


     [label] ADMMNICK [APPEND|REPLACE]
                      [,FAM=family]
                      [,NAME=name-list]
                      [,TOFAM=to-family]
                      [,TONAME=to-name-list]
                      [,DEVTOK=device token]
                      [,PROCOPT=processing-option list]
                      [,DESC='description'|"description"]

label
The label value is optional and is ignored by GDDM. Any word starting in column one is assumed to be a label.


APPEND|REPLACE
Specifies whether this nickname UDS is to replace or be added to other nickname UDSs with the same FAM= and NAME= values. (For more information about the effects of multiple nickname UDSs, see "Which nickname is implemented?" in topic 3.9.1.1.)

FAM=0|1|2|3|4
Identifies the GDDM printing family (1,2,3, or 4) to which this nickname statement applies. For example, a value of FAM=2 specifies that the other information supplied on this nickname statement applies only when family-2 output has been requested on the DSOPEN call. (Note that the GDDM-PGF ICU and User Control both produce family-2 output. If you want to define nicknames that affect the output from the ICU and User Control, you must set FAM=2.)

For a nickname statement to be usable by a DSOPEN call, the FAM= value on the nickname statement and on the DSOPEN call must be the same. The default setting is FAM=0, which means that this nickname statement can be applied to any family specified on the DSOPEN call. The same effect is achieved by specifying FAM=,, or omitting the FAM= parameter.

NAME=name-list
Identifies the physical destination of the output. This varies according to both the subsystem and the GDDM printing family. For example, the destination of family-2 output in the VM/CMS environment is an intermediate file (of type ADMPRINT, by default), whereas the destination of family-4 output in the TSO environment is a print data-set. For more information about possible name-list values, see Appendix D, "Name-lists" in topic D.0.

The name-list parameter comprises one or more name-parts, each of which is a string of 0 through 8 nonblank characters. The following are valid name-lists:


       NAME=name1,                -- one nonblank name-part
       NAME=(name1),              -- one nonblank name-part
       NAME=(),                   -- one blank name-part
       NAME=(name1,name2,name3),  -- three nonblank name-parts
       NAME=(name1,,name3),       -- two nonblank name-parts and one
                                      blank name-part
       NAME=,                     -- null name.

For a nickname statement to be usable by a DSOPEN call, the name-list values on the DSOPEN call and on the nickname UDS must match, or that specified on the nickname statement must be null. The two name-lists are considered to match if the corresponding name-parts are the same (after left-justification, translation to uppercase, and padding with blanks). If the name-lists do not contain the same number of name-parts, the shorter of the two name-lists is extended with "*" name-parts for the purpose of comparison. A value of NAME =* identifies the default device, which is the user console. In each of these three examples, the two name-lists are considered to match:

  1. 'FRED' and '(FRED)'
  2. 'FRED' and '(FRED,*)'
  3. 'FRED' and '(FRED,*,*)'
    
    
'FRED' and '(FRED,ADMPRINT)' do not match.

A name-part can contain a leading and a trailing "?" character, which is considered to match any combination of characters in the same position. For example:



       'abc?'  -- matches any name-part starting with 'abc'
       '?'     -- matches any name-part

Embedded "?" characters are invalid. The default is null (that is, NAME=,), which is considered to match any name-list specified on the DSOPEN call.

TOFAM=0|1|2|3|4
Allows output assigned to one GDDM printing family (on the DSOPEN call and on the FAM= parameter of this nickname statement) to be assigned to a different family. In effect, this allows rerouting of output from one printer to another. For example, if a nickname statement specifies FAM=2 and TOFAM=4, family-4 output is created instead of family-2 output.

TOFAM=0, which is the default value, leaves the FAM= value unaltered.

TONAME=to-name-list
Replaces the name-list specified on NAME= with a different name-list. If a nickname statement contains a TOFAM= value that changes the print family, a TONAME= value is also likely to be be required.

The to-name-list has the same format as the namelist value, except that "?" characters are not supported. If to-name-list is null, the NAME= name-list value is left unaltered.

DEVTOK=device token
A string of 0 through 8 nonblank characters that identifies some of the characteristics of the target printer or plotter, such as its model number and paper size. GDDM supplies a large set of device tokens, which are listed in Appendix C, "Device tokens supplied by GDDM" in topic C.0. You can also define your own. How to do this is described in "Creating your own device tokens" in topic 3.1.

The device token must be suitable for the TOFAM= and TONAME= values. If you specify a device token on the DEVTOK= parameter, it takes effect only if the device-token value on the DSOPEN call is set to "*" or blank. If a device token is explicitly named on the DSOPEN call, it cannot be overridden.

Device tokens tell GDDM the characteristics of the device, thereby suppressing the usual "device query." In general, it is better to let GDDM query a device at the time output is produced than to provide a device token on the DSOPEN call. However, there are circumstances in which GDDM cannot query a device and in which a device token should therefore be supplied. These are:

  • If GDDM is running under IMS
  • If GDDM does not have direct access to the device (usually a printer, typically managed by some other program, such as PSF)
  • If a dummy device (one not yet physically present) is used
    
    
Even in these cases, it is still better to specify the device token on a nickname statement than on the DSOPEN call.

PROCOPT=processing-option list
Processing options (procopts) control the details of an output process. For example, you can use a processing option to specify whether swathes are to be used to process a high-resolution image (HRISWATH), to specify the speed of plotter pens (PLTPENV), and to enable user control (CTLMODE). For a full list of processing options and their values, see Appendix B, "Processing options" in topic B.0.

PROCOPT= specifies a list of procopts as follows:


         PROCOPT=((procopt-spec),(procopt-spec),...)

Each procopt-spec comprises a keyword followed by a number of arguments valid for that processing option:


         PROCOPT=((keyword,argument,argument),
                  (keyword,argument), ...)

Procopts specified on the DSOPEN call cannot be overridden.

DESC='description'|"description"
A string of 0 through 72 bytes that describes the printer or plotter. The string can contain mixed double-byte (DBCS) and single-byte (SBCS) characters. SBCS characters must be encoded using the installation code page. The string should be enclosed in double quotation marks if there are single quotation marks within the string itself. By entering "?" in the "Name of printer or plotter" field of the User-Control output panel or in the ICU Printer Selection Panel, users can display the description of any printer or plotter that has a namelist of 1 through 8 characters. When displayed on the ICU Printer Selection Panel, descriptions are truncated to 60 bytes, and are listed in the reverse of the order in which they are defined in the external defaults module or file.

You are recommended to supply a description of any printer or plotter to which end users are likely to submit output.

Subtopics:

Go to the previous page Go to the next page



Copyright IBM Corporation 1990, 2012