Advent of Computing

I was cleaning out my garage and came across binders of COBOL 2 and SQL documentation from 30 years ago (I have not used COBOL since then). I do not necessarily want to trash them but looking for the best way to repurpose them.

Do you think libraries or colleges would want them? I am sure with the internet now days you could probably get the information faster than looking through paper documentation.

plx is a PostgreSQL extension that lets you write stored functions and triggers in the dialect you already know (the current set is listed below). When you run CREATE FUNCTION, plx transpiles the body to plpgsql and stores that plpgsql in pg_proc.prosrc. At run time the function is executed by PostgreSQL's own plpgsql interpreter. There is no separate language runtime loaded into the backend, and nothing new to run in production.

MOVE 0 TO WS-TOTAL
COMPUTE WS-A = PI * R ** 2
ADD WS-I TO WS-TOTAL
SUBTRACT B FROM A GIVING WS-D
MULTIPLY A BY B GIVING WS-P
DIVIDE B INTO A GIVING WS-Q

Hello everyone!

This is my first post here.

To give you some context, I’m a Brazilian web developer, and I’ve been thinking about learning COBOL and changing my career path. I’ve mostly worked for startups, and I’m tired of the instability. I’d like to work for a more traditional company that is more resilient during economic downturns.

So, I have a few questions:

Are there remote COBOL jobs available?

Does COBOL still offer good career opportunities?

Would learning COBOL be a good choice for someone with a web development background?

Hello! I am currently working as a cobol programmer/developer in Western Europe for a consulting company. I do not have any academic education on computer science (my background is biology and biochemistry), but I decided to change fields and I think it's been going well so far.

I now have 3 years of experience as a cobol programmer and I've been looking for a new job in the same field because I don't see myself building a career in my current company due to the lack of recognition and promotions.

I came across a job description for a Software deployment engineer or Harvest technician position. The RH from the consulting company that posted this job said that the current client team is very senior and they are looking for someone new, to learn and give continuity to the team. Which I'm completely down for. They also said that the team's profile is mostly people who have worked in cobol programming, and that usually people take this jump, from developing to release manager, later in their careers so this could be good for me.

What scares me is that I could be leaving software development too soon, but at the same time from the job description it looks like I might be able to have contact with different teams and programming languages. I'll leave the description bellow.

Also, is there anyone here working as a software deployment engineer or release manager, how's the job and how easy it is to find jobs like this and maybe switch? Do I need to be proficient in many programming languages? And I'm planning to leave my country in like maybe 3 years so I'd like to understand if this set of skills could be beneficial.

THANK YOU SO MUCH

tl;dr: unsure about leaving cobol software development too soon, for a software deployment position. does it have growth and future? is it worth it?

The job description
Main tasks to be performed:

• Manage deployment procedures across the environments that make up the SW lifecycle (DEV-TST-CER-QLY-PRD)
• Ensure the automation of SW compilation/promotion and distribution throughout the SW lifecycle
• Promote releases from test environments to Production, ensuring the preparation of the Delivery Plan and Implementation Plan
• Verify system operational status after completion of release deployment (implementation) and monitor the start of roll-out
• Ensure the maintenance and stability of development, certification testing, pre-production, and production environments
• Ensure the installation of applications on in-house servers and support the installation of the same applications on third-party servers

Required skills and technical knowledge:

• Knowledge of Software Change and Configuration Management and software lifecycle management
• Full understanding of the software development lifecycle, from initial development through maintenance and operation
• Ability to apply creative solutions to complex automation problems in order to automate repetitive tasks
• Ability to resolve technical issues related to build tools
• Ability to understand and troubleshoot software issues / hardware configuration issues
• Configure build, test, and deploy stages

Desirable skills and technical knowledge:

• Programming languages: Cobol, Visual Basic, u/net, Java, Perl, Clist, Rexx, JCL, Endevor-SCL, SQL
• Knowledge of CICS, DB2, Oracle, IMS, MVS, Z/OS, ENDEVOR, HARVEST, MQ, FTS
• Familiarity with IT best practice standards such as ITIL, ISO20000, COBIT, and CMMI

Question: how do invalid / non‑preferred sign codes behave in real data?

I'm learning how legacy COBOL handles decimal signs, and I've hit the case I'm most worried about. Valid/preferred sign nibbles (C positive, D negative, F unsigned) seem well‑behaved. What I can't pin down is what happens with non‑preferred or invalid sign nibbles (e.g. A, B, E, F, or a digit where a sign should be), the scenario where a field that should be negative (a debit) gets read as positive (a credit).

Specifically:

1. In real production data (life/pensions ledgers, long‑lived files), how often do you actually see non‑preferred sign codes in COMP‑3 / zoned‑decimal fields? Rare corruption, or a routine artefact of data migrated between systems?
2. How does IBM Enterprise COBOL treat them under NUMPROC(PFD) vs NUMPROC(NOPFD) vs NUMPROC(MIG) — and which setting was standard in the shops you worked in?
3. Have you ever seen sign handling actually flip a debit into a credit on money? What triggered it?
4. Where does GnuCOBOL diverge from IBM here? (I use GnuCOBOL as a learning bench and need to know exactly where it stops being a safe stand‑in for z/OS.)

Any "here's what really happens" war stories would be hugely appreciated.

Four months ago IBM stocks suffered a huge hit after Claude Code demonstrated some COBOL AI capabilities.

The Tech industry has been also suffering mass layoffs dating back a few years after the pandemic.

I've seen the job market in my stack suffering a lot, I'm not receiving many offers (or any at all), and I have friends unemployed and unable to secure a new job for months (sometimes 6 or 8+ months waiting).

As someone that started learning about mainframe and COBOL just now, I wonder, how did you already in the industry have suffered or observed about these recent moves?

Have any of you suffered a layoff following this IBM stocks/AI COBOL announcement?

Have you seen mainframe/cobol colleagues suffering with the mass layoffs?

I've worked with many different programming languages for the past years, and I've been focusing in Go and Scala for the past 5 years.

I'm just starting with Mainframes and looking right after Cobol, I don't know why, but Mainframes and Cobol have been growing into me. Both Go and Mainframes are the only two things that made me feel the joy of programming again after a decade of work.

However, I do wonder, what do you think about the future in the Mainframe job market, or how it has been for you so far?

Hello guys. I am a university student, and i am learning COBOL these days. I am doing this in WSL (Ubuntu). So what i want to know is what kind of editors you guys are using and any recommendations for me.

I'm not a COBOL developer by profession, but I've been spending a lot of time trying to understand how large COBOL applications are maintained in the real world.

One thing I'm curious about:

Imagine someone drops a change request on your desk for a COBOL application you've never worked on before.

What does your process actually look like?

Do you start with:

• JCL?
• Program search?
• Copybooks?
• Existing documentation?
• Dependency analysis?
• Talking to someone who knows the system?

And what usually ends up consuming the most time?

I'm asking because from the outside it seems like the coding part might be easier than figuring out where the change needs to be made and what else it could affect.

Would love to hear real stories from people who work on these systems.

A question about how these systems behave when the data goes wrong, rather than the happy path. 

When a batch program hits something like a divide-by-zero, a numeric field overflowing its size, or an invalid value where a number should be — in practice, does the typical production program abend (and the job stops), or does it carry on, maybe with ON SIZE ERROR handling, maybe with a leftover or default value in the field? 

I ask because I imagine the ‘normal’ answer varies a lot — some shops code defensively with ON SIZE ERROR everywhere, others let it abend so nothing bad slips through silently. What's been your experience of how these edge cases are actually handled, and have you seen cases where a program quietly continued with a wrong value rather than failing loudly? Any war stories there would be really helpful. 

I'm trying to understand how real mainframe applications are actually structured, and I'd value the perspective of people who've worked on them.

When you look at a production COBOL estate, how much of the meaningful business logic lives within a single program versus emerging across a chain of programs in a job stream? If you took one program out and ran it in isolation, would its behaviour be self-contained, or is so much driven by shared state, run order, and upstream/downstream steps that a single program doesn't mean much on its own?

I ask because I keep reading that COBOL programs are "more like modules" that work together as an application — so I'm trying to gauge how decomposable a real system actually is into pieces you could understand (or test) independently. Is that realistic, or a beginner's misunderstanding?

I'm trying to understand what ‘the same output’ really means when one COBOL program's output file feeds into another system. 

My assumption is that it depends on what the downstream system actually consumes. If it reads the literal characters/bytes of the file — including how a number is formatted, how a sign is represented (trailing sign, overpunch, CR/DB), how fields are padded — then two files that represent the same values but format them differently would NOT be interchangeable. But if the downstream just decodes the values, the formatting wouldn't matter. 

In your experience, which is it usually — is the exact byte-level layout and sign/format representation of an output file load-bearing for whatever reads it next, or do downstream systems mostly re-parse into values so formatting differences wash out? Trying to understand whether ‘identical output’ has to mean byte-for-byte or just value-for-value. 

Two things I'm trying to pin down about how the maths actually behaves:

1. When ROUNDED is written with no MODE phrase on Enterprise COBOL for z/OS, my understanding is the default is nearest-away-from-zero (round half up), not banker's rounding — can anyone confirm that's right for current versions?
2. I've read that GnuCOBOL with -farithmetic-osvs only emulates the older OS/VS intermediate-precision behaviour, not modern Enterprise COBOL — and seen a forum case where iterative COMPUTEs diverged significantly between the two. For ordinary financial maths (interest, premiums), is that divergence something that actually bites in practice, or mostly a corner-case curiosity?

Trying to understand where a calculation done off-mainframe would silently disagree with the real thing.

We published a breakdown of the IBM i developer retirement problem and what IT managers should do before 2030. The knowledge transfer and documentation challenges will be familiar to anyone in the mainframe space but this isn't just an IBM i problem.

https://prompteddev.com/blog/ibm-i-retirement-wave-2030

Curious what you're seeing in z/OS shops is it the same pattern?

Hi everyone,

I was recently hired as a COBOL intern. This is my first tech job, and I was wondering if you could you share some tips or advice?

I m currently freshman studying CS, and pay is ok.

Thanks in advance!

Hey everyone I want to know how to start my COBOL journey. Mentorship needed .

Which would you use in what case?

Swimm published a benchmark where they ran Claude Code (Opus 4.6) against real CMS Medicare COBOL programs. On an 18,000+ line program, paragraph coverage was 24-35%, with 42% variance between identical runs. They used it to argue against using Claude for COBOL modernization.

The framing is reasonable for their use case: automated extraction of every business rule from a massive program in one shot. But it's not what most shops actually need from documentation tooling. If you chunk the program into sections and run a targeted prompt on each one with explicit context about the business domain, accuracy is much higher and errors are catchable before they make it into your documentation.

Wrote up a practical workflow: chunk by section, use specific prompt templates (program-level summary, paragraph documentation, business rule extraction, REMARKS block generation), human review at each step. For a 5,000-line program it runs roughly 4-6 hours including review.

Article with the templates and workflow: https://prompteddev.com/blog/cobol-documentation-ai-guide/

Curious whether anyone here has tried the chunked approach vs. full-program prompts and what your experience has been.