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?
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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."
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |