Re: ASCBEJST

[Martin Packer]

I would expect STCK or STCKE. Try bit 51 as 1 microsecond.

Cheers, Martin

Sent from my iPad

> On 29 Sep 2017, at 21:17, Charles Mills  wrote:
> 
> Thanks, @Jim.
> 
> In STCK format? Microseconds * 4096?
> 
> It accumulates through the entire jobstep or started task, without ever
> being reset to zero until the end of the jobstep or STC?
> 
> As you can perhaps infer I have a problem that I have not quite been able to
> put my finger on.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Mulder
> Sent: Friday, September 29, 2017 12:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASCBEJST
> 
>  Yes, it is CPU time, not elapsed time.
> The comment on the field which says "ELAPSED TIME" goes all the way back to
> MVS 3.8. 
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
> Charles Mills  wrote on 09/29/2017 01:12:16 PM:
> 
>> From: Charles Mills 
>> To: ibm-main@listserv.ua.edu
>> Date: 09/29/2017 03:29 PM
>> Subject: ASCBEJST
>> 
>> ASCBEJST -- which *is* documented as a programming interface -- is 
>> documented as "elapsed job step timing." Am I confused or is it 
>> actually "job step TCB CPU time"?
>> 
>> Charles
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Setting up sshd on z/OS

[Tom Brennan]

I installed SSHD a few years back and it wasn't that difficult.  If I 
remember correctly, I ordered and downloaded the Ported Tools product 
via ShopZ (my notes say HOS1120 which was probably the latest at the 
time).  That's a no-charge product from IBM.  I probably used the 
Program Directory instructions, and it was an SMP/E install.  That may 
take some time and a systems programmer.


The result for me was a dozen or so files such as /usr/sbin/sshd 
/bin/sftp /bin/scp and others needed for the processing.  Most likely 
these would be installed into a test ZFS and then copied or migrated to 
a running system following your sysprog's normal methods.  That can also 
take time, and even might involve the dreaded change control folks.


To run the SSHD server, the sysprog will have to create/copy a proc and 
start that task.  There are notes on how to do that in the Program 
Directory I think, and I'm pretty sure it worked for me first time.  My 
notes say this: "To my surprise, SSHD started successfully" :) Starting 
a new STC task on the mainframe typically involves someone who works 
with an Auto Operations product that will start and stop the task at 
every IPL.  One more thing to do.


Then you may need sshd_config modifications, but since I think we're 
running just about the same code used on Unix/Linux machines, almost 
anyone familiar with non-mainframe SSHD should be able to help.


If you're lucky, Ported Tools was already ordered and installed (i.e. 
with ServerPac), and all you need to do is get someone to setup and 
start the SSHD task.  That would make things a lot simpler.


Frank Swarbrick wrote:

We don't currently have sshd setup.  I'm a developer looking to perhaps trial something 
that requires it.  How much effort is it to set up for the first time?  I want to know if 
its worth pushing our Systems group to do, or if I should not bother because I don't yet 
have a "business case" for it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[scott Ford]

Peter,

We have customer that my previous manager provided our exit code to. The
exit is to a non-IBM security system.
The customer with the said code wants to modify a routine we wrote. That
source wasn't provided. The exit can't pass any parameters during
activation, but the customer wants to disable one of our warning messages.
They were asking if the could use a set system symbolic and have our exit
check it for conditional processing, i.e.; turning off warning messages. I
was asking to see if I had another option..since my first posting we came
up with an easier method basically a bit map to set options to pass to our
routine.
Sorry for being vague but this code is our bread and butter so to speak..

Regards,
Scott



On Fri, Sep 29, 2017 at 4:18 PM Dana Mitchell  wrote:

> Slightly OT but.
>
> The FM says:
> A program that calls ASASYMBM can optionally provide user symbols and their
> associated substitution texts in a symbol table. The SYMBPSYMBOLTABLE@
> field, in
> the user parameter area of the ASASYMBP mapping macro, specifies the
> address
> of a symbol table, which is mapped by the SYMBT DSECT.
>
> I wonder why would someone pass a symbol table to this service to have  it
> substitute values for you?
>
> Dana
>
> On Fri, 29 Sep 2017 11:35:32 -0500, Kirk Wolf  wrote:
> >
> >Don't shoot the messenger - I don't like ASASYMBM much either :-)
> >
> >Kirk Wolf
> >Dovetailed Technologies
> >http://dovetail.com
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Setting up sshd on z/OS

