Re: Ignorant z/OS question
https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html On Mon, Jul 24, 2023, 06:32 Phil Smith III wrote: > Shmuel wrote: > >That looks like the result of CP, HCD and MCS not specifying the same > >device type. What happens if all three are 3215? What happens if all > >three are 3270? > > I know what CP is :) > HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx; > which is that, and where is the other one? > > -- > 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: Need DFSORT control statements to extract data from smf15 with storclas blank
On 24/07/2023 11:17 pm, Sri h Kolusu wrote: Was that a typo ? Isn't it supposed to be SMF15SCN ? or you are using SMF14 record layout with SMF15 Interchangeably as they are both have the same layout? The SMF 14 and 15 layouts are the same, so there is one implementation for both. This aligns with the IBM SMF macros. There is a Smf15Record class, but it just extends the Smf14Record class without adding anything. It's basically so you can create a Smf15Record object when you have a type 15 record, but the field names are still the smf14... names. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOGD config question.
On 7/24/23 1:42 PM, Tom Longfellow wrote: I am sure that all of Unix Gurus will laugh at my ignorance, but I still cannot break through this wall. A /good/ Unix Guru worth their disk space will NOT laugh at you / your perceived ignorance. A BOFH will laugh at most things, even legitimate questions. The syntax of syslogd.conf is a complete mystery of arcane directives that I have been unable to juggle.. There are both simpler and more complex files. But, syntax alone doesn't make a file simple or complex. Aside: There are multiple different SYSLOG implementations in the world and I don't have access to a mainframe to check the manual pages for USS / OMVS. I currently have a set up that send all messages from TASKA to LOGA... All messages from TASKB to LOGB. Okay. There is also a 'catchall' that sends all the messages to a common log file. ACK What I would 'like' to do is replace the 'catchall' with a selection screen that exclude TASKA and TASKB messages but still collects the rest of the syslog traffic. I don't know what to think about the "selection screen" comment. But I'm answering as an aspiring hope to be Unix Guru some day. syslog.conf usually has an option to negate something, frequently with a leading exclamation mark. Often the negation means not this priority level or higher levels. E.g. to write all mail logs below the info priority to /var/log/mail you'd use something like the following: mail.*;mail.!info /var/log/mail To write all mail logs except mail.info exactly, you'd use something like the following: mail.*;mail.!=info /var/log/mail With negation in mind, you need to build a pattern that matches everything /except/ the things that you want to not receive. I don't know how your "TASKA" refers to a service; mail, kern(el), cron, etc, or a level. If you are referring to a service, you should be able to construct a rule that matches all services except mail by listing all the other services on the line. I have long considered the service and priority to be akin to columns (services) and rows (priority) in a table. You can easily write rules that match a (set of) given column(s) / services or a (set of) given row(s) (priorities). Writing things to do an intersection of more than one row and column becomes interesting. The tedious method is to write a separate rule that matches each and every intersecting pair of column(s) (services) and row(s) (priorities). There should be no problem having multiple matches writing to the same log file. I hope that helps provide some insight from an aspiring Unix Guru's perspective. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Chaining format 9 and format 3 DSCBs in EAV VTOC
On Fri, 21 Jul 2023 16:46:26 -0500, Wendell Lovewell wrote: >Hello Listers, > >I have a question about how additional extents for a dataset are chained >together for files on EAV volumes. > >If I understand correctly: >- The format 8 record has slots to keep track of the first 3 extents of a >dataset (DS1EXT1/DS1EXT2/DS2EXT3). > >- If there are more than 3 extents, the DS1PTRDS will point to a format 9 >record For format-8, the DS1PTRDS will always point to a format 9 record. In DFSMSfp Advanced Services, describing DS1PTRDS, it says "In a format-1 DSCB this can be a pointer (CCHHR) to a format-2 or format-3 DSCB or be zero. In a format-8 DSCB this always is the CCHHR of a format-9 DSCB." Notice that for format-8 it doesn't say "or zero". Therefore every F8 has an F9. I have seen this in a VTOC dump, even for data sets with 1 extent. In that case the F9 was all hex 00's except the one hex F9 byte > >- The format 9 record contains pointers in the DS9F3 area to point to up to 10 >format 3 records > >- Each format 3 record can point to up to 10 extents 13 extents. > >- The DS9PTRDS description contains the text: > > "FORWARD CHAIN POINTER (CCHHR) TO THE NEXT FORMAT 9 DSCB >-> OR TO THE FIRST FORMAT 3 DSCB IF DATA SET HAS MORE THAN 3 EXTENTS. >OTHERWISE ZERO." > >There wouldn't be a format 9 record if there weren't more than 3 extents. So >I think the comment on the DS9PTRDS field is confusing. > There is always at least one format 9 for each format 8. >It seems there are 2 ways extents could be chained via the DSxPTRDS fields: > >DS9PTRDS -> the next FMT 9 record, whose DS9PTRDS -> another FMT 9 record, >or >DS9PTRDS -> the next FMT 3 record, whose DS3PTRDS -> another FMT 3 record > I don't think there are ever more than two FMT 9 records, but new F9 subtypes might be added some day. Two FMT 9 records are more than enough for the maximum 255 extents. I'm not sure if there is still a limit of 16 extents, even though the design allows more. >My question is: >If there are more than 13 extents, will the DS9PTRDS always point to another >format 9 record? Or are there circumstances when it will point to a format 3 >record? ITYM more than 16 extents. It would take more than 133 extents (3 + 10 * 13) to need a second F9. > >Or, maybe restated: >What will the DS3PTRDS field contain when the format 3 record has been pointed >to by a format 9 record, when there is another format 3 record? > >The graphics in >https://www.ibm.com/docs/en/zos/2.5.0?topic=components-data-set-control-block-dscb-types > show DS3PTRDS->another format 3 for non-EAV records, but they don't show >multiple format 9 records. > Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
It did mention Redhat. On Mon, Jul 24, 2023, 13:03 Rick Troth wrote: > Good article. > As often happens, the author didn't mention Linux for Z ... nor z/VM, > VSE, TPF. > Common public misconception is that Z is exclusively z/OS. > > Don't misunderstand: this is no slam on z/OS. I'm a fan! That's the one > place I'd put my heavy-lifting database and similar "system of record" > workloads. > But Z is hardware and the other op sys make excellent use of that > superior hardware. I'm a fan of Linux and run it on several kinds of > hardware. The best Linux performance, and the most reliable operation, > is consistently on Z. > > The article speaks much about COBOL. Sadly, I only know >one< university > professor teaching COBOL. (And his students are landing high-dollar jobs > out of the gate.) > COBOL benefits from inter-language workings. Similarly, z/OS benefits > from inter-opsys workings. And often those other op sys are on the same > class of hardware. > Calling COBOL to/from languages like PL/I, C, even Python or Rexx, makes > fabulous long-term use of all that lovely COBOL code "out there". > Where the Ars Technica article telling *that* story? (Credit where > credit due: this piece *did* discuss XML and JSON. Good.) > > Sincere thanks Michael for sharing the article. > > -- R; <>< > > > On 7/24/23 13:33, Bill Johnson wrote: > > Say it isn’t so! lol > > > > It’s estimated that there are 10,000 mainframes in use today. They’re > used almost exclusively by the largest companies in the world, including > two-thirds of Fortune 500 companies, 45 of the world’s top 50 banks, eight > of the top 10 insurers, seven of the top 10 global retailers, and eight of > the top 10 telecommunications companies. And most of those mainframes come > from IBM. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, July 24, 2023, 1:21 PM, Bob Bridges > wrote: > > > > Hey, that's fun! Kind of an answer to "the mainframe is old and > decrepit and can't survive much longer in the face of newer and [therefore] > far better technologies". > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* As a father, I have a vested interest in seeing my children do well > in school. If they don't, they won't graduate, and will probably wind up > living in my house until they are thirty years old. This will interfere > with my plan to reach retirement age without killing another human being. > -W Bruce Cameron, _Study Habits_ (2001) */ > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Schmitt, Michael > > Sent: Monday, July 24, 2023 12:43 > > > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > > > > https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ > > > > I’d quibble with the application server topic that talks about CICS with > no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. > > > > -- > > 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
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
I was on site when you came to life I helped make sure the power was correct And all your cables were plugged in But even after that special care Every year you tell me I owe state tax On 7/24/2023 11:12 AM, Mary Kay wrote: Here ‘s a little haiku tribute: Mainframe my mainframe You have been so good to me I’ll love you always Mary Kay -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply job failed GIM240001E for connect direct 6.2
What Allen said. And make sure you follow what the install doc says for Connect:Direct, as well as any HOLD ACTIONs: do the actions before BYPASS. Steve Thompson On 7/24/2023 1:44 PM, Allan Staller wrote: Classification: Confidential Most likley it is a missing library in the SYSLIB concatenation. 1) Check the assembly listing for "macro not found" messages 2) locate the macro 3) Using the SMPE dialogs, adjust the SYSLIB DDDEF to include the missing macro library(ies) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sathish Kumar Sent: Monday, July 24, 2023 12:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Apply job failed GIM240001E for connect direct 6.2 [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi All, While apply the usermod I get below error for connect direct. GIM240001E ** Assembler processing for sysmid LDIACRJ failed for module DGAXACRJ in the SDGASAMP library. The return code 12 Exceeded for the allowable value. ASMA057E undefined operation code. Lot of ASM* Errors messages in sysprint. Please advise on this. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- 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: SYSLOGD config question.
No sweat, Tom. And no laughing. Not sure how to *exclude* things, but I use two catchall statements. (And I avoid fancy extensions to the original specification: keep it simple.) So my /etc/syslog.conf looks mostly like ... *.info /var/log/messages *.info @loghost The first statement routes all event types (the asterisk) with a priority of "info" or more to the common file. The second statement routes the same traffic to a remote SYSLOG listener. (I like using UDP for a lot of reasons, and you didn't ask, so skipping for now.) But I think you already know this part. Moving on then. Is your catchall working? So you want to exclude certain traffic? Would it be acceptable to replace the catchall(s) with a number of specific statements? The way SYSLOG routes traffic is by the facility name. (I used an asterisk in the example, but you can code any of the ten or so pre-defined facilities, and/or make up your own as "local1" or "local5" or whatever.) So maybe ... auth.info /var/log/messages cron.info /var/log/messages daemon.info /var/log/messages kern.info /var/log/messages security.info /var/log/messages user.info /var/log/messages ... so on ... local2.info /var/log/otherfile local7.info /var/log/thirdfile Does this help? -- R; <>< On 7/24/23 14:42, Tom Longfellow wrote: I apologize to all who have seen this before. BUT since I cannot find my original post here, I am going to try again. I am sure that all of Unix Gurus will laugh at my ignorance, but I still cannot break through this wall. The syntax of syslogd.conf is a complete mystery of arcane directives that I have been unable to juggle.. I currently have a set up that send all messages from TASKA to LOGA... All messages from TASKB to LOGB. There is also a 'catchall' that sends all the messages to a common log file. What I would 'like' to do is replace the 'catchall' with a selection screen that exclude TASKA and TASKB messages but still collects the rest of the syslog traffic. =-=-=--=-=- -- 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: Ars Technica: The IBM mainframe: How it runs and why it survives
And if you start comparing the number of data managers, and people responsible for keeping the systems upto date, and security... z/OS comes out quite well. We had one person (lowly grade) whose job it was to go round and touch each laptop/workstation and put a sticker on it saying "Audit July 2023" as part of stock control and audit On Mon, 24 Jul 2023 at 19:51, Ramsey Hallman wrote: > In the two most recent shops I've worked in (prior to my current gig), the > Windows and Unix support staff was two times more than the mainframe staff. > Operations, help desk, security worked with all groups combined. We had 7 > sysprogs, 16 Windows admins, and 14 Unix admins (sysprog staff maintained > Linux Redhat as part of the zLinux support, and we were quite good at Linux > admin). In addition, we had 8 network engineers working on nothing but > network servers. I am talking about support staff. Each area had their own > development staff. The mainframe development staff was probably larger than > the Windows and Unix development staffs, but probably no more than 20%. And > this was a LARGE shop I'm describing. 23 million CICS transactions a day > (in sub-second internal response times) against a mountain of Db2 data. The > physical data center issues were no longer where were we going to put a > mainframe but rather where are we going to put the next DASD array. > > Ramsey > > On Mon, Jul 24, 2023 at 1:27 PM Bob Bridges wrote: > > > To be fair, he said it ~could~ require that many. It might have been > more > > helpful to say that it requires a few sysprogs, a few operators for each > > shift, a few security admins (up to a dozen in a big shop), at least one > > security analyst, as many developers as you need (which could indeed be > > hundreds)...sure, it can add up. But really a small working shop > > ~requires~ only a dozen. Maybe that's pushing it. > > > > --- > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* When you internalize an author whose vision or philosophy is both rich > > and out of fashion, you gain a certain immunity from the pressures of the > > contemporaryGreat literature can help us remain fad-proof. -from > > "Reading Old Books" by Joseph Sobran, 1999 */ > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Lionel B. Dyck > > Sent: Monday, July 24, 2023 13:51 > > > > Wow - talk about scary - requires hundreds to thousands of support staff > - > > something the author harps on several times. > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Schmitt, Michael > > Sent: Monday, July 24, 2023 11:43 AM > > > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > > > > > > https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ > > > > -- > > 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: Ars Technica: The IBM mainframe: How it runs and why it survives
In the two most recent shops I've worked in (prior to my current gig), the Windows and Unix support staff was two times more than the mainframe staff. Operations, help desk, security worked with all groups combined. We had 7 sysprogs, 16 Windows admins, and 14 Unix admins (sysprog staff maintained Linux Redhat as part of the zLinux support, and we were quite good at Linux admin). In addition, we had 8 network engineers working on nothing but network servers. I am talking about support staff. Each area had their own development staff. The mainframe development staff was probably larger than the Windows and Unix development staffs, but probably no more than 20%. And this was a LARGE shop I'm describing. 23 million CICS transactions a day (in sub-second internal response times) against a mountain of Db2 data. The physical data center issues were no longer where were we going to put a mainframe but rather where are we going to put the next DASD array. Ramsey On Mon, Jul 24, 2023 at 1:27 PM Bob Bridges wrote: > To be fair, he said it ~could~ require that many. It might have been more > helpful to say that it requires a few sysprogs, a few operators for each > shift, a few security admins (up to a dozen in a big shop), at least one > security analyst, as many developers as you need (which could indeed be > hundreds)...sure, it can add up. But really a small working shop > ~requires~ only a dozen. Maybe that's pushing it. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* When you internalize an author whose vision or philosophy is both rich > and out of fashion, you gain a certain immunity from the pressures of the > contemporaryGreat literature can help us remain fad-proof. -from > "Reading Old Books" by Joseph Sobran, 1999 */ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Lionel B. Dyck > Sent: Monday, July 24, 2023 13:51 > > Wow - talk about scary - requires hundreds to thousands of support staff - > something the author harps on several times. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Schmitt, Michael > Sent: Monday, July 24, 2023 11:43 AM > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > > https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ > > -- > 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
SYSLOGD config question.
I apologize to all who have seen this before. BUT since I cannot find my original post here, I am going to try again. I am sure that all of Unix Gurus will laugh at my ignorance, but I still cannot break through this wall. The syntax of syslogd.conf is a complete mystery of arcane directives that I have been unable to juggle.. I currently have a set up that send all messages from TASKA to LOGA... All messages from TASKB to LOGB. There is also a 'catchall' that sends all the messages to a common log file. What I would 'like' to do is replace the 'catchall' with a selection screen that exclude TASKA and TASKB messages but still collects the rest of the syslog traffic. =-=-=--=-=- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
To be fair, he said it ~could~ require that many. It might have been more helpful to say that it requires a few sysprogs, a few operators for each shift, a few security admins (up to a dozen in a big shop), at least one security analyst, as many developers as you need (which could indeed be hundreds)...sure, it can add up. But really a small working shop ~requires~ only a dozen. Maybe that's pushing it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* When you internalize an author whose vision or philosophy is both rich and out of fashion, you gain a certain immunity from the pressures of the contemporaryGreat literature can help us remain fad-proof. -from "Reading Old Books" by Joseph Sobran, 1999 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lionel B. Dyck Sent: Monday, July 24, 2023 13:51 Wow - talk about scary - requires hundreds to thousands of support staff - something the author harps on several times. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 11:43 AM Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
Here ‘s a little haiku tribute: Mainframe my mainframe You have been so good to me I’ll love you always Mary Kay > On Jul 24, 2023, at 2:05 PM, Rick Troth wrote: > > yeah ... saw that and cringed > > It's decidedly NOT TRUE. > And for comparison, other platforms require more staff. > > -- R; <>< > > >> On 7/24/23 13:51, Lionel B. Dyck wrote: >> Wow - talk about scary - requires hundreds to thousands of support staff - >> something the author harps on several times. >> >> >> Lionel B. Dyck <>< >> Website: https://www.lbdsoftware.com >> Github: https://github.com/lbdyck >> >> “Worry more about your character than your reputation. Character is what you >> are, reputation merely what others think you are.” - - - John Wooden >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Schmitt, Michael >> Sent: Monday, July 24, 2023 11:43 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Ars Technica: The IBM mainframe: How it runs and why it survives >> >> Ars Technica published a deep-dive explainer of modern IBM mainframes: >> >> https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ >> >> >> I’d quibble with the application server topic that talks about CICS with no >> mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. >> >> >> >> -- >> 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
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
> IBM 1401 Mainframe? > Univac, Rand, Sperry 1+1+1=1 > Amdahl, GE, RCA, NEC, Fujitsu, Hitachi, Unisys, Honeywell, Burroughs, and CDC FSVO "early* Also seems to confuse CPU with CEC; it's been a long time since MVS was limited to 32 CPUs. POWER? From: IBM Mainframe Discussion List on behalf of Schmitt, Michael Sent: Monday, July 24, 2023 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ars Technica: The IBM mainframe: How it runs and why it survives Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- 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: Ars Technica: The IBM mainframe: How it runs and why it survives
yeah ... saw that and cringed It's decidedly NOT TRUE. And for comparison, other platforms require more staff. -- R; <>< On 7/24/23 13:51, Lionel B. Dyck wrote: Wow - talk about scary - requires hundreds to thousands of support staff - something the author harps on several times. Lionel B. Dyck <>< Website: https://www.lbdsoftware.com Github: https://github.com/lbdyck “Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ars Technica: The IBM mainframe: How it runs and why it survives Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- 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: Ars Technica: The IBM mainframe: How it runs and why it survives
Wonderful article. As a retired mainframer I have always had faith in it. It will probably out-live me. I once heard the statistics that 85% of the world runs on the IBM mainframe. Go team Mary Kay > On Jul 24, 2023, at 1:51 PM, Lionel B. Dyck wrote: > > Wow - talk about scary - requires hundreds to thousands of support staff - > something the author harps on several times. > > > Lionel B. Dyck <>< > Website: https://www.lbdsoftware.com > Github: https://github.com/lbdyck > > “Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are.” - - - John Wooden > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Schmitt, Michael > Sent: Monday, July 24, 2023 11:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Ars Technica: The IBM mainframe: How it runs and why it survives > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ > > > I’d quibble with the application server topic that talks about CICS with no > mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. > > > > -- > 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: Ars Technica: The IBM mainframe: How it runs and why it survives
Good article. As often happens, the author didn't mention Linux for Z ... nor z/VM, VSE, TPF. Common public misconception is that Z is exclusively z/OS. Don't misunderstand: this is no slam on z/OS. I'm a fan! That's the one place I'd put my heavy-lifting database and similar "system of record" workloads. But Z is hardware and the other op sys make excellent use of that superior hardware. I'm a fan of Linux and run it on several kinds of hardware. The best Linux performance, and the most reliable operation, is consistently on Z. The article speaks much about COBOL. Sadly, I only know >one< university professor teaching COBOL. (And his students are landing high-dollar jobs out of the gate.) COBOL benefits from inter-language workings. Similarly, z/OS benefits from inter-opsys workings. And often those other op sys are on the same class of hardware. Calling COBOL to/from languages like PL/I, C, even Python or Rexx, makes fabulous long-term use of all that lovely COBOL code "out there". Where the Ars Technica article telling *that* story? (Credit where credit due: this piece *did* discuss XML and JSON. Good.) Sincere thanks Michael for sharing the article. -- R; <>< On 7/24/23 13:33, Bill Johnson wrote: Say it isn’t so! lol It’s estimated that there are 10,000 mainframes in use today. They’re used almost exclusively by the largest companies in the world, including two-thirds of Fortune 500 companies, 45 of the world’s top 50 banks, eight of the top 10 insurers, seven of the top 10 global retailers, and eight of the top 10 telecommunications companies. And most of those mainframes come from IBM. Sent from Yahoo Mail for iPhone On Monday, July 24, 2023, 1:21 PM, Bob Bridges wrote: Hey, that's fun! Kind of an answer to "the mainframe is old and decrepit and can't survive much longer in the face of newer and [therefore] far better technologies". --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* As a father, I have a vested interest in seeing my children do well in school. If they don't, they won't graduate, and will probably wind up living in my house until they are thirty years old. This will interfere with my plan to reach retirement age without killing another human being. -W Bruce Cameron, _Study Habits_ (2001) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 12:43 Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- 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: Ars Technica: The IBM mainframe: How it runs and why it survives
Wow - talk about scary - requires hundreds to thousands of support staff - something the author harps on several times. Lionel B. Dyck <>< Website: https://www.lbdsoftware.com Github: https://github.com/lbdyck “Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ars Technica: The IBM mainframe: How it runs and why it survives Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- 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: Ignorant z/OS question
Shmuel asked: >Do you have the URL for the Tracy Dean paper? Yes, I've read it. >Does it spell out all the pieces? Probably, but as I said before, it makes enough assumptions that I can't understand what to do. Alan Staller wrote: >Going back to the original post, I seemed to have missed the >information about the operating system release. >z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR >MVS/ESA R.x, but that could be incorrect.) This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just the output is fugly. And I'm 99.44% sure that wasn't true on our previous system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply job failed GIM240001E for connect direct 6.2
Classification: Confidential Most likley it is a missing library in the SYSLIB concatenation. 1) Check the assembly listing for "macro not found" messages 2) locate the macro 3) Using the SMPE dialogs, adjust the SYSLIB DDDEF to include the missing macro library(ies) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sathish Kumar Sent: Monday, July 24, 2023 12:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Apply job failed GIM240001E for connect direct 6.2 [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi All, While apply the usermod I get below error for connect direct. GIM240001E ** Assembler processing for sysmid LDIACRJ failed for module DGAXACRJ in the SDGASAMP library. The return code 12 Exceeded for the allowable value. ASMA057E undefined operation code. Lot of ASM* Errors messages in sysprint. Please advise on this. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Apply job failed GIM240001E for connect direct 6.2
Hi All, While apply the usermod I get below error for connect direct. GIM240001E ** Assembler processing for sysmid LDIACRJ failed for module DGAXACRJ in the SDGASAMP library. The return code 12 Exceeded for the allowable value. ASMA057E undefined operation code. Lot of ASM* Errors messages in sysprint. Please advise on this. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ars Technica: The IBM mainframe: How it runs and why it survives
Say it isn’t so! lol It’s estimated that there are 10,000 mainframes in use today. They’re used almost exclusively by the largest companies in the world, including two-thirds of Fortune 500 companies, 45 of the world’s top 50 banks, eight of the top 10 insurers, seven of the top 10 global retailers, and eight of the top 10 telecommunications companies. And most of those mainframes come from IBM. Sent from Yahoo Mail for iPhone On Monday, July 24, 2023, 1:21 PM, Bob Bridges wrote: Hey, that's fun! Kind of an answer to "the mainframe is old and decrepit and can't survive much longer in the face of newer and [therefore] far better technologies". --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* As a father, I have a vested interest in seeing my children do well in school. If they don't, they won't graduate, and will probably wind up living in my house until they are thirty years old. This will interfere with my plan to reach retirement age without killing another human being. -W Bruce Cameron, _Study Habits_ (2001) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 12:43 Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- 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: Ars Technica: The IBM mainframe: How it runs and why it survives
Hey, that's fun! Kind of an answer to "the mainframe is old and decrepit and can't survive much longer in the face of newer and [therefore] far better technologies". --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* As a father, I have a vested interest in seeing my children do well in school. If they don't, they won't graduate, and will probably wind up living in my house until they are thirty years old. This will interfere with my plan to reach retirement age without killing another human being. -W Bruce Cameron, _Study Habits_ (2001) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, July 24, 2023 12:43 Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ignorant z/OS question
Do you have the URL for the Tracy Dean paper? Does it spell out all the pieces? From: IBM Mainframe Discussion List on behalf of Allan Staller Sent: Monday, July 24, 2023 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question Classification: Confidential Going back to the original post, I seemed to have missed the information about the operating system release. z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA R.x, but that could be incorrect.) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Friday, July 21, 2023 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Alan Altmark wrote: >And if you haven't done so, please read the white paper Tracy Dean >referenced in her post. It is focused on this aspect of managing z/OS >guests. We spent a lot of time figuring out how to make it all come >together. (And you may remember me asking related questions on IBM-MAIN >at the time!) >Particularly, understand that z/OS isn't using a "device" of any kind >It thinks it's talking to the Operating System Messages task (aka >integrated console on the HMC), which CP simulates the same way we do >the 3215. It also means you can't just SEND a command like you can with >CMS. Well, I read that paper. Lots of assumptions in there about z/OS knowledge that I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V (I assume that's VARY?) in any of my CONSOLxx members. I do have a CNGRP00, which contains: GROUP NAME(MSTGRP) MEMBERS(S0W103D0,S0W10FFF) Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is INIT CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that console group. If I change the 3D0 to 3E1 to match the actual console address, is that likely to help/hurt? What I'd rather not do is kill the beast and require help from our hosting service--not that they won't help, but we'll have to wait at least a bit for that. (BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has no DIAL command on the screen) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- 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
Ars Technica: The IBM mainframe: How it runs and why it survives
Ars Technica published a deep-dive explainer of modern IBM mainframes: https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ I’d quibble with the application server topic that talks about CICS with no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ignorant z/OS question
Classification: Confidential Going back to the original post, I seemed to have missed the information about the operating system release. z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA R.x, but that could be incorrect.) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Friday, July 21, 2023 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Alan Altmark wrote: >And if you haven't done so, please read the white paper Tracy Dean >referenced in her post. It is focused on this aspect of managing z/OS >guests. We spent a lot of time figuring out how to make it all come >together. (And you may remember me asking related questions on IBM-MAIN >at the time!) >Particularly, understand that z/OS isn't using a "device" of any kind >It thinks it's talking to the Operating System Messages task (aka >integrated console on the HMC), which CP simulates the same way we do >the 3215. It also means you can't just SEND a command like you can with >CMS. Well, I read that paper. Lots of assumptions in there about z/OS knowledge that I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V (I assume that's VARY?) in any of my CONSOLxx members. I do have a CNGRP00, which contains: GROUP NAME(MSTGRP) MEMBERS(S0W103D0,S0W10FFF) Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is INIT CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that console group. If I change the 3D0 to 3E1 to match the actual console address, is that likely to help/hurt? What I'd rather not do is kill the beast and require help from our hosting service--not that they won't help, but we'll have to wait at least a bit for that. (BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has no DIAL command on the screen) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CF Maintenance
That chapter is where I found the suggestion to use REBUILD with LOCATION=OTHER. It just wasn't obvious why... Thanks for the reply!!! Bonnie Barthel Senior IT Specialist 719.649.7888 Mobile bonnie.bart...@kyndryl.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Neiman Sent: Monday, July 24, 2023 6:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: CF Maintenance Bonnie, Either REALLOCATE with MAINTMODE START or REBUILD with LOCATION=OTHER will work just fine for emptying a CF. I can think of two considerations that might affect the decision. First, REALLOCATE must evaluate all structures in all CFs, so the system does more work with that approach. That's not all bad, because it means system programmers and operators don't have to. On the other hand, you can't move XCF Signaling structures with a SETXCF START,REBUILD,CFNAME=cfname, so you'd have to rebuild those structures individually with SETXCF START,REBUILD,STRNAME=strname. In z/OS MVS Setting Up a Sysplex, the chapter "Coupling Facility Guidelines" has procedures for emptying CFs for upgrade (section "Removing structures from a coupling facility for shutdown") and for making updates like the one you're planning, to replace one CF with another (section "Upgrading or replacing a coupling facility"). Bill Neiman IBM Parallel Sysplex Development On Fri, 21 Jul 2023 16:13:04 -0500, Bonnie Barthel wrote: >A couple of questions... > >In the past few years using MAINTMODE START and STOP, I've used SETXCF >START,REALLOCATE to move structures off of a CF for maintenance and back . >I'm just reading a suggestion to use SETXCF >START,REBUILD,CFNAME=CFn,LOCATION=OTHER to move off and SETXCF >START,REALLOCATE to move back. What is the difference? I've had excellent >luck using REALLOCATE to go both ways. Have I just been lucky? > >We are getting ready to replace CF15 with CF13. I'm thinking I'll change the >policy to replace CF15 with CF13 in all structures, START the new policy which >results in a pending change for each structure changed then use REALLOCATE to >get MVS to eliminate all the pending changes rather than REBUILD each >structure. Is using REALLOCATE a risky way to REBUILD the structures? Is there >another way to change preference lists and eliminate CF15 for good? > >Any advice will be appreciated > >-- >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: Need DFSORT control statements to extract data from smf15 with storclas blank
>>|| r15.smsClassSections().get(0).smf14scn().equals(""))
Andrew,
Was that a typo ? Isn't it supposed to be SMF15SCN ? or you are using SMF14
record layout with SMF15 Interchangeably as they are both have the same layout?
Thanks,
Kolusu
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CF Maintenance
Bonnie, Either REALLOCATE with MAINTMODE START or REBUILD with LOCATION=OTHER will work just fine for emptying a CF. I can think of two considerations that might affect the decision. First, REALLOCATE must evaluate all structures in all CFs, so the system does more work with that approach. That's not all bad, because it means system programmers and operators don't have to. On the other hand, you can't move XCF Signaling structures with a SETXCF START,REBUILD,CFNAME=cfname, so you'd have to rebuild those structures individually with SETXCF START,REBUILD,STRNAME=strname. In z/OS MVS Setting Up a Sysplex, the chapter "Coupling Facility Guidelines" has procedures for emptying CFs for upgrade (section "Removing structures from a coupling facility for shutdown") and for making updates like the one you're planning, to replace one CF with another (section "Upgrading or replacing a coupling facility"). Bill Neiman IBM Parallel Sysplex Development On Fri, 21 Jul 2023 16:13:04 -0500, Bonnie Barthel wrote: >A couple of questions... > >In the past few years using MAINTMODE START and STOP, I've used SETXCF >START,REALLOCATE to move structures off of a CF for maintenance and back . >I'm just reading a suggestion to use SETXCF >START,REBUILD,CFNAME=CFn,LOCATION=OTHER to move off and SETXCF >START,REALLOCATE to move back. What is the difference? I've had excellent >luck using REALLOCATE to go both ways. Have I just been lucky? > >We are getting ready to replace CF15 with CF13. I'm thinking I'll change the >policy to replace CF15 with CF13 in all structures, START the new policy which >results in a pending change for each structure changed then use REALLOCATE to >get MVS to eliminate all the pending changes rather than REBUILD each >structure. Is using REALLOCATE a risky way to REBUILD the structures? Is there >another way to change preference lists and eliminate CF15 for good? > >Any advice will be appreciated > >-- >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: Ignorant z/OS question
HCD is the interactive tool that you use to maintain the IODF, which among other things defines the MVS I/O configuration. MCS is Multiple Console Support, the component that is concerned with controlling MVS consoles. From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Monday, July 24, 2023 7:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question Shmuel wrote: >That looks like the result of CP, HCD and MCS not specifying the same >device type. What happens if all three are 3215? What happens if all >three are 3270? I know what CP is :) HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx; which is that, and where is the other one? -- 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: Ignorant z/OS question
Shmuel wrote: >That looks like the result of CP, HCD and MCS not specifying the same >device type. What happens if all three are 3215? What happens if all >three are 3270? I know what CP is :) HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx; which is that, and where is the other one? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMITMSGX release 2.1.4 (CMS-like 'xmitmsg' for Linux/Unix/POSIX)
forgot the link https://github.com/trothr/xmitmsgx/releases/tag/2.1.4/ On 7/23/23 22:17, Rick Troth wrote: I was able to cut release 2.1.4 of this XMITMSG work-alike. It includes support for Rexx (Regina) and now also Java. Also included are shell scripts to demonstrate calling the utility from C, Rexx, and Java. Two RPMs are up on GitHub: 64-bit PC Linux (AMD/Intel) and 64-bit Z Linux. I did turn the crank with Linux on ARM, FreeBSD (on AMD/Intel), and Solaris (on AMD/Intel). Those are not up on GitHub but if anyone is interested I can provide them (but you can build them yourself). The samples are in the "src" directory. When packages are under /opt/vendor/package that makes sense, but the prefix for the RPM install is "/usr". That means the samples are in /usr/src, which seems ... unclean. Never the less, an 'rpm -e' nicely removes them, so I'm not stressed about it. Feedback is always welcome! I've gotten a lot of positive responses about supporting ooRexx. Dunno if it's my own denseness or if ooRexx really is harder, but I have not yet been able to crack the nut of the ooRexx SAA interface. If someone really wants to call this baby from ooRexx, do please lend a hand. danku -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
