Peter Knapper wrote in a message to Roy J. Tellason:

 RJT> Why is it that the requester starting up seems to take so long? 

 PK> It looks around the LAN to see what other resources are 
 PK> available that it might be able to use. The need for this is 
 PK> moot with the default PEER type configuration, but if it finds 
 PK> a PDC it can note this now for later use. The timings used for 
 PK> doing this can be user controlled, but you really need to know 
 PK> a LOT about SMB Networking and using a DOMAIN CONTROLLER to be 
 PK> able to tune how long it takes. As usual, IBM are rather 
 PK> conservative with their default timings... If you play with 
 PK> this (and there are HUNDREDS of settings!!!), be very careful, 
 PK> you can kill a machine or a NETWORK so easily by getting these 
 PK> wrong...

Well,  in that case I think I'll hold off on messing with any of that for the
time being.  At least until I know a whole *lot* more about what I'm getting
into here!

 RJT> Also on shutdown it sits there on "Peer service is being 
 RJT> stopped" for a while...

 PK> It advertises to the LAN what you are doing so that anything 
 PK> else on the Network can "unlink" you from their resources. This 
 PK> should be automatically handled, but its possible for the user 
 PK> to stop and start things manually, so it takes some time to 
 PK> perform a tidy shutdown of the network. In a small network its 
 PK> not too important, but on a large one it ensures there are 
 PK> plenty of Network resources freely available at all times. NT 
 PK> takes the same time to shut down its Networking...

Ok.

 PK> I normally remove the Network Messaging icon from the STARTUP 
 PK> folder and only start it if I need it, although it can be 
 PK> useful to debug problems.

 RJT> I'll look in the starup folder next time I fire that up. 

Did that,  and moved it so that it doesn't try and run on startup now.

 RJT> How would you use that?

 PK> Actually I was thinking of the AUDIT LOG, that tool CAN be 
 PK> useful for debugging problems. Network Messaging is like a chat 
 PK> program, it allows you to converse with another user on the 
 PK> LAN, just a simple Desktop to Desktop Messager type of 
 PK> function, TOTALLY unrelated to EMAIL!

Yeah,  so it appears.

 RJT> "Network SignON Coordinator/2", and 



 RJT> That sounds like something that would come in handy,  
 RJT> particularly with using another system as a fileserver.

 PK> ONLY if you use multiple DOMAIN Logins (IE you have MULTIPLE 
 PK> PDC's!) If you dont use Domain Logins, then its useless (well 
 PK> almost, but there are so many problems it can cause with PEER 
 PK> environments if you are not experienced). Leave it alone unless 
 PK> you have more than 1 PDC and really need it!

Ok...

 RJT> I think that ideally I'd like to end up with a setup where any 
 RJT> user (family mostly) can go to any of these boxes and log on,  
 RJT> and use whatever resources are available on the network as a 
 RJT> whole.

 PK> The Advantage of using a DOMAIN CONTROLLER is that EVERYTHING 
 PK> can be authenticated on the one system and makes what you want 
 PK> easier than individual configurations, it can make Multi-User 
 PK> administration over Multiple Platforms nice and easy. 

 PK> The Dis-Advantage of using a DOMAIN CONTROLLER is that if your 
 PK> PDC dies and there is no BDC, then you are TOTALLY DEAD in the 
 PK> water from a Networking perspective on ALL machines! This is 
 PK> not strictly true, but unless you really plan your DOMAIN and 
 PK> machine configurations carefully and set up backup options 
 PK> (PEER Logins as well) on ALL Clients with matching logins and 
 PK> passwords, then you can really have a hassle sorting out 
 PK> problems unless you really know what you are doing. Tread very 
 PK> carefully down this path if you wish to persue it...

Well,  I'm having a hassle sorting things out now,  so it sounds like I'm
already halfway there...!

 RJT> It also says in that "Login" box that the Network is "LS",  
 RJT> dunno where that came from or how to change it.  The domain 
 RJT> name does show up properly in another part of that,  though.

 PK> LS refers to IBM LAN Server, the standard IBM Server platform 
 PK> that provides the support for a PDC/BDC.

Ok.

 RJT> In "LAN Svcs" there's a "LAN Server Logon" and "Peer 
 RJT> Workstation Logon" and "Logoff".

 PK> I can't remember the exact locations of all objects with Warp 
 PK> 3, I totally dislike the Folder layout used by IBM and move 
 PK> everything around to suit my own perception of the world. 

