Den 2022-04-18 kl. 01:27, skrev Arne Vajhøj:
> 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
>

We have some Cobol cases where the data sent to "the other side"
was defined as JSON. The structure was fixed and the data parts
all had known and fixed sizes (or could be blank filled), so it
was easy enough to define the JSON structure as a Cobol record
with variables for the data parts and just "fill-in-the-blanks".

I guess that you could call that "a astring". With a special format
but still a (kind of) string.

For some cases (the recevier requested UUID version 4 while VMS
only supports Version 1), so we used Python and the JSON support
it has. On the communication channel (an MQ queue) it is still
a string of characters.

And in another case we got an XML structure, but it had a very
well known format so the data we needed could just be fetched
from well know positions in that "XML string".

So you can very well use JSON or XML *in specific cases*
without the fancy parsers.

I'm not against parsers, of course. In another case we receive
a large and very dynamic XML structure and there the parsing
and looping constructs in Python was very handy to read it.

On 4/18/2022 4:35 AM, Jan-Erik Söderholm wrote:
> Den 2022-04-18 kl. 01:27, skrev Arne Vajhøj:
>> On 4/17/2022 6:55 PM, Simon Clubley wrote:
>>> 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.
>
> We have some Cobol cases where the data sent to "the other side"
> was defined as JSON. The structure was fixed and the data parts
> all had known and fixed sizes (or could be blank filled), so it
> was easy enough to define the JSON structure as a Cobol record
> with variables for the data parts and just "fill-in-the-blanks".
>
> I guess that you could call that "a astring". With a special format
> but still a (kind of) string.
>
> For some cases (the recevier requested UUID version 4 while VMS
> only supports Version 1), so we used Python and the JSON support
> it has. On the communication channel (an MQ queue) it is still
> a string of characters.
>
> And in another case we got an XML structure, but it had a very
> well known format so the data we needed could just be fetched
> from well know positions in that "XML string".
>
> So you can very well use JSON or XML *in specific cases*
> without the fancy parsers.
>
> I'm not against parsers, of course. In another case we receive
> a large and very dynamic XML structure and there the parsing
> and looping constructs in Python was very handy to read it.

A parser that actually understand the rules of JSON/XML is
way more robust than a hack.

But obviously one need to do what one need to do. There are
no free JSON parser/generator for Cobol listed at json.org (one
commercial though).

Especially XML can be tricky.

3 years ago for another thread I created this monstrosity:

<a xmlns:df='http://df2'><b
xmlns='http://df1'><x><![CDATA[ABC<x></x>]]></x></b><c
xmlns='http://df2'><x><![CDATA[DEF<x></x>]]></x></c><c
xmlns='http://df3'><x><![CDATA[GHI<x></x>]]></x></c><df:c><df:x><![CDATA[JKL<x></x>]]></df:x></df:c></a>

Arne

On 4/18/2022 4:23 AM, Jan-Erik Söderholm wrote:
> 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".

My point is that somehow the application code need to describe the
web service to be exposed.

For a RESTful web service the mapping of URL's to methods/functions,
whether to consume/produce XML or JSON or both, mapping of data
structure to specific XML/JSON formats. If supporting browsers
also the CORS handling.

A SOAP contract first web service will also require mapping.

A SOAP code first web service may require relative little mapping. But
a language without reflection support will need the source code to
be present.

>> 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"?
>
> Well, the Cobol code calls the APis that CWS provides, of course.

I was referring to this by Bill:

"COBOL does CICS and CICS does the web. No extra code required."

If the Cobol code make calls that hook it into the web server then
it is a totally different story.

Arne

Den 2022-04-18 kl. 14:17, skrev Arne Vajhøj:
> On 4/18/2022 4:23 AM, Jan-Erik Söderholm wrote:
>> 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".
>
> My point is that somehow the application code need to describe the
> web service to be exposed.
>
> For a RESTful web service the mapping of URL's to methods/functions,
> whether to consume/produce XML or JSON or both, mapping of data
> structure to specific XML/JSON formats. If supporting browsers
> also the CORS handling.
>
> A SOAP contract first web service will also require mapping.
>
> A SOAP code first web service may require relative little mapping. But
> a language without reflection support will need the source code to
> be present.
>
>>> 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"?
> >
>> Well, the Cobol code calls the APis that CWS provides, of course.
>
> I was referring to this by Bill:
>
> "COBOL does CICS and CICS does the web.  No extra code required."
>
> If the Cobol code make calls that hook it into the web server then
> it is a totally different story.
>
> Arne
>

No idea what Bill wrote about. We used CWS, which is not a full blown
"web server", as I understand. It just gives the services needed for
CICS applications to respond to requests comming "from the web".

I might wery well be that Bill used CWS without knowing it.

And note this didn't use SOAP/XML/JSON or such, just usual GET/POST
HTTP calls from browsers. And CWS presented the CGI data to the
Cobol applications. Worked just fine. But it was 15-20 years ago.

>

On 4/18/2022 8:42 AM, Jan-Erik Söderholm wrote:
> Den 2022-04-18 kl. 14:17, skrev Arne Vajhøj:
>> On 4/18/2022 4:23 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-04-17 kl. 19:00, skrev Arne Vajhøj:
>>>> 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"?
>>  >
>>> Well, the Cobol code calls the APis that CWS provides, of course.
>>
>> I was referring to this by Bill:
>>
>> "COBOL does CICS and CICS does the web.  No extra code required."
>>
>> If the Cobol code make calls that hook it into the web server then
>> it is a totally different story.
>
> No idea what Bill wrote about. We used CWS, which is not a full blown
> "web server", as I understand. It just gives the services needed for
> CICS applications to respond to requests comming "from the web".
>
> I might wery well be that Bill used CWS without knowing it.
>
> And note this didn't use SOAP/XML/JSON or such, just usual GET/POST
> HTTP calls from browsers. And CWS presented the CGI data to the
> Cobol applications. Worked just fine. But it was 15-20 years ago.

application/x-www-form-urlencoded is usually associated with web
pages but it can be used by web services, but definitely old
fashioned in 2022.

Arne

> No idea what Bill wrote about. We used CWS, which is not a full
> blown "web server", as I understand. It just gives the services
> needed for CICS applications to respond to requests comming "from the
> web".
>

Luxury! How long have VMS 3GLs waited for such succor/manna?

On 18/04/2022 8:06 pm, Arne Vajhøj wrote:
> On 4/18/2022 4:35 AM, Jan-Erik Söderholm wrote:
>> Den 2022-04-18 kl. 01:27, skrev Arne Vajhøj:
>>> On 4/17/2022 6:55 PM, Simon Clubley wrote:
>>>> 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.
>>
>> We have some Cobol cases where the data sent to "the other side"
>> was defined as JSON. The structure was fixed and the data parts
>> all had known and fixed sizes (or could be blank filled), so it
>> was easy enough to define the JSON structure as a Cobol record
>> with variables for the data parts and just "fill-in-the-blanks".
>>
>> I guess that you could call that "a astring". With a special format
>> but still a (kind of) string.
>>
>> For some cases (the recevier requested UUID version 4 while VMS
>> only supports Version 1), so we used Python and the JSON support
>> it has. On the communication channel (an MQ queue) it is still
>> a string of characters.
>>
>> And in another case we got an XML structure, but it had a very
>> well known format so the data we needed could just be fetched
>> from well know positions in that "XML string".
>>
>> So you can very well use JSON or XML *in specific cases*
>> without the fancy parsers.
>>
>> I'm not against parsers, of course. In another case we receive
>> a large and very dynamic XML structure and there the parsing
>> and looping constructs in Python was very handy to read it.
>
> A parser that actually understand the rules of JSON/XML is
> way more robust than a hack.
>
> But obviously one need to do what one need to do. There are
> no free JSON parser/generator for Cobol listed at json.org (one
> commercial though).
>
> Especially XML can be tricky.
>
> 3 years ago for another thread I created this monstrosity:
>
> <a xmlns:df='http://df2'><b
> xmlns='http://df1'><x><![CDATA[ABC<x></x>]]></x></b><c
> xmlns='http://df2'><x><![CDATA[DEF<x></x>]]></x></c><c
> xmlns='http://df3'><x><![CDATA[GHI<x></x>]]></x></c><df:c><df:x><![CDATA[JKL<x></x>]]></df:x></df:c></a>
>
>
> Arne
>

What percentage of web services pass data via XML?

A: Bugger all!

On 4/18/2022 6:56 PM, Richard Maher wrote:
> On 18/04/2022 8:06 pm, Arne Vajhøj wrote:
>> On 4/18/2022 4:35 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-04-18 kl. 01:27, skrev Arne Vajhøj:
>>>> 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.
>>>
>>> We have some Cobol cases where the data sent to "the other side"
>>> was defined as JSON. The structure was fixed and the data parts
>>> all had known and fixed sizes (or could be blank filled), so it
>>> was easy enough to define the JSON structure as a Cobol record
>>> with variables for the data parts and just "fill-in-the-blanks".

