On Fri, 4 Feb 2022 at 18:07, Charles Mills wrote:
>
> Does the following make sense to anyone? From the JCL Reference, at least
> several recent versions including V2R5, Chapter 6. Job control statements on
> the output listing. It seems boggled to me on several levels. I don't think
> it is true,
Does the following make sense to anyone? From the JCL Reference, at least
several recent versions including V2R5, Chapter 6. Job control statements on
the output listing. It seems boggled to me on several levels. I don't think
it is true, and I think the references to specific programs are superflu
On 04/02/2022 22:42, Seymour J Metz wrote:
Dead tree or online? URL?
Google is your friend (in this case):
https://zh.booksc.eu/book/30664578/d49035
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
Dead tree or online? URL?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Peter Sylvester [peter.sylves...@gmail.com]
Sent: Friday, February 4, 2022 4:01 PM
To: IBM-MAIN
I watched a Soldier of Fortran hacking video the other day where Phil
noted to an audience of Linux folks how odd it was that MVS loaded
parameters and settings into memory control blocks. In Unix they say,
"Everything is a file", which is as odd to me as I'm sure they all felt.
On 2/4/2022 1
On 04/02/2022 21:06, Seymour J Metz wrote:
"A Timer-sharing display terminal session manager", J. M. McCrossin, R. P.
O'Hara, L. R. Koster, IBM Systems Journal 17, Number 3, 1978 pp. 260-275 says it started
as Research Display Facility at the T. J. Watson Research Center in Yorktown Heights.
And this IMHO is why the shared access to OS control blocks without access
controls makes z/OS less secure than a Linux Kernel which is locked down. I
think the clarification is cover for “we have a significant read-only
vulnerability” that needs to be corrected. Giving away information that s
I've always found it easy to convince myself to add and authorize whatever
logon procs I needed '-)
Yeah, if you're not a sysprog and management isn't willing to bless use outside
of systems then it's not an option. Less than 5% of my carreer has been spent
in environments where I didn't strong
I don't know what it is, but SM just bugs me. Kind of like watching
somebody use a Mac :)
On 2/4/2022 11:40 AM, Steve Smith wrote:
I've used Session Manager for years, but haven't yet met anyone else who'd
even heard of it. Of course, many of us would have to somehow convince a
sysprog they s
"A Timer-sharing display terminal session manager", J. M. McCrossin, R. P.
O'Hara, L. R. Koster, IBM Systems Journal 17, Number 3, 1978 pp. 260-275 says
it started as Research Display Facility at the T. J. Watson Research Center in
Yorktown Heights.
--
Shmuel (Seymour J.) Metz
http://mason.gmu
I do control the Rexx but it is buried in big jobs. The point of the SEND is
to highlight a problem. Searching for a say from the SEND is no easier than
searching for the problem!
I guess I have to learn not to hit Enter so impatiently. My wife has been
telling me for years not to be so impatient.
ISPF doesn't really change anything. If you do a SEND from the READY prompt,
the messages are still gone, gone, gone; it just takes a little longer.
If you control the REXX then you could always record the SEND commands yourself:
address TSO
"SEND' foo
say 'sending' for 'to' bar
--
Shmuel (Sey
I've used Session Manager for years, but haven't yet met anyone else who'd
even heard of it. Of course, many of us would have to somehow convince a
sysprog they should allow something new, which is often difficult and
onerous.
I find the ability to keep a log of commands & messages to be very val
And you can find, if you know the control blocks, the smf configuration, the
dump dataset info, etc.
Nothing is hidden from those who know the keys.
By locking down PARMLIB you just make it harder - not impossible.
Lock down /etc and see what happens.
Lionel B. Dyck <><
Website: https://www.
There are two conflicting pieces of general advice that are applicable here.
A. Making PARMLIB inaccessible is security by obscurity. You are not securing
the APF libraries by making one list of them unreadable.
B. Multiple lines of defense. Sure, there are other ways to get things like a
list
Only few of the parmlib members are represented on mobs control blocks.
Attacker may want to understand how smf is configured, to make sure his
activity is not recorded, what are the dump dataset mask, racf dataset
table (if it is a racf shop) and and many other information that help
penetrate the
1. I am running ISPF full screen. So once I hit Enter the message seems to
be gone, gone, gone.
2. The particular SENDs that I am interested in is sent from a batch job
with Rexx Address TSO "SEND ... but the question was intended to be general.
I don't see it in SYSLOG. I do see the SENDS that JE
we use EMS's Supervision product for systems consoles, we've defined
some VTAM session also.
I know the Console session have instant replay, we can go back in time
and step back and review console log messages, I use this for IPL's of a
new OS, I'm sure the other 3270 sessions we use for TSO/I
Amen Lionel. SHOWZOS is publicly available. Users can write their own REXX
code using the STORAGE function to display the active APF list on their
system. Security through (attempted) obscurity does not work.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
On Fri, Feb 4, 2022 at 1:02 PM
The good old TSO/E session manager may be your friend.
We had also the equivalent of the VM/CMS TELL.
That was 35 years ago during the EARN/BITNET time.
Like IRC or WHATSAPP.
I don't remember where The SM was developed, someone said it was in Italy.
On 04/02/2022 17:58, Charles Mills wrote:
I
If you want to hide your APF list then you also need to prevent ISRDDN's APF
option as it displays the APF list very nicely. I'm sure you can protect the
SDSF APF command, but can you prevent SHOWZOS, and other tools, from looking in
storage and displaying the list for you? The fact is that you
I agree with Ed, for most of the PARMLIB, but the APF list of libraries, should
be protected, since that is one way someone can get into the OS. Provided the
person has access to one of those libraries. So, I tended to be, maybe, over
protective of the APF and possible LNKLST, depending upon t
On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
I see the rule but I do not understand the rationale. Limiting UPDATE and
ALTER access to systems programmers is logical and reasonable. Limiting READ
access is not unless there are parameters in PARMLIB not available anywhere
else that can be
On Fri, 4 Feb 2022 08:58:37 -0800, Charles Mills wrote:
>Is there a way to retrieve a recently received but now-off-the-screen SEND
>message?
>
That sounds like a job for a terminal emulator: Log all screens to a file.
x3270 appears to have such an option; I haven't tried it. Other emulators?
M
That depends. For an MVS SEND command, including a TSO SEND that does an MVS
SEND, there is the syslog. For a TSO SEND that does a TPUT to another user, the
only way that I know of requires that you be running under the TSO Session
Monitor.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~sme
In my previous life, I used to work with tso prof nointercom and instead
wrote a small rexx to capture messages using outtrap and listbc command and
store them in an ispf table. I was able to read them and delete them. The
cons is that you don't get real time notifications.
*| **Itschak Mugzach |
I'm not sure if there's anyplace other than the broadcast datasets
maybe, if the SEND was issued from a job, like from a notify then maybe
check the syslog?
Carmen
On 2/4/2022 10:58 AM, Charles Mills wrote:
Is there a way to retrieve a recently received but now-off-the-screen SEND
message?
I
Is there a way to retrieve a recently received but now-off-the-screen SEND
message?
I can't be the only person who has been heads down on something, hit Enter
to get some pesky message out of the way, and then gone "wait ... what did
that say?"
Is there a way to retrieve a recently departed messa
That's what I was thinking. Hiding parmlib puts a rock in the road, but
you can just walk around it.
A long time ago I remember trying to compress parmlib in place and found
a started task had it allocated in its JCL. I can't remember why that
was - I assume to read bits and pieces at variou
While the status of the active settings derived from Parmlib members may be
viewable using tools such as IPLINFO and the like, there are other things in
Parmlibs as well.
For example,
1. many sites will have Parmlib shared amongst members of a sysplex. So READ
access to Parmlib gives you those
When it comes to security, a "need to know" rule applies. This Is true that
some (but not all, even not most, of the parmlib is in MVS control blocks.
However, as a pen tester, I want to know which SMF records are recording my
activity, dataset name of os components that are not part of their mvs
l
Several companies I was at lately had this policy of no read access to PARMLIB,
and it is a pain because things you are used to, like IPCS, do not work without
RACF READ access to it. I seem to remember that other tools also get their
startup parms from PARMLIB, so that seems very counterproduct
I don't believe that read access to PARMLIB is a security risk, and it is
possible that a prohibition could actually lead to security issues, but if you
are under the pervue of DISA the you need to abide by their policies, although
I would probably document the fact that I considered UACC=NONE f
I see the rule but I do not understand the rationale. Limiting UPDATE and
ALTER access to systems programmers is logical and reasonable. Limiting READ
access is not unless there are parameters in PARMLIB not available anywhere
else that can be used to gain an elevation of authority.
I have no
That's why my 3850 stopped working :)
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter Fatzinger
Sent: Friday, February 4, 2022 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS PURGE command
[External Email. Exercise caution when clicking links or opening a
As noted, the PURGE command was related to the 3850. The code backing the
command was eventually removed from the product in z/OS 1.11 which is why you
now get the IEE305I message.
I was unaware of the table in the SDSF book. I'll work with the publications
team to get the discrepancies correct
W dniu 04.02.2022 o 00:12, Farley, Peter x23353 pisze:
I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB
to be dangerous, BUT . . .
What information could possibly be gleaned from reading PARMLIB that would
require a knowledgeable auditor to insist on restricting re
No, it is (99% sure) related to IBM 3850 MSS device.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 03.02.2022 o 22:53, David Spiegel pisze:
Hi Radek,
Was it CICS-related?
Regards,
David
On 2022-02-03 15:34, Radoslaw Skorupka wrote:
W dniu 03.02.2022 o 21:25, Tony Harminc pisze:
On Thu, 3 Feb 2
Possible explanation:
MVS System Commands from 1978 says:
ASSIGN,PURGE, and DISPLAY3850are explained inOperator's
Library:IBM3850MassStorage
System(MSS)UnderOS/VS.
So it seems the command was related to MSS.
Maybe it's not worth to mention, MSS was available few years before
RACF, but it was
39 matches
Mail list logo
