DSXchange

Hi there,

I wonder you guys have any experience with EXPCOM (Expanded Company Name) Rule Set. I'm trying to use this rule set in Investigate stage for word investigation to see Pattern Report to output the columns for a pattern report and Token Report to output the columns for a token report.

Yet I'm encountering fatal error message like "main_program: Data set, file set, or file "FF_name:DSL_in.v": Non-pipe (or non-virtual data set) with .v in its name
Data set, file set, or file "Investigate_EXPCOM:InvReport_token.v": Non-pipe (or non-virtual data set) with .v in its name"

NB: I've enabled the environment variable $APT_DISABLE_COMBINATION = True and $APT_DUMP_SCORE = True. However, no more clue to share with you all.

Thanks,

Well.. I don't know about the EXPCOM rule set, but below should help

viewtopic.php?t=89199


Regards

Julio,

Thanks for your reply. I appreciate it. Yet it didn't help me out so much . I've checked Datasets directory of the project and haven't come across with any *.v file(set) or dataset.

However, I've done one more design with different rule set for instance CANAME or USNAME set and run it. Surprisingly, the same design with different Rule Set runs ok and I can see the pattern and token files for this design and they are created as expected.

In addition to that, I've provisioned all the rule set and tested via Rule Manager before posting this.

I'm just confused with EXPCOM Rule set and unfortunately there is no available documentation in IBM webpages.

I still wonder if I can use EXPCOM in Investigate stage or not.

Thanks,

DsExplorer,

As a general rule you could use any Rule Set in the investigation stages, that's the main purpose you investigate and Std with the same rule set...

Did you try to test the EXPCOM rule set in the Rule Set Management Windows? If not just try, if working OK that rule out any installation issue

Could you state your job design?

Finally look for any parameter, environment variables used in the job. Did you add them to the job's properties page?

Regards

The *.v has nothing to do with the Rule Set, so you can stop anguishing about that. When a DataStage/QualityStage job runs each link generates a virtual Data Set, the descriptor file for which has a name ending in ".v". For whatever reason, DataStage/QualityStage has detected that something associated with link DSL_in (attached to stage FF_name) and something else associated with link InvReport_token (attached to stage Investigate_EXPCOM) have been identified as not being a pipe or virtual Data Set. [See how much you can get by reading the whole error message?] As a first cut, I'd try simply re-compiling this job and seeing whether it recurs. There should be no "*.v" files in your project directory if no jobs are running; if there are (and there are no jobs running) you can delete them.

Yeah it's a bit of a puzzle, but I have seen the same thing using EXPCOM. And this was a Inv job that used a DB for both input and output.
I'll have a play around on Monday too, because it's something that's always bugged me... (A bit tragic, I know)

Hi there,

I reckon whenever the rule set is changed, [Separator List] and [Strip List] in the [Advanced Options] are changed as well. Therefore, it causes that strange error I encountered.

I've been given advice that one should take a look a the 'advanced options' in the job design, click the [Restore defaults] button and restore default separator and strip lists... and then recompile && try to run the job.

PS: I've just learnt this tip from IBM product specialist. I didn't have a chance to ask what is the rationale behind? why Investigate stage acts like this? Yet it starts working as expected.

Thank you all.

Hi,

When a rule set is used in the Investigate stage, the seplist and striplist are read and exposed in the 'advanced options'. You can change the seplist and striplist in the stage, and that would override the seplist and stiplist in the rule set. This is common practice when developing a new rule set.

The situation you faced was that you were using another ruleset first (USNAME, for example). This job ran ok. You then changed the Investigate stage to use EXPCOM. The Investigate stage should re-load the seplist and striplist from the new rule set, but it did not. It retained the 'old' version from USNAME. I believe this to be a bug and I will open a PMR to get that fixed.

Thank you for your patience and persistence!