>>What field is 1,4,CH? If you looked up the syntax of P, M, F then it is very easy to follow
P = start position of the field M = Length of the field F = format/type field so 1,4,CH = position 1 for a length of 4 bytes and character format >>Why should an applications programmer have to know in 2020 that offset 5 in the COBOL data division map means 6 if it is a fixed block file and 10 if it is a variable block file? hmm even in 2020 aren't you specifying what type of file you are reading/writing in COBOL via File Section? You don't have to specify what type of file you are reading via DFSORT. As for offsets, COBOL calculates the offsets by copybook/mapping of the file. Similarly you can use DFSORT symbols to specify the layout of the file and you can refer the fields directly in the control cards. DFSORT even provides a smart trick to convert your COBOL copybooks into equivalent DFSORT symbols. Check out the "Create DFSORT Symbols from COBOL Copybook" trick at https://www.ibm.com/support/pages/smart-dfsort-tricks >> For output you would be right about the COBOL program not being able > to handle the change in record length but if RECORD 0 is coded on the > FD for a QSAM input fixed block file, so long as the first n bytes are > the bytes expected, the program will read whatever record length is in > the DSCB and ignore the excess over what is described. Aren't you still limited by 01 record description of the file? If 01 record description is defined as 80 bytes, and if you are reading the 200 byte file then you cannot technically look at the contents beyond 80 bytes. I guess the alternative is to specify the largest 01 Record description. And this still does not solve the problem with different RECFM's (Fixed definition and Variable input) And output file as you pointed is always a drawback. For DFSORT you don't even have to specify the DCB of the input or output file as it figures out automatically. >>Both the sort and the COBOL program would be invalidated if any of the displacements for fields that aree reference change. Not really. For COBOL, you have to recompile and link edit with the new changes. For DFSORT it is mere change of displacement and if you use symbols then there is absolutely no changes for DFSORT at all. Just change the symbol mapping and you are all set. > When I see coding in field displacement and length I am reminded of > why I was very happy the company I was working got DYL280 to replace > DYL260. I was a heavy user of DYL260 but the ability to use COBOL > record descriptions and DYL280 record descriptions was a game changer. Well you are comparing a programming language to an utility and this topic is NOT about which one is better. Both products have their advantages and disadvantages. I for one believe in using the right tool for the right job. In this particular scenario, DFSORT is definitely a better tool. > Just out of curiousity, assuming half track blocking, how much more efficient is the sort I-O than coding BUFNO=30? Depends on several factors. Blocksize and available memory. Why don't test out a cobol program to copy a 100 million record dataset and do the same using DFSORT and verify the results. You can try different LRECL and Blocksize combinations. Thanks, Kolusu DFSORT Development IBM Corporation ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
