If I have a save tape from D3/NT, but forgot to cut it with the (A
option, is it unusable on my D3/Linux box? In the past I've just
recut the tape, but I've been curious if there's another solution to
restore those pesky FSI:-dwelling accounts from the tape...

Frank:

I believe the tape is unusable on D3Linux. :-(

Bill

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

"Bill H" wrote
strip the FSI: prefix from the accounts/files being pulled off the tape...

I don't think I've seen this level of interproduct incompatibility in their
software line since AP/DOS went away.

"Frank Winans" wrote:

Frank, the save process for D3NT has been the same since the product
came out about 9 years ago. Maybe you personally haven't seen this
but it's something that others see all the time and it's not generally
a problem. A typical site won't be moving data between platforms.
Anyone who knows there is a chance that they will be moving data
should just save with the proper format - hit those two extra keys
"(A". It's not a big deal and not odd at all that no change has been
made in this area.

If you don't like the file-save the way it is, the souce is in dm,bp,
and you're free to take the 2 minutes to change it to always save with
the A option which will give you exactly what you want. Isn't Open
Source great?!

T

"Tony Gravagno" wrote
{no questions, and sorts account names in the select list}.

I can't change the command run, or tell the user how to do it, since
the customer just barely cares if we can read their tape, and are
clueless about platform incompatibility anyway. Their attitude is that
a backup is a backup, and if it's good enough for them then it's good
enough for us. We've a vast pool of customers, but they only contact
us about every seven years, so I don't get to customize their system
commands to suit myself. My boss is also unhelpful in asking me to
survey these tapes on our d3/linux server in the first place. I end up
grabbing a d3/nt server undergoing final assembly to suck and recut
the tape. The restore routines aren't open source, and are probably
assembler anyway. I'm just about half tempted to simulate them for
maintenance chores like this, though.

"Frank Winans" wrote:
Many years ago a change was made to the D3 file-save program to select
the eligible accounts and then put the dm account at the top of the
list. Let's assume you have dm as account number 15 of 25 just
because all of your data accounts are named client01, client02, etc.
If you try to restore and there is corruption in one of the data
accounts, you don't have a dm account on the system to attempt
recovery. So for your purposes Frank, I recommend doing the same.
Something like:
***************************
sel = \select mds,, not "dm" with a1\
sel := \ "d]" "qs]" and not "[x]"\
execute sel returning mds
mds = "dm":@am:mds
execute \save flsdt\ :@am: mds
***************************
Note, I just scribbled that code out and didn't check it for syntax.

Understanding your scenario I'm more inclined to agree that a common
save method would be nice. I'll just repeat the mantra - if you have
a requirement, contact your vendor. If you bring this to RD now
they'll probably say the feature is available in the upcoming D3 v7.5.
I recommend registering for the beta.

For now it sounds to me like your FSI:VME issue is partially a lack of
rapport with the customer base. This is as much a procedural issue as
it is technical.

This comment particularly bothers me:
I'll resist from making comments about nails in the MV coffin (oops,
too late!) and just encourage some pro-active customer relations.

T

On Thu, 26 Jan 2006 19:55:20 -0800, Tony Gravagno
<g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

Perhaps "this one" instead of "they"?


Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

Hi Tony,
<snip>

Haven't had time to even check in here lately but this news made it
worthwhile! Has D3 Linux been released as Open Source as well or only
D3NT? Very interesting development in any case. Where are downloads
available?
-Tom

I don't think that Tony was referring to D3 being "Open-source" but
specifically referring to the fact that the source for the FILE-SAVE proc
was available to be modified in D3... Hence "open-source"...

Regards
Simon
"Tom deL" <ted (AT) blackflute (DOT) com> wrote

Simon is correct. That was a tongue-in-cheek remark. For the last
year I've seen non-MV business application software being touted in
magazines as Open Source with this model:
- For a fee starting at $15000 the end-user gets the entire
application complete with source.
- The software is under license for a single server and cannot be
distributed.
- All changes made by the end-user to their copy of the source must go
back to the vendor and become the property of the vendor.
- For-fee customization is of course available.

It seems this is the same model that's been used by most MV VARs for
about 25 years but without the restriction that all mods must go back
to the vendor. MV developers tend to assume (rightfully so) that
end-users aren't going to pass their source to any other Pick shops.
And even with the source on-site, for decades end-users have been
quite happy to pay VARs to customize their code.

I've mentioned this trend in this forum before but MV VARs don't seem
interested in taking advantage of the Open Source marketing spin. Of
course we all know this isn't GPL, but the source _is_ open for the
end-users, which is all the average business owner is looking for
these days - and better than keeping the source in escrow. So who
cares how "open" it is? If an end-user agrees to terms (whether an MV
VAR's or one of the 20+ open source licenses) then for all intents and
purposes all of this code is equally Open Source. Another way to
phrase all this is that Open Source does not really imply the GPL or
similar licenses, even though many people tend to think or assume that
it does.

In the case of D3, the dm,bp file does have copyright notices and the
software can't be sold, but VARs and end-users are certainly free to
enhance the code and share it among other licensed D3 users without
returning the source back to RD. This is something else that people
don't seem to want to take advantage of. Many bugs people talk about
in these forums are easily fixed by hacking the code they have on
their own systems. But what's consistent is that as people expect the
DBMS vendors to provide source which pleases everyone, many of the
same people tend to expect a Linux Distro to have everything they want
too. Open Source really has nothing to do with it - which is why I
always tend to approach this topic with such a sense of irony.

T

"Simon Verona" wrote: