Sigh, yes this has been happing for quite a few years.  I first noticed it in 
2002.




Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, June 21st, 2023 at 11:01 AM, Farley, Peter 
<[email protected]> wrote:


> Unfortunately, the ignoring of low-end processor client needs is just a 
> reflection of the Armonk attitude and position that only high-margin business 
> is worth IBM's attention. No concern for growing smaller clients into larger 
> ones at all. I have never understood that attitude, as it seems to me to be 
> guaranteed to drive you into oblivion.
> 
> Decades ago I ran a VM/SP + VSE/SP shop (just me and one other half-systems, 
> half-applications programmer plus one just-applications programmer) for a 
> company running their accounting and word-processing storage processes on a 
> 1M-byte 4361 processor and multiple 8100 processors running DPPX and it 
> satisfied all their needs. After I left they abandoned IBM and went to an all 
> DEC mini-computer solution using packaged accounting software because IBM 
> totally ignored their growing needs.
> 
> Peter
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [email protected] On Behalf Of 
> Brian Westerman
> 
> Sent: Wednesday, June 21, 2023 12:46 AM
> To: [email protected]
> Subject: Re: z/OSMF
> 
> After a couple years of use, I feel I'm pretty safe saying that, to me, 
> z/OSMF appears to be a poorly designed and very badly programmed product. 
> Most vendors would have ditched the product and stopped promoting it by now, 
> but IBM probably has grand "plans" that won't really come into fruition until 
> sometime around 2030 for z/OSMF.
> 
> As you all know, the z/OSMF product is the ONLY way to install z/OS, (without 
> using COS), and the product doesn't even run in a usable way on their 
> smallest, (but still supported and sold) processors. So some poor site that 
> buys into a z/15 T02 or z/16 A01 with a single CPU can barely even get the 
> product up let alone have more than one user, and even that user (the systems 
> programmer doing the install) has abysmal response time.
> 
> I have pointed the problem out to IBM (multiple times), and have gone through 
> the entire process of "proving" the issue(s) several times showing the issues 
> in detail, only to be pointed to a manual that states that you "should" have 
> a minimum of a 400MIP processor complex to use z/OSMF, (because that's what 
> they use(d) for testing).
> 
> The next problem I already see happening is that they are throwing a bunch of 
> new "features" and add-ons into it, and some of them would be great products 
> on their own, but are being hobbled by the (IMO) poorly designed product.
> 
> I still can't believe that the same company that proudly states that we can 
> still run code developed in the 1960's on the z/16 seems to care less about 
> the fact that their installation vehicle doesn't support their own small end 
> processors that you need the z/OSMF installation vehicle to install the OS 
> with. Any other vendor would be laughed out of town.
> 
> One of the sites we support (a z13s, no zIIP, single CPU) can't even install 
> the updates from Broadcom via the "normal" method because using the Java 
> interface times out before authentication. The solution from Broadcom (until 
> IBM can fix their issue) is that they build a special delivery package for 
> the site to use. That's just sad, and what was IBM's response after 7 months 
> of "looking into" the problem? "The site could use a faster processor or the 
> vendor should increase the authentication time limit." Neither of those is a 
> possible solution in this case.
> 
> Very sad and poorly played on IBM's part.
> --
> 
> 
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
> 
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to