|
View previous topic :: View next topic
|
| Author |
Message |
MJ DeChirico
New User
Joined: 29 Mar 2025
Posts: 3
Location: usa
|
|
|
|
Hi
I have a long-running application that closes and then reopens a dataset, which is fine. The problem occurs when a user decides to code FREE=CLOSE on the DD statement in the JOB's JCL.
Needless to say, when the application tried to reopen the dataset, the FREE=CLOSE function had removed the DDNAME from the TIOT and all related control blocks from the system.
There appears to be a bit in the DSAB and SIOT related to FREE=CLOSE. Is there a supported way to turn those bits off prior to issuing the close for the dataset?
A ZOS macro IEFDDSRV implies that it can modify allocation information, but what is required for the MODIFY=ALLOCATION request is not very well documented.
Does anyone have any experience with the IEFDDSRV function or know of other supported ways to prevent ZOS from performing the FREE=CLOSE when a dataset is closed?
Thanks in advance for any assistance that is offered.
JD |
|
| Back to top |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2194
Location: USA
|
|
|
|
Do not repeat the same question in different forums.
I don't think there is a legal way to manipulate with those system supported flags.
I believe if the user decided to code ANY parameters, either in DD statement, or in another program code, he must be aware of the consequences of his changes.
In such manner, a user can change hundreds, or thousands of different options, flags, or values. It is not possible for administration to programmatically fix hundreds of possible user's "decisions" except strict requirements to the user not to use unneeded, or harmful parameters, options, or flags in his coding. |
|
| Back to top |
|
|
MJ DeChirico
New User
Joined: 29 Mar 2025
Posts: 3
Location: usa
|
|
|
|
sergeyken,
That's a great philosophy regarding letting users be accountable for their actions.
But you really did not provide much of an answer to my question.
JD |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2194
Location: USA
|
|
|
|
| MJ DeChirico wrote: |
sergeyken,
That's a great philosophy regarding letting users be accountable for their actions.
But you really did not provide much of an answer to my question.
JD |
My answer is:
1. You cannot automatically overcome all possible user's stupidity.
2. The flag you mentioned has been introduced by IBM not to be switched back and forth. If FREE=CLOSE has been specified there should be a reason for that. In case there was no reason, this parameter MUST be eliminated from the code, not by resetting the flag.
3. There are hundreds of other flags a user can set, and the consequences may be even worse. The only way to fix it is - force the user not to code what he doesn't understand.
The user may also code:
X = Y / 0;
Do you plan to fix this automatically at the system level? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10896
Location: italy
|
|
|
|
FREE=CLOSE was meant to be used for sysout
using FREE=CLOSE will let JES2 start processing the sysout datasets as soon as they are created instead of waiting for the end of job |
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1381
Location: Bamberg, Germany
|
|
|
|
| enrico-sorichetti wrote: |
FREE=CLOSE was meant to be used for sysout
using FREE=CLOSE will let JES2 start processing the sysout datasets as soon as they are created instead of waiting for the end of job |
I would recommend JESLOG=SPIN* for such cases. |
|
| Back to top |
|
|
MJ DeChirico
New User
Joined: 29 Mar 2025
Posts: 3
Location: usa
|
|
|
|
| Thanks for all the comments, they have been enlightening to say the least. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2194
Location: USA
|
|
|
|
| enrico-sorichetti wrote: |
FREE=CLOSE was meant to be used for sysout
using FREE=CLOSE will let JES2 start processing the sysout datasets as soon as they are created instead of waiting for the end of job |
Another reason for using FREE=CLOSE might be: simulation of dynamic dataset re-allocation at JCL level. The same DDNAME can be defined multiple times with different DSNAME, and with FREE=CLOSE in each case. If so, the running program will switch to the next dataset after each CLOSE---OPEN on the same DCB (or FILE, or whatever).
Anyway, if FREE=CLOSE has been specified for any specific reason, then reset of the corresponding flag would prevent the goal to be achieved. If there is no useful reason for FREE=CLOSE, then correct way to fix the issue is: remove this parameter from the source code. |
|
| Back to top |
|
|
|
|
