Cobol - Re: OT (Maybe): ERPs

Author

Re: OT (Maybe): ERPs

steve.t

2005-01-26, 8:55 pm

Define success.
* Is it the actual implementation and users using the new system?
* Is it that the end users actually like the new system and its
functioning?
* Is it that the DR/Plan can be tested and things work at the DR site?

Or, in the case of a certain Electric Utility (those folks that are
said to have brought you the NE power outage) is it that upper
management declared the new system to be a success regardless of what
the end users were complaining about?

The problem boils down to not being able to do all of the I/Os needed
for an application system. When you have to have one system running the
database, another running the web server, yet another running the
applications and they all have to communicate across the same network,
what do you think happens next? Add to this all the I/O that must be
done by each of those "hosts" for system servicing, and local file
processing.

Take any mainframe (Honeywell, IBM, Unisys, etc.) and look at how they
are able to run all of those functions within the same box. The
critical interprocess communications I/O is done within memory at
memory access speeds. The only physical I/O that needs be done in this
case is local file servcie I/O, data base I/O, O/S and communications
I/O with/to the end users. And all of those are basically done with
TRUE Parallel processes.
To that end me thinks your statistics are very skewed.

Steve.T

Robert Wagner

2005-01-26, 8:55 pm

On 26 Jan 2005 12:21:11 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>Define success.
>* Is it the actual implementation and users using the new system?
>* Is it that the end users actually like the new system and its
>functioning?
>* Is it that the DR/Plan can be tested and things work at the DR site?

It was just a customer count. No doubt a small percentage bought the
thing and never installed it. A comparable small percentage of
mainframes are gathering dust. Neither alters the macroscopic fact
that there are more ERP customers than mainframe customers (the number
of shops/installations would be larger for both).

>Or, in the case of a certain Electric Utility (those folks that are
>said to have brought you the NE power outage) is it that upper
>management declared the new system to be a success regardless of what
>the end users were complaining about?

That's been happening in mainframe shops for 40+ years. Technology
doesn't change human nature.

>The problem boils down to not being able to do all of the I/Os needed
>for an application system. When you have to have one system running the
>database, another running the web server, yet another running the
>applications and they all have to communicate across the same network,
>what do you think happens next? Add to this all the I/O that must be
>done by each of those "hosts" for system servicing, and local file
>processing.

Mainframes also have to transport data from disk drive to CPU memory.
IBM's ESCON, which runs at 200mb/s, is slower than 2gb/s Fibre Channel
and 1.3gb/s SCSI-3.

>Take any mainframe (Honeywell, IBM, Unisys, etc.)

Honeywell stopped making or selling computers in 1991.

> and look at how they
>are able to run all of those functions within the same box. The
>critical interprocess communications I/O is done within memory at
>memory access speeds. The only physical I/O that needs be done in this
>case is local file servcie I/O, data base I/O, O/S and communications
>I/O with/to the end users. And all of those are basically done with
>TRUE Parallel processes.

Unix and Windows boxes also have multiple CPUs and pass data between
them at memory speed. Google on IPC (InterProcess Communication).

To evaluate OLTP thruput, for example, a top-down measurement of
actual performance is more informative than bottom-up hand waving
about channel speed and the like. When Unix systems are configured by
professionals, as opposed to non-technical management, they deliver
about the same performance as mainframes for a fraction of the cost.

Benchmark speed and cost per transaction data is publically available
for hundreds of platforms. Why are mainframes conspicuously absent?
Because they can't compete on cost.

>To that end me thinks your statistics are very skewed.

Kindly supply corrected statistics on number of ERP and mainframe
customers, or shops, or users.

While you're at it, explain why most mainframe growth in the last ten
years involved Linux and Web serving .. both ideas borrowed from other
cultures.

Robert Wagner

2005-01-27, 8:55 am

On 26 Jan 2005 20:19:43 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>Robert:
>
>Define success rather than deflecting.

A successful platform conversion is one where the organization ceases
being a user of the old platform, for the application(s) in question,
and becomes a 'permanent' user of the new platform.

It's not my definition; it comes from the worlds of investment and
marketing.

>Next, if you want to argue architecture, I'm ready. Be forwarned that I
>have other than mainframes in my tool box and that I actually have
>written microcode.

Your arguments for the superiority of mainframes are bottom-up. The
business world cited above looks at it top-down.

For instance, you think mainframes are 'inherently superior' for OLTP
because of channel design and operating system architecture. The
decision-making executive says, 'Don't tell me about technical
details. Run the same transactions through both, then tell me response
times and cost per transaction.' When the mainframe loses, you'll
claim the other side cheated by using a larger than normal cache or by
locking programs in memory. You'll be incapible of disengaging
bottom-up, incapible of thinking like the executive.

>Come to think of it, didn't you kinda get into this with me about 2
>years ago when I was too busy to engage you in your drivel?

I don't recall but it's likely that happened.

>But then,
>what with me being in the industry for over 30 years, maybe I'm having
>another of those senior moments.

If longevity were the only criterion, I'd win.

Lessons learned 30 years ago, when hardware was expensive, no longer
apply in today's world of cheap hardware. Worse, insisting on their
application can be counter-productive. Calcified thinking is WHY they
retire old farts. (Present company excluded, of course.)

Peter Lacey

2005-01-27, 3:55 pm

Robert Wagner wrote:
>
>
> If longevity were the only criterion, I'd win.
>
> Lessons learned 30 years ago, when hardware was expensive, no longer
> apply in today's world of cheap hardware. Worse, insisting on their
> application can be counter-productive. Calcified thinking is WHY they
> retire old farts. (Present company excluded, of course.)

That's rather too broad a generalization, I'd say. Lessons learned 30
years ago about using minimum resources, about making sure that
un-necessary statements stay outside the perform loops, things like that
- still are useful and will make for better programming.

I'm sure you didn't mean to imply this, but there are those who would
interpret your statement as meaning "it doesn't matter if we write
horrible inefficient programs that use a hundred times the memory and
disk space they actually need becuase hardware is so fast and cheap that
nobody will ever notice, just as long as they work, somehow". Did you
ever see the flight simulator hidden away as an easter egg in EXCEL?

Didn't structured programming come into existence about 30 years ago?

PL

Robert Wagner

2005-01-28, 3:55 am

On 27 Jan 2005 08:20:07 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>For instance, in our facilities here, where I make the decisions as to
>what hardware, O/S, etc, we run all Intel based systems. We are
>currently running NT 4.0 workstations because they do the job.

"Do the job" is as amorphous as "successful". A rock can do the job of
a hammer.

>We see no reason to migrate to anything Micro$**t offers.

No sign of bias there.

>As a result, we are
>going to migrate to Linux as soon as we solve certain of our backup
>issues. Sun Office does everything we need, so good riddance to
>MS/Office.

Quoting from the Wine Web site:

"The dependency is not so much on Microsoft Windows as it is on
Windows applications. Boxed off-the-shelf applications, games,
in-house applications, vertical market applications, are what prevents
users, companies and governments from switching to another operating
system. Even if 90% of the needs of most users are taken care of if
you can provide them with an office suite, an email client, a browser,
and a media player, then there will still be a remaining 10% of their
needs, potentially critical needs, that are not met. Unfortunately
these remaining 10% are spread across a wide spectrum of applications:
thousands of applications running the gamut from games to specialized
accounting software for French farms, via Italian encyclopedias,
German tax software, child education software, banking software,
in-house software representing years of development, etc. It is the
availability of all this software that makes Windows so compelling and
its monopoly so strong. No platform will become mainstream unless it
runs a significant portion of that software and lets individuals,
companies and governments preserve their investments in that
software."
http://www.winehq.com/site/why

Lacking Wine or equivalent, you've locked your users into in-house
developed software. That's what most IT administrators want, but is
not what users want.

