jBASE to QM

51 views
Skip to first unread message

Rick Weiser

unread,
Dec 18, 2009, 5:17:03 PM12/18/09
to OpenQM
Has anyone moved a jBASE account to QM (both Windows)?

Will a jBASE account-save work on QM?

Thanks for your time,

Rick

Fred Waltman

unread,
Dec 18, 2009, 5:50:09 PM12/18/09
to ope...@googlegroups.com
I did one a few years ago. I don't remember how I transferred the
data, though (sorry). I usually use AccuTerm or a program I have that
T-DUMPs an account. In any case it wasn't a big deal.

The only snags I remember were Indexes and shelling out to windows
(this application did a lot of that) but luckily both were pretty well
encapsulated in subroutines.

I switched the user because his server was dying and jBase wanted
nearly $1500 to move a 3 user license to a new machine (they had let
support lapse). I guess printers could have been a problem but all of
their printed output was PDF using HTMLDOC.

Fred.

Dave Taylor

unread,
Dec 18, 2009, 9:05:34 PM12/18/09
to Rick Weiser, OpenQM
Hi Rick,

Attached is the "Converting Applications to Open QM" document from
Ladybridge Systems with examples of ACCOUNT.RESTORE options for several
source databases - including jBase - on pg. 21.

There is also a QMSAVE program that comes in specific flavors - eg
QMSAVE.MVB to create a save on an mvBase machine that the QMRESTORE command
can read and process.

You might ask Martin Phillips if he has a version of QMSAVE for jBase.

Of course, you can always use Accuterm to transfer one file at a time - if
that meets your needs.

And, finally, we developed two programs - TAPE.DUMP and TAPE.LOAD - which
dumps up to all the dictionary and data files on an account in the source
database, including the MD of the account, in a series of T-DUMPs, and then
loads all of the T-DUMPs on the tape into the target database, creating each
file section as it goes if it doesn't exist using data that we load into the
label of the T-DUMP.

The TAPE.DUMP program will have to have the jBase syntax added to it, but
otherwise they should work.

Martin's only comment to me some time ago regarding T-DUMPs is that they do
not store text-marks, so this can be a problem if text-marks are used in the
database.

Of course, no helping hand would be complete without a small sales pitch.

Without being critical of QM, because I do think that it's a fine database,
it does not support the generic Pick (including jBase) print management
systems, architecture, commands, syntax. etc. In fact, it doesn't have a
generic Pick print spooler or queues to which to assign both print jobs and
printers to get the one printed on the other or to switch a print job from
one to another.

To Martin's credit, however, he has added some commands - eg SP-ASSIGN -
that looks and kind of feels like the Pick SP-ASSIGN command - which creates
a SETPTR command to print directly to the printer (which is named like a
queue).

Other commands however, like the Pick SP-ASSIGN, SP-EDIT, LISTPEQS, etc.,
and their functionality are missing. This, however, may work for you, and
it's certainly worth a look.

If you want a complete generic Pick print spooler so that jBase software
prints on QM like it does on jBase without any modification, we are pleased
to offer SpoolerPlus, our generic Pick print spooler for Universe, Unidata
and QM, including extensions to support the Reality syntax on critical
commands.

SpoolerPlus creates a spooler file and supports the spooler commands and
functionality that you're used to using in jBase.

It also includes a function to automatically reconfigure your printers to
the print characteristics of the queue when you assign any printer to any
queue.

And, LISTPEQS allows you to scroll up and down among all the print jobs in
the spooler without having to start over at the top to review the print
jobs.

If any of this interests you, let me know and I'll be glad to provide you
whatever additional information you need to make a choice.

I'm sure you'll like QM and the outstanding support provided by Martin
Phillips and by the others on this listserv group.

Happy Holidays,

Dave

Dave Taylor
Sysmark Information Systems, Inc.
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com

> --
>
> You received this message because you are subscribed to the Google Groups
> "OpenQM" group.
> To post to this group, send an email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to
> openqm+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/openqm?hl=en-GB.
>
>
>

conversion.pdf

Bob Joslyn

unread,
Dec 19, 2009, 3:47:04 AM12/19/09
to ope...@googlegroups.com, ri...@designbais.com
Top posted on purpose.  You already know the subject.
 
The save and restore options mentioned each have some warts.  They can be cured but they need to be cured.  The Text Mark is one, of course. Others include ID length, characters legal in the ID of some flavors but not others, and probably a few more.  If you have any significant amount of data then time itself becomes a wart.  Accuterm does a pretty good job of moving files from one flavor to another but it's not too speedy.  The fastest transfer requires some programming.  Use Openseq/Writeseq or its equivisent on the source system (prepending the Item ID to the body of the record before write) and Openseq/Readseq or its equivisent on the target.  If the target is QM then use OnError as well as Else when you read.  The OpenSeq will take the Else clause if the OS file does not exist but the file will be created.  The command System() will return an error code of zero in this case effectively telling you that the "error" was corrected.  The "OnError" clause will effectively bypass any records with item id's that are not acceptable to QM.  This is significantly faster than using the OS hashing if the files are large.  On a modest sized system with a few million items the convert time using the OpenSeq method reduced from many hours to about an hour.
 
I haven't used the mentioned spooler product because I'm not a fan of the Pick approach to printing anyway.  But for people who like that sort of thing, that"s the sort of thing that they like. (Quote from Abe Lincoln) There are tools available in QM to manage any printing task but they also require a little programming.  But isn't that what we do?
 
If you get heartburn from any of this, Martin always seems to find time to answer any question.  His motto seems to be that the only dumb question is the one you don't ask.
 
BobJ - A programmer in a former life.

Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
Reply all
Reply to author
Forward
0 new messages