t_anstey@darwin.ntu.edu.au (04/21/91)
This is a posting that I hope will provoke some comment as we need some outside and knowledgeable ideas on the topic to help us on our way. I am sending it to a number of LISTs as well as NEWS so do not be surprised to see it again. We are facing stringent financial times, in common no doubt many people, and our current mainframe sytems are just too expensive. Solution, lets down size to say a Novell LAN running Netware 386. The problem is that many people will will not believe that you can run large scale multi access systems with Novell. This is nonsense people have been doing it for years and there are lots of examples. We even have a few ourselves but some people do not want to believe it. Everyone knows the world is flat. The one problem I have with Novell and always have had is that of terminal access. In time all our users will be PC based so no problem, but I have to live thru the interim and have to provide for users with terminals who are not likely to get a PC and LAN card in the near future. There is also the very genuine one off remote user whom will never be connected to the LAN proper. There is PCANYWHERE etc and a myriad of solutions none of which I like much. They all have to do with driving a terminal from a PC connected to the LAN. We have even had PC XTs with 'bank select' memory options, (that puts me in the ancient age group for starters). This was all done in software, and each PC XT could handle up to four or more concurrent terminal sessions through one network card. The number of terminals was limited only by the memory size in the PC. It worked well, but to me it was a complete kludge. If I understand Netware 386 correctly then a solution to this may be at hand. I should say my understanding of Netware 386 is sketchy at best, hence my request for help on this. All our system development for Novell was done using a multi-user PC based database system which would run on PCs, Novell, UNIX, ULTRIX, XENIX, VMS etc. By this I mean the system could be developed on a PC and then copied to say a VAX and it would work without modification. I tried this and it worked, much to my surprise at the time. The actual files that contain the 'executables' and 'data' on the PC were uploaded to a VAX running VMS, via KERMIT, and they ran without any need for re-compilation or conversion. The reverse was also true. The system could be developed on a VAX and moved via KERMIT to a PC and off it would go. At the time this was a curiosity to me as I did not have any need to run the system on a VAX. I understand that in Netware 386, there is support for the Sun PC-NFS option. The server provides common disk storage to a UNIX box via TCP/IP but not the reverse ie the disk is attached to the server but is accessable from Netware and the UNIX box. Now this being the case we could have a Netware 386 server with BIG SCSI drives running a LAN and providing a PC-NFS type service to a UNIX box. The UNIX box would service terminal users via TCP/IP ethernet and our existing DECSERVERS. If the data and executables were being shared and the database system was loaded on both the server and the UNIX box, then in theory we are home. We have data and applications being shared between a UNIX box to handle the terminal users and a Novell Netware 386 server to handle the PC and MAC users on the LAN. I may not have the complete story on this as I have no firm information on Netware 386 other than news and trade sources. Obvious question is why go to all this trouble? Well the updating function of the common data would be done on the LAN with a processor being dedicated to each transaction in true LAN fashion, whilst in our case anyway, the ad hoc queries come from the terminal users and present a lighter load also much more spasmodic use, so a multi-user option makes sense. If anyone can pick holes in this by virtue of knowing more about Netware 386 than I do, not hard!, then I would love to hear from you. As I feel this could be a very real possibility and I would hate to waste my time on something that could never work. Tery Anstey Computer Services Northern Territory University Darwin, NT Australia INTERNET: T_ANSTEY@DARWIN.NTU.EDU.AU - "The LAN at the end of the INTERNET"
jkt@seneca.Sed.Novell.COM. (Jack Thomasson) (04/24/91)
>>>>> On 21 Apr 91 05:40:25 GMT, t_anstey@darwin.ntu.edu.au said:
Tery> I understand that in Netware 386, there is support for the Sun
Tery> PC-NFS option. The server provides common disk storage to a
Tery> UNIX box via TCP/IP but not the reverse ie the disk is attached
Tery> to the server but is accessable from Netware and the UNIX box.
we support NFS but not PC-NFS. PC-NFS is a Sun product that allows
PCs to access NFS exports as local disk drives (like mapping in
NetWare), throwing in (away?) user authentication, security, ... (i've
heard). the server you mention above would be a NetWare 3.11 server.
Tery> Now this being the case we could have a Netware 386 server with
Tery> BIG SCSI drives running a LAN and providing a PC-NFS type
Tery> service to a UNIX box. The UNIX box would service terminal users
Tery> via TCP/IP ethernet and our existing DECSERVERS. If the data
Tery> and executables were being shared and the database system was
Tery> loaded on both the server and the UNIX box, then in theory we
Tery> are home. We have data and applications being shared between a
Tery> UNIX box to handle the terminal users and a Novell Netware 386
Tery> server to handle the PC and MAC users on the LAN. I may not have
Tery> the complete story on this as I have no firm information on
Tery> Netware 386 other than news and trade sources.
right. NetWare 3.11 with NetWare NFS and NetWare for Macintosh allows
concurrent file access from PC-DOS, PC-OS/2, Mac, and Unix.
Tery> If anyone can pick holes in this by virtue of knowing more about
Tery> Netware 386 than I do, not hard!, then I would love to hear from
Tery> you. As I feel this could be a very real possibility and I would
Tery> hate to waste my time on something that could never work.
your choice of database could be limiting, depending on which way you
go. otherwise things are looking up.
Tery> Tery Anstey
Tery> Computer Services
Tery> Northern Territory University
Tery> Darwin, NT
Tery> Australia
Tery> INTERNET: T_ANSTEY@DARWIN.NTU.EDU.AU - "The LAN at the end of
the INTERNET"
--
---------------------------------------------------------------------
Jack Thomasson :{)} jkt@Sed.Novell.COM
Novell, Inc. / MS C-25-1 / 122 East 1700 South / Provo, UT 84606
Phone: (801)429-7604 FAX: (801)429-5511
"WARNING: the comments do not necessarily reflect the implementation"t_anstey@darwin.ntu.edu.au (04/24/91)
Since my previous posting on this subject there have been a number of developments on this front. A Novell person has responded to NEWS confirming that Netware V386.1 will support NFS, not PC-NFS as I mistakenly said. This allows common access between a Novell file server and a UNIX box via TCP/IP. I am very grateful for the interest and could not wish for a better confirmation. I have also discussed the matter with the producers of the database package and they confirm that if Netware 386 and the UNIX system, they vouchsafe SCO/UNIX, are both running on INTEL based systems then the database files can be shared successfully by their database system running on both systems. They did recommend that I recompiled the executable for each environment but the source code remains the same. I can live with that, and it would be foolish not to have the executables resident on both systems, as why share files needlessly? The comment was also made that the choice of database package could be a limiting factor and that could be so. The database I have in mind is cheap and I have used it to good effect for four years on a Novell platform and have NEVER EVER struck a bug in it. (They do exist but I have either found a work-around or never used that option). This then is not as problem to me. The problem of terminal access has always been a real bug-bear in a LAN, that and the dreadful DOS 640 KB memory limit. This new option means we can migrate to a LAN in the high intensity use areas, yet not write off our investment in terminals and equipment. There are some problems like how do we print remotely using DECSERCVER ports but I think I have an answer to that. This presents us with a very viable low cost (compare the cost of a VAX with VMS to say a '486 running SCO/UNIX plus a '486 running Netware 386) and we are going to take this very seriously. Especially as it preserves our investment in our network equipment. A problem I do have, and I suspect I am not alone, is that my management keep saying, undoubtedly motivated by detractors; "If it is such a good idea, why are others not doing it ?" Well someone has to be first, which sounds a bit lame. There are two quotes that sum up my position on this. "The leading edge of technology, is the brink of disaster" (ie never be first) and "All great truths, start as great heresies" (ie after enough time passes anything is acceptabe) In view of this can I have some ideas and thoughts on this concept, and in particular, WHY WILL IT NOT WORK !! Tery Anstey Computer Services Northern Territory University Darwin, NT Australia INTERNET: T_ANSTEY@DARWIN.NTU.EDU.AU - "The LAN at the end of the INTERNET"