Hello All,

One of my clients' systems has exhibited an odd problem. After the RD
supplied utility F-RESIZE is run, some (many) of the updated D-Pointers
contain 130000 (one hundred thirty thousand) attributes and the
suggested modulo has been placed in attribute<130000>. I am attempting
to find a pattern in which are written this way and which aren't but
with no luck so far.

Suspecting that someone had played with the program, I have recompiled
it. When that didn't fix anything, I decataloged it, moved the existing
program and restored dm,bp,f-resize from the FILES supplied with the
system. I have compared our program with the one from the FILES dm
account as well as with the program from a D3/NT system that someone
sent me. They are identical.

The line in the program that writes the suggested modulo is:
147 if dot else writev odd on fv.q,writem,13

I have removed the line and typed it manually; exported it and
hexdumped it ... there are no hidden characters that I can find. Also,
placing a debug statement before this line shows no garbage in the
"odd" variable; just the modulo enclosed in parens.

As another test, I added a line:
148 if dot else writev odd on fv.q,writem,17

Now those items contain 170000 attributes. Yikes, now _that_ is what I
call scalability! <g>

Thinking that something is broken in the system and causing this, I
wrote a little test program:

FN = 'ACCOUNT,TESTFILE,'
OPEN '',FN TO TEST ELSE STOP 'TEST'

READ ITM FROM TEST, 'TESTING' THEN
WRITEV '(4101)' ON TEST, 'TESTING', 13
END ELSE
ITM = 'TEST'
ITM<2> = 'ATT 2'
ITM<3> = 'ATT 3'
ITM<17> = 'Comment'
WRITE ITM ON TEST, 'TESTING'
END

END

Running this twice (once to populate the item, the other to do a
WRITEV), it acts exactly as one would expect it to: the item 'TESTING'
contains 17 attributes, with att<13> = '(4101)'

Has anyone else experienced this? Has anyone any ideas or suggestions?



The system is:
D3 7.4.0
But the ABS and FILES are:
D3_abs-lx-7.4.7-.Z
D3_datafiles-lx-7.4.7-.Z

So upgrades have apparently been performed.

RH 9 2.4.20-8smp

TIA,
-Tom

Tom deL wrote:
Yikes! At least they dont charge extra for all those AM's I'd make
sure the abs and other patches are current at this point.

I just downloaded the 7.4.0 distro tar file from RD and those are both
file names from the stock install. The abs patch files you download
are named a little differently, something like 638674xa218 (which is
the latest abs for 7.4.0 btw). Try checking with the "which" TCL
command like so:

which (cad

to see the current abs patch level on the machine (should say
7.4.0.A218 if its current).

hth, but if not it might be time to call RD support.

Tedd

Hi Tedd,

Shhhhhh! Don't give 'em ideas.

Thank you very much. Their system is out of date, they have been paying
a fair amount in annual support fees and thought that their VAR was
keeping them up to date :-\

I'll try to get them updated over the weekend. I didn't see this
problem in the litany of fixes but perhaps it was hidden in one of
them.

Thanks again!
-Tom

Makes you worried if the standard application codes uses writev!

Goo'day, Tom,

Wasn't there a similar problem/query on cdp not so very long ago? I
vaguely recall somebody's mention of thousands of attributes
appearing.... somewhere....as a result of some sort of maintenance....

Unfortunately, I've slept since then and memory's been erased....Can't
even remember the important stuff...

On 28 Apr 2006 14:30:43 -0700, "Tom deL" <ted (AT) blackflute (DOT) com> wrote:


Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

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

Tom,

With no way to prove it, I have to believe it has something to do with
precision. Since you start with an integer (13 or 17) and end up with a
large number (* 10000), it kind of points to there being a scaling problem.
But I don't know how everything else keeps working properly. What was the
actual value placed into attribute 170,000? Can you try it once with the
added line Precision 4? If that makes no difference, then the next step is
the Rolando Ruiz Parallel Processing Method. Start a process that works and
break it at br.writev. Start this process and stop at line 147. DEbug,
b/br.writev, M for modal trace when you get there, E1 and step thru the
debugger step by step. The broken system will do something that the
non-broken one won't and that's where the problem lies. There should be
four things on the stack: attr#, itemID, file pointer, data to write.

Mark Brown


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

Hi Mark,

Thank you for the input. I have made arrangements to apply the updates
tomorrow afternoon. Had forgotten that it's also EOM time.

How would we know that everything else keeps working properly? Is this
assumption based on the fact that a 20 line test program works as
expected? I have grave concerns about the data integrity of this
system.

With my test added, the actual value placed into att<170000> is the
same as that placed into att<130000> - the suggested modulo enclosed in
parens - "(1)" or "(101)" or ...

Is this something that might have been modified in the DM account?

Since the window in which I may have the system down is limited, are
you suggesting that I shouldn't spend this time effecting the ayatem
updates?
-Tom

Tom,

Since the test program works and the real program fails, there are limited
possibilities. Since just recompiling the program didn't make any
difference and since the system verifies (I assume?) the question is how
does 13 get changed to 130000. If this isn't some Flashed Basic/linux-side
problem then there has to be an anomoly somewhere. Pinpointing system side
problems usually boils down to something to do in the debugger.

I'd wait until after you upgrade the system before fiddling with it. If
it's an upgrade problem, it should go away after. If it's not, it will
still be there, so there's no hurry.

Assuming it still happens after the update, if adding the Precision 4
statement fixes the problem that more or less points at a scaling problem.
If it doesn't then I have no idea beyond examining the stack when you get to
that instruction.

Mark

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

Tom, have our own D3 basic programs that read the file of files,
creates a temp file with the proper modulo, copies the dicts and data,
deletes the old file, recreates it, and copies back the data, then
deletes the temp file. Sounds like a lot of work, but it IS a program
and we staqrt it 00:01 on a Saturday night...

Haven't trusted the R83/AP/D3 utilities for a while... If we need them
we rewrite them in Basic and stuff them in our own Utility libraries.
That way a new release that 'forgets' them (RD, not Pick Systems),
doesn't leave a hole in our support.

Nick

Hi
I have found that the way I prefer is to save a file that I want to resize
to a pseudo floppy then copy it back as it seems to be safer and much
faster. The resize file just seemed a bit too quirky for me as I had
trouble getting its display to work properly.
There again I wrote my own resize utilities so far back I forget which type
of Pick I originally wrote them for I think it was reality.

Peter McMurray

"NickQ" <nquinn (AT) totalgroup (DOT) bm> wrote