On 16/04/2022 7:25 am, Arne Vajhøj wrote:
> On 4/15/2022 7:17 PM, Richard Maher wrote:
>> On 15/04/2022 8:44 pm, Arne Vajhøj wrote:
>>> On 4/15/2022 3:36 AM, Richard Maher wrote:
>>>> On 15/04/2022 10:37 am, Galen wrote:
>>>>> Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>>>>>> COBOL evangelism, Love of protected subsystems (eg RMS,
>>>>>> Rdb), Depression and PTSD after years of VMS abuse, dreams
>>>>>> of VMS backend resurgence. . .
>>>>>
>>>>> What precisely, I dare ask, are you dreaming about VMS back
>>>>> ends?
>>>>
>>>> Something like Kestrel that talks HTTP and can pass JSON to
>>>> 3GL code a la mode de TIER3. FIDO2 Authentication support. To
>>>> start . . .
>>>
>>> Both Java and Python can provide nice embedded HTTP servers, do
>>> JSON and potentially interact with native code (Cobol or
>>> otherwise), but obvious question is whether it wouldn't be better
>>> to do it all in either Java or Python.
>>
>> This is the biggest mistake VMS has made for 20 years; throw away
>> the existing customer base :-(
>
> Using the right tool for the job is hardly throwing away the customer
> base.
>
> Cobol, Basic, Pascal, C etc. is just not the optimal language for
> writing a new web service.
>
> Not on any platform.
>
> Arne

Strings in, strings out, what is so special about your "web service"?

Perhaps you've forgotten the beauty of the Tier3 protocol to abstract
all of the network comms and leave you with providing an RTL of 6 functions?

I work every year with wankers that don't understand relational DBs and
SQL and insist on some shit like Entity Framework to try to turn a table
into a class(es) and other wankers that demand a "model" because they're
upset JSON is just a String :-(

Put away your bigotry an admit that "what" the server does has nothing
to do with HTTP!

On 4/16/2022 6:25 PM, Dave Froble wrote:
> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>> for writing a new web service.
>>>>>>
>>>>>> Not on any platform.
>>>>>
>>>>> Really depends on the web service, doesn't it?
>>>
>>> And on the *definition* of "web services".
>>
>> There may not be a formal definition, but most developers have
>> a common understanding what such a thing is.
>>
>> Something like: a service intended to be used by client applications
>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>
> Well, there you go again, refining the definition to match your claims.
> Of course that makes you right.

It is a pretty common definition. Maybe not exactly worded like that,
but close.

> How about anything that offers some service that might be needed over
> the internet?

Not at all.

Web services are probably more often used internally then over
public internet.

The web in web service sis the technology not the network used.

And not all services on the internet are web services. A web page
intended for browsers and humans are not a web service.

Arne

On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
> On 4/16/22 18:09, Arne Vajhøj wrote:
>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>> On 4/15/22 22:10, Dave Froble wrote:
>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>> On 4/15/2022 7:17 PM, Richard Maher wrote:
>>>>>> On 15/04/2022 8:44 pm, Arne Vajhøj wrote:
>>>>>>> On 4/15/2022 3:36 AM, Richard Maher wrote:
>>>>>>>> Something like Kestrel that talks HTTP and can pass JSON to 3GL
>>>>>>>> code a la mode de TIER3. FIDO2 Authentication support.
>>>>>>>
>>>>>>> Both Java and Python can provide nice embedded HTTP servers, do
>>>>>>> JSON and
>>>>>>> potentially interact with native code (Cobol or otherwise), but
>>>>>>> obvious
>>>>>>> question is whether it wouldn't be better to do it all in either
>>>>>>> Java or Python.
>>>>>>
>>>>>> This is the biggest mistake VMS has made for 20 years; throw away
>>>>>> the existing
>>>>>> customer base :-(
>>>>>
>>>>> Using the right tool for the job is hardly throwing away the
>>>>> customer base.
>>>>>
>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>> for writing a new web service.
>>>>>
>>>>> Not on any platform.
>>>>
>>>> Really depends on the web service, doesn't it?
>>>
>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>
>> I don't see that combo as special.
>>
>> CGI scripts in Cobol or PL/I would require the developers
>> to write maybe 10 times as much code and the result would
>> perform really bad.
>>
>> Java or Python frontend calling C wrapper calling Cobol
>> or PL/I code may be doable, but comes with a lot of risks
>> due to potentially incompatible threading/transactional/whatever
>> models.
>
> Why would you need all of that?  COBOL does CICS and CICS does
> the web.  No extra code required.

That sounds pretty easy.

But if we assume RESTful web services which are by far the
most common today.

1) How does CICS know the right URL to assign to a resource?
2) How does CICS know whether to use path or query URL?
3) How does CICS know whether to do XML or JSON or both?
4) How does CICS know whether to do CORS?

>> Neither seems attractive to me.
>>
>> Doing it all in Java is possible (Java on z works
>> with CICS and DB2). Maybe it is also possible to do
>> it all in Python (Python does support DB2 but I don't
>> know about CICS - and I would probably prefer Java over
>> Python for such code anyway).
>>
>> If the use case allows for async updates then it would
>> be easy to have Java or Python read directly from DB2
>> but send all updates to IBM MQ and have some regular
>> Cobol or PL/I code handle the actual update (there are
>> most likely existing code there that can be reused).
>>
>
> IBM COBOL does Embedded CICS just like Embedded SQL.
> It can all be done without any of the wrappers people
> seem so enthralled with.
>
> As for the non-IBM side.  I have done a number of proof of
> concept COBOL <-> WEB systems back in my academia days.
> It's actually easier than PHP. Cleaner than PHP.  Easier to
> understand than PHP.  And definitely more secure than PHP.

