DSXchange

What is the purpose of the osh script that is generated in a DataStage job compile? Can it be used with the osh engine? Or is it just for nostalgic purposes?

Shhhh. A PX job is just an OSH script generated plus custom operators from the GUI designer. The Orchestrate engine is now the PX engine, just by another name. I do believe you can still handcraft your OSH scripts if you'd like.

kcbland wrote:Shhhh. A PX job is just an OSH script generated plus custom operators from the GUI designer. The Orchestrate engine is now the PX engine, just by another name. I do believe you can still handcraft your OSH scripts if you'd like.

Well way back when I attended the DataStage Parallel Xtender class I was told we couldn't use the osh scripts that were generated by a compilation. At least, we couldn't use them as is.

Is there anyone out there who writes new osh scripts?

I tried updating a current osh with a db2read operator using client_instance, user and password parameters (which can be used in DataStage job) but I couldn't get the osh to work. In the old Orchestrate environment, you had to have a local database connection to use a db2read operator. We are moving away from local connections to remote database connections.

Any thoughts?

I know some existing Orchestrate customers who "backed in" to owning DataStage PX. By release 7.5, I would understand that handcrafted OSH scripts are poo-poo'd. I guess the core engine has been modified such that a from-scratch OSH script may not be possible. Your original question was not about modifying a GUI generated OSH script, but whether it was still required.

Someone else should chime in if they're handwriting OSH scripts using DS PX. I'll shut up for awhile.

kcbland wrote:I know some existing Orchestrate customers who "backed in" to owning DataStage PX. By release 7.5, I would understand that handcrafted OSH scripts are poo-poo'd. I guess the core engine has been modified such that a from-scratch OSH script may not be possible. Your original question was not about modifying a GUI generated OSH script, but whether it was still required.

Someone else should chime in if they're handwriting OSH scripts using DS PX. I'll shut up for awhile.

No my original question was what is the generated OSH good for? Can I use it for anything? We were among those Orchestrate customers who, as you say, were backed in to owning DataStage PX. We liked osh because we could do things with it in Unix shell scripts that are a bit more difficult to do in the GUI environment, like dynamically add parameters (not just set existing ones as only the GUI permits). Osh scripts did not require compilation (except for buildop compilation), DataStage jobs do require it. So my original question is left unanswered. What is the generated OSH for?

You have an option to not generate the osh script but still you will need to compile the jobs. These so far as I have expereinced are useful to undertand what is happening internally. Or only probably for those EXCLUSIVE companies who dint have Orchestrate to work with as now with PX.

DataStage jobs execute the generated osh. You can find the shell scripts that organize all of this in the RT_SCnnn directory, where nnn is the job number from DS_JOBS.

I also find it useful sometimes to inspect the generated osh (perhaps in conjunction with the job log) to diagnose those little irksome problems where things run but maybe not exactly how I expected. The generated osh tells you exactly what is programmed to happen.

Ray, do you know if it is possible to hand-write an OSH script as if a GUI didn't exist? Existing Orchestrate customers should have some backwards compatibility as of release 7.5, I hope.

I can only suggest that, theoretically, there's no reason why not. Examine the other files in RT_SCnnn to learn about the interface between the operating system and osh.

Not so sure about how you'd include custom routines - need to read some more in the Orchestrate Operators manual for that!

I use osh all the time. I have a local connection, so that makes things very easy. One common use is a script that moves a DB2 table from one server to another by exporting(db2read) to partitioned datasets, FTP/NDM/SCP the data sets from one server to another concurrently(big pipe), and then load using db2write. A lot faster than the sequential export, ftp, and load and still faster than partitioned exports, ftps and loads.

You can also run sql under osh so as to get full advantage of partitioning. I used to do that under 6.+ and it should still work under 7.5.

Ande