Yes, the LRECL will be set to 6 as documented in "z/OS DFSORT Application Programming Guide" where it says the following in the description of the WRITE(countdd) operand of COUNT:
o LRECL is set to one of the following:
- If WIDTH(n) is specified, LRECL is set to n. Use WIDTH(n) if your count record length and LRECL must be set to a particular value (for example, 80), or if you want to ensure that the count record does not exceed a specific maximum (for example, 20 bytes)
- If WIDTH(n) is not specified, LRECL is set to the calculated required record length. If your LRECL does not need to be set to a particular value, you can let ICETOOL determine and set the appropriate LRECL by not specifying WIDTH(n).
If you want LRECL=80, specify WIDTH(80). Since you didn't specify WIDTH(n), the LRECL was set to the calculated value of 6 as expected.
If you go around changing "stuff", how will anyone else be aware of it?
I have some automation programs which no one except me use. Moreover they are no where near to production programs.
Example, daily health checks of systems. Periodic reporting of transmissions and CPU consumption analysis of jobs..
Also allocation of dataset is a problem at our shop, where in a user is not allowed to use more than 300 CYLS in a single dataset on DASD. Also it gets worse before the end of the period, maybe thats when the defragmentation & Tape backup is done. Dont know.
So I thought reusing the same WORK dataset by changing the LRECL will suit for many purposes.
Although I have not yet tried it out.
I understand your point that changing LRECL could cause data corruption and S0C7 abend. Which is genuinely a valid concern.