CGI scripts or?

Arne

On 4/16/2022 7:00 PM, Craig A. Berry wrote:
> On 4/16/22 5:25 PM, Dave Froble wrote:
>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>>> for writing a new web service.
>>>>>>>
>>>>>>> Not on any platform.
>>>>>>
>>>>>> Really depends on the web service, doesn't it?
>>>>
>>>> And on the *definition* of "web services".
>>>
>>> There may not be a formal definition, but most developers have
>>> a common understanding what such a thing is.
>>>
>>> Something like: a service intended to be used by client applications
>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>
>>> Arne
>>>
>>
>> Well, there you go again, refining the definition to match your claims. Of
>> course that makes you right.
>>
>> How about anything that offers some service that might be needed over the
>> internet?
>
> Nope. That would be an internet service. A web service uses some
> version of the HTTP protocol. While that doesn't necessarily imply
> REST, the simplicity of REST has made web services largely eclipse older
> client-server protocols such as SOAP or Java RMI.

Having looked at REST, I find it as difficult and performance robbing as the
"rest" (no pun intended) of the "standard" protocols. We have done some
testing. We find that using sockets with no additional overhead has given us
the best performance and the least overhead and the simplest programming.

I will admit that we already had a protocol in place, so that helped.

So, if we cannot be considered having a "web service", we don't care, and we
think our approach is better.

We still call them our "web services".

I've written a HTTP(S) PUT utility using our socket communications, but only use
it when the trading partner insists on HTTPS.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/16/2022 7:15 PM, Jan-Erik Söderholm wrote:
> Den 2022-04-17 kl. 00:25, skrev Dave Froble:
>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>>> for writing a new web service.
>>>>>>>
>>>>>>> Not on any platform.
>>>>>>
>>>>>> Really depends on the web service, doesn't it?
>>>>
>>>> And on the *definition* of "web services".
>>>
>>> There may not be a formal definition, but most developers have
>>> a common understanding what such a thing is.
>>>
>>> Something like: a service intended to be used by client applications
>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>
>>> Arne
>>>
>>
>> Well, there you go again, refining the definition to match your claims. Of
>> course that makes you right.
>>
>> How about anything that offers some service that might be needed over the
>> internet?
>>
>
>
>
> That is not the common definition. "The internet" is a lot of other
> things than "the web". The web is usualy defined by a collectins of
> protocols and there are manby other protocols used on the internet.
>
> Note that "the internet" and "the web" is not the same thing.
>
> You can create a socket listener that clients conects to, but that
> has very litle to do with "the web".
>
> As Arne also wrote, a "web service" use the protocols that are used
> between web client (usually web browsers) and web servers. The web
> servers then uses web services server processes.
>
> A traditional "socket listener" is not a "web service".
>
>
>

Yeah, Ok, but they all have socket listeners at the core with additional stuff
piled on top.

Not sure if I'm interested in arguing symantics.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 17/04/2022 10:04 am, Dave Froble wrote:
> On 4/16/2022 7:00 PM, Craig A. Berry wrote:
>> On 4/16/22 5:25 PM, Dave Froble wrote:
>>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>>>> for writing a new web service.
>>>>>>>>
>>>>>>>> Not on any platform.
>>>>>>>
>>>>>>> Really depends on the web service, doesn't it?
>>>>>
>>>>> And on the *definition* of "web services".
>>>>
>>>> There may not be a formal definition, but most developers have
>>>> a common understanding what such a thing is.
>>>>
>>>> Something like: a service intended to be used by client applications
>>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>>
>>>> Arne
>>>>
>>>
>>> Well, there you go again, refining the definition to match your
>>> claims.  Of
>>> course that makes you right.
>>>
>>> How about anything that offers some service that might be needed over
>>> the
>>> internet?
>>
>> Nope.  That would be an internet service.  A web service uses some
>> version of the HTTP protocol.  While that doesn't necessarily imply
>> REST, the simplicity of REST has made web services largely eclipse older
>> client-server protocols such as SOAP or Java RMI.
>
> Having looked at REST, I find it as difficult and performance robbing as
> the "rest" (no pun intended) of the "standard" protocols.  We have done
> some testing.  We find that using sockets with no additional overhead
> has given us the best performance and the least overhead and the
> simplest programming.
>

