IFS and API oddity

Jonathan Ball

unread,

Sep 14, 2016, 10:19:53 PM9/14/16

to

I developed an external table function to produce a list of IFS objects
owned by a selected user. The service program calls the QSYLOBJA API to
develop a list of IFS objects for the user profile passed as input, then
invokes the Qp0lGetAttr() API to retrieve a list of attributes for an
individual IFS path/object.

For one user profile of interest, Qp0lGetAttr() was ending in error for
200 (out of over 80,000) path/objects owned by the profile. The numeric
error code is 3025 - "No such path or directory". I looked in the IFS
via Navigator for a handful of them, and sure enough, they don't exist.

Why would QSYLOBJA indicate the profile owns non-existent IFS objects?

Dr.UgoGagliardelli

unread,

Sep 15, 2016, 1:48:58 AM9/15/16

to

Who knows? Maybe you are passing to Qp0lGetAttr() an ill-configured
path-name, either wrong path length or path type. Look at pathname fields.

Jonathan Ball

unread,

Sep 15, 2016, 3:13:41 AM9/15/16

to

It's possible, but I don't think that's it. I added some code to
capture the supposedly bad path name and write it to a table. When I
look at the supposedly invalid entries, that path - that is, all the
directories - exist. It's the actual file that doesn't. The file names
all appear to be validly formatted names, i.e. the names and extensions
appear to be good.

There's also this: my manipulation of the path names and lengths from
the output of QSYLOBJA is correct for the other 80,000+ entries. The
call to the attributes API works and returns valid results. I'm running
this on multiple LPARs, and on just one of the others I got a solitary
error, 3485, which reads "A loop exists in the symbolic links."

Dr.UgoGagliardelli

unread,

Sep 15, 2016, 4:29:36 AM9/15/16

to

I you're following symbolic links, it can happen that a soft-link is
referring to something that doesn't exist anymore.
Also, if a path-name contains some charaters code-page dependant and in
the path-name structure you're using the wrong ccsid.

jse...@yahoo.co.nz

unread,

Sep 15, 2016, 5:05:14 PM9/15/16

to

I suspect you'll have difficulties deleting those profiles as the system will complain that owned objects exist even though they don't. I had a similar issue many many many years ago where I tried to delete a profile and couldn't as the system was saying it owned objects. Using wrkusrprf and looking at the owned objects, they were there but when I tried to delete them the system complained they didn't exist and wrklnk showed nothing. According to IBM (and I don't have the correspondence from so long ago), when you list owned objects by a profile, it builds the list from the user profile end back but when you go via wrklnk, it builds it from the directory side (something to that effect). They'll be out of sync, hence the errors you are getting. I don't know how to fix it. In my case, as I was trying to delete the profile, IBM gave instructions on force damaging the profile so it could get deleted. Probably not a solution you can use :-)

At any rate, I'd suggest contacting IBM support.

John Voris

unread,

Sep 16, 2016, 9:16:38 AM9/16/16

to

Other things to check . . .

The files may have been saved with STG(*FREE) rather than STG(*KEEP)

The files may have been created in a UNIX way . . . If the name is $xxxx then it becomes a hidden file. You may need to go into PASE or QSH to see the files.

John V.

Jonathan Ball

unread,

Sep 16, 2016, 4:28:52 PM9/16/16

to

I figured it out. The apparently missing IFS objects are all symbolic
links. I'm not an IFS power user and I don't know what symbolic links
do, but apparently they have no attributes to be retrieved by Qp0lGetAttr().

Thanks for your time, and thanks also to jsev99 and Dr.Ugo.

Obelix

unread,

Sep 17, 2016, 5:38:28 AM9/17/16

to

Il 16/09/2016 22:28, Jonathan Ball ha scritto:
> I figured it out. The apparently missing IFS objects are all symbolic
> links. I'm not an IFS power user and I don't know what symbolic links
> do,

SymLink are just shortcut pointing to a different File/Directory.

> but apparently they have no attributes to be retrieved by
> Qp0lGetAttr().

Well, not really. the 7nth param of the call (Follow_Symlnk) tells the
API to return attributes for the SymLink itself ( when value is 0 ) or
to return attributes for the object to which the SymLink reffered (when
value is 1).

Since, FWICR, a soft SymLink may exist even if the referred object no
longer exist, if you use '1' for the Follow_Symlnk, i suppose you might
get a 3025 error because the referred object no more exist.