I posted this message, earlier today, as a response to Tony G's
comments on a REVELATION subject. I decided to start a new topic,
using the same response to Tony, as I'm curious about other people's
feelings on this subject. Are there truly "significant" differences
with Reality and Cache, in relation to other (D3?) MV platforms, as
Tony suggests? Or, is this one of those "Beauty is in the eyes of
the beholder" topics?





Hello, Tony:

While reading over your posting to Rev's search for a developer, my
curiosity was raised by your mentioning of REALITY as “…significantly
different enough to preclude in-depth inquiry from any but the most
motivated prospects”. Having recently (April, 2010) converted from
D3/NT (rev 7.4.7) to REALITY (14.1) , and having to make few changes
to programs to get clean compiles, I’m wondering what you have in
mind
with that statement.


Much of our program library consists of packages originally written
in
the mid 1970’s. We also have a considerable number of programs
written to take advantage of nuances of Advanced PICK, as well as
D3. Admittedly, things like indexing and triggers (both of which we
have used to a great extent since the advent of both in A/P) are
approached differently, but neither of those proved difficult to
activate in REALITY. Case-insensitivty added to REALITY allowed me
to keep much of my lower-case programming intact.


For me, one of the most crucial aspects of even considering moving
off
of D3 was our extensive use of D3-API in VB(6) applications for our
retail firearms sales (capturing BATF requirements). At least at my
site, other MV vendors tried and failed to convert these apps;
REALITY
made every VB class work, in a relatively short span of time.
The other areas of concern when I was considering the move from D3,
to
“whatever MV would work”, were the ability to “easily” continue my
connectivity to disparate systems, particularly our POS system, and
our MySQL Linux Web Server. Again, those issues were tackled very
easily, and quickly.


Since I was a one-person programming staff for that conversion, I can
attest to every step involved in making the transition from D3-to-
REALITY. There were several weeks in mid-2009 that I “played” with
the REALITY tools. Serious conversion started, roughly, Oct. 1,
2009. We were live April 12, 2010.


Yes, I was (am) a “motivated prospect”, but I seriously doubt that
REALITY is “significantly different” than my previous PICK
implementation, D3/NT.


Jim Cronin
Kittery Trading Post

JJCSR wrote:

Jim - This is an excellent topic for discussion.

Without going too deep I'll toss out a short list of what adds up to
my definition of "significant":

- Option switches to change behaviors need to be set on a system
level, per-account, and/or per-user login. This tuning process can be
a challenge, and there are often post-production surprises.
- Spooler, Tape, and other Device management is different for every
platform. I'll include the Tandem command in here as well.
- BASIC often processes Equates and Common differently. Then of
course there are differences in indices and triggers, as you said.
- Some commands are different across platforms. One needs to
investigate options in things like CREATE.FILE vs CREATE-FILE, or
COPY. The TCL-I (AQL) commands are almost entirely compatible across
platforms, but TCL-II commands driven by programs often have nuances.

What's really different are the post-R83 extensions:
- XML
- Web services
- Sockets
- HTTP/FTP and any other supported protocols
- VB, Java, and other connectivity libraries

All of the platforms have their value-add features. On one hand, no
one can blame a company for introducing value-add. On the other hand
I'm simply saying this presents a (arguably) steep learning curve for
anyone migrating. Such features include:

- Hot-backup, journalling
- Security, passwords and encryptions
- Web development tools

In addition to supporting all MV functionality, Caché goes further to
support Caché Object Script (COS) and Caché BASIC (a pseudo derivative
of VBScript). It further supports a completely different DBMS model
based on Globals which are much more extensive than the MV model.

I'm not going into a lot of detail, just touching on some high level
items. The platforms are not that different for a sideways migration.
A successful migration to Caché would make use of its rich feature set
as described above. A successful migration to jBase would make use of
OS-level features and jEDI for cross-database usage. A successful
migration to OpenInsight would make use of the GUIs. A successful
migration to Reality would make use of security and web services, etc
etc. If all you're doing is replacing your vendor to maintain R83
compatibility, then you can pretty much go with any of the vendors.
But if you want to get more from your effort and start taking
advantage of everything that a new platform provides, you'll find that
most of the vendors offer pretty much the same features, but the
implementation details are "significantly" different, as can be
expected and which is reasonable.

It's that extra step required to get the real benefits from each
platform where I think most MV guys decide to stop looking beyond what
they have. When people get away from SSELECT and READV, which require
zero modification for a successful migration, they see all sorts of
funky syntax in things like COS, CallHTTP in U2, QMOO, or
I-descriptors. People glaze over, and the decision is usually made to
just stick with what's onsite. All I'm saying is that MV vendors need
to do a better job of making their value-add distinctiveness more
approachable so that they'll get more eyeball time with prospects and
heads nodding as the information sinks in. The more you can get
someone to flow with your paradigm before the sale, the more likely
you are to get the sale. And this is why I suggested that Revelation
(and the other MV vendors) should hire people from this MV community
who are well suited to keeping colleagues comfortable at that next
tier of the sales cycle.

IMO, what really distinguishes MV companies these days (or should) is
their positioning as solid business partners rather than simple
product vendors. Few companies seem to accept the role of true
partner. At the very least a real partner does Marketing to
strengthen the brand and eliminate perceptions of MV being old,
legacy, or like old DOS hierarchical files. Most of the MV vendors
don't even understand this concept, never mind having policies and
personnel in place to create a better environment for VARs selling MV.
In this way as well, some of these vendors are "significantly
different".

Regards,
T

