DECUServe Journal Part 3

[Sharon Frey]


December, 1993 The DECUServe Journal Page: 69

San Francisco Restaurant Guide
------------------------------

The following article is an extract of the DECUServe
Symposia_Public conference topic 267; another conference
that is shared between DCS and DECUServe. The conversation
occurred between July 29, 1993 and August 25, 1993.

By Sharon Frey, Jim Sims, Curt Snyder, Matt Holdrege, Art Frydenlund,
Douglas Brantley, Jamie Hanrahan, Bret Wortman, Glenn Dollar, Brian Tillman,
Chris Simon, Gus Altobello, Bob Koskovich, Pam Mayhew, Greg Yarmoluk,
J. Scott Boykin

(07/29/93 Frey)
---------------
I'd like to start a topic stream where people who are familiar with the
San Francisco area discuss their favorite restaurants. This should help those
of us who attend the coming west coast event.
Suggestions? Reviews?

(07/30/93 Sims: Mexican Vegheads)
----------------------------------
Well, I haven't been there (except for the airport) since DECUS was there
last time, but...
When you come out of the Marriott, heading toward the Moscone Center (which
is actually diagonally left, go straight) about 2 or 3 blocks straight ahead
and or or two blocks over is a hole-in-the-wall Mexican place that is
*awesome*. The place is only about 10x10 but the food is great and cheap.

(07/30/93 Snyder: Garlicheads)
-------------------------------
There is a restaurant that I have seen while there, but have not yet had
the opportunity to try. It's called "The Stinking Rose" and EVERYTHING is
loaded with garlic. Stay away from Pier 39 (Fisherman's Wharf), the prices
are extravagant and the food marginal.
Fiddler's Green, near Fisherman's Wharf, but up a few streets, is a
wonderful Irish pub with a blues band upstairs in the back....

(07/30/93 Holdrege: Compass Rose)
----------------------------------
The Compass Rose is one of the classiest saloons that I have ever sipped a
soda at. It's at the Westin St. Francis.
I'll be staying there for Interop in a few weeks. I hope to visit the
Embarcadero then.

December, 1993 The DECUServe Journal Page: 70

(07/30/93 Frydenlund: Some Spots not in the City Guide?)
---------------------------------------------------------
Since the quake, I have done little eating in downtown SF. But, based on
old sampling, here are some pointers.
Clown Alley has an outstanding hamburger. The spicing is unusual and you
will either love it or hate it. There is little in between opinion. CA is a
fifties style, with modest updating diner chain.
Salmagundi's is a mighty fine Soup and Salads and Sandwiches and Quiche
place. Cafeteria style. Popular with the pretheatre crowd. Modest prices.
They were wounded by the quake and I don't know the current status of the chain.
DAVID's is popular with the after theatre crowd (though it is open more of
the day) A combination bakery, deli. I have a real liking for their Blintzes.
Sit down style service.
Fresh Choice is a Salmagundi competitor. Single price. Broad selection of
salads, three our four soups, three or four pastas, outstanding muffins,
dessert bar, all you can eat. Heavy on the "health food". Location's
throughout the bay area.
The Tassajara Restaurant (at Fort Mason) is run by Zen's. Outstanding
vegetarian fair. (They also publish three or four cook books).
Although I normally stay clear of Pier 39, Fisherman's wharf area digs,
there is one spot in that area that is big on my list and that is Ghirardelli's
Ice Creamery at the Ghrardelli Square tourist trap. The prices are outrageous,
but so are the sundaes.

(08/03/93 Brantley: I'll Bite...)
----------------------------------
I will be in The City August 21 and 22 for a short vacation. Maybe I can
collect some data on the local eating establishments. I will look for a travel
guide and see what it has to say.
My wife will enjoy this...

(08/03/93 Frey: aha!)
----------------------
Any other favorite places to eat? Personally, I've enjoyed TGI Friday's
which is not too far from the Embarcadero. Aside from that, I haven't eaten
in San Francisco very much. How about you frequent visitors/residents?

(08/03/93 Hanrahan)
-------------------
TGIFriday's is a national chain. Fun places, but not what you want if
you're looking for something that's unique to the area.

(08/03/93 Wortman: They're *everywhere*! :-) )
------------------------------------------------
They even have Friday's in *Iowa*!
Ducking and running....

December, 1993 The DECUServe Journal Page: 71

(08/04/93 Dollar: San Francisco Resturant Guide)
-------------------------------------------------
For those of you who like Dim Sum, the best is the Hong Kong Resturant
on Pacific in the heart of China Town.

(08/04/93 Tillman: XCOM (and former XCOM) might know some)
-----------------------------------------------------------
Hey, Jeff Killeen, Pierre Hahn, Chris Rhode - where was that little
Sicilian restaurant we ate in a few years back, before riding the street cars
for a while?

(08/04/93 Simon: If you need a good guidebook)
-----------------------------------------------
I need to put in a plug here for my favorite guidebook. There is a series
of guidebooks called "Access Guides" by Richard Saul Wurman, author of
_Information Anxiety_. The San Francisco one is called _San Francisco Access_
(surprise!) These books are arranged by neighborhood, not by type of
establishment. In other words, rather than putting all of the restaurants in
one section, hotels in another, etc., they have all of the stuff that's close
together geographically in the same section. San Francisco lends itself to
this sort of treatment very well. The restaurant listings cover many price
ranges and are very helpful. We've had great luck with this book on several
trips to the area, finding nice little restaurants with no tourist traffic.
You can pick up this book at most bookstores for about $15.
One of our favorite places discovered with this book is a small restaurant
(seats about 40) called Hyde Street Bistro. It's on Hyde Street and the cable
car runs right past it, but no tourist traffic in the restaurant itself.

(08/04/93 Snyder: Scoma's Gets My Vote!)
-----------------------------------------
An OUTSTANDING seafood restaurant, yes, down on the waterfront, is Scoma's.
Excellent LARGE servings at fairly high prices. I can't imagine a trip to
SF without a meal at Scomas....

(08/09/93 Frey: Steak anyone?)
-------------------------------
There's a restaraunt that's being heavily hyped on my favorite AM radio
show <;-)> that I'm dying to try. It's called something like Ruth's Criss
Steakhouse, but I may have the spelling wrong. It's supposed to be on the
corner of Van Ness and California (if I remember right).
Has anyone eaten there who can tell us what they think?

(08/09/93 Coy: Good!)
----------------------
It's Ruth's Chris. There are ones in Atlanta and New Orleans.
There is one in Las Vegas that is absolutely superb.

December, 1993 The DECUServe Journal Page: 72

(08/10/93 Altobello: ...probably closed...)
--------------------------------------------
10 years ago, there was a new place called (I think) "Szechewan" which
served some really good, and really spicy, Chinese food. Is it still there
(near the waterfront?).

(08/10/93 Koskovich)
--------------------
Isn't that the place in Ghirardelli Square? (Second floor of the Woollen
Mill building, I think...) If so, it was there as of last January; I ate there
at Macworld.
Another cool place that we ate a few years ago is "Embarko" -- the fare is
Caribbean-ish. When we went, it was over in a heavy-industrial section on the
Bay side of the City. I'll have to see if I have info.
And of course, there's always the Hard Rock on Van Ness... Maybe a bit
touristy, but it was walking distance from our hotel, and we had a fine time
drinking Iced Teas and chuckling at the crowd.

(08/10/93 Koskovich)
--------------------
>Stay away from Pier 39 (Fisherman's Wharf), the prices are extravagant and
>the food marginal.

In general I'd agree. But there was a place upstairs -- the name I forget
(of course) ... Neptune's somethingorother? -- that had some quite good food.
I can still taste the chocolate dessert that COULD NOT be cut with a fork, and
had to be melted off the roof of my mouth with hot coffee.
Hmmm... I need to look around here for some chocolate right now, come to
think of it. :-)

(08/10/93 Koskovich: Second! :-) )
-----------------------------------
>Ghirardelli's Ice Creamery. The prices are outrageous, but so are the sundaes.

(08/10/93 Mayhew: Do they deliver...to Massachusetts? <groan>)
---------------------------------------------------------------
>I can still taste the chocolate dessert that COULD NOT be cut with a fork,
>and had to be melted off the roof of my mouth with hot coffee.

<DYING>

(08/11/93 Yarmoluk: Food Headlines)
------------------------------------
Headlines...

DECUS Meets Demise Due to Chocolate Withdrawal


December, 1993 The DECUServe Journal Page: 73

DECUS Causes Nationwide Chocolate Shortage with 1 Day Binge

DECUS Opts for Larger Convention Center - Attendence is Down but Size is Up

DECUS Awards Weight Loss Contract to Weight Watchers - Largest Contract in
Company's History

DECUS Bans "Chocolate" and Explicit Food Discussions from Notes Conferences

DECUS Lobbied to Rescind Chocolate Ban by Food Lobby - Sales Spiraling
Downward

DECUS Gives Thumbs-up to Chocolate and Other Good Food in Notes
Files - Prez Clinton Credits Society for Economic Turnaround

DECUS Lambasted by Perot for Deficit Eating

DECUS Rebuffed by Republicans - Cited as Society where Geeks Meet and Eat

DECUS Awards Medal to Bob Koskovich for Publishing Sinful Chocolate
Dessert Recipe (hint, hint)

DECUS Forgiven by Ross and GOP Thanks to Chocolate Dessert that Couldn't
be Cut with Fork

DECUS Notes Conference Proves Pavlov's Theories

(I gotta find a vending machine!)

(08/23/93 Frey: Meat-eaters Unite!)
------------------------------------
Well, a couple of weekends ago I and my boyfriend and some friends went to
Ruth's Chris Steakhouse in San Francisco. I'm glad to announce that it was
completely wonderful!!
It's very expensive. The filet is $20, but it is HUGE: 12 to 14 ounces.
And everything is ala carte. The steaks are served solo on a plate, sizzling
in butter. The portions of the side dishes are enough for two people to share,
which is good because they are pricey too. The tab for just my beau and I
(with no alcoholic beverages) was around $80! They gave us french bread to
start the meal, and also garlic cheese bread with the meal. We had a really
great time, and the food was "to die for". I'll definitely go back next time
I can afford it! :-)
Dress ranges from nice-casual to formal. It's on the corner of Van Ness
and California. They have complimentary valet parking for customers, which is
appreciated since there's absolutely no street parking available. For a really
decadent, hedonistic time, I heartily recommend it!! :-)

(08/25/93 Boykin: Any reviews in ba.food??)
--------------------------------------------
While browsing through the list of Internet News Groups, I discovered
that there are several news groups devoted to the Bay Area. Included are
ba.food and ba.weather. Could someone who has access to these groups post

December, 1993 The DECUServe Journal Page: 74

whatever information is available in them here? Or at least follow the food
group and post any interesting restaurant reviews.

Jorma Tapola "DECUServe is a GOOD example of how a computer
Quoted on 09/01/93 in system should be run. Thank YOU! P.S. IS there
DECUServe_Forum 373 a DECUServe FunClub?"

UNIX-like system differences?
-----------------------------

This article is an extract of the DECUServe Unix_OS
conference topic 197. The discussion occurred between
May 14, 1993 and June 16, 1993.

By Mark Shumaker, John Burnet, Terry Kennedy, Matt Holdrege, Joe Matuscak,
Ray Whitmer

