Thank you Jim, appreciate the detailed explanation which is understandably
similar to Peter Relson's back in March.
My intent want not to take this thread in another direction, just thinking
about PSF in terms of the poster's original question...
On Wed, 19 Aug 2020 19:11:33 +
Last ditch effort if you cannot tell. Install the product from scratch in a
new Global/Tlib/Dlib and go from there.
Sometimes it is easier to rebuild your SMP/e environment from scratch that
spend months trying to figure out which one is correct.
Then roll out the new zone and replace the
I've got an itch for one of those trendy hotel jobs. Do they ask for any
qualifications more than screwing up SMP? I thought it would be a lot harder. -
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
>From memory and besides the FMIDs, run a 'LIST SYSMODS PTFS' (with "SET
BDY(GLOBAL)." for each CSI) - then compare the outputs. If either
listing shows a PTF received and applied in one CSI, but not in the
other, then browse the LMOD(s) to which the PTF was applied in your
loadlib: you should
The first machine to implement ESA/370 was the 3090E. This was
done via microcode updates (since the 3090E hardware was
designed prior to ESA). It was not possible to implement PSF in
microcode, so MVS used x'1000' as the data space ORIGIN,
Every subsequent machine (starting with the
Some months ago I asked a question regarding the relevance of the ORIGIN parm
on a DSPSERV macro. During that time I came across older documentation which
referred to low-address protection being in effect when the PSF (Private Space
Facility) was not active. My limited understanding is that
Seems like the real question is how does it work on a z13? 2048-4095
(x'800-FFF') are *supposed* to be key0 fetch-protected.
"Fetch Protection Override" (CR0:38) is to allow everyone to fetch from
0-2047 (x'0-7FF'), while leaving 2048-4095 fetch protection in effect. It
is not a new feature,
Generally, that would give you an 0C1. In my case it was a simple LOAD
instruction. LR1,X'B4C'(0,0)
Chris Blaicher
Technical Architect
Syncsort, Inc.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent:
So I had an S0C4 one time - turned out the vendor had used an instruction
that was not on the CEC (firmware) we were running.
So maybe there is an instruction used on the z13 that the 15 does not have?
Lizette
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Fetch-protection-override (cr0.38) allowed the OS to put fetch protection on
page0 while allowing (legacy) access to 0-2047.
Don't know which hardware level allowed exploitation.
On Wed, 19 Aug 2020 19:11:33 + "Christopher Y. Blaicher"
wrote:
:>We have a program that ran fine on a z13
zOS V2.2, V2.3 and V2.4, all running on LPARs of a z15. It seems to be a
machine issue, not a zOS issue.
This is NOT, repeat NOT, code in any Syncsort, now Precisely, product.
Chris Blaicher
Technical Architect
Syncsort, Inc.
-Original Message-
From: IBM Mainframe Discussion List
Hi Lizette -
We used to meticulously go through the SCHEDxx defaults and carefully "nullify"
any entries for products that we were not using, but it just became an
administrative and logistical headache. So, after some amount of research and
internal discussion, we finally decided that this
Subject to APF.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
ITschak Mugzach
Sent: Wednesday, August 19, 2020 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with SCHEDxx Parmlib vs.
What was your zOS version and what is it now?
Sent from my iPhone
I promise you I can’t type or
Spell on any smartphone
> On Aug 19, 2020, at 14:21, Christopher Y. Blaicher
> wrote:
>
> We have a program that ran fine on a z13 that now gets an S0C4 on a z15.
> On a z13 we could access
We have a program that ran fine on a z13 that now gets an S0C4 on a z15.
On a z13 we could access data in the PSA in the 2048 to 4095 range without
going into key 0. The specific field is PSASVT.
To get to that data now, we have to do a MODESET to key zero.
Anyone else find this as a problem?
PPT can assign authority to program names instead of user-id. Review
entries that are assigned bypass security, or bypass data integrity
(usually storage keys as well). Have a look at STIG document AAMV0160 from
DISA. BTW, our product, IronSphere, monitors and reports on this
automatically.
List -
I have been researching whether we need to review all of our SCHEDxx for PPT
and remove anything that is currently shipped by IBM in Linklib for IEFSDPPT
Does anyone have any observations on this?
I am currently working on some DB2 upgrades and it was recommended to remove
IRLM
You might see if you have a product named CompareX
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of retired mainframer
Sent: Wednesday, August 19, 2020 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to determine which SMP CSI
On Wed, 19 Aug 2020, at 17:41, retired mainframer wrote:
> If both have global zones, do they contain any FMIDs in common? If
> not, the one with the FMID for your PTFs is the one you want.
Both might though... if one CSI is an experiment, or something put to one
side when a previous install
Compare SMPE Target datasets (e.g. SYS1.LINKLIB) to running datasets. The
modules should be a match for the most part.
If there are 2 different levels, the will be many more mismatches.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
retired mainframer
Sent:
Do both CSIs contain a global zone? Normally, one would contain the global
zone and point to the other for the target or distribution zone, or both.
If both have global zones, do they contain any FMIDs in common? If not, the
one with the FMID for your PTFs is the one you want.
By run time
What I'd do is use PDS to find RMID's of load modules. Then find status of
those PTFs in CSI. FYI this is super dangerous. Mixed modules have been the
ruination of many a sysprogs now tending bar at trendy hotels.
In a message dated 8/19/2020 8:19:47 AM Central Standard Time,
On Wed, 19 Aug 2020 09:25:08 -0400, Kurt Quackenbush wrote:
>On 8/18/2020 9:55 AM, Bill Giannelli wrote:
>>...
>> Is this pointing to lack of space in my USS file system?
>
>Bill, is there any output in SYSPRINT? GIMUNZIP should echo information
>there from any utilities it calls or from the
Or not. If you find the fmid ptf, it is. if not, try the other one.
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son *
On Wed, Aug 19, 2020 at 5:49 PM Jeremy Nicoll
wrote:
> On Wed, 19 Aug 2020, at
Or not. If you find the fmid ptf, it is. if not, try the other one.
ITschak
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **| *
*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**:
On Wed, 19 Aug 2020, at 14:51, Itschak Mugzach wrote:
> or just browse one of the PTFs and see the FMID. Than use the SMPE ISPF
> interface option 3.2 (Cross Zone Query) to see if the FMID is installed...
Surely that presupposes that the ispf dialog is pointed at the right CSI?
--
Jeremy Nicoll
or just browse one of the PTFs and see the FMID. Than use the SMPE ISPF
interface option 3.2 (Cross Zone Query) to see if the FMID is installed...
ITschak
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS,
Hi Bill,
Another idea in conjunction with Tom's below ...
Using the PDS Comand Processor (CBT File 182), you can sort the member
list by Link Edit Date. You could also display the HIStory of a given
member which should show you the APARs/PTFs APPLYd.
Regards,
David
On 2020-08-19 09:33, Tom
On 8/19/2020 9:12 AM, Bill Giannelli wrote:
I have a component, DB2 Query Monitor, that I need to apply PTFs to. I have found 2 CSIs.
How do I determine which CSI was used for the currently running "Run Time
Libraries"?
thanks
Bill
thank you all for your help and information.
I was able to get by the error by allocating a larger uss mountpoint.
thanks
Bill
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On 8/18/2020 9:55 AM, Bill Giannelli wrote:
I have been trying to unzip a USS file and I keep getting the following:
GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND.
GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE
Is this pointing to lack of space
Check your DDDEFs for your target zones and see what datasets they point to.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Bill Giannelli
Sent: Wednesday, August 19, 2020 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: How to determine which SMP CSI is
I have a component, DB2 Query Monitor, that I need to apply PTFs to. I have
found 2 CSIs. How do I determine which CSI was used for the currently running
"Run Time Libraries"?
thanks
Bill
--
For IBM-MAIN subscribe / signoff /
33 matches
Mail list logo
