How to start sharing? - OS2

This is a discussion on How to start sharing? - OS2 ; 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. ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: How to start sharing?

  1. How to start sharing?

    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!

    Ian
    --


  2. Re: How to start sharing?

    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!

  3. Re: How to start sharing?

    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...

    --


  4. Re: How to start sharing?

    [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

  5. Re: How to start sharing?

    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

  6. Re: How to start sharing?

    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!

  7. Re: How to start sharing?

    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

  8. Re: How to start sharing?

    [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...

+ Reply to Thread