(05/14/93 Shumaker)
-------------------
I need to get some (fairly accurate) idea of what differences exist between
or among various current or recent UNIX-like systems marketed (SUNos, Solaris,
HP-UX, Ultrix, OSF-1, AIX, and SCO are presently being considered). I
understand that some of these are based on various System V releases and some
on various BSD versions, and that file systems are therefore different and that
some common shell commands are incompatible between the different versions, but
I need to know just what the specific differences are. Can anyone point me to
a publication that lists these differences, or share with me the results of
their own research?

(05/14/93 Burnet: A couple of older references)
------------------------------------------------
Not much, but it's a start:
As part of the SVR4 manual set, Unix Press (Prentice-Hall) publishes at
least three volumes in what they call the "Migration Series":

UNIX System V Release 4 BSD/XENIX Compatibility Guide
UNIX System V/386 Release 4 Migration Guide
UNIX System V Release 4 ANSI C Transition Guide

The first of these sounds like it might be useful, since Solaris 2.x is
based in part on SVR4. Also, have you checked the Solaris 2.x manual set?
I'll bet there's some stuff about migration there.
A SVR4 manual from the same doc set says to call 201-767-5937 to order. The
"Unix Software Operation" SVR4 books were published under the direction of AT&T,
and I assume that Novell/USL has taken over that responsibility, so I don't
know whether this number is still useful.

December, 1993 The DECUServe Journal Page: 75

Mark Horton's book *Portable C Software* (Prentice-Hall, 1990) includes two
tables, "Portability of C Library Functions" and "Portability of UNIX System
Shell Commands", that compare features from various Unixes. The systems that
are covered in the latter table are POSIX, SVID (R3), SVR3, System III, V7, and
4.2BSD. As you can see, the table is a few years out of date... but it should
still help somewhat, if only to show you the kinds of differences that are
common.
I'm surprised that the O'Reilly people haven't published some sort of
reference manual that does a feature-by-feature comparison among the Unix
flavors that are current. I don't see anything appropriate in their latest
catalog.

(05/14/93 Burnet: -More- )
---------------------------
There are several documents available for anon FTP from gatekeeper.dec.com
that should be of interest:

92.11.05 11:19 1k pub/DEC/DECinfo/whitepaper/osf-os-comparison.abs
92.09.02 13:24 212k pub/DEC/DECinfo/whitepaper/osf-os-comparison.ps
92.11.05 09:37 73k pub/DEC/DECinfo/whitepaper/osf-os-comparison.ps.Z
92.11.18 10:29 1k pub/DEC/DECinfo/document/osf1-v1p0-svid-2-compatibility.abs
92.09.09 14:12 101k pub/DEC/DECinfo/document/osf1-v1p0-svid-2-compatibility.ps
92.11.18 16:49 42k pub/DEC/DECinfo/document/osf1-v1p0-svid-2-compatibility.ps.Z
92.11.18 10:49 1k pub/DEC/DECinfo/document/ultrix-to-osf1-migration.abs
92.09.02 13:29 1192k pub/DEC/DECinfo/document/ultrix-to-osf1-migration.ps
92.11.18 16:50 398k pub/DEC/DECinfo/document/ultrix-to-osf1-migration.ps.Z
92.11.04 10:13 1k pub/DEC/DECinfo/document/fortran-migration.abs
92.09.08 13:22 140k pub/DEC/DECinfo/document/fortran-migration.ps
92.11.04 10:20 52k pub/DEC/DECinfo/document/fortran-migration.ps.Z
93.04.13 15:31 1k pub/DEC/DECinfo/infosheet/unix-migration-services.abs
93.04.13 15:31 10k pub/DEC/DECinfo/infosheet/unix-migration-services.txt

