What if modernizing a COBOL system didn't have to start with rewriting everything from scratch?

I'm the creator of WapForm, a development framework built around WML, a declarative application-definition language.

My approach explores a different path:

COBOL → AI → WapForm → Flutter

Instead of asking AI to translate an entire legacy system directly into another programming language, the idea is to establish an intermediate application definition that can target different platforms.

WapForm already has a WML-to-Flutter code generation workflow. Applying this approach to existing COBOL systems is the next challenge: mapping business logic, data structures, and application behavior into WML, then validating the results against the original system.

This is an ongoing engineering direction, not a claim that every COBOL system can already be converted automatically.

Here's a video introducing the approach:

https://youtu.be/AQEowueepcY

I'd love to hear from COBOL developers and enterprise architects:

What is the hardest part of modernizing a legacy COBOL application?

Would an intermediate application-definition layer be useful?

What would you need to see in a proof of concept before considering this approach?

I'm interested in honest technical feedback and real-world experiences.

Hi everyone,

I’m Deb. We’re looking for people with hands-on COBOL or Fortran experience for a paid, remote project with a US-based AI lab.

What we’re looking for

COBOL

• Mainframe systems, batch jobs, JCL, CICS, DB2 or VSAM
• Legacy migrations or modernization
• Solid university work counts too

Fortran

• Scientific computing, for example MPI/OpenMP, CFD, climate or weather models, numerical libraries
• Legacy code modernization
• Researchers, PhD students and engineers are all welcome

The work

• Read, write and debug COBOL or Fortran code
• Review AI-written code and judge whether it is correct

Details

• Fully remote and part-time, flexible around your job or research
• Paid contract work. The rate depends on experience and is shared after a short skills test.
• The client’s name is confidential
• We never ask for money, passwords or ID documents

To apply: Dm me.

Know someone with COBOL or Fortran experience? Please share this with them. We pay a referral bonus when a referred person qualifies.

I’ll answer questions in the comments. Please check your employer’s outside-work policy before applying.

Mastering COBOL: The Power of the REDEFINES Clause

Ever wondered how to interpret the exact same chunk of memory in two completely different ways without allocating a single extra byte?

In mainframe applications, managing storage efficiently is everything. That is where the COBOL REDEFINES clause comes into play. It allows multiple data items to share the same physical memory space, giving you the flexibility to overlay structures—like converting an alphanumeric string into numeric sub-fields or handling variable record formats.

In my latest video, I break down:

-> Exactly how the REDEFINES syntax works

-> Crucial compiler rules you must follow (like handling level numbers and size limitations)

-> Practical, real-world project scenarios

If you want to sharpen your mainframe COBOL programming skills or need a quick refresher, check out the full tutorial here:

Watch the video on YouTube: https://www.youtube.com/watch?v=XbYteTi9d28

I've been working as a Business Data Analyst for the past 2 years and 3 months, and before that, I spent nearly to 6 years as a Software Developer, specialising in VB.NET and SQL.

Throughout my career in SQL I've been involved in developing, maintaining and troubleshooting our nightly ELT process, using our bespoke ELT software and SQL Server. I'm comfortable working with existing codebases, investigating issues and maintaining business-critical systems.

Recently, I've become increasingly interested in COBOL and mainframe development, and I'm seriously considering pursuing it as the next step in my career.

However, I'm struggling to work out how to break into the industry. Most of the COBOL positions I've come across seem to require several years of commercial COBOL or mainframe experience, and there don't appear to be many junior opportunities available.

I'm based in the UK, and ideally I'd like to make the transition without having to start my career over again, particularly given my existing development experience.

I'd be interested to hear from anyone currently working with COBOL or IBM mainframes.

• How did you get into the industry?
• Would my previous software development and SQL experience be relevant to employers?
• What would you recommend learning beyond COBOL itself, such as JCL, z/OS, Db2 or CICS?
• Are there realistic routes into the industry for experienced developers who haven't worked with COBOL professionally?
• Is it realistic to transition without taking a significant salary reduction?

I'm happy to dedicate time to studying and building my knowledge independently. I'm just unsure how to turn that into an actual career opportunity.

Any advice or experiences would be appreciated.

I've been building cobol-equiv, an open-source harness that checks whether a Python translation of a COBOL program behaves exactly like the original, using GnuCOBOL as the oracle. It comes with a small Python runtime for COBOL numeric semantics (PICTURE, COMP-3, ROUNDED, SIZE ERROR), validated against GnuCOBOL on 9,769 generated cases with 0 disagreements on 3.1.2.

