Hello Group

Just to let you know about a number of issues with D3 9.0 running on
Linux platform. I have not tried this on D3-Windows. TL are now
looking at these with "hopefully" a CRITICAL status

D3_setup grabs all the available "unallocated" disk space from your
drives even though you may have specificed "use existing partition".
It does what you ask it to do, but then decides it will scan your
drives for any other space it believes can be added to it.
Historically D3 used to consume all the unallocated space, but if you
tell it "use an existing partition", you expect it to do just that,
nothing more

Restoring D3 data accounts from previous platforms (ie D3 7.5.1 and
earlier) will cause GFE's as soon as you tr try to SAVE it on the D3
9.0 platform (TL Action Item 35328). This is an issue where the
ACCOUNT being restored has large Item-Id lengths / large records /
invalid pointer mismatch (that potentially show signs of error from
their original platform, which the original platform does not
highlight to you). The only time you notice the potential problems is
when you migrate up to the newer platforms. These types of records do
not get fixed as part of the restore. TL had addressed this in 7.5.1
and do fix a majority of the offending records from earlier platforms,
and this has been further enhanced on D3 9.0. However, they have not
captured all occurances of these potential errors to date. The current
"fix" (even for 7.5.1) is that you EDIT the offending items and simply
"FI" them. Problem on D3 9.0, is that the GFE does not even log the
correct information into the ERRORS file, to therefore provide you the
info needed to find such items.

Monitor M4a has now been released to stop the confusion over their
issues about having 2 different M4 patches in two different FTP
locations within TL. The M4 patch was supposed to fix Red Hat 6.0 and
64-Bit issues, but the M4 patch that was visible from the /pub folder
was incorrect, and you had to use the one they decided to leave in
the /outgoing folder. TL have replaced both of these with M4a, and is
now in the usual location.

HotBackup fails / crashes your server when transferring BINARY CODE as
part of its process.

John

Thanks for the info John.

I had found something similar in terms of "grabbing all disk" --> my
"solution" was to manually adjust the pick0 file

john wrote:
On the point about the FTP site:
The /outgoing path does not display files to anonymous logins. The
purpose of that directory is for PS/RD/TL to provide one-off files to
customers who will not publish the location or the data. That
directory is generally used for betas and tests like M4a, not for
production releases like M4. The /pub directory is visible to all,
and everyone is free to download from there. At the time M4a went
production, it should have been removed from outgoing and put into
pub. Once the software is in pub there's no sense in having it in
outgoing anymore - any given release should only be in one place.

HTH
T

Update On TL Issues
===============

Hard Disk Allocation
The reference manual is going to be updated to relfect that if you
take USE EXISTING PARTITION option, D3 will still take 75% of the
unallocated disk space ALSO as part of its setup.
D3 has always taken disk space this way, and I dont believe this will
ever change, although the manual needs to be much clearer.
TL also fixed a problem on Red Hat 6.0 whereby it was incorrectly
deciding what 75% was. I believe this was due to the way Red Hat 6.0
is presenting the drive information to D3

Monitor M4a
This now replaces the 2 confusing M4 patches, although my only gripe
here now, is that if you perform a WHICH (CAD it still says M4, dated
8th Decemvber 2010. M4a was released much later than 8th December 201,
and this may pose problems for VAR's, when TL support ask for a WHICH
(CAD and they wont know which of the 3 versions of M4 you could be
running !!!

Hot Backup
The seems to have settled down with A6 patch, but more tests are under
way.

File Inconsistency
Just an ongoing support issue for any site migrating. Not the end of
the world, but if you get any during the upgrade, you will have to
manually fix them at that platform. Unforutnatley, i had one in an MD
item, and even fixing it would have lost some data from Attributes 1 &
2. Not really a problem because the ITEM is defunct and not important.

John