SWB Mozilla Browser Tuning and Configuration parameters

[Richard J Maher]

Hi,

Can anyone please help me with tuning/configuration options for SWB on VMS?

I have this Web Application that uses a Java Applet (10KB) to pop up a couple of dialogue boxes for user login and then uses some reasonably sophisticated JavaScript/HTML/DOM to provide Batch/Print Queue Lookup functionality to any VMS server (in this instance) to the Deathrow cluster in Florida.

This example works perfectly well with (at least): -

. Windows 98, 2000, XP, and IE6 Sun Java 1.4.2-13 or higher
. Windows Vista 64bit IE7 Java 1.6
. Windows Firefox
. Linux Firefox
. Mac OS X Safari Java SDK 1.5
. Mac OS X Firefox
. Opera Windows XP JRE 1.5

Which is pretty much a big slice of the browser client market, yes?

The problem is (until recently) no one has been able to get it to work on VMS with Mozilla: -

This is what Craig A. Berry had to say:-
>>>>>>>>
On OpenVMS Alpha v8.3, SWB 1.7-13, Java 1.5.0-3, I got as far as
entering the credentials, clicked OK in the acknowledgement dialogue,
and then the browser went CPU-bound and has yet to come back 10 minutes
later. I have never used the Java plug-in with this browser before and
have no idea whether my settings are appropriate. It's an XP1000 with
2GB of RAM and I have run a number of Java GUI applications without
incident
<<<<<<<<

And this is what John Santos had to say today: -
>>>>>>>>
Feh! I thought people were claiming this doesn't work on VMS. Seems to
work just fine. (Though the 1st time through, it seemed to be downloading
or compiling something and my process was using 126% of the CPU for a while...
In about 10 seconds, it came up to the login box and the CPU consumption went
back to background levels... Subsequent logins and other operations (refresh,
sort the job list by various orders, etc.) seemed more or less instant with
no appreciable load.)

VMS V8.3 on an Itanium rx2620, 2 processor 1.6GHz, 4GB memory, Java 1.5.0-1,
Mozilla (SWB) 1.7.13.
<<<<<<<<<

So it does look like simple tuning/configuration issues, but I’m a bit stuck when it comes to knowing what levers to pull for SWB performance on VMS :-( Can someone who knows what they’re doing with Mozilla on VMS, please run my example and advise as to what my SYSGEN or Process Quotas should be in order to gain similar performance to all the other platforms that it currently runs on?

Thanks for all advice and assistance.

Cheers Richard Maher

[Richard J Maher]

Ok, here are the DEMO run instructions (Looks like ITRC needed my question broken in two for size?)

To activate the DEMO Application from your VMS Mozilla Browser please click on the following link:-

http://manson.vistech.net/t3$examples/demo_client_web.html

In order to be able to use this Queue Manager example successfully you will
need:-

1) Javascript enabled
2) Java Applets enabled
3) Can't be behind a Firewall that forbids all unknown outgoing connections
(otherwise open-up 5255)
4) Must be running any of the other industry standard configurations mentioned previously
OR
4a) Must be running Java 1.5 on VMS 8.3
4b) Must be running SWB 1.7.13

All things being equal you should then be prompted (via Java modal dialogue
box) for:-

Username: TIER3_DEMO
Password: QUEUE

If things are still going well, enter an asterix "*" for the Queue Name and
you will see the List-of-values appear with all the available queues on the
Deathrow cluster. Now click on the "Get Job Info" button and we're away!

If not the Java Console could give you a message.

If you're slightly curious as to exactly how easily this full-function,
high-quality, high-performance GUI has gained access to the VMS servers that
we all know and love, then all the source code is available at
http://manson.vistech.net/t3$examples/ (Can also help to track down any
problems)

Here's some of the functionality-catwalk highlights from the example: -

1) Full, one-time, context-specific, VMS User Authentication. No Cookies,
Session IDs, Password Caching or generic Work-Station or Browser
credentials! When you load the demo_client_web.html page into your browser,
a Java Applet is automatically activated that prompts the user for their VMS
Username and Password via a modal dialogue box. If authorization fails, the
"Access Denied" page will be displayed and VMS Intrusion Detection (in
accordance with the policy set out by your System Manager) will be enforced,
and Login-Failures is incremented in SYSUAF. Alternatively, if authorization
is successful (and you left the "Display Logon Confirmation" box ticked)
then a Welcome dialog box will be displayed detailing last login times and
the number of unsuccessful login attempts (if any). Login-Failures is now
set to zero and last non-interactive login time is set to the current time.

If you refresh this page, or move to a different page, then the server
connection is broken and you must be re-authorised before continuing to
access the Demo Queue Manager application.

2) A Hot-Abort button! After you have pressed the "Get Job Info" button
you'll notice that the "Abort Request" button becomes active and turns red.
(Actually you probably won't notice 'cos this query completes too quickly
:-) You can edit the DEMO_UARS.COB code and change the value of the
DEBUG_DELAY field if you want to see your 3GL Interrupt routine in action.)
In this case the cancel-flag I've set in the AST routine is picked up in the
mainline code, resulting in the graceful termination of the loop that
controls "next queue" (or "next row") retrieval.

Also, if you look at the getResponse() function in query_lookup.html, you
will see how the chan.setTimeout() method has been deployed to provide an
erstwhile "blocking" socket Read with the ability to surrender the
event-thread for things like processing the Abort button and ticking over
the clock. (all of this, and much more, "infrastructure-code" is already
there and doesn't have to be re-invented)

3) Predictive text on the Queue Name field so that all matching VMS queues
are retrieved on-demand as the user types. As is now common-place with many
websites, a drop down select list of matching options is automatically
retrieved from the server and made available for the user to select from.

4) Result-set drill-down. Many database queries return a result-set of rows
for the user to scan through and possibly drill-down into for more detail.
I've provided a reasonably generic example of this, where all matching Job
Entries have been populated into a dynamic HTML select list. Once again the
user was able to see the select-list grow, the scroll-bar diminish, and
"Jobs Found" field tick over in real-time, whilst continually being
empowered (by the Abort button) to curtail the results at any time!

If you click on an entry in the Select List then the changes and the
entry_details.html page appears. See the parent.entry_details.getReady()
call in queue_lookup.html to see how the handover to the new frame takes
place. (Also see goBack() in entry_details.html to see how simply that
operation is reversed.)

The user is now free to move forward, back, first, last, refresh, and delete
queue entries, or return to the previous frame. (Thanks to the deployment of
the VMS Persona functionality, the user is only permitted to see those queue
entries that the Username they signed in under is permitted to see. They can
also *only* delete those entries that this username is allowed to delete.)

5) Floating

s. You'll see that any queue names are highlighted in bold
and italics; if you mouseover any of these fields when they are not blank
then the current status information for that queue will be retrieved from
the server and displayed in a quasi-popup DIV.

6) Local Result-Set Sort. If you click on the "header" or "first" row in the
Select List of queues, you will get a popup prompting you for a sort key. If
you select one, the contents of the Select List are sorted in the chosen
order. (Try enter "*" for the Queue Name and then clicking "Get Job Info" to
get some data worth sorting)

[Craig A Berry · Accepted solution]

I missed John's success report earlier. The main difference between his set-up and mine is that we're using entirely different JVM implementations. On Itanium, you get Sun Hotspot, the JIT portions of which are shared with HP-UX, but on Alpha you get either the "Classic" or "Fast" JVM, which I believe are both DEC/Compaq/HP projects of long standing that used to be shared with Tru64 (before Tru64 support was discontinued).

I've tried both classic and fast VMs and can't run the Tier3 demo applet with either. I get bucketloads of the following error in my Mozilla log file:

**************** SERVER ERROR **************
SecureCallStaticMethod: bad method
**************** ************ **************

I have a file called java_vm.dmp, but it's binary and I don't know how to read it or whether it wouuld tell me anything relevant if I did.

I've now tried the applets on the Sun page that demonstrates the Java plug-in:

http://java.sun.com/products/plugin/1.5.0/demos/plugin/applets.html

and can run them without any trouble, but I can't run the Tier3 applet.

I've run without explict heap sizes, and also tried specifying heap minimum and maximum, e.g. minimum 256MB and maximum 512MB. None of that made any difference.