A couple of additional random comments:
Ultrix V4.x is more or less a "pure" 4.2BSD implementation, with some 4.3BSD
enhancements and a lot of DEC stuff like DECnet and LAT added, so in comparison
charts like the one in the Horton book that I mentioned you should be able to
assume that the 4.2BSD information applies to Ultrix.
Making big news these days is a new consortium of Unix vendors called COSE
that is attempting to present a unified front to the WNT threat. Included are
Sun, HP, IBM, USL/Novell, and SCO. Excluded is DEC. :-) :-( They have agreed
on X11, Motif, OSF DCE, Netware, and several other products as the common
subsystems to be used across all of their versions of Unix. Although this
won't wipe out the differences among those Unix variants, it will go a long way
toward ensuring compatibility of vendor-supplied and 3rd-party application
software. It's really sad that it took a major market threat to get those
companies to work together. There's nothing like a common enemy to turn
competition into cooperation.

(05/15/93 Kennedy: Well, it's not *that* new 8-))
--------------------------------------------------
The last time I looked at Ultrix internals (V4.1?), it was a pre-4.2BSD
implementation that made an effort to track 4BSD changes, unless the DEC folks
felt that the DEC way was better.

December, 1993 The DECUServe Journal Page: 76

From looking at things like Ultrix drivers, they pre-date 4.1BSD.
This is likely to be much more visible at the internals and API levels than
in the provided commands, though.

(05/16/93 Holdrege: My personal opinions)
------------------------------------------
Here are some _negative_ comments. These are based on subjective opinions
from a non-guru. Each of these operating systems has many great features, but
listing the good stuff would take too much time.

SunOs BSD lots of little bugs.

SunOs SYSV Very new and relatively untested.

HP-UX Poor diagnostics and poor overall support, many features
are proprietary. Some common utilities are non-standard.

Ultrix Lots of proprietary stuff, lots of holes.

OSF/1 Very new and relatively untested.

AIX Little adherance to RFC's. Lots of proprietary stuff. Many
bugs.

SCO Weak, based on old software.

OSF/1 seems the most promising, with SunOs 5.x runner up.

(05/17/93 Matuscak: Where does Solaris fit?)
---------------------------------------------

(05/17/93 Holdrege: Solaris)
-----------------------------
Solaris is a marketing name for SunOs. It also includes the OpenWindows
product. Solaris 1.x is BSD. Solaris 2.x is SYSV.

(05/17/93 Burnet: (non-)portability of file systems)
-----------------------------------------------------
Regarding file-system differences: Remember that you can use NFS to hide
the differences, if you don't mind the performance hit and the potential
security problems. :-/ NFS over FDDI should give acceptable performance...
This doesn't cover the case where you want to exchange file systems on
removable disks; but it's better to use tar and cpio for that, instead of
moving the file systems themselves.
(Actually, with high-capacity SCSI disks in external cabinets being quite
small and portable these days, I guess those qualify as "removable disks". It
would certainly be an advantage to be able to move a whole disk, with its file
systems, from one machine to another one that runs a different OS. But good
luck getting that to work...)

December, 1993 The DECUServe Journal Page: 77

(05/18/93 Whitmer: After brief encounter, I dislike SCO)
---------------------------------------------------------
I've had to port VMS stuff to a few UNIX boxes. The two I've had the most
experience with were Sun and SCO.
Sun never gave us a problem whereas SCO continually had made claims to
support things which didn't work when you tried them. A major thing we were
trying to get a signal on a file descriptor when it had input. Worked
beautifully on Sun, but didn't work at all on SCO. The SCO support spent their
time trying to convince us that we really didn't want to do the I/O that way,
as well as trying to convince us that the work-arounds we were attempting using
pipes would be miserably slow under SCO.

(05/18/93 Shumaker: I appreciate the info so far; and some background.)
------------------------------------------------------------------------
I appreciate the information so far. I'm getting the documents from
_gatekeeper_ that John recommended; with the C language book reference I may
have enough to start out with.
The application involved has to do with manufacturing software (mostly
scheduling) which is now being decentralized to each plant, and in some cases
to different operations in each plant. It appears that all such operations
have at least agreed on a common software package, one vendor's code associated
with a Oracle database, which runs on several different UNIX platforms. Since
the plants and operations vary _greatly_ in size and complexity, and the plant
managers have a great deal of autonomy, we expect that at least three different
platforms will initially be used -- 486/SCO, Sparc-10/Solaris 1 or 2, and
either HP/HP-UX, IBM/AIX, or DEC/Ultrix.
My problem is that our department will be responsible for writing and
maintaining some procedures that are to run on all of these platforms,
extracting data and transmitting it to a central site for Corporate-wide
production reporting. I _really_ want to avoid writing and maintaining several
slightly different versions of these programs. The classic method for this
would be to research all of the intended target environments to develop a list
of common features. Since this manufacturing software will be introduced in a
much larger scale on different machines if the trials are satisfactory, I
really can't predict what the list of target environments might be. This is,
of course, our first attempt at using UNIX in a critical 'production' (as
opposed to research) application.

(05/24/93 Burnet: I think perl is what you want)
-------------------------------------------------
I strongly suggest that you take a look at the perl language, and forget
about writing procedures in the various shell languages (sh, csh, ksh, etc.).
I can't provide any perl expertise; all I can do is to refer you to the standard
reference and to mention that perl is a public-domain program, so its source
code is available on the net (just ask archie). The reference is *Programming
perl* by Larry Wall and Randal L. Schwartz (O'Reilly, 1991).
The advantage that perl has over the various *sh languages is that there
will be *no* differences from one system to another. Setting up perl and
getting it running on all of your systems might take a little effort, but I
think that will be minimal compared to the effort of keeping shell scripts
coordinated if you're going to be using all those different versions of Unix.

December, 1993 The DECUServe Journal Page: 78

(06/06/93 Burnet: A couple more references)
--------------------------------------------
The discussion of Unix over in SHOP_TALK reminded me of two more books that
are useful in determining what differences exist among the various Unix
versions. I've recommended these before in other discussions here; they are:

*Unix System Administration Handbook* by Nemeth, Snyder,
and Seebass (Prentice-Hall, 1989)

*Essential System Administration* by Æleen Frisch
(O'Reilly, 1991)

These are valuable and useful books in general, and they do have a lot of
information about the differences among BSD, SysV, AIX, etc. that will be seen
by a system administrator. However, neither one has any convenient summary or
table of those differences, so you would practically have to read (or at least
skim) the whole book in order to get the picture. Each book is organized by
topic: adding and removing users, security, the printing subsystem, file
systems, and so on -- so if you are concerned about one or two specific areas
where differences might exist, you can probably find what you need pretty
quickly.

(06/16/93 Burnet: Unified Unix on the way?)
--------------------------------------------
> Making big news these days is a new consortium of Unix vendors called COSE
> that is attempting to present a unified front to the WNT threat. Included

DEC has just joined COSE. I guess we'll find out just how cozy they can
be with Sun, IBM, and the others.

Running out of headers on a disk
--------------------------------

The following article is an extract of the DECUServe VMS
conference topic 2019. The discussion occurred between
February 25, 1993 and August 13, 1993.

By Don Roberts, Terry Kennedy, Dale Coy, Rob Brown, Richard Black, Glenn Zorn,
George Cornelius, Pat Scopelliti, Carl Friedberg, John Osudar, Jonathan Prigot,
Bill Bochnik, Larry Stone, Frank Nagy

(02/25/93 Roberts)
------------------
We occasionally have problems with disks running out of headers. Today we
had this occur on our disk that has News on it. In the past we've always
relied ion the default for headers (16) and maximum files. I'm wondering if
others have guidelines as to what they do to deal with this. Do you set
maximum_files to the maximum for the device? Do you allocate more headers than

December, 1993 The DECUServe Journal Page: 79

the default? What guidelines do you use? Has anyone put together a procedure
that figures out what the maximum for a device is so that they can
automatically initialize the disk that way? What are the tradeoffs associated
with these numbers?
Is this a question for hardware_help? :-)
Thanks for any help in this area.

(02/25/93 Kennedy: What we do)
-------------------------------
My News disk (an RA90) was INIT'd with /HEAD=300000, /MAX_FILES=300000.
We're currently using about 201000 headers. About the only way I can see to do
this is to look at existing usage and try to extrapolate what will happen with
more newsgroups/longer retention.

(02/25/93 Coy: What I think I know)
------------------------------------
This isn't a "science" - and I'm not sure I have all of this straight,
but if I don't I'd like to learn. Somebody is sure to help.
First - part of the equation is the size of of INDEXF.SYS, which is by
default started as a small file and extended as needed to accommodate the file
system. If the disk free space is severely fragmented, then INDEXF.SYS can't
be _extended_ as far as you might need for the maximum_files you have specified.
Specifying maximum_files does not allocate space in INDEXF.SYS. It just
sorta says how big INDEXF.SYS can get - if it can be extended.
If you want to pre-allocate space (a wise plan for high-creation-activity
disks), you do that by specifying /HEADERS (and, I think, /directories also
pre-allocates space - but that's not your problem).

> Has anyone put together a procedure that figures out what the maximum
> for a device is so that they can automatically initialize the disk that
> way? What are the tradeoffs associated with these numbers?

Not quite that easy. The maximum MAX_FILES is
(total blocks) / (cluster_size + 1)
If you take the default cluster_size, then the computation for max_files
and for /headers could be guesstimated.
But you may want to _not_ take the default cluster_size. If you know
enough about how the disk is being used, you could use a different (smaller or
larger) cluster_size. [and possibly /extension]
If you do _not_ pre-allocate a large number of headers, then you might be
wise to pay attention to defragmenting the disk - [partially because
highly-fragmented files may use extra headers, but also because free-space
fragmentation may prevent fully extending indexf.sys

(02/26/93 Brown: What I think I know)
--------------------------------------
Speaking from my experience with ODS-1 ...


December, 1993 The DECUServe Journal Page: 80

>If the disk free space is severely fragmented, then INDEXF.SYS can't be
>_extended_ as far as you might need for the maximum_files you have specified.

I didn't know that.

>Specifying maximum_files does not allocate space in INDEXF.SYS. It
>just sorta says how big INDEXF.SYS can get - if it can be extended.

I would think that specifying the maximum number of files determines how
much space is allocated in INDEXF.SYS for the index file bitmap (one bit per
header) at the beginning of the index file (between the home block and the
header for INDEXF.SYS). In ODS-1, once this bitmap is full, there is no
provision for extending it. I don't know if ODS-2 has a way of extending it
or not.
When I initialize a disk, I create the index file with a pre-allocated
number of headers appropriate to how many I expect to use. I got into this
habit because RSX always created far more headers than I wanted. I had no idea
that VMS went too far the other way.
How large a max to specify? As Terry and Dale said, you have to guess how
you are going to use the disk. If you are going to fill the disk with
one-block files, then you had better specify something like

# blocks on disk
--------------------
cluster-size + 1

as maximum files.

(02/26/93 Black: Check INDEXF.SYS fragmentation)
-------------------------------------------------
I do not know what News is but we have a similar problem with the ALL-IN-1
shared mail areas. Our solution is like in .1 to create the disk with high
values for /HEAD and /MAX_FILES.
We run a check once a week on our INDEXF.SYS to see when it is time to do
a backup/restore of the disk. We do this by checking the number of Map Area
Words in use for the INDEXF.SYS, 10 is the defualt and 150 is the max. When we
reach 100, we check that disk every day. When we reach 130, we schedule a
backup/restore operation for that disk that night.
To get the number of Map Area Words in use for a disk do the following:

$DUMP/HEADER/BLOCK=COUNT:0/OUT=name.DMP DISK$name:[000000]INDEXF.SYS
$SEARCH name.DMP WORDS

(02/26/93 Roberts: More questions)
-----------------------------------
I guess I'm being left a little baffled as to the result of using the
/header qualifier. The manual says the default for this is 16, but the default
for maximum files is blocks / ((clustersize+1)*2). I see a bit of disparity
here. Terry says make headers same as Maximum_files, which is a much bigger
change for /headers. Does the statment about the one bit per apply to the

December, 1993 The DECUServe Journal Page: 81

/header qualifier? What exactly is the difference between the default for
/headers of 16 and setting it to maximum_files?

(02/26/93 Coy: It all depends)
-------------------------------
I think you're getting the same song from several viewpoints.
/Header defaults to 16 and its maximum is the same as whatever your
/maximum_files is. If you init it to the default (16), then it will extend
"as needed" up to the maximum. *IF* it can extend. I think I remember that
there can only be something like 70 extents (and one "extend" might take
several extents).
So, if you have a problem disk, you may want to pre-allocate by using
/headers=whatever. If you know enough, then /headers=NNNN (the maximum_files)
is a good number to use.

>Does the statment about the one bit per apply to the /header qualifier?

I _suspect_ that the "bits" get allocated in BITMAP.SYS based on
maximum_files. But in any case the "bits" aren't likely to be your problem.
For one thing, "bits" are small. (serious comment).

Notice that the
DEFAULT for maximum_files, and the
MAXIMUM for maximum_files
only differ by a factor of 2. (given the same clustersize).

And that the default essentially provides for creating a number of files of
size (2 * clustersize) that fills up the disk. That's a bunch of small files.
What's the average size of a file on your NEWS disk? (yes, it might well be
that small - but you should look).

>difference between the default for /headers of 16 and setting it to
>maximum_files?

The difference is in the size that is ALLOCATED at the time you init the
device. If you take the default, some small size is allocated, and may be
extended as you need more headers. If you set it to maximum_files, then the
whole amount of header space is pre-allocated, you can never use it for space
for the files themselves, etc. Any headers you don't use are "dead space" on
the device. OTOH, you will never have a "no headers" problem.

(02/27/93 Cornelius: Extending INDEXF.SYS)
-------------------------------------------
By the way, have you ever tried pre-extending INDEXF.SYS without
reinitializing?
I had a particularly bad case in which I had a disk that had some corrupted
Pathworks/Mac data that I knew could not undergo a full rebuild, so I could not
use the normal approach of initializing a new volume and copying to it
(Pathworks/Mac has some private structures that depend upon file-ID's being

December, 1993 The DECUServe Journal Page: 82

preserved, although a volume "rebuild" function is available in case files are
copied without this preservation). As a desperation move, I wrote some code to
extend INDEXF.SYS. After trying direct ACP calls, I found that an RMS $EXTEND
call worked just as well. My procedure for extending INDEXF on the volume
became:

1. Mount volume privately, with

$ MOUNT/CACHE=(NOEXTENT,NOFILE_ID,NOQUOTA,...)

2. Run program to do an RMS $EXTEND call on INDEXF.SYS

($OPEN,$FAB_STORE to set up linkage to an allocation XAB,
$EXTEND,$CLOSE)

3. ANALYZE/DISK/REPAIR

(This is needed because there are redundant copies of
the INDEXF.SYS header that are not updated by $EXTEND).

Again - the above is _not_ recommended - just because it works for me is
no indication it will work for you, or will continue to work.
I recently ran across a suggestion for a better way. Set default extend
size (with volume privately mounted, perhaps) to a large number - say 40,000
blocks. Then create as many empty files as the number of additional file
headers you need. Finally, set the default extend size back to normal and
delete the extra files. What should happen is that each INDEXF.SYS extend
operation will be by the volume default extend value instead of the INDEXF.SYS
default of 1000 blocks per extend operation. The large extend size should help
reduce fragmentation of the INDEXF.SYS header as you preallocate.
It is good to start with a defragmented volume - use BACKUP/IMAGE - before
you do this. And be prepared for it to take several hours - file creations
and deletions are not blindingly fast under VMS.

02/27/93 Coy: Just to make sure the picture is clear)
------------------------------------------------------
One thing that I don't think has been explicitly stated yet:
There is one block in INDEXF.SYS for every file on the disk. So, obviously,
the size of INDEXF.SYS (in blocks) must be at least equal to the number of
files.

(03/01/93 Roberts: Yikes, /header makes the file BIG!)
-------------------------------------------------------
Finally had a chance to try the init with /headers. There appears to be a
one to one correlation between headers value and blocks in indexf.sys (after a
certain minimum). I tried /max=600000/head=600000 and got a max files of 512k
and indexf.sys of 600000 blocks. So I decreased /head to 200000 and the file
went to 200000. Yikes! Our typical indexf.sys is 45k blocks or less. That
sure eats up a chunck of disk in a hurry (this was clustersize 7, btw).

December, 1993 The DECUServe Journal Page: 83

* clustersize 7 was chosen due to my perverse sense of humor, no other
reason :-)

(03/01/93 Coy: 1 block = 1 header = 1 file)
--------------------------------------------
Yes, as previously stated, there must be (AT LEAST) one block in INDEXF.SYS
for each file (header) on your disk. So, if you pre-allocate for 600000 files,
there will be 600000 blocks in INDEXF.SYS
Clustersize of 7 has not much to do with it - except that you can't have
more files than (disk_size)/(clustersize). But on your 4.2 Gig disk with
clustersize 7, 600000 files is a reasonable number. :-)
Also - with the default values for init, your indexf.sys will never get
bigger than around 50,000 blocks. So regardless of the size of the disk or
the clustersize, if you use defaults, you will never get more than around
50,000 files.

>clustersize 7 was chosen due to my perverse sense of humor, no other reason :-)

OK - but there are maybe better ways to choose the clustersize.

(03/02/93 Scopelliti: Managing INDEXF.SYS)
-------------------------------------------
Talking with CSC/Colorado one day they mentioned several things:

$ DUMP/HEADER/BLOCK=COUNT=0 disk:[000000]INDEXF.SYS will display
INDEXF.SYS's header information. Look for "Map area words in use" If
this gets to about 155 - INDEXF.SYS cannot get any more extents. Get
ready to say Backup/Restore :-(

$ INIT.../EXTENSION=10000 will cause INDEXF.SYS to extend by 10,000
blocks each time - haven't had a chance yet to test this or its
side-effects.

(03/03/93 Friedberg: BACKUP/IMAGE/NOINITIALIZE will leave /HEADERS alone)
--------------------------------------------------------------------------
Prior to VMS 3.7, it was possible to preallocate using the init/header and
backup/image/noinit to pre-extend the index file, just as in RSX (yes, indexf
gets big; that is the idea! you want to avoid indexf extends). However, after
3.7, backup/noinitialize ignored the settings for headers, and shrunk
indexf.sys back down to the exact size required by the number of files
restored. THis certainly caused problems for ALL-IN-none mail disks, among
other areas, where huge number of temporary files can be created.
THIS HAS BEEN FIXED. Somewhere around 5.5-2, backup/image/noinitialize will
leave the size of the indexf.sys as set by your initialize command. (I filed
an SPR sometime in the mid-eighties about this one...) SO the pre VMS 3.7
behavior has been restored. Thank you, VMS engineering.
I also believe there were quite a few VMS crashes when indexf.sys got too
badly fragmented; this also has been fixed now, but it was a nuisance.

December, 1993 The DECUServe Journal Page: 84

(03/03/93 Zorn: Definitely fixed in V5.5-2)
--------------------------------------------
I can vouch that the BACKUP/NOINIT problem has been fixed in V5.5-2 I just
spent a weekend doing backup/restores and have another weekend left to do.
Performing an INIT/HEADER is the way to go and you have to use your best
judgement on the value. For our main user disk I took the current number for
files (including .DIRs) and increased by 50%. This should give me enough
growth room to last a while.

(03/10/93 Osudar: a word of caution)
-------------------------------------
Beware -- the original version of BACKUP in which the /NOINIT problem was
"fixed" was one distributed as a CSC patch kit (CSCPAT_1101). Early versions
of that kit had a serious bug, in which BACKUP wouldn't clear unused headers
in the newly created index file. This would result in "phantom" files and
directories, and multiply allocated blocks on the disk. If, by any chance,
you're running a BACKUP from CSCPAT_1101, make sure the patch kit version is
at least 1.2.
As far as I know, none of the BACKUP images distributed with VMS itself
have had this problem.

(08/11/93 Bochnik: What about the system disk?)
------------------------------------------------
Does anybody have any GOOD recommendations as to how you would do all of
this on the SYSTEM disk? If I can avoid a SABACKUP via some arcane juggling
of disks around, and min boots, I'd be MUCH happier. Any ideas?

(08/11/93 Stone: Do you have a spare disk?)
--------------------------------------------
I don't have a suggestion to avoid using SABACKUP but if you have a spare
disk, you can avoid going to tape. Just do a disk-to-disk image backup
(BACKUP/IMAGE/any_other_qualifiers_you_like_such_as_VERIFY source_disk:
target_disk:). You can then swap the unit plugs (or reprogram the disk
depending on type) or just reverse the process to get back to the original disk.
We shadow all our disks (Phase I) and our defrags are simply a disk-to-disk
image backup from one member of the shadow set to the other. VMS is smart
enough to know which is the defragged version (since it's the most recently
updated) and then does a shadow copy from it to the other. The only exception
is the system disk where you boot off one disk (as a single member shadow set)
and then add the other disk with a shadow copy. Obviously, there we must make
the boot disk the target of the image backup.

(08/11/93 Bochnik: Our Sys disk is shadow'd)
---------------------------------------------
Would you then not boot the system minimally off of one member of the
shadow set, do the backup to the other, shut down, reboot off of the second,
and do the shadow copy? That is what I'm almost down to here. I figured that
the min boot would be fairly safe, as the que manager would not be up, no users

December, 1993 The DECUServe Journal Page: 85

sould be logging in, etc. so the system disk would have very few "open for
write" files.
Does this sound plausible?

(08/12/93 Nagy: Even a floppy disk will do)
--------------------------------------------
If you don't have a spare disk to make a new system volume, there are two
other approaches depending upon the resources available to you. These were
initially used to change the cluster size on a system disk.
If your target system has a removeable disk (even a floppy on it), then you
INITIALIZE a floppy before shutting down. Use the parameters you want (except
/HEADERS=, can't put too many of them on a floppy). Then shutdown and use S/A
Backup to make a /IMAGE save of your system disk. Then use S/A to make a
/IMAGE copy of your floppy to the old system disk (hmm, might need to do
/IMAGE to tape then from tape to system disk?). Your system disk is now
initialized with prototype parameters, now restore the system disk save
/NOINIT and you should end up with a system disk with new volume parameters
(such as a new cluster size) and a (mostly) contiguous header file ready to
boot.
If the target system does not have a spare disk or floppy, you can INIT the
new disk on another system and make a /IMAGE save of it to tape. You then
restore this tape first then then 2nd tape with /NOINIT as above to get the
same effect.
This was used to change the cluster size on an RP07 attached to a 780 with
a tape drive and no other disks other than the console floppy. Yep, the
prototype volume was made by initializing a floppy under VMS and saving that
to tape.

(08/12/93 Stone: Why a minimum boot?)
--------------------------------------
>I figured that the min boot would be fairly safe, as the que manager would not
>be up, no users sould be logging in, etc. so the system disk would have very
>few "open for write" files.

Why do you want to do a minimum boot rather than use standalone backup?
If you use S/A Backup, the system disk will have no "open for write" files.
This is one of the things for which S/A Backup exists.

(08/13/93 Bochnik: Hamster Brain)
----------------------------------
I'm not sure what I was thinking at that time. Sure, SA Backup looks like
the way to go with this. My concern was with getting the INIT stuff correct.
Thanks.

December, 1993 The DECUServe Journal Page: 85

"I want to deflect a little of the thanks to
Rick Carter some highly-competent, mostly-invisible people
Quoted on 09/02/93 in whom I get to deal with in my job as Customer
DECUServe_Forum 373 Assistant. Even though they're paid :-), they do
a great job. Dolores Pilitz is the System
Administrator here, and I'd mention all of her
staff but I might forget someone. But I will
single out Doris Panos as doing what is needed
to keep things going here, and working to dig up
right one of us when users call the DECUS office
to get their accounts fixed up right. Also,
Rosemary Lupo who works on all those "I renewed
3 months ago but haven't heard anything" snags,
and who thinks beyond the single problem to find
systemic changes to make to ensure its not
cropping up again. Finally, Anne Foley who, like
Doris, gets calls in the DECUS office and works
hard to make the users happy." [Editor's note:
Rosemary Lupo has moved to a different position
with Digital since this quote was written, but
we still want to thank her for her hard work!]

DCLTABLES problem?
------------------

The following article is an extract of the DECUServe VMS
conference topic 2166. This discussion occurred between
September 29, 1993 and October 2, 1993.

By Michael Baydoun, John Burnet, John Gorentz, Dan Wing, Jamie Hanrahan,
Stuart Renes

(09/29/93 Baydoun)
------------------
I'm having a problem installing a compiler (VAXC032) on a VAXstation
4000/60, which is a boot node in a LAVC. I think the problem is somehow
related to the DCLTABLES file, but I'm jumping the gun a bit.
The license is loaded, always has been. The 'files' are in the proper
directories, always have been, vms help, etc. But the cc command is a invalid
verb, specifically:

%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\CC\

Now I can install the compiler again, which only takes about 1 minute with
everything there already, and then I can compile. But I can only compile in
the *context* of the *process* that installed the compiler. No other new or
existing processes work. Once I log out, I'm back to square one.
What am I missing?

December, 1993 The DECUServe Journal Page: 86

(09/29/93 Burnet: Look for renegade DCLTABLES.EXE files)
---------------------------------------------------------
If the installation procedure for the compiler didn't already do this,
you'll need to do it yourself:

$ mcr sysman
SYSMAN> set environment/cluster
SYSMAN> do install replace sys$share:dcltables
SYSMAN> exit

Then log out and log back in. If the CC verb is still unrecognized, then
look for DCLTABLES.EXE files in system-specific [SYSLIB] directories. If you
find any, figure out which one is the "real" one (most up-to-date), rename it
to SYS$COMMON:[SYSLIB] as the highest version, delete or rename all other
versions in SYS$SPECIFIC directories, then do the SYSMAN and INSTALL stuff
above.
If that doesn't fix it, then somehow the verb wasn't added to DCLTABLES
properly. Did you see any error messages during the VMSINSTAL indicating that
something went wrong?

(09/29/93 Burnet: Check GBLPAGES and GBLSECTIONS on all cluster nodes)
-----------------------------------------------------------------------
Oh, yeah... the most common cause of something like this is a GPTFULL error
("global page table is full") when trying to reinstall DCLTABLES. If that's
happening to you, you'll need to use Autogen to increase the values of
GBLPAGES and/or GBLSECTIONS, then reboot. It's a good idea to make the values
of those two parameters rather large, relative to your system's actual needs;
there is very little penalty for making them too big, and that can save you
some reboots if you later install layered products.

(09/29/93 Gorentz: Maybe none of the above)
--------------------------------------------
| If you find any, figure out which one is the "real" one (most up-to-date),

But the answer to which one is the "real" one could be "none of the above"
if this condition has somehow escaped detection for a long time, and past
installations done from one node updated the one in sys$specific, and past
installations done from another node updated the one in sys$common. You
wouldn't want to go home thinking you fixed the problem without realizing you
created another one. :-)
If you think there is any possibility of this, you could use the VERB
utility to examine and compare.

(09/29/93 Wing: careful)
-------------------------
This thread mentioned that it is possible that the replace of DCLTABLES can
fail, but also recommends replacing DCLTABLES and then logging out.
I'd encourage you to SET HOST 0 and log again to verify the new command is
present, and that DCLTABLES is working, instead of logging out -- if your

December, 1993 The DECUServe Journal Page: 87

DCLTABLES is hosed because it only got 1/2 installed, it could be a mess to fix.
I've never had it happen, and am not really sure that it could happen, but
I wouldn't trust INSTALL farther than I could throw it. You know Install, the
utility that won't let you de-install a file using a different path?

(09/29/93 Gorentz: Paranoia forever!)
--------------------------------------
I've had it happen, which is why I do exactly what you suggest. I think I
once did it right by accident, and discovered I had a screwed-up DCLTABLES.
Ever since, I've made a practice of SET HOST 0 (or the equivalent thereof on a
multi-session workstation) after any changes to DCLTABLES.

(09/29/93 Burnet: Oh yeah, I forgot to mention that slight difficulty... ;-))
------------------------------------------------------------------------------
> I'd encourage you to SET HOST 0 and log again to verify the new command is

Thanks for pointing this out. I have seen this happen too; the usual
situation is the insufficient-GBLPAGES problem that I mentioned. What happens
is that INSTALL deinstalls the existing known image, then tries to make the
new one known; if the latter operation fails, then you have no DCLTABLES
installed on that node. Bummer.

