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.