LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Eric Thomas <[log in to unmask]>
Mon, 29 Nov 1993 00:01:16 +0100
text/plain (228 lines)
  L-Soft seeks partner to provide "off the shelf" mailing list service
  --------------------------------------------------------------------
 
In order to  provide the many Internet users who  cannot afford expensive
IBM  hardware   with  cost-effective   mailing  list   solutions,  L-Soft
international plans  to start  an "off the  shelf" mailing  list service.
Various levels  of support  would be  provided to  better meet  the broad
needs  of the  LISTSERV community.  Organizations with  existing LISTSERV
expertise that  plan to phase  out their IBM  hardware in the  short term
will be able to  retain the level of service their users  were used to by
simply contracting  L-Soft to run the  lists on a central  L-Soft system.
Such customers would  retain full control over the  administration of the
list and enjoy  the lowest service fees, because  L-Soft's manpower costs
would be minimal. On the other hand, an organization without any LISTSERV
(or  computer) expertise,  such  as a  Human  Sciences department,  could
contract  L-Soft  to  take  full responsibility  for  the  operation  and
administration of  the list,  in essence providing  a "LISTSERV  that you
program in English"  service which would probably be cheaper  than a unix
workstation on which to run a mailing list manually.
 
Since LISTSERV  will not be available  on cheap hardware within  the next
three  months, this  service will  have  to be  started on  a VM  system.
Purchasing  a dedicated  IBM mainframe  would not  be cost  effective and
would lead to  a steep price schedule, in effect  putting the service out
of reach  of most academic institutions.  The investment would be  in the
hundreds of thousands, whereas only a few  percent of the CPU would be in
use. The  P/370 is  not currently available  in a  suitable configuration
(with TCP/IP) and may not scale up to the expected I/O load (the limiting
factor is the  CPU power of the  PS/2 host, which cannot  be increased at
will).
 
Running  the service  on existing  hardware with  spare capacity,  on the
other hand,  could be  cost effective  while at  the same  time improving
quality of  service. A  large system  with spare  cycles would  provide a
better response time on the average than an entry-level dedicated system,
especially where I/O  is concerned. In addition, an  existing system with
thousands of users will have much better operational facilities (backups,
operator coverage, etc) than L-Soft  could afford for a dedicated system.
Finally, a typical  side effect of downsizing plans is  that spare cycles
become available as applications are moved away little by little, whereas
the operational costs  remain more or less constant.  The hardware cannot
be  removed   until  the  last  administrative   applications  have  been
relocated, and meanwhile there is no  use for the spare cycles within the
organization. They  can be rented easily  as the users will  not complain
about the extra load, but finding a  customer willing to move his work to
a machine that will  be removed within 1-2 years may not  be easy, so the
charges are likely to be reasonably low.
 
L-Soft would  like to invite  interested parties  to submit bids  for the
provision of the service described below. While we understand that it may
take  time to  contact all  the people  who need  to be  involved in  the
preparation  of  a formal  bid,  we  would like  a  first  contact to  be
established before December 20th, even if  this is on a non-binding basis
and some information is missing. Some sites  may be in a position to make
a binding  offer before January  and our customer feedback  suggests that
this service  is needed urgently,  so we will need  to know what  are the
other outstanding proposals in order to decide whether to wait or take up
one of  the offers already  made. L-Soft is in  a position to  start this
service as  early as  mid January,  although it  would be  unrealistic to
expect all the paperwork to be cleared on such short notice.
 
*************************
* Hardware requirements *
*************************
 
Hardware requirements are given in terms  of IBM model numbers, but third
party equipment is equally acceptable.
 
Ideally, the CPU should be a 9121, 9021 or ESA-capable 3090. We will also
consider bids  based on a  9221-170 (or  higher) or ESA-capable  4381. We
expect to need at  most 12 hours of 3090-equivalent time  a month for the
first year.
 
Any DASD model with a transfer rate of 3M/sec or higher is acceptable. As
long as the unit and path are not saturated, performance is not really an
issue and we would rather get the cheapest unit type (eg 3380 rather than
cached 3390). We expect to need  a couple hundred megabytes to a gigabyte
of disk  space for the first  year, depending on customer  demand. We are
willing to consider arrangements in  which we would purchase a secondhand
3380 unit that you would connect to  your system. L-Soft would then use 2
volumes and you would be allowed to use the other 2 as you see fit.
 
Unless we  can get a  long-term commitment, we  will be running  a second
level VM system so that we can easily move the service to another machine
at the  end of the  contract period. This means  we cannot use  SFS space
unfortunately.
 
*************************
* Software requirements *
*************************
 
The machine must run VM/ESA 1.1 or higher, TCP/IP V2.2 and RSCS V3. While
not absolutely mandatory, VS PASCAL is highly desirable.
 
******************************
* Operational considerations *
******************************
 
The  system must  be  available 365  days a  year,  except for  scheduled
relocation and  the like. Ideally  we would like 24x7  operator coverage,
although  we will  settle  for any  reasonable  arrangement that  somehow
addresses unexpected  problems during the  weekend. This point  should be
explicitly covered in the bid. We  will need to guarantee a certain level
of  availability  to corporate  customers  and  we must  have  reasonable
assurance that the  system cannot remain down for 4  days during extended
weekends, as we would lose money.
 
