Conference 7.286::digital

Surely it's a bit excessive to pronounce OpenVMS dead and buried because we
cancelled DECspell a few years ago (frankly, I was never a big fan anyway)!
Yes, a spell checker is a useful tool and should probably be part of the 
operating system.  Take the time to make an official request of the 
product managers.  I'll also bring this topic to their attention.

Meanwhile, there is a freeware spell checker available from DECUS which 
is fairly decent.  And best of all, it's available.  Now if only I had 
the details on where to get it...

j.

    I still use DECSpell on our VMS 6.1 system, so if you can get the
    savesets it still works.  

    I'm using DEC Spell on my 6.2 system also.  But that's because I've
    upgrade through 5.x when the kit was available.  There is NO kit
    available on the net from any pointer available in the DEC Spell
    conference.  And what about AXP systems?  I'm considering moving to any
    AXP system shortly.  I use the DEC Spell function in all text-based
    editing and in Mail.  I would think that certain basic functions should 
    be available in the operating systems.
    
    I guess we shouldn't have chosen DEC Spell in our example of how to
    install layered products on OpenVMS.

    Other signs of writing on the wall:
    
    SAP R3 ... moving off VMS
    WordPerfect ... VMS version farmed off to Spire Technologies
    Lotus 1-2-3 ... no Alpha VMS version

>    Other signs of writing on the wall:
>   
>    SAP R3 ... moving off VMS
>    WordPerfect ... VMS version farmed off to Spire Technologies
>    Lotus 1-2-3 ... no Alpha VMS version

Add the following applications nearing End-of-Life on OpenVMS in the MCAD
space:

	EDS Unigraphics
	PTC Pro/Engineer

Low volume = uninteresting / way too expensive for sustained software
development compared to economies of scale available in the commodity
market.  Choices: volume, or being able to directly run volume software
(well).

Until Digital copes with the fact that low volume is going to increasingly
affect software availabilty (particularly given the reliance on external,
rather than captive, software), this is going to be a problem, and
not just for VMS (VMS is just a bit farther along the curve, though
it does have various attributes that make it attractive for specific
niches.  The Unix vendors are in the same basic boat.)

So, yes, to some degree, the writing IS on the wall (since we presumably
aren't going to be pushing VMS/DECwindows against Windows 95 - and certainly
not successfully.)  Note that we aren't talking about something where
clustering, journalling or whatever might be an advantage - we're talking
about a simple, routine spelling checker (or word processor, or spreadsheet,
or ...) where VMS has no special advantage (and arguably, even disadvantages,
ignoring volume.)

Consider basic economics: If you were a software developer and could sell
100000 units at $100, or 1000 units at $1000 reflecting the SAME development
effort and very low "manufacturing cost" per unit, what choice would YOU
make?  (And remember that there WILL be competitors selling on commodity
systems at $100, so you'll have to justify why your very significantly
lower profit margin [or lower effort] software sells for 10 times as much -
or gets the same ROI at $10000 - if you can actually sell 1000 units at 100x
the commodity price...  And this is on top of people who bought the platform
getting pissed that the same software on their platform typically costs
a lot more, and has more bugs because of less shake-out, etc...)

"Silicon" and "software" both want volume.  "Silicon" may be able
to "slide by" by shipping other types of chips to support a sufficient
fab.  A low-volume platform (particularly one with no "upside" potential)
from a software perspective is the kiss of death.

(I seem to recall someone saying that software development was asked
how to get more people to develop on our systems 10 years ago.  The answer
was the same then [significantly lower cost/higher volume platforms] - and
we had the same relative pricing problems, just different competition...
We used to compare ourselves to IBM and got creamed by Sun, etc.  Now we
compare ourselves to Sun, etc., while the action has moved on to lower cost
personal systems, and increasingly portable personal systems.  The pain over
the past several years has arguably been over the first bad "mispredict".
The question is whether we will recognize/correct the problems in time
to avoid a second major "mispredict".  Neither VMS nor Unix are going
to be high volume software platforms relative to the commodity market,
and both are going to be increasingly difficult to attract ISVs to.)

We need to stop sticking our heads in the sand and fix the underlying
problem before it gets any worse (I'm specifically referring to Alpha
here - not necessarily VMS, since it isn't clear there is *any* significant
volume to be had for VMS at any price.)

Anyway, things like this should absolutely NOT be a surprise - it's basic
economics / capitalistic behavior.  Digital was "spoiled" for many years
by having captive software development to hide major market shifts.

(Note to anyone who thinks I'm "bashing" VMS [or Unix] - I'm not.)

A final thought: A recent Science News had an article on mass extinctions,
and one bit from it is that the primary predictor of survival wasn't
any particular biological attribute - it was pervasiveness, including
both population size and geographic diversity (if I remember correctly.)

