Discussion:
Old dbase III Plus Program - Query about Clipper
(too old to reply)
f***@gmail.com
2017-04-09 06:34:23 UTC
Permalink
I've been helping a local company maintain a dBase III Plus program for quite some time now. Every year it needs maintenance because it was badly configured. That's job security, sure, but the programmer in me wants to turn 'updating this' into a project.

The version of clipper this is working with is... old. Specifically, "The Clipper Compiler, Summer '87". So before CA even got a hold of it, or it got a version number.

Although I attempted to peruse through Harbor and xHarbour documentation, the clipper language has clearly evolved heavily from what this was written in and I don't know where to start.

I've been looking for an IRC channel or any kind of chat room where Clipper devs hang out... and all I've found is this forum.

My question is... really, where should I start? I have several options. One is trying to use the existing code but modernize it with something like xHarbour - if I can figure out just how to do that. Another is to code up a facsimile using something like PyQt... or I can just leave it as it is.

But not understanding all of my options really frustrates me. Just how spectacularly different is a 'modern' Clipper program from one written in the 80s?
Johan Nel
2017-04-09 07:45:18 UTC
Permalink
Hi,

As you indicated, yes [x]Harbour is probably your closest bet to make
this work.

However you should also look at how the xBase environment changed over
30 years....

1. CA-Clipper was replaced by Visual Objects, Win32 based. [x]Harbour
was also based on Clipper 5 and has survived.
2. Visual Objects was replaced by Vulcan.NET.
3. XSharp based on the Roslyn c# open source compiler is now 2 years old

I think what you really need to ask is where you want to take this
application to.

If you want to modernize it, then you will have to rewrite the
front-end. Business logic if encapsulated in functions should be
relatively easy to port to any of the "modern" XBase languages.

My suggestion would be to look at XSharp http://www.xsharp.info it is a
.NET compliant XBase language that is comparing well will c# and VB.NET
in what it can do, but still have the familiar XBase syntax.

Regards,
Post by f***@gmail.com
I've been helping a local company maintain a dBase III Plus program for quite some time now. Every year it needs maintenance because it was badly configured. That's job security, sure, but the programmer in me wants to turn 'updating this' into a project.
The version of clipper this is working with is... old. Specifically, "The Clipper Compiler, Summer '87". So before CA even got a hold of it, or it got a version number.
Although I attempted to peruse through Harbor and xHarbour documentation, the clipper language has clearly evolved heavily from what this was written in and I don't know where to start.
I've been looking for an IRC channel or any kind of chat room where Clipper devs hang out... and all I've found is this forum.
My question is... really, where should I start? I have several options. One is trying to use the existing code but modernize it with something like xHarbour - if I can figure out just how to do that. Another is to code up a facsimile using something like PyQt... or I can just leave it as it is.
But not understanding all of my options really frustrates me. Just how spectacularly different is a 'modern' Clipper program from one written in the 80s?
--
*Johan Nel*
George, South Africa


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Enrico Maria Giordano
2017-04-09 08:35:40 UTC
Permalink
Post by f***@gmail.com
Although I attempted to peruse through Harbor and xHarbour
documentation, the clipper language has clearly evolved heavily from
what this was written in and I don't know where to start.
If you want help on xHarbour please use comp.lang.xharbour newsgroup.

EMG

--
http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg
Thomas Orgelmacher
2017-04-09 12:35:56 UTC
Permalink
Post by f***@gmail.com
I've been helping a local company maintain a dBase III Plus program for quite
some time now. Every year it needs maintenance because it was badly
configured. That's job security, sure, but the programmer in me wants to turn
'updating this' into a project.
The version of clipper this is working with is... old. Specifically, "The
Clipper Compiler, Summer '87". So before CA even got a hold of it, or it got
a version number.
Although I attempted to peruse through Harbor and xHarbour documentation, the
clipper language has clearly evolved heavily from what this was written in
and I don't know where to start.
I usually try to get the existig code-base compile- and runnable
and then I clean up the code, modernize, refactor or whatever.

The last thing I did with Harbour was porting 1,5 million lines of code from
Clipper 5.2 to Harbour on Linux. And it was surprisingly easy (10, maybe 12
hours).

About how many lines of code are you talking?

In the end, it depends on you and the existig code. Is the company willing
to pay you for the work? Are the really no alternatives to the existig
software?


