krn@cs.umu.se (Kenneth Nilsson) (09/17/90)
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. 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 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. 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" ? 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. 4. Have you any experience of Windows 4GL in an XWindows environment? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + + Kenneth Nilsson + usenet address: + + Institute of Information Processing + krn@cs.umu.se + + Department of Administrative Data Processing ++++++++++++++++++++++++++ + University of Umea + telephone: + + S-90187 Umea + +46 90 - 16 56 30 + + Sweden + fax: + + + +46 90 - 16 61 26 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
robinson@durham.med.unc.edu (Gerard A. Robinson) (09/18/90)
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.
csb@gdwb.oz.au (Craig Bishop) (09/18/90)
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. >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 > 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. Major pain in the rear end, but the way they have designed it, on *EACH* workstation that a student uses that student must Authorise his account. INGRES makes no use at all of BSD network authorisation via the hosts.equiv and .rhosts files. If someone has a better way please tell me. We are running 6.3 on SUNOS 4.1 and the same situation still exists. I have questioned many people in INGRES about this and there seems no other way. Apparently there is a produce due for release in the next 6 months or so call (I think) "NetView" which is supposed to resolve some of these problems. >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" ? Almost never. The major problem I found was sometimes they did not start up for unknown reasons. And once they caused our server to stop in it tracks because on all the clients (INGRES calls them frontends) which had a database active the "iigcc" program started looping on something and was sending enourmous amounts of data to the server (backend). Once I found out what was happening killing and restarting the "iigcc" processes on the clients fixed things. >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. Don't know. >4. Have you any experience of Windows 4GL in an XWindows environment? Very soon. -- Craig Bishop Geelong & District Water Board Phone: +61 52 262506 61-67 Ryrie St Geelong Fax: +61 52 218236 Victoria 3220 Australia -- Craig Bishop Geelong & District Water Board Phone: +61 52 262506 61-67 Ryrie St Geelong Fax: +61 52 218236 Victoria 3220 Australia
johan@cwi.nl (Johan Wolleswinkel) (09/18/90)
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. > [ ... ] >+ Kenneth Nilsson + usenet address: + >+ Institute of Information Processing + krn@cs.umu.se + We have the same situation here: lots of Sun workstations (ca. 80), with lots of users (ca. 200) which will occasionally use an Ingres application, preferably from their own workstation, but in principle from any. It turns out, that version 6.3, which is already available, is much better tuned to this situation. Ingres environment variables can be set globally for all workstations, the files-directory can be (easily) shared, there is a new directory in the Ingres-dir.tree for the client-specific information. If you intend to start using 6.2 I would strongly advise to switch straight to 6.3. The problem of the host-specific netu-information still exists in this version. It's quite amazing, that one of the strong points of Ingres (the easy way of sharing DB's among different processors), is bothered so much by a seemingly simple administrative matter. We expect to solve the problem by linking the corresponding client-specific netu-files; this may cause problems in case of parallel update of netu-information, but prefer this very small chance over the other apparent approaches: - having each user run for each workstation (80 !) the tedious netu-sequences, OR - having each user keep his own administration on which workstation he ran allready netu, and running it for the others when needed, OR - having each user be confronted by the terrifying sequence of Ingres messages in case of running an application without a netu. However, we haven't got any experience with this setup, and are interested in other solutions (and finally of course in a real solution from Ingres!). -- Johan Wolleswinkel CWI, Postbus 4079, 1009 AB Amsterdam, Kruislaan 413, The Netherlands Phone: +31 20 5924122 Fax: +31 20 5924199 Telex: 12571 (mactr nl) Internet: johan@cwi.nl or ...!hp4nl!cwi.nl!johan
robinson@durham.med.unc.edu (Gerard A. Robinson) (09/19/90)
>We expect to solve the problem by linking the corresponding >client-specific netu-files; this may cause problems in case of >parallel update of netu-information, but prefer this very small >chance over the other apparent approaches: I should have mentioned yesterday that we do already do this (link the various client IILOGIN files together). The issues with this are the same with any unlocked file that gets read into memory, the version that writes it last is the "correct" one. I.E. you should take steps to make sure that the netu utility is run only on one system, and that the net servers are restarted periodically in order to read in the new entries. If you add a name on one system, then you add it only there and it possibly can be overwritten by some other entry from some other system. (At least that's the way it seems to work, I'd dearly love for someone at INGRES to clarify this.) If you update on a server then the client doesn't see it until its iigcn and iigcc are restarted. Gerard Robinson ... UNC-CH School of Medicine, Office of Information Systems