Re: Kinda fun
I'm pretty sure this happened with VM, though might have been with OS/360 and HASP. User brought odd printout (1403 or 3211) to system programming, asked what happened. It showed two output streams overprinted -- like a double exposed photo. Clearly impossible, but there it was. Research eventually revealed that someone had violated best practices and allowed a user into computer room. She had output, dropped it in a recycle box. Except it wasn't recycle, was next box of paper to be used. So operator fed it through printer without noticing it had been used. It was printed on again as part of someone else's output, which they received. Go figure, offender was already a user not popular with either operators or system programmers so this was just another strike on the scorecard. On Fri, 10 Nov 2023 23:12:23 -0800, Leonard D Woren wrote: >Bob Bridges wrote on 11/8/2023 6:56 AM: >> Reminds me of an old tagline: >> >> /* The more sophisticated the technology, the more vulnerable it is to >> primitive attack. People often overlook the obvious. -Dr Who, 1978 */ > >Long ago I was told why my shop didn't carpet the tape storage area. >Apparently some shop that did had a problem with unreadable tapes. >Eventually they figured out that all the unreadable tapes were on the >bottom row of the tape storage. And the outside cleaning people used >a vacuum cleaner... > > >Farley, Peter wrote on 11/8/2023 7:58 AM: >> 1401N1 printer (the big beast) raised its hood automatically when it ran out >> of paper, no way to turn off that behavior. NEVER put your coffee cup on >> top of that printer!! > >Supposedly the reason that IBM put that feature on the 1403 was some >big shops had a lot of 1403s and it helped the operator find the >printer that needed to be fed. Unfortunately, the feature didn't have >a failsafe. It was common to stack boxes of paper behind the >printer. At least once at UCLA, someone had stacked it one box too >high, and when the printer cover went up, the back end of the cover >was blocked by the too-high stack, raising the printer off the floor. > >And BTW, the 3211 had a "raise cover" CCW. I had some fun with that, >and one of the other IBM-MAIN readers probably remembers that, from >Post 360. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Will AI free Bill Johnson? (was AI will surpass human intelligence!)
ChatGPT Isn't Coming for Your Coding Job New technologies have long promised to make human software engineers redundant. But developers have only gotten more important over time. Software engineers have joined the ranks of copy editors, translators, and others who fear that they’re about to be replaced by generative AI. But it might be surprising to learn that coders have been under threat before. New technologies have long promised to “disrupt” engineering, and these innovations have always failed to get rid of the need for human software developers. If anything, they often made these workers that much more indispensable. To understand where handwringing about the end of programmers comes from—and why it’s overblown—we need to look back at the evolution of coding and computing. ... Bearing this history in mind, claims that ChatGPT will replace all software engineers seem almost assuredly misplaced. https://www.wired.com/story/chatgpt-coding-software-crisis/ ...and, of course, this can be generalized about other AI tools. They're tools, not independent actors. On Sat, 16 Sep 2023 15:23:09 +, Bill Johnson wrote: >I’m going to laugh when AI replaces many of you assembler deniers. The under >40 for sure. Maybe the under 50. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AI will surpass human intelligence!
You could also incorrectly "tell" that I didn't have a college degree. You have a talent for gratuitous insults and an obsession with starting and then arguing about wild digressions from whatever was the topic at hand. AI to assembler language to system programming demographics is quite the meander; each of those would have been worth separate discussions, but not in the unpleasant way you bring them up and then harangue anyone who disagrees with you. A basic question is why, since you disdain everyone here and disagree with most of what people say, you're still here. You're not changing minds, not making friends, not providing useful information, and not contributing anything. You're excellent at trolling though, which seems to be your sad reason for being. So you're entertaining, in a ghastly sort of way. On Fri, 15 Sep 2023 18:33:25 +, Bill Johnson wrote: >Are you that naive? Ever been to Share? The current makeup of mainframe >systems programmers is 65% white, 15% Asian, 9% Hispanic & 5% African >American. Factoring in most of the heavy posters are over 50, the demographics >are even more white since almost all systems programmers who got into IT in >the 50’s through the 70’s were almost exclusively white. Guess what? I can >also tell which people are Jewish, Asian, Hispanic, Scandinavian, Irish, and >most other ethnicities. That’s not nearly as easy but it’s not as difficult as >you’d think. I’d bet Oujeski isn’t a black guy. My Father in Law’s name was >Majewski. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
Yeah, sigh. It's sometimes hard to let pass nonsense such as what he spouted about assembler language. But of course when his assertions are demolished, he resorts to distractions such as whether degrees matter and who's had the most short-term employments. Anyone here with as misguided an opinion about what constitutes system programming isn't going to be convinced by reality. So, done. On Mon, 4 Sep 2023 20:43:05 +, August Carideo wrote: >Why don�t you guys just email each other directly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
Too funny. Basic research (LinkedIn, etc.) would have revealed my degree. Research ability is another important system programming skill you haven't exhibited. You've listed dozens of places you've worked (with apparently consistently short tenures) and various products you've touched but haven't said a word about anything you've accomplished. Claimed employers and skills and credentials are worthless without something to show for them. Listing my projects done using assembler language is simply stating facts. Your listing your degree and places you've worked is indeed irrelevant puffery. Now let's return to your nonsensical assertions about assembler language. On Mon, 4 Sep 2023 20:18:13 +, Bill Johnson wrote: >I’ve listed my skills and jobs here. Worked for numerous companies, some >rather large, (GM, Revco, Parker Hannifin, Kaiser Permanente, Kent State, Phar >Mor, Mellon Bank, First Energy, American Electric Power, Alltel, Medical >Mutual of Ohio, Microfocus, and others. I can tell you’re not a college grad. >Because you downplay what you lack. And try so hard to puff yourself up as >well as others who couldn’t hack college. > > >Sent from Yahoo Mail for iPhone > > >On Monday, September 4, 2023, 4:11 PM, g...@gabegold.com >wrote: > >That's correctly spelled z/OS. Even beginning system programmers should know >that. > >Degrees are often most relevant to people who rely on them for credibility, >vs. having actual qualifications and experience. > >"Unless you work for IBM, you’re likely an installer of zOS" shows profound >ignorance of what system programming actually entails: making effective >business-related use of what IBM and other vendors provide. Not just >installing -- that's a poor excuse for what system programming has been for >decades. It's too bad that in your decades of IT work at those dozens of jobs >(so many, such short tenures?) you never encountered the real thing. > >Your attitude towards a skill you don't posses is fascinating. Seems a lot >like sour grapes: > >refers to an attitude in which someone adopts a negative attitude to something >because they cannot have it themselves. > >Have you felt inadequate seeing assembler code you couldn't understand on the >list? > >Perhaps cheer yourself up by reading some comfortable JCL, or utility control >statements. And set some nice variables to feel better. > >On Mon, 4 Sep 2023 00:06:16 +, Bill Johnson wrote: > >>Degrees are never relevant to the non-degreed. Unless you work for IBM, >>you’re likely an installer of zOS. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
Not that it matters -- or that I rely on it for credentials/credibility -- but I do, B.S. in Applied Mathematics. Wrong again, you are. About so much. My point is that many excellent programmers (system and application) don't have degrees - and are no less excellent for that omission. And besides you I can't think of another working programmer who trumpeted their supposed credentials vs. real-world on-the-job accomplishments. What in the world does having a degree have to do with whether assembler language is a valuable/useful skill? Even for low-level grunt work such as yours, installing z/OS, how does your degree in Math/CS help? You've wandered far afield from the actual topic -- your misunderstanding that the essence of system programming isn't installing things. On Mon, 4 Sep 2023 20:12:41 +, Bill Johnson wrote: >No doubt you don’t have one. > > >Sent from Yahoo Mail for iPhone > > >On Monday, September 4, 2023, 4:11 PM, g...@gabegold.com >wrote: > >That's correctly spelled z/OS. Even beginning system programmers should know >that. > >Degrees are often most relevant to people who rely on them for credibility, >vs. having actual qualifications and experience. > >"Unless you work for IBM, you’re likely an installer of zOS" shows profound >ignorance of what system programming actually entails: making effective >business-related use of what IBM and other vendors provide. Not just >installing -- that's a poor excuse for what system programming has been for >decades. It's too bad that in your decades of IT work at those dozens of jobs >(so many, such short tenures?) you never encountered the real thing. > >Your attitude towards a skill you don't posses is fascinating. Seems a lot >like sour grapes: > >refers to an attitude in which someone adopts a negative attitude to something >because they cannot have it themselves. > >Have you felt inadequate seeing assembler code you couldn't understand on the >list? > >Perhaps cheer yourself up by reading some comfortable JCL, or utility control >statements. And set some nice variables to feel better. > >On Mon, 4 Sep 2023 00:06:16 +, Bill Johnson wrote: > >>Degrees are never relevant to the non-degreed. Unless you work for IBM, >>you’re likely an installer of zOS. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
That's correctly spelled z/OS. Even beginning system programmers should know that. Degrees are often most relevant to people who rely on them for credibility, vs. having actual qualifications and experience. "Unless you work for IBM, you’re likely an installer of zOS" shows profound ignorance of what system programming actually entails: making effective business-related use of what IBM and other vendors provide. Not just installing -- that's a poor excuse for what system programming has been for decades. It's too bad that in your decades of IT work at those dozens of jobs (so many, such short tenures?) you never encountered the real thing. Your attitude towards a skill you don't posses is fascinating. Seems a lot like sour grapes: refers to an attitude in which someone adopts a negative attitude to something because they cannot have it themselves. Have you felt inadequate seeing assembler code you couldn't understand on the list? Perhaps cheer yourself up by reading some comfortable JCL, or utility control statements. And set some nice variables to feel better. On Mon, 4 Sep 2023 00:06:16 +, Bill Johnson wrote: >Degrees are never relevant to the non-degreed. Unless you work for IBM, you’re >likely an installer of zOS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
You'll rely on vendors anticipating with variables every possible requirement for every installation? What happens when management comes to IT with an urgent business case-justified request? Tell them so sad, too bad, our vendor doesn't allow that? You consider filling in variables to be system programming? Solving intricate business case technology problems will be automated? By systems like ChatGPT that hallucinate? And who'll judge what this magic automation creates for correctness, completeness, security, performance, reliability? And how will it be maintained -- by more automation? Those aren't serious positions. On Sun, 3 Sep 2023 22:59:00 +, Bill Johnson wrote: >Easy, the Vendors will have it set up for you to fill in some variables. White >collar IT workers will be automated out of jobs. The first wave of automation >killed blue collar jobs. The next wave will eliminate lots of white collar >jobs. > > >Sent from Yahoo Mail for iPhone > > >On Sunday, September 3, 2023, 6:48 PM, Jeremy Nicoll > wrote: > >On Sun, 3 Sep 2023, at 23:41, Bill Johnson wrote: >> Anyone considering assembler training first off will be hard pressed to >> find any training classes, and in 5 years AI will be able to produce >> better assembler programs than anyone here can write. > >How will anyone spec for the AI precisely what an assembler routine >has to do? > >Suppose it's an exit that has to support a mix of specific vendor >software and work in a site-specific way? > >I'm not saying it's impossible; it just strikes me that whoeever codes >the spec (in some yet to be imagined formal form) will in some sense >be writing the code. THEY need to understand the ins & outs... > >-- >Jeremy Nicoll - my opinions are my own. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is the IBM Assembler List still alive
None of "DB2 DBA, DASD Admin, contractor, programmer analyst, manager of operations, programmer, and Operations" are system programming -- so aren't relevant to this discussion. Many people calling themselves system programmers are in fact installers/configurers/administrators. Those are all useful, but also aren't what most people consider system programming. Without assembler skills, how do you program -- or even fully understand -- systems written in assembler? What I described doing is what most people consider system programming -- maintaining/developing/enhancing system-level software -- and involved skills shared by all the others on my teams at Mitre and VMSG. Someone without assembler fluency would have been useless in both places. Degrees aren't relevant -- that's... The credentials fallacy is a logical fallacy that occurs when someone dismisses an argument by stating that whoever made it doesn't have proper credentials, so their argument must be wrong or unimportant. ...some of the best system programmers I've known had no degree. So good for you, degree in math and CS -- but so what? In this discussion, you're downplaying yourself with uninformed comments. As a system programmer without assembler skills, what did you DO? Not where did you work, what did you do that was system programming? And resorting to name calling, the last resort of bad arguments? On Sun, 3 Sep 2023 22:38:25 +, Bill Johnson wrote: >Sure David, I’ve never been a Systems Programmer other than the last 19 years. >Before that, I was a DB2 DBA, DASD Admin, contractor, programmer analyst, >manager of operations, programmer, and Operations for one of the largest auto >companies on the planet. I’ve worked in numerous industries, large and small >companies, and have a Math & Computer Science degree. Not the idiotic 2 year >tech degree that many colleges created to fast track kids into a burgeoning IT >industry. But keep trying to downplay me idiot. > > >Sent from Yahoo Mail for iPhone > > >On Sunday, September 3, 2023, 5:24 PM, David Spiegel ><0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > >HI Bill, >More vacuous and specious arguments. > >You said: "... In fact, making changes to delivered software can be >dangerous. ..." >Writing/modifying Exits is not the same as your statement. > >It is evident from what you've written, that you've never been a Systems >Programmer, the highest mainframe technical calling. >Yes, I am being elitist. People who can't/won't code Assembler should >know their place and should not be so arrogant in groups like this. >It almost seems like you're jealous of those of us who do this for a living. > >It took 3 of you to modify an IEFUSI?! Hah! How freaking "bush league". >Grow up and learn some Assembler. > >Regards, >David > >On 2023-09-03 12:37, Bill Johnson wrote: >> 1 persons experience doesn’t prove anything. The fact is assembler is >> becoming less and less important as a skillset. Anyone who thinks learning >> it now is a worthwhile exercise is a fool. Yeah, I went through college when >> Assembler was a mandatory course and COBOL was an elective. Guess which was >> infinitely more critical in my career! In college we coded almost >> exclusively in PL/I, which I’ll bet was in deference to IBM. Never used it >> once in the real world. Like I mentioned previously, one professor said >> there’s no reason to learn JCL because it will be obsolete soon. That was >> 1980. JCL was probably the most important skill of my career. I did make one >> misstatement earlier about never using Assembler. One time around 2010, we >> needed to change IEFUSI. Three of us were able to make the necessary >> adjustments. >> >> In 40+ years in IT, 20+ in tech support, other than the one time mentioned >> above, none of my colleagues ever needed to make changes to assembler code. >> In fact, making changes to delivered software can be dangerous. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Sunday, September 3, 2023, 11:45 AM, g...@gabegold.com >> wrote: >> >> I've only had three jobs (3, 14, 6 years duration) before switching to >> freelance writing/editing/consulting in 1994. But I'll chime in anyway with >> my experience using assembler as a critical part of my work. I learned and >> used it at IBM doing operating system development. >> >> Second job was at Mitre Corporation in Virginia, where we installed early >> VM. I developed tools such as a system automation tool used widely in the VM >> community. Same for an early system performance monitor, also widely used. I >> enhanced the interface routine for
Re: Is the IBM Assembler List still alive
That "one person's experience" was widely shared among the VM community -- hundreds of people collectively helping their installations benefit from what assembler language enables. You might consider taking your own advice: 1 persons experience doesn’t prove anything. "The fact is..." is an assertion, not a fact. It's contradicted by a great many people who've used assembler to advance careers and benefit their employers. Given the number of critical bugs fixed by customers, and the number of customer system enhancements merged into IBM product code, sometimes NOT "making changes to delivered software" can be dangerous. Assembler -- machine language -- is what actually executes, no matter what high-level language or utility uses/produces it. So understanding it helps understand much broader concepts. Your not encountering it among your colleagues might speak more about you and your colleagues than assembler language itself. Why advocate ignorance of a fundamental part of the platform for which you're such a relentless cheerleader? This is a silly argument -- you dismiss and deprecate something you never learned; that's an uninformed position to take, no matter how many colleagues you've met in your many, many jobs. Surely it's a specialized skill -- which you never acquired -- but that doesn't make it unimportant. On Sun, 3 Sep 2023 16:37:39 +, Bill Johnson wrote: >1 persons experience doesn’t prove anything. The fact is assembler is becoming >less and less important as a skillset. Anyone who thinks learning it now is a >worthwhile exercise is a fool. Yeah, I went through college when Assembler was >a mandatory course and COBOL was an elective. Guess which was infinitely more >critical in my career! In college we coded almost exclusively in PL/I, which >I’ll bet was in deference to IBM. Never used it once in the real world. Like I >mentioned previously, one professor said there’s no reason to learn JCL >because it will be obsolete soon. That was 1980. JCL was probably the most >important skill of my career. I did make one misstatement earlier about never >using Assembler. One time around 2010, we needed to change IEFUSI. Three of us >were able to make the necessary adjustments. > >In 40+ years in IT, 20+ in tech support, other than the one time mentioned >above, none of my colleagues ever needed to make changes to assembler code. In >fact, making changes to delivered software can be dangerous. > > >Sent from Yahoo Mail for iPhone > > >On Sunday, September 3, 2023, 11:45 AM, g...@gabegold.com >wrote: > >I've only had three jobs (3, 14, 6 years duration) before switching to >freelance writing/editing/consulting in 1994. But I'll chime in anyway with my >experience using assembler as a critical part of my work. I learned and used >it at IBM doing operating system development. > >Second job was at Mitre Corporation in Virginia, where we installed early VM. >I developed tools such as a system automation tool used widely in the VM >community. Same for an early system performance monitor, also widely used. I >enhanced the interface routine for IBM's OS-based GPSS simulation tool to >support external calls to assembler code, needed by a user. I and other system >programmers developed many other assembler-based tools which met the needs of >our users, who worked on various government-sponsored projects. A noteworthy >project for me was getting graphics software developed for CP/67 CMS to work >under VM/370 CMS, allowing a sophisticated simulation system to drive an IBM >2250 graphics display device. That application modeled air traffic control, >allowing someone in the data center to "fly" a Linc Trainer small aircraft >which interacted with simulated aircraft on 2250 screen to model different >collision avoidance algorithms. The graphic software was many thousand lines >of assembler (with comments in French, since it had been developed at >University of Grenoble). We also -- as did the rest of the VM community -- >used assembler to understand, debug, fix, and enhance VM. > >Third job was at VM Systems Group, small vendor >developing/marketing/selling/supporting enterprise software. Two early >products allowed taking snap dumps of the system and intercepting and avoiding >VM ABENDs -- written in assembler, of course, since they integrated into IBM >supplied operating system code. > >So assembler has been a lifelong part of what I consider to be system >programming. And as others have noted, it's also occasionally essential in >meeting application requirements. It also provides a good conceptual >understanding of how things work at a lower level than that of high-level >languages, so was helpful in understanding/explaining to users w
Re: Is the IBM Assembler List still alive
I've only had three jobs (3, 14, 6 years duration) before switching to freelance writing/editing/consulting in 1994. But I'll chime in anyway with my experience using assembler as a critical part of my work. I learned and used it at IBM doing operating system development. Second job was at Mitre Corporation in Virginia, where we installed early VM. I developed tools such as a system automation tool used widely in the VM community. Same for an early system performance monitor, also widely used. I enhanced the interface routine for IBM's OS-based GPSS simulation tool to support external calls to assembler code, needed by a user. I and other system programmers developed many other assembler-based tools which met the needs of our users, who worked on various government-sponsored projects. A noteworthy project for me was getting graphics software developed for CP/67 CMS to work under VM/370 CMS, allowing a sophisticated simulation system to drive an IBM 2250 graphics display device. That application modeled air traffic control, allowing someone in the data center to "fly" a Linc Trainer small aircraft which interacted with simulated aircraft on 2250 screen to model different collision avoidance algorithms. The graphic software was many thousand lines of assembler (with comments in French, since it had been developed at University of Grenoble). We also -- as did the rest of the VM community -- used assembler to understand, debug, fix, and enhance VM. Third job was at VM Systems Group, small vendor developing/marketing/selling/supporting enterprise software. Two early products allowed taking snap dumps of the system and intercepting and avoiding VM ABENDs -- written in assembler, of course, since they integrated into IBM supplied operating system code. So assembler has been a lifelong part of what I consider to be system programming. And as others have noted, it's also occasionally essential in meeting application requirements. It also provides a good conceptual understanding of how things work at a lower level than that of high-level languages, so was helpful in understanding/explaining to users what was going in on in their applications. On Fri, 1 Sep 2023 14:43:36 +, Bill Johnson wrote: >Which proves my point from a prior thread that coding and using assembler is >almost nonexistent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: End of several eras
And it will never be known what OCO cost IBM, customers, and the industry in terms of customer contributions/fixes/innovations it prevented. In VM-land, where source was once complete, its progression was like a light on a dimmer switch slowly fading out. But that's an old, settled, war. Maybe someone will earn a PhD documenting it. On Mon, 21 Nov 2022 17:25:00 -0800, Michael Stein wrote: >On Mon, Nov 21, 2022 at 06:06:43PM -0600, g...@gabegold.com wrote: >> Fiche was fun. > >yes, definitely. > >I remember using fiche two versions back (save that old fiche) to help >make a fix in VTIOC (TSO/VTAM) hung users which couldn't be canceled. > >And telling OPEN/CLOSE/EOV the line number containing the change they >had made which broke my program (they said it explained a lot of other >things they had seen). > >Also a small one bit change to 3830 microcode to prevent channel >disconnect (the 3830 was connected to a 360/91 selector channel). >Along with this was a 360 program run at IPL time which sent the 3830 >a microcode program to zap the bit. > >I always wonder how gradual OCO really was since there was a lot >of old fiche around. But, I'd guess, gradually the fixes from the >field slowed down to a trickle. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: End of several eras
Fiche was fun. Up to 370/148, microcode fiche was provided, including microcode problems. Browsing, I found one problem described as, "When LM instruction specifies same register twice -- that is, to load one register -- all 16 registers are loaded". Oops. And once, working on an interesting but stupid project that involved validating opcodes behaving properly (because management heard loony advice from an alleged industry expert that 4341 wouldn't be fully compatible architecture) several opcodes that shouldn't have existed did, didn't 0C1. Microcode fiche revealed that they were assist instructions for VS/1, etc. On Mon, 31 Oct 2022 23:46:40 -0500, Brian Westerman wrote: >I agree, I can't possibly convey how much I learned from some old IBM fiche >that I had access to in the computer center when I just started college. The >first really important thing I wrote (I was 17) were mods to pass the >condition codes from step to step within JES2 and then send the highest one to >the console and syslog at job end. I later learned that others had done the >same thing, and long before me, but I learned a lot. That code didn't work >with the first version of MVS I was exposed to after college, so it was >followed by doing that same thing with two jes exits and then even later >writing our companies Automation software that pulls the condition codes from >the same fields they were placed in originally way back then. > >Everything I have written over the years is still based on concepts and >techniques that I first learned by looking at the code in the IBM fiche. > >I had an extra advantage in that I worked for IBM throughout that same time >and was able to see some truly spectacular coding techniques and I am truly >thankful for that opportunity. > >I realize that IBM wanted to keep nefarious people from copying the code, but >I think that we lost a great deal of experience and expertise when we lost >access to the code. Some of those techniques are just not around for people >to examine and learn from, and that's very sad. > >Brian > > > >On Mon, 31 Oct 2022 19:42:50 -0400, David Spiegel >wrote: > >>Hi Tom, >>1983, eh? >>The same year as the (expletive deleted) OCO policy. >>I've seen IBM-lifers defend it on this forum, yet, it still did not/does >>not make sense. >> >>Regards, >>David >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM ordered to pay $1.6b to BMC
I left IBM in 1971 after working there three years. It was a great first job and I left on wonderful terms, was invited to return after getting real-world (that is, customer) experience. Three years, of course, meant that IBM's pension plan/benefits weren't relevant to me. I got plenty of customer -- and then ISV -- experience though neglected to return. But as a customer and then ISV executive I had a rewarding decades-long relationship with IBM, including, for a few years, editing and writing a technology magazine for them. So speculating that I'm in any way motivated as a disgruntled ex-IBMer is laughable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM ordered to pay $1.6b to BMC
OK, got it -- you're here to rant and insult. Good that it amuses you. This is pretty far from useful discussion of mainframes -- the reason the rest of us are here. Bye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM ordered to pay $1.6b to BMC
Bill, what's your goal in arguing about IBM? To convince people of anything or just to rant? Reflexively denying things -- mostly without credible facts or logical substance -- and insulting people with whom you disagree, isn't effective debating. You just look silly, alienate people, and certainly don't change anyone's mind. If you'd actually gone to law school instead of doing whatever you've done since you passed up that opportunity for education, you might have learned how to make cogent and perhaps convincing arguments, without personal attacks. It's a serious question -- what's your goal? Are you achieving it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reliable source for OCO?
I'm still here, though not posting much these days. I pulled out my source file
-- about 1 1/2 inches thick, including SHARE SSD (SHARE Secretary's
Distribution, as opposed to solid state device!) #349 from August 1986, and
SHARE 64 Session #0042, "All Your Fears are Sourceless" (report of the VM
Source Committee). But I don't think Wikipedia accepts my file cabinet as
secondary source (that word again!). Plus clippings, etc. I'll see whether
anything useful I have is available online -- though it's likely all from 1980s
so might not be conclusive proof of current status.
On Thu, 14 Apr 2022 11:23:09 -0400, Tony Harminc wrote:
>On Thu, 14 Apr 2022 at 07:37, Seymour J Metz wrote:
>
>> I'm editing the wikipedia [[Operating system]] article, and another editor
>> has challenged the sentence "The logic manuals for their contemporary
>> descendants, z/VM, z/VSE and z/VM, are not available to the general public."
>> What are the relevant URLs for IBM's policy? Thanks.
>
>The OCO (or more subtle) status of current software is in the
>announcement letters. Using IBM URLs as a reference is a bit of a
>trap, because IBM so frequently removes and rearranges things, and
>seems to have a global robots.txt that prohibits pretty much
>everything.
>
>It's not obvious to me that the existence of published logic manuals
>aligns with the OCO status of a product. IIRC many products that were
>not OCO have still had logic manuals withdrawn in favour of
>"diagnostic guides" and the like. At the same time some of those
>diagnostic books are remarkably detailed, and the logic is described
>or can be inferred even though the source code is not available.
>
>I also seem to remember some discussion of this on this very list,
>including the definitions of terms like "restricted materials of IBM",
>"object code only", and so on. I'm not finding them in a quick search,
>but one thing that did come up is a 2018 post from Gabe Goldberg, who
>said he had "my OCO file -- a decade or so worth of material
>documenting IBM's folly removing source code ("Object Code Only" for
>those who didn't live through it). " Might be worth contacting him.
>I'm not sure he's still active on this list, but g...@gabegold.com
>looks to be current.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagram of MVS Control Blocks
I'll bet 99% of people -- even those who ran OS/360 -- didn't t know what Roll out / Roll in did. I found it included in Mitre OS/360 SYSGEN when I joined company in 1971, laughed, exercised it, removed it -- saving xxKB from resident nucleus, back when bytes were precious. It enabled JCL options, something like Rollout=yes and Rollin=yes. Specify former, job was eligible to be pushed entirely out of memory to disk. Specify latter, job was eligible to push jobs out to make room. Or maybe that's backwards, or maybe those aren't the precise options. Some jobs designated as bullies, others wimps. Of course nobody at Mitre had ever used them; for grins I coded two jobs, one each. Ran wimp job, then bully job. Operator got a couple mysterious messages he'd never seen before about wimp job being rolled out and rolled in. Then I redid SYSGEN minus that pointless option. It was early primitive swapping. Lizette Koehler said: How about here http://www.lbdsoftware.com/os360.jpg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Colours on screen (mainframe history question)
In 1971, Mitre (DC-area non-profit think tank for government -- had a 2250 connected to OS/360, which included native device support for it. When we installed VM circa 1972, I got to make it work under CMS (component of VM). VERY fortunately someone at University of Grenoble (France) had written a lot of truly arcane and magnificent assembler code getting it to run under CMS part of CP/67 (VM's predecessor). "Fortunately" because I doubt I'd have been able to write that software. Even porting it from old CMS to new CMS was challenging -- and not helped by comments being in French (even having taken two years of French in high school -- with at least one semester using a chemistry textbook for class). Overall, it took relatively few tweaks to run. The last breakthrough was realizing that I had Maclibs (CMS macro libraries) in the wrong order so wrong macro versions were used for assembly. The primary application under VM was impressive -- displaying a simulated airspace where a number of fictional aircraft were flying. Plus one "real" airplane, a Linc Trainer (small aircraft flight simulator) in the data center with a real human pilot. I forget how the Linc Trainer connected to VM and what VM thought it was -- it surely wasn't a standard configurable peripheral. This was used for projects developing anti-collision algorithms and hardware for FAA. Charles Mills observed: The 2250 was a BEAST! Graphics. Light pen. A separate function key keypad. You could put typewritten labels in the function keys, and light up the allowed keys under program control. Had an 1130 computer under the hood as its controller. (No wonder it cost $$$.) The very first 360 application I ever saw was a 2250-driving system written in PL/I for one of the big pharmas -- trying to remember who. It was written by John Gilmore and Associates. (Yes, our very own IBMMAIN John Gilmore.) The idea was you could simulate the flow of a drug through the body, complete with a graphical representation. I don't believe it ever exactly worked. This would have been in 1969. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for article on testing mainframe systems, applications, networks [SEC=UNOFFICIAL]
Thanks -- that's GREAT, much appreciated. (The silence was giving me a headache!) May I quote you, with attribution? Editor likes quotes and they can't be anonymous. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highly technical question - how do I only get my posts?
This surely isn't what you want/mean -- but related -- long ago I had the idea for list-owner command "SET username BOZO". That would be a list option so idiots only see their posts (so they know list works) and no others (so they think list has dried up) and wander away. Similar to https://en.wikipedia.org/wiki/Shadow_banning -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for Destination z article -- mainframes back to the future
My first year-end retirement account statement -- for 1971! -- listed my projected retirement date as the incredibly distant, unimaginable, science-fiction-like date of February 1, 2012. So back then at least TIAA-CREF understood time windows spanning entire careers and beyond. Quoting: I was somewhat surprised that it took so long for Y2K to rise to the top, with 30-year mortgages and such forward-looking things being far from uncommon. But I guess those systems all got fixed one at a time as their windows passed 2000, without enough awareness that anyone said Hey, we need to fix this globally, now that storage (both memory and DASD) is cheap! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for Destination z article -- mainframes back to the future
Some time in early/mid-1970s, I did a competitive procurement of quarter-meg upgrade for 370/145 going from 0.5MB to 0.75MB. Evaluated several vendors, checked specs/references, etc. Spent about (as I remember) $30,000. A while later did the same for 370/148 1MB upgrade from 2MB to 3 MB, same price. Quoting: Phil: My memory is a bit foggy here but IIRC a megabyte in 370 memory was $10,000 . That may have been true at some time in its life. In the early 1970s when I was working at Wayne State, we had a model 65 that was later converted to (or replaced by, I don't remember) a model 67. At some time during its life, we bought a few megabytes of Fairchild semiconductor memory that came 256K bytes per box with a price of about $250,000 per box. My understanding was that it was less expensive than the core memory that came before it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for Destination z article -- mainframes back to the future
For some processor models -- I forget whether S/360 or later -- add-on memory vendors would install more memory than IBM designed for, expanding memory address/data buses to allow it. And of course when such processors returned to IBM they had to be de-extended, returned to IBM's limited address range. It must have been fun selling maintaining competitive memory. Quoting: All the focus on early memory prices also glosses over the fact that when the S/360 was introduced in 1964 even the largest models had a physical memory limit of 8 MiB, and the S/360 architectural limit was only 16 MiB. If you used a memory-extravagant design and created an application requiring memory beyond available limits, the cost of memory became effectively infinite - not available at any price. Larger record sizes impacted requirements for not only main memory but external storage capacity and channel bandwidth and processing time to manipulate the data. There definitely was a mindset in place in earlier days that placed great value on conserving all hardware resources as much as possible, to the point of obsession in some cases. If you exceeded available resources then, the hardware upgrade cost was more likely to be cost-prohibitive, or the upgrade might not even be possible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
