Sir:

Ian Johnston wrote:
> Sorry people, it's another question... I hope it's not too stupid this
> time.
>
> I have eCS 1.2 running happily on my Thinkpad R40e. It can happily see
> another eCS box on the network and use shared resources from that
> machine. However, I can't persuade the Thinkpad to share any of its
> resources.
>
> Local Network -> Sharing and Connecting gives me tabs for Identity,
> Connections and Icon. On the desktop machine I get tabs for these and
> also Shares, Permissions, Usres, Groups and Configuration.
>
> Typing NET SHARE tells me that I need to be an administrator to do
> this (NET2761).
>
> Help!
>

Change your default logon icon's parameter to read /v:local. Open the
muglib program and log on. If this is your first time, the ID is user
and the password is password. If these don't work, replace the NET.ACC
file in \IBMLAN\ACCOUNTS with a copy of the backup copy in
\IBMLAN\INSTALL. A reboot is not required, but do it anyway. Now try.
Configure it to your heart's pleasure. Create at least two users, the
admin and the ordinary user. Use the ordinary user routinely. I give
my ordinary user the same rights, except the right to add or remove
users. Then check in IBMLAN.INI set 'srvhidden = yes' to no. Now
reboot and try this Local Network -> Sharing and Connecting task again.

--
Bill
Thanks a Million!

On Sun, 6 Feb 2005 16:58:34 UTC, "William L. Hartzell"
wrote:

: Change your default logon icon's parameter to read /v:local. Open the
: muglib program and log on. If this is your first time, the ID is user
: and the password is password.

Thanks. I had forgotten this bit. Incidentally, it's USERID and
PASSWORD...

: Configure it to your heart's pleasure. Create at least two users, the
: admin and the ordinary user. Use the ordinary user routinely. I give
: my ordinary user the same rights, except the right to add or remove
: users. Then check in IBMLAN.INI set 'srvhidden = yes' to no. Now
: reboot and try this Local Network -> Sharing and Connecting task again.

All now working beutifully, thank you.

Incidentally, what does the srvhidden=no bit do?

Ian

PS Now off to find the oddest bug I have ever met. It's a large
numerical simulation program. Compiles and runs on the desktop fine.
Compiles on the laptop, but gives the wrong results. The executable
produced on the laptop works fine on the desktop: the executable
produced on the desktop fails on the laptop. But here's the wierdness:
both executables run just fine in a telnet session on the laptop...

--

[A complimentary Cc of this posting was sent to
Ian Johnston
], who wrote in article :

> PS Now off to find the oddest bug I have ever met. It's a large
> numerical simulation program. Compiles and runs on the desktop fine.
> Compiles on the laptop, but gives the wrong results. The executable
> produced on the laptop works fine on the desktop: the executable
> produced on the desktop fails on the laptop. But here's the wierdness:
> both executables run just fine in a telnet session on the laptop...

I do not know why executables produced on different machines behave
differently. To see why executables can behave differently on
different machines (and in telnet sessions) google for
"check_dlls_87".

Note that discussion there is about code produced by gcc compiler,
(which is designed to produce correct results). My suspicion is that
in the same situation code produced by IBM's compiler will just
silently produce a wrong result (instead of segfaulting).

Hope this helps,
Ilya

On Sun, 6 Feb 2005 21:45:14 UTC, Ilya Zakharevich
wrote:

: I do not know why executables produced on different machines behave
: differently.

It was the oldest mistake in the book ... inadvertantly assuming that
a (C) variable was initialised to zero. I had removed a bit of code
which zeroed it as a side effect. It's understandable that it should
have behaved differently on different machines - both using the Open
Watcom compiler - but I've never had a bug which showed in a console
session but not a telnet one before. Ah well, I live and learn!

Thanks for the suggestions, though. I do find that using different
compilers on the same source can be a useful way of finding nasties.

Ian

Sir:

