|
The following matrix was prepared after exaiming the products listed.
An in depth study was not done. .It was imperative that the function being
looked at was capable as this date - August 1987
FUNCTION/PRODUCT MATRIX
FUNCTION/CAPABILITY PRODUCT
DM PIMS KATIE DFM CCM ORCHID
1. Version control X X 0 X X X
2. Configuration control X 0 0 0 X LIMITED
3. Lock management X N/A X X X 0
4. Backup/recovery 0 0 VMS VMS VMS VMS
5. Security 0 0 X X VMS X
6. Journaling 0 0 X X X X
7. Alerts/mail X X X X 0 X
NOTES:
1. Legend - x indicates the product provides the capability
0 indicates the product does not provide the capability
2. DM - Although all functions/capabilities were planned, all
not performing correctly as currently delivered.
Performance is slow. RTL conv. still crashing.
3. PIMS - Many features not currently implemented are tentatively
scheduled for BL5 (Feb - Mar time frame).
4. DFM - Much is done over the network, does not address clusters,
might be incorporated under PIMS after BL5.
5. CCM - Currently being used for Aquarius, M.Evans (originator)
locally available, at a minimum, for verbal support.
PRODUCT: DDMS Design Data Management System Version PR5
FUNCTION/CAPABILITY PRODUCT
1. Version control - X
It provides two levels of version control one for project and the other
for local versions.
2. Configuration control - X
Configurations can be specified as specific versions or combinations of
rules specifying latest, latest local, latest project and specific
attributes related to find a file.
3. Lock management - X
Files can be reserved exclusively or for edit allowing others to read and
update the file.
4. Backup/recovery - 0
There is no backup and recovery mechanism. The VMS backup/restore utility
cannot be utilized to it's fullest extent as the files are encrypted into
cae2000 and the INGRES database. i.e. you cannot backup selected files
5. Security - 0
All users of the system must reside in a single group and certain data
files must be world readable.
6. Journaling - 0
There currently is not a journaling or transaction recording mechansism
in the system.
7. Alerts/mail - X
Users can specify mail alerts to a group of interested users.
COMMENTS:
The system has the potential of being very robust, data access can
be done through programs written to object oriented interfaces.
Accessing data can be done in numerous ways.
The system only runs on one node, and there currently is not a failover
mechanism today.
The underlining database system is currently in the process of being
understood and supported again, therfore it will take some time for
the support group to fix and enhance the code.
The system performance is extremely slow.compared to other data management
SUMMARY:
I feel that the product given time and proper management and support could
be a useable production system. We should continue to monitor the
progress of the system and use it in a limited fashion if it is proven
to be feasible.
PRODUCT: Product Information Management System (PIMS)
The PIMS system WILL BE what you want to have. The ability for Engineering
and Manufacturing to share a single, decentralized Meta-Database with
decentralized data file storage is a great idea. Ideally, Engineering
and Manufacturing could define their objects and processes so that submission
of a file by an Engineer could kick off a series of actions resulting in
the running of engineering tools which result in other files being checked
into the database which results in the running of a manufacturing tool which
transforms the data into something that manufacturing needs.
PIMS will not have all the functionality required by the above scenario until
at least BL5 or, not for at least 7 months, by their schedule.
Below is the requirements matrix filled in to the best of my knowledge
of PIMS.
FUNCTION/CAPABILITY PRODUCT
1. Version control
Only a few objects are available in BL3.5 and only some of
them are versionable. The complete user-defineable object
capability is to be in BL5 and objects should be fully
versionable then as well.
2. Configuration control
A requirement of BL5 is to support a Configuration object
type that is versionable.
3. Lock management
There is no concept of locks since the object's files
are NOT deletable (at least I can't find any delete command
for PIMS). The system is based on making all
files available to all users and leaving knowledge about
which is the proper file in the meta-data.
4. Backup/recovery
I can find no mention of this in the information I have.
The closest I can find is a reference to DB unload/reload
in the BL5 requirements.
5. Security
Security Manager, currently there is no protection of
PIMS data files. Any PIMS user can see all of the PIMS
managed files. Object level access control is supposed
to be available in BL5.
6. Journaling
I can't find any reference to this in any PIMS document
that I have.
7. Alerts/mail
Alerts, the current alert scheme is implemented by an
awkward interface to Datatrieve and is limited to mail.
This will be replaced with a new event driver for BL5.
In sum, the software is immature. Currently the BL3.5 software is
in beta test. There is a great deal of development to be completed
for BL5, some of which is non-trivial. I think that 7 months is
optimistic at best and should be regarded with caution.
PRODUCT: Product Information Management System (PIMS) - BASE LEVEL 3.5
Since it was a requirement that we only look at what functionality exists
today, I have done this evaluation with the latest release of the PIMS system.
FUNCTION/CAPABILITY
___________________
1. Version control - X
Version control is available today for the following objects: part, project,
generic file, part process.
2. Configuration control - X
There is a minimal amount of configuration control available today.
3. Lock management - 0
Currently today PIMS does not have a lock reservation mechanism.
4. Backup/recovery - 0
I did not find any documentation on backup/recovery, but being a VMS based
system standard VMS backup and restore capabilities are available.
5. Security - X
There is a minimum amount of security available in the system today. You do
have to have a proxy account setup in order to access the PIMS system.
6. Journaling - 0
None available
7. Alerts/mail - X
Notification lists are created using a DTR application.
COMMENTS:
The PIMS system currently is in Beta test with two test sites currently
using it. PIMS only runs on one node on a cluster and can only be
accessed thru that node with 40 concurrent users allowed at any given instant.
I would be concerned about the performance of PIMS/BRIDGE software, as it does
not seem to be a requirement for their system today.
SUMMARY:
I would recommend that we talk to the "BRIDGE" group as they are defining
the needs for the Aquarius manufacturing process and we may be able to work
with them to define and include our requirements. PIMS base level 5.0 would
seem to fit our needs and we should evaluate it for future use.
PRODUCT: Distributed File Manager (DFM) VERSION 1.4
FUNCTION/CAPABILITY
___________________
1. Version control - X
The software keeps every file stored in its database as a separate entity
and assigns a new generation to each file.
2. Configuration control - 0
Configuration control does not exist in the system. An application would have
to be developed using DFM to track configurations.
3. Lock management - X
Files may be reserved, which would prevent other users from storing new
versions. It also allows other users to retrieve a copy of the file
while it is reserved.
4. Backup/recovery - X
This would be done via the standard VMS backup and restore utility.
5. Security - X
Individual and group access control is provided, as well as a general
category called public which allow any registered user to access a file.
The access control type may be defined as well (read,write and delete).
6. Journaling - X
The DFM software creates history records whenever the database changes.
7. Alerts/mail - X
Notification lists are provided for users interested in the status of a
file.
COMMENTS:
An application could be built that would track DFM id's using the KEEP system.
But, this does not seem like a reasonable alternative since we need to put
something in place right away.
The PIMS group is currently looking into using DFM as their distributed file
manager.
SUMMARY:
Further development and enhancements are planned for the future. DFM
has been released and is currently being used by the software publications
distribution group.
All file copying is done using speedway/decnet which is a potential problem as
we would be limited by the number of decnet links allowed on the AQUA cluster.
I think that we should keep DFM in mind for any future applications we may
develop. We should also keep in touch the PIMS group to see whether they
have had success in using DFM with their system.
PRODUCT: CCM
CCM is a file management system written by Mike Evans.
1. Version control: yes.
The files stored in CCM directories are read only. Although
VMS versions are used, since the files cannot be deleted,
and new files can only be written by CCM, the versions are
controlled.
2. Configurations: yes.
Related files are stored in named directories (in other words
files of one configuration are stored in one directory or
directory structure) and files which point to these sets of
files are called configurations.
3. Lock management: yes.
Cluster wide locks are used on files which are being accessed
(these are temporary locks) at any one time. Files which are
reserved by one user cannot be reserved by another.
4. Backup/recovery: VMS.
CCM depends on VMS file and directory structures.
5. Security: VMS.
ACL's and UIC.
6. Journaling: yes.
A history file is kept in which transactions are recorded.
7. Alerts/mail: none.
PRODUCT: ORCHID
In ORCHID's world a piece of the design hierarchy is called a block.
A block can consist of other blocks and a block can contain files
related to that block.
1. Version control: yes.
Blocks are versioned in ORCHID. Specific commands are available to
create blocks.
2. Configurations: limited.
ORCHID understands hierarchy and maintains a hierarchy of blocks. The
user can then choose a tree of versioned blocks from that hierarchy
and perform tasks on that tree.
3. Lock management: none.
ORCHID does not provide lock management. Concurrent access to
blocks is permitted. Users can find out if a block is reserved
but can go ahead and do a concurrent reservation if they please.
ORCHID does not help in resolving conflicts due to concurrent
reservations.
4. Backup/recovery: VMS.
ORCHID depends on VMS file and directory structures.
5. Security: VMS.
ACL's and UIC.
6. Journaling: yes.
A .HISTORY file is kept in the block in which process history is
recorded.
7. Alerts/mail: none.
An ORCHID block contains several very useful control files. The
content of these files is controlled by the processes that run
under the ORCHID design management system. ORCHID depends on the
tools which make up its tool suite to update .HISTORY files,
.DEP (dependency) files, etc. If we were properly exploit the
ORCHID design management system, we would need to provide all the
necessary interfaces between the tools in our tool suite and
ORCHID.
ORCHID is more of a process manager than a file manager and we should
probably keep an eye on the future integration of KATIE and ORCHID
at Hudson.
|