Future directions for PICK?
Tom deL
After a long absence from any involvement in PICK I have recently been
involved in the enhancement of an old client's D3 based system. This
re-immersion has led me to paraphrase Bertrand Russel:
"Has PICK a future?"
This particular installation has been a huge investment for my client
but has also paid off well over the last 15 years. After seeing another
client ditch their PICK based system for a Windoze based system a
couple of years ago I have to wonder.
RD seems to have a serious case of craniao-rectal disease (heads firmly
implanted elsewhere). If/when they go the way SCO is headed, what will
happen to this clients enormous investment? Yes, the system is very
stable and should continue to be but what happens when we need to
replace or upgrade the hardware and are unable to activate the 100 user
license?
Are there (PICK-like) systems out there that would provide a smooth
transition if needs be from D3/Linux? Windoze as an O/S is not an
option; AIX might be but Linux (or BSD) is by the preference.
TIA for any input!
-Tom
--
"Anyone who trades liberty | "Anyone who trades liberty
for security deserves neither | for the illusion of security
liberty nor security." | deserves exactly what he gets."
-Benjamin Franklin | -Tommie d
Doug Dumitru
>Hello All,
>
>After a long absence from any involvement in PICK I have recently been
>involved in the enhancement of an old client's D3 based system. This
>re-immersion has led me to paraphrase Bertrand Russel:
>
> "Has PICK a future?"
>
>This particular installation has been a huge investment for my client
>but has also paid off well over the last 15 years. After seeing another
>client ditch their PICK based system for a Windoze based system a
>couple of years ago I have to wonder.
>
>RD seems to have a serious case of craniao-rectal disease (heads firmly
>implanted elsewhere). If/when they go the way SCO is headed, what will
>happen to this clients enormous investment? Yes, the system is very
>stable and should continue to be but what happens when we need to
>replace or upgrade the hardware and are unable to activate the 100 user
>license?
>
>Are there (PICK-like) systems out there that would provide a smooth
>transition if needs be from D3/Linux? Windoze as an O/S is not an
>option; AIX might be but Linux (or BSD) is by the preference.
>
>TIA for any input!
> -Tom
Fortunately, there are more players than just Raining Data. Of
course, you could say what I am saying about any single vendor, so
this is not to imply that Raining Data is in any better or worse
position than anyone else.
First, you have a number of commercial platforms that, with some work,
will run your D3 multivalue applications. This list includes:
RainingData D3
mvBase
mvEnterprise
IBM Universe
Unidata
Northgate Reality
Via Univision
jBase jBase
Ladybridge QM
Revelation Open Insight
... and others will happily fill in what I left out.
So you are not beholden to a single vendor, which is good.
More recently, there are two "open source" multivalue databases that
have appeared.
Maverick is a java-implemented MV database still in alpha testing.
Licensed under the LGPL, this is a totally free alternative to
commercial multivalue databases. Unfortunately, it still has a ways
to go in order to be ready to run business applications.
OpenQM is a GPL fork of the QM commercial database from Ladybridge.
It is licensed under the GPL instead of the LGPL which makes it
excellent for in-house "free" use, but typically requires commercial
software developers to purchase commercial licenses. Fortunately, the
commercial licenses are about 15% of D3 or U2. Because OpenQM is
based on the stable QM Linux release, you can argue that its stability
equals D3 and U2.
Hope this gives you some direction.
--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000)
EasyCo LLC do...@easyco.com http://easyco.com
--------------------------------------------------------------------
D3, U2, jBase Virtual Servers. Off-site backup over the internet.
Develop/test/deploy from $20/mo. Fast, secure, cheaper than tape.
http://mirroredservers.com http://mirroredbackup.com
Tom deL
When Maverick started I was quite excited. When I looked at it my
interest waned quickly. I use mySQL extensively and ... why try to
put a PICK nose and glasses on it?
After downloading and installing an eval copy of QM, your 'some work'
gives me cause for concern. From quick look at QM it would appear
to have little resemblence to what I know as "PICK" ... from LIST-FILES
to CREATE-FILE. In fact on their site they made mention of the fact
that OpenQM was explicitly not intended to be compatible (and a read of
their license explanation implies that this wouldn't be in their
plans).
The application that I would be moving began as an R83 system of
hundreds (maybe over 1K) of PICK/BASIC programs and a similar number
of PROCs. I would say that 99% of the system is still R83 compliant,
most of the differences being things that rely on shelling Unix
commands. The ideal path would be to something that was designed
with backward compatibility in mind.
Do any of the existing PICK licensees' offerings provide at least a
modicum of R83 compatibility? The point here isn't having others do my
homework but to get unbiased input from those who have done this
migration. When we originally moved this application to the then
fledgling AP, there were a few headaches but AP was trying very hard to
be able to accept R83 applications.
While I would love to see an open source solution, we have relied on a
commercial vendor for many years so that isn't really an issue.
Thanks again,
-Tom
Kevin Powick
> Do any of the existing PICK licensees' offerings provide at least a
> modicum of R83 compatibility?
Take a serious look at jBASE. http://www.jbase.com We moved from
AP/Pro to jBASE in '96 and have never regretted it.
Highly compatible, fast, flexible, and has migration tools. Versions
for Win32 and *nix. Easy integration with COM, Java, and .Net. Free
download available.
Only "problem" we had with AP/Pro to jBASE was indexes. jBASE has
them, but they work differently than AP/Pro. Maybe I should say they
actually work :-). Kidding aside, BASIC statements used in AP/Pro
don't exist in jBASe. Other than that, jBASE supports what you're used
to: Files, dictionaries, BASIC (jBC), Proc (jCL), Access (jQL),
spooler, etc.
Below is a link to the on-line manual. You'll recognize a lot of it.
TinyURL http://tinyurl.com/6troz
Original URL
http://www.jbase.com/knowledgebase/manuals/3.0/30manpages/man/manpage.ht
m
Initially, moving from a "classic Pick" platform to jBASE can be a
little confusing, mostly because in its default state, jBASE doesn't
have the idea of user accounts. However, it can emulate this quite
easily.
jBASE support (official and peer group) is superb.
--
Kevin Powick
Bruce Nichol
On 5 Dec 2004 11:54:34 -0800, "Tom deL" <pi...@trollsrus.com> wrote:
>Doug, thanks much for your input.
>
>When Maverick started I was quite excited. When I looked at it my
>interest waned quickly. I use mySQL extensively and ... why try to
>put a PICK nose and glasses on it?
>
>After downloading and installing an eval copy of QM, your 'some work'
>gives me cause for concern. From quick look at QM it would appear
>to have little resemblence to what I know as "PICK" ... from LIST-FILES
>to CREATE-FILE. In fact on their site they made mention of the fact
>that OpenQM was explicitly not intended to be compatible (and a read of
>their license explanation implies that this wouldn't be in their
>plans).
True. QM is based on knowldege (l)earned in "t'other side" of Pick -
coming from a Pr1me background......However, Martin has worked hard at
getting *some* - a great deal, actually - vanilla Pick compatibility -
but PROCS, "A" and "S" type DICT items are slated for "future release"
- if ever. The existing "Pick compatibility" is mainly concerned
with alternative BASIC statements (LOCATE, etc) and report generation
(BREAK-ON, etc) .
We spent some time eradicating PROCS - menus and SSELECT's feeding to
programs - and are very pleased with the result under QM.
If you haven't the time, or are not prepared to spend the effort, for
whatever reason, then QM as it stands now is probably a "distant" - as
opposed to "distinct" - possibility in the conversion stakes.
We've been through the conversion experience. Ours was a little
different as a few years ago we converted from Pick AP/PRO to UniVerse
- which has "good" Pick compatibility- thence recently to QM, and I
can't speak too highly of the QM product......
>
>The application that I would be moving began as an R83 system of
>hundreds (maybe over 1K) of PICK/BASIC programs and a similar number
>of PROCs. I would say that 99% of the system is still R83 compliant,
>most of the differences being things that rely on shelling Unix
>commands. The ideal path would be to something that was designed
>with backward compatibility in mind.
In that case, why not look at IBM's UniVerse?
>
>Do any of the existing PICK licensees' offerings provide at least a
>modicum of R83 compatibility?
UV has a "Pick flavour", the compatibilty is high - PROCS and DICT
items *are* supported, and if you're anything like us, you'll
gradually get around to thinking that their approach is somewhat
better, and you can start to "intermingle" the good parts of UV with
your existing Pick-like implementation.
Also, UV "started life" under unix, and the ability to "cross the
boundaries" betwixt "Pick" and unix is probably more "natural" than is
D3....
.
>The point here isn't having others do my
>homework but to get unbiased input from those who have done this
>migration. When we originally moved this application to the then
>fledgling AP, there were a few headaches but AP was trying very hard to
>be able to accept R83 applications.
>
>While I would love to see an open source solution, we have relied on a
>commercial vendor for many years so that isn't really an issue
.
Then again, ther's always JBase - but the learning curve is ...?
Regards,
Bruce Nichol
Talon Computer Services
ALBURY NSW Australia
If it ain't broke, fix it until it is....
Bill H
I've heard from several sources that jBase is R83 on "steroids". This
should provide you with a relatively smooth migration from D3.
However, jBase is not the mvDbms leader; IBM is. This would indicate
looking at the UniVerse product. This may not be as smooth a conversion as
jBase but your client would be supported by IBM. That's not bad. :-)
Their documentation is located at:
http://www-306.ibm.com/software/data/u2/pubs/
Hope this helps.
Bill
"Tom deL" <pi...@trollsrus.com> wrote in message
news:1102276474....@f14g2000cwb.googlegroups.com...
Dawn M. Wolthuis
news:gvMsd.141609$V41.45303@attbi_s52...
> Tom:
>
> I've heard from several sources that jBase is R83 on "steroids". This
> should provide you with a relatively smooth migration from D3.
>
> However, jBase is not the mvDbms leader; IBM is. This would indicate
> looking at the UniVerse product. This may not be as smooth a conversion
as
> jBase but your client would be supported by IBM.
I had thought folks said that PICK to UniVerse was quite painless -- is PICK
to jBASE really even easier? Just curious. I stick with U2 not only
because I started with Prime, but because I want to stick with a virtual
machine rather than dealing with native code in my applications (thus my
work in Java as well) for portability reasons. --dawn
BobJ
Doug. Tell the man what you might be able to do for him.
FWIW, I have converted from D3 (really R83 with a smattering of AP Pro) to
jBase, to Universe, and to Unidata. None was terribly difficult but none
was terribly easy, either. Universe was the easiest. JBase would be the
easiest for someone who would take the time to learn how jBase works with
its environment.
The real problem that we all face is that the future does not look great for
any of the vendors. IBM has a well earned reputation for continuing to
support products just so long as the customer is willing to pay for the
support. So it appears to me that the choices come down to IBM or using
something like the Service Bureau approach that Doug offers. If it were my
decision I would probably go with Doug simply because he will keep himself
alive one way or another and in the process of doing that he would keep me
alive, too.
BobJ
"Dawn M. Wolthuis" <dw...@tincat-group.comREMOVE> wrote in message
news:cp05b8$ee4$1...@news.netins.net...
Dawn M. Wolthuis
news:k4Nsd.6427$Va5...@newsread3.news.atl.earthlink.net...
> Doug's response forgot to mention Doug's products. Don't be so modest,
> Doug. Tell the man what you might be able to do for him.
> FWIW, I have converted from D3 (really R83 with a smattering of AP Pro) to
> jBase, to Universe, and to Unidata. None was terribly difficult but none
> was terribly easy, either. Universe was the easiest. JBase would be the
> easiest for someone who would take the time to learn how jBase works with
> its environment.
>
> The real problem that we all face is that the future does not look great
for
> any of the vendors. IBM has a well earned reputation for continuing to
> support products just so long as the customer is willing to pay for the
> support. So it appears to me that the choices come down to IBM or using
> something like the Service Bureau approach that Doug offers. If it were
my
> decision I would probably go with Doug simply because he will keep himself
> alive one way or another and in the process of doing that he would keep me
> alive, too.
> BobJ
That's quite a glowing report for Doug. I don't know him and suspect he is
great based on your report, but no matter what his talents, I'd guess that
IBM will outlive him. I could be wrong, but ...
Cheers! --dawn
Barry
[ snip ]
>
> The application that I would be moving began as an R83 system of
> hundreds (maybe over 1K) of PICK/BASIC programs and a similar number
> of PROCs. I would say that 99% of the system is still R83 compliant,
> most of the differences being things that rely on shelling Unix
> commands. The ideal path would be to something that was designed
> with backward compatibility in mind.
>
> Do any of the existing PICK licensees' offerings provide at least a
> modicum of R83 compatibility? The point here isn't having others do my
> homework but to get unbiased input from those who have done this
> migration. When we originally moved this application to the then
> fledgling AP, there were a few headaches but AP was trying very hard to
> be able to accept R83 applications.
>
Hi Tom,
To answer your question in one simple word, 'UniVision' is what you
are looking for.
UniVision was designed from the ground up as a R83 replacement, and over
time has been considerably enhanced while retaining R83 backward compatability.
I have first hand expierence that UniVision is more than capable of handling
a 100 user system, scales much better on a SMP system than D3, and is a
rock solid performer.
VIA systems are the international distributors, it would be worth getting
in contact with them, you will find them very helpfull and pleasent to deal
with.
Here is the URL.
HTH
Barry
Doug Dumitru
[ ... snipped ... ]
>That's quite a glowing report for Doug. I don't know him and suspect he is
>great based on your report, but no matter what his talents, I'd guess that
>IBM will outlive him. I could be wrong, but ...
I am sure that IBM will outlive me, the question is will IBMs support
of U2 outlive me. So far, I have outlived a bunch of them (and I am
not alone).
This is one think I like about QM. Even the commercial license has a
clause that public domain's the code in case Ladybridge decides to
"exit stage left". With the addition of the GPL version, the code is
no longer some "dark secret". Think of it as the ultimate code escrow
account.
On the other hand, when I am selling high-ticket solutions that need
support, Universe is very hard to beat. We run it in our hosting
service, support it on all of our products (web servers, etc.) and
have customers that just run.
OT: There have been a couple of comments about jBase. I think that
the implementation of jBase is very good. On the other hand, I think
that the choice to do a native code implementation instead of a pcode
implementation was a mistake. Just too many problem with managing
object code, compiling a live system, code generating, etc. And the
only plus is marketting. MV spends 99.9% of its time in the runtime
libraries. Eliminating the pcode just does not buy you enough. And
talking about migrating to jBase as being the "easiest" path, just
seems wierd to me. jBase is arguably one of the more demanding
environments to master requiring more interaction with the host OS and
its tools than any of the other choices.
Bob Coleman/PDX OR
"Doug Dumitru" <do...@easyco.com> wrote in message
news:mq97r0ds8du93hqkr...@4ax.com...
> On Sun, 5 Dec 2004 17:58:12 -0600, "Dawn M. Wolthuis"
>
> [ ... snipped ... ]
>
>
> OT: There have been a couple of comments about jBase. I think that
> the implementation of jBase is very good. On the other hand, I think
> that the choice to do a native code implementation instead of a pcode
> implementation was a mistake. Just too many problem with managing
> object code, compiling a live system, code generating, etc. And the
> only plus is marketting. MV spends 99.9% of its time in the runtime
> libraries. Eliminating the pcode just does not buy you enough. And
> talking about migrating to jBase as being the "easiest" path, just
> seems wierd to me. jBase is arguably one of the more demanding
> environments to master requiring more interaction with the host OS and
> its tools than any of the other choices.
>
> --------------------------------------------------------------------
> Doug Dumitru 800-470-2756 (610-237-2000)
> EasyCo LLC do...@easyco.com http://easyco.com
> --------------------------------------------------------------------
> D3, U2, jBase Virtual Servers. Off-site backup over the internet.
> Develop/test/deploy from $20/mo. Fast, secure, cheaper than tape.
> http://mirroredservers.com http://mirroredbackup.com
In general I can agree with your assessment of jBASE. But for someone like
me who is used to programming with several tools at the OS level, it is a
lot easier for me to integrate at the OS level than with a VM.
In the end it depends on who is using the tools, what they are used to doing
that with and what their target audience is.
As an aside, I am porting our application (~400K lines code) to OpenQM as
both a learning experience and a safety net. Then again I like the idea of
a challenge.
-Bob Coleman/PDX OR
Richard Kann
dollar company I said. Leader in Electronics I said. Six months
later....Gone with the wind. The bigger they are, the harder they fall.
Rich Kann
Richard Kann
better after the first releases I hear) and to try to get away from
Raining Data. Raining Date then bought GA and inherited MvBase.
I loved the MvBase product, but it is dead-ended with only a few who
support it and no real plans for any future releases. This is a problem
as it would be nice to have more robust features in it like
super-q-pointers, etc.
I switched to Jbase 12 months ago and have not regretted it since. It
does all that MvBase does and has the extra ties to windoze and unix
that I need.
Rich Kann
Joe wrote:
> Having worked with R83, mvBase, and jBASE, I'd say that mvBASE is more
> like R83 on steroids. Maybe mild steroids, but still...
>
> Undoubtedly, jBASE is far superior to both R83 and mvBase.
>
> Any migration will cause a bit of angst. It all comes down to what
> you consider a "problem".
>
> Regards,
> Joe
>
>
> "Bill H" <no...@nowhere.org> wrote in
> news:gvMsd.141609$V41.45303@attbi_s52:
>>>>-- Doug Dumitru 800-470-2756 (610-237-2000)
>>>>EasyCo LLC do...@easyco.com http://easyco.com
>>>>
>
> ------------------------------------------------------------------
>
>>>>-- D3, U2, jBase Virtual Servers. Off-site backup over the
murthi
all the conversions I have done over 15 years, jbase was, and still is, the
most difficult and frustrating. And several times, too. One client of mine
is raising the jbase conversion (from UV) again after a lull of a year. I am
*dreading* it, even tho' I get paid by the hour! There are too many idiotic
decisions on the developer's part to be different, too many environmental
variables, too much of a learning curve. It does not help that the jbase
community looks at everything with jbase blinders - IT'S NOT PICK should be
stickered on every copy.
Bill, please read archival comments of mine on this and jbase's e-list, and
the jbase community's curious responses. Basically the response to every
problem is that "you have to learn jbase first before daring to criticize
it". As for the vaunted benefits of jbase over, say, UV, I never received a
single concrete response as to what they were. For a fun read, see the
thread on the jbase list where it took about 20 responses from several
experts to figure out why a subroutine that you could successfully catalog
would not run..."how may experts does it take...?". Auto caching records on
a BASIC SELECT is another good one (eg you can unknowingly read an already
deleted record!), secretly sliipped into a release with no indication to the
users.
If it's easy you want, go Universe. It has plenty of faults, plenty of
glitches but basically solid and dependable. Don't expect much support,
though. Since you're R83, one issue you'll probably have is that complex
A-correlatives, particularly A's calling A's, are very buggy an may need to
be converted to I-descriptors (but note jbase has equally bizarre glitches).
And if its inter-operability (or any other buzzword) you want, note that
it's all in the mind of the developer. Plenty of apps on D3, UV and jbase
are equally capable of doing anything, so any claims of why a particular
system is better than another in dealing with the modern computer world
should be carefully examined.
And if do select jbase, I'd be happy to give you a list of what to expect,
warts and all.
Chandru Murthi
"Dawn M. Wolthuis" <dw...@tincat-group.comREMOVE> wrote in message
news:cp05b8$ee4$1...@news.netins.net...
Kevin Powick
> Sadly, Dawn, the answer, except to those with jbase credentials, is
> "no!" Of all the conversions I have done over 15 years, jbase was,
> and still is, the most difficult and frustrating.
It's no secret that Chandru dislikes jBASE, which is fine as no product
suits everyone. However, it appears this bias is based mostly on
personal disagreements with the architect of jBASE, Jim Idle.
While he will admit that no MV implementation is perfect, his posts to
CDP and the jBASE Tech e-mail list are particularly acerbic when
discussing jBASE.
He thinks the jBASE community has "blinders on" because they disagree
with his position. He can't accept that we actually like jBASE.
He'll complain that jBASE is not Pick-like enough, yet it is more
flexible in tailoring the environment to emulate more flavours of Pick
than any other MV implementation. He'll than complain there are too
many environment variables to set to obtain emulation flexibility.
Well, you can't have it both ways.
Do what he suggests. Search for and read the posts. What they mostly
come down to is that Chandru has opposing views in areas of jBASE's
design philosophy. This is fine as he's obviously a smart guy with a
history of contribution to the MV world. What's unusual though is the
intensity of the attacks. If it wasn't for his intelligent
participation in the long OT Election post, I would have thought he was
a staunch Republican. :-)
I suggest trying jBASE yourself, as that is the only way you will
really know if it is the appropriate MV platform for you.
--
Kevin Powick
frosty
[snip]
> It's no secret that Chandru dislikes jBASE, which is fine as no
> product suits everyone. However, it appears this bias is based
> mostly on personal disagreements with the architect of jBASE, Jim
> Idle.
> ...Chandru has opposing views in areas of jBASE's
> design philosophy.
OK, you lost me here. Personal disagreements with the architect
or disagreements on the architecture? Disagreeing with the architect
has nothing to do with disagreeing with the architecture.
--
frosty
BobJ
"frosty" <fro...@bogus.tld> wrote in message
news:hf2dnZPSme3...@adelphia.com...
BobJ
Patrick Latimer
<snip>
disagreements with the architect of jBASE, Jim
>>>Idle.
<snip>
As the jBase proponents often say, *jBase is not Pick*
Let's not get off topic now. We should stick to at least
what claims to be Pick or a close derivative. ;)
Patrick, <;=)
BobJ
is any other Pick Like on the market today. Perhaps more Pick than most
since my ancient R80 programs only required getting rid of the jBase key
words in order to compile and run.
But to get back on topic - yes, Pick has a future but it is rather dim one.
But the lack of a good future is more the fault of the pricing than of the
product. Using the Pick file structure with VB.NET is a very attractive
approach but not a very cost effective one when you go to sell the product.
Everybody cries that Pick has never been marketed effectively and there is
certainly a lot of truth to that. But "marketing" is more than sales. It
usually includes a group of people called product managers whose purpose in
life is to guide the designers and decision makers into creating a product
that can be sold in the intended market. "Build it and they will come" has
not worked very well for the Pick vendors. "Sell it and then build it" has
worked very well for Oracle and SAP and a number of others.
As usual, these are just one man's opinions and there is little solid
evidence to support them. Except perhaps the opinion that the Pick future
is dim. There seems to be a lot of solid evidence to support that. If you
disagree then just try to find a job as a Pick Programmer.
BobJ
"Patrick Latimer" <"Patrick Latimer"> wrote in message
news:88OdnRnt-eW...@comcast.com...
Dawn M. Wolthuis
news:88OdnRnt-eW...@comcast.com...
>
> disagreements with the architect of jBASE, Jim
>>>>Idle.
> <snip>
> The original question was "Has PICK a future?"
> As the jBase proponents often say, *jBase is not Pick*
The topic was about migrating from R83 and jBASE is one viable, if not
exactly simple, path. I did a little studying of the history of PICK and
its derivatives and jBASE is definitely in the MultiValue family of
products, which puts it squarely in the PICK family, even if it has its own
flavor. It is the only one I am aware of that does not run in a virtual
machine, however. I'm still partial to VMs but for those who are not, jBASE
is still in the running for an R83 migration. I haven't done such a
migration, but did research it a couple of years ago and advised migrations
to UniVerse, however (even though my familiarity is more with UniData). The
fact that Chandru seems to agree, gives my opinion far more weight.
> Let's not get off topic now.
I guess, but I enjoy the off-topic chatter about the differences between
Chandru & Jim Idle. They are both charming and intelligent men. The PICK
world used to voice their disagreements in court, but it is far more
entertaining and civil to do so in discussion lists (and, yes, I do read the
jBASE list on occasion just for entertainment).
> We should stick to at least
> what claims to be Pick or a close derivative. ;)
In case you have not seen my 2002 poster, check it out at
http://www.tincat-group.com/images/MVFamilyTreeColor.pdf
Cheers! --dawn
> Patrick, <;=)
>
Patrick Latimer
> "Patrick Latimer" <"Patrick Latimer"> wrote in news:88OdnRnt-
> eWOaSn...@comcast.com:
> Patrick, are you suggesting that jBASE is off-topic in cdp?
>
> Regards,
> Joe
No Joe, I'm suggesting that whenever anyone like Chandru
suggests that jBase is a *strange* port, that is the pat answer
from it's proponents. On the other hand when it serves their
purposes, there is a 180 and it is Pick. Don't believe me,
check here.
http://groups-beta.google.com/groups?q=%22Jbase+is+not+pick%22
or more
http://groups-beta.google.com/groups?q=%22not+pick%22+jbase&qt_s=Search+Groups
Interesting, but having it both ways is a marketing thing, not a
technical thing. Sorry it just does not work that way. You folks
need to, well, Pick. ;)
Patrick, <;=)
Kevin Powick
> OK, you lost me here. Personal disagreements with the architect
> or disagreements on the architecture? Disagreeing with the architect
> has nothing to do with disagreeing with the architecture.
<Sigh> Posting to CDP is so painful.
Merry Christmas Frosty.
Maybe Santa will bring some clarity.
--
Kevin Powick
Simon Verona
"Patrick Latimer" <"Patrick Latimer"> wrote in message
news:laWdneo0Utj...@comcast.com...
Whilst jBase may claim that "jBase is not Pick", this is mainly a marketing
message - particularly those that want to "load and go" - jBase is just not
that sort of product.
I have always understood this to mean that jBase is for Pick people who wish
to move into more main-stream environments. Those that just want R83/AP
compatibility will probably be better served elsewhere (though jBase will do
this too).
It still stands that technically, jBase *is* a Multi-Value product which
offers an alternative to people who currently use other MV flavors.
It is to the point whereby for 99% of our code, we keep common code between
jBase and mvBASE (where our original product was written).
Therefore, jBase is a Pick-clone, offers a future for Pick and therefore
deserves discussion in this context.
jBase has a learning curve, and it's idiosyncracies, but at the end of the
day I would suggest that 99% of existing multi-value applications could be
reasonably easily ported.
Personally, I've always been interested in the "jBase is not Pick" stance...
How many jBase systems are out there which didn't originate on other MV
variants? How many jBase systems are ports from Oracle/DB2/SQL Server
etc.?? It is clear to me that jBase is aimed primarily at the
multi-value market. Ok, it offers the benefit of going the other way
(porting existing MV products to use Oracle, DB2 etc as a backend database
without modification to the software), but this still makes it a MV variant!
Just my 2 Euro's.
Regards
Simon
Tom deL
apparently long standing
wrestling matches (although I suspect that CDP isn't that different
than any USENET
group).
For the record I am taking a closer look at jBase (perhaps _because_ of
some of the things
some in this thread see as disadvantages) and QM.
Reading threads on the Open Sourcing of Pick is quite interesting, I'll
be around ;-)
-Tom
BobJ
question that jBase and Universe are good choices for the moment. The
question is are they good choices for the long run. The answer is - nobody
knows. Conventional wisdom would indicate that IBM is more likely to be
around than jBase but conventional wisdom would also have favored W. T.
Grant and the Pennsylvania Railroad, neither of which is with us any more.
In other words size and age alone are not adequate to insure continuity.
IBM currently enjoys a reputation for integrity that perhaps they have not
really earned. Not so many years ago they had a practice of blackballing
any human on earth who disagreed with anything they did. They would
carefully "help" the DP Managers select new employs and would go to almost
any extreme to prevent someone from being hired by a customer if that
someone had ever indicated that maybe RCA or Honeywell or GE might have a
computer that works. This is not the rantings of a rejected employee or a
madman - this is just a statement of historical fact. I had an IBM VP visit
me once to explain that I was making a very bad choice if I hired a young
man down at the bottom of the organization. He made noises like "We've
worked together for a long time and I hate to see you make a mistake like
this" and even some veiled threats about the level of support that we could
expect if I didn't take his advice. Did he believe what he was saying? I'm
sure that he did and that he was sincere. Have they changed? Probably.
Will they change again? Probably. What's the point of this? The point is
that you have to look at the here and now of things to make an intelligent
decision - and even then the risk is great. And any and every successful
business man will sometimes reverse a decision or a position when
circumstances require such an act. Nothing reprehensible about that.
The bottom line is simple = the choice is not simple and you can't make it
simple by saying "nobody ever got fired for choosing IBM".
BobJ
"Joe" <avoidi...@nospam.com> wrote in message
news:31lpooF...@individual.net...
> "Tom deL" <pi...@trollsrus.com> wrote in news:1102422804.472262.268910
> @z14g2000cwz.googlegroups.com:
> have radically changed, you'll find that jBASE has unparalleled
> support.
>
> Regards,
> Joe
PickCoder
no. I think the problem here is that some people misinterpret the
question. Perhaps the questions should be more focused.
1) Is Pick/MV going to always be offered as a monolithic environment?
2) Are vendors, developers, integrators, and VARs willing to truely listen
to their customers. Will they give the effort to learn new things which
will help advance the global technology.
3) Will Pick/MV be completely dissolved and replaced by other technologies?
4) Is the support market for Pick/MV going to shrink?
5) What will happen to sites that refuse to upgrade to newer releases of
MV?
6) Look at the current poll on PickSource and decide for yourself: Who has
a majority control of this market?? Who has the power to really change
things?
7) Would any size company be able to afford a Pick/MV business system,
versus a comperable 'mainstream' solution?
8) What does Pick/MV offer, that no other solution or technology offer?
9) Is this community willing to market and co-design/co-develop products
that reach outside the comfort zone? One-man specific products aren't
going to continue to support this niche. It's time there's some
team/global re-development. You can't continue to make specialized tools
to fix a machine that is going to be discontinued. You will eventually
need to re-tool and re-design to stay alive.
OpenQM is a great attempt at moving the market in the direction it needs
to go. However, I feel it may be too late in the game. OpenQM needs a LOT
of marketing, documentation, development, and application development
help. No one can devote 100% of their time to a GPL project and still pay
their bills. That means we need MORE people to participate and put 100%
into whatever time and effort they can truely afford to contribute.
Tom deL wrote:
> Hello All,
> After a long absence from any involvement in PICK I have recently been
> involved in the enhancement of an old client's D3 based system. This
> re-immersion has led me to paraphrase Bertrand Russel:
> "Has PICK a future?"
> This particular installation has been a huge investment for my client
> but has also paid off well over the last 15 years. After seeing another
> client ditch their PICK based system for a Windoze based system a
ashe...@inlandkwpp.com
example.
Has it gone away: not yet?
Has it's market shrunk: yes
Has it been replace by something else: sorta
Has new versions provoked customers to upgrade: sometimes
Has a less proprietary clone provoked customers to change: starting to
happen
The thing is, as much as software companies want customers to upgrade
to the latest and greatest, it isn't going to happen. Software and
hardware is a huge investment in both time and money. Lets factor out
money. Even if companies can afford boatloads of licenses, support
contracts, maintenence/upgrade fees, the time it takes to switch
platforms is enough to just keep plugging along with what you already
have.
Just because the technology is old, does not mean it should "die".
The older the technology, the more mature and cheaper it should be.
Using our same Unix example, its market share is declining. However,
Linux, the same basic technology released only under a license that
respects your rights at negligible cost, is increasing marketshare by
leaps and bounds. But I thought Unix was dying? I mean, look how old
it is! The technology must be outdated! WRONG. People are
embracing it because they want rights and freedoms and a platform they
can understand and work with. They want lower prices. They want
freedom to distribute/copy.
MV is similar to Unix. It is infrastructure technology. People don't
pay for MV, they pay for the applications that run on it. As long as
the applications are being written for MV, people will buy MV
(arguable, but whatever).
If it is cheaper, easier, less restrictive, "better" to write
applications on another platform then the marketshare will dwindle or
stay where it is. People won't change from their existing MV apps
without good reason. They have too much time invested.
I personally see MV going the way of Linux/Unix but the license model
will probably look different than the OpenQM situation. Ideally, all
application sellers would distribute source code with their product
but this isn't the case. In my opinion, in order for an open source
MV backend to catch on, it'd have to dump the restriction of not being
able to link with proprietary applications. It isn't in the same
position as MySQL: MV's niche/developer/application base is too small
and its standards are not standard enough.
-Adam
Bill H
The points, IMHO of course, you've made that are important are:
> 8) What does Pick/MV offer, that no other solution or technology offer?
>
> 9) Is this community willing to market and co-design/co-develop products
> that reach outside the comfort zone? One-man specific products aren't
> going to continue to support this niche. It's time there's some
> team/global re-development. You can't continue to make specialized tools
> to fix a machine that is going to be discontinued. You will eventually
> need to re-tool and re-design to stay alive.
One can sell a solution that includes an mvDbms. I believe that's how most
are being sold today (as they have been in the past). I'll give you my two
biggest beefs with the mvDbms corporate community:
1) The costs are too high! I'm figuring they'll figure this out pretty
soon. As I move a software solution, using an mvDbms, to the internet
there's no way I'm going to pay $450/seat (RDUS - the idiots),
$225-$650/seat or a $20K unlimited license for U2 (at least they're
thinking), or whatever jBase charges (I think they're cheaper though). An
mvDbms solution has a lot to offer, as I work more and more with RDBMS
developers. The key is consolidation of computing BS.
2) There needs to be examples, examples, and more examples. Tony G used to
provide interesting and useful examples of doing things for D3. Once he
left RDUS the examples were left their overworked staff. Well, you know how
documentation goes. :-)
I believe your #9 hits on the critical problem: the mvDbms developer
mentality is so closed minded they rarely offer any examples to the rest of
us. I remember someone knew how to secure a FlashConnect connection, via
ssh, and wouldn't publish an example because they wanted consulting fees. I
believe that's "...cutting off ones nose to spite their faces...". The
mvDbms companies never offered such either. This is just the kind of
information for RDUS, jBASE, or IBM to be providing the community.
This is especially true for .NET and VB and Java development. We need
critical examples; like how to create a file object. How to use the
dictionaries as a property. How to create a global set of variables and
methods. How to call a BASIC routine. How to transfer data back and forth
to the mvDbms server. We're not stupid, but can use a little help with
these kinds of things.
The server based environment of an mvDbms is great for web based work.
BASIC is a wonderful stored-procedural language. Our code will mostly work,
with a little work, in this new environment. It's too bad the mvDbms
mentality won't help each other. So, in conclusion, I think our problems
lie:
1) Unwillingness of mvDbms participants to spread around their knowledge,
2) Unwillingness of mvDbms companies and participants to provide examples
(detailed) to move our applications, and
3) Unwillingness of mvDbms companies to come up with rational pricing
models.
I can develop all day in .NET using an mvDbms back-end. I wish I could get
help instead of having to discover everything myself.
Bill
Glen
>Glen:
>
>The points, IMHO of course, you've made that are important are:
>
>> 8) What does Pick/MV offer, that no other solution or technology offer?
>>
>> 9) Is this community willing to market and co-design/co-develop products
>> that reach outside the comfort zone? One-man specific products aren't
>> going to continue to support this niche. It's time there's some
>> team/global re-development. You can't continue to make specialized tools
>> to fix a machine that is going to be discontinued. You will eventually
>> need to re-tool and re-design to stay alive.
>
>One can sell a solution that includes an mvDbms. I believe that's how most
>are being sold today (as they have been in the past). I'll give you my two
>biggest beefs with the mvDbms corporate community:
>
>1) The costs are too high! I'm figuring they'll figure this out pretty
>soon. As I move a software solution, using an mvDbms, to the internet
>there's no way I'm going to pay $450/seat (RDUS - the idiots),
>$225-$650/seat or a $20K unlimited license for U2 (at least they're
>thinking), or whatever jBase charges (I think they're cheaper though). An
>mvDbms solution has a lot to offer, as I work more and more with RDBMS
>developers. The key is consolidation of computing BS.
>
As long as people will pay $1500 for 5 SQL Server licenses, you'll
never see license costs fall below $300 a seat for a marketed MVDBMS.
Why would anyone pay near the same cost, for something that is not
marketed in the mainstream and is not understood at all? There are
some MV products out that are cheaper, but they are not marketed as
strongly as those with higher fees. MV licensing structures are still
based on comparative markets, which IMO are not comparative in the
tiniest bit. The stockholders have a large say in how cheap the
licenses will be, based on revenue and profit. Unforunately, a lack of
new sales will always cause the licenses and support fees to rise.
It's a one-way street to no-where, unless marketing and development
goals change. Those will never change without demographics to show
that the investment is worth the loss in immediate revenue. Then
again, you can still have a bone-head running the show who still won't
get "it" and wants things to stay the way they are. At this point, I
believe that talking, arguing, or writing about it is pointless. If
"they" don't get "it" by now, then it's hopeless.
>2) There needs to be examples, examples, and more examples. Tony G used to
>provide interesting and useful examples of doing things for D3. Once he
>left RDUS the examples were left their overworked staff. Well, you know how
>documentation goes. :-)
Education, including documentation, is one of the larger reasons that
Pick still isn't a well known DBMS. Several top-skilled individuals
attempted to break the wall down and fund/support education outside of
the community. Not much luck there. No one wants to fund education
because it doesn't provide instant ROI. I think the best approach to
reaching outside is through either in-your-face antagonistic
advertising or high-level technical articles. Chuck Barouch has been
putting articles together for Database Trends. I have to wonder,
though, how many non-Pickies read that periodical. He's also been
helping me to try and put together a digested source of case studies,
relating to MV development, deployment, and bottom line. So far, I
have ONE real case study. ONE! I've requested case studies from many
of the top MVDBS vendors and still, nothing. Nada! I was told by
several people at RDUS, that they dont have any case studies but are
working on some. Of course, that was last March/April. I'm still
trying to get case studies from IBM as well. This is the kind of
marketing and development that needs immediate attention. Will it get
it? I doubt it.
>
>I believe your #9 hits on the critical problem: the mvDbms developer
>mentality is so closed minded they rarely offer any examples to the rest of
>us. I remember someone knew how to secure a FlashConnect connection, via
>ssh, and wouldn't publish an example because they wanted consulting fees. I
>believe that's "...cutting off ones nose to spite their faces...". The
>mvDbms companies never offered such either. This is just the kind of
>information for RDUS, jBASE, or IBM to be providing the community.
It's not closed minded nature, that's the problem. It's life-n-limb
tied to a 200 line snip of code, which could easily be duplicated and
sold. Developers are still relying upon pieces of code to pay the
bills. This is fine and dandy, provided the code is shelved with a
decent price tag. Some of the consulting fees and application costs
I've seen at Spectrum, make me wonder how much companies are truely
spending on IT solutions in this community. I don't want to take
anyone's lunches or run into copyright lawsuits. However, some of the
OEM and 3rd party tools currently being sold are now OLD technology
that should be freely available on ALL MVDBMS packages. It really
pisses me off seeing a $2000+ web connectivity "toolkit" that isn't
flexible enough to support XML processing. That's the main reason I
migrated the D3WWW project to MVWWW, in support of all flavors and
platforms. I fell that if you _really_ have to have commercial support
and help, then pay the cash and get support. I still can't believe
that e-mail support isn't native on all flavors!!! There's no way I'm
going to buy an e-mail application, when the integratable tools are
available freely on the Internet.
>
>This is especially true for .NET and VB and Java development. We need
>critical examples; like how to create a file object. How to use the
>dictionaries as a property. How to create a global set of variables and
>methods. How to call a BASIC routine. How to transfer data back and forth
>to the mvDbms server. We're not stupid, but can use a little help with
>these kinds of things.
The problem with doing this, is that every DBMS vendor has their own
way of doing things. There is no 'Pick Bible' that can be sold at
Barnes & Noble, which can tell anyone how to program on any flavor of
Pick/MV. The Pick community needs to establish common standards for
many things. Until that happens, the segregation of the technology
will be its final demise.
>
>The server based environment of an mvDbms is great for web based work.
>BASIC is a wonderful stored-procedural language. Our code will mostly work,
>with a little work, in this new environment. It's too bad the mvDbms
>mentality won't help each other. So, in conclusion, I think our problems
>lie:
>
>1) Unwillingness of mvDbms participants to spread around their knowledge,
>2) Unwillingness of mvDbms companies and participants to provide examples
>(detailed) to move our applications, and
>3) Unwillingness of mvDbms companies to come up with rational pricing
>models.
>
I agree to all 3 and I don't think that any of these 3 are going to
change until something drastic happens(like OpenQM/QM taking 2/3 of
the license market).
>I can develop all day in .NET using an mvDbms back-end. I wish I could get
>help instead of having to discover everything myself.
>
>Bill
>
News
product again. About the only caveat of a jBASE conversion from R83/D3 now
days is that all the programs should be CATALOGed. Any system written since
the McDonnell Douglas days should have all the programs CATALOGed anyways
since there is no advantage to RUNning them. If you downdload the jBASE 4
and send a request to devsup for the MV suite, they will send you a set of
programs that sets jBASE up with a file structure and utilities that make it
mirror D3/R83 arhcitecture. After that you can do a MV.RESTORE.ACCOUNTS and
be well on the way to a complete jBASE system and can then take advantage of
the jBASE pluses of JEDI, direct O/S integration, etc. As for UNIVERSE
being so easy to convert to: How easy is it to use a totally different
editor, the fact that right justified fields wrap, null equates to zero, a
dot is non-numeric, a READV of 0 returns the key, a failed ICONV returns the
data, and about 20 other things that jBASE handles with Config_EMULATE and
does not force you to recode for. And the SPOOLER is totally different on
Universe whereas with jBASE you can use UNIVERSE or D3 commands with the
spooler.
"Glen" <nospamw...@all-spec.all-spec.com.com> wrote in message
news:usucr019mnn4j7k87...@4ax.com...
Bill H
"Glen" <nospamw...@all-spec.all-spec.com.com> wrote in message
news:usucr019mnn4j7k87...@4ax.com...
[snipped]
> As long as people will pay $1500 for 5 SQL Server licenses, you'll
> never see license costs fall below $300 a seat for a marketed MVDBMS.
SQL Server can be had for an unlimited single CPU license for about $3,500
(maybe less). So, you run a web site using SQL server and you don't futz
around with licensing. That's like a 7 user D3 system or a 12 user Universe
system.
These guys will be going out of business pretty quick; especially RDUS.
Their pricing is completely unjustified. Other mvDbms vendors would do well
to improve their pricing. You can see it happening for the 2nd tier mvDbms
providers and one would hope rational pricing will find its way to jBase and
U2.
[snipped your accurate comments]
> Education, including documentation, is one of the larger reasons that
> Pick still isn't a well known DBMS.
Someone mentioned previously that even if you give away an mvDbms system the
user will just stare at a tcl prompt (if they get one) and wonder what to
do. :-) Think how cool the MS-Access database examples are. You can
learn quite a lot from just that small database.
> Several top-skilled individuals
> attempted to break the wall down and fund/support education outside of
> the community. Not much luck there. No one wants to fund education
> because it doesn't provide instant ROI. I think the best approach to
> reaching outside is through either in-your-face antagonistic
> advertising or high-level technical articles. Chuck Barouch has been
> putting articles together for Database Trends. I have to wonder,
> though, how many non-Pickies read that periodical. He's also been
> helping me to try and put together a digested source of case studies,
> relating to MV development, deployment, and bottom line. So far, I
> have ONE real case study. ONE! I've requested case studies from many
> of the top MVDBS vendors and still, nothing. Nada! I was told by
> several people at RDUS, that they dont have any case studies but are
> working on some. Of course, that was last March/April. I'm still
> trying to get case studies from IBM as well. This is the kind of
> marketing and development that needs immediate attention. Will it get
> it? I doubt it.
Well, there you go. They can't last long with nothing to help developers
and application providers. :-)
> It's not closed minded nature, that's the problem. It's life-n-limb
> tied to a 200 line snip of code, which could easily be duplicated and
> sold. Developers are still relying upon pieces of code to pay the
> bills.
[other fine observations snipped]
I found out, about 10 - 15 years ago, I couldn't sell 150 utilities for $50.
I must have sent out several thousand mailings offering all kinds of
utilities and stuff. Got one sale. That's it. Noone in the mV community
wanted the stuff. Now, I just give it away. If it's given away then more
people will be more productive and develop. that's the point. I've seen
some pretty cool mV software in the past few years.
A good example of something that should be given away is FlashConnect. What
in the world is RDUS going to do with it. Noone is going to buy it. It's
tied to D3 and not too many people are moving in that direction (moving on
to .NET). It's probably the best product I've ever seen. Great for BASIC
programmers (I suspect Doug D.s product is pretty cool too). It's really
easy to use, once you get used to a few things. There are good examples
too. But, they'll just sit on it until noone wants it any more. :-(
That's too bad.
> >This is especially true for .NET and VB and Java development. We need
> >critical examples; like how to create a file object. How to use the
> >dictionaries as a property. How to create a global set of variables and
> >methods. How to call a BASIC routine. How to transfer data back and
forth
> >to the mvDbms server. We're not stupid, but can use a little help with
> >these kinds of things.
>
> The problem with doing this, is that every DBMS vendor has their own
> way of doing things.
This is so moronic! (...just had to say that). Ahh, well. <sigh>
Bill
BobJ
with jBase if you can find the documentation. And sometimes you can and
sometimes you can't. You can ask Devsup and get a prompt, courteous and
correct answer - but most of us would rather do it ourselves, thank you. I
have converted to jBase and I have converted to Universe. If I were doing a
new conversion right now I would not be able to choose based on ease or
difficulty because once you know what you are doing they are about the same.
UV has tools to help. And many of the differences are not significant if
your programming methods are reasonably good. Storing a decimal in a value
is not generally good practice. Comparing items that may be zero with items
that may be null without first making sure of one or the other is also not
good practice. Both systems are a giant PITA where printers are concerned
but maybe it is just that printers and spoolers in general are a giant PITA.
The bottom line - when you port then you do some work. More work or less
work is more dependent on the background and skills of the porter than on
the thing that he is porting.
BobJ
"News" <dan...@fiponline.com> wrote in message
news:UzCtd.74238$Oc.2...@tornado.tampabay.rr.com...
Tony Gravagno
don't believe there is immediate need to do so for many reasons. D3
is a fine product, and if only the software were involved then most
sites wouldn't migrate. RD has lost a lot of business with their
desperate pricing policies in the name of generating revenue for a
public company. But unless those policies are intolerable, or they
officially announce a change of business, there's no other real
compelling reason to change platforms.
If you're asking about the general picture for the Pick market, there
are no clear winners, making a migration choice also not so clear.
- I don't see excitement from any of the MV DBMS vendors except
Revelation. (I don't even use OI yet, so please don't take this as a
biased comment.) Mike Ruane is the only DBMS provider that has
personal drive _and_ control over his products, along with some
critical mass of users to make a real difference. If you're looking
for a comfortable long-term future then I'd bet on OI, despite some
fundamental differences from the other platforms. With respect for
Bryan Shumsky and Martin Phillips, UniVision and QM combined don't
have the market power that Rev/OI has.
- IBM/U2 and jBASE are stable in a business sense but I would
only migrate to them for near-term business comfort (politics).
(That's not to say there's anything wrong with the software, for a new
system any of these platforms are great, but we're talking about
migrations.) Either of them (IBM or jBASE) could be compelled by
"forces from above" to dump their assets within a couple years time
frame - IBM proves this all the time and jBASE had some recent
shakeups too. I honestly don't think they'll do it, but they're in a
business position where it's not unthinkable of them to do so; IBM
doesn't need U2 and hides it (from themselves) in the DB2 family, and
Temenos themselves don't have a single mention of jBASE on their home
page (they call it "T24") - what's up with parent companies that are
afraid to say the P-word or anything related to it?
- With RD, I don't think they Can dump their assets because for
better or worse most of their survival revolves around MV. The best
thing that could happen to RD now would be for Rick Koe to cut his
losses and sell the company on a long-term agreement to someone who
cares about MV and knows what to do with it and the customer base.
Yeah I know, that's how he got into this mess. :)
If you're worried about activating your software, it seems to me the
problem and apparent business solutions are the same for all of the MV
providers. If you want an activation now, keep on a support contract.
(I'm tickled by how many off-contract sites threaten to take their
business to the competition.) If any MV provider closes shop, I think
it's safe to say "someone" will buy/acquire the activation assets to
provide that function (and provide Support) as sites consider their
migration options - bottom line, I wouldn't worry about it. YMMV
Tony
Nebula R&D
T...@opinionsarefreeNebula-RnD.com
Simon Verona
I too utilise mv (Jbase in particular) as a back end to a .Net based front
end... Getting this up and working involved a lot of pain, sweat and
tears!!! The end result is great as Data-Basic is a great language for
writing "Stored procedures" in.
regards
Simon
"Bill H" <no...@nowhere.org> wrote in message
news:uqttd.625323$mD.106349@attbi_s02...
Tony Gravagno
Glen wrote:
"Bill H" wrote:
>>2) There needs to be examples, examples, and more examples. Tony G used to
>>provide interesting and useful examples of doing things for D3. Once he
>>left RDUS the examples were left their overworked staff. Well, you know how
>>documentation goes. :-)
Very few people actually took advantage of those examples. People
"say" they want Java and VB and PDF (etc) connectivity to MV, but as
soon as you show them how to do it the subject drops and they try to
think of something that can't possibly be done. Horses and water...
Some examples are still available but no one ever refers to them:
http://flashconnect.rainingdata.com/wuc2000/fcdemos/index.html
>>I believe your #9 hits on the critical problem: the mvDbms developer
>>mentality is so closed minded they rarely offer any examples to the rest of
>>us. I remember someone knew how to secure a FlashConnect connection, via
>>ssh, and wouldn't publish an example because they wanted consulting fees. I
>>believe that's "...cutting off ones nose to spite their faces...". The
>>mvDbms companies never offered such either. This is just the kind of
>>information for RDUS, jBASE, or IBM to be providing the community.
(General response not necessarily directed at Bill despite the "you"
references, but my friend has brought this topic up many times and I
hope he makes careful note.)
After all of the years of providing free information, where has it
gotten many of us? I started a business based on the idea that people
would want either information "Research" or that they would want
someone else to do the heavy lifting "Development". My marketing,
which is really just me being me, has consisted of providing free
information on an assortment of topics for many years. Much of my
research is provided as a freebie toward development services - but I
really enjoy doing it anyway so it's usually my personal contribution
toward the greater good. But I get very little business with this
strategy and I'm tired of giving free information that makes other
people money while I need to work on non-MV work in order to pay my
bills. You want so much stuff for free, who do you think pays for it
down the line? Someone has to. When I was doing this sort of work
for RD they paid my salary, but without signs of tangible benefit from
my evangelism they had to let me a lot of other good people go -
including Bill, Mark and others here.
The phrase "cutting off one's nose to spite their face" implies that
by not doing X you sacrifice Y, but if we aren't getting anything from
X anyway, what have we to lose by telling people if they want it, no
more freebies, they'll have to pay for it. Pay for it with your own
research time or pay someone who has done the research or coding for
you, but you've gone without paying anything for a long time and it's
time to start owning up to responsibility and rewarding people who
make your life easier.
The same goes for the DBMS companies. As an example, the D3 Class
Library has been free since the beginning, but has providing that for
free R&D helped PS/RD to grow? Nope. FlashCONNECT was dropped to
FREE for over a year, but did VARs sell any more systems? Nope. So
now there is a price for PDP.NET and FlashCONNECT, and RD charges a
price for other add-in options too - if they aren't making any money
on DBMS licenses then they need to charge for the tools, it has to
come from somewhere. Is jBASE immune from this? Nope - they sell
jEDI too, but you don't hear jBASE customers complaining about it
because they appreciate the value in the add-on.
> It's not closed minded nature, that's the problem. It's life-n-limb
>tied to a 200 line snip of code, which could easily be duplicated and
>sold. Developers are still relying upon pieces of code to pay the
>bills. This is fine and dandy, provided the code is shelved with a
>decent price tag.
Glen, you're right that we make our living by selling code (if we're
lucky, vs selling our time for which there are no recurring sales), so
it's important to protect our assets.
Pricing products in this market is very difficult and sometimes
doesn't make a difference. For a short time I offered an MV-based XML
engine starting at $2500. It was modeled after mainstream products,
and did about as much as a couple of those products, even the new XML
functionality in U2, but was priced at about 1/10-1/20th of the cost
for the mainstream offerings. I got zero bites from the MV market -
maybe I should have started at $20,000?
> Some of the consulting fees and application costs
>I've seen at Spectrum, make me wonder how much companies are truely
>spending on IT solutions in this community. I don't want to take
>anyone's lunches or run into copyright lawsuits. However, some of the
>OEM and 3rd party tools currently being sold are now OLD technology
>that should be freely available on ALL MVDBMS packages. It really
>pisses me off seeing a $2000+ web connectivity "toolkit" that isn't
>flexible enough to support XML processing.
The problem is that most Pick people don't do their research like you
and I do. The code that ticks us off as being too simplistic is
absolute rocket science to some people, and they're willing to pay for
it (sometimes). You need to consider the audience. Also, by the time
a "product" makes it to market these days, the technology may have
already changed. My COM-based NebulAnalysis was rocket science when I
developed it (even though it was priced dirt cheap) but just a year or
two later the HTML/XML capabilities in Excel made my software obsolete
(for anyone who'd do the research to figure that out) - but I still
get calls today for the software. (Calls which I ethically try to
change into a service engagement because I don't want to get a bad rap
for selling old technology :) )
>That's the main reason I
>migrated the D3WWW project to MVWWW, in support of all flavors and
>platforms. I fell that if you _really_ have to have commercial support
>and help, then pay the cash and get support. I still can't believe
>that e-mail support isn't native on all flavors!!! There's no way I'm
>going to buy an e-mail application, when the integratable tools are
>available freely on the Internet.
Again you're not considering the audience. I'm installing NebulaMail
to another end-user site right now. They were hosted on D3NT and are
migrating to D3Linux. All of their code is hooked into blat and
getmail which are only available over Win32. Are they going to pay
someone full-time wages to research Linux-based freeware options?
(Gotta pay someone, eh?) Or would they rather pay me the pittance I'm
asking for cross-platform and supported software where the research
has already been done for them. (In case you're paying attention, yes
NebulaMail now supports SMTP _and_ POP3.)
Most end-users, and even MV VARs, are not qualified to do the research
and implement freeware solutions - especially when that world changes
so much faster than our own. You're young yet bud, see how easy it is
to keep up with the world in 20-30 years. You might find yourself
tossing a couple bucks to a guy like me who can use it rather than
taking time from your family to search FTP sites. (We're both lucky
to be married to women who tolerate us as it is!)
Bill continued:
>>This is especially true for .NET and VB and Java development. We need
>>critical examples; like how to create a file object. How to use the
>>dictionaries as a property. How to create a global set of variables and
>>methods. How to call a BASIC routine. How to transfer data back and forth
>>to the mvDbms server. We're not stupid, but can use a little help with
>>these kinds of things.
For what it's worth I did start writing a PDP.NET Tutorial for which
there was no interest from the community, nor from RD. If no one
wants documentation then what sense is there in writing it?
Aside from that, yes, I was going to sell it, but would you have me
doing this as a labor of love? So because people don't want to pay
for documentation in our market, there is none, and developers
continue to struggle with technology. I've mentioned before that I
spend a lot of time in book stores where the shelves are full of books
written by people who expect to get paid for their efforts, and
written for people who expect to pay for the knowledge they acquire.
If you want to know what technologies are successful, visit a book
store. If you want to know what happens to a market with no books,
read CDP.
> The problem with doing this, is that every DBMS vendor has their own
>way of doing things. There is no 'Pick Bible' that can be sold at
>Barnes & Noble, which can tell anyone how to program on any flavor of
>Pick/MV. The Pick community needs to establish common standards for
>many things. Until that happens, the segregation of the technology
>will be its final demise.
Not necessarily. There are hundreds of books on C/C++, VB, Java,
Oracle, MySQL, and all of the various subtleties associated with
running each in different environments. We don't need one Bible, we
need many of them. The problem is that people in this market won't
buy or read any of them. Just ask Jon, Harv, Matt, Malcolm...
>> So, in conclusion, I think our problems lie:
>>
>>1) Unwillingness of mvDbms participants to spread around their knowledge,
Because we want our effort to contribute to feeding our families.
>>2) Unwillingness of mvDbms companies and participants to provide examples
>>(detailed) to move our applications, and
Ibid
>>3) Unwillingness of mvDbms companies to come up with rational pricing
>>models.
I agree there, but the pricing models are a desperate response to the
issues I've gone on about here. If you want everything for free how
do you expect them to stay in business? Of course they're going to
start getting irrational with their policies. Bill, you know first
hand how irrational RD can get: What do they do when Sales and
Marketing people aren't generating revenue? They fire all of the
sales and marketing people - you included. We are in the open market
now because of the very mindset that you are supporting.
I don't disagree in general that free information and software
"should" encourage sales, but only in a market that actually
reciprocates with that policy. At some point investment is perceived
as expense, and that causes all of these software and service
providers (myself included) to re-evaluate the policy.
> I agree to all 3 and I don't think that any of these 3 are going to
>change until something drastic happens(like OpenQM/QM taking 2/3 of
>the license market).
It's a community mindset Glen. Over the last couple of years I've
proposed many ways for the community to take charge and do things for
itself but every effort ends in apathy. OpenQM is a great concept but
I'm afraid people will only use it as long as they can get someone
else to make changes to it for them. At some point the people who
maintain it will get tired, and that's where we can all hope that
mainstream open sourcing will bring in some fresh bodies to maintain
it. This generation of MV users will not appreciate OpenQM for what
it is, which may be one of the last chances to save our market. I
also fail to see how people who won't research SMTP options (one of
the most discussed protocols on the net as you say) are going to want
to have anything to do with a complex open source project like OpenQM.
Don't get me wrong, I'm a big (silent) fan of that project, I
unfortunately just don't see the average Pickie taking much interest.
>>I can develop all day in .NET using an mvDbms back-end. I wish I could get
>>help instead of having to discover everything myself.
>>
>>Bill
It'll cost you a couple more drinks - someone has to pay for the
research! (Running, ducking, covering) ;)
Hey, when are you coming back to town bud, I miss ya! :)
T
(wow, thats a lot even for me)
Bill H
"Tony Gravagno" <g6q3x9...@sneakemail.com.invalid> wrote in message
news:fi9ir0t7hbckivhg4...@4ax.com...
>
> "Bill H" wrote:
>
> >>2) There needs to be examples, examples, and more examples. Tony G used
to
> >>provide interesting and useful examples of doing things for D3. Once he
> >>left RDUS the examples were left their overworked staff. Well, you know
how
> >>documentation goes. :-)
>
> Very few people actually took advantage of those examples. People
> "say" they want Java and VB and PDF (etc) connectivity to MV, but as
> soon as you show them how to do it the subject drops and they try to
> think of something that can't possibly be done. Horses and water...
> Some examples are still available but no one ever refers to them:
> http://flashconnect.rainingdata.com/wuc2000/fcdemos/index.html
These examples were great. But, they weren't too mV user friendly. When I
was doing FlashConnect work I needed the examples and hours of your time,
which you were kind enough to give me, and we "both" worked for RDUS. Your
stuff wasn't useable without some serious work.
The stuff I was doing, using your examples to build a solution, was what I
was referring to. We were able to do some pretty cool things using
FlashConnect and your concepts. Most mV people would have benefited from
the solutions we were building. Those examples should have been made
available.
I'm not referring to you. When I refer to offering examples of solutions
I'm talking about what we often do here and at the PickWiki
(www.pickwiki.com). For someone in your position, where you've set up a
business to make consulting fees, it's difficult to "give" away your
services. But for me, I'm part of a group who develops a separate vertical
solution, offering examples of tools I've built, or structural development
decisions I've made is painless and not costly. Why the mvDbms players
wouldn't be scouring the countryside looking for this stuff to publish is
beyond me. This should be part of their products.
I look at FlashConnect. It's so difficult to get ones brain around the
entire concept, starting from an mvDbms perspective, because the describing
language of the new technology is so different. The new language describes
exactly what we're familiar with, but using such different language that it
took me 6-12 months to understand that HTML, Javascript, and other such
development environments weren't as difficult as I thought. Once I could
translate the new language I was back in business.
> The phrase "cutting off one's nose to spite their face" implies that
> by not doing X you sacrifice Y, but if we aren't getting anything from
> X anyway, what have we to lose by telling people if they want it, no
> more freebies, they'll have to pay for it. Pay for it with your own
> research time or pay someone who has done the research or coding for
> you, but you've gone without paying anything for a long time and it's
> time to start owning up to responsibility and rewarding people who
> make your life easier.
This phrase is more an attempt to get across the point that we all benefit
when the market grows. If I create something that 50 other people can use
to help build their solution, and I don't rely on that "something" to pay my
mortgage, then it benefits everyone, including me, if I publish that
"something". Or, better yet, if the mvDbms players provide these examples
to help people build solutions using their product.
> The same goes for the DBMS companies. As an example, the D3 Class
> Library has been free since the beginning, but has providing that for
> free R&D helped PS/RD to grow? Nope. FlashCONNECT was dropped to
> FREE for over a year, but did VARs sell any more systems? Nope. So
> now there is a price for PDP.NET and FlashCONNECT, and RD charges a
> price for other add-in options too - if they aren't making any money
> on DBMS licenses then they need to charge for the tools, it has to
> come from somewhere. Is jBASE immune from this? Nope - they sell
> jEDI too, but you don't hear jBASE customers complaining about it
> because they appreciate the value in the add-on.
I can only give you my non-technical, business oriented perspective on this.
The entire language of VB escaped me. I couldn't figure out the language of
VB. The assumption of the D3 Class Library was that I was totally familiar
with VB and it's language.
You sometimes forget guys like me aren't nearly at technically astute as
you. I'm a simple businessman who has a business degree who developed an
mvDbms solution to solve my pressing business problems. Offering me the VB
Class Library free doesn't even come close to describing why I want it, what
it does, how it can replace aspects of my current solution, how it's
cheaper, etc, etc, etc. What are the components of an application that the
D3 Class Library, let alone VB, that can be useful to me and how can I
implement it? See what I mean?
It's not just the technology but how to use it.
> > It's not closed minded nature, that's the problem. It's life-n-limb
> >tied to a 200 line snip of code, which could easily be duplicated and
> >sold. Developers are still relying upon pieces of code to pay the
> >bills. This is fine and dandy, provided the code is shelved with a
> >decent price tag.
>
> Glen, you're right that we make our living by selling code (if we're
> lucky, vs selling our time for which there are no recurring sales), so
> it's important to protect our assets.
>
> Pricing products in this market is very difficult and sometimes
> doesn't make a difference. For a short time I offered an MV-based XML
> engine starting at $2500. It was modeled after mainstream products,
> and did about as much as a couple of those products, even the new XML
> functionality in U2, but was priced at about 1/10-1/20th of the cost
> for the mainstream offerings. I got zero bites from the MV market -
> maybe I should have started at $20,000?
I think this is an example of what I'm talking about. Considering business
people have built mV solutions, how do they view XML? I think it would be
critical to understand this in determining a price.
Normally, the technically deficient like me need to see something working to
understand how it can impact the business. XML is just a buzz word that
doesn't relate to "bottom line" unless I can see how. Trying to sell me an
XML parser doesn't address my underlying concerns: how to increase revenue
or reduce expenses.
> > Some of the consulting fees and application costs
> >I've seen at Spectrum, make me wonder how much companies are truely
> >spending on IT solutions in this community. I don't want to take
> >anyone's lunches or run into copyright lawsuits. However, some of the
> >OEM and 3rd party tools currently being sold are now OLD technology
> >that should be freely available on ALL MVDBMS packages. It really
> >pisses me off seeing a $2000+ web connectivity "toolkit" that isn't
> >flexible enough to support XML processing.
>
> The problem is that most Pick people don't do their research like you
> and I do. The code that ticks us off as being too simplistic is
> absolute rocket science to some people, and they're willing to pay for
> it (sometimes). You need to consider the audience. Also, by the time
> a "product" makes it to market these days, the technology may have
> already changed. My COM-based NebulAnalysis was rocket science when I
> developed it (even though it was priced dirt cheap) but just a year or
> two later the HTML/XML capabilities in Excel made my software obsolete
> (for anyone who'd do the research to figure that out) - but I still
> get calls today for the software. (Calls which I ethically try to
> change into a service engagement because I don't want to get a bad rap
> for selling old technology :) )
Remember, a lot of us "Pick people" are not technically savvy. The
development of an mvDbms solution is usually different than the development
of a technically "mainstream" solution. Moving development to "mainstream"
methodologies negates a principal benefit of mV; lower development costs,
lower support costs, lower upgrade costs. And in doing so, this
"mainstream" methodology removes the businessman from most of the cycle.
That's a big change!
Can an mvDbms development methodology incorporate new technology? Can the
technology and its benefits be described in business terms?
[nebula mail stuff snipped]
> Bill continued:
> >>This is especially true for .NET and VB and Java development. We need
> >>critical examples; like how to create a file object. How to use the
> >>dictionaries as a property. How to create a global set of variables and
> >>methods. How to call a BASIC routine. How to transfer data back and
forth
> >>to the mvDbms server. We're not stupid, but can use a little help with
> >>these kinds of things.
>
> For what it's worth I did start writing a PDP.NET Tutorial for which
> there was no interest from the community, nor from RD. If no one
> wants documentation then what sense is there in writing it?
Yea, the vendor doesn't want examples nor do they want success stories.
What can you say? This goes back to what we've discussed about RDUS and D3.
D3 is an excellent product but what can people do when they overcharge and
refuse to provide any assistance in using their products for business
solutions.
Like the D3 Class Library, they provide technology to a community that is
mostly business oriented and wonder why that community doesn't beat a path
to their door; because technology is usually not a dollar and cents
language.
[snipped]
> > The problem with doing this, is that every DBMS vendor has their own
> >way of doing things. There is no 'Pick Bible' that can be sold at
> >Barnes & Noble, which can tell anyone how to program on any flavor of
> >Pick/MV. The Pick community needs to establish common standards for
> >many things. Until that happens, the segregation of the technology
> >will be its final demise.
>
> Not necessarily. There are hundreds of books on C/C++, VB, Java,
> Oracle, MySQL, and all of the various subtleties associated with
> running each in different environments. We don't need one Bible, we
> need many of them. The problem is that people in this market won't
> buy or read any of them. Just ask Jon, Harv, Matt, Malcolm...
Yea, but I've already completely read three ASP.NET books and am struggling
to understand the ins and outs of what I'm doing. It takes my friends to
help me digest this "new language" of doing pretty much what we've always
done to understand how it can help.
> I agree there, but the pricing models are a desperate response to the
> issues I've gone on about here. If you want everything for free how
> do you expect them to stay in business? Of course they're going to
> start getting irrational with their policies. Bill, you know first
> hand how irrational RD can get: What do they do when Sales and
> Marketing people aren't generating revenue? They fire all of the
> sales and marketing people - you included. We are in the open market
> now because of the very mindset that you are supporting.
>
> I don't disagree in general that free information and software
> "should" encourage sales, but only in a market that actually
> reciprocates with that policy. At some point investment is perceived
> as expense, and that causes all of these software and service
> providers (myself included) to re-evaluate the policy.
When I say spread the wealth of information I don't mean "give away" your
livelihood. Why would you want to keep to yourself the concept of a
"connection object", why it's needed, what it replaces in an mvDbms
environment, and how, properly written, it can save mvDbms development a lot
of grief.
But my complaint isn't about you at all. You're, personnally, way generous.
It's about the mvDbms vendors. Microsoft doesn't GPL their software
(mostly) but they make it pretty easy, and cost effective, to develop using
their products. I have a tainted view of Linux and their not-so-free free
software.
> It's a community mindset Glen. Over the last couple of years I've
> proposed many ways for the community to take charge and do things for
> itself but every effort ends in apathy. OpenQM is a great concept but
> I'm afraid people will only use it as long as they can get someone
> else to make changes to it for them. At some point the people who
> maintain it will get tired, and that's where we can all hope that
> mainstream open sourcing will bring in some fresh bodies to maintain
> it. This generation of MV users will not appreciate OpenQM for what
> it is, which may be one of the last chances to save our market. I
> also fail to see how people who won't research SMTP options (one of
> the most discussed protocols on the net as you say) are going to want
> to have anything to do with a complex open source project like OpenQM.
There is, and I suspect always has been, a disjoint between technologists
and business people. The language doesn't mean the same thing.
Technologists refuse to understand this. They have a complete language that
(try reading a newsgroup like comp.databases.theory) is especially unclear
when discussing anything outside a VB data type, an RDBMS SQL join, and on
and on. :-)
I've always thought of the mV community as a loosly knit bunch of business
people running businesses using MV technology; which allows them to either
write solutions or have some close to them write solutions. No need to
outsource this stuff to India. :-)
I was just down a few weeks ago. I'll call you when I come down again in,
probably, January. :-)
Bill
Doug Dumitru
<idontre...@hotmail.com> wrote:
>In article <mq97r0ds8du93hqkr...@4ax.com>,
> Doug Dumitru <do...@easyco.com> wrote:
>
>>And the only plus is marketting.
>
>I've noticed a lot of speed improvements not running inside the
>virtual machine. Also, in comparison to D3, you actually have OS
>files that can be backed-up instead of needing to export the data
>somehow to be backed-up. Finally, if you're used to Unix, it is very
>handy to switch back and forth between database mode and Unix mode.
But this is true of U2 as well.
>>MV spends 99.9% of its time in the runtime libraries. Eliminating
>>the pcode just does not buy you enough.
>
>My experience has been different. Part of the reason is because
>jBase maintains a pointer into your dynamic string. This eliminates
>the need for U2's REMOVE and accelerates any code that needs to step
>through a long list of attributes, values, etc..
This is a good optimization of the run-time libraries. Again, it has
nothing to do with p-code vs native code. My complaint about native
code is that:
a) it is bigger
b) it takes longer to compile
c) it is not portable
d) you have to suffer the limitations of the system linker
Probably the best "non-partisan" evidence of p-code vs native-code
performance is actually from D3. Early on, D3 flash compiled code
would generate "real" object code with the same type of runtime as
jBase. This was called flash level 1. Later on, because some
platforms could not be trusted to have reliable C compilers on them,
flash level 0 was created that used the same run-time libraries as
flash level 1, but had a small p-code interpreter instead of
generating native code. The performance difference between the two
version was <1%.
>>And talking about migrating to jBase as being the "easiest" path,
>>just seems wierd to me.
>
>It sounds odd, but with the two applications I've ported, it has been
>quite easy. They have a ton of portability flags, plus easy
>"programs" that set them to closely match every mv-flavor I've heard
>of, and a PORTBAS program that fixes keyword collisions. The biggest
>task that needed (well, it really didn't, but helped the speed) to be
>done was to switch from U2's LOOP ... REMOVE ... REPEAT to DCOUNT ...
>FOR ... NEXT because that's actually faster due to the internal
>pointers.
I have no doubt that porting from D3 to jBase can be done and can be
"easy" in many cases. I just don't think of jBase as being all that
close to D3 and native pick. D3 tends to isolate you from the host OS
at an admin level and jBase tends to immerse you in the host OS.
These are not absolute arguments, but just arguments of degree.
Also, it is my understanding that U2 does the dynamic array pointer
follow trick as well. Regardless, your saying LOOP ... REMOVE ...
REPEATE as a U2 construct and REPEAT to DCOUNT as a jBase construct is
not very helpful. In either case, both methods perform worse than
SELECT ... LOOP ... READNEXT ... UNTIL EOF DO ... REPEAT which has
worked well since before R83.
--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000)
EasyCo LLC do...@easyco.com http://easyco.com
--------------------------------------------------------------------
D3, U2, jBase Virtual Servers. Off-site backup over the internet.
Develop/test/deploy from $20/mo. Fast, secure, cheaper than tape.
http://mirroredservers.com http://mirroredbackup.com
Doug Dumitru
<idontre...@hotmail.com> wrote:
>In article <69l6r0hmionn8ne6h...@4ax.com>,
> Doug Dumitru <do...@easyco.com> wrote:
>
>> OpenQM is a GPL fork of the QM commercial database from Ladybridge.
>> It is licensed under the GPL instead of the LGPL which makes it
>> excellent for in-house "free" use, but typically requires commercial
>> software developers to purchase commercial licenses.
>
>That's a bit of a misstatement regarding the GPL. The difference
>between the GPL and the LGPL is that the LGPL isn't viral like the GPL
>is. Compilers, code builders, and such really should be licensed
>under the LGPL otherwise any executables, code, etc. built with them
>are bound by the GPL. Libraries are sometimes distributed under the
>LGPL, because if they aren't, then including the library in your
>project (unless play games with wrapper applications (which become
>bound by the GPL but protect your program and fork()) forces your
>application to be bound by the GPL.
Whether run-time libraries should be licensed under the GPL is really
a question of the intent of the owner of the libraries. In the case
of OpenQM, the intent is to use the GPL. If your application and
business model can run under the GPL then you are welcome to use
OpenQM. If your application and business model are better suited to a
commercial license, then license CommercialQM. This is a classic case
of using the viral nature of the GPL as a method to preserve at least
some commercial income.
My statement also said that OpenQM was excellent for in-house "free"
use. This is saying that you are welcome to use OpenQM in-house for
"free". It says nothing about commercial vs. non-commercial use. It
does say that commercial software developers would probably want to
purchase a commercial license. This is true because it is the
commercial software developers that dont want to GPL their application
code.
Also, attempts to circumvent libraries by using things like wrappers
is somewhat dubious as well. If you read the GPL faq, you will see a
lot of talk about what is a "combined application" and what is not.
The answer here is not whether the application runs in the same
address space, or even on the same system, but how intertwined the
application is with it's libraries. So using fork() for something
simple might be OK, but using this with a complete complicated
database application run-time is dubious at best.
>There's nothing in the GPL that prohibits commercial use. There's
>nothing in the GPL that prevents somebody from making a few tweaks to
>GPL code and then selling it. There's nothing in the GPL that forces
>custom changes to be passed to the upstream maintainers. The only
>requirements in the GPL regarding commercial sales of GPL code is that
>the source code must be available (but it only has to be made
>available to people that have purchased your product) and it allows
>anybody that has purchased a copy to give unlimited copies away for
>free.
You are absolutely correct. With OpenQM, you can fork the project to
parts unknown. You dont have to give anything back to Ladybridge
unless you want it to become part of "our" release (I was going to say
"official" but that was not quite right. Perhaps the "official
Ladybridge" release would be accurate). The only requirement that
Ladybridge has is that if you do submit code back to "us", then you
must submit it to us under a BSD style license so that your submitted
code can be used in both OpenQM and CommercialQM. The last thing we
want is for CommercialQM to become infected with someone else's GPL
code.
>Also, saying that code is released under the GPL for non-commercial
>use only, is (in spirit and possibly legally too) in conflict with the
>GPL and I doubt it would be enforceable. I also highly doubt the FSF
>would even help you enforce the GPL in that case. If you really want
>to find out, ask them at: <mailto:license-...@fsf.org>.
We have never said that. Both commercial and non-commercial users are
welcome to use OpenQM. We think that many commercial software
developers will chose not to use OpenQM because they don't want to GPL
their application code to their customers, but this is their decision.
We do say that we are liberal about giving out free licenses to
CommercialQM for non-commercial use, but that is a completely
different thing. What you use the code for is beyond the control of
the GPL. How and to whom you distribute it is what the GPL is all
about.
Doug Dumitru
<idontre...@hotmail.com> wrote:
[ ... snipped ... ]
>> The only requirement that Ladybridge has is that if you do submit
>> code back to "us", then you must submit it to us under a BSD style
>> license so that your submitted code can be used in both OpenQM and
>> CommercialQM.
>
>One more nit-pick. I'm assuming you're referring to one of the more
>recent "non-advertising" versions of the BSD (essentially identical
>to the X11 license), because the original BSD license is incompatible
>with the GPL.
Martin Phillips actually has a simple agreement regarding this. The
issue with a BSD "back to Ladybridge" license is that LadyBridge wants
to keep the commercial and GPL forks in sync. If a GPL piece from
another party gets into the commercial code-base, then the commercial
code-base becomes GPL. Code that Ladybridge wrote is OK, because,
well, it is their code. So code/fixes that others submit back to
Ladybridge have to be licensed so that Ladybridge can include them
freely in commercial QM. This is actually pretty common stuff. I
know that MySQL and Asterisk both work this way. I suspect there are
dozens of others.
Simon Verona
Long time no see!!! You been hibernating?
Developing new add-ons for jBase ???
I hope I didn't overplay the concept that jBase was SIMPLY a PICK clone....
It is a lot more than that.... I was hoping to point out that for those
simply looking to migrate from a MV variant (D3 etc) but didn't necessarily
want all the bells and whistles, then jBase should not be discounted as an
option.
Personally, I don't think that the learning curve for jBase is all that
bad... Or maybe I've been using it for so long that it's second nature..
Actually, I find it real difficult using mvBase these days - on the rare
occasions that I need to.
Chandru obviously has issues with jBase... It sounds like jBase is not the
product for him. I always got the feeling that jBase didn't fit in well
with his multi-platform program generator - though I'm probably
oversimplifying this.. I hope that I've not oversimplified this!
Anyways, I'm off to write JBASE GOOD 100 times on my whiteboard in green and
orange letters..
Regards
Simon
"Jim Not Pick" <ji...@idle.ws> wrote in message
news:1103046822....@z14g2000cwz.googlegroups.com...
>I rather think you are overplaying the 4 word statement. Of course
> jBASE can do anything that Pick can do (despite all my efforts) but the
> "Philosophy" is not Pick. In other words, don't treat the bloody thing
> like Pick and it won't bite you. But if you want to compile and catalog
> on a live system, and embed your app in 17 execution layers of Proc,
> then maybe it isn't the best choice, despite being able to do it.
>
> Basically, all of Chandru's stuff can be boiled down to:
>
> 1) BASIC doesn't produce something that can be run without CATALOGing;
> 2) Output formatting parameters don't always compile;
> 3) When I type T-DET (U it doesn't say !FLZ 4.2 like R83 does [and
> related stuff].
> 4) It isn't Pick and trying to be a Pick emulator so we need to write
> jBASE BAD in white letters on the barn wall;
> Why do I feel like a Wright brother being asked if it comes in green?
>
Jim Not Pick
Barry wrote:
> "Tom deL" wrote in message
>
> [ snip ]
>
>
> >
> > The application that I would be moving began as an R83 system of
> > hundreds (maybe over 1K) of PICK/BASIC programs and a similar
number
> Hi Tom,
>
> To answer your question in one simple word, 'UniVision' is what you
> are looking for.
Oh do me a favor.
The real answer is that any of the products will convert an R83 based
app in about a day with probably very little tweaking. I think that
even the Unix shell stuff would work on jBASE, though I hated putting
in copmatibility things such as that as what is the point of having say
a SH command in jBASE when you can just execute the command anyway. But
all that aside, you can port to anywhere, though I am afraid I have to
laugh when someone suggests that UniVision is the answer; I don't think
there is likely to be any problems porting an R83 application to it but
<insert reasons here...> etc blah
Then it depends what you care to do afterwards. If you are doing stuff
with Unix, then it coudl well be that jBASE is a good choice for you.
If you will never touch the thing once it is running, then just choose
the cheap one and forget about it - it isn't rocket science and thanks
to the fact that nobody ever wants to pay anything for a Pick product
anyway, there are no expensive options ;-)
Jim
Jim Not Pick
replies I find:
a) A number of responses too rude to post;
b) Most of what is posted here to be vitriolic rehtoric that does not
deserve a reply;
c) Given b) .... arrgh, too late.
Now I remember why I gave up reading the Pick and jBASE newsgroups.
Anybody got any jobs going?
Jim Not Pick
Jim Not Pick
a 1 minute glance at the website would reveal. The TEMENOS web site is
about explaining TEMENOS and the banking software, not the application
engine it happens to use, which would mean nothing at all to the
banking community without an awful lot of effort that would not really
help anyone. The jBASE stuff is explained at, strangely, www.jbase.com
Jim Not Pick
Jim Not Pick
Barry wrote:
> "Tom deL" wrote in message
>
> [ snip ]
>
>
> >
> > The application that I would be moving began as an R83 system of
> > hundreds (maybe over 1K) of PICK/BASIC programs and a similar
number
compliant,
> > most of the differences being things that rely on shelling Unix
> > commands. The ideal path would be to something that was designed
> > with backward compatibility in mind.
> >
> > Do any of the existing PICK licensees' offerings provide at least a
> > modicum of R83 compatibility? The point here isn't having others do
my
> > homework but to get unbiased input from those who have done this
> > migration. When we originally moved this application to the then
> > fledgling AP, there were a few headaches but AP was trying very
hard to
> > be able to accept R83 applications.
> >
>
> Hi Tom,
>
> To answer your question in one simple word, 'UniVision' is what you
> are looking for.
>
over
> time has been considerably enhanced while retaining R83 backward
compatability.
>
> I have first hand expierence that UniVision is more than capable of
handling
> a 100 user system, scales much better on a SMP system than D3, and is
a
> rock solid performer.
>
> VIA systems are the international distributors, it would be worth
getting
> in contact with them, you will find them very helpfull and pleasent
to deal
> with.
>
> Here is the URL.
>
> http://www.via.com/
>
> HTH
>
> Barry
murthi
course your own words (in all your posts) do more damage to your case, and
provide a better insight into your opinions of everybody, than anything I
case say. 'nuff said.Maybe you should get a job with Karl Rove, he can't
quite match your disinformative skills.
Chandru Murthi
"Jim Not Pick" <ji...@idle.ws> wrote in message
news:1103046085.2...@f14g2000cwb.googlegroups.com...
Dawn M. Wolthuis
know, these two gentlemen really are both key players in the history of the
MultiValue family of products (and perhaps also n the future?).
Mr. Murthri & Mr. Idle -- Is there any chance I could get you both to stop
by my house for dinner some time together? I'm not sure where you each are
right now, but I suspect I live about halfway between you (Iowa). I'll
video the dinner conversation and help to make it entertaining ... at least
for me.
We can turn it into an indie film "Anatomy of a Technical Disagreement?"
with the question mark in the title. We could try to determine what aspects
of the disagreement arise from the neocortical brain compared to the limbic.
Then again, it is the reptilian brain that is responsible for territorial
reactions, if I recall. Academy Award stuff.
smiles. --dawn
P.S. Let me know what dates work for you. You can fly into the Sioux Falls
or Sioux City airport.
"murthi" <c_xyz_murthi@seeing_xyz_green.net> wrote in message
news:OlZwd.1131$152.831@trndny01...
BobJ
"Dawn M. Wolthuis" <dw...@tincat-group.comREMOVE> wrote in message
news:cq3pcn$ojj$1...@news.netins.net...
> Gotta love this exchange between two pick icons. For readers who do not
> know, these two gentlemen really are both key players in the history of
> the MultiValue family of products (and perhaps also n the future?).
>
> Mr. Murthri & Mr. Idle -- Is there any chance I could get you both to stop
> by my house for dinner some time together? I'm not sure where you each
> are right now, but I suspect I live about halfway between you (Iowa).
> I'll video the dinner conversation and help to make it entertaining ... at
> least for me.
>
> We can turn it into an indie film "Anatomy of a Technical Disagreement?"
> with the question mark in the title. We could try to determine what
> aspects of the disagreement arise from the neocortical brain compared to
> the limbic. Then again, it is the reptilian brain that is responsible for
> territorial reactions, if I recall. Academy Award stuff.
>
> smiles. --dawn
> P.S. Let me know what dates work for you. You can fly into the Sioux
> Falls or Sioux City airport.
>
Sign me up for a copy at almost any price! But your house will be
radioactive for at least 500 years.
But only one is a Pick Icon. The other is a Not-Pick Icon.
BobJ
Dawn M. Wolthuis
news:1Cixd.4024$yK....@newsread3.news.atl.earthlink.net...
Good deal -- not only will it serve as some entertainment for me, but a
source of income as well. Jim & Chandru -- I'll give you an appropriate
share of the wealth, so now there is more reason to accept the invitation.
>But your house will be radioactive for at least 500 years.
> But only one is a Pick Icon. The other is a Not-Pick Icon.
I stand, uh, corrected. smiles. --dawn
> BobJ
>
Anthony W. Youngman
Keep it to Usenet please <idontre...@hotmail.com> writes
>> The only requirement that Ladybridge has is that if you do submit
>> code back to "us", then you must submit it to us under a BSD style
>> license so that your submitted code can be used in both OpenQM and
>> CommercialQM.
>
>recent "non-advertising" versions of the BSD (essentially identical
>to the X11 license), because the original BSD license is incompatible
>with the GPL.
One more nitpick ... "The BSD License" does not contain the advertising
clause any more, so the BSD Licence itself is a "non-advertising
licence" as you put it. (And nobody but Berkeley would have used the
original advertising version, because it required you to advertise
Berkeley.. :-)
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett
Anthony W. Youngman
ashe...@inlandkwpp.com writes
>I personally see MV going the way of Linux/Unix but the license model
>will probably look different than the OpenQM situation. Ideally, all
>application sellers would distribute source code with their product
>but this isn't the case. In my opinion, in order for an open source
>MV backend to catch on, it'd have to dump the restriction of not being
>able to link with proprietary applications. It isn't in the same
>position as MySQL: MV's niche/developer/application base is too small
>and its standards are not standard enough.
What I want to see, is for an MV backend to get into something like a
linux ldap server. The trouble is that SQL/Relational has the mindshare.
I happen to know that the linux engineers think it's crap (no database
IN linux is relational), but users and PHBs buy into it.
Get the linux engineers into MV, and we stand a decent chance of it
slowly driving out relational, just as linux is slowly but inexorably
driving its way into pretty much every OS market.
Bruce Nichol
On Tue, 28 Dec 2004 19:08:51 +0000, "Anthony W. Youngman"
<thew...@nospam.demon.co.uk> wrote:
|<snip>
>Get the linux engineers into MV, and we stand a decent chance of it
>slowly driving out relational, just as linux is slowly but inexorably
>driving its way into pretty much every OS market.
>
>Cheers,
>Wol
But that won't happen while DataBASIC, or any other BASIC, rules the
MV roost as the "primary" programming language.... especially with
Linuxnerds or any other ...nerds involved
An all-encompassing *new* (to MV) language is needed, that, strangely,
does everything that DataBASIC does...... and, the more convoluted and
involuted, the better. Preferably with compiler bugs 'n' all......
I wonder how a change of name, away from "...BASIC...", would go?
"D", "D++", anybody?
Regards,
Bruce Nichol
Talon Computer Services
ALBURY NSW Australia
If it ain't broke, fix it until it is....
Tony Gravagno
>An all-encompassing *new* (to MV) language is needed, that, strangely,
>does everything that DataBASIC does...... and, the more convoluted and
>involuted, the better. Preferably with compiler bugs 'n' all......
>
>I wonder how a change of name, away from "...BASIC...", would go?
>
>"D", "D++", anybody?
Nah, just create a decent open source class library that can be
invoked through a wrapper from common languages like C, Perl, Java,
PHP, and C#/Mono. I was trying to encourage RD to do that
Yeeeeeeaaarrrs ago but they never understood the concept. But guess
what? We already have mvWWW and JD3 to provide this sort of glue. So
now the only thing missing is a free MV DBMS...
If the license for OpenQM were extended to allow using it for
production use as an embedded database, more of an OS-level appliance
rather than a business application server, then it looks like we'd
have all of the pieces to provide an alternative database for LDAP and
other protocols.
Really though, most tools use plain text .conf files rather than a
database, and if anything, these tools would/should(?) migrate to XML
rather than a hefty container like a database.
2yen... (I can't say 2euros anymore, they're actually worth more than
the dollar!)
Tony
Simon Verona
Basic.Net, with some way of converting the MV data structures to standard
SQL. This is going the opposite way to what you Tony describes.
The conversion of Databasic itself to vb.net isn't actually that difficult,
providing a library is written to handle the "pick" functions - jBase does
something similar in it's conversion to C for native compilation. Ideally
though, unlike jBase's conversion to C, the conversion to VB.net should be a
once off conversion which then can be maintained in VB.net afterwards.
It's the data storage that becomes the problem... You could simply create
sql tables that have fields called "att1" "att2" "att3" etc, with
multivalues linked in a sub table with fields called att_no, Val_no,
SubValue_No etc...
But if you do this, you've lost some of the usefulness of switching to a
relational database! Your data isn't really relational at all so you can't
easily use SQL on it at all... So, I guess some sort of Conversion mapping
for the datatable for relational use could be made (similar to the mapping
that is already used for SQL access to MV data) which could then be used to
a) map the data, as well as b) migrate the <amc,vmc> syntax to use the new
field names.... I guess this is possible but there are a number of really
difficult issues (such as dynamic file opening where the filename is a
variable....)...
Perhaps an intermediate layer could do the mapping at runtime.... I've
played with this in my vb.net code where currently i have data-aware
controls that use AMC,VMC,SVMC offsets to access data - I've been working on
building a dataschema that could be used both for this mapping, as well as
creating dictionaries and for report generation etc... I will probably
complete this project in the next few months (it's kind of spare time work
at the mo as mapping directly to the data works well at the mo).... If so, I
expect to be able to move to standard .net databound controls by converting
MV datarecords to disconnected datasets.
This is very possible, and will then allow me to convert my inline code to
use sql style syntax on my MV data with the data being converted to and from
MV file format as it's read and written. I already switch data into
datasets from MV data for datagrids using a similar technique (the data
returned from a databasic function includes header information of the field
names, types etc for conversion to the dataset)....
Is this the killer app for Multivalue?? Well, it would probably kill
Multi-value if a payonce tool could convert the database to
DB2/SQLServer/mySql etc as well as convert the Databasic to Vb.Net (or other
"mainstream" programming language).
Whilst I don't really want or need to leave the MV marketplace, I think that
I will eventually need to "jump ship" simply to get out of the MV pricing
model... It will come to the point where the once off cost of writing the
code to do the conversion will be balanced by the ongoing licence cost....
This is the only reason I will migrate from MV - I don't feel disadvantaged
in any other way using the MV data model compared to competitors using other
databases...
Just my 2 Euros worth.... I obviously have a higher worth of my posts than
Tony does of his !! <G>
Regards
Simon
"Tony Gravagno" <g6q3x9...@sneakemail.com.invalid> wrote in message
news:u3o6t0h4kldg0dojm...@4ax.com...
BobJ
The big problem with converting MV to SQL is not the conversion - it's
the lack of knowledge of the data to be converted. The dictionary may be
accurate as far as it goes but it doesn't even begin to tackle dependencies.
So the only real way to convert a data base that is built in MV to one that
gives the same results in SQL requires that each and every program that
writes into a file be investigated in detail to see what it does to the
integrity and the dependencies. I suppose that could be done automatically
but it is a daunting task. And the dictionary may not be accurate - and
often is not accurate. The original entry is often left behind when a
change is made out of fear of breaking some proc that is seldom run but
needed badly when it is finally run. So now you have more than one entry
for a particular attribute. That in itself is a strength rather than a
weakness - until the two entries become mutually exclusive. Which is right?
Usually easy to determine with a little built in human intelligence but very
difficult programmatically. You can not just say that latest is best. We
fired a programmer once who left behind a large number of very bad
dictionary entries - all with A in attribute 1 instead of the mandated S.
Of course you have an advantage when you are converting your own programs
and data. But when you start trying to make a universal conversion kit then
the troubles start to mount.
But if you get it to work it probably will be the only tool in history,
aside from SB and PRC that is, that has found a market in the MV community.
BobJ
"Simon Verona" <ne...@aphroditeuk.com> wrote in message
news:41d3f7fd$0$14592$ed26...@ptn-nntp-reader01.plus.net...
Simon Verona
I concur with the difficulties...
The problem has always been the lack of requirement in MV databases for the
dictionairies to actual represent the data (or data represented as per the
dictionary - whichever is more appropriate!!!).
I agree that there is little chance of a general tool being able to convert
files on the basis of the dictionaires or the data-basic code... The
files would need manual mapping, which the conversion system could then
follow to build the new relational tables and also use at runtime for
"binding" the multi-value representation to the relational representation.
I'm going some of the way in trying to build some integrity into my
dictionaries - but thats by building my own data schema... It's not ideal,
but could be used to help convert my own files and data-basic code....
I don't intend to write such a generalised tool... It is likely that the
conversion will be simply for in-house use only.... though you never
know!!! I hope that I never have the need to write it..... but I'm afraid
that I might!
Regards
Simon
"BobJ" <b...@rjoslyn.com> wrote in message
news:ebVAd.2789$JC2....@newsread2.news.atl.earthlink.net...
Tony Gravagno
using SQL underneath: It would be interesting to see if we could flesh
out a spec for something like this so that "someone" could do it.
Without thinking about it too deeply I see a tool like this involving
the following rules/procedures:
1) This is a part manual process and part automated. There is no "one
size fits all" tool that's going to magically fix the damage that
decades of manual tweeks have made to code. The site admin (herein
called the developer) needs to prepare code for a conversion.
2) The code should be modularized to extract the UI from the rules.
How many times can I say this? The first step in doing anything with
the code is to remove the PRINT and INPUT statements. Do we want .NET
code working from a black and white Console?? No. Modularizing the
code makes it accessible from any UI, GUI, or Web Service architecure.
3) Don't trust the current Dictionaries. The developer creates an
alternate Dict for production files and copies or creates definitions
which properly define the structures. These dicts will be used to
define the data, not for AQL reporting, so they don't need A/F
correlatives, T/U justification, etc, just basic info. This also
helps to keep the conversion more consistent between A/S defs and
I-descriptors in U2.
4) As much as possible the developer needs to standardize file
references in code, and references to items read from specific files.
This helps a tool to figure out which structure to apply to a given
variable at any given time.
5) Variable pre-processing should be done as well. Many developers
use "temp" for strings, calculations, and as a For/Next var - all in
the same program. Unique variables should be assigned for unique
purposes - or at least for unique data types. That's not important
for Pick BASIC but is for other languages.
6) GOTO statements should be eliminated simply because other languages
don't support them.
7) Multi-statement lines (delimited with semicolons) should be
eliminated, as well as any other hot-shot tricks that simply aren't
necessary (user exits, complex OConv/IConv, reliance on var<0> or
known bugs). While many other languages can accomodate this, it's
really just a pain on the parsing (in my experience anyway).
Statements that have overly complex string manipulation all in one
line should be simplified to minimize the chance of parsing errors.
Sure, a convertor should be able to manage this, but the resulting
code would be unmanagable - clean code begets clean code.
8) EXECUTE statements need to at least be identified for further
evaluation, along with any other code that ties directly to the host
environment.
9) Recursive code (code that calls itself or calls to other programs
which call back on it) should be at least identified . Modern
languages can handle this but the way they do is different, and the
structures would need to be verified in converted code. Again, clean
and simple code is a better base from which to start.
10) Check for anything flavor-specific like UOPEN, ROOT/KEY and other
indexing, LOCATE with D3-specific right-justified sorts,
Ultimate-specific EXECUTE syntax, etc.
... so much more...
And remember, this is stuff that needs to be done before a tool even
starts looking at the code...
Having worked on language conversion projects before, thinking about
tools like this makes the little kid in me want to jump to the
keyboard and start banging out code. A more mature and somewhat jaded
professional realizes that a monolithic task like this can't be
undertaken without financing or at least some guarantee that the
effort will be investment and not expense. If someone can verify
financing of a project like this then we have the talent in our
community to make it happen. If not then it's at least a fun exercise
to think it out.
Tony
TG the dotnetifier @ remove this Nebula - RnD dotster com
Anthony W. Youngman
<tal...@optusnet.com.au> writes
>An all-encompassing *new* (to MV) language is needed, that, strangely,
>does everything that DataBASIC does...... and, the more convoluted and
>involuted, the better. Preferably with compiler bugs 'n' all......
>
>I wonder how a change of name, away from "...BASIC...", would go?
I was hoping to add such a language to MaVerick. Called COMPLEX, of
course :-)
Simon Verona
All the problems you mention are issues for such a conversion.
Interestigly, I don't think that the actual conversion of DataBasic to
vb.net is that difficult (relatively!). The difficulty will be in producing
code that is efficient, readable and maintainable.
The problem is the conversion of the database to relational. As you say,
the MV Data Dictionary is largely useless in an automated process - all the
files will need manual mapping. With a good data schema the conversion of
the data to relational could be done (as I said before, much like the
existing mapping routines for ODBC connections to MV data).... Existing
code could then be left with the concept of a dynamic array and converted to
and from a relational structure at runtime - as reads and writes are done.
This is more than possible though the major problem is the typical MV issue
of extra undocumented fields in the data!
Another problem are files where different items have different structures -
typically, parameter files in MV systems seem to have this kind of problem.
This file would not directly be able to be mapped to a relational
datastore....
Once the conversion to relational is done, then extensions to the Pick.Net
language could then use field names rather than attribute/value offsets etc.
Indeed, once conversion is made, new code would not require any MV code at
all - normal SQL access could be made..
An interesting angle would be to not go relational, but skip to one of the
newer generation of "XML" type databases.. It all depends on how quickly
they develop.. Personally, I think that maybe both would need to be
encompassed.
I don't deny that this would be a major undertaking for somebody (or more
likely a team of people)....
Unfortunately, I believe it will be a necessary undertaking unless the MV
vendors get their act together and remain competitive in terms of price and
database features...
Perhaps, it needs somebody like Tony to undertake such a project,
"sponsored" by members of the community.... By sponsorship, I mean
venture capital of course, though I guess also expertise, time and energy
would be required inputs. I for one would consider putting my money where
my mouth is....
Out of interest, i describe vb.net as the language of choice... CDP'ers will
know that I am a big fan of vb.net, though Java may need to be an
alternative.
Of course, the existing product that is closest to already having this is
jBase... It already converts Data-basic to C and then compiles, linking to
their own "pick" library. The linking to non-MV databases is done through
the jedi.... I believe that it would be technically possible to write a Jedi
driver that would use a MV-Relational data-schema to convert data to-from
relational as it goes along. I'm not a c programmer, so wouldn't even
consider writing such a Jedi!!! I don't know how difficult it would
technically be for jBase to generate vb.net code which links to their c
library... of course, if jBase did this, then they would be admitting
defeat for the multi-value model and cutting off their future revenue
stream....
Maybe IBM will do something to assist in the conversion of U2 to DB2.....
I believe that the concept is more than possible.... I don't know how
large the potential market for such a tool actually is...
Regards
Simon
"Tony Gravagno" <g6q3x9...@sneakemail.com.invalid> wrote in message
news:ori8t0dv1k11992uh...@4ax.com...
Tony Gravagno
[major snippage]
>Out of interest, i describe vb.net as the language of choice... CDP'ers will
>know that I am a big fan of vb.net, though Java may need to be an
>alternative.
Since we're off the wall anyway... :)
I would look at a project like this with the same eye as for GUI
development, divorcing the business rules from the UI. Conversion
From BASIC is one exercise and conversion To another language is
another exercise which should be done through a wrapper so that we can
have more than one target language. Same goes for the database - not
all relational databases are the same.
>Of course, the existing product that is closest to already having this is
>jBase...
If the topic is database migration and not so much BASIC code
migration, let's not write off ONware which specializes in this sort
of thing. We have some new relational talent here at Nebula and I'm
very keen on the idea of helping VARs port their software to ONware to
open themselves to Oracle and SQL Server shops.
http://www.REMOVETHISongroup.com/web/default.asp?page=2662
(Inquiries are most welcome.)
>... of course, if jBase did this, then they would be admitting
>defeat for the multi-value model and cutting off their future revenue
>stream....
Unfortunately for this reason it will be impossible to get
collaboration from Any of the MV providers.
>Maybe IBM will do something to assist in the conversion of U2 to DB2.....
I don't think that's in their game plan anymore. I hear U2 accounts
for 40% of their DB revenue these days. If that trend continues,
what's to stop IBM from eventually offering DB2 to U2 conversion
assistance? Go Suzie!
>I believe that the concept is more than possible.... I don't know how
>large the potential market for such a tool actually is...
My knee-jerk reaction is that the market would be immense.
Dove-tailing with another thread here though, I think it's more
realistic that the market could also be very small because Pick people
are just so comfortable with their BASIC code and multivalues. :(
T
Bob Coleman/PDX OR
don't care what language you use with jBASE, as long as you are using jBASE.
-Bob Coleman/PDX OR
"Simon Verona" <ne...@aphroditeuk.com> wrote in message
news:41d51a2a$0$48102$ed26...@ptn-nntp-reader02.plus.net...
> Tony,
>
<snip />
___cliff rayman___
>The problem is the conversion of the database to relational. As you say,
>the MV Data Dictionary is largely useless in an automated process - all the
>files will need manual mapping. With a good data schema the conversion of
>
>
>
>
herein lies the biggest problem with the database system
we like so much. there are data relationships not
properly spelled out within the database. having to
look at all the programs to see how the data is used,
in order to map relationships, is the biggest weakness
in the system.
the second biggest weakness, is using positional numbers
instead of names to obtain the values in an item.
i don't think there is much wrong with databasic. remember,
our programs tend to be much smaller than the ones written
in java, c, or c++. there are lots of features in
those languages designed to deal with the large size and
complexities of the program, that are non-issues for us.
--
_____cliff_rayman_____cliff_@_rayman_._com_____
Luke Webber
> "Simon Verona" <ne...@aphroditeuk.com> wrote:
> [major snippage]
>
>>Out of interest, i describe vb.net as the language of choice... CDP'ers will
>>know that I am a big fan of vb.net, though Java may need to be an
>>alternative.
>
> Since we're off the wall anyway... :)
> I would look at a project like this with the same eye as for GUI
> development, divorcing the business rules from the UI. Conversion
> From BASIC is one exercise and conversion To another language is
> another exercise which should be done through a wrapper so that we can
> have more than one target language. Same goes for the database - not
> all relational databases are the same.
But there really is no need for more than one language. The main thing
is to make sure that it's a capable, modern language which will be
around for at least a couple of decades, and preferably more. [1]
The problem? If you're going to rewrite the code, you might as well
redesign the database whil you're at it. And if you're going to redesign
the database, why not target a mainstream database which might get you
more sales *and* increase your slice of the total sale dollars as well.
Seriously, if you're writing in Java or VB/VB.NET, what's to stop you
from jumping ship entirely? Given the cost of MV licenses, you're mad if
you don't. I think we all know the turnoff factor that comes from
supporting less-than-mainstream databases. The client asks what the
database is, because they're running SQL Server and Oracle systems
alread. You tell them "D3". Sorry chum, that doesn't fit our strategy.
Of course, this isn't what a lot of you guys want to hear, but it's
definitely something that has to be considered.
Luke
[1] Of course, I also believe that the language needs to be
cross-platform, but that's a particular bugbear of mine.
CWNoah2
Finally got time to reply to this. The philosophy may not be Pick, but the
power and capabilities certainly are, and a lot more. I tend to treat Jbase
like Pick, and it usually only bites me when I push the envelope really hard.
We compile and catalog on a live system, with few exceptions (commons being
one), and have a lot of inherited code from the 80s that is as embedded as what
you describe. It works, but is as much a pain (but not more) than it was on
other platforms.
1) Who cares?
2) I'd need examples to comment.
3) We don't use tapes in applications - only backup.
4) We're not going to change Chandru's mind - oh, well...
5) Better yet, ask Henry Ford ;^).
All this boils down to my opinion (yeah, I know) that Jbase is "da bomb", and I
wouldn't want to go back to anything else, ever.
Have a wonderful and blessed new year,
Charlie Noah
Charlie Noah (CWN...@aol.com)
Luke Webber
> My long term utopia is to be able to convert my DataBasic Code to Visual
> Basic.Net, with some way of converting the MV data structures to standard
> SQL. This is going the opposite way to what you Tony describes.
>
> The conversion of Databasic itself to vb.net isn't actually that difficult,
> providing a library is written to handle the "pick" functions - jBase does
> something similar in it's conversion to C for native compilation. Ideally
> though, unlike jBase's conversion to C, the conversion to VB.net should be a
> once off conversion which then can be maintained in VB.net afterwards.
>
> It's the data storage that becomes the problem... You could simply create
> sql tables that have fields called "att1" "att2" "att3" etc, with
> multivalues linked in a sub table with fields called att_no, Val_no,
> SubValue_No etc...
>
> But if you do this, you've lost some of the usefulness of switching to a
> relational database! Your data isn't really relational at all so you can't
> easily use SQL on it at all... So, I guess some sort of Conversion mapping
> for the datatable for relational use could be made (similar to the mapping
> that is already used for SQL access to MV data) which could then be used to
> a) map the data, as well as b) migrate the <amc,vmc> syntax to use the new
> field names.... I guess this is possible but there are a number of really
> difficult issues (such as dynamic file opening where the filename is a
> variable....)...
I went through a lot of this pain when I was writing a jEDI generator
for CSC Health. It never got to market, because CSC were bought out, but
the fundamentals were there. It would probably always be less than
ideal, but there were people who wanted to run the app over
Oracle/Sybase DBMSs, and the CSC were willing to pay to get there.
Still, as I've said, I don't really want to go there any more.
Programming in Java, I'd be shooting myself in the foot if I wedded
myself to MV structures.
Luke