>On Saturday, July 29, 2023 at 03:26:45 PM PDT, Rick Troth <tro...@gmail.com>
>wrote:
> I don't follow your comparison of PDS/e and Unix filesystems.
Understanding PDS/e inefficiency is critical to understand because it is the
functional equivalent of a Unix filesystem. Put on your z/OS DASD sysprog hat
for a moment and think about the problems caused by a 10TB PDS/e file with
thousands of members being written and read by hundreds of users at the same
time. As DASD sysprog, you can't change anything to make this file perform
efficiently. Each block is written to a random available block in this 10TB
file. Deleting files free's blocks which may cause the disk head to bounce
around the disk. You can make VSAM and sequential files efficient but you are
at the mercy of PDS/e.
Anyone remember compressing a PDS or defragging MS Windows disk? PDS/e and
filesystems suffer from fragmentation and more.
> Some features of Unix (and Linux) filesystems are a step up from historical
> MVS data sets
There are problems with both. I disagree that filesystems are a step up from
MVS data sets. When did you last defrag a sequential z/OS file? I know that
architecturally, filesystems and PDS/e are different but conceptually they are
the same. We could talk about implementation but then we ignore why filesystems
perform badly for Windows, Linux, z/OS Unix and other OS's.
On Saturday, July 29, 2023 at 03:26:45 PM PDT, Rick Troth
<tro...@gmail.com> wrote:
I don't follow your comparison of PDS/e and Unix filesystems.
If I saw correlation of Linux filesystems with PDS, I glossed over it as
stoopid. (Here again, I feel your pain.)
My understanding is that PDS is (historically) a means of segmenting one
data set into related chunks. They're "related" because they're all
members of the same data set.
The real "filesystem" for MVS is the catalog, and the "files" are the
data sets, whether partitioned or not. Hopefully the VTOC and the
catalog match-up. That's not always required.
PDS are also flat, unless something has changed recently.
PDS is more like the partition table on a PC disk. (Though the latter
doesn't use names, per se, and tends to have less "members".)
You're absolutely right: a Unix filesystem is a file containing files.
There the similarity to PDS ends.
Unix filesystems have two important features: inodes and directories.
The inodes are usually invisible. The directories connect inodes with
names, which is what people see.
A hard link is where two files (by name) refer to the same inode. A
symbolic link is a special kind of Unix file that names another file.
Here's a neat trick: you can make a hard link to a sym-link.
There are only a handful of actual file *types*:
* plain file
* directory
* character special (like a terminal)
* block special (like a disk drive or partition thereof)
* symbolic link
* and a couple others added by OMVS ... really
As I recall, other Unix vendors added their own special types. But I've
slept since then and memory is fuzzy (or maybe I dreamed it).
Not all "filesystems" mountable on a Linux system properly implement
inodes and directories. They therefore lack some functionality in
practice; it can be significant.
Some features of Unix (and Linux) filesystems are a step up from
historical MVS data sets. It is sadly still possible to have a data set
with no time stamp.
So you can count that as one thing Unix did that MVS has learned
afterward. (Not a slam on z/OS. Just keeping things in perspective.)
-- R; <><
On 7/29/23 12:28, Jon Perryman wrote:
> Can anyone provide the definition of MAINFRAME? The ARS Technica article is
> complete nonsense because the mainframe is a state of mind and nothing to do
> with reality. Can anyone prove me
> wrong?https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.
>
> The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots.
> Linux will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I
> suspect it still uses a PCIe zCPU card. I can't say with any certainty, but I
> suspect that z/OS will run on a PC by using Hercules. What is the definition
> of MAINFRAME?
>
> 1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the
> 64 cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores).
> The largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD
> Ryzen CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC
> CPU (AMD uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz)
> has a slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25%
> extra user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD
> Ryzen would need 1 motherboard for 4 CPU.
>
> 2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are
> also on every modern motherboard. IBM z16 chooses not to include other
> hardware (e.g. SATA, IDE, WIFI and more). Motherboards choose not to have
> 1,600 PCIe slots. IBM could allow PCIe graphics cards, mice, keyboards and
> more. Essentially, IBM z16 and AMD Ryzen can implement the same hardware if
> there was enough customer demand.
>
> 3. OS does not make a mainframe. Linux running on z16 doesn't make it
> mainframe Linux. There's nothing stopping Linux from taking advantage of
> every z16 hardware feature (e.g. 1,600 PCIe slots) but no one is willing to
> build the Linux software. IBM hasn't duplicated z/OS software features in
> Linux.
>
> 4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for
> z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can
> still run DB2 on z16 but large customers choose DB2 for z/OS.
>
> ASK YOURSELF: Other than design philosophy, name 1 fundamental difference
> between IBM z16, AMD Ryzen and the software.
>
> ASK YOURSELF: Since design philosophy is the only difference, name the
> philosophy that makes a mainframe.
>
> Despite the story's false claims for z/OS relevance, it is ignorance in the
> Linux community that makes IBM z/OS relevant. Specifically, it's the lack of
> design in Linux. Consider DB2 for Linux and DB2 for z/OS which are the same
> product both from IBM and available on an IBM z16. Linux people tell you they
> provide the same results, but they ignore the intrinsic capabilities of z/OS
> design. DB2 for Linux supports high availability and large databases but it
> requires knowledge of big data solutions, Linux clustering solutions and
> more. Add a computer to the cluster and you must replicate the master disk.
> Take a computer offline from the cluster, then it must re-sync or replicate
> the master disk. DB2 on z/OS does not experience these problems because of
> z/OS shared dasd and dasd mirroring.
>
> ASK YOURSELF: Name 1 brilliant feature design that originated directly from
> Linux or Unix. Please don't use features that originated from IBM (e.g.
> databases, SQL, HTML, Cloud and more).
>
> Brilliant feature design exposes very little. For instance, does anyone know
> the problems solved by z/OS shared dasd and dasd mirroring. Linux people on
> the other hand can easily name those problems solved if you mention
> clustering solutions and big data solutions. I've personally seen one sysplex
> split between 2 sites 40 KM apart using line of site satellite dishes for
> communication, yet z/OS app programmers were informed. In other words, IBM
> designs for the 21st century.
>
> ASK YOURSELF: Name 1 brilliant unnoticed Linux feature. Name several
> brilliant unnoticed z/OS features.
>
> The story claims Linux feature design is similar to z/OS feature design. For
> example, the story claims Unix filesystems provide the same functionality as
> z/OS datasets. A filesystem is the equivalent of one PDS/e (even in Linux).
> In fact, z/OS Unix filesystems were built from PDS/e functionality. A
> filesystem is a container file containing the files in a Unix filesystem. You
> may have a filesystem using 10 disks but that's not any different than a
> single z/OS PDS/e file with 10 full disk extents. Like PDS/e members, files
> in a filesystem are randomly placed in the filesystem.
>
> ASK YOURSELF: Name 1 fundamental difference between a PDS/e and a Unix
> filesystem.
>
> ASK YOURSELF: Name the z/OS Unix feature that sort of fixes the fundamental
> design flaw with Unix filesystems just described?
>
> I suspect most people won't think about each user having a unique filesystem
> using automount to make their filesystem available. Typical Unix uses one
> file system with all users having directories in the /user directory. The
> mediocre design philosophy extends past Linux and enters into the programmer
> mentality.
>
> ASK YOURSELF: Name 1 z/OS application programmer that uses bTree, big-O,
> clustering, big data and various other techniques required for Linux.
>
> ASK YOURSELF: Name 1 reason why Twitter could not have been easily written in
> Cobol on z/OS. Excluding the user interfaces (e.g. phone app, Windows app,
> web browser app, ...). I'm not saying I would be willing but it's doable
> without additional effort.
>
> As many complained, the article says z/OS requires hundreds to thousands to
> support it. Twitter went from 7,000 employees to 2,000. Since it did not fall
> apart, the real question: do Linux developers understand how to create a
> well-designed application? z/OS applications programmers are business line
> experts whereas Linux applications programmers are computer experts who
> create programs for the business line. Exactly what makes them a computer
> expert?
>
> The story falsely claims Cobol is an ancient language. Big data, clustering
> and more are hidden by z/OS. VSAM is simple and efficient to use in Cobol but
> Linux programmers must use databases for the same purpose.
>
> ASK YOURSELF: Other than programmer self esteem, why do business programmers
> need languages more complicated than Cobol?
>
> The story falsely claims z/OS needs xWindows & bitmapping. z/OS supports
> xWindows & bitmapping. The author doesn't understand that xWindows is not
> used for general access of a multi-user environment (servers) regardless of
> platform. MS Windows and Mac don't use xWindows. For Linux servers, the only
> people using xWindows from these machines are sysadmins. Android is the
> largest Linux distro but no platform (even z/OS) does not build xWindows
> programs because there are so many different phone sizes.
>
> ASK YOURSELF: Name 1 company that uses xWindows except for Linux desktops and
> Linux workstations.
>
> ASK YOURSELF: Name 1 company whose programmers use their IDE (development
> environment e.g. VSCode) from common servers.
>
> The story mentions IMS & CICS but forgets to mention the Unix & Linux
> equivalents that stemmed from IMS & CICS concepts. Surely people have heard
> of SAP, Peoplesoft, web servers and other such products.
>
> Our worlds are colliding. z/OS should be smashing Linux but Linux survives on
> people's desire to be computer experts instead of business line experts.
> Google management thinks it's cheaper to spend $4,000 for each of their
> 5,500,000 servers than $4,000,000 for each IBM z16 computer needed. You get
> what you pay for.
>
> ASK YOURSELF: Are people delusional when they call the mainframe a dinosaur
> when it's more advanced than the most advanced workstations and servers?
>
> What is the definition of mainframe?
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@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
