From: SMTP%"goathunter@alpha.wku.edu" 13-MAY-1994 11:03:58.95 To: EVERHART CC: Subj: Trying to save BLISS---PLEASE READ!!! (was Re: BLISS Has Been Retired) X-Newsgroups: comp.os.vms,vmsnet.internals Subject: Trying to save BLISS---PLEASE READ!!! (was Re: BLISS Has Been Retired) Message-Id: <1994May10.163943.11016@netnews.wku.edu> From: goathunter@alpha.wku.edu (Hunter Goatley) Date: 10 May 94 16:39:38 CST Reply-To: goathunter@alpha.wku.edu (Hunter Goatley) Distribution: world Organization: Western Kentucky University, Bowling Green, KY Nntp-Posting-Host: alpha Nntp-Posting-User: goathunter X-Newsreader: mxrn 6.18-16 Lines: 457 To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article <1994May10.172815.3288@zippy.dct.ac.uk>, ccdarg@zippy.dct.ac.uk (Alan Greig) writes: >In article <2qo7uf$473@jac.zko.dec.com>, lionel@quark.enet.dec.com (Steve Lionel) writes: >> > >> Retiring the VAX BLISS-32 product does not mean that Digital's internal use >> of BLISS on the VAX and AXP platforms has no internal support. We retire >> products when the sales of licenses and support contracts no longer justify >> the engineering and support expenses for it. Note also that it is the VAX >> compiler that is retired (I don't believe we've offered the AXP compiler >> for sale.) > >Thanks. I hoped that would be the case but just wanted someone to >confirm it. Postings saying that a major building block of VMS was about >to vanish do worry your customers you know. Now I'd be even less >worried if the Bliss compiler was made more generally available >but as an 'unsupported' compiler in the manner that Bliss-10/-20 >were before their replacement by Bliss-36. > >As has been said there's a lot of good PD stuff including the >indispensable MX and the upcoming MadGoat ftp which are written >in Bliss. > >I would also comment on" > >"sales of licenses and support contracts no longer justify > the engineering and support expenses" > >I wonder how many sales of VMS based systems itself have been >influenced by the quality of products written in Bliss and >generally available? > I've once again started a serious battle to try to get Digital to bundle BLISS with VMS---treat it like TECO, the watchpoint driver, etc., and just stick it out in SYS$SYSTEM: with no support, no docs, etc. I've got lots of support from folks in BLISS and VMS engineering, but I have a feeling that Digital management will say, "It won't make us any money, so we won't do it." I'm appending below a white paper I wrote to address this issue. If you've ever had any interest in BLISS or just think it would be a really good idea, *please* send me a mail message at the address below. Maybe there'll be strength in numbers.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.WKU.EDU) ------------------------------------------------------------------------------- Bundling BLISS with OpenVMS Hunter Goatley May 6, 1994 Hunter Goatley Western Kentucky University Academic Computing, STH 226 Bowling Green, KY 42101 502-745-5251 goathunter@WKUVX1.WKU.EDU Bundling BLISS with OpenVMS For the past two years, I have been trying to understand Dig- ital's reluctance to make BLISS available for the OpenVMS AXP platform. While the compiler has been made available with a loan of products agreement through the ISV program, many OpenVMS pro- grammers would like to see Digital go a step farther than that and actually bundle BLISS with OpenVMS. For years, Digital encouraged vendors to program in BLISS. It only made sense, because OpenVMS itself was mostly written in BLISS. Now, Digital is telling those vendors that they should start migrating to another language (C). I've talked to numerous Digital people over the last two years, and it's my understanding that: o Digital never made much money from BLISS. o Supporting a product involves considerable time and expense, when such things as documentation, media, handling of support calls, etc., are included. o Digital is hiring people with C experience who don't want to learn BLISS. Since Digital never made much money from BLISS, the decision was made to pull BLISS (including the VAX version) from the market. This is a reasonable decision-we can't expect Digital to put forth a lot of money and effort marketing a product that doesn't sell. So why didn't BLISS sell well? From my own experiences and con- versations with dozens of OpenVMS programmers, there appears to be only one reason: price. The BLISS compiler was consider- ably more expensive than any of the other compilers (with the exception of Ada, if memory serves). The companies most likely to have an interest in BLISS were small software houses that couldn't afford to buy a license for the compiler. So MACRO-32 became the language of choice for many vendors simply because it 1 Bundling BLISS with OpenVMS cost them nothing outside the initial cost of licensing OpenVMS, since MACRO-32 was included with OpenVMS. Still, there are a number of vendors who followed Digital's lead and used BLISS for their products. Now, they are faced with the possible extinction of BLISS as a programming language and are looking at having to expend considerable time and money migrating to another language. What I suspect will happen if BLISS ever becomes completely unavailable is that, like so many other companies have done these days, many of them will decide that it's not worth the cost of migrating and they'll stop supporting those products on OpenVMS. Since BLISS never made Digital money, I can understand wanting to pull it from the list of products that Digital sells. But to essentially tell loyal vendors that they'll have to use something else isn't a good business practice, especially in light of Digital's financial problems lately. 1 Reasons Not to Bundle I and many others have petitioned for several years for Digital to bundle BLISS with OpenVMS. I can think of a few reasons for Digital not to bundle BLISS with OpenVMS: o Some customers may expect some level of support for BLISS if it's included in the operating system. o It adds slightly to the complexity of releasing a new ver- sion of OpenVMS, since the OpenVMS engineering team must coordinate with the BLISS developers to ensure that it's up-to-date, etc. o It adds a couple of thousand blocks to the base disk size of OpenVMS. o Since BLISS didn't sell well, it might be perceived that there aren't many OpenVMS users who would use the compiler now. 2 Bundling BLISS with OpenVMS I'm sure someone within Digital can think of another reason, but from where I stand, that's it. 2 Reasons to Bundle There are many reasons that many OpenVMS programmers want Digi- tal to bundle BLISS with OpenVMS. o BLISS is far from being a dead language inside Digital. While new product development may be done in C, it remains a fact that the majority of OpenVMS is written in BLISS. Digital must continue to maintain the compilers (VAX and AXP) to continue to provide OpenVMS on the VAX and AXP platforms. Pulling the product from the market doesn't reduce Digital's development and maintenance costs, since Digital itself relies heavily on the compiler. o Many programmers prefer BLISS to any other language. BLISS offers the systems programmer many advantages over conven- tional languages, including: o Complete access to hardware features, including the VAX JSB instruction, queue instructions, etc. o The ability to define structures to provide easy access to data, no matter what the format. o The best optimized code of all the VAX compilers. (GEM changes this for AXP.) o The ability to explicitly control PSECT definitions and attributes. o The ability to define and expand sophisticated macros. o The ability to specify linkages between routines. o Explicit control over the assignment and usage of regis- ters. o Freedom from relying on a run-time library to provide essential compiler features. 3 Bundling BLISS with OpenVMS BLISS also contains many similarities to high-level languages that make it easier to program in than assembler language, including: o a block structure; o loop control, including CASE, WHILE, UNTIL, and SELECT statements; o IF-THEN-ELSE constructs; o an automatic stack; o data structure definition capabilities; From discussions on ISVnet, DECUServe, and Usenet NEWS, it's obvious that there are a lot of programmers who would be interested in using BLISS, if the compiler were more accessible. I would like to address one more topic about language suit- ability. The world is moving toward C. Everyone knows that. One argument for using C is that it's ``portable.'' We all know that it's not, though code written in C can be made portable with careful coding and judicious (and prolific) use of conditional compilation. If software is written for OpenVMS so that it has the same feel as other OpenVMS utilities, then that software nec- essarily depends heavily on the OpenVMS system services, the run-time library routines (LIB$, SMG$, etc.), the CLI$ routines, and RMS. For such programs, the use of C for porta- bility gains nothing, as the programs are so closely tied to OpenVMS that they would probably have to be rewritten to run under another operating system. Since what I write is for OpenVMS and does depend on OpenVMS features, I would prefer to be able to continue to use BLISS. o The only development language bundled now is MACRO-32. Yet Digital has, from the beginning, stated that the MACRO-32 compiler was provided to help customers port applications to AXP, and that they should not expect the compiler to always 4 Bundling BLISS with OpenVMS be provided. Assuming Digital still intends to eventually remove the MACRO-32 compiler from OpenVMS AXP, that leaves OpenVMS AXP without a bundled language. That will effectively halt all development on AXP for many customers. At one time, I was told by Digital employees that DEC C and MACRO-64 were going to be bundled with OpenVMS AXP and Digital didn't want to include BLISS because that would make for three bundled languages. Since I was told that, both DEC and MACRO-64 were released as layered products. Bundling BLISS with OpenVMS (both VAX and AXP) would continue to provide customers with a development language that can be expected to be found on all OpenVMS systems. This is essential for many freeware products, where users like to be able to compile the products from the sources to ensure that they contain no hidden code (viruses, trojan horses, etc.). o Having ported several dozen freeware packages to OpenVMS AXP, I can state unequivocally that porting the BLISS software was easier than porting the C code. MX (Message Exchange) consists of several thousand lines of BLISS code and was ported to AXP with virtually no changes (a macro was used to handle the change from LIB$TPARSE to LIB$TABLE_PARSE). By contrast, many C programs require considerably more effort to port, especially if /STANDARD=VAXC is not used. This is not to say that C is a horrible language, but rather to point out that BLISS makes for an extremely attractive language for portability between OpenVMS VAX and OpenVMS AXP. As of today, it's still not possible to write kernel-mode code that makes use of undocumented executive routines in C on both VAX and AXP. But it is possible with BLISS. o Customers would be able to better understand the OpenVMS source listings, since they could learn and use BLISS them- selves. 5 Bundling BLISS with OpenVMS o It could provide a larger base of potential developers for Digital, since more people would have a chance to learn and use BLISS. o There is a lot of freeware available that is written in BLISS, including Message Exchange (MX), the Supervisor Series, and CMU-IP (aka CMU-Tek aka other names). These packages are in use at hundreds of sites around the world. Bundling BLISS with VMS would allow for easier distribution of freeware products, allowing the end-user to compile the code himself. o Most importantly, Digital will no longer be slapping the faces of the vendors and developers who followed their advice and used BLISS to develop their products. Digital has lost enough business lately without alienating those of us who deeply care about the future of OpenVMS. 3 What About Support? Many in Digital are concerned about the level of support that BLISS will require if it is bundled with OpenVMS. I see two options here: o Provide the same level of support for BLISS that is currently provided for MACRO-32. Does the Digital CSC really spend much time supporting MACRO-32 programmers? I would guess not. MACRO-32 is described in a manual in the OpenVMS documen- tation set. Everyone I know that uses or has used MACRO-32 learned the language from reading that manual and looking at examples. If Digital decides to bundle BLISS and promote it, then the same steps should be taken: SPRs should be accepted and a manual should be available. 6 Bundling BLISS with OpenVMS o Put the BLISS compilers in the OpenVMS distributions, but not document their presence. Digital has done this many times before, most notably with TECO, SET WATCH FILE, and WATCH (the watchpoint driver). In fact, the WATCH documentation (WP.HLB in SYS$HELP:) goes out if its way to mention that the product is not supported by Digital. BLISS could be treated the same way. It'd be there for those who want to use it, but there'd be no telephone support and no hardcopy documentation for it. Support for users programming in BLISS would come from the user community through DECUServe, comp.os.vms, etc. The second option does not mean the compilers should not be updated, but rather that there's no Layered Product Support available for it. Each time a new version of OpenVMS is ready to ship, the current version of the BLISS compilers should be included in the kit. This way, Digital still provides bug fixes for the compilers without directly supporting the compiler as a layered products. (And the bug fixes would include any changes Digital made in the course of their own internal support of the compilers.) 4 Other Options While I think the best thing for Digital to do would be to bun- dle BLISS with OpenVMS, there are at least three other options available: o Bundle BLISS with OpenVMS, but treat it like POSIX. I.e, a BLISS license is included with OpenVMS, but it must be installed separately. o Put the BLISS compilers in the DECUS Library, again with virtually no documentation (outside the HELP file). By plac- ing it here, there would be absolutely no implied support of the compilers (though they should be updated periodically as revisions are made). 7 Bundling BLISS with OpenVMS o Give the compilers away to anyone who wants them by making them available via anonymous ftp from gatekeeper.dec.com. Making it freeware does not make it public domain, as Digital knows. There are precedents for all four cases, and I would much prefer to see one of those used with BLISS than to see it die out. 5 Summary For years, Digital encouraged programmers and vendors to use BLISS when developing software for OpenVMS, even though the compiler was priced too high for most companies. Now Digital wants to pull BLISS from the market, citing the fact that it provided very little cash flow for them. Since Digital still has to maintain the BLISS compilers, the compilers should be bundled with OpenVMS VAX and OpenVMS AXP as either a supported component or an unsupported component. As long as Digital updates the compilers when they are updated for internal use, I see no reason that BLISS couldn't be bundled with OpenVMS as an unsupported product. It would cost Digital virtually nothing, and it would provide OpenVMS programmers with one more reason to stick with OpenVMS. The items discussed above have come from my own observations and from the observations of fellow BLISS programmers. 8