×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
One other workaround is to often use lvlchk(*no) on your files. The hope
is that IBM will add new fields to the end, and not modify the
construction of other fields.
Ranking is based on maintenance. Not on ease of initial creation.
Poorest solution: OUTPUT(*PRINT) then CPYSPLF to a disk file. Blows up
on even simple stuff like DSPSYSSTS OUTPUT(*PRINT) when IBM moves around
the layout. Also handling different systems in a couple of different
matters. Matter 1 being a system so large that it doesn't care about
decimals after GB, like 5010 G, versus a system that displays 705.6 G.
Second matter is compiling the data from multiple lpars/machines on to one
when they are not all at the same release.
Better solution: OUTPUT(*OUTFILE). "Most" time you can get around
different releases by compiling with LVLCHK(*NO) and not concerning
yourself with new fields at the end. You can get bitten by field size
changes like number of spool files per job (but try to find an output file
that contains that). Often in that case you may see an example like the
output file from DSPOBJD, field ODOBSZ for object size "Object size:
9,999,999,999=Use ODSIZU*ODBPUN".
Best solution: Use an appropriate API from:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apiref/api.htm
Rob Berendt
midrange.com