I have backed up  my DECspell kit to VIVIAN::SPELL.BCK
It will be there for 7 days - so if you need a copy then help yourself soon.

I can't for the life of me remember what PAK you need for this to work!
Since you can't buy it anymore I guess this is only useful for internal use
anyway.

	Stuart

    Got the kits this morning.
    
    I believe that you need two PAKs.  610 is the DECPSELL but I can't
    remember the other.  I'll check around in the DECSPELL conferene and
    figure it out.
    
    	Regards,
    
    	 kam

    I'm puzzled by the customer's expecting VMS to have a spelling checker
    built in.  What other OS has such a thing?
    
    					Steve

    re: .-1

    UNIX, and probably Mac. It's not built into MS DOS or Windows, but it
    is included in virtually every word processor other than Windows Write.


    re: .6

    Exactly. And of course that's why, except in extraordinary
    circumstances, software available only on a low-volume platform is not
    likely to be successful nor, therefore, likely to help stimulate sales
    of that platform.

    -Tom

  Mac doesn't have any spell checker built in, but every text
  processing utility more advanced than "SimpleText" (the equiv-
  alent of "Notepad" or "Write" for you Dos/Windows users) has
  spell checking integrated. On the other hand,"SimpleText"
  integrates text-to-speech. :-)

  And if you'd like pervasive spell checking, "Thunder 7" will
  add it to everything for about $40.

                                   Atlant

								     spell(1)

       

   Name
     spell, spellin, spellout -	check text for spelling	errors

   Syntax
     spell [-v]	[-b] [-x] [-d hlist] [+local-file] [-s hstop] [-h spellhist]
     [file...]

     spellin [list]

     spellout [-d] list

   Description
     The spell command collects	words from the named documents,	and looks
     them up in	a spelling list.  Words	that are not on	the spelling list and
     are not derivable from words on the list (by applying certain inflec-
     tions, prefixes or	suffixes) are printed on the standard output.  If no
     files are specified, words	are collected from the standard	input.

     The spell command ignores most troff, tbl and eqn constructions.

     Two routines help maintain	the hash lists used by spell.  Both expect a
     set of words, one per line, from the standard input.  The spellin com-
     mand combines the words from the standard input and the preexisting list
     file and places a new list	on the standard	output.	 If no list file is
     specified,	a new list is generated.  The spellout command looks up	each
     word from the standard input and prints on	the standard output those
     that are missing from (or present on, with	option -d) the hashed list
     file.  For	example, to verify that	hookey is not on the default spelling
     list, add it to your own private list, and	then use it with spell,

     echo  hookey  |  spellout	/usr/dict/hlista
     echo  hookey  |  spellin  /usr/dict/hlista	 >  myhlist
     spell  -d	myhlist	<filename>


   Options

     -v		    Displays words not found in	spelling list with all plau-
		    sible derivations from spelling list.

     -b		    Checks data	according to British spelling. Besides
		    preferring centre, colour, speciality, travelled, this
		    option insists upon	-ise instead of	-ize in	words like
		    standardise.

     -x		    Precedes each word with an equal sign (=) and displays
		    all	plausible derivations.

     -d	hlist	    Specifies the file used for	the spelling list.

     -h	spellhist   Specifies the file used as the history file.

     -s	hstop	    Specifies the file used for	the stop list.


									    1






   spell(1)


     +local-file    Removes words found	in local-file from the output of the
		    spell command.  The	argument local-file is the name	of a
		    file provided by the user that contains a sorted list of
		    words, one per line.  With this option, the	user can
		    specify a list of words for	a particular job that are
		    spelled correctly.

     The auxiliary files used for the spelling list, stop list,	and history
     file may be specified by arguments	following the -d, -s, and -h options.
     The default files are indicated below.  Copies of all output may be
     accumulated in the	history	file.  The stop	list filters out misspellings
     (for example, thier=thy-y+ier) that would otherwise pass.

   Restrictions
     The coverage of the spelling list is uneven; new installations will
     probably wish to monitor the output for several months to gather local
     additions.

     The spell command works only with ASCII text files.

   Files
     /usr/dict/hlist[ab] hashed	spelling lists,	American &
			 British, default for -d
     /usr/dict/hstop	 hashed	stop list, default for -s
     /dev/null		 history file, default for -h
     /tmp/spell.$$*	 temporary files
     /usr/lib/spell

   See Also
     deroff(1),	sed(1),	sort(1), tee(1)


























   2

    
    Guys, give me a break !!!!
    
    The economics mentioned in .6 are right on, and there's no doubt that
    the market has realized that a while ago.
    
    "market" = ISVs and customers.
    
    Not surprisingly (Hhhmmmm...), Digital's management has realized that too,
    and this is exactly that reason for the OpenVMS+NT anncouncement at
    DECUS.
    
    ISVs are and will develop for Windows 95 and Windows NT (which will
    eventually merge, perhaps sometime in '97), and therefore our strong
    relationship with Microsoft will do us good (at least in this area).
    
    Don't expect MANY OpenVMS customers to continue to buy VAXstations or
    even AlphaStations when all they need to run is a word processor, a
    spread sheet (and maybe a speller...), or a terminal emulator.
    
    We will sell our workstations into markets where there's still a clear
    advantage for them over PCs. I'm not sure how long this advantage will
    be there. IMHO, wait 3-4 years (max.) and the vague distinction between
    a PC and a workstation will disapear.
    
    My guess is that several years from now, people will be buying PCs as
    their desktop devices, and they will be able to configure them as super
    high-end workstations (enough cache, a strong graphics controller,
    etc.).  
    
    Yet, there is a market for OpenVMS, at least for the foreseeable
    future. Its clustering and redundancy capabilities are second to none,
    and customers understand and appreciate that.
    
    Maybe, just maybe, Digital might decide to adopt NT as its next
    mainstream server OS (maybe it has decided so already...) and cease
    from further investments in OpenVMS, but this should not happen, if at
    all, before 1999.
    
    OpenVMS is still the ONLY profitable systems business for us. We don't
    make money on UNIX and we don't make money on PCs. So, basically,
    OpenVMS pays ALL of our salaries, and keeps us alive.
    
    Let's not give up on it too early !!!
    
    EG
    

    I agree...don't give up anything, but recognize the trends:
    
    Per IDC:
    
    Server Market $ISS (new installed systems sold)
    
                            1994 WW Shipments            1997 WW Shipments
                            -----------------            -----------------
    OVMS                          10%                           9%
    UNIX                          28%                          33%
    NT                             2%                          14%
                            -----------------            -----------------
    Sub-total of Market           40%                          56%
    
    Let's capture as much as we can in all 3 O/S markets, but drive for
    larger shares of the growing market segments.  
    
    Mark
    

Eran:

  Two questions:

> We will sell our workstations into markets where there's
> still a clear advantage for them over PCs.

  What markets are those? How clear is the advantage?


  Do you think the lifespan of OpenVMS might have been prolonged
  if it had more of the features that PC and Mac users take for
  granted like:

    o Spell checking
    o Sophisticated text processors
    o Simple drawing and painting tools
    o Simple data bases (other than Datatrieve)
    o A mail utility that kept up with the times
    o A real GUI interface to the file system*
    o Simple TCP/IP integration instead of ISO/OSI?
    o Etc.

                                   Atlant

>    <<< Note 4040.0 by TENNIS::KAM "Kam USDS (714)261-4133 (DTN 535) IVO" >>>
>        -< OpenVMS lacking basic productivity applications e.g., SPELL >-

   OpenVMS has a fully supported spell utility, and it's free.  With
   POSIX, one gets spell, lex, yacc, grep, tar, cpio, man, etc.

    .15     o Simple data bases (other than Datatrieve)
    
    
    Datatrieve is not a relational database manager (CODs rules?) .   True 
    it is flexible enough to interface with RMS, Rdb and DBMS file 
    structures - its not a database manager.   
    
    .15 - ever hear of a product call dBase II?  
    
    it's available on OpenVMS - did you know this? 
    
     dBASE IV is a software product developed by Borland International Cor-
     poration and is licensed under Digital Equipment Corporation's Stan-
     dard Terms and Conditions.
    
     dBASE IV for VMS systems is a fully-integrated multi-user data man-
     agement system that provides comprehensive data management capabil-
     ities, an extensive Fourth Generation Language (4GL), and development
     tools for application development. dBASE IV for VAX is based on dBASE
     IV, Version 1.1 Developer's Edition for MS-DOS[R] computers.
    
     dBASE IV for VMS Systems provides users with the ability to serve as
     a front-end interface to local or remote VAX Rdb/VMS data through Dig-
     ital's SQL Services component of NAS (Network Application Support).
     Using the dBASE IV server login facility, users can connect to VAX
     Rdb/VMS  from within dBASE IV. Once connected, SQL commands can be 
     issued either interactively or embedded within applications for 
     transparent Rdb data access or data definition. Data can also be 
     queried from other  sources such as IBM[R] mainframe-based DB2[TM] 
     databases via Digital's for VAX RMS on VMS.
    
     dBASE IV for VMS Systems provides the same user interface as dBASE IV,
     Version 1.1 for MS-DOS systems, but also includes additional tools and
     capabilities specific to the VMS environment. For example, Rdb data
     can be converted to the native dBASE ".dbf" file format for additional
     processing on the VAX or downloaded to a PC to offload processing de-
     mands on the VAX.
    
     dBASE III[R], dBASE III PLUS[R], and dBASE IV applications are highly
    compatible between DOS-based PCs and VMS systems for including dBASE
    source and data files such as .dbf, .dbt, .db, .mdx, .ndx, .fmt, .frm, .frg,
     .lbl, .lbg, .prg and .prs. Applications can be moved between these
    platforms without data conversion or reprogramming (except for operating
     system specific differences). dBASE IV, Version 1.1 object files (in-
     cluding .fmo, .fro, .lbo, .qbo, and .dbo) are binary compatible un-
     der VMS and can be transferred from desktop PCs to the VAX without re-
     compiling.
    
     New Features
    
     o  VAX Rdb/VMS Version 4.0 support
    
     o  Supports DEC RdbAccess for VAX RMS on VMS.
    
     o  Import and export data in DTIF format.
    
     o  8-bit character support for ASCII characters as in the DOS code
        page 437 (where possible). Allows use of COMPOSE-key for entering 
        multi-national characters.
                            
    

    Is POSIX part of the BASE system or is it a layered product?  When we
    built the system it did NOT ask if we wanted to include the POSIX
    features.  We, the Business Partners, wish during the Installation that
    it asked this and allows us to include this and NOT have to, as an
    after thought, now go get another kit.  If OpenVMS is Open then why is
    it an effort to have to include the POSIX kit?
    
    	Regards,
    
    	 kam

  Borland's dBase products are laughably out of date even on the
  PC products, where they've actually done an occasional release.
  When was the last release of the OpenVMS product?

  By the way, what does the OpenVMS version of the product cost?

    o $99 will buy you Microsoft "Access" on the PC or
      ACIus's "4D First" on the Mac, both of them full-
      function Relational Data Bases.

    o $89 will buy you Claris "Filemaker/PRO" (currently
      a flat database like dBase but going relational
      soon) or Microsoft "FoxPro", a flat database that
      is widely viewed as far superior to DBase.

    o $69 will buy you Claris's "ClarisWorks", an inte-
      grated word-processing/spreadsheet/drawing/painting/
      low-end-database product.

                                   Atlant

Add to this the position that "Digital does not do software!" This appears to be
contradictory because Digital employs many software engineers developing
software (myself included). However, this can be interpreted to mean that
Digital does not do applications software, it only does systems software, i.e.
the software necessary to make its systems function in support of applications. 

Thus we have divested ourselves of various applications products like DECspell
and DECwrite. Many competitors exist to develop these types of products, but few
other companies are developing system software to compete with ours. That is,
while there may be other implementations of Unix to run on VAX/AXP systems, no
one is creating an alternate version of VMS, or alternate images to load into
our network boxes, etc. We do the system software to make our boxes run, someone
else does the application software to use those boxes in a particular way.

So is a spell checker system software or application software? Historically, it
has been a feature of applications. However, it is a pervasive, generally useful
function and thus might be considered a de facto operating system feature. If an
OS offered a spell-check service for each of its text object variants,
applications would not need to provide their own, they would just need to
interface to it, just as they interface to the file system. 

The more feature-laden the OS, the easier to develop applications for it. The
danger is "creeping featurism", the desire to make the OS all-encompassing. The
OS becomes more complex, bigger, more costly, even for those users who don't
care about spell-checking, or any other feature du jour. This argument can be
applied to any feature, and each one should be considered carefully.

    .21 This argument can be applied to any feature, and each one should 
        be considered carefully.
    
    I agree!   Single user application is one consideration and of course
    a single user license is less expensive that a concurrent / multiple
    license environment.   Apples / oranges....
    
    Should a single user, single threaded database product be priced the
    same as a multi-user, multithreaded enterprise wide application?  
    
    OpenVMS shouldn/t be compared to a MS/DOS in my opinion.  Functionalty 
    and power are 2 different classes.  
    
    Somewhere in the middle there are be client / servers which is really
    the middleware where a VAX or AXP meets a PC...   The Digital /
    Microsoft offerings under NT  should be an interesting high growth
    area...

> Is POSIX part of the BASE system or is it a layered product?  

    It is licensed as an optionally-installed part of the base
    system.  It is not installed as part of the base product
    installation under the assumption not all customers will want
    it -- for any of various reasons.

>    When we built the system it did NOT ask if we wanted to include the POSIX
>    features. 

    I suggested this integration to the responsible OpenVMS product
    manager quite a while back -- anyone with an interest might want
    to ask about (or for) it.

>     We, the Business Partners, wish during the Installation that
>    it asked this and allows us to include this and NOT have to, as an
>    after thought, now go get another kit.  If OpenVMS is Open then why is
>    it an effort to have to include the POSIX kit?
    
    You're quite right, the DECwindows installation is certainly
    better integrated into the OpenVMS installation than is the
    POSIX installation.  Again, please contact the product manager.

    POSIX *is* on the CD-ROM, which makes installation rather easier
    for those folks (both customers and internal sites) that are
    receiving the standard distributions.