Fatal error shared library xmloenu.dll failed to load

qt_ky · Post by **qt_ky** » Sun Sep 11, 2011 9:31 am

I've run across an interesting fatal error on a relatively new server:

main_program: Fatal Error: Fatal: Shared library (xmloenu.dll) failed to load: errno = (2), system message = (0509-022 Cannot load module . 0509-026 System error: A file or directory in the path name does not exist.)

This is from a DataStage 8.5 parallel job with XML Output stage... on AIX. I searched forums on the DLL mentioned and did not find this error. Why would the AIX version be looking for a DLL file?

Just curious if anyone has seen this error before. If not then I will plan to open a support case.

qt_ky · Post by **qt_ky** » Sun Sep 11, 2011 9:06 pm

When I open the XML Output stage in the repository under Stage Types, the properties show .dll files. When I compare those to the new server I just setup, the new server has .so files in the same properties. Both servers are on AIX. I am guessing now that the way the other server was migrated was not so clean.

chulett · Post by **chulett** » Sun Sep 11, 2011 10:02 pm

That is odd... how exactly was it 'migrated' and from where?

ray.wurlod · Post by **ray.wurlod** » Sun Sep 11, 2011 10:27 pm

Has the XML Pack been installed in the new location? Is your shared library search list set correctly?

jwiles · Post by **jwiles** » Mon Sep 12, 2011 1:38 am

I too am curious about the migration.

If I hadn't already done my thinking for the month I might have a suspicion about it...

qt_ky · Post by **qt_ky** » Mon Sep 12, 2011 7:23 am

The AIX server with the DLL not found issue was migrated (by the vendor) from IIS 8.1 WIN to IIS 8.5 WIN, as an intermediate step, to IIS 8.5 AIX. I have found that the xml*.so files do exist on the server, but of course the xml*.dll files do not, as expected. The stage type definitions are read-only, so I have opened a support case to find out the resolution. I'll post what it turns out to be.

chulett · Post by **chulett** » Mon Sep 12, 2011 7:31 am

So you didn't actually migrate 'the server', correct? To me, that would mean some sort of backup/restore whole-blood copy of the file structures but that wouldn't be prudent unless so many things were identical across environments, including the operating system. I'm assuming your vendor actually migrated the projects from one server to another, using export/import via dsx files.

If so, sounds like that process is a little broken.

However, further pondering on this has me second-guessing things. Why the intermediate step of 8.5 on Windows? That wasn't necessary to go from 8.1 Windows to 8.5 UNIX... unless a direct copy was then involved.

chulett · Post by **chulett** » Mon Sep 12, 2011 8:05 am

jwiles wrote:If I hadn't already done my thinking for the month I might have a suspicion about it...

Dang, James. You need to more careful rationing your thinks.

jwiles · Post by **jwiles** » Mon Sep 12, 2011 10:06 am

Yup. However, the third cup of extra-strength java this morning is leading to this question: Did the migration include the import of job executables? Or maybe environment variables?

Regards,

qt_ky · Post by **qt_ky** » Mon Sep 12, 2011 10:56 am

Unfortunately all that migration was done on site by the vendor before I arrived and I don't really have any details as to the rhyme or reason they did what they did. We didn't have any XML jobs to migrate so this problem was not tested until now, when I try to create a new job with XML stages.

I've had some interesting post-migration support cases. One involved a Windows path repository property reported as an ISALite failure on IIS 8.5 AIX. So it makes me think at some point, perhaps after manipulation, the repository was copied (DB2 backup and restore?) across versions or at least across platforms.

jwiles · Post by **jwiles** » Mon Sep 12, 2011 9:18 pm

Do you have any info on how the migration from 8.1 to 8.5 was performed? Was the IBM Concierge Program utilized at all? If your suspicion about the repository is correct, I could see that as a possibility although I can't see a real reason for that. It's not a step I've heard of being done before.

I bet someone included stage types when exporting jobs from the Windows server and imported stage types when importing to the AIX server.

Have you tried creating a new project on the afflicted server and creating an XML job there to see if it will work? With any luck the Template project was not corrupted like this other project.

Regards,

qt_ky · Post by **qt_ky** » Mon Sep 12, 2011 9:28 pm

I really don't have much info. I know for the 3 steps, each one was on a separate physical server. I know IBM was on site with an engineer at the time. XML was just missed/not tested because it wasn't used at the time.

The DLL errors are reported from a brand new DS project. I've checked other DS projects' stage type properties and found the DLL references there also, so I would guess either the project template was copied over from Windows or if those properties are coming from the repository, it slipped through somewhere. I have a ticket open w/ engineering now. I'm curious what the solution will be. I have a good server where the XML job runs fine, so we could possibly copy a fix over from there. It's a little too internal for me to know where to dig!

qt_ky · Post by **qt_ky** » Tue Nov 15, 2011 9:15 pm

I worked with support on a PMR to resolve the DLL errors on our AIX server last month and it has been resolved. Support had me run a number of commands I've never had to run before or again since. The commands deleted all the stage type definitions from the server across all projects, and then recreated them.