DSXchange

Does it always fail on this record now? Is your directory close to 100%? Is this hashed file close to 2Gb in size? Is this hashd file re-created often and if not, have you looked into checking whether or not it is corrupt?

How is this different from your earlier post located here?

That is the 3rd question in a row that is very, very general. In this case if you look at the Parallel Job Developer Guide you will see that each of these stages performs a very different type of action. This recent thread touches upon some of the distinctions. Note I forgot the thread name but used...

Look at a hashed file as a database table. This differs from a flat file in several important ways. To begin with, a sequential file has no key or index . There is no answer to the "which is better" question, it is like asking "Ferrari or Nissan pickup, which is better?"; I wouldn't go offroading in...

This sounds far too much like an interview question to go into detail answering!

DSXchange has a powerful search facility which would have pointed you to Ken Bland's tech tip on hashed files or this post amongst hundreds of other hashed file related posts.

The PX transformer stage will most likely use more CPU than the switch or filter stages. But chances are that the program will not be bottlenecked by CPU so it won't make that much of a difference.

Are you using a compound key in your job? If not, then the key probably contains an invalid character from your post. Another unlikely possibility is that your file system has filled up temporarily, but then you might be seeing other errors in your jobs. If you do have a compound key then your hashe...

The dssh/uvsh commands you are invoking use the current working directory to open up the account; your CWD is not an account so you are getting this message. Issue a cd to your project directory prior to entering the shell

Line 17 is your WRITESEQ statement. You cannot write "to" a file path, you need to open that file using OPENSEQ to a file unit and write "to" that unit.

I should have thought of Occam's Razor!

Pass variables from where? From outside of the job as a parameter?

It looks like the enterprise stage is pickier about extra text than the server one - I can't see a way to work around that unless you write your own shell script that filters out that text/command and replaces the default ftp call... and that is probably more work than it is worth investing in this.

I was thinking along the lines that your windows recipient box might not have the ftp server running (easy enough to check, if you can use the command line ftp to open a connection to the windows server it is up and running). The error message seems to refer to Kerberos or other security software is...

A much more robust and acceptable method would be to declare and use a DB2 sequence to do this. You call a DB2 stage as a reference lookup to get the next value from the sequence (and increment the counter). This will work no matter how parallel your job gets since DB2 controls the concurrency and l...

This documentation error has been known by IBM/Ascential for a while; I know I reported it over a year ago and got some tracking number for it. The BASIC Guide is actually pretty solid and doesn't contain many errors or omissions (unlike the PX ones).