Use a web browser to verify all URLs specified in /var/dhcp/dhcptab and in the javaosopts.txt file.
Run snoop(1M) and watch the packets to and from the JavaStation.
Early access versions of Views improperly saved properties into ~/.jdt.
See the README files in /opt/SUNWjdt/doc for each component.
Refer to the following Solaris man pages: dhcp(4), dhcp_network(4), dhcpconfig(1M), dhcptab(4), dhtadm(4), pntadm(4), in.dhcpd(1M), snoop(1M)
To update the "About" button, you'll need to edit the lib/html/welcome/welcomeAbout.html file.
To change the alias associated with the "Feedback" button, you'll need to update the selector.props property for each group configuration.
CalendarView works best with the Common Desktop Environment (CDE) calendar server. The feature of storing mail messages with appointments is available only for calendars in the data version 4 format. This format is supported by the CDE calendar server. The OpenWindows calendar server does not support the data version 4 format.
To find out whether the CDE calendar server is running on a particular machine, as superuser, type:
# /usr/dt/bin/sdtcm_admin -l -h name-of-machine-to-check
If the sdtcm_admin command returns a list of calendar names, the CDE calendar server is running on that machine. Otherwise, the command returns the following message:
# /usr/dt/bin/sdtcm_admin: Could not list calendars because: Service is unavailable.
The CDE calendar server is available in the SUNWdtdmn package.
When an appointment is scheduled through MailView, the mail message containing the appointment is saved in the login user's calendar mailbox and a reference to the saved mail message is stored with the appointment. This feature is not available for calendars in the OpenWindows calendar format, data version 3 or less. This is a limitation of the data version 3 (or less) format.
You can use the /usr/dt/bin/sdtcm_convert calendar conversion utility to convert data version 3 calendars to data version 4 format. Refer to the sdtcm_convert man page for details.
The Additional Permissions list within the Properties dialog may contain login IDs instead of complete names (for example, joes may be displayed instead of Joe Smith). This can occur if the user's calendar is in the OpenWindows data format or if the entry was added using calendar clients other than CalendarView. If the calendar is in the OpenWindows data format, use the /usr/dt/bin/sdtcm_convert utility to convert it to data version 4 format. Refer to the sdtcm_convert man page. Otherwise, use only CalendarView to add editors.
For editable calendars, clicking within an empty time slot will create a new 1-hour appointment in that time slot. There may be a significant delay in refreshing the view. If you did not intend to create a new appointment, delete it by clicking the Delete button in the CalendarView detail area.
To demonstrate automatic update, you need two calendar clients (two CalendarView or CalendarView and dtcm).
It may be useful to capture output from the Namesvc proxy to a file. This can be enabled by editing /opt/SUNWjdt/cgi-bin/namesvc. Comment the line:
# $JAVA_HOME/bin/java sunw.jdt.dex.server.Namesvc
# $JAVA_HOME/bin/java sunw.jdt.dex.server.Namesvc [boxv ] tee /tmp dex.last
If you perform a search and this file doesn't get created or updated, then chances are your httpd server is having problems launching the cgi-bin script. If the output in the file indicates some type of error:
Content-type: text/plain <DBError>:6
then the database probably couldn't be found or the permissions on the file are not set correctly. Make sure the database files have read access for world.
If you have enabled capturing output to /tmp/dex.last and this file isn't being updated, then it might be worth checking the httpd server error log file. This may indicate that there was some sort of cgi-bin error. The server may not be configured to run cgi scripts or maybe it couldn't find the namesvc script.
Make sure the database files you have created have read access set for world (chmod 664).
The 1.1 back end is not compatible with 1.0 clients. If you need to support both 1.1 and 1.0 clients, you have several choices. The easiest way to handle this is to install the 1.1 back end on a different server than the 1.0 back end. In this configuration you simply follow the steps that have already been outlined above. If you want to support 1.1 and 1.0 clients from the same server, follow these instructions:
Install 1.1 on the server but do not install it on top of your 1.0 installation. Put 1.1 under /opt/SUNWjdt1.1 or something similar.
In your web server cgi-bin directory make a symbolic link from webserver/cgi-bin/jdt1.1 to /opt/SUNWjdtd1.1/cgi-bin.
Edit the namesvc file in /opt/SUNWjdtd1.1/cgi-bin. Change the JDT_HOME environment variable from /opt/SUNWjdt to /opt/SUNWjdt1.1.
Edit /opt/SUNWjdt1.1/lib/props/standard/nameview.props. Change the value of the dex.db.cgi.proxy property to /cgi-bin/jdt1.1/namesvc.2.0.
Edit /opt/SUNWjdt1.1/lib/props/namesvc.props to point to your database.