(09/30/93 Hanrahan: This hint brought to you by Pat O'Malley)
--------------------------------------------------------------
n.b.: Unless you are VERY short on memory, set GBLPAGES to its maximum
allowed value of 100000. Set GBLSECTIONS to its max of 4095 while you're at
it. Avoids LOTS of reboots.

(09/30/93 Coy: Gblpages?)
--------------------------
But - GBLPAGES does not have a maximum of 100000.

(09/30/93 Renes: Large as -1)
------------------------------
You can set it up to 999,999,999 I believe. (Not that you'd want to!)

(10/02/93 Hanrahan)
-------------------
Oops, you're right -- it used to. Anyway, the point is to set it to Huge
Number That You Won't Ever Need. The cost is low and the benefit in avoided
reboots is high.

December, 1993 The DECUServe Journal Page: 88

New VMS file system?
--------------------

The following article is an extract of the DECUServe VMS
conference topic 2175. This conversation occurred between
October 14, 1993 and November 9, 1993.

By John Osudar, Al Hunt, Jamie Hanrahan, Larry Kilgallen, Terry Kennedy,
Lee Gleason, Bob Forrest, Lyndon Bartels, Frank Nagy, Jean-Francois Mezei,
Petri Backstrom, Bret Wortman, Dave Mores, Brian Breton, John Gorentz

(10/14/93 Osudar)
-----------------
OK, I'm sure other VMS users have seen this in DEC's press releases from
earlier this week:

o New Future Engineering Directions

Within 18 months the OpenVMS operating system will dramatically
increase capacity with 64-bit files and databases, and a new file
system that can store 10 Terabytes of data on-line, update 10
Gigabytes/day, and recover one Terabyte in eight hours. These changes
will make OpenVMS servers ideal for such high-capacity applications as
very large databases, imaging, full motion video, multimedia, advanced
simulations, and virtual reality. The capabilities of the new file
system will be extended to allow SERVICESlar clients to access the
same file without cumbersome translators. Digital also plans to
extend its high availability and data integrity features to desktop
client/server applications.

So... what does this mean?

-- is Digital planning to replace the present file system with this
new one, or to support both file systems?

-- is Digital planning to support the new file system on VAX
systems, or only on AXP?

-- is this going to be an extra-cost add-on or part of base VMS?

-- is Digital asking existing VMS sites for input into the design
of the new file system? Is Digital interested in input from
people such as those of us here on DECUServe? Or is it too late
to change what they will implement (after all, 18 months before
availability may mean that not only is the design finalized, but
the code for V1.0 may be in field test already! :-)

I know that anyone closely involved with this is almost certainly bound to
keep quiet under non-disclosure rules, and that Digital probably won't want to
talk about it at this time. But something this critical to the operation (and

December, 1993 The DECUServe Journal Page: 89

the future viability) of VMS ought to undergo some public scrutiny before it
springs full-blown from the minds (or other body parts :-) of Digital.

(10/14/93 Hunt: Some tidbits)
------------------------------
It was discussed and presented by a VP of DEC at DECUS in Atlanta. No
real details given.
Rumor has it that it will look familar to VMS, UNIX, and PC people. Anyone
will be able to store their data on VMS and feel at home. The ultimate server
if you get my drift. I believe they are also trying to resolve performance
problems that the present system has. I also know that additional features
such as LAST READ DATE will start showing up around V6.1 (not necessarily in
it). They need these new features for products like File Shelving and Media
Management that are on the horizon in some cases.
As to how we will be impacted I have no idea.

(10/14/93 Hanrahan)
-------------------
> Within 18 months the OpenVMS operating system will dramatically
> increase capacity with 64-bit files and databases, and a new file
> system that can store 10 Terabytes of data on-line, update 10
> Gigabytes/day, and recover one Terabyte in eight hours.

At last - sufficient capacity and throughput to handle a full newsfeed! :-)

(10/14/93 Kilgallen: What's a SERVICESlar?)
--------------------------------------------
>system will be extended to allow SERVICESlar clients to access the

That must have been somebody at DEC doing an erroneous global replace,
right?

(10/14/93 Kilgallen: Last Read Date ? -- yuckko)
-------------------------------------------------
> know that additional features such as LAST READ DATE will start showing
> up around V6.1 (not necessarily in it). They need these new features
> for products like File Shelving and Media Management that are on the
> horizon in some cases.

Why can't they use the Expiration date provided by SET VOLUME/RETENTION?
It seems to have the ultimate in system manager control of overhead.
There do seem to be some new dates associated with CDROM support, but I
gather that is for support of ISO 9660.

(10/14/93 Osudar: this 'n' that)
---------------------------------
>> system will be extended to allow SERVICESlar clients to access the
>That must have been somebody at DEC doing an erroneous global replace, right?


December, 1993 The DECUServe Journal Page: 90

Right... now, who can figure out what the global replace was? :-)

> Rumor has it that it will look familar to VMS, UNIX, and PC people.

If that means cross-platform products won't have to do filename
translations, I'll be happy.
I notice that there's no real mention of hierarchical features in the brief
"announcement", though there have been rumblings about such things from various
sources within Digital.

> As to how we will be impacted I have no idea.

Now *that* is the real question...

(10/14/93 Kennedy: I'll believe that when I see it)
----------------------------------------------------
> At last - sufficient capacity and throughput to handle a full newsfeed! :-)

(10/16/93 Hunt: Reliable LAST READ date)
-----------------------------------------
Problem with the expiration date is that commands like SET PROTECTION
update the date so it is not reliable. We used to have problems (may still)
with people who put the commands similar to:

$ SET PROTECTION=(S:REWD,O:REWD,G:RE,W) [...]*.*;*

in their LOGIN.COM. Needless to say this plays havoc with incremental backups.
There can be other issues as well.

(10/17/93 Kilgallen: It's always _something_)
----------------------------------------------
But if that point problem is solved, you could get the same effect with a
user who read the file characteristics from every file, or did a global search
for the string "password" or took some other action which happened to trigger
the date processing action.

(10/18/93 Gleason)
------------------
Here, the biggest problem was the use of SEARCH...a wide ranging search
command could cause no archiving (we archive by the EXP date) of a disk for
months. We fixed this problem by patching SEARCH to not update the expiration
date, by use of the xab$_norecord feature. That solved most of the problem here.

(11/03/93 Osudar: a list)
--------------------------
Back to the original topic -- the new file system for VMS... Let's talk
about what we want to see (and what we *don't* want to see) in a new VMS file
system.

December, 1993 The DECUServe Journal Page: 91

I spent a few minutes thinking about problems, limitations, and missing
features of ODS-2, and came up with my own first crack at a list:

(1) A file naming system that provides a consistent, unique mapping for
filenames from other systems (WNT, Unix, Mac, MS-DOS & its successors)

(2) Provisions for transparent implementation of a hierarchical storage
system (e.g. indication that the file has migrated to another storage
medium, with information required to locate the file there) although
the hierarchical system *could* be a separate product, the underlying
file system has to provide the required capabilities.

(3) The ability to leave unallocated gaps between allocated blocks
within a file

(4) Provisions for automatic encrypt-on-write/decrypt-on-read, file-level
password protection, and possibly automatic data compression

Then there are these, not really part of the file system, but VMS issues
related to it:

(1) The ability to handle directories nested to any depth

(2) A sequential file record structure that enables efficient "backward"
operations (e.g. reading a file from EOF backward, or "backspacing" to
the Nth previous record (Even something simple, like storing the XOR
of the next and previous record lengths, would do.) Along the same
lines, 32-bit (or 64-bit?) record lengths would be a nice improvement.

As for things *not* to do:

Please *don't* discard the concept of record structure! I don't want all
my files to be "stream" files.
More later...

(11/03/93 Forrest: new file system - hierarchical storage, global file space)
------------------------------------------------------------------------------
> (2) Provisions for transparent implementation of a hierarchical storage
> system (e.g. indication that the file has migrated to another
> storage medium, with information required to locate the file there)
> Although the hierarchical system *could* be a separate product, the
> underlying file system has to provide the required capabilities.
>

But with the constraint that global 'diskquotas' could be enabled and
tracked in some way between that disk volume set and the tapes used in
automatically migrating the customer's data from that disk volume set to tape.
I wouldn't want to have to deal with an explosion of tapes because the
customer's data kept being migrated to tape, but the diskquota on that disk
volume set remained the same, so that the customer could continually put more

December, 1993 The DECUServe Journal Page: 92

and more data for us to have to deal with (understand that we have limited
resources [$, room space, ...] in which to support our customer base, and
diskquotas is one of the tools we use to help manage our resources).
I'm sure for some sites, they would want diskquotas on the disk volume sets
but not on the tapes. It would be nice to have the capabilities of doing both
types of filespace quota trackings.

(11/03/93 Bartels: Amount of used space accupied by modified files.)
---------------------------------------------------------------------
I would like to be able to see how much of the used space on a disk is
being occupied by files wihout any backup date recorded. Meaning, modified
files. Then I can judge how long and how much tape space incremental backups
are going to take.

(11/03/93 Nagy: New file system - not a new record mgt system!)
----------------------------------------------------------------
Keep in mind that this is a new file system and as a replacement for ODS-2,
issues of record types and other internal structure to the file are not
considerations (though they would be for a new RMS). The file system treats
the files as bags of bytes (well, actually piles of disk blocks) and provides
for the organization of these bags (allocation of disk space, naming, directory
services). Even ODS-2 works this way; some bytes are provided in the file
header for the use of RMS (which is where the file organization, record type,
record attributes, etc. are stored). If you talk directly to the ACP all you
get a blocks of disk.

(11/03/93 Mezei: More suggestions)
-----------------------------------
Suggestions:

1- The FILE utility that can change a file's structure without changing the
actual contents. Although this is now a DECUS program, a complete "FILE"
should come with the new file system.

2- Intelligent access to indexed files from platforms who do not know about
such files. (a bit like TYPING a DDIF file from a VT terminal). In other
words, don't block access , just provide the sequential operations.
(Or something more powerful).

3- Proper management of MAcIntosh files. (eg: being able to set the file's
owner and application fields, being able to extract /separate the data
from resource forks and recombine them later. (Again: intelligent
access to these files from non-MAC platforms). Having a MAC save a
PAGEMAKER file on the VAX to be picked up by a PC for instance.
(eg: the PC would only see the data portion and wouldn't know about the
resource fork). Of course, a well documented rule as to what happens
when that PC saves the file. Does it get saved in the file original

December, 1993 The DECUServe Journal Page: 93

format (MAC, with only the data being updated, resource and file
type/owner stay the same), or does the PC overwrite the file completely
and it becomes a "PC" file?

4- Talk the the messaging folks to make sure that files can be transported
through Message Router/Mailbus 400 with the receiving end being able to
know what sort fo files they are.

5- A CONVERT qualifier that can convert text files from one format to
another based on CONTENTS (eg: check for line delimiters such as LF or
CRLF and then convert the file accordingly). This would come in very
handy when receiving files that aren't quite readable on a VAX.

6- Having the possibility to store the username of the last user who wrote
to the file.

Of course, there will have to be some debate on whether the file system
will hide physical disks from the users (eg: one master catalog), or whether
disks will remain part of the file names that users will see. Of course, today,
you could always use stripe-sets to acheive disk transparence. But if one
disk fails in that stripe-set, you are sort-of cooked and fried.

(11/03/93 Backstrom: fwiw)
---------------------------
>1- the FILE utility that can change a file's structure without changing
> the actual contents. Although this is now a DECUS program, a
> complete "FILE" should come with the new file system.

$ HELP SET FILE /ATTRIBUTE ! on VMS 6.0

(11/03/93 Osudar: file sys vs. RMS)
------------------------------------
>New file system - not a new record mgt system!

Yes, quite true, and a point well taken. (I tried to keep the file system
issues apart from the other things that Digital might decide to address at the
same time, such as record structure -- or lack of same.)

(11/03/93 Wortman: Check out LINKWORKS)
----------------------------------------
> 3- prpper management of MAcIntosh files. (eg: being able to set
> the file's owner and application fields, being able to extract

This sounds like LINKWORKS. Did you see the product announcement recently?
Granted, it's an add-on product, but is purported to handle exactly these
kinds of issues.

December, 1993 The DECUServe Journal Page: 94

(11/03/93 Hanrahan)
-------------------
No, it really doesn't sound like LinkWorks at all.... and it isn't an
add-on, it's part of DECwindows Motif. (See the Link menu in many Motif
applications.)
Pathworks, maybe?

(11/03/93 Kilgallen: Linkworks naming moved to Business Practices 366)
-----------------------------------------------------------------------
I have started a new topic to take this discussion. It is topic 366 in the
Business Practices conference (you'll see why). The SELECT command issued
right now will add the Business Practices conference to the notebook.

(11/04/93 Mores: Does it do soft links?)
-----------------------------------------
Does it do links, soft links like Unix file system?

(11/04/93 Kilgallen)
--------------------
I think you will have to define your interpretation of "like" for us to
discuss this. What aspects of VMS alias entries do you dislike (either the
current or former implementation :-).

(11/05/93 Mores: my likes)
---------------------------
Soft links ala Unix make a textual reference to another file (data or
directory) - i.e. reading the file would require two lookups, one on the file
that is the link and another on the reference therein, etc.
I am farmiliar with the former (old) VMS concept of the file alias entry,
but do not know what the current implementation did to improve or change that.
Anyway, soft links would never cause BACKUP to backup files multiple times.
A soft link file is a unique file in the file system.
Soft links can be used to as a convenience to make a scattered set of files
accessibly in one directory or may be used as a configuration management tool
to control what version of an application gets used by switching link files to
point to the appropriate directory. Yes, there are ways to do these things in
VMS without link files, but this is just another feature that I think would be
useful in a new, robust file system.

(11/05/93 Kilgallen: I don't think we should make implementation presumptions)
-------------------------------------------------------------------------------
So the real expression of need, then, is "no duplicate copies caused by
backing up a disk which has multiple ways to reach the same file".
Any discussion of Soft links or Aliases makes implementation presumptions
which may not be valid. Considering that DEC has gotten as far as adding
Protected Subsystems to ODS-2, anything requiring a _whole_new_filesystem_ must

December, 1993 The DECUServe Journal Page: 95

really be quite different, and describing things in terms of ODS-2 or Unix
implementation techniques may not be at all meaningful.

(11/06/93 Mezei: Personal comments)
------------------------------------
I am a bit saddened that Digital won't take part in these discussions. DEC
would have here the perfect opportunity to prove that it is customer driver and
really listens to customer needs during product development.
Of course, everything at Digiotal is still under non-disclosure seals, so
having customers participate is still impossible. It is a shame. I can
understand DEC wanting to keep DEC UNIX under wraps because there is direct
competition from SUN HP etc. But nobody competes against VMS so discussing VMS
futures won't hurt.

(11/08/93 Breton)
-----------------
If you guys ( and gals ) can keep to the topic and come up with some type
of report or wish list I would be more than happy to send it to the right folks.
I won't however send them a mish-mash of notes.
OK so who's up for writing the New OpenVMS File System Customer White Paper?

(11/08/93 Wortman: And we know DECUServers can't turn down a challenge....)
----------------------------------------------------------------------------
I sense a challenge here. ;-)

(11/08/93 Gorentz: Be greedier)
--------------------------------
I don't quite understand this. Those customers who are trying to influence
Digital's direction will of course be more effective if they organize their
ideas. But I would hope the "right folks" would be greedy for as much customer
input as they could get, even if it's a mish-mash of notes. I can understand
why they would not want to wade through tons of unrelated information, but
that's hardly the case here, is it?

(11/09/93 Bartels: But ...)
----------------------------
One could argue that a file system is the root of all evil. ;-)
Or for those who would rather "do unix" "/" of all evil. (pun not
originally intended, but not bad once I caught it!)

December, 1993 The DECUServe Journal Page: 96

File system questions
---------------------

This article is an extract of the DECUServe Windows_NT
conference topic 16. This conversation occurred between
May 16, 1993 and May 25, 1993.

By Jean-Francois Mezei, Petri Backstrom, Jamie Hanrahan, Bob Hassinger,
Mike DePriest, Bill Mayhew, Joe Crum, Bill Wood, Linwood Ferguson,
Larry Kilgallen, Mike Mulligan, John Featherly

(05/16/93 Mezei)
----------------
What sort of file organisations does NT support natively?
Is it like UNIX with only flat files that consist solely of allocated
blocks of disk space, or does NT have some sort of standard file organisations?
Does NT have the equivalent to VMS's indexed files?
If not, how is it suggested to migrate VMS applications to NT when they use
indexed files?
Are the only alternatives to read the whole file in memory or to use a full
fledged database system?

(05/16/93 Backstrom)
--------------------
They're stream files (FAT, HPFS and NTFS file systems).
Indexed access is up to the application (but, of course, does not have to
be a worry of the actual application developer as [s]he can use libraries like
Informix C-ISAM or full-fledged database systems like Oracle, etc.).

(05/16/93 Mezei: Sad to see NT lacking standard file structures)
-----------------------------------------------------------------
Ok, flat files. No standard indexed files. So, an indexed file created by
one application with one package cannot be read by another application unless
it has the same index-file-package.
I see this as a minus for an operating system.
I know that a lot of people complain about RMS and structured files, but
they do have the advantage of being standard on a platform wherever you go.
I guess Oracle will be making more money on NT since everyone will need it
because simple applications won't be able to use indexed files on NT.
I can just imagine the debates between Dave Cutler and the Microsoft people
who are used to DOS files :-) :-)

(05/17/93 Hanrahan)
-------------------
> I see this as a minus for an operating system.

I'm not so certain. There is a lot of work that is done on RMS indexed
files simply because RMS comes free with VMS -- work which would be much better

December, 1993 The DECUServe Journal Page: 97

done with a data base. Lately I've been tempted to say that any indexed file
that needs more than one key field should be moved to a data base instead.

(05/17/93 Hassinger: A good thought, but... )
----------------------------------------------
As long as data base systems cost as much as they typically do now (in
dollars, resources, and management), I suspect that while this may be valid
technically it seems unrealistic.
Further, how practical is it to expect the user of a personal system to
install multiple data base systems to support the various applications they
want to use (which happen to be layered on different data base systems)?
I have to say for small to moderate sized applications I have always felt
the availability of RMS has been a great strength of VMS. It provides an
excellent level of standardized functionality on all VMS systems, which allows
a great deal of in house and third party software that will run very well on
all VMS systems.

(05/17/93 Hanrahan)
-------------------
You can get a set of C library routines that provide a complete API for
XBase (== dBase without a trademarked name) for around $200. Source included.
Permission to build into executables of products you build and distribute is
also included.

> Further, how practical is it to expect the user of a personal system to
>install multiple data base systems to support the various applications they
>want to use (which happen to be layered on different data base systems)?

Bob, are you COMPLETELY unaware of how things are sold in the PC
"shrinkwrap" world? The code to access the various data bases COMES WITH the
applications in question.
BTW, you may have noticed that Digital is turning away from indexed files
too. The databases underlying many parts of DECset, for example, run on RDB...

(05/18/93 DePriest: What Jamie said...;-) )
--------------------------------------------
>You can get a set of C library routines that provide a complete API for XBase

Any more, any list-intensive PC programs come with this type of XBASE
support, so I consider the .DBF (XBASE) file to be the common ISAM format for
PC.
Microsoft Access will attach and use XBASE files as relational tables.
I think that the fact that NT doesn't include a native ISAM structure in its
supported file systems is a benefit - now there's incentive for third-party
developers to build high-performance add-ons.

December, 1993 The DECUServe Journal Page: 98

(05/18/93 Mayhew: I'll bite... )
---------------------------------
>You can get a set of C library routines that provide a complete API for XBase
>(== dBase without a trademarked name) for around $200. Source included.

Where?

(05/18/93 Hassinger)
--------------------
>Bob, are you COMPLETELY unaware of how things are sold in the PC "shrinkwrap"

Can't say about the PC world, but I have noticed that the products my
company uses in the Mac world tend to be proprietary. For example, 4D is the
database of choice. There are a limited number of externals to link with
certain other software, but I do not see anything like open cross-application
access to 4D data bases.
I guess I am old fashioned. Sometimes the shrinkwrap applications don't
seem to do quite what is required and I still seem to need to be able to write
pieces myself. So an open, supported ISAM or database that I can use from my
programming tools of choice still seems desirable.
On VMS I can even do a passable level of access to ISAM files from DCL code.
I have not found that sort of openness in the Mac world at all.
As I poke around in the Mac world I feel like I am back to the time before
VAX/VMS when we had many incompatible filing schemes and software development
tools. Perhaps the PC world is better than Mac, but I have not seen an
indication of that yet.

>btw, you may have noticed that Digital is turning away from indexed files too.
>The databases underlying many parts of DECset, for example, run on RDB...

How is DEC going to offer Rdb for WNT? What form will it take? How
accessible will it be for my home grown application? How much management will
it require? What will it cost?

(05/18/93 Hanrahan)
-------------------
> to write pieces myself. So an open, supported ISAM or database that I
>can use from my programming tools of choice still seems desirable.

The catch here is that with most of these products an indexed file -- which
is just a flat file with some key fields defined -- would be woefully inadequate
to the task. Look at VAX NOTES for example: Sure, it uses indexed files, but
the fact that VMS comes with an API for indexed files only gives you part -- a
small part -- of what you need to write programs that interact with a NOTES
conference file.
The "larger picture" answer is that we should simply stop buying software
that doesn't have an API available -- or at least a flat file export/import
facility. I've railed about this in many other threads. Unfortunately I don't
see this as a trend that's likely to get started anytime soon.

December, 1993 The DECUServe Journal Page: 99

On the other hand, Microsoft's OLE provides a lot of what is needed here.
If I can link a number in a report written via a word processor to a cell in a
spreadsheet, surely I can write other apps that, like Word Perfect, can grab
stuff out of the spreadsheet.

(05/18/93 Hanrahan: xBase API packages, C source included)
-----------------------------------------------------------
>>You can get a set of C library routines that provide a complete API for XBase
> Where?

The "Programmer's Connection" catalog (800-336-1166) lists two: Greeleaf
Software's dbLib, $185, and Sequiter Software's CodeBase 5, $259.
Or of course if you're working on a PC in the first place you can simply
use Clipper and call out to C (or other HLL routines) as needed.

(05/18/93 Hanrahan: xBase API packages, C source included)
-----------------------------------------------------------
Also see topic 389 in PERSONAL_COMPUTING.

(05/20/93 Crum: ISAM is fine, thank you!)
------------------------------------------
I have used both ISAM files and Oracle for a long time, and I prefer ISAM
to having a large black box database. One reason is that I develop software
that has to run 24 hr/day, 365 days/yr, and there is no database in existence
that I know of that has the kind of availability you can get with ISAM files.
Performance has not been an issue for me, and I have never had to manually
shut down RMS to extend a tablespace. I've heard all the arguments for a
database system, but I have yet to be convinced that's the way to go. I guess
I'm old-fashioned too, but as an experienced Oracle developer and DBA, I'm not
entirely ignorant of the subject. Anyone who's gone through a standard Oracle
upgrade (an oxymoron) knows the pressure of "what if it doesn't come up?". I
don't say this to belittle Oracle, as I'm sure the same is true of most
database systems. Although I have been know to knock it occasionally. :^}

(05/20/93 Wood: ELN had no indexed files either.)
--------------------------------------------------
> I can just imagine the debates between Dave Cutler and the Microsoft
>people who are used to DOS files :-) :-)

Don't assume Cutler supported an RMS approach. VAX-ELN is a Real Time
operating system written by Cutler's left coast team at DIGITAL several years.
It shipped without an Indexed file system. A relational DBMS was an add on
product to support structured data storage. Somehow a DBMS on a Real Time
machine seemed incongruous, but it worked.

December, 1993 The DECUServe Journal Page: 100

(05/20/93 Hanrahan: Maybe a later version will have it...)
-----------------------------------------------------------
The function of indexed files isn't a big problem imho, since they can be
supported via add-on packages.
I think that the absence of anything like VMS's lock manager is a much
bigger problem. Without that you don't have the tools to build an indexed file
system (or a DBMS) that cleanly supports network access. Granted you can write
one, but this sort of functionality really belongs in the kernel. IMHO.

(05/21/93 Wood: Rdb *needs* a lock manager.)
---------------------------------------------
Any idea why this is not part of WNT? It seems too obvious to miss. Since
Rdb is porting to WNT I would assume that there will be at least a partial port
of the VMS lock manager to go with it. Maybe Microsoft can buy this from
DIGITAL.

05/21/93 Ferguson: Bet the Rdb folks could do it better with their experience)
-------------------------------------------------------------------------------
Digital? Certainly much of its sophistication and, well, exercising did.
I wonder if the Rdb folks just decided to do their own for NT.

