PHYSICS - ASTRONOMY DEPARTMENT
COMPUTING PLAN
DRAFT 5/6/98

TABLE OF CONTENTS

I.   Mission of PA Computing            1
II.  Current Status                     2
       A. Computer Platforms            2
       B. Support Staff                 2
       C. Oversight                     3
       D. Strengths                     3
       E. Weaknesses                    4
III. Objectives                         5
IV.  Recommendations                    6
       A. Administration                6
       B. Hardware                      8
       C. Software                      8
V.   Appendices                        10
       A. Current Computers (3/11/97)  10
       B. Supported Hardware           12
       C. Supported Software           14
       D. Examples of current issues   15
       E. Major projects: 1997 - 2000  19

I. MISSION FOR PHYSICS - ASTRONOMY COMPUTING

The faculty, staff, and students in the Department of Physics and Astronomy need to have access to state-of-the-art computer resources to accomplish their goals. The goal of the Physics and Astronomy Computer Support System is to enable all department members to make effective use of computers. This will be accomplished by providing an efficient, robust computing environment for the department and by assisting individual users to operate their computers.

II. CURRENT STATUS

Nearly all of the faculty, staff, students, and visitors in the Department use computers in some aspects of their work. Major usage is for: electronic mail, editing, programming, network access, number crunching, organizational tools, data analysis, data acquisition and recreation. This usage supports teaching, research, administration, student course work and individual needs. It is performed on department servers, group and individual computers -- workstations, PCs and MACs. To facilitate computer use in support of the department's mission the department provides computer support for department faculty, staff and students.

A. Computer Platforms

There are currently about 300 computers used in the department -- workstations, PCs and MACs, manufactured by over a dozen vendors and employing more than two dozen different operating systems (Appendix A).

The PA department has two departmental servers: a SUN 167 MHz ultrasparc with 128 Mbytes of memory and 16 Gigabytes of disk space running Solaris 2.5.1 unix operating system and a DIGITAL 200 MHz alpha with 160 Mbytes of memory and 17 Gigabytes of disk space running VMS 6.2. The AST, CMP and HEP research groups each have clusters of workstations that support their research activities.

B. Support Staff:

Support for computer use in the department is provided by three full time staff members, three staff members who devote part of their time to computer support and five students. Supporting current computer use in the department frequently requires our full time personnel to work more than 40 hr/wk, and support needs are likely to increase in the future. The support staff, with the current distribution of their effort, are:

Full time devoted to computer support:

       George Perkins - Computing Applications Physicist
              -- troubleshoot hardware and software problems (35%) 
              -- maintain department network (25%) 
              -- install and maintain software (15%)
              -- install new hardware (15%)
              -- provide information (10%) 
       Darlene Salman - Microcomputer Hardware/Software Coordinator
              -- trouble shoot teaching lab computers (60%) 
              -- install and maintain teaching lab computers (20%) 
              -- trouble shoot non-teaching lab MACs (5%) 
              -- install and upgrade non-teaching lab MAC software (2%)
              -- answer MAC questions (3%)
              -- maintain documentation for laboratory courses (5%) 
              -- instruct in proper lab computer use (5%) 
       Margaret Wilke - System Manager
              -- maintain and manage department computers (30%) 
              -- install and manage group and individual computers (30%) 
              -- administration (20%) 
              -- maintain network (10%) 
              -- assist groups and individuals with purchases (10%)