Gruß, Thomas
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
Mr. Man-wai Chang
2017-04-09 14:03:43 UTC
Permalink
Post by f***@gmail.com
I've been helping a local company maintain a dBase III Plus program for quite some time now. Every year it needs maintenance because it was badly configured. That's job security, sure, but the programmer in me wants to turn 'updating this' into a project.
....
My question is... really, where should I start? I have several options. One is trying to use the existing code but modernize it with something like xHarbour - if I can figure out just how to do that. Another is to code up a facsimile using something like PyQt... or I can just leave it as it is.
Is it a standalone application? With Netware networking?
Do you want to keep the console mode text-based interface?
Maybe you should just rewrite it in Visual Basic, if not PHP+MySQL?
Visual Foxpro is another solution, though the product was discontinued.
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
dlzc
2017-04-09 14:57:43 UTC
Permalink
Post by f***@gmail.com
I've been helping a local company maintain a
dBase III Plus program for quite some time now.
Every year it needs maintenance because it was
badly configured. That's job security, sure, but
the programmer in me wants to turn 'updating this'
into a project.
The version of clipper this is working with is...
old. Specifically, "The Clipper Compiler, Summer
'87". So before CA even got a hold of it, or it got
a version number.
Then you are running Clipper S'87 code, with dBase III+, or you have compiled it and running it as S'87?
Post by f***@gmail.com
Although I attempted to peruse through Harbor and
xHarbour documentation, the clipper language has
clearly evolved heavily from what this was written
in and I don't know where to start.
Install a compiler, and make a simple "Hello World" program. Get that to run. Look on www.xharbour.org for the xHarbour package.

Copy all your source to another directory, where you will work. DO NOT work on your working source.

Just try and compile your original source. Look for classes of errors, things that you can change with a find-and-replace.

But this carries your existing errors forward...
Post by f***@gmail.com
I've been looking for an IRC channel or any kind of
chat room where Clipper devs hang out... and all I've
found is this forum.
Clipper has retired. Branched to Clipper 5.x, then Visual Objects. About the time Visual Objects arose, Harbour, then xHarbour arose from Clipper 5.3 compatibility. Visual Objects branched to Vulcan and some variants. Current effort is on X#, which uses Windoze IDE.

Clipper S'87 was largely command based (no return code), rather than function based. Some of the basic commands were "deprecated" by Clipper 5.3, so you will likely have some work there.
Post by f***@gmail.com
My question is... really, where should I start?
I'd choose a current language, one you already know, and build the functionality up from there. Got any other programming experience?
Post by f***@gmail.com
Another is to code up a facsimile using something like
PyQt... or I can just leave it as it is.
But not understanding all of my options really
frustrates me. Just how spectacularly different is a
'modern' Clipper program from one written in the 80s?
It turned into C, then got dragged into the Windoze world with different Windows "adders".

What frustrates you, I suspect, is that you really don't want to recode this application, from the ground up, to find and fix the current errors. But you cannot justify the time involved.

David A. Smith
Mr. Man-wai Chang
2017-04-11 07:46:32 UTC
Permalink
Post by f***@gmail.com
My question is... really, where should I start? I have several options. One is trying to use the existing code but modernize it with something like xHarbour - if I can figure out just how to do that. Another is to code up a facsimile using something like PyQt... or I can just leave it as it is.
But not understanding all of my options really frustrates me. Just how spectacularly different is a 'modern' Clipper program from one written in the 80s?
BTW, whatever you wanna do next, BACKUP the original source codes!
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
Otto Christiaanse
2017-04-11 09:56:40 UTC
Permalink
Post by Mr. Man-wai Chang
BTW, whatever you wanna do next, BACKUP the original source codes!
That's the least. Should use a Source Code Control program, whatever you do.
What system do you use?
Mr. Man-wai Chang
2017-04-12 15:28:40 UTC
Permalink
Post by Otto Christiaanse
Post by Mr. Man-wai Chang
BTW, whatever you wanna do next, BACKUP the original source codes!
That's the least. Should use a Source Code Control program, whatever you do.
What system do you use?
I have never needed any source code control programs. Just plain simple
data compression tools and drag-and-drop. :)
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
Otto Christiaanse
2017-04-18 09:02:02 UTC
Permalink
Post by Mr. Man-wai Chang
Post by Otto Christiaanse
Post by Mr. Man-wai Chang
BTW, whatever you wanna do next, BACKUP the original source codes!
That's the least. Should use a Source Code Control program, whatever you do.
What system do you use?
I have never needed any source code control programs. Just plain simple
data compression tools and drag-and-drop. :)
We did that for a while but when our team got bigger (>2 on the same product) and the requirements for tracking and tracing of our changes grew, that wasn't enough for us. Especially as the request for changes got numerous.

Regards,
Otto
dlzc
2017-04-18 14:04:36 UTC
Permalink
...
Post by Otto Christiaanse
Post by Mr. Man-wai Chang
I have never needed any source code control
programs. Just plain simple data compression
tools and drag-and-drop. :)
We did that for a while but when our team got
bigger (>2 on the same product) and the
requirements for tracking and tracing of our
changes grew, that wasn't enough for us.
Especially as the request for changes got
numerous.
Oh, sure! Get professional and everything!

