[Info-vax] Free Pascal for VMS ?

[Jan-Erik Söderholm]

Den 2018-05-10 kl. 03:25, skrev Richard Maher:
> On 09-May-18 2:59 PM, Jan-Erik Söderholm wrote:
>> Den 2018-05-09 kl. 04:36, skrev Arne Vajhøj:
>>> On 5/8/2018 8:50 PM, Richard Maher wrote:
>>>> On 08-May-18 11:34 PM, Arne Vajhøj wrote:
>>>>> Software development on VMS definitely need to move to OO.
>>>>>
>>>>> But I don't know if OOifying VMS Pascal is a good thing.
>>>>>
>>>>> I love Pascal as a language, but it is not a language with a great 
>>>>> future ahead.
>>>>>
>>>>> Existing VMS Pascal ported to VMS x86-64 would enable existing
>>>>> Pascal applications to move over.
>>>>>
>>>>> And I believe that port is needed.
>>>>>
>>>>> But I do not see a large number of new OO based applications
>>>>> pick Pascal if VMS Pascal is extended to support Object
>>>>> Pascal.
>>>>>
>>>>> It has not happened on other platforms.
>>>>>
>>>>> FPC is quite popular, but not for new business. For keeping old
>>>>> stuff running and for hobby usage by all those developers
>>>>> growing up with TP/BP/Delphi.
>>>>>
>>>>> And in general I am a bit skeptical about shoehorning new
>>>>> paradigms into old languages - usually new languages designed
>>>>> for the paradigm works better.
>>>>>
>>>>> C++, Java, C#, Kotlin, Scala, Ruby etc. will probably work better than 
>>>>> Object Pascal, Ada 95, OO Cobol etc..
>>>>
>>>> Python, Nodejs should be portable?
>>>
>>> I believe that it does take some work to keep Python running on
>>> VMS. Anyway I see Pythons role on VMS more as scripting than GP
>>> language.
>>>
>>> V8 is not available on VMS as far as I know, so node.js would need
>>> another JS engine. Supposedly it is possible to run node.js on
>>> Rhino and Nashorn, so maybe it will work.
>>>
>>>> But as I said for *many* years getting 3GLs to return JSON data should 
>>>> be the low-hanging fruit. A cross between WASD and Tier3
>>>> would be idyllic.
>>>
>>> If you include JVM languages, CLR languages, PHP etc. as 3GL then many 
>>> of them have it builtin.
>>>
>>> If you mean traditional native procedural languages then some
>>> external library is needed but they exist.
>>>
>>> https://www.json.org/ list libraries for Ada, C and Fortran.
>>>
>>> Most likely one of the C libraries will be possible to use from
>>> Pascal, Basic and Cobol.
>>>
>>> Arne
>>>
>>>
>>
>> In a current project we have a need to interface to a new server
>> that presents some REST APIs using JSON data in and out. Instead of
>> trying to do this from our main Cobol code, we wrote this in Python
>> scripts. Works very well and the development time is rather short and
>> we got Python examples from the server maintainer.
>>
>> The "interface" between the main Cobol code (old applications that gets 
>> some updates) and Python is through tables and triggers in Rdb. The Cobol 
>> code inserts something in a table and a trigger submits a batch job where 
>> the Python processing (doing the REST calls and inserting the result into 
>> Rdb) is done.
>>
>> The alternative would had been to write REST/JSON calls from C using some 
>> library and link that to the Cobol appliations. We think that we
>> got a way shorter develop time by using Python and easier to maintain
>> and test.
>>
>>
> 
> No offense, but I don't think your "interface" should be standardized or 
> recommended by VSI.
> 

Not sure of what "interface" you are refering to. Our Python based
interface? Or the fact that the server designer (out of our control)
selected a REST/JSON interface?

Our solution was the best with the tools at hand. I do not expect this
to become any "standard" from VSI. And even if VSI didn't directly
recommend the solution, they agreed that it was probably the best
given the circumstances.

> I don't know what plug in needs to be written to Apache/WASD to say to run 
> up EXEs in an AppPool rather than Python/PerlCGI but it can't be impossible?

Not sure what you are saying here, or how it relates to our project.
Our VMS system is the client and the REST/JSON server runs on Linux.
How does Apache/WASD help here? There are no calls inbound to VMS.