Yes. We have found no corruption in the VME.


D3 data and D3 program files are in E:. I have done a chkdsk on E drive
and the result is ok.
This problem has been occurring for several months and have not noticed
that anything has changed recently (patches, upgrades, connectivity
products, etc). If a new event triggered the problem, we can not found it.

For various reasons beyond our company, we can not get the help we want
from TL. Therefore, we only put the question on their forum.

Thanks for your help

--
Marcos Alonso Vega

On Aug 4, 8:21*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:
Wow I had completely forgotten about Ernie until you brought it up.
Obviously Ernie was not isolated to one site, because I don't think I
ever worked with you.

W.J. "hand fixing frame pointers is fun"

Hi
Are you certain that all the dots are char(0).
The easiest way of checking apart from writing a small program is to
copy the item into the vme and use DUMP
In DM create a file called test
Copy an item in, in my example car
:item test car
car
13748.0000 0026 car
1 items 38 bytes 0/38 frames in group 13748
:dump 13748 gx
This will show you the exact Ascii and hexadecimal
I strongly suspect that you will find the Char(0) is coupled with
another character. If this other character is Char(254) then you will
get an extra attribute.
Char(0):char(254) is the spanish i with diaresis in 16 bit Unicode
How can this happen? Somebody using a Spanish keyboard setup and
sending UTF-16 Unicode to the program quite possibly accidentally.
One can also send dodgy characters by using the ALT key with the
numeric keypad. I have a wireless keyboard and it will send repeated
characters if the battery is low.
If only one file is affected it is extremely unlikely to be external
electronic gremlins.
Peter McMurray
Peter McMurray

On Aug 11, 7:27*am, Excalibur21 <pgmcmur... (AT) gmail (DOT) com> wrote:
Neat trick! Being an "FSI Fan" I'm surprised you with have to resort
to this, though perhaps you have had experience fixing/identifying
issues in the FSI before :-)

On Aug 11, 2:29*am, MAV <alonv... (AT) hotmail (DOT) com> wrote:
Events like this can make paying for support seem to be a "cheap"
alternative. However, as with most insurance, the real value may only
become apparent when it is too late!

As a minimum, as you can identify the corrupt records, I'd fix the
record, dump out to a pseudo, restore to a new file & confirm that
everying is AOK, THEN delete the "real" file(s) [making sure they are
gone from Windows level as well], re-create, copy data back & cross
fingers.

I'd also consider an upgrade to 7.5.5 SP 7 ASAP

On Aug 11, 9:29*am, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Hi
I used it to validate my testing with Unicode files produced from
various sources rather than battle with BigEndian and LittleEndian
initially. Now I know that D3 Copy puts DLE + another character for
system marks I have incorporated that into my code. Not knowing how
experienced Marcos is at programming I thought that this would help
him initially.
I still think that the prevalence of Char(0) more likely indicates a
keyboard issue. If for example one of the people entering is using a
laptop with no numeric keypad then miskeyed data is very possible.
I would simply put a trigger on the worst file and capture where it is
coming from. I must admit that I am surprised that any program today
does not do better validation before writing stuff away. But if he is
lumbered with a pile of legacy code with no standard input routine
then tracking can be a devil of a job.
FSI is the greatest thing since sliced bread as far as I am concerned
having the DUMP verb would be a bonus however I have two or three
other engineering requests in that I would prefer that they spent time
on.

Excalibur21 wrote:
You're missing key details. If it was every other character, I'd
suspect a unicode or keyboard issue. Not when there is a stream of
them. Also note that these chars are over-writing attribute marks,
which wouldn't be the case if the data was entered at the keyboard.
And Marcos maintains there is no code accessing the affected areas.
Too many things point away from keyboard/unicode issues.

Excalibur21 escribió:

Hi Peter

Your answer is very interesting, but there is no code accessing the
affected areas. For example, the last error was in the MD of a file:

Original:

001 D
002 $(mds):$(MD)/TEMPORAL/TEMPORAL
003 1
004
005
006
007
008
009 L
010 10


Corrupted:

001 D
002 $(mds):$(MD)/TEMPORAL/TEMPORAL
003 1
004 ...
005
006 L
007 10

--

Thanks,

Marcos Alonso Vega

On Aug 11, 6:30*pm, MAV <alonv... (AT) hotmail (DOT) com> wrote:
Hi Marcos
From what you say the files are old files that are not being updated.
Something is corrupting the files from outside of Pick and since
nothing else is affected it must be a job on the machine.
Is there an anti-virus checker running through the Pick Data when it
is active?
Is there an automated backup running through the active data?
We can rule out external gremlins these days as people would be
complaining about their mobile phones gettting disrupted.
I presume that it is difficult to run a disk test!
Good Luck

Peter, I'm guessing you lost your CDP feed in the Google folly, so
you're making otherwise valid suggestions which are now no longer
valid based on information available.

You can catch up on the Q&A here:
http://bit.ly/pXaALX



Excalibur21 wrote:
That conclusion does not follow from the information provided.

Quite the opposite. Only D3 files seem to be affected, and only FSI,
not VME.

He already said no.

A backup that writes on top of data would be troublesome indeed, but
it's worth the question.

That's not a valid statement. Mobile phones, bluetooth, microwaves,
and various RF devices all operate on different frequencies.


He already said "I have done a chkdsk on E drive and the result is
ok."

T