DD DUMMY & CPU TIME

Nileshkul · New User Joined: 09 May 2016 Posts: 43 Location: India

I have a VB file to which millions of records are written. Now the file data is redundant. Will making file as DD DUMMY will save any CPU time?

Nileshkul · New User Joined: 09 May 2016 Posts: 43 Location: India

I am planning to DD DUMMY file in JCL without removing file write code in cobol program

Bill Woodger · Posted: Mon Dec 19, 2016 11:49 pm

Yes, but not as much as removing the processing to create the file which is no longer used.

Nileshkul · New User Joined: 09 May 2016 Posts: 43 Location: India

Thanks for quick response

Rohit Umarjikar · Posted: Tue Dec 20, 2016 2:37 am

Arun Raj · Posted: Wed Dec 21, 2016 12:20 am

Rohit Umarjikar · Posted: Wed Dec 21, 2016 12:32 am

I know what TS is asking here, my reply ain't different than what you say and that's why I say is a half fix dummying the output file instead of not producing it at all when not required anymore.

Arun Raj · Posted: Wed Dec 21, 2016 12:38 am

Your response seemed to suggest that, the OP is creating the data set in stepA and that he is trying to dummy it in stepB, which is not the case here.

vasanthz · Posted: Wed Dec 21, 2016 12:44 am

You would see difference in the EXCP(execute channel path macro call) values as there would be not writes happening to the DUMMY file.

The TCB would show decrease as no records are written and a minuscule difference in SRB as the device need not be allocated as it is DUMMIED out.

As for the CPU, like Bill mentioned the CPU variance in IO would be small compared to removing the logic on the program itself.

Phrzby Phil · Posted: Wed Dec 21, 2016 2:03 am

The half fix may be the safest.

I once worked at an agency that required every functionality to be tested if any change was made to a program. Hence, some simple changes were just never made.

Bill Woodger · Posted: Wed Dec 21, 2016 3:40 am

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.

steve-myers · Posted: Thu Dec 22, 2016 1:32 am

Well, I did try it. I thought I saw 50 million mentioned in this thread, but all I can actually find now is "millions." I couldn't get enough storage for 50 million, but I did try it for 10 million.

These were run under Hercules - 18.45 seconds to write 10,000,000 records to a data set, 1.06 seconds to "write" to DD DUMMY. The loop overhead was 0.10 seconds.

The program wrote a fixed record, so there was no record preparation time, so a real program will show higher times

vasanthz · Posted: Thu Dec 22, 2016 1:37 am

Nice research Steve, I wish there was a like button. How did you find the loop overhead. Just curious.

steve-myers · Posted: Thu Dec 22, 2016 2:33 am

steve-myers · Posted: Thu Dec 22, 2016 10:00 am

I'd propose several stages

Change the data set name on the existing output data set, so if some as yet unknown task attempts to use the current data set it can be detected and fixed.
Scan SMF 14s and 15s, or perhaps just 14s, for use of the current data set. This can extend back as far as convenient. Collecting data set names in these records is simple as they are at a fixed position in the records.
If there has not been any detected problems from the first bullet go with the DD DUMMY idea.
If no issues have been detected look at removing the code that creates the data set.

steve-myers · Posted: Thu Dec 22, 2016 5:14 pm

This is the PUT loop from the Assembler listing. The PUT macro is expanded.

steve-myers · Posted: Fri Dec 23, 2016 12:06 am

When I prepared the PUT subroutine code, I screwed up. The 3 NOPR 0 instructions are not true NOPRs. Well, for all intents and purposes they are NOPRs, but more like a slow NOPR. A true NOPR is BCR 0,0. These instructions are BCR 15,0. You can read about the difference in Principles of Operation.

I won't try to guess why IBM used them, unless my cynic theory is correct!