Then I used it to measure LLM translations. 50 programs: 30 public ones (Rosetta Code and Open Mainframe Project examples) and 20 written for the repo. One model, 3 attempts per program, protocol fixed before any run. The translator saw the COBOL source and two example input/output pairs; scoring was on hidden inputs (generated plus PICTURE boundary values).

What broke the plain-Python translations was not logic, it was COBOL semantics: - ACCEPT into 9(5)V9(3) cuts the input to the receiver length, so the last decimal digit is dropped. The translation kept it. - An 11-character input into 9(10) loses a digit on the left. - A negative zero printed as "-0", where GnuCOBOL edits zero without a sign. - Non-numeric input converted differently.

The embarrassing part: the runtime I gave the model had a bug. CobDecimal compared objects by identity and had no ordering, so most failures in condition A (crashes and two infinite loops) were mine, not the model's. The pre-registered numbers stay primary in the repo, and a corrected sensitivity analysis is published next to them, with every verdict that flips listed.

Limits, plainly: small corpus, one model on one date, GnuCOBOL instead of an IBM compiler, attempts of the same program are not independent, and at program level the A vs C difference is not statistically significant.

Repo, protocol, raw prompts and replies, and the verifier: https://github.com/abdulazizbalu/cobol-equiv

I'd really value critique from people who work with COBOL: which semantic traps would you add, and if you have small, deterministic programs under a permissive license, I'd like to add them to the public track.

I've been building GitGalaxy, an air-gapped scanner that builds a structural model of COBOL/CICS estates: byte-level layouts (every USAGE, REDEFINES, ODO, SYNC), copybooks, PERFORM/CALL/LINK/XCTL graphs, COMMAREA contracts, CICS/Db2/IMS/MQ operations, and compile options with their source.

The data is sufficient in scope to act as a generator for a deterministic translator (no LLM) generates Java from the model. Then both the original (on GnuCOBOL plus our CICS/Db2 models) and the Java run the same scenarios, compared byte for byte. Of 117 programs in 5 public estates (CardDemo, CBSA, GenApp and others), 75 translate whole and 62 behave identically on every scenario. Four outside parsers (Cobrix, Che4z and others) also agree with the model at 96–100%.

Semantics that bit us: TRUNC(STD) vs BIN, COMP-1/2 as IBM hex float, negative zero through a truncating MOVE, EBCDIC code pages × DECIMAL-POINT IS COMMA.

repo

RENAMES Clause:

The COBOL RENAMES clause (level number 66) creates alternative logical groupings or overlapping views of existing data items within a record without changing physical storage.

Syntax:

66 data-name-1 RENAMES data-name-2 [THROUGH | THRU data-name-3]

* Must use the special level number 66.

* Must immediately follow the last data description entry of the logical record.

https://www.youtube.com/watch?v=GE_MEelNXeA

TL;DR: Our ERP stores everything in AcuCOBOL Vision files. The only official way in was a 3-seat ODBC driver that was always maxed out and occasionally crashed. We reverse engineered the file format, now read the raw .dat files directly (read-only), and mirror 66 tables into Postgres every 5 minutes in about 35 seconds. It took a few weeks, one scary mistake, and a lot of verification.

The setup

We're a small food manufacturer running an ERP that's been around since the 90s. Under the hood it's AcuCOBOL, and every table is a Vision indexed file: a .dat with the records and a .vix with the index.

Everything modern we run (dashboards, EDI, order imports, a wholesale portal) reads a Postgres mirror of the ERP. That mirror used to be fed by a bridge over ODBC, through a vendor driver licensed at 3 concurrent seats. Those seats were spoken for all day by shipping stations and automation, the ODBC server is a single-threaded binary from 2014 that pegs one core, and a full refresh took hours. When it fell over, everything downstream went stale.

The idea

The files are just bytes on a share. If we could decode them ourselves, we wouldn't need a seat at all.

What made it possible: the ODBC product ships its own catalog describing every record layout. For each table it lists every field with its byte offset, length, PIC clause, usage, decimal places and date format. That's basically the COBOL copybooks in queryable form, so we never had to guess a field.

Cracking the file format

Vision files have a header area, then records stored in slots, each with a small header of its own. Where the records start, how big that per-record header is, and the stride between records all vary by file. So instead of hand-deriving 66 of them, we wrote a generator: try candidate layouts, decode a sample, and score how many decoded rows exactly match known-good rows pulled over ODBC. The winner goes into a config, and nothing gets in without validating against live data.

