Re: Is there a mainframe skills shortage?


<docdwarf@xxxxxxxxx> wrote in message news:eujf7f$iuf$1@xxxxxxxxxxxxxxxxxxxx
In article <574ohcF2bm2hgU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

<docdwarf@xxxxxxxxx> wrote in message
news:euil03$l33$1@xxxxxxxxxxxxxxxxxxxx
In article <57147bF29lbfkU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

[snip]

I don't think so. It is much better today than it was thirty years ago.
I
can remember getting bright eyed, bushy tailed, Computer Science grads,
sitting them down and asking them to do a three file merge in COBOL...

That's interesting, Mr Dashwood... my first response to that was
'there's
no need to do it in COBOL, one uses system utilities (DFSORT/SyncSort)
for
such tasks... but if one needs Lines O' Code to satisfy a Corner Office
Idiot then there's a single verb to manage it'.

Be that as it may... I was taught that Computer Science grads should be
designing compilers while applications jockies write the COBOL.


Sure, and guys go out to work while women mind the kids and cook dinner.

Mr Dashwood, that you see this as a matter of simple-minded prejudice
might speak of how things are done in places with which you are familiar
and little else.

A
somewhat arbitrary and constraining division of labour which, like not
letting CS grads develop applications, may prove less than optimum.

Perhaps, Mr Dashwood, it is a recognition that all edged tools are not
equal and that trying to use a chisel as an axe or a scalpel as chef's
knife might, possibly, lead to disappointment... then again, perhaps a
Manager might bleat 'It's got an edge on it... it's *your* fault that you
can't make it do what I want!'


With some justification apparently... Ironic you are discussing the finer
points of tool use when you have never used the tools I use daily. On the
other hand, I have used most of the tools you use and know the difference
between a scalpel, an axe, and a kirchen knife.


Most of them didn't even know how to approach the problem, yet these
same
guys could write a random number generator based on a binary polynomial
that
would guarantee never to repeat within so many billion samples... (Not a
lot
of call for that in the Banking industry :-))

That's why one doesn't hire CS grads to write banking apps... seems like
our educations were different.

You conveniently ignored my use of the past tense... the whole point of
this
particular discussion was that grads today are better than they used to
be,
at least that has been my experience.

Was that the point, Mr Dashwood? And here I was thinking that the point
was to use the proper personnel for the appropriate job... you know,
something that Management is concerned with.

That would be your wish to change the topic. Review the original post and
quote the context.


[snip]

Today, they would look at you and say: "Why would you want to merge
these
sequential files when you could have updated directly to a Relational
Database in ANY sequence you like and simply ORDERed the result set?"
:-)

'Because two of the files are the inputs from branches with a lot of
activity, (n) tens of millions of records per day; they are MERGEd into
a
single dump of the master table and reloaded, directly, into a
re-creation
of the master using a system utility. Do you have any idea why that
might
be superior to performing individual INSERTs?'

Actually, it wouldn't be, using todays technology.

Mr Dashwood, I have no idea what you are calling 'todays (sic)
technology'... when was the last time you loaded sixty million rows into a
table with a twenty-character primary key both ways (using a system
utility and performing individual INSERTs)?

Hmmmm... let me see... that would have been around the same time you
instantiated a table adapter to bind to your data automatically and
processed the in-memory result set with an iteration across each row
object...Ooops, might as well speak Swahili... I guess the answer on both
counts is "never".


I did this... hmmmmm, must have been four, five years ago and the results
were, by some standards, considerably different; I'd be most interested in
reviewing your data and, by doing so, learning more.

No you wouldn't. You'd be interested in confirming your already decided
conclusion based on the practices you know and understand.


Please be so kind as to begin with the hardware and database platform upon
which you did these tests... I was on (as usual) an IBM mainframe, running
z/OS (I think V1R3 or V1R4) and DB2.

You have my sympathy. Why not try a Bendix or a Hoover...?

(now, class, watch what happens when a Manager is asked, nicely and with a
'please', for facts and figures)

Yes, class, see how the busy Manager does not waste his time in pointless
arguments with the uninformed. Those of you who are genuinely interested in
what the new Data technology holds, could try these links:

http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx
http://wm.microsoft.com/ms/msdn/visualcsharp/LinqFarm01/LinqToSql01.wmv
http://themechanicalbride.blogspot.com/2007/03/dreaming-of-plinq.html
http://www.intelligententerprise.com/010327/celko_online.jhtml;jsessionid=2YLTSRCKMPFYAQSNDLQSKHSCJUNN2JVN
(Dwar...Er...People who are interested in large volumes of data might like
to comment on the "Putting the "Fun" in Functional Programming " paragraph,
in the last above. Personally, I'm not interested in a pissing contest over
data volumes ("mine is bigger than yours"), I'm much more interested in
techniques and solutions that optimise hardware (multiple cores) and query
expressions (functional programming and Lamdas) that can manipulate ANY
volume of data more effectively than most of us do currently. Today's
computer science graduates are learning these techniques, and a good thing
too...

Such techniques can obviate the old "merge sequentially and re-create"
approach, and that was where we came in...

Pete.


.

Relevant Pages
Quantcast