*** On "performance" note that Tier3's socket multiplexing via JAVA
Applet STATIC variables predated HTTP 1.1 and Google's multiplexing.
(Should've had a patent :-( )

But everyone agrees *no one* would start today with HTTP as the
client/server middleware protocol of choice! It just happened and we are
where we are.

When it comes to RESTful the main problem is sessions, by definition,
are out of scope. Then you get your regular Java wankers telling you
JWTs are the answer except they're a huge security and performance risk.
But they are popular 'cos all the session data is in the JWT cookie but
can't be cancelled and leads to same cognoscente deciding to revalidate
every 10secs :-(

Which delivers us nicely to FIDO2 passwordless(ish) authentication. VMS
must support this by being a validator.

But that's just authentication, what about authorization? Well that's
where VMS has to support REDis cache, or whatever Oracle has.

Lots to do eh?

Den 2022-04-17 kl. 02:26, skrev Arne Vajhøj:
> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>> On 4/15/2022 7:17 PM, Richard Maher wrote:
>>>>>>> On 15/04/2022 8:44 pm, Arne Vajhøj wrote:
>>>>>>>> On 4/15/2022 3:36 AM, Richard Maher wrote:
>>>>>>>>> Something like Kestrel that talks HTTP and can pass JSON to 3GL
>>>>>>>>> code a la mode de TIER3. FIDO2 Authentication support.
>>>>>>>>
>>>>>>>> Both Java and Python can provide nice embedded HTTP servers, do
>>>>>>>> JSON and
>>>>>>>> potentially interact with native code (Cobol or otherwise), but
>>>>>>>> obvious
>>>>>>>> question is whether it wouldn't be better to do it all in either
>>>>>>>> Java or Python.
>>>>>>>
>>>>>>> This is the biggest mistake VMS has made for 20 years; throw away
>>>>>>> the existing
>>>>>>> customer base :-(
>>>>>>
>>>>>> Using the right tool for the job is hardly throwing away the
>>>>>> customer base.
>>>>>>
>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>> for writing a new web service.
>>>>>>
>>>>>> Not on any platform.
>>>>>
>>>>> Really depends on the web service, doesn't it?
>>>>
>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>
>>> I don't see that combo as special.
>>>
>>> CGI scripts in Cobol or PL/I would require the developers
>>> to write maybe 10 times as much code and the result would
>>> perform really bad.
>>>
>>> Java or Python frontend calling C wrapper calling Cobol
>>> or PL/I code may be doable, but comes with a lot of risks
>>> due to potentially incompatible threading/transactional/whatever
>>> models.
>>
>> Why would you need all of that?  COBOL does CICS and CICS does
>> the web.  No extra code required.
>
> That sounds pretty easy.
>
> But if we assume RESTful web services which are by far the
> most common today.
>
> 1) How does CICS know the right URL to assign to a resource?
> 2) How does CICS know whether to use path or query URL?
> 3) How does CICS know whether to do XML or JSON or both?
> 4) How does CICS know whether to do CORS?
>

You use CWS. Google "cics web service". CWS gives access
to the usual tools used in web services programming.

I did CICS/Cobol/DB2 development including CWS approx.
20 years ago. At that time to build common web pages but
it seems to have evolved to include other functionallity.

>>> Neither seems attractive to me.
>>>
>>> Doing it all in Java is possible (Java on z works
>>> with CICS and DB2). Maybe it is also possible to do
>>> it all in Python (Python does support DB2 but I don't
>>> know about CICS - and I would probably prefer Java over
>>> Python for such code anyway).
>>>
>>> If the use case allows for async updates then it would
>>> be easy to have Java or Python read directly from DB2
>>> but send all updates to IBM MQ and have some regular
>>> Cobol or PL/I code handle the actual update (there are
>>> most likely existing code there that can be reused).
>>>
>>
>> IBM COBOL does Embedded CICS just like Embedded SQL.
>> It can all be done without any of the wrappers people
>> seem so enthralled with.
>>

If you do that, it is usually done with CWS. Less coding of
your own and less errors/bugs.

The same reason one use SQL today to "wrap" the DB accesses.

>> As for the non-IBM side.  I have done a number of proof of
>> concept COBOL <-> WEB systems back in my academia days.
>> It's actually easier than PHP. Cleaner than PHP.  Easier to
>> understand than PHP.  And definitely more secure than PHP.
>
> CGI scripts or?
>
> Arne
>

Den 2022-04-17 kl. 04:04, skrev Dave Froble:
> On 4/16/2022 7:00 PM, Craig A. Berry wrote:
>> On 4/16/22 5:25 PM, Dave Froble wrote:
>>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>>>> for writing a new web service.
>>>>>>>>
>>>>>>>> Not on any platform.
>>>>>>>
>>>>>>> Really depends on the web service, doesn't it?
>>>>>
>>>>> And on the *definition* of "web services".
>>>>
>>>> There may not be a formal definition, but most developers have
>>>> a common understanding what such a thing is.
>>>>
>>>> Something like: a service intended to be used by client applications
>>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>>
>>>> Arne
>>>>
>>>
>>> Well, there you go again, refining the definition to match your claims.  Of
>>> course that makes you right.
>>>
>>> How about anything that offers some service that might be needed over the
>>> internet?
>>
>> Nope.  That would be an internet service.  A web service uses some
>> version of the HTTP protocol.  While that doesn't necessarily imply
>> REST, the simplicity of REST has made web services largely eclipse older
>> client-server protocols such as SOAP or Java RMI.
>
> Having looked at REST, I find it as difficult and performance robbing as
> the "rest" (no pun intended) of the "standard" protocols.  We have done
> some testing.  We find that using sockets with no additional overhead has
> given us the best performance and the least overhead and the simplest
> programming.
>
> I will admit that we already had a protocol in place, so that helped.
>
> So, if we cannot be considered having a "web service", we don't care, and
> we think our approach is better.
>
> We still call them our "web services".

Yes, of course you do! :-) That is what the customers want to hear, right?
They probably do not care if it is correct or if it is just sales talk.

>
> I've written a HTTP(S) PUT utility using our socket communications, but
> only use it when the trading partner insists on HTTPS.
>

Most sane developer would not write that themself, but deploy a web
server that already have all that built-in out of the box. You "only"
have to supply the backend server process that has the business logic.

Process management, adding or removing processes as needed, access
and authentication control and so on are already handled by the
web server.

On 4/16/2022 10:04 PM, Dave Froble wrote:
> On 4/16/2022 7:00 PM, Craig A. Berry wrote:
>> On 4/16/22 5:25 PM, Dave Froble wrote:
>>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>>> And on the *definition* of "web services".
>>>>
>>>> There may not be a formal definition, but most developers have
>>>> a common understanding what such a thing is.
>>>>
>>>> Something like: a service intended to be used by client applications
>>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>
>>> Well, there you go again, refining the definition to match your
>>> claims.  Of
>>> course that makes you right.
>>>
>>> How about anything that offers some service that might be needed over
>>> the
>>> internet?
>>
>> Nope.  That would be an internet service.  A web service uses some
>> version of the HTTP protocol.  While that doesn't necessarily imply
>> REST, the simplicity of REST has made web services largely eclipse older
>> client-server protocols such as SOAP or Java RMI.
>
> Having looked at REST, I find it as difficult and performance robbing as
> the "rest" (no pun intended) of the "standard" protocols.  We have done
> some testing.  We find that using sockets with no additional overhead
> has given us the best performance and the least overhead and the
> simplest programming.
>
> I will admit that we already had a protocol in place, so that helped.
>
> So, if we cannot be considered having a "web service", we don't care,
> and we think our approach is better.
>
> We still call them our "web services".

Sending binary messages over a permanent socket is very
efficient, but it is not a web service. The technology used
is not something invented for web.

Obviously there is a tradeoff - more efficient for
more work and tighter coupling.

But it certainly has its use case. A modern flavor
of this is Thrift. And depending on view gRPC can
can be seen as a hybrid between this and web service.

Web services are very popular but it is not the right
choice for everything.

Arne

On 4/16/2022 10:06 PM, Dave Froble wrote:
> On 4/16/2022 7:15 PM, Jan-Erik Söderholm wrote:
>> Den 2022-04-17 kl. 00:25, skrev Dave Froble:
>>> How about anything that offers some service that might be needed over
>>> the
>>> internet?
>>
>> That is not the common definition. "The internet" is a lot of other
>> things than "the web". The web is usualy defined by a collectins of
>> protocols and there are manby other protocols used on the internet.
>>
>> Note that "the internet" and "the web" is not the same thing.
>>
>> You can create a socket listener that clients conects to, but that
>> has very litle to do with "the web".
>>
>> As Arne also wrote, a "web service" use the protocols that are used
>> between web client (usually web browsers) and web servers. The web
>> servers then uses web services server processes.
>>
>> A traditional "socket listener" is not a "web service".
>
> Yeah, Ok, but they all have socket listeners at the core with additional
> stuff piled on top.

A web service framework is build on top of a socket listener.

But there is a lot on top of it!

:-)

Arne

On 4/16/22 20:26, Arne Vajhøj wrote:
> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>> On 4/15/2022 7:17 PM, Richard Maher wrote:
>>>>>>> On 15/04/2022 8:44 pm, Arne Vajhøj wrote:
>>>>>>>> On 4/15/2022 3:36 AM, Richard Maher wrote:
>>>>>>>>> Something like Kestrel that talks HTTP and can pass JSON to 3GL
>>>>>>>>> code a la mode de TIER3. FIDO2 Authentication support.
>>>>>>>>
>>>>>>>> Both Java and Python can provide nice embedded HTTP servers, do
>>>>>>>> JSON and
>>>>>>>> potentially interact with native code (Cobol or otherwise), but
>>>>>>>> obvious
>>>>>>>> question is whether it wouldn't be better to do it all in either
>>>>>>>> Java or Python.
>>>>>>>
>>>>>>> This is the biggest mistake VMS has made for 20 years; throw away
>>>>>>> the existing
>>>>>>> customer base :-(
>>>>>>
>>>>>> Using the right tool for the job is hardly throwing away the
>>>>>> customer base.
>>>>>>
>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>> for writing a new web service.
>>>>>>
>>>>>> Not on any platform.
>>>>>
>>>>> Really depends on the web service, doesn't it?
>>>>
>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>
>>> I don't see that combo as special.
>>>
>>> CGI scripts in Cobol or PL/I would require the developers
>>> to write maybe 10 times as much code and the result would
>>> perform really bad.
>>>
>>> Java or Python frontend calling C wrapper calling Cobol
>>> or PL/I code may be doable, but comes with a lot of risks
>>> due to potentially incompatible threading/transactional/whatever
>>> models.
>>
>> Why would you need all of that?  COBOL does CICS and CICS does
>> the web.  No extra code required.
>
> That sounds pretty easy.
>
> But if we assume RESTful web services which are by far the
> most common today.
>
> 1) How does CICS know the right URL to assign to a resource?
> 2) How does CICS know whether to use path or query URL?
> 3) How does CICS know whether to do XML or JSON or both?
> 4) How does CICS know whether to do CORS?
>

Can't answer that because I haven't a clue what your talking about.
I'm not a web developer. I do real programming.

>>> Neither seems attractive to me.
>>>
>>> Doing it all in Java is possible (Java on z works
>>> with CICS and DB2). Maybe it is also possible to do
>>> it all in Python (Python does support DB2 but I don't
>>> know about CICS - and I would probably prefer Java over
>>> Python for such code anyway).
>>>
>>> If the use case allows for async updates then it would
>>> be easy to have Java or Python read directly from DB2
>>> but send all updates to IBM MQ and have some regular
>>> Cobol or PL/I code handle the actual update (there are
>>> most likely existing code there that can be reused).
>>>
>>
>> IBM COBOL does Embedded CICS just like Embedded SQL.
>> It can all be done without any of the wrappers people
>> seem so enthralled with.
>>
>> As for the non-IBM side.  I have done a number of proof of
>> concept COBOL <-> WEB systems back in my academia days.
>> It's actually easier than PHP. Cleaner than PHP.  Easier to
>> understand than PHP.  And definitely more secure than PHP.
>
> CGI scripts or?

I guess some would call it that, but what I did weren't "scripts",
they were real programs. As part of my proof of concept I did do
scripts, too. In some cases I took complex (and un-discernible)
PHP scripts and redid them in simple Shell Scripts and also in
COBOL. The results were much easier to understand (and thus to
maintain) and definitely more secure.

