OR EYES!sugar magnolia wrote: ↑Fri May 21, 2021 6:50 pm ...That shit is as bad as glitter to try to get out of your hair and clothes.
Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
- keith
- Posts: 3899
- Joined: Mon Feb 22, 2021 10:23 pm
- Location: The Swamp in Victorian Oz
- Occupation: Retired Computer Systems Analyst Project Manager Super Coder
- Verified: ✅lunatic
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Be assured that a walk through the ocean of most souls Would scarcely get your feet wet
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Back in the stone age we used teletype machines with paper tape. There were two types of tape generators - chad and chadless. On the chadless tape the holes weren’t punched all the way around, so it made a flap rather than a hole. on the chad tape machines, the chad generators had a clear plastic tube where the chad fell. The chadless tape was less messy, but it would often hang up in the tape reader when you went to transmit that message on another circuit.keith wrote: ↑Sat May 22, 2021 4:56 amOR EYES!sugar magnolia wrote: ↑Fri May 21, 2021 6:50 pm ...That shit is as bad as glitter to try to get out of your hair and clothes.
I had an asshole supervisor who used to dump chad on the floor just to make sure the person doing clean-ups actually vacuumed.
"Hey! We left this England place because it was bogus, and if we don't get some cool rules ourselves, pronto, we'll just be bogus too!" -- Thomas Jefferson
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
I cut my programming teeth on FORTRAN4 in school. As a 'professional' the first language I learned was 1401 AUTOCODER (remember WORDMARKS) while still in operations. I soon transferred to applications programming in COBOL. My very first development (as opposed to maintenance) assignment was to write a small system for year end reporting (insurance company) from actuarial definition. The kicker was my systems analyst who had recently 'discovered' Structured Programming wanted the damn thing written entirely in Structured COBOL so he tossed a manual on my desk and told me to "read and digest" before starting to code. The result was a true masterpiece of hideously convuluted PERFORM procedures without a GO TO to be found. It was a maintenance nightmare. I know that because the poor guy doing maintenance on it a couple of years later came to me with a question (Remember AUTHOR is not a required field in the IDENTIFICATION DIVISION) and it took me a half hour to figure out the logic. Hey, in my defense I was a rookie trying to put an overstuffed square pig in a triangular poke.keith wrote: ↑Sat May 22, 2021 4:37 amAnd yet when I first 'played with Cobol' I hated it too. Then when I had to use it in actual anger I had no problem with it, in fact it was great.roadscholar wrote: ↑Fri May 21, 2021 3:27 pm One of my started-but-never-finished Majors in college was Computer Programming. So I had to learn a bit of COBOL, and boy I hated it. Tedious. Long-winded. Mundane. In 1975, Edsgar Dijkstra famously proclaimed that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”
and yet...
My first language was IBM 1401 Autocoder (assembler) and a bit of Fortran. Then BASIC back when it was really basic. Then CDC Assembler with Fortran and a bit of Cobol. I was pretty good with both CDC Assembler and Fortran. But then I got a job at an IBM shop and I got really good with 360 assembler and Cobol. I hacked the lousy ancient Fortran compiler so we could compile SAS and read Census tapes because the freebee Fortran couldn't read multivolume tape files nor the large data records the Census came on. I would put me in the 'super programmer' class during that time - alas I'm far from it today. I got Fortran and Cobol to talk to each other when IBM said it couldn't be done. I got Fortran routines to run under CICS when IBM said it couldn't be done. Years later I got CICS and IMS to communicate seamlessly when IBM said it couldn't be done. I should have applied to do a redbook study on that one. Cobol had one of the first 'Object Orientation' models that you could actually use in real life projects - and yes, it actually looked like Cobol. I got to be pretty good with SAP/ABAP over the years too. Today I do my hobby hacking in Delphi Pascal.
Next they decided I needed to learn 7074 AUTOCODER on the theory it would be faster to convert some of those old programs to COBOL that way. It really wasn't though even when parts of the original definitions were missing.
Then I went to Systems Programming where of course I used 360 ASSEMBLER and even machine language, the System 360 Principles of OPeration (POP) was the Bible. This was in the days when on very rare occasions if you had a bad fix in the middle of the day that was highly impactful you could ZAP the running OS. Along the way I picked up AppleSoft BASIC for my own use and a few other BASICs plus a whole ton of of other support and statistical things.
All of which have pretty much totally decayed since I retired.
-
- Posts: 2146
- Joined: Mon Feb 22, 2021 1:13 pm
- Location: England
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Superzap (imaspzap?), great fun. So long ago can’t remember if it was the one that could overwrite storage using disk addresses.
If you can't lie to yourself, who can you lie to?
- roadscholar
- Posts: 751
- Joined: Mon Feb 22, 2021 11:17 am
- Location: Baltimore
- Occupation: Renaissance Mechanic
- Contact:
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
I'd have bet real money that couldn't be done.I got Fortran and Cobol to talk to each other
The bitterest truth is more wholesome than the sweetest lie.
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Yep, it was fun. Like you it was so long ago since I did it. I forget which was which and which did what. IMA was the IBM utility prefix for that class of utility and I think that overlaid code in RAM. On a side note we had a legendary systems programmer who drank a bit. On mornings when he came in hung over he would lock himself in one of the closets that had a keypunch for the programming staff (pre TSO terminals) and he would pound out the most elegant little programs, mostly utilities that always ran first time every time. When PDSs (Partitioned DataSets) first came into usage the method for recovering lost space (gas) was to dump it to a sequential file and restore it to PDS format. Long before IBM produced their utility to compress a PDS (get rid of the gas) he wrote a utility to do do that. He called it IEBFART.Uninformed wrote: ↑Sat May 22, 2021 1:24 pm Superzap (imaspzap?), great fun. So long ago can’t remember if it was the one that could overwrite storage using disk addresses.
Later I worked with a retired IBM Consulting (insulting?) Engineer. For you very old System 360 operators/programmers he was the guy who wrote the first super utility for System 360 called DEBE pronounced Debbie. DEBE stood for Does Everything But Eat. He wrote it for himself / the site he was working at. People saw it wanted it and he ended up shipping hundreds of copies worldwide on 1500 - 1800 80 column cards.
- Phoenix520
- Posts: 4149
- Joined: Mon Feb 22, 2021 1:20 pm
- Verified: ✅
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
I had an Opel Kadet that had funky wiring. It wouldn’t start if the humidity was above 50% so I always parked at the top of our hill in case it rained overnight.
My current auto has push button start but not on the floor.
My current auto has push button start but not on the floor.
- northland10
- Posts: 5928
- Joined: Mon Feb 22, 2021 6:47 pm
- Location: Northeast Illinois
- Occupation: Organist/Choir Director/Fundraising Data Analyst
- Verified: ✅ I'm me.
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
My push-button start is on my end table.
101010
- sugar magnolia
- Posts: 3382
- Joined: Mon Feb 22, 2021 12:54 pm
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Remote start fobs were all the rage around here until people started getting tickets for leaving their unattended cars running in the driveway to "warm up" in the morning.
-
- Posts: 980
- Joined: Mon Feb 22, 2021 9:11 am
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Clue less youth? Sorry Boomers, I.have to claim my ignorance.in the technology and language used now to navigate the shit imposed upon me since I turned 60. Unless you want to learn outdated crap, shut up.
- noblepa
- Posts: 2521
- Joined: Mon Feb 22, 2021 2:55 pm
- Location: Bay Village, Ohio
- Occupation: Retired IT Nerd
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
A couple of friends of mine and I did that in college in 1971, on an IBM 360 model 40. IIRC, the biggest problem we ran into was that Cobol and Fortran handled the passing of parameters from the calling program to the called subprogram differently. Also, Cobol didn't have any concept of a FUNCTION subprogram, so everything had to be written as a SUBROUTINE.roadscholar wrote: ↑Sat May 22, 2021 1:40 pmI'd have bet real money that couldn't be done.I got Fortran and Cobol to talk to each other
You also had to be very careful about the data types you passed. For example, FORTRAN couldn't handle COMP-3 (packed decimal) data. FORTRAN also didn't understand the data structure of COBOL records, with their 01, 05, 10 and so on, levels.
We never figured out a good reason to have a COBOL program call a FORTRAN subroutine, but it was a fun project. We also had to educate ourselves in IBM 360 assembler language, since reading the assembler output of the compilers helped us figure out how to match the data up.
One of the criticisms of COBOL has always been that it was so wordy. For example, to perform a subroutine, it is common to use the PERFORM paragraph THROUGH paragraph-exit. In truth, this is not necessary. I heard that the PERFORM ... THROUGH option was added to COBOL compilers because back in the fifties, the compilers were not very good, and they sometimes didn't return when you expected them to. In addition, spaghetti code was very common and the concepts of structured programming were decades in the future.
One of the principles of structured programming is that every routine should have precisely one entry point and one exit. Back then, it was common to see three or four paragraph names between the entry paragraph and the exit, with GO TO statements scattered throughout. If you write the called routine properly, using IF ... THEN ... ELSE constructs, the routine will fall through and exit as it should, making the exit paragraph name unnecessary.
I once tried to suggest this and was immediately shot down and told that we ALWAYS used PERFORM ... THROUGH.
I got the same response when I tried to promote the use of non-unique data names.
In COBOL, the data has a very well defined structure. Records are usually 01 level, with fields within the record being 05, 10, or 20 levels. COBOL allows a MOVE CORRESPONDING statement such as MOVE CORRESPONDING RECORD-IN TO RECORD-OUT. The compiler would generate the code to move like named fields. Instead we had to use MOVE INREC-FIELD1 to OUTREC-FIELD1, MOVE INREC-FIELD2 TO OUTREC-FIELD2 and so on.
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
When I began coding in COBOL and I believe it is still the case the only required arguement for a PERFORM is the procedure name. However it is perfectly valid to write something as obnoxious as:
PERFORM MILK-THE-COW THROUGH SHEAR-THE-CAT
VARYING TIME-OF-DAY FROM MORN TILL NITE
BY WHATEVER-FLOATS-YOUR BOAT UNTIL HELL-FREEZES-OVER
OR CAPT-KARL-SOBERS-UP. (Period optional now not then)
A similar piece of code was actually written to build a table of dividend values by someone who will remain nameless to make a snide comment on COBOL's highly touted self documenting capabilities. Now that I think about it it may have been much more risqué.
PERFORM MILK-THE-COW THROUGH SHEAR-THE-CAT
VARYING TIME-OF-DAY FROM MORN TILL NITE
BY WHATEVER-FLOATS-YOUR BOAT UNTIL HELL-FREEZES-OVER
OR CAPT-KARL-SOBERS-UP. (Period optional now not then)
A similar piece of code was actually written to build a table of dividend values by someone who will remain nameless to make a snide comment on COBOL's highly touted self documenting capabilities. Now that I think about it it may have been much more risqué.
-
- Posts: 2146
- Joined: Mon Feb 22, 2021 1:13 pm
- Location: England
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Worst thing I ever encountered was Assembler programmers who wanted to show how clever they were. The original meaning of “web” programming. Nightmare.
If you can't lie to yourself, who can you lie to?
- Frater I*I
- Posts: 3281
- Joined: Mon Feb 22, 2021 10:52 am
- Location: City of Dis, Seventh Circle of Hell
- Occupation: Certificated A&P Mechanic
- Verified: ✅Verified Devilish Hyena
- Contact:
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
That command would cause the whole network to crash and burn...
"He sewed his eyes shut because he is afraid to see, He tries to tell me what I put inside of me
He's got the answers to ease my curiosity, He dreamed a god up and called it Christianity"
Trent Reznor
He's got the answers to ease my curiosity, He dreamed a god up and called it Christianity"
Trent Reznor
- keith
- Posts: 3899
- Joined: Mon Feb 22, 2021 10:23 pm
- Location: The Swamp in Victorian Oz
- Occupation: Retired Computer Systems Analyst Project Manager Super Coder
- Verified: ✅lunatic
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Of course on a CDC machine there was no question about it. But in IBM DOS it was if the compilers were from different planets. But in the end it was actually easy enough. Just call an a little assembler routine that loaded the Cobol run time environment, get the registers loaded properly, make sure you clean up afterwards, and Bob's your uncle. Every thing you needed was actually in the Cobol programmers guide, but nobody ever read that.roadscholar wrote: ↑Sat May 22, 2021 1:40 pmI'd have bet real money that couldn't be done.I got Fortran and Cobol to talk to each other
Getting Fortran to play nice in CICS was a bit tougher. The shop refused to pay for the current release of Fortran, so we were working with obsolete stuff. The only real issue was if the Fortran program issued a wait, it would be an operating system wait, and that is forbodden in CICS. It took me a least a week to find the all the places where the wait could be issued and organize a way to trap them and issue a CICS wait instead.
Fun days.
Be assured that a walk through the ocean of most souls Would scarcely get your feet wet
- keith
- Posts: 3899
- Joined: Mon Feb 22, 2021 10:23 pm
- Location: The Swamp in Victorian Oz
- Occupation: Retired Computer Systems Analyst Project Manager Super Coder
- Verified: ✅lunatic
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
My use case was a CICS tranaction that needed to do an Economic Ordering Quanty calculation.noblepa wrote: ↑
We never figured out a good reason to have a COBOL program call a FORTRAN subroutine, but it was a fun project.
Be assured that a walk through the ocean of most souls Would scarcely get your feet wet
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Eh, just throw some C glue in and anything talks to anything. Though I was pretty spoiled with the GNU toolchain by the time I was dealing with such things.roadscholar wrote: ↑Sat May 22, 2021 1:40 pmI'd have bet real money that couldn't be done.I got Fortran and Cobol to talk to each other
- bill_g
- Posts: 5824
- Joined: Mon Feb 22, 2021 5:52 pm
- Location: Portland OR
- Occupation: Retired (kind of)
- Verified: ✅ Checked Republic ✓ ᵛᵉʳᶦᶠᶦᵉᵈ
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
I'm secretly envious of people that can do programming at any level.
I had to work in assembly in the late 70's to get my EE. My lab projects centered on MC6800 processor. I successfully muddled through it, but when I dipped my toe in higher languages, my brain turned to mush. That said, my puzzle brain loved recursive loops and IF THEN ELSE statements. That seemed to be my super power, and what I could bring to a group project.
Clocking and timing seemed to be another strength along with immunity - getting rid of noise in circuits. All that led me into field application, and getting stuff to bend to my will after it had been sold and implemented but failed to live up to customer expectations. As my degree aged and younger engineers were coming on the job, I became the OG that did the physicality of a project while the keyboard warriors worked remotely after I got something turned up enough to be reached.
It's a living.
I had to work in assembly in the late 70's to get my EE. My lab projects centered on MC6800 processor. I successfully muddled through it, but when I dipped my toe in higher languages, my brain turned to mush. That said, my puzzle brain loved recursive loops and IF THEN ELSE statements. That seemed to be my super power, and what I could bring to a group project.
Clocking and timing seemed to be another strength along with immunity - getting rid of noise in circuits. All that led me into field application, and getting stuff to bend to my will after it had been sold and implemented but failed to live up to customer expectations. As my degree aged and younger engineers were coming on the job, I became the OG that did the physicality of a project while the keyboard warriors worked remotely after I got something turned up enough to be reached.
It's a living.
- zekeb
- Posts: 834
- Joined: Mon Feb 22, 2021 1:12 pm
- Location: Strawberry Hill
- Occupation: Stable genius. One who tosses horseshit with a pitchfork and never misses the spreader.
- Verified: ✅Of course
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
COBOL programming using punch cards for line by line inputs. It's bad enough when you can type. I can't type. COBOL. FORTRAN. Where have all the good languages gone? I snark.
Largo al factotum.
- roadscholar
- Posts: 751
- Joined: Mon Feb 22, 2021 11:17 am
- Location: Baltimore
- Occupation: Renaissance Mechanic
- Contact:
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
I just read enough of the COBOL manual to pass the tests.neeneko wrote: ↑Sun May 23, 2021 9:50 amEh, just throw some C glue in and anything talks to anything. Though I was pretty spoiled with the GNU toolchain by the time I was dealing with such things.roadscholar wrote: ↑Sat May 22, 2021 1:40 pmI'd have bet real money that couldn't be done.I got Fortran and Cobol to talk to each other
I did more FORTRAN because I was drinking myself out of PreMed studies for the second time. Punched card decks.
C wasn’t around yet, in low-grade academia at least.
The bitterest truth is more wholesome than the sweetest lie.
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
Off Topic
hoo boy, the computer languages I've abused
In roughly chronological order:
FOCAL-8
Basic (on DTSS)
PDP-8 Assembler
FORTRAN (freshman in college)
DYNAMO
PDP-11 assembler
6800 assembler
(graduates from college)
LISP
C
National 32000 assembler (!)
VAX-11 assembler
DECSIM (here our hero learns that hardware and software are really the same thing)
VHDL
BLISS (but not much)
MIPS assembler
ALPHA assembler
PowerPC Assembler
ARM Assembler
MSP-430 Assembler
Golang
But mostly I do C. Very occasionally I have to go into assembler for either interface stuff (like the language interface issues mentioned above) or when doing performance analysis/improvement.
not too shabby for a "Microwave Engineer"
In roughly chronological order:
FOCAL-8
Basic (on DTSS)
PDP-8 Assembler
FORTRAN (freshman in college)
DYNAMO
PDP-11 assembler
6800 assembler
(graduates from college)
LISP
C
National 32000 assembler (!)
VAX-11 assembler
DECSIM (here our hero learns that hardware and software are really the same thing)
VHDL
BLISS (but not much)
MIPS assembler
ALPHA assembler
PowerPC Assembler
ARM Assembler
MSP-430 Assembler
Golang
But mostly I do C. Very occasionally I have to go into assembler for either interface stuff (like the language interface issues mentioned above) or when doing performance analysis/improvement.
not too shabby for a "Microwave Engineer"
Daughter went to a fancy party at a fancy venue somewhere south of Delray. Valet-only parking.
She drives a Golf R, with a 6-speed manual.
Nobody could drive it. She finally said "Look, is there a parking garage somewhere around here I can stick it in?"
She asked "But but what about all these people with ferraris and lambos and etc etc.."
Valet guy: "I've never driven one of those. I think they bring their own people to park their car."
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
By the time I was in school, FORTRAN was in use within research groups (which is how I learned it), but no longer taught. COBOL on the other hand, the university would not teach it, but it was close enough to y2k that I knew people who would read through a COBOL book enough to get the idea, drop out of school, and went straight to $80/hour contract work.roadscholar wrote: ↑Sun May 23, 2021 3:31 pm I just read enough of the COBOL manual to pass the tests.
I did more FORTRAN because I was drinking myself out of PreMed studies for the second time. Punched card decks.
C wasn’t around yet, in low-grade academia at least.
The year after me, they switched to teaching only Java, C++, and Javascript, and they were pretty half hearted with the C++. Dull times ahead. Luckily embedded/OS classes were C/VHDL, and AI classes still taught LISP & Prolog, so there was at least still SOME variety.
- noblepa
- Posts: 2521
- Joined: Mon Feb 22, 2021 2:55 pm
- Location: Bay Village, Ohio
- Occupation: Retired IT Nerd
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
qbawl wrote: ↑Sat May 22, 2021 6:24 pm When I began coding in COBOL and I believe it is still the case the only required arguement for a PERFORM is the procedure name. However it is perfectly valid to write something as obnoxious as:
PERFORM MILK-THE-COW THROUGH SHEAR-THE-CAT
VARYING TIME-OF-DAY FROM MORN TILL NITE
BY WHATEVER-FLOATS-YOUR BOAT UNTIL HELL-FREEZES-OVER
OR CAPT-KARL-SOBERS-UP. (Period optional now not then)
A similar piece of code was actually written to build a table of dividend values by someone who will remain nameless to make a snide comment on COBOL's highly touted self documenting capabilities. Now that I think about it it may have been much more risqué.
That was my point. The language does not require PERFORM ... THROUGH ..., but in every shop I ever worked in, the culture, if not written policies, required that you write something like
PERFORM GET-PAYROLL-MASTER-RECORD THROUGH GET-PAYROLL-MASTER-FILE-EXIT.
I tried to argue that this was not necessary, but I was always shot down. And, the paragraph names were usually much longer.
I actually didn't (and still don't) have a problem with long variable names and long paragraph names that COBOL encourages. If done properly, it can make the program a little more understandable.
Re: Clueless Youth Struggle With Old Technology & Stuff We Grew Up With
IMHO structured programming was the cause of the trend for needlessly verbose multi argument PERFORM statements.The dreaded GO TO was to be avoided at all cost lest you become accused of creating spaghetti code. To be fair I was a proponent of structured code for many reasons. Still a well placed GO TO could be useful (don't venture outside the scope of the current PERFORM though, because 'Here be dragons.')noblepa wrote: ↑Sun May 23, 2021 7:31 pmThat was my point. The language does not require PERFORM ... THROUGH ..., but in every shop I ever worked in, the culture, if not written policies, required that you write something likeqbawl wrote: ↑Sat May 22, 2021 6:24 pm When I began coding in COBOL and I believe it is still the case the only required arguement for a PERFORM is the procedure name. However it is perfectly valid to write something as obnoxious as:
PERFORM MILK-THE-COW THROUGH SHEAR-THE-CAT
VARYING TIME-OF-DAY FROM MORN TILL NITE
BY WHATEVER-FLOATS-YOUR BOAT UNTIL HELL-FREEZES-OVER
OR CAPT-KARL-SOBERS-UP. (Period optional now not then)
A similar piece of code was actually written to build a table of dividend values by someone who will remain nameless to make a snide comment on COBOL's highly touted self documenting capabilities. Now that I think about it it may have been much more risqué.
PERFORM GET-PAYROLL-MASTER-RECORD THROUGH GET-PAYROLL-MASTER-FILE-EXIT.
I tried to argue that this was not necessary, but I was always shot down. And, the paragraph names were usually much longer.
I actually didn't (and still don't) have a problem with long variable names and long paragraph names that COBOL encourages. If done properly, it can make the program a little more understandable.