July issue of The DECUServe Journal
fr...@eisner.decus.org
=====================
July, 1993
This issue of the DECUServe Journal contains a large variety of topics
and audience participation. ;-) The last few issues have been composed of
a few large articles, so I felt that it was time to give you a bunch of smaller
articles on a good range of topics. There should be something for everyone
here.
I have also tucked in a small questionaire; the goal of which is to
give me a better feel for who you are and what you would like to read in
future issues of the Journal. Please take a look at it and send your response
when you have a moment. I'm looking forward to hearing from all of you!
Sharon
fr...@eisner.decus.org
Table of Contents
-----------------
Editor's Comments .................................. 1
The Journal Questionaire ........................... 46
Technical Information .............................. 49
Articles
The Time Management Blues! ...................... 2
Multiple Mail Areas ............................. 9
So much for HSC Redundancy! ..................... 22
Is there an x.400 "postmaster"? ................. 29
PATHWORKS problems w/ Windows V3.1 .............. 31
Computer Humor .................................. 34
OSF/1 VMS Performance ........................... 37
How to start a process with different owner ..... 37
The device is, uh, illogical .................... 41
Why is SYS$COMMON an alias? ..................... 44
July, 1993 The DECUServe Journal Page 2
The Time Management Blues!
--------------------------
This article is an extract of the DECUServe All-In-1
conference topic 823. This discussion occurred between
January 6, 1993 and January 22, 1993. This article was
submitted for publication by Sharon Frey. Ed.
By Jo Ann Catcott, Mike Lampson, Steve Bonine, Maria Weisnicht, Lynda Peach,
Bruce Bowler
(01/06/93 Catcot)
-----------------
Hi y'all! Happy New Year! I am trying to resolve some problems with Time
Management. (I know, I know, I know...I'm nuts!) I am hoping you may have
seen these problems and have some ideas. Thanks ahead of time for your help!
1. One user has two meetings which were scheduled in 1992. She is trying
to be a good user and delete the old calendar references. Unfortunately,
they cannot be deleted! They do not go away! If you try to delete
them from the menu, nothing happens, no errors, nothing. The meeting
remains in the current item block. If you try to delete from the
index, the item is removed from the index, but the next time you choose
index, the meeting reappears.
A trace of the problem shows that OA$SCROLL_ADDRESS is used to obtain
MEETING_POINTER from CAL$CALENDAR. The intent seems to be to use
MEETING_POINTER to reference the system meeting and attendees records in
CAL$MEETING and CAL$ATTENDEE. Unfortunately, the data being returned by the
GET is incorrect!
If you look at the physical record in CAL$CALENDAR, the data IS correct.
The record key (CAL_KEY) and MEETING_POINTER both reference the same meeting
date/time string "199208041300". But the trace shows that even though
OA$SCROLL_ADDRESS (%#04000000000100) remains the same for all GETs, the returned
data references two different meetings. For example, CAL_KEY is returned as
19920804130000001 (correct date and time). However, MEETING_POINTER is returned
as 19920804150000001, which is incorrect! When CAL CAN MEET is executed, it
appears to go through the motions, but the trace shows the wrong
19920804150000001, #CAL_MEETING_POINTER reference. The end result is that the
meeting being deleted, 19920804130000001 remains in the calendar.
I can remove the offending records, but why is this happening? This is not
the first time this has happened and not always for the same user. Looks like
a good old fashion bug to me, but I wanted to make sure I was not overlooking
something.
2. The second problem may just be my lack of knowledge in the maintenance
of the calendar files. I saw an old note, #193, which discussed this
with no good resolution and nothing since. While reviewing the above
problem, I found that the system files CAL$MEETING
(OA$DATA:MEETING.DAT) and CAL$ATTENDEE (OA$DATA:ATTENDEE.DAT) are
July, 1993 The DECUServe Journal Page 3
large. The meeting file is 18,000+ blocks. Both files included records
which date back to the installation of 2.4. Some of these records are
because the user's have not cleaned-up their calendars, understood.
But, in the above research the MEETING_POINTER incorrectly being
referenced is for a meeting which WAS scheduled and deleted by the
user. There is no CAL$CALENDAR record, but there ARE STILL records in
CAL$MEETING and CAL$ATTENDEE. In fact, ALL of the meetings that the
user was able to successfully delete, have no CAL$CALENDAR records but
they can be found in CAL$MEETING and CAL$ATTENDEE!
Are these files supposed to keep these old records? Or has no one cared
enough to write the housekeeping script? I would like to write a script which
both eliminates old records and purges the orphan records, maybe improve
response time somewhat. Has anyone else already done this? Any reason this
is not a good idea?
Well, thanks for the help and consideration.
(01/06/93 Lampson: This should help you write a housekeeping procedure . . . )
-------------------------------------------------------------------------------
I can't explain why 1. is happening. It certainly seems like a bug. I
don't know what to suggest other than manually deleting them.
For 2., that is the way it is designed, unfortunately. Deleting old
calendar information simply deletes the record in the user's .A1CAL file.
The MEETING and ATTENDEE files are never purged. One of the reasons this is
so is because these data files are shared. If one user deletes a meeting, the
other users should still see all the attendees and responses.
So, a housekeeping procedure needs to resolve all usage of a particular
record in MEETING.DAT before purging the MEETING and ATTENDEE files. This
could be done in two phases. The first phase would, for each scheduler and
attendee of a particular meeting, check to see if that scheduler/attendee still
has the meeting on his/her calendar. If not, set a flag to specify that this
user is done with this meeting.
Now, after setting all these flags, go through each attendee record for
each meeting. If all ATTENDEE delete flags are set AND the scheduler delete
flag is set, delete the meeting record and all related attendee records.
When I wrote a spec to do this when I still worked at DEC, I suggested
using the STATUS field of the CAL$MEETING DSAB for the scheduler delete flag
and the KEEP_MEETING field of the CAL$ATTENDEE DSAB for each attendee. Note
that KEEP_MEETING is a field used by TM to designate whether or not the meeting
was kept on the attendee's calendar - the user has this choice when answering
N to a meeting request. This field is NOT translated, so should store a
hard-coded Y or N character. The STATUS field of the CAL$MEETING DSAB is not
used by TM, so it doesn't matter what value you put there to designate deleted.
Also, consider all remote attendee records as deleted. That way, once all
local attendees and the scheduler delete the record, you can delete the entire
set. The REMOTE_ATTENDEE field of the CAL$ATTENDEE DSAB was meant to designate
remote attendees. Unfortunately, a bug in TM prevents you from using this flag,
so you must parse the ATTENDEE_NAME field for "@" to look for remote attendees.
July, 1993 The DECUServe Journal Page 4
When doing this in V3.0, watch out for attendee records written to the
CAL$ATT_OVERFLOW DSAB. Attendee names are written into CAL$ATTENDEE if they
are 30 characters or less. If more, the ATTENDEE_NAME field contains a tilde
"~" character is position 26 and MEETING_POINTER and ATTENDEE_NAME make up the
key to CAL$ATT_OVERFLOW. The ATTENDEE_NAME field in CAL$ATT_OVERFLOW contains
the full attendee address (up to 255 characters).
(Whew!)
(01/06/93 Catcott: A Housekeeping we shall go!)
------------------------------------------------
Thanks Mike. I am off and running. I will let you know how it goes and
if I have any more questions. :-)
(01/06/93 Bonine: Hope you can come up with something for this.)
-----------------------------------------------------------------
I would be very interested in what you come up with. I don't really care
if it is "perfect". Our meeting and attendee files are huge and growing. If
someone complains to me that they cannot look at the attendees of a meeting
which was held a year ago, they're not likely to get much sympathy.
Good luck!
(01/07/93 Lampson: Careful about "partial" purges)
---------------------------------------------------
I think you bring up a good point that should be an OPTION in any TM
housekeeping procedure. The system management people may want to blow away all
TM information prior to a specific date. However, to not corrupt the TM
structures, such an option should delete the user information from users
.A1CAL files too. Most users don't even pay attention to the fact that their
.A1CAL files are growing forever.
However, some TM users (like me) keep old TM information around for a long
time. I used to use it to recreate a history of my tasks, accomplishments and
activities since my last performance review. In DEC, this used to be up to 18
months.
(01/07/93 Catcott: Proposal for TM Housekeeping)
-------------------------------------------------
I intend to allow the submitter to do both.
They can run a purge which will delete the user's CAL$CALENDER file
(appointments and meetings) and the system CAL$MEETING and CAL$ATTENDEE
files based on a specifed interval (days). The interval will be provided by
the submitter.
The submitter will also be able to run the "orphan" purge at the same
time. These procedures can be run together or independently.
Both procedures will produce reports indicating what has been deleted.
The reports can also be produced without actually completing either purge.
All of this will be done out of Houskeeping.
How does that sound?
I will let you know how it goes. Steve, I will ask the client if I can
post the code here. He is a good guy, so we may be able to arrange this.
July, 1993 The DECUServe Journal Page 5
(01/10/93 Weisnicht: PURGE hidden option)
------------------------------------------
Doesn't 2.4 have a hidden option/form called PURGE which allows a user to
clean out old events prior toa specified date? I don't think its around in 3.0
anymore.
(01/10/93 Lampson: PURGE doesn't help system files)
----------------------------------------------------
The form PURGE will simply remove old items from a user's .A1CAL file. It
doesn't remove the old information from the system TM files.
(01/11/93 Bonine: Looking forward . . . )
------------------------------------------
It sounds absolutely fantastic. I'll be happy to test it for you with
5,000 accounts if you wish . . .
Seriously, I do hope that you can post it here when it's done. It would be
a very valuable facility.
(01/13/93 Catcott: Initing the Calendar Files)
-----------------------------------------------
Well I am progressinq down the path of the Calendar file purge housekeeping
procedure. But I seem to have found a problem using NEWDIR and CALENDAR INIT
FILES.
Using a FOR loop through PROFIL, I am NEWDIRing to become each user and
thereby processing their CAL$CALENDAR file. Access to the calendar files does
not occur until the calendar files are opened and appropriate symbols are set.
According to the documentation, CALENDAR INIT FILES should achieve this for
me. Unfortunately, executing CALENDAR INIT FILES after a NEWDIR in the FOR
loop is not working. It errors off with the obnoxious "Form 'username' is not
in the library."
Any ideas? In an effort to make sure this is not a syntax problem, I have
tried this in skelton for loops where there is just a newdir and the calendar
init. The trace reflects the newdir completion, the CALENDAR INIT FILES begins
initializing then gives the bogus error. I have interactively executed the
NEWDIR and CALENDAR INIT FILES successfully and compared the traces.
Unfortunately, nothing obvious showed up. Any thoughts on this would be
apprecated. By the way, I have also tried using CALENDAR SET ALTERNATE_USER
with appropriate privileging and access and got the same error!
(01/13/93 Lampson)
------------------
CAL INIT FILES sets up some internal TM variables and some other stuff.
However, you should not call this function after every NEWDIR. NEWDIR detects
if CAL INIT FILES has already been done, and if so, changes the TM files as
part of the NEWDIR.
So, do CAL INIT FILES once before beginning your NEWDIR loop and you should
be set. As a precaution, it is probably a good idea to do DUMP_CACHE
CAL$CALENDAR before each NEWDIR. And, as a sanity check, you can look at the
July, 1993 The DECUServe Journal Page 6
symbol OA$TM_OWNER after the NEWDIR to see if the CAL$CALENDAR dataset is
pointing to the correct place (it should be equal to OA$USER).
Keep up the good work! This is going to be a great tool!
(01/14/93 Catcott: CAL INIT before NEWDIR)
-------------------------------------------
Thanks Mike. I will go give this a whirl and let you know how it goes.
I appreciate the encouragement as well. Although there is something to be said
regarding learning the hard way!
(01/14/93 Catcott: The Saga of CAL INIT)
-----------------------------------------
Mike, Mike, Mike - The CAL INIT FILES still does not work! :-( I knew
there was a reason why I have been ignoring TM, ignorance is in fact bliss!
;-) Actually, I think I have narrowed it down. The ALL-IN-1 username standard
here is "lastname.first". Although there are a few account names which are
just "lastname". The calendar initialization works (no form error) for the
accounts which are lastname only. It fails on any account which contains a
period. For example, it succeeds for ADAMS and fails for ADAMS.JOYCE and
ADAMS.PATRICIA.
I have been using DUMP_CACHE all along, so I do not think this has made any
difference to the problem. A good idea, but no difference. I had also tried
initializing the files at different times, but I had lost track of all the
various scenarios, so your suggestion was well worth a try.
Let me show you examples of the code. If I execute a script like the
following, no for loop, it works. When I NEWDIR, regardless of the periods in
the usernames, the calendar is appropriately initialized. But this has always
worked!
NO_FOR.SCP
cal init files
! set name of test user
get #user = "ADAMS.JOYCE"
dump_cache
get oa$function = "newdir " #user
get oa$function =-
"display User: " oa$user " TM User: " oa$tm_owner "\force"
!go back to my account
newdir
.exit
If however, I call the same script from within a for loop (with appropriate
commenting of commands), it fails for the user's with a period in their name.
For example:
July, 1993 The DECUServe Journal Page 7
FOR_LOOP.SCP
cal init files
for profil with .user = "ADAMS" do -
get #user = .user\\-
do called_from_for
newdir
.exit
CALLED_FROM_FOR.SCP (Same as NO_FOR with comments)
! cal init files
! set name of test user
! get #user = "ADAMS.JOYCE"
dump_cache
get oa$function = "newdir " #user
get oa$function =-
"display User: " oa$user " TM User: " oa$tm_owner "\force"
!go back to my account
!newdir
.exit
The really interesting part is that if I comment out the CAL INIT FILES
and just NEWDIR this script works fine. It has no errors at all regardless of
the username.
Well now that I have written a novel, let me know what you think. I
appreciate all of your help. Thanks.
(01/14/93 Lampson: typical ALL-IN-1 . . . )
--------------------------------------------
Well, all I can say is that I wish I still had access to the TM sources.
Something really strange is going on here. I'd suggest working outside of the
for loop and living with the less elegant code. You can write a manual loop
by loading the first Profile entry using:
GET #USER = PROFIL.%FIRST[""]
and then manually stepping through the Profile with:
GET #USER = PROFIL.%NEXT[#USER]
Don't forget to skip over the records in the Profile that aren't real
accounts!
Sorry.
(01/17/93 Bonine: Encouragement)
---------------------------------
Just a bit of encouragement for you, Jo Ann. We are all hoping that you
can make this work. I would not be surprised to see TM have a problem with the
period in the username . . . and our naming standard is the same as yours, with
a period in ALL of our real ALL-IN-1 usernames.
Good luck! Keep plugging!
July, 1993 The DECUServe Journal Page 8
(01/18/93 Catcott: Help and encouragement appreciated!)
--------------------------------------------------------
Thanks Y'all! I will let you know how it goes.
(01/20/93 Catcott: Calendar file(s) fields)
--------------------------------------------
Well, I am making progress. I ran the purge portion yesterday (reporting
only) and it looks as really good. I am testing the orphan stuff today. I had
a couple of new questions however. Mike, if you will once again come to my
rescue.
I want to keep track of whether or not the scheduler and attendees had
deleted the meeting as of the last execution of the script. If the scheduler
has deleted the meeting, but not all of the attendees have deleted the meeting,
there is no need to check the scheduler's calendar again. I am using the
.STATUS field Mike recommended for tracking this. But the inverse is also
true. If all of the attendees have deleted the meeting and only the scheduler
still has a reference, I do not want to have to check all of the attendees
again - to much newdiring. Is there another field, which can hold more than
one character, I can use for this? I am putting the number of attendees still
holding a reference into this field for reporting purposes, so the field should
hold up to four characters.
I also need more info on the layout of the overflow file. This is a 2.4
system, but I might has well include the code for the 3.0 system because it
will be upgraded eventually. I guess, I really just need to know the name of
the key field, because I will only be referencing this file when I know the
record should be deleted.
(01/20/93 Lampson: more field info)
------------------------------------
I recommend setting the KEEP_MEETING field of the CAL$ATTENDEE record to N
if this meeting is no longer in the attendee's calendar. When all KEEP_MEETING
flags are N, then no attendees are using this meeting information. When a
specific KEEP_MEETING flag is already N, then there is no need to check that
user's CAL$CALENDAR.
As for keeping a count, it makes sense to keep it in CAL$MEETING which only
has 1 record per meeting. The best field to use is FILLER. However, watch out
that there are not customizations that already use this field (remote
possibility). FILLER in the CAL$MEETING data set is 50 characters.
The key to CAL$ATT_OVERFLOW is 76 characters long. It is equal to the two
fields which make up the key to CAL$ATTENDEE. So just append the CAL$ATTENDEE
fields MEETING_POINTER (46 characters) and ATTENDEE_NAME (30 characters)
together.
(01/20/93 Peach: Bets are you're "in")
---------------------------------------
Since Jo Ann is the Associate AIM rep, I would suspect you had no problems!!
This has been a great series of notes!
July, 1993 The DECUServe Journal Page 9
(01/21/93 Bowler: here?? Here??)
----------------------------------
Even if they don't get accepted (which I'm sure they will), are you going
to upload the salient points of the notes here?
(01/21/93 Lampson: ...)
------------------------
What's it worth to you? ;^}
Seriously, yes, I can do that. I can post them around the time I submit the
notes. (I don't know the deadline yet.) I hesitate to simply post the field
layouts without explanation as there are dangers to using (or messing with)
certain fields that look like they aren't being used.
Multiple Mail Areas
-------------------
This article is an extract of the DECUServe All-In-1
conference topic 843. The discussion occurred between
February 22, 1993 and March 30, 1993. This article was
submitted for publication by Sharon Frey. Ed.
By Lynda Peach, Bruce Bowler, Chris Simon, Steve Bonine, Richard Black,
Mike Lampson, Bruce Burson, Pierre Hahn, Jean-Francios Mezei, Larry Rosenbaum
(02/22/93 Peach)
----------------
Can we talk about multiple mail areas in ALL-IN-1?
For example:
1) Are you running more than one mail area?
a) If so, how many?
b) Are they all open?
c) How many closed? How many open?
2) If you are at more than two, did you go there "slam bang" or open one,
then another, then another?
3) If you did go to multiple mail areas one at a time, why didn't you
create more than just one more?
4) What kind of challenges have you found in management of more than one
mail area?
5) If you had more than one mail area before you upgrade to 3.0, did it
cause any problems for you when you did?
6) Do you have anything that you've written/modified/etc. that help you
manage your "beast" better?
July, 1993 The DECUServe Journal Page 10
(02/23/93 Bowler: Answers from one site)
-----------------------------------------
Yes, 2, 1 open, 1 closed.
Started with one, then opened another.
Shortage of disk spindles.
I've not run into any extra "opportunities" :-)
Haven't upgraded yet, but it better work smoothly.
>6) Do you have anything that you've written/modified/etc. that help
Nope, if you mean multiple DAFs when you speak of the "beast" :-)
(02/23/93 Simon: Multiple mail areas surprisingly trouble-free)
----------------------------------------------------------------
Three. One closed, two open.
Closed E, opened both A and B at that time.
>3) If you did go to multiple mail areas one at a time, why didn't you
I ended up creating two more simultaneously because there had been both a
large increase in the number of users and a natural breakpoint where about half
of the users all worked for a single division of the company and thus send each
other much more mail than they send other people on the same system.
By the way, I do not run the Balance Mail Areas procedure. This is because
in my case, I feel that I know better which people should be in the same mail
area.
>4) What kind of challenges have you found in management of more than
No particular problem. Just make sure that the account creation templates
all have an OPEN mail area indicated in them once you close an area.
We haven't upgraded yet, but I don't anticipate any problem.
>6) Do you have anything that you've written/modified/etc. that help
Two things:
1. There is a small bug in the V2.4 MUA index form. If you try to index
users by mail area, you'll get nothing. This is because the named data
uses the wrong name for the field. It's .MAIL_AREA instead of .MAIL$AREA
or something similar. It'll be helpful to you if you fix this.
2. I've modified the command procedure used to reorganize system files.
In the DAF reorganization part, I've added a little bit of code that
says if I'm working on OA$DAF_E.DAT, look for OA$LIB:SDAF_E.FDL to do
the reorganization. If it exists, use it. If not, use the normal
OA$LIB:SDAF.FDL. It does this for each area. What this does is allow
me to optimize each of the DAF files individually. The biggest
difference in mine is the initial file allocation.
July, 1993 The DECUServe Journal Page 11
(02/24/93 Bonine: Additional mail areas is not a really big deal.)
-------------------------------------------------------------------
>1) Are you running more than one mail area?
a) 5
b) yes
We opened them over time. We started with two, and added additional
ones as the system grew.
>3) If you did go to multiple mail areas one at a time, why didn't you
No perceived need. We opened the additional mail areas for two reasons.
First, we needed the space. Second, we needed the heads. When you have 1500
concurrent users, you don't want to crowd them all into one area. I don't,
however, pretend to have a good handle on what the "right" number of users per
mail area might be.
>4) What kind of challenges have you found in management of more than
None. There are challenges related to managing large ALL-IN-1 systems,
but none that I can relate directly to the number of mail areas.
No upgrade yet, but don't see any problems.
>6) Do you have anything that you've written/modified/etc. that help
Like Chris, I have a customization to allow separate FDLs for the separate
areas.
I also have a mod which allows me to run concurrent empty-wastebasket jobs,
one for each mail area. This was a convenient way for me to segment the jobs;
it could as easily have been by alphabet or department or sixth letter of name;
the important thing for me was to be able to run concurrent jobs to get through
everyone in a reasonable time.
It would be nice to have an automated program which would go out and check
mail directory status and tell us when it's time to switch to a new set of
directories. This manual task is more time-consuming if you have more mail
areas, but it's not the end of the world.
(02/25/93 Black: Manage Alphabetically)
----------------------------------------
I have not been the ALL-IN-1 manager in a long time so I passed your
question to Doug Rager our current ALL-IN-1 Manager and here is his reply.
1) Yes.
a) 4 but users profiles only point to 3 which are active.
b) Yes all 4 are open but only 3 ge new messages. OA$SHARE is only open
because users can not access messages in a closed area according to Doug.
c) None are closed. 4 open, 3 active.
July, 1993 The DECUServe Journal Page 12
2) We opened one at a time as the I/O rates of disk required (each DAF on a
different disk to spread the I/O).
3) Each additional mail area you open creates overhead.
4) The biggest problem is balancing the users evenly between mail areas. We do
not use the BMA option becuse it is slow and we do not want to balance by
departments.
5) We are still using V2.4.
6) Basically we balance by spliting the profile into thrids alphabetically and
assign each third to a different mail area. Doug uses Datatrieve but I had
scripts that I used.
The scripts are Count_Mail_Area_Users.scp to find out how many users are in
a mail area. Change_Mail_Area.scp to do a mass move of an alphabetic section
of the profile to an mail area. Change_Mail_Area_Sel.scp to move users from a
selection list to an mail area. Change_Mail_Area_Sel.scp should only be used
if you need finer control who gets moved since it takes a lot more time to
setup the selection list.
Please feel free to use and/or modify the scripts at your site if you find
them helpful. All I ask is that you that you leave my name as the orginal
author.
! COUNT_MAIL_AREA_USERS.SCP
! Author: Richard H. Black 01/22/90
! Script to count how many users are in a MAIL AREA. This checks the MAIL$AREA
! field in their PROFILE record.
!
PROMPT "Count the number of users for which MAIL AREA? (OA$SHARD) "
GET #MAIL_AREA = OA$PROMPT_TEXT
DECIMAL I
COMPUTE #CNT = 0
OA$TRA_SET MESS,LOG
GET OA$FUNCTION="DISPLAY Starting COUNT_MAIL_AREA_USERS at " OA$TIME "\FORCE"
.LABEL NEXT
FOR PROFIL WITH .MAIL$AREA == #MAIL_AREA DO COMPUTE #CNT = #CNT + 1\\ -
GET OA$FUNCTION="DISPLAY " .USER "\FORCE"
GET OA$FUNCTION="DISPLAY MAIL AREA " #MAIL_AREA " Contains " #CNT " users.\FORCE"
.LABEL END
GET OA$FUNCTION="DISPLAY Finished COUNT_MAIL_AREA_USERS at " OA$TIME "\FORCE"
OA$TRA_SET OFF,MESS,OFF,LOG
DUMP_CACHE
GET OA$FUNCTION="DISPLAY MAIL AREA " #MAIL_AREA " Contains " #CNT " users.\FORCE"
.EXIT
July, 1993 The DECUServe Journal Page 13
! CHANGE_MAIL_AREA_FOR.SCP
! Author: Richard H. Black 12/13/89
! Script to change users MAIL$AREA field in their PROFILE record.
! Changes one share area per run. Moves all users from #START to #END
! into the selected mail area (i.e. move all users with usernames A to G
! into OA$SHARD).
PROMPT "Which MAIL AREA do you want to move these users to? (OA$SHARD) "
GET #MAIL_AREA = OA$PROMPT_TEXT
PROMPT "Starting with which letter "
GET #START = OA$PROMPT_TEXT
PROMPT "Ending with which letter "
GET #END = OA$PROMPT_TEXT
GET #END = #END "ZZZZZ"
OA$TRA_SET MESS,LOG
GET OA$FUNCTION="DISPLAY Starting CHANGE_MAIL_AREA at " OA$TIME "\FORCE"
GET OA$FUNCTION="DISPLAY Moving users starting with " #START " - " #END "\FORCE"
GET OA$FUNCTION="DISPLAY to MAIL AREA " #MAIL_AREA "\FORCE"
.LABEL NEXT
FOR PROFIL WITH ( .USER GES #START AND .USER LES #END ) DO -
WRITE CHANGE PROFIL USER = .USER, MAIL$AREA = #MAIL_AREA\\ -
GET OA$FUNCTION="DISPLAY " .USER "\FORCE"
.LABEL END
GET OA$FUNCTION="DISPLAY Finished CHANGE_MAIL_AREA at " OA$TIME "\FORCE"
OA$TRA_SET OFF,MESS,OFF,LOG
DUMP_CACHE
.EXIT
! CHANGE_MAIL_AREA_SEL.SCP
! Author: Richard H. Black 12/13/89
! Script to change users MAIL$AREA field in their PROFILE record.
! MAIL_LIST.SEL contains an entry for every person being converted.
! Use this script and selection list if you need finer control of who
! get moved to another mail area.
PROMPT "Which MAIL AREA do you want to move these users to? (OA$SHARD) "
GET #MAIL_AREA = OA$PROMPT_TEXT
OA$TRA_SET MESS,LOG
GET OA$FUNCTION="DISPLAY Starting CHANGE_MAIL_AREA at " OA$TIME "\FORCE"
.LABEL NEXT
NEXT_LIST MAIL_AREA.SEL
.IF $NEXT_LIST_ITEM == "" THEN .GOTO END
WRITE CHANGE PROFIL %KEY = $NEXT_LIST_ITEM, MAIL$AREA = #MAIL_AREA
GET OA$FUNCTION="DISPLAY " $NEXT_LIST_ITEM "\FORCE"
.GOTO NEXT
.LABEL END
July, 1993 The DECUServe Journal Page 14
GET OA$FUNCTION="DISPLAY Finished CHANGE_MAIL_AREA at " OA$TIME "\FORCE"
OA$TRA_SET OFF,MESS,OFF,LOG
DUMP_CACHE
.EXIT
(03/01/93 Bonine: BMA)
-----------------------
We also balance mail areas alphabetically, rather than using the supplied
BMA facility. The script I use is very simple minded, like this:
decimal i
oa$sub_close
compute #i = 0
for profil do compute #i = #i + 1 -
\\.if #i < 2200 then write change profil %key=.user,mail$area='OA$SHARB' -
else .if #i < 4400 then write change profil %key=.user,mail$area='OA$SHARC' -
else write change profil %key=.user,mail$area='OA$SHARE'
write change profil %key="A1FETCHER",mail$area='OA$SHARA'
(03/01/93 Peach: Great info... keep it comin')
-----------------------------------------------
This is great guys. I hope to get back into this area soon. If you check
out the Message Router note, you'll see where I've been working.
I'm finding the MR "situation" to be far more complicated that the ALL-IN-1.
Of course, I know a lot more about A1 than MR.
I need to write the two FDLs (one for each shared area) by Friday.
(03/02/93 Simon: Closed mail areas still usable)
-------------------------------------------------
Just to clarify, this is incorrect. Users CAN access messages in a closed
area. My OA$SHARE has been closed for over a year, but there's still plenty
in it, all of which is accessible. The big pain in closing a mail area is that
you have to shut down ALL-IN-1 to do it.
(03/02/93 Lampson: converting OA$DAF_%.DAT files...)
-----------------------------------------------------
Are these to convert the OA$DAF_%.DAT files? If so, a trick I use to
create an FDL to _start with_ is to do the following:
$ ANALYZE/RMS/FDL OA$DAF_E.DAT ! Assuming E in this example
$ EDIT/FDL/NOINTER/ANALYZE=OA$DAF_E OA$DAF_E
I then use my favorite text editor (TPU) to edit the OA$DAF_E.FDL file the
way I want. (I don't like the FDL editor too much.) In general, I usually
don't make many changes. But a real good change is to make sure the
July, 1993 The DECUServe Journal Page 15
OA$DAF_%.DAT files use large extends so they don't become as fragmented in the
future.
Be warned! These steps will take awhile!
(03/02/93 Bowler: Are the closed areas *really* any different?)
----------------------------------------------------------------
This may deserve a topic of it's own except that Linda asked for pitfalls
of multi-mail areas...
When we added area A in July 1992, we added it, closed E then did a BMA.
All users at that time were then in area A. Today, I discovered (while working
on a mildly corrupt PENDING) that some of my users, in fact all of those created
since July are in area E. A quick trip through the code reveals that the area
is closed but none of these people have a problem sending or receiving mail.
For grins, I moved my mail area to be E using MUA (no cheating here folks :-).
It let me do it, no validation of the area other than it's defined :-( I was
able to send messages. So, when is a mail area closed? Me thinks only when
it's truly deleted!
(03/02/93 Bonine: Why "formally" close an area?)
-------------------------------------------------
I agree with Chris; you can access information in a closed area.
Which brings up a question . . . Why bother closing an area? All our areas
are always open, but at any given time we have areas which have no users
assigned to them. (There are no profile records which contain OA$SHARx in the
mail area slot.) These areas are essentially closed. What do I gain by
"formally" closing an area?
(03/03/93 Burson: Probably for BMA)
------------------------------------
My guess would be for BMA. As pointed out in the previous replies, nothing
prevents you from moving users to a closed area or creating new users with a
template that points at a closed area. So the only real use for closing
area(s) would be for BMA to limit the areas that it balances accounts into.
If you get lots of off-node mail, you may want to close an area, balance all
the accounts over the remaining areas and then move POSTMASTER to the closed
area (all incoming messages from Message Router go to POSTMASTER's area).
(03/03/93 Black: Automate answer)
----------------------------------------
We do the same thing that was mentioned in [the last reply by Mike Lampson],
the difference being that we put in a procedure and just run it every Sunday.
The first procedure JANITOR_REORG just setups the environment and then submits
multiple jobs to run concurrently. The sendlock and fetchlock is there because
we run the ALL-IN-1 sender and fetcher simultaneously, which is not the default
from DEC.
July, 1993 The DECUServe Journal Page 16
$!-----------------------------------------------------------------------------
$! JANITOR_REORG.COM !
$! USAA MODS
$! DMR 07/10/90 - this procedure now only checks for sender and fetcher
$! running, submits janitor_reorg jobs, and then uses SYNCH
$! to wait for them to finish.
$! DMR 03/14/91 - Delete DAFE from conversion, change DAFC disks.
$! CYH 09/17/91 - Add DAFB to conversion
$! CYH 09/17/92 - Add DAFE back, remove DAFB
$!-----------------------------------------------------------------------------
$ write sys$output ""
$ write sys$output ""
$ write sys$output "''f$time()'"
$ write sys$output ""
$ write sys$output "ALL-IN-1 File Cabinet Data File Reorganization LOG"
$ write sys$output ""
$
$ send_ctrl = "N" ! Reset Sender control symbol
$ fetc_ctrl = "N" ! Reset Fetcher control symbol
$ retries = 0 ! Reset retries value
$ get_snd: ! Trying to get control of Fender
$ IF send_ctrl .EQS. "Y" THEN goto get_fet
$ IF F$SEARCH ("OA$MTI_DATA:SENDLOCK.DAT;1") .EQS. "" THEN -
CREATE OA$MTI_DATA:SENDLOCK.DAT;1
$
$ OPEN/READ/WRITE/ERROR=get_fet LOCKFILE1 OA$MTI_DATA:SENDLOCK.DAT;1
$
$ send_ctrl = "Y" ! Set Sender control symbol
$
$ get_fet: ! Trying to get control of Fetcher
$ IF fetc_ctrl .EQS. "Y" then goto not_got
$ IF F$SEARCH("OA$MTI_DATA:FETCHLOCK.DAT;1") .EQS. "" THEN -
CREATE OA$MTI_DATA:FETCHLOCK.DAT;1
$ OPEN/READ/WRITE/ERROR=not_got LOCKFILE2 OA$MTI_DATA:FETCHLOCK.DAT;1
$ fetc_ctrl = "Y" ! Set Fetcher control symbol
$
$ not_got:
$ IF (send_ctrl .EQS. "Y") .AND. (fetc_ctrl .EQS. "Y") THEN -
goto submit_janitor
$ retries = retries + 1
$ IF retries .EQ. 10 then goto finish
$ wait 00:05:00 ! Wait for 5 minutes
$ goto get_snd ! Go get control
$
$ finish:
$ IF send_ctrl .EQS. "Y" then close LOCKFILE1
$ IF fetc_ctrl .EQS. "Y" then close LOCKFILE2
$ write sys$output ""
$ write sys$output "''f$time()'"
$ write sys$output ""
$ write sys$output "***** WARNING *****"
July, 1993 The DECUServe Journal Page 17
$ write sys$output ""
$ write sys$output "ALL-IN-1 File Cabinet Data Files were not"-
+" reorganized due to Sender or Fetcher"
$ write sys$output "running."
$ write sys$output ""
$ exit
$!-----------------------------------------------------------------------------
$ submit_janitor:
$
$ SUBMIT/NOPRINT/QUE=GQTECHSYS/NOTIFY/NAME=JANITOR_REORG_DAFD -
/PARAMS=("$6$DUA53:","DISK$DATA02:[OA$SHARD]OA$DAF_D.DAT","D") -
/LOG=SYS$BACKUP:JANITOR_REORG_DAFD.LOG OA$LIB:JANITOR_REORG_CNVDAF
$ dafd_entry=$entry
$ SUBMIT/NOPRINT/QUE=GQTECHSYS/NOTIFY/NAME=JANITOR_REORG_DAFC -
/PARAMS=("$6$DUA907:","DISK$DATA03:[OA$SHARC]OA$DAF_C.DAT","C") -
/LOG=SYS$BACKUP:JANITOR_REORG_DAFC.LOG OA$LIB:JANITOR_REORG_CNVDAF
$ dafc_entry=$entry
$ SUBMIT/NOPRINT/QUE=GQTECHSYS/NOTIFY/NAME=JANITOR_REORG_DAFE -
/PARAMS=("$6$DUA50:","DISK$DATA00:[OA$SHARE]OA$DAF_E.DAT","E") -
/LOG=SYS$BACKUP:JANITOR_REORG_DAFE.LOG OA$LIB:JANITOR_REORG_CNVDAF
$ dafe_entry=$entry
$!
$! SUBMIT/NOPRINT/QUE=GQTECHSYS/NOTIFY/NAME=JANITOR_REORG_DAFB -
$!/PARAMS=("$6$DUA55:","DISK$DATA04:[OA$SHARB]OA$DAF_B.DAT","B") -
$!/LOG=SYS$BACKUP:JANITOR_REORG_DAFB.LOG OA$LIB:JANITOR_REORG_CNVDAF
$!dafb_entry=$entry
$
$ SET NOON
$! SYNCHRONIZE/entry='dafb_entry
$ SYNCHRONIZE/entry='dafc_entry
$ SYNCHRONIZE/entry='dafd_entry
$ SYNCHRONIZE/entry='dafe_entry
$ SET ON
$
$ close lockfile1
$ close lockfile2
$ write sys$output ""
$ write sys$output ""
$ write sys$output "''f$time()'"
$ write sys$output ""
$ write sys$output "Finished Reorganizing ALL-IN-1 DAF Files"
$ write sys$output ""
$ exit
$!-----------------------------------------------------------------------------
$! end of command procedure JANITOR_REORG.COM
$!-----------------------------------------------------------------------------
The second procedure JANITOR_REORG_CNVDAF.COM does the work. Note the
SET RMS/BLOCK=127/BUFFER=127/INDEX because it speeds up processing of large
files and our DAFs are large. Each of our DAFs is on a separate disk that is
shadowed. This helps keep the I/O rates within reason. Since our disk are
shadowed, we dismount the 2nd member and do the covert on it then copy it back
to 1st member. This is important because you write operations are slower on
July, 1993 The DECUServe Journal Page 18
a shadow set. Since we are doing the convert on an unshadowed disk it is faster
than if we left the disk shadowed. A separate procedure checks all the logfiles
for errors and if there are none it mounts the 2nd disk back into the shadow
set. If there are errors you still have a copy of the old DAF on the 2nd
member, so that you can manually fix the problems.
$!-----------------------------------------------------------------------------
$! JANITOR_REORG_CNVDAF.COM - 7/10/90 Copied and modified from !
$! SMSREORG.COM !
$! All-IN-ONE system file reorganisation command procedure. !
$!-----------------------------------------------------------------------------
$ shadow_disk == p1 - ":"
$ file_name == p2
$ daf_ltr == p3
$!
$! USAA MOD 05/26/88 - DGD - DAF is too big; must convert on second disk
$! speed up IO rate for converts
$ SET PROC/PRIOR=6
$ SET RMS/BLOCK=127/BUFF=127/INDEXED
$!
$ write sys$output ""
$ write sys$output ""
$ write sys$output "''f$time()'"
$ write sys$output ""
$ write sys$output "ALL-IN-1 File Cabinet Data File Reorganization LOG"
$ write sys$output ""
$ write sys$output ""
$ write sys$output ""
$ write sys$output "Reorganizing " + file_name
$ write sys$output "---------------------------------"
$
$! Save file protection so the new version can be restored correctly
$ on warning then goto End_routine
$ pro = f$file_attributes("''file_name'","PRO")
$
$! First convert file to a .tmp file incase of errors
$ on error then goto End_routine
$!
$! USAA MOD 05/26/88 - DGD - optimize index files
$ ANAL/RMS/FDL/OUT=DAF'DAF_LTR' 'FILE_NAME'
$ COPY DAF'DAF_LTR'.FDL TEMP'DAF_LTR'.FDL
$ ED/FDL/NOINTER/ANAL=TEMP'DAF_LTR' DAF'DAF_LTR'
$ PURGE/KEEP=2 DAF'DAF_LTR'.FDL
$!
$! unshadow the second member of shadow set if it is mounted
$ SH DEV 'SHADOW_DISK
$ IF F$GETDVI(SHADOW_DISK,"MNT") THEN -
DISMOUNT/CLUSTER/NOUNLOAD 'SHADOW_DISK
$ SH DEV 'SHADOW_DISK
$! Wait to make sure disk is completely dismounted
$ WAIT 00:01:00
$ INIT/NOHIGHWATER 'SHADOW_DISK SHADOW_DAF'daf_ltr'
July, 1993 The DECUServe Journal Page 19
$ SH DEV 'SHADOW_DISK
$ MOUNT 'SHADOW_DISK SHADOW_DAF'daf_ltr'
$ SH DEV 'SHADOW_DISK
$!
$ ASSIGN 'SHADOW_DISK':[000000] SORTWORK0
$ ASSIGN 'SHADOW_DISK':[000000] SORTWORK1
$ CONV/STAT/FDL=DAF'DAF_LTR' 'FILE_NAME' 'SHADOW_DISK':[000000]DAF.NEW
$!
$ DIR/FULL 'FILE_NAME'
$ DIR/FULL 'SHADOW_DISK':[000000]DAF.NEW
$ DEL/LOG 'FILE_NAME';* ! Deletes the old DAF off the 1st member
$ COPY/LOG 'SHADOW_DISK':[000000]DAF.NEW 'FILE_NAME'
$ SET PROT=(S:RWED,O:RWED,G:RE,W:RE) 'FILE_NAME'
$ DIR/FULL 'FILE_NAME'
$
$ DISMOUNT/NOUNLOAD 'SHADOW_DISK
$ DEL TEMP'DAF_LTR'.FDL;*
$! end mod
$ End_routine:
$
$ write sys$output ""
$ write sys$output ""
$ write sys$output "''f$time()'"
$ write sys$output ""
$ write sys$output "Finished Reorganizing ALL-IN-1 Data Files"
$ write sys$output ""
$ exit
$!-----------------------------------------------------------------------------
$! end of command procedure JANITOR_REORG_CNVDAF.COM
$!-----------------------------------------------------------------------------
(03/03/93 Peach: More...)
--------------------------
This stuff is great! I've about got Message Router behaving (knock very
LOUDLY on wood) but still have to do a reconfiguration on both clusters --
with documentation as to what and why. (What a concept!)
I believe the Close Mail Area is really for the BMA as someone stated
previously. For the person who has new accounts going to the old area, check
your templates. I bet they are still set to the old area, which of course
makes me wonder what mine are pointing to. Our site does not use ALL-IN-1 to
generate the accounts but a "home-produced" program which then uses A1. I bet
I may have the same thing happening!
Let's keep all the discussion on Mail Areas and SDAFs in this area. I
don't know about the rest of you but having not to hop around to various
bulletins to get answers to a question or concept in ALL-IN-1 is extremely
helpful.
(03/09/93 Bonine: VMSmail)
---------------------------
> If you get lots of off-node mail, you may want to close an area, balance
>all the accounts over the remaining areas and then move POSTMASTER to the
>closed area
July, 1993 The DECUServe Journal Page 20
We get no off-node ALL-IN-1 mail but vast amounts of imported VMSmail.
We have many users who have their VMSmail forwarded into ALL-IN-1. This mail
goes into the area defined in the profile entry for A1FETCHER, not POSTMASTER.
(03/09/93 Peach: How do you handle "rejected" messages?)
---------------------------------------------------------
On my very LOOONNGGG list of things to do... establish policies and
procedures regarding handling of "rejected" messages. These include stuff
internet won't handle, those lovely messages that give you some long hairy ugly
double .NBS files, etc. etc.
I'd love to hear how others handle it. I see anywhere from 10 to 100 of
these beasts a day. Obviously I can't spend huge amounts of time handling
these. How do others do it?
(03/10/93 Mezei: Have you looked inside those ugly NBS files?)
---------------------------------------------------------------
Lynda, care to elaborate a bit more on those .NBS files?
Have you tried to run MB$TOOLS:MRNBSDMP on them to see what they look like
inside ? (scary thought :-)
If you receive internet mail, make sure that an internet message posted to
"POSTMASTER" will end up somewhere on your system.
(03/10/93 Peach: Oh yes, I just wish it didn't take so long per look)
----------------------------------------------------------------------
You have nailed exacty the ones I mean.... the MRNBSDMP has to be used.
My biggest "gripe" about that is-- no make than an "are":
1) I have to retype that entire pathname which on my system is 5,872
characters long!
2) I can't view them on the terminal but must output them to file and
*THEN* read them. Most of the time I could do this via view with a
couple of quick notes.
Now I'll show my ignorance. Sceanario: I've read the NBS files and the
message ain't every going to go. Incorrectly entered address.
How do I get rid of those messages! Replying to the user is not that big
of deal. And I know the system will eventually dump them, but I'd like to
know who to physically remove them.
BTW, I did reconfigure my second cluster tonight. Not difficult at all
after the work done for the other cluster last week.
(03/11/93 Black: CHECK_AQM and FREE)
-------------------------------------
In your message router configuration, you define when to report that you
have TOO MANY MESSAGES in a message router queue (mailbox) and when you have
OLD MESSAGES. When you CHECK_AQM inside of MRMAN it will report these
July, 1993 The DECUServe Journal Page 21
occurances to you. When run a batch every 15 minutes that does a CHECK_AQM.
This notify's us that we have OLD (i.e. undeliverable?) mail, then we do a
$MCR MRMAN DUMP * to see what it is. If we decide that we want to delete it
we do a $MCR MRMAN FREE serial#.
If it is an OLD message and you do nothing at all the messages will be
automatically deleted when its age reaches the age you defined in your message
router configuration. I do not remember the defaults or the exact wording of
thes question in the message router configuration but they are fairly straight
forward.
If you like, I could post the command procedure that runs the CHECK_AQM.
(03/11/93 Mezei: MRNBSDMP can be used to dump to screen)
---------------------------------------------------------
When you use MRNBSDMP, specify TT: as the output file, and guess what ?
It gets displayed on your screen. Make sure you have your finger on the
hold screen button :-)
(03/16/93 Peach: TT: - great and AF can get you)
-------------------------------------------------
That's totally awesome! I'll try that tomorrow.
BTW, If you find a really STRANGE mail queue in MRMAN... check out your
AUTOFORWARD addesses. I know. They are SUPPOSE to validate. But we got one
the other day where the queue cae up as 93, SCHOOL TIL MARCH 15 -- and it was
in this user's autoforward address which had
username -- 93 etc.
I'd used FREE to get rid of the previous messages in this queue but until
we found his autoforward address, they kept appearing.
Now -- someone what to take a stab at how the AF got validated with that
in it?
(03/17/93 Rosenbaum: {CR} also works)
--------------------------------------
You can also just press Return when you are asked for the output file and
it will go to your terminal. The advantage to this is that you can use
up-arrow the next time you are prompted for the input file.
(03/28/93 Bonine: Address validation.)
---------------------------------------
It probably had either the word AT or the character @. That makes the
address valid becuase it is a remote address. We had a case recently in which
one of our users typed what was supposed to be an auto-REPLY into the
auto-FORWARD address. People who sent him mail got a non-delivery to "I am AT
class this week . . .".
As for the mailbox, numeric mailboxes are always valid. In your case, the
mailbox was numeric. We're forever ending up with the mailbox named "1"
because someone meant to send to @A1 and left out the "A".
July, 1993 The DECUServe Journal Page 22
(03/29/93 Peach: The AT's have it -- & -- Problem with COPY function)
----------------------------------------------------------------------
I think you got it with AT ... we didn't think of that one.
Okay -- here's a question. You have OA$SHARE and OA$SHARD and OA$SHARE is
closed. But a couple of your templates still ist OA$SHARE and were used.
Were those users with mail area OA$SHARE actually writing there -- even those
it was closed?
And if that is true, is it "fixed" in 3.0? How did we find it. A user
called Assistance and reported getting "problem with COPY function" upon login
and GOLD W didn't show anything else [according to Assistance]. Another error
at RN or II of EMC menus pointed to error opening DOCDB.DAT but GOLD W reported
problems with file protection violation. The user had OA$SHARE as mail area.
When we checked -- I was surprised this was the FIRST report we'd had like
this. We had over 100 accounts created since we closed OA$SHARE and this was
the first time I heard about this problem.
Any ideas? Comments?
(03/30/93 Bowler: closed isn't)
--------------------------------
Yes, I'm in E (which is closed) and messages I send end up in E. It's
my understanding from talking to Atlanta that is still functions this way in
3.0. "CLOSING" and mail area is *ONLY* for the benifit of certain housekeeping
procedures (mostly BMA)., NOte that the 3.0 docs are even "more wrong" than
the 2.4 docs. The 2.4 docs IMPLY that you can't write there. The 3.0 docs
state outright that you can't.
(03/30/93 Peach: bug/feature? feature/bug? I hate bugs!)
---------------------------------------------------------
Well, how "wonderful". Do we describe this as a "bug" or a "feature."
My fix was to go out and change all the current PROFILes to OA$SHARD
(the OA$SHARE was over 750,000 *after* it was converted!). And then changed
all the templates.
Thanks Bruce for the 3.0 info on this.
So much for HSC Redundancy!
---------------------------
The following article is an extract of the DECUServe
Hardware_Help conference topic 1335. The discussion
took place between February 4, 1993 and February 14, 1993.
This article was submitted for publication by Sharon
Frey. Ed.
By David Johnson, Jorma Tapola, Terry Kennedy, Dale Coy, Keith Chadwick,
Brian Tillman, Carl Friedberg, Gus Altobello, George Cornelius
July, 1993 The DECUServe Journal Page 23
(02/04/93 Johnson)
------------------
We had a HSC50 die on us about 2 PM today. That's not so bad because all
of the drives are dual ported. However, when the HSC50 died it corrupted 5
drives. We have spent the last 5 hours restoring data and verifying other
drives on the HSC were valid. Field Service has not found any problems yet!
They think it was caused by the m.data module or the power supply. Needless
to say, it's out of here!
So much for dual porting and shadowing.
(02/04/93 Tapola: What are disk types ?)
-----------------------------------------
I'm curious. We've had many HSC crashes without losing data.
What type of disks are you using ? or are 100% sure it's HSC ?
(02/04/93 Kennedy: What sort of corruption?)
---------------------------------------------
Were these DEC drives, or 3rd-party "RA lookalikes"? There is a lot of error
checking built into the SDI protocol and I find it impossible to believe that
multiple DEC drive were corrupted by a SDI-related fault (I can believe that
one or more drives on a single requestor were affected, though).
However, there could be some subtle corruption introduced by a software
problem, or HSC software corruption introduced by a failing module or power
supply in the HSC, although a lot of that has extensive error checking as well.
I think we need to define what you mean by "corrupted" - was the data on the
drives just changed improperly (like writes went to the wrong blocks or drives)
or was there a loss of format or format inconsistency (the HSC VERIFY utility
should check this for you)?
(02/04/93 Coy: Thanks)
-----------------------
These were 5 shadow sets? With the members on different requesters but on
the same HSC? And Phase I shadowing?
Very curious. Of course, there is *NO* perfect hardware and/or software.
There will always be _some_ probability that a hardware failure in an HSC (or
some combination of multiple failures)
However, my long-term experience is that I have _never_ seen an HSC corrupt
anything on any disk. You may have been terribly unlucky. If so - thanks for
soaking up all of this century's log-probability failures. :-)
(02/04/93 Johnson: RA70s and RA90s.)
-------------------------------------
> We've had many HSC crashes without losing data.
So have we. We have also been using hscS for 6 years without anything
like this happening.
July, 1993 The DECUServe Journal Page 24
> What type of disks are you using ? or are 100% sure it's HSC ?
DEC RA70s and RA90. 5 drives were corrupted that were all mounted on
the same HSC. Yes, 100% sure.
(02/04/93 Coy: How about the shadowing?)
-----------------------------------------
Let me ask this again, then.
> These were 5 shadow sets? With the members on different requesters but
> on the same HSC? And Phase I shadowing?
Also, I understand how you feel. However,
Without dual porting, you can't do any failover. Is that better?
Without shadowing, you only have one copy. Is one better than two?
OK - let's say you had these 5 drives on a separate controller, with no
shadowing. And the controller failed and trashed the 5 drives.
The HSC doesn't seem to have made things worse for you. And it has
(probably) saved you a few times over the past 5 years. It's just not
absolutely and totally perfect.
(02/04/93 Johnson: More Details... )
-------------------------------------
More details...
I have had some sleep now so I will give you all more information.
Sometime yesterday afternoon, something happened to one of out production
HSC 50s. It never actually crashed. However, five out of the ten or so drives
that were mounted through it were corrupted. When the corruption occurred,
the drives tried to unsuccessfully fail over to another HSC.
Two of drives were a shadow set on different requester cards. After this
happened, these two drives were totally inaccessible from any member in the
cluster. When you tried to mount them a Fatal Controller Error message was
returned. This error occurred even if you tried to mount them from another
HSC. The HSC DKUTL utility indicated that all four copied of the RCT was
corrupt on both drives. We had to reformat the drives and restore from the
latest backup.
Another RA90 had the same RCT corruption problem. However, this drive's
shadow set was not effected at all.
Another shadow set of 2 RA92s had a few blocks corrupted but was still
accessible from the cluster. However, when an application would access these
blocks, a CLASS_DRIVER bugcheck would crash the node. At the same time, the
HSC serving the disk would produce an EDC error. We reformatted one of the
shadow set members and restored it from the latest backup. We still have the
other one off line. When I get a chance, I will run the HSC Verify utility on
it and see what it says.
July, 1993 The DECUServe Journal Page 25
All other drives that the HSC was serving at the time of the problem were
not effected. The drives that were effected were on different requesters.
Also note that we are running controller based shadowing. The current theory
is that power supply or the M.DATA module had a problem and that all the write
operations in progress were corrupted.
Don't get the wrong impression from this note. I think we are the victims
of a very rare HSC problem. Field Service told me that they have seen this
happen before. I think HSCs and shadowing are a good way to configure for
reliability. However, we are going to start looking at host based shadowing.
We have been using HSCs for over 6 years and we are currently running 8 of
them. This is the first time anything like this has happened!
(02/04/93 Coy: A rare event)
-----------------------------
Host based shadowing might not have helped much in this situation. You
_can_ configure host-based shadowing so that the shadow set drives are on
totally different HSCs. In the unlikely event that you had, this would have
saved a disk drive. However, you give up some big points in efficiency of
merge-copy operations.
I just switched our system from Phase I to Host-Based shadowing, mostly
for performance reasons. I am very happy with the results.
(02/05/93 Johnson)
------------------
Why, is the merge-copy performed differently when both shadow sets are on
the same HSC?
What kind of other performance gains did you see?
(02/05/93 Coy: HSC hardware assist)
------------------------------------
Writing from "fuzzy memory", yes. There is "hardware assist" for the Phase
II shadowing in (at least some of the) HSCs. At the most recent level of HSC
software. I'm sure this applies to HSC V650.
There is this distinction between "copy" and "merge" operations, that I
always get mixed up in my memory, and have to go check the book.
But I am certain about the "hardware assist" for some Phase II operations,
and (obviously) it only applies if the disks are on the same HSC.
(02/05/93 Chadwick: VMS V5.5-2 is also a requirement)
------------------------------------------------------
You must also be running VMS V5.5-2 to have the shadowing software take full
advantage of the HSC hardware assist for phase II shadowsets on the same HSC.
Refer to section 2.30 in the VMS Version V55.-2 Release Notes (pages 2-33
through 2-43).
July, 1993 The DECUServe Journal Page 26
(02/05/93 Coy: Uh-Huh)
-----------------------
Thanks for pointing that out. It's an important point, and I forgot to
mention it.
We just went to 5.5-2, installed a 7000-610 into the cluster, installed
8 more disks on our pair of HSCs, re-volume-named all of the disks (old and
new), and converted from Phase I to Phase II Shadowing. All in one week. [And
now you know why I can't seem to remember which things were prerequisites for
which other things]
To reiterate - I am very happy with the performance of Phase II Shadowing.
In our situation, it is performing noticeably better than Phase I Shadowing in
some respects - and there is no place that it is worse.
(02/06/93 Tillman: Phase II costs a lot more than Phase I)
-----------------------------------------------------------
I'd love to switch to Phase II shadowing, but it would be much too costly
to go out and buy licenses for the 30 workstations in our cluster that don't
have disks. As it is, we have shadowing licensed on the five CI nodes and they
serve the disks to the remainder of the cluster (those 30 other nodes).
That's one thing I have always wondered about. The *real* I/O requests
are still being performed by the CI nodes serving the disks to the NI nodes.
Why would the NI nodes need any shadowing software?
(02/06/93 Coy: If you don't need the MOUNT command...)
-------------------------------------------------------
See VMS Topic 1515. The basic reason is that Mounting a Phase II Shadowed
Disk requires it. [Now, maybe it _shouldn't_, but that's another question].
BTW - Note that there is special discounted pricing on Phase II Shadowing
licenses through the end of March 1993.
(02/07/93 Tapola: Backups are usefull!)
----------------------------------------
I'll like to point out - no doubt that everybody reading this thread knows
- that backups should be taken care of, even with any kind of hardware.
My fear is that RAID is going to raise questions like:"Why do we need
backups ?"
YES WE DO NEED BACKUPS?
(02/07/93 Coy: Of course)
--------------------------
I always answer with a question, simply -
What is the effect on your system of doing
DELETE [...]*.*;*
I have yet to find someone who continues to believe that Shadowing or RAID
N will eliminate the need for backups.
July, 1993 The DECUServe Journal Page 27
(02/07/93 Chadwick: Would you buy RAID from a used car salesman?)
------------------------------------------------------------------
As Dale has already poijnted out, RAID will cheerfully delete all portions
of the file when requested to do so by a suitably privilged user.
Another thing to watch out for - All the claims for RAID reliability are
based on calculations which assume uncorrelated failures.
A power failure/glitch and disks failing to spin back or the file system
being trashed by noise is classified as a CORRELATED failure.
The RAID vendors get very closedmouthed when you ask them about real world
experience and failure rates with their products...
(02/11/93 Friedberg: questions about HSC phase II shadowing)
-------------------------------------------------------------
I have no HSC's to play with these days (aside from the code inside the
RF73's) but I am curious why you would want to have members of a phase II
(host based) shadow set in the SAME HSC?
1) Availability considerations would suggest you benefit by keeping
members of the shadow set on different HSCs.
2) I don't recall the exact details of the restrictions onf 5.5-2
minimerge, but on the RF73's, it relies on the cache within the drive
(read, HSC) to keep a write-log, and thus can figure out which disk
blocks might be different on different shadow-set members. Naively, I
would guess (...) that mini-merge would also work on suitable HSC's (ie
meeting the stated minimum hardware/software configurations), with
members in different HSC's. I HOPE it works that way. COmments?
3) Performance: Yes, you would avoid the CI paths, etc., during full
copies, but how often do full copies get done, and how much difference
is there? Mini-merge is supposed to change the hours into seconds
(haven't had it happen yet, as we NEVER crash a node...)
4) I think there is VMS thread somewhere on satellite-nodes destroying
shadow sets (which I posted over a year ago in a SCSI-dual-host topic).
Yes, every node (satellite or direct-connect) masters each shadow set,
and any node can remove a member from the shadow set if it loses touch
with that member. I can't believe they did that, especially since VMS
engineers must work in clusters with LOTS of satellites constantly
booting in and out. All it takes is a brief fluctuation on the ethernet,
and you loose a member from your shadow set (at least, you start a full
copy in that case...) I hope this is fixed "in a future release?"
(02/11/93 Kennedy: HSC's only know about VAXen, not other HSC's)
-----------------------------------------------------------------
But HSC's don't maintain connections to each other - they don't even know
the other one is "out there". So the mini-merge needs to go HSC1 -> VAX -> HSC2.
The VAX can't even create a direct HSC1-HSC2 path.
July, 1993 The DECUServe Journal Page 28
(02/11/93 Coy: It's the "no free lunch" theory)
------------------------------------------------
> (1) Availability considerations would suggest you benefit by keeping
Exactly.
It is important to understand the availability issues with various
configurations (2 HSCs, same HSC and same/different requestor), as well as the
performance issues (merge, seek optimization, etc) and the cost issues.
If there were a single answer, we wouldn't be discussing it. In general,
performance can be better if the drives are all on the same HSC. But if the
HSC fails, performance goes to zero.
(02/11/93 Altobello: Has HSC failover gone away in Volume Shadowing Phase II?)
-------------------------------------------------------------------------------
I'm only running Phase I shadowing, but surely this isn't true? If a pair
of disks is dual-ported to HSC000 and HSC001, but both are being served by
HSC000 (to get the performance boost) and HSC000 fails, won't HSC001 pick them
up and continue running?
Where is the "zero" in all this? At worst, you'd get a full copy when the
new HSC picked the drives up.
Considering that I shadow because "drives fail", and backups aren't perfect,
and downtime is expensive (while one replaces the drive and restores the
backup); considering the performance boost you're reputed to get with Volume
Shadowing Phase II on HSCs with VMS v5.5-2; and considering how seldom HSCs
fail: Why doesn't it make sense to have the drives on a single HSC.
Remember, we're talking "high availability" here, not "high reliability"
-- none of this hardware provides the latter.
(02/11/93 Coy: Thanks for clarifying what I tried to say)
----------------------------------------------------------
>if the HSC fails, performance goes to zero.
Uh - please don't quote me out of context. Those two things were separated
by several lines of text. I was just trying (poorly, it turns out) to point
out that it is sometimes necessary to balance conflicting objectives, when
working with HSCs.
>served by HSC000 (to get the performance boost) and HSC000 fails, won't HSC001
>pick them up and continue running?
It sure will. The "availability considerations" are mostly the oddball
ones (not unique to Phase I) such as "how do you know the other HSC is OK" and
similar low-probability events.
> considering how seldom HSCs fail: Why doesn't it make sense to have
> the drives on a single HSC.
That's the way I have mine set up. The shadowed drives are on different
requesters in each HSC, and they are normally "ONLINE" to the same HSC. And
they fail over just fine.
July, 1993 The DECUServe Journal Page 29
OTOH, there are other configurations that might suit special problems.
For instance, there's mention around here of a (low-probability) HSC failure
that trashed both members of a shadow set. If that worried me a lot, I might
give up the performance boost.
(02/14/93 Cornelius: I would think mini merge would work.. )
-------------------------------------------------------------
>So the mini-merge needs to go HSC1 -> VAX -> HSC2. The VAX can't even create
>a direct HSC1-HSC2 path.
Yes, that's true if a mini-merge is a full merge. But isn't the idea
of a mini-merge the following:
1. Node crashes;
2. Second node asks controllers to return information concerning
operations that were in progress (from crashed node? from all nodes?)
to either shadow member at time of crash;
3. Second node performs appropriate block copy operations to make sure
that the data for any blocks being written by crashed node is the same
for both shadow members.
This being the case, all that is required is that the controllers have the
proper level of support, and that the "second" node have a path to both
controllers.
Now if the question has to do with full shadow copies being
controller-assisted, I would agree - it's hard to have controller-assisted
shadow copies if the two HSC's cannot talk to each other.
(02/14/93 Coy: Is this RAID 23?)
---------------------------------
Well, I sure thought that I said that you needed to have the disks on the
same HSC, in order to have HSC-assisted operations.
My feeble old brain can't keep straight what's a "mini-merge" and what's a
"merge-copy" and what's a "shadow-copy" and what's a
"maxi-merge-shadow-mini-copy".
Is there an x.400 "postmaster"?
-------------------------------
The following article is an extract of the DECUServe
Office_Automation conference topic 155. The discussion
occurred between April 19, 1993 and April 21, 1993.
This article was submitted for publication by Sharon
Frey. Ed.
By Bruce Bowler, Jean-Francois Mezei, Matt Holdrege, Larry Kilgallen
July, 1993 The DECUServe Journal Page 30
(04/19/93 Bowler)
-----------------
Not seeing it elsewhere and guessing that the X.400 mavens might hang out
here...
Is there an X.400 facility that is similar in concept to the internet
postmaster?
I have an address that I used to send to that no longer works. I don't have
a telephone number to call so that's out. I get the good old "catch all" error
message back "invalid parameters" . None of the local support people have a
clue. They can't tell me what the invalid params are or even who's generating
the message. I'd like to sned something to the "postmaster" at the ADMD and
see if they have an idea but I don't know what the right address is. In this
case, it's MCI but is there a general address to send to?
(04/19/93 Mezei: Postmaster concept not in X.400 standards)
------------------------------------------------------------
X.400 does not have "postmasters". They do support probe messages for you
to test to see if a username works or not.
The reason why they never set out to standardize on "POSTMASTER" is that
with X.500 directories, you won't need to send inquiries to "postmaster" since
you'll be able to do the directory search yourself.
(04/20/93 Holdrege: Other uses)
--------------------------------
Postmasters serve other functions on the Internet than directory lookups.
Usually they represent the e-mail authority for an organization. They are
someone to contact when an outsider has an unsolveable problem with a user in
a given domain.
BTW, X.400 questions of this sort should probably be relocated to the
Internetworking conferences.
(04/20/93 Bowler: tell me more)
--------------------------------
>X.400 does not have "postmasters". They do support probe messages for you to
>test to see if a username works or not.
So what can I probe and how do I do it (syntax-wise)?
Can I probe an ADMD to see if a PRMD is valid?
Can I probe an ADMD and have it tell me all its PRMDs (realizing that it
will likely be a *long* list)
Can I probe an ADMD/PRMD to see if an "xx" is valid?
(04/21/93 Kilgallen)
--------------------
The last time I subscribed to Internetworking, it was full of TCP/IP stuff.
July, 1993 The DECUServe Journal Page 31
(04/21/93 Holdrege: What's in a name?)
---------------------------------------
I don't think that Internetworking is tied to any particular protocol.
X.400 and SMTP are just two ways to send e-mail.
The main reason behind moving this to internetworking however, is to get
more exposure to the topic.
PATHWORKS problems w/ Windows V3.1
----------------------------------
This article is an extract of the DECUServe Pathworks
Conference topic 369. This discussion occurred between
April 9, 1992 and September 9, 1992. This article was
submitted for publication by Sharon Frey. Ed.
By Alan Striegel, Terry Kennedy, Bob Doherty, Rich Gray, Paul Grieggs,
Jack Patteeuw
(04/09/92 Striegel)
-------------------
Since I upgraded to Windows V3.1, I have encountered problems with the
SETHOST terminal emulator dropping characters from the COM1: port when run
full-screen with the network loaded. There is no problem using it this way
without the network running, no problem when SETHOST is run in a window, and
no problem with SETHOST run straight from the DOS prompt (not under Windows).
I also never had this problem before with Windows V3.0.
So, to lay out the setup, 33 MHz 386 clone, PATHWORKS V4.1, Windows V3.1,
MS-DOS V5.0, using HIMEM.SYS as supplied with Windows V3.1.
There are so many variables introduced in this upgrade, that I hardly know
where to start to find a fix. There is an entirely new SYSTEM.INI file, a new
SMARTDRV.EXE disk caching program, explicit inclusion of the PATHWORKS network
support supplied by Microsoft.
Has anyone else got this problem? Anybody solved this already?
(04/09/92 Kennedy: New driver wants 16550AFN UART)
---------------------------------------------------
I understand that there is a new comm driver in Windows 3.1. I was asked to
bid on that job (several years ago) and declined, so I don't know who actually
did the coding. Anyway, it supposedly performs much better when there is a
16550AFN UART installed. You might want to try one of those parts, if your
serial card has socketed parts.
(04/09/92 Doherty: Try increasing COMMBuffer1 in System.INI)
-------------------------------------------------------------
There is a cryptic comment in one of the readme files on the WIN31
distribution, stating that if the FASTDISK (32 bit disk access) is implemented,
that the Lock Application Memory box should be checked in the PIF file for
COMM products. From my experience, with MS Kermit 3.1, even if FASTDISK isn't
July, 1993 The DECUServe Journal Page 32
enabled, that box should be checked. Before doing it, Kermit gave random
hangs (big red switch hangs) and left no footprints in the DrWatson log. This
was with no network loaded.
We use LAT with SetHost, so I can't speak to your problem with it. There
is mention in the Resource Kit for 3.1 that lost characters on a serial line
can be avoided by increasing a COMMBufferx (or some such) from its default
value of 128. It also indicates that another parameter COMMProtocolx, can if
need be, be set to XOFF, to give XON/XOFF handshaking.
There is a section in the Resource Kit about the new driver and the
system.ini statements which control it. If I remember correctly, the 16550
support is off by default, i.e., SETUP doesn't detect the 16550 for you.
Considering the myriad of configuration possiblities in the PC world, the
WIN31 SETUP does an amazingly good job of conservatively configuring the
system. I run Stacker at home, and it detected it, and kept the two copies of
config.sys and autoexec.bat in sync, as it modified them.
(04/09/92 Gray: Not Supported?)
--------------------------------
Last year in August, I placed my first trouble call to Dec support in
Atlanta. I was having problems with vt320 hanging during a term/inquire due to
lost characters. I was told by Dec that the SPD for PCSA says it does not
support simultaneous eithernet and async connections. I have since learned much
about pc's, windows, pathworks, and DEC SUPPORT.
I would bet that the problem would be solved by following Bob Doherty advice
in 369.2 (CommProtocolx). Will be anxious to hear the results.
(04/11/92 Grieggs: Try SETHOST /R )
------------------------------------
I have resolved async SETHOST problems with the command:
SETHOST /R
According to Atlanta support, the /R qualifier "rotates the hardware
interrupt priorities so that the async port is the highest".
My problems occured on 386 systems with EMM386.EXE and Pathworks PSC.COM
both loaded. SETHOST /R resolved the problem with SETHOST.
(04/13/92 Gray)
---------------
Thanks for posting the fix for sethost. It's also nice to hear something
good about Atlanta.
(04/17/92 Striegel: Only one thing works - not a good answer)
--------------------------------------------------------------
The results of making many modifications turned up only one way of making
it work and that answer is unacceptable. I tried the SETHOST /R switch with
no effect.
July, 1993 The DECUServe Journal Page 33
I also modified the following parameters in the SYSTEM.INI file to no
effect:
COMMBuffer1
COMMProtocol1
COMBoostTime
I even tried modifying the NCP parameters to see if I could help this by
increasing the buffers or decreasing the buffers.
In the end, the only thing that worked was to load all the network
components into conventional memory instead of using EMSLOAD to put them in
expanded memory (created by EMM386). I suppose that tells me there are delays
in switching to the expanded memory. But this takes up so much conventional
memory that my most important DOS applications (XTREE Gold, Lotus Magellan) will
not run correctly.
As I said, this never happened with Windows V3.0 and I would still hope
there is some value I could modify in the SYSTEM.INI to return this to normal.
(06/03/92 Striegel: How I got around the problem)
--------------------------------------------------
Revisiting the issue when I could no longer stand to be without the network
when using serial ports, I resolved to fix the problem once and for all. The
answer to my problems was, in the end, to stop loading anything into EMS and
use UMBs instead. This was an adventure in itself.
I reasoned that since I wasn't going to need the E000-EFFF area of memory
for a page frame, it should be available as UMBs, but Microsoft takes the
conservative approach and never touches this space unless you force it to.
Same is true of B000-B7FF (what they call the Monochrome Display Adapter --
MDA area). They were available and worked for me after I made a change to the
line in my CONFIG.SYS where I load EMM386.EXE:
DEVICE=\EMM386.EXE D=48 I=B000-B7FF I=E000-EFFF NOEMS
Then I had to find out the optimum order for loading all my device drivers
and networking TSRs into the 124 KB of UMBs this had made available (it had
already discovered the C800-CFFF area). I won't go into that since it will
vary for others. My STARTNET.BAT file needed to be edited to use the LH
(LOADHIGH) command for the components that would fit in upper memory blocks.
The final piece to the puzzle is that to make Windows work in 386 Enhanced
mode requires a special driver, MONOUMB.386 which is not provided on the
Windows diskettes. I got this file from Compuserve, then edited my SYSTEM.INI
one last time to add in the [386enh] section:
DEVICE=MONOUMB.386
Now my programs have plenty of conventional memory and my serial ports
behave properly. I just have to stay away from EMM386.EXE as an EMS provider.
July, 1993 The DECUServe Journal Page 34
(06/23/92 Gray: 9600 baud in enh?)
-----------------------------------
Do you use 9600 baud or over in 386 enhanced mode. I have problems with
flow control in enhanced mode at these speeds.
(06/24/92 Striegel: 9600 baud in 386 enhanced mode)
----------------------------------------------------
Yes, I only use 9600 baud for serial connections and I only use 386
enhanced mode. As I mentioned, as soon as I stopped using Expanded Memory the
problem went away.
(09/04/92 Patteeuw)
-------------------
Sorry for jumping in a bit late but I have a question and a comment.
Just what does MONOUMB.386 do ?
We use QuarterDeck's QEMM386 (V6.x for DOS 5) with very good results. It
has some good tools for checking where device drivers get loaded. With it's
"stealth" mode I have seen people with over 620 Kb of conventional memory with
a network running !
In general, no one around here uses EMS but I understand this will change
as the new version of FTP Corp's TCP/IP loads itself into entirely into EMS.
(09/09/92 Striegel: MONOUMB.386 makes Windows happy)
-----------------------------------------------------
Windows always tries to use all unused portions of the UMBs for itself
when it starts up. For users with EMM386.EXE creating the UMBs, when you
explicitly include the Monochrome Display Adapter (MDA) memory area (B000-B7FF)
as Upper Memory Blocks (UMBs), unless the MONOUMB.386 driver is present,
Windows will refuse to start.
If you are using Quarterdeck's QEMM386, you are supposed to use the
MONOUMB1.386 which Microsoft nicely included on the Windows diskettes.
Computer Humor
--------------
The following article is a brief extract of the DECUServe
Shop_Talk conference topic 20. This discussion occurred
between April 22, 1993 and April 24, 1993. This article
was submitted for publication by Jeff Killeen, DECUServe
Contributing Editor. Ed.
By Sharon Frey, Dale Coy, Saul Tannenbaum, Matt Holdrege, Matt Snoeyenbos
(04/22/93 Frey: you know you're on DECUServe)
----------------------------------------------
I made these up the other day. Anyone have others?
July, 1993 The DECUServe Journal Page 35
You know you're on DECUServe when:
o You post a personal introduction in the Who_am_i conference and people
argue about who gets to post the first welcome.
o You post anything in the 1st_timer's conference and people *politely*
tell you where to go.
o You post a FAQ or a "stupid question" and receive many detailed answers
and/or pointers to more information. (Go ahead and remove your
fire-retardant coveralls. And remember: there is no such thing as a
stupid question on DECUServe.)
o You commit a "social blunder" like mis-naming a topic header or TYPING
ALL IN CAPS, and your mailbox isn't filled with flames. Instead,
several very kind people advise you of the mistake. If you don't
correct your mistake (like a mis-named header), then one of the very
considerate moderators will do it for you. (And he won't set it to
anything like "Dimwit wants to know", either. :-) )
o Your posting contains a few four-letter unprintable words, and scant
hours later you find that it's been "set hidden". Don't worry, soon
you'll receive a friendly phonecall from a moderator who will read to
you from Ms. Manners' latest column. Take this to heart.
o You post an incorrect or incomplete answer to a question and nobody sends
you email questioning your IQ and vilifying your heritage.
o You don't have to weed through three pages of headers in order to read
a reply. Nor do you have to wade through three pages of trailers before
you get to the next one. (Or .sigs for that matter!)
o If you have a problem with any of the programs on the system or the way
things are run, you don't have to grit your teeth and live with it. You
just raise your hand (metaphorically speaking) and XCOM will be overjoyed
to let you help fix the problem/implement the program.
o The most-used TLA's are: The least-used TLA's are:
IMO RTFM
IMHO :-Q
BTW
IANAL
:-)
(04/22/93 Coy: Sign me up!)
----------------------------
I love it! And I won't even complain about...
> o You post anything in the 1st_timer's conference and people
Because
> speaking) and XCOM will be overjoyed to let you help fix the
July, 1993 The DECUServe Journal Page 36
(04/23/93 Tannenbaum)
---------------------
These are all great, but...
> o The most-used TLA's are: The least-used TLA's are:
> IMO RTFM
Doesn't this one violate the language canon? :-)
(04/23/93 Holdrege: 8-) 8-) 8-) 8-) )
--------------------------------------
> o The most-used TLA's are: The least-used TLA's are:
> IMO RTFM
Gosh Sharon, don't you know that RTFM is a FOUR-LETTER ACRONYM!!!
8-) isn't an acronym AT ALL!!!
JEEZ, some people.
Oops. I thought I was on Comp.os.vms. Sorry!
<(04/23/93 Frey: oopsie)
------------------------
> o You post anything in the 1st_timer's conference and people
> *politely* tell you where to go.
Wups. Of course I meant 1st_Aide. That's what I get for doing this
at home! Oh well, it helped prove one of the latter points. :-)
> o The most-used TLA's are: The least-used TLA's are:
> IMO RTFM
Well I've seen RTFM used here occasionally, so I don't think the letters
are against canons. But it's never been used as a directive, which was my
point. And I stretched a bit with the faces. They're Three Character
Symbolics: TCS's. Okay, okay. :-Q :-)
(04/24/93 Snoeyenbos: All in the mind of the beholder)
-------------------------------------------------------
> Well I've seen RTFM used here occasionally, so I don't think the letters
>are against canons.
Of course they aren't. When used in polite society such as this, they stand
for "Read The Fine Manual".
In fact, being in such company, I have no idea what else they could stand
for. ;-) ;-)
July, 1993 The DECUServe Journal Page 37
OSF/1 VMS Performance
---------------------
This article is an extract of the DECUServe Unix_OS
conference topic 189. The discussion occurred between
April 13, 1993 and April 18, 1993. This article was
submitted for publication by Sharon Frey. Ed.
By Robert Aldridge, Matt Holdrege, Terry Shannon
(04/13/93 Aldridge)
-------------------
We have our first AXP OSF/1 system now.
Besides getting our feet wet in "unix" we are also getting our feet wet in
"Alpha AXP."
Just curious about performance-- if I ran the same benchmark program on
this AXP OSF/1 system and on this AXP system running VMS, would the benchmark
results be similar?
In other words, how much performance variation can be attributed to the
choice of operating system?
(04/13/93 Holdrege: The war of the OS's)
-----------------------------------------
Opening the proverbial can of worms...your question reminds me of many
a religious war on Usenet.
VMS and OSF/1 are very different OS's with different dependencies. RMS has
more overhead then OSF/1's file system. Simply creating a file takes more CPU
cycles on VMS. But RMS gives you more control of your filesystem, thus making
the application more powerful. Thus goes the argument.
The best advice is to choose your application first. If it runs on both
OS's, then see which one is the fastest.
You can contact DEC to get the results of each different SpecMark for the
two systems. If you are attending DECUS symposia, you may find this available
from one of the DEC performance gurus.
(04/18/93 Shannon: OSF/1 Slightly Faster.)
-------------------------------------------
According to the figures that have been published so far, OSF/1-based
SPECnumbers are --in general-- several percent better than OpenVMS-based SPEC89,
Specfp92 and Specint92 numbers.
How to start a process with different owner
-------------------------------------------
The following article is an extract of the DECUServe Unix_Os
conference topic 194. The discussion occurred between
April 29, 1993 and May 20, 1993. This article was submitted
for publication by Sharon Frey. Ed.
By Jay Nelson, John Burnet, Matt Holdrege
July, 1993 The DECUServe Journal Page 38
(04/29/93 Nelson)
-----------------
I've just started to do a lot of work on UNIX so this may be a real simple
question.
How do I start a detached process from within the system boot command files
(rc.local) with an owner other than root? I've tried a command file with the
su <username> at the begining but it doesn't work.
Can anyone offer suggestions?
BTW: As you can tell from the wording (process, command file), I'm mostly a
VAX person. I've been through some of the DECUS UNIX for VAX Bigots courses
and a couple of AIX courses but this one has me stumped.
Thanks in advance.
(04/29/93 Burnet: Setuid stuff can be tricky)
----------------------------------------------
[Ignorance "claimer": I might be missing a very simple way to do this.
If so, someone please correct me.]
Question: Can you give more details about the situation? What is the
program going to be doing?
I don't think there is any equivalent of VMS's SUBMIT/USER. What you would
have to do is to start the process, then have it use a setuid() call to
change its user ID. So, if the program is called /etc/my-utility, the
command in /etc/rc.local would be
/etc/my-utility &
and the program that you compile to get that executable file would call setuid()
as the *first* thing (and would immediately exit if the call fails). The uid
should be hard-coded into the program, and of course the file must be owned by
root.
A less desirable alternative, which doesn't involve any programming, would
be to make a copy of the program that you want to run (in a root-owned
directory, like /etc), use the chown command to change its owner, use the chmod
command to set the setuid bit in the file's "modes" mask, then just run that
copy of the command instead of the original. The program could even be sh or
csh if you want to run a whole shell script as someone else. While the program
is running, the process's *effective* uid will be set to the owner uid of the
file. (The real uid will still be zero if the parent process was running as
root.)
There are serious security risks associated with this approach, particularly
if the "target" uid is zero (root) or some other uid that can be used to cause
damage on your system. This should *never* be done using a "privileged" target
uid. (Setuid-root programs are one of the biggest potential security risks on
a Unix system; they're equivalent to images installed with SETPRV on a VMS
system. You wouldn't want just anyone to be able to install an image of his
choice with SETPRV, nor would you install it for him at his request.) But if
the process is starting out as root and changing to a uid of a non-privileged
July, 1993 The DECUServe Journal Page 39
user (in the direction of more --> less privilege), it should be OK as long as
you're careful to set the file's modes to disallow all access to users other
than the owner. (The mask, including the setuid bit, would be 4700.) And then
you have to consider that the owner can overwrite the file, change its
protection modes, etc., which is usually not desirable for things that will be
run at system startup and that aren't owned by root.
(04/29/93 Burnet: More about su)
---------------------------------
Here's an idea... have you tried putting the password in a "here document"?
(The VMS equivalent is SYS$INPUT, read from the command file.) The shell
syntax is "<<something", where "something" is a string of your choice that
indicates EOF.
su some_user <<THE_END
password-for-some_user
THE_END
# other commands...
However, this is not recommended, since the password appears in the shell
script.
(04/30/93 Holdrege: su)
------------------------
Did you put a - (dash) after su? This forces a full login. Check out the
man page on su.
(05/08/93 Nelson: What I've tried so far)
------------------------------------------
Things I've tried so far.
Setting the 4000 bit with CHMOD. It appears this only works with ROOT
user going to someone else. Root always starts processes with root owner.
I checked SU on AIX and the include the syntax su <name> "-c command".
Unfortunately, ULTRIX doesn't support this. Who said UNIX was a standard.
I've tried all forms of SU < > << >> csh sh and anything else.
The second problem I ran into is that I gave up the hardcopy documentation
assuming the CD-ROM documentation included everything I needed. This is one
big *NOT*. The CD-ROM doesn't include the reference pages. Since I don't
have CSC support, I'm really out on a limb.
Could writing a program to do setuid and then fork the other process be
an option? It is a simple program to start. They way it's started now is
cd /usr/xyz
xyz -switch value -switch value -switch
Any ideas?
July, 1993 The DECUServe Journal Page 40
(05/08/93 Burnet)
-----------------
The way it should work is that with the 4000 bit set, the owner uid of the
file becomes the process's effective uid when the program is run. Does this
not work, even after you "chown" the file to give it a new owner user id and
group id?
>Unfortunately, ULTRIX doesn't support this. Who said UNIX was a standard.
Well, Ultrix sure isn't. :-}
>The CD-ROM doesn't include the reference pages.
The reference pages are in the Ultrix distribution kit; everyone has them,
but anyone can choose not to install them. If they are installed on your
system, then the "man" command will work (for instance, "man su" or "man 1 su").
If they aren't installed, you can always pull them off the kit. They're in
nroff source form; the catman(8) program is used to format them.
>Could writing a program to do setuid and then fork the other process be an
>option?
Sure, that would work. (Actually, it would be a fork followed by a setuid.)
I'm posting UNTESTED (sorry!) source code for a simple program like this in the
next reply.
(05/08/93 Burnet: Simple program to run a command as another user)
-------------------------------------------------------------------
/*
* Put the desired uid, gid, directory, and command string here.
* (A much better method would be to accept a username and a command string
* as command-line arguments and then to use getpwent() to look up everything
* else in the password file... but this is just a quick hack anyway.)
*/
#define THE_UID 42
#define THE_GID 42
#define THE_DIRECTORY "/usr/xyz"
#define THE_COMMAND "mumble frotz"
#include <stdio.h>
extern int chdir(), fork(), setgid(), setuid(), system();
int main()
{
int pid;
switch (pid = fork()) {
case -1: /* failed */
perror("fork");
return 1; /* fork() failed in parent */
July, 1993 The DECUServe Journal Page 41
case 0: /* child */
if (setuid(THE_UID) || setgid(THE_GID)) {
fprintf(stderr, "setuid or setgid failed.\n");
return 2; /* can't set user or group id in child */
}
else if (chdir(THE_DIRECTORY)) {
perror("chdir");
return 3; /* chdir() failed in child */
}
else if (system(THE_COMMAND)) {
perror("system");
return 4; /* system() failed in child */
}
else
return 0; /* everything succeeded in child */
default: /* parent */
fprintf(stderr, "pid of child process is %d.\n", pid);
return 0; /* fork() succeeded in parent */
}
}
(05/10/93 Nelson: I found the reference pages.)
------------------------------------------------
> The second problem I ran into is that I gave up the hardcopy documentation
>assuming the CD-ROM documentation included everything I needed. This is one
>big *NOT*. The CD-ROM doesn't include the reference pages. Since I don't
>have CSC support, I'm really out on a limb.
You can ignore this, I found them.
Thanks for the code listing... I'll try it to see if it works.
(05/20/93 Ohara: sun/os 4.1.3)
-------------------------------
The following works on sun to start a background process from root as
another user.
/bin/su user -c "command/background process"
The device is, uh, illogical
----------------------------
The following article is an extract of the DECUServe VMS
conference topic 928. This discussion took place between
April 9, 1990 and April 17, 1990. This article was
submitted for publication by Alan Bruns and Don Roberts,
both DECUServe Contirbuting Editors. Ed.
By Kevin Angley, George Merriman, Linwood Ferguson, Thomas Sammons,
John Burnet, Barry Suskind, Larry Kilgallen
July, 1993 The DECUServe Journal Page 42
(04/09/90 Angley)
-----------------
I have an old application for which source is not available which makes the
assumption about the name of a particular device, say XXA0:. The device that
it needs to use today is named YYA0:.
You would think that I could ASSIGN YYA0: XXA0: and fool it, but this didn't
work. I disassembled the code and it apparently is specifying _XXA0: (with the
underscore).
Is there any way to override its overriding logical names?
(04/09/90 Merriman: Try brute force)
-------------------------------------
If you got this far, can't you patch the image to stuff another name in the
same space -- a name that you can use as a logical in the run-time context?
(04/09/90 Ferguson: Like _xxA0 => LOGA0; LOGA0 = "yyA0")
---------------------------------------------------------
(04/10/90 Sammons)
------------------
Would a concealed logical name work ($ASS/TRANS=CONCEAL)?
(04/10/90 Angley: Looking for an elegant solution)
---------------------------------------------------
Well ... I hadn't thought about patching the .EXE .. that almost makes this
too scary to pursue.
I believe I tried the concealed attribute. Same result.
(04/10/90 Burnet: No FUD necessary -- just ZAP that '_' outta there)
---------------------------------------------------------------------
Don't be scared -- it's easy! Take a look at the manual for the PATCH
utility. Or, if you have VAX RSX installed, use HEXZAP. :-}
Seriously, patching the image is likely to be by far the easiest method
of solving the problem.
(04/11/90 Ferguson: Patching for the timid)
--------------------------------------------
Agreed. Doesn't sound like there will be a more elegant solution
forthcoming.
If you haven't done it before, some things to know: Unless you tell Patch
differently, it creates a new image so you still have the old. Save a copy
anyway in case you accidently tell it differently.
It creates a .JNL file with a record of what you did in case you want to
go back later and figure out where something happened (or recreate the patch
for a new version of the same image).
You can patch in absolute mode (basically each byte of the file is addressed
July, 1993 The DECUServe Journal Page 43
from the beginning of the file - can be used for all types of files including
fixing up RMS indexed files that are corrupted) or regular mode which knows
something about the image and lets you address things by addresses
corresponding to offets. Either sounds usable in your case.
Just change the "_" to a blank; the "_" is what is keeping the system from
translating it. Underscores are an intended way of saying "do not let anything
treat this as a logical".
If for some reason that doesn't work, it may be because something doesn't
like the space (unlike); in that case change it to an "X" or something and
define a logical accordingly.
(04/17/90 Suskind: use VFE to hack programs)
---------------------------------------------
Easy to hack the image....
Just use the DECUS program VFE to modify the image. Edit the file with VFE
(write enabled). Use the command:
lo '_XXAA'
to find the bad device name. Use the command:
cha byte location, 'YYAA'
(remember to zero terminate the string)
Use the command:
a
to display your work in ascii. Use the command:
write
to update that block of the file.
I have used VFE to hack images for years.
(04/17/90 Kilgallen: Have you been using "C" too long ? :-))
-------------------------------------------------------------
What makes you think that is a zero-terminated string?
For best results, I would suggest making it a 5 character name.
July, 1993 The DECUServe Journal Page 44
Why is SYS$COMMON an alias?
---------------------------
This article is an extract of the DECUServe VMS conference
topic 929. This discussion occurred between April 9, 1990
and March 06, 1990. This article was submitted for
publication by Don Roberts, DECUServe Contributing Editor.
Ed.
By John Osudar, Linwood Ferguson, Al Hunt, Tom Gerhard
(04/09/90 Osudar)
-----------------
Is there a legitimate reason for the way VMS sets up access to the "common"
portion of the system root, i.e. entry of an alias for the [VMS$COMMON]
directory in each root, as [SYSx.SYSCOMMON]?
SYS$SYSROOT: is currently defined to be the search list:
device:[SYSx.] (translation concealed and terminal)
SYS$COMMON: (no translation attributes)
and SYS$COMMON: is
device:[SYSx.SYSCOMMON.] (translation concealed and terminal)
What would be wrong if SYS$COMMON: were instead defined to be:
device:[VMS$COMMON.] (translation concealed and terminal)
and no alias entries were made?
Is there something, somewhere, that depends upon all the system files being
in device:[SYSx...]?
(04/09/90 Ferguson: Why?)
--------------------------
Don't do it if you ever want a cluster.
Also, there are lots of things that use SYS$SPECIFIC:[...],
SYS$COMMON:[....] and SYS$SYSROOT:[...] explicitly. You would need to get
these defined correctly (I assume all the same), and I think that's done by
part of the startup process (perhaps) beyond your control.
Is there a savings that makes it worth the effort, or just curiousity?
(04/10/90 Osudar: You misunderstood my question...)
----------------------------------------------------
I *have* a cluster, eight nodes, that does production work -- which is why
this note isn't a report on "experimental computer science" ;-) In my cluster,
SYS$SYSROOT has *three* elements -- the two standard ones, followed by
LAVC_COMMON, which is a concealed and terminal logical name pointing to
clustercommondisk:[LAVC_COMMON_ROOT.]
July, 1993 The DECUServe Journal Page 45
The latter is where my SYSUAF, JBCSYSQUE, and other cluster-wide files are
located.
I also understand the *historical* reasons for things being as they are, as
far as the standard definitions of SYS$SYSROOT and SYS$COMMON.
You misread my question.
I'm not suggesting going back to the "standalone system disk" structure
of pre-V5.0 days. I just want to know why the definition of the logical name
SYS$COMMON has to be disk:[SYSx.SYSCOMMON.] and can't be disk:[VMS$COMMON.]
since one is an alias for the other. SYS$SYSROOT and SYS$SPECIFIC would remain
completely unchanged.
So, the question is: is there any remaining *technical* reason for
SYS$COMMON to continue to point to an alias entry?
A lot of problems, ranging from annoyances (getting multiple copies of your
common system root backed up on non-image backups) to real headaches (the
recent VMS$COMMON vs. SYSCOMMON problem with restored backups) result from the
use of an alias entry for the common directory. (What actually bugged me enough
to ask the question was an attempt to find a file in *one of* my system roots
using DIR -- if you say DIR disk:[SYS%...]filename you look at the common
directory tree *N* times, if you have N system roots on the disk!)
(DEC even tells you, in the documentation for SET FILE/ENTRY, "don't ever
do this!" -- then they go ahead and base a critical part of the whole system
structure on it...)
If it isn't necessary, then it seems stupid to continue doing this. I want
to know if it *is* necessary, and if so, why? (If it's not necessary, some
brave souls among us might try to change it ourselves -- and the rest of us
can ask DEC to change it, via the SIR process or by screaming at them twice a
year at symposia... ;-)
(04/10/90 Hunt: A theory?
--------------------------
This is not a strong reason but one possibility. Under VMS V4 the directory
was named V4COMMON.DIR but under VMS V5 it was changed to VMS$COMMON.DIR.
Before VMS V5 came out, I thought we might see V5COMMON.DIR. I wonder if there
is some hidden use during part of the upgrade process where a common name can
be coded in the system (SYS$COMMON.DIR) but externally can be different in the
MFD.
This is just a shot in the dark.
(05/06/90 Gerhard: Could multiple 'common' roots work?)
--------------------------------------------------------
The way this is setup up makes me curious if DEC might have been thinking
about supporting more than one common root on the same system disk. If you
set up something like this:
Root Common alias
SYS0 VMS$COMMON
SYS1 VMS$COMMON
SYS2 TEST$COMMON
it would be *almost* the same as if the SYS2 root were on another system disk.
I don't have the courage to try this, but it seems that all references to the
July, 1993 The DECUServe Journal Page 46
common directory are via SYS$SPECIFIC:[SYSCOMMON] or some equivalent, and that
there is no real way to determine (or reason to care!) what that is equated to
via the directory entry.
Might be helpful when a rolling upgrade is needed for a single system ßdisk
cluster....
The Journal Questionaire
------------------------
The DECUServe Journal has been in the Internet community for over six months
now, and we here at DECUServe are curious about its audience. From informal
mail messages and requests for information, we have been very impressed with
the warm reception. But I'd like to get a better feel for what you think and
how the Journal fits into the community. And how I can make it better.
Notice that there are NO marketing or financial type questions here. We
are aiming solely for demographic data.
Please answer each question succinctly, using the question number and the
answer letter wherever possible. Try not to quote the questions, but if your
selected answer has a fill-in blank then please fill it in. Also feel free
to send a reponse for a peer who reads the Journal but who does not have an
email address (just say "this is for friend X"). Although names and companies
are frequently shown in the email headers, they are not important and will be
ignored.
If a majority of responses would like to see the compiled results, I will
publish them in an upcoming issue.
Send your response to me at fr...@eisner.decus.org.
1) How do you receive the Journal? (Check all that apply.)
A. vmsnet.decus.journal (Internet newsgroup)
B. comp.org.decus (Internet newsgroup)
C. A and/or B, whichever
D. Mailing list
E. CompuServe
F. Passed on from a coworker/peer/friend
G. As part of a DECUS membership package
H. Other: _______________________
2) How do you prefer to read it? (Check one.)
A. Printed in hardcopy format
B. Downloaded, but viewed on a terminal/PC/Macintosh screen
C. Viewed in a newsreader
July, 1993 The DECUServe Journal Page 47
3) What technical areas are you most interested in? (Check all that apply.)
A. VMS topics
B. Unix topics (and various "flavors" of Unix)
C. Digital Hardware topics
D. Digital Software topics (not including operating systems)
E. 3rd party hardware/other manufacturers of mainframes/mini's
F. 3rd party software
G. PC and Macintosh hardware issues
H. PC and Macintosh software issues
I. Networking and Connectivity Issues (LAN, WAN, or Internet)
J. General IS topics (semi- or non-technical)
K. Specific topic(s): ______________________
4) What is your preference for an optimum size of Journal? (Please check
only one.)
A. less than 20 pages
B. less than 40 pages
C. less than 60 pages
D. less than 80 pages
E. less than 100 pages
F. more than 100 pages
5) How often do you find the Journal useful in direct relation to your work?
A. All of the time
B. Most of the time
C. Sometimes
D. Rarely
E. Never
6) How often do you find the Journal useful to you from a career perspective?
A. All of the time
B. Most of the time
C. Sometimes
D. Rarely
E. Never
7) What country do you currently live (and/or) work in?
8) What types of trade magazines and journals do you currently subscribe to?
(Check all that apply.)
A. Those relating primarily to Digital products
B. Those relating primarily to other mini/mainframe vendors' products
B. Those relating primarily to PC products
A. Those relating primarily to Macintosh and Apple products
C. General technical computer journals
D. General non-technical computer journals
E. None
July, 1993 The DECUServe Journal Page 48
9) What professional organizations and/or clubs do you currently affiliate
with? (Check all that apply.)
A. ACM
B. IEEE
C. DECUS (Any chapter)
D. Other: ___________________
E. None
10) Which of the following best describes your job function?
A. System Administrator/Manager (technical)
B. Information Systems Administrator/Manager (non-technical)
C. A. and B. combined
D. Computer Security Specialist
E. System Operations
F. System Programming (scientific, operating systems, and/or utilities)
G. Business Programming (Business applications)
H. Network Hardware maintenance and design
I. Kind-of everything above
J. Not directly related to computers except that I use them alot
(Engineer, CEO, etc.)
11) I would like to see the compiled results of this survey in a future issue.
A. Yes
B. No
July, 1993 The DECUServe Journal Page 49
Technical Information
---------------------
Publication Information
-----------------------
Topic threads in the DECUServe VAXNotes conferences are selected for
publication on the basis of strong technical content and/or interest to a wide
audience. They are submitted to the editor by a team of Contributing Editors
who are DECUServe Moderators, Executive Committee members and other volunteers.
Articles in the DECUServe Journal are downloaded to a 286 PC and formatted
using a standard text editor.
Editorial Content Disclaimer
----------------------------
Opinions and information presented here belong to each individual author.
No inferences should be made that the authors are expressing the policies of
their employers unless specifically stated. Content has been deemed acceptable
by the Moderators of DECUServe according to the DECUServe Canons of Conduct.
How can I use DECUServe?
------------------------
DECUServe is available 24 hours a day, 7 days a week, except for the last
Thursday of each month at 5pm Eastern time for backups. Membership is by
individual subscription only, and subscriptions are sold on a yearly basis
currently for $75.00. Subscription forms are always included in DECUS New
Member packets and Symposia registration packets. Six-month subscription
forms are often distributed at symposia as well.
Foreign DECUS chapter members are invited to subscribe as well, although
they must do so through their chapter office. Forms and price details can be
obtained from the chapter office.
Also subscription forms can be downloaded directly from DECUServe by dialing
1-800-521-8950 with the username INFORMATION. Set your modem to 2400 or 9600,
1 stop bit, 8 bits, no parity. Internet access is also available.