I did some of that too,  so my mention of _where_ an icon happens to be
sitting probably isn't that important.

 PK> IBM really seems to try hard and obfuscate things at 
 PK> times.......;-( The 3 logins I mention are there, but possibly 
 PK> under different names. I change the names on many objects to 
 PK> reflect a more "sensible" naming (IMHO).

Same here.  I also shorten them a bit sometimes to make things easier to
arrange properly.

 PK> The different Logons are actually all the same executable, but 
 PK> different parameters cause it to present a different set of 
 PK> boxes (with slightly different titles) to be filled in. Look up 
 PK> the LOGON.EXE program help and note the possible commandline 
 PK> options. The one program does LOCAL, PEER and DOMAIN logins...

Ok.

 PK> The Logon is validated only on the local machine. In most 
 PK> cases, a user logged in as this cannot access resources on 
 PK> other machines that requires user validation for access to 
 PK> shared resources.

 RJT> I could be mistaken about this,  but it appears that such a 
 RJT> thing is possible with Samba running on the Linux box -- that 
 RJT> if the OS/2 machine can be persuaded to hand over the user 
 RJT> login and password it'll deal with things from there...

 PK> Thats what happens with a PEER Logon. When you connect from 
 PK> OS/2 to a share on a remote system that is PROTOTECTED, 
 PK> depending on how things are set up, OS/2 will present your 
 PK> current local Logon Id and prompt for a password, or supply 
 PK> your current logged on password. 

That's what I was thinking of.

 PK> This can be confiugred in "Sharing and Connecting" for each 
 PK> resource you wish to connect to...

I have not had a whole lot of luck in there.

 PK> This is the same style of Networking as provided by W4WG 3.11 
 PK> operation, HOWEVER it has advantages...;-).  

 RJT> What advantages are those?

 PK> An OS/2 PEER environment can actually access up to 4 different 
 PK> DOMAINS at the same time. To do this requires manual editing of 
 PK> the OS/2 PEER configuration files, but it works fine. I used my 
 PK> Laptop OS/2 Peer environment co-existing in 3 different DOMAINS 
 PK> for some time. WFWG 3.11 cannot exist in more than 1 DOMAIN at 
 PK> the same time. This really does help when doing certain types 
 PK> of work. I think NT can only exist in one DOMAIN at a time too, 
 PK> at least i can't find a way of getting it to exist in more than 
 PK> 1 at a time!

I guess I'm not particularly concerned at this time with multiple domains,
it's more a matter of getting these four machines talking to each other the
way I want them to...

 PK> 3. LAN SERVER LOGON
 PK>         This type of Logon REQUIRES a DOMAIN CONTROLLER to be 
 PK> used. I doubt if you have one of these so this is of no use to 
 PK> you. If you do not have a Primary or Secondary Domain 
 PK> Controller on your LAN, then you CANNOT USE THIS! Basically, 
 PK> your Logon is validated on the DOMAIN controller, the LOCAL 
 PK> user profile is NOT used at all. If the Userid exists on the 
 PK> local machine, then the user may have extra access as defined
 PK> lcoally, but this is NOT required.

 RJT> This sounds to me like something that Samba would deal with on 
 RJT> the Linux box as well,  though I still have some work to do on 
 RJT> that end.

 PK> I dont know SAMBA, but I would not expect it to provide a full 
 PK> DOMAIN PDC environment, there is quite a lot to providing a 
 PK> full PDC Server. As I said before, unless you really need it, 
 PK> dont play with a PDC.