Making it safe to cut over

This is the part that actually took the time. We ran the reader in shadow for weeks next to the old bridge:

• every night, a full row-hash comparison of every table, with both pipelines normalized the same way
• every two hours during business hours, count checks and field-by-field spot checks on the busiest tables
• a gate: 10 consecutive clean business-hours cycles on the order header file before we'd switch
• the reader code and configs are hashed together, so any change resets the streak

What it looks like now

• 66 tables re-checked every 5 minutes, about 35 seconds per sweep
• each record's raw bytes are fingerprinted, and only rows that actually changed get written
• files are opened read-only, and the reader never touches the ODBC service (4 small tables still ride the old path while we finish them)
• a row only gets deleted after it's missing from the source on two consecutive sweeps, so one bad read can't wipe live data

Things that bit us

• Live users lock records. Someone editing an order holds a byte-range lock on part of the file, and any read that hits it fails. We retry with backoff and treat a lock as "no data this pass," not an error. Once a desktop session died mid-edit and its server-side runtime held a lock for five and a half hours.
• Files change under you. We check size and mtime before and after each read and retry if they moved.
• REDEFINES. Two fields describing the same bytes, and the catalog's ordering of the tie isn't something you can derive.
• "Last synced" changed meaning. The old bridge rewrote every row on every pass, so a timestamp meant "last checked." Ours only writes changes, so it means "last changed." Four freshness monitors started calling quiet tables dead, and all of them had to be repointed at the reader's own heartbeat.
• Our own big mistake. During cleanup we deleted about 1.4M rows we believed were stale leftovers. We'd found them by comparing against the reader's output, but the reader deliberately skips very old records, so everything older than that cutoff looked "missing." It was real history. Every deleted row had been copied aside first, so it came back as archive tables. Lesson: an anti-join only tells you something is stale if both sides cover the same key range.
• Bloat. The old bridge rewriting every row every 15 minutes for months left some Postgres tables 7x their real size. One night of compaction took the database from 45 GB to 32 GB.

How it got built

Full disclosure: most of the reverse engineering and code was done pair-programming with Claude. It was great at grinding through byte offsets and writing verification harnesses. It was also the one that made the delete mistake, and the one that dug it back out, which honestly felt about right for a pair programmer.

Happy to answer questions if anyone else is stuck feeding a COBOL system through an ODBC straw.

Looking for advice, maybe even. short term engagement for one of two experienced Nonstop COBOL developers. I won't lie, right now our opportunity is quite wide and I'm open to ideas, but there may also be scope to build a fairly recurring bit of work. Anyone interested in discussing please reach out. Coming from a HPE Nonstop company working with Customers all round the world.

Hello people. Posting for any Mainframe opportunities in Europe for myself.

My background: I have 15+ years of industry experience working on Mainframes. Mostly my roles have been around 8 years experience in Development. Remaining close to 5 years in Production support - L2/L3 Oncall etc. I was also part of migration of DB2 z/OS to LUW.

I have worked for multiple clients, projects, geographies from diverse backgrounds. Banking, Insurance, Manufacturing, Utilities are the areas I mainly worked in Dev/Production support. Currently I am supporting a Mortgage application for a Large Danish bank. I can adapt to any domain/projects easily and I am sincere at my work.

I am currently based out of India and looking for opportunities to work at onsite in Europe for long-term (preferably Nordics but not necessary). If you have a role within your teams or know a position where I can fit, please DM me. I can share my CV/CL/LinkedIn etc. for interview and we can take it from there. Would be grateful for any help. Thank you for the read.

Is there anything like this in the current mainframe/COBOL industry? I am planning to develop something like this.

Hey everyone,

I’ve recently entered the world of banking (retail side) and have become incredibly intrigued by COBOL. I’ve never coded before but I’d really like to learn COBOL and hopefully make a career out of it. Any advice, warning, and helpful tutorials you have found in your journey with the language would be immensely appreciated.

Hey everyone, just published this video covering basics of cobol like pic, arithmetic, signs, storage, and much more.

First time taking the courage to put my face in video :D

Also do explore my platform. My platforms lets you execute cobol code, in an ide like environment.
It has a Pull request review component, vibe coding lessons that you won't find anywhere in any platform. Took me ~10 months to build it from scratch.

Im a recent CS grad and live in a major north American banking hub (Charlotte). I keep hearing conflicting stories about "Oh all the banks/gov need young people to keep the systems going!" And "Dont bother, its a waste of time and impossible to break into anyway." I dont have any experience with the language or accompanying frameworks. Would it be worthwhile to try and learn in hopes of employment?

Hey everyone,



If you've ever had to extract and analyze data from mainframe dumps, you know the headache of dealing with packed decimals (COMP-3), binary integers (COMP), and EBCDIC character encodings (IBM037, IBM1147).



Uploading sensitive banking/insurance extracts to online web converters is often a strict compliance violation (GDPR, PCI-DSS).



I built a lightweight, 100% offline desktop tool called COBOL Bridge:

- Drag & drop your .cpy Copybook and raw binary .dat file.

- Parses signed packed decimals (S9(9)V99 COMP-3), binary fields, and text accurately.

- Exports directly to CSV, JSON, and SQLite.

- Generates Pydantic (Python) or TypeScript models from copybooks in 1 click.

- Runs locally without sending a single byte to the cloud.



Available on Gumroad: gewa7.gumroad.com/l/bkzyiv



Would love to hear your thoughts and what specific COBOL clauses you deal with most often!

If you've ever had to extract and analyze data from mainframe dumps, you know the headache of dealing with packed decimals (`COMP-3`), binary integers (`COMP`), and EBCDIC character encodings (IBM037, IBM1147).



Uploading sensitive banking/insurance extracts to online web converters is often a strict compliance violation (GDPR, PCI-DSS).



I built a lightweight, 100% offline desktop tool called 
**COBOL Bridge**
:

- 
**Drag & drop**
 your `.cpy` Copybook and raw binary `.dat` file.

- Parses signed packed decimals (`S9(9)V99 COMP-3`), binary fields, and text accurately.

- Exports directly to 
**CSV, JSON, and SQLite**
.

- Generates 
**Pydantic (Python)**
 or 
**TypeScript**
 models from copybooks in 1 click.

- Runs locally without sending a single byte to the cloud.



You can check it out here: https://gewa7.gumroad.com/l/bkzyiv



Would love to hear your thoughts and what specific COBOL clauses you deal with most often!

New video from Moshix!

While looking for some example programs to test an RM Cobol setup I ran across a PDF called "Cobol for the TRS-80 Volume 1 Class Notes". I wanted to find something that was ancient ( for an Altos running Xenix no less ), so I dug through this document and typed in an example payroll calculating program. Seemed to compile and run, but it screws up simple arithmetic .. multiplying a salary * hours gives an unrelated crazy big number.

Ok ... I tried the exact same program on a later RM Cobol version 5.1 and it worked! Now I started going deep down the rabbit hole! ... it generates those crazy numbers with RM Cobol v1.5, 2.0D, and 2.2 under DOS 5.0, DOS 6.2, DOS 3.2 and Xenix and works just fine with RM Cobol 5.1, and 6 under DOS (real pc ) and DOSbox-x. And all of these versions run the RM Cobol verify tests, run a PI calculating program and a little calculator ... I've expanded the PIC fields, tried SEQUENTIAL organization for the data file being read, Displayed a bunch of variables, looked at the fields at the end of the compile list to see if everything numeric is declared as a numeric ... am learning a bunch of Cobol stuff doing all of this. Again, it's an ancient program from a 1983 doc that won't run in the compiler versions from that time but works great in the ones from the '90's

