Text 86, 112 rader
Skriven 2005-05-25 06:25:04 av Mike Luther (1:117/3001.0)
     Kommentar till text 83 av Peter Knapper (3:772/1.10)
Ärende: Logged on Peer chucks access!
=====================================
OK Peter and Herbert both..

End result of two approaches to fixing this on two different boxes.

 PK> Ok, go back to BEFORE you start Peer and open a DOS 
 PK> VDM, leave it open THEN start Peer and see what 
 PK> happens.

As noted blew up anyway.

 PK> is the culprit here. At a ROUGH guess it may be 
 PK> something to do with -

 PK>         vdostcp.vdd
 PK>         vdostcp.sys
 PK>         VDOSCTL.EXE

Rough guess .. Replaced them from known good MCP2 similar box.  No help.

 PK> Are these boxes using NETBIOS over TCP/IP or just NETBIOS?

No NETBIOS over TCP/IP anywhere in this case.

One of two boxes exhibiting this general behavior was an MCP2 latest box. 
Replacement of the above three files from known working also MCP2 box didn't
help.  This box was a converted Warp 4 box to MCP via first MCP1 thence MCP2. 
It also was from a box that had the earlier WARP PEER installed via the CID
method, as many of my earlier boxes as noted.  The boxes are same use system
positions.

It was faster to simply use DFSEE 7.04 and clone a for all purposes identical
MCP2 thouroughly working version of this with the same Intel 915GAV Mobo, NIC,
and all hardware as the bad puppy.  I then used Herbert's *VERY* informative
REXX re-addressing program as a study guide for research on this.  By had I
used QEDIT to edit all of the applical control response and .INI files to the
desired new box identity.

        Instant success on boot up for the MCP2 problem box.

The second box, an 800Mhz AMD Athalon system with a Kingston NIC that was doing
this same (similar?) behavior was a FP17 box,  It was still in the original CID
install for PEER and latest fix-pack status for that type box, cloned from a
totally working similar box with identical hardware.  In this case, I used
Herbert's information as a roadmap to again go in with QEDIT and completely
conform all the applicable files on it.

        Instant success on boot up for the WARP 4 CID installed box.


Summary.  As far as I am concerned.  Cloning boxes for Workstation use in WARP
PEER operations requires far more than either just altering CONFIG.SYS HOSTNAME
and attempting to change the HOST in MCPT and TCP/IP conventional setup
changes.  For some reason.

It is absolutely required to go into the IBMLAN.INI file and change the
identity of the box there.  That controls the box major identity in the master
tracking for it in the Sharing and Connecting utility in the grayed over top
section. Without that change, a SHARING PEER box will not properly separate
multiple workstations if they have the same identity shown there!

However, it is the CONNECTIONS pane with the edited name for the box in it
which is ALSO required for identity separation on a PEER SHARED box! And after
you have gotten the other file area information done by hand,it is also
required to go in to the CONNECTIONS folder and conform the idenity there to
the SAME data had set into the other files.

As a final learning experience for me about this, you cannot apparently do this
while all on line, even if you use NET STOP REQUESTER by hand to shut down the
box.  For sure in MCP# applications.  The overall procedure for this goes as
follows:

     1.) You must not be logged on to the LAN to start this.

     2.) Change the data in the edited files per Herbert's info
         with a text editor such as QEDIT PRO for OS/2.  It must
         be one which does not leave EOF marks at the end of
         the files.

     3.) Shut down the box and re-boot it.  MCP in my case starts
         the REQUESTER in the boot run.  WARP 4 here does not,  That
         may be one reason why a corrupted issue here sees the LAN
         smash even for a DOS session opened before log on in the
         MCP enviroment, but maybe not in a WARP 4 environment, Dunno.

     4.) Log on to the PEER LAN.  Open the CONNECTIONS folder.  Make
         sure the Machine Name in it conforms exactly to what was
         set in the other files by hand.

     5.) Disconnect each previously assigned connection.  Delete each
         previously assigned connection.  Re-create a NEW connection
         for each previously assigned connection.

     6.) Log off PEER.  Shut down the box and re-boot.

From that point on, I've seen no trouble at all from these two boxes. Bottom
line; you cannot just change the HOSTNAME in CONFIG,SYS, the HOST designation
in NETBIOS setup in MCPT, and in the TCP/IP LAN folder.  You also have to
change the IBMLAN.INI file data and at least something in at least one of the
other response and initialization files to stabilize at least some clonings.  I
don't know exactly which file setting is producing the PEER conflict for
multiple names that may add to the woes. But something else of Herbert's
suggested data changes is also needed too.

Thanks to both Peter and Herbert for their time and thought.


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)