Subj : Cobol/gnucobol
To : DARKNETGIRL
From : Dumas Walker
Date : Fri May 30 2025 10:51 am
> I understood that COBOL is more like German, i.e. in theory
> that's the common language, but in practice there are so many dialects there.
I do believe that is the case, at least in a sense. Where I have found the
dialect differences showing up are when I switch between platforms (there
are things that PC COBOL needs to do that mainframe doesn't, and
vise-versa), or because the compilers being used adhere to different
standards (in my case, the PC COBOL compiler was older and didn't "like"
some of the new/changed things added since).
> I just started playing with gnucobol as a starting point, perhaps
> I might embrace Mainframe (as MVS3.8j) or iSeries (ex AS/400) as
> I have an account on pub400.com
I coded on iSeries professionally.
> That said, I believe gnucobol is pretty limited when it comes to
> extensions, and that is also on screens. For example, is
Your sentence got cut off here.
> I also have to say that I'm not a developer. I'm a glorified sysadmin
> that mess with code sometimes. I just wanted something that has a decent
> "easy" language instead of get headaches with stuff like Rust.
LOL, I found COBOL to be easier (but not super easy) because it is mostly
in "plain English" and is meant to be more legible/"self-documenting" than
other languages.
> I would like to learn and I guess there's no better learning that read
> some code. (any suggestion of some publicly available code?)
Unfortunately, I have never really went looking for publicly available
code. I will poke around here and see what I might have. There is/was a
mainframe/COBOL internet forum where I used to find good snipits of code (as
well as SYNCSORT command usage), but that was where I used to work and I
cannot find the link here. :(
Last I checked, IBM did have their COBOL language reference available
online.
> For example, maybe a stupid question, is it normal that a CRUD application
> has everything in a single COB file?
That probably depends some on the installation and the developer but, in my
experience, all of the code for one application often is contained in one
dataset. For some smaller applications, that makes sense, and for some
larger ones (i.e. where multiple decisions all depend on each other) it almost
has to be that way.
I would expect that a CRUD application would be like that, so that the code
that interacts with the database could at least partially be reused for
each function. The end users may have also requested that all functions be
contained in one application.
> And is it normal that you
> need to have a sort of "command" with a letter or a number to process
> the CRUD (add, edit, update, delete)? Or I'm just doing something wrong?
Not sure. I think by "command" you might mean the paragraph names. Those
often start with a number. In many installations, the number or letter it
starts with tells you what kind of paragraph it is... initialization,
report or screen output, error output, database interaction, processing,
etc.
So you might have something like:
IF PROCESS-INDICATOR = 'A'
PERFORM A0100-ADD-RECORD
ELSE
IF PROCESS-INDICATOR = 'D'
PERFORM D0100-DEL-RECORD
ELSE
PERFORM U0100-UPD-RECORD
END-IF
END-IF.
So then A0100-ADD-RECORD would be a paragraph that contains the code to add a
record to the database, etc. What it is named exactly might depend on the
standards for that installation but, in general, you do want your paragraph
names to be descriptive enough that you (and anyone who might need to
maintain the code) can quickly identify what the paragraph does.
In theory, you can be "difficult" and name them just about anything, but
that won't help when you have to go back and make changes. ;)
That is a very simplistic example. If that turns out not to be what you
are asking about, let me know and I will try again. :)
