Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!pacbell.com!ames!mindcraft.com!karish
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.unix.aix
Subject: Re: objectrepository and odme (was Re: 3002 update breaks uucico
Keywords: odm, odme, objrepos
Message-ID: <663467505.4708@mindcraft.com>
Date: 10 Jan 91 00:31:44 GMT
References: <1001@pan.UUCP> <27@softpro.stgt.sub.org> <4704@awdprime.UUCP>
Organization: Mindcraft, Inc.
Lines: 85

In article <4704@awdprime.UUCP> jerry@heyman.austin.ibm.com
(Jerry Heyman) writes:
>In article <27@softpro.stgt.sub.org> cmo@softpro.stgt.sub.org
(Christian Motz) writes:
>>Since I am posting anyway: Hey you guys at Austin, was the $%&@?*#
>>"objectrepository" really necessary? Couldn't you have put the 
>>information in plain ascii files? And, while we're at it, why are
>>commands like the "odme" so poorly documented?
>
>The ODM was initially conceived as being the place where
>all the configuration information would reside and using SMIT would allow the
>user a single command to update the various ODM 'databases' (I use the term
>databases losely here).  This was seen as a better solution than stanza files
>where the information is distributed about in several that would have to be
>updated.  The ODM decision was driven by the fact that part of IBM's market
>for the RISC System/6000 was first time Unix(tm) users.
>
>Rather than having to document all the various places that stanza files would
>have to be changed, we provided the user with a single interface that would
>update the databases.  Granted stanza files were kept around for compatibility
>(among other reasons) and most of the commands can still be run using them as
>opposed to ODM (tcpip comes to mind - inet in particular).

Given the presence of a tool like smit that knows where the
configuration files are, this argument doesn't explain why the ODM
database is needed.  'most' isn't adequate; the sys admin has no way to
know when the traditional approach will work and when it won't.

>As for odme, well that particular odm application is extremely powerful (it can
>change any and all values within a specified odm database) and should have been
>better documented.

As far as I can tell from playing with odme, all it knows how to do is to
load a prepared stanza into the database.  When I found the entry for it
in the info database, I expected to be able to browse the database and
find out what features of the different components were configurable.
Instead, I found no way to determine the names of the objects in
the database, so I couldn't call them up and look at them.  I also
discovered that odme always screwed up the colors in my aixterm
windows.

As a system manager, I have yet to find a real use for odme.

>We erred in the assumption that having all the various
>odmxxx commands would alleviate the need for people to use odme - therefore the
>associated documentation is weak.  Hopefully that will be fixed...

I like smit.  It embodies a lot of system administration
knowledge and calling syntax that I don't have to learn myself.
I like the fact that it documents what it's done.

Several quibbles, though:

- How do I know when the traditional system administration
  approaches are equivalent to smit choices, and when things have to be
  done some special way?  It's fine to provide a maintenance tool that
  hides complication from the naive user, but it's not fine to wrap
  administrative tasks in magic that hinders expert users.  Especially
  when the high-level tools are less than perfect and less than
  complete.

- Where's the documentation for the special utilities that smit calls?
  smit by itself is not a complete system administration interface.
  Especially in large installations, it's necessary to write
  non-interactive programs to do maintenance on multiple machines.
  This is difficult when there's no specification for the behavior of
  the support programs.  Some of the documented interfaces (in the
  paper manuals, anyway) don't seem to exist, and many of the existing
  ones aren't documented.  I want to know how to call what smit calls,
  and I want some assurance that those utilities won't be arbitrarily
  changed or replaced and make my scripts worthless.

- Why does smit write smit.log and smit.script in my home directory?
  There's only one system being maintained; there should be exactly one
  trace of the maintenance process.

- The menu choices are not adequately explained.  They need, at the
  very least, specific references to the info database.

- Where's a list of the 'fast path' keywords for jumping to a
  particular smit menu from the command line?
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000