[Frank Swarbrick]

We don't currently have sshd setup.  I'm a developer looking to perhaps trial 
something that requires it.  How much effort is it to set up for the first 
time?  I want to know if its worth pushing our Systems group to do, or if I 
should not bother because I don't yet have a "business case" for it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Dana Mitchell]

Slightly OT but.

The FM says:
A program that calls ASASYMBM can optionally provide user symbols and their
associated substitution texts in a symbol table. The SYMBPSYMBOLTABLE@ field, in
the user parameter area of the ASASYMBP mapping macro, specifies the address
of a symbol table, which is mapped by the SYMBT DSECT.

I wonder why would someone pass a symbol table to this service to have  it 
substitute values for you?

Dana

On Fri, 29 Sep 2017 11:35:32 -0500, Kirk Wolf  wrote:
>
>Don't shoot the messenger - I don't like ASASYMBM much either :-)
>
>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ASCBEJST

[Charles Mills]

Thanks, @Jim.

In STCK format? Microseconds * 4096?

It accumulates through the entire jobstep or started task, without ever
being reset to zero until the end of the jobstep or STC?

As you can perhaps infer I have a problem that I have not quite been able to
put my finger on.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Friday, September 29, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASCBEJST

  Yes, it is CPU time, not elapsed time.
The comment on the field which says "ELAPSED TIME" goes all the way back to
MVS 3.8. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

Charles Mills  wrote on 09/29/2017 01:12:16 PM:

> From: Charles Mills 
> To: ibm-main@listserv.ua.edu
> Date: 09/29/2017 03:29 PM
> Subject: ASCBEJST
> 
> ASCBEJST -- which *is* documented as a programming interface -- is 
> documented as "elapsed job step timing." Am I confused or is it 
> actually "job step TCB CPU time"?
> 
> Charles



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SYS1 names (was SYS3 datasets)

[Paul Gilmartin]

On Fri, 29 Sep 2017 16:46:56 +0200, R.S. wrote:

>W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>> ServerPac supplies a number of default names with three qualifiers such as 
>> SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both 
>> redundant and confusing.
>>
>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and 
>> hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>> 2. Who can remember which data set groups have an mlq and which do not?
>>
>> Does anyone attempt to carry these default names forward to production?
>
>Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to
>LLQ, but need not to be.
>Ad 2. It's much better to look at dslist, not to remember.
>
Some systems programmers dislike DDDEFs, intensely.

In some cases, it's stronger than your "usually".  If UCLIN contains:
//SYSLMOD  DD  DSN=hlq.mlq.llq
... llq must be supplied as either a name of a DDDEF in the target zone or
as the name of a DD statement in the APPLY step.  (Is this true for any
DDNAME other than SYSLMOD?)

SMP/E might benefit systems programmers if it provided symbol substitution
in UCLIN an JCLIN.  I have generally followed the practice of a predecessor and
supplied tailoring macros to achieve this effect prior to SUBMIT.  If I had 
known
years ago the concerns discussed in this thread I might have supplied better
defaults.

>Yes, we do carry most of default names, including 3-qualifiers ones. No
>animal was hurt because of that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ASCBEJST

[Jim Mulder]

  Yes, it is CPU time, not elapsed time.
The comment on the field which says "ELAPSED TIME" goes all the
way back to MVS 3.8. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

Charles Mills  wrote on 09/29/2017 01:12:16 PM:

> From: Charles Mills 
> To: ibm-main@listserv.ua.edu
> Date: 09/29/2017 03:29 PM
> Subject: ASCBEJST
> 
> ASCBEJST -- which *is* documented as a programming interface -- is
> documented as "elapsed job step timing." Am I confused or is it actually
> "job step TCB CPU time"?
> 
> Charles



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Paul Gilmartin]

On Fri, 29 Sep 2017 11:35:32 -0500, Kirk Wolf wrote:

>No, but if you give it an input buffer "&THENAME" and the output ends up
>unchanged, then the symbol wasn't found (with RC=0).
>
How can you tell it wasn't found rather than found with value "&THENAME"?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SYS1 names (was SYS3 datasets)