bill

On 4/17/2022 9:00 AM, Arne Vajhøj wrote:
> On 4/16/2022 10:06 PM, Dave Froble wrote:
>> On 4/16/2022 7:15 PM, Jan-Erik Söderholm wrote:
>>> Den 2022-04-17 kl. 00:25, skrev Dave Froble:
>>>> How about anything that offers some service that might be needed over the
>>>> internet?
>>>
>>> That is not the common definition. "The internet" is a lot of other
>>> things than "the web". The web is usualy defined by a collectins of
>>> protocols and there are manby other protocols used on the internet.
>>>
>>> Note that "the internet" and "the web" is not the same thing.
>>>
>>> You can create a socket listener that clients conects to, but that
>>> has very litle to do with "the web".
>>>
>>> As Arne also wrote, a "web service" use the protocols that are used
>>> between web client (usually web browsers) and web servers. The web
>>> servers then uses web services server processes.
>>>
>>> A traditional "socket listener" is not a "web service".
>>
>> Yeah, Ok, but they all have socket listeners at the core with additional stuff
>> piled on top.
>
> A web service framework is build on top of a socket listener.
>
> But there is a lot on top of it!
>
> :-)
>
> Arne
>

Ayep! A LOT of BLOAT ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/17/2022 9:05 AM, Bill Gunshannon wrote:
> On 4/16/22 20:26, Arne Vajhøj wrote:
>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>
>>>> I don't see that combo as special.
>>>>
>>>> CGI scripts in Cobol or PL/I would require the developers
>>>> to write maybe 10 times as much code and the result would
>>>> perform really bad.
>>>>
>>>> Java or Python frontend calling C wrapper calling Cobol
>>>> or PL/I code may be doable, but comes with a lot of risks
>>>> due to potentially incompatible threading/transactional/whatever
>>>> models.
>>>
>>> Why would you need all of that?  COBOL does CICS and CICS does
>>> the web.  No extra code required.
>>
>> That sounds pretty easy.
>>
>> But if we assume RESTful web services which are by far the
>> most common today.
>>
>> 1) How does CICS know the right URL to assign to a resource?
>> 2) How does CICS know whether to use path or query URL?
>> 3) How does CICS know whether to do XML or JSON or both?
>> 4) How does CICS know whether to do CORS?
>>
>
> Can't answer that because I haven't a clue what your talking about.

Then how can you claim that no extra code is needed??

> I'm not a web developer.  I do real programming.

CORS are only for web programming, but the first 3 are not
specific for web programming.

These types of services are the building blocks that
financial systems, ERP systems, administrative systems
etc. are build from today.

It does not get much more real programming than that.

To some extent you can consider it the modern equivalent
of calling conventions.

>>> As for the non-IBM side.  I have done a number of proof of
>>> concept COBOL <-> WEB systems back in my academia days.
>>> It's actually easier than PHP. Cleaner than PHP.  Easier to
>>> understand than PHP.  And definitely more secure than PHP.
>>
>> CGI scripts or?
>
> I guess some would call it that, but what I did weren't "scripts",
> they were real programs.

CGI script just specify the mechanism used between the web server
and the application code.

It can be DCL/Perl/whatever or C/Cobol/Fotran/whatever.

It has been obsolete for serious usage in 2 decades.

Arne

On 4/17/2022 4:45 AM, Jan-Erik Söderholm wrote:
> Den 2022-04-17 kl. 02:26, skrev Arne Vajhøj:
>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>
>>>> I don't see that combo as special.
>>>>
>>>> CGI scripts in Cobol or PL/I would require the developers
>>>> to write maybe 10 times as much code and the result would
>>>> perform really bad.
>>>>
>>>> Java or Python frontend calling C wrapper calling Cobol
>>>> or PL/I code may be doable, but comes with a lot of risks
>>>> due to potentially incompatible threading/transactional/whatever
>>>> models.
>>>
>>> Why would you need all of that?  COBOL does CICS and CICS does
>>> the web.  No extra code required.
>>
>> That sounds pretty easy.
>>
>> But if we assume RESTful web services which are by far the
>> most common today.
>>
>> 1) How does CICS know the right URL to assign to a resource?
>> 2) How does CICS know whether to use path or query URL?
>> 3) How does CICS know whether to do XML or JSON or both?
>> 4) How does CICS know whether to do CORS?
>>
>
> You use CWS. Google "cics web service". CWS gives access
> to the usual tools used in web services programming.
>
> I did CICS/Cobol/DB2 development including CWS approx.
> 20 years ago. At that time to build common web pages but
> it seems to have evolved to include other functionallity.

I get that there is a web server.

I get that there are some Cobol code doing something.

What I don't get is how the web server end up exposing the
right API.

I know how ones does it in Java and C# - using annotations/attributes
in the application code to define it.

I have seen examples of how it is done in PHP and Python - setting up
callbacks.

I cannot see how that CICS web server can figure that out with
no code changes.

I am not a great believer in mind reading software.

Arne

On 4/16/2022 11:36 PM, Richard Maher wrote:
> *** On "performance" note that Tier3's socket multiplexing via JAVA
> Applet STATIC variables predated HTTP 1.1 and Google's multiplexing.

I suspect that you mean HTTP/2 not 1.1.

> But everyone agrees *no one* would start today with HTTP as the
> client/server middleware protocol of choice! It just happened and we are
> where we are.

:-)