(05/21/93 Hanrahan)
-------------------
>Didn't the need for a lock manager grow up out of DMBS or Rdb within Digital?

No, it came out of the need for cluster-wide synch techniques when dealing
with disk volumes that are mountable and writable across the cluster. But, yes,
the DB groups contributed a lot of "required features".
Obviously you can run a lock management function almost anywhere. But there
are lots of advantages to doing it in the kernel.

(05/21/93 Hanrahan)
-------------------
> Any idea why this is not part of WNT? It seems too obvious to miss.

Simple - time-to-market. I expect that a future release of NT will have it.

(05/21/93 Kilgallen: Overall, I'm not impressed)
-------------------------------------------------
> Any idea why this is not part of WNT? It seems too obvious to miss.

It was not included in VMS at the time Mr. Cutler left that part of DEC !!!
That doesn't excuse the indexed file gaffe, and I strongly believe that such
a basic tool should be provided by the operating system vendor. I say this
from the viewpoint of someone building software which runs on customer's
machines. I strongly doubt any $ 200 "right-to-distribute" license would give
a product of the quality of VMS RMS.

December, 1993 The DECUServe Journal Page: 101

Careful reading between the lines shows that Microsoft is also playing
light-and-loose with Posix accreditation, doing enough to meet the letter of
the law without providing anything useful in the context of their operating
system.

(05/21/93 Crum: They'll sell more $oftware...)
-----------------------------------------------
>I strongly doubt any $ 200 "right-to-distribute" license would give a product
>of the quality of VMS RMS.

It seems to me that the basic idea is to create a new large software market
for Microsoft (and others) by leaving out things we need, like a decent file
system. So we all have to go out and buy a database system, a lock manager,
and lots of other good stuff, and maintain the licenses and upgrades for all
of those products, as well as fight the version incompatibility problems.

(05/21/93 Mulligan: WNT Object Manager does locks)
---------------------------------------------------
>> I think that the absence of anything like VMS's lock manager is a
>> much bigger problem. Without that you don't have the tools to build

IANAWNTD (I am not a Windows NT developer) but a reading of the Custer book
tells about the object manager and how it supports mutexes (mutexi?) and
semaphores and events. That should be enough. I'm not sure you really NEED to
have all the fancy 6-levels-of-locks that the VMS lock manager offers.
Perhaps a more insidious problem is that the prefered Win-32 api doesn't
directly let you at the kernel object services (correct me if I've guessed
wrong). So it is in the kernel ("where it belongs") but you can't get at it!

(05/22/93 DePriest: More like 'spreading the wealth')
------------------------------------------------------
...and probably at a _fraction_ of what it's costing you to have Digital
include all that stuff in VMS.
Let's not forget where Microsoft's origins are, and who their current
customer base is. They're producing a follow on operating system to a portion
of a 50 million-strong installed base of $49.00 DOS and $99.00 Windows 3.1,

>> I strongly doubt any $ 200 "right-to-distribute" license would give
>> a product of the quality of VMS RMS.

I have a lot more faith in the performance and trial-by-fire reliability of
CA (Nantucket), Borland, and dozens of other independent library developers
than a single, potentially myopic system software group. ISAM isn't rocket
science anymore ;-). At only $200 a pop, you better have a rock-solid product
that generates a hot reputation, or you're not going to make any money in the
PC software business. Nobody - repeat - nobody is going to pay the $$$K that
Digital and IBM command for 'software support' and 'maintenance' in the NT or
PC worlds. (That 'free' RMS is starting to look a lot more expensive.)


December, 1993 The DECUServe Journal Page: 102

>So we all have to go out and buy a database system, a lock manager, and lots
>of other good stuff, and maintain the licenses and upgrades for all of those
>products, as well as fight the version incompatibility problems.

Gee, you make it sound like you've never had these problems with a monolithic
software vendor like IBM or Digital...;-)
I tend to look at this glass as half full - we don't have marginal products
from the OS vendor in these niches, so there's incentive for ISV's to build
killer versions.
Deal with version incompatibilities the same way you do now - wait and think
about it before you upgrade. If it's a big problem, scream loudly. If the
vendors in question don't respond, take your business elsewhere.

