| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 533.1 | Link to AA | HAN01::DOERING | Andreas Doering, SWAS Hannover @HAO | Mon Jan 15 1990 16:08 | 5 |
|
If you need more (insider) information pls. send me a mail. A friend of mine is
working for Anderson, I think he would feed me with more information.
- Andreas
|
| 533.2 | I'm not impressed... | NCDEL::KERNS | just one of the four samurai | Mon Jan 22 1990 20:34 | 9 |
| Re:.0
I'm working on a large "project" with #m and Andersen using the Foundation
tools (INSTALL/1 and DESIGN/1). On the sales side these tools looks great
but from a technical side there are problems. It competes with ACMS and DECForms
but is a poor replacement. Do you want details (there are many)? I could write
them down if needed.
Steve
|
| 533.3 | Yes .. Please post | MAIL::DUNCANG | Gerry Duncan @KCO | Mon Jan 22 1990 20:54 | 3 |
| Absolutely .... can you post them here ???
-- gerry
|
| 533.4 | Here are some of them... | NCDEL::KERNS | just one of the four samurai | Fri Jan 26 1990 02:39 | 101 |
| There are two parts of the Foundation product. These are DESIGN/1 and
INSTALL/1. We know something about DESIGN/1 because two of our specialists just
returned from a 2 day session on it. We know somethings about INSTALL/1 but not
enough because it is still in beta test for the VAX (we think they are
developing it here) but the things we do know have come from talking with the
Andersen people.
DESIGN/1
o Run on a PC (not my personal preference)
o Does not support VAX data types (it looks like IBM data types)
o It uses about thre or four different editors that are not consistent on the
keystrokes and function keys.
o You need to be an octapus to do some of the functions.
o No flow charting but does do a poor Warneir-Orr diagram.
o No link to CDD/Plus. We created our own and down-load the data to it.
o No logic checking (I'm not sure on this one)
o Lots of restrictions on what you can and cannot do, such as you cannot use
column 1 on a form.
I'm sure this list is not complete, but its what I got from our now DESIGN/1
specialists.
INSTALL/1
o Written in 99% COBOL and 1% Macro
o Uses mailboxes for all messaging. Some of the processes have as high as 54
mailboxes used.
o No CDD/Plus link. You can not even load it with out using DESIGN/1 or manually
keying in all of the fields and records.
o Uses copybooks for all data definitions.
o From what we've figured out is that it is maybe a poor COBOL Generator. It
handles the screen for you but you must code in the all of the logic. The code
stub that comes out of it initially does absolutely nothing.
o Single threaded processes and may not automatically start up new servers.
o This diagram best describes what it does, note all of these are processes
running on the VAX, and all of these processes uses up to 3 MB of memory so far.
+------------+
| Screen |
+------------+
|
v
+------------+
| Database |
| Access |
+------------+
|
v
+------------+
| Screen |
+------------+
|
v
+------------+
| Database |
| Access |
+------------+
|
v
+------------+
| Screen |
+------------+
Note, this is for one and only one conversation. A conversation is one or more
database transaction.
o Each user also has there own process
o The data that can be passed from process to process is limited to 4KB, so
under normal database processing you would:
read w/o locks to display the record(s)
keeping the records in memory for use later
allow the user to update the records
read w/ locking for comparison
compare the records to see if anything changed
update the records if comparison is ok
commit
This would require you keep in memory the old record and the new record, to be
passed from process to process. Under INSTALL/1, you are limited to only 4KB
that can be passed, so you must store them somewhere else (on-disk maybe).
o does not make use of the VMS Case tools, except LSE and CMS. Even those are
used poorly within INSTALL/1
I know there are somethings I might have forgotten, but I'll add them later if
I can remember them. Also, our DESIGN/1 specialists are going to a class on
INSTALL/1 next week so we may know more then.
Also, you might want to contact CSG Marketing group. They are evaluating it
right now. The persons name is Rich Devlin.
Steve
P.S. Andersen, in my opinion lied about this product to #M, so they could
replace ACMS and DECForms on this project. Andersen is also using this product
on a project at Northwest Airlines using Sun and IBM with SYBASE and from I can
been told is that that project has released Phase 1 of the project and it is
unusable (poor performance and not enough functionality). Though some of that
may be Andersens methodology and not just the products.
|
| 533.5 | more on Foundation | HAN01::DOERING | Andreas Doering, SWAS Hannover @HAO | Fri Jan 26 1990 17:17 | 33 |
| just some more I've got: These are messages of a convinced Anderson
employee (... not me) !!! Some of the statements are provocative, but they are
not mine (but this Anderson guy):
They consider DEC as a CASE-Point supplier, only for certain phases of a
software life cycle. Anderson are the CASE-INTEGRATOR !!
In addition to DESIGN/1, METHOD/1 and INSTALL/1 they have a PM-tool (like
VAX PM), called MANAGE/1.
DESIGN/1 runs on a PC, the rest on IBM mainframes and DEC (just finished the
port). He said, they have lots of installations on IBM, but he couldn't tell
me if they have often sold the whole package FOUNDATION (...the integrator?)
INSTALL/1 produces COBOL code, METHOD/1 runs in a kind of background,
telling you what to do at what time etc.
The whole application is stored in a repository (in fact 2, 1 logical/1 devel.)
which is layered onto Rdb ("it's not CDD/Plus, it's too slow..." he said).
They support 'COOPERATIVE PROCESSING' (front-end/back-end), one can use a VT,
PC or a workstation as a front-end. They used SMG-routines to support
'windowing' even on a VT. They are working on the DECwindows front-end.
The whole VAX-FOUNDTION is VMS-based, they are working on Unix version which
will be released in maybe 1 year.
They claim compatibility to 'ALL OUR TOOLS' as DECwindows, DECforms, VAXset,
Debugger, Rdb and even a type of bridge to the CDD (no full-function)
I've ordered sales brochures (for the IBM version) plus a piece of paper giving
technical differences between the VAX and IBM version.
Cheers, Andreas
|
| 533.6 | My answer to this salesy stuff | NCDEL::KERNS | just one of the four samurai | Fri Jan 26 1990 20:54 | 38 |
| >DESIGN/1 runs on a PC, the rest on IBM mainframes and DEC (just finished the
>port). He said, they have lots of installations on IBM, but he couldn't tell
>me if they have often sold the whole package FOUNDATION (...the integrator?)
In fact #M is a beta testing the product. The State of Minnesota (I just heard)
beta tested the IBM product and it ran over, did not have the functionality
promised and ran poorly.
>INSTALL/1 produces COBOL code, METHOD/1 runs in a kind of background,
>telling you what to do at what time etc.
INSTALL/1 produces a stub of COBOL which does nothing. METHOD/1 is a
methodology not an application.
>The whole VAX-FOUNDTION is VMS-based, they are working on Unix version which
>will be released in maybe 1 year.
Except DESIGN/1 runs on a PC and does not support VMS data types.
>They claim compatibility to 'ALL OUR TOOLS' as DECwindows, DECforms, VAXset,
>Debugger, Rdb and even a type of bridge to the CDD (no full-function)
DECWindows - not yet
DECForms - have not shown that it will
VAXset - only LSE and CMS not MMS, PCA, etc.
DEBUG - everything by default is compiled with debug
Rdb - only some of it is Rdb. CODE/DECODE tables are RMS files
CDD Bridge - not available until April (maybe)
>I've ordered sales brochures (for the IBM version) plus a piece of paper giving
>technical differences between the VAX and IBM version.
We've been told its just a port of the IBM code, not a rewrite to use the VMS
functionality.
Steve (a person who dislikes Andersen Consulting)
|
| 533.7 | See also CURIE::CASE (KP7, etc.) | SRFSUP::MCCARTHY | More fun than kissing a badger | Fri Jan 26 1990 22:10 | 9 |
|
There are many references to AA in the CURIE::CASE conference and
some discussion of their "foundation" tool set (which is awful).
Note that AA is an extremely dangerous competitor to Digital in the
Systems Integration (EIS) business. They are sort of a cross between
IBM (Account control-wise) and ORACLE (FUD-wise). As usual (cf,
ORACLE), the CASE Marketing Group refers to AA as an ISV who uses
VAXset, making them rather difficult to compete against.
|
| 533.8 | AA Peddles Boxes Too | PHDVAX::CALIDAS | | Tue Jan 30 1990 23:18 | 12 |
|
> Note that AA is an extremely dangerous competitor to Digital in the
> Systems Integration (EIS) business. They are sort of a cross between
> IBM (Account control-wise) and ORACLE (FUD-wise). As usual (cf,
> ORACLE), the CASE Marketing Group refers to AA as an ISV who uses
> VAXset, making them rather difficult to compete against.
Andersen Consulting is also an authorized reseller of all Sun and
Hewlett Packard systems..Compaq too, I think. Additional
incentive to go non-DEC.
|
| 533.9 | | CISM::MORAN | When Money Speaks The Truth is? | Wed Jan 31 1990 19:58 | 9 |
| RE : Last few
AC is a Digital Service Alliance Partner (DSA) as of 1-26-90.
As this program is primarily to help us WIN EIS business I'm not
sure upper management shares your views regarding Andersen Consulting.
The roles of who are our compeditors or partners change from
opportunity to opportunity.
John Moran
|
| 533.10 | | NCDEL::KERNS | just one of the four samurai | Sat Feb 03 1990 06:21 | 8 |
| re:-.1
Maybe Digital needs to chose its partners more carefully. Andersen is stabbing
us in the back on this project and from what I've heard they done this to us
before (Mass Tax project). Andersen will do anything necessary to win, at any
cost to its partners (partner being Digital on this project).
Steve
|
| 533.11 | Technical review of Install/1 | NCDEL::KERNS | just one of the four samurai | Sat Feb 03 1990 06:24 | 287 |
| 533.12 | Really? | NOVA::BOOTH | What am I?...An Oracle? | Sun Feb 04 1990 20:30 | 21 |
| RE: .9
"The roles of who our competitors or partners change from opportunity
to opportunity."
Gee, when IBM picks a partner, they become a partner. A competitor is a
competitor. Seems a very clear way of doing business.
An alternative is to explain carefully the agreements with various
vendors, so that field personnel (and corporate personnel) understand
the ramifications of agreements.
Another alternatice is to work jointly with "partners" on specific
proposals. A formal agreement may not even be necessary for this type
of approach.
If none of these approaches is used, agreements become relatively
useless, except in the case of creating confsuion, where they succeed
admirably.
---- Michael Booth
|
| 533.13 | YES , REALLY! | CISM::MORAN | When Money Speaks The Truth is? | Mon Feb 05 1990 23:06 | 21 |
| Re .12
Lets see now - IBM owns some of AMS yet they also compete against
AMS. Yet IBM calls them a partner. IBM purchased Rolm and then
sold them - should we classify that as a partnership, a marriage,
a rape? IBM competes against Andersen Consulting and works WITH
Andersen Consulting. What's that? Who are our partners? ASK
that has multiple applications on multiple platforms? We partner
with them on SOME opportunities and COMPETE against them on others.
If we do not recognize that alliences/partnerships are continiously
changing and it depends on the particular oportunity that we are
working whether friend or foe then we, Digital, will indeed earn
its reputation as difficult to do business with - and all the arrogance
that accompanies that type of attitude.
In the marketplace it will the customers who will determine the
alliances that will be successful and the alliances that will fail
in the long run. Digital certainly would not want to dictate to the
market who should be partnering should it? So when you say a
competitor is a competitor your right BUT it is totally dependant
on the opportunity in question and is not static forever and ever.
|
| 533.14 | Their partners don't seem to see much difference | COOKIE::BERENSON | Words are a deadly weapon | Wed Feb 07 1990 20:22 | 8 |
| I think Mike needs to talk to people like Metaphor to see how "good" a
partner IBM really is. Further, he might want to talk to the AS/400
group, or the RT group, or etc. to see how they feel about the deals
the other groups at IBM make.
I don't think the situation is any different at IBM and Digital, except
perhaps for the amount of effort they put into hiding the fragmentation
from the customer. Their success at hiding it is, limited.
|
| 533.15 | They don't like the truth... | NCDEL::KERNS | just one of the four samurai | Mon Feb 12 1990 23:08 | 6 |
| re: .11
It has been requested that I remove note .11. If you want further information
please contact CSSG.
Steve
|
| 533.16 | I think it should be set unhidden | ANITA::KELLEY | grep | rm | awk | Tue Feb 13 1990 13:40 | 12 |
| I am not sure who CSSG is, but I assume it is CSG. I thought the stuff was
well written and did not take any pop shots at Andersen Consulting. It just
pointed out, what some of us needed to know - the pitfalls of INSTALL/1.
If the people at CSG can not live with the fact that their 'friends' products
are not perfect, then that is their problem. Since INSTALL/1 is a direct
competitor to our products, we should know about the pitfalls of the product
so that we can consult with Digital's customers to make sure they choose the
best product that fits their needs.
MODERATORS, Please set .11 to be no longer hidden.
|
| 533.17 | Okay | NOVA::BOOTH | What am I?...An Oracle? | Tue Feb 13 1990 14:29 | 17 |
| I have allowed note .11 to be read. It seems to be simply an analysis
of INSTALL/1. I think we have a driving need for good information on
third-party as well as our own products. If we know shortcomingds, we
can work around them. It is surprises that are most unwelcome.
I don't see anything proprietary or offensive in the note in question.
It is just an analysis of a competitive product. I can find no valid
reason to hide a note of this nature. If I did that, then I would also
have to hide similar analytical notes on SmartStar, PowerHouse, Focus,
Oracle, Ingres, Sybase, and every other third-party product that runs
on Digital hardware.
I think we need this type of information to make rational choices. It
is part of being a "business partner" for our customers. Suppression of
this type of information aids no one.
---- Michael Booth
|
| 533.18 | Fixed, At Last | NOVA::BOOTH | What am I?...An Oracle? | Tue Feb 13 1990 17:01 | 263 |
| Note .11 will remain hidden. What I have done is to remove the
account-specific information from the note. That leaves the analysis of
INSTALL/1 intact, which is what everyone needs to see. Hope this solves
the problem.
---- Michael Booth
================================================================================
Note 533.11 Foundation, Anderson Consulting CASE Tool 11 of 17
NCDEL::KERNS "just one of the four samurai" 287 lines 3-FEB-1990 06:24
-< Technical review of Install/1 >-
--------------------------------------------------------------------------------
Here is a technical document on Install/1. Entered here with permission from the
author.
INTEROFFICE MEMORANDUM
Andersen Consulting's INSTALL/1
Technical Report
INITIAL FINDINGS
INSTALL/1 Field Test
--------------------------
Author: John Meler
Rev. Date: 1/30/90
The purpose of this paper is to begin to educate the Digital members
of the XXX project as to WHAT the INSTALL/1 product consists of and
HOW it has been implemented on the VAX system platform.
INTEROFFICE MEMORANDUM Page 2
2 TECHNICAL OVERVIEW
Install/1 is a component of Andersen Consulting's Foundation
product set which also includes includes Method/1 and Design/1.
Install/1 provides a CASE capability and a time-sharing based
transaction processing capability for the Foundation product.
The CASE capability is implemented through a screen driven
interface that is used to collect form and record definitions. The
definitions are stored in a data repository. The interface does not
provide tools to assist in the definitions, but does maintain the
consistency of data declarations between the pieces of the system.
Digital's CDD is not used to implement this functionality, rather,
records and control tables are generated which are then copied into
COBOL programs. Install/1 will generate program modules that use the
records and control tables, but these modules are either stubs or
"clones" of program models with call-backs to the transaction
processing side of the Install/1 product.
The ability to generate executables is also included in this part
of the product, however, the user must provide the names of the
executables to rebuild each time the modules they call are changed.
Install/1 does not have an automated system generation ability like
that provided by Digital's MMS. The Install/1 documentation talks
about maintaining versions of test data but not about maintaining
versions of modules and versions of a system.
It appears that the CASE capability is a less sophisticated
implementation of a subset of the functionality provided by Digital's
CMS, MMS, CDD, DTM, DECforms, and the Application Definition Utility
of ACMS.
The transaction processing capability provides a run time
architecture with some separation of the terminal interface and
processing similar to that provided by ACMS. The Install/1
architecture is the topic of the remainder of this paper.
Install/1 Architecture
Three process types are used to implement the transaction
processing capability of Install/1. The Conversation Control Program
(CCP) coordinates the terminal interface and processing for a
conversation. A conversation is a screen or series of screens that
perform a business function. It is similar to an ACMS task except
conversations may have more than one update data base step.
The second process type is a Message Editing Service (MES)
process. The MES process formats input and output screen data. MES
also can perform syntactical editing. MES uses Digital's SMG routines
and controls the terminal interface.
INTEROFFICE MEMORANDUM Page 3
The third process type performs the processing for the
conversation and is termed a server in the Install/1 scheme. A server
has two distinct parts -- a display side and a processing side. The
processing side accesses the data base and performs any processing
necessary to store or retrieve data. The display side performs any
set up work that MES does not perform. This work includes screen
set-up and data base access for screen display. Servers are not
created dynamically at run time as they are with ACMS.
-------
| CCP |
--------------->| 1|<---------------
| ------- |
| |
| |
v v
------- --------
| MES | |Server|
| 100+| | 250|
------- --------
This architecture is depicted in the figure above. The numbers is
the boxes represent the number of processes required by one
specific system. While the architecture appears similar to ACMS two
important differences should be noted. The screen interface
is not multi-threaded like the ACMS screen interface. There is
one MES process per user.
Secondly, each conversation requires a separate server in the
current version of the product. Servers are serially reusable, as are
the ACMS servers.
Run Time Execution
When a user enters a Install/1 online system, a MES process and a
Conversation Control Record (CCR) are created for the user. The CCR
contains context information for conversations and the data that is
input/output to the screens. After the user selects a conversation
from the menu, control is transferred to the CCP.
INTEROFFICE MEMORANDUM Page 4
The CCP reads the Conversation Control Table (CCT) that
corresponds to the menu item selected. The CCT was generated from the
data repository. The CCT contains conversation flow information and
is similar to an ACMS task data base. If the first step in the CCT is
the display of a form, the CCP passes the CCR to the display side of
the server. See the figure below. The numbers on the flows represent
the order in which the CCR is passed through the system. The number 1
corresponds to the passing of the CCR described above.
-------
4 | CCP | 2,6
--------------->| |<-----------------------
| ------- | |
| | |
| | |
3 v 1 v v 5
------- -----------------
| MES | |Display|Process|
| | | | |
------- -----------------
The server updates the MES information in the CCR and returns the CCR
to the CCP (2). The CCP then passes the updated CCR to the user's MES
process (3) which formats and displays the initial form. The MES
process accepts the user's input, performs syntactical edits and
returns the updated CCR to the CCP (4). The CCP calls the processing
side of the server and passes the CCR (5).
The server passes control for the conversation back to the CCP when
the processing is completed (6). If the conversation contains a second
screen then the CCP passes the CCR to the display side of the server
that just returned it (1), and, the flow described above is repeated
for each subsequent screen in the conversation.
Internal Communication
Communication between the CCP, MES processes, and servers is
accomplished via mailboxes. To pass the CCR from one process to
another two memory moves are performed -- one to copy the record to
the mailbox, and one to copy from the mailbox to the process's working
set. In the single screen case described above 12 memory moves are
required before the first screen is processed. It is interesting to
note that 12 moves are also performed between screens, or during the
time between when the user presses the return key and when the first
character of the next screen is painted. Because data is physically
moved in memory response time will be directly effected by the size of
the record required by the conversation.
INTEROFFICE MEMORANDUM Page 5
All information for the conversation is maintained in the CCR by the
CCP, MES processes, and servers. A CCR can be quite large
depending on the conversation selected. The CCR for the Order Entry
conversation in CSS must be able to hold 14 screens of data just to
create a single line order. An additional page or two of memory is
required for overhead, according to the product documentation. In an
ACMS based system, records are maintained in shared global sections,
and no data need be moved for cooperating processes to access it.
Tasks with large records pay no additional penalty in response time.
One way reduce the response time penalty is to reduce the size of the
CCR. This can be done by writing the CCR to disk after each
screen is entered by the user. The space freed in the CCR can then be
reused for the next screen. There are indications that Andersen may
consider the message manager a bottleneck as they have proposed at
least two schemes to accomplish this. The first was proposed as an
auditing and recovery feature under which each screen would be
journaled to disk.
The second is currently proposed to solve the potential embedded
update problem caused in TP systems when the data base is rolled back
after each screen in a transaction is processed. When the transaction
reaches the update point the application must insure that no data
germane to the transaction has changed since the transaction was
initiated. One common solution that was proposed by Digital's on site
team was read/re-read.
The read/re-read approach caches data from the data base as it is read
to process each screen. At the point of update, the cached data is
checked against the current data base copy by re-reading the
germane data. This approach was rejected as too unfriendly because
the user may receive a message that the data base has changed during
the course of the transaction. A more plausible explanation may be
that read/re-read would increase the size of the CCRs, placing a
greater strain on the message manager.
The approach proposed by Andersen is to build a locking mechanism
external to Rdb. Lock all records germane to the transaction as they
are read. Stall all other transactions that try to read the records,
and, to commit the data to data base after each screen is entered.
While this approach has serious data base recovery problems, response
time problems, and would require a two phase commit for the external
locking mechanism, it does accomplish one thing. It reduces the size
of the CCRs.
INTEROFFICE MEMORANDUM Page 6
Summary
Install/1 has features that are similar to many of Digital's
back-end CASE and TP products. The CASE front-end is mainly a
clerical interface. The Install/1 run time architecture is more
suited to a timesharing system than a transaction processing system.
INSTALL/1 is now in Field Test of it's first release (V1.0 at with
an estimated March, 1990, completion date.
Andersen Consulting has stated that the future direction for INSTALL/1
is to be implemented using VAX/ACMS and DECforms, but no firm timetable
has been committed for delivery of this version of INSTALL/1.
A technical and competitive analysis of INSTALL/1 will be conducted
by Digital's CSG Marketing Group in the first quarter of 1990 as
part of Andersen Consulting's application to become a Digital
cooperative marketing partner (CMP).
|
| 533.19 | Rdb/KB - Knowledge Build | HXOU01::THOMPSON | | Wed Jun 20 1990 21:44 | 7 |
| Does anyone have any information on Anderson's new product Rdb/KB
Knowledge Base. I don't believe it's been released yet but my customer
has seen a demo of it. Is it going to compete with RdbExpert?
I'll cross post this in the RdbExpert notes file.
Thanks,
Susan
|