<sigh> looks like the core "roll-on" functionality in D3 has gone by
the wayside, too. (tested version: 7.5.0 NT)

the internal algorithms that used to allow intelligent cascading of
multiple ROLL-ON values to a 'common column' for both visual
aesthetics and to conserve real-estate -- seem to be lost! worse, the
output for the roll-on now becomes completely mangled and embedded as
part of the SS-output, itself.

subsequent attempts to influence control of the output through
incorporating break-on/roll-on-combinations, will likely provide a
debugger abort with R15 referencing an illegal frame:

Fid Range (0001ADE9)
EL_NXTA_NX7:000
Return stack contents...
DB_ENTER:000

harrumph!

Hi Dave
How could that be! Tony has just sent a long screed about the thousands of
test that are done.
Unfortunately I suspect that they are of the same level as the items in the
old TEST account. That is THREE line wonders such as
FRED = OCONV(0,"D")
JOE = ICONV(FRED,"D")
IF JOE = FRED THEN RESULT = 0 ELSE RESULT = 1
If only there had been a tape read error test for example. The brilliant
response in AP was a Hex dump of memory and STOP regardless of the 128
users connected at the time. In D3 the same issue caused File-saves to
crash with a new tape for so long I automatically initialise all tapes with
a dump now. The AP botch cost me a 7 figure contract.

Then of course there are the complex A correlatives that don't work with
multivalued base dictionaries. We wont mention indices that do one thing in
the VME and something else in the FSI.

Hey I still think D3 is better than a lot of other things around, I have
just got very careful since AP and stick to plain vanilla. Those of us old
enough to remember the IBM 360 will know that there were over 1500
documented errors in the operating system that they had no intention of
fixing because they were scared of the likely catastrophes One beauty that
I found was the inability of the tape write to do a proper EBCIDIC to ASCII
conversion and the complete tangle that it got into trying to go down to
1600bpi. I solved that by getting the operators to give me EBCIDIC at 6250
and walking down the street with the tape to talk sweetly to the key punch
operators at AWA, who chucked it onto their machine and spun it off at 1600
then I read it in on a Reality and did an ASCII conversion as I read it.
You gotta love core memory and thumping great tape units, they aint fast but
they work. Oh! and then I spun it off to a Micromax that the Reality
thought was a terminal by printing it to the screen that wasn't there.
Where there is a will there is a way.

By the way the IBM 360 was actually slower than the 1400. The salemen
either did not know or forgot that there was a go faster switch on the 1400.
They guaranteed that the 360 was faster. Ooops! National Mutual got over 1
million dollars compensation for that one.

So far D3 7.5.2 on NT in a 22 user Citrix setup has gone fine in plain
vanilla mode using FSI and simple OSFI. (Touches forehead, these modern
desks are all blessed plastic no other wood in sight.)

Regards
Peter McMurray

"dzigray" <google (AT) bridge2 (DOT) com> wrote

"Excalibur" wrote:

PS/RD has always been very on and off about funding someone to
actually write new tests for new functionality. After the first major
tests were written back in the early 90s most of the subsequent tests
were only written to verify that bugs existed and were fixed. I don't
think there was ever an edict that said a new feature required a new
suite of QA tests to prove the feature worked. (That would include
'roll-on' when it was first added.) This is exactly what I was
talking about when I said the process only failed when circumvented by
people or budgets. And this was one of my constant issues in QA - how
can you assure quality when no one is authorized to write tests until
after someone reports a bug against a feature? A few years ago I
understand they did actually assign someone to write a lot of new
tests, but he's gone now and the system is large and this needs to be
an ongoing effort.

I'll leave it to you guys to ask RD what they do these days to test
the software and maintain the testing environment. You'll find my
pleas to this community over the last ten years have been entirely
consistent about you guys petitioning your vendors to conduct proper
testing before software gets into the field. Thousands of tests are a
drop in the bucket, they need tens of thousands and people who
understand how the system is used in the field.

BTW, this isn't unique to RD, so please don't get on any high horses
about how bad they are compared to everyone else. It seems every
company I deal with has exactly the same issue (except maybe IBM), and
none of the MV companies I work with have the same sort of testing
processes in place as RD. I also offer other companies my services to
help them implement better QA practices, and the only companies that
have ever accepted are outside of the MV market. Go ahead and ask
your vendors exactly what they do for QA, you may be so disappointed
that you'll want to keep it to yourself.


