Re: Paddle temporary fix?
Runs on Raspberry Pis and Network Attached Drives Atom processors too. On Sat, Feb 25, 2023 at 6:49 PM Jim Marshall <04a082badc31-dmarc-requ...@listserv.ua.edu> wrote: > > The Paddle Project at SHARE was formed in order to provide a means of support > when IBM stopped supporting the OS/MVT Operating System on IBM 360s and > ultimately running on the later IBM 4341. IBM had announced the IBM 370 and > its OS/VS R2, later becoming MVS and wanted customers to buy new hardware and > the new MVS OS. This was in the mid 1970s. > > I was in the Air Force and arrived in the Pentagon in early September 1975 > just in time to attend the last IBM OS/MVT Workshop given in order to be a > SYSProg on a surplus IBM 360/75J. There were quite a few IBM 360s running in > private industry and Government. > Many SHARE attendees were still running OS/MVT and Dr Robert (Bob) Rannie, > Northern Illinois University formed the Paddle Project, mascot an OAR, > signifying you could join the members in the symbolic CANOE and we would all > SHARE information paddling, providing our own support. IBM was not pleased. > Early on a number of attendees also formed a team wearing powder blue berets > with the “OS Special Forces” patch. > > My Data Center was trying to upgrade the IBM 360/75J to an IBM 370/168 but > the approval process would take years. In the meantime some high priority > workloads needed to keep running and the more they processed, the Air Staff > found more things to do. > Each SHARE the OS/MVT session were overflowing with our IBM Rep, Jerry > Fineman, attending. One meeting Jerry leaped on the stage, snatched the > Paddle from Dr Bob, and broke the handle over his knee signifying when OS/MVT > breaks, IBM would not assist in fixing; no way. Actually in my prior > assignment out in Colorado, IBM was fully supporting OS/MVT on multiple IBM > 360/75Js, including some overseas, for a high priority Defense system. In > fact IBM would later update OS/MVT to run on multiple IBM 3033s. But for now > all of us were “OWN OUR OWN”, up the creek but “WITH A PADDLE”. Brand X > vendors including IBM retrofitted, IBM 3330/3350 DASD and Tape drives from > 556bpi to 6250bpi to run on them. > > I help to consolidate and distribute all the know info on OS/MVT plus all the > performance related enhancements and ZAPS coded some by IBM’ers, but SHARE > members. I applied all to my IBM 360/75J and could outrun an IBM 370/158 on > MVS. > > Getting back to the broken Paddle, Dr Bob took the broken Paddle back to NIU, > created an APAR and create a PTF or Paddle Temporary FIX. He drilled holes in > each end and inserted a Titanium rod and used epoxy; good as new. I seem to > recall he wrapped tape around broken area to give the illusion it was a less > than permanent fix. > > Sure enough at the next SHARE, Dr Bob was on stage with the Paddle, Jerry > again leaped onto the stage with malice intent, grabbed the Paddle and in a > big display of contempt, raised his leg and slapped the Paddle down to break > it. He limped off the stage for the titanium fix had held. > > It tided me over until we upgraded in late 1978, getting the first IBM 30XX > shipped, an IBM 3032; especially the IBM 360/75J was located in the corner > with $300M worth of Honeywell Computers. The decision was made to keep the > IBM 360/75J, upgrade main memory from 1M to 2.5M, all high speed, add ITEL > 3330s and add a COMTEN 3650 Com Controller to offer Dial-up Unclassified Time > Sharing. TSO was enhanced with a bunch of TSOCPs, HASP3.1 was modified and > many offices installed RJE’s to keep from walking up to a mile to get their > output from the data center. > > Even though IBM wanted everyone to upgrade to MVS and begin paying for parts > to the system along with Program Products, the IBM 360 encouraged many > government sites to use it. After all, the system was stable, was fully paid > for and depreciated to $0. The software was free along with Assembler, COBOL, > PL1/F, ALGOL, RPG and JOVIAL. Then there was all the SHAREWARE software > written by non-IBM’ers showing up on the SHARE tape and CBT (Connecticut Bank > & Trust) maintained by Arnie Casinghino and later picked up by Sam Golob. > This free software had source code and was passed around all over the world. > Most of these compilers still run today even with z/OS. Plus users were not > restricted to work local to the Data Center. It was hard to convince > management to upgrade until maintenance issues along arose now done by Third > Party vendors along with parts availability. > > From that point it was into the 1980s and most installations had gotten > either the IBM 370 , coming of IBM 3090s where most of the smaller systems > jumped onto the IBM 4341 or 4381s. Actually it is little know but the GPS > satellites’ Command and Control System, at the time, was running on an IBM > 360/65 out of Point Mugu, CA; late an IBM 4381 using OS/MVT under VM. > >
Re: Cant SPKA to PSW Key 4
Seymour thanks for your suggestion I was trying to get IDF working on Friday had problems displaying source hopefully I can resolve it Thanks for the idea > On Feb 25, 2023, at 9:50 PM, Ed Jaffe wrote: > > On 2/23/2023 6:46 PM, Joseph Reichman wrote: >> I am trying to change psw storage key from "Normal" key 8 to Key 4 >> >> SPKA X'40' >> >> I have bit 15 of the psw 0 ,meaning I am in supervisor state and get a s0c1 >> running this code under TESTAUTH >> >> I am able to get to PSW key 0 SPKA 0 >> >> Don't get it > > ISTR discovering empirically 30+ years ago that TSO/E TEST and TESTAUTH > support only two execution keys: X'80' and X'00'. > > I wondered if in-fact they actually support whatever key is in TCBPKF and > X'00' but never experimented to see if that was the case. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > 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: Cant SPKA to PSW Key 4
On 2/23/2023 6:46 PM, Joseph Reichman wrote: I am trying to change psw storage key from "Normal" key 8 to Key 4 SPKA X'40' I have bit 15 of the psw 0 ,meaning I am in supervisor state and get a s0c1 running this code under TESTAUTH I am able to get to PSW key 0 SPKA 0 Don't get it ISTR discovering empirically 30+ years ago that TSO/E TEST and TESTAUTH support only two execution keys: X'80' and X'00'. I wondered if in-fact they actually support whatever key is in TCBPKF and X'00' but never experimented to see if that was the case. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cant SPKA to PSW Key 4
The S0C1 is almost certainly a bug in TESTAUTH, not in his code, and I wouldn't expect him to track down the bug in TEST, nor is it his responsibility. If he's not already licensed, think of this as a marketing opportunity. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Cole [dbc...@colesoft.com] Sent: Saturday, February 25, 2023 5:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cant SPKA to PSW Key 4 Hi Joe, Tony is right. It is not possible for SPKA to throw an 0C1. Therefore, the 0C1 has to be occurring somewhere else. When the 0C1 occurs, are you put back into TEST? Or are you blown all the way out to READY? If you're still in TEST, issue WHERE to see where execution is now. WHERE will display a message that looks something like: * "address. LOCATED AT +offset IN modulename .csectname UNDER TCB LOCATED AT whocares." It is vary likely that the "modulename" and "csectname" are not what you will expect them to be. The location given by "address." will be at the end of the bad instruction. To see the bad instruction itself, you will have to back up -2, -4 or -6 bytes. To display that, use "LIST address.-6 LENGTH(32)". So, now you know (more or less) where the 0C1 happened. Now comes the hard part: Figuring out WHY it happened. There basically only three possibilities: * 1) A wild jump occurred that took execution to god knows where. * 2) Corruption occurred that overwrote good code with bad data. * 3) Or both: A corruption occurred that causes a wild jump. I will have to leave it to you to figure that out. Best, Dave Cole, Developer dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) At 2/23/2023 10:54 PM, Tony Harminc wrote: >On Thu, 23 Feb 2023 at 21:47, Joseph Reichman wrote: > >> > >> > I am trying to change psw storage key from "Normal" key 8 to Key 4 >> > >> > SPKA X'40' >> > >> > I have bit 15 of the psw 0 ,meaning I am in supervisor state and >> get a s0c1 >> > running this code under TESTAUTH >> > >A program check 1 is not possible if you execute an SPKA, no matter what >state you're in, and what the content of R0 (the implied register) is. So >I'd say you didn't actually execute it. How, I have no idea. When you say >"running this code", presumably there is more code than the one SPKA >instruction. Please make sure it isn't e.g. the instruction right before >the SPKA that's failing - that could show you the address of the SPKA as >the failing address, depending on how it fails. Perhaps you're branching >into the middle of an instruction somewhere nearby? >TSO TEST[AUTH] does overlay instructions where you have set a breakpoint >with an SVC 97, so if your code is fetching from or storing into the >instruction stream where there's a breakpoint, all bets are off. >I am able to get to PSW key 0 SPKA 0 > > Don't get it > > >Neither do I. But architecturally, SPKA can't fail that way. If you got an >S0C2 that would make sense. >Tony H. -- 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: zOSMF
As long as the network people allow it, NFS is the best solution for a lot of things. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Neil O'Connor [ver.z...@outlook.com] Sent: Saturday, February 25, 2023 5:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zOSMF Re Mark Zelden's comment: >> >>Here, we have a zFS data set that is a full 3390-27, and is mounted at a >>location we call the /nts Everything that we acquire electronically goes >>there: portable software instances and PTFs from RECEIVE ORDER. We tidy it >>up with a DELETEPKG for PTFs, since we do RECEIVE ORDER very frequently. >> >Ditto, except mine is still 4 volume 3390-9 zFS. I tidy it up with a weekly >cron script that deletes everything older than 90 days. I have found NFS the best solution for receiving electronic deliveries into SMP/E. You can have terabytes of low cost non-mainframe storage mounted in USS for this kind of thing and you never have any space issues. I only learned about and experienced NFS on mainframe about 5 years ago, but now I use it all the time for all kinds of stuff. It's really useful. Did I mention I really like NFS on mainframe? Neil O'Connor (Australia) -- 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: Paddle temporary fix?
The Paddle Project at SHARE was formed in order to provide a means of support when IBM stopped supporting the OS/MVT Operating System on IBM 360s and ultimately running on the later IBM 4341. IBM had announced the IBM 370 and its OS/VS R2, later becoming MVS and wanted customers to buy new hardware and the new MVS OS. This was in the mid 1970s. I was in the Air Force and arrived in the Pentagon in early September 1975 just in time to attend the last IBM OS/MVT Workshop given in order to be a SYSProg on a surplus IBM 360/75J. There were quite a few IBM 360s running in private industry and Government. Many SHARE attendees were still running OS/MVT and Dr Robert (Bob) Rannie, Northern Illinois University formed the Paddle Project, mascot an OAR, signifying you could join the members in the symbolic CANOE and we would all SHARE information paddling, providing our own support. IBM was not pleased. Early on a number of attendees also formed a team wearing powder blue berets with the “OS Special Forces” patch. My Data Center was trying to upgrade the IBM 360/75J to an IBM 370/168 but the approval process would take years. In the meantime some high priority workloads needed to keep running and the more they processed, the Air Staff found more things to do. Each SHARE the OS/MVT session were overflowing with our IBM Rep, Jerry Fineman, attending. One meeting Jerry leaped on the stage, snatched the Paddle from Dr Bob, and broke the handle over his knee signifying when OS/MVT breaks, IBM would not assist in fixing; no way. Actually in my prior assignment out in Colorado, IBM was fully supporting OS/MVT on multiple IBM 360/75Js, including some overseas, for a high priority Defense system. In fact IBM would later update OS/MVT to run on multiple IBM 3033s. But for now all of us were “OWN OUR OWN”, up the creek but “WITH A PADDLE”. Brand X vendors including IBM retrofitted, IBM 3330/3350 DASD and Tape drives from 556bpi to 6250bpi to run on them. I help to consolidate and distribute all the know info on OS/MVT plus all the performance related enhancements and ZAPS coded some by IBM’ers, but SHARE members. I applied all to my IBM 360/75J and could outrun an IBM 370/158 on MVS. Getting back to the broken Paddle, Dr Bob took the broken Paddle back to NIU, created an APAR and create a PTF or Paddle Temporary FIX. He drilled holes in each end and inserted a Titanium rod and used epoxy; good as new. I seem to recall he wrapped tape around broken area to give the illusion it was a less than permanent fix. Sure enough at the next SHARE, Dr Bob was on stage with the Paddle, Jerry again leaped onto the stage with malice intent, grabbed the Paddle and in a big display of contempt, raised his leg and slapped the Paddle down to break it. He limped off the stage for the titanium fix had held. It tided me over until we upgraded in late 1978, getting the first IBM 30XX shipped, an IBM 3032; especially the IBM 360/75J was located in the corner with $300M worth of Honeywell Computers. The decision was made to keep the IBM 360/75J, upgrade main memory from 1M to 2.5M, all high speed, add ITEL 3330s and add a COMTEN 3650 Com Controller to offer Dial-up Unclassified Time Sharing. TSO was enhanced with a bunch of TSOCPs, HASP3.1 was modified and many offices installed RJE’s to keep from walking up to a mile to get their output from the data center. Even though IBM wanted everyone to upgrade to MVS and begin paying for parts to the system along with Program Products, the IBM 360 encouraged many government sites to use it. After all, the system was stable, was fully paid for and depreciated to $0. The software was free along with Assembler, COBOL, PL1/F, ALGOL, RPG and JOVIAL. Then there was all the SHAREWARE software written by non-IBM’ers showing up on the SHARE tape and CBT (Connecticut Bank & Trust) maintained by Arnie Casinghino and later picked up by Sam Golob. This free software had source code and was passed around all over the world. Most of these compilers still run today even with z/OS. Plus users were not restricted to work local to the Data Center. It was hard to convince management to upgrade until maintenance issues along arose now done by Third Party vendors along with parts availability. From that point it was into the 1980s and most installations had gotten either the IBM 370 , coming of IBM 3090s where most of the smaller systems jumped onto the IBM 4341 or 4381s. Actually it is little know but the GPS satellites’ Command and Control System, at the time, was running on an IBM 360/65 out of Point Mugu, CA; late an IBM 4381 using OS/MVT under VM. The IBM 360 ran long after because in an attempt to improve US/China relations the US State Dept was buying up obsolete IBM 360/65s and with OS/MVT 21.8E+ plus all the languages, was giving them to Chinese Universities. In fact Dr Bob at NIU was hired to trained Chinese SYSProgs on OS/MVT during summer sessions on
Re: zOSMF
My NTS is also a full 3390-27 Since we all have to use zOSMF, I'm Thinking about using this structure in my OMVS, Each about 20 Cylinders. Now my res volumes are 3390-27's /PPROD SYSHFS.OMVS.DEV1.PRODUCTS /PPROD/IBM SYSHFS.OMVS.DEV1.IBM /PPROD/BMC SYSHFS.OMVS.DEV1.BMC /PPROD/BROADCOM SYSHFS.OMVS.DEV1.BROADCOM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neil O'Connor Sent: Saturday, February 25, 2023 4:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zOSMF Re Mark Zelden's comment: >> >>Here, we have a zFS data set that is a full 3390-27, and is mounted at a >>location we call the /nts Everything that we acquire electronically goes >>there: portable software instances and PTFs from RECEIVE ORDER. We tidy it >>up with a DELETEPKG for PTFs, since we do RECEIVE ORDER very frequently. >> >Ditto, except mine is still 4 volume 3390-9 zFS. I tidy it up with a weekly >cron script that deletes everything older than 90 days. I have found NFS the best solution for receiving electronic deliveries into SMP/E. You can have terabytes of low cost non-mainframe storage mounted in USS for this kind of thing and you never have any space issues. I only learned about and experienced NFS on mainframe about 5 years ago, but now I use it all the time for all kinds of stuff. It's really useful. Did I mention I really like NFS on mainframe? Neil O'Connor (Australia) -- 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: zOSMF
Neil, Could you give a summary of how you do NFS,and what the backend is. Do you have encrypted disks etc Thank you Colin On Sat, 25 Feb 2023 at 10:41, Neil O'Connor wrote: > Re Mark Zelden's comment: > > >> > >>Here, we have a zFS data set that is a full 3390-27, and is mounted at > a location we call the /nts Everything that we acquire electronically goes > there: portable software instances and PTFs from RECEIVE ORDER. We tidy > it up with a DELETEPKG for PTFs, since we do RECEIVE ORDER very frequently. > >> > > >Ditto, except mine is still 4 volume 3390-9 zFS. I tidy it up with a > weekly cron script that deletes everything older than 90 days. > > I have found NFS the best solution for receiving electronic deliveries > into SMP/E. You can have terabytes of low cost non-mainframe storage > mounted in USS for this kind of thing and you never have any space issues. > I only learned about and experienced NFS on mainframe about 5 years ago, > but now I use it all the time for all kinds of stuff. It's really useful. > Did I mention I really like NFS on mainframe? > > Neil O'Connor (Australia) > > -- > 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: zOSMF
Re Mark Zelden's comment: >> >>Here, we have a zFS data set that is a full 3390-27, and is mounted at a >>location we call the /nts Everything that we acquire electronically goes >>there: portable software instances and PTFs from RECEIVE ORDER. We tidy it >>up with a DELETEPKG for PTFs, since we do RECEIVE ORDER very frequently. >> >Ditto, except mine is still 4 volume 3390-9 zFS. I tidy it up with a weekly >cron script that deletes everything older than 90 days. I have found NFS the best solution for receiving electronic deliveries into SMP/E. You can have terabytes of low cost non-mainframe storage mounted in USS for this kind of thing and you never have any space issues. I only learned about and experienced NFS on mainframe about 5 years ago, but now I use it all the time for all kinds of stuff. It's really useful. Did I mention I really like NFS on mainframe? Neil O'Connor (Australia) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cant SPKA to PSW Key 4
Hi Joe, Tony is right. It is not possible for SPKA to throw an 0C1. Therefore, the 0C1 has to be occurring somewhere else. When the 0C1 occurs, are you put back into TEST? Or are you blown all the way out to READY? If you're still in TEST, issue WHERE to see where execution is now. WHERE will display a message that looks something like: * "address. LOCATED AT +offset IN modulename .csectname UNDER TCB LOCATED AT whocares." It is vary likely that the "modulename" and "csectname" are not what you will expect them to be. The location given by "address." will be at the end of the bad instruction. To see the bad instruction itself, you will have to back up -2, -4 or -6 bytes. To display that, use "LIST address.-6 LENGTH(32)". So, now you know (more or less) where the 0C1 happened. Now comes the hard part: Figuring out WHY it happened. There basically only three possibilities: * 1) A wild jump occurred that took execution to god knows where. * 2) Corruption occurred that overwrote good code with bad data. * 3) Or both: A corruption occurred that causes a wild jump. I will have to leave it to you to figure that out. Best, Dave Cole, Developer dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) At 2/23/2023 10:54 PM, Tony Harminc wrote: On Thu, 23 Feb 2023 at 21:47, Joseph Reichman wrote: > > I am trying to change psw storage key from "Normal" key 8 to Key 4 > > SPKA X'40' > > I have bit 15 of the psw 0 ,meaning I am in supervisor state and get a s0c1 > running this code under TESTAUTH > A program check 1 is not possible if you execute an SPKA, no matter what state you're in, and what the content of R0 (the implied register) is. So I'd say you didn't actually execute it. How, I have no idea. When you say "running this code", presumably there is more code than the one SPKA instruction. Please make sure it isn't e.g. the instruction right before the SPKA that's failing - that could show you the address of the SPKA as the failing address, depending on how it fails. Perhaps you're branching into the middle of an instruction somewhere nearby? TSO TEST[AUTH] does overlay instructions where you have set a breakpoint with an SVC 97, so if your code is fetching from or storing into the instruction stream where there's a breakpoint, all bets are off. I am able to get to PSW key 0 SPKA 0 > Don't get it > Neither do I. But architecturally, SPKA can't fail that way. If you got an S0C2 that would make sense. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
