June DECUServe Journal
fr...@eisner.decus.org
=====================
Welcome again to the Hap-hap-happy world of DECUServe! (Okay, I'm
being gooey. Sorry.) The June issue of the DECUServe Journal brings another
bit of great news. By popular demand, the Journal is now available to you
through an email mailing list! You'll find details on how to add yourself to
the list, as well as how to access the Journal through the other channels, in
the article entitled, "The DECUServe Journal: What, How, When, and Where..."
in this issue.
Also of interest are the two technical articles. A long one on
Diskeeper by Executive Software, and one about modem hang-ups. ;-) Enjoy!
I'm looking forward to seeing my mailing list bulge at the seams.
(Thanks to those who wrote requesting one!) As always, questions and comments
can be sent to me at fr...@eisner.decus.org.
Sharon
Table of Contents
-----------------------
Editorial ............................................. 1
The DECUServe Journal: What, How, When, and Where .... 2
Technical Information ................................. 46
Articles
Diskeeper (Executive Software) ..................... 4
Modem hangup doesn't kill process .................. 43
June, 1993 The DECUServe Journal Page 2
The DECUServe Journal: What, How, When, and Where...
-----------------------------------------------------
What?
The DECUServe Journal is a digest of conversations that occur on
the DECUS BBS known as DECUServe. It is generally around 40 pages
long, and is formatted with the intention of being read as hardcopy.
It contains an assortment of technical articles that are hand-picked
from the well-moderated DECUServe conferences.
You do not need to be a member of DECUS or DECUServe in order to
receive the Journal (but we hope that it will encourage you to
join us!).
The Journal is considered to be sort-of public domain, so you can
copy, print, and otherwise distribute it at no charge to your friends
and associates. We only require that it not be altered or editted in
any way.
How?
The DECUServe Journal is distributed three ways: through two Internet
newsgroups, CompuServe, and by mailing list.
comp.org.decus
One Internet newsgroup is called comp.org.decus (the main DECUS
newsgroup). It is not moderated and contains many different
discussions on DECUS issues.
vmsnet.decus.journal
The other is called vmsnet.decus.journal, and it was set up
specifically for the journal. Vmsnet.decus.journal is "moderated" by
the Journal editor, and it is used only for posting each issue of
the Journal.
In order to access the Journal via either of these two newsgroups, your
system must carry one or both of them in its newsfeed.
Compuserve
To obtain a copy of The DECUServe Journal from The VAX Forum on
CompuServe, you must first obtain a CompuServe membership. While
you're logged onto CompuServe, type the words GO VAXFORUM. Once done,
you'll see The VAX Forum visitor's announcement, a news flash detailing
the latest uploads and events, and then the VAX Forum Main Menu. From
the Main Menu, select Option 8 (JOIN) to enter your name in the member
list. Joining The VAX Forum carries no extra charge beyond the standard
CompuServe access charge. Once you've joined The VAX Forum, you're free
to browse through the message base or the many libraries.
June, 1993 The DECUServe Journal Page 3
The DECUServe Journal can be found by typing LIB2 at any ! prompt. This
will bring you into the Library section of The VAX Forum, where
announcements, programs and user-submitted routines are located.
Library 2 is the place where you'll find The DECUServe Journal. From
the Library section, at the ! prompt, enter this command:
BRO LIB:2 DJ*
This tells CompuServe to BROwse through Library 2 and display the file
headers for all files beginning with the letters DJ. The DECUServe
Journal naming convention is DJMMYY.DEC, where MM is the two-digit
month and YY is the last two digits of the year. The May 1993 issue
would thus be called DJ0593.DEC. Once the file header to the issue you
wish to download is displayed, enter DOWN to download the file. You'll
be prompted to enter a filename for your computer. Enter the name and
then activate the transfer protocol you wish to use. You can also type
the command READ at the ! prompt after the file header is displayed and
scroll The DECUServe Journal into a capture buffer.
Mailing List
And now, by popular demand, you can have each issue of the Journal
emailed to you directly! In order to subscribe or unsubscribe you
simply send a one-line email message to "mail...@decus.org". The
body of the message should say:
subscribe decuserve-journal
or
unsubscribe decuserve-journal
You will receive an automatic acknowledgement of the request within
a day or so from the mailserver. If you've subscribed, when the next
issue is sent, you will receive a copy.
When?
The Journal is "published" monthly, on or around the first of the
month. (The editor, in keeping with DECUS traditions, is a
volunteer who also has a "real job". :-) )
Where...
did my issue go?
Occasionally part of the Internet somewhere in the world will choke
and an issue may never get to you. If you find an issue missing (ha!),
feel free to send me email asking for another copy. Also back-issues
from January of this year are available. I keep them all archived
here, and it is no problem to email copies when problems arise.
June, 1993 The DECUServe Journal Page 4
And any time you have questions, suggestions, problems, or compliments,
please don't hesitate to let me know. My email address is
fr...@eisner.decus.org
and I'm there almost daily so that's the best way to reach me.
- Sharon
Diskeeper (Executive Software)
------------------------------
The following article is an extract of the DECUServe
3rd_Party_Software conference topic 38. The discussion
printed in this article occurred between January 23, 1991
and May 5, 1993; although the actual discussion began on
June 22, 1988. This article was submitted for publication
by Jeff Killeen, DECUServe Contributing Editor. Ed.
By Brian Tillman, Pat Scopelliti, Bill Mayhew, Saul Tannenbaum, Ken Brucker,
Bob Hassinger, Arnold De Larisch, Bruce Bowler, Harrison Spain, Evelyn Vigil,
Terry Kennedy, Barton Bruce, Don Roberts, Dan Wing, Dale Coy, Allan Elkowitz,
Harold Kimmey, Alan Hunt, Wayne Bruzek, Linwood Ferguson, Larry Kilgallen,
Gus Altobello, Jon Jones, Barry Suskind, Arthur Cochrane, Galen Tackett,
Jack Harvey, Tim Gardner, Jim Campobello, Dave Mores, Jim Whitfill, Pete Sivia,
Charlie Luce Jr., David MacLean, Bill Downey, John Reynolds, Jamie Hanrahan,
Robert Aldridge, Rytis Balciunas, Bob Koehler, Bob Graham, Lawrence Newton,
Howard Siegel, Vaughn McMillan, Stephen Tatrai, Rick Morrison, Stuart Renes,
Bob Comarow, Larry Hewitt, Erik Husby, James Manley, Daniel Esbensen,
Kay Thomas, John Osudar, Ray Whitmer, John Cason, John Zimmerman,
Milton Campbell
(01/23/91 Ferguson: Diskeeper 4.0: /PASSES & /DONE now incompatible!)
----------------------------------------------------------------------
We finally installed Diskeeper 4.0c when we installed VMS 5.4, and the
next day had a big performance problem due to a minor change they made.
We run Diskeeper nightly in the off hours, running it without I/O
throttling, and limiting it to 8 passes so it will get done before things start
in the morning.
We also used the /DONE qualifier, so that if the disk were already in good
shape it would run less than 8 passes and quit. I.e.
/PASSES=8/DONE
This was explicitly permitted previously, i.e. from pg 2-12:
"Executive Software recommends using /PASSES=n and/or /DONE..."
^^^^
There's nothing I can find in the current release notes, but the current
June, 1993 The DECUServe Journal Page 5
manual now says:
"Executive Software recommends using /PASSES=n or /DONE, but not
both..."
So... if you happen to use this combination, expect it with V4.0c to begin
ignoring the /PASSES and run a LONG time. Mine was up to 111 passes when I
stopped it.
(01/23/91 Kennedy: I have it here...)
--------------------------------------
Well, in my copy of the release notes, I have:
"Beginning with this version of DISKEEPER/Plus, it is no longer appropriate
to specify /DONE and /PASSES=n together in a batch process. Choose one or
the other"
(P. viii, heading "New Sequence when /DONE is used with Multiple Disks")
(01/23/91 Ferguson: My copy of the released notes must have been fragmented)
-----------------------------------------------------------------------------
Yeah, they called a few minutes ago to point it out also. They haven't
been able to tell me how to restore the old behaviour, which I liked. I want
it to run a MAXIMUM of 8 passes, but to quit earlier if it should.
They're thinking about it. I won't be too distressed if we just run 8
passes all the time, since low-movement passes don't take long.
(01/23/91 Tillman: Some bugs in Diskeeper/Plus V4.0c)
------------------------------------------------------
I've just discovered several bugs in Diskeeper's Analysis Utility and View
program. First, in DAU, the Free Space Summary can often list a total free
space size *much* larger than DCL's SHOW DEVICE even when the caches are
completely accurate. Then, in DK_VIEW, the DETAIL screen can show a largest
free space size as being larger than the total free space size. The total free
space size, though, appears to be accurate and in agreement with SHOW DEVICE.
Also in DK_VIEW, on the CONTROL DETAIL screen, the fields containing the
process names are not totally rewritten when a new process name is placed
within then; that is, if a process name that is, say, eight characters long
replaces a process name that is nine characters long, the ninth character
remains on the screen. Thus, when the process name DK_$1$DU5 replaced the
name DK_$1$DU15, I saw DK_$1$DU55.
(02/05/91 Tillman: Something else to wonder about with 4.0c)
-------------------------------------------------------------
Here's another anomaly in Diskeeper. When I run the Diskeeper Analysis
Utility (DAU) on a particular disk, it reports one file that has three headers.
If I use DUMP/HEADER/BLOCK=COUNT=0 on that file, VMS reports that the file has
only a single header and it is not any of the headers DAU reports; i.e. the
June, 1993 The DECUServe Journal Page 6
file id is different from any of the FIDs DAU reports. When I use Jow Meadows'
FILE utility to examine the headers DAU reports, FIND simply returns to DCL,
reporting nothing, which, I believe, signifies that those headers aren't
currently in use.
(02/07/91 Tackett: What is 4.0c?)
----------------------------------
If I remember right, my copy of Diskeeper V4.0 which just came in last
month just says "V4.0" on the tape. I've been reading in prior entries to this
topic of a V4.0c. How do I tell if that's what I have? What is the latest
version?
(02/08/91 Tillman: It's sort of a rev-level)
---------------------------------------------
Version 4.0c is the version of Diskeeper that was on the Diskeeper/Plus
V4.0 tape. Diskeeper itself will tell you its version if you use the disk
analysis utility, DK_VIEW, or the diskeeper control program. Likewise, you
can look in the output files Diskeeper generates and find this version number.
(09/23/91 Campobello: Diskeeper from a non-local CPU?)
-------------------------------------------------------
The only reference I could find to my question is two years and two versions
old, so here goes:
Does anyone have experience running Diskeeper from a MicroVAX or VAXstation
that are clustered with a CI machine, to defrag disks that are off an HSC?
Executive Software says it can be done, but I'm curious about user feedback.
We currently have it running from an 8200 that's part of a 3-node cluster,
but the 8200 is going to be replaced by a MicroVAX. We can either upgrade to
an 8550 license or move Diskeeper to the Micro. The Micro is much cheaper of
course, but we don't want to create any problems.
There's a network traffic increase, and the CPU burden, but since we only
run it off hours that's no big deal.
Is anyone doing this?
(09/23/91 Mores: Diskeeper on a mixed interconnect cluster)
------------------------------------------------------------
Yes, we are doing it on a 8800, 8700, 6420, 785, 2-VAXstation cluster.
Diskeeper runs on one of the VAXstations nitely. I am not involved in system
management of the cluster, so I am not aware of the specific reasons for doing
it. However, it has been in place for months, so it cannot be all bad.
(09/24/91 Whitfill: Diskeeper in Mixed Cluster)
------------------------------------------------
> Does anyone have experience running Diskeeper from a MicroVAX or
> VAXstation that are clustered with a CI machine, to defrag disks that
> are off an HSC?
June, 1993 The DECUServe Journal Page 7
I have been doing this for about 2 years now, i.e., I have a cluster made
up of a 6320, a 6520, 2 MicroVax II's and some VaxStations. Each Microvax runs
Diskeeper on 1/2 of my disks. I have 14 RA-81/82's on my HSC-50 and 6 RA-92's
that are MSCP served off the 6520. The Microvaxes run off the cluster system
disk with only a local page/swap disk. I have had no problems with Diskeeper
running in this configuration. Before I started doing this, I worried too that
it might not work, but the cost of a MicroVAX license for Diskeeper is
inexpensive enough that I thought is was worth the risk, and it turned out OK.
(09/24/91 Campobello: Thanks, this will help.)
-----------------------------------------------
Thanks, this is the way we'll go then. I feel a lot better hearing it from
someone who's actually doing it.
My subscription has paid for itself a hundredfold in the past two weeks.
It just came up for renewal and I had to argue to get it approved (our budget
is really tight now); it helps a lot to be able to point to specific cost
savings that DECUServe contributes to.
(09/24/91 Luce: One more for the road)
---------------------------------------
I'm sorry I didn't catch up to this note before but we've also been doing
this since before I got her 1.5 years ago (6310, 8350, and a MVII with local
P&S disk). We also only run during off hours.
(09/25/91 MacLean: can (may) it run on smallest node to save cost?)
--------------------------------------------------------------------
Is there a licensing requirement for Diskeeper that determines the cost
based on the largest node in the cluster, independent of which node is actually
running the product? We run it from a 6310, which is CI-ed with an 8530 and
EtherNet-ed to a 3600. Technically, no problems. Our license is based on the
8530, which was the machine on which it was originally running (we just bought
the 6310 recently).
Might be worth checking with Exec Sw's license people?
(09/25/91 Campobello: Other nodes irrelevant)
----------------------------------------------
I called them earlier this week. The license and maintenance cost of
Diskeeper are based on the power rating of the node on which it runs,
regardless of what other nodes exist in the cluster. (That's why we want to
transfer our 8200 to a MicroVAX rather than an 8550.)
(09/25/91 Graham: policy change?)
----------------------------------
That's interesting. When we bought DISKEEPER a year and a half ago, ES
insisted that we had to license it for the highest rated machine in our cluster.
I wonder if they've changed their policy, or were we just "taken" before?
June, 1993 The DECUServe Journal Page 8
(09/25/91 Kimmey: Smallest machine, VAXstations much slower)
-------------------------------------------------------------
We don't yet own the product where I work, but I have demo'd the product
and I asked lots of questions. I understood, that you licensed it for whatever
node you wanted to, and whatever it could access, it could defragment. I would
bet that having to buy it for the largest node was incorrect. Definately check
with them as "slyly" as possible.
I had tried running Diskeeper on a Vaxstation defragmenting disks over the
ethernet and found it to be very slow in comparison (1 hour, vs 10 hours), but
your milage may vary.
Actually, I think I'll try the VAXstations again.
(09/25/91 Downey: Another vote for smallest)
---------------------------------------------
I was not only told that we could run Diskeeper on the smallest node in our
cluster, but it was recommended by Executive Software at the time of purchase
(3 years ago).
(02/10/92 Reynolds: 5.0 : waiting for the echoes... )
------------------------------------------------------
We received Diskeeper/plus* 5.0 back in November. I said to myself, "I'll
just watch DECUServe for a while and wait for someone else to find the land
mines".
Do you mean to tell me that it's been three months and not one note?! I
may be looking in the wrong place, but it looks like a major release came out
without a bug. I put that up with alien visitations and bowl victories for the
Buffalo Bills (Note : not picking on Executive S/W, this is a generic
observation on the software industry).
Any satisfied/unsatisfied customers want to say something? Please?
(02/10/92 Whitfill: Diskeeper-Plus V5.0 is OK)
-----------------------------------------------
I have been running Diskeeper_plus V5.0 now for about a month. I have
had no problems at all; it is as solid as V4.0. I like the way they have
written a scheduler to run the multiple disk defrags. Before, if a disk went
away or got sick, the entire defrag process got blasted and had to be restarted;
now it's much cleaner. They also use their own move file software, or the new
VMS hooks, depending on whether or not your system is running VMS V5.5.
(02/10/92 Campobello: Diskeeper working fine here)
---------------------------------------------------
We've been running Diskeeper Plus 5.0 since early December with no problem.
It ran under VMS5.3-1 for half that time and VMs5.4-3 for the other half.
(I had to reinstall after the upgrade.) It seems to work fine, but it could
use a little improvement in the job setup menu interface.
June, 1993 The DECUServe Journal Page 9
> I put that up with alien visitations and bowl victories for the Buffalo Bills
>(Note : not picking on Executive S/W, this is a generic observation on the
>software industry).
Maybe you're not picking on Executive S/W, but you ARE picking on the
Buffalo Bills. At least (oh no, I'm going to resort to the Minnesota/Denver
response) they got there.
(02/10/92 Bruce: notes from a demo)
------------------------------------
I can't give a very fair description, so take this with a grain of salt.
I got a demo, and DID NOT read the manual but simply installed it (as I had
successfully on previous demos). Enough had changed so my previous home-brew
command files to run it the way I thought I needed it run were useless.
They have provided a new menu system to automate setting up defragging
any particular disk or group of disks. Once you figure this out (I still didn't
read the manual, but poked and then called them) you should have little trouble.
I managed to do some things I probably should not have, and wound up with
it doing a pretty nifty job of defraging a bound volume set that *IS* our ANU
NEWS disk. News is the worlds BEST disk *FRAGMENTER*, so I was pleased, but a
MV2 can hardly keep up with news let alone do news and Diskeeper tuned for
heavy defragging.
I had done something wrong (and they were nice and did not say RTFM), and
sometimes got realtime defrag displays showing partially details that
definitely belonged to the OTHER disk!
I called, and they said 1) they knew about it, 2) it was a display ONLY
problem, and did not impact the actual defragging process.
I was going to play more with it, but since the demo period coincided with
Anaheim, by the time I had returned and recovered, the demo had timed out.
When they called, I did say I would appreciate an extension of the demo
but with the stats display fixed. Maybe I should call them again, as I still
want to try it and it should be fixed by now.
Their phone support is always quite helpful.
(02/10/92 Tillman: We've not installed it)
-------------------------------------------
Our policy here is that we will not install anything on the system disk
while the system is on line and out scheduled down times are few and far
between, so we've not installed it. Prior to V5.0, Diskeeper could be
installed on any disk. V5.0 made it a requirement that it be installed on the
system disk (although there's nothing inherent in what Diskeeper does that needs
the system disk - boo!).
(02/10/92 Aldridge: Whose move_file to use?)
---------------------------------------------
Re: diskeeper 5.0
Per a recent conversation with Executive SW: I was advised to *not* use
the VMS 5.5 move_file mechanism, but to stick with Executive's version of the
mechanism. Supposedly the VMS 5.5 move_file mechanism has problems with ACLs.
June, 1993 The DECUServe Journal Page 10
(02/10/92 Kilgallen: Oh yes, I remember that)
----------------------------------------------
This defect was discussed in Anaheim. Under some condition (extension
headers?) the ACLs are omitted from the new rendition of the file.
(02/11/92 Balciunas: Experiences OK here.)
-------------------------------------------
Been using 5.0 for our cluster since November, with no problems.
It's payed for itself in that I no longer have to spend 16 hours once a
month restoring verified copies of backups to defrag disks. I DO see a
performance improvement on one disk that is typically badly fragmented about
one hour after people show up for the day.
I don't have it running 100% of the time, as I've got a very tired cluster.
But the work Diskeeper does off-hours is enough for us...
By the way, 5.0 (at least the version I have here) does NOT require
installation on a system disk. I have it sitting on and running off of one of
my VAXstation's disks, which is NOT a system disk. I did not do anything
unusual to install it, that I recall (or don't recall).
(02/11/92 Koehler: only if you crash)
--------------------------------------
> the ACLs are omitted from the new rendition of the file.
I thought it was that the ACLs might not be part of the atomic change that
switches from the old copy of the file to the new copy, but that only presents
a small window of vulnerability if your system happens to crash right then.
All of the data is OK, you just might not be able to access it! (Or if the
ACE was ACCESS=NONE, maybe you can.)
So does DEC have to find a way to make header extensions part of an
"atomic" move in order to fix this? Sounds like fun for some poor programmer.
(02/11/92 Graham: v5.0 & the system disk)
------------------------------------------
>By the way, 5.0 (at least the version I have here) does NOT require
>installation on a system disk.
Well I'm very confused. The v5.0 that I have WON'T run unless it's on
the system disk, that's based on both the documentation and experience. The
installation procedure doesn't give you any options about where to install it,
it just (arbitrarily) puts the control master in SYS$SYSDEVICE:[SPICM] and
Diskeeper in SYS$SYSDEVICE:[SPICM.DISKEEPER_V50].
I tried to move it to another disk by copying the files and editing the
command procedures (many hard coded references to SYS$SYSDEVICE:[SPICM...]) and
found that it still simply refused to run. The control master wouldn't start;
I didn't write down the error message, but did make reference to not finding a
file on SYS$SYSDEVICE:[SPICM] (this was AFTER all the .COMs had been edited so
that NO references to SYS$SYSDEVICE existed). My conclusion was that at least
some of the images also have the SYS$SYSDEVICE hard coded...
June, 1993 The DECUServe Journal Page 11
Another obnoxious behavior that v5.0 has is that the new control menu
system resizes my DECterm windows down to 24x80.
Other than that, it seems to work just fine...
(02/12/92 Tillman: I'll bet you do have it on the system disk)
---------------------------------------------------------------
If you did nothing special, then you *did* install it on the system disk.
The KITINSTAL.COM file specifically has SYS$SYSDEVICE built in. I've had to
modify KITINSTAL for previous versions in order to get it to install on a
non-system disk.
02/12/92 Tackett: Comments on Diskeeper V5.0)
----------------------------------------------
I just updated Diskeeper from V4.0 to 5.0 on a VMS V5.4-3 system. I like
the idea of the menu-driven controls, but find the implementation a little
weak. Specifically, I'd like to be able to alter the characteristics of an
already created job without having to delete it and start from scratch. Also,
I've noticed that the menu package they use seems to misinterpret some control
character(s) (I think it was control/u or one of the command line editing
characters) as an input terminator.
With V4.0 I had a single process that defragmented multiple disks. This
prevented multiple disks being defragmented at once, to avoid the large I/O
load that might go along with it. With V5.0, I'm not certain what happens
when I have multiple defrag "jobs", one for each disk. Can/do they run in
parallel? If so, can this be prevented?
Does anyone from Executive Software still read this topic?
(02/12/92 Graham: defrag jobs run in parallel)
-----------------------------------------------
From observation, they all run in parallel. At least initially. I found
this out when I created 8 jobs using a "device list". Once the create finished,
I had 8 processes all running at once.
Of course, after they all finished their first runs, they all rescheduled
themselves to run again at different times. So now (2 days later), I generally
only none or just one process running.
(02/15/92 Balciunas: correction to .127)
-----------------------------------------
Others that corrected me on this are absolutely right - DISKEEPER is indeed
running off of a "system" disk. I am so fried from setting up these VAXstations
an juggling things from day to day, that I "forget" and don't even consider
the fact that they boot off of local disks and share a common system disk
elsewhere (things like *UAF, queues, etc.).
(02/16/92 Newton: Not Installed Here)
--------------------------------------
I have my copy still sitting on the shelf. I am not pleased with what they
June, 1993 The DECUServe Journal Page 12
have done with Diskeeper V5.0. I have been fighting for years to keep stuff
off of the system disk and here they come along and force system disk residency
not only for Diskeeper but the control program too. SYS$SYSDEVICE appears to
be hard coded in more than one image (I looked), so it would be difficult to
move it. A few carefully placed patches might make it moveable.
A separate issue I have is because of the way we have things set up, I can
no longer use any of our command files. We have a command file that runs the
analyse program on each disk at 6AM every day and pokes around in the output
to determine the degree of file and free space fragmentation. If either is out
side of our arbitrary values, a 5 pass Diskeeper run is scheduled for 6PM of
that day.
(02/18/92 Reynolds: No room, no upgrade.)
------------------------------------------
>The installation procedure doesn't give you any options about where to install
>it, it just (arbitrarily) puts the control master in SYS$SYSDEVICE:[SPICM] and
>Diskeeper in SYS$SYSDEVICE:[SPICM.DISKEEPER_V50].
Well, that's the show-stopper I was waiting for. I'm running a VAXstation
II with an RD53 system disk. I've got pretty close to no spare disk space there
already. Looks like it's version 4 forever...
I can understand why E.S. would want to standardize its installation on one
disk, but this really would have been a lot better as an option.
Thanks, everybody.
(02/22/92 Kimmey: I guess they will be committed now.)
-------------------------------------------------------
I had many of the same issues. If it's a DEC product and it installs
itself on the system disk, I complain to DEC. If a third party installs on
the system disk we don't buy it. We bought Diskeeper. You say, "Why ?".
Because I had a chat with some of the diskeeper developers and they could
understand why not to put it on the system disk. I appears that they now have
a more stringent need to know exactly where the software is in case it needs
it and I guess they felt the best way was to hardcode it and put it on a disk
that would always be there - SYS$SYSDEVICE. But they have agreed to change it.
I also like the menu interface, but if I can't create a command procedure
to run it flexible enough for my site then it no longer is good enough...
Rabbit-7 is a pretty good package. They have agreed to a command interface of
some sort to mimic the functionality of the menu's for the next release.
We have found Executive Software to be very open to reasonable changes that
are justifiable. If you don't like something call their technical support.
If it's important enough to you, ask to speak to a manager, or a developer.
We are running 4.0.
(03/23/92 Ferguson: Recent Diskeeper problems)
-----------------------------------------------
We are running 4.0c of Diskeeper and have recently had two different and
troubling problems.
On a 785, with RA81 disks, running VMS 5.4-2 (none of which has changed
June, 1993 The DECUServe Journal Page 13
recently) it started access violating. No damage was done to the disk (except
it left its temporary file around). ANA/DISK and diskeeper's validation
routine both say the disk is fine. DEC says the hardware is fine (no errors
logged, preventive maintenance and micro disgnostics run with no errors).
Executive software says "hardware problem" and wanted to close the call.
We insisted they research it, and that was the last we heard. We are not able
to run it on that system (and have stopped trying).
Also, we had a very scary problem on a 4000-300 which I've described in
HARDWARE 1107 which may have been hardware, or may have been Diskeeper, but
which definitely did corrupt data, and did so without logging a forced error of
any kind. This just happened and we are collecting the details to send to
Executive; I'll report any useful comments by them.
Any insight anyone has (or any similar stories) more than welcome.
I'm beginning to become less of a fan of disk degragmentation. :-(
(03/23/92 Kennedy: I think you have a hardware problem...)
-----------------------------------------------------------
I am running a 785 with Diskeeper 4.0c, with 12 RA81's on an HSC50 and 4
more RA81's on a UDA50 and haven't seen this problem. However...
> On a 785, with RA81 disks, running VMS 5.4-2 (none of which has changed
> recently) it started access violating. No damage was done to the disk
Can you look (or have someone at the site) look in the 785, behind the
smoked plexiglas covers, and see if your CPU has the "-YA" FCO installed?
Also, look at the memory controller and memory/SBI interface cards (M8275/6
as I recall) and tell me what revision they are (it will either be in red on
the handle, or wrapped on the handle with a Brady (tm) cloth marker?
Last, did you recently increase the amount of memory in the system?
If any of these point out anything, let's split that part of this discussion
off into HARDWARE_HELP in a 785 topic.
> I'm beginning to become less of a fan of disk degragmentation. :-(
I'm a big fan. We wouldn't be able to get by without it. However, I'm less
than thrilled with Executive Software's newer code. We had an _extended_ period
of discussion (4 or so months) with them about V5, with the end result that we
will not run it here. We are running 4.0c until DEC gets their defragmenter
stabilized, at which time we'll probably switch to it. [BTW, I didn't have
any problems with the defragmenter in V5, but had major gripes with the user
interface and the new job controller.]
(03/23/92 Tackett: More info on Diskeeper gripes?)
---------------------------------------------------
Terry, could you say more about what you don't like about Diskeeper's
latest version? We've just installed it within the last 6 weeks and haven't
had any serious problems, although I'm not completely happy with the user
interface.
June, 1993 The DECUServe Journal Page 14
(03/24/92 Kennedy: Some DK 5 gripes)
-------------------------------------
Some of this is based on a (ahem 8-) version I got before V5.0 shipped.
However, I was told that it was the same as was shipped to customers, so
I didn't even open my package.
First, it seems to be the exact same defragmenter engine from V4.0 (and
likely 3.1). All they've done is put a new wrapper on it and add movefile
support. I was profoundly unimpressed with the new "control master" interface,
which made some things harder to do than V4.0. There is no way to get any info
out of the job controller, which makes changing things a royal pain.
Bugs in the user interface that I reported under V4.0 still weren't
corrected. Try running DKVIEW on an LA120. Try using line editing. The folks
who did this code had no understanding of the "standard" VMS user interface,
which scares me when you think about what Diskeeper really does.
A new bug under V5 is that if a disk fails validation, it is removed from
the list without notifying the user via either the mail or the broadcast lists,
and you have to delete and re-enter the whole job because there is no way to
modify the entry. Also, I've found that this has about a 50% chance of
corrupting your queue file.
V5 starts a bunch of jobs off by default, and one has to tread one's way
through like 5 levels of menus to find the non-obvious way to change this.
I really think V5 was an attempt to provide a similar feature set to DEC's
version without really improving the product. In fact, I think the changes
reduced the functionality of the product.
(03/24/92 Tillman: Non-system disk use will probably happen)
-------------------------------------------------------------
By the way, a future release of Diskeeper will remove the requirement
that it be installed on the system disk. I received a phone call from
Executive Software and talked about this requirement. Apparently there's been
enough of an outcry that they will change it.
I just can't understand why they baked SYS$SYSDEVICE into the code in the
first place.
(03/24/92 Siegel: Boards is boards...)
---------------------------------------
>Can you look (or have someone at the site) look in the 785, behind the
>smoked plexiglas covers, and see if your CPU has the "-YA" FCO installed?
It's been too long since I've poked behind the plexy and I forget what all
the boards are, but here goes...
In the CPU, there are 3 boards with "YA" designations. The M7468 and M7469
boards have YA imprinted in the metal handle. The M7471 board has A1 on the
handle, but has YA written on the board.
In the next cage over are the following boards: (UNIBUS adapter?)
M8273 D1
M8272 D
M8271
M8270 D
June, 1993 The DECUServe Journal Page 15
The next card cage is the memory and it's controller is made of 2 M8375 D's
and one M8376 E1. The memory boards are a combination of M8373 AF, AJ, AP,
and B and the rest are EMC boards.
Next cage over has:
M8278 F
M8274 A1
M8276 E
M8275 J2
Next cage over has: (UNIBUS adapter?)
M8273 C
M8272 D
M8271 F2
M8270 D
More info on the configuration. The RA81's are split onto 2 UDA50's and
which are each on a separate UNIBUS.
Also, Linwood was not quite correct. ANALYZE/DISK said the disk was fine,
but the Executive Software DISK_VALIDATE program, which is supposed to cleanup
after DISKeeper, hung the system.
> If any of these point out anything, let's split that part of this discussion
>off into HARDWARE_HELP in a 785 topic.
Does any of this ring a bell Terry?
(03/25/92 Kennedy: Check these, answer in H_H please)
------------------------------------------------------
> In the CPU, there are 3 boards with 'YA" designations. The M7468 and M7469
> boards have YA imprinted in the metal handle. The M7471 board has A1 on
> the handle, but has YA written on the board.
Hopefully you have a -YA 7470 as well. Also, the M7460 should be D2 or
higher, and the M7472 should be C2 or higher.
> M8271
F2 or higher?
> M8273 C
Probably wants to be a D, but probably not important.
> Does any of this ring a bell Terry?
Not a lot. Suggest you check the new questions and report back in HARDWARE -
this has certainly become inappropriate for 3RD_PARTY at this point.
June, 1993 The DECUServe Journal Page 16
(03/25/92 Ferguson: 785/accvio -- take it to HARDWARE 1111.*)
--------------------------------------------------------------
Discussion on 785 access violations in Diskeeper moved to 1111.*
until/unless we determine something more directly relevant to this thread.
(04/08/92 Tackett: Hanging jobs in Diskeeper V5.0)
---------------------------------------------------
I've seen a peculiar problem with Diskeeper/Plus V5.0 that happens like
this:
1. Pause all Diskeeper jobs using the Diskeeper_Control program this is
done from a COM file so I can't use the menu interface), i.e.:
$ DISKEEPER_CONTROL ALL_JOBS/PAUSE
2. After waiting ten minutes or so to let any active job pause,
$ SET VOLUME/REBUILD=FORCE $x$DUAnnn:
$ MCR SYSMAN DISKQUOTA REBUILD/DEVICE=$x$DUAnnn:
for most or all of our 15 disk drives.
3. Resume all Diskeeper jobs, i.e.:
$ DISKEEPER_CONTROL ALL_JOBS/RESUME
After this, I sometimes find one or two jobs (I allow a maximum of two to
run) that show up as RUNNING in Diskeeper's job display, but their process is
idle (and in LEF or HIB, can't recall which). Attempting to pause or resume
the hung jobs produces no error messages but changes nothing. I have to kill
the jobs and restart them from scratch.
Too bad Evelyn Vigil (was that her name) or someone else from Executive
Software no longer reads this topic.
(04/09/92 Campobello: Have you tried /SUSPEND?)
------------------------------------------------
The Diskeeper /PAUSE qualfier allows the jobs to finish their current run.
Perhaps they aren't quite done when you do the REBUILD, and this interferes
with their completion and pausing. You could try using /SUSPEND instead of
/PAUSE. SUSPEND puts them on hold immediately. I have used it fairly often
with no problem resuming the jobs (you still use /RESUME).
(04/15/92 Tackett: /SUSPEND doesn't help)
------------------------------------------
/SUSPEND has the same effect as /PAUSE; I actually tried /SUSPEND first
given what the documentation says about it working immediately.
I've tried waiting for up to 20 minutes after /SUSPEND or /PAUSE but still
have the same problem. Whenever I issue a /SUSPEND interactively the jobs all
suspend almost immediately; /PAUSE only seems to take slightly longer.
June, 1993 The DECUServe Journal Page 17
(04/28/92 Bruce: they say they have been listening)
----------------------------------------------------
I just got a call from Executive Software and they said they have been
listening to all the complaints about the 'new' Diskeeper user interface, and
the display bugs, and feel they have addressed them all. The command line
interface is back and there are some supposedly nice new features, so I want to
see it.
There is apparently a new version in or about to be in beta, and the guy
that called said someone would be calling back about my getting a beta copy.
Has anyone else seen it yet? Does anyone know any more details?
(04/29/92 Tillman: Better late than never)
-------------------------------------------
In addition to the aforementioned changes, ES will also eliminate the need
to install on the system disk.
I, too, have been solicited for my opionion from Executive Software. Why
they didn't ask us for our opinions before they changed the interface, I'll
never know. It would have saved them a lot of grief.
(04/30/92 Siegel: That's the story I get)
------------------------------------------
Because of our recent problems with Diskeeper, I have been on the phone
quite a bit with Executive Software. One option they suggested was to use
version 5.0 instead of version 4.0c, which we are currently using. When I
mentioned that we had the 5.0 release tape, but would not be using it because
it did not have a CLI interface and we did not want to rewrite our procedures
to use it, they promised(!) that the CLI interface would be coming sometime
this summer. We shall see.
(05/01/92 Kennedy: They seem to be listening)
----------------------------------------------
I talked to them for a long time today. They called me because of a very
negative questionnaire that I sent back. They now seem to understand the need
for a command-based interface, and they're going to revisit some of the bug
reports I've filled out on V4 and V5 regarding the menu utilities.
I also discussed some possible functional enhancements to the product (new
utilities for dealing with the index file), and they sounded quite interested.
We'll see.
(05/02/92 Spain: Diskeeper V6.0)
---------------------------------
I just received a flier from Executive Software (they must have an unlimited
mail budget). It discusses quite a bit on Diskeeper V6.0 including the command
line interface (surprise!).
I suspect any Diskeeper customer will get this flier. The disappointing
part is that Diskeeper V6.0 will be released this summer! They seem anxious
to let us know the new features are on their way...
June, 1993 The DECUServe Journal Page 18
(06/25/92 McMillan: We're Back!)
---------------------------------
After a somewhat lengthy absence, someone from Executive Software is back on
DECUServe. Please allow me to introduce myself -
My name is Vaughn McMillan, and I'm the Research Director for Executive
Software. I've taken over Evelyn Vigil's position. She has taken an executive
position at a management consulting company here in Los Angeles. I'll be
monitoring this topic (as well as several others) in order to stay in closer
contact with you all, and to offer any technical assistance I can.
Let me start by saying thank you for all the feedback on DISKEEPER/Plus
V5.0. Rest assured we heard you, and are addressing all of the V5.0 issues
you've seen or written about in this conference (plus quite a few others).
V6.0 is in beta field test now, but no firm release date has been set.
Please let me know if there's anything I can help you with, as long as it
conforms to the DECUServe Canons of Conduct. Thanks!
(06/27/92 Spain: Welcome)
--------------------------
Thank you for the note Vaughn and welcome! I'm really looking forward to
a simple command line interface to DISKEEPER. Since we shutdown diskeeper
before backups and then restart, the reliability has been a real problem :-).
(09/10/92 Kennedy: Received V6.0, found bugs)
----------------------------------------------
I installed Diskeeper V6.0 last night. At this point I have identified a
large number of problems with it. While none of them seem to cause data loss,
they did make one of my production systems unusable (two of the bugs are that
it faults 6 pages for every disk block moved, and that it tends to loop for
extended periods at priority 31). It also isn't moving files that it should.
I have a call in to their tech support. I placed it at 9:00 AM. After
getting past their receptionist and connected with their call screening guy
(Chris), he tells me that they "hope to be able to call you back today".
We'll see.
Obviously, I suggest that you not install this version (at least not
without testing on a sacrificial system).
(09/11/92 Tatrai: Also having a problem)
-----------------------------------------
I read this not a day late. I also have noticed the problems. Will wait
to hear what you are told.
(09/15/92 Kennedy: Answers from ESI)
-------------------------------------
I escalated this problem within Executive Software and got some good
answers. The page faulting issue is due to the defragmentation process
limiting itself to 1500 pages. This can be fixed by navigating the menus as
follows:
June, 1993 The DECUServe Journal Page 19
CM STATUS PDB MODIFY DISKEEPER TYPE DKDFG WSQUOTA
I changed it to 5000 which fixed that problem.
The excessive time for disk validation only happens on one disk which has
141000 active files on it. There is some sort of "knee" in the performance and
if you exceed that, things slow down. They are looking at this problem. My
other disks validate in less than 5 minutes elapsed time.
The exclusion list is apparently a red herring. It is reporing directories
where it will look for files to be excluded. They claim it isn't excluding all
the files in the [*...SYSEXE] directory. They say that if I turn on the listing
of excluded files, I'll see a much smaller group of files.
At this point I'm satisfied with the answers I've received and am continuing
to run V6.
(09/15/92 Siegel: Menus vs CLI interface)
------------------------------------------
I know nothing about the menu interface as yet...
We intend to continue to use the CLI interface. Must one use the menu
interface to set the WSQUOTA or is there a different method one uses when using
the CLI interface?
(09/15/92 Kennedy: Probably)
-----------------------------
It's probably possible to do it from the command line. However, they talked
me through it via the menus. Since the menus are installed by default, and this
is a one-time configuration change, even rabid menu-haters can probably do it
without too much distress 8-)
(09/17/92 Morrison: Another v6.0 problem)
------------------------------------------
Ran into a bug here w/6.0. For event notification do NOT send MAIL
notification to a username who has mail forwarded to Pathworks mail. This
locks up the Control Master process. ESI is aware of the problem and is
researching. Just send to a VMS username who isn't forwarding to a Pathworks
client...or don't use the notification MAIL feature.
(09/17/92 Kennedy: Actually a callable mail bug)
-------------------------------------------------
In all fairness, I think that's actually a design error in Callable Mail.
If it's the same problem, you can work around it by specifying 0::username
instead of username.
(09/20/92 McMillan: Changing WSQUOTA From The CLI)
---------------------------------------------------
> We intend to continue to use the CLI interface. Must one use the menu
> interface to set the WSQUOTA or is there a different method one uses
June, 1993 The DECUServe Journal Page 20
> when using the CLI interface?
First, the default WSQUOTA works very well at most sites, so it is not
likely that you will need to change this parameter.
If you do indeed need to modify the WSQUOTA for the DKDFG server, it can be
done from the DCL prompt, taking advantage of the new Menu Command Macro
feature in DISKEEPER/plus V6.0. Here's a quick step-by-step:
1. Create a text file named WSQ.INP in the directory from where you invoke
DISKEEPER/Plus. (Any name and extension can be used, but the .INP
extension is the recognized default.)
2. In the WSQ.INP text file, enter the following commands:
PDB
MODIFY
DISKEEPER
TYPE
DKDFG
WSQUOTA
5000 ! Or whatever value is determined necessary for your site
! This blank line is interpreted as a <Return>
EXIT EXIT EXIT EXIT ! Exits this procedure from the menus
3. From the DCL prompt, define the following symbol:
$ CM_STATUS :== $ESI_PROD_CONTROL_MASTER:CONTROL_MASTER_STATUS.EXE
4. From the DCL prompt, invoke Control Master Status, calling the WSQ.INP
macro, with this command:
$ CM_STATUS @WSQ
This procedure circumvents the menu system, and makes use of the new Menu
Command Macro feature in an unconventional manner. The procedure is completed
in about three or four seconds.
Chapter 2 of the DISKEEPER/Plus User's Guide contains a full explanation of
the new Menu Command Macro feature.
Glad to be of service -
(09/21/92 Tatrai: Problems in VIEW DETAIL?)
--------------------------------------------
Has anyone notice under V6.0 having the values in the files moved etc.
area disappear while doing a view detail? The run # also disappears. If I
exit and return all seems OK.
(09/21/92 Tillman: It's not your imagination)
----------------------------------------------
This is definitely a problem that I've discussed at length with ESI support
personnel. It's not your imagination. It's also not the only problem with
June, 1993 The DECUServe Journal Page 21
VIEW. It will also on occasion decide that there are no jobs defined. I've
also had it jump between pass N and pass N-1 in the detail display. The
problem seems to be that they're not properly referencing the global section
where the pass info is kept.
(09/23/92 Renes: We found the bug, too!)
-----------------------------------------
WE just started using the new 6.0 release here too. Had been running
the 4.0+ version for quite a while with _no_ problems.
We ran into the mail forwarding bug too, but here Control Master died
trying to forward mail from the host 8700 to a VAXstation 3100 via standard
VAXmail. Once that was removed, it worked fine!
We defragment 100 disks a night on a single 8700 with about 33 server
processes. I noticed that _all_ disks get at least one run before the end of
the 14 hour "shift".
Anyone else adjusted the MAXIMUM SERVERS parameter and gained/lost
performance?
(09/24/92 Tillman: Have you been able to do this?)
---------------------------------------------------
> In all fairness, I think that's actually a design error in Callable Mail.
I tried to modify the USER list to specify 0::username and Control Master
would not allow the format. It checks for alphanumeric strings, apparently.
I've asked ESI to supply some mechanism to let me tell Control Master that,
whatever the form of the mail address, to accept it, such as quotes or angle
brackets (<address>).
(10/12/92 Comarow: Doesn't use logical names)
----------------------------------------------
My major complaint is that it translates logical names I give Diskeeper
into physical names for all log files and menus. For a large site, this rather
annoying, and also assures that one can't move drives and continue to have
Diskeeper operate.
If I give it a logical name, it should return logical names.
(10/12/92 Tillman: You can't believe VIEW very much)
-----------------------------------------------------
Another problem with VIEW's detail screen is that the size of the largest
free space can often be displayed as being larger than the total free space.
Right now, I have a disk that VIEW says has 400,000 as the largest free space,
but that the total free space on the disk is 200,000.
(10/13/92 Campobello: I guess it works both ways)
--------------------------------------------------
Last Friday DAU told me that a disk's largest free space was 271956
blocks, but I was able to create a contiguous 400000 block page file with no
June, 1993 The DECUServe Journal Page 22
change to the disk.
(10/13/92 Tillman: Potential Multiheader Consolidate problem)
--------------------------------------------------------------
I tried the new multiheader consolidate program shipped with Diskeeper
V6.0. For the most part, it worked exactly as advertized, even handling
multiheader files with ACLs attached (which wasn't possible before V6.0). For
one of these files, however, I noticed that the last two entries in an
eight-entry ACL were duplicated five more times in the ACL. That is, my ACL
looked like this:
(IDENTIFIER=ONE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=TWO,ACCESS=READ)
(IDENTIFIER=THREE,ACCESS=READ)
(IDENTIFIER=FOUR,ACCESS=READ)
(IDENTIFIER=FIVE,ACCESS=READ)
(IDENTIFIER=SIX,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
(IDENTIFIER=SEVEN,ACCESS=READ)
(IDENTIFIER=EIGHT,ACCESS=READ)
I performed a SET ACL/DEFAULT to clear it up. Other multiheader files in
the same directory and having the same ACL to start were consolidated with no
problem at all and the ACLs were correct. I've called ES to discuss the
matter, and am waiting for a return call.
(11/10/92 Spain: Diskeeper V6.0)
---------------------------------
I've been a DISKEEPER user for the past 8 years. I just spent about an
hour discussing the new V6.0 release with Executive Software (Howard Butler).
Am I alone in my disappointment over the "command line" interface, the
menu, and Control Master?
I was hoping for a more 4.0-like command line interface. This command line
simply inputs your information into the menu! You work to build the command
line and get to use it only once. After that you have to wade through the
menus to figure out how to change it. Yuck! I really dislike the menu :-).
I really dislike Control Master. How often has Control Master died? It is
hard enough getting Diskeeper to work properly without having Control Master
get in the way.
We try to pause the Diskeeper job before backup and resume after backup.
You use DISKEEPER_CONTROL to pause the job right? When DISKEEPER_CONTROL
June, 1993 The DECUServe Journal Page 23
passes a success to $STATUS the job is paused right? Wrong! The "success" is
only the fact that Control Master got the message. The job may (or may not)
be paused. The same is true of resume.
Why can't we just submit the jobs detached and be done with it? ES says
I'm alone in this and their survey shows folks really like the menu. I'm
whining in public to see if you agree :-).
(11/11/92 Kennedy: Me too)
---------------------------
I still don't like it. As an example, I recently needed to run Diskeeper
on a disk that was just "passing through". Under V4.0 I could just edit a new
CUSTOM startup .COM and then run it. With CM I have to specify all of the
options through the (annoying) menus.
We just renewed our Diskeeper support for another year (I expect to need an
update when VMS V6 comes out). When the year is up, we're probably going to try
one of the other products (probably DFO).
(11/11/92 Ferguson: We sure were not a customer asking for it)
---------------------------------------------------------------
If the V6 version won't run the V4 commands, they can expect to hear from
another unhappy customer also.
Diskeeper was suppose to be a "set it and forget it" program. The idea of
having to "remember" it to the point of reworking your procedures every update
is not reasonable.
(11/11/92 Comarow: Agree- but performance much better)
-------------------------------------------------------
I agree. I liked the v4 interface much better. I especially hate the
logical name-physical device substitution.
However, there appears to be a definite performance improvement - in that
the impact to the rest of the users/cluster is much less when diskeeper runs.
(11/11/92 Renes: Several small minuses, 1 BIG +)
-------------------------------------------------
We, too, do not like the menu very much. Try running it at home at 2400
bps sometime...very slow to repaint the screens (they wrote their own screen
package).
We've reported problems to Exec. Software about DISKEEPER-CONTROL not
passing the correct status to $STATUS. We've also reported problems with
Control Master/Menus not creating all jobs given a list of 100+ disk devices.
On the positive side, Diskeeper itself seems to be better than ever.
(11/11/92 Tillman: Why leave something good alone when you can change it?)
---------------------------------------------------------------------------
It is because I, you, Terry, and *many* others hollered that they even
put a command line interface back in. I, too, liked the V4 interface. All
the qualifiers and defaults were right there for me to see every time, instead
June, 1993 The DECUServe Journal Page 24
of having the CM program store them for me.
They felt that the vast majority of system managers were people thrust into
their jobs with little or no training and they wanted their products to do a
lot of hand-holding at installation and then be very inobtrusive from then on.
The upshot of this is that those of us who know how to take shortcuts are
stymied because the shortcuts have been blocked.
The rationale behind CM, though, was that they were going to release other
products that were also started by CM. It doesn't appear that any came to
fruition.
(11/11/92 Siegel: What causes a DATACHECK error)
-------------------------------------------------
After the problems we had a few months back, we started using the
/SOFTWARE_CHECK qualifier so DISKeeper will do the data comparisons rather than
VMS or the disk hardware. Now we have suddenly gotten a bunch of
"%SYSTEM-F-DATACHECK, write check error" error messages in the log file. They
occur right after the "Pass n started at" messages, with no other information.
So far, they have never occured in pass 1, only in the later passes. This has
occured on 2 systems on 3 disks (all RA81's). We are running VMS 5.4-2 and
5.4-3 and DISKeeper 4.0c. DISKeeper runs in detached processes, one process
per disk, started from a batch job at 01:00, with the following options:
/SOFTWARE_CHECK /PASSES=8 /NOIO_THROTTLING /PLACED_FILES
/REJECTED_FILES /NOFID /VALIDATE=ONCE /PERCENT_INVALID_LIMIT=1
After the first problem, Executive Software said there was a structure
error in the file system, but ANALYZE/DISK could not find anything.
So the question is, what could cause the DATACHECK errors and what problems
if any may result from DISKeeper aborting this way?
(11/11/92 Wing: menus - bletch!)
---------------------------------
I just wanted to add that I don't like the menu. I don't like most menus.
And Executive Software's 'command line interface' in V6.0 isn't as straight
forward as it should be. They should have just made the menu crank out the
V4.0-style commands (in a .COM file) and then execute the .COM file.
And Control-Master is a hassle.
I've got a 6620, and it takes a good 2-3 minutes to start all the jobs on
all my disks (about 15 or so) [when I want to reconfigure something] in V5.0.
(11/12/92 Hewitt: I agree!)
----------------------------
I'll second all of the negatives about the menu interface and Control
Master. I'm disappointed that the new command line is not like V4, as I was led
to believe.
June, 1993 The DECUServe Journal Page 25
(11/12/92 Downey: Me, too!)
----------------------------
You can add me to the list of disapointed users.
(11/12/92 Spain: Send in those cards and letters!)
---------------------------------------------------
I sent ES a letter detailing my frustrations and would encourage you to do
the same (who knows we may make a difference?).
ES indicated that new users to Diskeeper like the menus and old users hate
it. I suspect all of us are old users :-).
(11/17/92 Cochrane: Old user that also HATES the menu.)
--------------------------------------------------------
I am an old (not age) user and I HATE the menu. They also like to do things
with control sequences that drive DECterms from small to big.
I plan to go to DEXPO in Las Vegas and complain to ES. I suggest any other
symnposia attendees to likewise.
(11/19/92 Scopelliti: Let's bug them all week!)
------------------------------------------------
I'll bring my axe!
(12/18/92 McMillan: I Hear You)
--------------------------------
Dear All -
Boy, you guys sure got busy starting on the 11th of November! I just
thought I'd let you all know that I'm duly noting all of your comments about
DISKEEPER/Plus. Thanks for the honest opinions.
Part of my job here at Executive Software is to help determine what the
public needs/wants/likes/dislikes about DISKEEPER, and see to it that
subsequent releases provide as much as possible to as many as possible.
It's a little early to mention what will be in V7.0, but suffice to say,
it's feedback from the users that helps determine the direction the software
turns. As Harrison said, most new users prefer the menus; the old (not
necessarily by age) pros like to use the command line interface.
I'd like to read any specific suggestions for the CLI, so they can be
considered for the next version. Same goes for the menus (which are here to
stay, but are open for improvement).
(12/19/92 Ferguson: I liked Diskeeper because it *saved* work)
---------------------------------------------------------------
The CLI should remain upward compatible forever, at least to the extent
possible (and here "possible" means, like, DCL is still around and not Unix).
I have never upgraded from V4, and am not anxious to devote some
programmer, who (since it has been some years) has never seen _either_
June, 1993 The DECUServe Journal Page 26
interface or our setup, to figuring it all out and making the new 6.0 menus
work.
As I told both Brian and Howard at the Symposium: your product's big
selling feature is a "set it and forget it" approach. We set it, it works,
we're happy -- but with each new release we not only have to remember it
(installing it is kind of expected), we have to redesign how we use it. That
is very contrary to your biggest feature. Diskeeper should *save* me work,
not force me to do more.
(12/21/92 Comarow: Suggestions)
--------------------------------
A few suggestions:
1: It should use logical names. If I move a disk to another physical
device it breaks the jobs. If I want to examine the parameters of a
job I can use logical names. All other software allows me to use the
logical names.
If programmers use hard coded physical names, what do we usually call
that programming? Bad.
2: Compatiblity from version to version, as previously requested.
3: Not having to set up all kinds of symbols and such to set it at the DCL
level. The Version 4 syntax was fine.
4: Getting too pricy on large systems.
(12/29/92 Wing: DECterms get shorter)
--------------------------------------
I usually have 48-line long DECterms. When I startup the Diskeeper menu,
it cuts my DECterm down to 24x80, and doesn't return it. Pet Peeve of the week,
I suppose, but something easily fixed.
(12/30/92 Husby: A feature of SET TERMINAL/INQUIRE and the DECterm)
--------------------------------------------------------------------
That is most likely caused by Diskeeper doing the equivalent of the SET
TERMINAL/INQUIRE command. That command will also switch your 48 line DECterm
to 24 lines. Its a "feature" of the DECterm controller.
(01/02/93 Comarow: Automate MHC)
---------------------------------
Another suggestion.
Allow multi-header consolidate to have the option of simply running instead
of asking for each file.
June, 1993 The DECUServe Journal Page 27
(01/02/93 Scopelliti: Defragment INDEXF.SYS)
---------------------------------------------
Another suggestion:
Given a dismounted disk, the ability to defragment INDEXF.SYS.
No, I'm not crazy... Given a dismounted disk, it is fairly easy to
visualize how INDEXF.SYS could be defragmented. Note that INDEXF.SYS always
has at least four extents which cannot be reduced.
When INDEXF.SYS cannot be extended, my system is down for several hours
while I do the backup/restore thing. This does not contribute to 24 x 7!
(01/03/93 Kennedy: Already suggested)
--------------------------------------
I mentioned this to them during the development of V6. I also suggested that
it would be nice to have an off-line utility to contiguously extend INDEXF.SYS
at the same time.
Unfortunately, at the time I was considered an undesirable (yes, after this
all blew over one of the folks at ESI actually admitted this). However, the
person with the low opinion of me has left the company and I'm told that they
may consider this idea for the future.
(01/04/93 Manley: Diskit already does)
---------------------------------------
> No, I'm not crazy... Given a dismounted disk, it is fairly easy to
>visualize how INDEXF.SYS could be defragmented.
Besides Diskit from UIS does this with their off-line utility. This offline
utility is in my opinion the key difference between the two products.
(01/05/93 Tackett: Command line editing in menus)
--------------------------------------------------
How about allowing regular VMS-style command line editing in the DKP JOB
and VIEW menus? In V5.0, if you press control/E or backspace or use the arrow
keys, it sees them as input terminators...
(01/06/93 Kennedy: Most are fixed)
-----------------------------------
This was one of my _BIG_ complaints about V5, and I repeatedly explained
that there were major problems in their screen handling.
However, _most_ of them are fixed in the current version, V6.0. It seems
that someone who understands SMG went in and cleaned things up. The remaining
problems appear to mostly be a) actual discrepancies between what the Diskeeper
global section contains and reality, and b) a difference of opinion between
what the user thought he wanted and what the progtam thought the user wanted.
(01/11/93 Bruzek: How is DK Licensed at your site?)
----------------------------------------------------
Of you folks who use Diskeeper on a cluster, are you paying for it on a node
of your choosing, or being forced to pay to use it on the largest node of your
June, 1993 The DECUServe Journal Page 28
cluster? We always ran it on the smallest node (a 3500), but were told last
week that we would have to license it for the largest node in the cluster.
They (ES) said that that was always a requirement, but that they never really
enforced it!
(01/11/93 Altobello: I think it was always "largest node"...)
--------------------------------------------------------------
We always had Diskeeper licensed for the largest node on our cluster, and
I believe that was due to Executive Software's licensing requirements.
I seem to recall that the full condition was "largest node on the cluster
that could directly access all disks", which may not be the same in your case.
(01/11/93 Kennedy: We have it on not-largest)
----------------------------------------------
I have it running (and licensed) on a 785. There is also an 8650 in the
cluster, as well as some MicroVAX/VAXstation NI systems.
At the time we purchased it, this was Ok - in fact I specifically mentioned
that I had this 785 for the express purpose of performing this type of service
task.
Of course, with the increased CPU demands of recent versions this isn't
really practical any more - I have a disk which makes DK V6 sit in a solid COM
state for 6 hours before it begins processing, on _every_ _single_ _pass_.
Their tech support folks asked me for some info, which I gave them, and they
have not yet responded (8 months) with a solution/workaround. I suspect that
when we upgrade the 785 to another 8650, we will drop DK and investigate DEC's
offering (and possibly others).
(01/12/93 Campobello: Smaller node, and it better stay that way)
-----------------------------------------------------------------
We only have a two-node cluster, but we are using it on the smaller one.
The difference is significant, since it's an 8550 and a MicroVAX. We cleared
this specifically with E.S. when we got rid of an 8200 and acquired the
MicroVAX, less than a year ago.
If they try to make us pay for the larger node, that will be the end of
Diskeeper at our shop. We have neither the money nor the capacity to run it
on our larger node.
(01/12/93 Hewitt: Smallest node here, too)
-------------------------------------------
We run it on the smallest node in the cluster, too. ES is aware and said
nothing about requiring the largest node. We will switch to another vendor,
too if required to upgrade to the largest node.
(01/12/93 Bruzek)
-----------------
Yes, last year we moved the licenses from our 8600 to the 3500. It was
fine with the sales rep then, but now the new sales rep broke the news about
June, 1993 The DECUServe Journal Page 29
the largest node requirement. I told him we don't have the money budgeted to
do it, and he said he'd get back to me. As much as I like Diskeeper, I may
have to start looking at other packages. Any recommendations folks?
(01/12/93 Coy: DFO)
--------------------
DEC will license DFO to run on any node.
(01/13/93 Esbensen: How about A Fragmentation Preventor for a change?)
-----------------------------------------------------------------------
Well...our company has a new product:
Fragmentation Controller
It *prevents* the fragmentation from happening in the first place (about
95% of new file fragmentation goes away)!!
Dan E. (Designer of Fragmentation Controller, president of the company
that get $$$ from selling it!)
(01/21/93 Siegel: On the big guy)
----------------------------------
In our case, we have 2 LAVC clusters. On both, only the boot node has the
disks, and the boot node is also the largest system (3800 with satellite 3100
and VS2000, and a 4000/200 with a satellite VS2000). DK is licensed and runs
on the boot nodes.
(02/01/93 Bruzek: A happy ending...)
-------------------------------------
Got a nice phone call from ES the other day. They said that yes, it is
an old policy of ES to license DisKeeper on the largest node of a cluster, but
that it is a still older policy to honor previous arrangements made with
customers. Here is the first "smiley-face" I've ever typed on this system:
:-)
How'd I do?
(02/17/93 McMillan: Tech Support Problem)
------------------------------------------
> Of course, with the increased CPU demands of recent versions this isn't
>really practical any more - I have a disk which makes DK V6 sit in a solid
>COM state for 6 hours before it begins processing, on _every_ _single_ _pass_.
After seeing Terry's note above, I did some investigating to see why he had
not received a response from our Technical Support people. I found that Tech
June, 1993 The DECUServe Journal Page 30
Support had been in contact with him, but didn't follow up to see that his
situation was fully handled. We "dropped the ball" on this one, but the
situation in Tech Support is being corrected to keep this from happening in the
future.
We are now in the process of working out the solution to the problem that
Terry mentioned. Terry has been in direct contact with Gary Quan, our Director
of Software Quality, to get the problem solved. Gary and Terry have both been
performing various tests and we expect to get Terry's questions answered in the
very near future. We appreciate Terry's cooperation and assistance in handling
this situation.
(02/17/93 Kennedy: Happy with new support)
-------------------------------------------
By the way, I've been very pleased at the way this is being handled now. I
have to do some more tests, but I think that ES is going to solve this for me.
(02/18/93 Campobello: What did everyone do about WSQUOTA?)
-----------------------------------------------------------
I'm about to upgrade Diskeeper to 6.0, and I'd like to revive an old point.
>The page faulting issue is due to the defragmentation process limiting itself
>to 1500 pages. This can be fixed by navigating the menus as follows:
> CM STATUS PDB MODIFY DISKEEPER TYPE DKDFG WSQUOTA
> I changed it to 5000 which fixed that problem.
Should I just raise WSQUOTA to prevent any possible problem? I don't have
any disks with anywhere near that many files, but it seems like there's little
penalty for raising WSQUOTA so why not just do it?
(02/18/93 Tillman: I don't think Terry's alone)
------------------------------------------------
Hey, Vaughn, when you fix the problem for Terry, let all of us know what's
up. My DK processes sit computable nearly 100% of the time, too.
(02/18/93 McMillan: That's Right)
----------------------------------
> Should I just raise WSQUOTA to prevent any possible problem?
Jim -
You are correct. If you have the system resources available, and don't
have a problem with the DISKEEPER server process(es) having the larger working
set(s), there is no problem increasing WSQUOTA. This is particularly useful
on disks with a large number of files.
As a point of curiosity, you should watch the Peak Working Set (use SHOW
PROCESS /ID=nn /ALL) to see if DISKEEPER is really using all of the working set
you are giving it.
June, 1993 The DECUServe Journal Page 31
(02/18/93 Thomas: Diskeeper .vs. The Others (Why?))
----------------------------------------------------
I would like to pose an open-ended question to which I have been struggling
for about a month. I realize I will surely get a pro-Diskeeper slant to the
question, and that is intentional. Seeing as there is not much of a thread
for other utilities, here goes.
Why should I scrap the defrag utility I am currently using to switch to
Diskeeper?
(02/19/93 Kennedy: Some things to look at)
-------------------------------------------
I don't know that there's any "slant" to it - the reasons I give would be
as valid for "why should I scrap Diskeeper to switch to something else?".
Given that this class of utility is supposed to be unobtrusive, it's sort
of like asking "why should I change the brand of machine room air conditioner
filters I use?" 8-)
First, you need to consider if the product does what it advertises/what you
need. Since failures in defragmenters are _very_ high profile, we can probably
assume that yours works.
Next, is it accomplishing the level of defragmentation you desire? Some
products trade time for limited defragmentation. Some can be configured. If
you need large contiguous space for file allocations, this can be an issue.
Is resource consumption reasonable? With the exception we've been
discussing, Diskeeper is a fairly light CPU load on the system, and can be
configured to reduce disk activity when there is other activity.
Is scheduling flexible? Can you run the job for user-defined intervals to
meet your needs? Can you set the job to run when the load drops below a certain
threshold for a period of time? Can you force a job to cleanly stop at (for
example) 9:00 AM, regardless of whether the "pass"/"cycle"/whatever is complete?
If you frequently reconfigure disks and/or workloads, is the program's
user interface style (menu/command line/whatever) convenient for you, with all
options easily located?
What "other things" besides defragmentation does the package provide? Can
it consolidate multi-header files to single headers? Can it extend the
INDEXF.SYS file on a dismounted disk so you don't have to back up/restore to
get more headers?
Are you comfortable with the company's licensing terms, pricing, support,
etc.? Would you realize a substantial savings if you switched vendors? Is there
a trade-in allowance? Will they support very old/very new VMS versions?
These should give you some things to consider. I believe Executive Software
still does free demos, although they haven't sent me any bingo cards lately (I
guess I finally convinced 'em that I already bought it). So, you could get a
copy and compare it with what you're currently running.
On the other hand, if you're already happy, you probably wouldn't switch.
In that case, why ask? 8-)
NOTE: The list above gives some examples. I don't know of any product that
currently provides all of these. It does give you some points to compare.
June, 1993 The DECUServe Journal Page 32
(02/19/93 Ferguson: It should be a tool you forget about -- so forget it)
--------------------------------------------------------------------------
Why switch? Interesting question. I've been asking that question in terms
of DEC DFO, and I keep coming up with this answer:
Disk defragmentation has some clear benefits (e.g. the recent DECUServe
crash was somewhat related to fragmentation).
But it also has a ton of more questionable benefits, and I personally
question the extent to which a mediocre job of defragmentation and a good job
differ in terms of performance (here I mean "mediocre" and "good" in terms of
the extent to which the disk is defragmented, not things like safety). Also,
far more knowledgable people than I have questioned whether those products that
place files by some algorithm to keep hot files more available really have
substantial impact in a real life case.
The answer I keep coming up with is: if it does a good, basic job of
defragmenting, doesn't screw up my data, does it more or less when and how I
want, and is no trouble to support, then it does not matter whose name is on
the box. The bells and whistles and neat menus and fancy displays are gimicks.
Once you have it up and running you WANT to forget it, you do not WANT to fiddle
with it so you do not really care whether one user interface is a tad more
slick.
The grass may be a bit greener on the other side of the fence, but it is
still just grass. Unless you need something substantially different, don't
bother with the expense or trouble changing FROM or TO Diskeeper.
(02/19/93 Coy: Why only one alternative?)
------------------------------------------
I agree with Linwood.
And I would add that I find the question rather strange. The question "Why
should I switch to Diskeeper" sounds like you have already made up your mind
WHAT to switch to.
If you have decided that your current defragmenter isn't doing the job, why
are you only considering Diskeeper?
(02/21/93 Thomas: That's what *I'm* trying to find out)
--------------------------------------------------------
I have been looking through the trades and through the notes here on
DECUServe with regards to defragmenters, and by a great margin, Diskeeper is
the most popular. That doesn't mean that it's the best! But when you're
looking for alternatives, you look around to find out what else is around...
As a matter of fact, when looking here on DECUServe, the majority of the
notes on OTHER packages are negative in nature and are a couple years old. This
includes the one we are currently using.
> If you have decided that your current defragmenter isn't doing the job,
> why are you only considering Diskeeper?
I used Diskeeper for a couple years and was happy with it. (That is - I
forgot it was out there, and it NEVER came up as a problem when discussing
June, 1993 The DECUServe Journal Page 33
system performance at those sites.) Another person in my group also used
Diskeeper at her old job and was very happy with it. I guess when you find
something you like, and it's something high-profile like a defragmenter, you
look for things that you know by *experience* work.
We both have mentioned that the package we use today has some problems, and
perhaps we should consider something else. So here I am trying to get some
information on making a decision like this. :-)
(02/21/93 Coy: In that case, consider DEC's Defragmenter)
----------------------------------------------------------
Ah.
> As a matter of fact, when looking here on DECUServe, the majority of the
>notes on OTHER packages are negative in nature and are a couple years old.
OK. However, you should also consider products newer than Diskeeper. Those
products will have fewer notes, for obvious reasons.
I am very happy with DEC's Defragmenter. Although it is only V1.0, I
haven't seen any problems, and it is "set it and forget it".
(02/22/93 Kennedy: Look out for other requirements)
----------------------------------------------------
We looked at this briefly. We decided against switching because the "better"
functionality required (as I recall) Rdb run-time. We got trapped with such
"tag-alongs" once before (with CDD) and I am leery of getting stuck again. Also,
Rdb r-t isn't included in new system VMS licenses, so it's another extra-cost
option.
I was also told by some V1.0 sites that resource consumption was high. If we
weren't moving away from DEC I would probably investigate it in a year or two,
just to compare it with Diskeeper.
(02/22/93 Thomas: Sounds like another reason... :-) )
--------------------------------------------------------
That's what I've heard too. That's the main reason I haven't really
considered DEC's product. Although we are looking into the possibility of
migrating our application from RMS to Rdb. But that probably won't come to
reality for a year or two...
(02/22/93 Hunt: Details on Rdb RTO requirement.)
-------------------------------------------------
Rdb is required only if you want the full functionality of the DEC File
Optimizer. As to whether the additional functionality is needed I don't know.
As to the RTO license still being included with VMS purchases it depends on
the type of license bought. It is still included in some cases. I know the
one site that has it up and running here loves it. I plan to bring it up soon.
We just upgraded Rdb so I wanted to wait till that was completed.
June, 1993 The DECUServe Journal Page 34
(02/22/93 Coy: Rdb RTO is reasonable)
--------------------------------------
On this system, if you do HELP DEFRAG you can get an idea of the "full
function" version.
Without RDB-RT, it just allows you to tell it to defragment a volume, at
various levels of defragmentation; to monitor defragmentation as it is going
on; and to check the fragmentation of a volume.
With RDB-RT, it allows you to write defragmentation "scripts", control
execution, etc.
There isn't a fancy UI.
Your needs and preferences may vary. I certainly have nothing against
Diskeeper as a product. I'm just suggesting that you might seriously consider
other alternatives.
(02/24/93 Thomas: I just *knew* it)
------------------------------------
Point taken. We'll go back to the beginning and look at all the products
that are out there, and weigh each one on functionality, features and our
requirements. (I guess that's how it's supposed to be done. :-)
It's amazing how I tried to put a "subjective" question out and STILL get
a *fair and objective* look on it. Got to hand it to DECUServe!!
Thanks!
(04/07/93 McMillan: DISKEEPER/Plus in A Clustered Environment)
---------------------------------------------------------------
Questions have been brought up recently regarding Executive Software's
licensing of DISKEEPER/Plus for a VAXcluster. I would like to answer these
questions.
The intention has always been for DISKEEPER/Plus to be licensed for the
largest CPU in the VAXcluster. The reason is that DISKEEPER/Plus is capable of
defragmenting all the disks in a cluster, thus delivering cluster-wide service
by defragmenting dozens (or hundreds) of disks. We set up our pricing based on
a fair exchange for benefits accomplished by the software. Requiring
licensing on the largest node of a cluster was the most equitable pricing
possible, and surveys found it was preferred by VAX Managers over requiring it
be licensed on all nodes.
However, this aspect of DISKEEPER/Plus sales was not completely understood
by some of the sales personnel who have worked at Executive Software over the
years. There have been some cases of DISKEEPER/Plus having been sold for a
less-than-largest node. This departure from the original intention for
DISKEEPER/Plus pricing was discovered in 1992, and in the summer of 1992 policy
was issued repeating the largest node requirement.
So, how does this effect VAX managers who bought DISKEEPER/Plus on a
less-than-largest node prior to the reissue of the largest node policy in the
summer of 1992? What happens when they want to upgrade that less-than-largest
node that they have DISKEEPER/Plus running on? The answer is that Executive
Software will deliver what was promised. If a VAX manager purchased
DISKEEPER/Plus for a less-than-largest node he can continue to defragment his
cluster from that node. We will continue to deliver support and upgrades for
less-than-largest nodes where this was the basis of the original sale.
June, 1993 The DECUServe Journal Page 35
Any new license sales of DISKEEPER/Plus for VAXclusters will follow the
existing policy and original pricing intention, i.e. largest node. If a VAX
manager who originally bought DISKEEPER/Plus for a less-than-largest node was
required to license the largest node by Executive Software, he or she has the
option of returning the DISKEEPER/Plus license to the original node of choice.
Executive Software will credit the difference in license costs toward technical
support and upgrade services. We are in the process of contacting all VAX
managers who qualify for a credit, and welcome calls from anyone who feels a
credit is due.
All present Executive Software sales and support staff understand
DISKEEPER/Plus pricing and the correct handling of past sales for
less-than-largest nodes. We will continue to give you the excellent products
and service that Executive Software is known for. If you have any questions
or comments you may call Executive Software at 1-800-829-4357.
(04/07/93 Coy: Some vendors don't require that)
------------------------------------------------
>Requiring licensing on the largest node of a cluster was the most equitable
>pricing possible, and surveys found it was preferred by VAX Managers over
>requiring it be licensed on all nodes.
Actually, I prefer having my defragmenter licensed on a cluster node that
is adequate for executing it. You would probably find, through surveys of VAX
Managers, that they would prefer the same thing, rather than the "largest node"
or "all nodes".
Thanks for the explanation.
(04/08/93 Cason: DECUServe to the rescue!)
-------------------------------------------
Thank you DECUServe! And thank you Executive Software for listening! I
recently went a few rounds with our rep about this very thing. After quoting
various postings from this thread and stating in no uncertain terms I would
either be treated fairly or take my business elsewhere, ES finally acknowledged
that there had been some inconsistencies and that I would continue to receive
the pricing structure that I had been promised.
(04/08/93 Comarow: Belongs in Silliest Thing I Heard Today)
------------------------------------------------------------
>Requiring licensing on the largest node of a cluster was the most equitable
>pricing possible, and surveys found it was preferred by VAX Managers over
>requiring it be licensed on all nodes.
This is classic. If I wasn't an ES customer, lines like this, dripping
with a certain type of deceit, would certainly drive me away.
(04/08/93 Sivia: Vendors won't drive our purchasing decisions this way)
------------------------------------------------------------------------
Right on! My site is not an ES customer and this is one of the reasons
why not. It's absurd to believe that the largest node (license point-wise, I
June, 1993 The DECUServe Journal Page 36
presume, though somebody might be @#$@#$ enough to think floorspace wise :-)
is what ought to be the determinate in price. I certainly prefer to chose my
cluster CPU(s) that does the defragging and it might well be that I decide to
devote a small, but effective, system, like a VAXserver 3100, to this job.
<<flame on>>
Vendors who insist that they will drive how we build, use and maintain
systems will continue to not get my purchasing dollars. And believe me, I
encourage our many other sites to reject this kind of vendor licensing logic
listed in .223 as much as possible, although, unfortunately, not with 100%
success in the case of Diskeeper.
<<flame off>>
(04/09/93 Osudar: just wondering...)
-------------------------------------
I hate to interrupt the ES-bashing (they *do* make such a nice target! :-)
...but the last few notes have me wondering something: Do people who have NI
(or MI) clusters defragment MSCP-served disks from a single Ethernet-connected
node? If so, doesn't that do amazing things to your network traffic load (and
to the MSCP server on the node where the disk is locally connected)? After all,
defragmentation can be very I/O intensive. Or are all these single-license
clusters using CI or DSSI only?
(04/09/93 Wing: yes, it can be painful)
----------------------------------------
I do. I have a VAX 6620 running Diskeeper and a 3100-90 in the cluster.
The 6620 defrag's disks on the 3100-90.
Network load? Yup, it can hurt the network, but I don't allow DK to run
between 7am-6pm Monday-Friday, so most of the load is done off-hours.
Much more painful is having to do backups across the network because I
don't have a tape drive on the 3100-90. That brings me to 35-50% utilization
with a de-tuned backup account!
(04/09/93 Coy: Sure. Why not?)
--------------------------------
>...but the last few notes have me wondering something: Do people who have NI
>(or MI) clusters defragment MSCP-served disks from a single Ethernet-connected
>node? If so, doesn't that do amazing things to your
Yes. I use an ethernet-connected 3100 to defrag HSC-connected disks.
Given rational operation and configuration (and throttling, etc.), it's not a
big deal.
> After all, defragmentation can be very I/O intensive.
Yes, but it usually is NOT very I/O intensive.
The basic point is that I have the choice. And if I decide that running
DFO on the 3100 is "bad", then I can buy a license for the 7610. Or I can buy
a used 780 with CI, and run the defragger there.
June, 1993 The DECUServe Journal Page 37
(04/09/93 Sivia: Absolutely. It works for us.)
------------------------------------------------
I heartily second Dale's setup as that's what I do here from time to time.
Sometimes, in the interest of overall load (I use E'net, FDDI and CI for
cluster traffic in our main cluster here, with systems supporting E'net and
FDDI oriented with most protocols on FDDI; those with CI and FDDI and E'net
split amoungst whichever node they communicate with; and the MSCP served disks
on E'net-only systems are defragged by the local host; other times it makes
sense to have one of the larger FDDI or CI-equipped systems do it. We use a
reserved-to-the-cluster E'net as well so if the load is high there, it doesn't
particularly bother me. The defragging traffic never wanders past our E'net
bridge to our building E'net backbone and out to the rest of our E'nets.
Again, the point is that we must have the flexibility to configure (and
license!) our hardware and software the way that best suits our environment(s).
P.S. Bill Mayhew reminds me that I should put on my BPSSG hat from time to
time. It's "licensing issuing coordinator" and while I'm continuing to try to
get Digital to be a bit more rational in their licensing business practices
(with current focus on what constitutes an interactive user) 3p's are not
immune from our attention. So the discussion about ES's licensing practices
are of interest to at least me both from a company standpoint as well as from
a BPSSG standpoint.
(04/09/93 Osudar: not arguing, just asking)
--------------------------------------------
I didn't mean to suggest that you shouldn't do it; I just wanted to know if
the I/O load caused any problems. (We also do backups over the Ethernet, and I
know how much of a network load that can cause.)
>Yes, but it usually is NOT very I/O intensive.
Hmmm... interesting. My experience is with another defragger, not
Diskeeper; and I've seen average DIO rates of 12-15 per second over the life of
the defrag process. I wonder if that's atypical? (I think I'll find a generic
defragger discussion somewhere else, and ask there.)
>The basic point is that I have the choice.
Absolutely -- and I agree that you *should* have the choice. I hate
companies that insist on largest-node (or even worse, cluster-wide) licensing
for products that may only run on one node -- as much as I hate CPU-power based
licensing for products that have only a single user.
(I wasn't arguing in support of ES -- heaven forbid! :-) -- I was just
interjecting a technical question in the middle of the policy discussion.)
(04/09/93 Kennedy: We're CPU bound)
------------------------------------
>...but the last few notes have me wondering something: Do people who have NI
>(or MI) clusters defragment MSCP-served disks from a single Ethernet-connected
June, 1993 The DECUServe Journal Page 38
>node? If so, doesn't that do amazing things to your network traffic load (and
>to the MSCP server on the node where the disk is locally connected)? After
>all, defragmentation can be very I/O intensive. Or are all these
>single-license clusters using CI or DSSI only?
Perhaps it's due to the problem I reported earlier here, but my Diskeeper
jobs are heavily CPU bound. I expect that I could achieve a substantial
performance improvement by "downgrading" my license from a 785 to a VS3100/38.
I don't think the ESI policy (biggest node) makes a great deal of sense,
but I'm not militant about it (since I'm one of the existing not-biggest-node
customers). If a smaller CPU can handle the job, then why not let it do that?
On the other hand, if ESI wanted to *also* offer some sort of number-of-disks
license I might buy that, if it was priced reasonably. I believe this is
implementable with LMF right now - just make a user-based license where each
disk causes a "user" to be taken.
(04/09/93 Ferguson: The problem is in being tied to CPU at all)
----------------------------------------------------------------
Let me play devil's advocate for a moment.
Suppose I have a VAX 8xxx (I do). Suppose I want Diskeeper for it (I have
it).
Suppose you have one too, but have a 4000/VLC attached to it.
Why should I pay 10x what you do for the same functionality? (Someone is
going to say "not same, since on the 8xxx it can do more disks" -- that may be
true, but I bet the 4000/VLC over the NI link can do as many disks as I have
on my 8530 (4)).
Before you jump all over me too much: I think ES's licensing is wrong also,
because it considers the power of the CPU in dealing with a function which is
really related to how many and what kind of disks you have. Actually worse-
it considers some historical power rating (my 8530 is slower than a 4000/VLC).
That is equally as wrong as considering the power of the CPU for something like
a Cobol compiler used by a fixed number of people. I have sent ES numerous
upgrades because I changed CPU's while I did not change disks at all -- what
additional value did I get from ES in that transaction? None.
But it is arguably as fair to price the largest node as it is to let you
get the same value on the same disks as I would while paying a fraction what I
do, just because you have a workstation attached.
Or consider this: At the moment I have a 4000\VLC attached to my 4000-200.
It is not clustered. If it were, I could do both its 1GB drive and the 1GB+
.3GB on the 4000-200. As it is I can only do the 4000-200 (I have not bought
a license for the 4000\VLC). And I *am* licensed to cluster them, but I choose
not to for various reasons. Now why should that matter in what I pay ES?
So I suggest we not shoot at them because they require it licensed on the
largest CPU, but because they license it by any CPU at all -- why can I not by
a "5GB" Diskeeper license, where it will defragment that much storage? Or a
"5 spindle" license where it does that many drives.
June, 1993 The DECUServe Journal Page 39
(04/09/93 Kilgallen)
--------------------
To be "fair", one should be charge according to the number of blocks moved
per hour as part of the defragmentation process. Why should someone with
relatively unfragmented disks pay the same as those whose disks are heavily
fragmented?
Personally, I believe ES has the right to charge however they want and
customers have the right to buy from one of the several other vendors of
similar products. Those who are devoted followers of ES may choose to convince
them of the error of their ways, just as some of us may try to influence a
someone larger software/hardware vendor in our discussions here.
(04/10/93 Ferguson: Good idea)
-------------------------------
Hey, I like that!
Then DECps could charge by how badly tuned your VAX was.
And security software could charge by how many security incidents it
prevented. :-)
>Personally, I believe ES has the right to charge however they want and
>customers have the right to buy from one of the several other vendors of
>similar products.
Of course they do. But if the only way we could approve of or complain
about a product was by buying it or not, DECUServe would be a pretty boring
place. :-}
(04/12/93 Whitmer: Another improvement?)
-----------------------------------------
Or perhaps charge by the measured improvement in system performance Settle
the question about whether system performance is really improved by
defragmentation as part of the license. Otherwise you may wind up with a
defragmentation algorithm that spends time moving files which really were not
much of a problem and charging you for it.
Ultimately, I think all schemes are arbitrary and can never really measure
the value derived from use of a program, but it is good to try to eliminate
obvious problems with a scheme as long as it doesn't make it too complex. I
am working on the new licensing scheme that figures in the I.Q. and typing
dexterity of the users... :^).
(04/15/93 Zimmerman: Lies, damn lies and statistics)
-----------------------------------------------------
> This is classic. If I wasn't an ES customer, lines like this, dripping
>with a certain type of deceit, would certainly drive me away.
Not only is this "dripping with a certain type of deceit" but is is also
not true. Not too long ago we were presented with the "we only license the
June, 1993 The DECUServe Journal Page 40
largest node of a cluster" line. We responded: O.K. then we don't need your
product... Guess what? The sold me Diskkeeper with the smallest node of the
cluster licensed. I our case it was not a matter of $$$ though. I had no
intention on using our largest node (of 2) for anything other than user work.
The other node (8250 vs 8550) was used mainly as a misc. processing machine
(i.e. printers etc). Diskeeper on this machine was just fine with us and I had
no intention on purchasing it for a machine that I was not going to run it on.
(04/16/93 Campbell: Cluster pricing should consider whole cluster)
-------------------------------------------------------------------
I'm not sure I see that it matters very much which CPU Diskeeper is licensed
for. The benefits (whatever they are) presumably accrue to the whole cluster,
or at least to all the CPUs sharing the disk(s). If you accept that software
pricing by CPU power is valid at all (an entirely different argument), then I
don't think ES has an unreasonable policy.
Consider a single CPU site, say with a 9000. Again assuming that CPU power
pricing is reasonable, they will pay a hefty price and presumably get lots of
benefit. If they add a MicroVAX-II (I know, it's absurd) and make a two node
cluster, do they get any less benefit if they run Diskeeper only on the
uVAX-II? Ignoring the likely performance issues on the uVAX-II, the benefit
to the 9000 is the same. Why should the price be less?
(I have no connection to ES, I'm not even a customer.)
(04/16/93 Coy: I think that's not quite what you want, either)
---------------------------------------------------------------
"Yes but..."
By your argument, if they added 5 more 9000s, they should pay 6X the
license fee, because they are getting lots _more_ benefit.
Oh, yeah -
>The benefits (whatever they are) presumably accrue to the whole cluster, or
>at least to all the CPUs sharing the disk(s). If
We also need to consider all of the other nodes across the country that
are accessing the disks via NFS.
(04/16/93 Campbell: They picked something in the middle, maybe it's not so
unfair)
----------------------------------------------------------------------------
Well, what I *want* is for them to give it away, but I can understand why
they might have different ideas :-).
>By your argument, if they added 5 more 9000s, they should pay 6X the license
>fee, because they are getting lots _more_ benefit.
Actually, that wouldn't be so unreasonable. It is certainly no more
unreasonable than the theory that the fee should based on some smallish single
June, 1993 The DECUServe Journal Page 41
machine. What ES has done is pick something in the middle.
I think what we are really running into is that CPU power pricing doesn't
work very well for software that does not get proportionately "better" when
you run it on a faster machine. Clusters and the like further muddy the
waters. There are some creative alternatives in this topic, but they are
outside the current industry practice and might be a little hard to administer.
(04/16/93 Tackett: Questions regarding MOVEFILE)
-------------------------------------------------
I recently upgraded from Diskeeper V5.0 to V6.0. I've noticed somewhere
that Diskeeper V6.0 says it can't defragment directory files when using the
MOVEFILE primitive. This isn't a documented restriction on MOVEFILE; what's
the reason behind this limitation?
Also, when using MOVEFILE, is Diskeeper able to consolidate multiheader
files as part of the normal defragmentation process? Seems like it should be
able to (but I don't know the internals involved), but my trial using MOVEFILE
with V6.0 doesn't seem to do so.
I'm not especially interested in the pros and cons of using MOVEFILE vs.
Diskeeper's proprietary method -- I'm already well informed on that score. But
has DEC issued a fix for the problem with MOVEFILE that can cause it to lose
ACL information?
(04/17/93 Hanrahan: My bogosimeter just tripped.)
--------------------------------------------------
>I've noticed somewhere that Diskeeper V6.0 says it can't defragment directory
>files when using the MOVEFILE primitive.
Something's wrong here. Directory files are always contiguous in the first
place! (In other words, this restriction shouldn't bother you much!)
(04/18/93 Hassinger)
--------------------
I wonder if the actual measure of benefit in this case is really the number
of disks, or more specifically the total capacity of the disks being compressed.
And perhaps a factor related in one way or another to the level of fragmentation
being resolved. Maintaining efficient disks at 97% full should be worth more
than keeping them defragmented at 40% full.
(04/18/93 Hanrahan: Disk fullness is no guide to the "worth" of defragmenting)
-------------------------------------------------------------------------------
I don't think so. Some disks (e.g. VMS system disks) can be very easy to
keep relatively defragged even though they're almost full. Other disks (e.g.
news item text) very difficult to defrag, but the benefits of defragging may
be fairly small.
If you have the luxury of using a separate spindle for your VMS system disk,
for example, you'll find that it isn't uncommon to go months without significant
fragmentation. Oh, there are log files and such, but these are generally small
compared to the bulk of what's on the system disk, and they tend not to be
June, 1993 The DECUServe Journal Page 42
written to nor read very often, so fragmentation doesn't hurt them. Besides,
they usually get deleted soon after being written, which leaves the disk pretty
much the way it started.
What all this is leading to is something that's been mumbled about wrt
compilers and such: Charging for actual use. e.g. Diskkeeper would write a
log file and periodically ES would "read the meter" and bill you based on how
much work it actually did. But even this fails to take into account how much
benefit you'll see from the defragging operation.
(04/19/93 Tackett: But what about relocating .DIR files?)
----------------------------------------------------------
>Something's wrong here. Directory files are always contiguous in the first
>place!
Well, I think what was meant is that Diskeeper V6.0 can't relocate
directory files using MOVEFILE, not defragment them (since they're already
contiguous anyway). I'm not sure this is a serious limitation, but I'd still
like to know why.
(04/20/93 Wing: Update?)
-------------------------
>I have to do some more tests, but I think that ES is going to solve this for
>me.
Terry, do you have an update about the CPU-bound problem with DK V6.0?
(04/20/93 Kennedy: Sorry, but no)
----------------------------------
No - to be candid I dropped the ball on this. ESI requested that I run some
tests with an additional qualifier to determine the cause of the problem, under
both V4.0 and V6.0. I did this for V6.0 but not for V4.0. However, we did decide
the problem was excessive "remapping" (the process where DK scans the files on
the disk to decide what to move). However. Gary from ESI said he thought that
the number of remaps I was seeing was excessive and he was going to see if the
algorithm could be changed to do less remapping when working on a disk like
this.
(05/05/93 McMillan: RE: MOVEFILE & .DIR files)
-----------------------------------------------
Great, we're back to a technical discussion here ;-)
>Well, I think what was meant is that Diskeeper V6.0 can't relocate directory
>files using MOVEFILE, not defragment them (since they're already contiguous
>anyway).
Galen is right about MOVING directory files as opposed to DEFRAGMENTING
them. At times it is beneficial to move a .DIR file in order to create more
contiguous free space.
June, 1993 The DECUServe Journal Page 43
As far as WHY Diskeeper doesn't move .DIR files when MOVEFILE is enabled,
it is my understanding that the MOVEFILE primitive does not allow directory
file movement. (I don't think DFO moves .DIR files at all.)
> Also, when using MOVEFILE, is Diskeeper able to consolidate multiheader
>files as part of the normal defragmentation process?
When Diskeeper is used with the MOVEFILE option enabled (or the
/USE_MOVEFILE command line qualifier), it should consolidate multi-header files
as part of the normal defragmentation process. If this is not what you are
seeing in your trials, give our Tech Support people a call - if it's a bug,
we'd like to know; if it's your test case, maybe they can help devise one that
will show multi-header consolidation is actually occurring.
I hope this helps -
Modem hangup doesn't kill process
---------------------------------
The following article is an extract from the DECUServe
Security conference topic 249. The conversation took
place on April 19, 1993. This article was submitted for
publication by Jeff Killeen, DECUServe Contributing Editor.
Ed.
By Tom Kelley, Jean-Francois Mezei, Damon Brownd
(04/19/93 Kelley)
-----------------
The situation:
9600 baud Hayes modem attached to DECserver 200-MC. (Terminal setting/PORT
setting and MODEM settings attached).
(standard 25 pin RS232 connection between modem and server port)
We'd like to use the modem for both dial out and dial in.
The problem:
When a connection to the modem is broken without a logout, the process
remains attached to the modem and is available to the next person to call in.
(This only happens with DIAL INs!)
We have checked the most important pins with a breakout box. When there
is a "legal" logout, DSR and CD cycle properly, however if the connection is
broken from the other side, they do not cycle, and the process remains active
though they modem does hangup.
This is, of course, a serious security problem.
The workaround:
June, 1993 The DECUServe Journal Page 44
When we become aware that this situation has happened, we connect to the
server and logout the port.
Certainly, we're just missing something obvious here as far as settings to
the port or modem. However, Digital has yet to figure out the answer to the
problem. Any ideas?
PORT SETTINGS:
Port 7: Server: DSVR04
Character Size: 8 Primary Speed: 19200
Flow Control: CTS Alternate Speed: 19200
Parity: None Modem Control: Enabled
Access: Dynamic Local Switch: ^L
Backwards Switch: None Name: PORT_7
Break: Local Session Limit: 4
Forwards Switch: ^^ Type: Soft
Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0
Enabled Characteristics:
Autoprompt, Dialup, Inactivity Logout, Input Flow Control,
Loss Notification, Output Flow Control, Signal Check, Verification
MODEM SETTINGS:
AT&V
ACTIVE PROFILE:
B16 B1 E1 L3 M1 N1 T Q2 V1 W0 X4 Y0 &A0 &C2 &D3 &G0 &J0 &K3 &L0 &Q5 &R0 &S0 &T4
&U0 &X0 &Y0
S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050 S08:002 S09:006
S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S30:000 S36:007 S37:009 S38:020
S43:000 S46:002 S48:007 S63:000 S82:128 S86:000 S95:000 S97:030
STORED PROFILE 0:
B16 B1 E1 L3 M1 N1 T Q2 V1 W0 X4 Y0 &A0 &C2 &D3 &G0 &J0 &K3 &L0 &Q5 &R0 &S0 &T4
S00:001 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000
S25:005 S26:001 S30:000 S36:007 S37:009 S38:020 S46:002 S48:007 S63:000 S82:128
S95:000 S97:030
STORED PROFILE 1:
B16 B1 E1 L2 M1 N1 P Q0 V1 W0 X4 Y0 &A0 &C1 &D2 &G0 &J0 &K3 &L0 &Q5 &R0 &S0 &T4
S00:000 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000
S25:005 S26:001 S30:000 S36:007 S37:009 S38:020 S46:002 S48:007 S63:000 S82:128
S95:000 S97:030
TELEPHONE NUMBERS:
&Z0= &Z1=
&Z2= &Z3=
June, 1993 The DECUServe Journal Page 45
TERMINAL SETTINGS:
Terminal: _LTA10: Device_Type: Unknown Owner: No Owner
Input: 19200 LFfill: 0 Width: 80 Parity: None
Output: 19200 CRfill: 0 Page: 24
Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
Wrap Scope No Remote Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud Hangup
No Brdcstmbx No DMA Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
Dialup No Secure server Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 VMS Style Input
(04/19/93 Mezei: MON PORT STATUS should give you better info)
--------------------------------------------------------------
There are "features" (we can't use the word "bug" when talking about
Digital products) when both MODEM SIGNALS and SIGNAL CHECK are enabled.
That might be the cause of your problem.
You may wish to do a MON PORT x STATUS
Start it BEFORE the user logs in, check the signals as the use logs in, and
check the signals as the use disconnects the phone line before logging out.
If the modem does drop CD when the line gets disconnected, then your modem
should be configured OK and you should look into the DECSERVER side. Make sure
you have the latest and greatest software relase on your decserver, especially
if it is a 200 MC one.
You would be amazed at the number of sites that do not properly configure
their stuff to kill a user's process when the line is dropped. In Canada, when
Datapac introduced 2400 baud lines, all their modem pools were configured
poorly, and OFTEN, you would get into someone else's session. (provided the
last person disconnected without logging off and that you had the same
speed/parity settings). And if you phoned the telco to tell them about the
problem, they would respond that this was impossible and that their network
was secure :-)
(04/19/93 Brownd: Take a close look at the modem settings)
-----------------------------------------------------------
I don't have any 9600 baud Hayes modems, but I would take a close look at
the modem settings highlighted below. I think you have DSR forced on and CD
dropping only momentarily on disconnect. The DECserver 200 management guide
June, 1993 The DECUServe Journal Page 46
says that CD must drop for at least 2 seconds or DSR must drop for disconnect
processing to occur.
MODEM SETTINGS:
AT&V
ACTIVE PROFILE:
B16 B1 E1 L3 M1 N1 T Q2 V1 W0 X4 Y0 &A0 &C2 &D3 &G0 &J0 &K3 &L0 &Q5 &R0 &S0 &T4
^^^ ^^^
| |
Try &C1 Try &S1
(04/19/93 Kelley: Got it! :-) )
--------------------------------
Finally! This is one of those nagging problems I've been fighting for 2
weeks off and on! (I think I have my religion right, but if I don't and end
up in Hell, Satan's gonna meet me at the door and say "We have an infinite
number of broken modems and printers for you to fix Tom...hahahah." ;-) ).
What got it for me was now 1399.6 under Hardware_help on DECUServe.
Setting &S to &S2 did the trick.
Setting &C1 seemed the thing to do, but when I was trying that last week,
I was no longer able to dial-out. I haven't tried &S1, but it seems like that
would have done the trick too.
And in case you're keeping score...
DECUServe beat DSNlink to the answer again.
Technical Information
=====================
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.
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
June, 1993 The DECUServe Journal Page 47
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.
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. Other access modes are Tymnet, PC pursuit,
and Internet.