Usha wrote:
What if the network engineer that set up the 2003 server got hit by a
bus? You are looking at many days figuring out what they did and where
they did it. I have taken over many older Pick sites and converted them
to newer Multi-value solutions. There are many Pick programmers out
there. With people like Dawn talking to colleges and others hopefully
more programmers will get on the multi-value bandwagon. I know anytime
I've shown the power of Multi-value to SQL and other programmers their
jaws drop open that a system can do what MV does.

It is not a question of an old product that cannot compare to what else
is now out there. It is more of a question of not enough press and
education.

And don't get me started on education, because I have much to say about
today's colleges that teach things that are not relevant in the business
world. I took a course in programming at Jamestown Community college
once and told the prof, after I got my grade, that what he was teaching
was not what the real world was using and further that if he was on my
staff he would have been fired quite some time ago.

What if an
Which is a good reason to migrate to a version of Pick (read
multi-value) that runs on systems that do exist today such as D3, Jbase,
etc. Which in many cases is a simple re-compile and in other cases
slightly more complex but no where compared to totally re-doing an app.
Yes, someone new to the group might do that just like a person miught go
on the chocolate lovers group and suggest switching to vanilla. But why
since chocolate works just fine. Why go on the Dodge group and push Ford
or Chevy downplaying Dodge?

Is it that some people think the group members are not smart enough to
know there are other solutions out there? Been there. Done that. MV is
the only avenue I would pick (pardon the pun).

Richard Kann
Comp-Ware Systems, Inc.

Usha wrote:

hehe - don't leave the kitchen Usha, but I warn you it can get even
hotter.

You have some valid points and some not. I think you have enough
valid points and sincere interest that you should not (and it appears
are not) considered to be too far off the wall, or beyond help.

One invalid point you cite as justification for changing software is
that all of the key resources may be absent during a critical moment.
I'm afraid that's a management issue which will plague a site no
matter what technology they're using. Your other points in that
paragraph are valid. As you see, this isn't an all or nothing
proposition. But it's this mixture of information and mis-information
that boggles me.

Another point you're making is about the operating system where you
correctly state that Pick used to run on platforms that don't exist
anymore. This is far different than one of your reasons for
migration:
invalid) example of how someone might want to migrate off of an
obsolete OS. Let's assume you had originally said DGUX and your
example would be more correct - I'll give you that.

But this leads to the question about exactly what the real problem is.
An existing application can be ported with relatively few critical
changes to new OS and/or a new MV DBMS environment. You don't
completely replace an application in the name of 'modernization',
whether it's COBOL or MV or otherwise. The OS is a factor, but not a
reason for migration. I'm concerned that you're jumping way ahead
(the phrase comes to mind "throwing out the baby with the bath water")
and looking to replacement of all components (and personnel) in the
name of "modernization", when much less draconian tactical steps can
be taken to achieve the strategic goal.

Maybe the thing that gets me is that you're advocating migration as a
means of modernization, when these things are not directly related.
If you had opened with the idea that for some sites migration is a
simple fact of life - without citing reasons why you think Pick is
fundamentally bad - then you probably would not have been met with so
much resistence here. (Oh yes, and a clue about what you're proposing
that people migrate from, but that comes with time...)

By understanding what value exists already in a given environment, we
as consultants are better capable of providing supplementary value.
(They call it Value-Add Reseller, not Value-Replacement Reseller.)
I'm concerned that you don't understand the value that's already in
Pick/MV environments, so your approach is to propose replacement of
everything according to a planned migration path. My entire business
is based on providing supplementary tools and services to companies to
enhance what they already have. I don't walk into a site believing
everything needs to be replaced before I discuss requirements with the
client. This is the impression I get from you and if it's incorrect
there's nothing in this thread or your article to indicate the
contrary.

On this statement we are in full agreement:
I maintain that many projects are in trouble or fail for lack of
knowledge about the technology - or at least how to adapt technology
to suit business needs. That includes migrations from Java to .NET,
..NET to Java, MV to Relational, etc. This is why I provide services
to enhance what MV sites already have. Like you say, the problem
extends beyond the technology - so why are you proposing migration as
the solution to the problem of modernization? Of course there is a
lot of grey area here and every situation is different. Again,
however, your claims to-date indicate you don't much about the
technology but you're quite willing to replace it, even though you
seem to be aware that specific technologies by themselves are
fundamentally neither bad nor good.

Stick with us a while, and I hope you'll realize that "modernization"
might involve a lot less than you think now.

Regards,
T

Totally tongue-in-cheek replies below, couldn't resist. Chandru

"Usha" <usha.raikar (AT) gmail (DOT) com> wrote

My God, I fervently hope so. If not, quick, call out the troops!

In this case, I see exactly why that company should switch to an IT solution
requiring twenty more personnel. A rationale for increasing staffing has
never been put more eloquently.

Unlikely in the Pick scenario as, in their collective wisdom, Pick
developers refused to implement other languages (with the singular exception
of Microdata's RPG effort in the 70's....wait, did they try COBOL too? I
forget.) Besides, everything I read is that you're required to memorize at
least a hundred mnemonics before you're allowed into the .net or whatever
cavern (citation: TonyG's many posts.)

Yes, I would definitely advocate moving away from DG, Sequoia, DEC and other
80's technology. I make it a rule to never buy from dead vendors.