The OP is maintaining an old Clipper S'87 (or dBase III+) program suite. Likely by him/herself.

Keeping the originals in one directory / zip file, backed up, should be the minimum requirement.

Then a separate directory, with extensive notes as to what the changes are, for each version you end up pushing out to the field.

But frankly, the OP needs to go to a different programming platform, something that will get him current, salable experience. Have you ever heard of "PyQt" (what he/she mentioned), or seen it on resumes you might have reviewed?

David A. Smith
Mr. Man-wai Chang
2017-04-18 16:11:28 UTC
Permalink
Post by dlzc
Oh, sure! Get professional and everything!
It's not about professionalism. It's how you divide the work.
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
dlzc
2017-04-18 19:52:52 UTC
Permalink
Post by Mr. Man-wai Chang
Post by dlzc
Oh, sure! Get professional and everything!
It's not about professionalism. It's how you
divide the work.
Which itself requires professionalism, and encapsulation. Just does not require separate tools to achieve solid, repeatable results.

And I was being facetious...

David A. Smith
Otto Christiaanse
2017-04-19 08:51:37 UTC
Permalink
Post by dlzc
Oh, sure! Get professional and everything!
The OP is maintaining an old Clipper S'87 (or dBase III+) program suite. Likely by him/herself.
Keeping the originals in one directory / zip file, backed up, should be the minimum requirement.
Then a separate directory, with extensive notes as to what the changes are, for each version you end up pushing out to the field.
But frankly, the OP needs to go to a different programming platform, something that will get him current, salable experience. Have you ever heard of "PyQt" (what he/she mentioned), or seen it on resumes you might have reviewed?
Eh, nope. Sorry. But then again, I'm not in the Python edge. (And summer '87, I've not used it ever myself. When I started working with Clipper in 1997, the last source was just converted to 5.2)

The conversion to a new platform is always a troublesome task, not only because of possible paradigma shifts, but also because of the money involved. And it is helpful if you know the tech you want to move to...

Paying off the technological debt is better done along the whole lifetime of an application instead of in one sweep wtshtf, especially when there is much maintenance needed like the OP stated.

Rewrite piece by piece, maybe keeping (parts of) the business logic is sometimes the better investment.
Mr. Man-wai Chang
2017-04-18 16:10:39 UTC
Permalink
Post by Otto Christiaanse
We did that for a while but when our team got bigger (>2 on the same product) and the requirements for tracking and tracing of our changes grew, that wasn't enough for us. Especially as the request for changes got numerous.
If each program fragment (xxx.PRG) was small enough and was always
handled by one programmer, then there would no contention, saving the
need to use source code control tools.
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
Otto Christiaanse
2017-05-11 18:09:36 UTC
Permalink
Post by f***@gmail.com
I don't know where to start.
Let us know what you do or think. Maybe we can give you additional pointers.

We are all on the same road somewhere :)
Regards,
Otto
Geoff Barnard
2017-06-03 20:16:47 UTC
Permalink
First of all, are you doing this for YOUR benefit, or for the customer's?
Are you sure that your customer WANTS their software messed with too much.
They might not.

Until very recently, I was still maintaining some Clipper S.87 systems. I
have two systems still being used (I think) but customer doesn't pay, so I'm
not counting them as 'maintained'. They are probably still 'live' systems
though. I have the S.87 manual here. And all their source code, so I
could change/recompile whenever required.

I would suggest that a S.87 applic could be re-built as a Harbour console
mode applic, so it would still look the same. As you get used to the
environment, gradually re-work sections of the code, converting to a (more
?) WinDoze based system, assuming your customer is happy with that.

Geoff
<***@gmail.com> wrote in message news:c51e8153-5b55-4250-b328-***@googlegroups.com...
I've been helping a local company maintain a dBase III Plus program for
quite some time now. Every year it needs maintenance because it was badly
configured. That's job security, sure, but the programmer in me wants to
turn 'updating this' into a project.

The version of clipper this is working with is... old. Specifically, "The
Clipper Compiler, Summer '87". So before CA even got a hold of it, or it got
a version number.

Although I attempted to peruse through Harbor and xHarbour documentation,
the clipper language has clearly evolved heavily from what this was written
in and I don't know where to start.

I've been looking for an IRC channel or any kind of chat room where Clipper
devs hang out... and all I've found is this forum.

My question is... really, where should I start? I have several options. One
is trying to use the existing code but modernize it with something like
xHarbour - if I can figure out just how to do that. Another is to code up a
facsimile using something like PyQt... or I can just leave it as it is.

But not understanding all of my options really frustrates me. Just how
spectacularly different is a 'modern' Clipper program from one written in
the 80s?

Loading...