(05/24/93 Crum: WNT = VMS + 111?)
----------------------------------
> ISAM isn't rocket science anymore

I'm not after rocket science. I have a job to do, and VMS does it very
well.

>Nobody - repeat - nobody is going to pay the $$$K that Digital and IBM command
>for 'software support' and 'maintenance' in the NT or PC worlds

True, if NT is considered a replacement or follow-on for a single-user PC
environment. But it's being passed off as a follow-on for VMS, which is quite
a different ball game, and I am sure that Microsoft is aware that VMS users
are used to spending lots of money to get the functionality of VMS. So, do
you really think we're going to get a better operating system than VMS for the
price of mail-order shrink-wrapped software? Maybe. Probably not. :-}

(05/24/93 DePriest: Tempest in a teapot?)
------------------------------------------
I guess it depends on your perspective: I don't consider NT to be a follow
on OS for VMS, but for DOS, OS/2, and network OS's like Netware.
I also don't think that the initial releases of NT are going to be 'better'
than VMS for a lot of things - including, obviously, free built-in ISAM.
I DO think that early NT releases are going to smoke OS/2 and other server
systems for DOS networks, and if there are VMS-class applications that run in
the NT native environment (Rdb for NT, for instance, or Oracle, or whatever)
then I expect them to outperform their counterparts ON DOS OR OS/2.
Am I willing to bet the corporation on release 1 of NT as a replacement for
VMS 5.5-2? Heck no. But then again, that implies I already have the VAX and the
legacy application and data.
IMHO, you're going to see people doing new departmental client-server
systems with NT-based server software first. After there's a good solid track
record, THEN you'll see a lot of downsizing and porting. And when you port,
and move to client-server from monolithic apps, I think the absence of ISAM in
the OS will not be a big deal.
Then again, what do I know? 8-)

December, 1993 The DECUServe Journal Page: 103

(05/25/93 Featherly: distributed relational db)
------------------------------------------------
At a presentation yesterday, I saw a claim that "SQL Server" had support
for distributed databases - two phase commit. If true, I think that type of
technology will be as useful and probably in more demand than distributed
locking on ISAM files. Not to say that the latter would still be nice to
have...
"SQL Server" btw, is a MS port of Sybase to NT (so they said), was first
ported to OS/2.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
And now a public note of thanks to all the volunteers who make
DECUServe the best it can be:

DECUServe Executive Committee

Chris Simon - Chair
Pierre Hahn - Former Chair
Dale Coy - Manager of System
Don Roberts - Manager of Moderators
Sharon Johnson - Spokesperson
Rick Carter - Customer Assistant
Jane Furze - Member at Large
Mike Durkin - Member at Large
Rob Brown - Foreign Chapter (Canada) Representative
Bruce Bowler - Manager of Conferences

DECUServe Special Projects

Steve Arnold - Internet Operations Manager
Tom O'Keefe - Internet Operations Manager
Alan Bruns - News Manager
Charles Smith - News Manager
Terry Kennedy - Kermit Support
Rick Stacks - Volunteer Documentation Coordinator
Larry Stone - Updating the DECUServe User Guide
Bob Tinkelman - Internet Postmaster for eisner.decus.org and decus.org
Don Vickers - Technical Support for Account Expiration Notification
Jorma Tapola - Gatekeeper Manager
Sharon Frey - DECUServe Journal Editor

DECUServe Conference Moderators

Rick Bowen - Business_Practices
Bill Mayhew - Business_Practices, SIG_3rd_Party_Forum, SIG_BP_Forum
Curt Snyder - DECUServe_Forum, Hobbies_And_Interests, Shop_Talk,
Artificial_Intelligence, Windows_NT
J.M. Ivler - DECUServe_Forum, SIG_LT_Forum
Gary Rice - DEC_Networking, Algorithms, Factory_Automation,
Personal_Computing, Telecommunications
Bob Tinkelman - DEC_Networking, Algorithms, Factory_Automation,
Telecommunications

December, 1993 The DECUServe Journal Page: 104

Jamie Hanrahan - Hardware_Help, VMS, SIG_VMS_Systems_Forum, Swap_Meet,
Windows_NT
Bob Hassinger - Hobbies_And_Interests, Shop_Talk, DECUS_Library,
Latest_Release_Information, Local_Happenings,
Stan Barndt - Industry_News, 1ST_Aide, Conference_Of_Conferences,
Electronic_Law, New_Conference_Ideas, Security,
Site_Management, Standards
Eric Husby - Industry_News, Workstations, Artificial_Intelligence,
Electronic_Law, Local_Happenings, Security,
Software_Development, Unix_OS, User_Interfaces-Windows
Arnold DeLarisch- VMS
Jonathan Prigot - VMS
Frank Nagy - Workstations, 4GLS_And_Query_Tools, CIP_Forum,
Conference_Of_Conferences, Databases, New_Conference_Ideas,
Standards, Unix_OS, User_Interfaces-Windows
Don Amby - 1ST_Aide, Internetworking, Other_Software_Help, PDP-11,
Public_Domain_Software, Software_Development
Harrison Spain - 3RD_Party_VMS_Software, DEC_Software, VAX_Notes_Utility
Dale Coy - All_In_1, Document_Processing, Office_Automation
Chris Simon - All_In_1, Document_Processing, Office_Automation
Bill Wood - Hardware_Help, Latest_Release_Information, SIG_DMS_Forum,
Swap_Meet
Bob McDougall - 3RD_Party_VMS_Software, DEC_Software, VAX_Notes_Utility
Jim Gerland - CIP_Forum
Pierre Hahn - CIP_Forum, Employment
Don Roberts - CIP_Forum, Internetworking, Windows_NT
Sharon Johnson - DECUServe_Information, Employment
Bart Lederman - DECUS_Library, Pathworks
Linwood Ferguson- Employment
Mike Durkin - Other_Software_Help, Pathworks, PDP-11, Public_Domain_Software,
SIG_LT_Forum
Tony Ioele - SIG_AIM_Forum
Don Borsay - SIG_CHI_Forum
Rick Carter - SIG_NET_Forum
Bret Wortman - SIG_SITE_Forum
Rich DeJordy - SIG_VMS_Systems_Forum
Bruce Bowler - Society_Info
Mary McCormick - SIG_Site_Forum, Symposia_Public
Tom Kelley - Symposia_Public
Laurie Maytrott - Talk_To_The_LUGS
Michael Buck - Who_Am_I, Society_Info
Dana Schwartz - Who_Am_I, 4GLS_And_Query_Tools, Databases, Personal_Computing
David Gudewicz - Pathworks
Bill Tabor - SIG_3RD_Party_Forum
Tom Byrne - SIG_AIM_Forum
Lynn Pilachowski- SIG_CHI_Forum
Tim Mueller - SIG_DMS_Forum
Jack Crowell - SIG_DAARC_Forum
Tony Carrato - SIG_UNISIG_Forum
Jim Heringer - Talk_To_The_Lugs


December, 1993 The DECUServe Journal Page: 105

Technical Information
=====================

