
-----------------------------------------------------------------------
NOV-MOAB.DOC -- 19980114 -- Email thread on NW's "Next Gen" IP-Only NOS
-----------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Thu, 20 Nov 1997 10:27:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: MOAB

>Does anyone have any information sites about MOAB?  I have seen very
>little about it on Novell's site.  Thanks.
-------
	Please note that Moab is now available as a public beta, with all
the joys that go with betas. Please see Novell's web page for details and
request form.
	Just a word of caution. Beta software should be tested on non-
production machinery, and when NDS is involved it is often wise to use
a test tree. Moab runs, I set up such a server last summer as a native
IP device.
	Joe D.

---------

Date: Thu, 20 Nov 1997 17:35:07 +0000
From: Richard Letts <r.j.letts@SALFORD.AC.UK>
Subject: Re: MOAB

Look in the intranetware section on

	http://support.novell.com/beta/public/

or

	http://support.novell.com/beta/public/intranetware/moab/

------------------------------

Date: Fri, 5 Dec 1997 15:39:20 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: MOAB, NLMs, and HARDWARE

>Questions about Moab that I was hoping someone could shed some light on.
>
>Does Moab have increased hardware requirements?  Our Compaq P100 server
>with 144MB RAMdoes a great job for ~200 users running INW 4.11.  Should
>we consider a faster machine?
>
>How will existing NLMs run with the new memory protection and virtual
>memory features?
--------
	It's requirements to-date are basically those of NW 4.1x. Clearly
your server's memory is totally dominated by non-o/s issues and thus one
cannot address them without testing.
	As to "How will existing NLMs run", that depends on the NLM and
the various APIs in use and so on. Specifics need to be addressed, and
you won't be able to do that job completely until NetWare 5 is released.
Generally things should run, but that is a vague generality.
	You can obtain Moab beta-1 by visiting Novell's web site and
filling out a request form. This is hardly like the release product in
that much more work will be added in later betas. Please underscore the
previous sentence.
	Joe D.

------------------------------

Date: Tue, 16 Dec 1997 19:19:41 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: SFT III vs. Vinca

>I'd like to hear some pros and cons from people who've actually used
>these products?  I have a client in the medical field who wants
>SFT III - I've never done one.

SFT III.

Some minor points to remember when considering the use of SFT in a
Netware environment are...

1. With the soon to be availability of Moab, SFT III will no longer be
developed. This of course means that new patches etc, might cease to
support SFT III, and this is a very big issue.

2. SFT III needs two identical hardwares, from the smallest screw to the
largest disk and the last bit of memory. Vinca does not and can use any
two machines so long as the disks are similar in size.

3. SFT III in oposition to all the other such products on the market,
mirrors disks AND memory. This has definite advantages, and very serious
disadvantages, the main being, that if you have memory corruption on one
server, it is also going to be duplicated to your mirrored server. This
demands you bring down the system fully before it will clear memory.
Many people seem to think it is enough to bring one down, but trust me,
it isn't.

4. If you are considering SFT III, remember that your network NIC's are
NOT allowed to work faster than your SFT connector NIC's. In most cases,
this means you cannot use any NIC that is faster than 100MB or your SFT
will simply fail.

5. SFT is absolutely fantastic during mirrored servers crashes, allowing
you to take down either machine..or in case of a crash, bring one back
up without ANY lag at all on the users part. None of the NT based
systems can say the same, including Vinca. Of course, the longer the lag
between a data commit to actual commit, can sometimes mean a corrupted
file or database. FTP handles this exceptionaly well.

At my site, we currently have 9 SFT III systems, and we are installing 2
VINCA systems at a new site. this choice is not because we do not want
to use SFT III anymore, but simply because we need NT as an SQL machine
and Vinca provides the closest solution to SFT.

My final view....SFT III with thoughts to Clustering in the future. As
for that, External RAID disks on each server will allow for a much
better upgrade path towards Clustering whenever you decide, and if you
decide to move.

---------

Date: Tue, 16 Dec 1997 11:31:02 -0600
From: Dave Kearns <dkearns@VQUILL.COM>
Subject: Re: SFT III vs. Vinca

>1. With the soon to be availability of Moab, SFT III will no longer be
>developed. This of course means that new patches etc, might cease to
>support SFT III, and this is a very big issue.

Not quite true. While NetWare 5 (aka Moab) will not have an SFT III
option, the marketing info for Orion (the code name for cluster
services based on Wolf Mountain, which will run only on NetWare 5)
indicate that NetWare 4 and SFT III will continue to be available.
Since we've just seen NetWare 3.12 updated, I wouldn't write off SFT
III on NetWare 4.11 just yet.

---------

Date: Tue, 16 Dec 1997 16:16:29 -0500
From: Jim Ryan <ryan@JIMRYAN.COM>
Subject: Re: NOVELL Digest - 16 Dec 1997 - Special issue

Re: #5.  This is not true.  Our Fault Tolerant NT server will do this.
WWW.MOD.COM

---------

Date: Tue, 16 Dec 1997 13:10:00 -0400
From: "BURTT, PETER (AEL)" <PBURTT@GOV.NB.CA>
Subject: Re: SFT III vs. Vinca

I've been running SFTIII for over a year now, and I'll give you the
same advice I gave a colleague a couple of weeks back.

SFT III is complicated, and not well documented (in my opinion.)
There were some very good TIDs on the Novell web site,

Here's what I consider to be important SFTIII tips... Some are from
experience, some are from reading.

 - make sure that the hardware in the two servers is identical, i.e.
  processor, motherboard, RAM, hard drive controller, etc.

 - some people set up the hard drives in a RAID configuration on an
  SFTIII box, but you're allready mirroring drives across the two
  servers, so why waste the storage and lose speed? I've got my discs
  striped into a single, non-redundant system drive, so that large
  reads are spread across multiple discs. Nice and fast!

 - try and leave yourself at least a couple of weeks to play with
  SFTIII and get comfortable with it before you put mission-critical
  stuff on it. It's kind of strange to work with, most things are
  just like normal NetWare, and then you find something that requires
  a different approach. It's better to find that sort of thing on a
  test server, I played for a month before I dared convert AEL_HEAD3
  into the main file server.

Here are some of the shortcomings of SFTIII.

 - SFTIII is designed to protect against hardware failures. If a
  software problem occurs, then it happens in real time on both
  servers, and they both crash in real time.

 - SFTIII doesn't allow you get a lot of the stats in MONITOR.NLM
  like LAN driver stats, process utilization stats, process memory
  stats, etc etc. It makes troubleshooting lots of fun.

 - don't even try to set up backup hardware on an SFTIII server, use
  a normal NetWare server for that. We kept the DAT changer on our
  old Dell 486/66 (AEL_HEAD1) and it does our backup.

 - setting up TCP/IP on SFTIII is way more complicated then you would
  think, so we didn't bother. We left TCP/IP and NetPrint on
  AEL_HEAD1.

Not that I don't like SFTIII, but you should be aware of what you're
getting into...

------------------------------

Date: Wed, 14 Jan 1998 13:38:47 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Moab Installation Requirements

The basic requirements will be the same as IW if not slightly less due
to the fact that there will be, or it was stated that there will be NSS
(Netware Storage Services) as an integral part of the MOAB makeup. This
of course allows for less memory to be used for FAT's etc. As well as
the way NSS mounts disks, you should be able to mount much larger disk
spaces in much much less memory.

------------------------------

