@@inerlogic I would totally buy a T-Shirt inspired by this Awesome RU-vid 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.
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...
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 :).
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!
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.
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.
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.
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.
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.
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!
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."
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...
@@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!
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.
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.
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!
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. :)
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.
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)
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
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.
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’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.
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.
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 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.
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.
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.
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.
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.
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 :-)
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.
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 " ".
@@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 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. :)
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.
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 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.
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.
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.
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".)
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.
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)
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.
> 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...
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!
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.
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'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
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.
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 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,
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.
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.
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.
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.
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 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.
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...:)
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.
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 can't believe I learned this stuff in college. At no point did I see my code displayed or executed on a computer. It was all written on COBOL coding sheets. That was a soul-crushing class.
Ugh, that would be miserable. When I was learning to program as a kid, I would hear stories from people one generation older than me about punchcards and coding sheets, and either not getting to see their results, or having to wait hours to get a print out of their run. It sounded horrible; I was so thankful for my Timex Sinclair 1000 and then C64 hooked up to a black & white TV and I could type RUN and see my program run immediately!
19:09 ah just your average dead spiders nest. Always clean up stuff ASAP after unpacking. I learned that from a purchase I made by a guy in Australia. First thought it was hair inside the box, then inside the spine, hidden from sight I found the spider(s). They hide from sunlight. Come out at night... Not CREEPY at all. Just full blast HORRORSHOW!!!
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.
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!
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.
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?
TBH I'm slightly dubious of the claims that there is an surge in demand for COBOL developers that seems to repeat every few years. I think it's much more likely that the demand goes from 0 to 1 or 2 every so often and that counts as a surge. The actual solution to this problem is not to keep digging up old COBOL guys but to get one of them to sit down with someone else and write a transpiler (COBOL->JS apparently already exists), transpile some meaty important code and validate the result by letting it run in parallel with the original COBOL for a few years. Interesting that the habit of writing "this language is the greatest thing since sliced bread and will solve all of your problems" goes all the way back to COBOL.
The current drive is due to the US having a surge in the number of unemployed and the systems inability to cope - specifically the New Jersey Governor Phil Murphy was asking for volunteers with COBOL skills as their 40-year-old mainframe benefits system was besieged by a 1,600% increase in usage. Typical of large institutions - its not broken so do not fix it - damn how do we fix it...
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
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.
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.
As a software engineer since some decades I certainly heard of Cobol, but this is the first listing I've seen. I've done assemebler on 8 and 16 bit systems, some DSP signal processing and most higher level languages but Cobol has the weirdest syntax ever.
I was looking everywhere for how to start this compiler... SYS2051... THANKS! LOL Your system looks so familiar to me! I too have a C64c, a SuperCPU and that SD card reader. Ahhhhh! The spoiled life! :)