[Edward Gould]

> On Sep 29, 2017, at 9:46 AM, R.S.  wrote:
> 
> W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>> ServerPac supplies a number of default names with three qualifiers such as 
>> SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both 
>> redundant and confusing.
>> 
>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and 
>> hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>> 2. Who can remember which data set groups have an mlq and which do not?
>> 
>> Does anyone attempt to carry these default names forward to production?
> 
> Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to LLQ, but 
> need not to be.
> Ad 2. It's much better to look at dslist, not to remember.
> 
> Yes, we do carry most of default names, including 3-qualifiers ones. No 
> animal was hurt because of that.
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 

Radoslaw:

IBM *used* to use only sys1. Then they slipped a few more in, then a few more 
in and kept increasing it.
I got sick and tired of updating the security product almost every 6 month to 
accommodate these changes. Then the security changed from us to a security 
group. Then all hell broke loose, they basically refused to do the update we 
requested as they became a burden to the group (that was their claim). I 
decided at that point it was easier for me to change than depend on an outside 
entity. I made the decission to hell with IBM naming standards and stay with 
sys1.  
It was easier for me to rename the datasets and recatalog them than for the 
security people to get involved (we had a rock solid sys1 rule). Since I had 
control of all compile procedures as well that was a minor additional work for 
me to do.
The CEE and the ICQ (which we never used) and the others (ISR,ISP etc) were 
better maintained by me and only needed minor work.
I chucked IBM’s PITA naming conventions and never looked back. To this day you 
will not find any of those oddball datasets on any system that I am responsible 
for.
System installs (and blackouts although never used) were always a non event. 
One time I had to almost backout a JES2 change which they did not document but 
I used a PDS mass update programs to fix that.
The Hardcoded names like TCPIP… I had to live with and I have never forgiven 
IBM for doing such an jerky thing. The one exception I had to live with, which 
still boils my blood every time I have to deal with them.
BTW, IMO TCPIP was the starter of the of the evil IBM has set loose on sysprogs 
the world over. 

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

APAR OA53994

[Jesse 1 Robinson]

I just got a notice from ASAP that APAR OA53994 has PEed PTF UA91904 ,  which 
we installed in July. It looks pretty serious: records dropped at the end of an 
extended format sequential file. We have had no reports of such a problem, but 
it's pretty worrying. Has anyone stumbled on this crack in the sidewalk?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ASCBEJST

[Charles Mills]

ASCBEJST -- which *is* documented as a programming interface -- is
documented as "elapsed job step timing." Am I confused or is it actually
"job step TCB CPU time"?

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Kirk Wolf]

No, but if you give it an input buffer "&THENAME" and the output ends up
unchanged, then the symbol wasn't found (with RC=0).

Don't shoot the messenger - I don't like ASASYMBM much either :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Sep 29, 2017 at 10:41 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 29 Sep 2017 00:41:21 -0400, Peter Relson wrote:
>
> >>we need to query these symbolic names from an exit.
> >
> >really? care to share why? It is quite unusual to have to "query" a system
> >symbol.
> >
> >The case I usually think of is "I have a string, I support symbolics, I
> >call the symbol substitution service to do whatever it, according to its
> >documentation, chooses to do".
> >And if the customer used a symbol that they had failed to define, then
> >they get what they get, which is usually something that has bad syntax
> >because "&SYM" is not usually what a parser would be looking for.
> >
> Does that symbol substitution service indicate, via a return code, that it
> failed to find a definition for the symbol?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Paul Gilmartin]

On Fri, 29 Sep 2017 00:41:21 -0400, Peter Relson wrote:

>>we need to query these symbolic names from an exit.
>
>really? care to share why? It is quite unusual to have to "query" a system 
>symbol.
>
>The case I usually think of is "I have a string, I support symbolics, I 
>call the symbol substitution service to do whatever it, according to its 
>documentation, chooses to do".
>And if the customer used a symbol that they had failed to define, then 
>they get what they get, which is usually something that has bad syntax 
>because "&SYM" is not usually what a parser would be looking for.
> 
Does that symbol substitution service indicate, via a return code, that it
failed to find a definition for the symbol?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Steve Smith]

