Ok. I must have missed it somewhere that the OP is perhaps using ADCD, but he
said he is using VM to access his JES2? So, can you run ADCD as a guest under
VM?
The OP said that he is running in Dallas. It is my understanding (having never
worked on any of their systems) that Dallas provides
Elardus,
Just curious, at what z/OS level are you? I'm asking because that APAR is
somewhat old, but I'm sure that local fix also mentioned by Bob should help
you out until you can fix the init deck.
Are other LPARs using the same JES2? If so, you could try out the local fix
or purge
Barbara Nitz wrote:
Welcome to the wonderful world of ADCD systems! (Which is what I understand
Dallas is using.) ADCD systems come with a teeny tiny spool, and most parms in
the init deck are set so low that it just functions on a lowly loaded system.
After the second or third real 100% spool
W dniu 2015-01-04 o 08:08, ibmmain pisze:
Hi all
Could you explain what is the diffenet between volcount and Dynamic Volume
Count ?
I am very confused how to use volcount and Dynamic Volume Count
DVC is DYNAMIC. That means you can change it for existing datasets.
Volcount is static. It
There is one more important difference: this is an (the first) occasion where
Dataclass attributes are used during the life of a dataset. This means that
altering the DVC attributes of a dataclass will have effect on already existing
datasets. Before, the Dataclass attributes were only applied
What is the exact format of the LIST64 parameter. It is not clear if the
counts and lengths include a slack four bytes (like the SUMLIST64
parameter).
SUMLIST64 does have 4 reserved bytes after the field containing the
length. LIST64 does not. The description in the book really is correct in
On Sun, January 4, 2015 17:56, Paul Gilmartin wrote:
(why?) and must reconnect. Is there any way to get directly back to
IKJ56700A?
PA1. You won't get back to IKJ56700A but you can enter LOGON userid
there without a reconnect.
Regards,
Boris
On Sat, 3 Jan 2015 01:31:14 -0500, Jim Mulder d10j...@us.ibm.com wrote:
Was it the task's DU-AL that got full? Or was it actually
the address space's PASN-AL?
I don't know for sure, but I would guess that it's the DU-AL, we have a call
scheduled to discuss it this week.
If it was
Paul Gilmartin wrote:
My logon PROC is set up to bypass any solicitor and put me directly at:
IKJ56700A ENTER USERID -
userif
Review your solicitor to eliminate this pain.
Is there any way to get directly back to IKJ56700A?
Or even better, to change the Userid and continue with the
RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says
your attempt is invalid
Ah, but it does, right? Is that not the whole point of the topic?
If I say LOGIN FOO I can tell right away that FOO is an invalid userid (from
the appearance of the login screen). There is
Groan, I hate it to correct myself, but I was contacted offlist that I'm wrong
... ouch, so early in 2015! ...
So here goes ...
SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's
syntactically invalid. I can't use SSH to probe for known user IDs.
I believe this is
John McKown wrote:
Tony's Basement Computer wrote:
DoS, revoke all the non-Special and non-Protected users.
True. That concern was raised on RACF-L.
Hum, this sounds like a job for an IDS package. Perhaps something which would
dynamically update the z/OS firewall so that when an ID is
On Mon, 5 Jan 2015 09:48:28 -0600, Tony's Basement Computer wrote:
DoS, revoke all the non-Special and non-Protected users.
-Original Message-
From: Vernooij, CP (ITOPT1) - KLM
What is the point in trying to find a valid userid, if the userid will be
suspended after trying 3 invalid
Hello,
Cross Posted : MVS-OE and IBM Main
I am trying to take OMVS tace with the below command :
TRACE CT,64M,COMP=SYSOMVS
R XX,JOBNAME=(CC),OPTIONS=ALL,END
The above command fails with the below command :
IEE309I TRACEUNIDENTIFIABLE KEYWORD
ITT038I NONE OF THE TRANSACTIONS REQUESTED
Mike Wawiorko wrote:
Logon to TSO is an SNA session and not a (direct) IP connection. It may or may
not be from a tn3270 connection. If it is tn3270 the IP connection may well be
to another system and via a multi-session tool like TPX, Supersession, Tubes,
Multsess etc. where is the IP address
On 01/05/2015 09:35 AM, Paul Gilmartin wrote:
On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote:
For TSO, you can probe for known user ids, but you will see a lot of LOGON
and IEA989I message in the SYSLOG.
Only if you set a specific SLIP trap for this condition.
In the video cited:
Logon to TSO is an SNA session and not a (direct) IP connection. It may or may
not be from a tn3270 connection. If it is tn3270 the IP connection may well be
to another system and via a multi-session tool like TPX, Supersession, Tubes,
Multsess etc. where is the IP address and on which system?
On 2015-01-05, at 09:24, Mike Wawiorko wrote:
Logon to TSO is an SNA session and not a (direct) IP connection. It may or
may not be from a tn3270 connection. If it is tn3270 the IP connection may
well be to another system and via a multi-session tool like TPX,
Supersession, Tubes, Multsess
SMF and console messages to record logon/authentication failures.
These could be intercepted in real time to alert someone of unusual probing
while it is occurring
Yup! Come to either of my sessions at SHARE to learn about how to do that
(albeit with one of several commercial products).
Philip is larger than life and very into himself. He's keynoting at SHARE. Come
see him in person.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony's Basement Computer
Sent: Monday, January 05, 2015 8:57 AM
To:
In addition to what Dennis said, these buffers are for concurrent access
and are IN MEMORY above 16M. So they don't indicate SPOOL full. Even on
my relatively small z/OS system, I set this number to 209. It's virtual,
so it's not a real problem! grin/
On Mon, Jan 5, 2015 at 11:09 AM, Phil Smith
On Mon, Jan 5, 2015 at 8:57 AM, Tony's Basement Computer
tbabo...@comcast.net wrote:
Back years ago I worked at a Top Secret shop. That product wrote a
console message when a log on attempt has occurred that specified an
unknown user. Sadly, what was usually seen was a password. It's been
We have an open-source STC which, if not shut down cleanly, has a tendency to
fill SPOOL. Obviously we need to hunt down the problem and kill it. In the
meantime, when it happens, and our system gets IPLed (second-level guest, at
IBM Dallas), we wind up unable to logon. Starting the guest gets:
Check out $TBUFDEF to increase value of EXTBUF. $DBUFDEF will show your current
value which should be 49.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Phil Smith
Sent: Monday, January 05, 2015 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
I do not believe you will get RACF SMF and console messages for this type
of probing. It is my understanding that TSO performs a RACROUTE
REQUEST=EXTRACT to obtain the data to fill in the various fields in the
logon panel. When retrieving or replacing fields, the RACF manual
explicitly states:
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on
01/05/2015 12:09:35 PM:
From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 01/05/2015 12:10 PM
Subject: Full z/OS SPOOL
Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
We have an open-source
On my system the USERIF data of the TSO/E LOGON panel is unprotected. I can
overtype it with the correct userid. I hit Enter and TSO populates the panel
with the usual account number, etc.
Don't know what is different on my (V1R13) system, but the implication is that
yours might be made to
Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did
someone provide the magic VTAM command? I ask from ignorance because I didn't
watch 100% of the video and I'm not connect literate.
-Original Message-
From: IBM Mainframe Discussion List
Being old enough to remember the pre-Protected days, when this feature appeared
we implemented it into every user profile we could find that satisfied the
criteria. Zero pain, more uninterrupted sleep.
-Original Message-
From: IBM Mainframe Discussion List
Beep,beep,beep...Tape Mgr puts. INIT proc in one of STC Proclibs. Damn
that traffic jam.'
In a message dated 1/5/2015 6:17:54 P.M. Central Standard Time,
tbabo...@comcast.net writes:
Being old enough to remember the pre-Protected days, when this feature
appeared we implemented it into
On 5 January 2015 at 19:19, Tony's Basement Computer
tbabo...@comcast.net wrote:
Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did
someone provide the magic VTAM command? I ask from ignorance because I
didn't watch 100% of the video and I'm not connect literate.
His
Something like this?ICH408I USER(MYPSWD99) GROUP( ) NAME(???
)
LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED
The above was generated using the CICS CESN signon transaction.
From: Tony's Basement Computer tbabo...@comcast.net
To:
Hey Lou,
BTDT, *very* painful. Had to learn that one the hard way.
Cheers!
BobL
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lou Losee
Sent: Monday, January 05, 2015 4:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
I don't see those on my LPAR for the situation we are talking about -- invalid
userid but no password entry yet.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Frank Swarbrick
Sent: Monday, January 05, 2015 4:06 PM
To:
I have no idea how he got the addresses
I suspect by scanning.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Harminc
Sent: Monday, January 05, 2015 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enumerating User
The problem is, that when TSO populates the logon panel, it does not do
a(RACROUTE REQUEST=INIT (RACINIT) but rather does an RACROUTE
REQUEST=EXTRACT (RACXTRT) against the user id specified to populate the
fields on the logon panel. This does not result in any RACF message or SMF
record, but TSO
Hopefully all of your started proc user ids are PROTECTED otherwise those 3
invalid password attempts could cause you big problems.
Lou
--
Artificial Intelligence is no match for Natural Stupidity
- Unknown
On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote:
On Mon,
'Three in a row' means a sequence of accesses to a *particular* userid without
an intervening success. Accessing any number of *other* userids in the meantime
has no effect on the error count for that single userid. Only a successful
access to that userid resets the count, which may increment
On 01/05/2015 05:56 PM, Lou Losee wrote:
Hopefully all of your started proc user ids are PROTECTED otherwise those 3
invalid password attempts could cause you big problems.
Lou
--
Artificial Intelligence is no match for Natural Stupidity
- Unknown
On Mon, Jan 5, 2015 at 2:21 PM,
Before PROTECTED was implemented we only had this happen once that I
know of -- for a CICS region. It wasn't a hack or DoS attempt. Just a
user who wasn't paying attention and thought he was telling
SuperSessions to take him to that CICS region three times in a row when
he was really on a logon
So what TSO logon should be doing if the userid is invalid or not
authorized for TSO is not give any error indication on the logon screen
but populate the panel fields with plausible default values that look as
if a RACF TSO segment was found and force the user to supply the
password field before
I watched the flick and agree with a lot of what he said. He obviously
has no scruples about disclosing any and all information, but isn't that
how Open Source software protects itself? And if someone opens their
TN3270 port to the public internet, whose fault is that really?
One thing he
try:
OPTIONS=(ALL)
In article cahtvvrwv3qp6o8eshr_ewoua2e3nbey+ccghwbada7vrb_e...@mail.gmail.com
you wrote:
Hello,
Cross Posted : MVS-OE and IBM Main
I am trying to take OMVS tace with the below command :
TRACE CT,64M,COMP=SYSOMVS
R XX,JOBNAME=(CC),OPTIONS=ALL,END
The above
On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM
kees.verno...@klm.com wrote:
What is the point in trying to find a valid userid, if the userid will be
suspended after trying 3 invalid passwords (in our situation)?
Kees.
But not if you keep rotating IDs. It is three in a row for
I once suggested to management that we secure our z/OS user profiles. At the
time they were used as EMAIL addresses as well. I explained the scenario of
rotating IDs as Mike suggested it could lead to a DoS exploitation.
Naturally the EMAIL people prevailed.sigh.
-Original
Bob Rutledge wrote:
and our system gets IPLed (second-level guest, at IBM Dallas), we wind up
unable to logon. Starting the guest gets:
[ ... snipped ... ]
To Phil Smith, does that APAR OA26484 mentioned by Bob Rutledge describes your
symptom?
Just curious, at what z/OS level are you? I'm
I had not heard (and do not fully believe) that the hashed password data
set is generally readable (UACC=READ?).
It is not clear what data set you are referring to. I believe the hashed
password is stored in SYS1.RACF, which should be UACC=NONE. I suppose I should
watch the video.
On 01/03/2015 09:23 PM, Paul Gilmartin wrote:
On Sat, 3 Jan 2015 10:13:21 -0600, Ed Gould wrote:
Indeed it was at least interesting.
I would be curious if IBM would like to comment on some of the
statements on how how RACF encrypts the passwords.
I disagree with how RACF encryption is done
The fact is there have been several successful real hacks of production
mainframes, so some sort of real, present-day hacker exposure is not
unheard-of in the wild.
By real I mean not some staged attack on Hercules or the like but a real
outsider breach of a production mainframe, with
.a user without a TSO segment ?
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Boris Lenz
Sent: Monday, January 05, 2015 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CANCEL TSO Logon?
On Mon, January 5, 2015 16:29, Charles
On Mon, 5 Jan 2015 08:16:26 -0500 Peter Relson rel...@us.ibm.com wrote:
:What is the exact format of the LIST64 parameter. It is not clear if the
:counts and lengths include a slack four bytes (like the SUMLIST64
:parameter).
:SUMLIST64 does have 4 reserved bytes after the field containing the
On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote:
For TSO, you can probe for known user ids, but you will see a lot of LOGON
and IEA989I message in the SYSLOG.
Only if you set a specific SLIP trap for this condition.
In the video cited:
On Jan 2, 2015, at 3:31 PM, Mark Regan wrote:
DoS, revoke all the non-Special and non-Protected users.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP (ITOPT1) - KLM
Sent: Monday, January 05, 2015 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CANCEL TSO Logon?
On Mon, Jan 5, 2015 at 9:48 AM, Tony's Basement Computer
tbabo...@comcast.net wrote:
DoS, revoke all the non-Special and non-Protected users.
Hum, this sounds like a job for an IDS package. Perhaps something which
would dynamically update the z/OS firewall so that when an ID is revoked
due
For TSO, you can probe for known user ids, but you will see a lot of LOGON
and IEA989I message in the SYSLOG.
Only if you set a specific SLIP trap for this condition.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of
I see no console message at all (absent some SLIP trap) for simply testing a
userid (as opposed to a userid and password). Did I miss it?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Monday, January
On Mon, January 5, 2015 16:29, Charles Mills wrote:
I see no console message at all (absent some SLIP trap) for simply
testing a userid (as opposed to a userid and password). Did I miss it?
But you can probe for a valid userid on the logon panel. No message to the
syslog. If you don't get
57 matches
Mail list logo
