Thanks Sri, will give try this out today.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For multiple reasons, don't. It is a very, very bad idea.
Tony Thigpen
R.S. wrote on 10/29/18 12:03 PM:
I'm going to attach HMC remotely.
Remote means it is behind the router, so no broadcasts are realayed,
that alos mean one has to provide IP of the CPC (instead of
auto-detection), etc.
Hi,
Is there a way to persuade the above to return the full path name?
Alternatively, is there another REXX invocable routine that will return the
full path name?
Thanks
Steve
JCL:
// EXEC PGM=IRXJCL,
// PARM='REXXTEST'
//SYSEXEC DD DSN=SA.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
Thanks, looks like exactly like what I needed.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I suggest that you post this issue on the mvs-oe list, where you are much
more likely to have an IBM z/OS Unix guy see it.
On Tue, Oct 30, 2018 at 7:32 AM Steve Austin
wrote:
> Hi,
>
> Is there a way to persuade the above to return the full path name?
> Alternatively, is there another REXX
Scott, thanks for that. I had assumed the text generator was working correctly
once it got the allocate text units right. Bad assumption.
To others: I am not allowed to post source.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct
mistaks
> On Oct 30, 2018, at
Gil Cardenas,
It is quite simple with DFSORT to push the contents to the next records.
Using WHEN=GROUP you can push anything you want.
Here is an UNTESTED example . I assumed the REPORT01,REPORT02 values
start at position 1 and the values CART records have spaces in the first 4
bytes. I
I can only say that maybe even if I don’t require it go into supervisor state
and issue a SETFRR with Enabled unlocked task
I don’t know if I’ll go there but the registers associated with the creators of
the ESTAE are good enough as the base registers are intact enough to point to
my retry to
https://www.computerworld.com/article/3317679/data-center/little-it-shop-of-horrors-ii-another-fine-mess.html
--
Regards,
Mark T. Regan
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Something simple: did you check the SVC99 parameterlist for the 'last
parameter' hi-order bit and make sure it is set only in the last pointer?
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: 29
That error code really means "SVC 99 can't find a required key in the list of
text units." You must specify one of DDNAME, DSNAME, or PATH for SVC 99
unallocation. For that error, the system only cares that it has found one of
those three keys in the list during unallocation, and what you did
As Radoslaw says in his post, RACF and the usual Z host security is indeed
very, very good, but they do not protect you against everything. For example,
an insider attack by a sufficiently-authorized person could disclose keys
protected by RACF - there are people who can get to data on disk or
http://www.eweek.com/security/taking-a-closer-look-at-mainframe-security
What zero-day vulnerabilities would there be? I’ve not heard of unpatched
security holes in Z/OS before.
Unless you are not properly managing your data, that is, limit access to
confidential information, how would someone
Thank you both for the responses and samples. I was making it too complicated
and tried all kinds of parameters but keeping it simple worked like a charm.
Appreciate it,
Gil.
--
For IBM-MAIN subscribe / signoff / archive
DEALLOC requires 2 text units - the DDName tu and an UNALLOC tu
***UNALLOC TU
LA6,DUNUNALC POINT TO UNALLOC KEY
STH 6,S99TUKEY & PLUG IT INTO T.U.
LA6,0 0 PARMS FOR UNALLOC
STH 6,S99TUNUM PLUG INTO T.U.
MVI S99VERB,S99VRBUN PLUG IN
Mark Regan wrote:
>https://www.computerworld.com/article/3317679/data-center/little-it-shop-of-horrors-ii-another-fine-mess.html
Thanks! This is a good sharky story. Much appreciated.
Now, where is "Horrors number one"? ;-)
Oh, there is another one showing why you really need, uhum, "backups"!
Hi Eric,
The article is not talking about zero-day vulnerabilities with respect to
RACF or the other ESMs. A prime example of the type of vulnerability the
article is referring to would be the recent discussion of the SVC that put
the caller into key-zero supervisor state. A vulnerability like
Not just IBM, but any vendor that has a product that includes system level
code (APF authorized, Key 0 or supervisor state).
Lou
--
Artificial Intelligence is no match for Natural Stupidity
- Unknown
On Tue, Oct 30, 2018 at 1:43 PM Seymour J Metz wrote:
> If there were no unpatched security
Which program registers? In general you will have a chain of contexts, and you
can't find the right one without a precise definition of which one you need.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on
Here is something confusing me for several years:
The publication
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/dtcutz.htm
states TZ should be set at your /etc/csh.login, but I will add your
suggestion (/etc/rc) to my list of locations requiring
On Tue, 30 Oct 2018 19:36:23 +, Seymour J Metz wrote:
>Has anybody checked whether the problem is in DYNALLOC or in bpxwdyn?
>
An expert says, on MVS-OE:
It looks like bpxwdyn is in error. I suggest opening a PMR.
It's surprising that this went so long without being discovered.
>>>
So y'all will know how things worked out -- I found the issues
and fixed them.
Now it will deallocate the DD if the DD had been specified by JCL
or SVC99.
Thanx,
Steve Thompson
--
For IBM-MAIN subscribe / signoff / archive
If there were no unpatched security holes then IBM wouldn't need to release
security PTFs to fix them. I would hope that it's a lot harder to find one than
it used to be.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
Has anybody checked whether the problem is in DYNALLOC or in bpxwdyn?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent:
(Cross-posted)
On Tue, 30 Oct 2018 07:52:49 -0500, Kirk Wolf wrote:
>I suggest that you post this issue on the mvs-oe list, where you are much
>more likely to have an IBM z/OS Unix guy see it.
>
+1
>On Tue, Oct 30, 2018 at 7:32 AM Steve Austin wrote:
>>
>> Is there a way to persuade the above
The ones from the user program having register values from IGC062 doesn’t do me
much good
> On Oct 30, 2018, at 3:12 PM, Seymour J Metz wrote:
>
> Which program registers? In general you will have a chain of contexts, and
> you can't find the right one without a precise definition of which
+1 on the other replies so far.
The nature of zero-day vulnerabilities is that you have not heard of them
before.
Is z/OS inherently perfect and immune to all possible vulnerabilities,
including those resulting from customer error? Of course not!
Come to SHARE! Listen to the security
On 30 Oct 2018 07:59:23 -0700, in bit.listserv.ibm-main
(Message-ID:<22f77f8ce1e2084ab5fdb5843a0ba2a191038...@mlem1865.hrdc-drhc.net>)
frederick.verw...@hrsdc-rhdcc.gc.ca (Eric Verwijs) wrote:
http://www.eweek.com/security/taking-a-closer-look-at-mainframe-security
What zero-day
On Tue, 30 Oct 2018 19:35:56 -0400, Steve Thompson wrote:
>You mean like IBM, BMC, CA, etc.?
>
IBM? Really.
Scan this list's archives for helpful examples submitted by IBM reps. In a
couple minutes I found one only two hours old.
Thanks, IBM.
Sure, cleanse your sample of business-critical
On Tue, 30 Oct 2018 09:14:12 -0400, Steve Thompson wrote:
>
>To others: I am not allowed to post source.
>
Sounds like an obsession with zero-sum games.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
[Default] On 30 Oct 2018 16:19:45 -0700, in bit.listserv.ibm-main
ibmmain.10.ats...@xoxy.net (Arthur) wrote:
>On 30 Oct 2018 07:59:23 -0700, in bit.listserv.ibm-main
>(Message-ID:<22f77f8ce1e2084ab5fdb5843a0ba2a191038...@mlem1865.hrdc-drhc.net>)
>frederick.verw...@hrsdc-rhdcc.gc.ca (Eric
You mean like IBM, BMC, CA, etc.?
On 10/30/18 6:40 PM, Paul Gilmartin wrote:
On Tue, 30 Oct 2018 09:14:12 -0400, Steve Thompson wrote:
To others: I am not allowed to post source.
Sounds like an obsession with zero-sum games.
-- gil
Hi
I know system 23E is for invalid TCB it seems to me that TCB is valid could
any confirm that the following is the correct sequence of step to terminate
a TASK
I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am using
END_ECB I use to tell the subtask to return via BR 14
Steve Thompson wrote:
>So a test of the code, once fixed to run AMODE=31, works when I do an
>allocation of one of my own data sets using the DD of SYSUT1.
>When I do this allocate, I do not specify anything special for the text units.
>I only use the DDNAME, DSNAME and disposition of SHR.
>programmatically is there a way to determine were the program registers
are
In general, no. But specifically, "programmatically", sure (not
necessarily easily).
-- The SDWA for an FRR has the time-of-error registers.
-- The SDWA for an ESTAE has the time-of-error registers and (we can think
35 matches
Mail list logo
