Using Mercator 6.0 What is the latest version

[Jomercat]

Hi all,

Since Ascential aquired the Mercator application, I lost track of the latest versions.

Does anybody know if I can upgrade the Mercator 6.0?

What is the latest version?

I browsed the ascential.com web site, but I do not see anything mentioning to upgrade from Mercator to XXXXXX. Perhaps I waited too long.

Jose.

 

[JuJutsu]

The 6.0 release had a very short life, was replaced by 6.5.0. Two service packs brought this to 6.5.2, then 6.7 was released, then 6.7.1, then Ascential purchased Mercator and 7.5 and 7.5.1 were released. Then IBM bought Ascential and 8.0 was just released. You can have a number of problems trying to get from 6.0 to 8.0, depending on what your maps & systems are doing. If you are stable on 6.0, you systems and maps can't be too complex.



JuJutsu - Jeff S.
Support Analyst

 

[Jomercat]

Jujutsu,

Thanks for replying.

Has anything been improved on debuging?

Thanks.

Jose.

 

[eyetry]

not 'Jujutsu' but I can answer yes! They introduced a debbugging tool. You can now step through maps to help ID where a problem exists. Pretty handy! During the beta I used it on two maps that our developers were having an issue with and ID'd the issue right away.

There is also a performance tuning tool so you can determine where your maps are spending time. Architecture is excited about that feature as they spent month on a new environment (non-TX) trying to ID where the performance issues were. So as we merge TX maps to the new environment we'll be able to get a better feel for what's going on.

Other enhancements over 6.0 are log file settings allow you to log on errors only. I believe you can now point to F_maps that belong other map files. You can run multiple processes (tie events to separate processes so if one system crashes it won't crash everything). Oracle column-based triggering... and some other stuff...

They have not simplified the trace files. It still faster to use SQLLOADER to bulk load large files that via DBID. If you liked the launcher.txt file it's gone.

I'd say, over all, 8.0 is a big step in the right direction.

 

[JuJutsu]

Launcher.txt is not gone. It is now compoundsystem_timestamp.txt or, if you are multi-processing, MSL_Timestamp.txt in the /logs or \logs (if you are smart) directory

Also, you can turn on adapter tracing while the Event Server is running, and turn it off again. More and better debugging tools too.



JuJutsu - Jeff S.
Support Analyst

 

[eyetry]

I agree, 8.0 is looking very good...... but.....

'Launcher.txt is not gone....." The old 'Launcher.txt' file could be sent to any location with any name. The new files are restricted to the 'installation\logs' directory which we don't give developers access to, in production. This means that one needs to create an event to copy the file to an alternate, accessible, location if using it as part of a debug process. Not a big deal at all but less than convenient.

It the same thing in 7.5.* too and its one of the reasons I held off promoting an upgrade. For us 6.7.1 is meeting our needs and didn't see enough benefit to justify the upgrade expense. There's no doubt in my mind about going to 8.1

The good news is that when I write the related maps I'll probably see if there's anything I can enhance it with.

eyetry

PS: Just in case people are thinking I'm a TX sales rep I'm not! I'm just pretty excited about what I've seen. Opppss, I did it again...

 

[JEMIAZ]

As a user I think it is about time a version was released that made the upgrade process really saleable internally.

Haven't installed 8.* yet although on paper alot of the enhancements look good for developers. They don't appear to add anything major for the man paying the upgrade bills - the IT director and the end user.

True scaleability, proven fault tolerance compatability, active service management are things that make my boss take notice.

As a developer I'm excited but its not enough!

Tim

 

[Jomercat]

I do not see any mention of Mercator on the Acential web site.

How do they call it now?

Jose.

 

[eyetry]

IBM WebSphere DataStage TX

Not sure what you mean by "True scaleability, proven fault tolerance compatability". Could you clarify?

I sold our Director two levels...

1. Debugging tool will speed up development (pretty fast already though)

2. Performance tuning. We are moving to Java(TX not affected yet). When our development team moved the new code in there was a lot of performance issues. Slow connections, excess processing etc.... Due to the volume of code and related resources they had a heck of a time figuring out where problems were. They finally located a tool that would work like this new TX feature. Saved a lot of time. He really likes the concept.

Now, while the Director is ready and willing to upgrade, I want to wait for the first major service release. My tests went pretty well, overall. But, when I beta'd there were some issues specific to us. Haven't had a chance to test all of the fixes but the ones I looked at seem good.

I'd also like to see something done about bulk-loading but that's an old issue that will probably never get fixed.

 

[JuJutsu]

Bulk loading is best handled by DataStage or DataStage PX if you require really huge amounts of data. Even if you don't plan on upgrading the run time environment, you can use the 8.9 Design Studio to tune and debug a copy of your current version and just apply the changes.

JuJutsu - Jeff S.
Support Analyst