Ian Johnston wrote:
> On Sun, 6 Feb 2005 16:58:34 UTC, "William L. Hartzell"
> wrote:
>
> : Change your default logon icon's parameter to read /v:local. Open the
> : muglib program and log on. If this is your first time, the ID is user
> : and the password is password.
>
> Thanks. I had forgotten this bit. Incidentally, it's USERID and
> PASSWORD...
Right...
> : Configure it to your heart's pleasure. Create at least two users, the
> : admin and the ordinary user. Use the ordinary user routinely. I give
> : my ordinary user the same rights, except the right to add or remove
> : users. Then check in IBMLAN.INI set 'srvhidden = yes' to no. Now
> : reboot and try this Local Network -> Sharing and Connecting task again.
>
> All now working beutifully, thank you.
>
> Incidentally, what does the srvhidden=no bit do?
>
Allows other computers to see the shares that you create.
>
> PS Now off to find the oddest bug I have ever met. It's a large
> numerical simulation program. Compiles and runs on the desktop fine.
> Compiles on the laptop, but gives the wrong results. The executable
> produced on the laptop works fine on the desktop: the executable
> produced on the desktop fails on the laptop. But here's the wierdness:
> both executables run just fine in a telnet session on the laptop...
>
Sound like the floating point error. See the discussions about how IBM
compiler implemented a work-around and created floating point errors
upon return from certain system dlls. Basically, you have to restore
the fp flags upon return from any system call, while you are doing fp work.
--
Bill
Thanks a Million!

On Sun, 6 Feb 2005 23:16:30 UTC, "William L. Hartzell"
wrote:

: Ian Johnston wrote:
: > On Sun, 6 Feb 2005 16:58:34 UTC, "William L. Hartzell"
:
: > Incidentally, what does the srvhidden=no bit do?
: >
: Allows other computers to see the shares that you create.

Thanks!

: > PS Now off to find the oddest bug I have ever met. It's a large
: > numerical simulation program. Compiles and runs on the desktop fine.
: > Compiles on the laptop, but gives the wrong results. The executable
: > produced on the laptop works fine on the desktop: the executable
: > produced on the desktop fails on the laptop. But here's the wierdness:
: > both executables run just fine in a telnet session on the laptop...
: >
: Sound like the floating point error.

It was simpler and stupider: I had removed a section of code which as
a side effect zeroed one of my variables. Later I assumed it was
zeroed ... which it was on one machine, but not on the other, but was
in a telnet session. Moral: remember that C doesn't not initialise
variables unless you ask it (I knew this, really!)

Ian

[A complimentary Cc of this posting was sent to
William L. Hartzell
], who wrote in article :

> Sound like the floating point error. See the discussions about how IBM
> compiler implemented a work-around and created floating point errors
> upon return from certain system dlls.

Please do not misrepresent the problem. IBM's compilers (as well as
Watcom's) did not create any workaround. What they created is a BUG -
which now all programs which use FP should have workarounds against.
[They reset FP flags at "random moments"; to add insult to injury they
reset them to a useless state.]

What IBM's compiler has is another (mis?)feature which masks (?) the
problem if all you use is IBM's compiled code.[*]

Hope this helps,
Ilya
[*] Cannot be absolutely sure about the details: IBM's installed
exception handlers catch the floating point underflow (and probably
overflow?) exceptions; I saw reports that on OS/2 it is impossible to
do anything useful in the handlers. I do not know what this means.

One possible interpretations is that the result of "failing" FP
operation is the same as without exception handler AND without wrong
FP mask (this would be good if all you use is IBM's compiled code -
generating an exception then ignoring it is extremely wasteful, but at
least the results are correct). But another interpretation is that
the result is just a line noise... People who know FP architecture of
x86 may be able to comment more.

Note that these "failing" FP operation actually "work as designed;"
there may be some reason for some wizardry done when these conditions
are encountered, but I do not know whether such wizardry is actually
possible on x86 (and OS/2), and I'm sure that *very few* people on
earth are able to use such a wizardry...