"as usual", Crayford falsely believes my not responding means that I'm admitting I'm wrong. To the contrary, he get's so much wrong that it's not worth the effort to respond. Sadly, this has emboldened him to be rude and offensive. My not responding simply means I don't see any value to me once the OPs problem has been solved. It's a little late but here's my response about his false claims about IBM exits and MetalC.
> On Fri, 25 Aug 2023 11:04:49 +0800, David Crayford <dcrayf...@gmail.com> > wrote: >> On 25/8/2023 2:05 am, Jon Perryman wrote: >> For instance, you don't have exit points in the kernel that give you access >> to the system. >Hooking the kernel using ftrace is trivial. There are libraries for it. "as usual" Crayton ignores that IBM exits are well defined, well documented and regularly used by ordinary asm programmers. For example, userid/password for z/OS database (DB2, Oracle, Adabase, ...) access are not specified through the program interface. For Linux databases, userid/password is always specified in the program interface (usually in variables). They chose not to secure the userid/password behind an exit point. NASA recently had userids and passwords openly available through Github. Github is well known by hackers as a place to get userids with passwords. Rarely do you find userid / password in z/OS source code when there is a viable alternative? You don't find userids/passwords on CBTTAPE. >> Unix currently doesn't need SPC because it doesn't have built-in robust >> features like z/OS. >What? Linux doesn't need Systems Programming C because you use the same >compiler for kernel modules and userspace programs. z/OS is the odd one >in that language environment isn't suitable for systems programming. So >we need Metal/C which superceeded SPC years ago. "as usual", Crayford doesn't understand MetalC vs C. For instance, z/OS cannot tolerate dynamic calls in many situations thus ruling out the use of IBM Language Environment and the need for MetalC. These are important and robust z/OS features that don't exist in Linux. Linux on the other hand, has very few kernel restrictions. >When you consider that the internet runs mostly on Linux servers and >that Linux is also used as an embedded OS for routers and other devices >I would suggest it's reasonably robust. "as usual", Crayford doesn't understand the word robust. Free software maintained by random people on cheap hardware used on more hardware does NOT make it robust. It just makes it affordable instead of better. > Where I work we tend to have to > IPL our z/OS LPARs a lot more often then booting on Linux VMs. "as usual", Crayford ignores that he works for a vendor where frequent z/OS IPL's are standard practice. z/OS vendors do dangerous and volatile things making IPLs standard practice. Stable environments don't require frequent IPLs. Linux vendors very rarely do anything that risks damage to the kernel. It's painfully obvious in database userid/password is part of the application program instead of the kernel. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
