Unable to Save Jobs

Pete Morris · Post by **Pete Morris** » Tue Feb 12, 2008 7:25 am

When trying to save a job the following message is encountered
'cannot open executable job file RT_CONFIG6311'

Any ideas?

chulett · Post by **chulett** » Tue Feb 12, 2008 7:28 am

Repository corruption. Have you had any issues you are aware of, space problems where DataStage is installed for example?

Can you save it under a new name? Is it just this job or, as your subject says, are you unable to save jobs right now? I would suggest trying to reindex your project and see if that helps - search the forums for DS.REINDEX for the details and caveats when attempting this.

Pete Morris · Post by **Pete Morris** » Tue Feb 12, 2008 10:24 am

Tried the rebuild index command but still get the same error.

ArndW · Post by **ArndW** » Tue Feb 12, 2008 10:28 am

from the uv shell in that project or from the command line tool in the Administrator, type "COUNT RT_CONFIG6311" and see if you get a valid count or an error message.

ArndW · Post by **ArndW** » Tue Feb 12, 2008 10:34 am

directory is full or your user hasn't sufficient permission to create files in that directory are the two most common causes. Check at UNIX whether the file already exists in that path.

ray.wurlod · Post by **ray.wurlod** » Tue Feb 12, 2008 3:33 pm

There is another possibility, particularly if you are on Solaris, where there is a hard limit on the number of subdirectories in a directory (from memory 32K). Looking at your job number (9949) and knowing that each job creates five or six subdirectories, some of which are dynamic hashed files, I would cousel looking that this possible cause as well. Try a mkdir command in your project directory.

ArndW · Post by **ArndW** » Wed Feb 13, 2008 2:41 am

The same 32K inode entry for directories exists on AIX as well.

Pete Morris · Post by **Pete Morris** » Wed Feb 13, 2008 3:09 am

Guys,
you were right, we have exceeded the unix limit for subdirectories.

Can this limit be increased or is it fixed?

ArndW · Post by **ArndW** » Wed Feb 13, 2008 4:39 am

The limit cannot be changed, unfortunately. I once wrote a little job while at a client site (they participate here, so may be willing to post the code but I no longer 'own' it so cannot post it even if I did have it available here) which went through the project directory and converted all RT_STATUSnnn, RT_CONFIGnnn and DS_TEMPnnn files from dynamic to static hashed. A dynamic hashed file consists of : (1) a directory, (2) a DATA.30 (3) an OVER.30 and (4) a .Type30 file while a static hashed file is just 1 inode without a subdirectory. Since the 3 file types above do not grow appreciably (unlike the RT_LOGnnn files) it is safe to use static hashed files for them. This solved the directory file limit issue.

It can be done quickly from the uv shell, but requires some knowledge of the UV shell, includes several steps and a bit of editing:

1. SELECT VOC WITH @ID LIKE ...DS_TEMP... AND WITH F1 LIKE F...
2. SAVE.LIST XXX
3. use your favorite editor to edit /&SAVEDLISTS&/XXX and change every line to "RESIZE {origline} 2 1 1"; add "PA" as the first line
4. EDIT.LIST XXX
"SAVE VOC XXX"
5. Then just execute the XXX paragraph with all the resizes with "XXX"

Warning - if you are unsure of any of these steps DO NOT use this method, as it does have the potential of corrupting the project.