Author: Bill Woodger
Subject: Reply to: DD DUMMY & CPU TIME
Posted: Wed Dec 21, 2016 3:40 am (GMT 5.5)
Yes, there can be several stages. The DD DUMMY is a painless way of not actually getting the physical IOs, without the program requiring change, or being somehow changed by the now non-event - DD DUMMY is entirely transparent to a COBOL program. An easy first stage, being done as soon as possible.
I was once told, and have never verified, that putting buffers on DD DUMMY "allows the data to be ignored faster".
I think that all the CPU use within the IO routines stays, and the records are just finally not written. I think. I don't know.
Changing the program itself has at least two obvious potential stages. Remove the IO statements (and any checking associated with them). This is/should be transparent to the "business logic" in the program, but is a much larger change than just the DD DUMMY.
Then there is the clearing out of the processing associated with the creation of the records (again this can be staged). You may arrive at a point where there is still code remaining, but that it is bound to other processing in such a way that there's too great a risk of unintended consequence.
There is always a risk in leaving redundant code operating as well (it can trip future changes, analysis of the program, false impressions on problem-determination/impact-analysis.
Documenting, externally, such that the next person along should be aware, can mitigate the risks.
Subject: Reply to: DD DUMMY & CPU TIME
Posted: Wed Dec 21, 2016 3:40 am (GMT 5.5)
Yes, there can be several stages. The DD DUMMY is a painless way of not actually getting the physical IOs, without the program requiring change, or being somehow changed by the now non-event - DD DUMMY is entirely transparent to a COBOL program. An easy first stage, being done as soon as possible.
I was once told, and have never verified, that putting buffers on DD DUMMY "allows the data to be ignored faster".
I think that all the CPU use within the IO routines stays, and the records are just finally not written. I think. I don't know.
Changing the program itself has at least two obvious potential stages. Remove the IO statements (and any checking associated with them). This is/should be transparent to the "business logic" in the program, but is a much larger change than just the DD DUMMY.
Then there is the clearing out of the processing associated with the creation of the records (again this can be staged). You may arrive at a point where there is still code remaining, but that it is bound to other processing in such a way that there's too great a risk of unintended consequence.
There is always a risk in leaving redundant code operating as well (it can trip future changes, analysis of the program, false impressions on problem-determination/impact-analysis.
Documenting, externally, such that the next person along should be aware, can mitigate the risks.