> When it comes to RESTful the main problem is sessions, by definition,
> are out of scope. Then you get your regular Java wankers telling you
> JWTs are the answer except they're a huge security and performance risk.
> But they are popular 'cos all the session data is in the JWT cookie but
> can't be cancelled and leads to same cognoscente deciding to revalidate
> every 10secs :-(
>
> Which delivers us nicely to FIDO2 passwordless(ish) authentication.

REST is by definition stateless. But auth & auth is obviously still
needed. And there are various ways of handling that.

I do not have strong feelings pro or con JWT.

> But that's just authentication, what about authorization? Well that's
> where VMS has to support REDis cache, or whatever Oracle has.

VMS applications should be able to talk to use Redis if the necessary
client libraries are available.

There are different C libraries available - I have no idea whether
f.ex. hiredis build on VMS.

VMS PHP comes with Redis support per documentation.

The standard Python Redis client should work with VMS Python.

There are different Java libraries available but they are
pure Java so they should work with VMS Java.

Arne

On 4/17/22 12:52, Arne Vajhøj wrote:
> On 4/17/2022 9:05 AM, Bill Gunshannon wrote:
>> On 4/16/22 20:26, Arne Vajhøj wrote:
>>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>>
>>>>> I don't see that combo as special.
>>>>>
>>>>> CGI scripts in Cobol or PL/I would require the developers
>>>>> to write maybe 10 times as much code and the result would
>>>>> perform really bad.
>>>>>
>>>>> Java or Python frontend calling C wrapper calling Cobol
>>>>> or PL/I code may be doable, but comes with a lot of risks
>>>>> due to potentially incompatible threading/transactional/whatever
>>>>> models.
>>>>
>>>> Why would you need all of that?  COBOL does CICS and CICS does
>>>> the web.  No extra code required.
>>>
>>> That sounds pretty easy.
>>>
>>> But if we assume RESTful web services which are by far the
>>> most common today.
>>>
>>> 1) How does CICS know the right URL to assign to a resource?
>>> 2) How does CICS know whether to use path or query URL?
>>> 3) How does CICS know whether to do XML or JSON or both?
>>> 4) How does CICS know whether to do CORS?
>>>
>>
>> Can't answer that because I haven't a clue what your talking about.
>
> Then how can you claim that no extra code is needed??

Because it is all done in the COBOL program using CICS and DB2.
Granted, you can't write a version of Candy Crush Saga but all
I ever cared about was real work.

>
>> I'm not a web developer.  I do real programming.
>
> CORS are only for web programming, but the first 3 are not
> specific for web programming.
>
> These types of services are the building blocks that
> financial systems, ERP systems, administrative systems
> etc. are build from today.

Or, maybe a lot of fluff that really isn't needed to get the
job done but makes great marketing.

>
> It does not get much more real programming than that.

It does when the desire is to get rids of the fluff and only
sell the customer what they really needed.

>
> To some extent you can consider it the modern equivalent
> of calling conventions.

I guess because I started out long before bloatware became the
standard I see things a little differently.

>
>>>> As for the non-IBM side.  I have done a number of proof of
>>>> concept COBOL <-> WEB systems back in my academia days.
>>>> It's actually easier than PHP. Cleaner than PHP.  Easier to
>>>> understand than PHP.  And definitely more secure than PHP.
>>>
>>> CGI scripts or?
>>
>> I guess some would call it that, but what I did weren't "scripts",
>> they were real programs.
>
> CGI script just specify the mechanism used between the web server
> and the application code.
>
> It can be DCL/Perl/whatever or C/Cobol/Fotran/whatever.
>
> It has been obsolete for serious usage in 2 decades.

Yeah,, I keep hearing how COBOL and Fortran etc. are all dead.
funny how that never seems to come about. Oh yeah, and BYTE
Magazine announced the death of Unix at least 30 years ago.
One can only hope that the current move to take IT education
out of the hands of academia may eventually bring the industry
back to its senses.

bill

On 4/17/2022 1:00 PM, Arne Vajhøj wrote:
> On 4/17/2022 4:45 AM, Jan-Erik Söderholm wrote:
>> Den 2022-04-17 kl. 02:26, skrev Arne Vajhøj:
>>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>>
>>>>> I don't see that combo as special.
>>>>>
>>>>> CGI scripts in Cobol or PL/I would require the developers
>>>>> to write maybe 10 times as much code and the result would
>>>>> perform really bad.
>>>>>
>>>>> Java or Python frontend calling C wrapper calling Cobol
>>>>> or PL/I code may be doable, but comes with a lot of risks
>>>>> due to potentially incompatible threading/transactional/whatever
>>>>> models.
>>>>
>>>> Why would you need all of that? COBOL does CICS and CICS does
>>>> the web. No extra code required.
>>>
>>> That sounds pretty easy.
>>>
>>> But if we assume RESTful web services which are by far the
>>> most common today.
>>>
>>> 1) How does CICS know the right URL to assign to a resource?
>>> 2) How does CICS know whether to use path or query URL?
>>> 3) How does CICS know whether to do XML or JSON or both?
>>> 4) How does CICS know whether to do CORS?
>>>
>>
>> You use CWS. Google "cics web service". CWS gives access
>> to the usual tools used in web services programming.
>>
>> I did CICS/Cobol/DB2 development including CWS approx.
>> 20 years ago. At that time to build common web pages but
>> it seems to have evolved to include other functionallity.
>
> I get that there is a web server.
>
> I get that there are some Cobol code doing something.
>
> What I don't get is how the web server end up exposing the
> right API.
>
> I know how ones does it in Java and C# - using annotations/attributes
> in the application code to define it.
>
> I have seen examples of how it is done in PHP and Python - setting up
> callbacks.
>
> I cannot see how that CICS web server can figure that out with
> no code changes.
>
> I am not a great believer in mind reading software.
>
> Arne
>
>

