[Info-vax] Any stronger versions of the LMF planned ?, was: Re: LMF Licence Generator Code

[Arne Vajhøj]

On 8/8/2021 4:52 PM, Jan-Erik Söderholm wrote:
> Den 2021-08-08 kl. 22:42, skrev Arne Vajhøj:
>> On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
>>> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>>> - it does not integrate with newer system that it need to
>>>>>>    integrate with
>>>>>
>>>>> With the exception of Dave's system (I actually know very little
>>>>> about VMS BASIC) I can think of no legacy system that can not be
>>>>> integrated into a modern system.  I have had no problems doing web
>>>>> programming with COBOL.
>>>>
>>>> Anything can be somewhat integrated using various hacks.
>>>
>>> I needed no hacks to get COBOL running on the web.  It's a mindset
>>> problem, not a technical one.
>>
>> Literally nay programming language can be used to write
>> a CGI script.
>>
>> But there is a very long way from the 1995 CGI scripts
>> to modern web solutions.
>>
>> Did you Cobol web app support:
>> - session sharing across cluster
>> - OAuth integration
>> - LDAP integraion
>> - verification of client certificate
>> - Redis or memcached for cache
>> - exposing status / load info to load balancer
>> - reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
>> - reporting to Prometheus
>> - HTTP/2 push
>> - web sockets
>> - switching to in-cloud managed service for database
>> - having accept request header determine response format
>> ?

> Are we/you talkning about an application that runs "on the web"
> without any other help from a normal web server?

What is important is what the solution provide.

How that solution is implemented:
* one server communicating with scripts running in different processes
* one server running code in different modules within the process
* a standalone module including a standalone server
does not matter so much, except that the first approach tend to
make a lot of things more difficult.

> In the OpenVMS case, most of your points above would be handled
> by WASD (just as I know that one best) and the Cobol code just
> do the business logic. Maybe a small C-jacket to handle the
> CGI API against WASD also. But there is nothing stopping some
> Cobol code to be the main business logic in an web solution.

The Cobol code has no problem doing the business logic. The
problem is with the web context on top of that.

And I don't think WASD/Apache/OSU can solve much of the
above as it mostly have to be embedded in the application.

# session sharing across cluster

The web server cannot share the application's
session object across the cluster as it does not
have access to it.

# OAuth integration
# LDAP integraion

The web server can use use for accepting/denying
access to the application and pass on username,
but if the application want to query for roles
of that username, then the web server cannot help.

# verification of client certificate

Does the web server pass enough information on to
application about SSL for it to verify?

# Redis or memcached for cache

Pure application. The web server can not cache info it
does not have access to.

# exposing status / load info to load balancer

The web server can be load balanced based on general web server
status. But it will not be able to load balance based on
the state in the application.

# reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
# reporting to Prometheus

Pure application. The web server can not provide info
it does not have access to.

# HTTP/2 push

The web server may support HTTP/2, but it cannot embed stuff
in the response by itself. And unless CGI protocol has been
heavily extended to allow passing the info, then the application
cannot pass it.

# web sockets

The web server may support it, but how does it get it to the application
via CGI?

# switching to in-cloud managed service for database

Pure application

# having accept request header determine response format

Pure application. Also definitely doable in Cobol - just
requiring a lot of lines of code to do it.

> Today, and particular on an real environment such as OpenVMS
> (not some embedded thing), I do not see why one would put all
> the functionallity, that already has been developed and debugged
> by a tool such as WASD, into your own application.

I am definitely not arguing against using an existing web server
(or application server).

That is a given. The only question is standalone or embedded.

My point is that there are technologies that:
- works with existing web servers
- provides a ton of features useful in web context that a
   Cobol CGI script does not have

Arne