HELP
Rick Kennett
Director from a division of EDS. She has lamented from day one "We need
new technology". What the hell she means by that she has been unable to
explain but her continual complaining and her "EDS Pedigree" has given
her far too much credibility with ownership. Her first attack came early
as she attempted (unilaterally) to engage Computer Science Corporation
(where her ex EDS techies went) to 'upgrade our technology'. The price
tag startled ownership. She has since found a 'boutique' consulting firm
and we now have 4 consultants tooling around doing a Business Technology
Review with their meters running at $200.00 an hour. They have
recommended to management and ownership that we cease all development
projects as they may find that the 'whole system needs to be replaced'.
Lord.... What a surprise!
In any event, without going into a long winded defense of our system
suffice it to say that they are full of it and what they are looking for
is a platform they are familiar with, can recommend, deploy and keep
their freaking meters rollin.
I know there is a great deal of difficult associated with the migration
from a MV environment to plain ole relational but can anyone point me to
some good material. Documents that would rebut what we are about to hear
from our experts?
Sure would appreciate it.
Thanks
Rick
Homer L. Hazel
"Rick Kennett" <ri...@guildweb.com> wrote in message
news:3971AF7C...@guildweb.com...
Rick,
I don't know of anyplace where documentation exists, but surely there must
be some. I have two tales which might interest you.
Two of my clients migrated from AP/Pro to Progress. One to a package called
MFG-PRO and I cannot remember what the other one went to. Is there a
package called SYMIX or something like that.
The one that went to progress spent about $300,000.00 on just hardware and
software licenses. They were running on a Pentium Pro 200 Mhz with 40
users. I converted them to this from an Adds Mentor in about two weeks -
total price about $15,000 - including hardware and Software (40 Pick users)
and my time to do the conversion. The performance increase was incredible.
For example, the MRP Process that used to take at least 8 hours overnight
was able to finish - during the day - in only 15 minutes. When they
converted to Progress, they had to keep the AP/Pro system up and running to
check out dozens of things that were not included in the new improved
software. They also had to buy a big HP-8000 computer to handle the load of
10 users - yes, that's right, a mere 10 users.
The other company has kept their Pick machine up and running for three years
after the conversion. They just finally contacted me last week to come out
and re-convert all of the data from the Pick computer to EXCEL spreadsheets.
I don't know how much money these people spent. I do know they had a full
time Progress consultant on hand for 8 hours a day for over 6 months during
the conversion. I think they were paying him about $100.00 per hour.
I wish I could remember the lady's name, but I attended a Pick show one year
in Anaheim and this lady was at one of the sessions. She was nailing the
presenters to the wall - they were not a Pick based application, but had
another database engine. She asked how long it should take to convert
something silly like a 20 line proc to work with the "X" database. They
said it should take less than 8 hours. Then she asked why it had taken them
4 months to do the same conversion on her system. I cannot remember the
full time involved, but after trying to convert the full system for well
over a year, they finally gave up and just put everything back on the Pick
computer.
But, for your information, in both of the cases I experienced above, I was
sabotaged by an insider. The first was the company controller who was hired
from a company that had previously had this wonderful new package they
converted to. Surprise, Surprise!
The second company was bought out. They wanted to do the conversion in the
first year, but the local president said he needed to make certain dollar
goals and he would not commit to the $300,000 and still make his goals.
They didn't do the conversion until after they finally forced him out of the
picture. Ain't politics wonderful?
I hope this helps.
Larry Hazel
Tony Gravagno
environment, bought into the consultant hype, blew millions, trashed their
stock, took transaction time from seconds to minutes, and never really got
the job done anyway? Hostpital? Insurance? that was a testimonial if I
ever heard one. There are lots of these stories, but I don't think you're
going to win on the battlefield of horror stories.
Rick, I think the thing to do in this case is to get a firm definition of
what needs exist which are not satisfied by the existing system - real or
imagined. Then you can shop around to see what it would take to implement
those features into the existing system while the HR lady does her own
investigation. Absolutely nothing can be done if the specs keep changing,
so something must be carved in stone before the redevelopment or enhancement
process begins. If there is no plan, then there is another problem which no
computer system will ever fix, and that must be remedied before the search
for IT excellence is conducted. (Yeah, I know, plans change anyway - but
there needs to be a plan first.)
Now take a step back for a moment. It's possible, sorry to say, that your
application does need a major overhaul. Just because it's written over the
MV model doesn't make it great, and it could be missing a lot of bells and
whistles that people are used to these days. If this HR lady has some valid
points, you can't totally dismiss them. Maybe the solution IS to get
another app. Of course, it would be nice to stay with MV, so you may need
to shop around within the community for new apps or plug-ins that satisfy
the needs assessment, if that assessment is valid.
I think we also need to clarify that converting out of a Pick database
is not difficult at all - especially today when we (at least D3) can create
maps to make it look like we're as flat as the rest of the world.
The first problem people encounter is trying to find some Brand X
application in the market that has anywhere near the features of the exising
applications. The conversion is difficult because they realize after they
have bought Brand X that it doesn't have what it promises, and that just
getting back their existing functionality will cost a fortune in consulting
and development time and money.
The second problem people have (finger points back at all of us) is that
there isn't enough expertise in our market to talk up all of the things that
we CAN do, so the Brand X guys have a field day talking about all the things
that they think we can't do, and no one is around to argue. We can only
address this with education - and you know that Pick Systems is trying to
address this issue now.
So:
(1) Get a feature breakdown of what they want and what you have,
identify differences.
(2) Make inquiries here in CDP and find out what it will take to bridge
the gap.
(3) Partner up with your VAR or Service Provider for info and support.
If you don't have a VAR and If you're a Pick Systems customer, please let me
know and I'll get you hooked up with some sales and technical people. And
if you're not a Pick Systems customer, maybe you can make your own proposal
to make a conversion to D3 as a first step toward getting all the features
that they are talking about. Then you can hook yourself up with our
Professional Services and/or a knowledgable VAR who can help with the
details.
Good luck, and please let us know how this pans out.
Tony
Jeff Caspari
I have seen what you outlined time and again. It's sad, frustrating and
downright infuriating. A ton of money is spent on the process which really
could be better spent in so many more productive ways (simply giving it to
American Cancer Society would probably yield better results).
The worst thing is to watch this happen and be powerless to stop it.
The truth is, if the management is inclined to allow this to happen there is
little that can stop it.
That it has gotten this far is a strong indication that the process will
continue for a while because the more invested your company becomes the
harder it will be to justify abandoning this endeavor without implementing a
major change.
Here's my advice:
Keep an open mind to anything of value that is uncovered by the process.
Do not position yourself as a rebel. Try not to alienate anyone.
Keep a tally of the money invested.
Continually draw comparisons between the costs and the benefits.
Insist (and document) when any of the current capabilities of your system
are lost in the process.
Urge management to demand a justification of the costs.
Recognize your limitations.
Keep us posted and best of luck to you and your company.
Jeff
Rick Kennett <ri...@guildweb.com> wrote in message
news:3971AF7C...@guildweb.com...
K. Powick
One of our clients spent $US 15,000,000 on an AS/400 ASI software
combination that has really not put them any further ahead than they
were 10 years ago. One of their departments still uses AP/Pro and is
the envy of the other poor sods that are stuck with AS/400.
Unfortunately, once you head down a path with that big a commitment,
it's hard to turn around and tell your bosses that maybe it wasn't the
way to go. So you live with it.
Problem with consultants is that they always say what you have is crap
and that you need to implement what they recommend. It's funny how
they always recommend the same vendors as they did on their last
contract.
I know of another company that spent a hundred grand to have IBM
consult on their choice of new system vendor. Guess who IBM said
should do it? YES, amazingly they said IBM would be the best to
fulfill their needs.
I saw quote somewhere that pretty well sums up consultants. "A
consultant is a guy who borrows your watch to tell you what time it is
and then charges you $250.00"
On Sun, 16 Jul 2000 08:50:05 -0400, Rick Kennett <ri...@guildweb.com>
wrote:
>This is a multi-part message in MIME format.
>--------------A7E9BAFB7E58A21C8A3D235D
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>We are in a pickle.... Several months ago our company hired a HR
>Director from a division of EDS. She has lamented from day one "We need
>new technology". What the hell she means by that she has been unable to
>explain but her continual complaining and her "EDS Pedigree" has given
>her far too much credibility with ownership. Her first attack came early
>as she attempted (unilaterally) to engage Computer Science Corporation
>(where her ex EDS techies went) to 'upgrade our technology'. The price
>tag startled ownership. She has since found a 'boutique' consulting firm
>and we now have 4 consultants tooling around doing a Business Technology
>Review with their meters running at $200.00 an hour. They have
>recommended to management and ownership that we cease all development
>projects as they may find that the 'whole system needs to be replaced'.
>Lord.... What a surprise!
>
>In any event, without going into a long winded defense of our system
>suffice it to say that they are full of it and what they are looking for
>is a platform they are familiar with, can recommend, deploy and keep
>their freaking meters rollin.
>
>I know there is a great deal of difficult associated with the migration
>from a MV environment to plain ole relational but can anyone point me to
>some good material. Documents that would rebut what we are about to hear
>from our experts?
>
>Sure would appreciate it.
>
>Thanks
>
>Rick
>
>--------------A7E9BAFB7E58A21C8A3D235D
>Content-Type: text/x-vcard; charset=us-ascii;
> name="rickk.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for Rick Kennett
>Content-Disposition: attachment;
> filename="rickk.vcf"
>
>begin:vcard
>n:Kennett;Rick
>tel;work:631-232-5045
>x-mozilla-html:FALSE
>url:http://www.country-life.com
>org:Country Life
>adr:;;180 Motor Parkway;Hauppauge;New York;11788;USA
>version:2.1
>email;internet:ri...@country-life.com
>title:Director of Infomation Systems
>fn:Rick Kennett
>end:vcard
>
>--------------A7E9BAFB7E58A21C8A3D235D--
>
Kevin Powick
Trident Information Systems
kkp(at)tridentinfosys(dot)com
Concerned_Netizen
Andy Jayasinghe
We have many sites running our Pick Software and some of them are over
10 years old. We have seen and heard all the stories from our customers
that our systems are 'old fashioned' 'Not user friendly' 'The reports
are odd' and ' We have brought in a consultant to recommend another
system !'
We just ask for one opportunity when we hear of some discontent and the
need for a new system ... 'Please let us speak to the actual users and
find out what problems they have with the system' or 'Tell us where the
system is losing you money or where the system is stopping you making
more money or where the system could save you some money'. If we are
not given the opportunity to ask these questions and have answers then
we know that the consultant or an internal manager is upto some good
old brain washing of existing users/management and is fast creating an
'anti current system' scenario. However with the type of questions
being asked by us the powers that be quickly realise that we are acting
in the interest of their business and prompt the 'culprits' to provide
the answers and whilst they are providing the answers some questions
which are material to the cost benefits of dumping the 'old' system
comes up and then..... enlightenment.
You will also find a great deal of material to improve your present
system from this exercise.
We always say 'Give the consultant enough rope to hang himself'
Try impressing the managent by finding out what they need to improve
profitability of your company.
We all know how fantastic pick is, however the gurus who work with
objects, tables and linked tables cannot understand the pick data
structure and its advantages.... How about educating your enemies with
the virtues of pick.. All you need is a small program to convert your
access output to excel or even use odbc (if your pick system allows it
to show the data in microsoft query. If you can get your guys to look
at MVbase or D3 and allow the pick sales and techies to present pick
using current 'jargon' it will suddenly look very attractive to those
people who have not seen it before or even the ones who have seen or
heard of it in its 'old' format.
If by chance your system's functionality is out of date and it needs a
re-write concentrate on the areas of your business which has the most
complicated data structures and the speeds at which pick can handle
this data vs a flat file solution. You must show them that a re-write
in pick will give them a system that will be modern and it will last as
long as their current system and the cost of re-writing will be a much
less because pick has proved that it can handle your company's data
structure and its business rules. Ask your flat filers whether they can
give this assurance without a major system study (at a huge cost) and
months if not years of de-bugging and obtaining user acceptance.
Please keep us posted..
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
nos...@adomain.com
wrote:
>Anyone remember the name of that place that wanted to migrate from an MV
>environment, bought into the consultant hype, blew millions, trashed their
>stock, took transaction time from seconds to minutes, and never really got
>the job done anyway? Hostpital? Insurance? that was a testimonial if I
>ever heard one. There are lots of these stories, but I don't think you're
>going to win on the battlefield of horror stories.
Sounds like Oxford Health Plans (HMO). Now with more than 8 years
attempting to convert MV to Oracle. More than $250M spent and still
no chance of getting totally off MV any time soon. Things really went
south for this company when they went to production with Oracle
billing. No billing went out for months and the finance dept started
cooking the books. When Wall Street found out, 'fair haired' stock
went from $90+/share to less than $15 overnight. Not entirely
Oracle's fault either; this was by far the most poorly organized
project I've ever seen from both a management and developer
standpoint. IT managers were way over their heads and developers were
poor technically and had NO knowledge of the business. Bottom line -
CEO refused to back off Oracle - couldn't justify spending enormous
conversion costs to shareholders if he were to stop the project. Now
he and most all of management is long gone. The real crime in all of
this is that the software/hardware/licensing could have been easily
upgraded in MV for less than $25M without ever loosing a heartbeat.
Fact of the matter is that a lot of good managers went down the drain
that had no involvement with IT or the other problems that resulted.
This was a really dynamic HMO that really had excellent benefits for
the members; now it's like all the rest except there is now a bunch of
retail industry moguls running the show. Any manager that lasts more
than a year is most unusual. Most of the troops just blindly follow
orders and hope for better days.
>
>Rick, I think the thing to do in this case is to get a firm definition of
>what needs exist which are not satisfied by the existing system - real or
>imagined. Then you can shop around to see what it would take to implement
>those features into the existing system while the HR lady does her own
>investigation. Absolutely nothing can be done if the specs keep changing,
>so something must be carved in stone before the redevelopment or enhancement
>process begins. If there is no plan, then there is another problem which no
>computer system will ever fix, and that must be remedied before the search
>for IT excellence is conducted. (Yeah, I know, plans change anyway - but
>there needs to be a plan first.)
>
>Now take a step back for a moment. It's possible, sorry to say, that your
>application does need a major overhaul. Just because it's written over the
>MV model doesn't make it great, and it could be missing a lot of bells and
>whistles that people are used to these days. If this HR lady has some valid
>points, you can't totally dismiss them. Maybe the solution IS to get
>another app. Of course, it would be nice to stay with MV, so you may need
>to shop around within the community for new apps or plug-ins that satisfy
>the needs assessment, if that assessment is valid.
>
> I think we also need to clarify that converting out of a Pick database
>is not difficult at all - especially today when we (at least D3) can create
>maps to make it look like we're as flat as the rest of the world.
I disagree. This speaks of the tools. The technology is there in all
the MV products to do it relatively easily but the data relationships
are totally different than what you find in other database
technologies. This is accentuated even further when you look at the
impact of pick based dictionary code. Moving the data is easy, making
relational sense of it all is a totally different concept that many
people on the other side of the fence fall apart with. How often I
have watched these people just think that the data is a one to one
move. When you add in application methodology differences and coding
constraints of the target, the data migration task can get
overwhelming very quickly. And in some cases, the target application
REQUIRES some data that historically does not exist often causing this
application to fail. Custom coding on the target system is the only
way around it.
> The first problem people encounter is trying to find some Brand X
>application in the market that has anywhere near the features of the exising
>applications. The conversion is difficult because they realize after they
>have bought Brand X that it doesn't have what it promises, and that just
>getting back their existing functionality will cost a fortune in consulting
>and development time and money.
Another aspect often overlooked is what is the real cost in terms of
disruption to the company? Retraining the end users is almost never
considered fully. How about the overtime and/or extra people
necessary at the end user level required to offset the slow
productivity during the transition? How much business will be lost
when customers notice the big bump in the road? The IT dept in
particular will be totally different in the end. Totally different
technology almost always means a 90% turnover in your staff in the
long run. During the proposal stage make sure that these aspects are
covered and explained fully to the satisfaction of the ownership. If
they are smart, they will add it in (and maybe axe it). If not, they
have no one to blame other than the HR lady and her band of merry men.
> The second problem people have (finger points back at all of us) is that
>there isn't enough expertise in our market to talk up all of the things that
>we CAN do, so the Brand X guys have a field day talking about all the things
>that they think we can't do, and no one is around to argue. We can only
>address this with education - and you know that Pick Systems is trying to
>address this issue now.
To some extent this is true, but I have found that there is a strong
contingent of managers in large businesses that get sucked up in the
hype. Changes are more based on how 'successful' they appear when all
is said and done (resume building at it's best). A big piece of
what's going on is an economy that has been too good. Efficiency
seems out the window for now with far too much money being thrown at
IT in order to keep up with the rest of the pack. How players like
Datapro envision and report the recent events in the MV world will
have a big impact on the future. What is happening over at Informix
with the top end of the house is important too - Not just Pick
Systems. This could be viewed as a resurgence in the MV world if some
big players were to hop on board. The fact of the matter is the MV
model is a far better data structure for dealing with the web based
world; now it needs to be clearly demonstrated.
CWNoah2
There is only one thing I can add to Jeff's excellent advice:
If these things don't appear to be working, update your resume.
Regards,
Charlie
"Jeff Caspari" <q...@idt.net> writes:
>> We are in a pickle.... Several months ago our company hired a HR
>> Director from a division of EDS. She has lamented from day one "We need
>> new technology". What the hell she means by that she has been unable to
>> explain but her continual complaining and her "EDS Pedigree" has given
>> her far too much credibility with ownership. Her first attack came early
>> as she attempted (unilaterally) to engage Computer Science Corporation
>> (where her ex EDS techies went) to 'upgrade our technology'. The price
>> tag startled ownership. She has since found a 'boutique' consulting firm
>> and we now have 4 consultants tooling around doing a Business Technology
>> Review with their meters running at $200.00 an hour. They have
>> recommended to management and ownership that we cease all development
>> projects as they may find that the 'whole system needs to be replaced'.
>> Lord.... What a surprise!
>>
>> In any event, without going into a long winded defense of our system
>> suffice it to say that they are full of it and what they are looking for
>> is a platform they are familiar with, can recommend, deploy and keep
>> their freaking meters rollin.
>>
>> I know there is a great deal of difficult associated with the migration
>> from a MV environment to plain ole relational but can anyone point me to
>> some good material. Documents that would rebut what we are about to hear
>> from our experts?
>>
>> Sure would appreciate it.
>>
>> Thanks
>>
>> Rick
Charlie Noah (CWN...@aol.com)
Homer L. Hazel
You could also just take some classes in
[choose as appropriate]
[ ] SQL
[ ] ORACLE (complete with 3 coupons for private investigators)
[ ] SAP (now you can be one)
[ ] SYBASE
[ ] PROGRESS
[ ] ETC
Larry Hazel
"CWNoah2" <cwn...@aol.com> wrote in message
news:20000718062645...@nso-fv.aol.com...
va...@caligormed.com_remove
for Oxford when they began thier disaster.... I forwarded this to him and he
asked me to post his reply....
Vance Forste
MBM.
-----------------------------------------------------------------
Thanks for the article - it is as entertaining as it is sad.
Is is so difficult to grasp the concept of three dimensional world vs.
two dimensional table? But ignorance is unbeatable.
I think that the same faith is in the future for this company if they do not
understand the impact - they will fall on their face and bankrupt the
company. And the lady advisor will go to destroy the next victim with her
resume claiming a big victory.
I can provide them with so many examples, although the story with OXHP is a
perfect one. But those people would not listen until they will lose their
shirt. But it is shareholders' money and not their own - so why shoudl they
care.
Vance, please post my response, I wish I could help, but I doubt that
anybody will listen. Same old story all over again.
Gary Kanevsky
MBM
---------------------------------------------------------------------
<nos...@adomain.com> wrote in message
news:3pa6nssl4v9rhblmq...@4ax.com...
Darren
K. Powick <NoS...@SpamLess.com> wrote in message
news:3973143b...@gollum.kingston.net...
> >Director from a division of EDS. She has lamented from day one "We need
> >new technology". What the hell she means by that she has been unable to
> >explain but her continual complaining and her "EDS Pedigree" has given
> >her far too much credibility with ownership. Her first attack came early
> >as she attempted (unilaterally) to engage Computer Science Corporation
> >(where her ex EDS techies went) to 'upgrade our technology'. The price
> >tag startled ownership. She has since found a 'boutique' consulting firm
> >and we now have 4 consultants tooling around doing a Business Technology
> >Review with their meters running at $200.00 an hour. They have
> >recommended to management and ownership that we cease all development
> >projects as they may find that the 'whole system needs to be replaced'.
> >Lord.... What a surprise!
> >
> >In any event, without going into a long winded defense of our system
> >suffice it to say that they are full of it and what they are looking for
> >is a platform they are familiar with, can recommend, deploy and keep
> >their freaking meters rollin.
> >
> >I know there is a great deal of difficult associated with the migration
> >from a MV environment to plain ole relational but can anyone point me to
> >some good material. Documents that would rebut what we are about to hear
> >from our experts?
> >
> >Sure would appreciate it.
> >
> >Thanks
> >
> >Rick
> >
pic...@my-deja.com
Health debacle. One of the links was to a resume for someone who
worked there on the "backbridging" project - moving all the Oracle
transaction data to the "legacy Universe" system.
Hur Hur Hur Hur Hur
Sent via Deja.com http://www.deja.com/
Before you buy.
nos...@adomain.com
>I tried various Internet searches to get some background on the Oxford
>Health debacle. One of the links was to a resume for someone who
>worked there on the "backbridging" project - moving all the Oracle
>transaction data to the "legacy Universe" system.
>
>Hur Hur Hur Hur Hur
>
Most of the information was published by the financial press at the
time. A search of web sites like the Wall Street Journal, Dow Jones,
New York Times and the like should produce more of what your looking
for.
va...@caligormed.com_remove
today... Anyway this is what I found out ...
You might find this of some use, to fight the conversion.... (Maybe not ?)
Interesting outcome ...
Vance Forste
MBM
***********************************
As far as I know - OXHP is successfully processing all claims on
UniVerse and abandoned all efforts to convert to Oracle. OXHP prospered
using PICK software since inception and collapsed because of this
attempt to convert 3-dimensional arrays to flat Oracle tables. They got
rid of all Oracle developers long ago together with all mindless middle
managers who pushed "new technology" as a buzzword. Steve Wiggins - the
top executive and original creator of OXHP is also kicked out of there.
Now the company is doing better and stock price went from ~ $7 back to
around $25.
Thanks to good old and reliable PICK software.
Gary Kanevsky
MBM
<pic...@my-deja.com> wrote in message news:8l2s0c$k3b$1...@nnrp1.deja.com...
> I tried various Internet searches to get some background on the Oxford
> Health debacle. One of the links was to a resume for someone who
> worked there on the "backbridging" project - moving all the Oracle
> transaction data to the "legacy Universe" system.
>
> Hur Hur Hur Hur Hur
>
>
pic...@my-deja.com
Oxford
> >Health debacle. One of the links was to a resume for someone who
> >worked there on the "backbridging" project - moving all the Oracle
> >transaction data to the "legacy Universe" system.
> >
> >Hur Hur Hur Hur Hur
> >
> time. A search of web sites like the Wall Street Journal, Dow Jones,
> New York Times and the like should produce more of what your looking
> for.
>
--
Oh, I found quite a lot of stuff written at the time. Fromn this, it
appeared that the problem was a combination of
1 - The bad data in the Pick system
2 - The methods used to batch up the data (one failure and the whole
batch was rejected)
3 - Bad project management, especially in testing
What I really wanted to know was whether they were on Oracle or Pick.
Now I know that they are back on Pick. Hence the smug chortle.
Henry Eggers once contrasted Pick as a 'liberal-humanistic' database
versus the 'technocratic fascist' ones. I agree with him - the
relational database people put all these rules in their databases that
just slow things down. Something I continually meet is a bafflement
that the crap data in our database doesn't seem to hinder the business
operation.
I'll give an example:
Our marketing people wanted to get age bands of customers buying into
investment funds. I had a look and found that 50% did not tell us
their birth date. Not a problem, I just gave what I could and made
sure they understood the limitations. When I discussed this with a non-
Pick guy, his response was that we shouldn't take the customer's money
unless they gave their birth date. He then rationalised his stand by
saying that we had to do this to prevent money-laundering! (Holy cow,
this direct debit is out of a gangster account - luckily I got his
birthdate)
servico
M.I.S. director telling the CFO about an article in the WSJ regarding PICK
data corrupting Oracle. Of course, they were outsiders eager to purchase
someone else's source code and then modify it to suit "our" needs. But no
one would sell us source for less than $150K . . . they finally decided to
trash our payroll system and purchase an ADP product based on ORACLE and
running on NT 4. That never came to fruition. The ADP rep was astounded
when I told him our entire payroll system ran in 32 MB of memory and took up
less than 100 MB of storage.
And once all the data entry was done, one could process the entire payroll
about 3500 checks plus attendant reports ) in under 4 hours. And these
were NOT laser checks. ( I love PRINTRONIX printers! ) I asked him,
disingenuously, if Oracle was a resource hog. "Absolutely!" Of course, they
spent time, money and energy on the project and then canceled it when our
company's management decided to "improve" its chances of survival by merging
with another. A company with a "better" IT structure, i.e. Oracle and an
intranet. Everyone's gone now except a few accounting people. And
somewhere, out there, sits "MY" IBM PowerStation 580 running AIX 3.2.5 and
Advanced Pick 5.1 and all my mentor's RPL source code from 1982 on . . .
doing absolutely nothing except providing people with access the means of
looking up historical data. And the company which resulted from the merger?
Well, I recently heard they are trashing most of the work they've done for
the past 2.5 years to out-source everything.
I'm always amazed at the attitude of "new" people. Instead of learning how
to use what you already have, and perhaps appreciating it, they insist on
replacing everything with something else; something "bigger"; something
"brighter"; something HUGELY expensive! Its a variation on
Not-Invented-Here syndrome. And if you resist, you're branded a Luddite!
The Luddites knew their lives were going to be changed irrevocably. They
were seeking to minimize the damage to their way of life. Is that wrong?
Amusingly enough, the same people who insist on forcing their agenda on
everyone else are looking for a mature, stable platform. BWA-HA-HA! Is Unix
mature and stable? Or is it old and decrepit? I've heard it characterized
both ways. People are shocked when I tell them how long the PICK data model
has been around. But then again, they've never heard of it. I remember
occasionally seeing an ad for PICK Systems in DataBase and Design Magazine.
I'd cut them out and hang them on my office door because it seemed to
legitimize my claims.
Sigh!
I apologize for the rambling nature of my diatribe. I've been out of a job
for almost 12 months and PICK jobs are hard to come by in South Florida. I
have other computing skills but would prefer to work in the MV community.
Oh, well . . .
Still lurking after all these years.
nos...@adomain.com
>Oh, I found quite a lot of stuff written at the time. From this, it
>appeared that the problem was a combination of
>
>1 - The bad data in the Pick system
This was true. The problem here is that the application did very
little input data validation. It was common to find records with
symbols, control characters, and the like. This problem was presented
to IT management, but their position was that the application was
going away, so live with it. In most cases the actual transaction
ended up being duplicated (without the control key or whatever) with
the original bad record left half baked in the system. IT management
refused to allow the junk to be purged either.
At one point the application was converted from an old Sequoia to
Universe on a Pyramid machine. The Pick developers were forced to
ramrod this conversion through in less than a month (curious how the
Oracle types had spent more than 3 years at this point). To say there
were problems when the application went to production would be an
understatement of gross proportion. Pyramid and VMark had really
cooked the books with the benchmark they had created (an interesting
story in its own right, no disk i/o, no write activity, no locking,
etc), so it was no surprise that the new system had some serious load
issues from the day production started. The first problem was the
lock table. The answer to this from the fine VMark consultants was to
clear out the entire lock table periodically and subsequently trash
the data. My way to combat this was to check that the system lock for
the record was there before writing the data. This was
unacceptable!!!??? The Vmark types had convinced the IT management
that it was better to live with the corrupted data instead. I was
gone shortly afterward. They also did some other unorthodox things to
try to get the machine to try to live up to the bogus benchmark; like
remove the unix syncer and have /tmp space totally volatile on
electronic disk (no writes to a real disk - we certainly didn't want
anything to help us reconstruct things). If it crashed (which it
often did), it meant that everything that was in memory was gone. If
the application changed something that was basic to the application
and remained memory resident; a crash would destroy thousands of
transactions. I remember a phrase that we used to describe the
system, 'It's like driving a Ferrari at full speed without brakes!"
Of course failures of this nature were always the fault of the Pick
architecture and the applications people.
>
>2 - The methods used to batch up the data (one failure and the whole
>batch was rejected)
Basically a combination of two things; the corrupted data mentioned
above, and a problem with data that was not in sync relationally.
They would batch up data and convert it. Then batch another relative
area and not understand why it didn't match up even though they were
fully aware that hundreds of thousands of transactions had occurred
between the two. If the whole mess didn't match up they would trash
the whole thing and start over. I wonder why things got so
backlogged?
>
>3 - Bad project management, especially in testing
This was a comedy! The Oracle management made it a point to hire
developers that knew nothing of the health care industry (don't want
polluted thinking nor anyone who could potentially threaten their own
expertise). Their method of achieving this was to hire any and every
foreign national they could find. Individually they were ok, but any
time any one of them attempted to find out anything form the pick
people or the end users, they were shut down immediately. We coined
the place as the United Nations; without the benefit of interpreters
that the real one has. Communication was next to impossible with
serious ethnic clashes as well. A real classic was a situation where
the Project Manager was from Pakistan and the System Architect was
from India (maybe the other way around). This meant that everything
automatically became a contention for ethnic reasons. Some other
managers were more adept with who they slept with than anything else.
There were some basic architecture problems that didn't show up in
testing. The bottom line is that the application was structured to
allow an end user to have the capability to change anything. The
architecture was setup to immediately lock all parent records.
Processing a claim requires data from just about every module in the
system. Locking all this data (hundreds or thousands of records; just
about every table) caused all of the modules to come to a screeching
halt with cross locking problems. Testing didn't show it where they
were testing small areas of a particular module at a time. A full
integration test never happened; they had already thrown previously
tested modules into production and the pick side was shutdown with
data backstaged across. The bottom line is the application could
never work without completely backing things out and redesigning the
locking scheme. Management would never allow this.
>
>What I really wanted to know was whether they were on Oracle or Pick.
>Now I know that they are back on Pick. Hence the smug chortle.
From what I understand from some people I still have contact with
there, is that they are still running in a combined environment.
Oracle is handling most of the low level data entry, the data is
converted and shipped to the Universe side where all the serious
crunching takes place. Some people came up with some real solutions
that would in fact move everything back to pick, but management was
not interested. The 'new' management that is there is far too focused
on change control than fixing anything. A simple cosmetic change can
take 6 months. Managers just sort of lay low and hope nothing breaks;
if it does - they are gone!