code version check

A forum for discussing DataStage<sup>®</sup> basics. If you're not sure where your question goes, start here.

Moderators: chulett, rschirm, roy

Post Reply
PeteM
Premium Member
Premium Member
Posts: 19
Joined: Thu Dec 15, 2011 8:50 am
Location: uk

code version check

Post by PeteM »

Is there a way to check the version of a data stage job i.e. compare lengths of the executable?
Thanks
PeteM
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

The dsx entry for each job starts with this:

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
Is this what you're looking for?
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
UCDI
Premium Member
Premium Member
Posts: 383
Joined: Mon Mar 21, 2016 2:00 pm

Post by UCDI »

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.
Mike
Premium Member
Premium Member
Posts: 1021
Joined: Sun Mar 03, 2002 6:01 pm
Location: Tampa, FL

Post by Mike »

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
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

UCDI wrote:That isnt kept up automatically.
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. :(
-craig

"You can never have too many knives" -- Logan Nine Fingers
Post Reply