update:   here is the code ... I added some DISPLAY's trying to figure out what was going on .. the problem is with the calculation of IMD-REGULAR-PAY

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PAYROLL2.
       AUTHOR.     R GRAUER.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER.     TRS-80.
       OBJECT-COMPUTER.     TRS-80.

       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT EMPLOYEE-FILE
               ASSIGN TO INPUT "PAYROLL.DAT"
               ORGANIZATION IS SEQUENTIAL.
           SELECT PRINT-FILE
               ASSIGN TO PRINT "PAYROLL2.DAT".

       DATA DIVISION.
       FILE SECTION.
       FD  EMPLOYEE-FILE
           LABEL RECORDS ARE OMITTED
           RECORD CONTAINS 80 CHARACTERS
           DATA RECORD IS EMPLOYEE-RECORD.
       01  EMPLOYEE-RECORD.
           05   EMP-NAME.
                10 EMP-LAST-NAME      PIC X(15).
                10 EMP-FIRST-NAME     PIC X(10).
           05   EMP-HOURS-WORKED.
                10 EMP-REG-HOURS      PIC 99.
                10 EMP-OVERTIME-HOURS PIC 99.
           05   EMP-RATE              PIC 99V99.
           05   FILLER                PIC X(47).

       FD  PRINT-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 132 CHARACTERS
           DATA RECORD IS PRINT-LINE.
       01  PRINT-LINE                PIC X(132).

       WORKING-STORAGE SECTION.
       77  WS-DATA-REMAINS-SWITCH    PIC X(3)    VALUE SPACES.   

       01  DATE-WORK-AREA.
           05  TODAYS-YEAR           PIC 99.
           05  TODAYS-MONTH          PIC 99.
           05  TODAYS-DAY            PIC 99. 

       01  IND-COMPUTATIONS.
           05  IND-REGULAR-PAY        PIC 9(4)V99  VALUE ZEROS.
           05  IND-OVERTIME-PAY       PIC 9(4)V99  VALUE ZEROS.
           05  IND-GROSS-PAY          PIC 9(4)V99  VALUE ZEROS.
           05  IND-FEDERAL-TAX        PIC 9(4)V99  VALUE ZEROS.
           05  IND-NET-PAY            PIC 9(4)V99  VALUE ZEROS.

       01  COMPANY-TOTALS.
           05  CO-REGULAR-PAY         PIC 9(6)V99  VALUE ZEROS.
           05  CO-OVERTIME-PAY        PIC 9(6)V99  VALUE ZEROS.
           05  CO-GROSS-PAY           PIC 9(6)V99  VALUE ZEROS.
           05  CO-FEDERAL-TAX         PIC 9(6)V99  VALUE ZEROS.
           05  CO-NET-PAY             PIC 9(6)V99  VALUE ZEROS.

       01  PAGE-AND-LINE-COUNTERS.
           05  WS-PAGE-COUNT          PIC 9(4)     VALUE ZEROS.
           05  WS-LINE-COUNT          PIC 9(4)     VALUE 4.

       01  HEADING-LINE-ONE.
           05  FILLER                 PIC X(4).
           05  HDG-MONTH              PIC Z9.
           05  FILLER                 PIC X        VALUE "/".
           05  HDG-DAY                PIC Z9.
           05  FILLER                 PIC X        VALUE "/".
           05  HDG-YEAR               PIC Z9.
           05  FILLER                 PIC X(40)    VALUE SPACES.
           05  FILLER                 PIC X(8)     VALUE "PAYROLL ".
           05  FILLER                 PIC X(6)     VALUE "REPORT".
           05  FILLER                 PIC X(40)    VALUE SPACES.
           05  FILLER                 PIC X(4)     VALUE "PAGE".
           05  HDG-PAGE-NUMBER        PIC Z(4).
           05  FILLER                 PIC X(19)    VALUE SPACES.

       01  HEADING-LINE-TWO.
           05  FILLER                 PIC X(8)     VALUE SPACES.
           05  FILLER                 PIC X(4)     VALUE "NAME".
           05  FILLER                 PIC X(9)     VALUE SPACES.
           05  FILLER                 PIC X(4)     VALUE "RATE".
           05  FILLER                 PIC X(4)     VALUE SPACES.
           05  FILLER                 PIC X(9)     VALUE "REG HOURS".
           05  FILLER                 PIC X(4)     VALUE SPACES.
           05  FILLER                 PIC X(9)     VALUE "O/T HOURS".
           05  FILLER                 PIC X(4)     VALUE SPACES.
           05  FILLER                 PIC X(11)    VALUE "GROSS PAY".
           05  FILLER                 PIC X(2)     VALUE SPACES.
           05  FILLER                 PIC X(7)     VALUE "FED TAX".
           05  FILLER                 PIC X(5)     VALUE SPACES.
           05  FILLER                 PIC X(7)     VALUE "NET PAY".
           05  FILLER                 PIC X(23)    VALUE SPACES.

       01  DASHED-LINE.
           05  ROW-OF-DASHES         PIC X(111)    VALUE ALL "-".
           05  FILLER                PIC X(21)     VALUE SPACES.

       01  DETAIL-LINE.
           05  FILLER                PIC X(2).
           05  DET-LAST-NAME         PIC X(15).
           05  FILLER                PIC X(2).
           05  DET-RATE              PIC $$$.99.
           05  FILLER                PIC X(8).
           05  DET-REG-HOURS         PIC Z9.
           05  FILLER                PIC X(10).
           05  DET-OVERTIME-HOURS    PIC Z9.
           05  FILLER                PIC X(6).
           05  DET-REGULAR-PAY       PIC $$,$$9.99.
           05  FILLER                PIC X(3).
           05  DET-OVERTIME-PAY      PIC $$,$$9.99.
           05  FILLER                PIC X(2).
           05  DET-GROSS-PAY         PIC $$,$$9.99.
           05  FILLER                PIC X(3).
           05  DET-FEDERAL-TAX       PIC $$,$$9.99.
           05  FILLER                PIC X(3).
           05  DET-NET-PAY           PIC $$,$$9.99.
           05  FILLER                PIC X(23).

       01  TOTAL-LINE.
           05  FILLER                PIC X(6)      VALUE SPACES.
           05  FILLER                PIC X(6)      VALUE "TOTALS".
           05  FILLER                PIC X(41)     VALUE SPACES.
           05  TOTAL-REGULAR-PAY     PIC $$,$$9.99.
           05  FILLER                PIC X(3)      VALUE SPACES.
           05  TOTAL-OVERTIME-PAY    PIC $$,$$9.99.
           05  FILLER                PIC X(2)      VALUE SPACES.
           05  TOTAL-GROSS-PAY      PIC $$,$$9.99.
           05  FILLER                PIC X(3)      VALUE SPACES.
           05  TOTAL-FEDERAL-TAX     PIC $$,$$9.99.
           05  FILLER                PIC X(3)      VALUE SPACES.
           05  TOTAL-NET-PAY         PIC $$,$$9.99.
           05  FILLER                PIC X(47)     VALUE SPACES.

       PROCEDURE DIVISION.
       0100-PREPARE-PAYROLL.
           PERFORM 0200-GET-DATE.
           OPEN INPUT EMPLOYEE-FILE
                OUTPUT PRINT-FILE.
           READ EMPLOYEE-FILE
               AT END MOVE "NO" TO WS-DATA-REMAINS-SWITCH.
           PERFORM 0300-PROCESS-RECORDS
               UNTIL WS-DATA-REMAINS-SWITCH = "NO".
           PERFORM 1000-WRITE-COMPANY-TOTALS.
           CLOSE EMPLOYEE-FILE
                PRINT-FILE.
           STOP RUN.

       0200-GET-DATE.
           ACCEPT DATE-WORK-AREA FROM DATE.
           MOVE TODAYS-YEAR TO HDG-YEAR.
           MOVE TODAYS-MONTH TO HDG-MONTH.
           MOVE TODAYS-DAY TO HDG-DAY.

       0300-PROCESS-RECORDS.
           PERFORM 0400-COMPUTE-GROSS-PAY.
           PERFORM 0500-COMPUTE-FEDERAL-TAX.
           PERFORM 0600-COMPUTE-NET-PAY.
           PERFORM 0700-UPDATE-COMPANY-TOTALS.

           IF WS-LINE-COUNT > 3
           PERFORM 0800-WRITE-HEADING-LINE.
           PERFORM 0900-WRITE-DETAIL-LINE.
           ADD 1 TO WS-LINE-COUNT.
           READ EMPLOYEE-FILE
           AT END MOVE "NO" TO WS-DATA-REMAINS-SWITCH.

       0800-WRITE-HEADING-LINE.
           ADD 1 TO WS-PAGE-COUNT.
           MOVE 1 TO WS-LINE-COUNT.
           MOVE WS-PAGE-COUNT TO HDG-PAGE-NUMBER.
           WRITE PRINT-LINE FROM HEADING-LINE-ONE
               AFTER ADVANCING PAGE.
           WRITE PRINT-LINE FROM HEADING-LINE-TWO
               AFTER ADVANCING 4 LINES.
           WRITE PRINT-LINE FROM DASHED-LINE
               AFTER ADVANCING 1 LINE.

       0400-COMPUTE-GROSS-PAY.
           MULTIPLY EMP-REG-HOURS BY EMP-RATE GIVING IND-REGULAR-PAY.

           DISPLAY "EMP-OVERTIME-HOURS: " EMP-OVERTIME-HOURS.
           DISPLAY "EMP-REG-HOURS: " EMP-REG-HOURS.
           DISPLAY "EMP-RATE:  " EMP-RATE.
           DISPLAY "IND-REGULAR-PAY:  " IND-REGULAR-PAY.
           DISPLAY "EMP-LAST-NAME " EMP-LAST-NAME.

           COMPUTE IND-OVERTIME-PAY
               = EMP-OVERTIME-HOURS * EMP-RATE * 1.5.
           ADD IND-REGULAR-PAY IND-OVERTIME-PAY GIVING IND-GROSS-PAY.

       0500-COMPUTE-FEDERAL-TAX.
           COMPUTE IND-FEDERAL-TAX = .16 * IND-GROSS-PAY.
           IF IND-GROSS-PAY > 160
               COMPUTE IND-FEDERAL-TAX
                   = IND-FEDERAL-TAX + .02 * (IND-GROSS-PAY - 160).

           IF IND-GROSS-PAY > 200
               COMPUTE IND-FEDERAL-TAX
                   = IND-FEDERAL-TAX + .02 * (IND-GROSS-PAY - 200).

       0600-COMPUTE-NET-PAY.
           COMPUTE IND-NET-PAY = IND-GROSS-PAY - IND-FEDERAL-TAX.

       0700-UPDATE-COMPANY-TOTALS.
           ADD IND-REGULAR-PAY TO CO-REGULAR-PAY.
           ADD IND-OVERTIME-PAY TO CO-OVERTIME-PAY.
           ADD IND-GROSS-PAY TO CO-GROSS-PAY.
           ADD IND-FEDERAL-TAX TO CO-FEDERAL-TAX.
           ADD IND-NET-PAY TO CO-NET-PAY.

       0900-WRITE-DETAIL-LINE.
           MOVE SPACES TO DETAIL-LINE.
           MOVE EMP-LAST-NAME TO DET-LAST-NAME.
           MOVE EMP-RATE TO DET-RATE.
           MOVE EMP-REG-HOURS TO DET-REG-HOURS.
           MOVE EMP-OVERTIME-HOURS TO DET-OVERTIME-HOURS.
           MOVE IND-REGULAR-PAY TO DET-REGULAR-PAY.
           MOVE IND-OVERTIME-PAY TO DET-OVERTIME-PAY.
           MOVE IND-GROSS-PAY TO DET-GROSS-PAY.
           MOVE IND-FEDERAL-TAX TO DET-FEDERAL-TAX.
           MOVE IND-NET-PAY TO DET-NET-PAY.

           WRITE PRINT-LINE FROM DETAIL-LINE
               AFTER ADVANCING 2 LINES.

       1000-WRITE-COMPANY-TOTALS.
           WRITE PRINT-LINE FROM DASHED-LINE
               AFTER ADVANCING 1 LINE.
           MOVE CO-REGULAR-PAY TO TOTAL-REGULAR-PAY.
           MOVE CO-OVERTIME-PAY TO TOTAL-OVERTIME-PAY.
           MOVE CO-GROSS-PAY TO TOTAL-GROSS-PAY.
           MOVE CO-FEDERAL-TAX TO TOTAL-FEDERAL-TAX.
           MOVE CO-NET-PAY TO TOTAL-NET-PAY.

           WRITE PRINT-LINE FROM TOTAL-LINE
               AFTER ADVANCING 2 LINES.

And here is the "PAYROLL.DAT" file ( am seeing a blank line when I paste it here that's not in the file )

johnson bob 21 3 400

sanford fred 23 4 500

The result while running when it's failing shows:

EMP-OVERTIME-HOURS: 3

EMP-REG-HOURS: 21

EMP-RATE: 400

IMD-REGULAR-PAY: 728400 ( this is the quantity in error .. sb 21 * 400 gives 8400

EMP-LAST-NAME: johnson

EMP-OVERTIME-HOURS: 4

EMP-REG-HOURS: 21

EMP-RATE: 500

IMD-REGULAR-PAY: 699500 ( expecting 11500 here from 21 * 500 )

I don't have a background in STEM, I am terrible at math, I don't have any experience in programming of any kind, I barely know the basics of computer science and I am generally stupid.

But I want to learn COBOL - Either just for funsies or just to have a skill that could one day prove handy.

I have a vague interest in computing and am willing to learn... Even if it means taking years to learn.

How did you people start off? How did you learn?

Hi everyone, I've been working on a Windows application called "COBOL Data Inspector", and version 1.0 is now available in the Microsoft Store. I'm looking for COBOL and mainframe developers who would be willing to test it on real-world copybooks and data files and give me feedback. The application is currently focused mainly on IBM Enterprise COBOL / z/OS layouts.

Current features include:

• COBOL copybook inspection with PIC, USAGE, offsets, field sizes and record length

• OCCURS and REDEFINES support

• Nested COPY dependency resolution

• Comparison of two copybook versions

• Detection of potentially breaking physical layout changes and byte shifts

• FB and VB/RDW mainframe data viewer

• EBCDIC decoding

• COMP/BINARY and COMP-3 packed decimal decoding

• Raw hex view with field-to-byte mapping

• Record length, RDW and packed decimal validation

• IBM z/OS LP(32) and LP(64) layout profiles

• CSV and JSON export

• Built-in synthetic demo data for testing

Everything is processed locally on the PC. There is no account, no AI, no analytics, no advertising and no cloud upload. The application is completely free.

What I would especially like help testing:

• unusual or complicated copybooks

• incorrect field offsets or record lengths

• COPY / REDEFINES / OCCURS edge cases

• COMP-3 and EBCDIC decoding

• FB and VB/RDW files

• usability of the interface

• features that are missing but would actually be useful in real COBOL/mainframe work

If you find a bug, incorrect calculation, unsupported copybook structure or anything else that looks wrong, please let me know. I'm also very interested in ideas for future features. If there is something you regularly need when working with COBOL copybooks or mainframe data, I'd like to hear about it.

If anyone wants to try it, just open the Microsoft Store and search for:

"COBOL Data Inspector"

Thanks to anyone willing to test it and share feedback.

P.S. I'll post the direct Microsoft Store link in the comments in case that's more convenient for anyone.

I recently came across a free FUSE plugin called TigerFS that allows you to mount a PostgreSQL database as a file system where tables show up as directories and records show up as files. I had been experimenting with GixSQL but did not have much success with it.

https://tigerfs.io/

After mounting my database and creating a sample "employees" table:

create table emptable ( eno int4 not null,
lname varchar(10),
fname varchar(10),
street varchar(32),
city varchar(15),
st varchar(2),
zip varchar(5),
dept varchar(4),
payrate numeric(13, 2),
com numeric(3, 2),
miscdata varchar(128),
constraint emptable_pk primary key (eno));

I was able to access from gnucobol like processing a sequential tab-delimited file:

>> source format is free

identification division.
program-id. testtiger.

environment division.
configuration section.
repository.
function all intrinsic.


input-output section.
file-control.
select employee-file
assign to "/mnt/mylabdb/emptable/.export/tsv"
organization is line sequential.

data division.

file section.

fd  employee-file.
01  emp-record pic x(2048).


working-storage section.

01 WS-TAB          PIC X(1)   VALUE X'09'.

01 display-rec.

05 eno pic 9(20).
05 lname pic x(10).
05 fname pic x(10).
05 street pic x(32).
05 city pic x(15).
05 st pic x(2).
05 zip pic x(5).
05 dept pic x(4).
05 payrate pic 9(13)V99.
05 com pic 9(3)V99.
05 miscdata pic x(128).



procedure division.

main.

display " "
display "retrieving records from postgres public.emptable..."
display " "

open input employee-file

perform forever
read employee-file
at end
display "no more records"
exit perform

not at end

*>  parse the tab-delimited record format 
unstring emp-record 
delimited by WS-TAB  
into eno, lname, fname, street, city, st, zip, dept, payrate, com, miscdata of display-rec


display "Record: " eno
display "fname: " fname
display "lname: " lname
display "street: " street
display "city: " city
display "st: " st
display "zip: " zip 
display "dept: " dept
display "rate: " payrate
display "commission: " com
display "misc: " miscdata
display " "


end-read
end-perform


close employee-file

stop run
.

end program testtiger.

retrieving records from postgres public.emptable...

Record: 00000000000000000123

fname: John

lname: Doe

street: 123, Nowhere Lane

city: Noplace

st: N1

zip: 00100

dept: DEP1

rate: 0000000000100.00

commission: 000.00

misc: abcd1234

Record: 00000000000000000456

fname: Jane

lname: Smith

street: 456, Someplace Rd.

city: Somewhere

st: N2

zip: 00111

dept: DEP2

rate: 0000000000200.00

commission: 001.00

misc: defg5678hijk

Record: 00000000000000000789

fname: Theropod

lname: Green

street: 789, Somewhere Else st.

city: Somewhere2

st: N3

zip: 00177

dept: DEP4

rate: 0000000000120.00

commission: 000.20

misc: zxcvb12345

no more records

Addendum: I was also able to use this to allow gnucobol to perform arbitrary actions by using a facade table with a BEFORE INSERT trigger that calls a stored proc instead, and has access to all the INSERT values.

So basically, gbucobol could perform an RPC by inserting into the facade table with a transaction ID and parameters, and then poll a response table for the result.