@@inerlogic I would totally buy a T-Shirt inspired by this Awesome UA-cam Channel. Something about the title of the Channel. Maybe various 8 bit memes on the shirt.
I enjoyed the gentle humor in this video. Back in the Jurassic, along with all the other dinosaurs in our Fortune 500 corporation, I wrote COBOL code for over 15 years. No one ever referred to a variable as a "PIC", but rather as a variable or a field. However, the variable format statement was referred to as "the PIC clause".
SAME. I programmed in COBOL in the 1980s and 90s. We usually called a PIC clause a "field", or those of us who could also program in other languages (such as BASIC, C, or Fortran) it was a "variable". It all depended on who you were talking to. In all those years, I never recall using the term "picture". Not saying it is incorrect, just mentioning I never used that term with two different employers (US Navy and an insurance company) during that time period.
I am 59, and retired from a good 35 year career as a COBOL programmer. It paid me well. I have a house in SF to show for it. I spent a good part of the last ten years teaching people who learned other languages how to program in COBOL.
We're about the same age, my friend had a similar story.. When his daughter was in middle school and in a first class on computers she 'informed' the teacher that COBOL still existed and her father worked writing it. She's grown up and married, and her father still working on code bases there's no money to re-create. Not a house in SF, but Glendale AND a timeshare in Hawaii and that daughter years in ballet lessons.
How would you rate Abacus' COBOL-64 and COBOL-128 for seriously learning the BASICs? (Pun may or may not be intended). I bought both in the mid-1990s but had an abrupt career change in 1999/2000 which forced me away from my beloved Commodores and into the arms of Linux, Apache, MySQL, and PHP which I also love and have been using for the past 24 years. This week, however, I have finally found all the right ingredients to getting my old Commodores back in action... and I'm running VICE on my Linux box with SD cards for easy back-and-forth between the two. I just found and imaged my old COBOL-64 and COBOL-128 disks today and am seriously considering starting over with them now that I can again.
My very first job interview was at an insurance company. They were hiring people to be either Java or Cobol programmers. They provided training for both, so they were accepting people fresh out of university. The interviewer asked which language I preferred. I told him I preferred Java, but happy to learn Cobol as well. The guy looked me straight in the eye and slowly moved his head from side to side saying: "No, you don't wanna do that". That was the first and the last time I came across Cobol during my carrier. Coding in Java every since :).
999 got lost because you never pressed return on that line after changing 9999 to 999 (12:17). I sat there saying, "press return! press return!" but you never did, (12:26) and I knew it was going to surprise you when you ran the program. lol. great video.
@@CommodoreFan64 i'm liking the virtual nascar.... although.... i think they over reacted with Larson.... people make millions using that word in public...
Hey Robin. I'm so glad you did a video on this. I stumbled accross COBOL 64 a few months ago and fooled around with it a little. "80", Robin? Come on. I'm only 49 and I had a 17 year COBOL career and loved it. I'm no longer a developer in the work place, but COBOL has always been and is still my favorite language. I really miss it. With the the recent demand maybe I should take a leave of absence from my current job for a few months and go get a COBOL job. They should be paying a ton for them, given how hard is it to find COBOL developers these days and the current crisis. I still have print outs of every COBOL program I wrote in college. COBOL FOREVER!
I remember Compute! magazine running an April Fool's Day article about the impending release of Atari COBOL. At one point the article explained that the Atari's memory limitations required leaving out one of the four divisions of a COBOL program, and they decided to do without the procedure division, explaining that only power users were likely to miss it. It's kind of hilarious that there actually was a COBOL for the C64.
My first programming job when I graduated in 1975 was a COBOL programmer. This brings back happy memories. You have to remember that the alternative languages at the time were the equally bad FORTRAN, low spec BASIC which few people used for serious projects, ALGOL-60 if you were very lucky (no-one could ever figure out ALGOL-68), or just working in the assembly language of the computer you had available (which meant re-learning a new language if you went to another job). There were other languages around but they were very niche. Structured programming was seen as a fad that not everyone was convinced was worthwhile, and object-orientation was way off in the future. COBOL was based around punched cards, so having fixed columns wasn't a problem, since you could easily set up an 029 card punch machine to skip from column to column as easily as pressing the tab key in an editor today. It wasn't compulsory to have a number on each card; however, if you ever dropped a massive card deck (and it did happen!) then having card numbers allowed you to use a card sorting machine to put them back into order.
@@richardperritt Do you mean COMAL? I learned a bit in secondary school in the early 1990s, but preferred to just stick with C64 BASIC mostly... but COMAL didn't seem too bad, especially compared to COBOL!
Well, I'm really impressed that someone got a working and reasonably ANSI-compliant version of COBOL for the C64. I'm not surprised it a just a bit clunky though. It is probably also an interpreted implementation, which would not contribute to speed. A few random points: The "CHR " phrase of a data declaration is an extension from ANSI C74. It is useful in the case of a C64, but it is not literally part of the ANSI spec, though the ANSI spec does allow for extensions like this. The "STARTUP." label after PROCEDURE DIVISION. isn't a section name, it is a paragraph label, just like the label immediately following. A section name would be "STARTUP SECTION." C74 did not require section names, though some implementations erroneously did require them. A section (in the procedure division) consists of a section header line and one or more paragraphs. A paragraph consists of a paragraph label and one or more sentences. A sentence consists of one or more verbs and related constructs, and is terminated by a period. In the case of an IF statement, since it is a single statement, you do not put a period until the end of the ELSE clause (if you have one). But if you have a sequence of statements that are not part of an IF, you can have a period at the end of each clause. For instance, you could have done: MULTIPLY SEED BY 214013 GIVING WORK. ADD 0.2531011 TO WORK. MOVE WORK TO SEED. All three of those sentences would be part of the same paragraph, which runs from the RNG paragraph name to the next paragraph name (or end of program source code), in this case the END-PROG paragraph label. You mentioned that your random number generator needed to use values for a 32 bit binary number. You aren't working with a binary number, you are working with decimal numbers. Look up random generators in Knuth. Decimal generators can work just fine, but you use different modulus values and seeds than you would for a binary generator. The action of moving from WORK to SEED is giving a mod function that is a power of 10, not a power of 2. If you want a remainder other than an implicit divide by 10, you could do something like DIVIDE WORK BY 123 GIVING WORK, REMAINDER SEED, if I recall correctly (I don't have my manual handy at the moment). You don't have to use GO TO. You could do something like PERFORM LOOP 10000 TIMES or PERFORM LOOP UNTIL DONE and make the loop into a performed section or paragraph. No compliant COBOL implementation *requires* line numbers. The line format is 1-6 sequence number field 7 flag/comment marker field 8-11 A margin 12-71 B margin 72-80 (really 70 to end of machine-defined line length) patch marker field While the first 6 columns are for sequence numbers, a compliant COBOL should accept all blanks. COBOL was originally input on punched cards, which are more easily used as a fixed-format input medium than variable-format, like a keyboard and CRT you are used to. Many vendors implemented variable input formatting options for their COBOL implementations that relaxed the strictness of column 6 and the A and B margins and made sequence numbers optional or variable length. This was done for all versions of COBOL going back to COBOL-60, depending on the vendor. It has nothing to do with C85 to not require sequence numbers.
My COBAL/RPG experience was a Data Entry class back in 1980 using 8-inch floppies and an IBM S/32. I ended up being the SYSOP for the system and was able to get my assignments out within one day using the console while the rest of the class had to wait for the typists to enter their programs on the 8-inch floppies. Fun times!
I used to teach from BOTH the COBOL 74 version of the book you have at the right and the COBOL 85. PIC directs a "picture" of how the input/output will be formatted and controlled between numeric and text (among a few choices). You can choose characters by placing them in quotes without using ASCII/EBCDIC numeric references. The positions had to line up based on the original punch cards. On better compilers the errors are clearer. COBOL 85 fixes a lot of old language issues. COBOL 74 was designed for uses on computers barely as capable to do BUSINESS math and BUSINESS reporting on mainframes. If the mainframe has upgraded to terminals from card punches, the editors simplified numbering of lines. I taught COBOL 74/85, FORTRAN 77, 360/370 BAL, RPG II/III/IV/ILE (the latter on iSeries) for over two decades at university. However, I learned on punch cards. You REALLY appreciate terminals after having used punch cards. The editors were (generally) great and the operations software for multi-user systems were nicely designed. When we switched to MVS/TSO, I was able to flip between the editor, submission of files, and printing of output by fast tracking. There was only one down side back then - if a student's program crashed during CICS programming (creating a UI that worked "live"), it crashed EVERYBODY in CICS and took 20-30 minutes to reboot CICS.
Great video. COBOL is a "declaration by example" language, so that's why you use PIC to give a "picture" or a "general example" of what you want a data field to look like. Your program could be shortened, lots of the code is not needed or could be simplified / shortened. Instead of using evil GOTO you could use PERFORM VARYING ... which is the COBOL equivalent of a FOR loop in basic. COBOL does tend to be a very verbose language, but it is very powerful. e.g. you can filter and sort files in a few lines of Procedure Division code.
Great video Robin. What flashback. I had a year of COBOL on my college course in ‘94. Couldn’t understand why we were being taught it. On the run up to y2k I worked with a ton of COBOL programmers on various projects. They earned a fortune at all these financial services companies keeping their old systems up to spec.
The millennium bug provided a lot of work for a lot of older programmers that still knew languages like COBOL :) It kinda drives me mad when people claim the millennium bug wasn't even a real problem, as they overlook the huge amount of effort that went into making it not be a problem.
0:21 I'm old enough to have actually learned COBOL as an undergrad, which is also the last time I ever encountered it. (I guess you did, too.) 1:02 There's where to put the three zero bytes you had in a previous video. But it seems odd that they didn't just put a line of BASIC there so you don't need to know the start address. 2:24 Requiring a specific syntax of English prose doesn't make programming easier; it just means more typing. A complex syntax with a bunch of auxiliary words will be harder to remember than abbreviated syntax like with C. The opposite extreme would be APL. The advantage they might have been trying to state is that it might make it easier for a non-programmer to read the gist of the code. Of course, this is what comments are for! 3:41 Geesh! Okay, that's why nobody uses COBOL today except to maintain legacy systems that were programmed in the 1960s. 4:05 If this compiler is from 1984, it probably wouldn't support COBOL-85! 7:40 Why would the "VALUE" come before the "PIC" on some lines but not others? 9:53 We can have some sympathy for them stuffing a COBOL compiler into the C64 and leaving room for your program. 10:30 Are all variables global? The functions don't seem to take or return parameters. If so, then COBOL isn't inherently any more scalable than BASIC. LOGO had the same problem. 11:31 If none of the statements inside an IF need a terminal "." character, then the language can parse the statements independently (I guess from the strict indentation) and the "." terminator isn't needed in the language at all. 13:40 How does COBOL handle numeric overflows? The C64 version is using base-10 numbers, right? (Or BCD?) You don't need a MOD function if you have overflows. Base-10 RNG with overflowing integers should work just as well as base-2. If you can do a PEEK, you could use the low byte of CIA-1 Timer-A for a random number between 0 and 255 (which is basically what RND(0) in BASIC does). (Or use the SID chip after some setup.) 18:24 So, there's no compiler? Is this just interpreted? It looks a lot slower than BASIC!
Yes, all variables are global, and there doesn't appear to be any way to pass or return values when calling a paragraph with PERFORM. Yeah, it's essentially doing a base-10 "MOD" when moving the WORK variable into SEED. There's an ON SIZE ERROR clause that can deal with the overflow, but I'm (deliberately) not using it. There is no PEEK equivalent that I could find. This implementation is really simple, though I doubt the standard COBOL-74 has a PEEK either. The manual makes reference to there being both a compiler and an interpreter. If anything, I'd guess that the compiler turns it into an intermediate form which is then interpreted. The ~160 page manual is very light on technical details.
A paragraph is inside the current program, calling another program, linked in, would require you to set up a linking section and whatnot. This weekend I spent too much into the COBOL rabbithole 😀. Perhaps it is the version, but a loop like that would be done with a perform Paragraph 1000 times. The dot is for the compiler and programmer to know the end of a sentence. Quite like ALGOL68 and derivatives. For it being verbose; code is more often read than written so typing isn't considered an issue. Trouble is when too much code is crammed into one program and not neatly paragraphed or is copy pasted. That happens in any language and makes maintenance difficult in everywhere.
It doesn't matter, if "PIC" or "VALUE" comes first. I'm not sure about Cobol-74, but in Cobol-85 you certainly can return values (which is, why I find the use of "RETURN-CODE" in this video/program a bit unfortunate). BTW: If you're worried about scalability: There has been Object-oriented Cobol for a long time now.
Did all versions of COBOL have a set number of digits it could handle? My undergrad COBOL course leaves me with foggy memories of it doing most math the long and slow way and not using built-in types of the CPU archetecture. As in, doing math column-by-column and handling overflow in the language instead of the built in CPU overflows.
Having worked with COBOL in the mid- late nineties on a mainframe, it's quite amusing you managed to re-produce 10PRINT - great job as usual. It's still an option on the mainframe systems I support (z/OS), though I believe IBM will pull support soon'ish. COBOL is still rampant across legacy mainframe driven banks, airlines and other large customer base systems. It's reallly useful for processing large amount of repetitive transaction data, producing statements etc. But you knew that Robin. :)
Saw some used for a credit card transaction for Eaton's in Canada. I wrote some software for a company so they could data mine transactions for possible future purchases.
Actually SQL was also created to manage big databases. I started to learn these things in 1996 in schools, and after Turbo Pascal, Turbo C and C++ we learned the SQL. It was very easy to understand the syntax and the logic of the queries.
@@MMSZoli Yeah, and you can just use DB2 for that - but an awful lot still has embedded COBOL with embedded SQL/DB2 transaction code. I've still got my IBM manuals...
I started writing Assembler and COBOL using a card punch machine almost 40 years ago. Today, the card punch machines are gone but I still write in Assembler and COBOL. A few things have changed over that time (introduction of Concept 14 Macros for Assembler), but much if remains the same. I remember being told COBOL was a dead language 25 years ago and it would soon be all replaced. I still laugh all the way to the bank.
I programmed in COBOL (among other languages) for several years (1970's-early 80's). Two major failings (at the time): 1) No END-IF statement, which meant those idiots who used nested IF's could never get the logic right, and 2) no independent subroutines or functions (where the name-space was independent). PERFORM was equivalent to old BASIC's GOSUB, with similar associated problems. You could keep your nose clean by always using PERFORM paragraph-name THRU paragraph-name-EXIT. The one big advantage that COBOL had was flat-file record definition and redefinition. No language that I've seen since the 1970's does this better. For a couple of applications at the dawn of the microcomputer era I used the (in)famous Nevada COBOL ($29--cheap!). I had to debug and patch the run-time module so that it would work with my terminal (that's right--no monitor, a terminal linked to the micro via a 19,200 baud connection). I even wrote an 8080/8085/Z80 disassembler (to run under CP/M) using Nevada COBOL. Great times! Postscript: PERFORM ... VARYING. OMG. Idiots could never get this right. I always advised people to just code the loops manually, using a starting point and an exit label, and IF-logic. Whenever I had to debug someone else's code, the error was always in a nested IF or in a PERFORM ... VARYING.
I’ve had a bunch of head hunters contacting me for COBOL year plus contracts. $180k+ working for states contracts. Current COBOL has changed, you can do XML and all kinds of stuff. I’m sticking with my java/angular work.
Ahhhh, Memories.... I spent 10 years in the military starting in 1987 writing COBOL apps. Some mainframe in COBOL 74 and some for PC Microfocus (later bought by Microsoft) COBOL 85. To turbocharge the UI side, I wrote x86 assembly routines that our PC COBOL programs would call. Many years later, in 2005, In a Master's Programming Languages class, we had an assignment where all our teammates had to solve a common project, each with a different language. I did mine in .NET COBOL. :)
Commodore 64 continues to amaze me! That little 8-bit computer still running all the classic languages: Pascal, Cobol, Forth, Fortran, Logo, C and even a minimal but working Linux system! (Lunix)
Me too. I eventually graduated and went on to teach at my undergrad college and by then they had gotten terminals. While I felt jealous, I have to admit it was MUCH easier to teach on.
A lot of the formatting requirements make sense using 80-column punch cards. The line numbers mean that things won't break if the cards get shuffled. An asterisk comment can be added to an existing card.
@@markevans2294 The obstacle on the C-64 was the 40 column screen. Not insurmountable of course, but creating various workarounds isn't ideal for COBOL. Also, COBOL itself has no interactive system. It's simply an IPO system based originally from those punch cards. When IBM implemented CICS, it based it on a fast version of that - you created the screens in BAL, and when the user pressed enter the COBOL program was started from scratch with data from the BAL screen. The COBOL ran briefly and and returned data into the BAL screen it needed. When it worked, it was elegant. When it didn't, every single CICS user was waiting 20-30 minutes. I hated punch cards. Punches that crunched cards (we called them card crunches), the whole "carry them around" aspect. My experience with them at school went like this: 1. After getting approval to punch my cards (fine) I had to then schedule an appointment to use the punch in one hour blocks. Not terrible - they were relatively short programs. If you had the time, make a duplicate. 2. Walk the cards to the operator, who looked like someone from the dead. He ran the stack though a counter and gave me a bill to take to the cashier across campus. 3. Cashier accepts your money and provides two receipts - don't lose because one was for the operator. If you had to go through that cycle again, there was an extra charge. 4. Back to the op and hand him the receipt. He bands them to the cards so that some geek in the back whose ONLY job was to run jobs knows that the jobs was paid for. 5. When you come back TOMORROW, if the job was done you received it. Finding out what ops and jobbers liked in food could mean getting your job in an hour. 6. Look at the job, sometimes a typo, but I was a good punch so I rarely had typos. Syntax errors and semantic errors - part of the learning process. The school also charged for cards and paper used. Not sure where that was kept track of, but we'd get a bill at the end of the semester. When terminals were brought in, I asked students and found out that they were charged a flat fee (easily three times what I paid) when they registered. If they dropped, they lost that fee. When I was teaching (during grad school) the terminals were easy. There were 30 of them. Beautiful jade green screens. I miss them... :-( There was a line printer that printed massively fast. Teaching students how to use the system was easy. I took pics of the screens with a camera (film - some developer must have wondered if I was a Russian spy). I used it on my PC to rebuild the screen in a graphics program and make a set of instructions that basically said "to do this, go to the screen that looks like this and fill in the blanks". I knew the people who would drop because they couldn't look at pictures and follow directions. I still have the directions. Do people remember the green/white coding sheets and print chart sheets? How many people have printer spacing rulers or their flow chart template? I do... :-) This was a great video - I'm sure you did also Mark!
I used COBOL on IBM mainframes. To get the modulo (remainder) you do DIVIDE A BY B GIVING C REMAINDER R, which means C=A/B and R=remainder. I looked into the COBOL 64 manual (page 91) and doesn't mention this. So my guess is that this COBOL version doesn't have modulo implemented on it.
My favorite "inappropriate" combination of a computer and a programming language is still Pascal for C64, but Cobol is another contender. It begs the question, has anyone really used them on a C64? For non-academic purposes, I mean?
@@QuintusCunctator "Inappropriate" as "useless"? I have used Turbo Pascal for CP/M on C128 and that was very useful, especially with easy way of inlining Z80 code into program. Oxford Pascal on C64 was also usable - for similar purposes like BASIC 2.0.
@@tym0tym No, I meant "inappropriate" as in "barely fitting in a stock C64 memory and CPU". I'm looking at the manual of Pascal 64 by First Publishing, and it says that e.g. when using pointers and the NEW instruction, since there is no "free memory" instruction, one should follow pointer-intensive code with a "LISTINIT" instruction, which in turn performs garbage collection, or receive "out of memory" errors along the way. I can only hope other implementations did better, but I still imagine running Pascal on a C64 is a feat in and of itself, hence my observation.
@calcmandan I'll quote the Super Pascal manual: "First it's a difficult task to put a Pascal implementation into a computer the likes of the c64; its memory capacity, the fact that it is an 8 bit machine, and its i/o functions require some changes from any mainframe versions of Pascal. Second, a complete language and programming system had to be set up within the 64 which would bypass the standard OS, and cut down the time factor."
For a background to COBOL look up Grace Murray Hopper, a very smart lady. I learned COBOL in the late 1960s, but never had to use it in anger. It was clunky, but filled a niche. First, it was strictly for business problems which were about record keeping, so it emphasised defining and manipulating records and files. Secondly, laying out the hierarchical structure of the fields and subfields in the records was an important part of the language. I think it was one of the first languages which enforced strict data typing. There was an idea that the process could be made more intuitive by defining those hierarchies graphically on paper (pictures) and then coding from these diagrams. I have come across other early languages which tried the same idea. And yes, the procedures were in "English", which can be a wordy experience and the syntax checkers were inflexible. But these had to run on systems which in many respects were less powerful than the C64.
COBOL is very sensitive to what column you are in. Columns 1 to 6 are optional line numbers. Column 7 is the "is this a comment?" column. Columns 8 to 11 are "Area A" which are for the declaration of sections and paragraphs. Column B starts in column 12. On mainframes this then runs up to column 71. 72 is the continuation column (because you have 80 columns, because of Herman Hollerith.) Lovely stuff. COBOL-85 was a big improvement. END-IF statements! Full stops ending scope are still an irritation today though. I converted a BASIC Moonlander game into COBOL for my own amusement. COBOL doesn't have a MOD function but does have DIVIDE something BY something GIVING something REMAINDER mod function. I've just checked in my books upstairs and "COBOL for the Eighties" (published 1982) has it. Wonderful stuff! Wouldn't use it for missile defence of course, or astronomy!
I began my IT career around the same time as your university example. I remember being eager to take c++ and other object oriented programming in university, but was required to take COBOL as a prerequisite to those courses. I quickly learned about COBOL's unforgiving nature, and I became so frustrated with the language that I ended up having to take the course twice - and still only squeaking by with a very basic understanding of it. I think I had flashbacks when your programme failed to print the stats the first time around! That reaction perfectly sums up my memory of this language - "I'll run it... if I feel like it". *shudder
Something so much more intrinsically satisfying watching development on actual hardware vs an emulator. I realize this isn’t always as efficient but sure feels nice to see a real C64 with an accelerator.
> start watching this video > see the very distinctive box style of the Cobol for C64 box show up > immediately pause the video, raise my arms up and say "oh wow, glory be to Abacus Software, you really didn't know when to stop making crazy stuff for this thing" (or something like that) No seriously this is a company that has a bunch of strange businessy things in between their dozens upon dozens of books about the 1541 or Amiga (specifically). Now I really need to be on the lookout for their XPER series because these kinds of old productivity software packages fascinate me in a quasi-nostalgic-for-mid-90s-Microsoft-Office sort of way Apparently Abacus also made a C compiler for the C64, which now makes me wonder what other forgotten (since C isn't forgotten but COBOL mostly was) programming languages exist on the thing. APL? I also have a book called COBOL For Beginners by Christopher Lampton. His "For Beginners" books name a whole bunch of microcomputers; I have a couple more of them buried around my room somewhere...
NSULA required all CIS students to take COBOL programming when I was there in 2003-2007. No one really understood why we were learning such an old language. The professor explained how there were still tons of these businesses still running everything in COBOL and that if you know how to code with it then you became a very desirable prospect to employers and almost guaranteed to make big money.
I was a COBOL programmer 1992 - 2001 or so. I worked with DEC VAX systems then. Think it was COBOL 85 but can't be sure. The line numbers were optional thankfully. :) . The strict requirements for line number length etc comes from the fact that COBOL statements were originally punched onto cards so the column positions were important so the card readers would work properly. COBOL can run in the .Net framework now. Microfocus have produced a compiler and IDE for it. So much legacy code exists that the cost and risk of redeveloping some systems simply isn't worth it - but - COBOL code is one of the few languages that has proven genuinely portable. It's OK to call those level 77s variables. I used to prefix them with "WS-" so I knew they were working storage variables. COBOL also let you bind variables to files, records and fields in the DATA DIVISION so it was good to prefix the variables so you didn't mix up working variables with bound file variables. The PIC clause just defines the data type. I never used 77s - just used level 1. Level 88 was an interesting variable as it let you declare special condition names dependant on the values of the variable that could be used in IF statements. Was a nice concept. You also don't have to use english in conditional statements - you can use the arithmetic equivalents such as < and = etc. COBOL was one of the first third gen languages and of course there was too much hype about it. I think the legendary Grace Hopper was involved in the creation of the first version of it - or at least a very early language that COBOL was based upon. Worth googling about her. :)
I was a COBOL programmer from 1986 until 2000. Once all the Y2K changes were done I transitioned on to other languages and systems. At one point in there I was working for a company where we did all the COBOL development and testing on PC's before uploading the code to the mainframe. Those PC's were running OS2. I never heard of COBOL for the 64 before and I would have probably wanted to check it out at the time.
That was hilarious! Also, the COBOL you were writing here looks more familiar than your code from the early 90's. I didn't take the course myself, but as a CS LAB tutor, I helped debug a lot of it.
Great video, as usual. I think you deserve a medal for putting up with COBOL for two days! It feels like the language was designed with the dual goals of being "readable" for non-programmers, and driving programmers to madness!
COBOL stands for COmmon Business Oriented Language, very much intended to be read and reviewed by actuaries and other people from the Business side of companies. Not sure if that actually happened though. As the Wikipedia page states: ... though intended to be English like, not easily comprehensible ...
@@MeriaDuck I used to work hand in hand with actuaries and accountants in an insurance company in the early 1990s. I maintained many a COBOL program. The running joke at the time was that an actuary is an accountant without a sense of humor. I found that statement to be quite accurate over the years.
Here's a modern COBOL listing for the PC. RANDOM and MOD are included in COBOL now. I added REPOSITORY so I don't need the word FUNCTION in front of any intrinsic functions such as RANDOM and MOD. LEFT, RIGHT and COUNT are all reserved words in COBOL so I changed them. DISPLAY automatically does a CRLF unless you tell it not to to so I included LINE-LENGTH to set the width to the same 40 characters wide as the C64 and printed the CRLF at the end of each 40 character line. IDENTIFICATION DIVISION. PROGRAM-ID. TEN-PRINT. ENVIRONMENT DIVISION. CONFIGURATION SECTION. REPOSITORY. FUNCTION ALL INTRINSIC. SOURCE-COMPUTER. CORE I7 MODEL 7700K. OBJECT-COMPUTER. CORE I7 MODEL 7700K. DATA DIVISION. WORKING-STORAGE SECTION. 77 LEFTCOUNT PIC 9999 VALUE 0. 77 RIGHTCOUNT PIC 9999 VALUE 0. 77 TOTALCOUNT PIC 9999 VALUE 0. 77 LINE-LENGTH PIC 99 VALUE 40. PROCEDURE DIVISION. PERFORM COUNT-LOOP 999 TIMES. DISPLAY " ". DISPLAY LEFTCOUNT "+" RIGHTCOUNT "=" TOTALCOUNT. STOP RUN. COUNT-LOOP. IF RANDOM IS LESS THAN .5 DISPLAY "\" WITH NO ADVANCING ADD 1 TO LEFTCOUNT ELSE DISPLAY "/" WITH NO ADVANCING ADD 1 TO RIGHTCOUNT. ADD 1 TO TOTALCOUNT. IF MOD(TOTALCOUNT,LINE-LENGTH) IS EQUAL TO 0 DISPLAY " ".
PIC defines the actual layout of the variable both in memory and on screen / printouts unlike binary comp and you would normally use PIC for formatting output and comps for calculation (hence the PIC). Main drawback was the amount of memory they took - effectively one byte per character and core (yup that's what started with) was expensive. My first commercial role was in Cobol 85 having been given the basics at college and compared to Algol / Fortran / APL (the other commercial languages I used around then) COBOL was a breath of fresh air and was a lot easier to read till someone decided to use a variable for the wrong task and did not rename it (level 66)! OK it saved a few bytes (vital somedays to stop paging to disk) but really buggered you up if they did not document it! Thank you for bringing this back - I used the older PET machines (in 6502 / BASIC / FORTH) but did not know COBOL came out for any Commodore machines :-). Microfocus was and (still is I think) the main driving force for COBOL on smaller machines so to see another supplier was very interesting.
14.28 The COBOL mod statement is buried in the DIVIDE syntax. Coding a mod operation can be as easy as typing "DIVIDE FIELD-A INTO FIELD-B GIVING FIELD-C REMAINDER FIELD-D" (quoting most of an example from "Murach's mainframe COBOL".)
Very cool, it is the first time I see actual COBOL code. Thanks for showing. I looked for your 2nd channel but couldnt find it under Info on this channel.
I took 3 quarters of COBOL at my college, it was done on a DEC-10 (Mainframe) and terminals (Hazeltine, ADDS, and others lost to time) for my final project I ported wrote a simple video game I wrote for the VIC-20 called "Atomic Battleship" (not as popular as "Muncher"), I had to figure out how to use cursor control and I too had to write a Random Number Generator, based loosely on Dr. Knuth's algorithm book. At that point the instructor said "I guess business programming isn't your passion"... He was right, and I went on pursuing my Computer Science Degree. BTW: PIC 77's were special pictures, I think that's how I was able to do cursor controls for the various terminals (open a file and load the control sequence characters) and there were a few other cases, but dang it if I remember what they were. Also I think you could have written: "Add 1 to " and avoided the "giving" so "add 1 to count." but COBOL 74 might not have had that, The COBOL I learned back in 1983 had over 200 keywords, and all of the best ones were taken ... LOL. Memories :-)
This 74 year old dinosaur spent 20 years (‘75-‘95) witting COBOL. I’ve probably written close of a million lines of that stuff. Well written COBOL will not have any GO TO statements. Most version allow PERFORM xxx UNTIL yyy, allowing fully structured coding.
If someone didn't say already when you changed 9999 to 999 you didn't press RETURN to actually submit that change which you can see when you listed from 2900 onward and you can see that line still shows 9999. When you made the change I was actually watching to see if you were going to press RETURN and noticed you hadn't and it was confirmed when you did the next LIST command revealing the unchanged line.
My one and only COBOL program is a game of checkers I wrote for my mom's 68000 based TRS-80 Model 12 in the 80s (she used it for accounting). This was under RM/COS- Ryan Mcfarland COBOL Operating System. It showed the checkerboard in TRS-80 graphical characters- I remember there was no equivalent to BASIC's CHR$(), but I don't remember if it had the "CHR 206" thing, but there must have been some way. RM/COS was a kick- I remember it had a hierarchical directory system sort of- there was a single main directory, but files could be indented into lower levels- '.' was the path separator. It supported multi-tasking- you had to partition the memory ahead of time to decide how much each task should get.
It's funny that you make this video now. In about two months, I have to start creating a port of a COBOL program to some modern programming language. A central part of the financial calculation of our company depends on this COBOL tool and has done so for pretty much forever. It is amazing that it is still up to the task, but enough is enough. I won't have to learn COBOL however. We tried to find out everything this black box does and can do and reverse engineer it.
Very interesting, I cut my programming teeth on COBOL in the 80's and I've just brought myself an original C64 breadbin and the new C64 Maxi. Watching this video brought it all back. I'll be downloading it for sure. Many thanks for a great video.
I am not too ancient (51) :-) but did learn some COBOL at business school, using ICL mainframes and the fun part was doing this using teletype terminals. Was at the Mid-Kent College, Rochester, Kent, UK. When you showed the code, some of the stuff came flooding back. Thank you!
Since you always strive to make your programs short and efficient, I would suggest to be a bit more creative with defining your variables like this: 01 work pic 9(7)v9(7) value 0.1. 01 filler redefines work. 05 filler pic 9(7). 05 seed pic v9(7). That way you get an "implicit" mod function and can remove the line move work to seed from RNG. BTW: Even if your manual avoids using the term "variable". In Cobol it's not called "picture". "Picture" is the FORMAT of a variable (data-name, item .....).
This code works because COBOL by default stored values in Binary Coded Decimal (BCD), instead of the common int and float formats we use today. All arithmetic was therefore done in base 10. Slow, but accurate.
To be fair to COBOL, it was really one of the very first languages ever created for computer programming, and they didn't really know what worked and what didn't work well at that point. Because it was so widely used, by the time COBOL-74 came around they couldn't change much without breaking 15 years of code written to that point (yes, COBOL was created in 1959, based at least in part on Grace Hopper's FLOW-MATIC language!) so a lot of things like basing important details on column numbers stuck around until well after punched cards were used. That's why, for example, the first 6 characters had to be line numbers, with actual statements starting at 8 or 12. There was a whole specification on what columns were for what... I believe there was a special symbol if you wanted a line to span across two physical cards (80-character cards, of which you've already lost 12 characters for the bulk of your program, so it's not hard to imagine needing multiple cards). Anyway, if these languages pique your interest, there's a book by Jean Sammet written in 1969 titled "Programming Languages: History and Fundamentals" which pretty much covers every single programming language that had been created up to that point. Nowadays such a book would be impossible!
I got all excited thinking this language had something, Jesus I'm so glad I didn't start programming in COBOL - I definitely would have become a footballer or something instead of a programmer :D
Honestly, COBOL wasn't that bad. It looks bad only because you're able to compare it against modern languages, but at the time plenty of programmers enjoyed using it. I certainly did. Of course, looking back now I can see how limited it was, but no-one was aware of those limitations at the time. And of course, the money was good!
@@mandolinic There is one great thing about COBOL, those structured records that are almost database-y. Everything else... ugh. Of the contemporary languages If I could have those combined with Algol, I'd be a pretty happy bunny.
No kidding - COBOL is still a big business right now for consultancy companies migrating COBOL off IBM mainframes (these license costs!) using stuff like Micro Focus. You would be amazed how much of this stuff is still working in banking. For more C64 programming languages I have seen Dan's nice page telarity.com/~dan/cbm/languages.html . Apart from ADA, FORTH, FORTRAN there is more exotic stuff like COMAL or MUMPS.
Everyone did COBL @ university, and then forgot about it, except knowing that you have to get stuff in the right columns, and thought "gee that's a bad idea", (I'm looking at you python)
I programmed in COBOL for many years. I found it to be pretty easy. In fact, in the 90's, when drinking at lunch was fashionable, I found programming COBOL drunk was not a problem at all. Later, when I was using C, sobriety was a better state to be in. Drinking and passing arrays of function pointers just doesn't mix.
Never did the LCG thing before. Did take COBOL in college in early 90s. Did not output to display, was all paper reporting. Did not have line numbers for the compiler we used on 286 epsons, with amber monochrome display.
I had the misfortune of using applications written in Cobol and I had learned in in Business computing which I got a respectable B+ for coursework it was the date stamp that caused problems. Even the Microfocus cobol compiler was user hostile and that was in the late 1990s
I graduated university in '97 (Elec. Eng) but I managed to dodge the COBOL bullet... Did some FORTRAN to C translation in a co-op job though... The programming courses were all C. I'm pretty sure that you have to wear a tie when programming COBOL though, being in a room full of mainframe cabinets helps too. And of course the 150 baud teletype printer... Cheers,
I started college in 93, switched to Comp Sci. at the end of my freshman year, and had to take a programming course over the summer to ease the transition. My first language was FORTRAN, which was fun but woefully outdated! I bet COBOL programmers teased FORTRAN programmers to make themselves feel better. There are still a lot of IBM software products where various fields range up to "nine nines" to accommodate COBOL variables defined as PIC S9(9). Were it not for COBOL, I'm sure they would have C ranges from limits.h, like INT_MAX, ULONG_MAX, &c. instead.
COBOL today may now well be a part of gaming; the programs written in this language can be used to format the display of text on the screen for points scoring, lives remaining, time, health and role-play stats. COBOL might also be used in gaming for display of text for high-acore tables.
COBOL looks like psuedo code to me, like someone's trying to explain step by step how a program is supposed to work. It looks outrageously inefficient, and must be a complete nightmare to code with. Which, of course, is why we love it. Enjoyed this one, really cool you could make your 10-PRINT work! Not sure I would manage. :)
Actually, Pascal was meant to ONLY be pseudo code and somebody went and made a compiler for it. This made Niklaus Wirth more than a little cross. He then modified it to create Modula-2.
The program is excelent the only change I suggest is to change the if test with the "go to" in the count-loop function to a "perform until count equal 999" so you avoid the "go to" ;)
I looked into it and it seems COBOL-74, or at least this C64 implementation, doesn't have that PERFORM UNTIL structure available to it. COBOL-85, which I used in university in '92, has a lot of improvements like that.
@@8_Bit Oh! Well, I work for a few years programming cobol for a bank, so I assume they are using a lattest version. That implement that fuctions. I'm Brazilian we don't get commodore here to offten, when I was child my father gave me a MSX, so like you show in the beginning of the video it is more BASIC programming machine. PS.: Sorry about the english, is not my native language. Thanks I like a lot your videos.
I hear that, I was a kid in the 80's, and my late uncle who was a big Commodore user, and helped run a users group gave me my C64, and later C128 to get up, and running had started to try, and learn COBOL on the C128, he gave up after a month, or so, I saw the stuff sitting around his office, and asked if I could have a crack, he said knock yourself out kid(I was 8, or 9 at time), and after a few days I was like NOPE, and just went back to studying C64 BASIC.
@@CommodoreFan64 I went from C64 Basic and assembler into my first job in 1988 . Programming COBOL - wow - what a shock, sooo much text that appeared to do nearly nothing but declare things :) The whole 80 chars per line obv. lifted from punch card inputs etc. Layer on top JSP (Jackson structured programming) in force at that place of work, and any freestyle programming on the micros was knocked out of us. Earned me a living for a while anyway.
When I first graduated in 1975, at my first job we hand-wrote our code onto coding sheets, gave them to the punch operators, and the punch operators punched them onto cards.
@@mandolinic I started work around 1988 - still plenty of punch cards around then - just leftovers though being used as book marks etc rather than being thrown away.
I programmed COBOL on a giant Mannesmann Kienzle mainframe for a software company in Bury St Edmunds, Suffolk in 1990/91 before moving up to the incredible As-400 and learning RPG400, so this for me brings back many great memories. So much can go wrong thanks to a missing full stop!
Back in the late 90's I had an ex-girlfriend who I was still on friendly terms with, and I remember her telling me her new boyfriend was studying to be a COBOL programmer. I had heard of COBOL and I knew many considered it to be a dead language even in those days, but I never did ask her why he decided to go in that direction for a career. However, seeing how many legacy systems are still around here in 2020 using all manner of obsolete software and hardware, I'm guessing he's making very good money right now. The jerk. (I'm kidding, I would never wish COBOL on my worst enemy)
He probably helped solving the y2k problem. My Cobol knowledge came in handy when we switched to 5 digit zip codes from 4 digit in the early 90s and again for fixing the 2 digit year which caused the y2k problem. Oh, and RPG3 as well :D
COBOL was a joke amongst myself and my friends, even in the late 80's when I was 13, 14. We didn't know why, we just knew it was bad. BASIC gets a lot of flak, but in this video, it actually comes out shining compared to COBOL. One might think that in a different universe, BASIC may have killed of COBOL and become the mainframe programming language instead.
Great video, highly interesting! Thank you very much. :) I know about these old languages - COBOL, FORTAN, LISP... - but I never knew that there was a variant for the C64.
Fantastic, I had to learn Cobol in my first job when C++ and Java were already the most used languages. Cobol is definitively not dead. Were there some real compilers (not interpreter) for Pascal, C, Basic or Cobol that produced binary executables on C64?
There are definitely C and BASIC compilers that produced real binary executables for the C64. Not sure about Pascal, quite sure there was only this one COBOL implementation.
@@richardlincoln886 I am in my thirties and grew up with a C64 as my first Computer and I am so happy to see and learn new stuff about it. Especially in this time. I am really grateful for this videos! Hope to see many more videos in the future!
I think that Structured COBOL book is the textbook my mom used in the late '80s in school. I had to use COBOL (and JCL) in 1997 for my OS principles class.
I took intro to COBOL in university in about 2002/2003. It must have been COBOL 85, as I don't remember the line numbers, but maybe it wasn't. I think we also had to telnet into an old DEC system (?) made of multiple 486 CPUs. The servers at Trent were called Ebony and Ivory and they handled our email when I was there. They were running COBOL on this old system too. Don't think any old student systems were still running on COBOL when I was there, but I could be mistaken. I was sad to see they let students working in the IT department tear it apart and make "art" out of the old DEC server. That's how I know it was made of multiple 486 CPUs. (There was also the ATOP lab where you could telnet, or maybe SSH, into some Ultrasparc workstations with 128MB of RAM. They were slow even by the standards of the day but Sun had donated them so Trent gladly set up a lab for them.)
It's weird that COBOL 64 doesn't have modulo division. Even MVS 3.8j TK4's COBOL compiler from 1972 has this statement: DIVIDE (NUMERATOR) BY (DENOMINATOR) GIVING (DIV-RESULT) REMAINDER (MOD-RESULT) Maybe the manual doesn't mention it, or maybe they just didn't include it for some reason.
Multiple people have mentioned that it *should* be in there even though it's not in the docs. How about it, Mr. 8-Bit Show And Tell (if that is your real name)? Since you've already overcome most of the challenges in understanding COBOL 64, how about just giving it a try with the syntax provided?
My first job in my first year of college (1988) I worked for the campus Information Systems department. While it wasn't directly part of my job, they had me debug several COBOL programs. The experience was fun, but helped me to have no interest in participating in the great COBOL Y2K hiring event.
Welcome to Cobol, it takes 10 times longer to write and is 10 times slower than basic. It also requires 10 times more trees to print it out.. but don't worry... it's readable...just as long as you have a dining table that is long enough...:)
I was in "Computer Explorers", a division of the Boy Scouts, when I was in high school a million years ago. At the time I was very familiar with and fluent in Commodore BASIC and had done a dab of 6502 assembly as well. I was shown a COBOL program running on an IBM minicomputer and my first reaction was "What is this gibberish??" I respect how widespread COBOL was and continues to be even now, but trying to code in it was like trying to say every sentence backwards in Pig Latin, and always gave me a headache. As an IT professional these days, I was forced to take ITIL training. All I can say is the people that created ITIL probably get all excited when they see COBOL statements..
OMG, I was an Computer Explorer as well! I was very lucky in a couple of regards. Our Explorer Post was hosted/sponsored by Bell Labs. Secondly, my dad worked at Bell Labs as well. I built an Apple ][ from the chip-level up from a PCB my dad got from the local Apple group at work. I learned AppleSoft and 6502 assembler in the Explorer post, and also built 6502-mini computer as well. I remember reading about COBOL in high school, and what I remember most about it, was you had those 'coding sheets' to hand write your code out. I was into game coding, and wanted no part of that. Only folks who wanted to wear white shirts and ties (IBM!) would use coding sheets. It was great experience, that set me up wonderfully for my computing career.
COBOL on the C64: Awesome! Back in the days when cavemen wrote programs that worked reliably and didn't need to be replaced every few years. Actually, considering that the C64 has more memory, more auxiliary storage, and a faster processor than the computers that originally ran COBOL, it would be a great batch processing platform-if it weren't considered a toy by the people who make the purchasing decisions.
Fun Fact: The reason why cobol is picky about certain columns is a remnant of the punching card age. The same goes for RPG on IBM Machines. Punching cards had to have certain information always in the same column, thats also why the line numbers have to be 6 digits long.
I used to program in COBOL and I'm only in my 50's. The last time was in the 80's using DEC COBOL on a VAX. I used to drive the old guys crazy by indenting the code and trying to see how few periods I could get away with. Ah the good old days.
I never thought I'd see CoBOL on a 64.... seems so incongruous.... quite fascinating! Got me thinking now.... I want a CoBOL compiler for AVR and STM32 microcontrollers.... that would be ah-may-zing.
I'd have used PERFORM UNTIL instead of GOTO, and COMPUTE instead of ADD and MULTIPLY. (I really liked using COBOL the COmmon *Business* Oriented to write income tax software. Pascal was painful, and BASIC would have been, too.) And I see you used Ryan-McFarland in college!
Unfortunately, this implementation of COBOL-74 doesn't have COMPUTE or the UNTIL clause. You can check out the manual here: archive.org/details/COBOL-64_Software_System/mode/2up
My favorite late 70's early 80's computer books were "Enough Cobol" and "Fortran Made Really Easy This Time". I had the CPM board for my 64 and it had Cobol. I also had a Pascal compiler. Those were the days.
The C128 made running almost any CP/M program MUCH easier with the 1571. I was an undergrad doing mainframe languages on punch cards (the school was slow at upgrading equipment). I had learned Pascal (well, Turbo Pascal 2/3) in high school. I loved it. Mainframe Pascal was much different, but easy to adapt to after figuring out the I/O.
Pro Tip: If you use a Fibonacci number based on the number of bits, to multiply the seed, you'll end up with a random number generator that takes a long time to cycle around. I remember starting to learn Cobol after I had learned BASIC, only because the library had a book about it. And then I thought: WHY? I never finished the book.
I had to learn COBOL in university but I've never had to actually code in it in my professional career. Last year I did however have to look at some COBOL code to understand an old mainframe process that I was replacing with a .NET core API so yes, there is lots of COBOL out there still.
"...it only took me about two days to port this one line of BASIC..." CLASSIC!
This need to be on a t-shirt....
"COBOL 64" on the front.... that quote on the back....
@@inerlogic I would totally buy a T-Shirt inspired by this Awesome UA-cam Channel. Something about the title of the Channel. Maybe various 8 bit memes on the shirt.
I enjoyed the gentle humor in this video. Back in the Jurassic, along with all the other dinosaurs in our Fortune 500 corporation, I wrote COBOL code for over 15 years. No one ever referred to a variable as a "PIC", but rather as a variable or a field. However, the variable format statement was referred to as "the PIC clause".
you must be really suffering from severe arthritis in your hands/fingers now because of it! ;)
SAME. I programmed in COBOL in the 1980s and 90s. We usually called a PIC clause a "field", or those of us who could also program in other languages (such as BASIC, C, or Fortran) it was a "variable". It all depended on who you were talking to. In all those years, I never recall using the term "picture". Not saying it is incorrect, just mentioning I never used that term with two different employers (US Navy and an insurance company) during that time period.
I’m watching a stored multimedia tele-message through the Information Highway. It’s like I'm living in the future, very groovy ;-)
I am 59, and retired from a good 35 year career as a COBOL programmer. It paid me well. I have a house in SF to show for it. I spent a good part of the last ten years teaching people who learned other languages how to program in COBOL.
Joseph Cote do you have any tutorials? 🙏🏻 I’m trying to learn.
We're about the same age, my friend had a similar story.. When his daughter was in middle school and in a first class on computers she 'informed' the teacher that COBOL still existed and her father worked writing it. She's grown up and married, and her father still working on code bases there's no money to re-create. Not a house in SF, but Glendale AND a timeshare in Hawaii and that daughter years in ballet lessons.
How would you rate Abacus' COBOL-64 and COBOL-128 for seriously learning the BASICs? (Pun may or may not be intended).
I bought both in the mid-1990s but had an abrupt career change in 1999/2000 which forced me away from my beloved Commodores and into the arms of Linux, Apache, MySQL, and PHP which I also love and have been using for the past 24 years. This week, however, I have finally found all the right ingredients to getting my old Commodores back in action... and I'm running VICE on my Linux box with SD cards for easy back-and-forth between the two. I just found and imaged my old COBOL-64 and COBOL-128 disks today and am seriously considering starting over with them now that I can again.
Worked as a Cobol programmer from 2001 to 2017. 5 years for a Florida state agency and 11 years for a bank. It did pay well.
My very first job interview was at an insurance company. They were hiring people to be either Java or Cobol programmers. They provided training for both, so they were accepting people fresh out of university. The interviewer asked which language I preferred. I told him I preferred Java, but happy to learn Cobol as well. The guy looked me straight in the eye and slowly moved his head from side to side saying: "No, you don't wanna do that". That was the first and the last time I came across Cobol during my carrier. Coding in Java every since :).
amazing to see a language that makes Java look attractive in comparison...
You had to say “from the 1900s”
Dear God, I feel so old now.
Right I learned Cobol in college to become a sys admin
cobol is one of first programming languages for computer. I in my 50's and I heard of this language.
Yes, it was Grace Murray Hopper’s creation, IIRC.
Before that, it was just FORTRAN and assembly.
@@muffenme Came before BASIC
Come on, COBOL isn't that old. Just over 60 years, now...
999 got lost because you never pressed return on that line after changing 9999 to 999 (12:17). I sat there saying, "press return! press return!" but you never did, (12:26) and I knew it was going to surprise you when you ran the program. lol. great video.
Thanks for catching that! :)
*throwing popcorn at the TV
PRESS RETURN!AA!!!
...sorry.... the lack of sportsball on tv has got everyone on edge...
@@inerlogic there might not be any sportsball happening right now, but at least there is pro wrestling, and virtual Nascar.
@@CommodoreFan64 i'm liking the virtual nascar.... although.... i think they over reacted with Larson.... people make millions using that word in public...
@@inerlogic Agreed 💯, and they only made a fuss because at least to the ones complaining, he has the wrong skin color. 😞
3:20 I'm guessing those "advantages" are in comparison to writing everything in assembly or straight-up machine code :D
batlin after watching Ben Eater program a 6502 in machine code I can honestly say it is easier than using COBOL.
Hey Robin. I'm so glad you did a video on this. I stumbled accross COBOL 64 a few months ago and fooled around with it a little. "80", Robin? Come on. I'm only 49 and I had a 17 year COBOL career and loved it. I'm no longer a developer in the work place, but COBOL has always been and is still my favorite language. I really miss it. With the the recent demand maybe I should take a leave of absence from my current job for a few months and go get a COBOL job. They should be paying a ton for them, given how hard is it to find COBOL developers these days and the current crisis. I still have print outs of every COBOL program I wrote in college.
COBOL FOREVER!
(I'm 47 and coded in COBOL in 1992) :)
@@8_Bit Have you ever used COBOL II? It made life easier with things like SELECT statements and substrings without having to use REDEFINES.
I remember Compute! magazine running an April Fool's Day article about the impending release of Atari COBOL. At one point the article explained that the Atari's memory limitations required leaving out one of the four divisions of a COBOL program, and they decided to do without the procedure division, explaining that only power users were likely to miss it.
It's kind of hilarious that there actually was a COBOL for the C64.
My first programming job when I graduated in 1975 was a COBOL programmer. This brings back happy memories. You have to remember that the alternative languages at the time were the equally bad FORTRAN, low spec BASIC which few people used for serious projects, ALGOL-60 if you were very lucky (no-one could ever figure out ALGOL-68), or just working in the assembly language of the computer you had available (which meant re-learning a new language if you went to another job). There were other languages around but they were very niche. Structured programming was seen as a fad that not everyone was convinced was worthwhile, and object-orientation was way off in the future.
COBOL was based around punched cards, so having fixed columns wasn't a problem, since you could easily set up an 029 card punch machine to skip from column to column as easily as pressing the tab key in an editor today. It wasn't compulsory to have a number on each card; however, if you ever dropped a massive card deck (and it did happen!) then having card numbers allowed you to use a card sorting machine to put them back into order.
Python is very popular today and it requires the code to be formatted by indentation. I enjoy Python
If cobol was the language for the c64 instead of c64 basic, I would have trashed my 64 in 1983 !!!
you wouldn't bought it in the first place.
I started college in ‘83. First among my goals was to never learn COBOL.
There's an object-oriented version of COBOL, if that's more to your liking. ;-)
You never tried COMOL! 🤣
@@richardperritt Do you mean COMAL? I learned a bit in secondary school in the early 1990s, but preferred to just stick with C64 BASIC mostly... but COMAL didn't seem too bad, especially compared to COBOL!
Well, I'm really impressed that someone got a working and reasonably ANSI-compliant version of COBOL for the C64. I'm not surprised it a just a bit clunky though. It is probably also an interpreted implementation, which would not contribute to speed.
A few random points:
The "CHR " phrase of a data declaration is an extension from ANSI C74. It is useful in the case of a C64, but it is not literally part of the ANSI spec, though the ANSI spec does allow for extensions like this.
The "STARTUP." label after PROCEDURE DIVISION. isn't a section name, it is a paragraph label, just like the label immediately following. A section name would be "STARTUP SECTION." C74 did not require section names, though some implementations erroneously did require them.
A section (in the procedure division) consists of a section header line and one or more paragraphs. A paragraph consists of a paragraph label and one or more sentences. A sentence consists of one or more verbs and related constructs, and is terminated by a period. In the case of an IF statement, since it is a single statement, you do not put a period until the end of the ELSE clause (if you have one). But if you have a sequence of statements that are not part of an IF, you can have a period at the end of each clause. For instance, you could have done:
MULTIPLY SEED BY 214013 GIVING WORK.
ADD 0.2531011 TO WORK.
MOVE WORK TO SEED.
All three of those sentences would be part of the same paragraph, which runs from the RNG paragraph name to the next paragraph name (or end of program source code), in this case the END-PROG paragraph label.
You mentioned that your random number generator needed to use values for a 32 bit binary number. You aren't working with a binary number, you are working with decimal numbers. Look up random generators in Knuth. Decimal generators can work just fine, but you use different modulus values and seeds than you would for a binary generator. The action of moving from WORK to SEED is giving a mod function that is a power of 10, not a power of 2.
If you want a remainder other than an implicit divide by 10, you could do something like
DIVIDE WORK BY 123 GIVING WORK, REMAINDER SEED, if I recall correctly (I don't have my manual handy at the moment).
You don't have to use GO TO. You could do something like PERFORM LOOP 10000 TIMES or PERFORM LOOP UNTIL DONE and make the loop into a performed section or paragraph.
No compliant COBOL implementation *requires* line numbers. The line format is
1-6 sequence number field
7 flag/comment marker field
8-11 A margin
12-71 B margin
72-80 (really 70 to end of machine-defined line length) patch marker field
While the first 6 columns are for sequence numbers, a compliant COBOL should accept all blanks.
COBOL was originally input on punched cards, which are more easily used as a fixed-format input medium than variable-format, like a keyboard and CRT you are used to. Many vendors implemented variable input formatting options for their COBOL implementations that relaxed the strictness of column 6 and the A and B margins and made sequence numbers optional or variable length. This was done for all versions of COBOL going back to COBOL-60, depending on the vendor. It has nothing to do with C85 to not require sequence numbers.
I get a call once a year or so to help with COBOL/ESA, IBM Mainframe. I can never get away from it.
It's like the Mob they keep pulling you back in!
If you think that’s bad, I get called about an assembler i/o routine every few months
My COBAL/RPG experience was a Data Entry class back in 1980 using 8-inch floppies and an IBM S/32. I ended up being the SYSOP for the system and was able to get my assignments out within one day using the console while the rest of the class had to wait for the typists to enter their programs on the 8-inch floppies. Fun times!
Learned on a PDP 10 11
Thanks for making me feel young at 44...
I used to teach from BOTH the COBOL 74 version of the book you have at the right and the COBOL 85. PIC directs a "picture" of how the input/output will be formatted and controlled between numeric and text (among a few choices). You can choose characters by placing them in quotes without using ASCII/EBCDIC numeric references. The positions had to line up based on the original punch cards. On better compilers the errors are clearer. COBOL 85 fixes a lot of old language issues. COBOL 74 was designed for uses on computers barely as capable to do BUSINESS math and BUSINESS reporting on mainframes. If the mainframe has upgraded to terminals from card punches, the editors simplified numbering of lines.
I taught COBOL 74/85, FORTRAN 77, 360/370 BAL, RPG II/III/IV/ILE (the latter on iSeries) for over two decades at university. However, I learned on punch cards. You REALLY appreciate terminals after having used punch cards. The editors were (generally) great and the operations software for multi-user systems were nicely designed. When we switched to MVS/TSO, I was able to flip between the editor, submission of files, and printing of output by fast tracking.
There was only one down side back then - if a student's program crashed during CICS programming (creating a UI that worked "live"), it crashed EVERYBODY in CICS and took 20-30 minutes to reboot CICS.
Great video. COBOL is a "declaration by example" language, so that's why you use PIC to give a "picture" or a "general example" of what you want a data field to look like. Your program could be shortened, lots of the code is not needed or could be simplified / shortened. Instead of using evil GOTO you could use PERFORM VARYING ... which is the COBOL equivalent of a FOR loop in basic. COBOL does tend to be a very verbose language, but it is very powerful. e.g. you can filter and sort files in a few lines of Procedure Division code.
Great video Robin. What flashback. I had a year of COBOL on my college course in ‘94. Couldn’t understand why we were being taught it. On the run up to y2k I worked with a ton of COBOL programmers on various projects. They earned a fortune at all these financial services companies keeping their old systems up to spec.
The millennium bug provided a lot of work for a lot of older programmers that still knew languages like COBOL :)
It kinda drives me mad when people claim the millennium bug wasn't even a real problem, as they overlook the huge amount of effort that went into making it not be a problem.
0:21 I'm old enough to have actually learned COBOL as an undergrad, which is also the last time I ever encountered it. (I guess you did, too.)
1:02 There's where to put the three zero bytes you had in a previous video. But it seems odd that they didn't just put a line of BASIC there so you don't need to know the start address.
2:24 Requiring a specific syntax of English prose doesn't make programming easier; it just means more typing. A complex syntax with a bunch of auxiliary words will be harder to remember than abbreviated syntax like with C. The opposite extreme would be APL. The advantage they might have been trying to state is that it might make it easier for a non-programmer to read the gist of the code. Of course, this is what comments are for!
3:41 Geesh! Okay, that's why nobody uses COBOL today except to maintain legacy systems that were programmed in the 1960s.
4:05 If this compiler is from 1984, it probably wouldn't support COBOL-85!
7:40 Why would the "VALUE" come before the "PIC" on some lines but not others?
9:53 We can have some sympathy for them stuffing a COBOL compiler into the C64 and leaving room for your program.
10:30 Are all variables global? The functions don't seem to take or return parameters. If so, then COBOL isn't inherently any more scalable than BASIC. LOGO had the same problem.
11:31 If none of the statements inside an IF need a terminal "." character, then the language can parse the statements independently (I guess from the strict indentation) and the "." terminator isn't needed in the language at all.
13:40 How does COBOL handle numeric overflows? The C64 version is using base-10 numbers, right? (Or BCD?) You don't need a MOD function if you have overflows. Base-10 RNG with overflowing integers should work just as well as base-2.
If you can do a PEEK, you could use the low byte of CIA-1 Timer-A for a random number between 0 and 255 (which is basically what RND(0) in BASIC does). (Or use the SID chip after some setup.)
18:24 So, there's no compiler? Is this just interpreted? It looks a lot slower than BASIC!
Yes, all variables are global, and there doesn't appear to be any way to pass or return values when calling a paragraph with PERFORM.
Yeah, it's essentially doing a base-10 "MOD" when moving the WORK variable into SEED. There's an ON SIZE ERROR clause that can deal with the overflow, but I'm (deliberately) not using it.
There is no PEEK equivalent that I could find. This implementation is really simple, though I doubt the standard COBOL-74 has a PEEK either.
The manual makes reference to there being both a compiler and an interpreter. If anything, I'd guess that the compiler turns it into an intermediate form which is then interpreted. The ~160 page manual is very light on technical details.
A paragraph is inside the current program, calling another program, linked in, would require you to set up a linking section and whatnot.
This weekend I spent too much into the COBOL rabbithole 😀.
Perhaps it is the version, but a loop like that would be done with a perform Paragraph 1000 times.
The dot is for the compiler and programmer to know the end of a sentence. Quite like ALGOL68 and derivatives.
For it being verbose; code is more often read than written so typing isn't considered an issue.
Trouble is when too much code is crammed into one program and not neatly paragraphed or is copy pasted. That happens in any language and makes maintenance difficult in everywhere.
It doesn't matter, if "PIC" or "VALUE" comes first.
I'm not sure about Cobol-74, but in Cobol-85 you certainly can return values (which is, why I find the use of "RETURN-CODE" in this video/program a bit unfortunate).
BTW: If you're worried about scalability: There has been Object-oriented Cobol for a long time now.
Same here . I took an undergrad cobol class in 92. 93 was the last year it was offered. Oddly, offered again in 99 due to y2k bug demand
Did all versions of COBOL have a set number of digits it could handle?
My undergrad COBOL course leaves me with foggy memories of it doing most math the long and slow way and not using built-in types of the CPU archetecture. As in, doing math column-by-column and handling overflow in the language instead of the built in CPU overflows.
Having worked with COBOL in the mid- late nineties on a mainframe, it's quite amusing you managed to re-produce 10PRINT - great job as usual. It's still an option on the mainframe systems I support (z/OS), though I believe IBM will pull support soon'ish.
COBOL is still rampant across legacy mainframe driven banks, airlines and other large customer base systems. It's reallly useful for processing large amount of repetitive transaction data, producing statements etc. But you knew that Robin. :)
Saw some used for a credit card transaction for Eaton's in Canada. I wrote some software for a company so they could data mine transactions for possible future purchases.
Actually SQL was also created to manage big databases.
I started to learn these things in 1996 in schools, and after Turbo Pascal, Turbo C and C++ we learned the SQL.
It was very easy to understand the syntax and the logic of the queries.
@@MMSZoli Yeah, and you can just use DB2 for that - but an awful lot still has embedded COBOL with embedded SQL/DB2 transaction code. I've still got my IBM manuals...
I started writing Assembler and COBOL using a card punch machine almost 40 years ago. Today, the card punch machines are gone but I still write in Assembler and COBOL. A few things have changed over that time (introduction of Concept 14 Macros for Assembler), but much if remains the same. I remember being told COBOL was a dead language 25 years ago and it would soon be all replaced. I still laugh all the way to the bank.
I programmed in COBOL (among other languages) for several years (1970's-early 80's). Two major failings (at the time): 1) No END-IF statement, which meant those idiots who used nested IF's could never get the logic right, and 2) no independent subroutines or functions (where the name-space was independent). PERFORM was equivalent to old BASIC's GOSUB, with similar associated problems. You could keep your nose clean by always using PERFORM paragraph-name THRU paragraph-name-EXIT. The one big advantage that COBOL had was flat-file record definition and redefinition. No language that I've seen since the 1970's does this better.
For a couple of applications at the dawn of the microcomputer era I used the (in)famous Nevada COBOL ($29--cheap!). I had to debug and patch the run-time module so that it would work with my terminal (that's right--no monitor, a terminal linked to the micro via a 19,200 baud connection). I even wrote an 8080/8085/Z80 disassembler (to run under CP/M) using Nevada COBOL. Great times!
Postscript: PERFORM ... VARYING. OMG. Idiots could never get this right. I always advised people to just code the loops manually, using a starting point and an exit label, and IF-logic. Whenever I had to debug someone else's code, the error was always in a nested IF or in a PERFORM ... VARYING.
I’ve had a bunch of head hunters contacting me for COBOL year plus contracts. $180k+ working for states contracts. Current COBOL has changed, you can do XML and all kinds of stuff. I’m sticking with my java/angular work.
Ahhhh, Memories.... I spent 10 years in the military starting in 1987 writing COBOL apps. Some mainframe in COBOL 74 and some for PC Microfocus (later bought by Microsoft) COBOL 85. To turbocharge the UI side, I wrote x86 assembly routines that our PC COBOL programs would call. Many years later, in 2005, In a Master's Programming Languages class, we had an assignment where all our teammates had to solve a common project, each with a different language. I did mine in .NET COBOL. :)
Commodore 64 continues to amaze me! That little 8-bit computer still running all the classic languages: Pascal, Cobol, Forth, Fortran, Logo, C and even a minimal but working Linux system! (Lunix)
Sadly, there's no Smalltalk. Would make a fun project tho to write one ;)
First time I've seen interactive COBOL. When I learned it, we used 80-column punch cards for the code.
I bet that's what my mom means when she learned computers at Concordia on punch cards.
Same here, on an IBM 360.
Me too. I eventually graduated and went on to teach at my undergrad college and by then they had gotten terminals. While I felt jealous, I have to admit it was MUCH easier to teach on.
A lot of the formatting requirements make sense using 80-column punch cards.
The line numbers mean that things won't break if the cards get shuffled.
An asterisk comment can be added to an existing card.
@@markevans2294 The obstacle on the C-64 was the 40 column screen. Not insurmountable of course, but creating various workarounds isn't ideal for COBOL. Also, COBOL itself has no interactive system. It's simply an IPO system based originally from those punch cards. When IBM implemented CICS, it based it on a fast version of that - you created the screens in BAL, and when the user pressed enter the COBOL program was started from scratch with data from the BAL screen. The COBOL ran briefly and and returned data into the BAL screen it needed. When it worked, it was elegant. When it didn't, every single CICS user was waiting 20-30 minutes.
I hated punch cards. Punches that crunched cards (we called them card crunches), the whole "carry them around" aspect. My experience with them at school went like this:
1. After getting approval to punch my cards (fine) I had to then schedule an appointment to use the punch in one hour blocks. Not terrible - they were relatively short programs. If you had the time, make a duplicate.
2. Walk the cards to the operator, who looked like someone from the dead. He ran the stack though a counter and gave me a bill to take to the cashier across campus.
3. Cashier accepts your money and provides two receipts - don't lose because one was for the operator. If you had to go through that cycle again, there was an extra charge.
4. Back to the op and hand him the receipt. He bands them to the cards so that some geek in the back whose ONLY job was to run jobs knows that the jobs was paid for.
5. When you come back TOMORROW, if the job was done you received it. Finding out what ops and jobbers liked in food could mean getting your job in an hour.
6. Look at the job, sometimes a typo, but I was a good punch so I rarely had typos. Syntax errors and semantic errors - part of the learning process.
The school also charged for cards and paper used. Not sure where that was kept track of, but we'd get a bill at the end of the semester. When terminals were brought in, I asked students and found out that they were charged a flat fee (easily three times what I paid) when they registered. If they dropped, they lost that fee.
When I was teaching (during grad school) the terminals were easy. There were 30 of them. Beautiful jade green screens. I miss them... :-( There was a line printer that printed massively fast. Teaching students how to use the system was easy. I took pics of the screens with a camera (film - some developer must have wondered if I was a Russian spy). I used it on my PC to rebuild the screen in a graphics program and make a set of instructions that basically said "to do this, go to the screen that looks like this and fill in the blanks". I knew the people who would drop because they couldn't look at pictures and follow directions. I still have the directions.
Do people remember the green/white coding sheets and print chart sheets? How many people have printer spacing rulers or their flow chart template? I do... :-)
This was a great video - I'm sure you did also Mark!
I used COBOL on IBM mainframes. To get the modulo (remainder) you do DIVIDE A BY B GIVING C REMAINDER R, which means C=A/B and R=remainder. I looked into the COBOL 64 manual (page 91) and doesn't mention this. So my guess is that this COBOL version doesn't have modulo implemented on it.
Heh, funny video Robin! Also surprised a COBOL interpreter exists for the 64.
My favorite "inappropriate" combination of a computer and a programming language is still Pascal for C64, but Cobol is another contender. It begs the question, has anyone really used them on a C64? For non-academic purposes, I mean?
@@QuintusCunctator "Inappropriate" as "useless"? I have used Turbo Pascal for CP/M on C128 and that was very useful, especially with easy way of inlining Z80 code into program. Oxford Pascal on C64 was also usable - for similar purposes like BASIC 2.0.
@@tym0tym No, I meant "inappropriate" as in "barely fitting in a stock C64 memory and CPU". I'm looking at the manual of Pascal 64 by First Publishing, and it says that e.g. when using pointers and the NEW instruction, since there is no "free memory" instruction, one should follow pointer-intensive code with a "LISTINIT" instruction, which in turn performs garbage collection, or receive "out of memory" errors along the way. I can only hope other implementations did better, but I still imagine running Pascal on a C64 is a feat in and of itself, hence my observation.
@calcmandan I'll quote the Super Pascal manual:
"First it's a difficult task to put a Pascal implementation into a computer the likes of the c64; its memory capacity, the fact that it is an 8 bit machine, and its i/o functions require some changes from any mainframe versions of Pascal. Second, a complete language and programming system had to be set up within the 64 which would bypass the standard OS, and cut down the time factor."
And FORTRAN and PASCAL
Started watching your videos recently. Great stuff. Brought back some memories of writing Cobol in school. Thanks.
For a background to COBOL look up Grace Murray Hopper, a very smart lady.
I learned COBOL in the late 1960s, but never had to use it in anger. It was clunky, but filled a niche. First, it was strictly for business problems which were about record keeping, so it emphasised defining and manipulating records and files. Secondly, laying out the hierarchical structure of the fields and subfields in the records was an important part of the language. I think it was one of the first languages which enforced strict data typing. There was an idea that the process could be made more intuitive by defining those hierarchies graphically on paper (pictures) and then coding from these diagrams. I have come across other early languages which tried the same idea.
And yes, the procedures were in "English", which can be a wordy experience and the syntax checkers were inflexible. But these had to run on systems which in many respects were less powerful than the C64.
COBOL is very sensitive to what column you are in. Columns 1 to 6 are optional line numbers. Column 7 is the "is this a comment?" column. Columns 8 to 11 are "Area A" which are for the declaration of sections and paragraphs. Column B starts in column 12. On mainframes this then runs up to column 71. 72 is the continuation column (because you have 80 columns, because of Herman Hollerith.)
Lovely stuff. COBOL-85 was a big improvement. END-IF statements! Full stops ending scope are still an irritation today though.
I converted a BASIC Moonlander game into COBOL for my own amusement.
COBOL doesn't have a MOD function but does have
DIVIDE something BY something GIVING something REMAINDER mod
function. I've just checked in my books upstairs and "COBOL for the Eighties" (published 1982) has it.
Wonderful stuff! Wouldn't use it for missile defence of course, or astronomy!
I began my IT career around the same time as your university example. I remember being eager to take c++ and other object oriented programming in university, but was required to take COBOL as a prerequisite to those courses. I quickly learned about COBOL's unforgiving nature, and I became so frustrated with the language that I ended up having to take the course twice - and still only squeaking by with a very basic understanding of it. I think I had flashbacks when your programme failed to print the stats the first time around! That reaction perfectly sums up my memory of this language - "I'll run it... if I feel like it". *shudder
Something so much more intrinsically satisfying watching development on actual hardware vs an emulator. I realize this isn’t always as efficient but sure feels nice to see a real C64 with an accelerator.
> start watching this video
> see the very distinctive box style of the Cobol for C64 box show up
> immediately pause the video, raise my arms up and say "oh wow, glory be to Abacus Software, you really didn't know when to stop making crazy stuff for this thing" (or something like that)
No seriously this is a company that has a bunch of strange businessy things in between their dozens upon dozens of books about the 1541 or Amiga (specifically). Now I really need to be on the lookout for their XPER series because these kinds of old productivity software packages fascinate me in a quasi-nostalgic-for-mid-90s-Microsoft-Office sort of way
Apparently Abacus also made a C compiler for the C64, which now makes me wonder what other forgotten (since C isn't forgotten but COBOL mostly was) programming languages exist on the thing. APL?
I also have a book called COBOL For Beginners by Christopher Lampton. His "For Beginners" books name a whole bunch of microcomputers; I have a couple more of them buried around my room somewhere...
NSULA required all CIS students to take COBOL programming when I was there in 2003-2007. No one really understood why we were learning such an old language. The professor explained how there were still tons of these businesses still running everything in COBOL and that if you know how to code with it then you became a very desirable prospect to employers and almost guaranteed to make big money.
I was a COBOL programmer 1992 - 2001 or so. I worked with DEC VAX systems then. Think it was COBOL 85 but can't be sure. The line numbers were optional thankfully. :) . The strict requirements for line number length etc comes from the fact that COBOL statements were originally punched onto cards so the column positions were important so the card readers would work properly. COBOL can run in the .Net framework now. Microfocus have produced a compiler and IDE for it. So much legacy code exists that the cost and risk of redeveloping some systems simply isn't worth it - but - COBOL code is one of the few languages that has proven genuinely portable. It's OK to call those level 77s variables. I used to prefix them with "WS-" so I knew they were working storage variables. COBOL also let you bind variables to files, records and fields in the DATA DIVISION so it was good to prefix the variables so you didn't mix up working variables with bound file variables. The PIC clause just defines the data type. I never used 77s - just used level 1. Level 88 was an interesting variable as it let you declare special condition names dependant on the values of the variable that could be used in IF statements. Was a nice concept. You also don't have to use english in conditional statements - you can use the arithmetic equivalents such as < and = etc. COBOL was one of the first third gen languages and of course there was too much hype about it. I think the legendary Grace Hopper was involved in the creation of the first version of it - or at least a very early language that COBOL was based upon. Worth googling about her. :)
I was a COBOL programmer from 1986 until 2000. Once all the Y2K changes were done I transitioned on to other languages and systems. At one point in there I was working for a company where we did all the COBOL development and testing on PC's before uploading the code to the mainframe. Those PC's were running OS2. I never heard of COBOL for the 64 before and I would have probably wanted to check it out at the time.
That was hilarious! Also, the COBOL you were writing here looks more familiar than your code from the early 90's. I didn't take the course myself, but as a CS LAB tutor, I helped debug a lot of it.
Great video, as usual. I think you deserve a medal for putting up with COBOL for two days! It feels like the language was designed with the dual goals of being "readable" for non-programmers, and driving programmers to madness!
COBOL stands for COmmon Business Oriented Language, very much intended to be read and reviewed by actuaries and other people from the Business side of companies. Not sure if that actually happened though. As the Wikipedia page states: ... though intended to be English like, not easily comprehensible ...
it's totally a pointy haired manager thinh
@@MeriaDuck I used to work hand in hand with actuaries and accountants in an insurance company in the early 1990s. I maintained many a COBOL program. The running joke at the time was that an actuary is an accountant without a sense of humor. I found that statement to be quite accurate over the years.
Here's a modern COBOL listing for the PC.
RANDOM and MOD are included in COBOL now. I added REPOSITORY so I don't need the word FUNCTION in front of any intrinsic functions such as RANDOM and MOD.
LEFT, RIGHT and COUNT are all reserved words in COBOL so I changed them.
DISPLAY automatically does a CRLF unless you tell it not to to so I included LINE-LENGTH to set the width to the same 40 characters wide as the C64 and printed the CRLF at the end of each 40 character line.
IDENTIFICATION DIVISION.
PROGRAM-ID. TEN-PRINT.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
FUNCTION ALL INTRINSIC.
SOURCE-COMPUTER. CORE I7 MODEL 7700K.
OBJECT-COMPUTER. CORE I7 MODEL 7700K.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 LEFTCOUNT PIC 9999 VALUE 0.
77 RIGHTCOUNT PIC 9999 VALUE 0.
77 TOTALCOUNT PIC 9999 VALUE 0.
77 LINE-LENGTH PIC 99 VALUE 40.
PROCEDURE DIVISION.
PERFORM COUNT-LOOP 999 TIMES.
DISPLAY " ".
DISPLAY LEFTCOUNT "+" RIGHTCOUNT "=" TOTALCOUNT.
STOP RUN.
COUNT-LOOP.
IF RANDOM IS LESS THAN .5
DISPLAY "\" WITH NO ADVANCING
ADD 1 TO LEFTCOUNT
ELSE
DISPLAY "/" WITH NO ADVANCING
ADD 1 TO RIGHTCOUNT.
ADD 1 TO TOTALCOUNT.
IF MOD(TOTALCOUNT,LINE-LENGTH) IS EQUAL TO 0
DISPLAY " ".
PIC defines the actual layout of the variable both in memory and on screen / printouts unlike binary comp and you would normally use PIC for formatting output and comps for calculation (hence the PIC). Main drawback was the amount of memory they took - effectively one byte per character and core (yup that's what started with) was expensive.
My first commercial role was in Cobol 85 having been given the basics at college and compared to Algol / Fortran / APL (the other commercial languages I used around then) COBOL was a breath of fresh air and was a lot easier to read till someone decided to use a variable for the wrong task and did not rename it (level 66)! OK it saved a few bytes (vital somedays to stop paging to disk) but really buggered you up if they did not document it!
Thank you for bringing this back - I used the older PET machines (in 6502 / BASIC / FORTH) but did not know COBOL came out for any Commodore machines :-). Microfocus was and (still is I think) the main driving force for COBOL on smaller machines so to see another supplier was very interesting.
Fascinating. **doesn't understand a single thing about COBOL**
14.28 The COBOL mod statement is buried in the DIVIDE syntax. Coding a mod operation can be as easy as typing "DIVIDE FIELD-A INTO FIELD-B GIVING FIELD-C REMAINDER FIELD-D" (quoting most of an example from "Murach's mainframe COBOL".)
Very cool, it is the first time I see actual COBOL code. Thanks for showing. I looked for your 2nd channel but couldnt find it under Info on this channel.
I have the same question
Here it is: ua-cam.com/channels/AgWzEh5c8391eJnELDy9OA.html
I now added it under the "About" tab on my channel. Thanks for pointing that out!
I took 3 quarters of COBOL at my college, it was done on a DEC-10 (Mainframe) and terminals (Hazeltine, ADDS, and others lost to time) for my final project I ported wrote a simple video game I wrote for the VIC-20 called "Atomic Battleship" (not as popular as "Muncher"), I had to figure out how to use cursor control and I too had to write a Random Number Generator, based loosely on Dr. Knuth's algorithm book. At that point the instructor said "I guess business programming isn't your passion"... He was right, and I went on pursuing my Computer Science Degree. BTW: PIC 77's were special pictures, I think that's how I was able to do cursor controls for the various terminals (open a file and load the control sequence characters) and there were a few other cases, but dang it if I remember what they were. Also I think you could have written: "Add 1 to " and avoided the "giving" so "add 1 to count." but COBOL 74 might not have had that, The COBOL I learned back in 1983 had over 200 keywords, and all of the best ones were taken ... LOL. Memories :-)
This 74 year old dinosaur spent 20 years (‘75-‘95) witting COBOL. I’ve probably written close of a million lines of that stuff. Well written COBOL will not have any GO TO statements. Most version allow PERFORM xxx UNTIL yyy, allowing fully structured coding.
If someone didn't say already when you changed 9999 to 999 you didn't press RETURN to actually submit that change which you can see when you listed from 2900 onward and you can see that line still shows 9999. When you made the change I was actually watching to see if you were going to press RETURN and noticed you hadn't and it was confirmed when you did the next LIST command revealing the unchanged line.
My one and only COBOL program is a game of checkers I wrote for my mom's 68000 based TRS-80 Model 12 in the 80s (she used it for accounting). This was under RM/COS- Ryan Mcfarland COBOL Operating System. It showed the checkerboard in TRS-80 graphical characters- I remember there was no equivalent to BASIC's CHR$(), but I don't remember if it had the "CHR 206" thing, but there must have been some way. RM/COS was a kick- I remember it had a hierarchical directory system sort of- there was a single main directory, but files could be indented into lower levels- '.' was the path separator. It supported multi-tasking- you had to partition the memory ahead of time to decide how much each task should get.
It's funny that you make this video now. In about two months, I have to start creating a port of a COBOL program to some modern programming language. A central part of the financial calculation of our company depends on this COBOL tool and has done so for pretty much forever. It is amazing that it is still up to the task, but enough is enough.
I won't have to learn COBOL however. We tried to find out everything this black box does and can do and reverse engineer it.
If you can write any programming language you can read CoBOL.... it's agonisingly simple... that's the whole point of it.
Very interesting, I cut my programming teeth on COBOL in the 80's and I've just brought myself an original C64 breadbin and the new C64 Maxi. Watching this video brought it all back. I'll be downloading it for sure. Many thanks for a great video.
I edited the program with the VICE emulator and after some corrections it runs fine.
Great video. Thank you...
I am not too ancient (51) :-) but did learn some COBOL at business school, using ICL mainframes and the fun part was doing this using teletype terminals. Was at the Mid-Kent College, Rochester, Kent, UK. When you showed the code, some of the stuff came flooding back. Thank you!
Since you always strive to make your programs short and efficient, I would suggest to be a bit more creative with defining your variables like this:
01 work pic 9(7)v9(7) value 0.1.
01 filler redefines work.
05 filler pic 9(7).
05 seed pic v9(7).
That way you get an "implicit" mod function and can remove the line
move work to seed
from RNG.
BTW: Even if your manual avoids using the term "variable". In Cobol it's not called "picture". "Picture" is the FORMAT of a variable (data-name, item .....).
Right. PICTURE is not the data type; it's an illustration of the data format: 999V99, for example, is a "picture" of the data.
Saved me the ti e to write this myself. Bless redefines.
This code works because COBOL by default stored values in Binary Coded Decimal (BCD), instead of the common int and float formats we use today. All arithmetic was therefore done in base 10. Slow, but accurate.
To be fair to COBOL, it was really one of the very first languages ever created for computer programming, and they didn't really know what worked and what didn't work well at that point. Because it was so widely used, by the time COBOL-74 came around they couldn't change much without breaking 15 years of code written to that point (yes, COBOL was created in 1959, based at least in part on Grace Hopper's FLOW-MATIC language!) so a lot of things like basing important details on column numbers stuck around until well after punched cards were used. That's why, for example, the first 6 characters had to be line numbers, with actual statements starting at 8 or 12. There was a whole specification on what columns were for what... I believe there was a special symbol if you wanted a line to span across two physical cards (80-character cards, of which you've already lost 12 characters for the bulk of your program, so it's not hard to imagine needing multiple cards). Anyway, if these languages pique your interest, there's a book by Jean Sammet written in 1969 titled "Programming Languages: History and Fundamentals" which pretty much covers every single programming language that had been created up to that point. Nowadays such a book would be impossible!
Great training material. Fresh new entry into the COBOL 64 demo scene.
I greatly appreciated that you showed us the problems and not just the 'joys' of the process.
I got all excited thinking this language had something, Jesus I'm so glad I didn't start programming in COBOL - I definitely would have become a footballer or something instead of a programmer :D
Honestly, COBOL wasn't that bad. It looks bad only because you're able to compare it against modern languages, but at the time plenty of programmers enjoyed using it. I certainly did. Of course, looking back now I can see how limited it was, but no-one was aware of those limitations at the time. And of course, the money was good!
@@mandolinic There is one great thing about COBOL, those structured records that are almost database-y. Everything else... ugh. Of the contemporary languages If I could have those combined with Algol, I'd be a pretty happy bunny.
No kidding - COBOL is still a big business right now for consultancy companies migrating COBOL off IBM mainframes (these license costs!) using stuff like Micro Focus. You would be amazed how much of this stuff is still working in banking. For more C64 programming languages I have seen Dan's nice page telarity.com/~dan/cbm/languages.html . Apart from ADA, FORTH, FORTRAN there is more exotic stuff like COMAL or MUMPS.
I like your sense of humor.. a video about COBOL, with actual serious content, and keeping it entertaining? that is an achievement in its own right.
Everyone did COBL @ university, and then forgot about it, except knowing that you have to get stuff in the right columns, and thought "gee that's a bad idea", (I'm looking at you python)
I worked as an intern at Kraft Foods corporate offices for my first job in 1999. We worked on Y2K issues. It landed me a job at IBM.
I programmed in COBOL for many years. I found it to be pretty easy. In fact, in the 90's, when drinking at lunch was fashionable, I found programming COBOL drunk was not a problem at all. Later, when I was using C, sobriety was a better state to be in. Drinking and passing arrays of function pointers just doesn't mix.
I learned Cobol and used it to program some utils to handle print ques on our IBM System 36. It was a fun time. ;)
The S/36 had a pretty good editor. The AS/400 had a super good editor.
Never did the LCG thing before. Did take COBOL in college in early 90s. Did not output to display, was all paper reporting. Did not have line numbers for the compiler we used on 286 epsons, with amber monochrome display.
I had the misfortune of using applications written in Cobol and I had learned in in Business computing which I got a respectable B+ for coursework it was the date stamp that caused problems. Even the Microfocus cobol compiler was user hostile and that was in the late 1990s
I graduated university in '97 (Elec. Eng) but I managed to dodge the COBOL bullet... Did some FORTRAN to C translation in a co-op job though... The programming courses were all C.
I'm pretty sure that you have to wear a tie when programming COBOL though, being in a room full of mainframe cabinets helps too. And of course the 150 baud teletype printer...
Cheers,
I started college in 93, switched to Comp Sci. at the end of my freshman year, and had to take a programming course over the summer to ease the transition. My first language was FORTRAN, which was fun but woefully outdated! I bet COBOL programmers teased FORTRAN programmers to make themselves feel better.
There are still a lot of IBM software products where various fields range up to "nine nines" to accommodate COBOL variables defined as PIC S9(9). Were it not for COBOL, I'm sure they would have C ranges from limits.h, like INT_MAX, ULONG_MAX, &c. instead.
COBOL today may now well be a part of gaming; the programs written in this language can be used to format the display of text on the screen for points scoring, lives remaining, time, health and role-play stats. COBOL might also be used in gaming for display of text for high-acore tables.
Look at CoBOL slightly differently and you realise it's only a couple of steps removed from Assembly Language and you can do anything with it.
COBOL looks like psuedo code to me, like someone's trying to explain step by step how a program is supposed to work. It looks outrageously inefficient, and must be a complete nightmare to code with.
Which, of course, is why we love it.
Enjoyed this one, really cool you could make your 10-PRINT work! Not sure I would manage. :)
I learnt COBOL as part of my Comp Studies degree. It's a very easy language to use.
Actually, Pascal was meant to ONLY be pseudo code and somebody went and made a compiler for it. This made Niklaus Wirth more than a little cross. He then modified it to create Modula-2.
I took a course in Cobol in 1967 (I was just 30 yrs old) at Bell Labs, just introductory. Our main language for technical work was Fortran.
Just discovered your channel,and that "under 80" joke at the start just made my day. Thanks!
The program is excelent the only change I suggest is to change the if test with the "go to" in the count-loop function to a "perform until count equal 999" so you avoid the "go to" ;)
I looked into it and it seems COBOL-74, or at least this C64 implementation, doesn't have that PERFORM UNTIL structure available to it. COBOL-85, which I used in university in '92, has a lot of improvements like that.
@@8_Bit Oh! Well, I work for a few years programming cobol for a bank, so I assume they are using a lattest version. That implement that fuctions. I'm Brazilian we don't get commodore here to offten, when I was child my father gave me a MSX, so like you show in the beginning of the video it is more BASIC programming machine. PS.: Sorry about the english, is not my native language. Thanks I like a lot your videos.
COBOL at least was good for teaching typing! - soooo wordy, you had to type faster to get anything done :)
I don't want to go back LoL
I hear that, I was a kid in the 80's, and my late uncle who was a big Commodore user, and helped run a users group gave me my C64, and later C128 to get up, and running had started to try, and learn COBOL on the C128, he gave up after a month, or so, I saw the stuff sitting around his office, and asked if I could have a crack, he said knock yourself out kid(I was 8, or 9 at time), and after a few days I was like NOPE, and just went back to studying C64 BASIC.
@@CommodoreFan64 I went from C64 Basic and assembler into my first job in 1988 . Programming COBOL - wow - what a shock, sooo much text that appeared to do nearly nothing but declare things :)
The whole 80 chars per line obv. lifted from punch card inputs etc.
Layer on top JSP (Jackson structured programming) in force at that place of work, and any freestyle programming on the micros was knocked out of us.
Earned me a living for a while anyway.
When I first graduated in 1975, at my first job we hand-wrote our code onto coding sheets, gave them to the punch operators, and the punch operators punched them onto cards.
@@mandolinic I started work around 1988 - still plenty of punch cards around then - just leftovers though being used as book marks etc rather than being thrown away.
I programmed COBOL on a giant Mannesmann Kienzle mainframe for a software company in Bury St Edmunds, Suffolk in 1990/91 before moving up to the incredible As-400 and learning RPG400, so this for me brings back many great memories. So much can go wrong thanks to a missing full stop!
Back in the late 90's I had an ex-girlfriend who I was still on friendly terms with, and I remember her telling me her new boyfriend was studying to be a COBOL programmer. I had heard of COBOL and I knew many considered it to be a dead language even in those days, but I never did ask her why he decided to go in that direction for a career. However, seeing how many legacy systems are still around here in 2020 using all manner of obsolete software and hardware, I'm guessing he's making very good money right now. The jerk. (I'm kidding, I would never wish COBOL on my worst enemy)
I have a question about cobol,
WHY the hell would you want to keep communication with an ex? Best woman is the next don't waste your time
He probably helped solving the y2k problem. My Cobol knowledge came in handy when we switched to 5 digit zip codes from 4 digit in the early 90s and again for fixing the 2 digit year which caused the y2k problem. Oh, and RPG3 as well :D
COBOL was a joke amongst myself and my friends, even in the late 80's when I was 13, 14. We didn't know why, we just knew it was bad.
BASIC gets a lot of flak, but in this video, it actually comes out shining compared to COBOL. One might think that in a different universe, BASIC may have killed of COBOL and become the mainframe programming language instead.
Great video, highly interesting! Thank you very much. :) I know about these old languages - COBOL, FORTAN, LISP... - but I never knew that there was a variant for the C64.
Thanks for the timetravel! I used to program Databases in Cobol in the 1990´s - I am still recovering :0)
Fantastic, I had to learn Cobol in my first job when C++ and Java were already the most used languages. Cobol is definitively not dead.
Were there some real compilers (not interpreter) for Pascal, C, Basic or Cobol that produced binary executables on C64?
There are definitely C and BASIC compilers that produced real binary executables for the C64. Not sure about Pascal, quite sure there was only this one COBOL implementation.
... what the dinosaurs used... 😂🤣
You'd be surprised how much cobol is still around and how rich the 'dinosaurs' that still write it earn :)
@@richardlincoln886 I am in my thirties and grew up with a C64 as my first Computer and I am so happy to see and learn new stuff about it. Especially in this time. I am really grateful for this videos! Hope to see many more videos in the future!
Richard Lincoln I still make a very good living writing COBOL.
I think that Structured COBOL book is the textbook my mom used in the late '80s in school. I had to use COBOL (and JCL) in 1997 for my OS principles class.
I learned COBOL and FORTRAN at Control Data in a one week course in Vancouver. Found my hard copies in my old stuff stored at Moms. Incomprehensible.
Love the humor. This makes me feel grateful Kernigham and Ritchie, even though I swore about them in the early 90s.
I took intro to COBOL in university in about 2002/2003. It must have been COBOL 85, as I don't remember the line numbers, but maybe it wasn't.
I think we also had to telnet into an old DEC system (?) made of multiple 486 CPUs. The servers at Trent were called Ebony and Ivory and they handled our email when I was there. They were running COBOL on this old system too. Don't think any old student systems were still running on COBOL when I was there, but I could be mistaken.
I was sad to see they let students working in the IT department tear it apart and make "art" out of the old DEC server. That's how I know it was made of multiple 486 CPUs.
(There was also the ATOP lab where you could telnet, or maybe SSH, into some Ultrasparc workstations with 128MB of RAM. They were slow even by the standards of the day but Sun had donated them so Trent gladly set up a lab for them.)
Fantastic video. I use to program RM Cobol back in 1991-1994 as a student of programming. Good times.
Pretty sure that's what I used in my COBOL class in 1992 too.
It's weird that COBOL 64 doesn't have modulo division. Even MVS 3.8j TK4's COBOL compiler from 1972 has this statement:
DIVIDE (NUMERATOR) BY (DENOMINATOR) GIVING (DIV-RESULT) REMAINDER (MOD-RESULT)
Maybe the manual doesn't mention it, or maybe they just didn't include it for some reason.
Multiple people have mentioned that it *should* be in there even though it's not in the docs. How about it, Mr. 8-Bit Show And Tell (if that is your real name)? Since you've already overcome most of the challenges in understanding COBOL 64, how about just giving it a try with the syntax provided?
My first job in my first year of college (1988) I worked for the campus Information Systems department. While it wasn't directly part of my job, they had me debug several COBOL programs. The experience was fun, but helped me to have no interest in participating in the great COBOL Y2K hiring event.
Welcome to Cobol, it takes 10 times longer to write and is 10 times slower than basic. It also requires 10 times more trees to print it out.. but don't worry... it's readable...just as long as you have a dining table that is long enough...:)
I was in "Computer Explorers", a division of the Boy Scouts, when I was in high school a million years ago. At the time I was very familiar with and fluent in Commodore BASIC and had done a dab of 6502 assembly as well. I was shown a COBOL program running on an IBM minicomputer and my first reaction was "What is this gibberish??" I respect how widespread COBOL was and continues to be even now, but trying to code in it was like trying to say every sentence backwards in Pig Latin, and always gave me a headache. As an IT professional these days, I was forced to take ITIL training. All I can say is the people that created ITIL probably get all excited when they see COBOL statements..
OMG, I was an Computer Explorer as well! I was very lucky in a couple of regards. Our Explorer Post was hosted/sponsored by Bell Labs. Secondly, my dad worked at Bell Labs as well. I built an Apple ][ from the chip-level up from a PCB my dad got from the local Apple group at work. I learned AppleSoft and 6502 assembler in the Explorer post, and also built 6502-mini computer as well. I remember reading about COBOL in high school, and what I remember most about it, was you had those 'coding sheets' to hand write your code out. I was into game coding, and wanted no part of that. Only folks who wanted to wear white shirts and ties (IBM!) would use coding sheets. It was great experience, that set me up wonderfully for my computing career.
COBOL on the C64: Awesome! Back in the days when cavemen wrote programs that worked reliably and didn't need to be replaced every few years. Actually, considering that the C64 has more memory, more auxiliary storage, and a faster processor than the computers that originally ran COBOL, it would be a great batch processing platform-if it weren't considered a toy by the people who make the purchasing decisions.
Fun Fact: The reason why cobol is picky about certain columns is a remnant of the punching card age. The same goes for RPG on IBM Machines. Punching cards had to have certain information always in the same column, thats also why the line numbers have to be 6 digits long.
Most "modern" CoBOL compilers (anything after about 1978) don't care what column anything is in.
I learned COBOL JSP and TP at college. It led to using SAS and then R. It is a very good base system to learn
I used to program in COBOL and I'm only in my 50's. The last time was in the 80's using DEC COBOL on a VAX. I used to drive the old guys crazy by indenting the code and trying to see how few periods I could get away with. Ah the good old days.
"COBOL 64" sounds like a modern microprocessor implementation too. What is old is new again!
I never thought I'd see CoBOL on a 64.... seems so incongruous.... quite fascinating!
Got me thinking now.... I want a CoBOL compiler for AVR and STM32 microcontrollers.... that would be ah-may-zing.
I'd have used PERFORM UNTIL instead of GOTO, and COMPUTE instead of ADD and MULTIPLY. (I really liked using COBOL the COmmon *Business* Oriented to write income tax software. Pascal was painful, and BASIC would have been, too.)
And I see you used Ryan-McFarland in college!
Unfortunately, this implementation of COBOL-74 doesn't have COMPUTE or the UNTIL clause. You can check out the manual here: archive.org/details/COBOL-64_Software_System/mode/2up
My favorite late 70's early 80's computer books were "Enough Cobol" and "Fortran Made Really Easy This Time". I had the CPM board for my 64 and it had Cobol. I also had a Pascal compiler. Those were the days.
The C128 made running almost any CP/M program MUCH easier with the 1571. I was an undergrad doing mainframe languages on punch cards (the school was slow at upgrading equipment). I had learned Pascal (well, Turbo Pascal 2/3) in high school. I loved it. Mainframe Pascal was much different, but easy to adapt to after figuring out the I/O.
Pro Tip: If you use a Fibonacci number based on the number of bits, to multiply the seed, you'll end up with a random number generator that takes a long time to cycle around.
I remember starting to learn Cobol after I had learned BASIC, only because the library had a book about it. And then I thought: WHY? I never finished the book.
I had to learn COBOL in university but I've never had to actually code in it in my professional career. Last year I did however have to look at some COBOL code to understand an old mainframe process that I was replacing with a .NET core API so yes, there is lots of COBOL out there still.
We did not call variables pictures. We called them variables.
Not sure how, but I think people are missing the clever Star Trek reference in the title. Great video, funny title!