My system and process quotas are up to snuff with recommendations for Java except for FILLM, which is 2048 instead of the recommended 4096.

It is entirely possible that the problem is one of misconfiguration or resource exhaustion. It is also entirely possible it is a JVM bug that affects only Alpha but not Itanium.

Hope that helps. Richard, what does your own analysis on your own OpenVMS systems show?

[Richard J Maher]

Hi Craig,

Thanks again for your detailed an informative replies!

> The main difference between his set-up and mine
> is that we're using entirely different JVM implementations.
> On Itanium, you get Sun Hotspot, the JIT portions of which
> are shared with HP-UX, but on Alpha you get either the
> "Classic" or "Fast" JVM,

So weâ re talking Apples and Artichokes then :-) I think weâ re on safe ground here when we point the finger and say â There will be one or two differencesâ .

> I've tried both classic and fast VMs and can't run the
> Tier3 demo applet with either.

As I said in the comp.os.vms newsgroup, Iâ m more than willing to assist anyone from HP in analyzing/solving this problem. HP could have the Tier3 VMS Queue Lookup DEMO up and running on a TestDrive Cluster Alpha in about half an hour and, as you have seen, *all* of the client sourcecode (including that for the Java Applet) is available with the Hobbyist kit - copies of which can be found at: -

http://manson.vistech.net/t3$examples/

>>>>>>>>>>>>>>>
I've tried both classic and fast VMs and can't run the Tier3 demo applet with either. I get bucketloads of the following error in my Mozilla log file:

**************** SERVER ERROR **************
SecureCallStaticMethod: bad method
**************** ************ **************

I have a file called java_vm.dmp, but it's binary and I don't know how to read it or whether it wouuld tell me anything relevant if I did.
<<<<<<<<<<<<<<<<<<

It certainly looks like any Java or SWB support engineer would have more than enough to go on. Our applet, as seen in the source code, works *with blistering performance* on platforms as diverse as Windows64, IE7, Sun JVM 1.6 to Mac OS X Safari Apple J2SE SDK 1.5, W2K and Opera, to Linux with Firefox, and even works on IA64 VMS 8.3 HotSpot JVM 1.6 but stumbles on Alpha â Hey, maybe it is us?

> Hope that helps. Richard, what does your own
> analysis on your own OpenVMS systems show?

Youâ ve been a big help Craig and I (and Iâ m sure others) thank you for it.

What our own analysis shows is that we donâ t sell, much less support, any client-side software :-) Purely by way of an example as to how one could access their Tier3-managed Applications Servers on VMS from a Web Browser, we came up with DEMO_CLIENT_WEB.HTML and the other HTML/JavaScript files as well as the CornuCopiae.Java Applet (and other classes). If the strategies, algorithms and design decisions we employed when coming up with the client example do not suite a particular customer then they are free to make whatever changes they desire. Do you want to use Swing instead of SWT? Change the language or colours? Stop the browser re-sizing? â Then go crazy!

Your client, or presentation layer, developers talk to your Tier3 Servers using TCP/IP Sockets pure and simple. (Well, you can also use DECnet which may or maynot be via Sockets but thatâ s another story :-) If that development involves Java Sockets via an Applet and Browser (as in this case) thatâ s great. If itâ s a native Java application then weâ re also happy. If itâ s ActiveX controls or the Berkley C Socket library then weâ re over the moon. And if the client is a batch job on a VMS system using $QIOs to talk to your server then weâ re ecstatic :-)

The simple fact is we donâ t have SWB on any of our Alphas, and are currently in the market for a resonable development Itanium box so we can port Tier3 to VMS on IA64. (They donâ t have that USD$2000 Porting Class in deapest darkest Perth where you can walk away with an Itanium dev box.) And I have two people who no longer share my passion for VMS that want to see Tier3 on Linux yesterday :-(

So with limited resources, thereâ s only so much effort that we going to expend getting a demo example up and running on the (uniquitous :-) SWB/Alpha/VMS combination. Now if HP decide to own the problem and do something about it then weâ re all ears!

Of course if anyone experiences server issues then weâ d like to know about them as soon a they happen (and thanks again to those who help in getting Tier3 support for Multinet up and running!)

Cheers Richard Maher