Subj : Cobol/gnucobol To : DARKNETGIRL From : Dumas Walker Date : Fri May 30 2025 10:51:00 > 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. :) * SLMR 2.1a * The Bagginses, they steals our taglines, precioussss .... --- þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP .