Re: They are *all* dinosaurs
> On 2 Aug 2023, at 11:38 am, Jon Perryman wrote: > >> On Tuesday, August 1, 2023 at 05:18:46 PM PDT, David Crayford >> wrote: >> The obvious difference is that C/C++ etc are still evolving. >> The z/OS COBOL compiler hasn’t implemented significant features >> of the ANSI standard. If I were a COBOL programmer I would like >> the language to support collections, dictionaries etc but I suppose >> the type of applications where COBOL is used don’t require hash tables. > > Are you suggesting that COBOL programmers should stop using instorage VSAM > KSDS and learn how to use collections, dictionaries and hash tables? Are you > saying that KSDS doesn't solve these exact problems using a facility > programmers use daily? That’s not what I’m saying at all. My point is that IBM don’t invest in COBOL to implement features in the language standard whereas MicroFocus do. Most probably because they don’t have customer requirements asking for them. I mostly program in C++ and Java these days and take it for granted that they have built-in standard libraries for data structures and algorithms. COBOL doesn’t even support dynamic arrays but most COBOL programmers are used to having to use the file system to make up for the lack collections. Performing binary searches using SEARCH ALL was as good as it got back when I was working with COBOL. > > I don't use Cobol because it's boring and nothing to do with it's ability to > solve business problems. I think that Cobol allows programmers to be business > line experts instead of computer experts. I’m not knocking COBOL. The raison d’être of the mainframe is to run applications written in COBOL. > > > > -- > 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: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> The IBM z16 can have up to 1,536 PCIe+ slots I'm gonna quit explaining this and just say, "WRONG" every time you say this as if it's a fact :) On 8/1/2023 8:01 PM, Jon Perryman wrote: > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? PCIe was created specifically for PCs and IBM z16 chose to use that as their only channel technology. Channelized I/O for PC has been available for several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 PCIe+ slots. As for x86 fiber channel connection to a PC, PCIe is only one possibility. -- 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: They are *all* dinosaurs
> On Tuesday, August 1, 2023 at 05:18:46 PM PDT, David Crayford > wrote: > The obvious difference is that C/C++ etc are still evolving. > The z/OS COBOL compiler hasn’t implemented significant features > of the ANSI standard. If I were a COBOL programmer I would like > the language to support collections, dictionaries etc but I suppose > the type of applications where COBOL is used don’t require hash tables. Are you suggesting that COBOL programmers should stop using instorage VSAM KSDS and learn how to use collections, dictionaries and hash tables? Are you saying that KSDS doesn't solve these exact problems using a facility programmers use daily? I don't use Cobol because it's boring and nothing to do with it's ability to solve business problems. I think that Cobol allows programmers to be business line experts instead of computer experts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Take for example an Emulex (Broadcom) HBA. The quad port adapter can handle up to 10M IOPS with a throughput rate of 12,800MB/s full duplex using 16-lane PCIe which utilities DMA. All I/O is offloaded, interrupts, multiplexing etc. When you consider that a standard commodity rack server such as an AMD EPYC can support 128 PCIe lanes and up to 8 memory channels I would suggest x86 can handle a lot of I/O if you have the right gear. https://docs.broadcom.com/doc/LPe35000-LPe36000-PB > On 2 Aug 2023, at 10:42 am, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 8/1/23 7:20 PM, David Crayford wrote: >> What’s the difference between between channelized I/O and a rack of x86 >> servers connected to a SAN using fibre channel driven by high speed HBAs? > > I don't know. > > My understanding is that Fibre Channel is an evolution of SCSI which is > supposedly a somewhat intelligent controller wherein the OS asks said > controller to fetch / store some data for it. As I understand it, the OS & > main CPU aren't involved in the transfer beyond asking the controller to do > the transfer on it's behalf. > > I'd have to reference documentation to see if / how much Direct Memory Access > comes into play vs the CPU's involvement in the transfer to / from the > controller. > > But between the controller and the back end drive, as I understand it, the > CPU ins't involved. > > So I can't say that "a rack of x86 servers connected to a SAN using fibre > channel" isn't using channelized I/O. I think in many ways they are. > > This is a place where minutia matters. > > > > Grnat. . . . > > -- > 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
Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford > wrote: > What’s the difference between between channelized I/O and a rack of > x86 servers connected to a SAN using fibre channel driven by high speed HBAs? PCIe was created specifically for PCs and IBM z16 chose to use that as their only channel technology. Channelized I/O for PC has been available for several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 PCIe+ slots. As for x86 fiber channel connection to a PC, PCIe is only one possibility. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 7:20 PM, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? I don't know. My understanding is that Fibre Channel is an evolution of SCSI which is supposedly a somewhat intelligent controller wherein the OS asks said controller to fetch / store some data for it. As I understand it, the OS & main CPU aren't involved in the transfer beyond asking the controller to do the transfer on it's behalf. I'd have to reference documentation to see if / how much Direct Memory Access comes into play vs the CPU's involvement in the transfer to / from the controller. But between the controller and the back end drive, as I understand it, the CPU ins't involved. So I can't say that "a rack of x86 servers connected to a SAN using fibre channel" isn't using channelized I/O. I think in many ways they are. This is a place where minutia matters. Grnat. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? > On 2 Aug 2023, at 6:53 am, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 8/1/23 3:10 PM, Rick Troth wrote: >> Look for channelized I/O, > > Didn't supers ~> cray use channelized I/O? > > Also, I feel like there is another slippery slope discussion of what is > channelized I/O in this context. > >> then other physical attributes (not just size, not just the instruction set). > > Please elaborate on what "other physical attributes" means. > > > > Grant. . . . > > -- > 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: They are *all* dinosaurs
> On 31 Jul 2023, at 10:28 pm, Seymour J Metz wrote: > > The media sling around terms like dinosaur and legacy for mainframes and > mainframe software, and tout "new" languages and platforms like C, Unix and > windows. But look at the dates and explain to me, e.g., how z is legacy but > x86 is not, how z/OS is legacy but Unix is not, how COBOL and PL/I are legacy > but C is not. > > The obvious difference is that C/C++ etc are still evolving. The C23 and C++23 standards are due for ratification next year. C++ from 1998 is a different language to C++20. PL/I has been functionally stabilised for decades. The z/OS COBOL compiler hasn’t implemented significant features of the ANSI standard. If I were a COBOL programmer I would like the language to support collections, dictionaries etc but I suppose the type of applications where COBOL is used don’t require hash tables. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 3:10 PM, Rick Troth wrote: Look for channelized I/O, Didn't supers ~> cray use channelized I/O? Also, I feel like there is another slippery slope discussion of what is channelized I/O in this context. then other physical attributes (not just size, not just the instruction set). Please elaborate on what "other physical attributes" means. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I do not recall Multi-core cpus being part of the initial z/arch disclosure in 1979 when I was at that special meeting in POK for CA. The ideas of the G3 chipset was announced about 2001 at another disclosure meeting I went to in NY (forgot the name of the town, it was not POK) given by Bob Rogers. S/390 v2.10 and z/OS 1.1 were discussed and Bob said the two were so close to each other he would have had to look at the CVT prefix to know which OS was running on that machine. Wasn't it the z14s that initially had "dual" core processing for the zIIPs and IFLs? Eventually the zAAPs became zIIPs So many changes, that I just can't remember all of them. Steve Thompson On 8/1/2023 5:44 PM, Jon Perryman wrote: > On Tuesday, August 1, 2023 at 12:54:10 PM PDT, Steve Thompson wrote: when IBM comes up with a new Architecture... AFAIK, IBM z is not a new architecture. Intel, Sun & HP invented multi-core CPU chips. Intel invented PCI and PCIe. What is the new architecture that IBM z introduced? How long will it take to need > 64bit addressing? 64 bit data adressing already exists. As for programs, does anyone think they can write a 4TB ( 64 bit ) program? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Tuesday, August 1, 2023 at 12:54:10 PM PDT, Steve Thompson > wrote: > when IBM comes up with a new Architecture... AFAIK, IBM z is not a new architecture. Intel, Sun & HP invented multi-core CPU chips. Intel invented PCI and PCIe. What is the new architecture that IBM z introduced? > How long will it take to need > 64bit addressing? 64 bit data adressing already exists. As for programs, does anyone think they can write a 4TB ( 64 bit ) program? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Definition of mainframe? Was: Ars Technica
> On Tuesday, August 1, 2023 at 07:59:07 AM PDT, Grant Taylor wrote: >> On 8/1/23 2:49 AM, Colin Paice wrote: >> You can have synchronous write - used in same "site" and async - >> where the remote end is miles away. This is used for media failure. > Yes. Emphasis on /media/ failure. This does nothing for /data/ > failure, e.g. corruption / malicious activity. > Traditional offline backups address both /media/ failure and /data/ failure. > Note. This is not a backup. If you delete the dataset, both copies will be > deleted. > I usually see snapshots created a couple of different ways: > 1) The older way was to pause things and take an actual copy. Tunnel vision is the biggest problem people need to address. IBM GDPS is decades old and has always included an IBM services contract to specifically address customer tunnel vision. They start with a big picture approach by first identifying the recovery requirements and recovery problems that must be addressed. Only at that point can you then decide the software, hardware and procedural components to best meet the requirements and solve the problems. To say "This is not a backup" ignores the stated requirements (delete a file and have a backup). Rename resolves both requirements. To say "async - where the remote end is miles away" denies the existence of GDPS. As in the name implies, Globally Dispersed Parallel Sysplex, you can have a sysplex split between 2 active locations. Sync is a sysplex requirement. To say "usually see snapshots" ignores requirements. A GDPS customer will have many requirements and money is usually lowest on the list (or not on the list). Consider for instance, a dual copy disk on both sites of the sysplex and each disk is mirrored (2 disks on at each site). When all commits have completed, turn off mirroring at one site and you have a moment in time backup, site failure recovery if the unmirrored disk fails and site failure recovery if the mirrored disk site fails. Recovery is far more complicated than a single component. There is substance to everything being said but realize this is a truth, but not necessarily the complete truth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
W dniu 01.08.2023 o 19:52, Phil Smith III pisze: Sebastian Welton wrote: https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Heh heh, "BS2000". Reminds me of the company that bought the NOMAD product: Select Business Systems; their domain was SelectBS.com. Wow, make that "is", it lives: https://selectbs.com/products/nomad/ This is former Siemens product, very similar to IBM mainframe. I saw such machine around 2001 in National Bank of Austria. Connected to Symmetrix CKD DASD using ESCON channels. There was at least one installation in Poland. However it was popular in DACH countries (Deutschland, Austria, Confederiatio Helvetica). Now it is as moribound as Nec - Bull - GE - Honeywell Gecos. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I've been told by some sales folks not to use the M-word when talking about LinuxONE. I feel like HAL keeping secrets from the crew of Discovery One. No relation to Linux One - or is there? On 8/1/2023 12:44 PM, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I had a brief exposure to Burroughs machines in the mid-1970s. I would say that the B6700 was definitely a mainframe, as well as the B6800 that followed it. I've never worked with any Univac mainframes, nor am I familiar with the current line from Unisys. It has been said here that the current Unisys machines use x86 processors. I don't consider that to be relevant in discussing whether or not they are mainframes. IOW, whether or not anyone is doing it, it is possible to design a mainframe using commodity processors, x86 or otherwise. -- Tom Marchant On Tue, 1 Aug 2023 16:10:48 -0400, Rick Troth wrote: >On balance, I encountered a Unisys machine, with the instruction set of >a much older system (which might have been a mainframe in its time) >which was definitely *not* a mainframe (because the contemporary box >just did not fit the class). >So Unisis machines not so much. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I don't know what you mean, Mike. Access Registers (introduced with ESA/390) do not point to pages or bytes, but to address spaces or data spaces. -- Tom Marchant On Tue, 1 Aug 2023 15:09:01 -0500, Mike Schwab wrote: >Of course ¿ESA? did create access registers that point to 4K pages instead >of bytes, so 8/16 TB was possible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
An access register points (indirectly) to an entire address space, not just a page. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, August 1, 2023 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On 40TB main memory now, so only 20,480 x since 1999 intro of 64 in 24 years. Of course ¿ESA? did create access registers that point to 4K pages instead of bytes, so 8/16 TB was possible. On Tue, Aug 1, 2023, 14:54 Steve Thompson wrote: > How about we change from Mainframe to zFrame? > > Yeah, I know, then when IBM comes up with a new Architecture... > How long will it take to need > 64bit addressing? > > Steve Thompson > > On 8/1/2023 3:44 PM, Phil Smith III wrote: > > Jon Perryman wrote: > >> The last Fujitsu mainframe is scheduled for 2030 and dropping all > >> support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are > >> now x86 based. Are these mainframes or are they PCs? > > PCframes? mainCs? It is hard to define rigorously, but as someone else > quoted SCOTUS, "I know it when I see it". > > > > In common use, I'd argue (not very vociferously, I admit) that only IBM > machines-and maybe Fujitsus-are really mainframes: The others are just very > large computers. But this may be due entirely by the fact that I have to > explain to sales reps on a regular basis that our z/OS support means IBM > machines, not Unisys or whatever! > > > > > > -- > > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 15:44, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! Fujitsu machines following S/370 architecture are mainframes. Amdahl machines were definitely mainframes. Look for channelized I/O, then other physical attributes (not just size, not just the instruction set). It's not difficult, and it's not merely cultural. On balance, I encountered a Unisys machine, with the instruction set of a much older system (which might have been a mainframe in its time) which was definitely *not* a mainframe (because the contemporary box just did not fit the class). So Unisis machines not so much. -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 40TB main memory now, so only 20,480 x since 1999 intro of 64 in 24 years. Of course ¿ESA? did create access registers that point to 4K pages instead of bytes, so 8/16 TB was possible. On Tue, Aug 1, 2023, 14:54 Steve Thompson wrote: > How about we change from Mainframe to zFrame? > > Yeah, I know, then when IBM comes up with a new Architecture... > How long will it take to need > 64bit addressing? > > Steve Thompson > > On 8/1/2023 3:44 PM, Phil Smith III wrote: > > Jon Perryman wrote: > >> The last Fujitsu mainframe is scheduled for 2030 and dropping all > >> support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are > >> now x86 based. Are these mainframes or are they PCs? > > PCframes? mainCs? It is hard to define rigorously, but as someone else > quoted SCOTUS, "I know it when I see it". > > > > In common use, I'd argue (not very vociferously, I admit) that only IBM > machines-and maybe Fujitsus-are really mainframes: The others are just very > large computers. But this may be due entirely by the fact that I have to > explain to sales reps on a regular basis that our z/OS support means IBM > machines, not Unisys or whatever! > > > > > > -- > > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
How about we change from Mainframe to zFrame? Yeah, I know, then when IBM comes up with a new Architecture... How long will it take to need > 64bit addressing? Steve Thompson On 8/1/2023 3:44 PM, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Jon Perryman wrote: >The last Fujitsu mainframe is scheduled for 2030 and dropping all >support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are >now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Sebastian Welton wrote: >https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Heh heh, "BS2000". Reminds me of the company that bought the NOMAD product: Select Business Systems; their domain was SelectBS.com. Wow, make that "is", it lives: https://selectbs.com/products/nomad/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AT-TLS and CSSMTP setup
Brian Westerman asked: >so you can use authsmtp.com to send directly from CSSMTP? It's just an SMTP server, so if you can get there from your network, sure. >When you send the email, does it come from where you say it should or >do you have to use a special email that they give you? You tell it the valid sending domains. You need to set your SPF record correctly, of course. >That would be great. I assume they have an smtp server that you set up >in the targetname field. Do you know if they use port 25, 26 or 587? 2525. Avoids all those blocked-port hassles! See https://www.authsmtp.com/features.php for details. >I think if it works, it would be a great solution. >I tried sending them a question, but there contact form fails. Ouch. I've emailed them, CCed you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Definition of mainframe? Was: Ars Technica
Williams tube: periodic regeneration Drum: stable Delay line: amplification Core, rod, thin film: destructive read followed by rewrite From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, August 1, 2023 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Definition of mainframe? Was: Ars Technica I think most pre- semiconductor memory including core memory in S/360 was destructive reads with hardware rewiting the store, so you can certainly understand using move, not to mention C for Compare instructions had few alternatives. On Tue, Aug 1, 2023, 10:51 Seymour J Metz wrote: > The term of art "move" goes back at least to the 705, well before COBOL, > so even if it's confusing it's not likely to change. > > > From: IBM Mainframe Discussion List on behalf > of Gary Weinhold > Sent: Tuesday, August 1, 2023 11:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Definition of mainframe? Was: Ars Technica > > >> Wayne B wrote: > COBOL MOVE was not intuitive. Should have been PROPOGATE or COPY, COPY was > already taken I guess. > > > Assembler has the same problem: MVC, MVCL, etc. > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at http://www.dkl.com/ > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, > you are not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. > > > > -- > 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: Definition of mainframe? Was: Ars Technica
I think most pre- semiconductor memory including core memory in S/360 was destructive reads with hardware rewiting the store, so you can certainly understand using move, not to mention C for Compare instructions had few alternatives. On Tue, Aug 1, 2023, 10:51 Seymour J Metz wrote: > The term of art "move" goes back at least to the 705, well before COBOL, > so even if it's confusing it's not likely to change. > > > From: IBM Mainframe Discussion List on behalf > of Gary Weinhold > Sent: Tuesday, August 1, 2023 11:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Definition of mainframe? Was: Ars Technica > > >> Wayne B wrote: > COBOL MOVE was not intuitive. Should have been PROPOGATE or COPY, COPY was > already taken I guess. > > > Assembler has the same problem: MVC, MVCL, etc. > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at http://www.dkl.com/ > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, > you are not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. > > > > -- > 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: Definition of mainframe? Was: Ars Technica
The term of art "move" goes back at least to the 705, well before COBOL, so even if it's confusing it's not likely to change. From: IBM Mainframe Discussion List on behalf of Gary Weinhold Sent: Tuesday, August 1, 2023 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Definition of mainframe? Was: Ars Technica >> Wayne B wrote: COBOL MOVE was not intuitive. Should have been PROPOGATE or COPY, COPY was already taken I guess. Assembler has the same problem: MVC, MVCL, etc. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://www.dkl.com/ E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- 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: Definition of mainframe? Was: Ars Technica
>> Wayne B wrote: COBOL MOVE was not intuitive. Should have been PROPOGATE or COPY, COPY was already taken I guess. Assembler has the same problem: MVC, MVCL, etc. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Definition of mainframe? Was: Ars Technica
On 8/1/23 2:49 AM, Colin Paice wrote: Your Copy on Write - may be what I know as dual write - where you write to different volumes - usually on different dasd subsystems, so if you lose one dasd subsystem - the data is available on another. Nope. "Copy on Write" is explicitly what you were previously describing where in multiple references to the data had the same singular copy of the data in the back-end and and things are copied only when one of the references to the data changes the data. As long as COW instances use the exact same data, as in base OS data sets from the same OS version, then there's only the single instance, independent of how many references to it there are. I see writing to multiple drives in parallel -- from an OS / software level -- referred to as software RAID / mirroring. COW and RAID (mirroring) are different things meant to serve different purposes. You can have synchronous write - used in same "site" and async - where the remote end is miles away. This is used for media failure. Yes. Emphasis on /media/ failure. This does nothing for /data/ failure, e.g. corruption / malicious activity. Traditional offline backups address both /media/ failure and /data/ failure. Note. This is not a backup. If you delete the dataset, both copies will be deleted. needMOREcoffee We seem to be thinking very similar things but typing at different times. I was talking about what I think is called snapshot. It is used like 1- Issue Snapshot copy (of your database) - this takes a couple of seconds or less. I usually see snapshots created a couple of different ways: 1) The older way was to pause things and take an actual copy. This was slower and took quite a while O(minutes ~> hours). 2) The newer way seems to be some sort of -- what I would call -- COW system where changes to parts of the storage are written to a new location and access to the primary / live interface reflect the new data. Conversely the snapshot interface reflects the old data from the point in time the snapshot was made. This is faster and takes much less time O(seconds). The gory details of how it's done are implementation specific. 2- Backup this copy - it may take a couple of hours to read from the DASD subsystem, and write to perhaps Virtual Tape. Agreed. 3- The original data set continues to be updated, whereas the copy does not change, so you have point of time consistency Agreed. 4- You can restore to the point of time, and for products like DB2 and MQ, read the logs and reapply all of the updates. I think I agree though I will say that depending on how the snapshot was taken and if the higher level applications are aware of the snapshot and quiesced in support of the snapshot may make the difference between a "crash consistent" snapshot / copy and a "suspend consistent" snapshot. This type of consistency and how the applications roll forward here from gets interesting and tricky. But, even a crash consistency snapshot is almost always more current and easier to recover than a cold backup from hours / days ago. Or at least looses less data / is more fresh / less effort to bring back current. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XMITMSGX release 2.1.5 for C, Regina Rexx, ooRexx, Java
Thanks to help from Sir Dave the Generous, we confirmed that the XMITMSGX Rexx support built with Regina works just fine with ooRexx. Yay! I had been trying to build against ooRexx expecting some linkage differences, but *someone* in ooRexx land made things compatible between ooRexx and Regina. I did not cut a new release (on GitHub) but did spin two new RPMS (Linux-s390x and Linux-x86_64). They're here ... http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5-0.s390x.rpm http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5-1.x86_64.rpm and the source tarball ... http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5.tar.gz The only change was to the shell script wrapper demonstrating the message handler from Rexx. As of now, if it doesn't find Regina then it falls back to 'rexx' (presuming ooRexx). No change to the sample Rexx script nor to the interface library. Enjoy! -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Preferred FTP Client for Windows
In Co:Z, linerule=L4 (4 byte length prefixes) and linerule=rdw (IBM compatible RDWs) are different things. There is also a linerule=mfrdw, but you'll have to look at the documentation for that. Kirk Wolf On Mon, Jul 31, 2023, at 6:29 PM, Paul Gilmartin wrote: > On Mon, 31 Jul 2023 17:16:20 -0500, Kirk Wolf wrote: > > >Here's the direct URL to the User's Guide: > >https://coztoolkit.com/docs/sftp/index.html > > > >for FILEDATA=Record, here's an example: > > > >ls /+mode=binary,linerule=L4 > > > >(There are a number of different linerule options, including rdw, crlf, nl, > >etc.) > > > And I suspect RDW is incompatible with FILE DATA=RECORD. It takes only > two IBM designers, not communicating, to achieve that. > > I once did a GET to desktop with format RECORD. Even as promised it returned > the RDWs as data. Than I did a PUT to a different MVS data set with the same > option. It faithfully treated the RDW images as data. Now I have two RDWs on > each record. There's no way to create an incident for that: It's behaving > precisely as documented. > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Sebastian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Definition of mainframe? Was: Ars Technica
Your Copy on Write - may be what I know as dual write - where you write to different volumes - usually on different dasd subsystems, so if you lose one dasd subsystem - the data is available on another. You can have synchronous write - used in same "site" and async - where the remote end is miles away. This is used for media failure. Note. This is not a backup. If you delete the dataset, both copies will be deleted. I was talking about what I think is called snapshot. It is used like 1- Issue Snapshot copy (of your database) - this takes a couple of seconds or less. 2- Backup this copy - it may take a couple of hours to read from the DASD subsystem, and write to perhaps Virtual Tape. 3- The original data set continues to be updated, whereas the copy does not change, so you have point of time consistency 4- You can restore to the point of time, and for products like DB2 and MQ, read the logs and reapply all of the updates. On Tue, 1 Aug 2023 at 03:06, Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 7/31/23 12:45 PM, Colin Paice wrote: > > A volume is a convenient picture - they no longer exist on modern DASD. > > ACK > > My limited understanding is that the S/360 or S/370 would probably not > recognize anything in use today as DASD. The S/390 /might/ see > something that vaguely reminds it of DASD through ESCON / FICON. > > It seems as if things are significant numbers of layers of abstraction > and emulation. > > > Data is spread across many different PC sized disks. > > Yep. > > It's amazing if not mind blowing what can be done with abstraction and > virtualization of storage. > > > We have extended volumes which are bigger than traditional volumes. > > It gives more space for the same number of volumes. > > :-) > > > A "track" is mapped to one PC sized disk, and block on disk.. > > If you rewrite a track it will most probably go to a different > > PC disk. In the storage controller there is a big array which has > > VOLID.CYL.Track -> pcdisk.position. > > I'm not unpacking and scrutinizing that based on your "Some of the above > is not true" comment. > > > I can "copy a dataset" on the same DASD subsystem just by copying > > the relevant bits of this array. So if we have part of dataset1 > > USER00.00.01 -> PCDISK1. 4000 the copy creates USER99.4002.12 -> > > PCDISK1.4000. This copy takes a second or so. There is no data > > transfer. If you update dataset1, then its VOLID.CYL.track will > > point to a new block, and so the arrays diverge. > > This sounds like what I generally hear referred to as "copy on write" > and is frequent enough that it's abbreviated as C.O.W. and multiple > things support this, one even with COW in the file name. > > > If we copy the dataset to a different DASD subsystem - then every block > > will be read - and written to the other subsystem. > > Yep. > > > Some of the above is not true - but it gives the picture. > > ;-) > > > > Grant. . . . > > -- > 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