Part time devoted to computer support:
(percentages refer only to fraction of time devoted to computer support)

       Mark Olson - Teaching Lab Technician
              -- manage teaching labs 
       Bob Raine - Electronic Technician
              -- PC hardware repair 
              -- network cabling 
       Barry Tigner - Electronic Shop Manager
              -- (70% of total time on computers)
              -- install and upgrade PC hardware and software (43%)
              -- answer PC questions (36%)
              -- trouble shoot PCs (21%)

       Student Employees:

          Jazcek Braden
              -- Maintain printers; primary printer support
              -- Secondary helpdesk coordinator.
                    Handle Helpdesk questions and requests.
              -- Install application software
          Jason Hicks
              -- Astronomy VMS cluster backup
              -- CTEQ NeXts
              -- Web FAQs for recurring helpdesk requests
          Nathan Paquette
              -- Windows 95 support
              -- Printer support
              -- Install software
              -- Set up systems
          Don Reed
              -- Perform VMS, Unix and Windows NT backups.
              -- Primary helpdesk coordinator; prepare weekly summaries.
                    Handle Helpdesk questions and requests.
              -- Install application software
          Chris Wilkinson
              -- Maintain and upgrade PCs in B2 N. Kedzie.
              -- Maintain and improve PA Departmental Web pages.
              -- NeXt cluster backups and troubleshooting.
              -- Handle Helpdesk questions and requests.
              -- Assist with training of other Computer Assistants.

C. Oversight

Computer operations in the Physics and Astronomy department are administered by the Computer Operations Committee (COC) which oversees the departmental servers and support for research, secretarial and individual computers and the Academic Operations Committee (AOC) which oversees the teaching laboratory computers along with other teaching related responsibilities. The computer related aspects of the AOC's work are coordinated with the COC.

D. Strengths

The department provides accounts for all faculty, staff and graduate students on its VMS and UNIX servers. These provide email, web browsers, editors, compilers and other application software (see Appendix C). In addition, many faculty have individual workstations and the rest have PCs or MACs with which they access departmental, university and external computer resources. Graduate students have access to computer resources through individual workstations, PCs, MACs and terminals on their desktops or via a public VMS alpha and several Xterminals. All secretaries also have PCs or MACs on their desks.

The MSU Computer Laboratory provides powerful high performance computers for calculations that require more memory or higher speed than is available within the department. Currently the most powerful of the central site computers is a SUN 30 processor, 250 MHz, ultrasparc with 7.5 Gigabytes of memory and 26 Gigabytes of local scratch disk space.

The computing staff are dedicated to improving computing in the Department, eager to tackle new projects, and continually working to increase their knowledge base. They work effectively both independently and as members of ad-hoc teams. Each staff member has a unique background and experience which helps to define his or her own on-the-job specialties.

Others in the Department have computer expertise in various areas and assist the computing staff. People such as Phillipe Laurens, Dan Edmunds, Steve Gross, Jim Linnemann, Bob Stein, Marc Conlin, Michael Hamlin, and Ed Loh (to name a few) have often been invaluable in helping the computing staff to complete projects and resolve problems. Hence, one of the Department's computing strengths is its community of experts, all supporting each other.

E. Weaknesses

The Department's most scarce computer resource is its experienced, computer personnel. Expectations for computing support in the Department are diverse and demanding. The demand for new features/hardware/expertise seems to be insatiable. This produces increasing and conflicting demands on staff time. There are insufficient support staff to provide all of the services desired by the department computer users. People are disappointed when their requests for help are not handled quickly. Long range projects have low priority and take a long time to complete.

Specific problems are:

  1. Large number and variety of hardware and software. (see Appendices A, B and C)
  2. Aging equipment that needs upgrading or replacement.
  3. Interrupt driven work schedule.
  4. Difficulty enforcing priorities. (see Example, Appendix D.3)
  5. Slow response to some help requests.
  6. Backlog of projects that are in process or undone.
  7. Inadequate tracking of help requests.
  8. Long time to complete long range projects. (see Example, Appendix D.6)
  9. Delays in maintaining and upgrading of departmental software. (see Example, Appendix D.4,5)
  10. Undertaking commitments with unanticipated and untenable consequences. (see Example, Appendix D.7)

III. OBJECTIVES

  1. Department network:
    Provide a reliable backbone network, routers, repeaters, and connections. Provide inter-operability among different platforms and printers.

  2. Department servers and printers:
    Provide fast and secure departmental servers and printers, with minimal downtime. Run standard compilers and basic applications. Backup on a regular, frequent schedule.

  3. Group and Individual Computers

    Coordinate all computer purchases.

    Install computers for faculty, staff and students.

    Maintain certain hardware and software. Level of support depends on type of platform and age. As computers become outdated their maintenance level will decrease.

    Upgrade software, firmware, and hardware. Upgrades will be performed only when there is a compelling reason and there is a rational upgrade path. Computer owners will be required to purchase all necessary components to make the upgrade practical (e.g. additional RAM or larger disk may be required to upgrade an operating system).

    Assist with remote access.

    Handle "immediate" needs quickly.

  4. User support:
    Answer user questions in a timely manner.
    Provide local documentation and references.

  5. Management:
    Provide pro-active management of computer systems, networks, and applications. (Find trouble spots and fix them before the computer user even knows about it.)
    Handle computer requests in an orderly and predictable manner. Complete longer-term projects at a regular pace.

IV. RECOMMENDATIONS

A. Administration

  1. Additional personnel are required to handle the ever increasing requests for computer support. The top priority is to hire an additional senior computer support staff person. We need people whose primary responsibility is: department network, unix, NT, PCs and MACs. (VMS is a temporary need for the next year or so.) Staff should have additional expertise beyond their primary area of responsibility so they can cover for each other. (This will allow more focused expertise, enable more student assistants to be supervised, speed up response times, reduce the backlog of projects and facilitate the maintenance and upgrading of departmental network, hardware and software and the completion of long range projects.)

  2. Enforce prioritization according to the principle:

    Highest Priority: department network
    High Priority: severe problems affecting many people
    Lower Priority: jobs affecting fewer people or requiring more time
    Research efforts by faculty with grants take precedence over those without.

    The computing staff installs, manages and maintains departmental computers and the building network. The network, department servers and teaching laboratory computers have the highest priority. The staff also assists research groups, individuals and secretaries to install, manage and maintain their own workstations, PCs and MACs at a lower priority. Computers critical for departmental functions will be given higher priority for assistance.

    Prioritization will be done by the support staff administrator with oversight by the COC. (This will hopefully maintain an agreed upon prioritization of help requests.)

  3. The computer staff now functions in a collegial fashion with an informal sharing of work and organizing of tasks. Because the complexity of the support effort has increased, one of the staff or faculty should act as the staff administrator and organize the tasks that fall outside of or overlap the specific responsibilities of the individual staff members. This person will also manage the student [support, helpdesk] staff. (This will improve the efficiency of the support operation, help enforce priorities, reduce interruptions, ensure allocation of resources to long range projects, and prevent a drift into unanticipated and untenable commitments.)

  4. Encourage management of computers in small groups of like computers, which can share common resources. Groups may hire their own support staff to work exclusively on their own machines. This support person will coordinate their activities with the central department support staff. (This will increase the ease of maintaining the large variety of hardware and software in the department and will speed up the response time for those groups.)

  5. In order to pay for the increasing number of personnel required to support the department's computing, additional revenue needs to be generated in order to higher an additional computer support person.

    (This will increase the range of computer services that can be provided, e.g. NT and Linux, and speed up response times, reduce the backlog of projects and facilitate the maintenance of departmental software and the completion of long range projects.)

  6. Assistance with upgrading hardware and software will be provided when there is a compelling reason and a rational upgrade path. Only hardware and software that is in common use in the department and that the computer staff has experience with can be supported. As platforms age and support by their vendors decreases the level of support provided will also decrease. (This will eliminate unneeded upgrades and reduce the requests for support.)

  7. Faculty intending to use computers (PCs, MACs or Department servers) in their courses need to plan ahead and provide the computer support staff sufficient lead time to determine the best way of providing the resources needed for the course, obtaining any necessary hardware and software, installing it and verifying its operation. Requests for teaching computer resources must be approved by both the AOC and COC. Although teaching is a high priority for the computer staff, last minute requests require an exorbitant amount of staff effort and hence can not be undertaken. Teleconferencing courses, at present, require an especially large staff effort. If possible, central MSU facilities should be used. If departmental facilities are used, extra funding may be needed to provide the extra support. (This will reduce the workload on the support staff and relieve the problems of slow responses, backlog of projects, long time to complete long range projects, and delays in maintaining and upgrading of departmental software.)

  8. Institute a department help system which maintains a database of all requests for support, their current status, place in queue, and the priority assigned to them, as well as past problems and solutions. Write up information on common problem threads. This information would be available to everyone via the department web pages. The database would be maintained by the student employees. (This will improve the tracking of help requests.)

  9. The teaching laboratories contain valuable computer and other equipment. Hence the laboratory rooms should only be used for scheduled laboratory classes and, with approval of the AOC, for other scheduled and supervised non-laboratory classes and organized groups. Laboratories should not be open for individual use of the computers and equipment. No computers should be removed from the laboratories. (This will reduce the work load on the support staff and help to relieve the problems of slow responses, backlog of projects, long time to complete long range projects, and delays in maintaining and upgrading of departmental software.)

  10. Additional senior personnel will enable supervision of additional student employees. Students will be hired as freshman, whenever possible, with the intention of training them and retaining their services for their entire time at MSU. As their experience increases, the sophistication of the services they can provide will increase. Students may be contracted out, for part of their time, to provide exclusive support to individual research groups. (This will increase the number of support staff and hence speed up response times, reduce the backlog of projects and facilitate the maintenance of departmental software and the completion of long range projects.)

  11. Certain support tasks require significant blocks of time to master the necessary information and perform the task. Therefore, certain of the support personnel (Perkins and Wilke) will set aside a block of time each week during which they will not be available for support work except in cases of department emergencies. These times will be publicized to the department. This will enable them to focus on more complex and longer range tasks. (This will reduce interruptions to the work schedule and shorten the time to complete long range projects.)

  12. Maintain records of warranty information on all platforms and peripheral equipment in the department. This should be done by group secretaries. (This will ease the maintenance of individual PCs, MACs and workstations.)

  13. Provide basic information on how to seek help via login messages on department servers. (This will improve the tracking of help requests.)

  14. Request the MSU Computer Laboratory to install X-windows software as part of their common software suite on the microlab computers.

  15. The move to the new building presents an opportunity to plan a well thought out, rational computing environment. A discussion of the computer facilities desired in the new building should be undertaken with the different user groups within the department. Following this collection of information, a plan should be drawn up for the computing environment in the new building.

B. Hardware

  1. Support only a small variety of platforms (Appendix B). (This will reduce the workload on the support staff and hence speed up response times, reduce the backlog of projects and facilitate the maintenance of departmental hardware and the completion of long range projects.)

  2. All computer acquisitions (by the department, staff, groups, for teaching or by individuals) requiring support must be reviewed by the computer support staff and the COC. All network connections and disconnections must be performed by the staff. Approval of an acquisition does not necessarily imply full support, which depends on the type of hardware and its use. (Currently supported platforms are listed in Appendix B.) (This will minimize the variety of hardware and software in the department.)

  3. Be very conservative in purchasing new platforms and upgrading existing systems (department, teaching labs, groups, staff and individuals) in order to minimize new information the support staff must master and to reduce the flux of support tasks. (This will minimize the variety of hardware and software in the department and also the workload on the support staff.)

  4. Phase out obsolete equipment. (This will reduce the amount of aged equipment.)

C. Software

  1. Support only a small variety of operating systems and applications (Appendix B and C). (This will reduce the workload on the support staff and hence speed up response times, reduce the backlog of projects and facilitate the maintenance of departmental software and the completion of long range projects.)

  2. New commitments for computer support, whether they originate with the department chair, the teaching faculty or the computer users, should be discussed by the COC prior to their being undertaken. An evaluation of the required resources to provide the service should be made. The significance of the requested service should be assessed and if necessary this should be discussed with the Chair and ADCOM. As an alternative, the desired resource may be available through the Computing Laboratory. (This will prevent a drift into unanticipated and untenable commitments.)

  3. Only a small set of compilers, core applications and utilities will be supported and maintained by the staff on the department servers. Users will be provided an area to install and maintain software that will be available for general use. Requests for staff maintained software must be approved by COC, which on approval, will assign it a priority for installation and maintenance. (This will minimize the variety of software in the department.)

  4. Software can be installed by PA Departmental computer staff for an hourly fee. All installed software must be properly licensed on the computer for which it is installed. No support will be given for unlicensed copies of software or for software versions that are out-of-date (except to upgrade to current versions). (This will reduce the workload on the support staff and relieve the problems of slow responses, backlog of projects, long time to complete long range projects, and delays in maintaining and upgrading of departmental software.)

  5. Install a common set of core applications on all teaching computers providing the basic functionality needed for most uses. Additional, project specific software, will be installed as needed when enough lead time is given (June 1 for fall and Oct 1 for spring semester). (This will reduce the workload on the support staff and relieve the problems of slow responses, backlog of projects, long time to complete long range projects, and delays in maintaining and upgrading of departmental software.)

  6. Phase out VMS. (This will reduce the variety of supported operating systems and software.)

APPENDICES

APPENDIX A. Current Computers (3/11/97) 

                       DEPARTMENT COMPUTERS
                          11 March 1997

PLATFORM                 OPERATING SYSTEM    NUMBER (+- 1 or 2)
--------------------     ----------------    -------

DEC alpha                VMS V6.2+,           5
                         OSF/1 V3.2+         10
                         WinNT V3.5.1+        3
DEC VAXStation 3100/40+  VMS V6.2+            3
                         ELN                  1  (more from FNAL soon)
DEC VAXStation (<3100)   VMS V5.5-2+          5
DEC MIPS                 Ultrix V4.2A+        9

SUN sparc, ultrasparc    Solaris 2.4+        10
SUN sparc                SunOS 4.1.3          5

SGI                      IRIX 6.2+            5

IBM RS/6000              AIX V4.1.4+          7

NeXTStation              NeXTStep V3+        18

PC  Pentium              Win95, WinNT        65  [1]
PC  Pentium              OpenStep             0
PC  486, Pentium         Linux 1.2+          13
PC  486, Pentium         NS/Intel 3.2+        1
PC  486, Pentium         WfWG 3.11 + DOS 6.x 87  [1]
PC  <486                 any                 10

MAC power PC             Mac OS 7.5.x+       30
MAC 68K                  MacOS 7.0+          14
MAC 68K                  MacOS <7.0           2

X-Terminals (Tektronix)  TEK Xpress V8.x+    14
X-Terminals (NCD)        NCDware              5

Dumb Terminals                              ~10

Printers HP4M+ (with int. jet direct)        28
         all others                          10  [2]
NOTES:

  1. The exact split between Win95/WinNT and WfWG is uncertain at the level of ten machines or so for two main reasons: (a) if a hardware or OS upgrade took place which didn't involve a network address change, the network database may not have been updated to reflect it; (b) some machines were upgraded to run Windows 95 or Windows NT without the recommended hardware upgrade to Pentium level; there is no place for these on the "supported hardware" table, so they're still counted in the WfWG group here; there are about 6 to 10 of these.
  2. The printer count includes only those which are directly on the network. There are almost a dozen others which are network-accessible via one protocol or another through the PC or workstation they are attached to. The "all others" printer category does include about 5 color HP DeskJets at the 1200C/PS and 1600CM level which are directly on the network.
  3. There are about 16 devices which would go into an "other" category if there was one (Amiga, OS/2, LynxOS, NG Sniffer, managed hubs, etc.).

APPENDIX B. Supported Hardware 

                       SUPPORTED HARDWARE
                          19 Feb 1997

PLATFORM                 OPERATING SYSTEM    SUPPORT   SUPPORT
                                             LEVEL     UNTIL
--------------------     ----------------    -------   ----------------

DEC alpha                VMS V6.2+,          high
                         OSF/1 V3.2+
                         WinNT V3.5.1+
DEC VAXStation 3100/40+  VMS V6.2+           medium    DEC drops support
                         ELN
DEC VAXStation (<3100)   VMS V5.5-2+         low       DEC drops support
DEC MIPS                 Ultrix V4.2A+       low       < 1999

SUN sparc, ultrasparc    Solaris 2.4+        high
SUN sparc                SunOS 4.1.3         low       SUN drops support

SGI                      IRIX 6.2+           medium    unknown

IBM RS/6000              AIX V4.1.4+         medium    unknown

HP                       HP Unix             none

NeXTStation              NeXTStep V3+        medium    <1999

PC  Pentium              Win95, WinNT        high
PC  Pentium              OpenStep            medium    unknown
PC  486, Pentium         Linux 1.2+          medium    unknown
PC  486, Pentium         NS/Intel 3.2+       medium
PC  486, Pentium         WfWG 3.11 + DOS 6.x low       early 1998
PC  <486                 any                 none

MAC power PC             Mac OS 7.5.x+       high
MAC 68K                  MacOS 7.0+          low
MAC 68K                  MacOS <7.0          none

X-Terminals (Tektronix)  TEK Xpress V8.x+    medium    unknown
X-Terminals (NCD)        NCDware             low       unknown

Dumb Terminals                               none

Printers HP4M+ (with int. jet direct)        high
         all others                          low
There are some older machines that are currently receiving high level support. It is anticipated that they will be upgraded or replaced over time.

Definition of terms:

APPENDIX C. Supported Software 

                 Supported Software and Add-on Software
                            19 Feb 1997

                              Operating Systems   
==================            ========================================
                              Windows NT/95,      Unix          VMS
                              Macintosh                        (alpha)
==================            ========================================
All Machines
==================            ========================================
TCP/IP                         X                   X
WWW browser                    X                   X
VT-100 terminal emulator       X                   X             X
MS Word                        X
MS Excel                       X
Virus scan software            X
Text Editors (vi,EVE/EDFOR)                        X             X
Login shells                                       X

==================            ========================================
Some Machines
==================            ========================================
TCP/IP                                                           X
Compilers (f77, f90, cc, c++)                      X             X
Math subroutine libraries                          X             X
TeX/LaTeX                                          X             X
Additional Text Editors                            X
      (emacs, xedit, Nedit)
X-Windows display              X                   X             X
      (often built-in to OS)
Postscript display             X                   X             X
      (GSview/Ghostscript)
WWW browser                                                      X
WWW helper applications        X                   X             X
Video conferencing             X                   X
Acrobat Reader                 X                   X
NetNews Reader                 X                   X             X
Graphics viewers               X                   X             X
Mathematica                    X                   X             X
MS PowerPoint                  X
perl                                               X
E-mail shell (elm or pine)                         X
Mathcad                        X
Backup software                X
Utilities                      X                   X             X
------------------------------------------------------------------------------------
Installed on a limited number of machines: Web Server (httpd), Multi-protocol network tunneling/routing/translating software (Samba, cap/arns/atalkad, M-bone routing).
======================================================================= On some machines = additional software which is frequently installed on some computers in the Department. Many other software packages and utilities are in use but are not included for this report. Software not on this list is not supported.

APPENDIX D. Examples of current issues

  1. Different types of computer usage are often integrated in a single problem for which help is sought from the staff.

    An astronomer wishes to provide high-resolution printed pictures relating to his research, to students that he teaches. He captures GIF images from a World-Wide-Web site, downloads them to his PC running Linux, manipulates each image with the 'xv' Unix tool, saves it as a postscript file, and prints it to a Departmental printer which is served by a VMS computer. During this process, some of the images do not print out and he uses electronic mail to contact the computer staff to help determine the cause of the problem. The staff member and the astronomer meet to discuss the problem, revise the procedure, perform some tests, and resolve the issue. This task used email, department applications, web access, and was performed in support of both teaching and research. At least three different computers were used to accomplish this task. Additionally, it was an "immediate" need (needed for the next day).

  2. An example of overlapping authority and lack of anticipation of needed resources.

    The AOC made plans to computerize one of the Physics labs in the fall of 95. The Chair obtained funding for the project from the Office of Computing and Technology. ADCOM formed a Task Force to determine the specifications for the project. The Task Force was composed of several faculty members and staff. Staff worked quickly and efficiently to set up the lab once the hardware was available. If everything had gone perfectly, the project would have been lauded as a wonderful example of adding computers to the classroom. However, several problems arose, and the AOC assumed that computer staff could "drop everything" and solve the technical issues immediately. Meanwhile, the COC required the same computer staff to make significant progress on "priority" projects on their list. Each interest group sees their resources (especially technical expertise) as being diluted by the other group. There are many "chiefs" who may make requests to the computing staff at any time. The current committee structure makes no requirement that the committees coordinate their activities or demands on resources.

  3. Example of the conflicting demands on the computer staff and the difficulty in enforcing priorities.

    A professor upgrades his PC so that he can run the latest versions of MS- Word, Excel, Netscape, etc. He decides to use Netscape's Mail Tool (a POP3 client program) and it seems to work ok at first using the Department's VMS server as the POP3 server. However, some mail is occasionally deleted by Netscape before it is read by him, so he asks for help from the System Manager. The System Manager informs him that the Department is not supporting POP3 mail on its VMS servers because of concerns about load, configuration issues, backups, remote access to mail, and support issues with the variety of POP3 client software on a variety of PC platform. However, there are a few people using POP3 mail via Eudora as a test and the System Manager suggests that he configure his PC similarly (with Eudora) since this is known to work better. However, the professor likes the features of the Netscape mail tool and asks for help with this anyway. The System Manager expects that if she turns down his request, he will either contact another staff member for assistance (run around the obstacle) or complain about the computer support he is receiving to others. The System Manager must try to fit in this project among other pending jobs. The "customer" with the greatest amount of displayed anxiety often gets the immediate attention of the staff, bumping aside other longer-term projects. There is a tremendous dis-incentive to delay assistance to the individual with an "immediate" need, since he/she is apt to (a) ask another staff member to do the same task (The staff then discovers that two or more people are working on the same request.) or (b) complain to the Department Chair or another person who may have influence in this situation.

  4. Examples of application software maintenance

    Application software installation follows a wide range of scenarios. The primary variable is the care that the original programmers put into the installation process. At the "good" end of the scale are installation packages which consist of the following:

    Typically, after reading through the documents, one just has to make a couple of small edits in configuration/setup files, and then issue a command or a simple set of commands, and the pre-set scripts take over and do the installation. Under Unix, when this is done, the program is generally now accessible to users who have the standard file search paths set up without further action. Under VMS, the last step is generally to put a file into the system startup sequence and to write a SETUP_XXX.COM file to define its logicals and symbols.

    Examples of such "good" packages include: -- Most software packages designed by companies for their own machines, -- Some commercial packages such as Netscape; -- Freeware utilities from NCSA, DECUS, GNU, MadGoat Software, etc. On the reverse side of the coin from "good" are the many "bad" packages; each one has its own particular flavor of badness: inadequate documentation, multi-levels of "readme" files and sequences of "make" commands, non-generic command syntax in Makefiles and installation scripts, insufficient testing (both in installing and in running) on diverse platforms, and, of course, bugs in the program.

    Among the packages which have suffered from such drawbacks are: -- numerous popular freeware utilities such as GhostScript, trn/xrn, pbmplus/NetPBM, and (most egregiously) TeX/LaTeX. Many "bad" packages can take weeks to understand and install (and some turn out to not be compatible with a particular version of OS or hardware variety after all, regardless of the documentation).

  5. Example of long time scale for upgrading/installing application software

    TeX/LaTeX is an example of a software package that is difficult to install. Its problem is multi-level readme and makefiles which need to be configured by hand for each particular platform. The VMS upgrade to TeX/LaTex2e was spread over an entire year. Although the files were copied from a working version on the Fermilab VMS cluster, it was still necessary to make local modifications and to define the necessary local logicals. The total amount of time used was only three days. However, it was difficult to set aside large blocks of time to do the work systematically, because of continual interruptions by other requests for assistance. Hence, the installation process was spread over many months. Even after a working version was in place, no announcement of its availability was made because a little further work remained to be completed. The installation of TeX/LaTex on the Solaris server also has been spread over an extremely long time. The official CDROM version did not install properly. Rather than obtaining a working version from a similar installation on campus, much time was spent correcting the problems. The long time to complete the upgrade on the VMS server and the installation on the Unix server was due to: the low priority given to the users request for LaTex2e and a unix version; the constant interruptions by many small requests and the inability to organize blocks of time to concentrate on the installation procedure; the overlooking of resources available from other MSU computer installations; the desire to master the entire process within the PA department; and the desire to present a fully tested and documented product for use by the department, rather than allowing some of the more experienced users to try it and find the problems needing correction.

  6. Example of long time scale for completion of long term projects

    The migration from a primarily VAX-based VMS cluster to a primarily Alpha-based VMS cluster (MSUHEP to DIRAC) took 17 months. The goals were set in August, 1994 to be:

    a. Minimum downtimes and minimum inconvenience to computer users.
    b. Move Departmental e-mail hub function to DIRAC.
    c. Recompile or duplicate nearly all functions on the VAX to run on the Alpha before turning off the VAX.
    d. Sell MSUHEP.

    New hardware had to be substituted for old and the operating system upgraded. Networking operations had to be reconfigured. DEC and third-party applications had to be ported. Applications required re-compilation and/or revision from source code. These included physics-content applications as well as utilities which were either "home-grown" or developed at other physics and public domain sites and ported to this environment.

    The project was successfully completed in a logical fashion. The goals of minimal downtime and minimal inconvenience to computer users were achieved, but the transition took much longer than expected because:

    a. There were many other ongoing demands on the time of the computing staff for other Departmental and individual computer projects during this period. Some examples are: the CMP OSF/1 cluster had to be set up; pads1 (our World-Wide-Web server) was unstable and had to be upgraded; the Abrams Planetarium joined the Department and had to be networked and supported; CAPA PC's had to be set up in B2 N.Kedzie; the PC lab in 108 P-A had to be networked and required software upgrades; the Macintosh lab in 102 P-A was set up; the Graduate Student Study Room in 350 Giltner was set up; and there were numerous individual requests for assistance with computer purchases, setup, upgrades, and configuration changes.

    b. The larger transition jobs required substantial blocks of time, and these were difficult to organize because the queue of ongoing jobs was saturated. The most problematic porting job was TOPDRAWER, a public domain data analysis and graphing software package. Parts of this software were developed at different sites and on different types of systems and were not designed for easy porting.

    c. There were several unanticipated problems: CHIP could not be used for a VAX boot node after many changes had already been made under that original plan; some of the peripheral hardware arrived late; changes usually made something else break which had to be fixed; there were problems with the mixed VAX - Alpha VMS clustering; deciding on software options took lots of discussion.

    d. Completion of the project in a short time was not the overriding priority of the COC chairs.

  7. Examples of Drifting into Untenable Commitments

    There are numerous instances of the computer staff trying to be helpful and undertaking projects for faculty members without first evaluating the time commitment involved. Projects often seem initially to be straightforward, until complications and problems arise. Projects often are often initiated with little lead time for the staff to prepare. The person requesting service is often unaware themselves of the ramifications of the project. Some recent examples are the departments first telecourse and the installation of encryption software on DIRAC.

APPENDIX E: Major Projects: 1998 - 2000

Following is a list of anticipated major changes and trends for computing in the Department for the next two years.
Year 1 - FY 1998-99:
Year 2 - FY 1999-2000:
[ Updated: Unknown ]
This page has been accessed 1528 times.

Bob Stein's home page , email: steinr@pilot.msu.edu