Conference 7.286::digital

    I for one would be interested. I only have access to X86 and MIPS
    systems and need to gain access to an AXP to play with - I mean become
    familiar newer software that does not run on Ultrix. I would also be
    interested in obtaining used systems - but fairly new - systems.
    

    .1/.0
    
     I have for years maintained to anyone who would listen that this
    is the case NOT only in digital but every company who has a network...
    
    NOW WITH THE WEB and JAVA(others to come soon) it should be a real
    win to increase revenue...
    
    just remember while we sleep, there are nnnn millions of people
    somewhere in the world that could benifit from the idle time our
    systems sit and use power....imagine with WEB and JAVA(others to come
    soon) how much a researcher say in China could get done and how much
    quicker discoveries could be made if this excess compute power was
    available...ALSO it would contribute to Digital's bottom line...
    
    what about banks/insurance/etc anywhere in the world using this
    compute power in off hours...TIME IS MONEY...
    
    IMHO

       	Well, guess I'll start small and see what happens. I'm planning to
    have something in place after the holidays. I have just over a dozen
    systems with most of them being DEC3000-500's. I also have terminal 
    servers set-up so that system console access and control are available
    over the net. Dial-ins and ISDN lines are already in place.

    	Once set-up, I'll be able to put a clean version of VMS or Digital 
    Unix on any of them and have them up on the net in 3 hours or less, 
    from the time I start. I'm planning on offering some previous releases, 
    current releases, and FT releases of operating system per request.

    	Layered products (for VMS anyway) are available locally to these
    test beds via Infoservers. All non-royalty PAKs would be loaded.

    	Although available as an additional service, I'd like to offer the 
    systems pretty much as is without having to get into a lot of 
    reconfiguration or Layered Product SW installs. This would allow me to
    just charge a flat fee per system, regardless of the hardware. Special
    requests for special SW or disks/tape would be handled on an as 
    needed/available basis.

    	For rate info, I was considering a flat fee of $200 per system to
    install the OS system and version of choice. I was also considering
    that the systems themselves would be something like $100 /day, $400 /week, 
    $1200 /month, $2400 /quarter. Any additional labor over and above the
    basic service offering would be charged on a per hour basis with rates 
    varying depending on whether someone needed a tech, an engineer, or a 
    consultant.

    	Thoughts ?

    	Ray

    re: .3
    
    Gee, sounds an awful lot like an ACT:-)
    
    Bob - former Dallas ACT system manager

    re:ACT
    
    	I thought that the ACTs were primarily for external customers ?
    
    	Ray

    
      Also sounds like what SQOIS makes available on occasion...
    
      Great idea - my only concern would be the reluctance to do layered
    product installations.
     
       When I worked in ACMS,  we constantly needed such facilities (and
     even checked with your group),  but the end result was that by the
     time we could get all the layered products installed and special
     usernames configured (and drive over to NIO), it was always quicker
     to simply do it ourselves on our own machines.  (The flip side of
     this argument is that the testing group can't efficiently develope
     and maintain the  expertise to install/configure 100% of the 
     available layered products so we would have ended up doing a 
    lot ourselves anway.)
    
      One compromise would be to maintain standard configurations
    for groups (which you could build once for a fee)  which  you
    couldd then roll out on short notice.  (To re-iterate the ACMS
    example,  our need was for 3 or 4 pre-made systems with 
    particular versions of RDB/CDD/DEC-Forms/ACMS installed)  If
    a test group could have rolled out this configuration (using 
    several different versions of each product) on short notice
    we could have made great use of them,  particularly if they 
    could also maintain an archive of the regression test system 
    that went with each version combination.  (It took man-months
    to get the regression tests running in SQOIS, but then they
    blew it away when the funding ran out, then kept calling us 
    to see if we would be willing to come set it up again etc.)
    
    
    					-al
    

    
    before laying down all those $$$$, you may wnat to call/check with 
    John Holtz at either ZKO or MKO. 
    

    re:6+7
    
    	I work for John Holz and this is an off-shoot from that. The group
    in NIO normally uses new state-of-the-rev equipment at a higher equipment 
    rental price. This material is rolled-over (exchanged for new) every so
    many months. There are certain legal limits on what you can do with 
    roll-over equipment before you render it used. Since this is capital, 
    there is no such restriction.
    
    	This is also an off-shoot of the SQOIS function, which I also do
    and is normally what the test beds exist for (contracted Layered Product
    testing). SQOIS doesn't exist under that name anymore. I inherited some
    of this and have done enough of it to know that we typically run with 
    excess hardware capacity. On occasion, we need it.
    
    	In thinking about what I wrote yesterday, I made it sound as though
    we'd be unwilling to perform the LP installation and set-up. I'd like to 
    clarify that this is not the case. The thought process was that by 
    providing a customer with what they needed, they typically have the 
    specific expertise to most efficiently set-up a test bed, especially
    an initial complex set-up charged at an hourly rate.
    
    	I am certainly not opposed to setting this up *and/or* backing up the
    environment for future use. With everyone trying to watch costs, I was
    thinking that the most cost effective way to set this up would be to 
    subscribe to the basic service, set it up one time, and then I could
    make/retain a backup of the environment for future use, if needed. Future 
    use would then pretty much be the same cost as the basic service price.
    
    	If successful, I can put money back into the business by adding to 
    or upgrading the hardware environment. Before any of that happens, I
    have to start somewhere. Putting some quick feelers out to get a rough 
    idea of the demand seemed a good place to start.
    
    	Ray
    
    BTW - Unless a system isn't capable of being halted from the console,
    other than loading a tape in a tape drive, why would anyone have to
    drive to NIO to use a system ?

                      <<< Note 4309.2 by TRLIAN::GORDON >>>

>    just remember while we sleep, there are nnnn millions of people
>    somewhere in the world that could benifit from the idle time our
>    systems sit and use power....imagine with WEB and JAVA(others to come
>    soon) how much a researcher say in China could get done and how much
>    quicker discoveries could be made if this excess compute power was
>    available...ALSO it would contribute to Digital's bottom line...
    
>    what about banks/insurance/etc anywhere in the world using this
>    compute power in off hours...TIME IS MONEY...
    
  It's not that simple. Here are a few issues:

1. This sounds like a security nightmare. How would we prevent hackers among
the non-Digital users from poking around the Digital-internal stuff on these
systems. Or even using the system as a trap door to access Easynet?

2. Having the systems used 20 hours a day instead of 10 (allowing 4 hours/day
for maintenance) means almost twice as much data being stored (assuming some
software is used by both user comminities). That means almost twice as much
storage capacity. Maybe more than can be added onto some of these systems.

3. Many of our computer rooms have no service available after hours. Having
our systems used by non-Digital customers after hours would mean GPS would
have to provide 24-hour service. And that would mean hiring second and third
shift people to do this.

4. We would have to install and maintain software that we would not otherwise
need. If we were to limit use to that which is already installed on these 
systems, I don't think we would have many takers.

  We need to keep thinking of bright ideas, but I think this scheme would not
bring in enough revenue to offset all the hidden costs.

    
>  It's not that simple. Here are a few issues:

  the concept is very simple(K.I.S.S.) the details are difficult I agree...

> 1. This sounds like a security nightmare. How would we prevent hackers among
> the non-Digital users from poking around the Digital-internal stuff on these
> systems. Or even using the system as a trap door to access Easynet?

  that even exits today, even with the firewall and security layers on a
  system and will always exits...

> 2. Having the systems used 20 hours a day instead of 10 (allowing 4 hours/day
> for maintenance) means almost twice as much data being stored (assuming some
> software is used by both user comminities). That means almost twice as much
> storage capacity. Maybe more than can be added onto some of these systems.

  JAVA has some/most of these preventive measures built in as I recall
  and it's certainly going to get stronger...

> 3. Many of our computer rooms have no service available after hours. Having
> our systems used by non-Digital customers after hours would mean GPS would
> have to provide 24-hour service. And that would mean hiring second and third
> shift people to do this.

  Obviously not EVERY system would have access, in any oganization there
  are systems that are off limits but this is part of the details of 
  implementation...

> 4. We would have to install and maintain software that we would not otherwise
> need. If we were to limit use to that which is already installed on these 
> systems, I don't think we would have many takers.

  maybe true but unless you try...

>   We need to keep thinking of bright ideas, but I think this scheme would not
> bring in enough revenue to offset all the hidden costs.

  agree, but if this "scheme" gets someone thinking...what if...

  the revenue has been made for years by companies that lease/rent time on 
systems, that concept isn't new...

    re:2+10

    	About the closest thing that I could think of that may apply along 
    the lines of this is if a company had peak computational times, like say, 
    the end of a quarter. Then they may want to rent a system or two to off-
    load some large quarterly batch job that would result in a rental being 
    worth it to them in saved time.

    	Even with this being the case, I don't know if there is any
    mechanism that I have to directly charge an outside customer. For
    simplicities sake, this will mean that this service would only be 
    available to Digital employees.

    	It's a nice thought to be able to utilize idle system time for 
    research projects, but research tends to be a long term endeavor.
    For a long term project, a lease would likely be a more cost effective
    solution, if not an outright purchase.

    	The whole point in any of this is being able to fill a niche by
    being a cost effective solution. If a group experiences an occasional 
    short term need for a system, this service may wind up being more cost 
    effective than buying, setting up, and maintaining their own system. 
    That's what this is all about.

    	Ray

    re: .5
    
    >	I thought that the ACTs were primarily for external customers ?
    
    Nope.
    
    Bob

    re: .9/11
    
    some see things as they are and ask why...
    
    others see things as they are and ask why not...
    
    

I can't remember who they are but some group back east already
does this. We got a mailing from them asking if we'd be interested.
Unfortunately, recreating the US CSC environment is a major hassle
so we maintain all our own test systems. 

Besides, we frequently need to switch hardware around and fiddle
with system parameters. Usually that creates a problem when you
don't own the system. I could see this being usefull for simple
products that don't have multiple cross product requirements. liesl

    	Re:Switching hardware
    
    	This is likely the toughest thing to handle. When you know how
    to do something, and you're on a tight schedule, you don't want to be
    spending time waiting for someone to do a hardware reconfig for you.
    
    	External add-ons, like disks/tapes aren't a big deal. It's when you
    start having to get into the CPU box that it could get tricky. You start 
    with a working piece of hardware, someone does something, and now it isn't 
    working. Who fixes it and/or pays for the fix ?
    
    	It's impossible to cover all the bases for all the cases. There are
    times where a rental system will make a lot of sense. If there is a need 
    for frequent hardware reconfigurations over a long period of time, this 
    probably won't be one of those times.
    
    	Ray