The apar is meant to deal with those types of hacks, where someone has a list
of userids and then just try to logon to TSO by connecting and attempting to
logon to TSO. Without the apar/parm, the normal logon screen shows the person
IF the userid actually has a TSO profile.d
When the correct p
On 1/23/2020 9:32 AM, Peter Vander Woude wrote:
The apar is meant to deal with those types of hacks, where someone has a list
of userids and then just try to logon to TSO by connecting and attempting to
logon to TSO. Without the apar/parm, the normal logon screen shows the person
IF the useri
On 1/23/2020 9:32 AM, Peter Vander Woude wrote:
> The apar is meant to deal with those types of hacks, where someone has
> a list of userids and then just try to logon to TSO by connecting and
> attempting to logon to TSO. Without the apar/parm, the normal logon
> screen shows the person IF th
Hi,
you can also combine several techniques.
You could also set up a firewall rule that blocks someones ip, that has e.g.
more than 3 ip connects (create socket) within 3 minutes or so against the
telnet 3270 port, the port can be blocked for e.g. 60min. That will make ddos
even harder. All numb
To expand on this...
yes, we are just getting to the DR test:)
I have new XCF and CFRM datasets pointing to new plant id and serial number,
policy
but no new LOGR and WLM, using same as prod (on another machine)
defined a new policy in DR CFRM
We IPLd at the other site for DR and got the follow
It's not the PTF that creates the exposure; it's the autorevocation policy,
with or without the PTF.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Peter Vander Woude
Sent: Thursday, January
It sounds like your COUPLExx still points to your prod XCF and CFRM
datasets.
On Thu, Jan 23, 2020 at 1:40 PM Elaine Beal wrote:
> To expand on this...
> yes, we are just getting to the DR test:)
>
> I have new XCF and CFRM datasets pointing to new plant id and serial
> number, policy
> but no n
We have defined in our policy both the CF's normally in use during
Production and the CF that will be used in a DR. That way when the policy
is replicated to the DR site all the information required is already
present and we do not have to switch policies. In normal life a D CF
command shows one un
I am trying to understand where some jobs are coming from. When I look in
the log I see
$HASP100 JOB1 ON RDR1
Which I take that the JCL is coming thru RDR(1).
I can display RDR(1), but that doesn't help me. How is the JCL getting to
RDR(1)?
Is this use of the RDRCHAR to get the JCL processe
Unless we're picking up the wrong COUPLE member, the CFRM and XCF
are pointing to the DR datasets
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IB
I would assume that you're running z/OS on z/VM and that RDR1 is assigned to a
virtual card reader. If so, check the console log for the virtual machine to
see the incoming SPOOL files.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
Time is the hacker’s most precious resource, so make them spend a lot to get a
little.
Our “Haystak” system (midrange) solicits and requires both userid and password
and if authorisation fails then “logon failed” is the only response given.
The “user” is allowed several attempts to get it right
These recommendations are culled from the procedure we've used for 20 years.
-- With a new (empty) CFRM data set, you should not see any reference to the
production policy.
-- 'IN USE BY ANOTHER SYSPLEX' suggests that you are pointing to (a copy of)
the prod version, not the DR version.
--
13 matches
Mail list logo
