I noticed that AUTOMAN from expans in now free anf is on file 627 of the
cbttape. I used generalized MPF exit file 708 to convert a client from a
commercial product to MPF based automation and it worked very well.
ITschak
On Tue, Jan 14, 2020 at 9:33 AM Ken Bloom wrote:
> Hi jake
>
> What
Hi jake
What are you trying to do? There are products out there that can “screen
scrape” consoles and send alerts based on content.
Ken
Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com
> On Jan 13, 2020, at 11:50 PM,
remember no real CKD devices have been made for decades ... all being
simulated on industry standard fixed-block ... need a fair amount
electronics and processing between the emulated CKD layer and the real
fixed-block hardware (whether fixed-block spinning disks or fixed-block
SSD).
a lot of the
Hello,
Is there any CBTTAPE file which has the solution to trap message in console
and send email ?
Or else if there is any other method you are following please let me know.
Regards
Jake
--
For IBM-MAIN subscribe / signoff /
On 1/13/2020 8:48 AM, Barbara Nitz wrote:
I am attempting to install zSecure. I get
GIM58901E ** APPLY PROCESSING FAILED FOR SYSMOD HCKR240. SYSMOD HCKR240 WOULD
HAVE CAUSED A CHANGE TO THE MVST ZONE THAT CAN NOT BE PROCESSED
COMPLETELY BY PRIOR LEVELS OF SMP/E. USE
Is it V6.3 that introduces the capability to generate 64-bit executables. Or is
that already available in V6.2?
If V6.3 introduces the ability to generate 64-bit executables I would argue
(even as a COBOL developer) for a transition period where V6.3 was "available
but not standard", with an
Caution and backups and fallback strategies are always good, but I don't
think there is much relationship between *running* a COBOL version X program
and having the *compiler* version Y installed. I believe all of the runtime
is part of LE, not the compiler, and compatibility from VS COBOL II (if
Alas, hogst...@us.ibm.com is my IBM address. I generally use my personal
account for mailing lists and open source involvement as that transcends my
employer. Sorry if that was confusing; I didn’t mean it to be.
Matt Hogstrom
m...@hogstrom.org
“It may be cognitive, but, it ain’t intuitive."
I would certainly have 6.2 and 6.3 available for a few months of
testing, for sure. Probably a 3 way compare with 5.2 so you can be
certain of a useable program if you limit to 5.2 / 6.3.
On Mon, Jan 13, 2020 at 5:33 PM Frank Swarbrick
wrote:
>
> I was wondering what "methodologies" shops have
I was wondering what "methodologies" shops have for migrating to a new
"release" within the same "version" of a compiler. Specifically, we currently
have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. Our systems group
asked if we just wanted to "replace" 6.2 with 6.3. I'm a bit wary
Nope.
//SY010AA JOB (SYS00),'MARK JACOBS',MSGLEVEL=(1,1),
// MSGCLASS=X,CLASS=A,NOTIFY=SY010A
//STEP1 EXEC PGM=IFASMFDL,REGION=512M
//SYSPRINT DD SYSOUT=A
//SYSINDD *
LSNAME(IFASMF.DEVL52.DEFAULT,OPTIONS(DELETE))
DATE(2019364,2020012)
/*
Sent from ProtonMail, Swiss-based encrypted
On Sun, 12 Jan 2020 09:27:52 +, Jeremy Nicoll
wrote:
>On Sun, 12 Jan 2020, at 04:24, Phil Smith III wrote:
>> From a book:
>>
>> "... located a Trojan virus during a routine mainframe defrag."
>
>I dunno about the first bit, but "routine mainframe defrag" is fine.
>DFDSS has a DEFRAG verb.
Look at message, you probably have an OUTDD specified in the JCL.
Regards,
Leo
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mark Jacobs
Sent: Monday, January 13, 2020 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LOGR Offload Dataset deletion problem
We've been
IBM supported TCP/IP for the same reason that it earlier supported the ISO OSI
and ITU (nee C.C.I.T.T.) recommendations; that where the market, especially the
US Federal Government market, seemed to be going.
> The most concerning security problems on the mainframe are not caused by
> TCP/IP
There have been vulnerabilities in some of the protocols. That said, the
community has been fairly good about fixing them.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
zMan
Sent: Monday,
I remember that IBM supported X.25, APPN corrected a lot of the issues of SNA,
and IMHO the industry would have been better off going to the ITU (nee
C.C.I.T.T.) X.foo recommendations.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
I disagree. VTAM *was* the center, and remained so with the advent of APPN.
What changed is that VTAM no longer required centralized administration. ISO
OSI and TCP/IP became available for MVS much later.
However, I do agree that it was absolutely necessary for IBM to support TCP/IP
once it
We've been unable to delete some offload datasets from one of our logstreams,
We're getting these messages in IFASMFDL. Our daily archive process is dumping
the data, but isn't able to the delete the now longer necessary offload
datasets. The same messages are being issued in the archive
I think you are absolutely correct There is a reason why VTAM adopted APPN,
because it was impossible for VTAM to look and behave as if it were the entire
center for every communications need. TCP/IP was inevitable given its large
penetration into the home consumer market and the cost for
Of course!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Knutson, Samuel
Sent: Monday, January 13, 2020 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is a mainframe?
In my opinion IBM helped to save the mainframe
On 1/13/20 9:50 AM, zMan wrote:
Eh? That's silly. There's nothing inherent about TCP/IP that makes
things hackable. Any connectivity creates potential exposures, whether
it's TCP/IP, SNA, bisync...
I do think there is something to be said about the size of the potential
pool of attackers via
On Sun, 12 Jan 2020 19:41:07 -0500, Matt Hogstrom wrote:
>That was my thinking too Paul. We should be able to mask a lot of this in
>software and not have to do a lot of unnecessary “busy” work.
>
>Part of the challenge is to identify some behaviors that could be deprecated.
>We have a lot
On Mon, 13 Jan 2020 07:47:58 -0600, Barbara Nitz wrote:
>I am attempting to install zSecure. I get
>
>GIM58901E ** APPLY PROCESSING FAILED FOR SYSMOD HCKR240. SYSMOD HCKR240 WOULD
> HAVE CAUSED A CHANGE TO THE MVST ZONE THAT CAN NOT BE PROCESSED
> COMPLETELY BY PRIOR
tcpip stack on z is just a proof that IBM recognized that the 70's passed.
some of you may remember that while the industry standard was x.25, IBM
decided that if you want to connect to a mainframe, you need to play IBM's
game of SNA. If IBM was rolling the market, these days, we might be still
Eh? That's silly. There's nothing inherent about TCP/IP that makes things
hackable. Any connectivity creates potential exposures, whether it's
TCP/IP, SNA, bisync...
On Sat, Jan 11, 2020 at 3:53 PM z/OS scheduler wrote:
> Welll, in my opinion the mainframe died when IBM allowed tcpip on their
>
In my opinion IBM helped to save the mainframe when they included a built-in
highly performant TCP/IP stack in the operating system.Making the mainframe
a more mainstream hardware server and more importantly a mainstream software
server that communications, API implementations and
On Sun, 12 Jan 2020 13:59:21 -0500, Matt Hogstrom wrote:
>it occurred to me that for the most part a lot of the work in defragging,
>worrying about disk geometry and other issues are really not / less of
>an issue with cache and SSD technologies.
No, as long as z/OS still allocates data set
I am attempting to install zSecure. I get
GIM58901E ** APPLY PROCESSING FAILED FOR SYSMOD HCKR240. SYSMOD HCKR240 WOULD
HAVE CAUSED A CHANGE TO THE MVST ZONE THAT CAN NOT BE PROCESSED
COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE UPGRADE COMMAND TO
As of (IIRC) z/OS 1.12 there is a user enabled dfsms function CA_RECLAIM that
allows the use of orphaned CA's w/o need for a "offline" reorg.
Applies to VSAM KSDS. Not to Linear VSAM
HTH
>-Original Message-
>From: Jeremy Nicoll
>Sent: Sunday, January 12, 2020 1:28 AM
>
>I dunno about
29 matches
Mail list logo
