We are migrating a client from mvBASE to D3 NT and we are unable to get
a compatible account save. Does anyone know the account save options
necessary to create a psuedo save on mvBASE that can be restored on our
D3 NT system?

Thanks.

<j.carroll (AT) earthlink (DOT) net> wrote

Have you tried using the 'C' option on your save?

<syntax> SAVE SYSTEM MYACCOUNT (TYC </syntax>
Where: 'T'=tape (virtual or otherwise), 'Y'=test for GFEs (good idea),
'C'=bkwd Compatible (R83).

Also recommend using a virtual tape and then reading it from the D3 server
directly, or moving it to the D3 server and reading it locally. Assuming
you are moving fairly generic logic along with your data note the following:
$INCLUDE becomes INCLUDE etc - SEND/GET becomes INPUT,0 - forget about
standard COMMON, use named COMMON instead (trivial.) Those were the ones I
remember from the last one I did back in the dark ages, I'm sure you'll find
others, YMMV.

BTW - using T-DUMP works too, but moving the dict and data separately is a
real PITA at both ends.

BFaux (not afta)

nods to some high-priests of pickdom: M Brown, C Murthi, J 'frosty' Trankler
(sic?)

"newsguy" <newsguy (AT) prodigy (DOT) com> wrote

I don't know so much about high priest as maybe Grand Dragon, but in either
case I left my sheet at home.

$include works on D3, as does GET/SEND.

I'm not sure the advise about named commons is so good either. Standard
common stays around for the life of the application, named common lasts as
long as the user does. Sometimes that's good, sometimes, as with lists, it
can leave unused data lying around.

I'd be more interested in the facts surronding the statement about
"compatible account save". IIRC, mvBase is advanced R83. There shouldn't
be anything incompatible in that direction. What's the actual error that
you get when you try to restore?

Mark Brown

Mark -
(was newsguy)
The thing we encountered seemed to be from the Mentor implementation of 2K
frame sizes in their 'native' save process. The good folks in Happauge
added the 'C' option so that we could move accounts from pre-3.0 Mentor to
post 3.0 mentor. Using that option solved some other problems we had
transferring later accounts to D3, but those were all older (much older)
versions.

Of course the $Include is there now as well as send/get but the send/get
functions didn't work exactly the same at the time, haven't checked since
they all got ported over, no point. The named common thing came about from
a stability problem that was traced to the common block, changing it to
named common on the D3 machines made it more robust and didn't seem to break
the app so we left it alone...been some years now its still working fine.

Don't know the exact requirements of the original poster (need to move
entire accts in mass, separate files in pieces...), just thought I'd toss
the 'C' option in there as a possibility. The first throw on porting the
code would of course be to try compiling and deal with the bombs.

Didn't mean to imply knowledge beyond by place, (on my knees and bowing
three times to the monitor) please forgive me oh yea of the flaming
breath...

BFaux (not afta)

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

Hey wait a minute... aren't both of these (D3 and mvBase) RD products now?
When we did it GA was still around. Isn't there some kind of published
method to do this easily? Gotta be...

-B

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

"B Faux" wrote
suitable for giving as high school graduation presents to get kids hooked on
D3 rdbms later? I'm glad to hear it has virtual tapes, if it's intended users will
eventually graduate to a more capable flavor...

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
"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

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.



Mark Brown wrote:

"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote
ditto...
BFaux

<j.carroll (AT) earthlink (DOT) net> wrote


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