What I learned about SMP/E today

I’ve been developing a Java interface to GIMAPI and writing some sample reports. In the process I’ve been doing a deep dive into the some of the information in the SMP/E CSI.

HFS element delivery

Delivery of HFS elements is one of the more confusing parts of SMP/E. So I took a look into how they are delivered and how the various parts fit together.

Let’s look at an example:

ENTRYNAME : IOEZH002
ENTRYTYPE : HFS
  ZONENAME : MVST
  DISTLIB : AIOEHLIB
  FMID : HZFS510
  HFSPARM : PATHMODE(0,7,5,5)
  INSTMODE : BINARY
  LASTUPD : HZFS510
  LASTUPDTYPE : ADD
  LINK : ../zfsadm
  RMID : HZFS510
  SYMLINK : ../../../../../../bin/zfsadm
  SYMPATH : ../usr/lpp/dfs/global/bin/zfsadm
  SYSLIB : SIOEHLMD

Where does this entry end up, and what’s the deal with all the ../../..?

Firstly, all paths are relative to the DDDEF specified by SYSLIB. If we look at the SIOEHLMD DDDEF:

ENTRYTYPE : DDDEF
  ENTRYNAME : SIOEHLMD
  ENTRYTYPE : DDDEF
    ZONENAME : MVST
    PATH : /sysc/usr/lpp/dfs/global/bin/IBM/
    PROTECT : NO
    WAITFORDSN : NO

The DDDEF should point to a location in your service HFS environment so you’re not updating live code. In this case the service filesystem lives under /sysc.

What we end up with:

The actual element installed by SMP/E is

/sysc/usr/lpp/dfs/global/bin/IBM/IOEZH002

SMP/E creates a hard link (another directory entry for the same inode in the filesystem):

/sysc/usr/lpp/dfs/global/bin/IBM/../zfsadm

SMP/E creates a symbolic link SYMLINK at:

/sysc/usr/lpp/dfs/global/bin/IBM/../../../../../../bin/zfsadm

Each ../ walks up one level in the directory tree. So ../../../../../.. goes up 6 levels from /sysc/usr/lpp/dfs/global/bin/IBM/ and results in /sysc/bin/zfsadm.

The symbolic link target SYMPATH is relative to the symbolic link, so it points at:

/sysc/usr/lpp/dfs/global/bin/IBM/../../../../../../bin/../usr/lpp/dfs/global/bin/zfsadm

I think I have that correct… did I mention it was confusing? It’s walking up and down the directory tree.

It’s too hard to figure out manually, so I wrote a program to resolve (using Path.normalize) and report the paths. We end up with:

Entry: IOEZH002   SYSLIB: SIOEHLMD   DDDEF PATH: /sysc/usr/lpp/dfs/global/bin/IBM/
     PATH: /sysc/usr/lpp/dfs/global/bin/IBM/IOEZH002
     LINK: /sysc/usr/lpp/dfs/global/bin/zfsadm
  SYMLINK: /sysc/bin/zfsadm
        -> ../usr/lpp/dfs/global/bin/zfsadm
        -> /sysc/usr/lpp/dfs/global/bin/zfsadm

The element installed by SMP/E:

/sysc/usr/lpp/dfs/global/bin/IBM/IOEZH002

The hard link, which is the commonly used name:

/sysc/usr/lpp/dfs/global/bin/zfsadm

The symbolic link which creates a command in the search path:

/sysc/bin/zfsadm -> ../usr/lpp/dfs/global/bin/zfsadm

which resolves to:

/sysc/usr/lpp/dfs/global/bin/zfsadm

which is the hard link to the SMP/E element. So everything fits together neatly.

To confirm, I looked at the live system (removing the service filesystem prefix /sysc):

$ ls -li /usr/lpp/dfs/global/bin/IBM/IOEZH002
22743 -rwxr-xr-x 2 OMVSKERN OMVSGRP 353 Jun 2 2023 /usr/lpp/dfs/global/bin/IBM/IOEZH002

$ ls -li /usr/lpp/dfs/global/bin/zfsadm
22743 -rwxr-xr-x 2 OMVSKERN OMVSGRP 353 Jun 2 2023 /usr/lpp/dfs/global/bin/zfsadm

$ ls -l /bin/zfsadm
lrwxrwxrwx 1 OMVSKERN OMVSGRP 32 Jun 12 2023 /bin/zfsadm -> ../usr/lpp/dfs/global/bin/zfsadm

ls -li shows the inode, and we can see that /usr/lpp/dfs/global/bin/IBM/IOEZH002 and /usr/lpp/dfs/global/bin/zfsadm are entries pointing to the same entry in the filesystem (inode 22743).

/bin/zfsadm is a symbolic link to /usr/lpp/dfs/global/bin/zfsadm.

See the samples or try it yourself

If you want to see other sample SMP/E queries, they are on Github at: https://github.com/BlackHillSoftware/gimapi-samples/tree/main

More information about the Java GIMAPI interface is available from: https://www.blackhillsoftware.com/easygimapi/