On 19-Oct-2015 12:01 -0500, Graves, Chuck wrote:
Is there a way in CL, to retrieve the OUTQ value for a Display
device? I need to programmatically change this value for lots of
workstation device descriptions based on current values in the OUTQ

From the Receiver variable returned from the following API [see reference link below] the CL command\statements shown here should be helpful for that effect, using the Format name of DEVD0600 for the Receiver Variable (&RcvVar) return information:

CHGVAR &OutQnm %sst(&rcvVar 335 10)
CHGVAR &OutQlb %sst(&rcvVar 345 10)

CHGDEVDSP OUTQ(&newOutQlb/&newOutQnm)

_Retrieve Device Description_ (QDCRDEVD) API
" ...

Format name

The content and format of the information returned for each device description. The possible format names are:

DEVD0100 Basic device information.
DEVD0200 Detailed information for device category *APPC
DEVD0300 Detailed information for device category *ASC
DEVD0400 Detailed information for device category *BSC
DEVD0500 Detailed information for device category *DKT
DEVD0600 Detailed information for device category *DSP

Output queue (OUTQ). The output queue to be used for printed output associated with this display station. This information is returned in two separate fields:

• Name of the queue
• Library in which the queue can be found

(See the OUTQ parameter in the _CRTDEVDSP_ [http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/cl/crtdevdsp.htm] command.)

The output from Display Object Description (DSPOBJD) of *ALL Object Type (*DEVD) can be used to generate a list of all devices [in the machine context; aka in QSYS], and that list can be pared to only those where ODOBAT LIKE 'DSP%' such that only the Configuration Description (CFGD) of type Display Device (*DSP) are retrieved; i.e. being already determined that they are of the desired type *and* attribute, no reason to call the API to determine what is the extended type\attribute of each device:

If (%sst(&odobat 1 3) *eq 'DSP') then(do) /* fix only DSPxxx */
callprc vfyNfixOutQ(&odobnm) /* reset OutQ name if rqd */

And if an alternate means of generating the list of display devices also is of interest [i.e. DSPOBJD or an equivalent API was not already chosen], then the SQL could be used to generate and even pare the list. A VIEW could be defined to generate just a list of Device Description (*DEVD) objects with the Object Attribute (OBJATR) of DSPxxx. Just as with using the Output File (OUTFILE) support of the DSPOBJD command, the Receive File (RCVF) [after Declare File (DCLF)], optionally using first an Open Query File (OPNQRYF) [if for example collating the requested work or further refinement of the selection is desirable], can get the data from each record of the file. Effectively, in place of DCLF QADSPOBJD and RCVF on the equivalent\overridden-to output file, the Receive of row-data would be performed against the VIEW that is defined as encapsulating a query of the OBJECT_STATISTICS table-function, created using something like the following [untested] which limits from all-device-descriptions to just the display-device-descriptions:

/* given: prior existence of the VIEW DEVDSP */
/* that selects device attributes of */
/* DSPVRT, DSPLCL, ¿others?; per: */
/* */
/* create view DevDsp */
/* ( odobnm , odobat ) */
/* as */
/* ( select */
/* from table( */
/* qsys2.object_statistics('QSYS', '*DEVD') */
/* ) as OI */
/* where OI.OBJATTRIBUTE like 'DSP%' */
/* ) */
/* */
dcl (&rcvvar) *char 1400
dcl (&rcvlen) *int 4 (1400) /* len of (&rcvvar) */
rcvf /* next record from DEVDSP VIEW */
monmsg cpf0864 exec(do)
rcvmsg rmv(*yes)
goto noMorDev:
call qsys/qdcrdevd +
( &rcvvar +
&rcvlen +
'DEVD0600' +
&odobnm +
x'0000000000000000' +
/* do stuff, according to retrieved DevDsp info */

The SQL could be used to perform both the request for change and the request for selecting which devices, if there were a table-function or a scalar function that presented the OUTQ details for a named display-device; I am aware of neither a UDF nor UDTF for with that capability, but if the described activity is something that might be required somewhat more and similarly or more ad-hoc than the current situation, then there may be value in creating a UDTF or scalar UDF(s), to avoid having to create the CLP. Of course at that point, creating a CLP that is much more generic and dynamic is also an option; just that the SQL already has a nice interface for dynamic with the ability for variable replacement, which is a bit more challenging that what is provided for the CL [outside of REXX anyhow].

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.