To osh or not to osh?

[devnull]

A little while ago I posted a question asking, essentially, "osh, what is it good for?" I asked the question because when I attended my first DataStage class as former Orchestrate user, the instructor left me with the impression that the osh script generated from the compilation of a DataStage job was not runnable as an osh script. In fact, the primary reason we converted our Orchestrate osh scripts into dsx files we later imported into DataStage, was because we thought osh was on its way out, that the PSX runtime engine was merely a courtesy extended to those who needed to limp along on osh scripts until we converted them to DataStage jobs. Our last osh scripts holdouts were scripts that could not be neatly converted because they dynamically added properties to operators as needed based on parameters passed to the script. We were lamenting the fact that by discarding osh scripts in favor of utilizing DataStage jobs we were sacrificing the versatility of scripts in the shell environment for just another pretty GUI with less versatility. And for me, being able to dynamically add properties at runtime is a huge deal.

I just got the official word from IBM that osh is hear to say, and as others have already mentioned, osh is at the core of the parallel extender technology. I'm interested to hear (especially from osh users), if anyone is still using osh actively? If not, why?

[devnull]

.. I mean here to stay!

A little while ago I posted a question asking, essentially, "osh, what is it good for?" I asked the question because when I attended my first DataStage class as former Orchestrate user, the instructor left me with the impression that the osh script generated from the compilation of a DataStage job was not runnable as an osh script. In fact, the primary reason we converted our Orchestrate osh scripts into dsx files we later imported into DataStage, was because we thought osh was on its way out, that the PSX runtime engine was merely a courtesy extended to those who needed to limp along on osh scripts until we converted them to DataStage jobs. Our last osh scripts holdouts were scripts that could not be neatly converted because they dynamically added properties to operators as needed based on parameters passed to the script. We were lamenting the fact that by discarding osh scripts in favor of utilizing DataStage jobs we were sacrificing the versatility of scripts in the shell environment for just another pretty GUI with less versatility. And for me, being able to dynamically add properties at runtime is a huge deal.

I just got the official word from IBM that osh is hear to say, and as others have already mentioned, osh is at the core of the parallel extender technology. I'm interested to hear (especially from osh users), if anyone is still using osh actively? If not, why?

[ray.wurlod]

While not an active user of direct osh, I agree with the assessment that it's unlikely to go away any time soon; that judgment is based on my understanding of the DataStage architecture, which remains 100% reliant upon the parallel execution technology acquired from Torrent Systems.

The only maybe is that they may deprecate some of the operators. My experience is that IBM goes on supporting deprecated functionality way longer than other vendors.

[Andet]

I/we use osh extensively. It's the fastest way to move huge tables from one server to another: write a .ds from the table, parallel scp or ftp from one server to another for each partition of the .ds, and read the .ds into the table. Of course the two servers have to have the same partition setup. Once you've scripted it, it's a screamer. just keep the metadata definitions up to date.

Additionally, you can run sql queries in osh, and get the advantages of parallelism without the overhead of DS. (of course this can be argued....)

Ande