SDSF (at least on the systems I can access) has a SYM command that
shows them all.  MXI (unsurprisingly) also does.

sas

On Fri, Sep 29, 2017 at 10:52 AM, Nims,Alva John (Al)  wrote:
> I might be offering information that may mean anything, but have you looked 
> at Mark Zelden's IPLINFO REXX code, he lists the system symbols (find 
> "symbols:" in the code).
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Symbols Question

[Nims,Alva John (Al)]

I might be offering information that may mean anything, but have you looked at 
Mark Zelden's IPLINFO REXX code, he lists the system symbols (find "symbols:" 
in the code).

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Friday, September 29, 2017 12:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Symbols Question

>we need to query these symbolic names from an exit.

really? care to share why? It is quite unusual to have to "query" a system 
symbol.

The case I usually think of is "I have a string, I support symbolics, I call 
the symbol substitution service to do whatever it, according to its 
documentation, chooses to do".
And if the customer used a symbol that they had failed to define, then they get 
what they get, which is usually something that has bad syntax because "&SYM" is 
not usually what a parser would be looking for.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SYS1 names (was SYS3 datasets)

[R.S.]

W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:

ServerPac supplies a number of default names with three qualifiers such as 
SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both 
redundant and confusing.

1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and 
hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
2. Who can remember which data set groups have an mlq and which do not?

Does anyone attempt to carry these default names forward to production?


Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to 
LLQ, but need not to be.

Ad 2. It's much better to look at dslist, not to remember.

Yes, we do carry most of default names, including 3-qualifiers ones. No 
animal was hurt because of that.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Last SAD (was: DLIB volume for SAD)

[Ronald Kristel]

With the exception of the required SAD every 3 months due to training/audit, We 
had to SAD roughly once a year for 'real'.

Ronald Kristel

From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, September 29, 2017 4:05:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Last SAD (was: DLIB volume for SAD)

On Fri, 29 Sep 2017 12:59:56 +, van der Grijn, Bart (B) 
 wrote:

>Had to? Can't remember that far back. We've had an LPAR fail, autoipl SAD and 
>then autoipl z/OS in
> the last couple of years, but we didn't need the actual SAD to determine the 
> cause/solution.
>Bart

That's a good point.  In my post I mentioned an SAD last week I took of a 
sandbox LPAR when
it went into a wait at IPL time.  In pre-2074 / OSA-ICC days I would have seen 
the NIP message
on a console, but with OSA-ICC the console just clears and goes back to the 
connection
screen.  I took the SADUMP just to see the wait message / module / reason code.


Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Last SAD (was: DLIB volume for SAD)

[Mark Zelden]

On Fri, 29 Sep 2017 12:59:56 +, van der Grijn, Bart (B) 
 wrote:

>Had to? Can't remember that far back. We've had an LPAR fail, autoipl SAD and 
>then autoipl z/OS in
> the last couple of years, but we didn't need the actual SAD to determine the 
> cause/solution. 
>Bart 

That's a good point.  In my post I mentioned an SAD last week I took of a 
sandbox LPAR when
it went into a wait at IPL time.  In pre-2074 / OSA-ICC days I would have seen 
the NIP message
on a console, but with OSA-ICC the console just clears and goes back to the 
connection 
screen.  I took the SADUMP just to see the wait message / module / reason code.


Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Last SAD (was: DLIB volume for SAD)

[van der Grijn, Bart (B)]

Had to? Can't remember that far back. We've had an LPAR fail, autoipl SAD and 
then autoipl z/OS in the last couple of years, but we didn't need the actual 
SAD to determine the cause/solution.
Bart

-Original Message-


>A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
>haven’t done one in 20+ years.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Last SAD (was: DLIB volume for SAD)

[R.S.]

W dniu 2017-09-28 o 20:01, Art Gutowski pisze:

"Steely.Mark"  asked:


A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
haven’t done one in 20+ years.
  
We've taken at least a couple in the last 4 years.  I don't recall the exact circumstances (lots of brush fires early in the transition), but on at least one occasion, IIRC, we were still working through firewall issues and had a hard time getting the dump to IBM.


I *NEVER* did it except training purposes. That mean ~18 years.

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN