DSXchange

Many of the file related internal displays and commands, notably the LIST.READU command, will show a DataStage user as having a Device and Inode open for a hashed file.

Question: How do you find out what physical file is actually open?

Answer: You need to take several steps in order to get the answer. The steps are:

1. Convert the Device number into a useable Major and Minor device.
The Device is displayed as a decimal number such as "2621442" which doesn't really mean much until you dissect it. First off, convert this to a Hexadecimal number. The result, 0x280002, is the actual UNIX major and minor device number with the leading zeroes stripped. Take the last 4 digits and convert from Hex to Decimal to get the minor number, then use the remaining digits and convert from Hex to Decimal to get the major device. Thus, "2621442" actually converts to Major Device 40, Minor Device 2.

2. Find out which device names match this Major/Minor number
Armed with this information, go to your /dev directory and do an "ls -l" and you'll see that the display is something like

[quote][/quote]

The columns just before the date list the major and minor device, i.e. for "hd10opt" the value is "10, 10". There can be several devices with the same major, minor number.

3. Get the mount path that corresponds to this device name.
Use the mount command to get the list of mounted devices. Only one of the names list from the previous command will match a mounted device.

The 2nd column of the output, in this case "/opt" shows you the mounted path. We are almost finished!

4. Use the find command to find the inode on that mount point
Use the find -inum command to get the actual filename. The syntax on AIX is "find {Result from #3.} -inum {inode number} -xpath 2>/dev/null" and it will return the one line that contains the fully qualified path to the file with that inode or no lines if the inode doesn't exist. The find command needs to traverse and search for the inode, so this can take several seconds or even longer on a big file system.

As far as I know these steps need to be done, but I'd welcome any more efficient approach that doesn't involve looking through the /dev and mount points.

Run ACCOUNT.FILE.STATS ALL LOCAL in the project on a regular basis. This updates a hashed file called STAT.FILE in the project.
Apart from having gathered file tuning statistics, STAT.FILE contains the device, inode and file name for everything accessible from that account's VOC file with type "F" or "Q". (Thus you may need to SETFILE for your directory-based hashed files.) For example:

The local files are, as Ray has shown, easily found and tracked using the STAT.FILE contents. The difficulty lies in locating all those hashed files that aren't referenced in any VOC when given just a device and inode.
I thought that some of the denizens here might be interested in how to get from a reported file device/inode to an actual file. Those of us from Primos and UniVerse have been doing it so long that it has become second nature, but I felt that there might be the odd person here who might benifit from locating what file is actually referenced when they get some cryptic message with a device number.

There's an executable $DSHOME/bin/UVfile that can help to find these "orphaned" hashed files. Use find to capture names, exec UVfile, then grep '(' to select only those with UniVerse file information in their reports. For example: