IBM Mainframe Forum

Hey guys.

So I have been coming across a lot of JCL online and something that grabbed my interest was the use of DUMMY DD's in IEBGENER.

This is the job I just ran to see what would happen:



I ran the job and it got an RC=00.

I checked the output but there was no indication as to what exactly happened.

Why would someone copy a dataset to a dummy DD?

Is there any reason at all for this syntax?

Any advice is appreciated.

Thank you!

There are two reasons to use DD DUMMY.

1. For input, DD DUMMY implies an empty data set. The action a program might take depends on the program.
   
   This DD statement does not create an empty data set -
   
   //SYSIN DD UNIT=SYSDA,SPACE=(TRK,1)
   
   It creates a 1 track data set, but any data in the track is from a previous use of the track. While it is possible for a program to detect that the data set has not been initialized, it requires fairly deep Assembler knowledge. Even programmers that know how to detect an uninitialized data set seldom bothered. ISPF is one of the few programs that consistently and correctly detects an uninitialized data set.
2. For output, the programmer has no use for any data in the data set, so why create the data set? Most of the time this is less efficient than not providing a DD statement for the data set. Many programs insist that the DD statement be present.

These users thanked the author steve-myers for the post:

deucalion0 (Fri May 13, 2016 6:01 pm)

Could be a way to check if data in the dataset is readable.
Where I would normally use DUMMY for output is when using ADRDSSU to delete datasets. Control statements something like DUMP ... DELETE.
Or for unwanted print files.

These users thanked the author willy jensen for the post:

deucalion0 (Fri May 13, 2016 6:01 pm)

willy jensen wrote:Could be a way to check if data in the dataset is readable. ...

"Readable" covers a lot of sins. For example, the program that dumped this track -read the track with no trouble. However, finding a "regular" program that can read this track will be quite difficult! In case you didn't notice, the record is slightly longer than 32760 bytes