Oh, sure. I remember a request at a DECUS event where the customer asked for
DCL to do what he meant, not what he typed. Everyone thought it was a great idea.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-04-16, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
> I work every year with wankers that don't understand relational DBs and
> SQL and insist on some shit like Entity Framework to try to turn a table
> into a class(es) and other wankers that demand a "model" because they're
> upset JSON is just a String :-(
>

But JSON isn't a string. That would be like calling a database just
a stream of bytes.

The string is just the backing store for the data held within and you
certainly do need a parser, and maybe some object model that you can
iterate through, to assign meaning to the contents of that string.

Having said that, I do think that sometimes people do go overboard in
using whatever is the fashion of the month instead of just a nice simple
parser that maybe just builds an object tree that you can iterate through
to extract the data you need.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-16, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>
> But everyone agrees *no one* would start today with HTTP as the
> client/server middleware protocol of choice! It just happened and we are
> where we are.
>

It's called history and we have to live with it. :-)

For example, if VMS was designed today, it wouldn't be designed
in the way it was. But we have what we were given decades ago based
on the technology of the time.

For an even bigger example, why do we have QWERTY keyboards instead
of some other arrangement ? Decisions made over a century ago still
control how people who use QWERTY keyboards (and their variants)
actually do use those keyboards.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-16, Dave Froble <davef@tsoft-inc.com> wrote:
>
> I've written a HTTP(S) PUT utility using our socket communications, but only use
> it when the trading partner insists on HTTPS.
>

What encryption methods do you use to securely transfer data when you
don't use this option ?

Also, what TLS version does the above utility use ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/17/2022 6:55 PM, Simon Clubley wrote:
> On 2022-04-16, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>> I work every year with wankers that don't understand relational DBs and
>> SQL and insist on some shit like Entity Framework to try to turn a table
>> into a class(es) and other wankers that demand a "model" because they're
>> upset JSON is just a String :-(
>
> But JSON isn't a string. That would be like calling a database just
> a stream of bytes.
>
> The string is just the backing store for the data held within and you
> certainly do need a parser, and maybe some object model that you can
> iterate through, to assign meaning to the contents of that string.

Yep.

> Having said that, I do think that sometimes people do go overboard in
> using whatever is the fashion of the month instead of just a nice simple
> parser that maybe just builds an object tree that you can iterate through
> to extract the data you need.

If you use JSON then you do not need to write that parser but can
just pick one and use it - for almost all languages - and for
the more popular languages there are multiple parsers to choose from.

Arne

On 4/17/2022 7:10 PM, Simon Clubley wrote:
> On 2022-04-16, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> I've written a HTTP(S) PUT utility using our socket communications, but only use
>> it when the trading partner insists on HTTPS.
>>
>
> What encryption methods do you use to securely transfer data when you
> don't use this option ?

We use SSL/TLS, whatever is available.

> Also, what TLS version does the above utility use ?

TLS V1.3, or, whatever we have to use to talk to each trading partner.

Come on Simon, what does a data format (HTTP) have to do with encryption? One
uses the latest SSL/TLS stuff, what else would one do?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/17/2022 4:25 PM, Bill Gunshannon wrote:
> On 4/17/22 12:52, Arne Vajhøj wrote:
>> On 4/17/2022 9:05 AM, Bill Gunshannon wrote:
>>> On 4/16/22 20:26, Arne Vajhøj wrote:
>>>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>>>
>>>>>> I don't see that combo as special.
>>>>>>
>>>>>> CGI scripts in Cobol or PL/I would require the developers
>>>>>> to write maybe 10 times as much code and the result would
>>>>>> perform really bad.
>>>>>>
>>>>>> Java or Python frontend calling C wrapper calling Cobol
>>>>>> or PL/I code may be doable, but comes with a lot of risks
>>>>>> due to potentially incompatible threading/transactional/whatever
>>>>>> models.
>>>>>
>>>>> Why would you need all of that?  COBOL does CICS and CICS does
>>>>> the web.  No extra code required.
>>>>
>>>> That sounds pretty easy.
>>>>
>>>> But if we assume RESTful web services which are by far the
>>>> most common today.
>>>>
>>>> 1) How does CICS know the right URL to assign to a resource?
>>>> 2) How does CICS know whether to use path or query URL?
>>>> 3) How does CICS know whether to do XML or JSON or both?
>>>> 4) How does CICS know whether to do CORS?
>>>
>>> Can't answer that because I haven't a clue what your talking about.
>>
>> Then how can you claim that no extra code is needed??
>
> Because it is all done in the COBOL program using CICS and DB2.

I find it a bit weird to hear someone claim that X is easy
to do in a given technology without knowing what X is or how to
to do X in that technology.

>>> I'm not a web developer.  I do real programming.
>>
>> CORS are only for web programming, but the first 3 are not
>> specific for web programming.
>>
>> These types of services are the building blocks that
>> financial systems, ERP systems, administrative systems
>> etc. are build from today.
>
> Or, maybe a  lot of fluff that really isn't needed to get the
> job done but makes great marketing.
>
>> It does not get much more real programming than that.
>
> It does when the desire is to get rids of the fluff and only
> sell the customer what they really needed.

This is all about the "how". The end user only care
about the "what".

Arne

