Hi,
We were trying to do export full project from manager. while doing this we are geting the following errors
1.Cannot open executable job file RT_CONFIG9621
2.Cannot open executable job file RT_CONFIG9391
3.Cannot open executable job file RT_CONFIG9190
4.This item has no design time information and lastly
Run-time error '91' : Object Variable or with block variable not set
After throwing the last error, the manager is shutting down automatically.
Please help us in this regard
Thanks in advance[/quote]
Run-time error '91'
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Run the following query from the Administrator for the first three jobs to get their names:
Then again for 9391 and 9190, then try recompiling them and see if that helps.
Code: Select all
SELECT CATEGORY,NAME FROM DS_JOBS WHERE JOBNO = '9621';-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Craig,
Thanks for the reply.
I ran the query said by you, i got the job names, but when i tried to open them, i am getting a error called "This item has no design time information"
The project we are trying to export is version control project. so all the 3 jobs are the same but different versions.
Is this error "This item has no design time information" of 3 jobs causing the problem for export? If yes, please advice me what can i do.
Thanks for the reply.
I ran the query said by you, i got the job names, but when i tried to open them, i am getting a error called "This item has no design time information"
The project we are trying to export is version control project. so all the 3 jobs are the same but different versions.
Is this error "This item has no design time information" of 3 jobs causing the problem for export? If yes, please advice me what can i do.
OK, that changes things slightly. Jobs in Version Control projects are not compiled. And 'no design time information' means it can't find the actual job design, which is further confirmed by the RT_CONFIG error.
Have you tried what Ray suggested, see if it behaves differently? You migh also try manually copying the config directories from the original projects for the jobs in question into the VC project. It won't actually "fix" anything but could stop the errors. To actually fix it you should contact your official support provider, in my opinion.
Have you tried what Ray suggested, see if it behaves differently? You migh also try manually copying the config directories from the original projects for the jobs in question into the VC project. It won't actually "fix" anything but could stop the errors. To actually fix it you should contact your official support provider, in my opinion.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
More info
Hi !
I am just providing some more info regarding the problem we are facing. This might be relevent.
Our vesion control project has hit the AIX inode limit of 32767 directry entries in the project directory. we are unable to create any more directoy entries in the project directory.
It manifests itself when we try to initialize a job into the project. We get a message saying "Error on CREATE.FILE command. Unable to create operating system file RT_CONFIGxxxx file."
After the error message however, i creates a new version, say 1^12 for the job in question.
So - could the above errors be because version control thinks it has say version 1^12 of the job but the file does not exists ?
I am just providing some more info regarding the problem we are facing. This might be relevent.
Our vesion control project has hit the AIX inode limit of 32767 directry entries in the project directory. we are unable to create any more directoy entries in the project directory.
It manifests itself when we try to initialize a job into the project. We get a message saying "Error on CREATE.FILE command. Unable to create operating system file RT_CONFIGxxxx file."
After the error message however, i creates a new version, say 1^12 for the job in question.
So - could the above errors be because version control thinks it has say version 1^12 of the job but the file does not exists ?
vishal
Yes, of course. I haven't had access to an AIX system for more years than I'd care to admit, so specific advice will need to come from other folks like Arnd who seems to be on it right now. I remember there are games you can play to convert the internal hashed files from Type 30 to some other type to conserve on directory entries - that or simply start using a new version control repository going forward. Or both.
If you take that route, I'd suggest you start everthing off in there at the next major number (2^1) so as to differentiate them from the entries in the old repository, which I assume are all 1^something.
If you take that route, I'd suggest you start everthing off in there at the next major number (2^1) so as to differentiate them from the entries in the old repository, which I assume are all 1^something.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
thanks for your response chulett.
For the version control project issue, we called up ibm tech support and they advised us to export the project and just import it into a new version control project. They say, that will somehow magically reduce the number of diretory entries. I don't understand how but i am going ahead with that advise anyway. Just can't get the project to export. Do you think deleting version 1^10, 1^11 and 1^12 of the job in question by using "component deletion" feature of version control can help ?
I also read about changing the dynamic hash files to static hash files and thereby reducing the number of directories. But that seems like a very tedious process. As i understand it, i will have to manually convert each RT_XYZ file ? Besides, sooner or later i will hit that limit again. Won't I ?
A question. Why doesn't IBM tech support know or suggest any of this stuff that i read about at dsxchange ? They are not even in India. I mean the people I talk to do seem to be Americans.
For the version control project issue, we called up ibm tech support and they advised us to export the project and just import it into a new version control project. They say, that will somehow magically reduce the number of diretory entries. I don't understand how but i am going ahead with that advise anyway. Just can't get the project to export. Do you think deleting version 1^10, 1^11 and 1^12 of the job in question by using "component deletion" feature of version control can help ?
I also read about changing the dynamic hash files to static hash files and thereby reducing the number of directories. But that seems like a very tedious process. As i understand it, i will have to manually convert each RT_XYZ file ? Besides, sooner or later i will hit that limit again. Won't I ?
A question. Why doesn't IBM tech support know or suggest any of this stuff that i read about at dsxchange ? They are not even in India. I mean the people I talk to do seem to be Americans.
vishal
I'm not sure either how a simple export/import will reduce the number of directories needed. The other issue you're going to have is you will not have a working VC project after you do that. Simply bringing over the jobs is not enough, there are five magical hashed files (which an export does not include) that turn a normal project into a "version control" project:
APM.BATCH
APM.BATCH.MEMBERS
APM_BP
APM.VERSION
APM.VERSION.XREF
So, try this. Create your new version control project and then connect to it once so that all of these account-based hashed files are created first. Then import your exported jobs (or reverse that order, doesn't matter). Lastly, copy the above hashed files over to the new project and you should be in pretty good shape there. The 'connect to it once' part before copying over your old hashed files is the important part.
Can't really answer the IBM Support question, they do have some pretty smart peoples over there that I've spoken with. However, it's just like in chess - you've got to get past the pawns to get to the queen. As for DSXchange, in our full might we do outnumber them, and some of the premium peoples (not me) worked for Ascential back in the day and actually wrote some of the stages (etc), so being in on it from its genesis they have a pretty good idea How Things Work.
APM.BATCH
APM.BATCH.MEMBERS
APM_BP
APM.VERSION
APM.VERSION.XREF
So, try this. Create your new version control project and then connect to it once so that all of these account-based hashed files are created first. Then import your exported jobs (or reverse that order, doesn't matter). Lastly, copy the above hashed files over to the new project and you should be in pretty good shape there. The 'connect to it once' part before copying over your old hashed files is the important part.
Can't really answer the IBM Support question, they do have some pretty smart peoples over there that I've spoken with. However, it's just like in chess - you've got to get past the pawns to get to the queen. As for DSXchange, in our full might we do outnumber them, and some of the premium peoples (not me) worked for Ascential back in the day and actually wrote some of the stages (etc), so being in on it from its genesis they have a pretty good idea How Things Work.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Update
The issue with the export was resolved by using a different client as suggested by IBM. So basically the manager client on one machine was giving all those errors that started this thread. We switched to a different machine for taking the export and it worked. Don't ask me how.
After we took the export of the version control project and imported it into another new project it seems to have reduced the number of directories from 32767 to 32588 just as IBM said it would. Thanks Craig for telling us about those 5 files/directory to copy over. It's all working now.
However, the number of directories is still in the same ball park and will hit the 32,767 limit pretty soon again.
It's for this reason we have decided to bite the bullet and start using a completely new version control project going forward. This thread may be closed now.
After we took the export of the version control project and imported it into another new project it seems to have reduced the number of directories from 32767 to 32588 just as IBM said it would. Thanks Craig for telling us about those 5 files/directory to copy over. It's all working now.
However, the number of directories is still in the same ball park and will hit the 32,767 limit pretty soon again.
It's for this reason we have decided to bite the bullet and start using a completely new version control project going forward. This thread may be closed now.
vishal