topic Re: Apache DCL Scripts in Operating System - OpenVMS

Apache DCL Scripts

Robert Atkinson — Mon, 23 Feb 2004 04:58:28 GMT

I wrote a web frontend to Digital's CMS product, that runs under Apache.

Some of the functions require the web server to spawn a batch job, which returns information back to the server process (through logicals).

The problem is that if the end user hits the stop button, or clicks on another link, it aborts the session, and the DCL script, before the two components have communicated so things get out of synch.

My question is, does anyone know how to stop the user being able to abort the current DCL script? I've tried the obvious like 'set nocontrol=(y,c)' but that doesn't work!

Cheers, Rob.

Re: Apache DCL Scripts

Jan van den Ende — Mon, 23 Feb 2004 07:54:04 GMT

Robert,

Sorry, no answer, but: do I read you correctly, you have Apache webserver using DCL scripts? I am very interested in something like that.
Not being in development, but in SystemManagement, I officially do no programming, but I can advise on good practice. If I can show a rather easy, rather simple (as in DCL) method to access VMS applications (and for this comparison I view CMS as an example application) then it could save us a lot of work, and hopefully also a lot of misery in half-functioning web-apps on half-functioning micro$oft systems.
No to mention that it might slow down (prevent?) the drain on VMS applications onto "nicer ( = webbrowser-based) platforms.
If you would be willing to help me, mail it to jpe@vdende.demon.nl
If you think it is generic enough to help more people, then a post at openvms.dcl is even better.
If I have the DCL, I will certainly look into your question! (if only because I might run into it myself).

TIA

Jan

Re: Apache DCL Scripts

Antoniov. — Mon, 23 Feb 2004 08:18:42 GMT

Hello Rob,
as Jan I'm interesting into DCL application with web.
Please post more info to help us!

@Antoniov

Re: Apache DCL Scripts

Robert Atkinson — Mon, 23 Feb 2004 08:31:15 GMT

It's pretty simple really.

You need to tell Apache (or WASD) that the command file is exectable :-

ScriptAlias /cms-cgi/ "/cms$system/"

You then place all of your command files in this area, or alternatively whereever your current CGI-BIN directory is located.

You then create a command file and get it to write out the HTML page through SYS$OUTPUT, which is directed to the browser client by the web server.

For Apache, the first thing you output must be :-

$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","Content-type: text/html")

otherwise you get an internal error.

I also use CGIUTL, stolen from the WASD package to 'decode' forms into DCL symbols and/or files, so that I can have the user submit various forms of data and make the web pages interactive.

Using these two basic principles, I create a dynamic, interactive database around CMS that is driven by a web server.

I've attached one of the CMS modules, there are around 60 in all, to show you what I mean.

If I can explain anything further, I'm happy to.

Rob.

Re: Apache DCL Scripts

Robert Atkinson — Mon, 23 Feb 2004 08:36:36 GMT

One thing I perhaps should have mentioned is that DCL is very slow, and cumbersome to manage, so I'd always recommend using something like Perl or PHP.

But if like me your a DCL nut-head (and it sounds like you both are) then go for it!!!

Re: Apache DCL Scripts

Antoniov. — Mon, 23 Feb 2004 09:58:57 GMT

Rob
thanks you!

I will try it next days!
:-)

@Antoniov

Re: Apache DCL Scripts

Jan van den Ende — Mon, 23 Feb 2004 10:30:51 GMT

THANK you!!!!

I will definitely get some use out of this!

Jan

Re: Apache DCL Scripts

Jan van den Ende — Tue, 24 Feb 2004 08:27:28 GMT

Rob,

>>>>>
I also use CGIUTL, stolen from the WASD package to 'decode' forms into DCL symbols and/or files, so that I can have the user submit various forms of data and make the web pages interactive.
<<<<<<<

Obviously (I hope) this is what I am lacking.
What exactly is it, and/or where do I get it?

Is there any more of this _to_me_not_so_trivial_ stuff that I need?

Thanks/

PS.

I did not find any spawning? That way I can not even look whether I might help you with your question...

Jan

Re: Apache DCL Scripts

Robert Atkinson — Tue, 24 Feb 2004 09:56:40 GMT

You can find WASD at http://wasd.vsm.com.au/wasd/

It's then a case of unpacking and following the installation instructions, to get the utilities.

You can visit the demo server - http://wasd.vsm.com.au/ - to have a look at what the utilities do.

Make sure you check out ConanTheLibrarian, it's a brilliant little utility for viewing libraries.

I'd have to say that WASD is about the best Web Server I've ever come across, but it's written and supported by one mad Australian, Mark Daniels, so for a critical environment is not a good choice.

How no commercial company hasn't offered Mark a fortune for the software I'll never know!

Regarding the SPAWN. It's not actually a spawn, but a SUBUSER (SUBMIT/USER=) I do. The command file it runs actions the request, using the account for the logged on user rather than the server account, and then sets a number of logicals to tell the web server it's complete.

You can similate my problem though using this script :-

$ SET ON
$ ON ERROR THEN GOTO PROBLEM
$ WAIT 00:10:00
$ EXIT
$PROBLEM:
$ REPLY /ALL "WEB SERVER HAD A PROBLEM!!"
$ EXIT

Simply run this as a CGI program, and hit the STOP button on your browser to have the command file terminate and send the message.

It's this type of problem I want to stop.

Re: Apache DCL Scripts

Ian Miller. — Tue, 24 Feb 2004 09:56:54 GMT

WASD can be found here
http://wasd.vsm.com.au/wasd/
parhaps one of the scripts packages is what you want.

Re: Apache DCL Scripts

Robert Atkinson — Tue, 24 Feb 2004 10:02:02 GMT

I'm amazed not to get any feedback regarding my problem (requests for info excluded of course chaps).

Have I really got the VMS Guru's stumped on this one.......

Will no one answer my plea.......

Can Batman really save Robin from the evil Dr Dread......

......Tune in next week for another trilling installment.

Nana, Nana, Nana, Nana - Nana, Nana, Nana, Nana - BATMAN!!!!

Re: Apache DCL Scripts

Johan Brusche — Tue, 24 Feb 2004 16:42:54 GMT

perhaps....?

$ ON CONTROL_Y THEN GOTO DO_SYNC
$ ON ERROR THEN GOTO SYNC_TO
$ DO_SYNC:
$
etc...

Re: Apache DCL Scripts

Wim Van den Wyngaert — Wed, 25 Feb 2004 02:13:17 GMT

For WASD, I found the following bypass. Maybe the same kind of thing exists for Apache.

Btw : I hope they implement "ON STOP" or "ON KILL" some day.

If a client disconnects from a running script (by hitting the browser Stop button, or selectinganother hyperlink) the loss of network connectivity is detected by the server at the next output write. Generally it is necessary for there to be some mechanism for a client to stop long-running(and presumably resource consuming) scripts. Network disconnection is the only viable one. Experience would indicate however that most scripts are short running and mostdisconnections are due to clients changing their minds about waiting for a page to build or having seen the page superstructure moving on to something else. With these considerations in mind there is significiant benefit in not running-down ascript immediately the client disconnection is detected. A short wait will result in most scripts completing their output elegantly (the script itself unaware the output is not beingtransmitted on to the client), and in the case of persistent scripts remaining available for the next request, or for standard CGI the process remaining for use in the next CGI script. The period allowing the script to complete it's processing may be set using the HTTPD$CONFIGconfiguration directive

DclBitBucketTimeout]. It should be set to say fifteen seconds, or whatever is appropriate to the local site.

Re: Apache DCL Scripts

Willem Grooters — Wed, 25 Feb 2004 04:04:07 GMT

Robert,

actually, what you want is that the user is NOT able to follow another link or quit the browser.
If this happens, as you said the _session_ is aborted, meaning the process is deleted, but batchjobs started will continue. this is (happily enough) normal behaviour.
I think you'll need some form of handshake between the batch process and the process started by Apache. To give you an idea:

