Help System for Application Development

[Chris Summerfield]

Can anyone clue me in on what is the approved system or methodology du jour for providing online and/or context-sensitive help in applications on OpenVMS? It appears that there is a standard (sort of) for CDE that is used on some UNIX platforms. I suppose that we don't use Bookreader anymore on OpenVMS? Most people have moved to browser-based help, but the difficulties associated with Mozilla on OpenVMS appears to make that an unworkable solution here.

So what's an application on OpenVMS supposed to do these days? As an application developer, I need a simple way to provide online help with my Motif-based applications. So is there a facility that is documented for OpenVMS (including tools and techniques for how to build Help for whatever we are using these days)?

[Chris Summerfield]

I don't find a way to ammend or append to a posted message here, so this is an addendum masquerading as a reply. In browsing through OpenVMS online documentation, I find references to the aforementioned CDE Help Authoring system, so I'm guessing that this is what is supported or recommended for use with OpenVMS. Please correct me if I'm wrong ('cause I was hoping for something different). But if so, can anyone point me to a way to download the documentation for this help authoring tool in pdf (Adobe Protable Document Format, but you knew that already). I don't see any point in forcing us to read online documentation only.

BTW, Sun Microsystems provides documentation for the CDE Help Authoring system (and everything else in the world) in downloadable pdf format, so if there are no differences in CDE Help Authoring on VMS as compared to the same on Sun, then we can just rely on Sun for our documentation. But as VMS is not exactly Solaris, that's probably not the case.

I sure would like to see HP make online access to VMS documentation be as comprehensive and easy to use as what Sun has provided. Sun is certainly blowing our socks off in this regard. Opinion, of course.

[Martin P.J. Zinser]

Hi Chris,

could you be more specific about the perceived problems with
Mozilla on OpenVMS? I am using it right now to read this forum ;-)

Also if we are talking documentation only VMS Mosaic is a quick and much less resource demanding possibility.

Greetings, Martin

[Dale A. Marcy]

You can define a symbol in the system login procedure to point to the Mozilla command procedure and then just specify the html address as the first parameter after the symbol:

in sylogin.com

$ cswb :== @disk:[directory]mozilla

at runtime

cswb HTTP://www.whatever.com

[Martin P.J. Zinser]

Actually if you want to wrap it
in your application it is easy
to define it from there:

define_symbol_name
("MOZILLA", "@PUBLIC$ROOT:[BINDIST.MOZILLA]MOZILLA");

[Chris Summerfield]

Thanks to Dale and Martin for your suggestions. I have been trying to follow these leads, and where the road has led me so far is this...in reverse order...

As far as I can tell, there is no translation on my OpenVMS Alpha V7.3 system for PUBLIC$ROOT. This is not a serious problem because, although inconvenient, I can require users to specify through some system logical the path to their MOZILLA directory. This is an extra step that is not required on other platforms, but it is tolerable.

The more difficult problem is that even if I know the path to MOZILLA.COM, getting VMS to open a browser window and display the contents of a specified HTML file is more complicated than just saying "mozilla " (or "cswb filename" or whatever foreign command we might define to be equivalent to @SYS$COMMON:[MOZILLA]MOZILLA.COM).

Becase we are not talking about something that a person is going to type at a command prompt. The task at hand is for a running interactive application to fork (pardon the Unixism) a browser.
I cannot just ask VMS to execute a command in the manner that I might do with LIB$DO_COMMAND becuase that would terminate my current process, which is not what we want. So I surmise that I must do SYS$CREPRC to run SYS$SYSTEM:LOGINOUT.EXE. But to do this in a way that will allow me to execute a DCL-style command like "MOZILLA " I will need first to create a file on disk that contains the command that I want to execute, and then assign the fully-qualified filename to SYS$INPUT in the process that is going to run LOGINOUT.EXE. And as this entails creating a file with a unique name in a directory somewhere on disk (which entails making the assumption that I have a directory somewhere on disk that I also have the privilege to write into, and also entails ensuring that the file that I so create, if I can create one at all, gets deleted whether the attempt to run LOGINOUT succeeds or not) leads down the path that I found objectionable in the first place. The whole process is just a messy, messy ordeal as compared to the simplicity on Windows or Unix.

