IIS 8.0.1 MsgHandler migration from DataStage 7.5.2

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
cundyp
Premium Member
Premium Member
Posts: 53
Joined: Tue Feb 06, 2007 10:57 am

IIS 8.0.1 MsgHandler migration from DataStage 7.5.2

Post by cundyp »

IIS 8.0.1 MsgHandler migration from DataStage 7.5.2

We are in the process of migrating production jobs from DataStage 7.5.2 to IIS 8.0.1 DataStage.

The problem that we are currently having is how to equate the DataStage
7.5.2 Message IDs with the IIS 8.0.1 DataStage Message IDs. It appears that all Message IDs in IIS 8.0.1 DataStage are preceeded with 'IIS' plus the structure is different.

IBM case 708183

IBM Answer: You are correct that the message ids are not migrating properly.

Note: We have escalated this to a P2 priority.

Anyone have any ideas on how to approach this problem?
Pete Cundy
Leawood, Kansas
vmcburney
Participant
Posts: 3593
Joined: Thu Jan 23, 2003 5:25 pm
Location: Australia, Melbourne
Contact:

Post by vmcburney »

You could take the opportunity to re-evaluate what message handlers you need by running all your jobs through a testing environment and downgrading the warnings that show up and had accepted under version 7. Being a new version of DataStage you might find some old warnings no longer happen and some new warnings appear.
cundyp
Premium Member
Premium Member
Posts: 53
Joined: Tue Feb 06, 2007 10:57 am

Project level MSG Handlers

Post by cundyp »

We currently have implemented only project level MSG Handlers, one for each of the projects. We have three projects migrating into IIS 8.0.1 production.

Our developers would like to add more specific Msg Id MSG Handlers.
Pete Cundy
Leawood, Kansas
vmcburney
Participant
Posts: 3593
Joined: Thu Jan 23, 2003 5:25 pm
Location: Australia, Melbourne
Contact:

Post by vmcburney »

I prefer project level message handling to job specific as they tend to be easier to manage over time and therefore less risky. If you start to spread your message handling across jobs it becomes very difficult to maintain documentation and testing around them. If you have a specific job that needs a message handler that other jobs should not have then you could redesign that job.
Post Reply