Now we would like to invite you to attend our 2021 survey. Here is the
link:https://www.surveygizmo.com/s3/6163579/IBM-z-OS-Management-Facility-2021-Survey.
Your feedback is greatly appreciated.
--
For IBM-MAIN subscribe /
On 5/02/2021 1:32 am, Charles Mills wrote:
TCP/IP certainly makes use of lots of UNIX services.
Yes, and it goes both ways. I'm working a project right now with one of
the original IBM OMVS developers and he told me that the BPX callable
services wrap Comms Server APIs and then the LE C/C++
On Thu, 4 Feb 2021 17:10:55 -0800, Charles Mills wrote:
>Are there not occasional fleeting references here and there to "the Pascal
>TCP stack"?
>
That had the notorious GIVESOCKET/TAKESOCKET, needed because prior
to OMVS, descriptor inheritance was unheard of.
Orthogonal concepts. I don't
SAP Crystal Reports? Next release Crystal Ball Reports.
It's Friday here...
On Fri, Feb 5, 2021 at 12:47 PM Wayne Bickerdike wrote:
> Could end up with too many false alarms.
>
> I recall many years ago we ran a CA-Datacom MUF with a 64M region. Perhaps
> once a month we'd get an S80A abend.
>
VMCF and TNF may still be on your systems for the few remnants depending on the
PASCAL stack API. It was ported out of VM and did not perform well either.
Another factor which slowed the adoption of TCP/IP in the z/OS (them MVS world)
was the IBM Communications group resistance. They had all
Could end up with too many false alarms.
I recall many years ago we ran a CA-Datacom MUF with a 64M region. Perhaps
once a month we'd get an S80A abend.
I had a chat with CA and they said give it more memory. Our sysprog was
reluctant and kept monitoring storage use and claimed that it was
Are there not occasional fleeting references here and there to "the Pascal
TCP stack"?
The first I personally wrote any z/OS socket code was around 2010. (I had an
employee who wrote socket code for Z in the 90's but I am not the least bit
intimate any more with the details. I seem to recall that
Looks like OS/390 V2R4 (Sept 1997?) contained "A new TCP/IP stack, for
applications using OS/390 UNIX System Services (formerly called OpenEdition)
sockets".
Prior to that was TCP/IP Version 3 Release 2, which I believe was based on a
port of TCP/IP for VM (and written in Pascal!). Or
I installed the U of Wisconsin DARPA project TCP/IP VM/CMS stack around
1986-ish, and (as I remember) it was indeed ported to MVS. IBM also rolled
out their own VM/CMS stack version, and we had quite a jolly time converting.
UW code had enhancements that IBM didn't have yet, and vice versa.
I believe the Power Off function prevents all future failues.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Thursday, February 4, 2021 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any way to
Thanks. I think I forgot about the OVERLAY statement and then didn't find it
during this RTFM. Looks like I can get what I want.
Now, I'm par way through this work. With a partial SORT and a partial Rexx ...
:)
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of
On Feb 4, 2021, at 4:24 PM, Mike Schwab wrote:
>
> z/OS FTP required a RACF OMVS flag in 2001 when I started submitting
> dumps to IBM.
>
I have a vague recollection that in the early 1990s IBM provided a TCP/IP stack
on MVS that was ported from VM, but sometime in the OS/390 era it was
AFAIR there is one of "Smart DFSORT Tricks" which address the problem.
The book is old (20+ years), but you can find it:
https://www.ibm.com/support/pages/system/files/inline-files/$FILE/sorttrck.pdf
Look for IDCAMS and "Delete all members of a PDS"
This is similar example.
(shameless plug:
I have a copy of that on IBM letterhead hidden away somewhere
Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Thursday, February 4,
z/OS FTP required a RACF OMVS flag in 2001 when I started submitting
dumps to IBM.
On Thu, Feb 4, 2021 at 1:37 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Thu, 4 Feb 2021 09:32:58 -0800, Charles Mills wrote:
> >
> >I believe TCP/IP and several of its
That made me smile - OS/VU I had forgotten about that one
Lizette
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gibney, Dave
Sent: Thursday, February 4, 2021 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any way to anticipate failure messages
Yup - I'd rather anticipate and stop the failure than anticipate the messages
from the failure
Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette
http://www.weathergraphics.com/tim/ibm.htm
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Lizette Koehler
> Sent: Thursday, February 04, 2021 1:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any way to anticipate failure messages
>
> So the problem is to
So the problem is to know what events or message will occur and then prevent
them from happening.
The Omnipresence SysTem
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Thursday, February 4, 2021 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject:
The binder will simply discard the "private code" (unnamed) CSECT (section), if
it has text.
It never gets incorporated into the module being bound, so it should have no
effect on it.
Binder has behaved like this since near the beginning (early 90's, around when
PM3 format was introduced).
The
Given a list of Datasets with varying length dsnames:
ZOS21D.ASM.AASMMAC1
ZOS21D.ASM.AASMMAC2
ZOS21D.ASM.AASMMOD1
ZOS21D.ASM.AASMMOD2
ZOS21D.ASM.AASMPUT2
ZOS21D.ASM.AASMSAM1
ZOS21D.ASM.AASMSAM2
ZOS21D.CBC.ACCNCMP
ZOS21D.CBC.ACCNSR1
ZOS21D.CBC.ACLBDLL
ZOS21D.CBC.ACLBDLL2
I easily get:
On Thu, 4 Feb 2021 21:59:22 +0100, Radoslaw Skorupka wrote:
>W dniu 04.02.2021 o 21:40, Lizette Koehler pisze:
>>
>> As always something happens and management reacts
>>
>> We are looking to see if there is any tool that could trap any message or
>> event on Mainframe and generate a daily report
W dniu 04.02.2021 o 21:40, Lizette Koehler pisze:
List -
As always something happens and management reacts
We are looking to see if there is any tool that could trap any message or
event on Mainframe and generate a daily report for the SYSPROGs to review to
ensure zero failures
Lizette,
Have you heard of Tivoli Enterprise Portal?
> On February 4, 2021 3:40 PM Lizette Koehler wrote:
>
>
> List -
>
>
>
> As always something happens and management reacts
>
>
>
> We are looking to see if there is any tool that could trap any message or
> event on Mainframe and
Didn't the HAL 9000 have predictive failure analysis? Of course that was in
2001 :)
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Thursday, February 4, 2021 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any way to anticipate failure messages
List -
As always something happens and management reacts
We are looking to see if there is any tool that could trap any message or
event on Mainframe and generate a daily report for the SYSPROGs to review to
ensure zero failures
Lizette
tcp/ip on MVS far antedates OMVS...
TCP/IP (FAL) was around in the MVS/ESA days (and OS/390 I know for sure).
Joe
On Thu, Feb 4, 2021 at 1:37 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Thu, 4 Feb 2021 09:32:58 -0800, Charles Mills wrote:
> >
> >I
Flushing the pipeline is a trade-off between complexity and performance. It's
certainly possible to design a pipeline that can handle key changes without
flushing; whether it's worth the real estate is something that your engineers
have to decides.
--
Shmuel (Seymour J.) Metz
On Thu, 4 Feb 2021 09:32:58 -0800, Charles Mills wrote:
>
>I believe TCP/IP and several of its "children" such as FTP server run as UNIX
>daemons.
>
Some such children are recent adoptees. I believe FTP on MVS far antedates
OMVS. (But was that an ISV offering? IIRC an Intel Fastpath(?) that
On Thu, 4 Feb 2021 at 12:25, Joe DeChirico
wrote:
> Is there any information available on the relationship between TCP/IP and
> OMVS?
I'm not sure if I (or others) fully understand your question. But one
way of looking at it is to say that any TCP/IP implementation is
really just a Physical
The current TCP/IP is a Unnix application, which means that it must be dubbed.
A Unix Zystem Services application can use the legacy MVS services.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
Paul G wrote:
Consider possible consequences when a program object is relinked of:
XCSECT
DCA(B)
CSECT
BDCH'0'
END
Assemble it; study the Relocation Directory; and weep.
The assembly shows one RLD entry. I did not try to "study" it.
-- When
What specifically?
I believe TCP/IP and several of its "children" such as FTP server run as UNIX
daemons.
There is not so much of a classic MVS versus OMVS dichotomy as one might
imagine. USS is a fundamental part of z/OS. It's not so much this "thing" that
coexists with MVS as a set of
I dimly recall from decades ago a recommendation to run CICS in key 7. IIRC,
it had something to do with aligning a buffer on a page boundary. Long
obsolete advice, I'm sure.
==
Peter Relson wrote:
>.
>
>
>May I ask why you
Hi
Is there any information available on the relationship between TCP/IP and OMVS?
Thanks
Joe DeChirico
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the
I think I found the problem... In my ADCD system the are two versions of
DB2 installed, but only V12 is running. The rexx looks at the linklist to
see if SDSNLOAD is there, and if not, Find it in APF. SDSNLOAD of version
11 is first in APF... I'll remove the first one and try again.
*| **Itschak
-805 means the version of dsnrexx that you are running doesn't match what
is in DB2. either wrong DB2/DSNREXX or DSNREXX wan't installed.
Mike
On Thu, Feb 4, 2021 at 8:47 AM Binyamin Dissen
wrote:
> On Thu, 4 Feb 2021 16:17:59 +0200 ITschak Mugzach
> wrote:
>
> :>the DB2-L group seems to be
I got it thanks
> On Feb 4, 2021, at 9:34 AM, Peter Relson wrote:
>
> RBINTCOD is a 2-byte field. The fact that SVC's are 0-255 is unimportant
> to that fact.
> You should compare the 2-byte field.
>
> I don't know why, in general, you would require that the SVC-issuing RB be
> a PRB
On Thu, 4 Feb 2021 16:17:59 +0200 ITschak Mugzach wrote:
:>the DB2-L group seems to be inactive, so i am asking here...
:>I have a rexx program that calls stored procedures and gets -805. the
:>complete details below. I followed the instructions in the manual and ran
:>the SQLs recommended but
RBINTCOD is a 2-byte field. The fact that SVC's are 0-255 is unimportant
to that fact.
You should compare the 2-byte field.
I don't know why, in general, you would require that the SVC-issuing RB be
a PRB (checking RBFTP for b'000').
If this is a type 2-3-4 SVC, then information about the
the DB2-L group seems to be inactive, so i am asking here...
I have a rexx program that calls stored procedures and gets -805. the
complete details below. I followed the instructions in the manual and ran
the SQLs recommended but haven't found the one with the correlation-id
printed. I also ran
41 matches
Mail list logo
