>After installing GNUCORE, GNUGCC, and GNUCVS, the java program
>quit working.

You would be better served to pick up the NMSTORE version of GNU
in the future. That resolves the security problems.

Even so, your ls -l is interesting, because I see the same symptoms
on ORBiT's machine. But, both work for me:

/BACKUPPL/KLEIN(132): /usr/local/java/jdk1.1.7/bin/java -version
java version "JDK 1.1.7B"
/BACKUPPL/KLEIN(133): /usr/local/java/jdk1.2.2/bin/java -version
java version "JDK 1.2.2"
Classic VM (build A.22.02 built on 05/30/00 @ 14:12, green threads, HP)
/BACKUPPL/KLEIN(134):

>I could *chmod* the files to correct the access but what is a group of 0
>and how do I make the files have it?

You can use the following brute force method to begin cleaning things
up. From /usr/local/java/jdk1.1.7 do (as MANAGER.SYS):

chmod -R o+r *
find . -perm -u+x -exec chmod o+x {} \;

(You'd be best served to cut/paste those commands)

The first command changes everything under Java such that everyone
can read it. The second command finds everything where the owner
has execute access and grants execute access to everyone.

>How did I do this?  It was clearly
>something that occurred while installing the GNU stuff, since just before
>it the JAVA command was working.

I find that hard to believe, because GNU doesn't go into the java
hierarchy. However, GNU does create various XLs in /lib and /usr/lib
and if you didn't do it as MANAGER.SYS, it may have changed a permission
there and that's what is causing you to fail. You might want to do the
chmod stuff in /lib and /usr/lib first and see if that fixes things.


Also note that the users accessing java must also have PH capability
assigned to them.