Now I love VMS, and I have always loved VMS (Open or otherwise), but it just appears to me like the VMS development group is really letting us down on the matter of integrating browser support into the operating system. Which is sort of pre-requisite to providing a way for applications to display HTML-based Help, which has become the de facto standard in the industry. So our customers expect it.

So of course I understand that Mozilla is not an HP (or Compaq or Digital) product and we can make excuses about how we have no responsibility for it. But look here. It isn't a Microsoft or a Sun product either, but those vendors have managed to ensure that it gets installed and has a default configuration when the operating system is installed. And they have provided a way to open the browser to display a program-specified file with a single line of code in a C language application. And that's all we need or are asking for to enable us to implement online Help in a VMS application.

So am I missing something? Can anyone point me to documentation that describes (or provide an example that works) that I can embed in a C language application to cause Mozilla to run and open a browser window and display an HTML file that I specify without jumping through all the hoops required to dynamically create a command procedure file and run LOGINOUT and try to make sure that I can clean up my mess when I'm done....

Whew. Sorry for going on and on about this, because...it's simplicity that I'm really looking for.

[John Deutsch · Accepted solution]

Hello,

Won't LIB$SPAWN do what you want? I've used that in a large application written in PASCAL which a client of mine has been using since about 1986. They have never complained about it being slow. Its first parameter is the command to be obeyed. I've never needed to use any of its other parameters.

I've used it both to obey a command directly and to run a command file. I've never used MOZILLA though.

John

[Chris Summerfield]

John,

Of course, thanks for your suggestion about LIB$SPAWN! This solves the problem of starting Mozilla and giving it a specification for the filename to display.

There are still some issues, but the question of how to start Mozilla and specify a target html filename is, in fact, resolved using LIB$SPAWN.

For those who might wish to know, the remaining issues have to do with the extreme overhead requirements of the command procedure that runs Mozilla...and with an ACCVIO that occurs from time to time in Mozilla. And with an annoying little write to SYS$OUTPUT that is contained in MOZILLA.COM.

In reverse order, every time MOZILLA.COM is run (whether in the context of a LIB$SPAWN subprocess or otherwise) it writes a little "Starting..." message to SYS$OUTPUT. This can be suppressed by commenting out the line "$ write sys$output "Starting ''moz_image'..." in MOZILLA.COM.

Then there is the problem that Mozilla ACCVIOs from time to time with the traceback
Notify in LIBGKLAYOUT at line 59472
from Fire in LIBXPCOM at line 21222
from handleTimerEvent in LIBXPCOM at line 21284
from PL_HandleEvent in LIBXPCOM at line 41022 ... etc

Then there is the problem of resources required to run Mozilla. On my AlphaStation 400 running OpenVMS Alpha V7.3 in a process with substantial quotas and resources, from the time the command to run MOZILLA.COM is issued via LIB$SPAWN until a window is displayed averages 65 seconds. It takes Mozilla another 10 seconds to display the html file in the window. So 1.25 minutes before the Help text appears on the screen. Most users, I fear, will have banged on the button 20 times by then and finally given up and exited the program.

Last and probably least, I'm curious about why the subprocess that is created by LIB$SPAWN (to display the Mozilla browser window) stays around if/after the parent process exits. Perhaps I would find that MOZILLA.COM (if I looked at it more closely) actually creates a detached process to run the browser. So I suppose we are creating a process to run a command procedure in a subprocess that creates a detached process to open a browser window. Maybe.

