From: Dan Cross <crossd@gmail.com>
To: segaloco <segaloco@protonmail.com>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: Bell COBOL Environment?
Date: Thu, 13 Jul 2023 22:14:36 -0400 [thread overview]
Message-ID: <CAEoi9W6BzoL0OoVCFefbgRAxVtET7gf23AqMmv+VYU7cJTZ5Zg@mail.gmail.com> (raw)
In-Reply-To: <jM9VnbNYQhLaC8aOAM1YUWeWQ824ureo_F2I8-yCx639Qej60ce1g8kU3dPP1Ov-qO0798MSZBFaxJ19Iqp3rN7O5PjaSregi89V_wb1VXs=@protonmail.com>
On Thu, Jul 13, 2023 at 6:36 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL. Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN. Would that be a fair characterization?
Echoing what others have said, that seems reasonable to me. Don't tell
the mainframe infosec folks about this; they get really touchy about
defending COBOL's honor for some reason I don't quite understand.
> Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical.
A way to think about COBOL is that it's like a DSL for business
transaction processing, but is itself a small part of the overall
offering. In the mainframe world, it's often intimately tied to things
like CICS, ISAM, VTAM and 3270 access methods, SNA, and so on, and in
that sense the language itself is a rather small part of the
ecosystem. Transferring everything into a new environment (e.g., on
Unix) raises a lot of questions about the surrounding technologies and
their non-availability, and ultimately just having the language by
itself isn't terribly useful if you don't have all the other stuff as
well.
Also, COBOL is just a terrible language.
- Dan C.
next prev parent reply other threads:[~2023-07-14 2:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 19:02 [TUHS] " segaloco via TUHS
2023-07-13 20:34 ` [TUHS] " Clem Cole
2023-07-13 20:50 ` Arrigo Triulzi via TUHS
2023-07-13 21:41 ` Kenneth Goodwin
2023-07-13 23:02 ` Clem Cole
2023-07-13 23:19 ` KenUnix
2023-07-13 21:42 ` Jon Forrest
2023-07-13 22:35 ` segaloco via TUHS
2023-07-13 23:20 ` Warner Losh
2023-07-14 0:20 ` Bakul Shah
2023-07-14 1:16 ` Alan D. Salewski
2023-07-14 1:05 ` David Arnold
2023-07-14 1:45 ` Clem Cole
2023-07-14 2:14 ` Dan Cross [this message]
2023-07-14 8:46 Paul Ruizendaal via TUHS
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEoi9W6BzoL0OoVCFefbgRAxVtET7gf23AqMmv+VYU7cJTZ5Zg@mail.gmail.com \
--to=crossd@gmail.com \
--cc=segaloco@protonmail.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).