I've usually thought of GnuCOBOL as a vehicle, to freedoms and re-use of old in the new. In a head space where the COBOL programmers know how to build software from root principles and aren't afraid of computers, languages, and platforms.
The trend has been Modernization for a while now. So maybe the head space should change, modify some assumptions about who GnuCOBOL is being developed for.
I also hold a fair bit of disdain for Cloud. Have since I first heard about it and grifter alarm bells started ringing. That's why the Juju Charm demo only made it to pre-alpha release. The point was proven, and I didn't really want any part of it beyond that.
That was 2014ish, I think. Time has passed, the grifters won. Do we want more press on GnuCOBOL in the Cloud? We have some already, and more with each passing week, but do we put up GnuCOBOL as thee COBOL for virtualization and containers?
It's kinda anti-pro-commercialization. Some few big players get the freebie compiler and run-time, and can earn big dollars not really earned. Free software GnuCOBOL can become more famous. This might be at the expense of some compiler vendor bottom lines, which is a negative, not a positive, in my somewhat ill-defined opinion.
Should GnuCOBOL aim for command line programmers, or clickey clickey coders? I'm pro CLI. If the consensus is more to the clickey clickey and ease of use by devops, it might be worth while setting up more complete kits and demos for the various Clouds.
One nice thing about virtualization is the consistency of platform. Pick one, code to it, using all the nifty features and provide the whole kit and kaboodle per application. If we pick a platform, and code to it, we might be able to produce a pretty slick base, covering all the paradigms of GUI, TUI, CLI, Network and Web, going well beyond what is feasible with cross-platform basics.
But, it'd be in the Cloud, a conman grifter space, in my less ill-defined, baked in opinion.
Thoughts? Is GnuCOBOL worthy of the being the COBOL of Modernization?
Have good, make well,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the subject of modernising GC I have some strong suggestions some of
which I posted in the features report some years back :
1. Allow programs using screen section to use a standard GUI interface
that will work with KDE and Gnome (subject to a setting).
2. Same as 1. but for using a web browser although there might be
issues say when wishing to use Firefox or Chrome etc
More important allow a compile to executable (-x) to generate a
STATIC program with only light usage of steering lines to cobc where
program can be using or not using Storage section and or ISAM files
regardless of variant i.e., BDB, VBISAM etc) although it might mean that
only some can be used if static version of their library are not
available or possible.
This should not need to use the GNU make tool where ever not needed to
stick to the KISS methods.
4. Although the cobc steering commands to use the one's used with
compilers from IBM and Micro Focus to be used where ever possible and if
needed to create new ones where the list of such is not currently in
IBM/MF command sets and shown and listed by command order and by
function order.
From 4. Allow when building the compiler to have pre-built commands
already set up as a site wide set.
From 5. Allow the same from a config file that over rides / in
addition to for project specific changes.
From 6. Allow the same from a Local config file that is present in
the source directory to override setting from 5. and 6.
From 7. Allow the same from within say a $SET on line 1 of a source
file for program specific changes, if any.
5 - 8 will allow usage of abbreviated compiler steering using the IBM /
MF abbreviated format commands
When I was proving out the Juju Charm, I was also working on some "cobweb" (my name for it) core. A command dispatch routine with a field in the command table for CLI, TUI, GUI, Web. The GUI was cobweb-gtk. The Web form used the Broadway backend to automagically route GTK displays to the Browser via backchannel web sockets and translation of the graphic bits. The Periodic Table of Buttons used those features too, as captured in https://gnucobol.sourceforge.io/faq/index.html#redirect-to-browser
Each command could then be directed to CLI, GUI, or Web without changes to the actual COBOL code triggered by the command. TUI is a little different, as it requires changes to COBOL to support the extended ACCEPT/DISPLAY, so the command dispatch pointed to a different entry point.
Just before I dropped everything a few years back, I was keen on AGAR as a possible GUI, and was getting close to trying a few changes to libcob to support GUI transforms from COBOL TUI code, given an environment setting at run-time. I do plan on revisiting libagar and a function repository, and maybe the attempt at libcob changes to support either TUI or GUI from the same COBOL.
When I got back, I noticed the GnuCOBOL reserved word list now included a whole whack of actual COBOL words for GUI use. The run-time is not in, but the words and phrases are recognized. (I think, based on ACUCOBOL-GT graphic word sets).
We should probably pick a GUI and start in on the run-time support for those COBOL words. I'd be keen on Agar as that base, but, GTK offers a lot more not-just-gui features with all the other GNOMEy things. Qt/KDE is also an option, but when I first tried that back in the early 2010s I was faced with C++ linkage issues that seemed more hassle than productive (that view has changed, and GnuCOBOL does just fine integrating with C++).
The Charm work was relatively easy. Mostly simple virtualization, with reproducible image build scripting. That allows focusing on a single platform, using all the available features, and relying on virtual desktop or browser (ala Cloud) for the human interface. Hosted on some Cloud provider space and plopped into those stores as a single click instantiation. I can only assume other Clouds would be similar and simple from the top level view. I ran the lab from a Fedora box, with a LCX container for Ubuntu, which then loaded a local Cloud (more virtualized Ubuntus) to run the whole show over VNC and browser ports. So a little Intel NUC was running a Cloud. Performance was snappy (and that included pulling down a fresh tarball of GnuCOBOL 2 + ReportWriter and building GnuCOBOL inside the instance during the cloud startup, which then compiled some COBOL for use in the demo).
There can be thousands of combinations that would work, but I think it would be sane if we picked ONE combination, and code to it. With all the fancy features, and worrying less about cross-platform. Then, start tooting horns about GnuCOBOL as the Cloud Modernization COBOL. Free software, top to bottom, ready for the world of bullshit, hype, errrm, power that is the Cloud, VNC and browsers.
I haven't looked in any Cloud stores lately, but at the time, I was trying PostgreSQL with Japan's OCESQL pre-processor. It worked beautifully inside a cloud container. I just never extended the demo to include that example, for reasons outlined at the top of this thread. Now I'm thinking it's time to go with the flow, get in on the hype, and cement GnuCOBOL as thee Cloud COBOL. Feature rich free software Cloud COBOL.
Or not. Still leery of Cloud when it comes to extracting rent from people that shouldn't really have to be paying rent. Although, if designed for use in local Clouds, then it'd be up to the customers to decide if they want to self host or punt responsibility to a provider and pay rent.. Hmm, and as far as I know, Hercules with MVS 3.8 and VM/370 works inside Cloud containers too. Could include some mainframey things in this COBOL of the Cloud base package.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And just to be clear, prompted by the comments Simon made on Wish 413 and reading more, this thread was originally meant as a "Should GnuCOBOL be positioned as the COBOL of the Cloud ready for Modernization?", versus "Should GnuCOBOL be modernized?". I've always felt GnuCOBOL was modern, and anyone thinking about porting off rent paying COBOL run-times had viable options. ;-)
We still want to keep enhancing GnuCOBOL potentials inside and out, but this is meant as a market positioning thread. And I'll say, having thought about it a little more since posting; yeah, we should position GnuCOBOL as the future of Cloud ready COBOL, and then plop packages in all the provider spaces. I'm not sure there are that many other COBOL compiler suites that fit the model of free software most people expect[1] in Cloud computing, so we should advertise as such.
Edit for explanation: By packages here I meant something akin to Docker, not just the Debian .deb or Red Hat .rpm packages already in the Cloud as part of the distro repositories available. Something that comes with cobc, gcsort, esql processors, some tasty contrib entries, all built and ready to go after instantiation. Which I still call Charms, as that's the only kind I've tried so far.
I think. It's still the Cloud, and that's still very much wound up in rent paying head spaces, but if we build out a package that can be tested in Local Cloud setups, then the option to pay less rent is still there, and we can still focus on leveraging advanced features provided by a platform (or two maybe). From what I understand, and will look into more is the no rent little clouds that some providers offer for sampling and the whole your first hit is free for thing.
[1] I wrote most people expect, but being historically anti Cloud and only studied the surface I have actually no idea what most people expect from Cloud.
Cheers,
Blue
Last edit: Brian Tiffin 2022-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am firmly in the "Make it compatible with IBM COBOL" camp.
For me to agree or disagree with what you wrote I would need to understand
exactly what change you are proposing.
Having ready to run cloud machines with GnuCOBOL setup with tutorials for
users to use would be helpful.
For instance, having a cloud machine with GnuCOBOL, esql, and Postgres
would be helpful to some.
When someone says "cloud ready" it should mean that their application can
simply scale by adding another cloud machine and if any one of those
machines goes down the "transaction" is retried on a different machine.
If the application does not work like that then they are simply using the
cloud as "Someone Else's Computer".
For me to agree or disagree with what you wrote I would need to understand
exactly what change you are proposing.
That's the thing, Michael, I'm not really proposing any changes, inner changes that is.
The TL;DR is I wasn't planning on many if any changes to GnuCOBOL other than the way I cheerlead, some adverts and coding up a few proof of concept demos with what we already have.
I started the topic because for the last n years, 12 I think now, I've been cheerleading this COBOL as a "normal" developers COBOL Normal, being my own perception of normal. Command line, programmers know how to wield the tools without excessive hand holding, can build software on the machines they use and can use those machines to build big systems. Times changed, or perhaps my perception of what a "normal" programmer is has changed.
Anyway, now in a head space of tooting horns as GnuCOBOL as the COBOL you want to use in the Cloud. Even though I've not yet completely changed perception of Cloud. Cloud is a con game, extracting rent from people that don't know any better on purpose (non-technical types that have other work to do and non-programmer centric businesses) manipulated to think they are better off paying money to some big player than having an expert in the house that knows a little bit of rudimentary system administration. And the data ownership leaks... But I digress. And yeah, it was probably smart of Netflix to use the Cloud when they started, but I count that business as an outlier to the vast majority of IT needs.
Of course waving pom poms will mean actually looking into what current Cloud really is, and getting a sense of what expectations are. I've ignored the entire field completely so far, except for the few days I spent proving out the Juju Charm years ago. What little I did learn of the domain space is that local clouds are easy enough to configure for development and testing. Why would people pay rent when off the shelf server machines and mid tier sysadmins are capable enough for most applications (at the scale I've seen throughout life). But that might flip with a little more learning. Maybe the Cloud has benefits I've missed due to inner bias filters.
And that is just one of the angles of the current marketing hype behind COBOL Modernization. (I still laugh at that a little as sales people tricking other decision makers, but it is what it is). Anyway, seems a lot of decision makers think they benefit from Cloud, so give them a free software COBOL in the Cloud. It's already used that way, but GnuCOBOL is rarely mentioned as the COBOL that is being used, as that might not fit in with Vendor messaging. see the bias? ;-)
Automagic ports to Java is another trend. We can play well in that space too, but it might require a little bit of work with intrinsic functions or new reserved words. Just provide hooks here and there and use COBOL mixed in a JVM system or JVM system mixed in with COBOL. Transforming code is likely the least effective way of doing these kind of rip and replace projects.
Anyway, sorry, Micheal, you apologized for being curt, and I'll apologize for being verbose replying to a little bit of your note. ;-) I'm working through what I think as I type this.
Looking at the rest of your note, and this is still very new to me in terms of details, it might take a little exploring to get a Certified Cloud Ready GnuCOBOL if it means things like auto expansion of storage for VISAM files when a new instance is invoked for temporary up scaling. One thing I'd like to not do is false advertising when it comes to GnuCOBOL capabilities.
For the now, reading the marketing blurbs around COBOL I'm more than willing to stand on a rooftop and proclaim that GnuCOBOL is ready for COBOL Modernization. Maybe that's because I don't know what COBOL Modernization really means when used as a term of art.
It only took a few tens of hours, from zero experience, to getting a Charm that builds GnuCOBOL from source, compiles some demos with a table driven command dispatcher supporting CLI, TUI, GUI, Web. The scripting allowed adding PostgreSQL and lots of other modules with the charm clicky clicky.
and now I'm going to drift into some of the reasons the Charm never got past pre-alpha
I didn't expose that linkage part as I started getting a sense that I was building something that could save corporations bags of money and just automate other developers out of work. I usually try and avoid that part, and just provide starter kits and hints on how to use free software things, then hope and dream that companies will go pay someone to build the specific thing they need with a cool COBOL compiler on POSIX. That thinking is changing with this thread, as I type this, when it comes to putting GnuCOBOL up front and telling it like it is.
Still pondering if that fits with GNU or if mentioning COBOL for the Cloud would be better off on a separate site, with the goal of reserving the primary development site as true to the philosophy.
But I'm seriously sliding to thinking GnuCOBOL needs to be in the Cloud, loudly. We're in the Cloud with all the distros, should maybe just say so on the home page. ?? ?? ;-) And by that I mean loudly. Start in on full colour glossy demos of GnuCOBOL as a COBOL for buzz word compliant Modernization and Cloud.
I'll stop now. This needs some study, but I'm leaning toward thinking that Modernization hype is not counter to the philosophy of free software COBOL.
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am firmly in the "Make it compatible with IBM COBOL" camp.
;-) That's one of the areas where I'd expect a company in need to do the few days of tightening, and then tell us about it for sharing. I get the need, and see the benefits, but it comes down to who has the itch or the urge? It'll only take one key person or team to make it a reality for everybody. It's already really close, no? POSIX vs MVS aside, as that'll take some bridging code, but the COBOL. I'm kinda surprised a shop somewhere hasn't already done this in the open. And also not surprised. ;-)
I might not yet get it, as I've only read a few marketing blurbs so far. Is effort free ports from frames to small tin an expectation when using Modernization as a term of art? Not trying to sound snarky, asking, because if it is, that would mean some changes to cobc and libcob. I'll count myself as green in this area having ignored it on purpose as vendor hype, so what I think I know is likely complete bunk at this point.
On the long side of volunteering, I have taken a few small steps into a pet project for BKNTYM, Back in Time. Hercules, MVS, ANS COBOL 72. Made to work with GnuCOBOL. Then wave pom poms about using 60 year old code mixed in with tomorrow's. BKNTYM is a small set of scripting for now. Job submits to MVS (or VM/370) via Hercules network ports, print output captured and suitable for POSIX pipelines. If I finish the work, then GnuCOBOL will have an ANS 72 mode. But it's an itch, not a need. Satisfying the itch might play well with other people's needs, but there is no timeline or promise. I only mention it, since playing around with 24bit S/370 code that is also compiled with GnuCOBOL might uncover some edge cases.
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...I am firmly in the "Make it compatible with IBM COBOL" camp..."
Having participated in several migrations of mainframe COBOL to the "cloud" I do not believe that GnuCOBOL, using the current GnuCOBOL technology, to be suited to migrate COBOL applications to the Cloud.
Albeit GnuCOBOL as an implementation of the COBOL language is progressing, the infrastructure to support mainframe applications via GnuCOBOL is lacking.
The easiest example is the lack of a SQL preprocessor.
Other issues would be the absence of LE (Language Environment), batch via JCL, JES, CICS, IMS, SDSF, ILC, RACF, 3270 terminal emulation, MQ, several critical IBM utilities, EBCDIC, etc.
The notion that Hercules would be a useful companion to GnuCOBOL is for me a stretch.
Cloud sizing / scaling to meet production demands with ISAM data files is not feasible. ISAM / VSAM does not play well in a cloud environment - SQL is the I-O / DB deployment.
Migration to the cloud in mainframe environments is not solved by a few forward thinking analysts promoting POSIX - it is a major effort requiring extensive analysis, back breaking parallel testing and prayer to the extent that the cloud provider maintains 100 % up time.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good points, and yeah, as I assumed, ports between MVS and POSIX are not expected to be zero effort games. Far from.
Still going to proclaim GnuCOBOL as a Modernization COBOL that is in the Cloud. It's in the Cloud already, but it might not be classed as Cloud Computing COBOL.
On this one:
The easiest example is the lack of a SQL preprocessor.
We have Japan's ESQL for PostgreSQL, Sergey's ODBC friendly version, the processor for the DB2/Express engine, gpre for Firebird, the Oracle layer has been proven to work. Most if not all of these should be available in a modern menu selector for Cloud image builds. I think, having not explored the installer choices in a long long time. I've already tried ocesql with Postgres in a Charm, worked the beauty on the first try. I didn't publish it as part of the demo though, now with a yet...
I'm still trying to figure out what Cloud Ready means as a term of art. I'd back a promotional for GnuCOBOL as Modernization Ready already, but it sounds like overtly advertising GnuCOBOL as Cloud Computing might be a toe over; for now a COBOL for Modernization, that happens to be the free software COBOL offering in the Cloud, that knows how to talk to C and the JVM and SQL and Rexx, and Tcl, and Python, and ... in the Cloud. ;-)
The Hercules angle is bonus. Training potential for the most part. Exposure offered to those that might not have jobs that have accounts on a z box. Even for those with, Hercules offers sysprog privs, access to virtualized mainframe system administration, from device configuration, sysgen, on up to RAKF, TSO and KICKS. Way more educational potential than most humans are ever given a chance to explore in the real world. Some bits of TCP/IP networking included, with emulated S/370 S/390 opcodes allowing hooks into the Hercules host's TCP/IP stack along with some nice use of DIAG instruction subcode exits for access to other host features like file system access. and that is all expanding as volunteers dig in on MVS/CE turnkey systems and expand on the Hercules emulator. MVS Community Edition, with lots of frills and some super smart bored retired system programmers with access to the S/370 assemblers, S/390 features and lots of know how. Moshix already runs an instance of VM/370 running MVS and other guests, which is cloned by others in their Clouds, networked with a Bitnet alternate called HNET, so that's all proven out now too. Much fun to be had, and transferable skills in the end. I like to cheerlead for Hercules, everyone should give it a spin. It's clickey clickey, or as low level as you'd like. The team that ported GCC started out by creating an MVS/380 (there is no 380) for 31bit builds. Building GCC takes more than 24bits. MVS/380 is not recommended for day to day use, but is stable enough to get the tools built for use on solid 24bit MVS. Access to GCC means people are having fun with lots of C free software. I've got a pretty nice Forth (mostly) ported to VM/370 now, and our Dave Pitt's FOCAL implementation runs like a charm.
But, good points, Ralph, might hold off on proclaiming Cloud Computing COBOL, but I'm not going to hold off on proclaiming COBOL for Modernization, in the Cloud. Unless I learn that is not fair use as a term of art. For now, valid marketing in my current but evolving opinion. ;-)
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hope people don't mind, but I'm thinking that this thread can meander a bit, all under Marketing for Programmers and Marketing for Decision Makers umbrellas.
Vince, I noticed this on a re-read...
This should not need to use the GNU make tool where ever not needed to
stick to the KISS methods.
I'd like to understand a little more about what you mean by that. Being a fan of documenting tectonics in the source code.
I often use make as a laze out and how-to reminder tool, compressing long commands to a nickname, and being a reference to read a few months later in terms of incantations.
If there needs to be a huge environment variable override set for run-time, then a bash script comes into play as a nicknamed invoker kinda thing.
Anyway, I find the text in a simple Makefile (the kind mentioned above, a collection of nicknamed builds and runners) as befitting the S in KIS. As much so as a collection of nicknamed shell scripts in a local bin directory.
Am I missing something that kicks make out of the S pile? Or worse, out of the first S pile and into the second?
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brian,
Any comments I "make" here might confuse more than clarify, but since my background as a programmer is primarily in MVS, VM, VSE, RPS, PC-DOS, and Windows, "make" is a complete mystery to me, and the closest IBM analog to it that I can find is "sysgen", which most COBOL application programmers have never heard of.
I use "make" all the time when building GnuCOBOL in MinGW, but I still do not understand it AT ALL. When I run "make", where is the input file that is actually being executed? What is it named? I might have a guess, but sometimes I'm wrong, and there can be more than one input "make" file, but how do I know? It appears to be a script in some kind of programming language, but it's not a programming language I've ever seen before. What is that programming language named and where can I find documentation on it? And what does it mean when I read something like "don't use CMAKE, use gnumake instead"?
When I want to compile a COBOL program I no longer have the MinGW environment. It's difficult and inconvenient to write a long CLI string that begins with "cobc" because it includes a large number of parameters. The cobc command line wraps because it's usually wider than the screen. Sometimes it's three lines long and the continuation is not controlled the same way as in IBM JCL.
So obviously I'm going to create a Windows BAT or CMD script to compile a GnuCOBOL program. I can do that fairly well, but there are exceptional cases where it's hard to make it work like IBM JCL:
Where can I set installation-wide COBOL compile options? (in the default.config file).
Where can I set default COBOL compile options? (in the BAT or CMD script)
How can I set COBOL compile options specifically for the current program? Do I need to create a lot of alternately named compile scripts with embedded options, or allow for additional input parameters in the compile script? And it I do the latter, do I need a table of different cobc command lines, or is there a way to modify or parameterize the cobc command line options?
In IBM COBOL (multiple OS'es and platforms) I can embed COBOL compile time options at the top of the COBOL source program file. But GnuCOBOL doesn't support most of the ones I need. I can understand if the options have different names from IBM, but most options have no analog in GnuCOBOL. This would be for simulating the CBL or PROCESS statements in IBM COBOL.
If I need to statically bind relocatable Assembler, COBOL, or C subprograms, how do I specify the library/subprogram path for each subprogram? This is a trivial issue in IBM JCL, but it's an unsolvable problem with GnuCOBOL in Windows CMD.EXE.
How do I specify a list of three autolink libraries for GnuCOBOL in Windows? This would be for the GCC link step, so is it done in the cobc command or in environment variables? Am I allowed to have more than one autolink library? Because I might need 8 or more.
I can easily believe that all these questions are easy to solve (or don't even arise) using make, but "make" is NOT PART OF WINDOWS. I know "make" exists in MinGW, but it doesn't exist in %Windir% or C:\Windows\System. Where can I get it for CMD.EXE (or Windows 10 TTY), and where can I find documentation on how to use it? Remember, most of the people who download my MinGW GnuCOBOL binaries will not have MinGW, Cygwin, or any access to "make".
If you don't come from Unix style development tools, how will you even know that "make" exists or what it's for?
Please note, nowhere am I saying that "make" is a bad tool. I'm just saying it doesn't EXIST in the COBOL development environments that I am familiar with, particularly Windows, so I don't know where to begin if I want to learn it.
Kind regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Second, I'd was getting an urge to try and explain the contents of Makefile, with target: dependencies and tab indented shell commands that are part of the recipe, but that won't scale very well in terms of Marketing for Programmers. So, more to think about for the rah rah pom pom waving.
For me, make targets are kinda like nicknamed scripts that only do recipes when a dependency triggers the work, but I can see more clearly now that that is a specific knowledge base and not a universal knowledge base, in the same vein as assuming a youngling would be comfortable with JCL. ;-)
Thanks for the note.
Cheers,
Blue
Last edit: Brian Tiffin 2022-02-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Second, I'd was going to try and explain the contents of Makefile,
with |target: dependencies| and tab indented shell commands that are
part of the /recipe/, but that won't scale very well in terms of
Marketing for Programmers. So, more to think about for the rah rah pom
pom waving.
For me, make targets are kinda like nicknamed scripts that only do
recipes when a dependency triggers the work, but I can see more
clearly now that that is a specific knowledge base and not a universal
knowledge base, in the same vein as assuming a youngling would be
comfortable with JCL. ;-)
And? just what is wrong with MVS type JCL as aganst VM or any of the
other variants ??
That's easy compared to playing with make syntax etc as that I find as
really difficult !
There again I am NOT that young :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By comfortable, I kinda meant already exposed to and familiar. I trust any and all to be able to learn a thing. But there are so many things, and each of us only need to learn a few to easily fill more than 25 hours a day. ;-)
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What do people here use when faced with desktop publishing needs? Webpage and PDF targets, not so much actual paper print pages.
Should there be full colour glossies ala Scribus for the Marketing for Decision Makers blurbs? Or LaTeX? Or something more mainstream like LibreOffice?
Should the style used for Decision Makers be similar to the style used for Programmers? I kinda aim to have the Marketing for Programmers more of a technical list, highlights and pain points that might need to be mitigated on a Modernization port to GnuCOBOL. For Decision Makers, the plan was for more straight up advertising and rah rah woo hoo, save money/effort/risk here style. (Without out claiming more than is within potentials).
Unless someone has other suggestions I kinda think this should be limited to choices of (read that as what I used before) any or all of
Scribus
LaTeX or other TeX that plays well with LaTex
LibreOffice
and of course, Sphinx ReStructuredText which is almost a given from this seat.
And I guess the main take away I'd like opinions for is how far to push the Marketing speak as compared to straight up Technical speak? Knowing that at least one of the target audiences is non-technical by nature or simply technically adjacent by trade.
Have good,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My experience of sites and user would be Libreoffice and possibly will Word.
Scribus is only used in special usage case requirements and Latex and
it's mates are just a royal pain to use and debug.based on my experience
for updating the GnuCobol manuals. I have migrated the PG via PDF to
LibreOffice ODT and .DOC formats but it needs more work on it as for
every page it creates new styles for everything. A Nightmare.
Vince
mod edit for some reply-to
Last edit: Brian Tiffin 2022-02-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GnuCobol opens up a door to small business and organizations who want/need customized software and can't afford high compiler prices. Vendors don't care about their bottom line only theirs. Vendor prices are passed on the consumer anyway and that's bad,
The trend is open source and its growing. Vendors will deal with.
The Cloud is a scam and always was. When the cloud is down data is still accessible to hackers and criminals. If you own server/mainframe goes down you are still hosed but you know your data is safe. Why any would put sensitive data near the web isn't serious about security.
Containers: An extra layer of complexity originally designed to protect data that never worked.
Market GNUCobol for what it is. Easy to read and change, full data structure support, index files, screen tui, accurate arithmetic, reusable code etc.. New languages are backing off the OO a bit proving it a failure. Sell it with minimal OO if you want it.
IBM compatibility? Ok. IBM does some great things. VSAM, ISAM, CICS, Operating systems and their greatest achievement PL/I. Nothing has ever come close to it. A lot of IBM'ers out their it can only help.
Have no issues command line, TUI or CGI. I am to this day against GUI. Why? Can't tell how many times I stood in retail lines waiting for a sales people stop playing with the mouse. When I was working for Silo back in the day we used TUI and customers where in and out in no time. A Function/Enter key tap is much quicker and easier. Easier on the programmer too. But all programmers are sold on GUI. So if you want to go GUI route then solve the problem that still exist. Document it well so the programmer does not have to experiment with it. Have it do what the documentation states. Have it clear so that the first attempt is the last. Most GUI documentation is not good. Look at what the Red Language is doing. Keep it simple. Simple is a big plus and selling point. If I'm paying programmers I want code not experimentation.
. Eliminate layers of software. Resources are finite and costly. Don't add layers. Example: GUI: code > wrapper > screen display. Why the wrapper? Screen interface too complicated?
I think GNUCobol could be a big player in the small to medium, medium to large arenas.
Just my opinion.
👍
2
Last edit: Joe Reichart 2022-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks, Joe. I think your and my answers to a tech survey would likely match on almost all if not all points. ;-)
On 7, I'm going to drift a little.
My first real research gig was at the telco when we were first designing the application I spent the goodly portion of my career working on. Had a week to prepare a report on CLI versus GUI (very much pre web, and barely into the days of the internet). Ended up pretty much just regurgitating an ACM SIGCHI report on TAU.
ACM, Association of Computing Machinery
SIGCHI, Special Interest Group, Computer Human Interface
TAU, Temporal Aspects of Usability
GUIs are best for the inexperienced. Pictorial mnemonics, look to find, and "hand holding". Humans do not like being inexperienced in fields of endeavour, and will strive up the first step to a point of basic understanding and a minimal level of expertise. After that minimal level, the impetus can subside as people feel comfortable having learned a thing and no longer count as green.
After that, GUI productivity is quickly outpaced by command lines where people in the know don't need hand holding, know what they want to do, and just want to be able to do it quickly. Keyboard macros and such, automate the repetitive bits and get on with things. GUIs slow that down (for people in the know) and the more the expertise the more time a CLI saves in relation to menus and buttons.
That report put paid to grand schemes some on the management team had about X11 everywhere. ;-) And we got to build a TUI with a command line, with a few DECWindows screens for the tutorials and a few of the help functions. Company only had to buy VT220's for the majority of the technicians and peppered in a few shared graphic work stations for training and other odds and sods.
Then PCs came along, and Windows screens were going to be the next big upgrade to the system. We dusted off the report, and put paid to those arguments too. Yeah, yeah, go ahead and put a PC on everyone's desk, but all they really need for the job at hand is a 220 compatible terminal emulator. ;-) Technicians did not mind. They just wanted to get as many things done in a shift as they could.
A side note on that, from the ACM study, if a machine does not respond within about 0.25 seconds of user action (I'm likely mis-remembering the exact number in the study results), most people will start to think about other things and lose focus on the task at hand. So programmers took up that challenge and kept adding useless eye candy to ensure that systems always respond in slightly over 0.5 seconds, regardless of the exponential chip speed and display technology improvements. ;-)
During one of the cycles of the constant "legacy will suck you dry" chants that management types were always spouting, we were to examine Java for use in a shiny new replacement (those rewrite projects always failed, usually spectacularly). Part of that exercise was using the developer productivity improvement tool, Eclipse. "Boss. It can't even keep up with one finger one thumb typing speeds. This is not going to end well." ;-) It did not.
Thanks for the feedback, Joe.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The command line always works better. Probably why I prefer TUI than GUI. TUI is closer to the command line. I miss those vt220 and the IBM 32xx/52xx terminals. If laptops only had that capability I'd be happy with that . After all - the web really only needed rich text and photos with an upgrade to video, sound and of course speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The last MF COBOL I paid for was around 1992. I think it was Version 6. And I paid lots of money for me, as I was a single developer.
At that time I was using Novell 3.12 (386 400Mhz?) and disk less client computer (286?) booting from Novell via NE200 card or something alike.
At that time Windows 3.xx was barely out, maybe even windows for Workgroups, not sure.
But MF made a simple GUI with simple Windows Textboxes and Labels to display screen sections.
Jus a commandline switch and one could either display a standard text scree or run as GUI under windows.
No Dropdowns, Lists or other fancy stuff, just Labels for text and textboxes for accept.
Sure you had to fiddle around to have the screen looking somehow alike regards to positioning because it basically calculated the GUI position out of the non proportional Screen Section Character positions, but it worked very well to have some windows looking Dialog instead of a CMD Text window.
And that is the way GNU COBOL should go. Not Java, Agar, full blown Web Interface just another display layer providing standard Screen Section in a different visual form.
No 'call xxx using blabla' to display a input box on a screen you created with 'call zzz using blabla returning Hwind and blabla'.
This is not COBOL. This is calling other languages and leaving the COBOL space.
And this is simply wrong.
The correct way to go would be to put some sort of common interface using - well- the basic usage of extended screen io now possible with curses or pdcurses on say CGI or GTK (runs nicly on Windows Mac and Linux) and NO changes in source needed.
Just CORRECTLY display Screen Sections in a halfways sane manner.
And well fixing the editing of numeric fields in extended IO. That is really bad currently with workarounds to move back and forth between Screen Items and Working storage items.
The goal should always be to compile a UNCHANGED source using standard Screen Sections to display and accept in text mode and GUI mode.
Not to get all the fancy web stuff in. Not to get all the fancy Linux Windows and Mac controls in.
Just Labels and Texboxes with correct behavior and common sensible position based on Screen Section character positions.
Just my two cents.
Mike
.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, Mike. This seems to be working out nicely, with all the angles of what programmers expect from a COBOL.
Awesome.
Yeah, there is a wrinkle to making a dual mode screen section. Windows vendors have a platform to code to, a known (and fixed for the entire customer base) set of graphic APIs. The run-time has a single if to deal with for TUI or GUI (overly simplified). For Windows and Mac, now it's two ifs.
There is also the pending Graphic COBOL reserved word extensions in the cobc tree.
For POSIX it's umm, not fixed, so not known. Can be raw X11 to cover a lot of customers in this smaller pool, but X11 in base form is down right unslick, And would be complicated looking when part of the libcob C code base. Most second layer GUI frameworks are based on X11, but not all. Then we get into an explosion of ifs for GTK/GNOME, Qt/KDE, Tk, Agar, ....... a subsystem that is usually picked by the customer's choice of desktop.
We have a fair start on GTK. The code techniques that implements the function repository contribution could fairly easily get lifted and smoothed into libcob. I gave up chasing the GNOME team, as they were burned bridge racing while I was learning, and I got into a backtrack and retrofit cycle, while learning. Got sulky and looked elsewhere for a stable API with stable docs. :-) Years have passed, they may have already burned down all the bridges they are going to burn down. I'm pretty sure that addition of the CSS layer for theming, could get cobweb-gtk into a reasonable state again. That was the straw for me, couldn't change the colour of a button without using a CSS form in the lowlevel API. Deprecated the setters/getters. Weenies. ;-)
Found Agar. Not a great choice when looking to cover the pre-installed customer base. Fractions of fractions. But, sweet. Not overly fancy. A definite step up from raw X11, but not as polished looking as most. There is frame buffer code, doesn't need a window manager at all, just SDL OpenGL drivers. Which is not a given install either, but it's getting fairly ubiquitous if I'm not mistaken. The Agar frame buffer calls are fixed size fonts and positioning, port to dual mode SCREEN SECTION would be the easiest to implement in my current opinion. Support for the new graphic extension words that are in the works would be middling to hard hard to implement though. Perhaps not slick enough when slicker is available, and effort would be similar? Agar screens feel a little more mainframey to me, which is not a negative. ;-)
W have to choose from the combinations of possibilities. I tried the X11 driver for PDCurses, but that just puts the TUI in a wrapped window frame. Still looks like a TUI in a terminal, not a GUI form.
We can do so in libcob, given a target. Hard slog to cover too many. GTK is probably the sanest choice when it comes to customer base, both for a dual mode SCREEN SECTION code and for the new words, like WINDOW, BUTTON, BITMAP. 100s of words awaiting run-time support. But that all needs a graphic API to code to. Again, even though I gave up a while ago, I'd still probably vote GTK for the API. Agar, can be an optional for people that want to write games or CAD systems, left as a really nifty powerful function repository. With GTK we'd get Broadway as a backend, and that could mean Cloud via graphics in the browser powers, no code changes (umm, once the graphic words get some support in libcob that is).
Can't speak to timelines, Mike, but dual mode SCREEN SECTION is in the works, in the thinking about it works at least. The graphic COBOL words will need a target too, should be the same one.
And yes, we need to fix binary numeric field entry in SCREEN SECTION. It really just needs to call cob_move code behind the scenes to get proper display usage to internal storage forms, I think. Better, I've been pestering for someone to try and take a kick at true PICTURE edits in the TUI. No takers over the last 10 years-ish, since Roger gave us the alpha cut of SCREEN SECTION. Of course, we've had the crappy version of DISPLAY form numerics for a while now, and we'd need a USAGE-DISPLAY-NUMERIC-SCREENS compiler build flag to fix this now, or risk breaking code in the wild. :-)
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You forgot FORMS and I think the version of MF was Workbench v3.4 or
around that version as thats the one I had that earlier releases relied
on a dongle at least up to the point when I needed it to run on a secure
system that did not have serial or parallel ports so got a non-dongled
version of v3.4 or so.
That is not to say that FORMS and DIALOG did not have there share of
issues :)
Hmm, still have some of the manuals in a cupboard and still use the A6
pocket guide dated April 93 v6 for DOS, Windows and OS/2.
Vince
mod edit for some reply-to
Last edit: Brian Tiffin 2022-02-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
COBOL to be successful has to bet on SQL (ISAM is outdated, doesn't work on the web, it's not ACID, etc...), and the GUI !!!! The modern world is visual, I respect the opinions of the old guard, but the world has changed... it has changed a lot. I programmed in Icobol with GUI/TUI with the same code, but the results were not brilliant. Later I programmed with MF+Dialog System - a terrible desperation. Fujitsu's Powercobol was excellent as a GUI tool, unfortunately it's not opensource, it was based on a technology that was killed by Microsoft (Activex), but it was an opportunity to bring new blood to Cobol. Currently in Europe nobody knows Cobol, there are no programmers and it is usually wrongly seen as something for old people, and for outdated technologies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, Paulo. Those are bang on point points, in my opinion.
They don't really match the inner child desires I have had for this free software COBOL (a world where people just keep COBOL treasure piles, link to all the new funky things with intelligently placed, surgical precision hooks and compile new binaries). :-)
I'm in Ottawa, Canada, the civil service here is still very much a COBOL customer, which spills over into the private sectors supporting the civil services.
This pondering about Marketing GnuCOBOL is splintering into a few main branches for me. Marketing to Home Programmers, Marketing to SME Programmers, to Large Enterprise, to Mainframe Programmers, and Marketing to Decision Makers that support those programmers (the first and second camp may be the same persons). Not just one full colour glossy, but six or eight or more.
For blatant Modernization Marketing materials, GnuCOBOL might need some changes, and/or backing support layers before the envisioned adverts would be reasonably universal and worthy.
GnuCOBOL is modern COBOL, always has been. But maybe it's not quite ready for meeting reasonable expectations for, or stamping as, a Modernization COBOL, as a term of art. Still pondering, and trying to avoid inner bias desires and beliefs that may not match the general consensus of the reality. ;-)
Have good, make well,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to throw this out there and do with it what you will.
In the last couple of months alone thousands of people have literally dumped their windows boxes in favor of Linux(Android and Apple phones are in the mix now too).. I think people are starting see that the tech products they use was not built for them but the companies themselves. People are starting to see the two sets of rules. One for them and one for big tech. I expect this trend to continue. I believe over the next couple of years or so Microsoft will lose it dominance over the desktop. MS knows this and will try to stop it but as the same time will make moves in different direction as they have been doing. There real problem is credibility and I don't think they will be able to fix it.
So whatever you do with GnuCobol Windows is not the future. Too much effort in that direction may just go to waste.
I'm not asking you to believe me. Do your own research.
👍
1
Last edit: Joe Reichart 2022-02-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mickey's recent news links got me thinking.
I've usually thought of GnuCOBOL as a vehicle, to freedoms and re-use of old in the new. In a head space where the COBOL programmers know how to build software from root principles and aren't afraid of computers, languages, and platforms.
The trend has been Modernization for a while now. So maybe the head space should change, modify some assumptions about who GnuCOBOL is being developed for.
I also hold a fair bit of disdain for Cloud. Have since I first heard about it and grifter alarm bells started ringing. That's why the Juju Charm demo only made it to pre-alpha release. The point was proven, and I didn't really want any part of it beyond that.
That was 2014ish, I think. Time has passed, the grifters won. Do we want more press on GnuCOBOL in the Cloud? We have some already, and more with each passing week, but do we put up GnuCOBOL as thee COBOL for virtualization and containers?
It's kinda anti-pro-commercialization. Some few big players get the freebie compiler and run-time, and can earn big dollars not really earned. Free software GnuCOBOL can become more famous. This might be at the expense of some compiler vendor bottom lines, which is a negative, not a positive, in my somewhat ill-defined opinion.
Should GnuCOBOL aim for command line programmers, or clickey clickey coders? I'm pro CLI. If the consensus is more to the clickey clickey and ease of use by devops, it might be worth while setting up more complete kits and demos for the various Clouds.
One nice thing about virtualization is the consistency of platform. Pick one, code to it, using all the nifty features and provide the whole kit and kaboodle per application. If we pick a platform, and code to it, we might be able to produce a pretty slick base, covering all the paradigms of GUI, TUI, CLI, Network and Web, going well beyond what is feasible with cross-platform basics.
But, it'd be in the Cloud, a conman grifter space, in my less ill-defined, baked in opinion.
Thoughts? Is GnuCOBOL worthy of the being the COBOL of Modernization?
Have good, make well,
Blue
On the subject of modernising GC I have some strong suggestions some of
which I posted in the features report some years back :
1. Allow programs using screen section to use a standard GUI interface
that will work with KDE and Gnome (subject to a setting).
2. Same as 1. but for using a web browser although there might be
issues say when wishing to use Firefox or Chrome etc
STATIC program with only light usage of steering lines to cobc where
program can be using or not using Storage section and or ISAM files
regardless of variant i.e., BDB, VBISAM etc) although it might mean that
only some can be used if static version of their library are not
available or possible.
This should not need to use the GNU make tool where ever not needed to
stick to the KISS methods.
4. Although the cobc steering commands to use the one's used with
compilers from IBM and Micro Focus to be used where ever possible and if
needed to create new ones where the list of such is not currently in
IBM/MF command sets and shown and listed by command order and by
function order.
From 4. Allow when building the compiler to have pre-built commands
already set up as a site wide set.
From 5. Allow the same from a config file that over rides / in
addition to for project specific changes.
From 6. Allow the same from a Local config file that is present in
the source directory to override setting from 5. and 6.
From 7. Allow the same from within say a $SET on line 1 of a source
file for program specific changes, if any.
5 - 8 will allow usage of abbreviated compiler steering using the IBM /
MF abbreviated format commands
Will that be enough for getting on with ?
Vincent
mod edit for some reply-to - and reference added to [feature-requests:#413]
Related
Wish List: #413
Last edit: Simon Sobisch 2022-02-10
Thanks, Vince. Nice feedback.
When I was proving out the Juju Charm, I was also working on some "cobweb" (my name for it) core. A command dispatch routine with a field in the command table for CLI, TUI, GUI, Web. The GUI was cobweb-gtk. The Web form used the Broadway backend to automagically route GTK displays to the Browser via backchannel web sockets and translation of the graphic bits. The Periodic Table of Buttons used those features too, as captured in https://gnucobol.sourceforge.io/faq/index.html#redirect-to-browser
Each command could then be directed to CLI, GUI, or Web without changes to the actual COBOL code triggered by the command. TUI is a little different, as it requires changes to COBOL to support the extended ACCEPT/DISPLAY, so the command dispatch pointed to a different entry point.
Just before I dropped everything a few years back, I was keen on AGAR as a possible GUI, and was getting close to trying a few changes to libcob to support GUI transforms from COBOL TUI code, given an environment setting at run-time. I do plan on revisiting libagar and a function repository, and maybe the attempt at libcob changes to support either TUI or GUI from the same COBOL.
When I got back, I noticed the GnuCOBOL reserved word list now included a whole whack of actual COBOL words for GUI use. The run-time is not in, but the words and phrases are recognized. (I think, based on ACUCOBOL-GT graphic word sets).
We should probably pick a GUI and start in on the run-time support for those COBOL words. I'd be keen on Agar as that base, but, GTK offers a lot more not-just-gui features with all the other GNOMEy things. Qt/KDE is also an option, but when I first tried that back in the early 2010s I was faced with C++ linkage issues that seemed more hassle than productive (that view has changed, and GnuCOBOL does just fine integrating with C++).
The Charm work was relatively easy. Mostly simple virtualization, with reproducible image build scripting. That allows focusing on a single platform, using all the available features, and relying on virtual desktop or browser (ala Cloud) for the human interface. Hosted on some Cloud provider space and plopped into those stores as a single click instantiation. I can only assume other Clouds would be similar and simple from the top level view. I ran the lab from a Fedora box, with a LCX container for Ubuntu, which then loaded a local Cloud (more virtualized Ubuntus) to run the whole show over VNC and browser ports. So a little Intel NUC was running a Cloud. Performance was snappy (and that included pulling down a fresh tarball of GnuCOBOL 2 + ReportWriter and building GnuCOBOL inside the instance during the cloud startup, which then compiled some COBOL for use in the demo).
There can be thousands of combinations that would work, but I think it would be sane if we picked ONE combination, and code to it. With all the fancy features, and worrying less about cross-platform. Then, start tooting horns about GnuCOBOL as the Cloud Modernization COBOL. Free software, top to bottom, ready for the world of
bullshit,hype, errrm, power that is the Cloud, VNC and browsers.I haven't looked in any Cloud stores lately, but at the time, I was trying PostgreSQL with Japan's OCESQL pre-processor. It worked beautifully inside a cloud container. I just never extended the demo to include that example, for reasons outlined at the top of this thread. Now I'm thinking it's time to go with the flow, get in on the hype, and cement GnuCOBOL as thee Cloud COBOL. Feature rich free software Cloud COBOL.
Or not. Still leery of Cloud when it comes to extracting rent from people that shouldn't really have to be paying rent. Although, if designed for use in local Clouds, then it'd be up to the customers to decide if they want to self host or punt responsibility to a provider and pay rent.. Hmm, and as far as I know, Hercules with MVS 3.8 and VM/370 works inside Cloud containers too. Could include some mainframey things in this COBOL of the Cloud base package.
Cheers,
Blue
And just to be clear, prompted by the comments Simon made on Wish 413 and reading more, this thread was originally meant as a "Should GnuCOBOL be positioned as the COBOL of the Cloud ready for Modernization?", versus "Should GnuCOBOL be modernized?". I've always felt GnuCOBOL was modern, and anyone thinking about porting off rent paying COBOL run-times had viable options. ;-)
We still want to keep enhancing GnuCOBOL potentials inside and out, but this is meant as a market positioning thread. And I'll say, having thought about it a little more since posting; yeah, we should position GnuCOBOL as the future of Cloud ready COBOL, and then plop packages in all the provider spaces. I'm not sure there are that many other COBOL compiler suites that fit the model of free software most people expect[1] in Cloud computing, so we should advertise as such.
Edit for explanation: By packages here I meant something akin to Docker, not just the Debian .deb or Red Hat .rpm packages already in the Cloud as part of the distro repositories available. Something that comes with cobc, gcsort, esql processors, some tasty contrib entries, all built and ready to go after instantiation. Which I still call Charms, as that's the only kind I've tried so far.
I think. It's still the Cloud, and that's still very much wound up in rent paying head spaces, but if we build out a package that can be tested in Local Cloud setups, then the option to pay less rent is still there, and we can still focus on leveraging advanced features provided by a platform (or two maybe). From what I understand, and will look into more is the no rent little clouds that some providers offer for sampling and the whole your first hit is free for thing.
[1] I wrote most people expect, but being historically anti Cloud and only studied the surface I have actually no idea what most people expect from Cloud.
Cheers,
Blue
Last edit: Brian Tiffin 2022-02-11
Quick Reply; Excuse the Curtness.
I am firmly in the "Make it compatible with IBM COBOL" camp.
For me to agree or disagree with what you wrote I would need to understand
exactly what change you are proposing.
Having ready to run cloud machines with GnuCOBOL setup with tutorials for
users to use would be helpful.
For instance, having a cloud machine with GnuCOBOL, esql, and Postgres
would be helpful to some.
When someone says "cloud ready" it should mean that their application can
simply scale by adding another cloud machine and if any one of those
machines goes down the "transaction" is retried on a different machine.
If the application does not work like that then they are simply using the
cloud as "Someone Else's Computer".
Mod edit for some reply-to
Last edit: Brian Tiffin 2022-02-10
:-)
That's the thing, Michael, I'm not really proposing any changes, inner changes that is.
The TL;DR is I wasn't planning on many if any changes to GnuCOBOL other than the way I cheerlead, some adverts and coding up a few proof of concept demos with what we already have.
I started the topic because for the last n years, 12 I think now, I've been cheerleading this COBOL as a "normal" developers COBOL Normal, being my own perception of normal. Command line, programmers know how to wield the tools without excessive hand holding, can build software on the machines they use and can use those machines to build big systems. Times changed, or perhaps my perception of what a "normal" programmer is has changed.
Anyway, now in a head space of tooting horns as GnuCOBOL as the COBOL you want to use in the Cloud. Even though I've not yet completely changed perception of Cloud. Cloud is a con game, extracting rent from people that don't know any better on purpose (non-technical types that have other work to do and non-programmer centric businesses) manipulated to think they are better off paying money to some big player than having an expert in the house that knows a little bit of rudimentary system administration. And the data ownership leaks... But I digress. And yeah, it was probably smart of Netflix to use the Cloud when they started, but I count that business as an outlier to the vast majority of IT needs.
Of course waving pom poms will mean actually looking into what current Cloud really is, and getting a sense of what expectations are. I've ignored the entire field completely so far, except for the few days I spent proving out the Juju Charm years ago. What little I did learn of the domain space is that local clouds are easy enough to configure for development and testing. Why would people pay rent when off the shelf server machines and mid tier sysadmins are capable enough for most applications (at the scale I've seen throughout life). But that might flip with a little more learning. Maybe the Cloud has benefits I've missed due to inner bias filters.
And that is just one of the angles of the current marketing hype behind COBOL Modernization. (I still laugh at that a little as sales people tricking other decision makers, but it is what it is). Anyway, seems a lot of decision makers think they benefit from Cloud, so give them a free software COBOL in the Cloud. It's already used that way, but GnuCOBOL is rarely mentioned as the COBOL that is being used, as that might not fit in with Vendor messaging. see the bias? ;-)
Automagic ports to Java is another trend. We can play well in that space too, but it might require a little bit of work with intrinsic functions or new reserved words. Just provide hooks here and there and use COBOL mixed in a JVM system or JVM system mixed in with COBOL. Transforming code is likely the least effective way of doing these kind of rip and replace projects.
Anyway, sorry, Micheal, you apologized for being curt, and I'll apologize for being verbose replying to a little bit of your note. ;-) I'm working through what I think as I type this.
Looking at the rest of your note, and this is still very new to me in terms of details, it might take a little exploring to get a Certified Cloud Ready GnuCOBOL if it means things like auto expansion of storage for VISAM files when a new instance is invoked for temporary up scaling. One thing I'd like to not do is false advertising when it comes to GnuCOBOL capabilities.
For the now, reading the marketing blurbs around COBOL I'm more than willing to stand on a rooftop and proclaim that GnuCOBOL is ready for COBOL Modernization. Maybe that's because I don't know what COBOL Modernization really means when used as a term of art.
It only took a few tens of hours, from zero experience, to getting a Charm that builds GnuCOBOL from source, compiles some demos with a table driven command dispatcher supporting CLI, TUI, GUI, Web. The scripting allowed adding PostgreSQL and lots of other modules with the charm clicky clicky.
and now I'm going to drift into some of the reasons the Charm never got past pre-alpha
I didn't expose that linkage part as I started getting a sense that I was building something that could save corporations bags of money and just automate other developers out of work. I usually try and avoid that part, and just provide starter kits and hints on how to use free software things, then hope and dream that companies will go pay someone to build the specific thing they need with a cool COBOL compiler on POSIX. That thinking is changing with this thread, as I type this, when it comes to putting GnuCOBOL up front and telling it like it is.
Still pondering if that fits with GNU or if mentioning COBOL for the Cloud would be better off on a separate site, with the goal of reserving the primary development site as true to the philosophy.
But I'm seriously sliding to thinking GnuCOBOL needs to be in the Cloud, loudly. We're in the Cloud with all the distros, should maybe just say so on the home page. ?? ?? ;-) And by that I mean loudly. Start in on full colour glossy demos of GnuCOBOL as a COBOL for buzz word compliant Modernization and Cloud.
I'll stop now. This needs some study, but I'm leaning toward thinking that Modernization hype is not counter to the philosophy of free software COBOL.
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-11
On another angle...
;-) That's one of the areas where I'd expect a company in need to do the few days of tightening, and then tell us about it for sharing. I get the need, and see the benefits, but it comes down to who has the itch or the urge? It'll only take one key person or team to make it a reality for everybody. It's already really close, no? POSIX vs MVS aside, as that'll take some bridging code, but the COBOL. I'm kinda surprised a shop somewhere hasn't already done this in the open. And also not surprised. ;-)
I might not yet get it, as I've only read a few marketing blurbs so far. Is effort free ports from frames to small tin an expectation when using Modernization as a term of art? Not trying to sound snarky, asking, because if it is, that would mean some changes to cobc and libcob. I'll count myself as green in this area having ignored it on purpose as vendor hype, so what I think I know is likely complete bunk at this point.
On the long side of volunteering, I have taken a few small steps into a pet project for BKNTYM, Back in Time. Hercules, MVS, ANS COBOL 72. Made to work with GnuCOBOL. Then wave pom poms about using 60 year old code mixed in with tomorrow's. BKNTYM is a small set of scripting for now. Job submits to MVS (or VM/370) via Hercules network ports, print output captured and suitable for POSIX pipelines. If I finish the work, then GnuCOBOL will have an ANS 72 mode. But it's an itch, not a need. Satisfying the itch might play well with other people's needs, but there is no timeline or promise. I only mention it, since playing around with 24bit S/370 code that is also compiled with GnuCOBOL might uncover some edge cases.
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-11
"...I am firmly in the "Make it compatible with IBM COBOL" camp..."
Having participated in several migrations of mainframe COBOL to the "cloud" I do not believe that GnuCOBOL, using the current GnuCOBOL technology, to be suited to migrate COBOL applications to the Cloud.
Albeit GnuCOBOL as an implementation of the COBOL language is progressing, the infrastructure to support mainframe applications via GnuCOBOL is lacking.
The easiest example is the lack of a SQL preprocessor.
Other issues would be the absence of LE (Language Environment), batch via JCL, JES, CICS, IMS, SDSF, ILC, RACF, 3270 terminal emulation, MQ, several critical IBM utilities, EBCDIC, etc.
The notion that Hercules would be a useful companion to GnuCOBOL is for me a stretch.
Cloud sizing / scaling to meet production demands with ISAM data files is not feasible. ISAM / VSAM does not play well in a cloud environment - SQL is the I-O / DB deployment.
Migration to the cloud in mainframe environments is not solved by a few forward thinking analysts promoting POSIX - it is a major effort requiring extensive analysis, back breaking parallel testing and prayer to the extent that the cloud provider maintains 100 % up time.
Ralph
Good points, and yeah, as I assumed, ports between MVS and POSIX are not expected to be zero effort games. Far from.
Still going to proclaim GnuCOBOL as a Modernization COBOL that is in the Cloud. It's in the Cloud already, but it might not be classed as Cloud Computing COBOL.
On this one:
We have Japan's ESQL for PostgreSQL, Sergey's ODBC friendly version, the processor for the DB2/Express engine, gpre for Firebird, the Oracle layer has been proven to work. Most if not all of these should be available in a modern menu selector for Cloud image builds. I think, having not explored the installer choices in a long long time. I've already tried ocesql with Postgres in a Charm, worked the beauty on the first try. I didn't publish it as part of the demo though, now with a yet...
I'm still trying to figure out what Cloud Ready means as a term of art. I'd back a promotional for GnuCOBOL as Modernization Ready already, but it sounds like overtly advertising GnuCOBOL as Cloud Computing might be a toe over; for now a COBOL for Modernization, that happens to be the free software COBOL offering in the Cloud, that knows how to talk to C and the JVM and SQL and Rexx, and Tcl, and Python, and ... in the Cloud. ;-)
The Hercules angle is bonus. Training potential for the most part. Exposure offered to those that might not have jobs that have accounts on a z box. Even for those with, Hercules offers sysprog privs, access to virtualized mainframe system administration, from device configuration, sysgen, on up to RAKF, TSO and KICKS. Way more educational potential than most humans are ever given a chance to explore in the real world. Some bits of TCP/IP networking included, with emulated S/370 S/390 opcodes allowing hooks into the Hercules host's TCP/IP stack along with some nice use of DIAG instruction subcode exits for access to other host features like file system access. and that is all expanding as volunteers dig in on MVS/CE turnkey systems and expand on the Hercules emulator. MVS Community Edition, with lots of frills and some super smart bored retired system programmers with access to the S/370 assemblers, S/390 features and lots of know how. Moshix already runs an instance of VM/370 running MVS and other guests, which is cloned by others in their Clouds, networked with a Bitnet alternate called HNET, so that's all proven out now too. Much fun to be had, and transferable skills in the end. I like to cheerlead for Hercules, everyone should give it a spin. It's clickey clickey, or as low level as you'd like. The team that ported GCC started out by creating an MVS/380 (there is no 380) for 31bit builds. Building GCC takes more than 24bits. MVS/380 is not recommended for day to day use, but is stable enough to get the tools built for use on solid 24bit MVS. Access to GCC means people are having fun with lots of C free software. I've got a pretty nice Forth (mostly) ported to VM/370 now, and our Dave Pitt's FOCAL implementation runs like a charm.
But, good points, Ralph, might hold off on proclaiming Cloud Computing COBOL, but I'm not going to hold off on proclaiming COBOL for Modernization, in the Cloud. Unless I learn that is not fair use as a term of art. For now, valid marketing in my current but evolving opinion. ;-)
Have good, make well,
Blue
Last edit: Brian Tiffin 2022-02-12
I hope people don't mind, but I'm thinking that this thread can meander a bit, all under Marketing for Programmers and Marketing for Decision Makers umbrellas.
Vince, I noticed this on a re-read...
I'd like to understand a little more about what you mean by that. Being a fan of documenting tectonics in the source code.
I often use
makeas a laze out and how-to reminder tool, compressing long commands to a nickname, and being a reference to read a few months later in terms of incantations.If there needs to be a huge environment variable override set for run-time, then a bash script comes into play as a nicknamed invoker kinda thing.
Anyway, I find the text in a simple Makefile (the kind mentioned above, a collection of nicknamed builds and runners) as befitting the S in KIS. As much so as a collection of nicknamed shell scripts in a local bin directory.
Am I missing something that kicks
makeout of the S pile? Or worse, out of the first S pile and into the second?Cheers,
Blue
Brian,
Any comments I "make" here might confuse more than clarify, but since my background as a programmer is primarily in MVS, VM, VSE, RPS, PC-DOS, and Windows, "make" is a complete mystery to me, and the closest IBM analog to it that I can find is "sysgen", which most COBOL application programmers have never heard of.
I use "make" all the time when building GnuCOBOL in MinGW, but I still do not understand it AT ALL. When I run "make", where is the input file that is actually being executed? What is it named? I might have a guess, but sometimes I'm wrong, and there can be more than one input "make" file, but how do I know? It appears to be a script in some kind of programming language, but it's not a programming language I've ever seen before. What is that programming language named and where can I find documentation on it? And what does it mean when I read something like "don't use CMAKE, use gnumake instead"?
When I want to compile a COBOL program I no longer have the MinGW environment. It's difficult and inconvenient to write a long CLI string that begins with "cobc" because it includes a large number of parameters. The cobc command line wraps because it's usually wider than the screen. Sometimes it's three lines long and the continuation is not controlled the same way as in IBM JCL.
So obviously I'm going to create a Windows BAT or CMD script to compile a GnuCOBOL program. I can do that fairly well, but there are exceptional cases where it's hard to make it work like IBM JCL:
I can easily believe that all these questions are easy to solve (or don't even arise) using make, but "make" is NOT PART OF WINDOWS. I know "make" exists in MinGW, but it doesn't exist in %Windir% or C:\Windows\System. Where can I get it for CMD.EXE (or Windows 10 TTY), and where can I find documentation on how to use it? Remember, most of the people who download my MinGW GnuCOBOL binaries will not have MinGW, Cygwin, or any access to "make".
If you don't come from Unix style development tools, how will you even know that "make" exists or what it's for?
Please note, nowhere am I saying that "make" is a bad tool. I'm just saying it doesn't EXIST in the COBOL development environments that I am familiar with, particularly Windows, so I don't know where to begin if I want to learn it.
Kind regards,
First, that was utterly clarifying, Arnold. ;-)
Second, I'd was getting an urge to try and explain the contents of Makefile, with
target: dependenciesand tab indented shell commands that are part of the recipe, but that won't scale very well in terms of Marketing for Programmers. So, more to think about for the rah rah pom pom waving.For me, make targets are kinda like nicknamed scripts that only do recipes when a dependency triggers the work, but I can see more clearly now that that is a specific knowledge base and not a universal knowledge base, in the same vein as assuming a youngling would be comfortable with JCL. ;-)
Thanks for the note.
Cheers,
Blue
Last edit: Brian Tiffin 2022-02-14
On 13/02/2022 16:30, Brian Tiffin wrote:
That's easy compared to playing with make syntax etc as that I find as
really difficult !
There again I am NOT that young :)
And, just to clarify a meaning. :-)
By comfortable, I kinda meant already exposed to and familiar. I trust any and all to be able to learn a thing. But there are so many things, and each of us only need to learn a few to easily fill more than 25 hours a day. ;-)
Cheers,
Blue
Splitting off a another drift, hopefully short.
What do people here use when faced with desktop publishing needs? Webpage and PDF targets, not so much actual paper print pages.
Should there be full colour glossies ala Scribus for the Marketing for Decision Makers blurbs? Or LaTeX? Or something more mainstream like LibreOffice?
Should the style used for Decision Makers be similar to the style used for Programmers? I kinda aim to have the Marketing for Programmers more of a technical list, highlights and pain points that might need to be mitigated on a Modernization port to GnuCOBOL. For Decision Makers, the plan was for more straight up advertising and rah rah woo hoo, save money/effort/risk here style. (Without out claiming more than is within potentials).
Unless someone has other suggestions I kinda think this should be limited to choices of (read that as what I used before) any or all of
And I guess the main take away I'd like opinions for is how far to push the Marketing speak as compared to straight up Technical speak? Knowing that at least one of the target audiences is non-technical by nature or simply technically adjacent by trade.
Have good,
Blue
My experience of sites and user would be Libreoffice and possibly will Word.
Scribus is only used in special usage case requirements and Latex and
it's mates are just a royal pain to use and debug.based on my experience
for updating the GnuCobol manuals. I have migrated the PG via PDF to
LibreOffice ODT and .DOC formats but it needs more work on it as for
every page it creates new styles for everything. A Nightmare.
Vince
mod edit for some reply-to
Last edit: Brian Tiffin 2022-02-14
Interesting...
I think GNUCobol could be a big player in the small to medium, medium to large arenas.
Just my opinion.
Last edit: Joe Reichart 2022-02-11
Many thanks, Joe. I think your and my answers to a tech survey would likely match on almost all if not all points. ;-)
On 7, I'm going to drift a little.
My first real research gig was at the telco when we were first designing the application I spent the goodly portion of my career working on. Had a week to prepare a report on CLI versus GUI (very much pre web, and barely into the days of the internet). Ended up pretty much just regurgitating an ACM SIGCHI report on TAU.
GUIs are best for the inexperienced. Pictorial mnemonics, look to find, and "hand holding". Humans do not like being inexperienced in fields of endeavour, and will strive up the first step to a point of basic understanding and a minimal level of expertise. After that minimal level, the impetus can subside as people feel comfortable having learned a thing and no longer count as green.
After that, GUI productivity is quickly outpaced by command lines where people in the know don't need hand holding, know what they want to do, and just want to be able to do it quickly. Keyboard macros and such, automate the repetitive bits and get on with things. GUIs slow that down (for people in the know) and the more the expertise the more time a CLI saves in relation to menus and buttons.
That report put paid to grand schemes some on the management team had about X11 everywhere. ;-) And we got to build a TUI with a command line, with a few DECWindows screens for the tutorials and a few of the help functions. Company only had to buy VT220's for the majority of the technicians and peppered in a few shared graphic work stations for training and other odds and sods.
Then PCs came along, and Windows screens were going to be the next big upgrade to the system. We dusted off the report, and put paid to those arguments too. Yeah, yeah, go ahead and put a PC on everyone's desk, but all they really need for the job at hand is a 220 compatible terminal emulator. ;-) Technicians did not mind. They just wanted to get as many things done in a shift as they could.
A side note on that, from the ACM study, if a machine does not respond within about 0.25 seconds of user action (I'm likely mis-remembering the exact number in the study results), most people will start to think about other things and lose focus on the task at hand. So programmers took up that challenge and kept adding useless eye candy to ensure that systems always respond in slightly over 0.5 seconds, regardless of the exponential chip speed and display technology improvements. ;-)
During one of the cycles of the constant "legacy will suck you dry" chants that management types were always spouting, we were to examine Java for use in a shiny new replacement (those rewrite projects always failed, usually spectacularly). Part of that exercise was using the developer productivity improvement tool, Eclipse. "Boss. It can't even keep up with one finger one thumb typing speeds. This is not going to end well." ;-) It did not.
Thanks for the feedback, Joe.
Cheers,
Blue
The command line always works better. Probably why I prefer TUI than GUI. TUI is closer to the command line. I miss those vt220 and the IBM 32xx/52xx terminals. If laptops only had that capability I'd be happy with that . After all - the web really only needed rich text and photos with an upgrade to video, sound and of course speed.
The last MF COBOL I paid for was around 1992. I think it was Version 6. And I paid lots of money for me, as I was a single developer.
At that time I was using Novell 3.12 (386 400Mhz?) and disk less client computer (286?) booting from Novell via NE200 card or something alike.
At that time Windows 3.xx was barely out, maybe even windows for Workgroups, not sure.
But MF made a simple GUI with simple Windows Textboxes and Labels to display screen sections.
Jus a commandline switch and one could either display a standard text scree or run as GUI under windows.
No Dropdowns, Lists or other fancy stuff, just Labels for text and textboxes for accept.
Sure you had to fiddle around to have the screen looking somehow alike regards to positioning because it basically calculated the GUI position out of the non proportional Screen Section Character positions, but it worked very well to have some windows looking Dialog instead of a CMD Text window.
And that is the way GNU COBOL should go. Not Java, Agar, full blown Web Interface just another display layer providing standard Screen Section in a different visual form.
No 'call xxx using blabla' to display a input box on a screen you created with 'call zzz using blabla returning Hwind and blabla'.
This is not COBOL. This is calling other languages and leaving the COBOL space.
And this is simply wrong.
The correct way to go would be to put some sort of common interface using - well- the basic usage of extended screen io now possible with curses or pdcurses on say CGI or GTK (runs nicly on Windows Mac and Linux) and NO changes in source needed.
Just CORRECTLY display Screen Sections in a halfways sane manner.
And well fixing the editing of numeric fields in extended IO. That is really bad currently with workarounds to move back and forth between Screen Items and Working storage items.
The goal should always be to compile a UNCHANGED source using standard Screen Sections to display and accept in text mode and GUI mode.
Not to get all the fancy web stuff in. Not to get all the fancy Linux Windows and Mac controls in.
Just Labels and Texboxes with correct behavior and common sensible position based on Screen Section character positions.
Just my two cents.
Mike
.
Thanks, Mike. This seems to be working out nicely, with all the angles of what programmers expect from a COBOL.
Awesome.
Yeah, there is a wrinkle to making a dual mode screen section. Windows vendors have a platform to code to, a known (and fixed for the entire customer base) set of graphic APIs. The run-time has a single if to deal with for TUI or GUI (overly simplified). For Windows and Mac, now it's two ifs.
There is also the pending Graphic COBOL reserved word extensions in the cobc tree.
For POSIX it's umm, not fixed, so not known. Can be raw X11 to cover a lot of customers in this smaller pool, but X11 in base form is down right unslick, And would be complicated looking when part of the libcob C code base. Most second layer GUI frameworks are based on X11, but not all. Then we get into an explosion of ifs for GTK/GNOME, Qt/KDE, Tk, Agar, ....... a subsystem that is usually picked by the customer's choice of desktop.
We have a fair start on GTK. The code techniques that implements the function repository contribution could fairly easily get lifted and smoothed into libcob. I gave up chasing the GNOME team, as they were burned bridge racing while I was learning, and I got into a backtrack and retrofit cycle, while learning. Got sulky and looked elsewhere for a stable API with stable docs. :-) Years have passed, they may have already burned down all the bridges they are going to burn down. I'm pretty sure that addition of the CSS layer for theming, could get cobweb-gtk into a reasonable state again. That was the straw for me, couldn't change the colour of a button without using a CSS form in the lowlevel API. Deprecated the setters/getters. Weenies. ;-)
Found Agar. Not a great choice when looking to cover the pre-installed customer base. Fractions of fractions. But, sweet. Not overly fancy. A definite step up from raw X11, but not as polished looking as most. There is frame buffer code, doesn't need a window manager at all, just SDL OpenGL drivers. Which is not a given install either, but it's getting fairly ubiquitous if I'm not mistaken. The Agar frame buffer calls are fixed size fonts and positioning, port to dual mode SCREEN SECTION would be the easiest to implement in my current opinion. Support for the new graphic extension words that are in the works would be middling to hard hard to implement though. Perhaps not slick enough when slicker is available, and effort would be similar? Agar screens feel a little more mainframey to me, which is not a negative. ;-)
W have to choose from the combinations of possibilities. I tried the X11 driver for PDCurses, but that just puts the TUI in a wrapped window frame. Still looks like a TUI in a terminal, not a GUI form.
We can do so in libcob, given a target. Hard slog to cover too many. GTK is probably the sanest choice when it comes to customer base, both for a dual mode SCREEN SECTION code and for the new words, like WINDOW, BUTTON, BITMAP. 100s of words awaiting run-time support. But that all needs a graphic API to code to. Again, even though I gave up a while ago, I'd still probably vote GTK for the API. Agar, can be an optional for people that want to write games or CAD systems, left as a really nifty powerful function repository. With GTK we'd get Broadway as a backend, and that could mean Cloud via graphics in the browser powers, no code changes (umm, once the graphic words get some support in libcob that is).
Can't speak to timelines, Mike, but dual mode SCREEN SECTION is in the works, in the thinking about it works at least. The graphic COBOL words will need a target too, should be the same one.
And yes, we need to fix binary numeric field entry in SCREEN SECTION. It really just needs to call
cob_movecode behind the scenes to get proper display usage to internal storage forms, I think. Better, I've been pestering for someone to try and take a kick at true PICTURE edits in the TUI. No takers over the last 10 years-ish, since Roger gave us the alpha cut of SCREEN SECTION. Of course, we've had the crappy version of DISPLAY form numerics for a while now, and we'd need a USAGE-DISPLAY-NUMERIC-SCREENS compiler build flag to fix this now, or risk breaking code in the wild. :-)Cheers,
Blue
You forgot FORMS and I think the version of MF was Workbench v3.4 or
around that version as thats the one I had that earlier releases relied
on a dongle at least up to the point when I needed it to run on a secure
system that did not have serial or parallel ports so got a non-dongled
version of v3.4 or so.
That is not to say that FORMS and DIALOG did not have there share of
issues :)
Hmm, still have some of the manuals in a cupboard and still use the A6
pocket guide dated April 93 v6 for DOS, Windows and OS/2.
Vince
mod edit for some reply-to
Last edit: Brian Tiffin 2022-02-14
COBOL to be successful has to bet on SQL (ISAM is outdated, doesn't work on the web, it's not ACID, etc...), and the GUI !!!! The modern world is visual, I respect the opinions of the old guard, but the world has changed... it has changed a lot. I programmed in Icobol with GUI/TUI with the same code, but the results were not brilliant. Later I programmed with MF+Dialog System - a terrible desperation. Fujitsu's Powercobol was excellent as a GUI tool, unfortunately it's not opensource, it was based on a technology that was killed by Microsoft (Activex), but it was an opportunity to bring new blood to Cobol. Currently in Europe nobody knows Cobol, there are no programmers and it is usually wrongly seen as something for old people, and for outdated technologies.
Thanks, Paulo. Those are bang on point points, in my opinion.
They don't really match the inner child desires I have had for this free software COBOL (a world where people just keep COBOL treasure piles, link to all the new funky things with intelligently placed, surgical precision hooks and compile new binaries). :-)
I'm in Ottawa, Canada, the civil service here is still very much a COBOL customer, which spills over into the private sectors supporting the civil services.
This pondering about Marketing GnuCOBOL is splintering into a few main branches for me. Marketing to Home Programmers, Marketing to SME Programmers, to Large Enterprise, to Mainframe Programmers, and Marketing to Decision Makers that support those programmers (the first and second camp may be the same persons). Not just one full colour glossy, but six or eight or more.
For blatant Modernization Marketing materials, GnuCOBOL might need some changes, and/or backing support layers before the envisioned adverts would be reasonably universal and worthy.
GnuCOBOL is modern COBOL, always has been. But maybe it's not quite ready for meeting reasonable expectations for, or stamping as, a Modernization COBOL, as a term of art. Still pondering, and trying to avoid inner bias desires and beliefs that may not match the general consensus of the reality. ;-)
Have good, make well,
Blue
Just to throw this out there and do with it what you will.
In the last couple of months alone thousands of people have literally dumped their windows boxes in favor of Linux(Android and Apple phones are in the mix now too).. I think people are starting see that the tech products they use was not built for them but the companies themselves. People are starting to see the two sets of rules. One for them and one for big tech. I expect this trend to continue. I believe over the next couple of years or so Microsoft will lose it dominance over the desktop. MS knows this and will try to stop it but as the same time will make moves in different direction as they have been doing. There real problem is credibility and I don't think they will be able to fix it.
So whatever you do with GnuCobol Windows is not the future. Too much effort in that direction may just go to waste.
I'm not asking you to believe me. Do your own research.
Last edit: Joe Reichart 2022-02-14