AL' 10/15
CHANGE '(' DIGITS*3 ')' TO SUBSTRING 2/4
From: IBM Mainframe Discussion List on behalf of
Leonard D Woren
Sent: Friday, September 8, 2023 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler L
On Fri, Sep 08, 2023 at 04:35:59PM -0700, Leonard D Woren wrote:
You left out URSA at UCLA. Online editing as long as the file was
RECFM FB/80/400. Pre 3270, 20 lines of 40 characters. Along with job
submission and output view capability.
> Just like the rest that I listed. So a failure, inst
This list is dying just like assembler. Another 5, maybe 10 years, both will be
in the dustbin of history. In 10 years, most of the dominant posters will be
gone.
Sent from Yahoo Mail for iPhone
On Friday, September 8, 2023, 7:44 PM, Tom Brennan
wrote:
I'd say head them over to
https://ww
I'd say head them over to
https://www.facebook.com/groups/ProfessionalMainframers
In spite of the name, it's 90% nostalgia - maybe more. And there are a
lot of retired folks there to give upvotes and comments - unlike a new
email group.
For me, I don't mind anything reasonably on-topic. It'
Seymour J Metz wrote on 9/8/2023 5:29 AM:
I used SuperWylbur, but even in the free version you had associative ranges,
which greatly simplified many editing tasks.
Doesn't current ISPF's regexp support let you do the same thing? Not
that I've learned yet how to do that stuff...
Even before
Steve Thompson wrote on 9/7/2023 7:24 PM:
You ever work with WYLBUR?
Yes, at RAND circa 1976 as a guest of an employee, and at Stanford,
which is where I quickly grew to hate it. Funny thing is, many of the
other Stanford systems people started using TSO more as they saw what
I could do wit
Hercules 390 list often gets many of those conversations. Or trying
to recreate the software.
On Fri, Sep 8, 2023 at 4:17 PM Mark Zelden wrote:
>
> I'm with most of the posters...
>
> There needs to be an IBM-MAIN-NOSTALGIA list and these trips down memory lane
> moved there when they start.
>
>
I'm with most of the posters...
There needs to be an IBM-MAIN-NOSTALGIA list and these trips down memory lane
moved there when they start.
I was pretty much gone from IBM-MAIN over the last 2-3 years due to just being
too busy
to try and keep up but recently have tried to start following again.
For what it's worth (which is not much, I realize) I generally read this kind
of thread with interest and sometimes chime in. Not saying you're wrong, Rex,
just casting my own vote the other way.
There are lots of threads that don’t interest me, but it's very little work to
ignore 'em.
---
Bo
this list.
Please stop the chatter on this.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Crawford Robert C (Contractor)
Sent: Friday, September 8, 2023 7:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [EXT] Re: Is the IBM Assembler List still ali
ursday, September 7, 2023 9:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Is the IBM Assembler List still alive - Dumps - Early days
You ever work with WYLBUR?
Single address space, keeping users from crossing boundaries (RACF, ACF2, Top
Secret and WACF). Could edit a library with RECFM=U
@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
You ever work with WYLBUR?
Single address space, keeping users from crossing boundaries
(RACF, ACF2, Top Secret and WACF). Could edit a library with
RECFM=U. So one could keep source there if they wanted. Would, on
close
You ever work with WYLBUR?
Single address space, keeping users from crossing boundaries
(RACF, ACF2, Top Secret and WACF). Could edit a library with
RECFM=U. So one could keep source there if they wanted. Would, on
close compress the PDS to a single extent if it could.
Used very low level in
I agree. ROSCOE was clunky & less productive. I’ve never used the other TSO
alternatives.
I seem to remember vaguely ROSCOE requiring the user to “attach” the member you
wanted to edit but that was 35 years ago.
Sent from Yahoo Mail for iPhone
On Thursday, September 7, 2023, 9:15 PM, Leonard
Roscoe was one address space so everything was there when you logged
in. Much like using a CICS editor.
On Thu, Sep 7, 2023 at 8:15 PM Leonard D Woren wrote:
>
> Bill Johnson wrote on 9/7/2023 1:05 PM:
> > We used to use ROSCOE at a small shop in the 80’s because it used less
> > resources. I h
Bill Johnson wrote on 9/7/2023 1:05 PM:
We used to use ROSCOE at a small shop in the 80’s because it used less
resources. I hated it.
ROSCOE was one of a collection of TSO alternatives, which were all
junk. TONE, ACEP, Wylbur, maybe more that I don't remember. They all
had 1 two-pronged de
udders.
> > > >
> > > > ____
> > > > From: IBM Mainframe Discussion List on
> > behalf of Clem Clarke
> > > > Sent: Wednesday, September 6, 2023 6:38 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
>
___
> > > From: IBM Mainframe Discussion List on
> behalf of Clem Clarke
> > > Sent: Wednesday, September 6, 2023 6:38 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
> > >
>
t;
> >
> > From: IBM Mainframe Discussion List on behalf of
> > Clem Clarke
> > Sent: Wednesday, September 6, 2023 6:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Is the IBM Assembler Li
Agree.
Sent from Yahoo Mail for iPhone
On Thursday, September 7, 2023, 8:00 PM, Matt Hogstrom
wrote:
We used it at a bank because of the number of application developers. TSO was
reserved for system programmers. Also, it was limited in what you could do
with the OS. made sense for the
I didn’t start it. But, I’ll bet I get the warnings.
Sent from Yahoo Mail for iPhone
On Thursday, September 7, 2023, 7:21 PM, Bob Bridges
wrote:
And, they're off again.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* "If dickering won't work, then you have to fight. But I thi
IN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the
awards program. I’m very proud of it and my Math expertise paid off handsomely.
Sent from Yahoo Mail for iPhone
On Thursday
We used it at a bank because of the number of application developers. TSO was
reserved for system programmers. Also, it was limited in what you could do
with the OS. made sense for the purpose but it was not a lot of fun. It was
like being moderated at every turn. TSO, was, Liberating.
Ma
And, they're off again.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* "If dickering won't work, then you have to fight. But I think maybe it
takes a man who has been shot at to appreciate how much better it is to fumble
your way through a political compromise rather than have th
ubject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the
awards program. I’m very proud of it and my Math expertise paid off handsomely.
Sent from Yahoo Mail for iPhone
On Thursday, September 7, 2023,
ber 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Ohio, I was at the top in Algebra and Geometry. Early 70’s. I still have the
awards program. I’m very proud of it and my Math expertise paid off handsomely.
Sent from Yahoo
_
From: IBM Mainframe Discussion List on behalf of
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: September 7, 2023 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Ohio, I was at the top i
er had TSO in less than 2 MiB; 768 KiB gives me shudders.
>>
>>
>> From: IBM Mainframe Discussion List on behalf of
>> Clem Clarke
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA
___
>> From: IBM Mainframe Discussion List on behalf of
>> Clem Clarke
>> Sent: Wednesday, September 6, 2023 6:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>&g
n List on behalf of Clem
Clarke
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Running TSO in 3/4 of a meg was interesting. And VERY slow.
--
-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
What was the first OS that you had a 2 MB TSO region? What hardware.
MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB . There was a lot
you could do, although it was slow. I did experiment with overlay
mo
I had been using TSO/ISPF for a decade mostly at GM, then EDS when GM bought
them. Before accepting the job at the small local company (hospital) that used
ROSCOE. In my programming days.
Sent from Yahoo Mail for iPhone
On Thursday, September 7, 2023, 4:41 PM, Bob Bridges
wrote:
If you can
If you can explain why without deriding anyone, Bill, I'd be interested in
knowing why. I first encountered ROSCOE in 1980 and used it for a while
without thinking much about it. When I realized I could change things around
in it, I got excited.
It was another two years before I was exposed t
Clarke
> Sent: Wednesday, September 6, 2023 6:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
>
>
> Running TSO in 3/4 of a meg was interesting. And VERY slow.
>
-
.
From: IBM Mainframe Discussion List on behalf of Clem
Clarke
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
Running TSO in 3/4 of a meg was interesting. And VERY slow
e shudders.
From: IBM Mainframe Discussion List on behalf of
Clem Clarke
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days
I used to arrive at work every morning to ha
Please can this conversation be moved to the assembler list (and so give it
usage!)
Thank you
Colin
On Wed, 6 Sept 2023 at 14:35, Phil Smith III wrote:
> Clem, I've never heard of CLEO. Should I assume it's NOT the same CLEO
> that comes up when I search "cleo programming language"? That one loo
Clem, I've never heard of CLEO. Should I assume it's NOT the same CLEO that
comes up when I search "cleo programming language"? That one looks like some
modern scripting thing.
It's pretty interesting these languages that came and went. You'd think that
there would still be pockets of each,
I used to arrive at work every morning to have to wade through a two
foot high paper system dump to see why an OS abend had occurred that
night. Every night, pretty well in the early days!
MFT, MVT, MVS. MVS was a LOT better.
Running TSO in 3/4 of a meg was interesting. And VERY slow.
We u
I specify DUMP=NO,
sorry Steve, I neglected to say that, but I didn't delete my SYS1.DUMP
datasets
Carmen
On 8/19/2022 9:12 AM, Steve Beaver wrote:
I have turned on DYNAMIC dumps and tested.
No I want to drop my PHYSICAL dump datasets. That is easy.
What do I need to
8/19/2022 9:12 AM, Steve Beaver wrote:
I have turned on DYNAMIC dumps and tested.
No I want to drop my PHYSICAL dump datasets. That is easy.
What do I need to do in PARMLIB to insure the system doesn't
Look for them after I delete the PHYSICAL dump datasets?
I have turned on DYNAMIC dumps and tested.
No I want to drop my PHYSICAL dump datasets. That is easy.
What do I need to do in PARMLIB to insure the system doesn't
Look for them after I delete the PHYSICAL dump datasets?
TIA
prevent unauthorized dumps of
execution-controlled programs.
The check uses a resource name of IEAABD.DUMPAUTH where:
(a) Access of UPDATE (or no profile) allows the dump
(b) Access less than READ means suppress the dump, and
(c) Access of READ means allow the dump if
(c1) SETR NOWHEN
> The check uses a resource name of IEAABD.DUMPAUTH
That module comment is incorrect. It checks resource name IEAABD.DMPAUTH
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instruct
Commentary from the module that does the checking:
...checks a FACILITY class profile to ensure the installation allows the user
to take this dump. Can prevent unauthorized dumps of
execution-controlled programs.
The check uses a resource name of IEAABD.DUMPAUTH where:
(a) Access of UPDATE
Thanks Peter for the information. It then seems appropiate to RACF protect
IEAABD.DMPAUTH resource.
RACF SAG states:
<<<>>>
Who should have access to IEAABD.DMPAUTH (human/non-human userids)?
Regards,
Juan MautalenEl martes, 12 de julio de 2022, 09:11:43 p. m. GMT-3, Peter
Relson escribió:
IEAABD.DMPAUTH processing is very different than IEAABD.DMPAKEY.
> I assume the answer is YES, but I want to be sure.
That is not a good assumption.
It happens to be true for IEAABD.DMPAUTH.
It is not true for IEAABD.DMPAKEY (which applies only when the abend occurred
in key 0-7).
They were cre
On Mon, 11 Jul 2022 15:40:10 + "jgmauta...@yahoo.com.ar"
<01f9499d67db-dmarc-requ...@listserv.ua.edu> wrote:
:>Hi!
:>
:>I have a question regarding IEAABD.DMPAUTH / IEAABD.DMPAKEY resources in RACF
FACILITY class:
:>
:>
:>1- In this context, when the RACF "Security Administrator Guid
Hi!
I have a question regarding IEAABD.DMPAUTH / IEAABD.DMPAKEY resources in RACF
FACILITY class:
1- In this context, when the RACF "Security Administrator Guide" says
"controlled programs", is it referring to programs protected in RACF PROGRAM
class?
2- It is not completely clea
On Mon, 4 May 2020 16:29:48 -0400, Tony Harminc wrote:
>On Mon, 4 May 2020 at 04:23, Barbara Nitz wrote:
>
>> Doesn't matter. With an IMS region, you cannot use cancel (z/OS:
>> "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel
>> first, please"). And you cannot use for
.
-Original Message-
From: Barbara Nitz
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Mon, May 4, 2020 10:23 am
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
On Thu, 30 Apr 2020 09:09:32 -0400, Peter Relson wrote:
>
>z/OS FORCE did not work
>
>
>Wanna bet?
>
>FORCE,ARM runs
On Mon, 4 May 2020 at 04:23, Barbara Nitz wrote:
> Doesn't matter. With an IMS region, you cannot use cancel (z/OS:
> "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel
> first, please"). And you cannot use force because IMS intercepts that and
> tells you to terminate t
or
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2
Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
From: Barbara Nitz
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 04/05/2020 09:23
Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and
in the control region,
but the de-registering hasn't made it down the tcbs in that IMS message region.
Sometimes the callrtm program worked after the 5th invocation, but sometimes it
didn't work even after 10 invocations. (With the dumps to verify it didn't
work in betwee
ERV.UA.EDU
> Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
>
> On Thu, Apr 30, 2020 at 8:16 AM Seymour J Metz wrote:
>
> > Technically, you could move, e.g, TCB, RB, above the line, if there were
> a
> > good enough business case. As a practical matter it wo
nframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
John McKown [john.archie.mck...@gmail.com]
Sent: Friday, May 1, 2020 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
On Thu, Apr 30, 2020 at 8:16 AM Seymour J Metz wrote:
> Technic
On Thu, Apr 30, 2020 at 8:16 AM Seymour J Metz wrote:
> Technically, you could move, e.g, TCB, RB, above the line, if there were a
> good enough business case. As a practical matter it would require duplicate
> pointer fields and a PARMLIB option with a default of below. It would
> definitely be
, Denis. -Original
Message-
From: Attila Fogarasi
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, May 1, 2020 12:43 am
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
If your application consists of 200+ modules with up to 8m working storage
per module, then storage management becomes a
, April 30, 2020 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Wanna bet?
FORCE,ARM runs in the address space so would have been affected.
FORCE does not.
We had PMRs open on that, countless dumps. CANCEL and FORCE are rejected
because the region is
>
> Wanna bet?
>
> FORCE,ARM runs in the address space so would have been affected.
> FORCE does not.
> We had PMRs open on that, countless dumps. CANCEL and FORCE are rejected
> because the region is still registered with IMS.Sometimes the Mainview KILL
> worked, I think
Wanna bet?
FORCE,ARM runs in the address space so would have been affected.
FORCE does not.
We had PMRs open on that, countless dumps. CANCEL and FORCE are rejected
because the region is still registered with IMS.Sometimes the Mainview KILL
worked, I think it calls CALLRTM directly under the
://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Peter Relson [rel...@us.ibm.com]
Sent: Thursday, April 30, 2020 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
z/OS
z/OS FORCE did not work
Wanna bet?
FORCE,ARM runs in the address space so would have been affected.
FORCE does not.
z/OS still is a 24bit operating system with some 31/64bit addressing and
instructions as long as under the covers such old mechanisms need to be
maintained and taken into acco
, Test IBM Corp.
Poughkeepsie NY
From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 04/29/2020 04:00 PM
Subject:Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Sent by:"IBM Mainframe Discussion
On Wed, 29 Apr 2020 08:45:30 +0100, Martin Packer wrote:
>As much to the point, why does this need to be 24-bit LSQA?
Compatibility.
TCBs and RBs are still below the line because moving them above the line
will likely break existing AMODE(24) programs.
--
Tom Marchant
---
Don't forget that GETMAIN requests for storage above the line will return
storage
below the line if there isn't sufficient storage above the line to honor the
request.
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / arc
You have used up all the below-16M storage. End of story.
Short answer: don't do that.
Long answer: don't do that.
Every task and RB uses "some". And your application uses whatever it
uses.
It is up to you not to create so many tasks that things run out. The
system isn't going to try to stop y
metz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Denis [01664d8ede6c-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 29, 2020 4:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps -
compatibility for old modules, etc.
Thanks, Denis.
-Original Message-
From: Barbara Nitz
To: IBM-MAIN
Sent: Wed, Apr 29, 2020 10:26 am
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
>We had a similar issue in IMS regions, stalling after out of memory abend, no
>way to g
itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2
Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
From: Barbara Nitz
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 29/04/2020 09:27
Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dum
>We had a similar issue in IMS regions, stalling after out of memory abend, no
>way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work,
>except with some vendor tool cancel that just gets rid of the address space
>without proper cleanup that gets you closer to IPL.I wondere
routines, sounds awkward?!
My two cents, Denis.
-Original Message-
From: Martin Packer
To: IBM-MAIN
Sent: Wed, Apr 29, 2020 9:45 am
Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
As much to the point, why does this need to be 24-bit LSQA?
Cheers, Martin
Martin Packer
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 29/04/2020 08:21
Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Sent by:IBM Mainframe Discussion List
You say that the problem happens when all the tasks terminate. Your
problem is with not enough LQSA for termination. Du
You say that the problem happens when all the tasks terminate. Your problem is
with not enough LQSA for termination. During termination a number of RBs are
getmained by RTM to handle termination - like an RB that your ESTAE gets
control under (a PRB, IIRC). Or a PURGEDQ SVRB. Depending on what y
MAXPROCSYS in SYS1.PARMLIB(BPXPRM00)
MAXASSSIZE in SYS1.PARMLIB(BPXPRM00)
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Thomas David Rivers
Sent: Sunday, April 26, 2020 9:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0F9 and SOFD ABENDs and SVC dumps - oh my
ginal Message-
From: IBM Mainframe Discussion List On Behalf Of
Thomas David Rivers
Sent: Sunday, April 26, 2020 10:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0F9 and SOFD ABENDs and SVC dumps - oh my!
I have a program that fires up about 1000 tasks, and each of these tasks fire
up a sub
I have a program that fires up about 1000 tasks,
and each of these tasks fire up a sub-task... (I say "tasks"
but these are actually BPX threads - started with BPX
pthread_create.) Each of the 1000 tasks/threads starts
a sub-thread and waits for its completion.
Most of the time when I run the p
It seems odd to me that MVS needs all those "built-in" SLIPs to suppress
dumps. I would expect most of those are abends that didn't request a dump
in the first place.
That is not how taking of abend dumps truly works. The issuer of an abend
does not have to request a dump in
It seems odd to me that MVS needs all those "built-in" SLIPs to suppress
dumps. I would expect most of those are abends that didn't request a dump
in the first place.
sas
On Wed, Apr 17, 2019 at 7:42 AM Peter Relson wrote:
> There is nothing that fault analyzer can do ab
There is nothing that fault analyzer can do about this. When the system is
told not to take a dump, it does not take a dump.
>I'm not going to get permission to do this.
Permission to do what? Ask someone who issues "CANCEL" (especially for
something of yours) to include the "DUMP" operand?
Re
t on behalf of
Peter Relson
Sent: Saturday, April 13, 2019 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dumps and cancelling jobs
I think that products such as abend aid get control only when an abdump
occurs.
z/OS is configured not to take an abdump on a cancel unless you ask f
I think that products such as abend aid get control only when an abdump
occurs.
z/OS is configured not to take an abdump on a cancel unless you ask for
one.
This is accomplished via the SLIP trap
SLIP SET,C=222,ID=X222,A=NODUMP,END
within IEASLP00.
CANCEL with DUMP results in completion cod
Frank Swarbrick
Sent: Friday, April 12, 2019 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dumps and cancelling jobs
This didn't help.
I see no indication that Fault Analyzer was invoked at all. Usually when its
invoked, even if the dump is suppressed, FA will write an informational me
: IBM Mainframe Discussion List on behalf of
Christopher Y. Blaicher
Sent: Friday, April 12, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dumps and cancelling jobs
You probably will get what you want with C jobname,DUMP console command, or CD
in a SDSF screen.
Chris Blaicher
Technical Arch
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Christopher Y. Blaicher
Sent: Friday, April 12, 2019 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dumps and cancelling jobs
You probably will get what you want with C jobname,DUMP console command, or
CD in a SDSF screen.
Chris Bla
12, 2019 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dumps and cancelling jobs
The discussion about non-recoverable abends and cancelling jobs brings to mind
an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall
correctly, if a job was cancelled in
The discussion about non-recoverable abends and cancelling jobs brings to mind
an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall
correctly, if a job was cancelled in z/VSE the "dump analysis" product
(Abend-Aid, IBM Fault Analyzer, et al) would still get control and
As someone who spends a considerable amount of time reading dumps,
> I have some requirements for anyone who uses a product like this on a dump
> and then sends the dump to IBM.
>
> 1. You must inform IBM that the dump you are sending has been modified.
>
> 2. You must supp
W dniu 2017-08-14 o 18:29, Ron Hawkins pisze:
Then tell me why my overseas banks contacting me to provide details under FBAR.
What's good for the goose...
Yes, my bank also contacted me in regard of FBAR (or other US
regulation). Neither me nor the bank has businesses in US.
--
Radoslaw Sko
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)
Then tell me why my overseas banks contacting me to provide details under FBAR.
What's good for the goose...
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM
-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDPR for US companies (Was: Scrubbing sensitive data in
dumps)
@Tony, thanks for starting a new thread. I was about to do so, realizing I had
hijacked a perfectly good dump-scrubbing thread.
There was a lot of "how are they going to enforce it on us?&quo
rame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Sunday, August 13, 2017 4:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)
Tony Thigpen wrote:
>In other words, the GDPR can claim to reach in
As someone who spends a considerable amount of time reading dumps,
I have some requirements for anyone who uses a product like this on a dump
and then sends the dump to IBM.
1. You must inform IBM that the dump you are sending has been modified.
2. You must supply a list of all of the
Tony Thigpen wrote:
>In other words, the GDPR can claim to reach into other countries, but
>legally, it can not.
*Legally*, of course they can. GDPR is a set of European Union regulations.
They say what they say.
It's a separate question whether, when, and how the European Union and its
member co
dumps)
> On Aug 12, 2017, at 4:05 PM, Charles Mills wrote:
>
> @Tony, thanks for starting a new thread. I was about to do so, realizing I
> had hijacked a perfectly good dump-scrubbing thread.
>
> There was a lot of "how are they going to enforce it on us?" at the SHA
es
> that said "we have to implement this -- so we might just as well do it for
> all of our customers."
>
> Charles
Charles:
This per se is not about dump scrubbing, but it does have to do with dumps.
In the 1980’s I had a job interview with an unnamed part of the governmen
on List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Thigpen
Sent: Saturday, August 12, 2017 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GDPR for US companies (Was: Scrubbing sensitive data in dumps)
Charles,
Even if the regulation says:
"Non-Eu businesses processing the data of EU citiz
logy is successful in recognizing credit card numbers, SSNs, and so forth. There is more
pattern to a credit card number than just "16 numeric digits.")
These products address files and datasets, but the same pattern recognition
would apply to dumps.
The problem as I see it -- after taking
few years ago `i wrote a program to mask business data from dumps. it
masked Hebrew text, zone decimal numbers (if the are larger then 3 chars)
and some Luhn baed numbers by replacing them with dots on both sides of a
printed dump. I don't have access to the code now, but it is quit simpl
o a credit card
number than just "16 numeric digits.")
These products address files and datasets, but the same pattern recognition
would apply to dumps.
The problem as I see it -- after taking several sessions at SHARE on data
privacy -- is that the definition of "personal
1 - 100 of 140 matches
Mail list logo
