UC4, Perl and TT2

Solo on 2005-11-11T00:41:47

At my day job, we use an enterprise job scheduler called UC4. I don't have experience with its competition to make comparisons, but UC4 itself has a frustrating scripting language built in. It lacks true loop constructs, has only basic expression handling (one operation at a time), and so on. I suppose we'll make a complete list of annoyances one day. For now, I'm more interested in workarounds than vendor developments.

One thing that UC4 got right is an XML-based import/export mechanism. Any object (except folders, which are purely organizational) can be exported, modified and imported. Savvy users can even create XML files from scratch and import them, but it's much more practical to edit export files IMO.

One of my major annoyances with UC4 is how difficult it is to handle the same job or job plan for multiple systems. Solution: Perl and TT2. I can embed TT2 directives in my UC4 objects, export them to XML, process the XML with perl, TT2 and a datafile, import to UC4 and generate the same object for multiple systems. Viola!

I needed to use START_TAG and END_TAG that UC4 could accomodate, '#$' and '#@' respectively (UC4 has rules about what an object can be named), but apart from that, the processing script was very simple--basically identical to the Template::Plugin::Datafile module. I had a working system in about 15 minutes, once I'd thought of it.

Is anyone else using UC4 for their job scheduling and feeling the same? I'd post some code and example objects to Perlmonks, but I wonder the audience is too small.


Re:

cog on 2005-11-11T00:56:41

I'd post some code and example objects to Perlmonks, but I wonder the audience is too small.

First, you never know. There might be someone out there (more than one someone, probably) using UC4 too (no, not me).

Secondly, if you post on Perlmonks, you might help someone going there in the future, even if you're no longer using UC4 by then.

Re:

Aristotle on 2005-11-11T02:13:06

Just a word of warning: beware of dying the sendmail.cf death. Tools whose configuration is so complex, annoying or both that they need extensive macro facilities should probably be exchanged for something saner in whatever timeframe is realistic.