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?

Il 15.09.2016 04.19, Jonathan Ball ha scritto:
> 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?
>
Who knows? Maybe you are passing to Qp0lGetAttr() an ill-configured 
path-name, either wrong path length or path type. Look at pathname fields.

On 9/14/2016 10:48 PM, Dr.UgoGagliardelli wrote:
> Il 15.09.2016 04.19, Jonathan Ball ha scritto:
>> 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?
>>
> Who knows? Maybe you are passing to Qp0lGetAttr() an ill-configured
> path-name, either wrong path length or path type. Look at pathname fields.

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."

Il 15.09.2016 09.13, Jonathan Ball ha scritto:
> On 9/14/2016 10:48 PM, Dr.UgoGagliardelli wrote:
>> Il 15.09.2016 04.19, Jonathan Ball ha scritto:
>>> 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?
>>>
>> Who knows? Maybe you are passing to Qp0lGetAttr() an ill-configured
>> path-name, either wrong path length or path type. Look at pathname
>> fields.
>
> 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."
>
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.

On Thursday, 15 September 2016 14:19:53 UTC+12, Jonathan Ball  wrote:
> I developed an external table function to produce a list of IFS objects=
=20
> owned by a selected user.  The service program calls the QSYLOBJA API to=
=20
> develop a list of IFS objects for the user profile passed as input, then=
=20
> invokes the Qp0lGetAttr() API to retrieve a list of attributes for an=20
> individual IFS path/object.
>=20
> For one user profile of interest, Qp0lGetAttr() was ending in error for=
=20
> 200 (out of over 80,000) path/objects owned by the profile.  The numeric=
=20
> error code is 3025 - "No such path or directory".  I looked in the IFS=20
> via Navigator for a handful of them, and sure enough, they don't exist.
>=20
> Why would QSYLOBJA indicate the profile owns non-existent IFS objects?


I suspect you'll have difficulties deleting those profiles as the system wi=
ll complain that owned objects exist even though they don't.  I had a simil=
ar issue many many many years ago where I tried to delete a profile and cou=
ldn't as the system was saying it owned objects.  Using wrkusrprf and looki=
ng at the owned objects, they were there but when I tried to delete them th=
e 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 li=
st 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 (som=
ething to that effect).  They'll be out of sync, hence the errors you are g=
etting.  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 cou=
ld get deleted.  Probably not a solution you can use :-)

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

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.

On 9/16/2016 6:16 AM, John Voris wrote:
> 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.

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.

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.