I run LH Verify on SYSDICT and get SYS103. Is that normal? (I cannot find that error code in reverror.dat, by the way.)

- Oystein -

Hi Oystein,

Well, I don't think it's normal, because I just ran it on the system here and got no errors.

If you check the SSPERRORS_100 insert you'll find

equ ssp_user_abort_err$ to "SYS103" ;* user hit abort for this req

What this means in your case is anybody's guess, as I find it difficult to believe you aborted the process!

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

Carl,

Thanks.

What this means in your case is anybody's guess

Well, if it's serious I really hope somebody's able to make a correct guess.

Checking a couple of old versions I think I must have had it through all my time with 3.3, and even before, i.e in 2.61. I find it odd that it could have survived from OILAN to OIWG, though, because the latter wasn't an upgrade from the former but a spanking new system. (Or wasn't it?)

On the bright side it seems it's gone in a version I upgraded to 3.5. (Or does that make it odder still?) (On the downside it seems I'm not quite ready to go to 3.5 yet…)

- Oystein -

Oystein,

I believe there was a bug related to LH verify/fix against SYSDICT related to the absence of DICT.SYSDICT. Basically, when R/List would use SYSDICT (in cases where a table didn't have a dictionary or where specified dictionary items were not in the table's dictionary) and would actually try to open DICT.SYSDICT, which did not exist (until 3.6) so the OPEN statement would automatically redirect DICT.SYSDICT to SYSDICT. This in turn confused LH verify/fix.

Cameron Purdy

[email protected]

Cameron,

Thanks for helping me with this.

I believe there was a bug related to LH verify/fix against SYSDICT related to the absence of DICT.SYSDICT.

So do you think this bug was always there until a certain version of OI? And most people wouldn't notice it because they'd never try to verify SYSDICT?

If so - then you must be wrong about the change being from version 3.6 and onwards, because the bug's not in my 3.5.

Basically, when R/List would use SYSDICT (in cases where a table didn't have a dictionary or where specified dictionary items were not in the table's dictionary) and would actually try to open DICT.SYSDICT, which did not exist (until 3.6) so the OPEN statement would automatically redirect DICT.SYSDICT to SYSDICT. This in turn confused LH verify/fix.

I must confess I don't quite follow this, but I'll leave it at that. Except I'll tell you that RList lists SYSDICT just fine, but that probably shows how little I did understand.

- Oystein -

Oystein,

So do you think this bug was always there until a certain version of OI? And most people wouldn't notice it because they'd never try to verify SYSDICT? If so - then you must be wrong about the change being from version 3.6 and onwards, because the bug's not in my 3.5.

We fixed the symptom (LH fix/verify) before 3.6 because it was a small change and had a very low chance of breaking something. We finally fixed the underlying problem (OPEN aka $RTP9) in 3.6, and even though we were very careful and tested it well, it still caused a regression (large selects handled by EXTERNAL.SORT, fixed in 3.61).

Cameron Purdy

[email protected]

Cameron,

Thanks for the clarification and for easing my mind on this issue.

- Oystein -

Well I hope I'm not throwing a spanner in here but I've just tried a VERIFY_LH on one of our data directories that does not include SYSDICT and the same SYS103 error appears! Running from System Monitor, the dot that usually appears when a process finishes doesn't in this case but OIEngine is idle and you can continue as normal.

I've tried verifying SYSDICT and DICT.SYSDICT and this does not give me SYS103. This happens on versions 3.6 and 3.61 but I haven't tried any earlier versions.

Any ideas?

Matt Crozier

View this thread on the forum...