code version check
Moderators: chulett, rschirm, roy
code version check
Is there a way to check the version of a data stage job i.e. compare lengths of the executable?
Thanks
PeteM
PeteM
The dsx entry for each job starts with this:
Is this what you're looking for?
Code: Select all
BEGIN HEADER
CharacterSet "CP1252"
ExportingTool "IBM InfoSphere DataStage Export"
ToolVersion "8"
ServerName "name"
ToolInstanceID "project name string"
MDISVersion "1.0"
Date "2017-06-15"
Time "15.06.57"
ServerVersion "11.5"
END HEADER
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
That isnt kept up automatically.
I just checked an old job that has had many revisions and it says
MDISVersion "1.0"
Is there something you have to DO to make it work?
What we do is keep a comment field in each job with the latest change date. Its the only thing we have found to be reliable across servers and projects etc. There is a cross project compare, but it is a little flakey. Comparing DSX files works but I had to write custom code to ignore some lines that had embedded server names and other stuff that is irrelevant.
I just checked an old job that has had many revisions and it says
MDISVersion "1.0"
Is there something you have to DO to make it work?
What we do is keep a comment field in each job with the latest change date. Its the only thing we have found to be reliable across servers and projects etc. There is a cross project compare, but it is a little flakey. Comparing DSX files works but I had to write custom code to ignore some lines that had embedded server names and other stuff that is irrelevant.
I've gone with a 2 step approach for identifying version change candidates.
Step 1 is to compare the modification timestamps using XMETA. These are the same modification timestamps that you would see with an advanced find using the Designer client. This does require read access to the XMETA repository. And it does potentially result in some false positives (e.g. job may appear to have been modified based on the timestamps even when there is no identifiable version difference).
Step 2 is to take everything out of step 1 and run the cross project compare from the command line. This will eliminate the false positives from step 1 and give you a nice report of changes for those with actual version changes. As UCDI mentioned, the cross project compare is not 100% reliable, so watch out for failed comparisons.
Mike
Step 1 is to compare the modification timestamps using XMETA. These are the same modification timestamps that you would see with an advanced find using the Designer client. This does require read access to the XMETA repository. And it does potentially result in some false positives (e.g. job may appear to have been modified based on the timestamps even when there is no identifiable version difference).
Step 2 is to take everything out of step 1 and run the cross project compare from the command line. This will eliminate the false positives from step 1 and give you a nice report of changes for those with actual version changes. As UCDI mentioned, the cross project compare is not 100% reliable, so watch out for failed comparisons.
Mike
I seem to recall this being true all the way back to the 3.x versions that I started with... it had to be manually incremented to make use of the field which of course meant it was hardly ever (sometimes also known as never) 'correct'. Guess that hasn't really changed.UCDI wrote:That isnt kept up automatically.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers