DSXchange

basu.ds wrote:Thanks for the quick response.
My OS is windows and i dont have an unix environment to run this

Where did anyone mention you had to have UNIX to do this? You get to the "DS shell" from your operating system, regardless of what it is.

pradkumar wrote:Array size as 1 and transaction size 50000 -- job aborted with same error.

This one surprised me, the implication being that transaction size is somehow playing a role in the heap issue... and I really don't see how that could be the case.

Never heard of either "splice" or "reuse", even after all this time with the product and on this board. Need to look them up, it seems.

Didn't say you needed to change the Oracle client, simply have your DBA add another one, an 8.1 client in this case. Then point DataStage to that client by setting $ORACLE_HOME to it in the dsenv file.

No other applications would be affected.

Oh my, even worse news. There is no guarantee of compatibility from Oracle between new clients and old databases. However, old clients can generally be used without issue against newer databases. If that 8.1 database is your only Oracle source/target, then you really need to get a matching 8.1 clien...

This isn't a DataStage issue but rather an Oracle one. What version is your Oracle database - 10.1 or 10.2? Sure seems like you should get the 10.2 client onto production since that's the one working for you.

Shouldn't be necessary.

If I had to guess, I'd venture one that you have a different Oracle client installed in Production.

I know, but there's so much stuff in there I need a 'Search Favorites' option to find anything ever again.

That transaction size is "fine" as long as you don't mind how difficult it can make an abort/restart scenario and you understand that they can slow down your processing. For example, at 4M records processed you've commited 400 times in the database. Me, I prefer doing that only once at the...

The transaction size / commit frequency is not contributing to your heap allocation issue (that is purely array size) so I would either leave transaction size back at 10000 or set it to 0. Commits complicate restarts and are an expensive operation which slow things down when done 'too often' , so I ...

First suggestion would be to search the forums for your message - ParamValue/Limitvalue is not appropriate. It has been discussed here quite a bit in the past, both the cause of the error and the solution.

Ok, but not successful why? Are you able to identify the Policy rows? Let's try this in a more "PX" fashion, shall we? Rather than the "one long string" approach, trying defining the sequential file metadata such that it matches only the Policy detail records. That should work be...

Just because a field is nullable doesn't mean you don't have to do any null handling. For example, are you writing to a fixed-width file?

Why not? What have you tried? Use stage variables to help, skip up to (inclusive) the first set of dashes and then process records until you read 'End of Report'.