In the end, if I create the browser window and display the file, I figure that I have probably done my job. If the process takes forever or if Mozilla crashes from time to time, I suppose those issues belong to VMS Development (who will probably wish to disclaim any responsibility for Mozilla, although to no avail). If VMS hopes to survive in the 21st century, it's going to have to get MUCH better at integrating support for a browser (IMHO). Even if it thinks it is only a backoffice operating system. There is no escape. It's do or die.

[Martin P.J. Zinser]

Hello Chris,

the system sent part of my last
answer to the bit bucket, so
here we go again ;-)

Startin netscape/mozilla every
time you want to display a help
page is not a good idea on either Unix or VMS since it
incurs quite a bit of overhead.

To avoid this you might want to
experiment with the "-remote"
switch to mozilla/netscape.

Disclaimer: I have not done this
with Mozilla on OpenVMS yet.
Something similar does work with the VMS version of Mosaic.

[Chris Summerfield]

Martin,

Thanks for the suggestion about -remote. I've been looking for documentation about what this might do, and I haven't found any. In fact, in wading through devedge.netscape.com and mozilla.org and a variety of other sites and online O'Reilly books, I haven't found anything about any switch options for Mozilla at all, except for -chrome. Oh yes, I also checked the hardcopy (printed) User's Guides for Netscape to no avail. I'm really surprised about the lack of documentation about Mozilla. I guess it's just supposed to be intuitively obvious, and if you're not savvy enough to intuit it, you shouldn't be using it.

[John Deutsch]

Chris,

I've had three further thoughts that speed up your entry into MOZILLA. These are not things which I've tried, but they might lead somewhere.

1. What about running MOZILLA as an installed image (I think that is the right term)? This could make it quicker to start up.

2. What about running MOZILLA as a service? I've never tried creating a service, and I'm not sure how that would work.

3. What about each user having MOZILLA running as a second session on their terminal? I don't know how you would tell it what file to look at. Maybe there is a way of doctoring its list of favourites or of recently visited addresses.

John

[Chris Summerfield]

John,

Good ideas, all. I imagine that having Mozilla be an installed image would be a step in the right direction, and I think that is about as far as VMS comes to having a service (other than running a detached process in hibernation or an event flag wait state). Overall, my take on this is that it is a decision for VMS Engineering to make, as they have provided MOZILLA.COM as the approved (supported?) method (so far) of starting Mozilla. I think they need to take a much more serious look at how to support a browser in VMS in a way that will minimize impact on startup performance and provide options that allow browser requests to be satisfied by either

a) opening a new browser window to satisfy the request (irrespective of whether another window is already open on the display); or

b) checking first to see if a browser window is already open on the display and, if so, using it to satisfy the request, if not, then opening a new window to satisfy the request.

My impression so far is that VMS Engineering has invested the minimum amount of effort possible to slap together something to run a browser on at least some of the systems that run VMS (ignoring VAX and ignoring the performance implications of the ways that browsers are used). I just think that history may prove this approach to be very short-sighted and unfortunate for the future of VMS.

The issue invites me to wonder what vision VMS Engineering has for the place of VMS in the world of operating systems anyway. What need to they expect it to satisfy in a world that is dominated by the Windows/Unix duo. Now that even Mac OS has become Unix, and the world of Unix variants is rapidly imploding to Linux. Porting to VMS to Itanium may be futile if no one elects to use it. And if it can't even run a browser...well...

[Martin P.J. Zinser]

Hello Chris,

try mozilla -help

which does give a link to a page
with information about -remote
(as I've written, that should be
usefull on Unix too, not only
OpenVMS)

<> superficial experimentation did show some problems. I guess this might be a process name issue. You might want to get in touch with
Colin Blake ( colin@theblakes.com) to sort them out.

Greetings, Martin

[John Deutsch]

Chris,

Maybe they have no vision beyond enabling existing VMS programs to run on newer hardware. I imagine that around the world there must be hundreds or thousands of VMS applications that cannot easily be moved to UNIX or WINDOWS, and that must keep going for several years to come.

