I searched for any post with some relation with this subject, and could not find.
If, by any chance, such a post exists, please, redirect me to it.
--------------------------
On my TSO/ISPF session I have a lot of data sets allocated to around 20 DDNAMEs, when the session is started.
I need to modify the data sets that are alllocated on a few of these DDNAMES - free some of them, already allocated, and allocate a few others, on the same DDNAME.
I tried to free the DDNAME, but received failing msg saying "DATA SET OPEN".
Then I tried to free some of the data sets, but received same msg.
I tried to find, on TSO and ISPF manuals, how should I proceed on this situation (possibly, first closing the data sets, who knows...), but was unable to find any information.
I have a reasonable understanding of TSO, and I am able to effectively look on its documentation, but I could had overlooked something.
Unfortunately, the same is not true for ISPF, and looking for something on its manuals, at least for me, is like trying to find a needle on a haystack
Any hint/clarification will be really appreciated!
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
In line mode TSO (READY prompt) you have the FREE command. Do HELP FREE SYNTAX if you do not know the syntax.
In ISPF, you have bunches of data sets allocated, usually under DD names ISPxxx something. Most are fairly permanent allocations. Yes, you can free them at the READY prompt, but then ISPF won't run right. In my experience ISPF is excellent at freeing data sets, like data sets you edit or browse, it no longer needs. I just looked at a TSO session I've been running for 8! days - yes 8- and outside of the semi permanent ISPF DD names I don't see anything that's likely to be a problem.
Some TSO commands - LINK and LOADGO are major offenders - leave data sets behind they really should free on exit. This idea goes back to pre-MVS so they didn't have to reallocate the data sets which could be a real drag in the allocation environment of that era, but that's all I can say with more than 40 years using TSO.
As you say, TSO does not let you free DDs that are open. You my be trying to free ISPxxx data sets while ISPF is running. Obviously that's no good, but you should be good to go at the READY prompt. If you're stuck there, about all you can do is logoff and start over again. You can get into this issue if something you're doing ABENDs and end of task failed to close the DD. It happens to all of us.
You know, I just realized TSO has been with is for almost 50 years!
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
Quote:
free some of them, already allocated, and allocate a few others, on the same DDNAME.
If the data set list is outdated, my suggestion is to get the system programmer to update the logon proc with the correct data sets. That is my preference instead of having your colleagues use a different set of data sets than you or having each of them to resolve this same issue themselves.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Pedro wrote:
If the data set list is outdated, my suggestion is to get the system programmer to update the logon proc with the correct data sets. That is my preference instead of having your colleagues use a different set of data sets than you or having each of them to resolve this same issue themselves.
Many shops use the logon Rexx EXEC for this purpose; this is a second source of customization. A possible third source of customization is for a user's Rexx EXEC to be run near the end of the logon Rexx EXEC. All of this means the LOGON proc is kept as simple (and therefor reliable) as possible.
The TS is probably not experienced enough to figure out what's going on in his environment and adding additional customization.
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
Another approach is to allocate user-level libraries before ISPF is started. Rather than FREEing a DDname and ALLOCATEing it again with a different list of data sets, just allocate the user level DDname, for example ISPPUSR. The ISPPUSR allocation is searched before ISPPLIB.
@steve-myers, I think satisfies your concerns.
See the discussion in the ISPF Services Guide, under LIBDEF.
