1
1:root@SERVER:/root # lslpp -l bos.perf.perfstat
  Fileset                      Level  State      Description         
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.perf.perfstat        6.1.9.100  COMMITTED  Performance Statistics
                                             Interface

Path: /etc/objrepos
  bos.perf.perfstat          6.1.0.0  COMMITTED  Performance Statistics
                                             Interface
1:root@SERVER:/root #

The different version can cause dependency or builddate verification problems. This issue is not shown by lppchk nor instfix commands.

Q: is it a healthy thing that according to lslpp different ODM's have different version of a software? Is this normal? Could there be different versions and still, it will not cause problems?

Peter84753
  • 159

1 Answers1

2

This is normal AIX behavior, and it's a good sign -- you've been patching! You've upgraded at least perfstat, and hopefully the whole TL, up to TL9 SP6. The system was installed with a base level of AIX 6.1 and was then patched up from there.

The lslpp -l bos.perf.perfstat (lower-case 'l') output splits out the root (non-shared) ODM from the usr (shareable) ODM. If you had used lslpp -L bos.perf.perfstat (upper-case 'L'), it would combine those two with the most recent level. You can see expanded information with the -a option: lslpp -al bos.perf.perfstat will show all of the intermediate patches that were applied to that fileset. The difference in versions between the /usr/lib/objrepos path and the /etc/objrepos path simply implies that the root/non-shared files were not updated with the patches. In this particular case, there are no files in the /etc/objrepos path of this package -- notice the NONE at the end:

$ lslpp -f bos.perf.perfstat
  Fileset               File
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.perf.perfstat 6.1.4.0
                        /usr/lpp/bos.perf/README.perfpmr
                        /usr/lib/perf/cfg_perfstat
                        /usr/lib/perf/cfg_perfvmmstat
                        /usr/lib/drivers/perfvmmstat
                        /usr/lib/perf
                        /usr/lpp/bos.perf
                        /usr/lib/perf/perfstat

Path: /etc/objrepos
  bos.perf.perfstat 6.1.4.0
                        NONE

If you want builddate information, your best bet is the -L option to lslpp, although I don't see any packages off-hand that display a build date. In any case, if there is software that's using -l to gather builddate information, that software needs to be changed.

If you are trying to determine version information for installed packages, my suggestion would be to use lslpp -Lc instead of lslpp -l -- this would consolidate the ODM versions to the highest level, and use colon-separated output (for easier programmatic parsing).

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
  • wow, Thanks for the answer! Only one comment: "root/non-shared files were not updated with the patches" -> but is this a normal thing or a software error?? if there are different versions, we can get builddate verification problems, so upgrade fails! usually we delete the ex.: "bos.perf.perfstat" from both ODM, install base for given package, ex.: "bos.perf.perfstat", then update it to the requested level... so I think this is not normal :\ – Peter84753 Sep 19 '16 at 16:04
  • I can't speak to how IBM "normally" does things, but you'll notice that there were no files to not update (double-negative), so they've apparently decided to not bump the version number in that situation. I'd suggest clarifying the situation with your builddate verification software, as versions are under IBM's control. – Jeff Schaller Sep 19 '16 at 16:19
  • there are two ODMs, so two installs when installing a fileset. If one install fails for any reason, it will roll back that install, thus the two ODM could have different versions. ex.: bos.perf.tools could fail because of missing dir: /var/perf/pm/daily. the solution is to force the package reinstall in smitty "OVERWRITE same or newer versions? = yes'" or to remove only the bad version from the "bad" ODM then install the needed version. – Peter84753 Sep 24 '16 at 13:34