What was the first X/OPEN UNIX certification for MVS? The first The Unix Group
certification?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send ema
Scary stuff being asked about. Certainly there is nothing that is supported
(and that likely includes whatever TSOLIB does and whatever is on the CBT
tape), and nothing that won't put your customer at risk (including possibly
introducing system integrity problems).
TASKLIB on ATTACH is the only
MVS/SP 5.1 in April 1994 announcement letter stated X/OPEN certification
was being applied for, my memory is that it was obtained by GA date.
MVS/SP 4.3 which introduced Open Edition had NIST certification and some
POSIX standards implemented but not all. Neither were actually complete
enough to p
Hi Pete,
You said: "...Certainly there is nothing that is supported (and that
likely includes whatever TSOLIB does ..."
It seems as if you're saying that TSOLIB (distributed with z/OS) is
potentially not supported.
Did I misunderstand?
Please explain.
Thanks and regards,
David
On 2023-07-19 0
On 7/19/23 7:34 AM, Attila Fogarasi wrote:
MVS/SP 5.1 in April 1994 announcement letter stated X/OPEN
certification was being applied for, my memory is that it was
obtained by GA date. MVS/SP 4.3 which introduced Open Edition had
NIST certification and some POSIX standards implemented but not a
Billions is being spent on developing quantum computing. I doubt it’s because
they’ve got money to waste.
https://newsroom.ibm.com/2023-05-21-IBM-Launches-100-Million-Partnership-with-Global-Universities-to-Develop-Novel-Technologies-Towards-a-100,000-Qubit-Quantum-Centric-Supercomputer
https://
Yes, it is, because quantum computing enables solving classes of problems
that current machines can't. But it is a very poor fit for the overwhelming
majority of computing tasks today.
Put another way: a z/Series vector facility isn't going to do much good
computing payroll. Neither is a quantum s
I feel like I’m arguing with the same people who thought the mainframe was
going to be obsolete by Y2K. Very poor fit NOW. In 10 years, perhaps not.
Sent from Yahoo Mail for iPhone
On Wednesday, July 19, 2023, 9:28 AM, Jay Maynard wrote:
Yes, it is, because quantum computing enables solving
What a BS 'survey'.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, July 18, 2023 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Will z/OS be obsolete in 5 years?
CAUTION: This email originated from outside of the Texas Comptroller's email
Has anyone considered that z/OS is knee-capped so it only runs on GPs? Are we
suggesting that people will buy GPs at 10 times the price rather than IFLs or
zIIPs just so they can run z/OS under Linux?
--
For IBM-MAIN subscribe
Peter,
I'm a little over my head on this, but isn't TSOLIB in TSO implemented with
TASKLIB on ATTACH?
--
Tom Marchant
On Wed, 19 Jul 2023 12:04:12 +, Peter Relson wrote:
>Scary stuff being asked about. Certainly there is nothing that is supported
>(and that likely includes whatever TSOL
On Wed, 19 Jul 2023 12:04:12 + Peter Relson wrote:
:>Scary stuff being asked about. Certainly there is nothing that is supported
(and that likely includes whatever TSOLIB does and whatever is on the CBT
tape), and nothing that won't put your customer at risk (including possibly
introducing
z\OS containers being crucial? Absolutely. Some z\OS, DB/2, etc. upgrades
require applications, subsystems, LPARs, Sysplexes, etc. At a certain stage
before proceeding to the next stage. Hopefully these requirements can be
limited to one or a small subset of containers.
On Wed, Jul 19, 2023, 00
Let me try to respond to some of this; keeping in mind that I know nothing of
the business decisions here, and am speaking for myself, not IBM.
1. As far as I’m aware, IBM is still very separate from RedHat. Maybe
things are different at the board level, but at my level, there is an
incred
Thanks! That helps me understand things much better. I looked through
the survey and the questions were way over my head.
On 7/19/2023 8:41 AM, Kevin Mckenzie wrote:
Let me try to respond to some of this; keeping in mind that I know nothing of
the business decisions here, and am speaking for
On Wed, 19 Jul 2023 00:47:04 +, Jon Perryman wrote:
>IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux).
You didn't bother to cite any reference, so I am highly skeptical. I looked for
this "announcement" and didn't find it.
Linux is licensed under the GPL. It doe
Kevin’s note is a great summary. FWIW, years ago when I worked for IBM (early
2000’s) we met with RedHat. During the introductions someone from IBM referred
to them as an Open Source company. One of the RedHat execs corrected them and
said, “We are a commercial software company that uses open
On Wed, 19 Jul 2023 15:41:44 +, Kevin Mckenzie wrote:
> 2. RedHat is not moving to closed source. RedHat couldn't make RHEL closed
> source if they wanted to. RedHat doesn't own the copyright to something like
> 90% of RHEL, and whatever copyright they do own, they've assigned to the
>
Considering that VSE still exists, the answer would be no.
How long ago was it that IBM tried to cancel VSE, but relented due to customer
demand?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, July 18, 2023 7:47 PM
To: IBM-MAIN@LISTSERV.
Yes, TSOLIB is part of TSO/E and is correctly implemented by ATTACHing
subsequent commands with a TASKLIB. The TSO/E developer who
was designing TSOLIB wanted to do an incorrect, dangerous thing like STEPLIB
did, so that he could provide equivalent function to STEPLIB.
Peter Relson, Karl Schmi
Hi Jim,
Why is "STEPLIB" dangerous?
Please explain in detail.
Thanks and regards,
David
On 2023-07-19 13:49, Jim Mulder wrote:
Yes, TSOLIB is part of TSO/E and is correctly implemented by ATTACHing
subsequent commands with a TASKLIB. The TSO/E developer who
was designing TSOLIB wanted to
On 7/19/2023 11:32 AM, David Spiegel wrote:
Hi Jim,
Why is "STEPLIB" dangerous?
Please explain in detail.
Thanks and regards,
David
He is not referring to the //STEPLIB DD statement, he is referring to
the old STEPLIB command.
There might actually be more than one version of STEPLIB floatin
> You didn't bother to cite any reference, so I am highly skeptical.
> I looked for this "announcement" and didn't find it.
How could you not find official references when so many people are infuriated.
For instance, see
https://www.redhat.com/en/blog/red-hats-commitment-open-source-response
On Wed, 19 Jul 2023 17:49:08 +, Jim Mulder wrote:
> Yes, TSOLIB is part of TSO/E and is correctly implemented by ATTACHing
> subsequent commands with a TASKLIB.
>
TASKLIB should not depend on TSO/E and should satisfy the OP's need.
Are TSOLIB and TASKLIB inherited alike by grandchild tasks?
Or please provide references to docs, articles etc. that could explain it to
the rest of us.
Thanks
An ignorant STEPLIB user
mkk
On Wed, 19 Jul 2023 14:32:59 -0400, David Spiegel
wrote:
>Hi Jim,
>Why is "STEPLIB" dangerous?
>Please explain in detail.
>
>Thanks and regards,
>David
>
>
>On 2023-
On Tue, Jul 18, 2023 at 06:49:26PM +0300, Binyamin Dissen wrote:
> I am trying to do the equivalent of TSOLIB for BATCH, i.e., dynamically adding
> loadlibs. I do not have spare parent tasks that I can hang a JLB DCB.
> Does reaching TCBJSTCB stop the search of the JLBs?
from MVS3.8 source of IEA
On Wed, 19 Jul 2023 12:15:10 -0700, Michael Stein wrote:
>
>> Does reaching TCBJSTCB stop the search of the JLBs?
>
>from MVS3.8 source of IEAVLK01
>
Are comments in the source of 3.8 the best available documentation?
>*...
>* A. THE CONTENTS DIRECTORY ENTRIES (CDES) FOR LOA
On Wed, Jul 19, 2023 at 02:38:44PM -0500, Paul Gilmartin wrote:
> Are comments in the source of 3.8 the best available documentation?
They might be out of date, but requirements of compatiblity and the cost
to IBM of changes make them somewhat relevant. They're easily accessible
the other choice
On Wed, 19 Jul 2023 13:58:15 -0500, Paul Gilmartin wrote:
>On Wed, 19 Jul 2023 17:49:08 +, Jim Mulder wrote:
>
>> Yes, TSOLIB is part of TSO/E and is correctly implemented by ATTACHing
>> subsequent commands with a TASKLIB.
>>
>TASKLIB should not depend on TSO/E
It doesn't. It is used TSO/
Hi Paul,
You said: "...What is the motivation for using CBT 452 STEPLIB, ever?
Should CBT
withdraw 452 from circulation? ..."
The CBT Tape is useful for programming techniques, even if the code
isn't actually used.
No, it should not be withdrawn.
Are you trying to censor it?
Regards,
David
> Container orchestration exists because some of those containers (or the
> hosts they may run on) may have a problem.
Containers is just one of multiple solutions to a problem that most people
don't grasp. Ask yourself what problems does Kubernetes containers resolve.
The problem exists on
On Wed, 19 Jul 2023 18:54:04 +, Jon Perryman wrote:
>
>> You didn't bother to cite any reference, so I am highly skeptical.
>> I looked for this "announcement" and didn't find it.
>
>
>How could you not find official references when so many people are infuriated.
How dare I fail to read ev
> What a BS 'survey'
What is it you consider to be BS? Are you saying that the hardware numbers are
wrong? An IBM z16 Max200 fully loaded has 256 cores where 200 cores are
available to the customer, 40TB ram and 1,536 (4 CPC draws with 12 fanout
adapters each containing 2 ports connecting t
Thanks to Jim Mulder and Tom Marchant for correcting my post.
I was perhaps thinking of the STEPLIB "tool" when I mentioned TSOLIB.
As Jim pointed out, TSOLIB does utilize the ATTACH with TASKLIB approach.
Peter Relson
z/OS Core Technology Design
---
> An IBM z16 Max200 fully loaded has 256 cores where 200 cores
> are available to the customer, 40TB ram and 1,536 (4 CPC draws
> with 12 fanout adapters each containing 2 ports connecting to
> a 16 PCIe slot I/O drawer)?
That 1,536 doesn't sound right. Max I/O drawers on a z16 A01 is 12 (see
p
>>How could you not find official references when so many people are
>>infuriated.
> How dare I fail to read everything that you do!
> If this was a Linux list perhaps your arrogant response would be warranted.
I don't look at much Linux stuff these days but IBM RHEL closed source is
poppin
> That 1,536 doesn't sound right. Max I/O drawers on a z16 A01 is 12 (see
> page 20 in the pdf you linked). So 12 x 16 = 192 cards. And if all of
> them are 2 port cards, max ports is 384. And that still leaves CEC
> slots for 36 dual port ICA cards to connect that huge mass.
On page 22,
I just ran a test config for a full z16 A01 and it had the limits I
mentioned.
I am impressed! For the past few years upgrades have generally gone
from 2 cables to 4 cables which can be a surprise for the facilities
folks. I can't even comprehend 8 x 32 = 256 14 foot cables. A couple
of la
38 matches
Mail list logo
