HP3000-L Archives

June 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Dirickson b894 WestWin <[log in to unmask]>
Reply To:
Steve Dirickson b894 WestWin <[log in to unmask]>
Date:
Wed, 4 Jun 1997 22:05:00 P
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
<<I've been racking my brains trying to figure out a way of putting
certain groups in our development account off-limits.  I'm trying to set
up source control procedures, such that the original files are kept in
the "secure" groups.  Scripts will be used to control taking files out of
the groups to edit & saving changed or new files into the groups.  I
would like to be able to prevent any programmer from easily bypassing the
system (this would be mainly due to laziness or forgetfulness).
  Specifically, I would like the "secure" groups to have read access
only, so that searches for strings and similar operations are possible,
and the scripts would be able to then retrieve from or save to those
groups.>>


"Secure groups" might be pretty tough, especially in light of your
following comment. If you put the groups to be controlled in another
account, you'll have better luck restricting write access. You could then
use "get", "checkin" and "checkout" scripts to build and execute job
streams that copy/move the files into/out of the controlled
group/account.

<<All our programmers have AM capability, we have the Vesoft trilogy
(MPEX, Security & Veaudit) and are on MPE/iX 5.5.>>


Any particular reason why? I can see developer's needing things like PM,
OP and PH, but I can't think of a good reason offhand why an entire group
would need AM to perform development activities. Maybe you have some
custom software package that requires it? AM allows a user to override
almost any account-level security controls you can put in place anyway.

<<Anyone got any hints or ideas?  I don't think we need to buy a
full-blown source control package.>>


Although, if you invest too many programmer hours in developing and
testing scripts, job files, and permission structures, you'll have spent
more than it would have cost to buy an SCS up front. Especially if you
try to do versioning manually.

Steve

ATOM RSS1 RSS2