-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ObjectList is returning bad path: /QSYS.LIB/QSYS.LIB #63
Comments
RCA is that this is a combination of JTOpen and the underlying QGYOLOBJ API. QGYOLOBJ returns QSYS for both the library name and object name. JTOpen then combines the two, and that's how "/QSYS.LIB/QSYS.LIB" is being returned. The QGYOLOBJ API is working as intended. @ThePrez thoughts? Leave as-is to be in-sync with the system API or not? |
OK, I guess you can close this out as working as designed. I just find it to be weird. |
Well, IMHO the problem is that the QSYS.LIB filesystem is not actually hierarchically correct. If DSPOBJD claims that QSYS contains itself, then /QSYS.LIB/QSYS.LIB should be a valid path. It's my understanding that from an MI point of view no library contains another library so both DSPOBJD and QSYS.LIB are "wrong". In the MI parlance, a library object is a type of context object and all library contexts are located either in the system ASP machine context or an independent ASP machine context, not another libreary. Above the MI, everything must be referred to by library/object naming, however, so everything must be in a library. And that's why libraries and other objects which only live in the machine context (such as user profiles) are shown as existing in QSYS. IIRC, doesn't JTOpen have a class for generating IFS paths given a library and object name which handles the /QSYS.LIB/QSYS.LIB issue already? If so, I think this interface should handle this properly. |
QSYSObjectPathName
|
ObjectList objList = new ObjectList(sys, "qsys", "Q*", "*LIB");
ObjectDescription[] objects = objList.getObjects(-1, 0);
The result includes the path "/QSYS.LIB/QSYS.LIB". This to me seems to be a bug.
If you try to use IFSFile with the above path, using method isDirectory(). The following exception
com.ibm.as400.access.ExtendedIOException: /QSYS.LIB/QSYS.LIB: Request is not supported. rc=23.
The text was updated successfully, but these errors were encountered: