Conference 7.286::digital

        SO if you know about it, you just order it from SDC. I am sure
        RDB Product Management is amenable to case by case decisions
        if approached, although with the advent of LMF/PAK's it is
        about time they rethought there head-in-the mud attitude.
        
        q
        

    I don't think any internal products should be restricted in the
    manner than RDB is currently.  Digital Equipment owns its software
    resources, not individual groups.
    
    With VMS/LMF we have the ability to track PAKs back to the individual
    who requested it... that seems sufficient to ensure software stays
    within Digital, I would think -- now who wants to suggest this to
    RDB Development?
    

    
    
    We in Database Systems have implemented a new procedure for aquiring
    a network copy of Rdb/VMS.  The procedure will do a better job of
    tracking who receives such kits.  
    
    We in DBS stopped supplying such a service when several kits were
    'found' at customer sites.  Besides the obvious loss of revenue
    and potential customer satisfaction issues there is a real possibility
    that Digital could find itself being sued.  We felt the only option
    was to not support network kits.  
    
    The new procedure will hopefully help avoid such problems by keeping
    an audit trail.  We STILL feel very strongly about these kits being
    FOR INTERNAL USE ONLY and will enforce the policy.
    
    
    Steve Horn
    VAX Rdb/VMS Product Manager
    
    

        RE: This topic.  This is really not an appropriate topic for
        this conference.  I'm pleased to learn that the "problem" has
        been resolved, but discussing it here certainly is not a way
        to get it resolved.  If discussing it in Notes were the way
        to get it resolved (which it really isn't), then the Rdb/VMS
        conference would be the right conference.
        
        Being that as it may, the assertion in .2 that the internal PAKs
        can be traced back to an individual is wrong, and even if it were
        correct, it is, at best, a Bandaid on the problem. 
        
        Tom

    RE: .4
    
    
    Tom, I believe you are mistaken.  When PAKs are issued, they are
    unique.  If (for instance) the RDB people decide to make netkits
    and then offer unique PAKs for anyone internal who decides that
    they'd like a kit, then they do in fact have the capability to issue
    a PAK that can be traced.  The more generic PAKs that are issued
    along with netkits can't be traced, but specific issues can.
    
    I'd believe the folks (ie: .2) in VMS development who are involved
    in working with LMF (ie: STAR::BOUCHARD), I think they know what
    they are talking about.
    
    
    -bill

        Bill, I have generated internal PAKs using the SIXPAK system,
        and other people in my group have generated PAKs.  In our
        experience to date, the PAKs were the same.  Of course, we
        have not done exhaustive testing.
        
        Tom

.2 is what was intended/promised.

.6 is the reality, which was quite a surprise to me.

We are working to fix it.

>< Note 584.4 by DR::BLINN "Opus for VEEP in '88" >
>                  -< This doesn't belong in this conference >-
>
>        RE: This topic.  This is really not an appropriate topic for
>        this conference.  I'm pleased to learn that the "problem" has
>        been resolved, but discussing it here certainly is not a way
>        to get it resolved.  If discussing it in Notes were the way
>        to get it resolved (which it really isn't), then the Rdb/VMS
>        conference would be the right conference.

1. I thought long and hard before posting it here.
2. I contacted the Product Manager before I posted the note... If you knew
   the history and number of complaints about the "No Netkit" policy of RDB,
   you'd realize that this was not something that appeared out of the blue
   on Monday afternoon.  It has affected many internal people for years.
3. I checked the "policy" statement in 1.last before posting the note.
   Everything I wrote, I believe, complies with the policy... [see below]
4. The reason I posted it here is because sometimes a wider forum can
   provide incentive to those who are not "doing the right thing" to
   either stand behind their policy or change it.  The RDB Notes Connference
   has (had) a single note which was write-locked and said "There is no
   netkit for RDB V3.0.   End of discussion."
5. I am very happy this situation appears to be resolved.  It will save
   plenty of internal users a great deal of frustration.


================================================================================
Note 1.13                         Introduction                          13 of 13
HUMAN::CONKLIN "Peter Conklin"                      239 lines  27-MAR-1988 22:31
--------------------------------------------------------------------------------

    This file for issues about our Company, how we work here, how we could
    work better, etc...

    Speak what's on your mind, even if it's a complaint or criticism of
    someone, some group, or the company as a whole. However, don't forget
    some basic guidelines of behavior in expressing yourself "in public." 
    Although this file is restricted to Digital employees, remember that
    you are addressing a large and diverse group of people. What you write
    here will be on record for many years. See below for some advice on
    propriety.

        Given the background you've provided, I have to agree that this
        conference is appropriate.  However, in general, just writing a
        "gripe" note here won't fix the problem, although it can make
        people feel better.  Generally, if there's a conference that's
        clearly specifically related to the issue (as the RDB conference
        is), then that is a better forum, as it will be more focused, and
        is more likely to be seen by those directly affected.  And it
        might be a good way to find out who's responsible for the problem,
        product, or policy.  Since that was already done before writing
        the note here, then this conference provide the broader forum.
        
        Tom

    Thanks to .0 for posting this note. The Rdb group has really been a
    pain to deal with. Somebody just said it real good: the company owns
    the Rdb product, the Rdb group doesn't. This note seems to have helped
    with the issue; complaints in all other forums (the Rdb conference, the
    EASYNET_KITS conference, calling the Rdb group manager) have fallen
    on deaf ears.
    
    Somebody else just said that the Rdb group has some new "system"
    for distributing the Rdb kit internally. Perhaps that person could
    tell us what that system is or give us a pointer to that information.
    
    This whole "no netkit" policy is really crazy. Yes, I've ordered
    Rdb from the SDC a few times and I can't tell you how many internal
    people I then gave a copy of the kit to. There is absolutely no
    reason for the Rdb group to not have a netkit available. Not to
    mention that it is much more expensive for an internal employee
    to utilize the SDC than the expensive network that the company
    maintains for things like this.
    
    -Glenn-

Hi Glenn.  You sound a little frustrated and I don't blame you,
but let's give RDB their due.  The company does own the product,
but the RDB group is chartered to protect and nourish the product.

If they felt that network distribution was damaging it they were
not just in the right to stop it, they were obliged to stop it.

We can question their original judgement, or their subseqent
policy implementation, but not their inherent right and obligation
to do the right thing for the company property they are charged
with overseeing.

Besides, as someone pointed out, the issue will be moot soon
because of LMF.  And it will go away WRT to RDB in particular
for other reasons I can't discuss here.

Regards, greg

    Howdy Greg. I just had to put my 2� worth in because yes, I have been
    frustrated more than once trying to get an Rdb kit for our systems. The
    group's total lack of cooperation makes me wonder about them doing the
    right thing. I know I was doing the right thing in requesting a kit.
    Getting a blanket response of "go talk to SDC" makes you feel like they
    just don't want to play ball. 
    
> Besides, as someone pointed out, the issue will be moot soon
> because of LMF.  And it will go away WRT to RDB in particular
> for other reasons I can't discuss here.
  
    I'll believe the issue is moot when I see an Rdb kit available over
    the network! :-)  What does "WRT" mean?
    
    -Glenn-

    
       It was implied (by Steve Horn, I believe in .3 or so,) that the
    corporation could be sued by the distribution of internal-use-only kits
    to external users.  Of course, this is clearly the WRONG thing to do on
    the part of the people giving the kits out, but where does the legal
    responsibility for undistributed software come into play?  Should other
    groups which have fieldtest kits be as wary?
    
    For instance, the fieldtests of VMS V5.0 were internally available for
    quite some time before SDC.  I'd have a HARD time believing that no
    outside customers without a fieldtest agreement got their hands upon
    the software.  (No personal evidence, but based on availability, and
    past knowledge of how things "get around".)  Would Digital have been in
    the same boat then?
    
       Just to make it clear, I'm a staunch supporter of network-kits. 
    Perhaps it would be a good idea to get the SDC folks a few VAXen and
    set them up in various strategic locations with the software accessable
    from them?  That way there'd be one single location to get ALL the SDC
    software, rather than constantly searching about notes conferences
    (sometimes unlisted) and kit locations (not always posted in
    EASYNET_KITS and thus in the KITSDIR.DOC file.)
    
    
    						-mjg
    

The issue of giving customers network kits of SDC versions is different
than network versions of field test kits.

In the latter case:

	The customer is not licensed to use FT software.  The
	FT kit is _NOT_ the product.  No one should ever give
	an FT kit to a non-ft site.

	If the person doing it allows the customer to think
	that they've been given the product, or perhaps just
	fails to explicitly state otherwise, then the customer
	could be "upset" that it fails to conform to the spec.

	If this caused them direct damage, and they decided it
	was the result of knowing negligence on the part of
	a Digital employee, they might take us to court.

I'm not a lawyer.  I don't know how good of an example I've given,
and I've no idea whether such a suit, if pursued, could be won.
But I have discussed things like this with legal, and this is
roughly the _sort_ of scenario they paint.

It is not entirely hypothetical.  We've definately had customers
made unhappy because they were given field test software.  (And,
I'm sure, many others who were made quite happy).

As far as SDC versions of the kit placed on the net.  How can
you _PROVE_ it's the SDC version?  Could an unscrupulous employee
have patched it?   The SDC is charged to be responsible for such
things.  Engineering isn't.  We just have to make sure we gave
them the right kit for starters.  Sometimes kits placed on the
network and labelled "SDC" are then pulled from the SDC and
have to be pulled from the network.  Can you be sure that any
such kit that went to a customer gets pulled too?

We've had intruders on the net this year.  Are you 200% certain
they didn't touch that kit?  Even if you are, would your $30B
customer be happy if they knew that the software might have been
patched?  How much do you think that, say, GE should bet on
that?  The responsibility for security/quality of customer kits
is in the SDC, not on the E-net.

I know this sounds like paranoia.  But things that you can ignore
when you are a $1B company, cannot always be ignored when you are
a $10B company.  We are a bigger target for "mischief" and negligence
with each new order of size.

It's worth thinking about.

- greg

By the way, this is yet another reason we are pushing CDROM.  It's
a high-density, fast-turnaround, high-volume, cheap and tamper-resistant
							----------------
delivery vehicle.  The network is an accident waiting to happen.

	While this discussion has been carrying on, the Rdb netkit
    availability was announced in topic 83 in the NOVA::Rdb
    
    kp7 or Select.

    FYI, WPS also has the same requirment, that you must get it from
    SDC.  The little I have heard, was that you need documentation to
    do the install correctly.  
    
    I view these few examples as white elephants.  Most of the reasons
    are a white wash, but make the groups feel they are protecting their
    product.
    
    	- mark

    Standard disclaimer about not being a lawyer.
    
    Digital provides software to customers under license.  It doesn't
    matter whether we charge the customer a red cent, whether it's field
    test or SDC software (different license applies in each case). 
    Anytime an employee gives somebody a kit under the table, especially
    when that someone isn't licensed to use the software, that's putting
    Digital's proprietary rights at risk.
    
    I think we had a legal problem with our patent on the DECtape device
    because we weren't so careful about licenses during field test way
    back when.  I don't remember any actual cases, but software could
    go into the public domain if we gave a copy to somebody without
    being covered by a license -- anybody else could demand to have
    a copy.  What's worse, it may jeopardize our right to charge for
    the product (I don't know whether it's just that version or for
    all subsequent versions).
    
    In the case of a kit being given to a customer who is already licensed
    to use the product, there are different concerns, some of which
    have been mentioned.
    
    Internal network kits have become a way of life, a part of the Digital
    way of working.  Although there are no rules (that I know of) requiring
    development groups to make such kits available, employees have come
    to expect network kits, not as luxuries, but as necessities.  There
    are, however, costs to the groups providing the kits.
    
    One cost already mentioned is pilferage -- unauthorized distribution
    of kits outside the company.  This not only has an impact on the
    company's revenue, it also distorts the return on investment in
    the product.  Let's face it, in today's Digital, products are made
    not just for fun, but for profit.
    
    When the users of the product are internal, only "funny money" is
    involved, and who cares anyway about funny money?  Furthermore,
    network kits may be cheaper than SDC kits, although I don't know
    whether anyone has done an actual cost analysis comparing the two
    methods of internal distribution.  What may not be obvious is this:
    A completely passive kit distribution mechanism gives no indication
    of the extent to which the product is being used.  Products live and
    die partly based on how much mileage we get out of them.
    
    Consider this.  How many systems in Digital have installed VAX Notes
    (just to pick a random product)?   I don't think anybody really knows.
    If there is a reliable figure, and it's multiplied by some reasonable 
    value per kit, albeit in funny money, the company may come to realize
    how valuable the product is and invest in it accordingly.
    
    It's a whole new ballgame with LMF, of course.
    
  --Simon
    

    re: .17
    
    I think WPS-PLUS is a little different, as the spell-checker and usage
    alert are bundled in with it, and they're licenced from another
    company.  Thus it would be a violation of Digital's agreement with the
    dictionary provider, if a network kit were made available.
    
    In general, I've been very thankful that some groups make network kits
    available.  But I don't look on the existence of a network kit as a
    right, especially since there's all kinds of other factors such as past
    experiences, third-party licence issues, documentation issues (say the
    product requires documentation to install, and since you copied it off
    the net, you didn't get it, and so you didn't install it right, and it
    doesn't work right, and you start to generate problem reports or
    something like that), etc. 
    
    So a big hurrah to those groups who do supply network kits!
    
    thanks,
    b.

        The "SPELL" checker that's used by WPS-PLUS is available as
        a net kit for "stand-alone" use, so I doubt that's the reason
        why there's no network kit for WPS-PLUS.  I suspect we have
        a "corporate" license to use the spelling checker, as well
        as the usage alert software, anywhere in the corporation at
        no additional license fee, but do have to pass on royalties
        for each sale to a customer.  (I'm not certain of this.)
        
        Being that as it may, it's up to each product group to decide
        whether distributing a network kit makes sense for them.  Some
        do, some don't, some only do upon request, some have a special
        procedure you invoke that sends MAIL, copies the relevant disk
        savesets to do the install, installs them, and then deletes
        them from your local disk.  There's no single way that this
        gets handled.
        
        Tom

 re: < Note 584.20 by DR::BLINN "Eat dessert first -- Life is uncertain" >
>                      -< Ah, but, SPELL *is* available.. >-
>
>        The "SPELL" checker that's used by WPS-PLUS is available as
>        a net kit for "stand-alone" use, so I doubt that's the reason
    
    You sure about that?  I was told by someone who's really peeved
    that WPS-PLUS (or is it ALL-IN-1) forces you to use their spell
    checker, not the DECspell that he prefers.  (I am not really sure
    about whether there's one or two spell checkers.  But I just want
    to check your facts.)
    
  --Simon
    

    VMS-Services for MS-DOS does not have a network kit available either.
    Their excuse is that Microsoft software is included in the kits. While
    licensing issues such as this are understandable (even though I don't
    like them), there should be some way for field rats such as myself to
    get copies of the documentation over the network.  This is especially
    true for new releases of products.  As a resident, I am expected
    (by the customer) to be familiar with the new product as soon as
    it arrives.  As is usually the case, the customer wants the product
    installed yesterday.
    
    I would be an old man if I waited for the internal orders to get
    approved and shipped.  Customer orders take weeks even with P1 status.
    If I am willing to use my personal time (I'm supposed to bill my
    40+ hours/week) to read documentation on new/enhanced/unfamiliar
    products, I should at least be able to get the documentation over
    the network.  We all work for Digital, right?
    
    Well I am off to find doc on CDDplus and ACMS 3.0... If I can't
    find kit locations, I'll be back....
    
    brett_who_just_wants_to_do_right_and_stay_ahead_of_the_customer
    
    P.S.  We finally got the VMS-Services V2.0 doc two+ weeks and one
    bad shipment after getting P1 status.
    

        RE: .22 -- perhaps we should take this digression off to the
        DECspell conference.  In any case, it seems they ship a newer
        version with ALL-IN-1 and/or WPS-PLUS than the "stand-alone"
        one that's available as a network kit.  The point is simply
        that the reason for WPS-PLUS not having a network kit is not
        just that there are problems with DECspell, although that may
        be an excuse.  There are other reasons, as well, I suspect.
        And it *may* be the case that we can't distribute the "newer"
        DECspell internally without restrictions, although I suspect
        that the reason is simply that there's no new functionality
        so there's no benefit in making a new kit available.  Asking
        in SCRIBE::DECSPELL might get the true facts..
        
        Tom

    back to rdb.
    
    i was having an argument with somebody the other day about the use
    of rdb.  she had made a statement that she knew of a group that
    had spent quite a bit of time scoping out a project, then even more
    time designing a database that they were to write for that project.
    
    this seems like a tremendous waste of time to me.  i told her that
    i thought that the group should use an existing database product,
    like rdb, and concentrate their efforts on writing the interface,
    etc.  why duplicate the efforts of dec employees who have already
    written database products that work?
    
    if i had to write a graphics interface i certainly wouldn't start
    from scratch, i'd get a decwindows kit and use the routines that
    somebody had already written.
    
    so my question is in two parts - first, am i right?  second, where
    does one find out about all the 'layered' products that are available
    to avoid duplicating efforts in the future?  i looked in my software
    engineering manual and found references to decwindows, but nothing
    at all on databases.
    
    thanks,
    
    bs

re: .24

>    i was having an argument with somebody the other day about the use
>    of rdb.  she had made a statement that she knew of a group that
>    had spent quite a bit of time scoping out a project, then even more
>    time designing a database that they were to write for that project.
    
>    so my question is in two parts - first, am i right?  second, where

You're certainly right in principle, but there isn't enough information
in your opening paragraph to judge the specific instance.  Indeed, "de-
signing a database" is something you do regardless of whether you use
an existing database manager or not.  Did you mean "designing a database
manager?".

Anyway, there are still questions about performance, capabilities,
reliability, availability, etc., that could prevent the use of an
existing product --- especially in a base software engineering environment,
as opposed, say, to an applications environment.

- greg

    The "VAX Software Handbook" contains a brief description of every
    Digital product available for VAX systems (at time of publishing).
    
    				Steve

    .26,
    
    when i think of a database i guess i think of file handling, query
    handling, etc.  if i were writing an application that needed data
    storage, i'd try to find something close to what i need and then
    concentrate my efforts on creating the proper interface to what
    exists.
    
    the group in question is writing an application, and doing everything
    from scratch.  i don't see anything special about what they're doing,
    but then again this was just a casual argument, i didn't read any
    specs.  the person i was arguing with, however, admitted that they
    weren't aware of any existing database products...
    
    for myself, not being a database programmer, i'd have no interest
    in creating one from scratch, and even if i did i'm sure that someone
    elses would be better.  i'd much rather stick to what i'm good at,
    and use a database that was built by someone who is good at *that*.
    
    .27,
    
    thanks.
    
    bs

re: .28

>    the group in question is writing an application, and doing everything
>    from scratch.  i don't see anything special about what they're doing,
>    but then again this was just a casual argument, i didn't read any
>    specs.

The casual answer is, "don't re-invent the wheel".  Whether it applies
here or not requires more than a casual in-spec-tion.

Cheers, Greg

    This is one of the sad realities that occurs over and over in the
    field.
    
    Our people are not adequately trained in even the existence of VMS
    products so that they will at least know that SOMETHING exists to
    do what they need.  To me, inadequate knowledge of VMS and VMS products
    is inexcusable, but it happens.
    
    More subjective are existing application systems that represent
    thousands of hours of coding, but are undocumented or unadvertised
    so that countless other specialists re-invent the wheel at the
    application level (I am guilty of this too).
    
    This is partly due to a lack of confidence in other programmer's
    work, and partly due to a lack of information.

    There are programs underway like ASSETS that attempt to alleviate the
    problem of getting information on existing application systems. But it
    is left as an excercise for the specialist to research the existence of
    these programs, then obtain information on them and become familiar
    with them.
    
    In 1984, no more than a handful of specialists in my district had
    even heard of Notes, and probably only one person used them.  Even
    now I would say that Noters are a minority in our district, and
    the percentage goes down outside of SWS.

    Forget Rdb - does the person in question know about Notes?
    
    Jim
    

        RE: -previous questions about WPS-PLUS

        Back during my Pre-sales days (ohhh what fun!) and demoing
        every product under the sun to any customer Sales dragged me to...
        I learned a lot about WPS-PLUS... And even back then (~2 yrs ago)
        there was no Net kit available then....

        REASON:  WPS-PLUS has a built-in  Thesaurus (synonym helper) that
                 Digital pays a Royalty fee to one of those Dictionary guys
                 (I think it is "American Heritage") every time we sell
                 a WPS-PLUS license.  Not to mention the Lexicons you can
                 buy for your special business purpose (legal, etc).

        Because of MAINLY the above (I was told) there was no Network kit
        freely available.

        I think there are other products similar to the above and which
        do Not make their kits so easily available (VMS/SNA DTF, etc...).
        I really sympathize with anyone in the field under pressure to
        find a kit, have to install it, (first have to read doc. if can be
        found), learn it, and then use it for our  customers in some way....
        I spent lots of nights on  MY  time burning myself out trying to stay
        ahead with no thanks.   I've learned my lessons and will never forget.
        Bill        

    re:  < Note 584.31 by BAGELS::FINNERTY >

>       Back during my Pre-sales days (ohhh what fun!) and demoing
>       every product under the sun to any customer Sales dragged me to...

    This *used* to be the case, but no more, at least in our current
    manpower crunch.  I, too, spent many an hour dredging up manuals,
    begging software kits from customers, etc.  Nowadays, though, if
    a product is not readily available, over the network or however,
    then too bad.  Sales Support doesn't have the time and effort to
    waste fighting our own red tape, so either the Sales Rep tries to
    sell without the demo, or that particular product is dropped from
    the proposal, and we go with something else.  I've seen it happen
    to Rdb/VMS in particular, and a few other products in general.
    
    A lot of people back in the Greater Maynard area seem to think it's
    easy to pick things up from the SDC, after all, it's just down the
    road for lots of you.  But it doesn't work that way in the Field,
    where you're at the end of the distribution chain, and expense money
    is tight.  My CC manager (who has to sign for internal orders) is
    located 200 miles away, and I'm one of the lucky ones ...
    
    In my own view, piracy is pretty impractical these days for most
    of our products, for one reason or the other.  As far as our major
    customers are concerned, we have close working relations with them.
    I have accounts on quite a few customer machines, as do lots of the
    other specialists.  Certainly no one I know of would base a production
    application on a pirated piece of software, where no support could
    be requested, and no updates could ever be ordered.  Nor can I see
    any specialist I know handing out software on the sly, at the risk
    of getting terminated instantly.  And of course, there is absolutely
    nothing to prevent such a person from ordering an SDC kit internally,
    and making 10,000,000 copies of it if he really wants to ...
    
    So what's the *real* reason?

        Nit:  The lexicon that's used in WPS-PLUS is the same as the
        one in the SPELL and GRAMMAR checkers, I believe.  It's used
        under license from Houghton-Mifflin.  I believe that DEC has
        a corporate license for its use, so that is probably not the
        real reason for "no netkit for WPS-PLUS".  After all, there
        is a netkit for DECSPELL, as well as a field test kit for the
        Grammar Checker.  (See the relevant conferences for details.)
        
        A likely reason for "no netkit" policies is that the product
        manager has gotten burned, perhaps once too often.  As the
        old saying goes, "Fool me once, shame on you; fool me twice,
        shame on me."
        
        Tom

    Re: < Note 584.32 by AUSTIN::UNLAND >

    I could not have said it better myself.
    
    For the Northwest District, SDC is on the order of thousands of
    miles away!  And most of the time they are not sympathetic to
    emergencies.
    
    As a delivery specialist on residencies, I have (through software
    loan agreements of course) managed to demo a product on a customers
    VAX.  At least 1/3 of the time, this has sold the customer on the
    product.
    
    Unfortunately, those days are over.  I remember trying to get DECshell
    in an emergency...I'd have had better results fishing for halibut
    in the Great Lakes.

    Doug

re: .34 

>    Unfortunately, those days are over.  I remember trying to get DECshell
>    in an emergency...I'd have had better results fishing for halibut
>    in the Great Lakes.

"Those days" are just beginning.  The consolidated pre-delivery of
software on compact disc along with "demo" keys (PAKs) will make
"those days" seem like horse-and-buggy.

It won't happen overnight, but things will be different by the 90's
(which are just 14 months away).

- greg

    Re: < Note 584.35 by STAR::ROBERT >

    With all SDC layered software, there is also an installation command
    file (KITINSTAL.COM).  Do you happen to know if the new versions
    of our software will also have a deinstall command procedure?
    
    This has always been a sore point with me, but if they are planning
    on doing what I think you are suggesting, then a deinstall procedure
    is the next logical step.
    
    Doug

    DEINSTAL is not only the next logical step, it is an absolute
    necessity.
    
    Fred

DEINSTAL is indeed the next logical step, but we hope to leapfrog that
so that is is not necessary.

This work is borderline "unannounced product" but we have hinted at
it broadly in public customer forums and so let me paint a general
picture; however, this should not be construed as either a product
committment or schedule.  It is, however, a committment of direction.

"In theory", it is possible to ship a completely integrated system
disc on CD ROM.  We have experimented with this in our lab, and
described it to customers.  In such a case, there is no need to
either install or de-install software.  Enablement with a temporary
key (PAK) is sufficient.

Obviously there are zillions of details to consider, and such an
approach is easier for some products than others.  But it applies
in nearly every case to varying degrees.

So you should expect:

	Limited further engineering investment in the install/de-install
	model of software product integration.

	Continued experimentation and modest progress in shipping
	software that is "pre-delivered, pre-installed, and pre-
	integrated".

	Increased dependence on Compact Disc probably with somewhat
	tighted network access.  Intuition notwithstanding, we
	believe software can be distributed _faster_ and more
	_broadly_, with better version/eco control on CD than
	via the network.  (I imagine those with narrow bandwidth
	links, esp. non-continental USA, appreciate this).

These directions are public, and indeed reflect industry trends
(see AS400 pre-installed system disks for example).

This is an engineering reply to a "Digital Way of Working" question
and to discuss it in any further detail in this forum is probably
stretching the limits of this conference.  But these new technologies
are as much a part of our way of working as the Easynet, and so
I felt this was relevant.

I would suggest that any detailed questions, discussion, or debate
be persued in VMSNOTES under the guise of "SBT Directions".

- greg

    re:  Pre-built system disk with keys
    
    Sounds like a great idea.  One of the things that has made the IBM
    AS/400 systems more popular than expected is that all the system
    software is pre-installed at the factory.  All the customer has to
    do is plug it in, turn it on, and start creating user-ids.

    Geoff