On 4/17/2022 4:25 PM, Bill Gunshannon wrote:
> On 4/17/22 12:52, Arne Vajhøj wrote:
>> On 4/17/2022 9:05 AM, Bill Gunshannon wrote:
>>> On 4/16/22 20:26, Arne Vajhøj wrote:
>>>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>>>> As for the non-IBM side.  I have done a number of proof of
>>>>> concept COBOL <-> WEB systems back in my academia days.
>>>>> It's actually easier than PHP. Cleaner than PHP.  Easier to
>>>>> understand than PHP.  And definitely more secure than PHP.
>>>>
>>>> CGI scripts or?
>>>
>>> I guess some would call it that, but what I did weren't "scripts",
>>> they were real programs.
>>
>> CGI script just specify the mechanism used between the web server
>> and the application code.
>>
>> It can be DCL/Perl/whatever or C/Cobol/Fotran/whatever.
>>
>> It has been obsolete for serious usage in 2 decades.
>
> Yeah,, I keep hearing how COBOL and Fortran etc. are all dead.
> funny how that never seems to come about.  Oh yeah, and BYTE
> Magazine announced the death of Unix at least 30 years ago.
> One can only hope that the current move to take IT education
> out of the hands of academia may eventually bring the industry
> back to its senses.

You are mixing up a lot of stuff.

By obsolete I mean technologies where better technologies
has been invented. That means that someone having totally freedom
to pick the technology will never pick the obsolete one.
Obsolete stuff may still be supported. And new code
may still be created based on the obsolete technology, if the new
code has to fit in with a lot of old code based on
that technology. There will be a desire to change from the
obsolete technology to something newer, but the risk of
a big migration project get many migrations postponed
to some undefined future.

Dead on the other hand is more severe. The technology does
not have a future. Either support has been dropped or
a deadline for end of support has been set - and no new
versions. That is a scenario that forces IT departments
to start migration projects. They may not like the risk
and they may not like the timing, but the risk of not
migrating is too big.

Fortran is neither dead nor obsolete. Fortran 66 and 77 is
obsolete, but newer Fortran versions are not. Fortran has
become very much niche, but if even for a totally new from
scratch project, then there are cases (scientific number
crunching) where Fortran is still an obvious choice.
Python, R and Julia have taken over the high level
logic, but down to the matrices and vectors then
Fortran is still a player.

Cobol is not dead. IBM, VSI, Microfocus etc. still support
it and develop new versions. Lots of Cobol code exists
and there is no indications that everybody will have
migrated off within the next few decades. But I will consider
Cobol obsolete. If starting from scratch then Cobol will
not be chosen - business calculations, RDBMS access,
key value store access etc. can be done better in other
languages. Languages for business applications is
a very overcrowded market today.

CGI scripts are not dead either. There are still CGI scripts
being used (even though not that many - applications get rewritten
a lot faster in the web world than in the world where Cobol
reside). Most web servers still support them (even though
it has become common to not have them enabled by default).
But obsolete - not a choice for new applications. There
are so many alternatives (PHP, Python, node.js, Java, .NET etc. all
have lots of different alternatives). And CGI scripts has
some fundamental problems. Process creation make them slow on *nix
and very slow on non-*nix. The execution model makes it impossible
to use database connection pools so database access is slow.
The execution model makes simple in memory application and
session objects impossible.

Arne

Den 2022-04-17 kl. 19:00, skrev Arne Vajhøj:
> On 4/17/2022 4:45 AM, Jan-Erik Söderholm wrote:
>> Den 2022-04-17 kl. 02:26, skrev Arne Vajhøj:
>>> On 4/16/2022 6:54 PM, Bill Gunshannon wrote:
>>>> On 4/16/22 18:09, Arne Vajhøj wrote:
>>>>> On 4/16/2022 7:28 AM, Bill Gunshannon wrote:
>>>>>> Like maybe, IBM zSystem running COBOL with CICS and a DB2 backend.
>>>>>
>>>>> I don't see that combo as special.
>>>>>
>>>>> CGI scripts in Cobol or PL/I would require the developers
>>>>> to write maybe 10 times as much code and the result would
>>>>> perform really bad.
>>>>>
>>>>> Java or Python frontend calling C wrapper calling Cobol
>>>>> or PL/I code may be doable, but comes with a lot of risks
>>>>> due to potentially incompatible threading/transactional/whatever
>>>>> models.
>>>>
>>>> Why would you need all of that?  COBOL does CICS and CICS does
>>>> the web.  No extra code required.
>>>
>>> That sounds pretty easy.
>>>
>>> But if we assume RESTful web services which are by far the
>>> most common today.
>>>
>>> 1) How does CICS know the right URL to assign to a resource?
>>> 2) How does CICS know whether to use path or query URL?
>>> 3) How does CICS know whether to do XML or JSON or both?
>>> 4) How does CICS know whether to do CORS?
>>>
>>
>> You use CWS. Google "cics web service". CWS gives access
>> to the usual tools used in web services programming.
>>
>> I did CICS/Cobol/DB2 development including CWS approx.
>> 20 years ago. At that time to build common web pages but
>> it seems to have evolved to include other functionallity.
>
> I get that there is a web server.
>
> I get that there are some Cobol code doing something.
>
> What I don't get is how the web server end up exposing the
> right API.
>
> I know how ones does it in Java and C# - using annotations/attributes
> in the application code to define it.

A lot of that is done outside of the application code. It is
configurations in the web parts in CWS. I'm not really sure there,
someone else did the web related parts and we (the Cobol guys) was
given some functions to call for the web releated parts. Or descriptions
on how our code was going to be called by the CWS for the "web services".

>
> I have seen examples of how it is done in PHP and Python - setting up
> callbacks.
>
> I cannot see how that CICS web server can figure that out with
> no code changes.
>

No code changes in what code? There was no code to change. This
was new web-enabled code. What do you mean with a "code change"?

> I am not a great believer in mind reading software.
>

And I have no idea what you are talkning about... :-)

> Arne
>
>

Well, the Cobol code calls the APis that CWS provides, of course.