Re: C
It's been awhile. Think there was a set distributed with SDSF. Don't know if it was IUP or feature. Mid 80's got to debug somebody's production application that corrupted their TMC. Only took half the night. In a message dated 4/29/2020 10:32:04 PM Central Standard Time, jcew...@acm.org writes: I think many places had various forms of structured macros for Assembler during the 1980's. I believe there was eventually even a set that was distributed, either from IBM or at SHARE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Aw: Re: LzLabs
As their own release says, it's only 2.5k MIPS of batch COBOL Swisscom was going to EOL anyway. Emulating the entire ecosystem and all the third-party tools seems like insane. They call it re-hosting. IMHO you can re-host something written to open standards. Otherwise you have to deal with legal issues and since it's all propritary and patented they must have reverse engineered entire zOS. Can you do it without infringing on patents ? And even if you can, how many man years would you need ? Harsh reality these days is funding is becoming scarce. Peter Baumann Gesendet: Dienstag, 28. April 2020 um 17:11 Uhr Von: "Ed Jaffe" An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: LzLabs On 4/28/2020 7:49 AM, Jake Anderson wrote: > They migrated some swiss based telecommunications company. Swisscom, the largest telco in the country: https://www.theregister.co.uk/2019/05/16/lzlabs_kills_swisscoms_mainframes/ Re: the lay-off, now is great time to trim workforce "fat" and/or "dead wood" with many governments providing unheard of subsidies for the unemployed... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/[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: Here we go again
On Wed, 29 Apr 2020 20:48:23 -0500, Paul Gilmartin wrote: >On Wed, 29 Apr 2020 17:08:40 -0700, Charles Mills wrote: > >>PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 19.03.21 DATE APR >>29,1920 >> >Go to SR. IBM took an APAR for me on a similar error in an IEBCOPY page >header, but a hundred million times smaller. > >1982? > >-- gil Don't bother! :-)> OS/VS COBOL hasn't been supported since 1994! It was replaced by VS COBOL II, which eventually became Enterprise COBOL. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Here we go again
On Wed, 29 Apr 2020 17:08:40 -0700, Charles Mills wrote: >PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 19.03.21 DATE APR >29,1920 > Go to SR. IBM took an APAR for me on a similar error in an IEBCOPY page header, but a hundred million times smaller. 1982? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday OT, cheerful program for gloomy times
conditional macro assembler as in (readable form): .EXTRM ANOP TERMINAL EXCLUDES DEFINITION .* &A1 SETA 1 &C1 SETC '&EXCNT' &@SYSSETC 'EXCL&SYSNDX' &@SYSDCH'&C1' EXCLUDES COUNT .* .EXLOOP AIF (&FLHEX).@EXHEX &A2 SETA &@EXCLUD(&A1) CONVERT EXCLUDES TO HEXADECIMAL &A3 SETA &A2/16<-- modulo 16 part 1 &C1 SETC '&HEXVAL(&A3+1)' &A3 SETA &A2-(&A3*16) <-- modulo 16 part 2 &C2 SETC '&HEXVAL(&A3+1)' &@EXCLUD(&A1) SETC '&C1&C2' .@EXHEX DCXL1'&@EXCLUD(&A1)' EXCLUDED &A1 SETA &A1+1 AIF (&A1 LE &EXCNT).EXLOOP &@SYSSETC 'EXMK&SYSNDX' &@SYSDCXL2'' END OF EXCLUDES MARKER .* MNOTE *,' COUNT OF TERMINALS EXCLUDED = &EXCNT' &@NZ SETC 'EXTRMOK' AGO .EXCNTL END OF TERMINAL EXCLUDES .* .** .* .EXCLEND ANOP END OF TERMINAL EXCLUDES BLOCK &@NZ SETC 'EXCLOK' .EXDONE AGO .EXCNTL .* Cheers. On 29/04/2020 03:05, Paul Gilmartin wrote: > On Wed, 29 Apr 2020 02:57:23 +0100, CM Poncelet wrote: > >> ... but that's the only way to do it in conditional macro assembler; so >> what me worry about 3GL's? :) >> > What hardware? Doesn't Divide leave the quotient in one register and the > remainder in an adjacent one? > >> On 28/04/2020 10:46, David Crayford wrote: >>> No worries. FWIW, I think using the // modulo operator would make >>> your code less verbose and complex ;) > -- gil > > -- > 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: Friday OT, cheerful program for gloomy times
conditional macro assembler as in: .EXTRM ANOP TERMINAL EXCLUDES DEFINITION 00075800 .* 00075900 &A1 SETA 1 00076000 &C1 SETC '&EXCNT' 00076100 &@SYS SETC 'EXCL&SYSNDX' 00076200 &@SYS DC H'&C1' EXCLUDES COUNT 00076336 .* 00076400 .EXLOOP AIF (&FLHEX).@EXHEX 00076500 &A2 SETA &@EXCLUD(&A1) CONVERT EXCLUDES TO HEXADECIMAL 00076600 &A3 SETA &A2/16 00076700 <-- &C1 SETC '&HEXVAL(&A3+1)' 00076800 &A3 SETA &A2-(&A3*16) 00076900 <-- &C2 SETC '&HEXVAL(&A3+1)' 00077000 &@EXCLUD(&A1) SETC '&C1&C2' 00077100 .@EXHEX DC XL1'&@EXCLUD(&A1)' EXCLUDED 00077200 &A1 SETA &A1+1 00077300 AIF (&A1 LE &EXCNT).EXLOOP 00077400 &@SYS SETC 'EXMK&SYSNDX' 00077500 &@SYS DC XL2'' END OF EXCLUDES MARKER 00077600 .* 00077700 MNOTE *,' COUNT OF TERMINALS EXCLUDED = &EXCNT' 00077800 &@NZ SETC 'EXTRMOK' 00077900 AGO .EXCNTL END OF TERMINAL EXCLUDES 00078000 .* 00078100 Cheers. On 29/04/2020 03:05, Paul Gilmartin wrote: > On Wed, 29 Apr 2020 02:57:23 +0100, CM Poncelet wrote: > >> ... but that's the only way to do it in conditional macro assembler; so >> what me worry about 3GL's? :) >> > What hardware? Doesn't Divide leave the quotient in one register and the > remainder in an adjacent one? > >> On 28/04/2020 10:46, David Crayford wrote: >>> No worries. FWIW, I think using the // modulo operator would make >>> your code less verbose and complex ;) > -- gil > > -- > 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: Here we go again
PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY 1, 1982 19.03.21 DATE APR 29,1920 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Wednesday, April 29, 2020 4:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again On Wed, 22 Apr 2020, 19:29 Seymour J Metz, wrote: > True, but as an amusing side note there were Y2K bugs that were not worth > fixing, like displaying the year as 100 instead of 00. Unfortunately, most > were not like that. > And thus was born the "Year 19100 bug" :-) Rupert -- 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: C
If you do a GETMAIN for your save area then it's trivial to put your local variables after it and, voila, recursion. There were lots of prolog/epilog macro pairs floating around independent of the control structure macro packages. Yes, one set of macros for structured assembler was listed in SHARE PROGRAM LIBRARY AGENCY User's Guide and Catalog of Programs 1977 EDITION: 360D-99.0.009 PROGRAM COLLECTION: STRUCTURED PROGRAMMING, UTILITIES, TRANSLATORS, SIMULATOR, HASP MODIFICATIONS, AND MACROS AUTHOR: DONALD S. HIGGINS DIRECT TECHNICAL INQUIRIES TO: MR. DONALD S. HIGGINS B-3 FLORIDA POWER CORPORATION P.O. BO X 140 42 ST. PETERSBURG, FL 33733 DESCRIPTION - THE FOLLOWING CCLLECTION OF PROGRAMS ARE INCLUDED IN A SINGLE DISTRIBUTION PACKAGE: GENERAL PURPOSE ASSEMBLER MACROS - SUBENTRY + SUBEXIT, STANDARD LINKAGE WITH REENTRANT OPTIONS; EDIT PACKED DATA USING A MASK; EQUAL, COMMONLY USED EQU'S; PERFORM, PENTRY, PEXIT - STRUCTURED PROGRAMMING BLOCK CONCATENATION USING NO REGISTERS; IF, ELSE, FI - STURCTURED PROGRAMMING ALTERNATE BLOCK SELECTION; DOCASE, CASE, ESAC, ESACOD - STRUCTURED PROGRAMMING MULTIPLE ALTERNATE BLOCK SELECTION; ACCEPT + DISPLAY SIMPLIFIED I/O; DCWV - DEFINE V TYPE ADDRESS FOR DYNAMIC SUBROUTINES. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joel C. Ewing [jcew...@acm.org] Sent: Wednesday, April 29, 2020 7:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C I think many places had various forms of structured macros for Assembler during the 1980's. I believe there was eventually even a set that was distributed, either from IBM or at SHARE. Our set of structured macros included support for PROCs with "local" variables and PROC return info on a stack so it was trivial to write assembler code that permitted recursion. JC Ewing On 4/29/20 5:04 PM, Wayne Driscoll wrote: > At that time NIU, located about 90 minutes west of Chicago made available a > set of assembler macros that provided structured programming constructs, as > many Chicago area IT organizations hired from NIU, many used these macros. > > Wayne Driscoll > Rocket Software > Note - All opinions are strictly my own. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Mike Schwab > Sent: Sunday, April 26, 2020 12:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C > > EXTERNAL EMAIL > > > > > > I was doing an internship in the Chicago area during the summer of 1984. > They were using an assembler with IF macros. > > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: >> HLASM in 1980? Not before June 1992. I assume that you were using XF >> and H, possibly with the SLAC mods on the latter (thank you, Greg and >> John.) >> >> >> -- >> Shmuel (Seymour J.) Metz >> https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g >> mu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea06d7f >> 5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637235187442674475& >> sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reserved=0 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of Donald Blake [dhbl...@gmail.com] >> Sent: Sunday, April 26, 2020 8:51 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: C >> >> I took my first C course in 1980. The text was the original *The C >> programming Language* by Kerrigan and Richie, which I still have on my >> shelf, The text is copyright 1978. That's 42 years ago. I was an IBM >> HL Assembler programmer at the time. BTW ... we still were using >> IFOX00 at the time as well. >> >>> Hey, it's not politically correct to point out how old C is. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason >>> .gmu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea0 >>> 6d7f5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63723518744267447 >>> 5&sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reser >>> ved=0 >>> >> ... > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > ... -- Joel C. Ewing -- 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: Here we go again
On Wed, 22 Apr 2020, 19:29 Seymour J Metz, wrote: > True, but as an amusing side note there were Y2K bugs that were not worth > fixing, like displaying the year as 100 instead of 00. Unfortunately, most > were not like that. > And thus was born the "Year 19100 bug" :-) Rupert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
I think many places had various forms of structured macros for Assembler during the 1980's. I believe there was eventually even a set that was distributed, either from IBM or at SHARE. Our set of structured macros included support for PROCs with "local" variables and PROC return info on a stack so it was trivial to write assembler code that permitted recursion. JC Ewing On 4/29/20 5:04 PM, Wayne Driscoll wrote: > At that time NIU, located about 90 minutes west of Chicago made available a > set of assembler macros that provided structured programming constructs, as > many Chicago area IT organizations hired from NIU, many used these macros. > > Wayne Driscoll > Rocket Software > Note - All opinions are strictly my own. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Mike Schwab > Sent: Sunday, April 26, 2020 12:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C > > EXTERNAL EMAIL > > > > > > I was doing an internship in the Chicago area during the summer of 1984. > They were using an assembler with IF macros. > > On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: >> HLASM in 1980? Not before June 1992. I assume that you were using XF >> and H, possibly with the SLAC mods on the latter (thank you, Greg and >> John.) >> >> >> -- >> Shmuel (Seymour J.) Metz >> https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g >> mu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea06d7f >> 5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637235187442674475& >> sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reserved=0 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of Donald Blake [dhbl...@gmail.com] >> Sent: Sunday, April 26, 2020 8:51 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: C >> >> I took my first C course in 1980. The text was the original *The C >> programming Language* by Kerrigan and Richie, which I still have on my >> shelf, The text is copyright 1978. That's 42 years ago. I was an IBM >> HL Assembler programmer at the time. BTW ... we still were using >> IFOX00 at the time as well. >> >>> Hey, it's not politically correct to point out how old C is. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason >>> .gmu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea0 >>> 6d7f5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63723518744267447 >>> 5&sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reser >>> ved=0 >>> >> ... > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > ... -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C
At that time NIU, located about 90 minutes west of Chicago made available a set of assembler macros that provided structured programming constructs, as many Chicago area IT organizations hired from NIU, many used these macros. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Sunday, April 26, 2020 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C EXTERNAL EMAIL I was doing an internship in the Chicago area during the summer of 1984. They were using an assembler with IF macros. On Sun, Apr 26, 2020 at 2:11 PM Seymour J Metz wrote: > > HLASM in 1980? Not before June 1992. I assume that you were using XF > and H, possibly with the SLAC mods on the latter (thank you, Greg and > John.) > > > -- > Shmuel (Seymour J.) Metz > https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea06d7f > 5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637235187442674475& > sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Donald Blake [dhbl...@gmail.com] > Sent: Sunday, April 26, 2020 8:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: C > > I took my first C course in 1980. The text was the original *The C > programming Language* by Kerrigan and Richie, which I still have on my > shelf, The text is copyright 1978. That's 42 years ago. I was an IBM > HL Assembler programmer at the time. BTW ... we still were using > IFOX00 at the time as well. > > > Hey, it's not politically correct to point out how old C is. > > > > > > -- > > Shmuel (Seymour J.) Metz > > https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason > > .gmu.edu%2F~smetz3&data=02%7C01%7C%7C1dfd83889d9d4a9127a108d7ea0 > > 6d7f5%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63723518744267447 > > 5&sdata=nRSQMjThQ3ncTFLzDDyfUbha0VX2cE2c9VHizXJr2uU%3D&reser > > ved=0 > > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMShsm high CPU consumption
Some scrutiny of the DFHSM activity logs to see if the same old datasets are failing to be processed each time, may not go amiss. That sort of stuff can build up over time, and can accumulate to become a considerable overhead every time automatic functions run. On Tue, 28 Apr 2020 at 06:50, Brian Westerman wrote: > I agree, HSM is a bit of a hog, so it shouldn't be set to run above your > loved ones. It's more important than batch or TSO, but not CICS, > DB/2|ADASBAS|ORACLE, TCP, VTAM or anybody else important. > > STCLOW is a good choice so long as everything "important" is above it. > > Brian > > -- > 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: S0F9 and SOFD ABENDs and SVC dumps - oh my!
There are also fields which contain 24-bit addresses of these things, like RBLINKB, with no room to expand to 31 bits without moving the field. Moving the field would break all programs that use it, (including AMODE(31) and AMODE(64) programs). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 04/29/2020 04:00 PM Subject:Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by:"IBM Mainframe Discussion List" On Wed, 29 Apr 2020 08:45:30 +0100, Martin Packer wrote: >As much to the point, why does this need to be 24-bit LSQA? Compatibility. TCBs and RBs are still below the line because moving them above the line will likely break existing AMODE(24) programs. -- Tom Marchant -- 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: Question About Dormant MVS Resource Managers
A memory termination resource manager is considered to be "dormant" if the TCB under which it is running has not been dispatched during the past 4-8 minutes. The 4-8 range is because the dormancy checking of all of the memterm TCBs is done once every 4 minutes. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 04/29/2020 01:04:21 PM: > From: "esst...@juno.com" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 04/29/2020 04:00 PM > Subject: Question About Dormant MVS Resource Managers > Sent by: "IBM Mainframe Discussion List" > > Hello,. > I reading about Resource Managers - and its capability to be "dormant". > I understand if the Resource Manager is "dormant" for four minutes, the system > will abend the Resource Manager with a 40D Abend. > . > What exactly does it mean when a Resource Manager is "dormant" ? > . > If I have three Started Tasks and they all issue a RESMNGR ADD for the > same program, when is the Resource Manager considered to be dormant ? > What eactly needs to occur for the system to deem the Resource Manager to be > "dormant" ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question About Dormant MVS Resource Managers
My understanding is that if an EOM resource manager does not complete in a timely manner it will be abended. The clock starts when it is invoked. On Wed, 29 Apr 2020 17:04:21 GMT "esst...@juno.com" wrote: :>Hello,. :>I reading about Resource Managers - and its capability to be "dormant". :>I understand if the Resource Manager is "dormant" for four minutes, the system :>will abend the Resource Manager with a 40D Abend. . :>What exactly does it mean when a Resource Manager is "dormant" ? . :>If I have three Started Tasks and they all issue a RESMNGR ADD for the :>same program, when is the Resource Manager considered to be dormant ? :>What eactly needs to occur for the system to deem the Resource Manager to be :>"dormant" ? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question About Dormant MVS Resource Managers
Hello,. I reading about Resource Managers - and its capability to be "dormant". I understand if the Resource Manager is "dormant" for four minutes, the system will abend the Resource Manager with a 40D Abend. . What exactly does it mean when a Resource Manager is "dormant" ? . If I have three Started Tasks and they all issue a RESMNGR ADD for the same program, when is the Resource Manager considered to be dormant ? What eactly needs to occur for the system to deem the Resource Manager to be "dormant" ? . Paul D'Angelo ** ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
On Wed, 29 Apr 2020 08:45:30 +0100, Martin Packer wrote: >As much to the point, why does this need to be 24-bit LSQA? Compatibility. TCBs and RBs are still below the line because moving them above the line will likely break existing AMODE(24) programs. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Don't forget that GETMAIN requests for storage above the line will return storage below the line if there isn't sufficient storage above the line to honor the request. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange code Generation from XL\C Metal C
You are right there is a bug in this program when I ran it under TESTAUTH it works When I run it normally ( ad stated task it didn’t determined from ESTAE ) trying to Get to the bottom of this thanks On Apr 29, 2020, at 3:48 AM, David Crayford wrote: > > I don't understand what the point of this code is? > > &thread_ptr->buffer[0] > > All references to arrays in C decay to a pointer so just use the much simpler > form: > > thread_ptr->buffer > > 2020-04-29 2:27 PM, retired mainframer wrote: > >> The LY instruction is picking up the file descriptor (think DD name) so the >> IO accesses the correct file. >> >> The memcpy statement doesn't care what file the data came from. You are >> copying whatever is currently in the buffer to reclen and it is obvious that >> the buffer is at the start of your structure/class. >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Joseph Reichman >>> Sent: Tuesday, April 28, 2020 6:44 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Strange code Generation from XL\C Metal C >>> >>> I am using a pointer to buffer to read in data the data name is >>> thread_ptr->buffer buffer is define char[2100] >>> >>> >>> >>> Here is code when I call the read notice it bumps register 4 21000 bytes >> to >>> get the address of buffer >>> >>> _read(thread_ptr->fh, &thread_ptr->buffer[0], reclen); >>> >>> L 2,@113thread_ptr >>> >>> LY4,21000(0,2)(*)threadstor.threadstor.fh >>> >>> LLH 14,@123reclen >>> >>> "IBMUSER.DBGR.SERVER(OPENFILE)" Page 68 >>> >>> R14 >>> >>> rce Statement HLASM R6.0 2020/04/28 21.34 >>> >>> L 0,#WSA_1 >>> >>> L 15,=V(@READ) >>> >>> LA1,224(,13) #MX_TEMP1 >>> >>> ST4,224(,13) #MX_TEMP1 >>> >>> ST2,228(,13) #MX_TEMP1 >>> >>> ST14,232(,13) #MX_TEMP1 >>> >>> MVC 8(4,13),#NAB_1+4 >>> >>> SAC 0 >>> >>> BASR 14,15 >>> >>> SAC 512 >>> >>> >>> >>> Here is code where I am trying to copy pos 10 of buffer for 2 bytes notice >>> there is no LY for 21000 to get to buffer ? >>> >>> >>> >>> memcpy(&reclen, &thread_ptr->buffer[10],2); >>> >>> L 14,@113thread_ptr >>> >>> CPYA 2,14 >>> >>> MVC @123reclen,10(14) >>> >>> >>> >>> >>> >>> >>> -- >>> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0F9 and SOFD ABENDs and SVC dumps - oh my!
You have used up all the below-16M storage. End of story. Short answer: don't do that. Long answer: don't do that. Every task and RB uses "some". And your application uses whatever it uses. It is up to you not to create so many tasks that things run out. The system isn't going to try to stop you. It is perhaps also of interest how much below-16M region your job has been allowed to obtain (hence Sam K's question about IEFUSI). And how much you did use. LSQA allocates "top down" and user subpools "bottom up". Field LDACRGTP DSACurrent high address of PRIVATE AREA Region can be of interest. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
You're asking for the impossible: there are competing demands on space below the line. Increase LSQA capriciously and jobs start abending on, e.g., S804. The long term fix is to move more above the line, but that too has consequences. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Denis [01664d8ede6c-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, April 29, 2020 4:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Hi Barbara, thanks for the insights.Nevertheless, to me it looks like z/OS still is a 24bit operating system with some 31/64bit addressing and instructions as long as under the covers such old mechanisms need to be maintained and taken into account. If region termination requires space in 24bit LSQA, z/OS should at least reserve it silently behind the scenes without a need to put that on the agenda or todo list of system programmers and with enough space that the termination of an address space never stalls because of RTM running out of memory. It should be default and IEFUSI or the parmlib member optional.I think of it telling the management, we need to maintain this 24bit memory hole to allow for proper cleanup of anything within z/OS. These are the things that make z/OS look old and to be replaced and not considered modern, even if it is for a very good reason not losing compatibility for old modules, etc. Thanks, Denis. -Original Message- From: Barbara Nitz To: IBM-MAIN Sent: Wed, Apr 29, 2020 10:26 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! >We had a similar issue in IMS regions, stalling after out of memory abend, no >way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, >except with some vendor tool cancel that just gets rid of the address space >without proper cleanup that gets you closer to IPL.I wondered back then, how >dare the z/OS RTM routine doing getmains or module loads in a region that >abended with end of memory, does not make sense to me.The answer is probably, >it has been that way ever since and use IEFUSI.Why would terminating an >address space in 64bit or 31bit mode require loading 24bit routines, sounds >awkward?! The address space *task structures* (TCBs, PRBs, SVRBs, IRBs, CDEs) are all allocated in below the line LSQA. It has been that way since before MVS/XA, I think. The RTM2WA is allocated above the line. Also, there is no one 'RTM routine' that gets executed. When RTM gets control (remember PSW swap?) it doesn't *know* yet what it got control for. So it just needs to figure that out, which costs some storage. And recovery always goes back to the last PRB, which means that RTM gets control under a new PRB to ensure that things are not muddied by the recovery (think dump analysis). And then system integrity demands that proper cleanup is done (as in resource managers need to run), not to mention possible recovery routines that the application set up. Or the routine doing the cleanup. Terminating an address space without violating system integrity or hanging up the address space (or the system) is a very complex business. In a previous life I also had to deal regularly with IMS regions not terminating due to various reasons. In 50% of the cases the 'callrtm' program (which has now morphed into a variant of the force command) did the trick. In all other cases IMS needed to get recycled. I always took a dump to determine the TCB address that I needed to terminate (the bottom one that needs to terminate so everything above can terminate), and most of the time a few of those ominous 'non-cancelable' bits were on. What is worth more? System integrity or IMS restart? As for routines running in 24 bit - if it is an application routine, it *should* be at least located above the line. But some of the *system* routines *must* run in 24bit, IIRC. IBM has made a real effort over the years to put as much as possible above the line, without rewriting all of the operating system. And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to terminate cleanly. Barbara -- 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: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Hi Barbara, thanks for the insights.Nevertheless, to me it looks like z/OS still is a 24bit operating system with some 31/64bit addressing and instructions as long as under the covers such old mechanisms need to be maintained and taken into account. If region termination requires space in 24bit LSQA, z/OS should at least reserve it silently behind the scenes without a need to put that on the agenda or todo list of system programmers and with enough space that the termination of an address space never stalls because of RTM running out of memory. It should be default and IEFUSI or the parmlib member optional.I think of it telling the management, we need to maintain this 24bit memory hole to allow for proper cleanup of anything within z/OS. These are the things that make z/OS look old and to be replaced and not considered modern, even if it is for a very good reason not losing compatibility for old modules, etc. Thanks, Denis. -Original Message- From: Barbara Nitz To: IBM-MAIN Sent: Wed, Apr 29, 2020 10:26 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! >We had a similar issue in IMS regions, stalling after out of memory abend, no >way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, >except with some vendor tool cancel that just gets rid of the address space >without proper cleanup that gets you closer to IPL.I wondered back then, how >dare the z/OS RTM routine doing getmains or module loads in a region that >abended with end of memory, does not make sense to me.The answer is probably, >it has been that way ever since and use IEFUSI.Why would terminating an >address space in 64bit or 31bit mode require loading 24bit routines, sounds >awkward?! The address space *task structures* (TCBs, PRBs, SVRBs, IRBs, CDEs) are all allocated in below the line LSQA. It has been that way since before MVS/XA, I think. The RTM2WA is allocated above the line. Also, there is no one 'RTM routine' that gets executed. When RTM gets control (remember PSW swap?) it doesn't *know* yet what it got control for. So it just needs to figure that out, which costs some storage. And recovery always goes back to the last PRB, which means that RTM gets control under a new PRB to ensure that things are not muddied by the recovery (think dump analysis). And then system integrity demands that proper cleanup is done (as in resource managers need to run), not to mention possible recovery routines that the application set up. Or the routine doing the cleanup. Terminating an address space without violating system integrity or hanging up the address space (or the system) is a very complex business. In a previous life I also had to deal regularly with IMS regions not terminating due to various reasons. In 50% of the cases the 'callrtm' program (which has now morphed into a variant of the force command) did the trick. In all other cases IMS needed to get recycled. I always took a dump to determine the TCB address that I needed to terminate (the bottom one that needs to terminate so everything above can terminate), and most of the time a few of those ominous 'non-cancelable' bits were on. What is worth more? System integrity or IMS restart? As for routines running in 24 bit - if it is an application routine, it *should* be at least located above the line. But some of the *system* routines *must* run in 24bit, IIRC. IBM has made a real effort over the years to put as much as possible above the line, without rewriting all of the operating system. And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to terminate cleanly. Barbara -- 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: S0F9 and SOFD ABENDs and SVC dumps - oh my!
So you would hope the application could be abstemious with 24-bit to the point of allowing the aforementioned 6MB of 24-bit. But this still doesn't seem very scalable - unless termination was sequenced to use less instantaneous (not-E)LSQA. But then sequencing - call it "pacing" - would prolong the outage. I have to ask, though, what is different about DB2 where DIST and DBM1 address spaces have many hundreds of balls in the air? (DIST through DBATs and DBM1 through prefetch, deferred write, castout engines.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Barbara Nitz To: IBM-MAIN@LISTSERV.UA.EDU Date: 29/04/2020 09:27 Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by:IBM Mainframe Discussion List >We had a similar issue in IMS regions, stalling after out of memory abend, no way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, except with some vendor tool cancel that just gets rid of the address space without proper cleanup that gets you closer to IPL.I wondered back then, how dare the z/OS RTM routine doing getmains or module loads in a region that abended with end of memory, does not make sense to me.The answer is probably, it has been that way ever since and use IEFUSI.Why would terminating an address space in 64bit or 31bit mode require loading 24bit routines, sounds awkward?! The address space *task structures* (TCBs, PRBs, SVRBs, IRBs, CDEs) are all allocated in below the line LSQA. It has been that way since before MVS/XA, I think. The RTM2WA is allocated above the line. Also, there is no one 'RTM routine' that gets executed. When RTM gets control (remember PSW swap?) it doesn't *know* yet what it got control for. So it just needs to figure that out, which costs some storage. And recovery always goes back to the last PRB, which means that RTM gets control under a new PRB to ensure that things are not muddied by the recovery (think dump analysis). And then system integrity demands that proper cleanup is done (as in resource managers need to run), not to mention possible recovery routines that the application set up. Or the routine doing the cleanup. Terminating an address space without violating system integrity or hanging up the address space (or the system) is a very complex business. In a previous life I also had to deal regularly with IMS regions not terminating due to various reasons. In 50% of the cases the 'callrtm' program (which has now morphed into a variant of the force command) did the trick. In all other cases IMS needed to get recycled. I always took a dump to determine the TCB address that I needed to terminate (the bottom one that needs to terminate so everything above can terminate), and most of the time a few of those ominous 'non-cancelable' bits were on. What is worth more? System integrity or IMS restart? As for routines running in 24 bit - if it is an application routine, it *should* be at least located above the line. But some of the *system* routines *must* run in 24bit, IIRC. IBM has made a real effort over the years to put as much as possible above the line, without rewriting all of the operating system. And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to terminate cleanly. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
>We had a similar issue in IMS regions, stalling after out of memory abend, no >way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, >except with some vendor tool cancel that just gets rid of the address space >without proper cleanup that gets you closer to IPL.I wondered back then, how >dare the z/OS RTM routine doing getmains or module loads in a region that >abended with end of memory, does not make sense to me.The answer is probably, >it has been that way ever since and use IEFUSI.Why would terminating an >address space in 64bit or 31bit mode require loading 24bit routines, sounds >awkward?! The address space *task structures* (TCBs, PRBs, SVRBs, IRBs, CDEs) are all allocated in below the line LSQA. It has been that way since before MVS/XA, I think. The RTM2WA is allocated above the line. Also, there is no one 'RTM routine' that gets executed. When RTM gets control (remember PSW swap?) it doesn't *know* yet what it got control for. So it just needs to figure that out, which costs some storage. And recovery always goes back to the last PRB, which means that RTM gets control under a new PRB to ensure that things are not muddied by the recovery (think dump analysis). And then system integrity demands that proper cleanup is done (as in resource managers need to run), not to mention possible recovery routines that the application set up. Or the routine doing the cleanup. Terminating an address space without violating system integrity or hanging up the address space (or the system) is a very complex business. In a previous life I also had to deal regularly with IMS regions not terminating due to various reasons. In 50% of the cases the 'callrtm' program (which has now morphed into a variant of the force command) did the trick. In all other cases IMS needed to get recycled. I always took a dump to determine the TCB address that I needed to terminate (the bottom one that needs to terminate so everything above can terminate), and most of the time a few of those ominous 'non-cancelable' bits were on. What is worth more? System integrity or IMS restart? As for routines running in 24 bit - if it is an application routine, it *should* be at least located above the line. But some of the *system* routines *must* run in 24bit, IIRC. IBM has made a real effort over the years to put as much as possible above the line, without rewriting all of the operating system. And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to terminate cleanly. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
We had a similar issue in IMS regions, stalling after out of memory abend, no way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, except with some vendor tool cancel that just gets rid of the address space without proper cleanup that gets you closer to IPL.I wondered back then, how dare the z/OS RTM routine doing getmains or module loads in a region that abended with end of memory, does not make sense to me.The answer is probably, it has been that way ever since and use IEFUSI.Why would terminating an address space in 64bit or 31bit mode require loading 24bit routines, sounds awkward?! My two cents, Denis. -Original Message- From: Martin Packer To: IBM-MAIN Sent: Wed, Apr 29, 2020 9:45 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! As much to the point, why does this need to be 24-bit LSQA? Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/ or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Barbara Nitz To: IBM-MAIN@LISTSERV.UA.EDU Date: 29/04/2020 08:21 Subject: [EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by: IBM Mainframe Discussion List You say that the problem happens when all the tasks terminate. Your problem is with not enough LQSA for termination. During termination a number of RBs are getmained by RTM to handle termination - like an RB that your ESTAE gets control under (a PRB, IIRC). Or a PURGEDQ SVRB. Depending on what your ESTAE does, you'll need more LSQA for further stuff. I don't have a rule of thumb how much LSQA is needed per TCB. Given that you say you create 1000 tcbs, and each tcb creates at least one subtask, we're talking at least 2000 TCBs. Plus their associated RBs and CDEs. I'd guess that you need at least 6MB below the line of storage reserved for LSQA, possibly more. The only way to do that is to write a custom IEFUSI that really reserves that much LSQA especially for your job. Or the equivalent parmlib member. Remember that LSQA 'grows' from top of region below downwards while private storage 'grows' from bottom of region upwards. So conditional getmains don't help here IMHO. You would have to determine current top of region programmatically and then subtract 1-2MB for termination and then check if you've still got enough room to do your getmain. Anecdote: Before IBM introduced command classes and all the messages that go with too many commands issued at the same time there used to be regular wait states (wait07E, IIRC) due to LSQA exhausted in *master*. Commands execute in *master* (for the most part). Too many commands at the same time generated the exact same situation you currently have - not enough LSQA left. Which is really deadly when it happens in asid 1. IBM only allows 100 commands per class these days. If more are issued, they get held back until there's 'room' again to have them execute. Why do you need 1000 tcbs? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Strange code Generation from XL\C Metal C
I don't understand what the point of this code is? &thread_ptr->buffer[0] All references to arrays in C decay to a pointer so just use the much simpler form: thread_ptr->buffer 2020-04-29 2:27 PM, retired mainframer wrote: The LY instruction is picking up the file descriptor (think DD name) so the IO accesses the correct file. The memcpy statement doesn't care what file the data came from. You are copying whatever is currently in the buffer to reclen and it is obvious that the buffer is at the start of your structure/class. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Tuesday, April 28, 2020 6:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Strange code Generation from XL\C Metal C I am using a pointer to buffer to read in data the data name is thread_ptr->buffer buffer is define char[2100] Here is code when I call the read notice it bumps register 4 21000 bytes to get the address of buffer _read(thread_ptr->fh, &thread_ptr->buffer[0], reclen); L 2,@113thread_ptr LY4,21000(0,2)(*)threadstor.threadstor.fh LLH 14,@123reclen "IBMUSER.DBGR.SERVER(OPENFILE)" Page 68 R14 rce Statement HLASM R6.0 2020/04/28 21.34 L 0,#WSA_1 L 15,=V(@READ) LA1,224(,13) #MX_TEMP1 ST4,224(,13) #MX_TEMP1 ST2,228(,13) #MX_TEMP1 ST14,232(,13) #MX_TEMP1 MVC 8(4,13),#NAB_1+4 SAC 0 BASR 14,15 SAC 512 Here is code where I am trying to copy pos 10 of buffer for 2 bytes notice there is no LY for 21000 to get to buffer ? memcpy(&reclen, &thread_ptr->buffer[10],2); L 14,@113thread_ptr CPYA 2,14 MVC @123reclen,10(14) -- 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: S0F9 and SOFD ABENDs and SVC dumps - oh my!
As much to the point, why does this need to be 24-bit LSQA? Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Barbara Nitz To: IBM-MAIN@LISTSERV.UA.EDU Date: 29/04/2020 08:21 Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by:IBM Mainframe Discussion List You say that the problem happens when all the tasks terminate. Your problem is with not enough LQSA for termination. During termination a number of RBs are getmained by RTM to handle termination - like an RB that your ESTAE gets control under (a PRB, IIRC). Or a PURGEDQ SVRB. Depending on what your ESTAE does, you'll need more LSQA for further stuff. I don't have a rule of thumb how much LSQA is needed per TCB. Given that you say you create 1000 tcbs, and each tcb creates at least one subtask, we're talking at least 2000 TCBs. Plus their associated RBs and CDEs. I'd guess that you need at least 6MB below the line of storage reserved for LSQA, possibly more. The only way to do that is to write a custom IEFUSI that really reserves that much LSQA especially for your job. Or the equivalent parmlib member. Remember that LSQA 'grows' from top of region below downwards while private storage 'grows' from bottom of region upwards. So conditional getmains don't help here IMHO. You would have to determine current top of region programmatically and then subtract 1-2MB for termination and then check if you've still got enough room to do your getmain. Anecdote: Before IBM introduced command classes and all the messages that go with too many commands issued at the same time there used to be regular wait states (wait07E, IIRC) due to LSQA exhausted in *master*. Commands execute in *master* (for the most part). Too many commands at the same time generated the exact same situation you currently have - not enough LSQA left. Which is really deadly when it happens in asid 1. IBM only allows 100 commands per class these days. If more are issued, they get held back until there's 'room' again to have them execute. Why do you need 1000 tcbs? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
You say that the problem happens when all the tasks terminate. Your problem is with not enough LQSA for termination. During termination a number of RBs are getmained by RTM to handle termination - like an RB that your ESTAE gets control under (a PRB, IIRC). Or a PURGEDQ SVRB. Depending on what your ESTAE does, you'll need more LSQA for further stuff. I don't have a rule of thumb how much LSQA is needed per TCB. Given that you say you create 1000 tcbs, and each tcb creates at least one subtask, we're talking at least 2000 TCBs. Plus their associated RBs and CDEs. I'd guess that you need at least 6MB below the line of storage reserved for LSQA, possibly more. The only way to do that is to write a custom IEFUSI that really reserves that much LSQA especially for your job. Or the equivalent parmlib member. Remember that LSQA 'grows' from top of region below downwards while private storage 'grows' from bottom of region upwards. So conditional getmains don't help here IMHO. You would have to determine current top of region programmatically and then subtract 1-2MB for termination and then check if you've still got enough room to do your getmain. Anecdote: Before IBM introduced command classes and all the messages that go with too many commands issued at the same time there used to be regular wait states (wait07E, IIRC) due to LSQA exhausted in *master*. Commands execute in *master* (for the most part). Too many commands at the same time generated the exact same situation you currently have - not enough LSQA left. Which is really deadly when it happens in asid 1. IBM only allows 100 commands per class these days. If more are issued, they get held back until there's 'room' again to have them execute. Why do you need 1000 tcbs? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
