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
As an Amazon Associate we earn from qualifying purchases.