The system should have  an uptime of 99.3% or better  on a monthly basis,
ie at most 5 hours of downtime, scheduled or not, not counting hurricanes
and the  like. We  will not  want a formal  guarantee as  long as  we can
terminate the  agreement if  the system consistently  fails to  meet this
requirement. We  will accept longer  downtime on an exceptional  basis to
relocate equipment, install upgrades, and so on.
 
You will be responsible for backing up our data at least once a week. You
will restore  our data at  no charge in case  of hardware problem  or any
other problem beyond our control. You will restore data at our expense if
we delete a file by mistake and need to have it reloaded. You will not be
liable for  consequential damage if  you lose our  data, but if  you lost
more than one day's worth we will not pay for the usage of the disk space
since the last  working backup or for the last  month, whichever is more.
We will also want  to be able to exit the contract if  you lose more than
one week's worth.
 
Because we will  be using a second-level system you  need not worry about
backing up our first-level spool  files. Backup of our second-level spool
files will  be our responsibility. You  will provide a SPTAPE  drive upon
request  and  at no  extra  charge  at times  when  we  must make  system
generations: twice a year for time zone changes if you are running VM/ESA
1.1, whenever you  relocate the hardware, and whenever you  require us to
upgrade to a newer version or service level of VM.
 
************************************
* System management considerations *
************************************
 
We will manage the second-level  system and your only responsibility will
be to configure  the first-level userid properly and provide  us with all
the  information we  need to  set up  the second-level  system. Since  we
expect to take  a R/O link to  public disks such as MAINT  190 (which you
are presumably caching),  we will need to be informed  of your procedures
and schedules  for updating such  public disks, so  that we can  take the
necessary steps to protect our second-level applications.
 
We will work together to minimize the impact of our second-level workload
on your first-level  applications, and optimize the response  time of the
second-level system. While we do not require V=F regions or the like, the
bid  should describe  the  kind  of configuration  you  are offering.  In
particular we want to know how  much first-level storage the second level
system will have, whether we will have  a SET RESERVE or locked frames to
avoid dual paging,  what SHARE we will  get, and so on. We  expect to run
the second-level  system in  a 10-16M virtual  machine, depending  on how
storage-constrained your  first-level system is.  At 16M there  should be
virtually no paging.
 
****************
* Connectivity *
****************
 
The system must have excellent  Internet connectivity with reasonable RTT
and packet loss rates (ie IP over X.25 will be a strong deterrent). We do
not expect to use much bandwidth as most of our traffic will be mail. For
pseudo-legal reasons we will not accept to be charged for connectivity by
volume, as we want to avoid  anything that might give the impression that
we are selling connectivity or network access.
 
The second-level system will need its  own IP address and hostname (again
so that it can be easily relocated  when the contract runs out). This can
be accomplished either via a dedicated 8232/BTI, if you have a spare one,
or  via a  connection to  the  first-level TCPIP.  We will  take care  of
registering  the host  and providing  primary  name service,  but we  may
require you  to provide  secondary name  service on  a local  machine for
better reliability.
 
The second-level  system will  have to  be connected  to BITNET.  If your
first-level  system is  a BITNET  node  with VMNET  (or other  high-speed
connection) we will simply use a  VCTC connection to the first-level RSCS
as that is the most convenient  and cost-effective solution. In that case
it will be necessary (for  administrative reasons beyond our control) for
you to take responsibility for managing our BITNET node registration with
the  NCC or  BITNIC, as  appropriate.  We will  pay for  any increase  in
membership charges caused by our  connection. EARN sites should note that
we are  authorized to connect L-Soft  systems to EARN at  no charge until
July 1996, and such connections do not count towards volume-based country
membership charges.  In other words,  there is  no extra charge  for EARN
sites,  neither to  the institution  hosting  the connection  nor to  its
national network. If  the first level system is not  connected to BITNET,
we will license VMNET  at our expense and establish a  link to a suitable
system. In that case we will take care of all aspects of the connection.
 
***********
* Charges *
***********
 
The agreement  should be for an  initial period of one  year, preferrably
with an option to renew it on  a quarterly basis after that. We will need
to know how long you expect to be able to offer the service.
 
We must be explicitly authorized to  resell the resources you are selling
us. While we will probably not sell second-level accounts, we will charge
our customers for the disk space allocated to list archives and the like,
and we must have written permission to do such things.
 
We will need some form of  protection against accidental CPU charges. For
instance, if the second-level CP goes into a loop we could end up burning
quite a lot of CPU time and impacting your first-level users. Technically
the only way to avoid this  is a suitably privileged first-level monitor,
which you probably  have already if you charge your  users for CPU usage.
We do not want to accept the  responsibility of having a class A/B userid
on your first level  system that we would have to use  via TELNET over an
open network, nor do we want to get into legal battles over the extent of
our responsibility for a  loop caused by a CP bug  when operations and VM
maintenance/service  are under  your responsibility.  So we  will want  a
mechanism whereby we can say that we refuse to be charged for more than a
certain amount of hours  per month, and you will take  steps to make sure
this does not happen  (and, even if it does happen, we  will only pay for
the amounts we registered).
 
We will provide free licenses for  LISTSERV and LMail valid on both first
and second-level systems. This may constitute an advantage in kind if you
are otherwise paying for our products.
 
You are free to  propose any charging schedule. We can  pay for the exact
amounts used or a fixed sum for a "package" deal. We can also pay part of
the costs  in kind (licenses  for other machines  and free access  to the
mailing list  service), or then give  you a percentage of  our profits on
the mailing list service.

ATOM RSS1 RSS2