I wrote a VMS application for a client in 1986 and they are still using it today, but with new features added in over the years. It has run on VMS since version 3, and is now run on an Alpha rather than a VAX. It was so central to their survival that when they were looking into which systems might put them out of business if they failed because of Y2K - it was in the first four that they listed.

They were seriously worried about the demise of DEC and the possible effect on the longevity of VMS and the machines. However (sadly for me) the nature of their products has changed in the last year or so, and they don't envisage needing the system for more than a few years.

John

[Chris Summerfield]

Martin,

Thanks for the reference. I checked out http://www.mozilla.org/unix/remote.html and now I understand a bit more about where the -remote option came from and where it might be going, along with some insight into the volunteer source efforts at mozilla.org. Not that I want to jump into the seamonkey source and start swimming around. That's well beyond the scope of my project. But I will certainly experiment with it and see what I can come up with.

John,

Yes, I too have been writing applications for VMS for a very long time. And some of them expire with time when customer needs change, or when the customers themselves expire. But other applications have the opporutnity to grow and change with the times. And those that do will grow and change only on those platforms that provide the facilities and support required to support the changing times. If VMS is going to assume a status quo posture, then I expect that it will die when its legacy applications die, surviving only for so long as HP (or whoever owns it next year) can find profit in supporting it.

I would like to think that if VMS can get its act together to provide reasonable support for a browser and some of the other basic functionality that the world expects from an operating system these days, then it might have a chance for life in the 21st century. Maybe HP can parlay the move to Itanium to make this happen, but time is running out as customers continue to look elsewhere, and it may be too little too late. Maybe. Maybe not. She loves me. She loves me not. She loves me...

[Chris Summerfield]

For those, if any, who might care to know, the -remote option does allow a couple of things that can be quite useful if you can afford to run a couple of commands via CLI and the MOZILLA.COM command procedure...

First, if you define a foreign command MOZILLA to run the MOZILLA.COM command procedure, such as

MOZILLA :== @SYS$COMMON:[MOZILLA]MOZILLA.COM

then you can use the -remote command option to determine if a browser is already running, as follows:

$ MOZILLA -remote "ping()"

If this command completes without error, then a browser is already running on the local display. If a browser is not running, the command will return error 2 and a text message.

Then if a browser is running already on the local display, you can cause it to display the contents of a file (instead of whatever it is already/currently displaying) by executing a command of the form

$ MOZILLA -remote "openFile(file:///sys$common:[somedirectory]myfilename.htm)"

and this can (might) execute in only a few seconds instead of a few minutes, as may be required if a browser is not already running on the local display.

Now if all of this could be encapsulated into a simple command that can be executed from within an application, and if we could get the initial startup time for the browser down to a couple of seconds instead of more than a minute, then we might really have something!

Our thanks to Martin for leading us down this road of discovery...

[Craig A Berry]

An alternative would be to distribute your help files in PDF format and use XPDF to read them on VMS. XPDF has a *much* lighter footprint than Mozilla; you could simply distribute the XPDF executable with your application. It may run on VAX as well, but I don't remember for sure.

I don't know if you mentioned what language you are using. If it's C, then you may find that system() or something from the exec() family are even easier than lib$spawn for invoking external programs in a subprocess. In particular, if you avail yourself of the VAXC$PATH logical name, then you don't have to hard code any paths when using exec().

[Martin P.J. Zinser]

If you follow Craigs advise
concerning Xpdf, just a few
hints from me:

1.) Wait a bit ;-) If everything
goes right the VMS ready version
of Xpdf 2.02 should appear at
http://www.decus.de:8080/www/vms/sw/xpdf.htmlx
some time this weekend.

2.) Make sure you build an executable with both T1lib and Freetype2, since this will give much better rendering.

Also for these two I hope to have the new versions up this weekend (5.0.0 and 2.1.4 resp) at the site above

[Chris Summerfield]