>When you discuss OLTP tests you do realize that there is more to it
>than just running a screen write/read and grab a line from a table. So
>when the computations are done for cost per transaction, the models
>given do not necessarily meet what a business actually does. All they
>do is tell us what a specific configuration can do with a standard
>test. It gives us the ability to compare apples to apples, sort of.

The benchmarks are designed to model 'typical' applications. They do
more than a screen write/read followed by grab a line.

"TPC benchmarks also differ from other benchmarks in that TPC
benchmarks are modeled after actual production applications and
environments rather than stand-alone computer tests which may not
evaluate key performance factors like user interface, communications,
disk I/Os, data storage, and backup and recovery.

The most frequent transaction consists of entering a new order which,
on average, is comprised of ten different items. Each warehouse tries
to maintain stock for the 100,000 items in the Company's catalog and
fill orders from that stock. However, in reality, one warehouse will
probably not have all the parts required to fill every order.
Therefore, TPC-C requires that close to ten percent of all orders must
be supplied by another warehouse of the Company. Another frequent
transaction consists in recording a payment received from a customer.
Less frequently, operators will request the status of a previously
placed order, process a batch of ten orders for delivery, or query the
system for potential supply shortages by examining the level of stock
at the local warehouse. A total of five types of transactions, then,
are used to model this business activity."
http://www.tpc.org/tpcc/detail.asp

>Can you, Mr. Wagner, tell me how fast an Itanium can process 5TB of
>data v. a S/390 ESA system running OS/390 V2R10? Which one will finish
>first? When is a MIP not a MIP? Yet this is the kind of comparision
>that is attempted with OLTP numbers.

The important question, from a management point of view, is how much
it costs to process all the company's transactions.

>Assuming that the one machine has
>8 CPUs and 2GB of memory, can it also be doing a large amount of batch
>oriented processing at the same time and still achieve its OLTP numbers
>(and I was actually thinking of a Regatta runing AIX5L)?

Here you're referring to Total Cost of Ownership. Since most costs are
labor rather than hardware/software, TCO is impossible to measure with
a benchmark. It's a function of management and organization. At first
glance, a centralized mainframe would have the advantage over hundreds
to thousands of decentralized servers. The issue of centralized vs.
decentralized has been examined extensively in the literature of
business. One concern, for example, is acquisitions and spin-offs.
Companaies that are centralized find it difficult to digest an
acquisition and nearly impossible to spin-off a division.

>Success of a migration/implementation: That an entity is up on the new
>platform and the old one is gone does not a successful migration make.
>When 30% of your people are unable to do their job adequately because
>the new system can't produce a report you need in a reasonable time...
>When companies are seeing Cxx being hauled off in chains...

F.U.D.

>Now let us back up many years. Since you are older than me, and an old
>fart (your definition), why did IBM, RCA, Honeywell, GE, Univac, NCR
>and Burroughs select the internal architectures that they did (I refer
>to Ibank/Dbank, memory v. bus centric, single I/O path v. multiple
>channel processors, etc.)? And who ultimately won the battles and why?
>Frankly, from what I know and remember, Burroughs should have beaten
>IBM and the others to a pulp. But they didn't.

I worked extensively on and for Burroughs, Honeywell and RCA. Techie
wisdom at the time held that IBM won because of better marketing;
hardware had nothing to do with it. Personally, I LOVED the CII/Bull
machines marketed by Honeywell as Level-6x. They failed in the US
because few people knew they existed.

>Why did all the other computer makers that got into this around
>1977-1980 decide on bus centric and segmented memory? Why did they have
>to change to the way mainframes looked at memory?
>
>So why is it that all the makers of computer systems today are trying
>to tell us that they are doing xxxx "which is very much like a
>mainframe?"

Marketing? Surely not envy.

>If what you implied (calcified thinking) should be thrown out, why is
>it then, that when I lived in SillyCone valley, did people I knew
>working for an Intel based mother board maker come to me (and I'm no
>great engineer) to ask how to get two CPUs to work together? Why did
>things get changed about the processors to allow them to do interlocked
>updates?

The answer is SMP. But that doesn't address the basic problem of how
to give applications parallelism. They'll be single-threaded so long
as the programming language assumes it's running on a Von Neumann
machine. Some back-door approaches to parallelism are AI, OO and
database.

>And who had 64bit addressing
>functioning and available first? [You might be surprised.]

Apple, running a PowerPC made by IBM?

>Why do you think I do modeling to determine if the design can handle
>the workload being placed on it? It's the same old calcified routines
>that I used to determine if a mainframe system could handle the
>workload.

I had experience with simulations working for Comress on SCERT. It
cost a fortune and didn't work very well. The fallacy, in my opinion,
was trying to solve top-down problems with a bottom-up model. Given
that it didn't work on single-task processors with minimal I/O
parallelism, the same approach doesn't stand a chance in today's
environment. I think benchmarks are the way to go.

>Could my calcified thinking be why EVERYONE of the migrations I've done
>have not only worked, but performed without having to throw more and
>more resources at it?

Congratulations. Did your plan deal with organization of support
staff, or was it only about hardware and software?

Robert Wagner

2005-01-28, 3:55 am

On Thu, 27 Jan 2005 12:38:55 -0600, Peter Lacey
<lacey@mb.sympatico.ca> wrote:

>Robert Wagner wrote:

>
>That's rather too broad a generalization, I'd say. Lessons learned 30
>years ago about using minimum resources, about making sure that
>un-necessary statements stay outside the perform loops, things like that
>- still are useful and will make for better programming.

It's now more a question of Art than Necessity.

>I'm sure you didn't mean to imply this, but there are those who would
>interpret your statement as meaning "it doesn't matter if we write
>horrible inefficient programs that use a hundred times the memory and
>disk space they actually need becuase hardware is so fast and cheap that
>nobody will ever notice, just as long as they work, somehow".

That describes most Windows programs. Why does WeatherBug take 6 meg,
and FireFox take 12 meg? I can remember when only monster machines had
16 meg of memory. Now 128 meg isn't enough to run 2-3 simple apps
without thrashing. Serious servers have 16 gigabytes of memory, which
is more than the total DISK space we once had.

Yet, Cobol programmers are still using packed decimal to save space.
The saving is measured in pennies; the cost to someone trying to
import the file is many hundreds of dollars.

Peter Lacey

2005-01-28, 3:55 am

Robert Wagner wrote:

>
> Yet, Cobol programmers are still using packed decimal to save space.

Won't argue with you about that. I actually lost a conversion job
because I tried to convince her that packed wasn't necessary.

PL

William M. Klein

2005-01-28, 3:55 am

I certainly will NOT speak to other compilers or operating systems, but the (or
at least one of the) major reasons that Packed Decimal is used over "display" on
IBM mainframes - is for performance not to "save space". Obviously, this does
not impact occasionally used data items or non-performance sensitive
applications, but from page 31 of the

"IBM Enterprise COBOL Version 3 Release 1
Performance Tuning"

the following information seems pretty relevant to me (based on actual
performance testing),

"DISPLAY compared to packed decimal (COMP-3)
- using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
- using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
- using 17 to 18 digits: DISPLAY is 150% to 200% slower than packed
decimal"

There are LOTS of "caveats" to these specific statistics (in the paper) so
"YMMV".

To see this comparison in context (along with other comparisons of different
compiler options, data types, etc), see the full paper from:

http://www-1.ibm.com/support/docvie...uid=swg27001475

--
Bill Klein
wmklein <at> ix.netcom.com
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:41F9C5AB.F9B8DC2E@mb.sympatico.ca...
> Robert Wagner wrote:
>
>
> Won't argue with you about that. I actually lost a conversion job
> because I tried to convince her that packed wasn't necessary.
>
> PL

jce

2005-01-28, 3:55 am

"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1106842807.711642.135610@z14g2000cwz.googlegroups.com...

> Success of a migration/implementation: That an entity is up on the new
> platform and the old one is gone does not a successful migration make.
> When 30% of your people are unable to do their job adequately because
> the new system can't produce a report you need in a reasonable time...
> When companies are seeing Cxx being hauled off in chains...

The platform is not the hardware...it's the software solution running on
hardware...could be on multiple servers, single server, end user pc
etc...could even be an application running hosted on someone else's
hardware.

I'm sure a significant number of transformations do not fail due to
inadequate hardware for five simple reasons -

Firstly, the requirements to move come from executives, yet the requirements
for the application come from end users - super users if you want. The end
users goal - simplify my life - is not the same as the executives - make
this cheaper.

Secondly, the end users are very good at capturing requirements with regards
to "this is what I've wanted for 2 years" but are very poor at capturing
requirement that express "this is what we need now" (they sometime manage to
tell you what they have now which is not the same thing and unfortunately
they seem to forget the things they do that are painless and refer only to
those things that are painful). They assume that everything they do will be
provided by default so only share the blue sky future. They don't seem to
want to realize that the migration is like the collective bargaining
agreement in american sports - at the end of the contract it goes away and
the negotiation starts from nada. A transformation project starts with the
end user having NOTHING.

Thirdly, a failure to recognize that the answer is not to transition the
existing solution from one hardware platform to another. The solution most
likely works, in part, because of the hardware it is running on. If there
is a cost issue, there are always options to reduce the hardware costs
without changing the solution architecture. A migration to a new hardware
should be coupled with the need to migrate to a new solution. This is often
not the case. The transition is deemed necessary by consultants and IT
branches...its an existence justification. IT departments are now in the new
role of having to provide - and excuse the marketing slang - their own value
proposition.

Fourthly, the time allowed to complete a migration is never sufficient. I
understand that in some instances the project is canned after 2-3 years, but
the original project plan was I'm sure *not* that large. It always starts
at 6 months investment and this is just enough time to try and rush in a
"executive demo" without actually considering the solution
ramifications.....then it becomes a we've gone 6 months, we just need 3
more......then you find the mistakes of the first 6 months .....and then you
need just 3 more...until they finally realize that the business is
suffering.

Fifthly, or lastly even, the platform (still software solution) change, but
the roles and function of personel do not. As the functional role of the
employees does not change, the data cannot be changed significantly, and
therefore not successfully re-architected, and then alas the problems (not
all, but usually the more heinous ones) are also transformed. It seems that
the data migration plan and the process definitions are the last item to be
discussed on a transition plan ?! Unfortunately the success of any data
processing area requires accurate data modelling. Your functional areas are
then are built around the data and not the other way around. Perhaps what
we miss is that in some instances the pieces of the mainframe solution being
transformed relies in its original form on some high I/O throughput due to
inadequacies in the data model or even poor code.

A great example is at my location before I arrived there was an IMS to DB2
migration. The old IMS code was rewritten to "work". It runs like a dog
because it still accesses the data in a hierarchical and not relational way.
We are still finding instances of open cursor a to get b...open cursor b to
get c ....open cursor c to get the answer....where DB2 could handle this
much more efficiently as a combination of joins.

I am a only a web bigot. I hate any web application that forces me to hit a
"close window" button, or a "back" button or has to warn me with a "don't
hit this button twice" button.

> I have migrated whole accounting systems off to NT from mainframe. It
> worked because the amount of data to be processed was within the
> capablilities of the design and equipment. However, I explained, and it
> was accepted, what their growth path was and how they would know when
> they got there. The amount of transactions to be processed per hour was
> key. All the programming was being done in COBOL.

Ah...now you touch on it...it really isn't a hardware platform issue ...it's
a software platform issue.....only a specific instance of a failed project
knows why the project failed and I'd venture a guess that 75% of projects it
is not the hardware...

JCE

Robert Wagner

2005-01-28, 8:55 am

On Fri, 28 Jan 2005 05:54:04 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I certainly will NOT speak to other compilers or operating systems, but the (or
>at least one of the) major reasons that Packed Decimal is used over "display" on
>IBM mainframes - is for performance not to "save space".

IBM and Unisys mainframes support packed decimal hardware
instructions. On Intel, Sun and others, packed decimal is no faster
than display.

