DSXchange

If you are unfamiliar with cron on UNIX systems, perhaps a chat with your SysAdmin is in order. From the operating system command line, logged in as the scheduling user, a "crontab -l" will list all of the scheduled items for that user. It will look a little cryptic if you've never seen it...

DataStage doesn't include a "scheduler" so leverages the underlying O/S. For UNIX that means cron and a check of the crontab entries for the scheduling user will have what you need.

I don't have access to the Oracle Enterprise stage to know if / how it (array size) would be leveraged by the stage for the Load option.

Edited my post to help. Again, there are no commits done in a DIRECT=TRUE load, so don't expect to be able to control that there. And 64 is the default commit interval.

Have a look at the discussion I linked to.

Well... they certainly won't work with a direct path load as there are no commits done when DIRECT=TRUE. So, is the ROWS option working for you or not? Hard to tell for sure from the way you phrased it. Note that you may also need to increase the BINDSIZE depending on the length of your records so i...

You should investigate the use of the APT_ORAUPSERT_COMMIT_ROW_INTERVAL and APT_ORAUPSERT_COMMIT_TIME_INTERVAL environment variables. Or, if you'd rather use the Oracle OPTION, use ROWS=x there with whatever number you feel is appropriate.

Already explained the 'why' of it as best I can. Ray / Arnd / Ernie might have more insight into that.

On the contrary, that's what the Img or "Image" tags are for. Upload your picture(s) to any file sharing site and then use those tags to link to them from here.

Seems fine to me but I really don't have any jobs that are called by multiple Sequence jobs to test it out with. Worked fine for the singletons, btw.

PSFTP is a form of secure FTP which is not what the stage uses, and which is why the suggestion is to let us know if plain old ftp works for you.

Don't recall hearing of that problem before. When you did the uninstall/reinstall of the client, how did you go about that? If you didn't do all of the steps mentioned here I'd suggest you try that again, and if it still doesn't work open a case with your official support provider.

So, what do you get when you attempt to compile a job? What exactly happens? Usually, not getting the 'error box' is a good thing.

It is 'taking Arg1 into account'. I think what you're seeing is just an artifact of the way the 'Test' option works with that common storage from the Manager. I would wager that if you used it in an actual job it would work as you expect without any modifications needed.

Only thing which is anoying me is still i cannot locate the hash file on unix box. Well, it certain is there in every project... shouldn't be all that hard to find. Typically the Projects directory is at the same level as the DSEngine directory, so try this: cd $DSHOME/../Projects And see if you do...

Well, that's certainly not the default behaviour. Do you have a 'dev' project where made a copy of it that wouldn't be Read Only? It may have been changed there and the changes promoted to other projects. The one as deliverd is in the sdk/KeyMgt branch of the repository and is named 'KeyMgtGetNextVa...