On Wed, 31 Oct 2018 08:20:30 +, Steve Austin wrote:
>DYNALLOC with DINRPATH returns the correct path, so bpxwdyn looks to be the
>culprit. I'll raise a PMR.
>
I'll suggest that when/if you get a fixtest you try also with trailing blanks.
It's possible that BPXWDYN now truncates before the
The PSW is amode 31, so there's something odd going on. I'd look at the
system trace to see if the PGM 03B really occurred at that spot. The LE
dumps can be nice for simple errors, but when it gets weird like this,
it's better to use SYSMDUMP and IPCS to see what happened. Although you
can't call
Well, I made it go away. Didn't really diagnose it, but made it go away
hacking at the 87 different ways of linking or loading
DSNULI/DSNALI/DSNRLI/DSNHLI2/DSNHLIR/DSNHLI/DSNWLI2/DSNWLIR/DSNWLI/DSNELI.
G ...
Charles
-Original Message-
From: IBM Mainframe Discussion List
> What butt-stupid program ... ?
Umm, Language Environment
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Wednesday, October 31, 2018 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with diagnosing
I better correct that... I get Region 1 2 & 3 mixed up, so I can't
definitively say which bits are corrupt... but it may well be all of them.
I got this (and its sisters, 39 & 3A (maybe)) a few times after I turned on
the DIAG trap to catch bad register save/restore hygiene.
sas
On Wed, Oct 31,
What butt-stupid program decided you didn't need to see the high-order
words of the registers?
Your abend is due to a dirty high register... the 3b indicates pollution in
the high-order 11 bits.
sas
On Wed, Oct 31, 2018 at 6:45 PM Charles Mills wrote:
> Correcting the subject line. Sorry.
Correcting the subject line. Sorry. Please reply to this one if possible.
Charles
-Original Message-
From: Charles Mills [mailto:charl...@mcn.org]
Sent: Wednesday, October 31, 2018 3:43 PM
To: IBM Mainframe Discussion List (IBM-MAIN@listserv.ua.edu)
Subject: Help with diagnosing
I am getting the following error:
IEF450I SANDBOX1 - ABEND=S0C4 U REASON=003B
S0C4-3B is documented in part as
Region-Third exception. While running in 64-bit addressing mode, one of the
following errors occurred:
- A program attempted to reference storage that had not been
Jake Anderson wrote:
Hi
Some of the products came with serverpac comes with only base . I had an
assumption that products are updated latest RSU as per the serverpac note.
If there was RSU/HIPER fix/PE fix service available for those products
on the date your order was built, and the PTF
Ok got one more idea just be sure I didn’t mess up the TASK_ADDRESS in the
storage are shared between main task and subtask
I am going to put a TESTAUTH breakpoints right before I return to main and look
at the TASK_ADDR and PSATOLD
> On Oct 31, 2018, at 3:10 PM, Wayne Driscoll
> wrote:
>
Why use TCBUSER and KEY 0? Allocate a storage area and put its address in a
task level Name/Token pair so you don't have to mess with key switching or
potential integrity issues.
Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM
Which product? In my experience, all products ordered via serverpac get
maintenance selected for then I do a SMPE RECEIVE ORDER for everything. Is it
possible that the "product" is installed in some other zone and you didn’t
select that zone in your FORTGTZONES statement? You don’t say
I'd strongly recommend not using such fields as TCBUSER without a blessing from
IBM. Also, anything that lets you get into key zero increases the cost of
errors substantially.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe
END_ECB is the address of an ECB
Joe Reichman
170-10 73 rd ave
Fresh meadows NY 11366
> On Oct 31, 2018, at 2:45 PM, Seymour J Metz wrote:
>
> Is END_ECB and EB or the address of an ECB?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
Is END_ECB and EB or the address of an ECB?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Tuesday, October 30, 2018 10:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: S23E
Hi
Some of the products came with serverpac comes with only base . I had an
assumption that products are updated latest RSU as per the serverpac note.
There was a IBM product we installed came up with only base level though
it's Last RSU update was on 2016 and I was curious why IBM product don't
Sorry, finger check.
it should have been:
...and the last digit 'n' to the right of the ppp at the right side of the "="
rather than
...and the last digit 'n' to the right of the ppp at the left side of the "="
On Wed, 31 Oct 2018 13:23:46 -0500, Giliad Wilf wrote:
>As far as I can
As far as I can recall, a media statement in DEVSUPxx has the format:
MEDIA1=ppp1,
MEDIA2=ppp2,
..
..
MEDIA13=pppD
...where ppp stands for partition No., and the last digit 'n' to the right of
the ppp at the left side of the "=", must match the 'n' of MEDIAn to
I still think I am going to need a ECB or actually 4 to say I’m done or else
the main task might finish first looking at the registers
None have any info from main task or subtask
Rob I’m not trying to complicate things
But as I said the main task needs to know when things are done may have to
EXTR routines are given control under the owner of the terminating TCB :
"ETXR=exit rtn addr Specifies the address of the end-of-task exit routine. It
is given control after the subtask normally or abnormally terminates. The exit
routine is given control when the originating task becomes
The SVRB for DEATACH contains the registers for the calling program; I still
don't know whether that is the register set you want.
Note: check carefully which words are supposed to be pointers to other words.
Confusing, e.g., an ECB with the address of an ECB, will certainly cause issues.
--
In my code running under TESTAUTH I made a breakpoint after the wait ECB=SYSECB
and I go directly to my recovery routine with a 23E makes me think it’s not the
DETACH
Not sure more so I posted the code if anyone code confirm the logic is right ?
> On Oct 31, 2018, at 1:28 PM, Seymour J Metz
Is DETACH self valid?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Rob
Scott
Sent: Wednesday, October 31, 2018 7:01 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S23E
I would suggest
Do you mean open systems or "open" systems? z/OS may be as vulnerable as a well
secured Linux system, but I doubr that it is as vulnerable as a windows system.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
W dniu 2018-10-31 o 13:56, Robyn Gilchrist pisze:
[...]
z is just as vulnerable as open systems,
[...]
No, not *as open systems*.
BTW: z/OS is open system, while Windows is not really open. So... ;-)))
--
Radoslaw Skorupka
Lodz, Poland
Any article that starts with:
Big-hunk heavy-metal equipment made by IBM (Z Series) ...
is hard to take seriously.
On Wed, Oct 31, 2018 at 9:33 AM Allan Staller wrote:
> Agreed!
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Arthur
> Sent: Tuesday, October
Agreed!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Arthur
Sent: Tuesday, October 30, 2018 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: eWEEK Article highlights weaknesses in Mainframe Security
On 30 Oct 2018 07:59:23 -0700, in bit.listserv.ibm-main
CNMEUNIX is the NetView Unix Command processor that allowed unauthorized access
to UID(0), patched in 2012. IBM HTTP Server (DGW Base) had a security red
alert back in early 2013 but, as is IBM’s prerogative, they didn’t divulge the
particulars of the exposure.
Ray opened my eyes to exactly
Peter
END_ECB is the address, it is DSECTed off R7
So is TASK_ADDR, END_ECB and SYS_ECB they are unique to the 4 subtasks as for
the reason code as you so helpfully suggested yesterday the registers I got in
my dump were from IGC062 i know with what I provided it would be close to
impossible
Please provide all the relevant information in a post like this. The
IBM-Main community is very helpful but should not be wasting time trying
to guess about things that could easily have been supplied. This would
include the 23E reason code, the ATTACH (and how you saved the result) and
the
Rob
Is your suggestion to use EXTR as opposed to ECB because you suspect the
validity of the TCB and the TCB is passed to the exit in R1
More so the EXTR will get control after the subtask does a BR R14
Back to the EXTR when the exit ( EXTR ) does a BR 14 to z/os, z/os will resume
executing
Thanks
> On Oct 31, 2018, at 7:01 AM, Rob Scott wrote:
>
> I would suggest performing the DETACH from an "end of task exit routine"
> whose address is passed on the ETXR keyword of ATTACH(X).
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion
I would suggest performing the DETACH from an "end of task exit routine" whose
address is passed on the ETXR keyword of ATTACH(X).
Rob Scott
Rocket Software
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Wednesday, October 31, 2018 2:20 AM
W dniu 2018-10-30 o 21:55, Charles Mills pisze:
+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
Thanks everyone
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Vernooij, Kees (ITOPT1) - KLM
Sent: Wednesday, October 31, 2018 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DEVSUPxx question
From the DEVSUPxx doc in Init and Tuning:
" Use the DEVSERV
DYNALLOC with DINRPATH returns the correct path, so bpxwdyn looks to be the
culprit. I'll raise a PMR.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, October 30, 2018 8:58 PM
To:
From the DEVSUPxx doc in Init and Tuning:
" Use the DEVSERV QLIB,CATS command, which is documented in the z/OS MVS System
Commands, to dynamically change the library partitioning category codes without
IPL."
Kees
> -Original Message-
> From: IBM Mainframe Discussion List
Thanks
The results are not wat I expected.
Do these values get updated when I issue the T DEVSUP=00 command?
Gadi
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Brian Fraser
Sent: Wednesday, October 31, 2018 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DEVSUPxx
The risk landscape has changed. If you look at CVE for IBM products that
are based on GPL code, you will see may vulnerabilities. That's to say that
the mainframe is not immune against zero day attacks. Generally speaking,
many of the success mainframe penetration stories are based on
DS QL,CATS
On Wed, 31 Oct 2018 at 14:16, Gadi Ben-Avi wrote:
> Hi,
> I coded
>
> NON_VSAM_XTIOT=YES,
> COMPACT=YES,
> MEDIA1=11,
> MEDIA2=21
>
> In DEVSUP00 and then issued the command SET DEVSUP=00
>
> How can I be sure that the values for MEDIA1 and MEDIA2 were accepted?
>
> I am running z/OS
Hi,
I coded
NON_VSAM_XTIOT=YES,
COMPACT=YES,
MEDIA1=11,
MEDIA2=21
In DEVSUP00 and then issued the command SET DEVSUP=00
How can I be sure that the values for MEDIA1 and MEDIA2 were accepted?
I am running z/OS v2.2
Thanks
Gadi
? ?? ? ?? ??? ??? ?? ?
41 matches
Mail list logo
