Re: Is there a mainframe skills shortage?

In article <575uvjF29rv7kU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

<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]

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

So, Mr Dashwood, you made an assertion ('Actually, it wouldn't be, using
todays technology') based on what you admit, above, as a complete and
utter lack of experimental evidence. In the terms employed by those
familiar with the rules of the game of baseball this has been referred to
as 'strike one'.



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.

Mr Dashwood, you accuse me of telling a lie ('no, you wouldn't') and then
do not post data to support your assertion... in terms employed by those
familiar with the rules of the game of baseball this has been referred to
as 'strike two'.



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.

Mr Dashwood, you belittle another's experience and then, in typical
Manager fashion, respond to a request for data with a variant of 'I'm a
very busy man'... in terms employed by those familiar with the rules of
the game of baseball this has been referred to as 'strike three'.

Those familiar with the rules of baseball are familiar with the
consequence of having made three strikes... but perhaps those familiar
with baseball's more primitive antecedant play by rules which allow for
such shuffling and dodging, I am not certain.

[snip]

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

Such techniques are not reflected in your own experience when it comes to
loading sixty million rows with a twenty-character primary key into a
table of any kind, Mr Dashwood... 'none' cannot reflect, remember?

Don't worry, Mr Dashwood... I'll continue to post based on what I have
learned and what I have done, you are welcome to post based on... whatever
it is that you use as a basis, and, as usual, the readers will decide.

Class dismissed.

DD

.

Relevant Pages

  • Re: Disassembler
    ... Pete Dashwood wrote: ... 000100 AND WITH THESE AND OTHER INSTANCES IN MIND WE SHOULD, ... Does the piper ALWAYS call the tune? ...
    (comp.lang.cobol)
  • Re: Disassembler
    ... Pete Dashwood wrote: ... the source needs to be recreated from a listing? ... 'Grandpa, there aren't any tigers anywhere near here.' ...
    (comp.lang.cobol)
  • Re: The Lambda lambada...Why embedded SQL is becoming irrelevant and why you should start looking at
    ... Pete Dashwood wrote: ... Mr Dashwood, as the Italians used to say, 'Mit Geld und guten Woerte tut ... to say the same thing ) for sunsets is 'negative'; ...
    (comp.lang.cobol)
  • Re: Disassembler
    ... Pete Dashwood wrote: ... The aphorism I recall is 'He who pays the piper calls the tune'... ...
    (comp.lang.cobol)
  • Re: PIC P put to real use
    ... Pete Dashwood wrote: ... I barely know why *I* would do things, Mr Dashwood, let alone anyone ... purpose fo COBOL, which is what I was discussing. ... Many corporations are happy to put plenty of money into fulfilling corporate ...
    (comp.lang.cobol)