We're running DataStage EE under USS on the mainframe and my developers are complaining about the length of time it takes to compile parallel jobs.
The mainframe is quite heavily loaded, but the time required does seem excessive (up to half an hour for jobs with 20 or so stages in them).
We have increased scheduling priority via WLM (Workload Manager), which helped a bit, but it's still pretty bad.
Can anyone suggest further optimisation which we could try?
Thanks for any help.
Rob.
Long compile times under USS
Moderators: chulett, rschirm, roy
RobJ,
have you noticed a difference between jobs with and without transform stages? Oftentimes a job (even a very complex one) with no transform will compile quickly whilst a simple job with a transform might take a long time. If this is the case, it might have to do with the c++ compiler.
have you noticed a difference between jobs with and without transform stages? Oftentimes a job (even a very complex one) with no transform will compile quickly whilst a simple job with a transform might take a long time. If this is the case, it might have to do with the c++ compiler.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Yes, it does appear to be the Transformers which take the time.ArndW wrote:RobJ,
have you noticed a difference between jobs with and without transform stages? Oftentimes a job (even a very complex one) with no transform will compile quickly whilst a simple job with a transform might take a long time. If this is the case, it might have to do with the c++ compiler.
What, if anything, can be done to speed up the C++ compiler?
We're invoking the compiler like this:
c++ -+ -DRW_COMPILE_INSTANTIATE -D_OS390 -D_ALL_SOURCE -DYYDYNAMIC -D_M
SE_PROTOS -Wc,DLL,EXPORTALL -W "0,langlvl(LONGLONG)" -D_SHR_ENVIRON -D_OPEN_SOUR
CE=3 -Wc,"float(IEEE)" -DIEEE_754=1 -D_AE_BIMODAL -D__IOC_ANSI_STREAM -D_XOPEN_S
OURCE_EXTENDED -c
and the linker like this
c++ '-+ -D_OS390 -D_ALL_SOURCE -DYYDYNAMIC -D_MSE_PROTOS -Wc,DLL,EXPORTALL
-Wl,dll -W "0,langlvl(LONGLONG)" -D_SHR_ENVIRON -D_OPEN_SOURCE=3 -Wc,"float(IEEE
)" -DIEEE_754=1 -D_AE_BIMODAL -D__IOC_ANSI_STREAM -D_XOPEN_SOURCE_EXTENDED
(Obviously, the command lines are wrapping here.)
Any suggestions?
Rob.
I wish I did have suggestions. I think the compiler is licensed by number of concurrent users, and processes will wait for a free slot when that number is reached; so perhaps part of the long compile times might result from this bottleneck. But this is conjecture on my part and might be completely wrong.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
I've been digging a bit further and although the time is related to compiling transformers, it's not actually the C++ compiler, which provides the sub-second response times expected.ArndW wrote:I wish I did have suggestions. I think the compiler is licensed by number of concurrent users, and processes will wait for a free slot when that number is reached; so perhaps part of the long compile times might result from this bottleneck. But this is conjecture on my part and might be completely wrong.
The time is all "startup time" for the DataStage process which actually submits the compile jobs. (If you look in the job directory under USS you'll see a bunch of files related to the transformers with extensions such as .trx, .trx.osh and .trx.sh
The .trx.sh scripts are run as part of the job compilation, invoking osh to process the transformers. There seems to be a huge overhead (over a minute) here.
So, the question now becomes: how to optimise the osh startup time?
Rob.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
That, dare I suggest, is an issue for the vendor. How about lodging an enhancement request? They, too, are new to USS, and doubtless are looking for ideas about improving things.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
The problem is (almost) the same on busy PX sites - the last one I was at had similar wait times for compilation of jobs with transform stages. I think the approach DS takes is the same in both implementations, so hopefully by making the compile quicker on native unix it will also speed up the virtual unix one.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>