03-27-2018 12:56 PM
I have a prior client who claims to be having trouble with running out of space when the AGE statement is processing in a PROC DATASETs step.
Since the AGE statement is just renaming datasets in an existing directory (and possibly deleting one), that does not make sense to me.
But I wonder if perhaps there is something about the order of the renames (e.g., adding the .lck suffix) that is somehow causing this.
Has anyone seen this as an issue?
03-27-2018 05:24 PM
Even is this is a concatenated library, no new data is created. What happens then is that tables may not get deleted as expected, but that does not use new space.
03-28-2018 09:30 AM
It is not a concatenated library.
And I agree this is weird since new data is not being created.
Part of the path for the libname is a Unix shortcut. When running a PROC CONTENTS the path shown in the output is the redirected path. I have no idea if that is an issue as I am grasping at straws to figure this out.
03-28-2018 11:59 AM
03-28-2018 12:39 PM
I am trying to get some facts, including the log. This is a former client and I no longer have access to their file system and can't look for myself.
This is also production scheduled job which changes data. So rerunning it with other options like FULLSTIMER is not an option.
I don't believe this is a space issue. And I told my ex-client that. The sole reason for my question was to ask if others had ever experienced a space issue with PROC DATASETS.
03-28-2018 07:29 PM - edited 03-28-2018 07:30 PM
As we all speculated, this was not a space issue. As I said in my original question, I was skeptical. The client insisted he was and asked me to check with other (thus my post).
They had space issues in the past and jumped to conclusions that the issue was space. I was finally able to get them to send me the log and the message is very clearly a rename error.
ERROR: Rename of temporary member for XXXXXXXXXXXXXXXXX_NEW.DATA failed.
This is a production job and the above data set was the first one listed. PROC DATASETS is used to replace the prior version with the one that has the _NEW suffix. The rationale being the data step to create the data set runs for a long time and to minimize the remote possibility of contention, the AGE statement is used which only locks the data set for a tiny fraction of a second.
AGE XXXXXXXXXXXXXXXXX_NEW XXXXXXXXXXXXXXXXX;
Once I got access to the log I told them that it was definitely not a space issue.
I have seen this error before (on Unix systems) and the cause at that time was the parent directory was set so files could be created or replaced, but not deleted. The error results because the XXXXXXXXXXXXXXXXX dataset could not be deleted so the XXXXXXXXXXXXXXXXX_BAK dataset could not be renamed.
So they are now off checking to see if the parent folder settings in their production environment were reset by someone.
Thanks to everyone for your responses. Once/if the client confirms the issue is the folder not allowing delete, I will update this thread.