objectrepository and odme (was Re: 3002 update breaks uucico

Chuck Karish karish at mindcraft.com
Sat Jan 12 11:25:04 AEST 1991


In article <4740 at awdprime.UUCP> jerry at heyman.austin.ibm.com
(Jerry Heyman) writes:
>In article <663467505.4708 at mindcraft.com> karish at mindcraft.com
>(Chuck Karish) writes:
>[... discussion about why objrepos/odm was created ...]
>>
>>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.
>
>This raises some questions as to exactly what SMIT is.  SMIT is nothing more
>than a command builder that saves an administrator from knowing all the nitty
>gritty little commands that are required to do configuration and other mgmt
>type operations.  

This is a paraphrase of one of the points I made in the quoted
article.  It doesn't address the issue:  If the point of the ODM is to
move towards a system that's maintainable by novices, and smit is
available to serve as a high-level interface for use by non-gurus, what
difference does it make whether the system configuration is stored in a
fancy binary database or in ASCII files?

>When I said 'most' configuration could still be done in stanza files (and I 
>gave the example of inet.conf) this lead to the above comments.  If you use 
>SMIT and ODM for all your configuration information, then you should be ok.

If I use SMIT and ODM for all my system configuration tasks on all
the 6000s here, I stay stuck in menu hell all day long.  Not acceptable.
Yes, I do know how to use smit.script to construct my own tools.

>>As a system manager, I have yet to find a real use for odme.
>
>I'm not real sure that as a system manager I would want to use odme.

There is no documentation, other than what comes up in smit menus, of
what device and system properties are modifiable.  The smit menus seem
to be incomplete, and I've had to deal with some that are buggy (on
pre-release software; on the base GA release smit seems to be pretty
good).  It's impossible to use the handy little commands by guessing
what the attribute identifiers are; odme is the only tool I've been
able to find that gives me any hope of being able to seek out this
information.

>>- Where's the documentation for the special utilities that smit calls?
>
>SMIT doesn't call any special utilities.

OK.  Show me the man pages for chrtcp, mkszfile, and mksysb.

>The most interesting thing about smit is that the screens are
>stored in several odm databases.

Maybe it's interesting to you; it's an annoyance to me.  Smit isn't
always willing to show what command it will run without actually
running it first, which means I can't look at the manual page for the
command before deciding to commit to a system change.  If it were
actually a series of scripts, or if the specification were stored in an
accessible file, I'd be able to look before leaping.

>>- 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.
>>
>Have you actually looked at either of these two files?

Sure.  What I meant was: smit writes smit.log and smit.script to / if I
log in as root, and to my home directory if I su to root.  This is a
botch; it means that I can't use /smit.log as a record of the changes
the system has been through.

>>- Where's a list of the 'fast path' keywords for jumping to a
>>  particular smit menu from the command line?
>
>A fast path would be to say 'smit commandname' and you will be jumped directly
>to the menu that deals with that particular command.

Some of the keywords suggested in the installation documentation
don't seem to be command names.

To repeat what I said last time, I think smit is a good tool.
It would be a better one if the AWD folks would make the
system configuration system more self-consistent (give me one
database, and make it right) and more open.
-- 

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



More information about the Comp.unix.aix mailing list