DECUServe Journal Part 1
Sharon Frey
December, 1993
=====================
Jolly Christmas greetings to all!
You may have noticed that this issue of the DECUServe Journal is about
three times the size of past issues. DECUServe's Executive Committee and I
decided that it would be neat to distribute copies of the Journal at the
December National Event in San Francisco. I took it one step further and
decided that I would make this a very special issue and try to get the widest
possible range of topics. That's why this is a triple-issue! This issue also
includes occasional quotes, more detailed information about how to join
DECUServe and what it offers, who runs it, and also application forms.
If you browse the table of contents, I am sure that you'll see many
interesting articles. I hope that you find this issue is interesting,
informative, and impressive. If so, then when you are done, please be sure
to skim the credits at the end, just to honor the hard-working volunteers who
made this all possible. I also want to thank some people who helped me format
and copy 1200 diskettes in 5 days: Bruce Guthrie, J. Lee Eaton-Maxwell, and
Michael Ferranti!
Well, on to the fun...
Sharon Frey
DECUServe Journal Editor
fr...@eisner.decus.org
Table of Contents
-----------------
Editor's Greeting ..................................... 1
Credits to DECUServe Volunteers ....................... 103
Technical Information ................................. 105
DECUS Application Form ................................ 107
DECUServe Application Form ............................ 108
Articles
Datatrieve V6.1 upgrade and Alpha Datatrieve ....... 2
How does working for DECUS benefit my company? ..... 6
What will tune a Rdb database? ..................... 15
Cable Testers ...................................... 25
Pocket guide for email addresses? .................. 29
Getting Invalid Service & breakin msgs ............. 49
Macintosh network backups? ......................... 53
How to do trusted subsystems in a network? ......... 57
Development Environment for C Coding? .............. 65
San Francisco Restaurant Guide ..................... 69
UNIX-like system differences? ...................... 74
Running out of headers on a disk ................... 78
DCLTABLES problem? ................................. 85
New VMS file system? ............................... 88
File system questions .............................. 96
December, 1993 The DECUServe Journal Page: 2
Datatrieve V6.1 upgrade and Alpha Datatrieve
--------------------------------------------
This article is an extract of the DECUServe 4GLS_and_Query_Tools
conference topic 188. This discussion occurred between
September 22, 1993 and September 29, 1993.
By Carl Friedberg, Bill Wood, Al Hunt, Dale Coy, Chris Wool
(09/22/93 Friedberg)
--------------------
This is being posted to Colorado Support Center and DECUSERVE/4GL
conference.
Recently, we received the September software CD-ROMs for both VAX and Alpha,
and each contained new versions of Datatrieve, CDD-PLUS, and RdB.
We use Datatrieve extensively on the VAX, and are currently running DTR 6.0,
CDD/Repo 5.1 and RdB 4.2.
Reading the DTR release notes, it appears that many of the problems we
encountered on DTR 6.0 have been addressed. Thank you. However, we remain
extremely concerned about the difficulty of taking a production system and
simultaneously upgrading 3 products of this complexity. We wish to do some
testing, and it occurred to us that perhaps Datatrieve 6.1 is similar enough
(as to features, bugs, etc.) that testing on the Alpha would suffice to
validate that version for VAX as well.
QUESTION 1 Is that assumption reasonable?
QUESTION 2 Has anyone tried this, and if so, what advice do you have for us?
QUESTION 3 Where can I find a list of differences between the current VAX and
Alpha versions of DTR (and of relevant differences of CDD/Repo and
RdB RTO)?
Our Environment:
3-node VMScluster (4000-300,4000-100,3000-400S)
5 shadow sets, including the system disk (which has RdB/CDD files)
All VAX disks are RF73 (17 total, 7 unshadowed)
Alpha has one SCSI disk (system disk RZ26) and SCSI CD-ROM.
Lots of BASIC programs
Lots of DTR procedures
ONLY DMU dictionary in use
NO use of RdB except as required by CDD/repo, at this time
QUESTION 4 Is there any reason to switch from DMU to CDO yet?
QUESTION 5 Does CDO support EVERYTHING that DMU did?
QUESTION 6 Can BASIC and DTR share this CDO (we use lots of arrays in
BASIC, so this is a non-trivial question). [This is obviously
not presently an Alpha migration question, since BASIC is not
yet a product on the Alpha].
December, 1993 The DECUServe Journal Page: 3
TESTING STRATEGY
GOAL: to determine that representative DTR procedures functions correctly on
the Alpha.
RESTRICTIONS: no shadowing on Alpha, so will have to find DTR procedures that do
not require production datasets (all of these are shadowed), or that can be
made to work correctly on a small sample of data.
1. Create a new directory structure on a non-shadowed disk. Shutdown DTR,
CDD, RdB, and copy over all the following directories using BACKUP from
the SYSTEM account:
CDD$COMPATIBILITY DISK_COMMON:[VMS$COMMON.CDDPLUS]
CDD$TEMPLATE DISK_COMMON:[VMS$COMMON.CDD$TEMPLATE]
CDD$TEMPLATEDB DISK_COMMON:[VMS$COMMON.CDD$TEMPLATEDB]
CDD$EXTENSIONS DISK_COMMON:[VMS$COMMON.CDD_EXTENSIONS]
plus DISK_COMMON:[VMS$COMMON.SYSEXE]CDD.DIC;
QUESTION 7 - are there any gotcha's here when using BACKUP (ie. will /BY_OWN
with SYSPRV privielge be sufficient, or is BYPASS necessary, etc)
Modify CDDSTRTUP.COM to update the CDD logicals to point to the new location.
2. Reboot the cluster. (Pray).
3. Continue production work using the new location.
Naturally, since this is a non-shadowed device, we want to do frequent backups
to a shadowed device. What needs to be backed up aside from the files listed
above? I assume that BACKUP/IMAGE with RdB, DTR, and CDD/REPO stopped wil be
adequate.
QUESTION 8 - what is the best way to do this backup (if DMU only;
if some DMU and some CDO; and if CDO only).
4. Install MULTIVERSION RdB 5.1 on the Alpha, and CDD/REPO 5.3.
QUESTION 9 - does the installation of CDD/REPO 5.3 scrozz the CDD dictionary
files and directories for the VAX cluster? (Scrozz is a technical
term defined by Keith Walls).
QUESTION 10 - Is this sharing possible?
QUESTION 11 - Am I on the right track here? or is this possible?
5. Install DTR 6.1 on the Alpha.
6. Test until all bugs in new DTR have been found and fixed -).
December, 1993 The DECUServe Journal Page: 4
MIGRATION STRATEGY
After testing has completed successfully, we can upgrade the VAX nodes
1. Shutdown RdB, CDD, DTR on cluster
2. Install new version on VAX system disk (single-version RdB 5.1)
3. Install single-version RdB 5.1 on Alpha
4. Reboot cluster
If the proposed strategy will not work because CDD 5.1 and 5.3 use different
formats, or for any other reason, then I assume we will have to create a
private (non-clustered) "vision" of RdB, CDD, etc., for the Alpha. Is that
possible? If not, how should we do this testing? Take Alpha out of cluster
and use DECnet?
A final request: if you are reading this on DECUSERVE, and you use
Datatrieve in production, please post a reply giving the following information:
Current version of DTR, CDD, RdB in use at your site
Are you using CDO or DMU (elaborate as you like)
Are you using RdB for other purpose besides CDD? Multiversion RdB?
Are you running an Alpha in your cluster? If so, please answer
the above questions separately for VAX and Alpha.
Thanks.
(09/22/93 Wood: Sounds like fun.)
----------------------------------
We've stayed with the version of DTR before V6.0, CDD V4.2 and Rdb V4.1.
We are only using CDO where DMU doesn't work, like defining records and
fields for programs working with Rdb. We use DMU as much as possible for DTR,
Basic programs not useing Rdb, etc. (Sometimes DTR will put things on the CDO
side if the dictionary is not specified correctly.) If DMU is meeting your
needs I can see no benefit to changing to CDO, and plenty of hassles including
performance degradation and much greater probability of dictionary corruption.
Note that proper backups of a CDO dictionary, including CDD$COMPATIBILITY,
*require* Rdb as well as VMS backups unless you can *guarantee* that the
dictionary is quiescent
We make very extensive use of Rdb for many applications. We have used
multiversion on our testing cluster, but have not used it in production yet.
We are likely to install V5.1 multiversion on at least one production cluster
later this year.
We are not bringing in our first Alpha/VMS box until disk shadowing is
working. Let us know what you find.
Also, I have lots of experience with the CDD support team at CSC. Drop me
an E-mail and let me know who is responding to this and how they're doing if
you get a chance.
(09/23/93 Hunt: DTR V6.1 may have a bug)
-----------------------------------------
I believe there is a bug with DTR V6.1 and Rdb. There was a notice out not
to install DTR V6.1. I haven't heard of the problem being corrected yet.
December, 1993 The DECUServe Journal Page: 5
(09/23/93 Coy: I don't recall any recent notices)
--------------------------------------------------
Are you saying that both DTR and Rdb have a bug? Or just one?
When was the notice published?
(09/24/93 Wool: The problem is DATATRIEVE V6.1)
------------------------------------------------
The bug is with DATATRIEVE V6.1 - Certain types of MODIFY statements will
change data that they aren't supposed to.
We received a DSNlink FLASH message in early July. The message said that
the problem is listed in the DATATRIEVE and RDBVMS databases of DSNlink.
(09/24/93 Coy: Oh - THAT article)
----------------------------------
Ah - yes, early July. I finally found it, and it turns out that it's only
in the RDB database, not in the Datatrieve database.
(09/29/93 Friedberg: how I installed 6.1 for testing on AXP)
-------------------------------------------------------------
This is what I did, after extensive communications with the CSC:
I gave up on trying to share anything.
Instead, I installed RDB5.1(single version), CDD5.3 and DTR6.1 on the AXP,
and copied over the CDD.DIC (we have ONLY DMU in use!!!) to the AXP disk. Thus,
CDD$DICTIONARY on the AXP points to the AXP system disk, and on the VAX,
points to the VAX system disk.
I was able to get this to work (had to install FMS RTO of course). I now
can get a DTR prompt, and have run some simple procedures, it looks OK so far.
One minor problem, see next note
(09/29/93 Friedberg: NO CDDV on AXP (buy a VAX))
-------------------------------------------------
After moving (with BACKUP) the CDD.DIC file over to the AXP, I went to run
CDDV on it (you know -- VERIFY, maybe FIX, then COMPRESS).
Well, there is no CDDV.
I wrote a message to my friendly CSC, and guess what? DEC found out that
they couldn't VEST it (a privileged image), and dind't have resources to
rewrite it.
Therefore, the solution is to run CDDV on a VAX... -)
Please feel free to send comments about thsi to DSIN if you are a supported
Datatrieve customer on the AXP (are there any others)?
We requested an SPR, got an LOR instead...
December, 1993 The DECUServe Journal Page: 6
"I may be very vocal and may express many
Jean-Francois Mezei opinions, but I would like to express my
Quoted on 08/31/93 in appreciation to DECUServe. We often take dial-up
DECUServe_Forum 373 systems for granted. Just dial the number, enter
the username and viola. Right? However, I think
that DECUServe deserves a big prize for providing
stable, consistent, and professional quality
system management that allows many users to access
its resources. I have recently had access to
other systems and came to realise that DECUServe
WORKS, and it works well. Modem problems are
few, and any report is taken seriously. There is
constant communication between XCOM, the system
management, and the users, and we have input on
where DECUServe is going. While other systems may
have paid staff to manage the system, I have found
that DECUserve is much more responsive and offers
a much higher quality of service than the others.
And DECUserve is run by volunteers!!! ... For all
the improvements that are made to DECUserve, there
are very few instances where the availability of
the system was jeopardized because of changes to
the system. I think that this reflects very well
on the folks who manage the system."
How does working for DECUS benefit my company?
----------------------------------------------
The following article is an extract of the Board_Public
conference topic 108, which is shared between DCS (a
private BBS system for DECUS leadership) and DECUServe.
The discussion occurred between September 10, 1993 and
October 20, 1993.
By Dale Coy, Bill Mayhew, Bob Hassinger, Jane Furze, Mary Margaret McCormick,
Jeff Killeen, Bret Wortman, Linwood Ferguson, Bill Wood, Laurie Maytrott,
Rick Carter, Lynda Peach, Clyde Poole, Brian Breton, Karen Kuchenbrodk,
Douglas Brantley, Mike Durkin,
(09/10/93 Coy)
--------------
[This is the best place I could think of to put this question]
I need some help that might also help other DECUS "Leadership".
I intend to go to the September 17-19 C&IP meeting. One of those days is
a Friday, of course.
Yesterday, my boss said "Are you planning to take vacation to go to that
meeting?". And after I said "I hadn't planned on it", he asked me "Tell me
how this meeting will benefit our corporation?"
December, 1993 The DECUServe Journal Page: 7
[Note: He understands and supports and attends DECUS Symposia, so it's not
the question you might have suspected].
I tried several approaches.
1. All of the stuff I remember from the "Why attend Symposium" stuff.
Professional contacts, exposure, training, (and leadership experience),
etc. The response to that was essentially "you can get all of that from
Symposium, etc.".
2. My participation benefits all of our corporation members who are DECUS
members. The response was essentially "If you don't do it, won't
somebody else do it?" (Of course, the answer is yes).
3. I pointed out that a large number of other companies support this as
professional activities of benefit to the company. The response was that
what any OTHER company does is immaterial to what our company does.
So, can I have your ideas on how to answer the question:
How does participation in DECUS leadership directly benefit my/your
company? (Enough to justify a day or two away from work).
(09/10/93 Mayhew)
-----------------
IMO you *don't* get much "leadership experience" at Symposium. There is
too much "content stuff" to get much "leadership stuff" out of it. (Note that
these days, I go almost exclusively for leadership stuff, not content stuff...
but what I'm saying is that it can be very difficult to get much
leadership-stuff bang-for-the-buck because it's not concentrated in time
during the week.)
IMO you get much more "leadership experience" out of doing something like
playing a management role on DECUServe, and attending the C&IP meeting is just
part of playing that role (whether DECUS views it as a mandatory part or not,
it is, I think, key to maximizing the leadership experience benefit that you
take away).
(09/10/93 Coy: I didn't say that quite right)
----------------------------------------------
Sorry - I didn't state that clearly. I tried using the _applicable_ things
that are claimed to be Symposium benefits, as _also_ being benefits of
participation in DECUS Leadership.
None of those (including the "leadership experience" aspect of being in
DECUS Leadership) were perceived as being of direct benefit to our company.
[Of course, I am not being groomed for a management role]
As a footnote - my "day off" _is_ being supported by my boss, because it's
"the right thing to do" - not because of any perceived benefit to the company.
But now that he has raised the question, I think it's an interesting (and
legitimate) one.
December, 1993 The DECUServe Journal Page: 8
(09/10/93 Hassinger: Real bottom line: "Because I want to")
------------------------------------------------------------
(09/10/93 Furze: Involvement give company visibility)
------------------------------------------------------
What does your company do? Does the added visibility aid your company's
image.
When I attended my first symposium, I was working for the Advanced R&D Div.
of a large corporation. My general manager prided himself in employing the
cream of the crop - or at least that's how he sold us to the rest of the
corporation. To support this idea, he encouraged all of us to be actively
involved in professional organizations and standards organizations. He
participated in 3 international standards groups himself. Before I left for
St. Louis he told me "I'll send you to 1 symposium incognito. If you ever plan
to attend another, I expect to see your name and the company's name in print.
I want to see you presenting papers, chairing sessions, chairing committees,
participating in leadership, whatever it takes."
When I questioned what I could possibly know that would be worth presenting
a paper on his response was something like, "You might be suprised. Besides,
most of the competition will never hear what you have to say. The people who
are attracted by names in print usually look no further than to see the topic
and the company name, but THOSE ARE THE PEOPLE WHO ARE MAKING THE DESICIONS
ABOUT SPENDING MONEY."
In my current position with a different company, I justify my continued
involvement as on-going leadership training. The current trend is for
corporations to promote leaders instead of managers (administrators).
Successful leaders require strong technical skills combined with strong people
skills and moderate administrative skills. What better place to learn patience
and motivational skills that in working with a group of creative, highly
opinionated volunteers?
I use my DECUS-learned skills daily. Whenever my boss comments on a
technique that he considered especially effective, I point out when & how I
learned that skill through participation in DECUS leadership.
(09/10/93 McCormick: Stress the contacts)
------------------------------------------
Well, what do YOU think you get out of such a meeting that could be helpful
to your employer?
If I had to justify (to anyone other than myself), I would stress the people
angle: This is a highly skilled, extremely knowledgeable set of professionals
in the computer industry. Smaller meetings, away from the stress of the
symposium experience, tend to foster more one-on-one communication
opportunities. Even if you don't find a specific piece of technical
information, you are making contacts.
Will this justify your participation without a vacation day to your boss?
Unlikely. Is it true? Yes. It's like playing the lottery: You don't know
when (or IF) you'll win, but the more you play, the better your odds are.
BTW: When I had to justify my participation to an employer, I went in with
an *annual* statement (ten days for Symposia, six days for scheduling meetings,
n days for this, etc.). They bought off on the whole package. I doubt if many
December, 1993 The DECUServe Journal Page: 9
employers would do that now for the number of days I required then due to
multiple hats -- but once it was budgeted for the year, it didn't go away, so
I didn't have to go begging every time a meeting came up.
(09/10/93 Killeen: Where else do you get to experiment on someone else's dime?)
--------------------------------------------------------------------------------
Taking it from the standpoint of the fact you are on the senior leadership
team of a product unit - being a DECUS volunteer does place you in a situation
where you have to deal with a real business case and solve real business
problems. If I was your employer I would value my technical folks getting
this kind of experience by risking someone else's dime.
Taking it from the standpoint of contacts - I often talk about technical
issues over dinner at these volunteer meetings. So if your employer understands
the value of relationships one builds at Symposia think of these meetings as
mini Symposia type experiences at contact building through out the year -
again on some else's dime.
(09/10/93 Wortman: My reasons.... )
------------------------------------
Well, since the boss gave me four and a half days off during a two-week
period for DECUS stuff....
o Ditto the visibility issue. Feeling that my achievements (hah!) in
the organization will reflect well on my employer is a biggie.
o Contacts, contacts, contacts. While Bob's aware that I spend time
on DECUServe getting questions answered, he's also aware that some of
my more sticky problems have been solved by personal phone calls with
people I knew only through DECUS "leadership" activities.
o Training. I'm a propellor-head, sort of. There isn't much
management training in desigining databases and application systems. I
get that here, and the cost to my company is minimal.
I'll put the question to the boss on Monday and see if he has any other
reasons he can articulate. :-)
(09/11/93 Ferguson: There are a few direct cost savings from leadership)
-------------------------------------------------------------------------
There's the minor but significant issue that, because of the nature of
your position, you get access to DECUServe and the internet without your
company having to pick up the communication costs.
Other leaders save direct costs by things like fee waived symposia
attentence.
While I think these are minor compared to building a network of resources
you can use for questions, etc., they might be more significant to a somewhat
out of touch manager (whether yours is or is not is another question).
December, 1993 The DECUServe Journal Page: 10
(09/11/93 Wood: Who should do the work - and leadership?)
----------------------------------------------------------
> DECUS members. The response was essentially "If you don't do it, won't
> somebody else do it?" (Of course, the answer is yes).
Are you sure about the "of course"? While this may be true for this
meeting, I wonder whether it is true for your overall DECUS activity. I have
similar problems justifying DECUS investment by my employer. If all employers
share the "how will it benifit our corporation" attitude who will provide the
DECUS products?
(09/13/93 Maytrott: Influence, "special" info, contacts!)
----------------------------------------------------------
In DECUS leadership, we often have a vote (or if not a vote, at least
influence a vote) on how things are done in DECUS. Items that are voted on
(since they involve DECUS policies and products) will have a direct effect on
one's employer if that employer is a consumer of DECUS products.
I often take DECUS issues that are being discussed to my boss and ask him
what he thinks if it's something that affects a service or product that we use.
There may be discussion on DCS where the symposia committee (or pick a
unit/product) is doing a "what do you guys think" informal survey on possible
changes. I'll let my boss know and get some input from him before I post an
opinion (fortunately, we almost always agree). Thus, he feels like through me
he has an avenue to affect DECUS to better serve our needs. He feels our LUG
is one of the most directly beneficial DECUS "products" to our organization,
and so he appreciates the fact that I'm looking out for the LUG's interests by
participating in the NLC. Attending a DECUS leadership meeting that overlaps
work time? There's almost always something to be discussed that will affect a
DECUS product which we consume.
I use "insider" information (not stuff the public can't know, just stuff to
which they may not always have timely access... often, just stuff I can find
out sooner) to help with his "buy" decisions and to make him feel like he's
getting "special" information. Someone forwarded me a tentative session lineup
on a hot topic for San Francisco. I had asked my boss if he was going to San
Francisco and he told me he wasn't. After showing him the tentative session
lineup on that one topic (which happens to be very appropriate and timely for
us), he's now very seriously considering SF.
I've often used my national network of contacts to obtain public domain
programs, information, how-to's, etc. for stuff he's wanted, and of course,
always let him know that it's a DECUS connection that made it possible. This
has been well driven home. He often starts out a request with "Find out if
any of your DECUS buddies...." And it's always very effective if I bring
this info back after a face-to-face with other DECUS leaders from one of those
meetings that overlapped work time!
(09/13/93 Carter: Not much help for first one, but leverage for 2nd one)
-------------------------------------------------------------------------
I first started in leadership in the Networks SIG. My boss at the time
asked some questions similar to yours, and similarly wasn't very convinced, but
sent me also because 'it was the right thing to do'.
December, 1993 The DECUServe Journal Page: 11
To make the NEXT meeting more palatable, I went armed with a few technical
and futures questions that I would try to ask people on the SIG (I didn't know
much about networks, but someone on the steering committee was a colleague and
very persuasive about signing people up). I was able to speed up async.
DECnet a bit and get a good explanation as to why I couldn't speed it up
further. I made sure my boss knew where that info. came from.
Also, I found that in the suppertime small-talk, I got some other useful
tidbits I hadn't set out to get. I implemented or discussed these, as
appropriate, and once again ensured that my boss knew where it had come from
as asides "oh, yeah, someone at the Woods meeting told me if you configure
this like...." Bottom line -- I got to go to all future ones without much
question as long as they took only one work day for the weekend.
(09/13/93 McCormick)
--------------------
Why don't you download this topic (perhaps with an intermediate editing
step, depending on your boss) and give it to him?
(09/13/93 Peach: It's important to all concerned)
--------------------------------------------------
When I went to work for Tybrin at Eglin AFB I was ready to accept that my
DECUS involvement would probably have to be less -- but money talked. I was
getting a job that didn't require me to be on the road constantly.
YET -- what happened was this:
My company supports my DECUS involvement. I was already giving sessions.
I was already in "senior" DECUS leadership. My term as meeting coordinator of
the Fall 1991 symposium actually "meant" something. They want that involvement
now with THEIR name as my employer.
And Eglin supports my activity because they like being able to get
information from DECUS via my contacts.
Dale has heard me say this before -- but the key, imho, is never ever ever
take credit for a piece of information that you got via DECUS. Whether that
is via a symposium, a LUG meeting, a phone call between friends, or DECUServe.
The notes prior to this are excellent. Many *good* points. Well stated.
(09/13/93 Coy: Good points)
----------------------------
> Why don't you download this topic (perhaps with an intermediate editing
> step, depending on your bos) and give it to him?
I intend to do so. And I'll feed back his comments, if any. But I also
think it may be valuable for others.
(09/14/93 Poole: DECUS is Responsible for My having a Job)
-----------------------------------------------------------
After reading the preceeding notes in this stream I decided to add my
experience.
December, 1993 The DECUServe Journal Page: 12
About 8 months ago I started a new job after being (voluntarily)
unemployeed for about 4 months. One of the key factors in my getting and being
successful at this new job was directly the result of my experience in DECUS
senior leadership. Today I am mostly a technology and strategic planner for
the state of Texas. I am responsible for the State Strategic Plan for
Information Resources Managment and the State Technology Assessment Center.
I learned to do REAL strategic planning from my years on the Management Council
and Board of Directors. I learned how to manage people that don't really work
for me from those same years. Without that experience, I would not be as
effective in my work today and I expect that the experience I am gaining now
in "change management" inside DECUS will serve me well in my professional life.
DECUS allows us all to do things that are somewhat out of line with our
normal daily work and thereby encourages us to grow professionally. DECUS
allows us to fail while we are doing these things without threatening our
monthly cash flow. This too encourages us to grow.
I am careful to tell my boss EVERY time I do something that I learned from
either being a DECUS leader or from a DECUS related source. She understands
what that means and supports the MANY MANY hours that I spend working for DECUS.
(09/16/93 Breton)
-----------------
Here's a differenet approach in line with a few others...
Contact and visibility for you and your company with Digital Leadership.
There are members of the BoD that call me directly. Symposia Committee
members SIG Chairs etc. Joe average Symposia attendee gets to talk to me only
during Symposia week.
At the Cambridge meeting you got to hear from and speak with the Digital VP
of Engineering, Bill Strecker. In Las Vegas the SIG Chairs got to have breakfast
and chat with then COO Jack Smith. Annually the VMS SIG has a Maynard area
woods meeting and on one of the days they come into DEC and meet with Bill
Demmer, VP Computer Systems Group and his staff. Another time it was with the
VMS Operating Systems Management team.
You don't get these kinds of contacts just from Symposia. Is it worth it to
your boss for you to get to know a few key Digital folks that you can call or
Email any time?
(09/16/93 Kuchenbrodk: Proactive)
----------------------------------
All suggestions here are good. I offer only that every time I return from
a DECUS-related event, I draft my boss a memo. This outlines what I learned
or did of direct benefit to my area, to the region, and to the company as a
whole. Next paragraphs are indirect benefits.
He loves it so much that he forwards it to higher levels and it is
discussed positively at branch and national managers meetings. As a result,
more people from the company are getting involved nationwide. To my thinking,
this is goodness.
Also, he is happy that I do this on my own before he has to ask. It's hard
to get home after a weekend meeting and have this on his desk early Monday
morning, but the effort is working very well for me.
December, 1993 The DECUServe Journal Page: 13
(09/17/93 Killeen)
------------------
Dale - have you run any these by your powers that be?
(09/17/93 Carter: May we learn from your process?)
---------------------------------------------------
> He loves it so much that he forwards it to higher levels and
> it is discussed positively at branch and national managers meetings.
Do you have an easy way of posting a sample? Sounds like you can write
a heckuva memo!
(09/17/93 Coy: not yet)
------------------------
Jeff, I haven't run any of the past my boss yet - but I will.
(09/28/93 Brantley: DECUS Experience)
--------------------------------------
Expanding my knowledge of Information Technology is part of my job. I read
the industry magazines. I try to find the trends. I attempt to see where
others have failed so we do not follow the same track.
Knowing more about the direction of Digital is very important. We have
been a Digital shop for 21 years. We have a Digital bias.
I invest a considerable amount of my free time doing DECUS things.
I believe my personal investment in DECUS is a good investment.
Why...
* Peer Networking
* Contacts After The Meeting Is Completed
* Product Evaluation and Experiences
* Industry Directions
* Connections Within Digital
* Reality Checks On Our Direction
I find that the discussions we have at any leadership meeting leads to
some type of learning experience. The dinner/lunch/breakfast/break time
discussions lead to expanded conversations in the suite or later via e-mail.
(09/28/93 McCormick: Feedback?)
--------------------------------
Dale, did you get to attend the meeting? What did you say to your boss?
Did his position change as a result?
December, 1993 The DECUServe Journal Page: 14
(09/28/93 Coy: That is the question, isn't it?)
------------------------------------------------
Yes.
Nothing additional, yet - as I already said, he had agreed to let me
attend the meeting.
I'll let you know if any of this is of significance to him.
(10/06/93 Coy: Yes, thanks)
----------------------------
>Dale - have you run any these by your powers that be?
Yes, and my boss was quite appreciative. He has a printed copy that he
is saving for reference.
Although I had covered most of the points made here by others, the
differences in the way things were said were quite valuable.
I hope this topic will prove useful to others in the future.
(10/08/93 Durkin: Pointer to other sources)
--------------------------------------------
Took me a while, but I did did up a couple of articles which appeared in
DECUS publications a few years back. The reason I've kept these somewhat handy,
okay - so it took me a while to take care of some real work, is in case my
manager should ever change in the future. I might have to go through this all
over again. ;-) While they both are geared more towards the topic matter of how
to justify attendance at symposium, each presents points which are somewhat
relevant to your volunteer time.
The first article appeared in the Q1 July 1989 DECUScope. It is titled
"Sending your people to DECUS - The Return On Investment" and was penned by
G. Beau Williamson. This one is very good since it illustrates some
cost/benefit scenarios and we know how the bean counters love this stuff. It is
three pages long in two column format, probably Tex, and would be difficult to
reproduce here. I could copy and Fax to you Dale if you're interested ? If
others are similarly interested, perhaps we can obtain the original text from
someone involved with DECUScope production ?
The other article appeared in the DECUS SIG Newsletters V2 #7 dated March
1987. It is titled "Symposia Justification Package" and was submitted by the
OA SIG. There is no specific authorship cited but one could hazard an educated
guess and give credit to the newsletter editor who was Therese M LeBlanc. It
presents nine main points, and also provided an overview, roadmap if you will,
of the upcoming OA SIG activities, Sessions and Pre-Symposia Seminars as part
of the article. I actually began to transcribe the article in the next note,
but lost it due to a keystroke error on my part. I'll if I can't get it
re-keyed in the next week or so. Gotta run for now.
(10/12/93 Peach: Probable authors)
-----------------------------------
If I remember correctly, the article in the OA SIG newsletter was
co-authored by Joe Whatley (OA SIG Chair) and Ralph Bradshaw (OA SIG Vice
Chair).
December, 1993 The DECUServe Journal Page: 15
I remember both SIG newletter articles. They are excellent.
What will tune a Rdb database?
------------------------------
The following article is an extract of the DECUServe Databases
conference topic 308. This discussion occurred between
June 21, 1993 and June 24, 1993.
By Arthur Cochrane, Keith Hare, Linwood Ferguson, Simon Maufe, Dale Coy,
Scott Harper-Sotan, Bill Wood, Larry Kilgallen
(06/21/93 Cochrane)
-------------------
What if any products are available for tuning Rdb databases?
(06/21/93 Hare: Don't Trust Tools - Understand the Application)
----------------------------------------------------------------
The primary product that will allegedly tune an Rdb database is RdbExpert.
RdbExpert analyzes data collected by DECtrace and attempts to make that
database run better.
However, it has several problems.
1. The definition needed for RdbExpert to be accurate is incredibly detailed.
Essentially, you need to enter lots of information on cardinality and
volatilities at the column level. Otherwise, RdbExpert will make some
completely bogus recommendations.
2. It tries to solve every problem, instead of identifying the top 3-4
performance problems.
3. It may be able to make a query faster, but it can't make a dumb query smart.
I've reviewed applications that were doing the same query multiple times, or
just doing stupid queries. In my experience, this is where a lot of the
performance problems are.
To tune an Rdb application you need to understand:
- Where your performance problems are -- Instrument the application up front
with DECtrace so you can find this.
- Where the important business transactions are -- This means you need to
understand your application
- What your transactions are -- you can't tune if you don't know what the code
does. Also, you need to know what you application does.
- What your database is -- you need to start off with a good database design
December, 1993 The DECUServe Journal Page: 16
If you start off an application good database design, good application
design, and good transaction design, then focus on performance throughout
design, implementation , and testing, you will get much better results than if
you wait to focus on performance until test or production.
(06/21/93 Ferguson: I was going to buy it this summer)
-------------------------------------------------------
There is a product from FREND (sorry, I pitched their literature, but I
think it is mentioned somewhere around here). It looked to me to be a poor
man's RdbExpert, with a DECtrace-like product available "soon".
Keith (or others): your comments were not encouraging in terms of RdbExpert.
I agree with everything you said about understanding your queries, workload,
etc., but given a reasonable design and application, would you choose Rdb
Expert/DECtrace to help with physical design, or would you do it by hand?
More to the point, if you were me and not an expert specializing in Rdb
tuning (etc), would you use it?
Most importantly to me: if you had the same application replicated at many
sites of vastly varying size, would Rdb Expert be a good tool for varying the
physical design based on size and workload, rather than (not practical for us)
having someone really be an expert on each site). I had an expectation
(perhaps a fantasy) that I could just run a week's of monitoring at each site
once every few months, and let RdbExpert rebuild the database's physical
structure to match the workload and table sizes (subject to some sanity
checking).
(06/21/93 Maufe)
----------------
I'm not Keith, and I support Rdbexpert so I have vested interest 8-)
DECtrace and Rdbexpert together will do a bang-up job of making your life
easier. I don't think the tools have any value for somebody not used to tuning
a database, and who cannot read the reports Rdbexpert generates.
First DECtrace captures all the requests fired at the database. Once this
is imported into Rdbexpert, then exported as SQL, you can do a great job of
seeing how the database is being used. Saves many many hours of effort and
talking to users (and being given the wrong info).
Secondly Rdbexpert can generate an audit report that explains its suggested
design and why it decided to use has over sorted over index. Again its a
helping hand for busy DBA.
I would never recommend anyone taking an RDBEXPERT generated design as
gospel and throwing it the database. I would always take the design as one
input to the redesign process.
PS I have a "Day in the life of DECtrace and Rdbexpert" document, explains
all the new users bumps in getting the products working, any interest in
posting it here?
(06/21/93 Harper-Sotan: A 1st cut at classification)
-----------------------------------------------------
I've had experiences with both products (own RdbExpert/DECtrace, evaluated
FrEnd). I've also talked to a number of people who have used each product.
Here is how I would break down appropriate uses of these tools. I've also
December, 1993 The DECUServe Journal Page: 17
recently seen a 3rd product on the market (in DB Prog & Design or Rdb World) -
can't remember the name though.
Mushroom (knows absolutely nothing about Rdb or DB design) - Design by hand
is probably out of the question - too high a probability of making a really
bad move. RdbExpert is also too much of a tool for these folks. The FrEnd
product is probably a good choice since it seems to make a passable first cut
at a multi-file design with reasonable page sizes and added indexes.
Beginner (knows a little about Rdb and DB design) - Design by hand should
be limited to a small subset of Rdb features. RdbExpert is, again, a lot of
work if this person can't make heads or tails of the suggested design. I say
suggested design, because as Keith said, RdbExpert can make some seemingly
brain damaged suggestions, and you may need to compensate for this. To
compensate, you need to know more than the average beginner (the "brain
damaged" crack is not really fair because ther are facets of any application
that just cannot be represented yet by numbers and existing workloads alone).
Again, FrEnd may not be a bad choice for this consumer since there is a
"suggestion" facility that the beginner can use to infulence FrEnds design.
Advanced (Has a lot of experience and knowledge with Rdb features and
traps) Tuning by hand, though time consuming, will probably yield very good
results. RdbExpert is an option since this person has enough experience to
spot where the sugested design is incorrect and make the necessary changes.
RdbExpert though, like hand tuning, is till time consuming and currently isn't
convenient for iterative tuning sessions. FrEnd will probably not please this
person.
Guru (knows the ins and outs of Rdb very well and can talk expertly on
them) Tuning by hand will probably yeild the best results from this person.
Will have no patience for RdbExpert (although the DECtrace workloads and query
frequencies obtained thusly will be attractive). FrEnd would be a toy to this
person.
I'm hoping to get others thoughts on this since I think it's important to
let tool vendors know where their products fit and where they need some
improvement.
(06/21/93 Coy: All explanations welcome)
-----------------------------------------
>PS I have a "Day in the life of DECtrace and Rdbexpert" document, explains all
>the new users bumps in getting the products working, any interest in posting
Yes, please. Either here or in the ARTICLES conference, whichever you
prefer.
(06/21/93 Wood: Don't forget the human element.)
-------------------------------------------------
I have done some evaluation of both the FREND products and Rdb-Expert.
I agree with Scott's review almost completely.
The other option to consider is to hire the expertise to provide database
analysis and design while educating your staff. The consultants active here
(Keith and Chuck) would be a good place to look for such skills. (Disclaimer:
I have no vested interest in either JCC of Front Range Consulting except as a
satisfied customer.)
December, 1993 The DECUServe Journal Page: 18
(06/22/93 Maufe: horrible style, useful info though!)
------------------------------------------------------
A DAY IN THE LIFE OF DECTRACE AND RDBEXPERT
Okay, so the production database has slowed down under the load and
export/import didn't speed it up. I guess that means its time for the
snail-busters to come in - DECtrace and RDBEXPERT! But wait, these are new
tools and I need to quickly get results, I can't read all the documentation
AND keep my Boss happy.
There is life after getting a box from the Digital Software Supply Business.
This short talk tries to make that life look rosy and happy, with sub-second
response times from your database.
If you need to tune a database, what do you need to know? You need to know the
logical layout of the database, table this table that. Constraints used for
referential integrity, and some triggers to do away with all that nasty
application code. We know that already, because we have a database, its just
slow. Well, we also need to know what size daatabase we're talking about, how
many rows are in each table and so forth. We also need to know the environment,
shall we tune the database for a VAX 9000 Model 500 with 10 RA90s and 128megs
of memory. Or are we fitting it onto two RZ23s on a 3100? Last, and the most
vital input, we need to know the workload. How can we design a database if we
don't know how people use it? Mrs Smith in Payroll does that huge batch job
every week, and Boggins on the shop floor is always pulling up schedules, but
what other requests are being fired at the database? And how important are
those requests? And how frequently are those same requests being used. What do
you mean in a distributed multi-protocol many-platform client-server fail-safe
lights-out environment you don't know? Thats where the request policeman comes
in - DECtrace to the rescue!
Like an obedient bloodhound, DECtrace sits at your gate and watches everybody
pass, and sniffs their shopping baskets. So, to stretch this analogy a little
thin, DECtrace watches Rdb/VMS, and on command will store all the requests
people are firing at the databases. For people who down and dirty details,
Rdb/VMS passes BLR to DECtrace.
Why don't we take a walk, and see how DECtrace and RdbExpert can give you your
weekends back and make your Boss happy? First, a picture to hang on your wall,
+-----------------------------------------------------------------------------+
+ DECtrace | FACILITY --> SELECTION --> COLLECTION --> RMS file --> database+
+ | +
+ |----<----------<---------------<- +
+ RdbExpert | Design Directory | +
+ Conceptual | +
+ logical design | +
+ physical design | +
+ environment | +
+ volume | +
+ workload <--------| +
+-----------------------------------------------------------------------------+
December, 1993 The DECUServe Journal Page: 19
The picture is to look at, but not too hard.
DECtrace and RdbExpert are twin sisters - fraternal. They spring from the same
family, but have different temperaments and strengths. DECtrace watches your
databases and collects all the requests. RdbExpert takes this as input and all
the other input, and gives you a suggested design for the database. So first
lets get some DECtrace workload information collected. RdbExpert has a MOTIF
interface and a character cell interface. It's up to you which one you use.
Use the SHOW SYSTEM command to check that the EPC$REGISTRAR process is running.
This is DECtrace's bloodhound, "sniffer central". As each user comes into
Rdb/VMS, via SQL, RDO, SQLMOD, SQLPRE, SQL/Services, wherever, Rdb/VMS calls
the DECtrace registrar and says, "are you interested in my user?". And
depending on whether you are actively collecting DECtrace data, the registrar
replies yes or no. If the registrar says yes, Rdb/VMS sends over every request
from that user (eg SELECT * from PAYROLL, INSERT A into PAYROLL) to DECtrace,
where it is squirrelled away for later analysis by RdbExpert.
So how do you get DECtrace interested in collecting data? First you need to
create a facility. Then you define a selection based on the facility. Then you
schudule the collection, say from 9am to 10am. DECtrace uses its registrar
process to sit out on the system waiting for new users.
Lets take the first step. DECtrace comes with facilities for many layered
products, for example ALL-IN-1, Rdb/VMS, DBMS, DEC Rally and so forth. If you
do a,
COLLECT SHOW FACILITY
you'll see all the facilities that DECtrace knows about. If you don't see
RDBVMS listed, execute
@EPC$EXAMPLES:EPC$INSERT.COM
and this will add all the facilities for you. Stop and restart
DECtrace using the commands,
COLLECT STOP SYSTEM/ABORT
@SYS$STARTUP:EPC$STARTUP.COM
DECtrace keeps two databases of its own, the administration database and the
history database. The adminstration database keeps all your definitions and so
forth, the history database all the success and fatal error messages.
Now most people use DECtrace over and over again in the same manner. So we
create a "selection" that is a a description of how we want to use DECtrace.
Today we are collecting data for later use by RdbExpert. So we can,
COLLECT CREATE SELECTION BIGBOSS/OPTIONS
Options> FACILITY RDBVMS/VERSION=V4.1-0/CLASS=RDBEXPERT
Options> cntl-Z
December, 1993 The DECUServe Journal Page: 20
It is very important that we specify RDBVMS, that we exactly specify the
correct version number, and that we specify the class to be RDBEXPERT.
Otherwise when Rdb/VMS asks the DECtrace registrar whether it is interested in
a V4.1-0 RDBVMS user attaching to PERSONNEL.RDB, the registrar will say no!
We now have a personalised profile of what we want to collect. It is now time
to tell DECtrace at what times of the day we'd like to collect data. GIGO
rules here just like anyplace else. If we don't collect enough workload data,
RdbExpert will produce a poorly designed database. If we collect too much
data, it will take many days to move the data from DECtrace to RdbExpert. So
what is the right balance? Well, you want to aim for a snapshot or
cross-section of all users requests. If you know that between 10am and 11am
on a Monday, and 11pm and 5am on Saturday you'll see an example of every
request fired at the database, you should decide to collect at those times.
You should try and avoid collecting for 24 hours or more, otherwise you collect
too much data! You should avoid collecting for just 10 minutes, you'll miss a
lot of requests that RdbExpert needs to know about. So lets schedule for the
above times,
COLLECT SCHEDULE COLLECTION SIMONS_COLLECTION1 DISK10:[DIR]MYFILE.DAT-
/SELECTION=BIGBOSS/BEGINNING=11:00/ENDING=12:00/PROTECTION=(W:w)
COLLECT SCHEDULE COLLECTION SIMONS_COLLECTION2 DISK10:[DIR]SATURDAY.DAT-
/SELECTION=BIGBOSS/BEGINNING=23:00/ENDING=05:00/PROTECTION=(W:w)
The /PROTECTION on the command above was very important. After individual
Rdb/VMS users have signed in with the registrar, they start sending their data
to the RMS file directly, not through some privileged account. So if MRS_SMITH
doesn't have read,write,access to the data file, her data won't be collected.
So make sure you put the file someplace that has wide open access.
We can now do a
COLLECT SHOW REGISTER
to see who is collecting what. You'll see that until 11am, lots of people are
registered with DECtrace, but not registering. What you'll see between 11am
and noon is that everybody who starts an Rdb/VMS session is being collected.
So their use of the database is being collected. The file DISK10:[DIR]MYFILE.DAT
will be growing larger by the minute as people write to it. At noon you'll
see users are listed as "registered and not collecting". So they signed in
with DECtrace, but were told "We're not interested right now." If you have
any msitakes in your selection now is when you'll see them, as the DECtrace
registrar says "not interested" when in fact it may be interested.
After we have collected some data, we need to start moving it over to RdbExpert.
This is a two-step process. First we FORMAT the text file MYFILE.DAT into an
Rdb/VMS database, then we IMPORT the WORKLOAD into RdbExpert. We'll do the
format now, and the IMPORT later today.
December, 1993 The DECUServe Journal Page: 21
COLLECT FORMAT MYFILE.DAT FORMATTED_WORKLOAD.RDB
COLLECT FORMAT/MERGE SATURDAY.DAT FORMATTED_WORKLOAD.RDB
so now the database FORMATTED_WORKLOAD.RDB holds all the information on who
used the databases between 11am and noon, and 11pm and 5am. DECtrace has done
its part and can be allowed to retire gracefully. We'll take lunch, and move
onto RdbExpert.
So, was lunch good? Pencils sharpened and ready to go? Good, put the pencils
down. We'll let RdbExpert take the strain from here, its all keyboard work, and
for the lucky MOTIF people we'll give the mouse a run for its money. Let recap
where we were before lunch. We used DECtrace to collect a lot of information
about how our users used the database. We did for this a total of 7 hours, and
FORMATed the information into an Rdb/VMS database ready for consumption by
RdbExpert.
First, we need to tell RdbExpert a few other things about the database. First
we need a workbench, where we can collect all our data. Type in RDBEXPERT at
the DCL prompt. MOTIF people will get a pretty window, character cell people
will get an RDBX prompt. RdbExpert calls its workbench a DESIGN DIRECTORY. Its
an Rdb/VMS database (surprise!) and its where RdbExpert will keep its data.
Character cell people do a
RDBX> CREATE/OPEN DIRECTORY MYPROJECT;
MOTIF people pull down the CREATE menu and select DESIGN DIRECTORY.
An RdbExpert design directory can be used to tune many databases, so we need to
keep each project in a conceptual directory(eg SHOPFLOOR_DATABASE,
ACCOUNTING_DATABASE etc). In addition each conceptual project can have a
logical design, eg should we have 20 tables, or should we normalise the
database into 200 tables). So we have the hierarchy,
DESIGN-DIRECTORY
|
CONCEPTUAL-DESIGN_DIRECTORY
|
LOGICAL-DESIGN-DIRECTORY
So MOTIF people have been pulling down CREATEs like mad to get to this stage,
character cell people have been typing a little more,
RDBX> CREATE CONCEPTUAL_DESIGN RDBX$MAIN.concept;
RDBX> CREATE LOGICAL_dESIGN RDBX$MAIN.concept.ldesign;
What you can see is we have a hierarchy. The logical design directory lies under
a conceptual design directory which lies under the design directory. The whys
and wherefores of this indirection don't matter.
We now come to the interesting point. Remember that RdbExpert needs to know
four things to be able to design a faster database?
December, 1993 The DECUServe Journal Page: 22
o logical schema - what do your tables and so forth look like
o environment - how many disks and how much memory can I use
o volume - how large are my tables
o workload - how do people use the database?
So we "IMPORT" these into RdbExpert, in the order listed above.
Lets do the logical schema. For MOTIF people use the mouse to highlight the
logical-schema. Then select IMPORT SCHEMA under the design menu. You will be
asked for the filename of your database. Your head is probably spinning, you
have three databases! The real one (remember, the slow one you are trying to
tune), the formatted dectrace workload, and your design directory. Well, fill
the box in with the name of the real database.
Character cell people need to,
RDBX> IMPORT LOGICAL_SCHEMA RDBX$MAIN.concept.ldesign.lschema
cont> FROM RDB_ROOTFILE myrealdatabase.RDB;
This will take around 20 to 30 minutes, time for a coffee and some phone calls.
We now know what the database looks like logically. We can implement this
physically in many different ways, one design may have 10 storage areas on 5
disks, another 1 storage area only. So we create a physical design directory
for our initial design. MOTIF people click on CREATE and physical design
directory, character cell people,
RDBX> CREATE PHYSICAL_DESIGN RDBX$MAIN.concept.ldesign.pdesign;
Now we'll start bringing in the data that shapes our physical design. First
we'll IMPORT the environment. Lets begin with an introduction to PDL!
RdbExpert has a 'language' called PDL. It is used very rarely, but it used to
describe the environment. This examples come from
RDBX$EXAMPLES:RDB_PERSONNEL_ENVIRONMENT.PDL. I suggest you copy this file to
your directory and edit it,
ENVIRONMENT FOR PHYSICAL_DESIGN 'Physical'
USERS IS 10
MAXIMUM_MEMORY IS 16 MEGABYTES
AVAILABLE_MEMORY IS 60 PERCENT
AIJ IS ENABLED
DISK 'DISK$DB_1:'
RANK IS 1
SPACE IS 200000 BLOCKS
LOCATION IS 'SYS$SCRATCH:'
DISK 'DISK$DB_2:'
RANK IS 2
SPACE IS 100000 BLOCKS
LOCATION IS 'SYS$SCRATCH:'
December, 1993 The DECUServe Journal Page: 23
So we'll IMPORT this environment to RdbExpert. MOTIF people, highlight the
physical design you just created, and select IMPORT ENVIRONMENT. Type the name
of your PDL file in the box provided. Character cell users,
RDBX> IMPORT ENVIROMENT RDBX$MAIN.concept.ldesign.pdesign FROM
cont> PDL MYDISKS.PDL;
We have a hierarchy that MOTIF people can see, and character cell people have
to imagine,
DESIGN-DIRECTORY
|
CONCEPTUAL-DESIGN-DIRECTORY
|
LOGICAL-DESIGN-DIRECTORY
|
LOGICAL-DESIGN
|
PHYSICAL-DESIGN
|
ENVIRONEMNT
We next will IMPORT the volume, ie how many rows are in each table of the
database. This operation doesn't take long, as every Rdb/VMS database keeps an
estimation of this figure in its header. MOTIF users can highlight the physical
design with one click, and IMPORT VOLUME. You'll be asked the filename of your
database. Character cell people,
RDBX> IMPORT VOLUME RDBX$MAIN.concept.ldesign.pdesign
cont> FROM RDB_ROOTFILE myslowdatabase.RDB;
The only input missing now is the workload. This is the operation that really
takes a long time and uses up memory and IO and disk space on your machine.
You have been warned! MOTIF people (you know what I'm going to say) highlight
the physical schema and IMPORT the workload. You'll be asked to supply the
filename of the DECtrace workload database, we called it
FORMATTED_DATABASE.RDB remember? Character cell people, type
RDBX> IMPORT WORKLOAD RDBX$MAIN.concept.ldesign.pdesign.myvolume
cont> FROM DECTRACE FORMATTED_WORKLOAD.RDB;
Allrrrigght! Its early evening and your workload import completed. RdbExpert
now has all the keys to puzzle of how to redesign your database. It is time to
..... GENERATE. This step sucks in all the data provided, gurgutates it some
and .. returns to the prompt. So, you say? What happened. Well, RdbExpert has
stored inside its design directory a new physical design for your database. You
can now EXPORT this design to an SQL file. The SQL file can take 2 formats, an
EXPORT/IMPORT type way of changing the old database to the new database; or in
the form of a SQL CREATE DATABASE command. Which way you choose is up to you!
To make the transition easier you can create a RESDESIGN procedure. This is a
DCL command file that asks some questions, does a whole bunch of RMU/UNLOADs
from the old database, creates the new database, and does a whole bunch of
RMU/LOADs into the new database.
December, 1993 The DECUServe Journal Page: 24
RdbExpert also will tell you WHY it generated the design it did. MOTIF people
pull done the REPORT menu and ask for the audit report. It will justify why a
hashed index, why these columns in the index, and why placed in this storage
area with this page size.
The important thing to remember is now that you have generated a database
design, nobody is forcing you to execute it. Plenty of people print off the
design, and print off the audit report. Then they selectively implement the
ideas RdbExpert puts forward.
And the real magic of RdbExpert is that it is interative. You spend a day with
it, and get a certain database design that helps some. Well, after a few days
or weeks, go through the workload collection and generation process again, and
you'll find an incrementally faster database. And so on.
Remember, the design is only as good as the data. So collect plenty of workload
but don't collect so much that it takes days to IMPORT it into RdbExpert. You
see the same request (SELECT * FROM PAYROLL) probably happens many times.
RdbExpert will try and collate all the same requests together, and set the
frequency. So rather than saying, this request happened, and this request
happened, and so forth, RdbExpert will say SELECT * from PAYROLL happened 50
times. This collation and counting of frquency takes place during workload
import.
Advanced users can 'tweak' all of the inputs, environment, volume and workload.
MOTIF people can double-click on the object. Character cell people can export
the workload, environment or volume to a PDL file, edit the PDL file, and
IMPORT again with the /REPLACE qualifier.
Remember the heierarchy, and where everything slots in,
DECtrace
FACILITY (aka DEFINITION)
|
SELECTION
|
COLLECTION
COLLECTION goes into a file, that gets FORMATed into a database,
COLLECT FORMAT myfile formatted_workload
Then, in RdbExpert we set up the conceptual design, the logical design
directory, the logical design and the physical design. Then we IMPORT the
environment, the volume and workload. Then we GENERATE the design, and
examine the reports.
Copyight Digital Colorado Springs Prepared by Simon Maufe
December, 1993 The DECUServe Journal Page: 25
(06/23/93 Hare: More on Tools)
-------------------------------
Scott's classifications look pretty accurate to me. I guess that by his
definitions I must be a guru since that is pretty much my reaction to RdbExpert
and FrEnd.
My main criticism of RdbExpert is that it is too big and tries to do too
much, and so makes it difficult to focus on a particular issue.
In Linwood's case, where he is attempting to support and tune multiple
instances of the same database, RdbExpert should be useful. The thing to do is
to set up the logical and conceptual designs (or whatever the RdbExpert terms
are) and have multiple workloads. In this case, the effort to define column
level cardinalities and volitilities(sp?) will be amortized over multiple
workloads.
(06/24/93 Kilgallen: Feature creep is part of the industry)
------------------------------------------------------------
My experience in offering software for sale is that potential customers
want to see all their pet capabilities provided.
My experience offering comments to the DECtrace developers a while ago is
that I wanted to see all _my_ pet capabilities provided.
"I want to add my appreciation of the
Joe Crum volunteers who manage and support DECUServe. As
Quoted on 09/01/93 in I have said before, it is a well-managed and very
DECUServe_Forum 373 valuable service that I rely on to help me do my
job, and it pays for itself practically every
week. I have been a subscriber since day 1, and I
have seen participation grow to the necessary
"critical mass", and beyond with participation by
many very informed people. Thanks for providing
this great service!"
Cable Testers
-------------
The following article is an extract of the DECUServe
Hardware_Help conference topic 1531. The discussion
occurred between September 22, 1993 and September 30, 1993.
By Jim Campobello, John Burnet, Matt Holdrege, Terry Kennedy, Dale Coy,
David Campen, John Matuscak, Brett Coningham,
(09/22/93 Campobello)
---------------------
My company wants to purchase a cable tester. It has to handle thick and
thin ethernet; 10baseT would be a nice plus. We want to be able to identify
wiring problems such as bad connections, etc.
December, 1993 The DECUServe Journal Page: 26
From looking in catalogs and calling vendors, I located the products below.
(They are listed in approximate order of cost/features.)
Does anyone have experience with any of these testers? Are there any that
you particularly recommend or advise against? Thanks.
MT350 Scanner
Pair Scanner
LANcat 1800
LANcat 1500
Cable Scanner
MT310 Scanner
Quick Scanner
(09/22/93 Burnet: 9/93 Data Communications for survey)
-------------------------------------------------------
This isn't exactly what you asked for (I have no direct experience to
report), but you might want to take a look at the September 1993 issue of Data
Communications magazine. It contains a survey and summary of about 20 handheld
cable testers (pages 95-104).
(09/22/93 Holdrege: Microtest)
-------------------------------
I've used the Microtest pair scanner with good success in the past.
(09/22/93 Kennedy: Fluke 672)
------------------------------
>Does anyone have experience with any of these testers? Are there any that
>you particularly recommend or advise against? Thanks.
Fluke 672. Note that you can get a nice VAXstation for what one of these
guys goes for. 652 if you want somewhat less functionality.
(09/22/93 Coy: Worth what you pay)
-----------------------------------
You get about what you pay for.
If you intend to have a high-quality network with few problems, and fix
problems quickly, then excellent instruments like those from Fluke and
Tektronix and HP will get you there.
The "low end" instruments are a big help, of course - it just takes more
work and time.
(09/22/93 Burnet: It depends on what you really need...)
---------------------------------------------------------
This is certainly true. However, even the low-end handheld units are
pretty impressive, when you consider that five or ten years ago a TDR cost tens
of thousands of dollars. And not every network needs all the advanced features
of the more expensive units.
December, 1993 The DECUServe Journal Page: 27
(09/22/93 Coy: I agree)
------------------------
That's what I was trying to convey. You just have to balance a lot of
factors.
If your boss (or his boss) is breathing down your neck to instantly find
and fix the problem, then you'd better have a lot of really good equipment.
If you don't have much time to monitor and work on your network, then really
good equipment will really improve what you can do in limited time.
But you also get a lot more in the small, "inexpensive" handheld units than
was available just a few years ago.
(09/23/93 Campobello: Anything is better than nothing)
-------------------------------------------------------
Thanks for the information. I will definitely look for that issue of Data
Communications.
Of course we would lke a good tester, but we're a small shop and we'll be
lucky to get even the higher end of the ones I listed. There's no chance
they'd approve anything more.
Well we've gotten along without one for 7 years, so anything will be an
improvement. Our ethernet went berserk last week -- totally down for an hour,
constant collisions during that time, with no apparent cause. It stopped as
mysteriously as it started. That incident is the reason we've got a chance to
get a cable tester now.
(09/23/93 Burnet: Cable tester vs. protocol analyzer)
------------------------------------------------------
Keep in mind that a cable tester will only show you whether the physical
medium itself is any good; it isn't a protocol analyzer. For serious network
problems caused by broadcast storms, sick transceivers, etc., you'll need
something like a Sniffer. Those beasts are expensive enough that it makes
more sense to rent one if you'll only need it once in a while.
(09/23/93 Campen: How about NTA - a software sniffer.)
-------------------------------------------------------
Has anyone used "Network Traffic Advisor" from Bernstein & Associates. I
have been thinking of buying it as a network monitor. I don't need a $40k
sniffer but it would be nice to have some idea of the traffic on the local net.
The cost of NTA is not much.
(09/23/93 Matuscak: LanWatch)
------------------------------
You should look at the LanWatch package from FTP software. Its a pretty
nice protocol analyzer software package that runs on a standard PC. It won't
catch all the stuff that a $20k system will, but for something like $1200, its
really pretty nice.
December, 1993 The DECUServe Journal Page: 28
(09/24/93 Campobello: We'd like to have hardware and software information)
---------------------------------------------------------------------------
>For serious network problems caused by broadcast storms, sick transceivers,
>etc., you'll need something like a Sniffer.
Actually we have a network monitor (Network Professor). As fate would have
it, I had shut down the machine it runs on just a few minutes before the
problem started. When I tried to restart it, the network was so messed up that
I couldn't get a message to the data collection unit to start collecting.
Our guess is that the problem was a physical connection (or lack thereof),
but we don't really know. It just scared us enough to try again to get a
tester.
(09/29/93 Coningham: Two product plugs, for free)
--------------------------------------------------
Shortly after I inherited the job of network manager, we had a similar
occurance of the network going bonkers, excessive collisions, etc. The bottom
line was that workers in one of our "temporary" buildings disconnected the
thinwire line at various places while the building was being remodelled. In
addition, the line was way out of specification (767' long, which I discovered
later). The unterminated end of the line was apparantly reflecting packets
back into the network and causing the collisions. I should add that several
things have happened since to prevent similar problems in future, such as
better communication between planners and myself, all lines back into spec,
DEMPR's replaced with 90C's, etc.
Since that early problem I purchased a Cable Scanner, and I have to say
that no matter how you view it (cheap or not) this unit has paid for itself
countless times. I regard it as absolutely essential. In addition, I use a
plain old FET VOM to check for shorts and opens right at the suspect connector.
It does not take an expensive instrument to quickly locate problem line
segments or faulty connectors.
I would also like to put a plug in for DEC's new PacketWatch product; for
about $3K for a probe, and another $3K for software, you have a very nice
network monitor/sniffer tool. We beta-tested this, and it is another tool I'd
regard as essential, given the price. DEC still has to add some things, but
it has helped me solve some rather sticky traffic problems already. (Let me
add that the product has undergone some name-changes during it's development
life, such as TrafficProbe, TrafficWatch, PacketProbe, NETScout, etc., so I am
not sure what the final product name is. The software I am running is called
PacketWatch, and it runs on my DECStation 5000/133. I will definitely buy this
when the new fiscal year begins (and we hopefully have money again!). The
Probe is the same form-factor as DECHub-90 modules, and will plug into a
DECHub90 or DECHub900, or can be attached to a thinwire line.
(No, I don't even have any DEC stock, hi).
(09/30/93 Coningham: PROBEWatch & DECpacketprobe)
--------------------------------------------------
I found this product introduced and described in INDUSTRY_NEWS 620.11; the
probe is called a DECpacketprobe 90, and the software is called PROBEWatch.
December, 1993 The DECUServe Journal Page: 29
Pocket guide for email addresses?
---------------------------------
This article is an extract of the DECUServe Internetworking
conference topic 167. This conversation occurred between
August 16, 1993 and September 10, 1993.
By Richard Norman, Matt Holdrege, Bob Tinkelman, Jean-Francois Mezei,
Mike Durkin, J. Scott Boykin, Al Hull, Petri Backstrom, Calvin Diddle,
Robert Eden, Brian Tillman
(08/16/93 Norman)
-----------------
Mike Lampson has been helping me to put together a short example list of
Internet addresses for various services.
This was prompted by some examples in the TidBits newsletter which fell
short of my needs. This list is a little longer, but still has plenty of
holes. If there is a better one out there please let me know where and how to
get it.
Otherwise if you have additional examples I'll be glad to update and
maintain the list.
From SMTP To:
.............
Portal => user...@cup.portal.com
Compuserve => #.#@compuserve.com where #.# is userid numbers.
Genie => user...@genie.geis.com
America on line => user...@aol.com
MCImail => user...@mcimail.com
Ones we are _NOT_ sure of:
..........................
Fidonet: ??
ATTmail(?): user...@attmail.com
DELPHI: user...@delphi.com (I think)
AppleLink: user...@applelink.apple.com (I think)
Digital: first...@loc.mts.dec.com (first.last are parts of a name
loc is a location code which any
DEC office or business card can tell)
SMTP to UUNET: edi...@topgun.UUCP -or-
topgun!edi...@uu.uu.net (this is the editor at X journal)
Future Services:
................
NASA will be bringing an X.500 service online by June 1994 and by December 1993
at MSFC. It sounds similar to what DEC is doing.
December, 1993 The DECUServe Journal Page: 30
From SMTP to:
.............
NASA: Firstname...@center.nasa.gov where center = MSFC, KSC, JSC, ...
Al...@center.nasa.gov where alias is one of several possibilities
Bill instead of William for example.
What about ambigous addresses? You'll get a return message with enough info
to determine which address you need.
I noticed several messages on address techniques for PMDF in this
conference. Would someone like to post an IN% list of examples? Assuming this
isn't in an FAQ somewhere.
(08/16/93 Holdrege: DECstyle)
------------------------------
>Digital: first...@loc.mts.dec.com (first.last are parts of a name
That is one method of addressing a Deccie. The other method is
user...@nodename.ENET.DEC.COM
This method usually goes to a VMS MAILbox, while the first goes to an
Allin1 mailbox.
(08/16/93 Tinkelman: There is no ``PMDF answer''. Answers are site dependent.)
-------------------------------------------------------------------------------
>Would someone like to post an IN% list of examples?
I'm not sure what you're asking.
If your site is running PMDF, and if you want to send mail to Internet address
us...@fully.qualified.domain.name
then, from VMSmail you use
in%"us...@fully.qualified.domain.name"
and from PMDF MAIL you use
us...@fully.qualified.domain.name
If you're asking about sending mail *to* a site that is running PMDF, then
the answer is totally site dependent. PMDF provides tools by which a local
postmaster can set up various types of address mappings for inbound mail.
However, the PMDF software does not impose any policy on this. The local
postmaster can set up any arbitrary correspondence s/he can dream up, including
FirstName.LastName -> login-name.
(08/17/93 Mezei: APPLElink adressing was correct)
--------------------------------------------------
The adressing for APPLElink was correct.
(user...@applelink.apple.com)
(08/17/93 Durkin: Inter-Network Mail Guide)
--------------------------------------------
Can't attest to it's validity, but here is something I came across recently
in the comp.dcom.telecom newsgroup.
December, 1993 The DECUServe Journal Page: 31
X-NEWS: eisner comp.dcom.telecom: 8011
Relay-Version: VMS News - V6.1 30/1/93 VAX/VMS V5.5-2; site eisner.decus.org
Path: eisner.decus.org!noc.near.net!howland.reston.ans.net!spool.mu.edu!telecom-request
Newsgroups: comp.dcom.telecom
Subject: Inter-Network Mail Guide (was Re: Internet to Commercial E-Mail)
Sender: tel...@eecs.nwu.edu
Organization: TELECOM Digest
[Moderator's Note: We have a copy of this in our archives although not
as recent as the version attached below. My thanks to the dozen of you
who sent this identical posting to my attention today. No names are
needed, you all know who you are. Thanks to all. PAT]
* INTER-NETWORK MAIL GUIDE: Last Update: 8/1/93 *
Further modifications and (C) 1993 by Scott Yanoff (yan...@csd4.csd.uwm.edu)
Inter-Network Mail Guide - Original Copyright (C) 1992 by John J. Chew
This guide is available via anonymous ftp to: csd4.csd.uwm.edu
INTRODUCTION
This file documents methods of sending mail from one network to another. It
represents the aggregate knowledge of the readers of comp.mail.misc and many
contributors elsewhere. If you know of any corrections or additions to this
file, please follow the instructions in the section entitled 'HOW TO FORMAT
INFORMATION FOR SUBMISSION' and then mail the information to me:
Scott A. Yanoff <yan...@csd4.csd.uwm.edu>.
HOW TO USE THIS GUIDE
If you just want to browse the guide manually for information, this is what
you need to know. The guide is organized as a list of entries. Each entry
tells you how to get from one network to another. Here is what a typical
entry might look like:
#FROM: mynet
#TO: yournet
#RECIPIENT: youraddress
#CONTACT: contactaddress
#INSTR: send to 'youraddress@thegateway'
This means that to send mail FROM a network called 'mynet' TO a RECIPIENT
address 'youraddress' on a network called 'yournet', you should follow the
INSTRUCTIONS shown and address your mail to 'youraddress@thegateway'.
Names and descriptions of the possible FROM and TO fields:
N: aol ; America Online; America Online, Inc.; commercial;
N: applelink ; AppleLink; Apple Computer, Inc.; in-house;
N: arcom ; X.400; ?; ?;
December, 1993 The DECUServe Journal Page: 32
N: att ; AT&T Mail; AT&T; commercial;
N: bitnet ; BITNET; none; academic;
N: bix ; Byte Information eXchange; Byte magazine; commercial;
N: bmug ; ? ; Berkeley Macintosh Users Group; in-house;
N: compuserve ; CompuServe; CompuServe Inc.; commercial;
N: connect ; Connect Professional Information Network; ?; commercial;
N: easylink ; Easylink; AT&T; commercial;
N: easynet ; Easynet; DEC; in-house;
N: envoy ; Envoy-100; Telecom Canada; commercial; X.400
N: fax ; Facsimile document transmission; none; none;
N: fidonet ; FidoNet; none; bbs;
N: genie ; GEnie; GE Information Services; commercial;
N: geonet ; GeoNet Mailbox Systems;
- Geonet Mailbox Services GmbH/Systems Inc.; commercial;
N: gold-400 ; GNS Gold 400; British Telecom; commercial; X.400
N: goldgate ; GoldGate Telcom Gold; Net-Tel Computer Systems; ?;
N: greennet ; GreenNet; Soft Solutions Ltd; commercial;
N: gsfcmail ; GSFCmail; NASA/Goddard Space Flight Center; in-house;
N: ibm ; VNET; IBM; in-house;
N: internet ; Internet; none; academic;
N: keylink ; KeyLink; Telecom Australia; commercial; X.400
N: mailnet ; X.400; ?; ?;
N: mausnet ; Mausnet; Mausnet; non-profit;
N: mci ; MCIMail; MCI; commercial;
N: nasamail ; NASAMail; NASA; in-house;
N: nsi ; NASA Science Internet; NASA; government;
- Dual-protocol: instructions given here pertain only to NSI-DECnet addresses
- (NSI-TCP/IP addresses should be treated as shown for 'internet')
N: omnet ; OMNET; OMNET; commercial;
N: peacenet ; PeaceNet; Institute for Global Communications;
- non-profit;
N: prodigy ; PRODIGY; commercial; ?;
N: sinet ; Schlumberger Information NETwork; ?; ?;
N: sprintmail ; SprintMail; Sprint; commercial; formerly Telemail
N: thenet ; Texas Higher Education Network; University of Texas;
- academic ;
N: wwivnet ; WWIVnet; WWIVnet; non-profit;
The 'RECIPIENT' record gives an example of an address on the destination
network, to make it clear in subsequent lines what text requires subsitution.
The 'CONTACT' record gives an address for inquiries concerning the gateway,
expressed as an address reachable from the source (#FROM:) network. Presumably,
if you can't get the gateway to work at all, then knowing an unreachable
address on another network will not be of great help.
The 'INSTR' records, of which there may be several, give verbal instructions
to a user of the source network to let them send mail to a user on the
destination network. Text that needs to be typed will appear in double quotes,
December, 1993 The DECUServe Journal Page: 33
with C-style escapes if necessary. If the instructions consist simply of
mailing to a certain address, this will be indicated by the words 'send to'
followed by a quoted address. If there are alternative addresses, they will
be marked 'or to' instead.
HOW TO FORMAT INFORMATION FOR SUBMISSION
Here is what I really want in the way of information. If you are adding a new
network to the list, tell me what its official name is (pay attention to
capitalization), what the name of its responsible organization is, and what
kind of a network it is (academic, commercial, government, in-house or
non-profit). If this isn't clear, look at the examples above. For each
connection, give me an entry that looks something like:
#FROM: foonet
#TO: barnet
#RECIPIENT: baraddress
#CONTACT: contactaddress
#INSTR: send to 'baraddress@thegateway'
Note that 'contactaddress' must be an address expressed in foonet's native
format, and not that of barnet, since if a user is having trouble accessing
barnet, giving him/her an address on that net to contact for help is not
productive. If there is no contact/postmaster address, please tell me. If
there are more complicated instructions, use additional #INSTR: lines.
Once you've got all the information together, send it to me in an e-mail
message with the words 'INMG update' in the Subject: line. You can in general
expect an answer back from me within a week.
#FROM: aol
#TO: applelink
#RECIPIENT: user
#CONTACT: Internet
#INSTR: send to 'user@applelink'
#FROM: aol
#TO: compuserve
#RECIPIENT: 71234,567
#CONTACT: Internet
#INSTR: send to '71234.567@cis'
#FROM: aol
#TO: genie
#RECIPIENT: user
#CONTACT: Internet
#INSTR: send to 'user@genie'
#FROM: aol
#TO: internet
#RECIPIENT: user@domain
#CONTACT: Internet
#INSTR: send to 'user@domain'
December, 1993 The DECUServe Journal Page: 34
#FROM: applelink
#TO: bitnet
#RECIPIENT: user@site
#INSTR: send to 'us...@site.bitnet@internet#'
#FROM: applelink
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'user@domain@internet#' (address must be < 35 characters)
#FROM: arcom
#TO: internet
#RECIPIENT: fr...@Domain.dd.uu.us
#INSTR: send to C=CH,A=ARCOM,P=SWITCH,ORG=us,OU1=uu,OU2=dd,OU3=Domain,S=fred
#FROM: att
#TO: bitnet
#RECIPIENT: user@site
#INSTR: send to 'internet!site.bitnet!user'
#FROM: att
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'internet!domain!user'
#FROM: bitnet
#TO: internet
#RECIPIENT: user@domain
#INSTR: Methods for sending mail from Bitnet to the Internet vary depending on
#- what mail software is running at the Bitnet site in question. In the
#- best case, users should simply be able to send mail to 'user@domain'.
#- If this doesn't work, try 'user%domain@gateway' where 'gateway' is a
#- Bitnet-Internet gateway site nearby. Finally, if neither of these
#- works, you may have to try hand-coding an SMTP envelope for your mail.
#FROM: compuserve
#TO: fax
#RECIPIENT: +1 415 555 1212
#INSTR: send to '>FAX 14155551212'
#INSTR: not transitive - message must originate from a CompuServe user
#INSTR: for calls outside the NANP, use '011' as the international prefix
#FROM: compuserve
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'INTERNET:user@domain' (only from CompuServe users)
#FROM: compuserve
#TO: mci
#RECIPIENT: 123-4567
#INSTR: send to '>MCIMAIL:123-4567' (only from CompuServe users)
December, 1993 The DECUServe Journal Page: 35
#FROM: connect
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'DASN'
#- and set the first line of message: '"user@domain"@DASN'
#FROM: easynet
#TO: bitnet
#RECIPIENT: user@site
#CONTACT: DECWRL::ADMIN
#INSTR: send to 'nm%DECWRL::"us...@site.bitnet"' (from VMS using NMAIL)
#INSTR: send to 'us...@site.bitnet' (from Ultrix)
#INSTR: or to 'user%site....@decwrl.dec.com' (from Ultrix via IP)
#INSTR: or to 'DECWRL::"us...@site.bitnet"' (from Ultrix via DECN)
#FROM: easynet
#TO: fidonet
#RECIPIENT: john smith at 1:2/3.4
#CONTACT: DECWRL::ADMIN
#INSTR: send to 'nm%DECWRL::"john....@p4.f3.n2.z1.fidonet.org"'
#- (from VMS using NMAIL)
#INSTR: send to 'john....@p4.f3.n2.z1.fidonet.org'
#- (from Ultrix)
#INSTR: or to '"john.smith%p4.f3.n2.z1.fidonet.org"@decwrl.dec.com'
#- (from Ultrix via IP)
#INSTR: or to 'DECWRL::"john....@p4.f3.n2.z1.fidonet.org"'
#- (from Ultrix via DECN)
#FROM: easynet
#TO: internet
#RECIPIENT: user@domain
#CONTACT: DECWRL::ADMIN
#INSTR: send to 'nm%DECWRL::"user@domain"' (from VMS using NMAIL)
#INSTR: send to 'user@domain' (from Ultrix)
#INSTR: or to 'user%dom...@decwrl.dec.com' (from Ultrix via IP)
#INSTR: or to 'DECWRL::"user@domain"' (from Ultrix via DECN)
#INSTR: or to 'user@domain @Internet' (using ALL-IN-1)
#FROM: envoy
#TO: internet
#RECIPIENT: user@domain
#CONTACT: ICS.TEST or ICS.BOARD
#INSTR: send to '[RFC-822="user(a)domain"]INTERNET/TELEMAIL/US'
#INSTR: for special characters, use @=(a), !=(b), _=(u),
#INSTR: any=(three octal digits)
#FROM: fidonet
#TO: internet
#RECIPIENT: us...@machine.site.domain
#INSTR: convert to 'us...@machine.site.domain ON 1:1/31
#FROM: fidonet
#TO: wwivnet
#RECIPIENT: number@node
December, 1993 The DECUServe Journal Page: 36
#CONTACT: Kevin C. ON 1:100/215
#INSTR: convert to '#number @node ON 1:100/215'
#INSTR: WWIVgate; LOW TRAFFIC SITE, USE SPARINGLY.. Gateway is modem-based,
#- they absorb cost of long distance connects to pick-up and deliver.
#- Keep messages under 10K, use infrequently, do NOT use mail-lists or
#- file/list-server commands.
#FROM: genie
#TO: internet
#RECIPIENT: user@domain
#CONTACT: postm...@genie.geis.com
#INSTR: send to user@domain@INET#
#FROM: geonet
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'DASN'
#INSTR: set subject line to 'user@domain!subject'
#FROM: gold-400
#TO: internet
#RECIPIENT: user@host
#INSTR: send to '/DD.RFC-822=user(a)host/O=uknet/PRMD=uk.ac/ADMD=gold 400/C=GB/'
#INSTR: for special characters, use @=(a), %=(p), !=(b), "=(q)
#FROM: gsfcmail
#TO: internet
#RECIPIENT: user@domain
#CONTACT: cust.svc
#INSTR: send to '(SITE:SMTPMAIL,ID:<user(a)domain>)'
#INSTR: or to '(C:USA,A:TELEMAIL,P:SMTPMAIL,ID:<user(a)domain>)'
#INSTR: or send to 'POSTMAN'
#- and set the first line of message to 'To: user@domain'
#INSTR: Help is also available by phoning +1 800 858 9947.
#FROM: gsfcmail
#TO: nsi
#RECIPIENT: host::user
#CONTACT: cust.svc
#INSTR: send to '(SITE:SMTPMAIL,ID:<user(a)host.DN.NASA.GOV>)'
#INSTR: or to '(C:USA,A:TELEMAIL,P:SMTPMAIL,ID:<user(a)host.DN.NASA.GOV>)'
#INSTR: or send to 'POSTMAN'
#- and set the first line of message to 'To: us...@host.DN.NASA.GOV'
#FROM: internet
#TO: aol
#RECIPIENT: A User
#CONTACT: postm...@aol.com
#INSTR: send to au...@aol.com (all lower-case, remove spaces)
#INSTR: msgs are truncated to 32K (8K for PCs), all characters except newline
#- & printable ASCII characters are mapped to spaces, users are limited to
#- 75 pieces of Internet mail in their mailbox at a time.
December, 1993 The DECUServe Journal Page: 37
#FROM: internet
#TO: applelink
#RECIPIENT: user
#INSTR: send to 'us...@applelink.apple.com'
#FROM: internet
#TO: arcom
#RECIPIENT: (G:John, I:Q., S:Smith, OU:ORG_UNIT, O:Org, P:PRMD, A:ADMD, C:CA)
#INSTR: send to:
#- /G=John/I=Q/S=Smith/OU=ORG_UNIT/O=Org/P=PRMD/A=ADMD/C=C...@chx400.switch.ch
#FROM: internet
#TO: att
#RECIPIENT: user
#INSTR: send to 'us...@attmail.com'
#FROM: internet
#TO: bitnet
#RECIPIENT: user@site
#INSTR: send to 'user%site.bitnet@gateway' where 'gateway' is a gateway host
#- that is on both the internet and bitnet. Some examples of gateways
#- are: cunyvm.cuny.edu mitvma.mit.edu. Check first to see what local
#- policies are concerning inter-network forwarding.
#FROM: internet
#TO: bix
#RECIPIENT: user
#INSTR: send to 'us...@bix.com'
#FROM: internet
#TO: bmug
#RECIPIENT: John Smith
#INSTR: send to 'John....@bmug.fidonet.org'
#FROM: internet
#TO: compuserve
#RECIPIENT: 71234,567
#INSTR: send to '7123...@CompuServe.com'
#INSTR: Ordinary Compuserve account IDs are pairs of octal numbers
#FROM: internet
#TO: compuserve
#RECIPIENT: organization:department:user
#INSTR: send to 'us...@department.organization.compuserve.com'
#INSTR: This syntax is for use with members of organizations which have a
#- private CompuServe mail area. 'department' may not always be present.
#FROM: internet
#TO: connect
#RECIPIENT: NAME
#INSTR: send to 'NA...@connectinc.com'
December, 1993 The DECUServe Journal Page: 38
#FROM: internet
#TO: easylink
#RECIPIENT: user mail number 1234567
#INSTR: send to: 123...@eln.attmail.com
#FROM: internet
#TO: easynet
#RECIPIENT: HOST::USER
#CONTACT: ad...@decwrl.dec.com
#INSTR: send to 'us...@host.enet.dec.com'
#INSTR: or to 'user%host...@decwrl.dec.com'
#FROM: internet
#TO: easynet
#RECIPIENT: John Smith @ABC
#CONTACT: ad...@decwrl.dec.com
#INSTR: send to 'John....@ABC.MTS.DEC.COM'
#INSTR: this syntax is for sending mail to ALL-IN-1 users
#FROM: internet
#TO: envoy
#RECIPIENT: John Smith (ID=userid)
#INSTR: send to 'uunet.uu.net!att!attmail!mhs!envoy!userid'
#FROM: internet
#TO: envoy
#RECIPIENT: John Smith (ID=userid)
#CONTACT: /C=CA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TEST_GROUP/@nasamail.nasa.gov
#INSTR: send to
#INSTR: '/C=CA/ADMD=TELECOM.CANADA/DD.ID=userid/PN=John_Smith/@Sprint.COM'
#FROM: internet
#TO: fidonet
#RECIPIENT: john smith at 1:2/3.4
#INSTR: send to 'john....@p4.f3.n2.z1.fidonet.org'
#FROM: internet
#TO: genie
#RECIPIENT: user
#CONTACT: postm...@genie.geis.com
#INSTR: send to us...@genie.geis.com
#FROM: internet
#TO: geonet
#RECIPIENT: user at host
#INSTR: send to 'user:ho...@map.das.net'
#INSTR: or to 'us...@host.geomail.org' (known to work for geo2)
#INSTR: known hosts: geo1 (Europe), geo2 (UK), geo4 (USA)
#FROM: internet
#TO: gold-400
#RECIPIENT: (G:John, I:Q, S:Smith, OU: org_unit, O:organization, PRMD:prmd)
December, 1993 The DECUServe Journal Page: 39
#INSTR: send to 'john.q.smith@org_unit.org.prmd.gold-400.gb'
#INSTR: or to
#- '"/G=John/I=Q/S=Smith/OU=org_unit/O=org/PRMD=prmd/ADMD=gold 400/C=GB/"
#- @mhs-relay.ac.uk'
#FROM: internet
#TO: goldgate
#RECIPIENT: 10087:CQQ061
#INSTR: send to '10087....@goldgate.ac.uk'
#INSTR: or to '/G=10087/S=CQQ061/P=uk.ac/O=GoldGate/C=GB/'
#FROM: internet
#TO: greennet
#RECIPIENT: user
#CONTACT: sup...@gn.apc.org
#INSTR: us...@gn.apc.org (or us...@gn.uucp if mailing from JANET)
#FROM: internet
#TO: gsfcmail
#RECIPIENT: user
#CONTACT: na...@nasa.gov
#INSTR: send to 'us...@gsfcmail.nasa.gov'
#INSTR: or to '/PN=user/ADMD=TELEMAIL/PRMD=GSFC/O=GSFCMAIL/C=US/
#- @x400.msfc.nasa.gov'
#FROM: internet
#TO: ibm
#RECIPIENT: us...@vmnode.tertiary_domain (syntax?)
#CONTACT: n...@vnet.ibm.com
#INSTR: send to 'us...@vmnode.tertiary_domain.ibm.com'
#INSTR: To look up a user's mailbox name, mail to n...@vnet.ibm.com with
#- the line 'WHOIS name' in the message body.
#FROM: internet
#TO: keylink
#RECIPIENT: (G:John, I:Q, S:Smith, O:MyOrg, A:Telememo, C:au)
#CONTACT: aar...@aarnet.edu.au
#INSTR: send to John.Q...@MyOrg.telememo.au
#INSTR: for keylink Private Mail Domains such as
#INSTR: (G:John, S:Smith, O:MyDept, P:AusGov, A:Telememo, C:au)
#INSTR: send to John....@MyDept.AusGov.telememo.au
#FROM: internet
#TO: mausnet
#RECIPIENT: hans schmidt @ box
#CONTACT: sy...@k2.maus.de
#INSTR: send to 'hans_s...@box.maus.de'
#FROM: internet
#TO: mci
#RECIPIENT: John Smith (123-4567)
#INSTR: send to '123...@mcimail.com'
December, 1993 The DECUServe Journal Page: 40
#INSTR: or to 'JSm...@mcimail.com' (if 'JSmith' is unique)
#INSTR: or to 'John_...@mcimail.com' (if 'John Smith' is unique - note the
#- underscore!)
#INSTR: or to 'John_Smith/123...@mcimail.com' (if 'John Smith' is NOT unique)
#FROM: internet
#TO: nasamail
#RECIPIENT: user
#CONTACT: na...@nasa.gov
#INSTR: send to 'us...@nasamail.nasa.gov'
#INSTR: Help is available by phoning +1 205 544 1771 or +1 800 858 9947.
#FROM: internet
#TO: nsi
#RECIPIENT: host::user
#CONTACT: na...@nasa.gov
#INSTR: send to 'us...@host.dnet.nasa.gov'
#INSTR: or to 'user%host...@ames.arc.nasa.gov'
#INSTR: or to 'user%host...@east.gsfc.nasa.gov'
#INSTR: Help is also available by phoning +1 800 858 9947.
#FROM: internet
#TO: omnet
#RECIPIENT: user
#CONTACT: na...@nasa.gov
#INSTR: send to 'us...@omnet.nasa.gov'
#INSTR: or to 'user/om...@omnet.nasa.gov' (?)
#INSTR: or to '/DD.UN=user/O=OMN/ADMD=TELEMAIL/C=US/@Sprint.COM'
#INSTR: Help is available by phoning +1 800 858 9947
#FROM: internet
#TO: peacenet
#RECIPIENT: user
#CONTACT: sup...@igc.org
#INSTR: send to 'us...@cdp.igc.org'
#FROM: internet
#TO: prodigy
#RECIPIENT: user
#CONTACT: ad...@prodigy.com
#INSTR: send to 'us...@prodigy.com' For example: abc...@prodigy.com
#- Please note that this service is still currently being tested!
#FROM: internet
#TO: sinet
#RECIPIENT: node::user or node1::node::user
#INSTR: send to 'us...@node.SINet.SLB.COM'
#INSTR: or to 'user%no...@node1.SINet.SLB.COM'
#FROM: internet
#TO: sprintmail
#RECIPIENT: John Smith at SomeOrganization
#INSTR: send to
December, 1993 The DECUServe Journal Page: 41
#- '/G=John/S=Smith/O=SomeOrganization/ADMD=TELEMAIL/C=US/@Sprint.COM'
#FROM: internet
#TO: thenet
#RECIPIENT: user@host
#INSTR: send to 'user%host....@utadnx.cc.utexas.edu'
#FROM: internet
#TO: wwivnet
#RECIPIENT: number@node
#CONTACT: faq-r...@tfsquad.mn.org or br...@tfsquad.mn.org
#INSTR: convert to 'numbe...@wwiv.tfsquad.mn.org'
#INSTR: WWCPgate; LOW TRAFFIC SITE, USE SPARINGLY.. Gateway is modem-based,
#- they absorb cost of long distance connects to pick-up and deliver.
#- Keep messages under 10K, use infrequently, do NOT use mail-lists or
#- file/list-server commands.
#FROM: keylink
#TO: internet
#RECIPIENT: John Smith <user@domain>
#CONTACT: (G:CUSTOMER, S:SERVICE, O:CUST.SERVICE, P:telememo, C:au)
#INSTR: send to '(C:au, A:telememo, P:oz.au, "RFC-822":"John Smith
#- <user(a)domain>")'
#INSTR: special characters must be mapped: @->(a), %->(p), !->(b), "->(q)
#FROM: mausnet
#TO: internet
#RECIPIENT: user@domain
#CONTACT: sysop@k2
#INSTR: send to 'user@domain'
#FROM: mci
#TO: compuserve
#RECIPIENT: John Smith (71234,567)
#CONTACT: 267-1163 (MCI Help)
#INSTR: at the 'To:' prompt type 'John Smith (EMS)'
#INSTR: at the 'EMS:' prompt type 'compuserve'
#INSTR: at the 'Mbx:' prompt type '71234,567'
#FROM: mci
#TO: internet
#RECIPIENT: John Smith <user@domain>
#CONTACT: 267-1163 (MCI Help)
#INSTR: at the 'To:' prompt type 'John Smith (EMS)'
#INSTR: at the 'EMS:' prompt type 'INTERNET'
#INSTR: at the 'Mbx:' prompt type 'user@domain'
#FROM: nasamail
#TO: internet
#RECIPIENT: user@domain
#CONTACT: admin
December, 1993 The DECUServe Journal Page: 42
#INSTR: send to '(site:smtpmail,id:<user(a)domain>)'
#INSTR: Help is also available by phoning +1 205 544 1771 and at 'admin/nasa'.
#FROM: nasamail
#TO: nsi
#RECIPIENT: host::user
#CONTACT: admin
#INSTR: send to '(site:smtpmail,id:<user(a)host.DN.NASA.GOV>)'
#INSTR: Help is also available by phoning +1 205 544 1771 and at 'admin/nasa'.
#FROM: nsi
#TO: gsfcmail
#RECIPIENT: user
#CONTACT: na...@nasa.gov
#INSTR: send to 'east::"us...@gsfcmail.nasa.gov"'
#INSTR: or to 'east::"/PN=user/ADMD=TELEMAIL/PRMD=GSFC/O=GSFCMAIL/C=US/
#- @x400.msfc.nasa.gov'
#INSTR: Help is also available by phoning +1 800 858 9947.
#FROM: nsi
#TO: internet
#RECIPIENT: user@domain
#CONTACT: east::"na...@nasa.gov"
#INSTR: send to 'east::"user@domain"'
#INSTR: or to 'dftnic::"user@domain"'
#INSTR: or to 'nssdca::in%"user@domain"'
#INSTR: or to 'jpllsi::"user@domain"'
#INSTR: Help is also available by phoning +1 800 858 9947.
#FROM: nsi
#TO: omnet
#RECIPIENT: user
#CONTACT: omnet.service
#INSTR: send to 'east::"us...@omnet.nasa.gov"'
#INSTR: Help also available by phoning +1 617 244 4333 (OMN customers only)
#FROM: nsi
#TO: sprintmail
#RECIPIENT: John Smith at SomeOrganization
#CONTACT: east::"na...@nasa.gov"
#INSTR: send to
#- '/G=John/S=Smith/O=SomeOrganization/ADMD=TELEMAIL/C=US/@Sprint.COM'
#INSTR: Help is also available by phoning +1 800 858 9947.
#FROM: omnet
#TO: internet
#RECIPIENT: user@domain
#CONTACT: omnet.service
#INSTR: Enter 'compose manual' at the command prompt. Choose the Internet
#- address option from the menu that appears. Note that this gateway
#- service charges based on the number of 1000-character blocks sent.
#INSTR: Help also available by phoning +1 617 244 4333 (OMN customers only).
December, 1993 The DECUServe Journal Page: 43
#FROM: sinet
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'M_MAILNOW::M_INTERNET::"user@domain"'
#INSTR: or to 'M_MAILNOW::M_INTERNET::domain::user'
#FROM: sprintmail
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to '(C:USA,A:TELEMAIL,P:INTERNET,"RFC-822":<user(a)domain>) DEL'
#INSTR: Help available within the United States by phoning +1 800 336 0437 and
#- pressing '2' on a TouchTone phone.
#FROM: sprintmail
#TO: nsi
#RECIPIENT: host::user
#INSTR: send to
#- '(C:USA,A:TELEMAIL,P:INTERNET,"RFC-822":<user(a)host.DNET.NASA.GOV>) DEL'
#INSTR: Help available within the United States by phoning +1 800 336 0437 and
#- pressing '2' on a TouchTone phone.
#FROM: thenet
#TO: internet
#RECIPIENT: user@domain
#INSTR: send to 'UTADNX::WINS%" user@domain "'
#FROM: wwivnet
#TO: fidonet
#RECIPIENT: First Last ON zone:node/fnet
#CONTACT: 1@3469
#INSTR: convert to 'First Last ON zone:node/fnet @656'
#INSTR: WWIVgate; LOW TRAFFIC SITE, USE SPARINGLY.. Gateway is modem-based,
#- they absorb cost of long distance connects to pick-up and deliver.
#- Keep messages under 10K, use infrequently, do NOT use mail-lists or
#- file/list-servers commands.
#FROM: wwivnet
#TO: internet
#RECIPIENT: us...@machine.site.domain
#CONTACT: faq-request@9702 or 1@9702
#INSTR: convert to 'user#machine.site.domain@506'
#- If 'user' begins with digits, begin address with a quote.
#INSTR: WWCPgate; LOW TRAFFIC SITE, USE SPARINGLY.. Gateway is modem-based,
#- they absorb cost of long distance connects to pick-up and deliver.
#- Keep messages under 10K, use infrequently, do NOT use mail-lists or
#- file/list-server commands.
(08/17/93 Boykin: X.400 user through MCI Mail)
-----------------------------------------------
I have not had time to read all the previous note yet but can anyone give
me the exact form of addressing an X.400 user at MCI Mail from the Internet?
I have been trying to figure this for several months.