* Let the process started by Apache, pass info to the batch-job stating it's presence. Either as parameter, logicals or passed via a mailbox or socket. data could be PID, processname, CGI-data like WWW_REMOTE_USER etc. The only requirement is that if the "parent process" dies, this data is gone as well.
* The batch process will check the existence of the "parent process" before and after updates have been done. You can do it one change at a time, or the whole bunch together.
* Changes are not committed unless the parent process has been notified, which in turn has signalled the user and received a confirmation of commit.
* if NOT committed, chnages are to be reversed.

HTH

Willem

Re: Apache DCL Scripts

Robert Atkinson — Wed, 25 Feb 2004 04:07:11 GMT

Willem - in and ideal world this would be fine, but the coding across the whole site to detect the parent has one away, and the reverse out the changes from RMS files would be a nightmare.

This is just not a practical solution, so I still need a way of stopping the web server from aborting the command file.

Re: Apache DCL Scripts

Antoniov. — Wed, 25 Feb 2004 05:00:50 GMT

Hi Robert,
it's not clear in my mind the exact terms of your problem. Correct me if I wrong.
You have a client that open a web session and obviuosly create a new process on server; this process run a DCL script interactively with clien request.
A request can start a batch job and when batch has terminated send back info about its own results; process script recevied info and show theese info to web page.

Now your problem is: when web client hit stop or change link, DCL script abort (but obviusly batch continue his work).
My question is:
a) If web client hit stop, this means he wants halt, so there is not problem to send back any information; perhaps you would stop batch job?
b) if web client change link, may be operator will return on same session a few time after, but in this case DCL script was aborted and it's not possible find any information on previous session (because http protocol has not any session support); do you retrieve information of previous session in this case?
c) what does happen if web client send refresh page request?
d) HTML standard permit you hide all browser button: this is very hard solution, is it good for you?

Sorry for long sentence but my english is very poor!

@Antoniov

Re: Apache DCL Scripts

Robert Atkinson — Wed, 25 Feb 2004 05:06:16 GMT

Antoniov,
your description of the problem is fairly accurate.

If the user is just viewing information, it doesn't matter if he hits STOP. When the user requests information to be updated, he cannot hit STOP because only half of the information is updated.

So, I need some way of being able to ingore the STOP button, or anything else that aborts the server process.

Re: Apache DCL Scripts

Antoniov. — Wed, 25 Feb 2004 05:40:15 GMT

Ok Robert,
in this moment I don't remember how make, but I'm sure it's possible disable browser button. Today I'll read my HTML book to refresh my mind and tomorro I can send you this information.

@Antoniov

Re: Apache DCL Scripts

Robert Atkinson — Wed, 25 Feb 2004 05:45:36 GMT

Antoniov, disabling the browser button is not good. I would have to disable all of the hyperlinks, the functions keys, and more.

That's why this has to be done on the server and not the client.

Re: Apache DCL Scripts

Willem Grooters — Wed, 25 Feb 2004 06:12:23 GMT

Robert,

I don't think there an answer other than something similar to what I suggested.

So, I need some way of being able to ingore the STOP button, or anything else that aborts the server process.

As said: you don't want the remote user to end this session as long as the process runs. Actually: you'd like to prevent him to switch off his machine, unplug the network... You are no dounbt aware that you shouldn't under-estimate the user's creativity (and certainly not if he's a professional computer-user!).

You will get exactly the same problem in case of failure of external origins: connection, power...It may be even worse, since this may not involve just one user, but hundreds. I don't know your environment in that matter but if it involves a lot of users, you'll have a lot of discrepancies - and a lot of reversing to do.

Really, No Kidding.

Since you have no control over the user's behaviour, you'll have to take precautions within your application, so the work, once started, will be finished completely (no matter what), or can be reversed easily.
Since the latter is no option, you'll need some form of protocol, where the remote user can add what he wants, confirms it and has to acceept the work is done as he said. Even if he 'logs out' (that's what he does by closing the browser)