Note in my previous post on QA that I said you need to keep the tests
small and focused, so yes there are a lot of small tests like that.
(Well, not quite like that because that code is invalid.) But there
are many more sophisticated tests as well that build upon the success
of others. If you have a test that checks if sleep will wake up at
the right time, you need to ensure that basic time/date handling is
correct. If the sleep test fails AND iconv/oconv date handling fails
then you have a clue that it wasn't the sleep that failed, it was the
way the system reported the date in that specific release. As you
see, this can get to be pretty complex.


That's just so much crap. If it was worth that much to you, you would
have pressed your vendor through business channels for a proper
solution and they would have delivered. You were obviously more
comfortable being indignant and happy with your workarounds.

Yes, that's a harsh comment and unusually unreserved. If you had been
working with the vendor as I've been suggesting all of this time then
you wouldn't have lost the contract. Horses and water, sorry. There
are solutions to these problems if only people would actually pursue
them in a manner that's commensurate with their needs.


In this case the problem isn't a lack of quality control. These are
known issues that seem to have been left for years without resolution
because there wasn't enough cost-justification to devote the manpower
to make the changes. As always, if it's important petition the
vendor. If the vendor doesn't get enough requests, they don't
consider it worthwhile.

Can any of you guys see why I go on about this year after year? Just
look at how obvious this chain of cause and effect is. If you don't
invoke change, you'll see the same features broken year after year.
Why is the chasm so large between the messages that you get here and
your interactions with your vendor? After all of these years I don't
give a damn about D3 or how bad you guys think it is because if YOU
felt it was important enough for your clients and your business, YOU
would pick up the gauntlet and work with RD to make it the product
that you want. If you don't want a 7 digit contract (or whatever) bad
enough to sit on the vendor's doorstep to ensure quality, then quit
whining about it and move on to MySQL or something.


Same with some D3 issues unfortunately.


Thanks for a perfect example of how this market works and why it's
going away.

I wonder if anyone is going to report the roll-on issue that Dave
found, or if people here will be laughing or screaming about it after
v7.6 goes production. My guess is that so many people are coding in
AP-compatibility mode that few people are using roll-on and this might
be one of those issues that never gets fixed for lack of high enough
priority. Software is what you make of it folks. It's the simple
principle of 'demand and supply' at work.

T

<BIG SNIP>


Tony, sometimes your mouth and your brain seem to lose connection. I have
always worked closely with the vendor, this case included. If you had taken
the trouble to enquire about the circumstances you would not make such a
fool of yourself. However I have no intention of boring the group with the
full details. Suffice to say that this bit of monumental stupidity by a
bone idle grossly incompetent Unix programmer gave a major accounting
company an opportunity to shaft my company and protect their own asses. You
should know that in multi million dollar contracts politics is more
important than prowess.

Peter McMurray

On Mar 19, 3:32 pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

The trouble with your generalities is that they generally don't hold
true - and for some reason you appear to "have it in" for Peter in
your "unreserved" exchanges.

If this is the site I'm thinking of (which is somewhat of a legend in
Oz) it involves the one and only EDGE "desktop" sold in Australia
(well, actually it was big enough to provide a number of desktops), a
little company called Mobile (www.exxonmobile.com) and what was then
one of the "Big 6" accounting firms (auditors with a software
interest)

The hardware/database "vendor" in this case vacated the country (and
IIRC was belly up worldwide within 6 months), and Peter's company was
well & truly shafted (cast your mind back to the rocky gestation that
Advanced Pick had)

With the benefit of hindsight, I daresay Peter would have pushed
Sequoia (IIRC the auditors selected the hardware) and the face of
Petroleum Distribution in Australasia would be different today - but
the history of Pick is littered with lost opportunities that could
have had major implications (Ninja, Pick as the OS for the IBM PC!)

I've probably said too much already (not my story, and funny
litigation laws here - you can be guilty of defamation by telling the
truth!). Peter, as always the gentleman, was probably correct to limit
his response - but he was certainly correct when suggesting that you
should have taken the opportunity to check a few basic facts ...
Sometimes the horse will not drink because the water is tainted!!


Ross Ferris
Stamina Software
Visage > Better by Design