I'm also running 'named' on that box,  a name server of some sort.  And I'm
pursuing a bit of DNS stuff there...

 RJT> But it still doesn't seem to want to see the Linux box for some 
 RJT> reason.  The w95 box shows up in that "Peer Resources" box 
 RJT> okay,  even though it's not turned on at the moment.

 PK> Thats actually quite normal, previously OS/2 Peer had seen the 
 PK> W95 machine and remembered that it existed on the network. You 
 PK> can't browse it (obviously), but if the machine is placed back 
 PK> on the LAN you can go directly to it.

 PK> Browsing an SMB Network exposes the biggest problem with SMB. 
 PK> SMB is a very "chatty" protocol (there are a lot of exchanges 
 PK> between 2 points to complete an information exchange and 
 PK> because it is a broadcast protocol, everyone on the same LAN 
 PK> segment always gets all the messages.

 PK> In your case, the non-visibility of the Linux box is a little 
 PK> puzzelling, however there could be several reasons for this. If 
 PK> ALL machines are using the SAME DOMAIN NAME, then the only 
 PK> thing I can think of is that the Linux box MUST need NETBIOS 
 PK> over TCP/IP as its transport. Dont be fooled by the Windows 
 PK> machine not showing NETBIOS over TCP/IP, I would bet that its 
 PK> probably there, but not obvious. I haven't touched a W95 
 PK> machine myself so I dont know what it looks like in its 
 PK> Networking configuration. I know that on NT its definately in 
 PK> there as a unique protocol...

On the w95 box when you go to "properties" in the network stuff there's a list 
of things,  and both "Netbios" and "TCP/IP" show up in there as separate
protocols.

 PK> Add NETBIOS over TCP/IP to the OS/2 machine and see if that 
 PK> helps...

Did that,  it didn't seem to make any difference.  The one thing I could try
is to give it the number '0' instead of the '1' it's got now,  and remove the
"NetBIOS" (by itself) entry.

 PK> TIP: If when you try and browse the resources on the LINUX box 
 PK> from OS/2 it reports back quickly (within about 5 seconds) and 
 PK> shows  as available, then LINUX is saying to OS/2 that 
 PK> the currently logged in User on the OS/2 machine, is not 
 PK> allowed access to anything on the LINUX machine (access is 
 PK> being rejected). If there is a delay of about 15 seconds or 
 PK> more before this message comes back, then the LINUX box is not 
 PK> being found in the same DOMAIN as the OS/2 box. 

It's not seeing that machine at all.  Which is quite puzzling as the domain
settings are the same in all machines,  and the w95 box has no trouble seeing
it.  The OS/2 and w95 boxes can also see each other quite well,  no problems
there.  This is puzzling,  and is probably going to turn out to be something
relatively simple,  once I find it.

 PK> Its actually quite easy to do this, go into the INSTALL of PEER 
 PK> Services and follow through the install process until it finds 
 PK> the existing Database and asks if you want to RESET it. Reply 
 PK> YES and it installs the defaults again.

 RJT> Would that be the "Installation" under "LAN Svcs"?

 PK> Yep...

I may give that a shot -- rip it all out and re-install,  and see if that
doesn't fix the problem.

 PK> Make sure ALL machines have NETBIOS over TCP/IP configured in 
 PK> them. You may also have to set up some broadcast mappings in NB 
 PK> over IP, I dont know if SAMBA needs these or not (I have never 
 PK> used SAMBA).

I'm pretty sure I've got this right.  I can define a share on the Linux box in 
the smb.conf file and have it show up properly on the w95 box,  no problem.
It's only the OS/2 box that has a problem with seeing that system for some
reason.

 RJT> You're not the first one to say this,  but my understanding of 
 RJT> the protocol issues is that you don't need that unless you want 
 RJT> to route NETBIOS stuff across more than one lan segment,  and 
 RJT> that having both NetBIOS and TCP/IP (as separate protocols in 
 RJT> there) should do the trick.

 PK> Generalyl that is true, however over time the useof NB over IP 
 PK> has become very popular because it can solve a lot of problems.

Oh?  What sort of problems?

 PK> I have not used SAMBA so I can't say for sure, however SMB 
 PK> started life as a pure NETBIOS protocol. it could ONLY operate 
 PK> on a local LAN segment, unless you had some way of connecting 
 PK> LAN segments together that transported NETBIOS messages. 
 PK> Because NETBIOS is BROADCAST, and linking LANS over a WAN was 
 PK> very slow, the entire LAN would run at the speed of the slowest 
 PK> WAN connection.

 PK> At this stage the concept of encapsulating the NETBIOS traffic 
 PK> inside a TCP/IP packet was born. This had 2 immediate 
 PK> advantages, TCP/IP is not a Broadcast communications mode it is 
 PK> Point to Point, so a large portion of the NETBIOS traffic over 
 PK> the WAN was eliminated, speeding up LAN operations 
 PK> dramatically.  TCP/IP can be very efficiently routed to 
 PK> wherever it is needed, so traffic was removed from everywhere 
 PK> it was NOT needed, freeing up the local LAN segments. Also 
 PK> included in NB over IP was the ability to locate and store 
 PK> addressing info to help resolve the addressing issues without 
 PK> refering back to the source all the time.

Hmm.

 PK> The one down side to NB over IP is that all this requires extra 
 PK> configuration and can slow down the messaging between the 
 PK> machines that actually do connect over the NB over IP 
 PK> component, but it does work. I connected from my OS/2 Thinkpad 
 PK> in Sydney Australia, to my OS/2 Desktop in Auckland NZ (about 
 PK> 1200 miles away), over a very busy routed Network and used my 
 PK> Desktops Modem to place a local call in Auckland. It worked 
 PK> very well...

That's pretty impressive.

 PK> So much networking involves WAN components these days that it 
 PK> is not unusual to find NETBIOS over TCP/IP in configurations, 
 PK> in fact over 95% of our NETBIOS based machines at work (about 
 PK> 1500) have it installed. I think the default networking 
 PK> configuration for NT installs NB and NB over IP anyway... 

I don't know anything about NT.  And probably won't,  unless I get a chance to 
find out in the course of some employment,  it just strikes me as wanting way
more in the way of resources than I'd feel good about giving it (if I even
_had_ them here!) for what you get.  That's why I'm doing the bit with the
Linux box...

 RJT> am still stuck when I try to get any further results with the 
 RJT> "Sharing and Connecting" part,  particularly the "Create a 
 RJT> Connection" part.  I can enter the machine name of the Linux 
 RJT> box under the "Workstation" field,  at which point it upcases 
 RJT> it (could that be a problem?) 

 PK> No, all SMB resource names are in upper case. 

 RJT> and under the "Share/alias" field it says "".  

 PK> There are 3 things you need to check -

 PK>   1. The NETBIOS MACHINE name you supplied could not be found 
 PK> on the network,

That's a possibility.  Someone in another echo mentioned that I might need an
"lmhosts" file,  so I made one last night.  Haven't tried it yet...

 PK>   2. The NETBIOS MACHINE name could be found on the Network, 
 PK> but the DOMAIN NAME configured on the Server does NOT match the 
 PK> DOMAIN NAME on the OS/2 machine.

I *really* don't think that's it.

---