jerry@heyman.austin.ibm.com (Jerry Heyman) (01/09/91)
In article <27@softpro.stgt.sub.org> cmo@softpro.stgt.sub.org (Christian Motz) writes: [... discussion on IBM's support ...] > >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? Inquiring minds >want to know ;-) > There was (and at times, still is) a running debate about the ODM and stanza files here in Austin. 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). 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. 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... >-- >SOFTPRO doesn't speak for me, and I do not speak for SOFTPRO. So what? > > Christian Motz, cmo@softpro.stgt.sub.org jerry -- Jerry Heyman IBM T-R: jerry@heyman.austin.ibm.com AWD Tools Development VNET : HEYMAN at AUSVMQ AWD Austin T/L : 793-3962 *** All opinions expressed are exactly that - my opinions and NOT IBM's
karish@mindcraft.com (Chuck Karish) (01/10/91)
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
markw@airgun.wg.waii.com (Mark Whetzel) (01/11/91)
In article <663467505.4708@mindcraft.com>, karish@mindcraft.com (Chuck Karish) writes: [odm discussions deleted for bandwidth] > > 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. > [ some good points about smits failings ] Ah, but if you are devloping new software such as device drivers and need to modify elements of the database, odme is a necessity. I don't have the time to write all the @#%$# smit interface menus just to make my new device driver work. That can be done later when all is working and the system now needs polish to make my code fit in 'just like other ibm devices'. ODME also has saved my day several times when real early versions of SMIT would completely screw up the odm database, and smit would refuse to touch it again! ( ah, TCPIP woes during the 89Q build come to mind! :-) Using odme also allows you to specify wild cards for lookups when using the search functions. Useful when you dont know exactly what you are looking for. Press f2 search, and specifiy 'like disk*' for example which will look for any string that starts with disk.. BUT... I agree, at times the odm database does seem like a hassle. Later Markw -- Mark Whetzel My comments are my own, not my company's. Western Geophysical - A division of Western Atlas International, A Litton/Dresser Company DOMAIN addr: markw@airgun.wg.waii.com UUNET address: uunet!airgun!markw
jerry@heyman.austin.ibm.com (Jerry Heyman) (01/11/91)
In article <663467505.4708@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >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: > [... 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. 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. Some people might not want to have all their information in an ODM database, so we have given the option of starting some of the commands (again I'll use inetd) by telling it NOT to use ODM and to use the stanza files. As for which commands do and don't use ODM, all the new configuration information for the RISC System/6000 use the ODM. Some of the older commands can use the databases but don't have to. > >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. > Without proper documentation (and I agree that we haven't provided enough for any of the databases - let alone for odme) all the fields actually make sense. I just used odme on /etc/objrepos/CuAt. In it you will find three columns, the first being the object name, the second being an attribute of the object, and the third being the value for the attribute. You can modify any of these values (though I won't guarantee that you can reboot after doing so). And yes, odme DOES screw up the colors and we are aware of the problem. >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. [... deletions...] > >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. > A thing to note when using smit. It always modifies the appropriate odm database, but doesn't update a stanza file that has the same information in it. This is a shortcoming of the tool and is being addressed. >- 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. > SMIT doesn't call any special utilities. The best way to envision what smit does is by imagining it is a large shell script. Each menu is in turn another shell script that will create the appropriate system command when you have completed all the information that is required for the command to execute. That means that all the proper options will be filled out and the proper syntax is guaranteed. The most interesting thing about smit is that the screens are stored in several odm databases. >- 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? smit.log shows the output once the commands in smit.script are executed. once you have a smit.script that you are happy with, you can use it rather than going into smit to do the same things over and over. It should be possible to take a smit.script from one machine and use it to help configure a different S/6000 machine. >- The menu choices are not adequately explained. They need, at the > very least, specific references to the info database. > This is probably true. I haven't seen what each menu looks like and most were done by the developers of the particular lpp so they may have taken for granted knowledge that someone else doesn't have. >- 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. For example you could start smit up and go through the various screens until you get to the screen where you set the hostname, or you can say 'smit hostname' and get there directly. > > Chuck Karish karish@mindcraft.com > Mindcraft, Inc. (415) 323-9000 jerry heyman -- Jerry Heyman IBM T-R: jerry@heyman.austin.ibm.com AWD Tools Development VNET : HEYMAN at AUSVMQ AWD Austin T/L : 793-3962 *** All opinions expressed are exactly that - my opinions and NOT IBM's
karish@mindcraft.com (Chuck Karish) (01/12/91)
In article <4740@awdprime.UUCP> jerry@heyman.austin.ibm.com (Jerry Heyman) writes: >In article <663467505.4708@mindcraft.com> karish@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@mindcraft.com Mindcraft, Inc. (415) 323-9000
john@fulcrum.austin.ibm.com (John R. Miller) (01/12/91)
In article <663467505.4708@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes:
Several quibbles, though:
[ some of the quibbles deleted ]
- 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.
Although smit is an acronym for system management interface tool, it
can be handy for other users as well. It can be used by almost anyone
to query the system or do (fairly) complicated things that are
unrelated to system management (e.g., It is perhaps a good way to
start using the print spooler.) No sense in cluttering up root's
smit.{log,script} with JRU's poking about.
[ another quibble deleted ]
- Where's a list of the 'fast path' keywords for jumping to a
particular smit menu from the command line?
Try these odmget commands. I don't think they'll list every fast
path, but they'll get most of them.
# First get the commands. Note, however, that you can't
# jump to a command that has a name select in front of it.
odmget -q "has_name_select != 'y'" sm_cmd_hdr | egrep "^->id =|^->name ="
# Next get the name selects that are in front of some commands.
odmget sm_name_hdr | egrep "^->id =|^->name ="
# Lastly get the menu nodes. This one is trickier than it
# should be for reasons that are unclear to me.
odmget sm_menu_opt | egrep "^->next_id =|^->text ="
where -> is a tab in each of the REs.
There may well be an easier way. I'm neither a smit nor an odm
expert. These commands will definitely miss some fast paths. In
particular, I think it will miss some that have more than one path.
For example, one can get to the main NFS menu via
smit nfs_menus
or
smit nfs
or
smit NFS # (normally, the fast paths are case sensitive)
but the odmget commands above only retrieve the first. I think the
other two are "aliases" that were placed by hand but are not used
internally by the menus and so don't appear in the sm_menu_opt list.
Of course, one could get all menu nodes with
odmget sm_menu_opt | grep "^->id ="
but at best this would be less than useful since there would be no
description of the ids.
Piping it through the following sed command will combine ids and
descriptions (of course, 'name' should be replaced with 'text' when
using it on the output of the third command).
# Combine the id with the description on one line.
sed -n -e N -e 's/"\n name = "/" "/' -e p
(I only include this because, personally, I have trouble remembering
how to combine lines in this way.)
Hope (as they say) this helps.
--
John R. Miller (not to be confused with my employer)
work: 512/823-3867 john@glasnost.austin.ibm.com
home: 512/331-0155 john@crcaus.cactus.orgjohn@fulcrum.austin.ibm.com (John R. Miller) (01/12/91)
In article <JOHN.91Jan11215312@fulcrum.austin.ibm.com> john@fulcrum.austin.ibm.com (John R. Miller) writes:
Piping it through the following sed command will combine ids and
descriptions (of course, 'name' should be replaced with 'text' when
using it on the output of the third command).
# Combine the id with the description on one line.
sed -n -e N -e 's/"\n name = "/" "/' -e p
That should be a tab between the newline and name:
sed -n -e N -e 's/"\n->name = "/" "/' -e p
--
John R. Miller (not to be confused with my employer)
work: 512/823-3867 john@glasnost.austin.ibm.com
home: 512/331-0155 john@crcaus.cactus.org