I know this is a dumb question in that the answer should obviously be "no
problem". I am messing around with rewriting MVSCPMCD. It currently does
PGFIX & PGFREE to fix and free the areas being communicated to VM as
required for the DIAGNOSE (Hypervisor call) instruction. I was rewriting
the code
I am not finding this. I want to change the PKM for my running, APF
authorized, program to include key 0. Why? So that I can switch in and out
of key 0 using an SPKA instruction rather than MODESET. But mainly so that
I can use the MVCSK and MVCDK instructions to read & update key 0, fetch
New builtin to replace '' initialisations:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=133518
Enhance the sum() builtin function and add two siblings
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=133641
If you think these RFEs are useful, please vote
A little over a year later I started here as an entry level sys prog.
Can't remember when I joined IBM-Main, thinking it was like 92 or so...
Thank you Darren...
On 6/6/19 8:01 PM, Edward Finnell wrote:
> Happy Birthday Ibm-main established 6 June 1986. Thanks Darren...
>
>
And this is telling.
What did you propose? New product to make the system less vulnerable or
just suggest proper configuration?
What's the solution for the case?
Why almost all cases mentioned here are like that, that means some
misconfiguration done by mistake or due to lack of knowledge?
Why
On Fri, Jun 7, 2019 at 11:24 AM Charles Mills wrote:
> > Why is FIX=LONG unnecessary?
>
> Because SP 223 is already/always fixed?
>
Ah, yes. I am going not so slowly crazy (co-worker is bothering me wanting
unnecessary changes to some production backups -- why on Friday I don't
know -- he's
On Fri, Jun 7, 2019 at 12:15 PM Charles Mills wrote:
> I am by no means an expert on this stuff. Whenever I have to touch my code
> I have the MVS and PoOp manuals open, close at hand, and in some cases,
> printed out and highlighted.
>
> > not fetch protected
>
> Not fetch protected has fallen
On Fri, Jun 7, 2019 at 10:45 AM Charles Mills wrote:
> My WAG is that FIX=LONG is totally unnecessary. I would omit FIX=LONG to
> avoid any possibility of a problem. That would moot your FIX=LONG question.
>
Why is FIX=LONG unnecessary? I will be passing the real address to z/VM via
DIAG x'08'
Consider the following STORAGE OBTAIN request:
STORAGE OBTAIN,
SP=12,
LV=8192,
LOC=(31,PAGEFRAMESIZE1M),
FIX=LONG,
STARTBDY=12 * 4K BOUNDRY
LR R6,R1
LRA R5,0(,R6)
Will the real address gotten by the LRA
My WAG is that FIX=LONG is totally unnecessary. I would omit FIX=LONG to avoid
any possibility of a problem. That would moot your FIX=LONG question.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Friday,
> Why is FIX=LONG unnecessary?
Because SP 223 is already/always fixed?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Friday, June 7, 2019 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dumb STORAGE
IBM-Main great help to many of us. A big thank you to all concerned.
On Fri, Jun 7, 2019 at 8:19 AM Brian France wrote:
> A little over a year later I started here as an entry level sys prog.
>
> Can't remember when I joined IBM-Main, thinking it was like 92 or so...
>
> Thank you Darren...
>
>
How many vulnerabilities have you seen that did not come down to people? Those
sysprogs are just the tip of the iceberg as far as configuration, enforcement,
management, policy, procedure, protocol and training vulnerabilities are
concerned. Yes, I've seen code vulnerabilities, but they're
I am by no means an expert on this stuff. Whenever I have to touch my code I
have the MVS and PoOp manuals open, close at hand, and in some cases, printed
out and highlighted.
> not fetch protected
Not fetch protected has fallen way out of fashion! It is generally considered a
security no-no
So I thought IBM would want us to use z/OSEM?
Is that still the plan? Or is this a different function
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Jesse 1 Robinson
> Sent: Thursday, June 06, 2019 4:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject:
The steps needed was
Add a TSO Segment by coding UNIT(SYSDA) in TSO section. No other options were
updated (I.e. no TSOPROC coded)
Grant any additional OPERCMDS class entities - for example MVS.VAR.*
Once this was done and SETR REFRESH completed
My job now runs successfully
IBM
Lizette, I had forgotten about your 'hanging post'. A colleague had the same
problem just this week. He wrote a CONSOLE REXX that worked for me but not for
him. The problem: I had a TSOE segment and he did not. He added a TSOE segment
to his userid, and his job worked fine.
I am however
The simplest description I've found is referenced in the APAR text:
http://publibz.boulder.ibm.com/zoslib/pdf/OA55959.pdf
As I understand it, PDUU was designed to give the customer a standard
*supported* mechanism for uploading SR doc to IBM. The original implementation
used FTP, which is
I had already gone through the OPERCMDS and TSOAUTH classes and added the IDs
to what I thought might fix consprof.
It was not until the TSO Segment (and all I did was do UNIT(SYSDA) nothing
else) it was not working.
The manual, in my opinion, only alluded to TSO segment without coming out
I think you mean z/OSMF, and even when fully implemented, we won't be allowing
direct access to upload dumps from the mainframe without some manual
intervention at least. I looked at that briefly awhile back, and sadly we are
still way behind getting security setup correctly.
It is good
> I am trying to avoid running key 0 or supervisor state to the extent possible.
I support that. ("I agree.") Least privilege and all that. Of course, least
privilege and "doing it the most efficient (at run time) way" (even as a
learning exercise) are sometimes mutually exclusive.
> LOCHIH
An "infinite loop" feature was overlooked when the COBOL standard added support
for EXIT PERFORM. This feature is scheduled to be added in the next COBOL
standard ("202x"). But seeing that there was 12 years between the 2002 and
2014 standards, and 17 years between the 1985 and 2002
22 matches
Mail list logo
