Thanks Chuck .... I was starting to look in this direction. This confirms
On 10/27/2015 11:01 AM, CRPence wrote:
On 26-Oct-2015 08:51 -0500, Rich Loeber wrote:
I am trying to retrieve several job related work management fields
using the QUSLJOB API. Using the API documentation, I can get
information for keys 101, 304, 312 and 1906 without a problem, but I
am looking for information on key 314 (percent used during elapsed
time). When I call the API with this key in the list, it fails with
the CPF1867 message pointing to this key value.
In the documentation for QUSLJOB, this key is not shown, but there is
a link in the documentation to the "Work Management API Attribute
Descriptions (WMAttrDesc) which shows this key. That page seems to
indicate that it is available to use for the QUSLJOB API, but it
keeps failing on me.
The doc references might be easily enough misconstrued, but suffice it
to say, the key=314 is not available for the invocation of the List Job
(QUSLJOB) API with Format JOBL0200, as diagnosed by the msg CPF1867
"Value &1 in list not valid." being issued:
The _Valid Keys_ for the API are expected to be presumed by the reader
as being definitive; i.e. the presented "table contains a list of the
valid keys" _for the API_ documented on that page. And the redirect
from that page to the documentation of "all the valid key attributes"
intends for the reader to understand that the redirection is merely to
the specific documentation for each of those listed-as-valid choices
from that _table_, not that "all" of those listed are "valid" in every
FWiW the target of the redirect is the "one place" serving as
documentation for a consolidated list of every Key Attribute that _might
be available_ to one or more of the various [six listed] Work Management
APIs. The comment suggesting that the WMAttrDesc page "describes all
the Job and Thread attributes that are used in all the Work Management
APIs" does not mean to imply that all keys are available to all of those
APIs; perhaps "used in all" should have been "used across the various".
There is I suppose, even a possibility that some of the /attributes/
documented there, although they have been assigned a key-number defined
so as to appear in the table [for which Key is a heading], may not even
appear as a valid key for use with any of the APIs, such that the data
for that attribute could be available only via non-keyed API requests.
1. Submit a comment on the QUSLJOB page asking why the key=314 is not
supported, if perhaps an oversight vs a design decision given the data
is documented as available in the Open-List variant of List-Jobs;
possibly also noting lack of other keys available from the OLJB0200
format of the other API.
2. The JOBI1000 Format of the Retrieve Job Information (QUSRJOBI) API
includes the "Processing unit used - percent during the elapsed time
(job)" attribute at offset 0x68 rather than via a key=314.
3. Use the List of Keys Supported for Format OLJB0300 for the Open
List of Jobs (QGYOLJOB) API.
And if used instead of the Format JOBL0200 of the List Job (QUSLJOB)
API [IMO better than used in addition to QUSLJOB], then in order to
obtain both that *and* the other noted keys, would require using
additionally, the List of Keys Supported for Format OLJB0200 of the List
of Jobs (QGYOLJOB) API:
Note: If QUSLJOB will be used with an additional API call to get the
missing information, then the Internal job identifier returned from that
list-jobs invocation can be used as input to the QUSRJOBI invocation
with quick effect, despite being an additional\separate invocation. If
the Open-List API would be used, then I infer most likely that a
wholesale change to use that QGYOLJOB job-listing API would be
preferable over use of both the non-Open-List and the Open-List
variants, despite any possible ability [and I am not aware there is, nor
could I find, the capability] to /list/ just the one job via the
Internal job identifier.