...
The following observations about Message Handlers, based on Data Migrators' decades of field experience, lead us to suggest switching away from using themsuggest DataStage developers and architects should reconsider their use.
Message Handlers are not DataStage assets
Message Handlers are not an asset of DataStage. IBM documentation notes that they cannot be managed the same way as jobs, sequences, parameter set definitions, etc., are managed. They cannot be placed in an ISX export of their own, they have to be associated with a jobJob.
| Note |
|---|
"You can use the IBM® InfoSphere® Information Server Manager (the deployment tool) to move, deploy, and control your IBM InfoSphere DataStage® and QualityStage® assets." However, message handlers cannot be managed individually using the IS Manager or |
Therefore MettleCI does not can’t handle them in the conventional way for the reasons above. Project level -Level Message Handlers are not can’t be handled at all. and and , while special provisions must be made for Job level -Level Message Handlers. They have to have names corresponding to the job, they have to be kept in a specific place, and there is a step required to “inject” them into the job’s ISX file before they can be deployed to a target environmentRefer to this page to understand the complicated manual process that is required to obtain and on-board Job-Level Message Handlers as you apply devops to your DataStage solution. These considerations mean extra work during all migrations and deployments.
Message Handlers may disguise poor development practices
High-performing DataStage development teams rightly view message handlers as something that disguises risks disguising poor coding or job Job design decisions. They are most often found in organizations that mandate that Jobs should run without warnings but with little else to encourage their developers to remediate the root cause. As a resultUnder this design standard, Jobs are often set to Abort (e.g. via an After Routine) if they generate warning messages. Unfortunately, this often leads to developers - especially those under pressure - applying message handlers Message Handlers to quickly get compliant and move on.
Message Handlers are subject to regression
As previously highlighted, the very nature of IBM’s tools for managing Job Level Message Handlers in Information Server means any automation solution for them will be at risk of permanent regression with future IBM Fix Packs and Releases. Since they are not “assets”, they may be regarded as “second class citizens” when breaking changes are introduced.
Conclusion
In view of the above drawbacks, organizations should refrain from it’s recommended that organizations reconsider the wisdom of using Message Handlers (by refactoring jobs to not produce warnings or errors) and should configure their Job Schedulers and, instead, focus on refactoring Jobs to eliminate (or at least minimise) warnings or errors. In conjunction, Job Schedulers can be reconfigured to be able to allow Warnings in exceptional circumstances. That In this way, high standards of development are generally maintained development standards improve but in the unlikely situation that there is no alternative, Job Warnings can be allowed.Even in the absence of automation challenges, we suggest the general situation with Job Level Message Handlers ought to trigger customers to reconsider their use (or at least modify the tolerance of Warning Messages by dependent systems) and refactor accordingly. This can be done over time but should be planned for and carried out as soon as practicalapplied consciously, instead of by default.