Earlier quoted context omitted.
And yet, if you didn't mind that kind of work, you could have been making a fortune from 1999 to now. You'll be retired before COBOL is no longer used.
There is a large market for maintaining legacy COBOL, SNOBOL, and various esoteric assembly codebases. Additionally APL and its derivatives are not entirely dead.
Micro web-framework for COBOL
51–60 of 66 posts
Re: Micro web-framework for COBOL
#52I remember showing my "systems analyst" brother-in-law my second year university schedule when I was planning which courses I would take that fall. "You don't have any Cobol, PL/1, OS360 Assembly Language or APL on here", he observed. "I am going to focus on C, Unix and operating systems. I want to write compilers for microprocessor based computers". When he finished laughing, he called me "unemployable" and said, "m…
There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?" The mainframe programmer then began to describe his…
Re: Micro web-framework for COBOL
#53Earlier quoted context omitted.
There is a large market for maintaining legacy COBOL, SNOBOL, and various esoteric assembly codebases. Additionally APL and its derivatives are not entirely dead.
SNOBOL should be looked at, if for nothing else, for its string handling (add a brief look at Icon right afterwards). I would have killed to take APL in college, but despite having to program on an IBM 370 mainframe, no classes were offered. I'm still a little ticked.
Re: Micro web-framework for COBOL
#54It works very well, very fast and is under active development. Although the backend can be written in COBOL, making porting to the web quite easy, the language it actually uses is called 'Z'.
Re: Micro web-framework for COBOL
#55I once had the pleasure to meet a young person (~30 years old at the time) who had learned to program at a bank, so I had to ask her about COBOL. Her reply was interesting, if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. But if you look at COBOL as a DSL for building specific business applications, it does not look all that bad. Having never used COBOL beyond a simpl…
if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. Plenty of people get by swinging a hammer all day and not a Swiss army knife. COBOL is one person's hammer. For me, at one point, it was RPG. You think COBOL is "domain specific"? RPG has the DSL right in the name: "Report Program Generator". Yuppers, RPG is a report writer. And when you're writing banking software or t…
I was in the other side of xBase languages, did some dBase III Plus stuff, Clipper Summer '87 followed by OOP with Clipper 5.x, hurray!
High level programming in MS-DOS and were just perfect for crushing out database frontends.
Re: Micro web-framework for COBOL
#56I once had the pleasure to meet a young person (~30 years old at the time) who had learned to program at a bank, so I had to ask her about COBOL. Her reply was interesting, if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. But if you look at COBOL as a DSL for building specific business applications, it does not look all that bad. Having never used COBOL beyond a simpl…
if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. Plenty of people get by swinging a hammer all day and not a Swiss army knife. COBOL is one person's hammer. For me, at one point, it was RPG. You think COBOL is "domain specific"? RPG has the DSL right in the name: "Report Program Generator". Yuppers, RPG is a report writer. And when you're writing banking software or t…
During my training I once had a supervisor who spent years writing reports in RPG on an AS/400. She had interesting stories to tell, but unfortunately, she was always far too busy to actually tell them. :-(
Re: Micro web-framework for COBOL
#57Earlier quoted context omitted.
>> Query parameter parsing, and POST body parsing, can't do much without these. Is this to be implemented in cobol? I'd have thought they're to be implemented in Rexx, which is really great for writing parsers in.
You're first I run into saying that who isn't a mainframe programmer. It was an interesting language in summaries I read but I never really dug into it. What was good about Rexx for writing parsers?
I've worked for a big financial corp. I was in one of their mainframe teams for a year or so [1]. There's still a lot I don't know but I sure know Rexx is the most fun you can have on a mainframe. It's kind of like the polar opposite of JCL, or getting stuck on a TSO command line.
The first reason why Rexx is great for parsing is the fact that variables equal themselves. There's no "string" data type. If you type "myvar" then that's the name and the contents of your variable (unless you assign it another value):
DO INDEX = 1 TO 10 BY 2
SAY HELLO
END
/* Outputs:
HELLO
HELLO
HELLO
HELLO
HELLO
***
*/
Skipping the assignment reduces clutter and makes it very easy to see what you're dealing with. Unless you mess it up later, obviously.Second, for parsing, Rexx has a keyword instruction called ...(drumroll)... PARSE that essentially implements pattern-matching, of some sort, probably as a regular automaton like regexes but without the regex syntax which is actually really nice. Instead, you define a pattern as a string with literals and variables and the special symbol '.' (a period) to indicate any token, (that's similar to the regex '.' but it matches between spaces).
Here's an example from my notes from that time (spaces delimit literals and variables) [2]:
/* Fun with patterns at the REXXREPL*/
BANDS = 'SLAYER, BATHORY, MOTORHEAD, VENOM'
PARSE VAR BANDS ABAND ', ' BEST ', ' REST
SAY ABAND
SLAYER
SAY BEST
BATHORY
SAY REST
MOTORHEAD, VENOM
PARSE VAR BANDS . ', ' BEST ', ' REST /* Skipped Slayer */
SAY BEST
BATHORY
SAY REST
MOTORHEAD, VENOM
You can also use numbers to indicate positions in a string (absolute, in the example below, but there's also relative ones): DIGITS = '11001011'
PARSE VAR DIGITS FIRSTTWO 3 NEXTFOUR 7 LAST
SAY FIRSTTWO
11
SAY NEXTFOUR
0010
SAY LAST
11
On top of that, Rexx has "compound variables", a data structure that (to me) resembles a tree and lets you compose hierarchical structures. For instance, here's part of a program that reads in JCL files (formatted to a standard format with another Rexx program so that everything of the same kind is in the same column) and stores their DD, dataset, step and program names in such a structure: /*PARSE JOBNAME OFF FIRST LINE IN JCL FILE*/
PARSE VAR CA.1 '//' JOBNAME .
/*PARSE OTHER NAMES INTO A STEM CALLED 'MATCHES.'
EACH TYPE OF NAME GOES INTO ITS OWN TAIL
TAILS FOR DDNAMES AND DATASET NAMES ARE INDEXED IN TANDEM
SAME FOR TAILS WITH STEP AND PROGRAM NAMES
IN OTHER WORDS, MATCHES. IS STRUCTURED AS FOLLOWS:
TAIL INDEX CONTENTS
---------- --------
MATCHES.DDNAMES.N N'TH DD NAME FOUND IN JCL FILE
MATCHES.DSNAMES.N DATASET NAME FOR N'TH DD NAME
MATCHES.STEPNAMES.M N'TH STEP NAME
MATCHES.PROGNAMES.M PROGRAM NAME FOR N'TH STEP NAME
SO, TO GET THE DATASET NAME THAT CORRESPONDS
TO THE 5TH DD AND DATASET NAME
FOUND IN THE JCL FILE, YOU LOOK INTO:
MATCHES.DDNAMES.5
MATCHES.DSNAMES.5
*/
DO INDEX = 2 TO CA.0 BY 1
PARSE VAR CA.INDEX '//' DDNAME . 'DSN=' DSNAME ','
/* IF DD NAME IS EMPTY, DON'T ASSUME DDNAME='DD'*/
IF DDNAME = 'DD' THEN
DDNAME = ''
PARSE VAR CA.INDEX '//' STEPNAME . 'EXEC' PROGNAME ','
IF DSNAME ¬= ''
THEN
MATCHES.DDNAMES.INDEX = DDNAME
MATCHES.DSNAMES.INDEX = DSNAME
IF PROGNAME ¬= ''
THEN
MATCHES.STEPNAMES.INDEX = STEPNAME
MATCHES.PROGNAMES.INDEX = PROGNAME
END
(The above will probably make more sense if you've seen a jcl script before).The point is that all of that is very hard to do with COBOL, and, I believe, impossible with JCL [3]. In Rexx on the other hand, it's a doozy.
I also note that all of the above is nice to have in any language and that not very many of the languages popular outside of mainframes let you parse strings that easily, without explicitly calling a regex library or such.
_______________
[1] I raised hell until they put me in one of those teams. I could get plenty of experience with Spring and Hibernate outside of that corp. Since I was there, I figured I might as well learn something I couldn't learn anywhere else as easily. Still, people looked to me as if I was mad. "You want to be on a mainframe team? Why?".
Dude. Big computers. Millions of users. What the hell?
[2] Note that the "REXXREPL" in my comment is a Rexx program running on TSO (the Z/OS command line, ish):
/* REXX INTERPRET */
REPLPROMPT = "SAY '>>'"
INTERPRET REPLPROMPT
DO FOREVER
PULL USERINPUT
IF USERINPUT = "END" THEN EXIT 0
INTERPRET USERINPUT ; END
The INTERPRET instruction is another funky bit of Rexx that's real cool to have on a mainframe.[3] Though I'm sure there's someone, somewhere still on this planet who would laugh in my face for saying that. But probably no more than four or five people.
Re: Micro web-framework for COBOL
#58Earlier quoted context omitted.
You're first I run into saying that who isn't a mainframe programmer. It was an interesting language in summaries I read but I never really dug into it. What was good about Rexx for writing parsers?
Who said I'm not a mainframe programmer? :) I've worked for a big financial corp. I was in one of their mainframe teams for a year or so [1]. There's still a lot I don't know but I sure know Rexx is the most fun you can have on a mainframe. It's kind of like the polar opposite of JCL, or getting stuck on a TSO command line. The first reason why Rexx is great for parsing is the fact that variables equal themselves. Th…
"Since I was there, I figured I might as well learn something I couldn't learn anywhere else as easily. Still, people looked to me as if I was mad. "You want to be on a mainframe team? Why?". Dude. Big computers. Millions of users. What the hell?"
I like your style. Same excuse I had for trying (but failing sigh) to get onto a team with SGI NUMA machines. They were confused about why I'd want to do tedious work tweaking numerical applications. For 256 CPU's and 3TB of RAM in one machine? Obviously...?
Note: I imagined it had time in between jobs and a quota system not designed with people like me in mind, too. ;)
Re: Micro web-framework for COBOL
#59Earlier quoted context omitted.
if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. Plenty of people get by swinging a hammer all day and not a Swiss army knife. COBOL is one person's hammer. For me, at one point, it was RPG. You think COBOL is "domain specific"? RPG has the DSL right in the name: "Report Program Generator". Yuppers, RPG is a report writer. And when you're writing banking software or t…
FoxPro! :) I was in the other side of xBase languages, did some dBase III Plus stuff, Clipper Summer '87 followed by OOP with Clipper 5.x, hurray! High level programming in MS-DOS and were just perfect for crushing out database frontends.
Re: Micro web-framework for COBOL
#60Earlier quoted context omitted.
You folks think you're being funny but I have vary off the interface on our iSeries to move it to a different ethernet switch then do an IPL over the weekend.
What's the reliability of the iSeries models in terms of the per-server failures? And have they worsened or gotten better on reliability or admin side than the AS/400's that preceded them? Just curious about such things.