>>>It's worth noticing that any serious OS must allow user impersonation (is there such a word in English?), thus, it must expose a method to programatically logon a user. So, any good system admin should limit the number of failed logons in order to protect the system against password "guessing".
>
>>Yeah, we use the "user impersonation" term. :-) And I see your point here.
>
>We've dropped it to 3rd logon fail gets a permanent lockout now, and you have to go to LAN security HQ and show ID badge to get it reset.
>
>So, how is it that we see in all the movies some device checking all possible combinations with some neat-looking device, and breaking into the systems? Artificial, I guess, or poorly-secure systems :)

Yeah. Don't know how many chances you get on our LAN but I'm sure it's set up. In our dial-in RAS system, three strikes and you're out. Got to get them to reset your secure ID logons, etc.

BTW, read Malcom's article you referenced and that's gotta be it. The application has a Main.prg, Main.mpr and a Main.scx so I guess I'll just leave in the CLEAR PROGRAM statement until MS fixes it. In my case I only seem to have to execute it on the way out of the application for the development scenario. But, like Malcom, just don't like the feel of CLEAR PROGRAM in a run-time application.