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
parameter.
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)
[
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/QDCRDEVD.htm]
_Retrieve Device Description_ (QDCRDEVD) API
" ...
Format name
INPUT; CHAR(8)
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 */
call QSYS/QDCRDEVD ...
callprc vfyNfixOutQ(&odobnm) /* reset OutQ name if rqd */
enddo
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:
DCLF DEVDSP
/* given: prior existence of the VIEW DEVDSP */
/* that selects device attributes of */
/* DSPVRT, DSPLCL, ¿others?; per: */
/* */
/* create view DevDsp */
/* ( odobnm , odobat ) */
/* as */
/* ( select */
/* OI.OBJNAME, OI.OBJATTRIBUTE */
/* 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) */
nxtDev:
rcvf /* next record from DEVDSP VIEW */
monmsg cpf0864 exec(do)
rcvmsg rmv(*yes)
goto noMorDev:
enddo
call qsys/qdcrdevd +
( &rcvvar +
&rcvlen +
'DEVD0600' +
&odobnm +
x'0000000000000000' +
)
/* do stuff, according to retrieved DevDsp info */
noMorDev:
return
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].
midrange.com
