Apache on OpenVMS 7.2 Alpha
jran...@hotmail.com
sysadmins I'm working with have told me that they are running on
OpenVMS version 7.2. HP's website on Apache (and their port to VMS,
Secure Web Server)
http://h71000.www7.hp.com/openvms/products/ips/apache/csws_download.html
indicates that you need OpenVMS version 7.3-1 at a minimum.
Is there any way to run Apache on 7.2, or will standard Apache run on
7.2, i.e. not HP's ported version? What would be some of the issues in
getting Apache to run on 7.2, if possible?
Thanks!
Josh
Tom Linden
Josh, do yourself a big favor, forget about Apache or SWS and use something
better which was also designed for VMS http://wasd.vsm.com.au/
It is free, but you can optionally pay for support, I do.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
jran...@hotmail.com
provides easy ways to do this.
I've done some looking through the website that you sent regarding
WASD and I can't see analogous utilities for web services. Any
suggestions?
I want to use web services (i.e. SOA-style) to pass calls through to
some compiled COBOL programs which will in turn access flat files on
the VMS system. I'm open to alternate ways to do this if there are
suggestions, but it would be nice to stay with using the COBOL to
actually access the datafiles (particularly for writes) because that
way a minimum of training and changes are required to staff to
implement the actual data changes. It's also less risky in terms of
possible corruption of data.
Thanks,
Josh
Richard Maher
> I'm open to alternate ways to do this if there are
> suggestions, but it would be nice to stay with using the COBOL to
> actually access the datafiles (particularly for writes) because that
> way a minimum of training and changes are required to staff to
> implement the actual data changes.
There has been recent discussion in HP's ITRC forum about a similar COBOL
requirement and IMO you could do a lot worse than to read, fully, my replies
to each of the following threads. (Currently the last replies in each
thread)
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1110572
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1095466
The attachment to the first reply contains all the JavaScript and HTML
needed to put a browser-based GUI front-end on a VMS COBOL Queue Management
example application. The attachment to the second reply contains *ALL* of
the code that your application development staff would need to supply on the
server side. Just six User Action Routines in the form of a Shareable Image,
is all you have to provide for any VMS server application. (Whether you want
to talk to it via a Browser, .NET, Java, another VMS box, or even using
DECnet as a transport)
Your COBOL does not change - Your server development tools do not change.
You code is informed of the VMS username on whose behalf a request is being
made, and a matching Persona is made available for you if needed. You get a
full-duplex, conversational pipe with which to communicate with your client,
and server affinity is completely under your control. All network-connection
management, multi-threading, and server-process load-balancing is done for
you.
Anyway, If you'd like to see what it looks like in action (and especially
how easy a platform it is to develop on) then send me an e-mail.
Cheers Richard Maher
<jran...@hotmail.com> wrote in message
news:1177626898....@r35g2000prh.googlegroups.com...
Tom Linden
I have on my agendum (notice correct use of singular) to do the same for
PL/I,
but we are going one step further by generating Java object classes
(through the
good offices of SDL) for PL/I entry declarations, thus faciltating canning
(i.e., jar-ing) legacy apps. The same could be done for Cobol.
>
> <jran...@hotmail.com> wrote in message
> news:1177626898....@r35g2000prh.googlegroups.com...
>> I would like to implement web services and I know that Apache Axis
>> provides easy ways to do this.
>>
>> I've done some looking through the website that you sent regarding
>> WASD and I can't see analogous utilities for web services. Any
>> suggestions?
>>
>> I want to use web services (i.e. SOA-style) to pass calls through to
>> some compiled COBOL programs which will in turn access flat files on
>> the VMS system. I'm open to alternate ways to do this if there are
>> suggestions, but it would be nice to stay with using the COBOL to
>> actually access the datafiles (particularly for writes) because that
>> way a minimum of training and changes are required to staff to
>> implement the actual data changes. It's also less risky in terms of
>> possible corruption of data.
>>
>> Thanks,
>>
>> Josh
>>
>
>
--
Arne Vajhøj
> I would like to implement web services and I know that Apache Axis
> provides easy ways to do this.
>
> I've done some looking through the website that you sent regarding
> WASD and I can't see analogous utilities for web services. Any
> suggestions?
Apache Axis or at least the Java version runs in Apache Tomcat
servlet container not in Apache HTTP-server.
It is common to run Apache HTTP-server in from of Tomcat, but
you don't need to.
And the Axis C/C++ version is not widely used.
> I want to use web services (i.e. SOA-style) to pass calls through to
> some compiled COBOL programs which will in turn access flat files on
> the VMS system. I'm open to alternate ways to do this if there are
> suggestions, but it would be nice to stay with using the COBOL to
> actually access the datafiles (particularly for writes) because that
> way a minimum of training and changes are required to staff to
> implement the actual data changes. It's also less risky in terms of
> possible corruption of data.
One possibility would be to use BridgeWorks.
--(SOAP/HTTP)--Tomcat+Axis+BW client--(DCE)--BW server--COBOL--files
It is a long chain but you should be able to get do with minimal
coding.
The web service can reside on VMS or on another box as you prefer
because DCE is a remote call.
Arne
Richard Maher
> --(SOAP/HTTP)--Tomcat+Axis+BW client--(DCE)--BW server--COBOL--files
I rest my case.
Cheers Richard Maher
PS. Maybe you coulda speed things up a little bit with some additional CGI,
ASP, JSP, JDBC, JSON, AJAX and a really good garbage collector of JavaBeans
in your JVM? (Or you could write VMS code; it's up to you)
PPS. Is BridgeWorks going to Itanium now?
"Arne Vajhøj" <ar...@vajhoej.dk> wrote in message
news:4632ad83$0$90266$1472...@news.sunsite.dk...
Richard Maher
> I have on my agendum (notice correct use of singular)
I had to look that up, and am still suprized.
> to do the same for PL/I,
I should point out that although this particular server example is in COBOL,
there is no restriction on the use of any language for the six User Action
Routines. As long as it can adhere to the VMS procedure calling standard and
is capable of being compiled/linked into a VMS shareable image then it can
be a server.
If you Fortran guys want to user your COMMONs for interprocess
communication, or create your Global Sections on the fly then go for it! -
Mailboxes? Spawning subprocesses? Then no problem - go crazy! - Rdb, RMS,
Oracle? Why not? - Server affinity? Under your control. - lib$*_vm? Of
course!
We don't want to hide VMS from you, your coders, or your users, like it was
some dodgy relative you're too embarassed about; we want you to continue
revel in its beauty, functionality, and stability! (I for one have had
enough of the VMS-appologists from HP talking about affinity with this
product or that operating system, and how you have to wrapper your "legacy"
code up in a mini-skirt and a thong 'cos dignity and integrity are no longer
fashionable.)
I don't know in which animal one would find the inherent skills, talent and
anatomical attributes that best reflect the strengths of VMS in the IT
domain (it's certainly a reliable work horse, and there's always JF's shark)
but one thing's for sure, Richard Maher is never gonna try to stick flippers
on it, strap a rubber bill to its head and tell it to quack like a fucking
duck!
Do whatever you like on the client; on the server we're 100% VMS! (And
*proud* of it)
Cheers Richard Maher
"Tom Linden" <t...@kednos-remove.com> wrote in message
news:op.trez0rb0tte90l@hyrrokkin...
Stephen Hoffman
Most anything is possible in this particular problem space, given the
availability of and the application of appropriate incentives and skills
and time.
IIRC, the baseline requirement within Secure Web Server (Apache) was
due to the availability of C APIs expected by the server. The standard
C library has seen a massive influx of new calls in recent OpenVMS
releases.
In this case, you'll either end up backporting and dealing with your
own Apache build, or you'll end up upgrading OpenVMS and dealing with
the HP build. Or out-sourcing the backport or the OpenVMS upgrade.
WASD is certainly a good option here. Haven't looked for a LightTPD
port, but I'd certainly consider that approach. Apache is very
powerful, and certainly also not a light-weight web server environment.
TANSTAAFL. Staying on an older software release might look to be a
free solution, but the approach is not without eventual costs. The
costs just tend to sneak up on you. Sometimes incrementally and
peripherally, and sometimes a wallet-monster leaps out and consumes your
entire down-rev savings. And more.
--
www.HoffmanLabs.com
Services for OpenVMS
Neil Rieck
"Stephen Hoffman" <Hoff@HoffmanLabs-RemoveThis-.Org> wrote in message
news:f17lq3$21k4$1...@pyrite.mv.net...
> jran...@hotmail.com wrote:
>
[...snip...]
>
> Most anything is possible in this particular problem space, given the
> availability of and the application of appropriate incentives and skills
> and time.
>
> IIRC, the baseline requirement within Secure Web Server (Apache) was due
> to the availability of C APIs expected by the server. The standard C
> library has seen a massive influx of new calls in recent OpenVMS releases.
>
It's been a while since I looked at the release notes but I was under the
impression that Apache needed the UNIX Portability APIs associated with
OpenVMS-7.3 (and that might be what Hoff was referring to in the paragraph
above).
But is there some reason the author is trapped on OpenVMS-7.2 ? There are
some really cool speed ups built into 7.3-2 and I wouldn't run any Alpha
system below that level. In fact, a recent Bruden OSSG presentation states
that OpenVMS just keeps getting faster with each incarnation so I can hardly
wait to upgrade from 8.2 to 8.3
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
--
Posted via a free Usenet account from http://www.teranews.com
Doc
@r35g2000prh.googlegroups.com:
Anything you can do with Apache, you can do with WASD. We've got WASD up
and running on Deathrow and every registed user has webspace *AND* cgi
capability. So, if you want to try interfacing a COBOL program to WASD
we offer an environment to play in. Give me (user DC) a shout if we're
missing the COBOL compiler, I think the node we lost due to a PSU issue
was the one with it on it.
The web page is at http://deathrow.vistech.net, or you can just
telnet/ssh to the system and create an account with user NEWUSER,
password NEWUSER.
I'd also recommend digging around for the info-wasd mailing list. It is
a fairly quiet list most of the time, but there are quite a few
knowledgeable people there who could suggest ways to interface your
existing code with WASD.
Almost lastly, your sysadmins will like WASD, it sits and consumes very
little resources when not busy. Admittedly only serving up static pages
at the time, it kept going when Deathrow was listed on slashdot. The
difference in our case was we got slashdotted on telnet at the same time,
and that stayed responsive.
And really lastly... Take heed of the advice from other people in this
thread, if you can get upgraded to a more recent VMS version then do so.
This isn't one of those unmentionable operating systems, VMS releases
improve the performance instead of adding more performance dragging eye-
candy.
Doc.
Main, Kerry
[snip ..]
Yep, that's a good point as many folks in this day and age just assume
that new OS releases means you will likely have to add hardware (CPU,
Memory etc) in order to accommodate the new version.
Fwiw, I use OpenVMS V8.3 on all of my home lab systems. This includes
one of my oldest home systems - a DEC 3000 that is approximately 15
years old. It's a great little box for testing things like the latest in
Java, upgrade testing/planning, shadowing etc. I also use the latest and
even beta versions of Multinet (V5.2), WASD (V9.2) as well as other ISV
prod's on some of these older these lab servers as well.
I suspect most other OS platforms would struggle using their latest OS
release on 15 year old server/WS hardware.
Re: web services-
A few additional links of interest:
NetBeans J2EE IDE: (free btw)
http://h71000.www7.hp.com/openvms/products/ips/netbeans/overview.html
http://h71000.www7.hp.com/openvms/products/ips/netbeans/modules.html
(plug-in modules for Fortran, Basic, C/C++, Pascal etc)
Web Services Integration Toolkit (WSIT): (free)
http://h71000.www7.hp.com/openvms/products/ips/wsit/
UNIX Portability (Moving UNIX Applications to OpenVMS): (free)
http://h71000.www7.hp.com/portability/index.html
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Arne Vajhøj
> Web Services Integration Toolkit (WSIT): (free)
> http://h71000.www7.hp.com/openvms/products/ips/wsit/
Very interesting !!
I had not seen that.
I assume this a replacing Bridgeworks.
Is the web service part entirely developed by HP or
is it based on an external web service toolkit
(Axis, JWSDP etc.).
Arne
Arne Vajhøj
> Anything you can do with Apache, you can do with WASD.
What about Tomcat integration (mod_jk or other) ?
Arne
Mark Daniel
Reverse proxy seems to be the most common solution.
Tomcat is/can-be an independent server anyway.
--
We are what we pretend to be, so we must be careful about
what we pretend to be. [Kurt Vonnegut; Mother Night]