--------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00011 Date: 09/08/96 From: MIKE BILOW Time: 12:57pm \/To: BRUCE LANE (Read 6 times) Subj: Lan's Bruce Lane wrote in a message to MIKE ROBINSON: MR> I have three computer that I would like to lan togather. One has MR> windows 95, one has windows 3.1 and the other is a BBS in DOS. MR> How can I do this? and keep the cost down... BL> Well, the cheapest way to do it is: BL> * Shop the used/surplus market for coaxial-cable BL> (Thinnet) network cards. BL> * Use a coax cable daisy chain between the three. BL> Twisted-pair is nice, but then you need a hub which can BL> add significantly to the cost. On the other hand, coax is a lot more expensive than UTP cable, so a long run of coax could easily offset the savings from not having to spend $60 on a UTP concentrator box. -- Mike --- * Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00012 Date: 09/09/96 From: MIKE BILOW Time: 12:08am \/To: JIM PALMER (Read 6 times) Subj: Peer-to-peer Jim Palmer wrote in a message to Mike Bilow: MB> I never contended that Sun was as bad as Microsoft. I'm not even sure MB> that I would suspect Sun of being ill-intentioned. However, Sun makes MB> sure that they retain the right and power to do exactly the kind of MB> harmful things Microsoft does, even if they never actually do them. JP> I think we should agree to disagree here, I retain the right JP> and power to be a murderer, but so long as I use those rights JP> responsibly, I see no reason to brand me a 'murderer', just JP> because I retain my second admendment rights. Nevertheless, if I was giving a party, I would be reluctant to let someone in carrying a large club even if he asked nicely. JP> I would think I would need to see some flaw in Sun's behavior JP> before I disaproved of their informal attitude to standards. You have a point here. What it comes down to is that I'm uneasy; you're not. -- Mike --- * Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00013 Date: 09/09/96 From: MIKE BILOW Time: 01:03am \/To: CHRIS STONE (Read 6 times) Subj: Backup Software for Netware 4.10 Chris Stone wrote in a message to All: CS> Well, an incompetent CNA stricks. (and they are nowhere to CS> be found as luck would have it) CS> I purchased a 10 station system and server setup (with all CS> software) from a local company. They put in a Colorado CS> Memory Systems 1400 1.4 gig tape backup system. Had a case CS> the other day that I needed to restore some files. Tried and CS> failed. Did some checking and the software docs said NOT to CS> use the Colorado Backup software with Netware NDS due to CS> possible critical server crashes. Checked their web site and CS> ftp site for new software and found none available. Just CS> found more warnings about using the software with NDS. The whole Colorado Jumbo series, including the 1400, is not supported in any way for server-based backup in a NetWare server. The Colorado PowerTape and PowerDAT series are supported by Cheyenne Arcserve 5.x for server-based backup, but that does not help you any. For further information, see Colorado's technical document LPG12030, available on the Internet at "http://hpcc998.external.hp.com/isgsupport/cms/docs/lpg12030.htm". Using a Colorado Jumbo drive such as the 1400 for workstation-based backup is supported using Colorado software for DOS and Windows, but not for NDS. Colorado technical document LPG12037 makes this clear; it is available at "http://hpcc998.external.hp.com/isgsupport/cms/docs/lpg12037.htm": The Colorado software will not properly backup NetWare 4.0X, and in some cases may cause the server to crash. Customers wanting to use the Colorado software on NetWare 4.0X should be advised against it and are asked to use a third party solution. Problems caused by using Colorado software on NetWare 4.0X: NDS (Network Directory Services) will not be backed up. In fact, a bindery error will be reported in CBW. This is happens because there is no bindery (even in bindery emulation mode) to backup. Our software makes a system call to close the bindery before backup. This system call in older versions of NetWare 4.0X can cause a process loop on the server and destroy server performance. Compression is defaulted as on during volume creation in NetWare 4.0X. If the user did not change this setting then the Colorado backup software may decompress all compressed files during backup. If there is not enough room on the volume to hold all compressed files in an uncompressed mode, the volume will dismount itself after reporting it is full. Un-compression, re- compression can be controlled in the NetWare settings but is usually not touched. These settings do not turn on/off compression, they only control compression delays. To remove compression from a volume, the volume must be destroyed and recreated causing data loss. Migration is allowed to near line storage devices and tape. This is the process of moving files that are seldom used to the near line device until needed. The server does the migration automatically The files appear to be on the volume but are not. When the file is requested, the file is moved from near line storage to the volume automatically During a backup, this can cause performance problems on the server if the near line unit is slow. Backups can also cause the volume to fill up which, in turn, will cause the volume to dismount and possibly crash. NetWare 4.0X also has new attributes for files and directories that we will not pickup correctly during backup. During a restore, we could corrupt this data on the server due to improper settings of these attributes causing ABEND errors to occur. For Product Information or Technical Support Questions Contact us at: Colorado_Support@HP-Loveland-om10.om.hp.com (c) Copyright 1996 Hewlett-Packard Company. Updated May 30, 1996 I quoted this statement at some length to forestall any discussion about whether the tape drive could be used if NW 4.1 is in bindery emulation mode. CS> Need to know if there is any backup software available that CS> will work with the 1400 tape drive. Really don't want to have CS> to purchase another drive if I don't have to. Anyone know of CS> any? The Colorado Jumbo series is a disaster anyway. You really need a better tape drive, preferably a server-based DAT drive. I have been very happy with the Conner (now Seagate) and real HP drives, using Conner (now Seagate) BackupExec. There is no reliable way to back up a NW 4.x server from a workstation-based tape drive, regardless of the software used. -- Mike --- * Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00014 Date: 09/05/96 From: KURT HILL Time: 07:43pm \/To: ALL (Read 6 times) Subj: Software wierdness... I am having an odd problem... Bear in mind that I am new to Novel LANS... I just installed a package on our network (an interactive algebra turorial), and it runs fine when I am logged on as a supervisor. But, when I log on as a regular user (out "users" are actually the workstation as opposed to a specific user), the program still runs, but *slower*! Why would a program run fast as a supervisor, but slow as a user? The trustee settings seem OK, as the user/staton has all rights except access control to the directory... And then, the wierdness goes on... The slowness which manifests itself as a _long_ delay before the opening screen is upwards of several minutes on my 486 class test station, but usually around 40 seconds on the 286 workstations... A 286 running 3-4 times faster than a 486! Only in Netware, I guess! Any ideas anyone? Please? ThanX! --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00015 Date: 09/05/96 From: KURT HILL Time: 07:49pm \/To: ALL (Read 6 times) Subj: SD Area... Is there anyone in the San Diego area? Clairmont Mesa? If so, leave me a letter! Thanks! --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00016 Date: 09/06/96 From: KURT HILL Time: 06:05am \/To: ALL (Read 6 times) Subj: SHARE.EXE... The current lab-tech where I work has been overheard saying such things as "we have to get away from using SHARE..." OK, I'll buy into it for no other reason that Mr. Gates had his fingers in the program... But just for funsies, lemme ask: Why, How? There are programs that still use/require SHARE. I understand the concept of SHARE, but probably incorrectly; I had thought that the NOS would handle file-locking and sharing. And if I am correct, then SHARE only handles it for local drives. So then the situation becomes I must load share so that the Multiplex interrupt returns SHARE Installed when queried so that the program can run, but otherwise does not do anything... Are there problems associated with share that necessitate getting rid of it? --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00017 Date: 09/06/96 From: KURT HILL Time: 06:11am \/To: DOMINIC ASPEL (Read 6 times) Subj: General question Dominic, I have used the Linux/Samba server setup you mentioned. Tricky and not at all intuitive stuff, but fun! Make sure your unix file attribs (rwx) are set to at least match the CONFIG.SMB permissions... They are independant of each other, as I found out when I tried to write to a networked drive that was clearly marked as writeable, but was unable to... The "w" flag wasn't set... Have fun! I am now running a Windows96 peer-peer network for my BBS, and although I would prefer the Linux/Samba combo (strictly for it's "fun"), I had to have it up and running quickly. Perhaps one day I'll do it again. My turn for a question: How did you analyze your network speeds? I need to do the same, but want to be assured of accurate results. Let us know your techniques/software preferences. Thanx! --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00018 Date: 09/06/96 From: KURT HILL Time: 06:16am \/To: DANIEL JONES (Read 6 times) Subj: Unix/Networking... You had said that unix includes netwrking as part of the OS... I agree, but don't quite understand it... So lemme ask this: Under linux, why do I have to install SAMBA to network? Or, am I required to install SAMBA *only* to network to machines using SMB packets? Can I network *without* SAMBA to a TCP/IP machine? Thanx! --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00019 Date: 09/06/96 From: KURT HILL Time: 06:29am \/To: SCOTT PARKS (Read 6 times) Subj: Windows on the network... OK, the current setup seems a mess to me... We have software installed on the local HD (windows software), other stuff is on the network... It's all scattered about. I am thinking of redoing it from scratch on *long*weekend. Here my questions: 1) After running "SETUP /A," to get a NW installation copy on he network, do I run "SETUP /N" on *each* workstation, thus installing the files on each machines local HD? Or can I run "SETUP /N" just once, from a network dir, and then give each station READ and FILESCAN rights to that dir, so *ALL* stations are running the *exact* same config at all times? 2) If I can install only ONE workstation windows directory for all the workstations, then when I install new software, I install it from an account with full access to that directory, and just to keep things neat, install new apps in there own directories under a "WINAPPS" directory. Is this a good plan? I am the "child-prodigy" -- I ooze talent, but lack experience, so want to post my ideas here before I implement them. Otherwise it is quite likely that I will be oozing my own blood on the workstations if I cause any major problems :) Thanks for y'alls advice! --- Maximus 3.01 * Origin: BBS, The (1:202/107) --------------- FIDO MESSAGE AREA==> TOPIC: 193 LAN Ref: DDD00020 Date: 09/08/96 From: TORE HANSEN Time: 07:28pm \/To: MIKE BILOW (Read 6 times) Subj: BNC HUBS..? Hello MIKE, on 09-03-96 you wrote to GEORGE WHITE about BNC HUBS..?: GW> I've got a copy of the Datapoint ARCNET Cabling Guide here, GW> publication No 51087, Edition 02, Copyright 1988, which may GW> explain why some participants in the thread have said GW> RG-59/U is suitable. GW> Relevant excerpts: GW> Page 1-3: GW> "RG-62 (Belden #86262 or equivalent), as recommended for GW> ARCNET installation since 1977. GW> RG-59/U (Belden #89108 or equivalent), suitable for use with GW> both ARCNET and MINX real-time video teleconferencing GW> systems." MB> I've never seen this before, and I can't imagine why it would be in MB> the specification. I would certainly consider it obsolete. In my experience, the use of 75 Ohm RG-59/U cable to run Arcnet has been very common. All the Arcnets that I have installed (including my very first home LAN), and the ones installed by others that I either worked on or ripped out, all used RG-59 cable. And they all worked properly as well, considering the workstation "T" connected stub cables, and the passive splitters they commonly used. I believe that RG-62 cable was usually only used with Arcnet in locations where this cabling was originally installed for IBM mainframe terminal use, later to be reclaimed for use as an Arcnet LAN. One of the great things about Arcnet was that it really wasn't all that impedance sensitive (especially if one avoided the use of the 93 Ohm matched impedance passive splitter boxes), and quite tolerant as to the cable medium and cabling lengths used. Although Arcnet is generally considered obsolete for business use, Arcnet is still the ideal gaming network card setup for teenagers stringing cables between their houses. The cards are inexpensively available used, fast enough for good game play, and can easily drive thousands of feet of either coax or twisted pair cable of such a poor quality that Ethernet simply wouldn't tolerate it. Tore tore.hansen@bbs.logicnet.com -- CMPQwk 1.42-R2 391 ... True multi-tasking means buttering two slices of toast at once. --- PCBoard 15.2 * Origin: 32 lines 40 Gig BBS, Realtime InterNet SLIP (403)247-7900 (1:134/10)