On Thu, 21 Aug 2025 20:45:09 -0400, Steve Thompson <ste...@wkyr.net> wrote:
>Just thinking about future of z/Arch systems given the amount of >bias I have found in AI for deciding if cloud is better or a z/xx >machine.... ROTFLOL! Is it bias or is it ignorance? The bias is not just by AI. In my opinion, AI bias is based on common perceptions. Be it truth or a lie. AI simply states what many people believe. Make no mistake, IBM sysplex is a PRIVATE CLOUD and does not need any cloud software! Every z/OS meets all the tenets of cloud computing. Is z/OS DB2 (without cloud software) a "cloud database" ? Absolutely, 30 years of DB2 Sysplex! You have a DB2 table and 3 z/OS sysplex. DB2 for this table is running on all 3 z/OS. Remote users can use standard database API (TCP) to connect and use the table. You can set limits on table size and change those limits. TCP can balance use among the 3 z/OS. This fully meets cloud requirements. More important, z/OS sysplex eliminates the need for cloud services within a cloud. E.g. you can run an IMS transaction and it will find a place to run. IBM z/OS Sysplex was a major contributor to the first "cloud" specification and people were ecstatic over the concepts. A few months later, reality set in and a lot was ripped out because Unix could not support those features. To save typing, I had a chat with Google Gemini about cloud, PostGRE and DB2. https://g.co/gemini/share/9da8b11325e9 PostGRE was correct although I found a few debatable points. When it came to Cloud or DB2, it often screwed the pooch. If you interpreted cloud comments from PostGRE perspective, the answers were mostly ok. For example, PostGRE won't be a cloud database without software such as SaaS. Also realize AI has major inconsistencies. For example, it mentions "on premise" databases aren't cloud but when I later asked about "private clouds" it tells you about "on premise" database being part of that cloud. In other words, always verify answers involving mainframes. Always know the right questions to ask. >would be quicker and faster to develop in COBOL, What expertise do Cobol programmers possess that all others lack? In my opinion, they are subject matter experts instead of computer experts. They don't get as sidetracked with the computer. This is a constant theme within the mainframe. Unix have system admins but the mainframe has sysprogs who are subject matter experts in security, DB2, CICS, z/OS, IMS, or ???. Is it faster to code? Cobol programmers aren't focused on NoSQl, PostGRE, security, ttree and a million other things. Useful data presentation is more important than making it pretty. I suspect they are faster because they aren't wasting their time. I believe they produce a better product because they ignore what is irrelevant. Clearly the mainframe got it all wrong and needs to modernize ASAP. The reality is companies can't find willing participants. >And for those that don't know, COBOL now allows some "hex" >operations. And it supports json and a certain amount of >methodization.... Cobol would be perfectly suited for an HLASM (not C) type of macro language. If it didn't have "hex", "json" or some other important functionality, it becomes trivial. Think how IBM built the TSO parser. That's not to say it could not be improved after 65 years but it has held up well. Imagine building a Cobol that isn't considered repugnant. >I know some find COBOL repugnant, You missed the memo. We're MODERNIZING the mainframe. Or is it we are recreating ourselves in the image of the Linux gods? Since they can't come up to our level, we must come down to their level. Unix developers find Cobol boring and overly wordy. They refuse to use the language. Frankly, I don't want to work with it because it presents no challenge. Anyone who can do Java, Python, C, Go or ??? can easily master Cobol in a few minutes. >options that have the compiler using the instructions available ROTFLOL! Purely from a compiler perspective, Cobol is more efficient than C. C is a function-based language and Cobol is a compile time machine language based language. In Cobol MOVE A TO B translates to a single MVC instruction that knows all the programmer provided details (e.g. length). C's memcpy(a,b,7) ignores the details provided by the programmer (e.g. length) and calls memcpy.S which is a generalized function that goes thru several instructions to move the data. Don't forget the C optimizer is not optimizing the assembler memcpy..S function. C optimizer plays a much larger role in optimizing than Cobol optimizer. >It could be made such that it is 64bit capable, it would >automatically use DCBEs allowing I/O buffers to be above the >line.... VSAM would be above... Are people complaining about this? This doesn't affect Cobol in CICS and I'm guessing same for IMS. Are people experiencing problems in ISPF or TSO? How about batch? Unless this is a problem, why bother? I'm not stating an opinion. Simply asking the questions that should be asked.