>>> And in another case we got an XML structure, but it had a very
>>> well known format so the data we needed could just be fetched
>>> from well know positions in that "XML string".
>>>
>>> So you can very well use JSON or XML *in specific cases*
>>> without the fancy parsers.
>>>
>>> I'm not against parsers, of course. In another case we receive
>>> a large and very dynamic XML structure and there the parsing
>>> and looping constructs in Python was very handy to read it.
>>
>> A parser that actually understand the rules of JSON/XML is
>> way more robust than a hack.
>>
>> But obviously one need to do what one need to do. There are
>> no free JSON parser/generator for Cobol listed at json.org (one
>> commercial though).
>>
>> Especially XML can be tricky.
>>
>> 3 years ago for another thread I created this monstrosity:
>>
>> <a xmlns:df='http://df2'><b
>> xmlns='http://df1'><x><![CDATA[ABC<x></x>]]></x></b><c
>> xmlns='http://df2'><x><![CDATA[DEF<x></x>]]></x></c><c
>> xmlns='http://df3'><x><![CDATA[GHI<x></x>]]></x></c><df:c><df:x><![CDATA[JKL<x></x>]]></df:x></df:c></a>
>
> What percentage of web services pass data via XML?
>
> A: Bugger all!

JSON is by far most common today.

But XML still happens.

And relative easy to support both with most frameworks (declarative).

Arne

On 2022-04-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> 3 years ago for another thread I created this monstrosity:
>
><a xmlns:df='http://df2'><b
> xmlns='http://df1'><x><![CDATA[ABC<x></x>]]></x></b><c
> xmlns='http://df2'><x><![CDATA[DEF<x></x>]]></x></c><c
> xmlns='http://df3'><x><![CDATA[GHI<x></x>]]></x></c><df:c><df:x><![CDATA[JKL<x></x>]]></df:x></df:c></a>
>

I fully agree with you Arne.


That example above is indeed a monstrosity. :-)

I don't suppose you happen to remember what you were on when you
wrote it ? :-)

Simon.

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

On 19/04/2022 7:34 am, Arne Vajhøj wrote:
> On 4/18/2022 6:56 PM, Richard Maher wrote:
>> On 18/04/2022 8:06 pm, Arne Vajhøj wrote:
>>> On 4/18/2022 4:35 AM, Jan-Erik Söderholm wrote:
>>>> Den 2022-04-18 kl. 01:27, skrev Arne Vajhøj:
>>>>> 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.
>>>>
>>>> We have some Cobol cases where the data sent to "the other
>>>> side" was defined as JSON. The structure was fixed and the data
>>>> parts all had known and fixed sizes (or could be blank filled),
>>>> so it was easy enough to define the JSON structure as a Cobol
>>>> record with variables for the data parts and just
>>>> "fill-in-the-blanks".
>
>>>> And in another case we got an XML structure, but it had a very
>>>> well known format so the data we needed could just be fetched
>>>> from well know positions in that "XML string".
>>>>
>>>> So you can very well use JSON or XML *in specific cases*
>>>> without the fancy parsers.
>>>>
>>>> I'm not against parsers, of course. In another case we receive
>>>> a large and very dynamic XML structure and there the parsing
>>>> and looping constructs in Python was very handy to read it.
>>>
>>> A parser that actually understand the rules of JSON/XML is way
>>> more robust than a hack.
>>>
>>> But obviously one need to do what one need to do. There are no
>>> free JSON parser/generator for Cobol listed at json.org (one
>>> commercial though).
>>>
>>> Especially XML can be tricky.
>>>
>>> 3 years ago for another thread I created this monstrosity:
>>>
>>> <a xmlns:df='http://df2'><b
>>> xmlns='http://df1'><x><![CDATA[ABC<x></x>]]></x></b><c
>>> xmlns='http://df2'><x><![CDATA[DEF<x></x>]]></x></c><c
>>> xmlns='http://df3'><x><![CDATA[GHI<x></x>]]></x></c><df:c><df:x><![CDATA[JKL<x></x>]]></df:x></df:c></a>
>>>
>>
>>
>> What percentage of web services pass data via XML?
>>
>> A: Bugger all!
>
> JSON is by far most common today.
>
> But XML still happens.
>
> And relative easy to support both with most frameworks
> (declarative).
>
> Arne

Easy "relative" to what??? 2 nights in a Turkish prison?

SOAP is dead!! WS-Trans is dead! Ws-Auth is DEAD!
>
>
>

On 4/18/2022 9:12 PM, Richard Maher wrote:
> On 19/04/2022 7:34 am, Arne Vajhøj wrote:
>> On 4/18/2022 6:56 PM, Richard Maher wrote:
>>> What percentage of web services pass data via XML?
>>>
>>> A: Bugger all!
>>
>> JSON is by far most common today.
>>
>> But XML still happens.
>>
>> And relative easy to support both with most frameworks
>> (declarative).
>
> Easy "relative" to what??? 2 nights in a Turkish prison?
>
> SOAP is dead!! WS-Trans is dead! Ws-Auth is DEAD!

Some SOAP services still exist.

A lot of RESTful services support both XML and JSON.

There may even be some XML-RPC out there still.

Arne