...
DSX – The older Information Server export format that supports only a subset of all current Information Server asset types. NOTE: This format is also available
7in a ‘7-bit
encodingencoding’; variant in which any ASCII character above DEL (127) is encoded as
\nnn
wherennn
is the relevant character’s ASCII number. This is useful when transmitting the resulting DSX via constrained communications channels.XML (referred to in the DataStage documentation as ‘Legacy XML')
ISX – A compressed XML (binary) based format which supports all Information Server asset types. To add further complexity to this picture the ISX format exists in multiple variations:
The ‘default’ format, useable by all IBM tools to represent
...
individual DataStage jobs,
An Information Server Manager-specific ISX format
...
, and
An
istool
-specific version, use when creating ‘releases’ and which supports multiple assets.
For DataStage Jobs, the DSX and ISX formats allow you to choose whether you want your export to include Job design information only, encoded-binary executable information, or both. When you choose to create an export incorporating only Job design information then that file will need to be re-compiled in any target project into which it is subsequently imported.
...
MettleCI provides the mechanisms for committing DataStage artefacts to a Git repository, testing them against Compliance Rules and Unit Tests, and deploying them to downstream environments. It’s also possible to swap Jobs' parameter values to those appropriate to each target environment. Many of these operations relay on the unique capabilities provided by the ISX format. When performing a Git commit MettleCI commits and pushes files using only contain design information and which use the ‘default’ flavour of the ISX format, and which only contain design information. Executable information is deliberately excluded but can be reconstituted further down the delivery pipeline for organisations who have a mandate which prevents the compilation of code in Production environments. See Deploying DataStage Binaries for more details. We want to be able to DIFF DSXs to compare versions in version control, or between environments. WE can’t do that with ISXs
The format in which DataStage artefacts are stored in Git only matters to a customer when they want to do something with those artefacts outside of beyond what can be achieved using MettleCI’s capabilities, most commonly accessed using its Command Line Interface. Many users have an historical attachment to DSX files for a variety of reasons: DSX is ASCII based which, despite being
Benefit | Reason | MettleCI Mitigation |
---|---|---|
ASCII is easily 'inspectable' | ||
ASCII format means DSX files can be subjected to traditional test-based diffing techniques to identify the changes between code versions | While DSX’s may be human readable they are certainly not human parsable. | MettleCI |
Can be modified by scripts (DSX Split?) | ||
Can be modified by scripts (Parameter updates) | ||
Can be parsed for anti-patterns or security violations | MettleCI provides a library of Compliance Rules to scan for coding anti-patterns, standards non-compliance, security violations, and code maintainability issues. these rules are easily modified or extended as necessary. | |
The perception that ISX files are opaque binary files to which existing build and deployment processes and can include the compiled version of the job.
...