(Originally posted 2007-05-31.)
(Also posted to MXG-L Listserver (MXG-L@PEACH.EASE.LSOFT.COM) which I highly recommend as a place where mainframe performance people hang out.)
I must confess I feel slightly foolish about this… 🙂
After having asked for input into my UKCMG BOF one of the themes that came out was better ways of doing what IFASMFDP does. (I already have this on my agenda – as you’ll know if you follow my blog.)
So I asked my friend Frank Yaeger (who is the DFSORT Function Development lead) the following question:
“Frank, I thought you told me once that DFSORT had some issues with handling actually spanning records. Did I hear you right?”
to which I got a reply (paraphrased)…
“No, that’s wrong. DFSORT handles spanned records just fine. We can handle records up to 32767 bytes in length”.
So, a healthy slice of humble pie is mine, complete with plastic fork and paper plate. 🙂
Seriously, would anyone care to do a test for me and copy some eg Type 30s using DFSORT? 42-6 and 74-1 are the other cases that bother me. And perhaps 74-5. The test would be to copy and then run the results through (say) MXG. (I suspect using ICEGENER wouldn’t be a fair test as it may well revert to IEBGENER which we’ve always said does break SMF records.)
What I’d like to do, if such tests are successful, is to publish some examples of using DFSORT as a “better IFASMFDP”.
One thing still bothers me a little: Using DFSORT Copy doesn’t produce Dump Header and Trailer records – SMF Types 2 and 3. Does anyone actually care about losing them?
Note: This is emphatically not a DFSORT vs Syncsort question. I’d assume Syncsort also copes with spanned records. If someone is in a position to test that then great. If this were ever to be a DFSORT vs Syncsort thing it’d be on the grounds of what you can do with DFSORT vs Syncsort, not their ability to cope with SMF.
Mainframe, Performance, Topics 