Hi, We are having strange behavior of temp dataset. when temp dataset with same name is allocated more than once without deleting, system is not giving JCL error and later use of temp dataset is causing unpredictable reference to data. for ex.
JSTEP010.STEP010 create &&TEMP1 (DISP=NEW,PASS)
JSTEP010.STEP020 read &&TEMP1 with DISP=SHR (&&TEMP1 is not deleted)
JSTEP020.STEP010 create &&TEMP1 (DISP=NEW,PASS)
JSTEP020.STEP020 read &&TEMP1 - this may pick up the &&TEMP1 dataset created in JSTEP010.STEP010 which is not intended.
I got the same result - I think - described in the first post. In other words, the SYSUT2 data set in JSTEP020.STEP020 contains the text TEMP DATA SET CREATED IN JSTEP10.
where stmt 13 is
13 ++SYSUT1 DD DISP=SHR,DSN=&&TEMP1
Now, when you get to JSTEP020/STEP020 there are two data sets in the passed data set queue: the &&TEMP1 from JSTEP010 and the &&TEMP1 from STEP010 in JSTEP020. It picked the first one. This is the behavior I would expect. Nothing strange about it.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
The MVS JCL Reference manual says:
Quote:
To ensure that a temporary data set name is unique, do not code a temporary data set name. Allow the system to assign one.
So the behavior you're seeing is expected and normal.
Furthermore, there is an option SYSTEM TEMPDSFORMAT(UNIQUE) in PARMLIB member ALLOCxx that enables allocation to use a more unique format for DSN=&&dsn names. You might want to talk to your site support group about that option.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
You can see the data set names in the SYSMSGS data set.
As Mr. Sample says, you can persuade the system to generate fully unique names, but then there is the problem of retrieving the names. In terms of the initial request, the JCL becomes
Often, though, you have to use names, as in the infamous &&GOSET(GO)). One of my mentors when I was starting out ran multiple step FORTGCLG jobs, and we had to remember to delete the @#%$ data set between the job steps.
