DECUServe Journal Part 2
Sharon Frey
December, 1993 The DECUServe Journal Page: 44
(08/17/93 Tinkelman: Not an answer, but a pointer to a source of info.)
------------------------------------------------------------------------
The O'Reilly & Associates book titled
!%@::
A Directory of Electronic Mail Addressing & Networks
ISBN: 1-56592-031-7
is usually a good source for information like this. In this case, it
contains three forms of addressing mail to MCI users:
accou...@mcimail.com
mci...@mcimail.com
full_us...@mcimail.com
none of which addresses your question.
The standard way to get questions like this answered would be to send a
querry to postm...@mcimail.com with as much details as you feel would be
helpful.
The !%@:: book also lists the following contact information for MCI
Customer Service:
+1 800 444 6245 (US only)
email: 3248...@mcimail.com
My personal style would be to first send mail to postm...@mcimail.com,
and then if that failed to try customer service.
(08/20/93 Hull: Digital policy on Internet addresses)
------------------------------------------------------
The style for addressing Digital folks that is approved by our own
Corporate Security is the MTS address style, namely:
first...@sitecode.mts.dec.com
where sitecode is their office site code. For instance, my address is
alan...@ohf.mts.dec.com
This is exactly the same as we use internally to address to anyone in the
corporation via ALL-IN-1: Alan Hull @OHF The area routers take care of
translating the site code to real node addresses.
The other style, ...@node.enet.dec.com, which uses actual Easynet node
names, certainly works, but according to our security rules, we are not
supposed to give out that style address, since it reveals node names. The MTS
style reveals no nodenames and is therefore approved.
I guess they don't realize that the first time we send out a message to the
outside world all the node reverse path is there anyway...
I won't tell. 8^)
December, 1993 The DECUServe Journal Page: 45
(08/30/93 Backstrom)
--------------------
The
first...@sitecode.mts.dec.com
is a Message Router address, which Digital employess can have redirected to
ALL-IN-1 IOS, DEC MAILworks, VMS Mail, SMTP, or whatever.
I.e. it does not necessarily imply an ALL-IN-1 address.
(09/01/93 Diddle: Fidonet net?)
--------------------------------
A friend of mine is trying to send mail from Internet to Fidonet. Anyone
know the correct format? The Fidonet address is
1:151/183
According to Note 167.4 'Inter-Network Mail Guide' the correct address
format for sending from internet to fidonet is:
"First...@f183.n151.z1.fidonet.org"
This does not seem to work and there has been no return. It just
disappears and is never seen again.
(09/02/93 Boykin: X.400 users at MCI Mail)
-------------------------------------------
>can anyone give me the exact form of addressing an X.400 user at MCI Mail
>from the Internet?
I have found an address format that will allow users on the Internet to
address e-mail to MCI Mail users at X.400 links.
SN=lastname%S=lastname%G=firstname%prmd...@MCIMAIL.COM
A call to the MCI Mail help line confirmed that both the SN and the S
qualifiers should point to the user's lastname. I believe that MCI uses one
of these and our X.400 gateway needs the other one.
The SN and the S appear to refer to the Surname portion of an X.400
address and the G represents givenname.
(09/07/93 Eden: fidonet address ok)
------------------------------------
You have the fidonet address correct. Mail from the internet to fidonet
isn't the most reliable.... it works to some nets but not to all. Don't
expect a bounce if it doesn't work.
You may want to start by asking your friend if he can receive "netmail".
Some boards don't support this. You may also have his sysop (if the node
address isn't his) check with the local EC.
December, 1993 The DECUServe Journal Page: 46
(09/09/93 Norman: ex)
----------------------
Thanks for the mail guide and pointer to the book. Since neither will fit
in my pocket, ;-) I'll try to update this list which leaves out a lot of the
tutorial info. And therefore fits on one page, and may be totally useless to
anyone but me ;-) BTW just got a notice that a new version of the !%@:: book
is available.
The 'Inter-Network Mail Guide' list looks like it was formated to be read
by a database or program. Is there a nice GUI client for it? There was an
email address in the guide. I'll inquire there too.
Also I've included some of the PMDF examples, even though I've never used
it. I'm trying to get a handle on the x.400 syntax (see next note) which may
be hopeless ;) The site dependent stuff as Bob pointed out is the big
stumbling block for making a _short_ examples list. And I may be getting some
PMDF and X.400 stuff mixed up. Since I've never set up a service, I'm on the
outside looking in.
On sending to a PMDF site Bob wrote:
>The answer is totally site dependent ... The local postmaster can set up
>any arbitrary correspondence s/he can dream up, including
>FirstName.LastName -> login-name.
Unfortunately this is why I need a list. Fortunately at least some
organizations such as DEC and NASA are begining to establish a more uniform
addressing scheme that the outside world can use. This will keep the list
shorter, but obviously DEC's and NASA's scheme is enough different that one
example won't cover them both.
Updated list (Sep 09, 1993):
From VMSMail to an SMTP address:
................................
using PMDF: in%"username@domain"
in%"username@[#.#.#.#]" where #.#.#.# is TCP/IP Address in decimal
using TGV: smtp%"username@domain"
From VMSMail to an X.400 address:
.................................
using PMDF and including a blank in PRMD field:
in%"'/S=smith/ADMD=ATTMAIL/PRMD=nothern trust/'@ATTMAIL.COM"
SMTP address format for various services:
.........................................
Service SMTP address
America on line => user...@AOL.COM
AppleLink => user...@APPLELINK.APPLE.COM
BITNET/EARN => username%host....@CUNYVM.CUNY.EDU
user...@host.BITNET
Compuserve => #.#@COMPUSERVE.COM where #.# is userid numbers.
Digital => first...@loc.MTS.DEC.COM (first.last are parts of a name
loc is a location code which any
December, 1993 The DECUServe Journal Page: 47
DEC office can supply)
user...@nodename.ENET.DEC.COM (NOT preferred because node
might change)
Fidonet => First...@f183.n151.z1.fidonet.org (UNreliable, No Bounce)
Genie => user...@GENIE.GEIS.COM
MCImail => user...@MCIMAIL.COM
mci...@MCIMAIL.COM
acct...@MCIMAIL.COM
NASAMAIL => username@NASAMAIL (probably will be phased out)
OMNET => user...@OMNET.NASA.GOV
Portal => user...@CUP.PORTAL.COM
UUCP => user...@host.UUCP
Telemail => username@TELEMAIL
Near Future Service
...................
NASA => Firstname...@center.nasa.gov where center = MSFC, KSC, JSC, ...
Al...@center.nasa.gov where alias is one of several possibilities
such as Bill for William
Ones we are _NOT_ sure of:
..........................
ATTmail(?): user...@attmail.com
DELPHI: user...@delphi.com (I think)
UUNET: edi...@topgun.UUCP -or-
topgun!edi...@uu.uu.net (this is the editor at X journal)
(09/09/93 Norman: x.400 Yuck! IMHO)
-------------------------------------
Here at MSFC we send x.400 stuff from vmsmail to a gateway which forwards to
appropriate mail box which may involve other gateways. This may get into the
site specific stuff Bob was talking about, but I think some of it is at least
standard.
It appears to me that fields 4 and 5 are used pretty loosely, but fields 2
and 3 are not.
Where can one get a list of ADMD's and PRMD's? I assume they must be
registered with someone.
To: MX400::MRGATE::"x400 address"
"x400 address" examples:
For NASAMail:
"TELEMAIL::1=US::2=TELEMAIL::3=NASAMAIL::5=NASA::6=SMITH::7=John"
"TELEMAIL::1=US::2=TELEMAIL::3=NASAMAIL::5=NASA::John Smith"
"TELEMAIL::C:USA,ADMD:TELEMAIL,PRMD:MSFC,OU:PSC,SN:Smith,FN:John"
For someone on a Data General:
"DGMIS::1=US::2=TELEMAIL::3=MSFC::4=PSC::Michael SMITH"
December, 1993 The DECUServe Journal Page: 48
For someone on a Mac with CCmail:
"HPX::1=US::2=TELEMAIL::3=MSFC::5=CCMAIL::4=MSFC14PO::DENNIS SMITH"
I don't understand how or why the first field in each of the first examples
is used, but the rest of the fields are as follows:
1=country (C)
2=admin domain (ADMD or A)
3=private mail domain (PRMD or P)
4=organizational unit (OU)
5=organization (O)
6=surname (SN)
7=first name (FN)
8=middle initial (I)
others not used ?
(09/09/93 Mezei: X.400 can be Ok if setup properly)
----------------------------------------------------
When you send to
node::MRGATE::"mumble::x400_address",
the mumble is used to point to a Message Router Mailbox which is handled by an
X.400 gateway. If sending to various X.400 platforms involves adressing your
X.400 message to various Mesage Router Mailboxes it is beccause your system
was configured so that each X.400 agent/gateway on Message Router talks to a
single platform.
Remember that MRX is ~old~ technology and perhaps not the best product on
the messaging market and it may be unable to talk to different X.400 MTAs from
the same Message Router Mailbox. This may not be the case (eg: I may be wrong).
Also, it could simply be the way your X.400 network was setup, piece by
piece with no overall topology that makes it into a single X.400 network.
(09/09/93 Diddle: Fidonet - not that simple!)
----------------------------------------------
> Fidonet => First...@f183.n151.z1.fidonet.org (UNreliable, No Bounce)
^^^^ ^^^^ ^^
From (alt.internet.services) with a subject of (mail/country-codes) it
gives the following information compiled by Olivier M.J. Crepin-Leblond.
FIDONET: "firstname...@point.node.net.zone.fidonet.org". To send
mail to a FidoNet user, you not only need the name, but the exact
FidoNet address s/he uses. FidoNet addresses are broken down into
zones, net, nodes, and points. To send to John Doe, who uses point 1 of
node 2, which is in net 3 of zone 4 - you would send your mail to
"john...@p1.f2.n3.z4.fidonet.org".
December, 1993 The DECUServe Journal Page: 49
(09/10/93 Tillman: "G" is usually the first name)
--------------------------------------------------
I always thought "FN" in X.400 meant "full name," not "first name" and
that "G" meant "given name" (in the US, this corresponds to first name).
(09/10/93 Norman: At least one program available.)
---------------------------------------------------
Thanks Calvin for the clarification on fidonet.
I got a message back from Scott the author of the mail guide posted earlier,
and he gave me a source code example for reading the guide. It was copyrighted
with no info on distribution so I'll hold up on posting it until I get some
clarification. It appeared to be a command line driven program similar to
nslookup.
"And I, too, as a quiet 'reader' of DECUserve
Rich Helmke wish to thank all those in the limelight and
Quoted on 09/02/93 in behind the scenes for the outstanding service
DECUServe_Forum 373 provided by the DECUServe staff and volunteers!"
Getting Invalid Service & breakin msgs
--------------------------------------
The following article is an extract of the DECUServe Pathworks
conference topic 601. The discussion occurred between September
15, 1993 and September 21, 1993.
By Bill Weissborn, Dan Wing, John Cox, Dale Coy
(09/15/93 Weissborn)
--------------------
I have a couple of sites that have had Pathworks 4.1a installed on their
PCs. At one site, whenever you attempt to login to the server (we use file
services) you get a message something to the effect of:
"Invalid service or insufficient privilege"
then you get:
"Attempting login without username"
and bang!, you are in. This also generates all sorts of msgs on the consoles
about breakin detection for user XXXX. Eventually, in the course of a day,
the user will get "locked out" via breakin mechanism.
We have checked everything we can think of and can see no reason for this
message and/or the breakin msgs. BTW, there is no entry in the security audit
file about this "breakin".
Any ideas?
December, 1993 The DECUServe Journal Page: 50
At another site, we do not get any of the "invalid service or username"
msgs, but we will occaisionally see msgs about breakin detection on the
consoles. Again, no record in the audit file.
Any idea on what is going on?
Thanks in advance
(09/15/93 Wing: $ SHOW AUDIT)
------------------------------
I don't understand why you'd see breakin messages on the security consoles
but not in the security audit logs. Whats the setting for failures (crash,
wait, or discard)?
(09/15/93 Cox: Passoword Expired? One password login error!)
-------------------------------------------------------------
I believe this is an old problem from version 4.0 days. Something in the
default setup causes this. Look at the LGI_BRK_DISUSER flag and see what it is
set to. Also to understand this a little more see note 275.
(09/16/93 Weissborn: Everything checks out, I think)
-----------------------------------------------------
I believe the audit server settings are to ignore messages if there is
insufficient disk-space. In both cases, there is plenty of disk-space!
We have checked the uaf entries and the password is not close to expiring,
nor has it expired. *Everything* looks okay which is why we are at a loss as
to what to do.
I have noticed, at one site, that some members of the cluster do not have
the same nonpriv username/password in the decnet executive. That is going to
be fixed this morning. Also, this site does not have objects set up for FAL,
Phone, NML, etc. However, I don't see anything in the Pathworks docs that would
indicate this would be a problem.
(09/16/93 Coy: Known problem)
------------------------------
I can't explain why you get different messages (or none) at different
sites.
But:
> I have a couple of sites that have had Pathworks 4.1a installed on
The "breakin attempt detection" is a known problem with 4.1a, with articles
available on DSNLink. The fix is to upgrade to the latest version of Pathworks.
[When we upgraded to 4.2, that problem went away].
(09/16/93 Weissborn: more info for digestion)
----------------------------------------------
The exact message we get is "invalid service or password"
December, 1993 The DECUServe Journal Page: 51
NO entries in audit journal about breakins.
Breakin params are set for 5 attempts within 30 seconds.
Breakin Message is almost instantaneous, ie,get the message on the first
issued of "logon" command.
PC will then display "attempting login without username"
If this is indeed a "bug" in 4.1a, why don't we see it at other sites?
(09/16/93 Coy: Beats me)
-------------------------
If all of the sites are set up identically, with respect to SYSGEN
parameters, AUDIT parameters, NCP parameters, and the commands that are used
in users' login, then I don't know.
> NO entries in audit journal about breakins.
What do you log with AUDIT? Note that
> The exact message we get is "invalid service or password" will not
>necessarily be interpreted as a BREAKIN ATTEMPT.
There are some fairly good articles about this on DSNLINK in the
Pathworks-VMS database. Search for "breakin", for instance.
(09/16/93 Weissborn: Came here because I don't have DSIN support)
------------------------------------------------------------------
We don't have support for pathworks in DSIN...which is why I came here.
We have the audit server enabled for all breakin events.
(09/16/93 Coy: OK)
-------------------
Ah. OK - my recollection is that it had something to do with how the use
statement actually works with those versions of Pathworks. I just don't have
time at the moment to go re-research it. And I never was terribly interested
in understanding the exact cause.
When I _did_ research it many months ago, the answer was "upgrade to 4.2-x".
We upgraded and the problem went away. BTW- we were not getting messages, but
we were getting users locked up and nodes declared to be intruders. I would
think that whether or not you see the messages may be due to some setup
parameter(s) somewhere.
Bottom line: we could probably help you get rid of the messages, but I
doubt there's a way to get rid of the PROBLEM - except to upgrade.
One other suggestion:
> we don't have support for pathworks in DSIN...which is why I came here.
December, 1993 The DECUServe Journal Page: 52
It doesn't cost much to get full support for one or two licenses. Then
you can buy right-to-new-version for all of your PCs when you need to.
(09/20/93 Cox: What is the version of the SERVER?)
---------------------------------------------------
> Breakin params are set for 5 attempts within 30 seconds.
> Breakin Message is almost instantaneous, ie,get the message
> on the first issued of "logon" command.
Security was changed and this caused a lot of confusion. There is a new
parameter in PCFS$LOG_FILES:PCFS$STARTUP_PARAMS.DAT called PCFS$NODE_BKI_ENABLE.
If this is set True (default) Pathworks uses NODE Security verse VMS account.
As Dale said it has to do with USE command if you use the following :
USE ?: \\server_node\service%username
and did not include the * or a correct password an intrusion record is logged
in the intrusion database because MS pass the command string with out the
password resulting in an intrusion.
> PC will then display "attempting login without username"
We don't use the LOGON command here so I'm not sure if this is your problem,
but as was said before you need to have your SERVER at 4.2-1 and read the
release_notes on the changes to security and what they where and how they
effect this whole BREAKIN issue.
> If this is indeed a "bug" in 4.1a, why don't we see it at other sites?
What version are your servers running? 4.1a is the client version. I'm
assuming you have more than one server they are connecting to. Petri or
someone else ....maybe able to shed some light on the use of LOGIN. If it's in
two parts, username then password like the use command this could be your
problem.
(09/21/93 Weissborn: Found the problem.)
-----------------------------------------
Red-face on:
Well, we found the problem...after hacking the logon.bat command, and
upgrading the server to 4.2-1.
After turning on echo we say that the use command was munging the username
to something like pcareapcarea%pcarea. Further investigation showed that this
system had 4DOS installed as the shell. Removal of that and using the DOS 6.0
shell corrected the problem.
(Ahhh, the joys of remote-control system administration 8-( )
Red-face off:
Thanks to all who have provided so many clues/suggestions...I now know
more about Pathworks than I ever thought I would or would care to.
December, 1993 The DECUServe Journal Page: 53
"I wish I ran *my* systems this well, and I'm
Gus Altobello picky! The greatest benefits are the lack of
Quoted on 09/08/93 in flamers (which continually puts me off of netnews)
DECUserve_Forum 373 and the abundance of helpers. I do believe that
as the world becomes "connected", we'll see more
"DECUServes" appearing as the blood-and-guts style
of information interchange typified by the
Internet news items I've seen is evolved into
"information societies". Folks who think that
moderation isn't needed haven't realized that
humans made laws because anarchy was hard for most
to live with. And with this realization may come
a greater appreciation for the jobs the moderators
do here. "Moderation in moderation". I love it.
MANY thanks!"
Macintosh network backups?
--------------------------
The following article is an extract of the DECUServe
Personal_Computing conference topic 496. This discussion
occurred between August 9, 1993 and September 13, 1993.
By Clay Denton, Larry Kilgallen, Bob Koskovich, Saul Tannenbaum, Joe Bates,
Mike Durkin, Shawn Allin, Frank Nagy, Larry Wahlers
(08/09/93 Denton)
-----------------
Is anyone familiar with a product to automate backing up networked Macintosh
systems to a VAX based tape drive or an AppleShare server (which could be a
VAX that could then place data on tape).
Or, if anyone has home grown procedures I'd be inteested in what you set up.
Thanks for any ideas...
(08/09/93 Kilgallen: Retrospective Remote)
-------------------------------------------
I am under the impression that Retrospective Remote by Dantz is the
definitive product in this space.
(08/09/93 Denton: Contact info?)
---------------------------------
Do you have contact information?
(08/09/93 Koskovich: Retro. Definitely.)
------------------------------------------
Retrospect is a snazzy product. I use it every day on my Mac.
December, 1993 The DECUServe Journal Page: 54
It'll back up to most SCSI-connected tapes local to the Mac, as well as any
mountable *anything* (like AppleShare volumes). I'm pretty certain that you
won't be able to back up to a VAX-connected tape drive.
They do a good job of tech support.
Published by:
Dantz Development
4 Orinda Way, Bldg C
Orinda, CA 94563-9919
510-253-3000 (main)
510-253-3050 (tech)
510-253-9099 (fax)
(08/10/93 Tannenbaum)
---------------------
Another vote for Retrospect/Restrospect Remote.
It was good in Version 1.
Version 2 makes it even better.
(08/10/93 Bates)
----------------
But with a little bit of magic with ResEdit Retrospect will backup to a
TK50/TLZ04/TLZ06 SCSI tape drive connected to a Mac.
Also if you have PATHWORKS for Mac and DECnet/Mac installed on your
Macintosh, you can use DECnet to backup Mac hard drives to a VAX based tape
drive. It's a bit kludgy, and not necessarily screaming fast, but can be done,
is documented in the PW4M manuals and PW4M provides an example DCL command
procedure to do it with installation of the PW4M server.
(08/11/93 Durkin: TK50?)
-------------------------
I was attempting this a while ago and thought the limiting factor was the
absence of an appropriate driver for the TK50? Back in thread 354 here, it
looked like it was possible, however the Dantz support staff indicated the TK50
was not a supported unit. I'd be most interested in obtaining a copy of your
ResEdit hacked version or a detailed explanation of your ResEdit hack. :-)
(08/23/93 Bates: Retrospect Patches for TK50)
----------------------------------------------
OK, here's the patch exactly as related to me for Retrospect V1.2 and V1.3
to work with a SCSI TK50 drive. I've also got patches for the TZK QIC drives
and TLZ DAT drives if anyone needs them. 1.2 can initialize a new TK50 (and
backup/restore), 1.3 seems to have lost its ability to initialize a tape but
backs-up and restores (once initialized) quite nicely. I haven't used a TK50
with Retrospect V2.0 since I've upgraded to a TLZ04, but you should be able to
figure it out with the attached. Note that 2.0 regains the capability of
December, 1993 The DECUServe Journal Page: 55
initializing new tapes and still works great at backup and restore. While the
modifications to ResEdit aren't _officially_ supported by Dantz, they've worked
unfailingly for me and quite a few other Mac folks in DEC for quite a few years.
Patch to Retrospect V1.1.2 to use Digital TK50 (SCSI) tape drive on Macintosh.
First make a backup copy of Retrospect. (probably to a floppy)
Run Resedit and open the Retrospect Application.
Open STR# resource number 2140.
Locate the string that starts with Typ7
Change that string to contain Typ7TAPE
Locate the string that starts with Vnd7
Change that string to contain only Vnd7
Locate the string that starts with Prd7
Change that string to contain only Prd7
Close Resedit and select yes to make changes.
Power the Macintosh off.
Now connect the TK50 to the Macintosh using a standard Macintosh System SCSI
cable.
Power the TK50 on.
Power on the Macintosh and run Retrospect.
The rest is simple.
Now, what have we changed in Retrospect to make the TK50 work?
The Typ fields in the string resource are checked against what a device returns
from a SCSI inquire. The TK50 returns "TAPE" as the type. The Vnd and Prd
fields are the product and version which are returned as nothing by the TK50.
So by entering TAPE as the Typ7 and nothing after the Vnd and Prd fields we make
Retrospect think that TK50 is a helical scan tape device.
(08/23/93 Durkin: I'll give it a whirl. Thanks!)
-------------------------------------------------
December, 1993 The DECUServe Journal Page: 56
(08/24/93 Allin: Does Retrospect support multiple "savesets" on one tape?)
---------------------------------------------------------------------------
RE: Retrospect: On and off we have been trying to set up network backups
for our small Mac network (Ethernet based). At one point, my predecesor had a
combination of Retrospect 1.3 and Quickeys going that would have a Mac server
with an Exabyte connect to a client through Appleshare with a "Backup" username,
backup the hard disk, then disconnect. One thing that has never been clear to
me though, is whether Retrospect supports multiple "savesets" or whatever it
calls them on one tape. Does anyone do this? We'd like to do Mac 1, then Mac
2, etc, etc.
(08/24/93 Koskovich: Been there, done that)
--------------------------------------------
Yep, Retrospect supports multiple "sessions" per "StorageSet" (the new 2.0
name for "archives"). Each source volume goes into its own session.
When you're setting up your backup script, just select multiple sources
using the standard Mac method (shift-click for a range, command-click for
discrete selections).
I have two daily scripts. One runs full backups of two or three machines,
then the second runs incremental backups of any of the other machines that are
left on.
When you need to restore, you get a list of the sessions from which to pick.
(08/24/93 Nagy: Another solution: FastBack Plus to VAXshare volume)
--------------------------------------------------------------------
I use FastBack Plus V3.0 to backup my Mac IIvx to a VAXshare volume on the
hard disk (Wren V) on my VAXstation 4000/60. The IIvx has an Apple Ethernet
card and is connected to the same Ethernet ThinWire cable my VAXstation is on.
I have a FastBack document setup to backup the Mac hard disk to a folder on my
VAXshare volume. FastBack writes save sets or "StorageSets" to mounted
Macintosh volumes. I have compression turned on in FastBack to save space.
About 20 minutes or so are required to backup the 70-80 MB in use on the Mac
hard disk. I have not setup any automatic macros but manually invoke FastBack
about once a week or so.
By comparison my brand new Centris 650 (for home) backs up 77 MB from its
internal hard disk to a SyQuest 88 MB cartridge in 11 minutes. So the speeds
are rather comparable.
(09/13/93 Wahlers: Yet another solution-Redux)
-----------------------------------------------
I've been using Redux 1.63 for years now. I just ordered version 2.0, which
supports several improvements, including the ability to backup to a specific
folder on a network, scheduled backups, etc.
I find Redux to be more user-friendly than either FastBack or Retrospect
- a nice thing, considering some of the limited expertise of some of my users.
December, 1993 The DECUServe Journal Page: 57
"Well, I'm one of the runners these days, but
Don Roberts I thought a plug for those who have gone before
Quoted on 09/09/93 in and laid the foundation is needed. People like
DECUServe_Forum 373 Chris Rhode, who set the standard for manager of
moderators that I have yet to live up to, and Jeff
Killeen, whose enthusiasm and political drive made
this system much of the success it is. And all
the others who laid the foundations and thought
out so well what was to come. A particular hat's
off to Dan Eisner."
How to do trusted subsystems in a network?
------------------------------------------
The following article is an extract of the DECUServe Security
conference topic 267. This discussion occurred between
October 15, 1993 and October 18, 1993.
By Linwood Ferguson, Bill Wood, Brian Breton, Keith Chadwick, Larry Kilgallen,
John Burnet, Harry Flowers
(10/15/93 Ferguson)
-------------------
As I understand it (and I have not broken out the new manuals to look) V6
of VMS is suppose to introduce the idea of protected subsystems, where you can
associated in some way programs and data they are allowed to operate on
(presumably by installing with a rightslist ID).
Has their been any consideration to how this works in a client server
environment, either theoretical (that we might try to roll our own) or actual
(like maybe DEC did something when I wasn't looking).
We have two specific problems. One is using Rdb between multiple VAXen.
On one VAX we could grant access to various tables to a rightslist id and
presumably install an image with that id, and then anyone running that image
(anyone that image allows to run it) would have access through it (and only
though it) to that data. No problem. However, when the image is on one VAX
and the database on another, the access is through the server image. It
appears that regardless of how you end up giving the server process on the
remote node the right to access the database, the chain is broken -- there is
no way to know that the access comes from the trusted image on the local node.
A similar problem occurs in client/server with PC's [is anyone else
irritated that "client/server" has come to mean PC -> Server and only that?].
The 4Gl we use provides a server process much like Rdb's server, and like the
case for Rdb we can grant or deny access to the Rdb database easily, but how
can we know whether the person on the PC end is running the client software we
"trust" (at the moment I am not really concerned about such subtrafuge as
replacing it with their own program, but the common place problems of are they
running program A or program B).
The latter problem is obviously complicated by running 3rd party software
mixed with two operating systems. But how about the former, which is VMS ->
December, 1993 The DECUServe Journal Page: 58
VMS, and Rdb -> Rdb, all Digital. Is there some practical way to carry over
the ideas of protected subsystems to the Digital network?
By the way, add to this the desire to be able to log (e.g. in triggers in
the database) the access and who it came from. It would not really be good if
the username seen accessing the Rdb database on the remote node were always
SYSTEM or something, since then recording audits of changes would be pretty
useless.
(10/15/93 Wood: Maybe someone else can define "soon".)
-------------------------------------------------------
(02/02/93 Breton: OpenVMS 6.0 on the horizon)
----------------------------------------------
There are no network capabilites in Protected subsystems. What you are
describing is what is called "Distributed Authorization". DCE authentication
(kerberos) will be a reality soon but I really can't say when.
(10/15/93 Ferguson: Reply (posted with permission))
----------------------------------------------------
From: EISNER::BRIGGS "John Briggs, Vitro Corporation" 15-OCT-1993 10:59:36.45
To: EISNER::FERGUSON
CC:
Subj: Trusted subsystems
> As I understand it (and I have not broken out the new manuals to look)
>V6 of VMS is suppose to introduce the idea of protected subsystems, where you
>can associated in some way programs and data they are allowed to operate on
>(presumably by installing with a rightslist ID).
This reply is far enough off-topic so that I'm not posting it. It's mostly
a description of the implementation of protected subsystems.
Protected subsystems don't require that the "privileged" image be installed.
But the result is quite similar.
A protected subsystem is implemented as a new type of ACE applied to an
image. Something like:
(SUBSYSTEM,ID=TRUSTED_ACCOUNTING_APPLICATION)
The syntax here is guaranteed to be wrong, but the concept is right.
When the image activator fires up the image, it scans the ACL on the image
and enables any identifiers specified in ACE's of this format. And it
arranges for image rundown to revoke these identifiers.
In addition, a new identifier attribute has been added so that users who
hold an identifier with the attribute are allowed to apply this sort of ACE to
executable images.
One security implication of this is that disks mounted into a VMS
environment must be trustworthy. If someone builds a disk at one site they
can put protected subsystem ACE's on the files on that disk. When the disk is
moved to another site and mounted there, these ACE's are still in effect and
December, 1993 The DECUServe Journal Page: 59
could result in the granting of inappropriate rights identifiers. For this
reason, the $MOUNT system service and the DCL MOUNT command have been modified
to allow a volume to be mounted such that these ACE's are ignored on a
volume-wide basis.
With respect to your client/server question, I don't see protected
subsystems as doing anything differently from images installed with privilege.
Only two things have been changed:
o The image doesn't have to get SYSPRV, it can make do with a rights
identifier.
o You can delegate the ability to create protected subsystems
to your users.
In a client/server environment, It is still the privileges and rights of
the process and image on the server node that are used to arbitrate file access.
And if you are going to make use of special privileges/rights associated with
the server image, you still have to make sure the server authenticates the
client first.
(10/15/93 Ferguson: Reply to reply)
------------------------------------
From: EISNER::FERGUSON "Linwood Ferguson" 15-OCT-1993 13:37:07.33
To: EISNER::BRIGGS
CC: FERGUSON
Subj: RE: Trusted subsystems
Hi. Thanks. Actually...
>This reply is far enough off-topic so that I'm not posting it. It's
>mostly a description of the implementation of protected subsystems.
It was pretty much on topic, but ok. Thanks for the explanation, that is
more or less what I had pictured though I had not thought through syntax.
>With respect to your client/server question, I don't see protected
>subsystems as doing anything differently from images installed with
>privilege. Only two things have been changed:
>
> o The image doesn't have to get SYSPRV, it can make do with a rights
> identifier.
>
> o You can delegate the ability to create protected subsystems
> to your users.
>
>In a client/server environment, It is still the privileges and rights of
>the process and image on the server node that are used to arbitrate file
>access. And if you are going to make use of special privileges/rights
>associated with the server image, you still have to make sure the server
>authenticates the client first.
December, 1993 The DECUServe Journal Page: 60
Let me see if I can be more clear, because herein lies our problem.
On a single VMS system, I set up image X as "trusted" and thus implicitly
grand rightslist ID TRUSTED_ACCOUNTING to anyone who runs it. The key to
making this most useful is that I build into image X the smarts to decide who
can and cannot run it, and what they can do. I see that as integral to making
it trust-worthy.
When I take this into a client server environment, even if VMS client to
VMS server, in general the server image is one I buy, not one I get to write
(though I can install or protect it, and probably control the context in which
it runs including user id). So making it "trusted" in the same way does not
yield the same result. Example, for Rdb, I might be installing the SYS$SYSTEM
RDBSERVER.EXE as TRUSTED_ACCOUNTING.
Now, however, the smarts for deciding who gets to use it is in the client.
This works nicely if the client is my client, but it might not be.
I think the key is in your statement "you still have to make sure the server
authenticates the client first". If I were implementing both the client and the
server code, this would be possible (questions of spoofing and needing fancy
encrypted signatures aside). However, in most cases that I have found (Rdb and
4GL client-server systems) you get to control the client, but the server comes
ready made where at most you control its context, not its decisions. Basically
I see little way that I can allow user X to access an Rdb database on a remote
node from a "trusted" local image without allowing the same kind of access
from an untrusted one (ok, there are special cases, like removing NETWORK from
the user but granting it to the image, but I'm speaking more generally).
Does that make sense?? Or am I thinking about this all wrongly?
(10/15/93 Ferguson: More (switching from mail to notes))
---------------------------------------------------------
From: EISNER::BRIGGS 15-OCT-1993 16:07:17.32
To: EISNER::FERGUSON
CC:
Subj: RE: Trusted subsystems
Ok. I have a clearer picture of where you are coming from now (I think).
What about protecting a password file on the client with a rights
identifier. Then you install a client as a trusted subsystem with the
"PASSWORD_FILE_ACCESS" identifier. If a user goes after the server through
your client, the client can pick out a password and thereby authenticate itself
to the server and get some level of enhanced access. If your user goes in
without using your trusted client, he doesn't have access to the password file
and can't get the server to grant him the enhanced access.
This does mean that you pretty much have to write your own client. But you
might be able to do something clever like writing a simple client that gets the
password and then does a LIB$DO_COMMAND to access the real client, specifying
the magic password.
Is this the kind of thing you were thinking of doing?
(10/15/93 Ferguson: More explanation of needs)
-----------------------------------------------
>What about protecting a password file on the client with a rights
>identifier. Then you install a client as a trusted subsystem with the
December, 1993 The DECUServe Journal Page: 61
Think about this is in the context of a VMS to VMS connection to RDBSERVER
as the server. I can't change RDBSERVER's behavior. At most I can control
the context in which it runs, so I think in this case at most I could change
the user name under which the client log into the network connection to the
remote node. RDBSERVER seems to work very much like Uniface's polyserver in
this regard, and I suspect like many database and/or 4GL client/server
application generation systems. Basically a vendor-provided server and you
write the client.
So think RDBSERVER:
Now if I log in the network connection with the user's own ID (assuming
they have one) this doesn't buy me anything, since it means that user could do
the same thing outside of the trusted client. If I log in with a generic,
privileged ID that works, but I loose the connection to who is running what
(e.g. if I update in SQL with USER I get, say, SYSTEM, not JOE_M). More
importantly I loose the concept of doing this with rightslists instead of
privileges, unless I hard-code the netserver.com routine to grant a rightslist
based on some aspect of the incoming connection and remove privileges.
I think what I need to do (and have never tried) would be to copy RDBSERVER
to multiple images, install each with the associated rightslist, and invoke
different ones from different clients (not client/users, but client-types).
So I might have a RDBSERVER_ACCOUNTING and RDBSERVER_PAYROLL if I think of
these as separate trusted subsystems. I'm not sure how well that would work in
practice, but I thin it sounds possible (though it doesn't appear to get around
the problem of user names, but maybe I can have the process switch actual
user names using privilege prior to invoking RDBSERVER). Of course telling
in a netserver process who the remote node is not reliable, if I remember
correctly, much less knowing whether I can access different objects instead of
RDBSERVER from a RDB/SQL program or Uniface.
I guess I have to give this some more thought. The basic problem I have is
if someone runs program A on vax Y, accessing Rdb database on vax Z, I want
them to be able to access a certain database there. If they run SQL or any
program other than A on vax Y, I do not want Z to grant them access.
I am frankly not concerned about such issues as shipping passwords around
on a LAN unencrypted or people spoofing nodenames and the like. Well, "not
concerned" is too strong, but am conciously making the decision not to try to
address it today. But I really want to make sure that, for instance, someone
running Datatrieve to report against files can't do a READY .... WRITE and
suddenly get access to write to the payroll files just because when they run
the time card entry program it allows them to.
(10/15/93 Ferguson: If wishes were fishes...)
----------------------------------------------
> There are no network capabilites in Protected subsystems. What you are
describing is what is called "Distributed Authorization". DCE authentication
>(kerberos) will be a reality soon but I really can't say when.
Maybe this is my problem. I dismiss the problems of true and reliable
authentication and encryption, but vendors cannot. I see it as just needing a
way to extend the domain of protected subsystems in some way across the
network, not really worrying about the security of the transport across, nor
about whether each node is itself reliable. I simply define them as such.
Clearly a vendor cannot.
December, 1993 The DECUServe Journal Page: 62
But this seems to leave the area of network access either wide open, or
based on username/password like regular file security (i.e. either you can get
to it, or you cannot, regardless of what you are running). And that's giving
me real headaches as we try to design a client server implementation of our
existing system.
What I really want is some way to convey, as part of a decnet connection,
the current (and dynamic) state of rightslist ID's and perhaps even privileges.
(10/15/93 Chadwick: Do DECnet proxies offer a solution here?)
--------------------------------------------------------------
How about authenication on both the client and server via the following:
As I recall, the "default" configuration of the RDBSERVER object is to run
under a specific account (perhaps DECNET or RDB$SERVER). This is accomplished
by defining/setting the User Id and Password characteristics in the NCP object
database.
If you changed this to allow proxy access:
NCP> DEFINE/SET OBJECT RDBSERVER PROXY BOTH
NCP> DEFINE/SET OBJECT RDBSERVER ALIAS INCOMMING ENABLED
Then the remote RDB clients would log into proxy accounts on the server
machine.
You could then control which databases the proxy accounts had access to
through the standard rights identifier mechanisms and access control lists on
the server.
This would allow the application to not have to propogate "remote
rights/permissions" across the network.
Of course, you could still authenticate at the client before initiating the
DECnet connection, but the final authentication would be on the server using
standard VMS rights identifiers and access control lists.
(10/15/93 Ferguson: Regular network access control is not the same)
--------------------------------------------------------------------
>As I recall, the "default" configuration of the RDBSERVER object is to run
under a specific account (perhaps DECNET or RDB$SERVER). This is
I'll have to research the default part a bit, but on our system it all runs
under proxy now, and I don't recall setting it up that way. I think the
RDB$REMOTE account is used if you don't have proxy's or explicit access
information.
>You could then control which databases the proxy accounts had access to
>through the standard rights identifier mechanisms and access control lists on
>the server.
This is the straightfoward way to do it, but is not what we want (at least
if I understand you). For example, if I do this I can run program X on the
local VAX and access the remote database, but I can also access it (through
the same proxy) from Datatrieve or Interactive SQL in the same way, since the
December, 1993 The DECUServe Journal Page: 63
same proxy access exists. The remote system (for proxy access) only cares what
the process ID is, not what image that process is running, or what rights it
owns at that moment.
The point is that we want to permit a _program_ on the local VAX to access
data on a remote VAX independent of who is using it, while (perhaps) not
allowing any of those users to access it directly through SQL or other
programs. Or better example, I might want to grant read access through the
database ACL's but not write access so they can use commercial query programs
against the data, but only grant write access to our trusted programs.
The idea of the local trusted client looking up some otherwise-inaccessible
user/password and using that on the remote system sounds closest. What I
really want is to do that without having it appear everyone is under the same
remote account, but I guess I can get around most of that problem by building
any auditing into the application (client) instead of database triggers
(though this is kind of politically incorrect in itself). This seems pretty
easy on VMS, but I'm not sure how easy this is on a PC.
(10/15/93 Kilgallen: VMS has it now)
-------------------------------------
>The idea of the local trusted client looking up some otherwise-inaccessible
>user/password and using that on the remote system sounds closest.
That is the capability provided by the Privileged Default DECnet account in
VMS. You get one outgoing username/password which will be used for connections
which do not otherwise specify access control information.
(10/15/93 Kilgallen: With privilege, you can twiddle the rights list)
----------------------------------------------------------------------
>What I really want is some way to convey, as part of a decnet connection, the
>current (and dynamic) state of rightslist ID's and perhaps even privileges.
For an account accessed via the Privileged Default DECnet capability you
could write a privileged program invoked from LOGIN.COM which would look up
the identity of the remote user in a table and set up the server process rights
list appropriately. Getting to the special account proves that the user is
running the blessed program (within the limits of your total trust that nobody
could access your network connections from a PC). Setting the rights list
gives you all the granularity you need to control access with normal database
mechanisms.
(10/16/93 Ferguson: Getting closer to "good enough")
-----------------------------------------------------
Can I reliably know the identity of the remote user? I thought there were
problems with SYS$REM_ID (or whatever the logicals are) that under some even
non-malicious situations they would be wrong. Is that not true?
And I'm pretty pathworks ignorant: Is the issue that I can't hide the priv
account information on a PC, since they can access anything? Or is there more to
it than that?
December, 1993 The DECUServe Journal Page: 64
(10/17/93 Kilgallen: PC /= Security)
-------------------------------------
1. I know of no problems with conveying the remote user ID other
than malice on the originating node or the network in between.
2. The fact that I don't know about such problems does not mean
such problems don't exist.
Everything I said presumed VMS-to-VMS using Phase IV DECnet. There is
absolutely no concept of reliable identity from MS-DOS. I doubt that anyone
even bothered to implement Privileged Default DECnet access from MS-DOS.
Is there even such a thing as an Rdb client on MS-DOS?
(10/18/93 Ferguson: Getting closer still (for us))
---------------------------------------------------
No idea, will have to start learning, I guess.
> Is there even such a thing as an Rdb client on MS-DOS?
Again no idea, but there is a Uniface client which (conceptually) works
the same way, in fact replaces the Rdb server on the VAX side, so all the same
issues apply.
I've been thinking about this side of it (without any knowledge of it,
which makes it easier :-). Uniface clients have easy hooks into
encrypt/decrypt routines of a user's choice. I could have a (server resident
probably) file with access information in it accessible to the PC but encrypted.
The decryption routines would be linked into the uniface software we load on the
PC. They could decrypt and long into the VAX under a privileged account on the
VAX instead of the user's own (their own account would control access to this
encrypted file).
That's not perfect for lots of reasons, but I think it is good enough for
us. In fact, I suspect the file just being on the server in some not obvious
place is good enough for a first pass for us. Our PC population will be very
small at first and probably restricted to manager-types, where what we really
want to do is make it hard for them to screw stuff up while meaning-ly
exploring their new system.
(10/18/93 Burnet: NCB instead of SYS$REM_NODE, REM_ID)
-------------------------------------------------------
>Can I reliably know the identity of the remote user? I thought there were
>problems with SYS$REM_ID (or whatever the logicals are) that under some even
>non-malicious situations they would be wrong. Is that not true?
I think it is true, and there is some information about it around here
somewhere. As I recall, the problem is that the information can get stale when
a NETSERVER process is reused.
You can always parse the network connect block; that should be more
reliable. See VMS 1417.7.
December, 1993 The DECUServe Journal Page: 65
(10/18/93 Flowers: DECnet SYS$REM* logicals aren't reliable)
-------------------------------------------------------------
The problem is with server processes that, by default, hang around for five
minutes waiting for any further connections. Under this scenario, the SYS$REM*
logicals will have the data from the first connector, not necessarily the
current one. The suggested method is to parse SYS$NET, which has the
information and is current. It's just not as convenient.
"Something in Jamie's note about the pending
Barb Wulff divorce and associated following notes has started
Quoted on 11/07/93 in me thinking about the DECUServe culture. I
Who_Am_I 262 certainly feel like even if we do not know each
other personally face-to-face, we certainly know
each other as a community. We get a flavor for
each person in his/her likes and dislikes,
hobbies, homelife, joys and struggles. That makes
it a much nicer place to hang around, at least for
me. I wonder if there are other BBS's that are
like this or if we are unique. I know from my
perspective, DECUServe helped a lot when I was
[enduring personal trials]. I felt like I had a
support group to get me through. I think relying
on friends both electronically and here in person
is an important thing in life. I guess I am just
trying to say THANKS DECUServers for helping me
in my job and my life. I am continually amazed at
the wide range of interests and knowledge in
people that the outside world would label Nerds.
Keep it up!"
Development Environment for C Coding?
-------------------------------------
The following article is an extract of the DECUServe
Software_Development conference topic 109. This discussion
occurred between April 6, 1993 and April 15, 1993.
By Mike Durkin, Jamie Hanrahan, Dale Coy, Linwood Ferguson, Petri Backstrom,
Bill Wood, David Stiles, Richard Norman, Steve Di Pirro
(04/06/93 Durkin)
-----------------
We are getting ready to launch ourselves into some headsdown C development
and I'm looking for some comments on best strategies for a development
environment. We've got LSE, CMS and MMS, however one person feels strongly
about coding on a PC and copying up to the Vax for compilation after a coding
cycle on the PC. What are you folks doing and how well does it work? I know
there are some PC code control applications but we're looking to limit the
December, 1993 The DECUServe Journal Page: 66
acquisition of any more tools. Then again, convince me I need it and I'll
probably be able to persuade the necessary folks here. ;-)
(04/06/93 Hanrahan)
-------------------
Pathworks 4.0 came with an unsupported CMS client for MS-DOS. This let you
check things out from and merge them back in to a CMS library on a VMS host,
all from the PC.
It still runs on 4.1, but I don't believe it's distributed any longer.
(04/06/93 Coy: Same principle for any language?)
-------------------------------------------------
>however one person feels strongly about coding on a PC and copying up to the
>Vax for compilation after a coding cycle on the PC.
What's his/her reason? I can think of some legitimate ones, and some
questionable ones, and some crazy ones.
If the reason(s) are at least un-crazy I would be inclined to let it be
tried, with some monitoring and benchmarks.
OTOH, I find it hard to believe that - if you are really going to USE LSE
on the VAX - the productivity on a PC could be as good.
(04/06/93 Ferguson: Where are they going to test it?)
------------------------------------------------------
>however one person feels strongly about coding on a PC and copying up to the
>Vax for compilation after a coding cycle on the PC.
If this is a situation where it could be tested on the PC also, this might
have some advantages in speed.
But at least with VAX C and most PC products I looked at I would not trust
a program that runs on the PC to also run on the VAX. I would want it tested
at least as well there.
And if I had to do all my testing and fixing on the VAX, I'm not sure (if
it were me) I would have any benefit from actually doing the changes and what
would basically be a syntax-check compilation on the PC.
(04/07/93 Durkin: Better compilers on the PC?)
-----------------------------------------------
Apparently, and I'm not an authority on the topic, the PC compilers are
better at flagging things with warnings which would otherwise pass by
un-noticed via the VAX C compiler. BTW, Linwood, did you ever find a public
domain LINT package on the VAX platform? Testing would not take place on the
PC, unless it was generic enough to not require VAX specific hooks. This does
cause me to be concerned over code control, what with the source code existing
in at least two incarnations in at least two places.
This person also recommended coding C via C++ since we have no real
investment in C modules at present. We will be building our own function
library, perhaps borrowing from other sources, to accomodate a future where
December, 1993 The DECUServe Journal Page: 67
C/C++ will be the dominant 3GL. Then, at some future date, we will hopefully
be well positioned to make the jump to real C++ coding. However, like I said
at the top, I'm not an authority on the topic, hence my posting. ;-)
(04/07/93 Hanrahan)
-------------------
If you're developing on the PC, for the PC, some of the development
environments available are really nice. Borland C++ has the best released
one, IMO. Microsoft has lagged behind but they're catching up.
I agree with the comments about VAX C's non-pickiness, though
/standard=portable will do some lint-picking.
If someone is used to, for example, Borland's environment, their
productivity may be better than under LSE under VMS if that environment is
unfamiliar to them.
If the comparison is between a character cell terminal and a PC, the PC wins
hands down on display update speed alone. Nor will it ever get any slower
because other users are keeping it busy with other things...
...otoh, if the VAX environment is a workstation, preferably a 1280x1024
screen, even more preferably with a second "head" for getting at Bookreader and
such, that works pretty well too.
(04/07/93 Ferguson: Nope)
--------------------------
>Linwood, did you ever find a public domain LINT package on the VAX platform?
Nope. Only for-fee ones, and I don't want to pursue those until DEC C is
out to see to what extent it has better lint-like features (it certainly was
said to have some in Vegas).
(04/07/93 Backstrom)
--------------------
>Pathworks 4.0 came with an unsupported CMS client for MS-DOS. This let you
PCMS is not distributed with the PATHWORKS for DOS media kit, but it
available through other sources (the DECPCI forum on CompuServe, DSNlink, here
- see PCSA:[COMPUSERVE.UNSUPPRT]PCMS.ZIP -, CSC's and bulletin boards some
CSC's manage).
(04/08/93 Wood: Strong Typing.)
-------------------------------
>This person also recommended coding C via C++ since we have no real investment
I am considering skipping C and jumping to C++ as well. I really like the
strong typing capability in C++. (But then I prefer Pascal :-) ).
>We will be building our own function library, perhaps borrowing from other
>sources, to accomodate a future where C/C++ will be the dominant 3GL.
December, 1993 The DECUServe Journal Page: 68
Interesting prophesy.
(04/12/93 Stiles: AA development environment using C)
------------------------------------------------------
I am currently involved in a "headsdown C project". The project currently
has 6 designers/programmers using VAXstation 4000 Model 60. Several editors
are being used: LSE, MED, EDT. The choice of editor is based on personal
preference. We also depend heavily on CMS and MMS. This environment has
served us very well.
I agree that there are valid reasons for using a PC for code development.
The one disadvantage that stands out most, to me, is the vendor's
implementation of 'C' may not be compatible with VAX 'C' or DEC 'C'. This
could cause headaches and/or nightmares trying to figure out why the code
compiled on the PC but not the VAX.
I am a strong supporter of LSE. Within LSE 'trial' compile can be done;
key definitions are possible, for those of us who are lazy; the environment can
be 'customized'. The customized environment has allowed use to implement 'C'
coding standards for our current project. This will allow others joining the
team to quickly start using the coding standards with very little pain.
CMS has allowed us to 'communicate' with each other in regards to who has
what 'checked out'. We have also built a utility that will scan the CMS
library for reservations. When reservations for a particular user are found a
VAXmail message is sent reminding them of the reservation.
This is just a quick synopsis of our work environment. The environment
has served us well these past 9 months and should help over the next 24 months.
(04/12/93 Norman: {{{{ brace yourself }}}})
--------------------------------------------
program development environment using C
My favorite environment is a padded room, especially for Mac C 8*}
(04/15/93 DiPirro: Depends...)
-------------------------------
DECC is a lot less forgiving and will do a lot more type checking than
VAXC. In fact, if it's strict ANSI C that you want, DECC can enforce those
rules.
I agree with the sentiment that using some of the C++ development
environments out there can really enhance productivity over "traditional"
methods. However, it also depends somewhat on the nature of your program. It
must be relatively portable by nature for this sort of environment. If it's
something intimately tied to VMS, then you'd probably be better off doing the
development with LSE on VMS.
If this is a fairly large, complex application with most of it being
portable, then Borland C++ (or an equivalent) might be the way to go. Of course,
just using C++ doesn't necessarily buy you better productivity and
maintainability. Object-oriented design techniques should be applied as well.