Thanks to Martin and Craig for the suggestions about PDF. A little background about our purpose...

We have an application that runs on Windows, Unix and VMS. Same functionality and considerable common code (written in C) on all platforms. The native GUI is Windows (of course) on Microsoft and Motif on Unix and VMS. Each dialog (panel or window) in the GUI has a "Help" button which, when clicked, causes a separate dialog to be displayed to show help for the dialog from which Help was invoked. The source for Help is, in fact, an HTML version of the User's Guide. We also provide an install on the user's system a PDF copy of the same User's Guide.

The plan has been to base the directly-linked help on HTML, and to provide the PDF files as a resource that users can view or print as a book at their discretion (provided they have a PDF reader installed). I suppose the reason for this has been the convenience of opening a window indexed to the proper page (anchor) in HTML, together with a navigation window on the left side of the display in Help (requires Java plug-in). And in Windows, of course, this is a "no-brainer" because all of the resources required to support this can be provided packaged in a single chm file that works like a charm in either Netscape or Explorer. In Unix and VMS we provide a Help directory that has about 100 separate HTML, gif and js files, with the Users Guide pdf in a separate doc directory.

Providing the pdf has sort of been an afterthought, like we give it to you and good luck with it if it's useful to you. We have had little expectation that it would be useful to Unix and VMS users, but if a decent pdf viewer is available that expectation may change. I'll certainly check it out!

[ShyGuy]

Chris,

given the level of (or more appropriatly lack of) performance in invoking Mozilla - could you give us an idea about the configuration of the machine you do this on (machine type, amount of memory etc)?

/ShyGuy

[Chris Summerfield]

ShyGuy,

The system environment of this test system is a small and relatively old Alpha system. It is an AlphaStation 400 4/233 with 160 MB of real memory. Running OpenVMS Alpha V7.3. It's probably a "worst case" configuration for running a browser, but it's not unlike what many of our customers have. Along with systems like Sun SparcStation 5.

[ShyGuy]

Chris,

that's 96MB more memory than I have in my DEC3000-300X. But then I don't try to use resource hogs like Mozilla on that machine :-) Usually I only use it for some coding where I need my own machine and as a display device...

If I remember correctly the SPD indicates that VMS it self requires at least 64MB of memory, depending on configuration. That would leave 96 for your application and Mozilla to share (assuming you don't have an rdms or other applications that also consume resources), not a whole lot for an application like Mozilla, that seems to be written as resources was endless... But then that is why we stuff or PCs with lots of memory (even my notebook has 1GB) but when it come our traditional servers we run with memory configurations that was appropriate 10 years ago. I guess that if we want to run ports of todays PC-style applications on VMS we must realize that they has about the same memory requirements on VMS as on that PC...

Now that I have all that of my chest, have you ensured that the account that the browser is running under has quotas that are appropriate as possible for Mozilla? Also note that the way old Netscape browsers that was ported to VMS required a lot less memory, maybe you should recommend your users to use one of those if the have a resource starved system or an even more efficient alternative would be to use Lynx, but then a text based browser is probably frowned upon today.

/ShyGuy

[ShyGuy]

Chris,

I forgot to mention this, if you are writing your application in C you might just as well use system() instead of lib$spawn to save at least one conditional or what ever you do in your product to separate out platform specific code.

system() is simply a jacket on lib$spawn

/ShyGuy

[Willem Grooters]

Chris (and all others),

something to be aware of!

I found Mozilla could crash sometimes (and 1.3 surely if you use Java 1.4 on the machine!), luckily it never happened within a procedure. I setup mozilla as a foreign command and then SPAWN it, like this:

MOZ_START.COM is a small commandprocedure I use to setup and launch mozilla.

$ MOZ :== @DISK:[MOZILLA]MOZ_START.COM
$ SPAWN MOZ

Eventually /LOG to obtain output. This allows me to obtain stackdump information, otherwise lost.