Tony:

Thanks for the response. I follow your thoughts on the "significant
difference" issue.

I guess you could say we were, for the most part, a "sideways
migration". However, "fail safe" and "DR" were key issues I needed
to deal with. D3/NT could not do so at the level we were at (7.4.7),
so we are now positioned to start working towards implementing
failsafe and DR on REALITY/NT. Hardware and networking upgrades are
already underway.

Thanks again for your explanations.

Best regards,

Jim Cronin

On Jun 1, 2:25*pm, JJCSR <JCro... (AT) ktp (DOT) com> wrote:
Add to this:

FOR J = A TO B
blah blah
NEXT J

In some (D3), variable A and B are recalculated every loop, whereas in
others (UV) they are only calculated once.

Mike

Interesting topic sums up as the Bells and Whistles differ but the
heart is the same. TG has it about right and it is good to see why
the Trading Post changed , it had me wondering when they first did
it. Sound business decision. Personally I would like to see a decent
encryption algorithm to help with banking regulations, and yes it is
an engineering item that I have requested.
As we have seen from the restaurant disaster in earlier posts many
never went past first base but now it really is worth doing so.
I must disagree with this comment below however there always was an
entry in the manual that warned one not to do calculations in the FOR
part of a loop because they would have to be evaluated every time. So
the proper way wherever possible is
B = calculate something
FOR A = 1 TO B
do this
NEXT A
Is the most efficient way in any language there is no way to execute
the loop that does not involve incrementing A and comparing it to B.
Of course if one uses the Compile (o option the loop will be executed
at a very low and high speed level in C.
The current manual does give examples of times when this is not
possible and the WHILE is appropriate.
Peter McMurray

Suffice to say, even at the R83 compatibility level (without vendor
enhancements to their flavor) there are a LOT of little differences
between platforms in BASIC (EQUates, Common, definition of zero...),
AQL (supported options and modifiers), Proc (limited or full PQN
support), Paragraphs (syntactical nuances), TCL dot-stacks (all a
little different), phantoms, and other common subsystems. Each vendor
makes decisions about what's a bug or feature, and whether to remedy
differences with option flags, to document the anomaly, or to let
people fall into a trap (is lack of documentation any less?).
Anecdotes of these nuances (like FOR/NEXT implementations) could fill
a book. To a degree, I consider these to be minor differences, though
the sum of them for any given migration could be "significant".

T

On Jun 1, 8:07*pm, Excalibur21 <pgmcmur... (AT) gmail (DOT) com> wrote:
One other major reason for moving to REALITY was the ability to create
encrypted files (for existing files, create a "temp" file with the
encryption option and key, move data from existing file to "temp",
delete the original file, then rename "temp" to the original file
name). Users must then be given permission to process against an
encrypted file. Kittery Trading Post has several files for which we
will be using encryption.

There was a particular aspect of REALITY that I had to deal with,
personally, and that had to do with their stacker. TCL commands are
not stored, "ad infinitum", as with D3. Outside of the IT staff here
at KTP, there are three users who are very TCL-savvy, as they do a
large amount of queries. One of those users, our V.P. of Finance,
was very disheartened to hear that his stacked commands were going to
vanish. Selections / lists, done weeks, maybe months ago, were not
going to be there for him to peruse with the CTL-A. I had to come up
with a remedy, quickly, so I wrote my own stacker application,
"replicating" (not necessarily the same as "duplicating") most of what
D3' stacker does. Once a user enters TCL from any of the primary
menus (and only a select few know the passwords to get to TCL from any
of those menus), they "EXECUTE STAK", which is my stacker program.
They will see a TCL-Prompt that is different from REALITY, and from
that point on, every command will be captured in LIFO sequence (the
last command entered is moved to the top of the stack; the entire
command is processed in "locate-else-insert" fashion, so as not to
duplicate; CTL-A (or ".S") at TCL, followed by some verbiage, will
search their stacker for any instance of that verbiage; ".L" will list
all commands, top-to-bottom with line numbers on left of screen;
choose a line number to execute that command. For every occurrence
found, the options allow for "R" to run that command; "C" to change it
(maybe a long SELECT statement just needs different dates entered); or
"Q" to quit back to TCL. Each user has commented that STAK fulfills
their usage of D3 stacker.

Considering what started this thread, I would have to say that the
STAK application was my most "significant" difference to have to deal
with.

Best to all,

Jim Cronin

On 06/02/2011 12:28 PM, JJCSR wrote:
Glad to hear that was the exent of what you had to worry about. Sorry
I didn't know about this before you went to work to write you own.
I'd have gladly given you mine that was originally in my Pick User
Digest column back in 1988/89. Or pointed you to Harvey Rodstein's
stacker that was in his Advanced techniques programming book.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk

On Jun 2, 3:52*pm, sdavmor <sdav... (AT) fakeemailaddy (DOT) com> wrote:

Thanks for the offer. However, one of the processes of my STAK
program is to first move through REALITY's "stacker" (one batch for
every "logoff", for each user) and grab any commands that may have
been entered at the REALITY stacker. That way, in the event we find
ourselves working outside of STAK, I can still collect the entries and
post them to my STAK file.

I do remember "Pick User Digest". And I know Harvey, but wasn't
aware of his "Advanced Techniques" programming book.

Again, thank you for the reply, and "stacker" offer.

Jim Cronin

On 06/02/2011 01:38 PM, JJCSR wrote:
That's a good idea.

Well worth reading. Even 20 years down the road it's worth its weight
in gold for the ideas and the code examples.

Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk