INTRODUCTION

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

     This note is a statement of our views on service cen- ter
standards.  It is an input to the service center panel discussion of
the October Network meeting.  Some areas are identified for
consideration in intra-network standardiza- tion.  We do not describe
a methodology for analyzing com- puter systems; however, such analysis
may be appropriate for solving the problems.  We also do not enumerate
the spectrum of services that may be required.  We merely enu- merate
areas where commonality of appearance and function can be of immediate
value to a network user.

CAVEAT

------

     It is assumed that service centers will conform to official
network standard protocols.  This is essential for service centers
since the effects of their practices are generally more wide-spread
and are crucial to the effectiveness of minimal hosts such as TIPs.

JUSTIFICATION

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

     The generation of network standards for service centers is of
value to a very important class of people--the ultimate user
community.  We have such a community at Rand that is composed of
research scientists and their support programmers.  Certainly such
users exist elsewhere, and a goal of the net- work must be to
encourage their use.  In the past, these researchers have relied
solely on programmers to buffer them from computer detail.
Standardization of services is cer- tainly a great value in expanding
the community of users and eliminating the buffer.

     Additionally, standards will be of benefit to those persons
responsible for implementation of resource access programs.  Instances
and areas of standardization are cited below to support both of these
statements.
     Each host installation has its own standards for pro- gramming
and operational procedures.  From a network point of view, we are only
interested in standards affecting external performance--primarily
required operations and documentation of procedures.  Intra-network
standards should allow a user to plan his network use effectively to
improve the performance of his tasks and take advantage of savings in
both time and money.

Remote Job Entry

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

     One immediately apparent area for standardization is in the
access to network resources.  For example, there are two remote job
entry (RJE) facilities on the network at present with two different
data protocols.  The UCSB facility was developed early to provide
timely access to their resources.  The UCLA facility was developed
after the Telnet and Data Transfer protocols and takes advantage of
them.  If these two services appeared alike to the user and to the
using process, two significant advantages would be obtained.  First,
the using system would need only one module to access both facilities.
And secondly, a user could select either facility on a dynamic basis
using the conditions influencing him at any given moment without any
additional knowledge of the specific site.

Login Procedures and Subsystem Access

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

     A more global example of common access to resources is the login
procedure to remote systems.  All systems require basically the same
information--password, identification, account number.  Yet the
formats are syntactically inconsis- tent.  An extension to the logger
generally exists at these sites in the form of a "line scanner" for
the network.  In general, this module also performs other
transformational functions.  It would certainly be reasonable for this
module to translate a network standard login into whatever format was
required at the site.  Perhaps to a lesser extent, a similar approach
could be taken to constructing a uniform access to subsystems from the
supervisor.  In like fashion, a network standard interrupt could be
translated into the escape (e.g., control C) of the serving host to
return from a subsystem.

Charging Algorithms and Accounting Protocol

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

To accurately forecast costs, a normalized formula for machine

Off-Line Services

----------------- .

     Procedures need to be established for off-line services where
they are offered as a service or are an integral part of a service.
Such services are graphic hardcopy, large quantities of printer
output, tape or disc facilities, etc.  How are such items transmitted?
What guarantees or state- ments should be made about turnaround times?
How should they be specified--in terms of invocation and communication
with operations staffs?

Job Scheduling, Priorities and Status Information

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

     Extrapolating from the above rather static cost com- parisons
that a normalized formula allows, envision a small but useful process,
i.e., a throughput query service, that allows the user to dynamically
determine the most cost ef- fective location for a job.  (Such a
service is technically reasonable since some systems now offer status
data such as a core map and job queues display.) Imagine the user's
situation.  "Let's see, I need these numbers by 4:00 and I'm willing
to pay a slight dollar premium to get them; the job will run on any
Tenex machine, where should I run it?" The user would like to query
Tenex systems, providing as input the requirements of his program, and
get answers like probable turn-around time and cost vectors for dif-
ferent priorities.  (Incidentally, our non-programmer users are
familiar with their job parameters (time, core space, etc.) since this
information is normally part of the out- put stream.)

     Most of the necessary elements for such a service are readily
available in systems with which we are concerned.  The query service
would be a utility for users.  This is the kind of a problem we should
address concerning services vis-a-vis exporting Network concepts.
     In addition to the above items, the user community could
immediately benefit from standards in: documentation formats and
distribution, operating schedules, the extent and availability of
consulting services, data transmission and storage facilities,
techniques for communication with operations staffs, and abnormal
procedures such as system or program failures.

     Some of the above items should be described in a standard format
rather than the services themselves being standardized across the
network.  For example, schedules obviously vary in different time
zones and each system has a different magnitude and policy for on-line
storage capabilities.

     To some extent these items are covered in the Resource Notebook.
It should either be expanded to become a service center standards
notebook or a separate item to fulfill that function should be
created.  For example, a site might have resources that it wished to
offer on a limited or special arrangement basis to the network
community and should be included as such in the Resource Notebook.
However, that site might not wish to or have the staff to conform to
network service center standards.  Hence, the service center notebook
would describe standards for a much more rigor- ously conforming
community.

SUMMARY

-------

     The theme of this note is that without classifying ser- vices and
analyzing operations at service nodes, there are a number of areas
that can be standardized to some extent throughout the network.  What
is needed is a manual of service center standards and a collection of
documentation on services.  Perhaps the latter is the Resource
Notebook.

     Service centers who intend to attract a significant network user
community should be prepared to adopt a psychol- ogy appropriate to
the market-oriented requirements for providing service.  In the
network at large, with our re- search orientation, personnel tend to
have a different approach to computing than that required by a service
bureau.

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]