Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. 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

    7

    in a ‘7-bit

    encoding

    encoding’; variant in which any ASCII character above DEL (127) is encoded as \nnn where nnn is the relevant character’s ASCII number. This is useful when transmitting the resulting DSX via constrained communications channels.

  2. XML (referred to in the DataStage documentation as ‘Legacy XML')

  3. 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:

    1. The ‘default’ format, useable by all IBM tools to represent

...

    1. individual DataStage jobs,

    2. An Information Server Manager-­specific ISX format

...

    1. , and

    2. 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.

...