CODEWITHSUNDEEP
mainframezosjcldfsort
Jeremy C.
Jeremy C.

Reputation: 2465

SUM not working 'Invalid or missing field format'

I have an input file in this format: (length 20, 10 chars and 10 numerics)

jname1    0000500006
bname1    0000100002
wname1    0000400007
yname1    0000000006
jname1    0000100001
mname1    0000500012
mname2    0000700013

In my jcl I have defined my sysin data as such:

SYSIN    DATA  *              
 SORT FIELDS=(1,1,CH,A)
 SUM FIELDS=(11,10,FD)        
         DATAEND              
*

It works fine as long as I don't add the sum fields so I'm wondering if I'm using the wrong format for my numerics seeing as I know they start at field 11 and have a length of 10 the format is the only thing that could be wrong.

As you might have already realised the point of this JCL is to just list the values but grouped by the first letter of the name (so for the example data and JCL I have given it would group the numeric for mname1 and mname2 together but leave the other records untouched).

I'm kind of new at this so I was wonder what I need for the format if my numerics are like that in the input file.

Upvotes: 0

Views: 1281

Answers (2)

Bill Woodger
Bill Woodger

Reputation: 13076

If new to DFSORT, get hold of the DFSORT Getting Started guide for your version of DFSORT (http://www-01.ibm.com/support/docview.wss?uid=isg3T7000080).

This takes your through all the basic operations with many examples.

The DFSORT Application Programming Guide describes everything you need to know, in detail. Again with examples. Appendix C of that document contains all the data-types available (note, when you tried to use FD, FD is not valid data-type, so probably a typo). There are Tables throughout the document listing what data-types are available where, if there is a particular limit.

For advanced techniques, consult the DFSORT Smart Tricks publication here: http://www-01.ibm.com/support/docview.wss?uid=isg3T7000094

You need to understand a bit more the way data is stored on a Mainframe as well.

Decimals (which can be "packed-decimal" or "zoned-decimal") do not contain a decimal-point. The decimal-point is implied. In high-level languages you tell the compiler where the decimal-point is (in a fixed position) and the compiler does the alignments for you. In Assembler, you do everything yourself.

Decimals are 100% accurate, as there are machine-instructions which act directly on packed-decimal data giving packed-decimal results.

A field which actually contains a decimal-point, cannot be directly used in arithmetic.

An unsigned field is treated as positive when used in any arithmetic.

The SUM statement supports a limited number of numeric definitions, and you have chosen the correct one. It does not matter that your data is unsigned.

If the format of the output from SUM is not what you want, look at OPTION ZDPRINT (or NOZDPRINT).

If you want further formatting, you can use OUTREC or OUTFIL.

As an option to using SUM, you can use OUTFIL reporting functions (especially, although not limited to, if you want a report). You can use SECTIONS and TRAILER3 with TOT/TOTAL.

Something to watch for with SUM (which is not a problem with the reporting features) is if any given one (or more) of your SUMmed fields exceed the field size. To continue to use SUM if that happens, you need to extend the field in INREC and then get SUM to use the new, sufficient, size.

Upvotes: 1

Jeremy C.
Jeremy C.

Reputation: 2465

After some trial and error I finally found it, appearantly the format I needed to use was the ZD format (zoned decimal, signed), so my sysin becomes this: 

SYSIN    DATA  *              
 SORT FIELDS=(1,1,CH,A)
 SUM FIELDS=(11,10,ZD)        
         DATAEND              
*

even though my records don't contain any decimals and they are unsigned, I don't really get it so if someone knows why it's like that please go ahead and explain it to me.

For now the way I'm going to remember it is this: Z = symbol for real (meaning integers so no decimals)

Upvotes: 0

Related Questions