"Ross Ferris" wrote:
No such agenda I assure you. My memory, desire, and capacity for
carrying sentiment like that between threads is much more limited than
you think. My response would have been the same for any mention that
someone lost 7 figures because of someone else. When it's that
important, people do whatever they can or should. If they don't they
shouldn't blame others.

I truly sympathize for the loss of a client where some other company
was involved and (allegedly) malicious or incompetent - that certainly
does happen. But this has nothing to do with a core dump from a tape
operation in AP as was explicitly stated. Before my employment at
Pick Systems I too had a few RS6000s in the field which had flashing
888 errors accompanied by an immediate halt. After many exchanges,
Pick Systems denied responsibility, but working with IBM amd Pick
Systems, and going through complete hardware, OS, and DBMS replacment
(at a couple of these sites, IIRC), the issue was resolved before it
came to a head - because it was important enough to all of us to make
that happen.

T

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:89itv29ddje997e5kiiajievmpeg52u5e1 (AT) 4ax (DOT) com...
When others have sole knowledge (RD) of their os, then those others can
certainly mess things up for those who can only sit by and watch their sales
go up in smoke. At one point Follett College Stores was the largest D3NT
customer (around 1996). But due to the newness of the current version of D3
at the time, there arose an overwhelming constellation of problems directly
attributable to the os. FCS hung with the systems as long as they could,
then threw RD and all the vendors out. Can't remember who they went with
after that, but mv wasn't in the running anymore.

Ed

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:89itv29ddje997e5kiiajievmpeg52u5e1 (AT) 4ax (DOT) com...
By God you are a slow learner Tony. It had everything to do with the core
dump or more specifically the system halt that crunched everything. My own
software was so well written that I was able to fully recover the system and
rebuild all transactions when I found out about it a fortnight later. By
then the damage was done to the contract situation. I was making the point
that one person's stupidity can have far reaching effects. You cannot
untangle a car wreck by saying we will fix the issue, people have already
died.
Ross's brief resume was quite correct however the ripples went far wider
than that.
Interestingly enough the same software was installed on an Ultimate at
another dealer. The accountants came over to get that shafted too. I had
the fascinating opportunity to watch the manager from the accountants having
a blazing row with the client, full range of expletives, in the centre of
the road, yes the black bit where the traffic goes. The client told the
accountant to go to blazes and two take overs later the software is still
there.

Oh! and by the way my point about simplistic testing was exactly that. The
program shown is not a test with or without the error. A date test for
example would start with 29 February 1900 and 2000 and then work through
sundry combinations of D, D2- etc. You have obviously forgotten the TEST
account that came with every system in those days.
Peter McMurray

On Mon, 19 Mar 2007 22:08:37 GMT, "Excalibur"
<excalibur21 (AT) bigpond (DOT) com> wrote:

Once more Tony beats his tired old drum. When will he realise that
many people gave up on reporting these things to RD precisely because
they GOT NO FREAKIN RESPONSE to their problems.

If you beat your head against a brick wall, sooner or later, it hurts
and you STOP! No?

Dave

Ed's anecdote about Follett prompted me to do some thinking. At the
time, D3NT was a new platform. I personally don't think it should
have been installed in a site as large as that when it was still in
its infancy. Even today I consider D3NT to be capable, but sometimes
rather adolescent compared to its more mature *nix siblings. Personal
views aside, the important thing is that both Pick Systems and Follett
tried very hard to make that situation work for quite a long time, and
it still just didn't work out - the contract was lost despite
everyone's best efforts.

The situation that Peter had seems similar, involving new technology
that was probably just not ready for prime time despite best efforts
of all parties. A few people might remember the name PickTel which
was yet another of those situations that just shouldn't have happened.

The thing that gets me about all of this is that many of us, and I'll
point a finger right back at myself here, just don't know when it's
time to stop trying to fix a problem, and realize that the solution is
to change the game entirely. Hindsight being so very 20/20, Peter's
system and the D3NT at Follett should have been pulled and replaced
before the situation went critical. Of course when we're deep in
these situations there's rarely a bell that rings that tells us it's
time to quit. I tend to go on here about how people jump to
workarounds before even consulting with the vendor - these other
situations are entirely in the opposite direction and it was that
notion of letting things get extreme that prompted my comments.

Moderation between extremes is something learned over time, and yes
Peter, it seems I am sometimes a bit slow, especially when it comes to
some forms of moderation. Please accept my apologies.

T