IBM Mainframe Forum

In the recent Sort in VB topic there was talk about the flags in the second and third bytes of some variable length records that are spanned. Koluso can provide the definitive answer, but I believe the discussion was incorrect.

The flags as mentioned in the Sort in VB topic exist to allow data management to connect segments of a variable length record that exist in 2 or more physical records together into a complete record. Programmers that use QSAM and specify BFTEK=A in their DCB macro never see these flags; QSAM collects all the record segments into complete logical records. Assembler programmers that use BSAM to process data sets with spanned records will see the flags, but their programs should be connecting the segments into whole records.

Of course I have no idea about how sort processes data sets with spanned records, but I'm reasonably certain it will collect the segments into whole logical records as I just described for QSAM with BFTEK=A, and the spanned record flags for the first segment will be discarded, and that's what wil be sorted.

steve-myers wrote:In the recent Sort in VB topic there was talk about the flags in the second and third bytes of some variable length records that are spanned. Koluso can provide the definitive answer, but I believe the discussion was incorrect.

The flags as mentioned in the Sort in VB topic exist to allow data management to connect segments of a variable length record that exist in 2 or more physical records together into a complete record. Programmers that use QSAM and specify BFTEK=A in their DCB macro never see these flags; QSAM collects all the record segments into complete logical records. Assembler programmers that use BSAM to process data sets with spanned records will see the flags, but their programs should be connecting the segments into whole records.

Of course I have no idea about how sort processes data sets with spanned records, but I'm reasonably certain it will collect the segments into whole logical records as I just described for QSAM with BFTEK=A, and the spanned record flags for the first segment will be discarded, and that's what wil be sorted.

steve-myers,

I am not sure as to what I need to provide the answer for. I may have missed the topic about Flags in VB sort topic. Can you provide me with a link? As for how DFSORT process spanned records, it depends on the OPTION SPANINC. Check this link which explains in detail about SPANINC

http://publibz.boulder.ibm.com/cgi-bin/ ... 1ca60/3.14?

SPANINC=RC0 option eliminates incomplete spanned record segments from the input data set. Basically it skips over any segments that don't comprise a complete record. DFSORT does NOT create incomplete spanned records.

P.S: The name is Kolusu and NOT koluso

skolusu wrote:P.S: The name is Kolusu and NOT koluso

I don't really follow sort topics very much. It's been more than 5 years since I've used either DFSORT or the other major sort product. I just couldn't believe any sort product behaves as described in Sort in VB file. Most of my programming these last few months has been with VBS data - SMF records - so I have a nodding familiarity with VBS issues - and thought it might be a good idea to correct what appeared to be an error. As for the name; I thought I had typed in skolusu correctly, but I was typing from memory and missed the s and got the rest of it wrong, too.

If I am wrong, then I am wrong, and will freely acknowledge it; the shock wore off a long time ago

I think that this is the topic, dfsort-icetool-icegener/topic9351.html

I think there is a little confusion with an example showing x'0000nnnn' for the RDW, which should be x'nnnn0000'.

The question itself is a little obtuse. What happens when you SORT first on the RDW? Then the records are primarily in RDW order. For non-spanned records, that will be definitely record-length order. For spanned records, I'm not sufficiently interested to check (set up a test/read the manual) whether there is anything in the IOCS by the time SORT happens which would modify the behaviour.

If the previously-spanned-multiple-records are presnted to the SORT statement as one record (expected) I'd expect x'0000' in the low-order bytes of the RDW. If possible to read the constituent records individually, I'd expect the low-order two bytes to be non-zero.

I've only ever SORTed on the record-length to get data into record-length order for analysis of a file. If I wanted data also sorted withen equal record-lengths and the key happened to start at 5, I'd not consider clumping it all together, as it would hide my specific abnormal wishes. Normally I'd have no problem with clumping consecutive keys (although these days no real problem, I believe, in leaving them separate, it's an old habbit). It is just that the RDW is not "data" so I'm not going to confuse things by pretending it is "data".