migrate to D3 from mvBASE

#11

j.carroll (AT) earthlink (DOT) net wrote:

Quote:

The first time we tried to restore the data on D3 was from an mvBASE
file save but D3 could not find the accounts. T-RDLBL would not find
any tape labels but even the ACCOUNT-RESTORE xxx (A would not work (we
were prompted to insert the next tape).

RD support advised us that there was a compatibility error and D3 could
not restore the accounts. So we gave up on reading the tape and tried
to find other ways of saving the accounts. They gave us the mvBASE
command SAVE SYSTEM SYSTEM (FTDYC and we decided to use a virtual tape
so we could send the file save via the internet.

We setup a virtual tape and used the RD commands but we get 2 error
messages during the file save:
1) incompatible item type: XXX in file# nnn - (not fatal)
2) DEVICE NOT READY <crlf> CONTINUE/QUIT (C/Q)?

I can't tell if the virtual tape setup is bad or if the file save
command is bad and I'm not certain I could restore the acounts if this
succeeds.

The device not ready message seems unusual. I assume you've taken the
basic steps in setting up the vtf:

T-STATUS (check all the tape units)
T-SELECT 5 (select tape unit 5)
SET-TAPEFILE C:\Temp\FileSave.vtf (define the vtf)
T-ONLINE (put the tape online)

put your save command here

T-REW
T-DET

Cheers,

Brian Speirs
brian at rushflat dot co dot nz

#12

Well, that's great. Seeing as how mvBase is a dead-end product, like R83,
it might behoove you to get off that product to either D3 or some other
mvDbms.

Just my $.02. :-)

Bill

"B Faux" <bdfaux (AT) prodigy (DOT) com> wrote

Quote:

"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote
For character applications, mvBASE is probably one of the best
implementations of multi-value on Windows. Granted, it runs out of steam
when you move beyond the legacy green screen application, but that
probably has more to say about lack of development first by GA, and then
by RD.

I for one remember fondly my days with the "mentor" products, going back
to Mentor 1.9 in 1984!

Regards
Simon

ditto...
BFaux

#13

Thanks for the 2 cents...

You are correct, mvBase was great for legacy multivalue apps., but doesn't
really stand up against the "current" multi-value products.

Personally, we migrated to jBase several years ago... and haven't really
looked back..

What is amusing though, is that until recently (literally the past couple of
weeks) we actively developed our application on mvBASE and recompiled on
jBase for release.... To be totallty honest, there is nothing really that
we do with jBase today (including running our .net based windows front end)
that we couldn't also have done with mvBASE.... Quite ironic really.

The one thing I remember most fondly about mvBASE was it's stability. It
would just run forever with little or no maintenance... Installation and
configuration was simple. I never really felt (though i've never used D3 in
anger) that D3 has ever been as stable on a Windows platform.

regards
Simon

"Bill H" <notme (AT) bogus (DOT) com> wrote

Quote:

Well, that's great. Seeing as how mvBase is a dead-end product, like R83,
it might behoove you to get off that product to either D3 or some other
mvDbms.

Just my $.02. :-)

Bill

"B Faux" <bdfaux (AT) prodigy (DOT) com> wrote in message
news:4W3ef.3792$p37.56 (AT) newssvr17 (DOT) news.prodigy.com...
"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote
For character applications, mvBASE is probably one of the best
implementations of multi-value on Windows. Granted, it runs out of
steam when you move beyond the legacy green screen application, but that
probably has more to say about lack of development first by GA, and then
by RD.

I for one remember fondly my days with the "mentor" products, going back
to Mentor 1.9 in 1984!

Regards
Simon

ditto...
BFaux

#14

Thanks for your input. It pointed me in the right direction.

My solution was to backup each account using ACCOUNT-SAVE xxx (C and
then restore each account using ACCOUNT-RESTORE xxx (A.

The message "DEVICE NOT READY (C/Q)?" appeared when the virtual tape
file exceeded 2 GB. Perhaps a file size limit of Windows NT 4.0? The
only other problem was the restores required a T-RDLBL to move past the
label otherwise the accounts could not be found.

B Faux wrote:

Quote:

j.carroll (AT) earthlink (DOT) net> wrote in message
news:1131986150.398476.198320 (AT) g44g2000cwa (DOT) googlegroups.com...
The first time we tried to restore the data on D3 was from an mvBASE
file save but D3 could not find the accounts. T-RDLBL would not find
any tape labels but even the ACCOUNT-RESTORE xxx (A would not work (we
were prompted to insert the next tape).

RD support advised us that there was a compatibility error and D3 could
not restore the accounts. So we gave up on reading the tape and tried
to find other ways of saving the accounts. They gave us the mvBASE
command SAVE SYSTEM SYSTEM (FTDYC and we decided to use a virtual tape
so we could send the file save via the internet.

We setup a virtual tape and used the RD commands but we get 2 error
messages during the file save:
1) incompatible item type: XXX in file# nnn - (not fatal)
2) DEVICE NOT READY <crlf> CONTINUE/QUIT (C/Q)?

I can't tell if the virtual tape setup is bad or if the file save
command is bad and I'm not certain I could restore the acounts if this
succeeds.
[snip]

I just tried the temporary virtual tape function in my old (ancient) mvBase
1.3 running on W2K server and it worked fine. For starters the option list
you are using could be shorter: 'D' does not equate in mvBase (used to mean
'data' but its not a supported option for the mvBase SAVE verb - check your
manual.) It shouldn't pose a problem tho' - Also the 'F' for file list is
only important if you like to see the files flash across the screen. This
will help however with diagnosing the errors you are getting.

1) Your incompatible item types are probably greater than 32K, these won't
play nicely with the mvBase virtual save (I think it works for the physical
media). Suggest you come up with a utility to break apart large items
(temporarily) and reconstruct them on the other end. We had this problem
with some large programs, but not data so it was only a small PITA. You can
check the item size with the editor using the 'S?' command or in DataBasic
with LEN(). I usually just dummy up the name, ex. program named 'PROG',
create PROG.TOP and PROG.BOT with neither the top part or the bottom part
being greater that 32K, of course you could go with PROG.1, PROG.2, ...if
its greater than 64K. Its got something to do with how the mvBase system
deals with 32K+ item lengths. GD Brown might be of help here (that's
'Grand Dragon' BTW) ;-)
xx
2) This 'Dev not ready...' msg is a bit of a mystery. There might be some
conflict using the full save technique which will attempt to store a version
of the SYSTEM fid list in a weird way at the end. Again maybe Mark could
shed some light here. You could try to save the accounts separately using
the 'SAVE SYSTEM MYACCOUNT (TYC' syntax for each account where 'MYACCOUNT"
is an actual account name. Also try starting with TWO 'T-REW' commands, yes
that's twice in a row, execute one and wait for TCL then execute the second.
Sometimes the tape buffer does strange things, this is probably not
necessary, but its harmless. Common best practices in MV world says you
should preface ALL tape operations with dual T-REW commands whether saving
or restoring (same goes for forcing a retension on cartridge tapes before
starting a save or restore, often done automatically by the database.)

At this point I would not suspect a problem with your virtual file, if
mvBase can't find it, it'll croak instantly. But on the restore side you
could try a 'T-FWD' command (or two) to push the buffer pointer past the
first file (which can usually be thrown away anyway.)

BFaux