On IBM mainframes (don't know about Unisys), converting display to and
from packed is very fast. When I work on mainframes, I put display in
files, packed in working-storage. I do arithmetic in working-storage,
not in the record area.

Robert Wagner

2005-01-28, 8:55 am

On 27 Jan 2005 20:51:39 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>Now all you have to do is come up with a list of software that
>steve.t's company might _actually_ care about, because I don't think it
>is a French farm or a child educator.
>
>
>Most banking software is on mainframes or Unix.
>
>But what is your actual point ?

My point is that 95% (according to the Wine site) of shrink-wrap
software runs on Windows.

>
>MIPS R4000 ?

Good answer. It appears to be right.

Robert Wagner

2005-01-28, 3:55 pm

On 28 Jan 2005 01:41:12 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>dollars.
>
>I don't think that one can EMail a zOS VSAM file raw dump, if one could
>the packed fields would be the least of the problems.
>
>With most systems attempting to use raw files is nonsense. I know that
>you used to do this with C-ISAM files which are _almost_ useful.
>Data interchange must be done with well defined file structures.

Every w

or two someone asks here how to read a 'Cobol file',
because someone sent a raw file.

docdwarf@panix.com

2005-01-28, 3:55 pm

In article <v5dkv0d9c4c4fokh4goj9sqbu1cageuitp@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 28 Jan 2005 01:41:12 -0800, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
>Every w

or two someone asks here how to read a 'Cobol file',
>because someone sent a raw file.

Really? I have no idea, Mr Wagner, how you come to conclusions about what
is sent or received... but it might be concluded with greater validity
that people ask how to 'read a 'Cobol file'' because they never learned
such minor details as the independence of programming languages and file
structures... and that their management does not have the competence to
realise that knowing such details, and others associated with them, might
just possibly be beneficial in accomplishing a stated executive goal when
said managers assign tasks.

DD

Michael Mattias

2005-01-28, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:v5dkv0d9c4c4fokh4goj9sqbu1cageuitp@
4ax.com...
> On 28 Jan 2005 01:41:12 -0800, "Richard" <riplin@Azonic.co.nz> wrote:
>
> Every w

or two someone asks here how to read a 'Cobol file',
> because someone sent a raw file.

And every w

or two I send them to my tutorial on this subject at:

http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm

It's old, it's visually unappealing, but by golly, it tells you what you
need to know.

(Oh, sorry, I forgot the most important thing considering the clientele
here: it's free).

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com

docdwarf@panix.com

2005-01-28, 3:55 pm

In article <j4sKd.24208$by5.1167@newssvr19.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:

[snip]

>(Oh, sorry, I forgot the most important thing considering the clientele
>here: it's free).

.... and worth at least double what you charge for it, too!

DD

Michael Mattias

2005-01-28, 3:55 pm

<docdwarf@panix.com> wrote in message news:ctdj72$fvf$1@panix5.panix.com...
> In article <j4sKd.24208$by5.1167@newssvr19.news.prodigy.com>,
> Michael Mattias <michael.mattias@gte.net> wrote:
>
> [snip]
>
>
> ... and worth at least double what you charge for it, too!

Well, I guess in a group this size one must expect at least one person of
dubious legitimacy of birth.

MCM

docdwarf@panix.com

2005-01-28, 3:55 pm

In article <aWsKd.24218$by5.18572@newssvr19.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:ctdj72$fvf$1@panix5.panix.com...
>
>Well, I guess in a group this size one must expect at least one person of
>dubious legitimacy of birth.

It was a cheap shot, Mr Mattias, I will agree... but I could *not* resist.

DD

Robert Wagner

2005-01-28, 3:55 pm

On 28 Jan 2005 08:03:38 -0500, docdwarf@panix.com wrote:

>In article <v5dkv0d9c4c4fokh4goj9sqbu1cageuitp@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>Really? I have no idea, Mr Wagner, how you come to conclusions about what
>is sent or received...

When someone says he has a pair of files named .IND and .INX, it's
obvious to most that he has a raw indexed file.

> but it might be concluded with greater validity
>that people ask how to 'read a 'Cobol file'' because they never learned
>such minor details as the independence of programming languages and file
>structures...

Format is tied to the compiler, not the language. He should have asked
how to read a 'Micro Focus file'. Happy now?

>and that their management does not have the competence to
>realise that knowing such details, and others associated with them, might
>just possibly be beneficial in accomplishing a stated executive goal when
>said managers assign tasks.

Assigning blame to a person might make you feel better, but doesn't
help with getting the file read.

Chuck Stevens

2005-01-28, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:h3tjv01c4c0i5596hlmpca9h9it15rofck@
4ax.com...

> IBM and Unisys mainframes support packed decimal hardware
> instructions.

Can't speak to the ex-Sperry mainframes, but what the MCP variety supports
is fast hardware instructions to pack and unpack items, as well as to
convert from both decimal formats into binary and back. The arithmetic is
actually done in binary.

> On IBM mainframes (don't know about Unisys), converting display to and
> from packed is very fast.

True also on Unisys MCP, and often used in MOVE, but if you're retrieving
for arithmetic purposes it's that conversion to and from *binary* is very
fast that matters.

We investigated building decimal hardware into the early A Series back in
the mid-1980's. The Burroughs Medium System was designed around "string"
arithmetic, and we had some experience with it. The "string" model wouldn't
map very well to the "word-oriented" A Series, but the engineers thought
they could come up with a reasonable way to do this. The argument that won
the day at the time was that decimal arithmetic hardware in the A Series
word-oriented environment (be it "operand-oriented" or "pointer-oriented")
would be decidedly expensive, and that we could get the same performance
benefit by improving the performance of the existing binary-to-decimal
(packed or display) and decimal-to-binary instructions at MUCH less cost.

-Chuck Stevens

JerryMouse

2005-01-28, 3:55 pm

William M. Klein wrote:
> I certainly will NOT speak to other compilers or operating systems,
> but the (or at least one of the) major reasons that Packed Decimal is
> used over "display" on IBM mainframes - is for performance not to
> "save space". Obviously, this does not impact occasionally used data
> items or non-performance sensitive applications, but from page 31 of
> the
> "IBM Enterprise COBOL Version 3 Release 1
> Performance Tuning"
>
> the following information seems pretty relevant to me (based on actual
> performance testing),
>
> "DISPLAY compared to packed decimal (COMP-3)
> - using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
> - using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed
> decimal - using 17 to 18 digits: DISPLAY is 150% to 200% slower than
> packed decimal"
>
> There are LOTS of "caveats" to these specific statistics (in the
> paper) so "YMMV".

Yeah, but the biggest caveat is "who cares?" Aside from the business about
something being "100%" slower (which means, to me, that its speed is zero, I
won't even attempt to define "200% slower"), the big question is 100% slower
than WHAT?

A saving of 50 nanoseconds per transaction is so close to zero as to be
indistinguishable.

docdwarf@panix.com

2005-01-28, 3:55 pm

In article <biokv0pn1tuns3kicugp4uei5bu3e9nhqc@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 28 Jan 2005 08:03:38 -0500, docdwarf@panix.com wrote:
>
>
>When someone says he has a pair of files named .IND and .INX, it's
>obvious to most that he has a raw indexed file.

When someone says 'he has' it is not obvious that 'he was sent' anything,
Mr Wagner.

>
>
>Format is tied to the compiler, not the language. He should have asked
>how to read a 'Micro Focus file'. Happy now?

Shoulda, coulda, woulda, Mr Wagner... what's there is there, perhaps you
can deal with it.

>
>
>Assigning blame to a person might make you feel better, but doesn't
>help with getting the file read.

Mr Wagner, you certainly appear to enjoy seeing things in terms of
'blame'... I point out whose job it is, by definition, to do things, no
more, no less. The allocation, co-ordination and motivation of personnel
and resources towards the accomplishment of a stated Executive goal is the
responsibility of Management, or so the textbooks have said; are you
saying that to state this is to 'assign blame'?

DD

Howard Brazee

2005-01-28, 3:55 pm

NNTP-Posting-Host: ums.cusys.edu
X-Trace: peabody.colorado.edu 1106935809 28779 192.12.240.129 (28 Jan 2005 18:10:09 GMT)
X-Complaints-To: abuse@colorado.edu
NNTP-Posting-Date: 28 Jan 2005 18:10:09 GMT
X-Newsreader: News Rover 10.1.0 (http://www.NewsRover.com)
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:106728

On 28-Jan-2005, "JerryMouse" <nospam@bisusa.com> wrote:

> A saving of 50 nanoseconds per transaction is so close to zero as to be
> indistinguishable.

Usually.

But not always, especially in jobs that have to fit in a window, running
billions of transactions before the database goes down at midnight.

Robert Wagner

2005-01-28, 8:55 pm

On 28 Jan 2005 12:56:41 -0500, docdwarf@panix.com wrote:

>In article <biokv0pn1tuns3kicugp4uei5bu3e9nhqc@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:

[color=darkred]
>
>Mr Wagner, you certainly appear to enjoy seeing things in terms of
>'blame'... I point out whose job it is, by definition, to do things, no
>more, no less. The allocation, co-ordination and motivation of personnel
>and resources towards the accomplishment of a stated Executive goal is the
>responsibility of Management, or so the textbooks have said; are you
>saying that to state this is to 'assign blame'?

When a problem arises, management instinctively asks who's guilty;
programmers work on a remedy. You offered an opinion about the
competence of management, and nothing about a remedy. So yes, you're
assigning blame.

Robert Wagner

2005-01-28, 8:55 pm

On 28 Jan 2005 10:19:44 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>No. I see no evidence that the files were 'sent'. Mostly it is trying
>to access the data in an existing system, possibly to replace it with
>some VB they just knocked up.

That's true in this case. Others said the file had been sent, or is
being sent monthly.

>With most systems, such as default MF on Windows, Fujitsu, RM, Accu,
>mainframe; there is no point at all in trying to read the raw file, or
>'send' it. Packed would be the least of their problems.

Reading the raw file with a MF program or tool is the only practical
solution (unless it's C-ISAM). Even though the format is obsolete, MF
is good about backward compatibility.

>Even with your 'mostly not junk' C-ISAM you didn't have 'sign separate'
>so negatives were not easily processed. There may only have been a few
>of those so the result was probably only partly complete nonsense.

Negatives are easily fixed with a text editor. Mark the column, find
within scope, run macro to convert number and place dash in front of
field.

William M. Klein

2005-01-28, 8:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:biokv0pn1tuns3kicugp4uei5bu3e9nhqc@
4ax.com...
> On 28 Jan 2005 08:03:38 -0500, docdwarf@panix.com wrote:
<snip>>
>
> When someone says he has a pair of files named .IND and .INX, it's
> obvious to most that he has a raw indexed file.
>

"have" versus "sent" is what I see as the difference. I think that most of the
posts (and this is just my GUESS) come from people at shops where an exsiting
(old) COBOL program creates output - and they now want to do something
"non-COBOL" with the file.

--
Bill Klein
wmklein <at> ix.netcom.com

Richard

2005-01-28, 8:55 pm

> That's true in this case. Others said the file had been sent, or is
> being sent monthly.

You just make stuff up.

> Reading the raw file with a MF program or tool is the only practical
> solution (unless it's C-ISAM).

No. _Even_ if it is C-ISAM. Apart from COMP or COMP-3 fields, there
are also deleted records and junk in slack space. These will cause
records to be incorrectly read.

There also may be issues with negative numbers even if they are
display.

> Negatives are easily fixed with a text editor. Mark the column, find
> within scope, run macro to convert number and place dash in front of
> field.

Is this what your dumb users did when you sent them a C-ISAM file ?
Did you send a note explaining where the sign was and the values ? Did
you write the macro for them ? When the dash was 'added in front' did
this misalign the fields ? or did it potentially overwrite the high
order digit ?

Given that you didn't seem to know about the problem with deleted
records (it took several messages before you realised there was a
problem) and you just made up this 'macro' I suspect your users just
gave up when you sent them a raw file that was to them 'junk'.

Lueko Willms

2005-01-28, 8:55 pm

.. On 28.01.05
wrote spamblocker-robert@wagner.net (Robert Wagner)
on /COMP/LANG/COBOL
in v5dkv0d9c4c4fokh4goj9sqbu1cageuitp@4ax.com
about Re: OT (Maybe): ERPs

RW> Every w

or two someone asks here how to read a 'Cobol file',
RW> because someone sent a raw file.

But this is not for data exchange, but for conversion of the
application from COBOL to some other environment.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Man stattete ihm sehr heißen, schon etwas verbrannten Dank ab. -G.C.Lichtenberg

JerryMouse

2005-01-28, 8:55 pm

Howard Brazee wrote:
> On 28-Jan-2005, "JerryMouse" <nospam@bisusa.com> wrote:
>
>
> Usually.
>
> But not always, especially in jobs that have to fit in a window,
> running billions of transactions before the database goes down at
> midnight.

I exaggerate for the purpose of emphasis.

Still, 10 billion transactions at a saving of 50 nanoseconds each is an
overall saving of 500 seconds: ~ eight minutes.

docdwarf@panix.com

2005-01-29, 3:55 am

In article <f28lv01qvq2qfbvqo3hvpk3tlkrc15c1qf@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 28 Jan 2005 12:56:41 -0500, docdwarf@panix.com wrote:
>
>
>
>
>When a problem arises, management instinctively asks who's guilty;
>programmers work on a remedy.

That's curious... I have worked in shops, Mr Wagner, where the programmers
instinctively asked 'who did this?' and the managers asked 'who can fix
this?'; experience in such a place seems to be absent from your view of
the world and thus might explain a particular shortsightedness.

>You offered an opinion about the
>competence of management, and nothing about a remedy. So yes, you're
>assigning blame.

Offering opinion about competence is assigning blame? Interesting
dictionary you have there, Mr Wagner... perhaps some day it might be other
than a completely idiosyncratic one; I'll try to abide, for the nonce, by
the definitions supplied by the OED.

DD

jce

2005-01-29, 3:55 am

>> Robert Wagner <spamblocker-robert@wagner.net> wrote:
>docdwarf@panix.com wrote:

> That's curious... I have worked in shops, Mr Wagner, where the programmers
> instinctively asked 'who did this?' and the managers asked 'who can fix
> this?'; experience in such a place seems to be absent from your view of
> the world and thus might explain a particular shortsightedness.

[color=darkred]
> Offering opinion about competence is assigning blame? Interesting
> dictionary you have there, Mr Wagner... perhaps some day it might be other
> than a completely idiosyncratic one; I'll try to abide, for the nonce, by
> the definitions supplied by the OED.
>
> DD

Maybe you're not assigning blame, but you're assigning responsibility. With
that responsibility you have associated a level of incompetence.
It goes if you cannot perform your responsibilities in a competent manner,
then there is a fault. Anywhere there is a fault there is blame.

The blame has to be applied to management - that is where the incompetence
lies. It's Peter and his Principles again.

JCE

jce

2005-01-29, 8:55 am

Xref: newsfeed-west.nntpserver.com comp.lang.cobol:106816

"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1106842807.711642.135610@z14g2000cwz.googlegroups.com...

> Success of a migration/implementation: That an entity is up on the new
> platform and the old one is gone does not a successful migration make.
> When 30% of your people are unable to do their job adequately because
> the new system can't produce a report you need in a reasonable time...
> When companies are seeing Cxx being hauled off in chains...

The platform is not the hardware...it's the software solution running on
hardware...could be on multiple servers, single server, end user pc
etc...could even be an application running hosted on someone else's
hardware.

I'm sure a significant number of transformations do not fail due to
inadequate hardware for five simple reasons -

Firstly, the requirements to move come from executives, yet the requirements
for the application come from end users - super users if you want. The end
users goal - simplify my life - is not the same as the executives - make
this cheaper.

Secondly, the end users are very good at capturing requirements with regards
to "this is what I've wanted for 2 years" but are very poor at capturing
requirement that express "this is what we need now" (they sometime manage to
tell you what they have now which is not the same thing and unfortunately
they seem to forget the things they do that are painless and refer only to
those things that are painful). They assume that everything they do will be
provided by default so only share the blue sky future. They don't seem to
want to realize that the migration is like the collective bargaining
agreement in american sports - at the end of the contract it goes away and
the negotiation starts from nada. A transformation project starts with the
end user having NOTHING.

Thirdly, a failure to recognize that the answer is not to transition the
existing solution from one hardware platform to another. The solution most
likely works, in part, because of the hardware it is running on. If there
is a cost issue, there are always options to reduce the hardware costs
without changing the solution architecture. A migration to a new hardware
should be coupled with the need to migrate to a new solution. This is often
not the case. The transition is deemed necessary by consultants and IT
branches...its an existence justification. IT departments are now in the new
role of having to provide - and excuse the marketing slang - their own value
proposition.

Fourthly, the time allowed to complete a migration is never sufficient. I
understand that in some instances the project is canned after 2-3 years, but
the original project plan was I'm sure *not* that large. It always starts
at 6 months investment and this is just enough time to try and rush in a
"executive demo" without actually considering the solution
ramifications.....then it becomes a we've gone 6 months, we just need 3
more......then you find the mistakes of the first 6 months .....and then you
need just 3 more...until they finally realize that the business is
suffering.

Fifthly, or lastly even, the platform (still software solution) change, but
the roles and function of personel do not. As the functional role of the
employees does not change, the data cannot be changed significantly, and
therefore not successfully re-architected, and then alas the problems (not
all, but usually the more heinous ones) are also transformed. It seems that
the data migration plan and the process definitions are the last item to be
discussed on a transition plan ?! Unfortunately the success of any data
processing area requires accurate data modelling. Your functional areas are
then are built around the data and not the other way around. Perhaps what
we miss is that in some instances the pieces of the mainframe solution being
transformed relies in its original form on some high I/O throughput due to
inadequacies in the data model or even poor code.

A great example is at my location before I arrived there was an IMS to DB2
migration. The old IMS code was rewritten to "work". It runs like a dog
because it still accesses the data in a hierarchical and not relational way.
We are still finding instances of open cursor a to get b...open cursor b to
get c ....open cursor c to get the answer....where DB2 could handle this
much more efficiently as a combination of joins.

I am a only a web bigot. I hate any web application that forces me to hit a
"close window" button, or a "back" button or has to warn me with a "don't
hit this button twice" button.

> I have migrated whole accounting systems off to NT from mainframe. It
> worked because the amount of data to be processed was within the
> capablilities of the design and equipment. However, I explained, and it
> was accepted, what their growth path was and how they would know when
> they got there. The amount of transactions to be processed per hour was
> key. All the programming was being done in COBOL.

Ah...now you touch on it...it really isn't a hardware platform issue ...it's
a software platform issue.....only a specific instance of a failed project
knows why the project failed and I'd venture a guess that 75% of projects it
is not the hardware...

JCE

Robert Wagner

2005-01-29, 3:55 pm

On 28 Jan 2005 13:44:27 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>I have seen you do that many, many times, as well as about all
>mainframe programmers, system admins, and even doctors.
>
>The difference is that the Doc referred to _their_ managers, the small
>specific sample that directly related to where a programmer was given
>the task of reading a file without the management providing the means
>to know how to do that.
>
>You, on the other hand, apply your opinions to 'all' or to the whole
>group, such as here when you broadened doc's 'their management' to the
>generalised 'management'. And you never seem to notice the difference.

Doc doesn't know their managers. His comments were about managers in
general.

>And, yes, he _did_ provide an implied remedy:
>
>"""knowing such details, and others associated with them, might
>just possibly be beneficial in accomplishing a stated executive goal
>when said managers assign tasks."""
>
>Note the use of 'said managers', ie those specific ones that did not
>supply such aids, as is evidenced by the programmers having to ask
>here.

Every contract I work on involves technology I hadn't used before.
There's no hand-holding manager. If I can't get up to speed within
days, they'll find someone else who can. Doc has probably experienced
the same lack of foresight on his contracts.

Robert Wagner

2005-01-29, 3:55 pm

On 28 Jan 2005 19:53:22 -0500, docdwarf@panix.com wrote:

>In article <f28lv01qvq2qfbvqo3hvpk3tlkrc15c1qf@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>That's curious... I have worked in shops, Mr Wagner, where the programmers
>instinctively asked 'who did this?' and the managers asked 'who can fix
>this?'; experience in such a place seems to be absent from your view of
>the world and thus might explain a particular shortsightedness.

I _have_ seen that reversal of roles, typically from older programmers
who thought they had a sinecure. They're the ones who look like deer
in headlights when the company is acquired and I arrive to convert
mainframe systems to Unix.

>
>Offering opinion about competence is assigning blame? Interesting
>dictionary you have there, Mr Wagner... perhaps some day it might be other
>than a completely idiosyncratic one; I'll try to abide, for the nonce, by
>the definitions supplied by the OED.

My definitions are influenced by real world experience .. at companies
that make Dilbert's employer look progressive. Places unfamiliar with
the word 'nepotism' but adept in its practice.
-------------------------------

While we're on the topoc of vocabulary, I compiled this list
describing netizens:

rectitudinarian: A person obsessed with personal sanctimony (also
tight-ass).
unco guid (scottish epithet): A prim-and-proper puritan.
antithalian: Against enjoyment.
wowser (Australian): A nagging puritan hung up on banning petty
amusements that others enjoy.
peccatophobe: One who worries about having committed a sin or
imaginary crime. Has a strong sense of right and wrong, clean and
dirty.
atelophobe: A perfectionist unable to reconcile personal imperfections
with his ideal vision.
asthenophobe: A person afraid to admit weakness of any sort. Usually
found in the military and board rooms. Also macho men.
solifidian: One who believes that faith alone is sufficient for
salvation.
ablutomania: A mania for washing oneself.
facticide: One who twists facts, doctors data, tells half-truths &
white lies.
solipsist: One who places himself at the center of the universe. A
solipsist does not necessarily think himself superior to others,
he is impenetrably oblivious to others unless they annoy him.
sophomania: Delusion of exceptional intelligence.
morosoph: An over-educated pedantic jerk and erudite ass.
misologist: One who hates rational discussion and honest
agrumentation. Most misologists are stupider than they look.
hobberdehoy: A youth entering manhood.
hagiarchy: Government by religious types.
pornocracy: Government by prostitutes.
philodox: One who loves his own opinions.
Dogberry: A smug official who who is an bone-headed, inept busybody
(from a constable in Shakespeare's "Much Ado About Nothing").
energumen: An individual who is fanatical about one issue.
marplot: The well-meaning interferer whose efforts only hinder a
project.
stormy petrel: One who starts arguments, fights, wars. A troublemaker.
polypragmatist: A busybody.
badaud: A self-confident ignoramus who believes and repeats anything.
gobemouche: A gullible rube who will believe anything.
kvetch: A constant complainer.
cacographer: A terrible speller whose English seems to be written
phonetically and modeled on restroom graffiti.
abacedarian: One learning the alphabet, a beginner.
logomachist: One who constantly asks for definitions of words.
parvanimity: A petty or mean person endowed with smallness of mind.
ferbissener (fem: ferbisseneh): A sour, embittered person. The only
time ferbisseners light up a room is when their clothes are on fire.
criticaster: A third-rate critic of others' ideas, has none of his
own.
catagelophobe: A thin-skinned person overly sensitive to criticism.
malapert: One who likes to shock with saucy, brasen, impudent
statements.
abuccinate: To proclaim, like a fanfare.
hierofastidia: Dislike of holy things.
mome: One who loves to use others' petty mistakes as an excuse to put
them down. A hair-splitter.
psychasthenic: Neurotic weakling. Woody Allen without the talent.
mattoid: A semi-unhinged genius. Not quite around the bend but always
has the turn signal on.
futilitarian: Quixotic Ralph Kramden type who embraces big ideas,
get-rich-quick schemes, never quite making it.
ironist: One who is always saying the opposite of her words' meaning
("I'm SO impressed"). Has a gift for mockery. Usually female.

ultracrepidarian: One who tries to work outside his field of
knowledge, where he has no business being.
aristarch: A severe but fair critic.
lexiphane: Person with an inflated vocabulary.

Sources: "Dimboxes, Epopts and other Quidams", David Grambs
"Mrs. Byrne's Dictionary", Josefa Heifetz Byrne

docdwarf@panix.com

2005-01-29, 3:55 pm

In article <sc0nv057ba39g2kurqhh42brtg3j25tkvl@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 28 Jan 2005 13:44:27 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

[snip]

>
>Doc doesn't know their managers. His comments were about managers in
>general.

Mr Wagner, perhaps it was your desire to make my words appear that way by
a series of midsentence interruptions... but you might recall my response
of:

'Really? I have no idea, Mr Wagner, how you come to conclusions about
what is sent or received... but it might be concluded with greater
validity that people ask how to 'read a 'Cobol file'' because they never
learned such minor details as the independence of programming languages
and file structures... and that their management does not have the
competence to realise that knowing such details, and others associated
with them, might just possibly be beneficial in accomplishing a stated
executive goal when said managers assign tasks.'

.... and pay particular attention to what precedes 'management' in the
phrase 'their management does not have the competence' as it appears to
indicate a subset.

>
>
>Every contract I work on involves technology I hadn't used before.

There is no evidence I can discern, Mr Wagner, indicating the original
poster is anything other than an employee.

>There's no hand-holding manager.

There was no indication that such was needed, Mr Wagner... unless you
consider management with the minimal competences I suggested to be 'hand
holding'.

>If I can't get up to speed within
>days, they'll find someone else who can. Doc has probably experienced
>the same lack of foresight on his contracts.

Of course I have, Mr Wagner... but I did not consider that experience to
be of relevance here. It is one thing to use the right tool for the right
job, as I indicated was not being done... quite another to expect an
employee to be a consultant.

DD

docdwarf@panix.com

2005-01-29, 3:55 pm

In article <ZgEKd.3887$JO2.646@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
>
>
>
>
>Maybe you're not assigning blame, but you're assigning responsibility. With
>that responsibility you have associated a level of incompetence.
>It goes if you cannot perform your responsibilities in a competent manner,
>then there is a fault. Anywhere there is a fault there is blame.

Neatly spun... but not quite. A fault can be a simple weakness, an
absence or lack; as such it seems a matter of existence and outside of
responsibility. Consider the geographic use of the term.

>
>The blame has to be applied to management - that is where the incompetence
>lies. It's Peter and his Principles again.

In the sense of 'the competent person chooses a tool which is capable of
accomplishing the task' there is no blame to be applied... unless the task
does not get accomplished.

DD

docdwarf@panix.com

2005-01-29, 3:55 pm

In article <hipmv0djd3bcieikf0egbt193i35kagenq@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 28 Jan 2005 19:53:22 -0500, docdwarf@panix.com wrote:
>
>
>I _have_ seen that reversal of roles, typically from older programmers
>who thought they had a sinecure.

Ahhhhh, so it *has* been in your experience, Mr Wagner, and you, for
whatever reason, choose to ignore it when formulating your response.

>They're the ones who look like deer
>in headlights when the company is acquired and I arrive to convert
>mainframe systems to Unix.

How interesting... programmers who 'behave like management' act this
way when the environment changes.

>
>
>My definitions are influenced by real world experience .. at companies
>that make Dilbert's employer look progressive.

Your definitions might be influenced by Space Aliens bombarding your head
with alien brainwaves, Mr Wagner... but - no matter what one thinks of the
man's politics - it might help to avoid idiosycratic definition by
remembering the canine-amputee-ignoring riddle (often attributed to
Abraham Lincoln) of:

'How many legs does a dog have if you call a tail a leg?'

'Four... calling a tail a leg does not make it one.'

DD

Donald Tees

2005-01-29, 3:55 pm

Richard wrote:
>
> acquired and
>
>
>
> No. There may be a completely different reason why they are dismayed to
> see you arrive.
>

Getting splattered over a grill is much the same on any hardware. When
you happen to be the bunny, the finer details tend to be moot points.

Donald

Robert Wagner

2005-01-29, 3:55 pm

On 29 Jan 2005 08:11:03 -0500, docdwarf@panix.com wrote:

>Mr Wagner, perhaps it was your desire to make my words appear that way by
>a series of midsentence interruptions... but you might recall my response
>of:
>
>'Really? I have no idea, Mr Wagner, how you come to conclusions about
>what is sent or received... but it might be concluded with greater
>validity that people ask how to 'read a 'Cobol file'' because they never
>learned such minor details as the independence of programming languages
>and file structures... and that their management does not have the
>competence to realise that knowing such details, and others associated
>with them, might just possibly be beneficial in accomplishing a stated
>executive goal when said managers assign tasks.'
>
>... and pay particular attention to what precedes 'management' in the
>phrase 'their management does not have the competence' as it appears to
>indicate a subset.

When people ask how to read a 'Cobol file', I'll let YOU tell them
their manager let them down. The tact you use mightl be instructive to
all.

>
>There is no evidence I can discern, Mr Wagner, indicating the original
>poster is anything other than an employee.

I see. If a consultant asks, we'll just tell him or her how to read
the file.

>
>Of course I have, Mr Wagner... but I did not consider that experience to
>be of relevance here. It is one thing to use the right tool for the right
>job, as I indicated was not being done... quite another to expect an
>employee to be a consultant.

There are places willing to pay tens of thousands to consultants doing
it the hard way, but balk at paying a few hundred for the right tool.
It comes out of a different budget and goes through a different
approval process. I typically mention the tool once, but if they're
not interested, I do it their way. If I insisted, they wouldn't be
grateful, they'd say someithing like 'That Wagner wouldn't shut up
until we got Toad Xpert. Then he used it for less than a w

to
optimize the databases. What a waste of $2,000."

Robert Wagner

2005-01-29, 8:55 pm

On 29 Jan 2005 09:57:53 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>acquired and
>
>No. There may be a completely different reason why they are dismayed to
>see you arrive.

Could it be the hair? The earring? The CodeWarrior t-shirt?

Just kidding. I don't display any of those during the first month.

jce

2005-01-30, 3:55 am

<docdwarf@panix.com> wrote in message news:ctg2kv$t7a$1@panix5.panix.com...
> In article <ZgEKd.3887$JO2.646@tornado.tampabay.rr.com>,
> jce <defaultuser@hotmail.com> wrote:
>
> Neatly spun... but not quite. A fault can be a simple weakness, an
> absence or lack; as such it seems a matter of existence and outside of
> responsibility. Consider the geographic use of the term.

I agree, but not quite. In the world of your comment on "their management"
you stated that the fault was not recognizing the need for a specific skill
in completing an assigned task.
When your job is to manage allocation of skills to match the task, and you
fail, then this is a fault to which we *should* attach responsibility.

>
> In the sense of 'the competent person chooses a tool which is capable of
> accomplishing the task' there is no blame to be applied... unless the task
> does not get accomplished.

It is ironic that the opposite does not follow. I see blame even when the
task is accomplished!

JCE

docdwarf@panix.com

2005-01-30, 3:55 pm

In article <o8mnv0phfr7lr8m3qphincjk72fhmkmkpb@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 29 Jan 2005 08:11:03 -0500, docdwarf@panix.com wrote:
>
>
>
>When people ask how to read a 'Cobol file', I'll let YOU tell them
>their manager let them down.

Mr Wagner, I'm sure you have a Very Good Reason for thinking that someone
might need your permission for such an activity... so, by all means, feel
free to relate what it is that causes you to believe that anyone in this
forum might require anything resembling your say-so for their actions for
reasons outside of, say, amusement.

>The tact you use mightl be instructive to
>all.
>
>
[color=darkred]
>
>I see. If a consultant asks, we'll just tell him or her how to read
>the file.

No, Mr Wagner, if a consultant asks you'll be able to tell him that you
have been in the same boat... what fun!

>
>
>There are places willing to pay tens of thousands to consultants doing
>it the hard way, but balk at paying a few hundred for the right tool.
>It comes out of a different budget and goes through a different
>approval process.

The end-result is no different than if it came down of a mountain engraved
on a stone tablet, Mr Wagner; the processes by which the organisation
voluntarily chooses to run it'sself cause difficulties when it comes to
accomplishing a task. The Anciente Wisdome has it that:

'Doc, it hoits when I do dis!'

.... is appropriately responded-to with

'So... don't do dat!'

>I typically mention the tool once, but if they're
>not interested, I do it their way. If I insisted, they wouldn't be
>grateful, they'd say someithing like 'That Wagner wouldn't shut up
>until we got Toad Xpert. Then he used it for less than a w

to
>optimize the databases. What a waste of $2,000."

If you choose to work in places with this kind of vision, Mr Wagner, then
you'll get all kinds of lovely stories to tell. A classic has the
punchline of:

Hitting maching: $25.00
Knowing where to hit machine: $99,974.00

DD

docdwarf@panix.com

2005-01-30, 3:55 pm

In article <bU%Kd.8774$JF2.8393@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
>
><docdwarf@panix.com> wrote in message news:ctg2kv$t7a$1@panix5.panix.com...
>
>I agree, but not quite. In the world of your comment on "their management"
>you stated that the fault was not recognizing the need for a specific skill
>in completing an assigned task.

I am not sure to what, exactly, you are referring... but in the 'world of
my comment on 'their management' I stated:

--begin quoted text:

Really? I have no idea, Mr Wagner, how you come to conclusions about what
is sent or received... but it might be concluded with greater validity
that people ask how to 'read a 'Cobol file'' because they never learned
such minor details as the independence of programming languages and file
structures... and that their management does not have the competence to
realise that knowing such details, and others associated with them, might
just possibly be beneficial in accomplishing a stated executive goal when
said managers assign tasks.

--end quoted text

.... there's mention of competence, certainly, but not of fault.

>When your job is to manage allocation of skills to match the task, and you
>fail, then this is a fault to which we *should* attach responsibility.

Perhaps so... but this is not a world in which 'should' equals 'is'... and
managers get *their* assignments from someplace, last I looked; the plaque
reading 'The Buck Stops Here' is well-known for being on an Executive's
desk.

>
>
>It is ironic that the opposite does not follow. I see blame even when the
>task is accomplished!

Nothing new in that... from
<http://groups.google.co.uk/groups?s...m&output=gplain>

--begin quoted text:

Hmmmm... decades back, when I got my First Job, my sainted Mother, may she
sleep with the angels, gave me the following sage counsel:

'Then it comes to work remember two things: you can be wrong about
something... and be fired for it; you can be right about something... and
be fired for it.'

Perhaps you are related to her... what was your grannie's milkman's name?

--end quoted text

(Note of interest - over seven years after first posting this I notice
that I mis-typed her initial word of 'When' as 'Then')

DD

jce

2005-01-30, 3:55 pm

<docdwarf@panix.com> wrote in message news:ctio6h$a26$1@panix5.panix.com...
> In article <bU%Kd.8774$JF2.8393@tornado.tampabay.rr.com>,
> jce <defaultuser@hotmail.com> wrote:

>
> Perhaps so... but this is not a world in which 'should' equals 'is'... and
> managers get *their* assignments from someplace, last I looked; the plaque
> reading 'The Buck Stops Here' is well-known for being on an Executive's
> desk.
This is the Peter and hit Principle...I interpret 'their management' with
the implicit 'chain' (those in charge).
Perhaps another fine example of one not taking the exact literal of your
meaning !

I also assumed that you - being of integrity - would attach blame where it
*should* be thereby making it *is*.
Perhaps yet another fine example of one not taking the exact literal of your
meaning !

>
> Nothing new in that... from
> <http://groups.google.co.uk/groups?s...m&output=gplain>
>
> --begin quoted text:
>
> Hmmmm... decades back, when I got my First Job, my sainted Mother, may she
> sleep with the angels, gave me the following sage counsel:
>
> 'Then it comes to work remember two things: you can be wrong about
> something... and be fired for it; you can be right about something... and
> be fired for it.'
>
> Perhaps you are related to her... what was your grannie's milkman's name?
My gran lived in the WW II, she couldn't afford milk so she didn't have a
milkman....maybe the same postman.

Also, if I wanted to DD you (don't go after me like the Tivo anti
brand-as-verb execs) I would lustfully point out that I didn't say that you
could be fired for being right. I said you could receive blame for
executing something successfully. But, as the provided advice was sage, and
predated this thread, I will let it go :-)

> --end quoted text
>
> (Note of interest - over seven years after first posting this I notice
> that I mis-typed her initial word of 'When' as 'Then')
And no one corrected you? Geez...the internet was no fun back then

> DD
I have to say that the sage counsel was made up of wise words indeed.
Hmmm...the words are not wise....but the counsel was wise.....you know what
I mean :)

JCE

docdwarf@panix.com

2005-01-31, 3:55 am

In article <X8aLd.9033$JF2.4476@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
><docdwarf@panix.com> wrote in message news:ctio6h$a26$1@panix5.panix.com...
>
>This is the Peter and hit Principle...I interpret 'their management' with
>the implicit 'chain' (those in charge).
>Perhaps another fine example of one not taking the exact literal of your
>meaning !

Eh? When one states 'a fish rots from the head' it might not an
invitation to expound on refrigerating seafood, no.

>
>I also assumed that you - being of integrity - would attach blame where it
>*should* be thereby making it *is*.

Your assumptions and my integrity aside... there are things about which I
am unsure, hence my tendency to use the subjunctive.

>Perhaps yet another fine example of one not taking the exact literal of your
>meaning !

Refrigeration is needed for seafood because a fish... oh, never mind.

>
>My gran lived in the WW II, she couldn't afford milk so she didn't have a
>milkman....maybe the same postman.

There's more than one way to make sure the male's delivered, aye.

>
>Also, if I wanted to DD you (don't go after me like the Tivo anti
>brand-as-verb execs) I would lustfully point out that I didn't say that you
>could be fired for being right. I said you could receive blame for
>executing something successfully. But, as the provided advice was sage, and
>predated this thread, I will let it go :-)

How generous of you.

>
>And no one corrected you? Geez...the internet was no fun back then
>
>I have to say that the sage counsel was made up of wise words indeed.
>Hmmm...the words are not wise....but the counsel was wise.....you know what
>I mean :)

As Wittgenstein puts it, 'I cannot know what you mean, only what you say'.

DD

jce

2005-01-31, 8:55 am

"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1107128575.221971.106350@f14g2000cwb.googlegroups.com...
> "Ah...now you touch on it...it really isn't a hardware platform issue
> ...it's
> a software platform issue.....only a specific instance of a failed
> project
> knows why the project failed and I'd venture a guess that 75% of
> projects it
> is not the hardware... "
>
> First, I generally deal with systems that process huge amounts of data.
> In the accounting system's case, data was sent to it across the
> internet. That data was processed to produce bills and statements.
snip snip
> Steve.T

Fair points.

Initially you stated:

"I'm looking for a web site that I think exists that shows all the
failed whoopie-wow projects. You know, like the attempted Siebel
implementations (where they tried to take over something being done on
a mainframe)."

I think the issue here is migrating an existing CRM solution to Siebel. This
is software not hardware - generally speaking.

With further explanation I see how your particular example was primarily
hardware driven...

JCE

Richard

2005-01-31, 3:55 pm

> The w

ly check run took two hours on two fire-breathing mainframes
> ...
> The new system went live on-time and on-budget.

It seems the story is rather different: previously you had:

RW> Tight assembly language, probably written in the '60s, runs very
FAST on a
RW> modern mainframe. That payroll system could plow through a 1G
master file and
RW> compute 200K paychecks in less than 15 minutes. The first attempt
on PeopleSoft
RW> took longer than 12 hours. Speeding it up required partitioning the
database
RW> over 30 disks and using lots of parallel processing. Thirty
high-end servers
RW> were still cheaper than two monster mainframes.

The numbers have changed, mainframe seems to have slowed from 15
minutes to 2 hours to suit the Unix result while originally it seemed
that the extra servers had to be added which would have increased the
budget.

That is always a problem with making things up, it is so hard to
remember how much you exagerated last time.

steve.t

2005-02-01, 3:56 am

I think his name in real life is Al Gore

Robert Wagner

2005-02-01, 3:56 am

On 31 Jan 2005 11:15:24 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>It seems the story is rather different: previously you had:
>
>RW> Tight assembly language, probably written in the '60s, runs very
>FAST on a
>RW> modern mainframe. That payroll system could plow through a 1G
>master file and
>RW> compute 200K paychecks in less than 15 minutes. The first attempt
>on PeopleSoft
>RW> took longer than 12 hours. Speeding it up required partitioning the
>database
>RW> over 30 disks and using lots of parallel processing. Thirty
>high-end servers
>RW> were still cheaper than two monster mainframes.
>
>The numbers have changed, mainframe seems to have slowed from 15
>minutes to 2 hours to suit the Unix result while originally it seemed
>that the extra servers had to be added which would have increased the
>budget.

The program that computed paychecks did run in 15 minutes. It was one
of 20 programs in a jobstream that took 2 hours.

Now that you jogged my memory, there were 30 servers rather than 24.

>That is always a problem with making things up, it is so hard to
>remember how much you exagerated last time.

Reality is the antedote to (your) solipsism.

Call Sears HQ in Hoffman Estates, Il, and ask the payroll system
manager to describe what they're running. Verify that it was installed
in 1998-9 by Deloitte Touche and Keane. Then, if you insist, I'll scan
and send a tax document showing I worked there during that period.

Robert Wagner

2005-02-01, 3:55 pm

Robert Wagner

2005-02-01, 3:55 pm

William M. Klein

2005-02-01, 3:55 pm

Robert Wagner

2005-02-01, 3:55 pm

Robert Wagner

2005-02-01, 3:55 pm

Peter Lacey

2005-02-01, 3:55 pm

Robert Wagner

2005-02-01, 3:55 pm

or two someone asks here how to read a 'Cobol file',
because someone sent a raw file.

Robert Wagner

2005-02-05, 3:55 pm

docdwarf@panix.com

2005-02-05, 3:55 pm