Jerry Draper wrote:
Is there a way to display all jobd's to a file like we can do
with dspusrprf?
I need to look over all jobd's in a system and change message
logging where appropriate.
/* CLP: LISTJOBD creates QTEMP/JDLIST as list of *JOBD */
PGM PARM(&LIB &OBJ) /* for OBJ(&LIB/&OBJ) on DSPOBJD */
CRTDUPOBJ QLIDOBJD *LIBL *FILE QTEMP JDLIST DATA(*NO)
/* assumes no file; code to handle as appropriate */
CHGPF QTEMP/JDLIST SIZE(*NOMAX)
DSPOBJD &LIB/&OBJ *JOBD *FULL +
OUTPUT(*OUTFILE) OUTFILE(QTEMP/JDLIST)
ENDPGM
One method is to create a SQL UDF or UDTF where the QWDRJOBD API
retrieves the desired information which is returned to the external
function [i.e. the HLL program which calls that API] as data and/or an
indication that the current setting is not /appropriate/.
A UDTF might use the above CLP or its file as input [or object list
API] to establish the list of Job Description objects from which it then
generates one row for each *JOBD in the output file. The external User
Defined Table Function would establish the table with field names JDxxx
to denote the information from the *JOBD object. Then the SQL SELECT
JDLIB, JDNAME, JDLOGLVL, JDLOGSEV, JDLOGTEXT FROM
TABLE(ODJOBDLIST('*ALL', '*ALL')) WHERE JDLOGTEXT <> '*SECLVL' could
return those rows from the DSPOBJD which [according to the WHERE clause]
did not have Second Level text logging set.
A UDF might be more specific [than a UDTF might be] to the LOG()
elements, and respond to a question as a function named IsJOBDlogOK or
to a request for action as a function named SetJOBDlogging. The
function could returns a '0' for false or unchanged, '1' for true or
changed. An SQL SELECT ODNAME, ODLBNM, IsJOBDlogOK(ODNAME, ODLBNM, 4,
0, '*NOLIST') could show a report of which have LOG(4 0 *NOLIST) and
which do not. An SQL SELECT ODNAME, ODLBNM, SetJOBDlogging(ODNAME,
ODLBNM, 4, 0, '*NOLIST') could show a report of those same job
descriptions, but also include the action to change those which did not
match the expected setting.
Some may imply that effecting the actual change in the UDF would be
/dangerous/ since it would be best to limit the data by a WHERE clause
or join to prevent changing something unexpected. *But* that is only
for lack of first reviewing what would be changed [as a sanity check],
which is _no different_ than coding the same change activity outside of
any SQL. Using the SQL just makes it /fit/ with the use of an output
file; i.e. rows of data. To avoid making two functions, I have used an
extra parameter on just the one [change capable] function, as a 'D' for
display-only and 'C' for a request to implement the change. In that
manner I can select all the data to see what would have been changed
without it actually having changed anything. Other times I would use
the UDTF to enable the review of the affected /rows/, and then it is run
again as input to a program which actually makes the change; but to
prevent the dynamic results of the UDTF from changing between
invocations of the UDTF, either the UDTF operates against a static list
[the JDLIST file is created before, not by the UDTF] or the reviewed
data is best stored separately as a static list using something like:
CREATE TABLE QTEMP/LISTTOCHANGE
AS SELECT * FROM TABLE(ODJOBDLIST(...))
WITH DATA
Regards, Chuck
midrange.com
