DSXchange

Here's the rub... it sounds like the original job is the one that went south.

So... you took PX job A and tried to save it as PX job B but couldn't for some unknown reason. When you were able to check again, PX job A is now an empty Server job?

Ah yes, Locate. Exact match without all the fuss.

Put something around each occurance in the list to check againts and then do the same for the value you need to check so they become unique, like single quotes. For example: If (Index(Convert(",",@FM,"'CALA','LTRA','OOARCAL','OOARLTR','OOAY'"), "'":dedup...

Yes, exactly. Edited my response to make that more obvious.

Because the Index function finds 'CAL' in 'CALA' and 'LTR' in 'LTRA'.

No. Without having the mainframe '390' version of DataStage, the assumption is that you will arrange to have the data extracted from the mainframe system and tranferred to the DataStage server. Once there, the CFF stage can then be used to read it.

No worries... and by now I think we all expect a Perl solution from you at times like this.

PhilHibbs wrote:Additional info: or should that be, WTF8?

Sorry, just noticed this and had to laugh.

Whew, better now.

Well... it's in there with all of the other DataStage pdf 'Docs' on your PC where you installed the client. Take a peek!

A slightly different assumption and answer: the same as they would have in any other environment and/or tool.

I haven't seen any such assumption about people's understanding, if anything it's usually the other way around. I for one will click on a user's name to see how they have ranked their own knowledge of the product and use that to craft an answer. No guarantees if someone has been overly generous in t...

What kind of help do you need? Like most things, there are many ways to skin this cat. One such... 1. Pass in a full ISO timestamp 2. Use the TimeDate() function to get the current date/time 3. Reassemble the output in ISO format 4. Directly compare the two strings Or use whatever functions tickles ...

union all is more performant than UNION because a UNION is a distinct. Specifically, a UNION ALL simply returns the results of all queries. A UNION must first get the results of all queries and then so a 'SORT DISTINCT' on the results, so it obviously will take longer and more processing resources....

Time to mark this post as Resolved then!