Op Fri, 13 Jan 2017 06:41:10 +0100 schreef Wolf <w...@wlenerz.com>:


there ae 2 versions of DM : DM5_obj and DM5_int_obj , the problem only seems to arise on the..int version, use the other one instead.

Minor point is that only the _int_ version has been patched for GD2.
I just installed both versions in SMSQm8 and both reported the date error but now my PC clock was not upset, nor by OK on the given date. There was a Qlib error next on "Q_ERR_ON"(?)- both versions and Qlib_run was installed - but a Continue did start the program. Then there was a running error on the FEX keyword, which is expected to be an FI2 command but may have been disabled while the SMSQ/E command does something completely different.

To resolve both issues the sources are needed so I think it's wise to avoid DM5 until this is resolved. Earlier I had patched my copies of DM5 and FI2 to read FFX instead of FEX, which worked until the date problem arose.


On 12/01/2017 17:47, Martyn Hill wrote:
Hi Bob

Just to confirm that I too have been unable to run DM5 on QPC (v4) and
saw oddities around the date before it would hang QPC.

I didn't investigate to the same depth, but it appears to match your


On 12/01/2017 15:35, Bob Spelten wrote:
Hi All,

I was trying to get DiskMate5 to run in QPC2/QLE but ran into a
serious problem.
It reported a wrong date but while the suggested date was correct my
PC clock had been reset in the background to 18-Jan-2053, causing
problems on the W$7 side.
In my QPC2/QLE this also froze SMSQ/E but not in my normal QPC2.
Also a previous QPC2 (v3.40/3.16) behaved the same.

I have used DM5 for GD2 sporadically before but never seen this bug.
Has something changed in SMSQ/E's date handling that is not working
for DM5 anymore?
Has anyone experienced this before?


The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/";
QL-Users Mailing List

Reply via email to