DECUServe Journal Publication Information
-----------------------------------------
Topic threads in the DECUServe VAXNotes conferences are selected for
publication on the basis of strong technical content and/or interest to a wide
audience. They are submitted to the editor by a team of Contributing Editors
who are DECUServe Moderators, Executive Committee members and other volunteers.
Articles in the DECUServe Journal are downloaded to a 286 PC and formatted
using a standard text editor.
The Journal is distributed monthly, close to the first of each month. There
are several methods of accessing it.

* Internet Newsgroups: vmsnet.decus.journal, comp.org.decus

* Email mailing list: decuserve-journal
To subscribe, send email to "mail...@decus.org". The body of the
message should say only "subscribe decuserve-journal". You will
receive an automatic acknowledgement by return email.

* Anonymous FTP from ftp.spc.edu in the subdirectory
[.usenet.vmsnet-decus-journal].

* Monthly posting in CompuServe's VAX FORUM.

* The Journal is also offered as part of several foreign DECUS
Chapter Membership packages!

* And it is archived permanently on DECUServe. Contact me with any
questions or problems with accessing the Journal.

Editorial Content Disclaimer
----------------------------
Opinions and information presented here belong to each individual author.
No inferences should be made that the authors are expressing the policies of
their employers unless specifically stated. Content has been deemed acceptable
by the Moderators of DECUServe according to the DECUServe Canons of Conduct.

How can I use DECUServe?
------------------------
DECUServe is available 24 hours a day, 7 days a week, except for the last
Thursday of each month at 5pm Eastern time for backups. Membership is by
individual subscription only, and subscriptions are sold on a yearly basis
currently for $75.00. Subscription forms are always included in DECUS New
Member packets and Symposia registration packets. Six-month subscription
forms are often distributed at symposia as well.
Foreign DECUS chapter members are invited to subscribe as well, although
they must do so through their chapter office. Forms and price details can be
obtained from the chapter office.

December, 1993 The DECUServe Journal Page: 106

Also subscription forms can be downloaded directly from DECUServe by dialing
1-800-521-8950 with the username INFORMATION. Set your modem to 2400 or 9600,
1 stop bit, 8 bits, no parity. DECUServe can also be accessed through the
Internet using TELNET!

What does DECUServe offer?
--------------------------
* A large conferencing system using VAXnotes. Currently there are over
32 active technical conferences that cover a range of topics from
hardware issues to software issues to "shop talk" and business issues.
There are over 80 conferences available in all, counting many read-only
conferences from foreign DECUS chapters, general DECUS (Symposia, LUG,
and SIG) conferences, and a few social conferences.

* A growing Internet newsfeed with a variety of newsreaders.

* Internet Email, which means that a subscription to DECUServe gives
you, automatically, an Internet Email address.

* Gopher, FTP, Telnet.

* Online access to the DECUS Software Library Index.

* Quick access to DECUS leaders via Email and conferencing. (Several
conferences are shared with the DECUS Leadership BBS.)

* Quick access to many DEC product managers and engineers, 3rd party
software people, and fellow DECUS gurus. The cream o' the crop!

* Virtually no downtime. Unlimited access times, and unlimited access to
the above listed benefits.


December, 1993 The DECUServe Journal Page: 107

--------------------------- cut here -----------------------------------------
APPLICATION FOR DECUS MEMBERSHIP

Complete and mail this form to: Digital Equipment Computer Users Society
Membership Group
SHR3-1/T25
334 South Street
Shrewsbury, MA. 01545-4195
Phone: (800)332-8755

DECUS U.S. Chapter Application For Membership

IMPORTANT! Please provide a complete mailing address including zip code in
accordance with postal regulations for your locality.

___New Membership ___Update to Current Membership Profile

Current DECUS Membership Number_______________________________

Please print clearly or type
Name________________________________________________________________
Company_____________________________________________________________
Address_____________________________________________________________
____________________________________________________________________
____________________________________________________________________
City________________________________________________________________
Phone: Business(___)_________________ Home (___)__________________
Address type Home___ Company___

Are you an employee of Digital Equipment Corporation? ___Yes ___No

Do you belong to a Local Users Group (LUG)? ___Yes ___No

Do you wish to be included in mailings conducted by Digital (for marketing
purposes etc.)? ___Yes ___No

Citizen of the United States? ___Yes ___No

If no: Country______________________________________________________

1. How did you learn about DECUS? (check applicable item)

1__Another DECUS Member 9__Seminar
13__Local Users Group 4__Digital Sales
5__Hardware Pkg. 2__Symposia
8__DECUS Chapter Office 14__Special Interest Group
12__Advertising 6__Software Pkg.
7__Software Dispatch 10__Electronic Store
(Digital Newsletter) 3__Regional Conference

2. Primary business activity at your location: (check one)

Non-Computer Related 42__Trade (wholesale, retail)
31__Manufacturing (other) 43__Research & Development
32__Agriculture, Construction 44__Leisure
33__Energy, Mining, Oil 45__Media
34__Engineering, Architecture 46__Other_____________________
47__Travel, Transportation
35__Utilities Computer of DP Related
36__Government - Local, State 25__Manufacturing (DP Equip.)
37__Government - Non-Military 26__Software Development
38__Government - Military 27__Communications & Networking
41__Education 28__Systems House, VAR/OEM
40__Medical or Legal Services 29__Consultant
39__Finance, Banking, Insurance 30__Other DP Services

3.I wish to participate in the following DECUS U.S. Chapter Special
Interest Group(s):

3__Artificial Intelligence 15__Networks
37__Business Practices 36__Personal Computing Systems
6__Data Management Systems 18__RSTS
5__Fourth Generation Languages 38__Security
8__Education 21__UNIX
9__Electronic Publishing 39__User Interface
10__Graphic Applications 26__VAX Systems
11__Technology, Hardware & Engineering 32__Site, Mgmt & Training
16__Language and Tools 20__Third-Party Providers
14__Mumps
31__DAARC (Data Acquisition, Analysis, Realtime and CIM)
1__Business & Office Applications, Integration, & Mgmt.

4. Using the classification numbers from question 3, please indicate
which SIG would be the primary focus for your interest?
#_____________

5. Using the classification numbers from question 3, please indicate
which SIG would be of secondary focus for your interests?
#_____________

6. Total employees in entire company/institution/government
department: (check one)

2__ 10,000 or More 6__ 250 to 499
3__ 5,000 to 9,999 7__ 100 to 249
4__ 1,000 to 4,999 8__ 6 to 99
5__ 500 to 999 9__ Fewer than 6

7. My Principal job function is: (check only one)

11__ General Management: CEO, President, Owner, Director, Vice
President, Partner, General Manager
15__ Purchasing: Agent, Buyer, Procurement Office
20__ Management, Computer/Systems Operations: VP/Manager
MIS/EDP, System Manager, Programming Manager, Data Communications
Manager, Telecommunications Manager, Computer Center/Operations
Manager
22__ Staff, Computer/Systems Operations: Systems Analyst, Programmer,
Software Designer, Computer Operator, Technical Librarian
30__ Management, Engineering/Manufacturing: VP/Manager or R&D Cheif
Engineer, VP/Manager of Manufacturing, Plant or Production
Manager, QC Manager
31__ Staff, Engineering/Manufacturing: Design/Production/Research/
Applications Engineer, Member of Technical Staff, Technician,
Production Control, QC Engineer/Technician
12__ Financial: CFP, Treasurer, Controller, Accountant, Financial
Analyst, CPA
13__ Administrative: Office services, Secretary, Clerk, Word Processing
Specialist, Librarian, Personnel Dervices
14__ Sales/Services/Marketing: Sales Manager/Representative, Account
Representative, Advertising/PR, Customer Service, Training
41__ Research: Scientist, Chemist, Physicist
51__ Education: Dean, Processor, Teacher, Instructor
50__ Consultant/Professional: Independent Consultant, Attorney,
Medicine, Social Services
52__ Other Specify: ______________________________________________


Signature____________________________________________________________


December, 1993 The DECUServe Journal Page: 108

---------------------------- cut here ---------------------------------------

DECUServe Registration Form
_
o Please print clearly or type. | |
|_| New Account
o The registration form below must be used as an invoice. | |
|_| Renewal
o No purchase orders will be accepted.
For renewals, please
o All checks must be made payable to DECUS. enter current username.
_____________________
o There will be no refunds or transfers for any reason. | |
| |
---------------------

Name______________________________________________DECUS Member #______________

Company__________________________________________ Mailstop____________________

Street________________________________________________________________________

City___________________________________________________State______ ZIP________

Telephone # (_______)_________________________________________________________

E-Mail Address _______________________________________________________________

DECUServe Registration Fee [ ] Check [ ] Diners Club / Carte Blanche

$75.00 for one year. [ ] VISA [ ] American Express

[ ] MasterCard

Credit Card #_____________________________________ Expiration Date______________

By signing this form, I agree to abide by the DECUServe Canons of Conduct
(below).

Applicant Signature__________________________________________ Date______________

MAIL YOUR PAYMENT AND COMPLETED REGISTRATION FORM TO:

DECUS -- DECUServe Processing
334 South Street, SHR3-1/T25
Shrewsbury, MA 01545-4112
Please allow four to six weeks for processing.



DECUServe/DECUShare Canons of Conduct

INDIVIDUAL USE OF ACCOUNTS AND ACCOUNT RESPONSIBILITIES

Your DECUServe/DECUShare account is for your use only. You may not share it with
anyone. You are personally responsible for all the activity of this account.
You are personally responsible for all postings made from your account. Postings
to DECUServe/DECUShare include, but are not limited to, any notes entered in
any conference on the DECUServe/DECUShare computer system as well as code,
files, or other information submitted to any part of the DECUServe/DECUShare
computer system.

USE OF POSTINGS IS AT SUBSCRIBER'S OWN RISK

All postings on DECUServe/DECUShare are provided for use at the SUBSCRIBER'S OWN
RISK. DECUS, DECUServe, DECUShare, and the contributor make NO warranties
whatsoever, including without limitation, all implied warranties of
merchantability and fitness.

NO RESTRICTIONS ON REDISTRIBUTION OR MODIFICATION OF POSTINGS

All postings to DECUServe/DECUShare are made with NO restrictions as to
redistribution or modification. Such postings may be freely distributed or
modified by any party, including but not limited to DECUS or any one within
DECUS.

ITAR, PROPRIETARY, CLASSIFIED INFORMATION RESTRICTIONS

No posting on DECUServe/DECUShare, in keeping with DECUS policy, may contain
contain technical data/information that is proprietary, classified under U.S.
Government secrecy laws, controlled by any non-disclosure agreements of any
sort, or governed by the U.S. Department of State's International Traffic in
Arms Regulations (ITAR).

RECRUITING AND SELLING PROHIBITIONS

Personnel recruiting is expressly prohibited. Overt selling is prohibited except
where special exceptions have been explicitly stated.

PROFESSIONAL CONDUCT REQUIRED

Subscribers must conduct themselves in a professional manner marked by integrity
and a spirit of fair play.

OFFENSIVE LANGUAGE PROHIBITED

The use of vulgar, obscene, racially oriented, sexually oriented, or other
inappropriate language is not allowed.

FINAL AUTHORITY

The DECUS Board of Directors reserves the right to determine if any activity is
in violation of the Canons of Conduct. All conduct must adhere to standard
DECUS and DECUServe/DECUShare policies.

You may wish to make a copy of the application and canons before mailing.

Form 20 Aug 93 Canons 25 May 1990