Ok, thanks.
I believe I found a different approach, from a little experiment.
I have discovered, some differences on symbolic links and external links in USS.
Using the java class: java.io.File, though both types of links appear as files, symbolic links are resolvable while external links are not. For a symbolic link, either of the following methods from File class: isFile(), isDirectory() would return the value true, depending on how the link is resolved. As such, from the File class, the method: getPath() returns the name of the link itself, while the method: getCanonicalPath() returns the path name referenced in the symbolic link. Though, on the other hand to test for a external link, both methods of File class: isFile() & isDirectory() all return false.
However, I also discovered from z/OS C/C++ runtime library is the function: readlink() returns the name referenced in the external link.
As with the sample C++ code below, I’ve ran a test using the function:
Code: Select all
Using namespace std;
#include <unistd.h>
#include <cstdio>
#include <cstdlib>
// I used the follow declaration to resolve compile errors
extern “C” {
int readlink(const char *, char *, size_t);
}
// supply path name of symbolic/external link
int main(int argc, char *argv[])
{
char buf[256];
int len;
if (argc < 2) {
printf(“usage: %s filename\n”,argv[0]);
}
if ( (len = readlink(argv[1], buf, sizeof(buf))) < 0)
perror(“readlink() error”);
else
printf(“readlink() returned ‘%s’ for ‘%s’\n”, buf, argv[1]);
return 0;
}
Next, all I have to do is to write a JNI (wrapper) around this function

Once, I receive the name of the MVS file in java, I then have the option to examine/edit it and pass it on to the appropriate java class to open this file.
