Path: utzoo!attcan!uunet!lll-winken!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!mcnc!beguine!durham!robinson
From: robinson@durham.med.unc.edu (Gerard A. Robinson)
Newsgroups: comp.databases
Subject: Re: Use of INGRES in a SUN environmnet
Message-ID: <1090@beguine.UUCP>
Date: 18 Sep 90 02:30:49 GMT
References: <1990Sep17.150529.4468@cs.umu.se>
Sender: usenet@beguine.UUCP
Reply-To: robinson@uncmed.med.unc.edu (Gerard A. Robinson)
Organization: UNC-CH School of Medicine, Office of Information Systems
Lines: 66

In article <1990Sep17.150529.4468@cs.umu.se> krn@cs.umu.se (Kenneth Nilsson) writes:
>
>We are now installing INGRES version 6.2 (including INGRES Net on SUN 
>(4/490 servers and SPARC SS1 diskless work stations) and have some questions 
>concerning the best way to organize the use of INGRES for a large number 
>of students.

Please note that there are significant problems with INGRES/NET under 6.2 of
INGRES.  There are restrictions in the number of user logins it will
maintain in memory.  My best understanding is that the number maxes out at
128.  Also 6.2 does not have any standard way of supporting diskless
clients.  6.3 has a much nicer setup for them, and some corrections to /NET.
I'd recommend getting it first.  I'll refrain from flames :-)

>
>1. Registration and deregistration of students as users of INGRES/Net.
>   INGRES should be available for each of the students (about 200 students)
>   from each work stations (about 30). As we have understood it, a
>   student must register as a user of a dbms on a certain server each time 
>   when he starts using a new work station. Since most of the students are

Actually a user needs to register his/her login & password for the database
server at each workstation.  There is no INGRES/NET relationship to database
except, of course, as relates to which db on which server.  This is similar
to 5.0 INGRES/NET's creation of a .ingnetSERVERNAME file for each server.
The difference is that it is stored in a centrally maintained file.

>   casual users of INGRES we would like to avoid the registration on the 
>   net. Is there any clever way to achieve this? Note that each user is 
>   supposed to use his own private database. 

The only thing that I can suggest is that you use the 'homogeneous'
networking available with INGRES.  Each user would be required to get from
the server the port number of the iidbms process for that machine(and db
if multiple servers).  S/he then would need to do (presuming csh):

setenv II_DBMS_SERVER dbserver::1034

presuming that 1034 is the port number of the iidbms process (the port 
number shows up under "ps ax").  Alternately, you could set this for a
client as a whole by making the setenv command an ingsetenv command.  (NOTE:
under 6.2 you're going to have to hack up some way for each client to have
its own ~ingres/files/symbol.tbl if you run INGRES/NET.)  Since it bypasses
/NET there's no login information to be stored/maintained.

>2. When using INGRES Net a number of processes are presupposed both on the
>   clients and the server (e.g. iigcc and iigcn). How often does any of 
>   these processes "die" ?

Only at shutdown.

>3. Which are your experience of the load on the server/network when for 
>   example 15 - 20 students are developing applications by means Application 
>   By Form, etc. simultaneously. 

We support 9 programmers doing development on a SS1 (acting as server to
other clients) with little problem.  The network traffic is the worst when
doing the actual compiles.

>4. Have you any experience of Windows 4GL in an XWindows environment?
>

I've had some contact with a beta-test version of the product and it seems
quite nice.  I am, though, holding out for an OpenLook version of it.

Thanks ... Gerard Robinson, UNC-CH Medical School Information Systems.