Re: SMF/RMF Reporting question

[Bob Rutledge]

IBM Mainframe Discussion List  wrote on 
11/20/2015 07:22:44 AM:

> From: "Hardee, Chuck" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/20/2015 07:23 AM
> Subject: SMF/RMF Reporting question
> Sent by: IBM Mainframe Discussion List 
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, 
> after an event has occurred, what units of work were using how much 
> of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in 
> increments of y units, what was the consumption of CPU on a unit of 
> work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU 
> consumption in a context similar to the SDSF DA screen as one sits 
> at their terminal and presses the enter key.

Within RMF/SMF, the only thing I can think of is the RMF Monitor III 
Processor Usage report.

Bob

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

Re: SMF/RMF Reporting question

[Hardee, Chuck]

I have access and knowledge of SysView and SDSF.
What our system programmers have I do not know.
I'm thinking no, because their first attempt at giving me what I need was to 
use SysView.


Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, November 20, 2015 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

Do you have any tools like SAS/MICS or SAS/MXG?
Any monitoring tools like Tivoli Omegamon, MainView?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 5:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF/RMF Reporting question
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, after an
event has
> occurred, what units of work were using how much of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in increments of
y
> units, what was the consumption of CPU on a unit of work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU consumption
in a
> context similar to the SDSF DA screen as one sits at their terminal and
presses the
> enter key.
> 
> We are trying to find out who, during a specific interval of the day, was
consuming
> the greatest amount of CPU to the ultimate effect that it essentially stopped
one of
> our database regions from executing and thereby causing it to think some of
its
> subtasks had gone into a runaway CPU condition so it aborted them as a
preemptive
> action against bad coding. We know that the code is good, it's been literally
running
> for years with no changes and, until the last couple of weeks, has had not a
single
> hiccup. Over the last couple of weeks, for no reason we can identify as of
yet, the
> code has randomly been aborted by the database software in which it runs, as a
> runaway task.
> 
> The theory is that the runaway check process is actually reporting a false
condition
> since it is based on wall clock time (this is vendor code, not ours and I'm
not going to
> debate it one way or another). What the vendor theorizes is that another task
in the
> system, yet to be identified, has stolen the CPU away from the database and
held on
> to it long enough such that when the database finally regained access to the
CPU,
> the runaway interval had been exceeded by the internal task executing our code
so it
> was aborted for a potential loop within the code.
> 
> The database vendor has suggested looking for this kind of information in
order to
> confirm or deny that the database had the CPU it needed or if another task
within
> the LPAR had control. If we find that the database had the CPU, then the
vendor has
> more analysis work to do on the dump with a more powerful magnifying glass, or
we
> have to turn our sights on someone else, either ourselves or, possibly,
another
> vendor for another product.
> 
> Thanks for any thoughts you may have on this.
> Chuck
> 
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  |
> www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this
> e-mail or the information herein by anyone other than the intended recipient,
or an
> employee or agent of a system responsible for delivering the message to the
> intended recipient, is prohibited. If you are not the intended recipient,
please inform
> the sender and delete all copies.
> 
> 
> --
> 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: 

Re: Deleting all members of a pds

[Brenton, Ren]

Address "ISPEXEC" "LMINIT DATAID(FDTID) DATASET('"dsn"') ENQ(SHRW)"   
Address "ISPEXEC" "LMOPEN DATAID("fdtid") OPTION(OUTPUT)" 
Address "ISPEXEC" "LMMLIST DATAID("fdtid") MEMBER(MEMNM)" 
Do While cc = 0   
   Address "ISPEXEC" "LMMDEL DATAID("fdtid") MEMBER("memnm") NOENQ"   
   cc = rc
   Address "ISPEXEC" "LMMLIST DATAID("fdtid") MEMBER(MEMNM)"  
   cc = rc
End   
Address "ISPEXEC" "LMCLOSE DATAID("fdtid")"   
Address "ISPEXEC" "LMFREE DATAID("fdtid")"

Ren
Ext 1448

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, November 20, 2015 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Re: Deleting all members of a pds

Peter Hunkeler wrote:

>>(Had you come to SHARE, you might have known that--hint, hint. ;-)

>Re: hint, hint, John, would you find some time to convince our upper level 
>management of many companies of the value of SHARE, etc?

Hint, hint - the rarity of money beats the value of SHARE by a full knock-out...

>Sorry, could not resist.

Neither me. ;-)

Groete / Greetings
Elardus Engelbrecht

PS: I know it is good to attend the SHARE in the sense you get information way 
before others and thus getting an advantage.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


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

Re: SMF/RMF Reporting question

[Elardus Engelbrecht]

Staller, Allan wrote:

>Sounds like you need to enable SMF Interval Recording  (SYS(...(INTERVAL)) in 
>SMFPRMxx. Set the interval as low as needed. Can be enabled/disabled 
>dynamically to limit the amount of type 30 (1,2,6) and RMF records written to 
>SMF.

Also look at ERBRMFxx for these two: SYNC(RMF,) and INTERVAL().

>As another has suggested, RMF III can also provide some good insights.

Indeed.

Groete / Greetings
Elardus Engelbrecht

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

Re: SMF/RMF Reporting question

[Lizette Koehler]

And if you have not set this up, the RMF Spread Sheet Reporter might be helpful

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD106241

This recorded demonstration show how to install and setup the RMF Spreadsheet
Reporter and how to run the IO Queueing report to obtain performance information
related to Hyper PAV usage on the DS8000

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.erbb
200/rpp.htm
The RMFT Spreadsheet Reporter is the powerful workstation solution for graphical
presentation of RMF Postprocessor data. Use it to convert your RMF data to
spreadsheet format and generate representative charts for all performance
relevant areas.

The RMF Spreadsheet Reporter offers the following features:

ease of use - manage the related resources by means of an Explorer-like GUI
fast path to graphical presentation - prepare the SMF data in one single
step
batch mode - generate the input files for the spreadsheets without any GUI
interaction

AFAIK - No charge item, downloads RMF reports to the PC to run under a Java App

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, November 20, 2015 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF/RMF Reporting question
> 
> Do you have any tools like SAS/MICS or SAS/MXG?
> Any monitoring tools like Tivoli Omegamon, MainView?
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Hardee, Chuck
> > Sent: Friday, November 20, 2015 5:23 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SMF/RMF Reporting question
> >
> > Hello Everyone,
> >
> > I am trying to find, from a historical perspective, that is to say,
> > after an
> event has
> > occurred, what units of work were using how much of the available CPU.
> > Is there an SMF and/or RMF report that allows on to ask,
> >
> > "During the interval from hh:mm to hh:mm on a particular day, in
> > increments of
> y
> > units, what was the consumption of CPU on a unit of work basis?"
> >
> > Another way to put it is, I am looking for a report that shows CPU
> > consumption
> in a
> > context similar to the SDSF DA screen as one sits at their terminal
> > and
> presses the
> > enter key.
> >
> > We are trying to find out who, during a specific interval of the day,
> > was
> consuming
> > the greatest amount of CPU to the ultimate effect that it essentially
> > stopped
> one of
> > our database regions from executing and thereby causing it to think
> > some of
> its
> > subtasks had gone into a runaway CPU condition so it aborted them as a
> preemptive
> > action against bad coding. We know that the code is good, it's been
> > literally
> running
> > for years with no changes and, until the last couple of weeks, has had
> > not a
> single
> > hiccup. Over the last couple of weeks, for no reason we can identify
> > as of
> yet, the
> > code has randomly been aborted by the database software in which it
> > runs, as a runaway task.
> >
> > The theory is that the runaway check process is actually reporting a
> > false
> condition
> > since it is based on wall clock time (this is vendor code, not ours
> > and I'm
> not going to
> > debate it one way or another). What the vendor theorizes is that
> > another task
> in the
> > system, yet to be identified, has stolen the CPU away from the
> > database and
> held on
> > to it long enough such that when the database finally regained access
> > to the
> CPU,
> > the runaway interval had been exceeded by the internal task executing
> > our code
> so it
> > was aborted for a potential loop within the code.
> >
> > The database vendor has suggested looking for this kind of information
> > in
> order to
> > confirm or deny that the database had the CPU it needed or if another
> > task
> within
> > the LPAR had control. If we find that the database had the CPU, then
> > the
> vendor has
> > more analysis work to do on the dump with a more powerful magnifying
> > glass, or
> we
> > have to turn our sights on someone else, either ourselves or,
> > possibly,
> another
> > vendor for another product.
> >
> > Thanks for any thoughts you may have on this.
> > Chuck
> >
> >
> > Charles (Chuck) Hardee
> > Senior Systems Engineer/Database Administration EAS Information
> > Technology
> >
> > Thermo Fisher Scientific
> > 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 |
> > Mobile +1
> (412)
> > 877-2809 | FAX: +1 (412) 490-9230
> > chuck.har...@thermofisher.com  |
> > www.thermofisher.com
> >

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

Cobollin'

[Mark Regan]

A hip-hop look at mainframe computing and COBOL Programming.

https://www.youtube.com/watch?v=uKG0IEyeZb0=youtu.be

Mark T. Regan, K8MTR

CTO1, USNR-Retired
1969-1991

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

Re: SMF/RMF Reporting question

[Hardee, Chuck]

Thanks Bob. I'll see if my system programmers know how to run the report.



Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Rutledge
Sent: Friday, November 20, 2015 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

IBM Mainframe Discussion List  wrote on 
11/20/2015 07:22:44 AM:

> From: "Hardee, Chuck" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/20/2015 07:23 AM
> Subject: SMF/RMF Reporting question
> Sent by: IBM Mainframe Discussion List 
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, 
> after an event has occurred, what units of work were using how much 
> of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in 
> increments of y units, what was the consumption of CPU on a unit of 
> work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU 
> consumption in a context similar to the SDSF DA screen as one sits 
> at their terminal and presses the enter key.

Within RMF/SMF, the only thing I can think of is the RMF Monitor III 
Processor Usage report.

Bob

--
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: SMF/RMF Reporting question

[Staller, Allan]

Sounds like you need to enable SMF Interval Recording  (SYS(...(INTERVAL)) in 
SMFPRMxx. Set the interval as low as needed.
Can be enabled/disabled dynamically to limit the amount of type 30 (1,2,6) and 
RMF records written to SMF.

As another has suggested, RMF III can also provide some good insights.

HTH,


I am trying to find, from a historical perspective, that is to say, after an 
event has occurred, what units of work were using how much of the available CPU.
Is there an SMF and/or RMF report that allows on to ask,

"During the interval from hh:mm to hh:mm on a particular day, in increments of 
y units, what was the consumption of CPU on a unit of work basis?"

Another way to put it is, I am looking for a report that shows CPU consumption 
in a context similar to the SDSF DA screen as one sits at their terminal and 
presses the enter key.

We are trying to find out who, during a specific interval of the day, was 
consuming the greatest amount of CPU to the ultimate effect that it essentially 
stopped one of our database regions from executing and thereby causing it to 
think some of its subtasks had gone into a runaway CPU condition so it aborted 
them as a preemptive action against bad coding. We know that the code is good, 
it's been literally running for years with no changes and, until the last 
couple of weeks, has had not a single hiccup. Over the last couple of weeks, 
for no reason we can identify as of yet, the code has randomly been aborted by 
the database software in which it runs, as a runaway task.

The theory is that the runaway check process is actually reporting a false 
condition since it is based on wall clock time (this is vendor code, not ours 
and I'm not going to debate it one way or another). What the vendor theorizes 
is that another task in the system, yet to be identified, has stolen the CPU 
away from the database and held on to it long enough such that when the 
database finally regained access to the CPU, the runaway interval had been 
exceeded by the internal task executing our code so it was aborted for a 
potential loop within the code.

The database vendor has suggested looking for this kind of information in order 
to confirm or deny that the database had the CPU it needed or if another task 
within the LPAR had control. If we find that the database had the CPU, then the 
vendor has more analysis work to do on the dump with a more powerful magnifying 
glass, or we have to turn our sights on someone else, either ourselves or, 
possibly, another vendor for another product.


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

Re: 3DES encryption using ICSF callable services

[Todd Arnold]

> Actually ICSF provides both open and secure key encryption services.

Yes - mainly, those were added so that applications would have a way to use 
ICSF for clear-key encryption with the CPACF.  Those were not originally a part 
of CCA, and are not supported in the HSM cards (Crypto Express, 476x).  In 
addition, CCA has always had clear key "ENCODE" and "DECODE" verbs, but those 
were intentionally limited to encrypting just 8 bytes of data - the original 
designers wanted to discourage use of clear key encryption.

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

Re: SMF/RMF Reporting question

[Lizette Koehler]

Do you have any tools like SAS/MICS or SAS/MXG?
Any monitoring tools like Tivoli Omegamon, MainView?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 5:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF/RMF Reporting question
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, after an
event has
> occurred, what units of work were using how much of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in increments of
y
> units, what was the consumption of CPU on a unit of work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU consumption
in a
> context similar to the SDSF DA screen as one sits at their terminal and
presses the
> enter key.
> 
> We are trying to find out who, during a specific interval of the day, was
consuming
> the greatest amount of CPU to the ultimate effect that it essentially stopped
one of
> our database regions from executing and thereby causing it to think some of
its
> subtasks had gone into a runaway CPU condition so it aborted them as a
preemptive
> action against bad coding. We know that the code is good, it's been literally
running
> for years with no changes and, until the last couple of weeks, has had not a
single
> hiccup. Over the last couple of weeks, for no reason we can identify as of
yet, the
> code has randomly been aborted by the database software in which it runs, as a
> runaway task.
> 
> The theory is that the runaway check process is actually reporting a false
condition
> since it is based on wall clock time (this is vendor code, not ours and I'm
not going to
> debate it one way or another). What the vendor theorizes is that another task
in the
> system, yet to be identified, has stolen the CPU away from the database and
held on
> to it long enough such that when the database finally regained access to the
CPU,
> the runaway interval had been exceeded by the internal task executing our code
so it
> was aborted for a potential loop within the code.
> 
> The database vendor has suggested looking for this kind of information in
order to
> confirm or deny that the database had the CPU it needed or if another task
within
> the LPAR had control. If we find that the database had the CPU, then the
vendor has
> more analysis work to do on the dump with a more powerful magnifying glass, or
we
> have to turn our sights on someone else, either ourselves or, possibly,
another
> vendor for another product.
> 
> Thanks for any thoughts you may have on this.
> Chuck
> 
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  |
> www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this
> e-mail or the information herein by anyone other than the intended recipient,
or an
> employee or agent of a system responsible for delivering the message to the
> intended recipient, is prohibited. If you are not the intended recipient,
please inform
> the sender and delete all copies.
> 
> 
> --
> 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: SMF/RMF Reporting question

[Hardee, Chuck]

I will have to look into this.
Thanks!

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, November 20, 2015 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

And if you have not set this up, the RMF Spread Sheet Reporter might be helpful

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD106241

This recorded demonstration show how to install and setup the RMF Spreadsheet
Reporter and how to run the IO Queueing report to obtain performance information
related to Hyper PAV usage on the DS8000

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.erbb
200/rpp.htm
The RMFT Spreadsheet Reporter is the powerful workstation solution for graphical
presentation of RMF Postprocessor data. Use it to convert your RMF data to
spreadsheet format and generate representative charts for all performance
relevant areas.

The RMF Spreadsheet Reporter offers the following features:

ease of use - manage the related resources by means of an Explorer-like GUI
fast path to graphical presentation - prepare the SMF data in one single
step
batch mode - generate the input files for the spreadsheets without any GUI
interaction

AFAIK - No charge item, downloads RMF reports to the PC to run under a Java App

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, November 20, 2015 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF/RMF Reporting question
> 
> Do you have any tools like SAS/MICS or SAS/MXG?
> Any monitoring tools like Tivoli Omegamon, MainView?
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Hardee, Chuck
> > Sent: Friday, November 20, 2015 5:23 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SMF/RMF Reporting question
> >
> > Hello Everyone,
> >
> > I am trying to find, from a historical perspective, that is to say,
> > after an
> event has
> > occurred, what units of work were using how much of the available CPU.
> > Is there an SMF and/or RMF report that allows on to ask,
> >
> > "During the interval from hh:mm to hh:mm on a particular day, in
> > increments of
> y
> > units, what was the consumption of CPU on a unit of work basis?"
> >
> > Another way to put it is, I am looking for a report that shows CPU
> > consumption
> in a
> > context similar to the SDSF DA screen as one sits at their terminal
> > and
> presses the
> > enter key.
> >
> > We are trying to find out who, during a specific interval of the day,
> > was
> consuming
> > the greatest amount of CPU to the ultimate effect that it essentially
> > stopped
> one of
> > our database regions from executing and thereby causing it to think
> > some of
> its
> > subtasks had gone into a runaway CPU condition so it aborted them as a
> preemptive
> > action against bad coding. We know that the code is good, it's been
> > literally
> running
> > for years with no changes and, until the last couple of weeks, has had
> > not a
> single
> > hiccup. Over the last couple of weeks, for no reason we can identify
> > as of
> yet, the
> > code has randomly been aborted by the database software in which it
> > runs, as a runaway task.
> >
> > The theory is that the runaway check process is actually reporting a
> > false
> condition
> > since it is based on wall clock time (this is vendor code, not ours
> > and I'm
> not going to
> > debate it one way or another). What the vendor theorizes is that
> > another task
> in the
> > system, yet to be identified, has stolen the CPU away from the
> > database and
> held on
> > to it long enough such that when the database finally regained access
> > to the
> CPU,
> > the runaway interval had been exceeded by the internal task executing
> > our code
> so it
> > was aborted for a potential loop within the code.
> >
> > The database vendor has suggested looking for this kind of information
> > in
> order to
> > confirm or deny that the database had the CPU it needed or if another
> > task
> within
> > the LPAR had control. If we find that the database had the CPU, then
> > the
> vendor has
> > more analysis work to do on 

Re: Deleting all members of a pds

[Brenton, Ren]

Forgot the initial CC = 0 line some where before line 4

Ren
Ext 1448

-Original Message-
From: Brenton, Ren 
Sent: Friday, November 20, 2015 9:37 AM
To: 'IBM Mainframe Discussion List' 
Subject: Re: Deleting all members of a pds

Address "ISPEXEC" "LMINIT DATAID(FDTID) DATASET('"dsn"') ENQ(SHRW)"   
Address "ISPEXEC" "LMOPEN DATAID("fdtid") OPTION(OUTPUT)" 
Address "ISPEXEC" "LMMLIST DATAID("fdtid") MEMBER(MEMNM)" 
Do While cc = 0   
   Address "ISPEXEC" "LMMDEL DATAID("fdtid") MEMBER("memnm") NOENQ"   
   cc = rc
   Address "ISPEXEC" "LMMLIST DATAID("fdtid") MEMBER(MEMNM)"  
   cc = rc
End   
Address "ISPEXEC" "LMCLOSE DATAID("fdtid")"   
Address "ISPEXEC" "LMFREE DATAID("fdtid")"

Ren
Ext 1448

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, November 20, 2015 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Re: Deleting all members of a pds

Peter Hunkeler wrote:

>>(Had you come to SHARE, you might have known that--hint, hint. ;-)

>Re: hint, hint, John, would you find some time to convince our upper level 
>management of many companies of the value of SHARE, etc?

Hint, hint - the rarity of money beats the value of SHARE by a full knock-out...

>Sorry, could not resist.

Neither me. ;-)

Groete / Greetings
Elardus Engelbrecht

PS: I know it is good to attend the SHARE in the sense you get information way 
before others and thus getting an advantage.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


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

Re: Deleting all members of a pds

[Sri h Kolusu]

>>I looked at that.  It builds a list of IDCAMS commands to delete the 
members one-by-one.

Well the deletion of all members of a PDS DFSORT trick is written when 
IDCAMS did not support the Wild card deletion function on PDS members. So 
DFSORT chose the traditional method of deleting the members.  The new 
features are written based on the customers needs and  if a customer is 
upto date with the latest features then he can use IDCAMS wild card 
deletion. We just keep on adding new tricks of DFSORT and never delete off 
any trick from that document.

Similarly DFSORT had another trick of reading GDG generations in FIFO 
order and with z/OS 2.1 the system itself supports the FIFO parm.  So the 
new enhancements gives you an alternative solution and the customer is 
wise to chose the optimal solution. 

>>>Does it at least sort the list in descending order? 

Descending order of what? member names or Size? Why exactly do you need to 
sort the list ? Do you think it would make a difference to the directory 
blocks? And just for the record as DFSORT is capable of sorting the member 
names in either ascending/descending order.

Thanks,
Kolusu
DFSORT Development




From:   Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/19/2015 05:30 PM
Subject:Re: Deleting all members of a pds
Sent by:IBM Mainframe Discussion List 



On 2015-11-19 15:04, R.S. wrote:
> W dniu 2015-11-19 o 22:42, John Mattson pisze:
>> Someone was asking about deleting all members of a pds.  I just noticed
>> that DFSort has a bunch of "samples" one of which includes how to use
>> ICETOOL to delete all members of a PDS.  Hope this helps.  Lots of 
other
>> neat things in here too.
>> http://www-01.ibm.com/support/docview.wss?uid=isg3T794
> Smart DFSORT tricks! 
>
I looked at that.  It builds a list of IDCAMS commands to delete the 
members
one-by-one.  Now that there are better techniques, it becomes less smart.
Does it at least sort the list in descending order?  Does IDCAMS
DELETE DATA.SET.NAME(*)
use STOW ,,I?

> I was really proud to be one of the tricks authors!
> Recently I was placed in some redpaper about exploitation of large 
amount of memory, again it was related to DFSORT.
> :-)
> 

--
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: AW: Re: Deleting all members of a pds

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>>(Had you come to SHARE, you might have known that--hint, hint. ;-)

>Re: hint, hint, John, would you find some time to convince our upper level 
>management of many companies of the value of SHARE, etc?

Hint, hint - the rarity of money beats the value of SHARE by a full knock-out...

>Sorry, could not resist.

Neither me. ;-)

Groete / Greetings 
Elardus Engelbrecht

PS: I know it is good to attend the SHARE in the sense you get information way 
before others and thus getting an advantage.

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

AW: Re: Deleting all members of a pds

[Peter Hunkeler]

>(Had you come to SHARE, you might have known that--hint, hint. ;-)


Re: hint, hint, John, would you find some time to convince our upper level 
management of many companies of the value of SHARE, etc?


Sorry, could not resist.


--
Peter Hunkeler




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

Re: Deleting all members of a pds

[John Eells]

For the curious, IDCAMS does indeed use STOW (with I) to delete all the 
members of a PDS or PDSE. This is not only fast, but it eliminates any 
need to compress a PDS afterward. (Had you come to SHARE, you might have 
known that--hint, hint. ;-)


Also, this function has been available since z/OS V1.12, so everybody 
running on a supported release can use it.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

SMF/RMF Reporting question

[Hardee, Chuck]

Hello Everyone,

I am trying to find, from a historical perspective, that is to say, after an 
event has occurred, what units of work were using how much of the available CPU.
Is there an SMF and/or RMF report that allows on to ask,

"During the interval from hh:mm to hh:mm on a particular day, in increments of 
y units, what was the consumption of CPU on a unit of work basis?"

Another way to put it is, I am looking for a report that shows CPU consumption 
in a context similar to the SDSF DA screen as one sits at their terminal and 
presses the enter key.

We are trying to find out who, during a specific interval of the day, was 
consuming the greatest amount of CPU to the ultimate effect that it essentially 
stopped one of our database regions from executing and thereby causing it to 
think some of its subtasks had gone into a runaway CPU condition so it aborted 
them as a preemptive action against bad coding. We know that the code is good, 
it's been literally running for years with no changes and, until the last 
couple of weeks, has had not a single hiccup. Over the last couple of weeks, 
for no reason we can identify as of yet, the code has randomly been aborted by 
the database software in which it runs, as a runaway task.

The theory is that the runaway check process is actually reporting a false 
condition since it is based on wall clock time (this is vendor code, not ours 
and I'm not going to debate it one way or another). What the vendor theorizes 
is that another task in the system, yet to be identified, has stolen the CPU 
away from the database and held on to it long enough such that when the 
database finally regained access to the CPU, the runaway interval had been 
exceeded by the internal task executing our code so it was aborted for a 
potential loop within the code.

The database vendor has suggested looking for this kind of information in order 
to confirm or deny that the database had the CPU it needed or if another task 
within the LPAR had control. If we find that the database had the CPU, then the 
vendor has more analysis work to do on the dump with a more powerful magnifying 
glass, or we have to turn our sights on someone else, either ourselves or, 
possibly, another vendor for another product.

Thanks for any thoughts you may have on this.
Chuck


Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | 
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


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

Re: Deleting all members of a pds

[Paul Gilmartin]

On Fri, 20 Nov 2015 08:11:08 -0700, Sri h Kolusu wrote:

>>>I looked at that.  It builds a list of IDCAMS commands to delete the 
>members one-by-one.
>
>Well the deletion of all members of a PDS DFSORT trick is written when 
>IDCAMS did not support the Wild card deletion function on PDS members. So 
>DFSORT chose the traditional method of deleting the members.  The new 
>features are written based on the customers needs and  if a customer is 
>upto date with the latest features then he can use IDCAMS wild card 
>deletion. We just keep on adding new tricks of DFSORT and never delete off 
>any trick from that document.
>
>Similarly DFSORT had another trick of reading GDG generations in FIFO 
>order and with z/OS 2.1 the system itself supports the FIFO parm.  So the 
>new enhancements gives you an alternative solution and the customer is 
>wise to chose the optimal solution. 
> 
When better techniques become available, perhaps the inferior ones should
me marked in future editions as deprecated.

But, yes, they continue to have instructional value, at least as syntax 
examples.

Does it at least sort the list in descending order? 
>
>Descending order of what? member names or Size? Why exactly do you need to 
>sort the list ? Do you think it would make a difference to the directory 
>blocks? And just for the record as DFSORT is capable of sorting the member 
>names in either ascending/descending order.
>
Member names.  I believe that when the alphabetically first member is deleted
all following directory blocks (not data blocks) are rewritten to fill the gap, 
an
unwelcome quadratic behavior.  Deleting the last member requires rewriting only
the last active directory block.  (Yes, I thought this would be a natural 
application
of DFSORT.  I bet DFSORT is faster than quadratic time.)

Thanks,
gil

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

Re: Deleting all members of a pds

[Tom Marchant]

On Fri, 20 Nov 2015 08:11:08 -0700, Sri h Kolusu wrote:

Does it at least sort the list in descending order? 
>
>Descending order of what? member names or Size? Why exactly do you need to 
>sort the list ? Do you think it would make a difference to the directory 
>blocks?

Member names. The reason would be that a PDS directory is maintained in order, 
and the directory is always kept compressed.

Whenever a member is deleted from a PDS, the following directory entries are 
all 
shifted to the left. Then, if there is enough space at the end of that 
directory 
block, the first entry from the next block is moved to that space, and the 
process 
repeats to the end of the directory.

As a result, there is less I/O if they are deleted starting at the end of the 
directory. 
This is especially true if there are a lot of members in the PDS.

-- 
Tom Marchant

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

Re: Cobollin'

[Ken Hume IBM]

What did I just watch

Did you notice there is not a COBOL programmer listed in the credits?

Ken


-Original Message- 
From: Mark Regan 
Sent: Friday, November 20, 2015 7:43 AM Newsgroups: bit.listserv.ibm-main 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Cobollin' 


A hip-hop look at mainframe computing and COBOL Programming.

https://www.youtube.com/watch?v=uKG0IEyeZb0=youtu.be

Mark T. Regan, K8MTR

CTO1, USNR-Retired
1969-1991

--
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: Deleting all members of a pds

[Paul Gilmartin]

On Fri, 20 Nov 2015 06:58:42 -0500, John Eells wrote:

>For the curious, IDCAMS does indeed use STOW (with I) to delete all the
>members of a PDS or PDSE. This is not only fast, but it eliminates any
>need to compress a PDS afterward. (Had you come to SHARE, you might have
>known that--hint, hint. ;-)
> 
I understand that the old CBT technique for PDS (doesn't work for PDSE)
writes 8x'FF' at the beginning of the directory, then EOF at the beginning
of the data area (and/or resets DS1LSTAR?)  No compression should be
necessary.

>Also, this function has been available since z/OS V1.12, so everybody
>running on a supported release can use it.
>
So many inferior alternatives have been suggested in this thread that I
submitted an RCF, even though it comes uncomfortably close to a
discussion of internals:

Hello, MHVRCFs,

In:

Required Parameters (for the DELETE command)

z/OS DFSMS Access Method Services Commands
SC23-6846-01

I read:

   If a member in the list matches the filter criteria, the member is
   deleted. If you specify the entryname in the format of a partition[ed]
   data set, pdsname(*) or pdsname(**) , the command deletes all the
   members in the partition data set. If the partitioned[ed] data set is
   not a PDSE, the directory is reinitailized when using pdsname(*) , but
   not for pdsname(**).

(Spelling suggestions in "[...]")

This ought to mention that IDCAMS DELETE pdsname(*) uses a highly efficient
technique and programmers should prefer it over other techniques, even some
which remain described in other (obsolescent) IBM publications.

(How does one delete all members of a non-PDSE without reinitializing the
directory?  It seems that 8x'FF' must be written at the beginning, and then
the directory is de facto initialized.  Does "reinitialized" mean that
all further directory blocks are overwritten (with binary zeroes?) to
remove any residual data?)

Thanks,
gil

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

Re: Deleting all members of a pds

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, November 20, 2015 8:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Deleting all members of a pds
> 


> When better techniques become available, perhaps the inferior ones should
> me marked in future editions as deprecated.

So every time IBM makes an update to a marketed product, they should search all 
the freebies to see if they might need some pedantic update to the code or 
documentation?  It's not enough that IBM allows people to spend time on the 
clock to develop this stuff for which they will not charge and make it 
available to all, even non-customers and competitors?  That would probably kill 
the incentive to release any "as is/no warranty or support" tools of any kind.
 
> But, yes, they continue to have instructional value, at least as syntax 
> examples.
> 
> Does it at least sort the list in descending order?
> >
> >Descending order of what? member names or Size? Why exactly do you need to
> >sort the list ? Do you think it would make a difference to the directory
> >blocks? And just for the record as DFSORT is capable of sorting the member
> >names in either ascending/descending order.
> >
> Member names.  I believe that when the alphabetically first member is deleted
> all following directory blocks (not data blocks) are rewritten to fill the 
> gap, an
> unwelcome quadratic behavior.  Deleting the last member requires rewriting 
> only
> the last active directory block.  (Yes, I thought this would be a natural 
> application
> of DFSORT.  I bet DFSORT is faster than quadratic time.)

Didn't anyone read the reference?  On page 84:  " For PDSs with lots of 
members, you can improve the performance of the IDCAMS step by deleting the 
members in reverse order. To do this, just add:
SORT FIELDS=(1,8,CH,D)
to CTL2CNTL to sort the members in descending order.

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

Re: Should utilities FREE DDNAMEs?

[Charles Mills]

I think the first principle. A module saves registers on the way in and 
restores them on the way out. In other words, it leaves the environment as it 
found it (other than whatever chore it was supposed to perform).

I am kind of surprised at the behavior you see. Freeing a DD name takes a 
certain amount of effort -- and very non-trivial effort at the time IEBGENER 
first came to life. IEBGENER especially was written 99% to run as a jobstep 
program where freeing a DD would be pointless.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, November 20, 2015 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Should utilities FREE DDNAMEs?

In a program, I am passed a DDNAME allocated by another program.

I'd like to use it twice, once as IEBGENER SYSUT1 and once as TSO RECEIVE INDD. 
 Either works by itself.  But each utility seems to FREE its DDNAME before 
returning (is this documented, or perhaps common knowledge?), so I can't use it 
for the other.

There's a principle that utilities should be discreet, do nothing they aren't 
required to, and return the caller's evironment with as little change as 
possible.

OTOH, there's a contrary principle that common chores should be left in 
subroutines, avoiding redundant code in callers.

Which should prevail?

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

Re: SMF/RMF Reporting question

[Norman.Hollander]

Chuck-
SysView definitely has historical reporting (has for many many years).  As
your
SysProgs to show you how to access it.  It is very easy to use.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Hardee, Chuck
Sent: Friday, November 20, 2015 6:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

I have access and knowledge of SysView and SDSF.
What our system programmers have I do not know.
I'm thinking no, because their first attempt at giving me what I need was to
use SysView.


Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile
+1 (412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com  |
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of
this e-mail or the information herein by anyone other than the intended
recipient, or an employee or agent of a system responsible for delivering
the message to the intended recipient, is prohibited. If you are not the
intended recipient, please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Friday, November 20, 2015 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

Do you have any tools like SAS/MICS or SAS/MXG?
Any monitoring tools like Tivoli Omegamon, MainView?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 5:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF/RMF Reporting question
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, 
> after an
event has
> occurred, what units of work were using how much of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in 
> increments of
y
> units, what was the consumption of CPU on a unit of work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU 
> consumption
in a
> context similar to the SDSF DA screen as one sits at their terminal 
> and
presses the
> enter key.
> 
> We are trying to find out who, during a specific interval of the day, 
> was
consuming
> the greatest amount of CPU to the ultimate effect that it essentially 
> stopped
one of
> our database regions from executing and thereby causing it to think 
> some of
its
> subtasks had gone into a runaway CPU condition so it aborted them as a
preemptive
> action against bad coding. We know that the code is good, it's been 
> literally
running
> for years with no changes and, until the last couple of weeks, has had 
> not a
single
> hiccup. Over the last couple of weeks, for no reason we can identify 
> as of
yet, the
> code has randomly been aborted by the database software in which it 
> runs, as a runaway task.
> 
> The theory is that the runaway check process is actually reporting a 
> false
condition
> since it is based on wall clock time (this is vendor code, not ours 
> and I'm
not going to
> debate it one way or another). What the vendor theorizes is that 
> another task
in the
> system, yet to be identified, has stolen the CPU away from the 
> database and
held on
> to it long enough such that when the database finally regained access 
> to the
CPU,
> the runaway interval had been exceeded by the internal task executing 
> our code
so it
> was aborted for a potential loop within the code.
> 
> The database vendor has suggested looking for this kind of information 
> in
order to
> confirm or deny that the database had the CPU it needed or if another 
> task
within
> the LPAR had control. If we find that the database had the CPU, then 
> the
vendor has
> more analysis work to do on the dump with a more powerful magnifying 
> glass, or
we
> have to turn our sights on someone else, either ourselves or, 
> possibly,
another
> vendor for another product.
> 
> Thanks for any thoughts you may have on this.
> Chuck
> 
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information 
> Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | 
> Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  | 
> www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying 
> of this e-mail or the information herein by anyone other than the 
> intended recipient,
or an
> employee or agent of a system responsible for delivering the message 
> to the intended recipient, is prohibited. If you are not the intended 
> recipient,

Re: "tapehlq" parm in IGGCATxx

[Bonno, Tuco]

thank you!!  i track that book down and see what it has to say 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andy Higgins
Sent: Friday, 20 November, 2015 12:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "tapehlq" parm in IGGCATxx

On Thu, 19 Nov 2015 19:24:01 +, Bonno, Tuco  wrote:

>can anybody throw some light on the USAGE of the "tapehlq" parm in IGGCATxx?

Tape volume catalogs are described in DFSMS OAM Planning, Installation, and 
Storage Administration Guide for Tape Libraries.

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


Note: Act 121 of 2014 (SC Restructuring Act of 2014) abolished the Budget and 
Control Board. Effective July 1, 2015, the Department of Administration has 
been established. Please update your contact information.


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

Were you at SHARE in Seattle? Watch your credit card statements!

[Charles Mills]

The Seattle Sheraton was breached for a time range that included March of
2015.

http://www.starwoodhotels.com/Media/PDF/Corporate/Hotel_List.pdf 

Also the Orlando Dolphin but not while SHARE was there!

Charles 

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

Re: "tapehlq" parm in IGGCATxx

[Andy Higgins]

On Thu, 19 Nov 2015 19:24:01 +, Bonno, Tuco  wrote:

>can anybody throw some light on the USAGE of the "tapehlq" parm in IGGCATxx?

Tape volume catalogs are described in DFSMS OAM Planning, Installation, and 
Storage Administration Guide for Tape Libraries.

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

Re: Deleting all members of a pds

[Sri h Kolusu]

>>> Member names. The reason would be that a PDS directory is maintainedin 
order, 
> and the directory is always kept compressed.

Tom,

Thanks for the info and as mentioned earlier DFSORT has the ability of 
sorting the member names in ascending/descending order. Here is a sample 
to show just the sorting of pds member names.

//STEP0100 EXEC PGM=IKJEFT01 
//SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(5,5),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=0),UNIT=SYSDA 
//SYSTSIN  DD * 
  LISTDS 'USERID.PDS' MEMBERS 
//* 
//STEP0200 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD DISP=SHR,DSN=& 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  INREC IFTHEN=(WHEN=GROUP,BEGIN=(1,11,CH,EQ,C'--MEMBERS--'), 
  END=(1,5,CH,EQ,C'READY'),PUSH=(81:ID=1)), 
  IFTHEN=(WHEN=(1,11,CH,EQ,C'--MEMBERS--',OR, 
1,05,CH,EQ,C'READY'),OVERLAY=(81:8X)) 
 
  SORT FIELDS=(81,1,CH,A, 
   03,08,CH,D),EQUALS 
//* 

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
11/20/2015 09:54:59 AM:

> From: Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/20/2015 09:55 AM
> Subject: Re: Deleting all members of a pds
> Sent by: IBM Mainframe Discussion List 
> 
> On Fri, 20 Nov 2015 08:11:08 -0700, Sri h Kolusu wrote:
> 
> Does it at least sort the list in descending order? 
> >
> >Descending order of what? member names or Size? Why exactly do you need 
to 
> >sort the list ? Do you think it would make a difference to the 
directory 
> >blocks?
> 
> Member names. The reason would be that a PDS directory is maintainedin 
order, 
> and the directory is always kept compressed.
> 
> Whenever a member is deleted from a PDS, the following directory 
> entries are all 
> shifted to the left. Then, if there is enough space at the end of 
> that directory 
> block, the first entry from the next block is moved to that space, 
> and the process 
> repeats to the end of the directory.
> 
> As a result, there is less I/O if they are deleted starting at the 
> end of the directory. 
> This is especially true if there are a lot of members in the PDS.
> 
> -- 
> Tom Marchant
> 
> --
> 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: Cobollin'

[Tony Thigpen]

Why would you think that? Just because they have a fancy title does not 
mean they don't play with the code?


Tony Thigpen

Ken Hume IBM wrote on 11/20/2015 10:41 AM:

What did I just watch

Did you notice there is not a COBOL programmer listed in the credits?

Ken


-Original Message- From: Mark Regan Sent: Friday, November 20,
2015 7:43 AM Newsgroups: bit.listserv.ibm-main To:
IBM-MAIN@LISTSERV.UA.EDU Subject: Cobollin'
A hip-hop look at mainframe computing and COBOL Programming.

https://www.youtube.com/watch?v=uKG0IEyeZb0=youtu.be

Mark T. Regan, K8MTR

CTO1, USNR-Retired
1969-1991

--
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




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

Should utilities FREE DDNAMEs?

[Paul Gilmartin]

In a program, I am passed a DDNAME allocated by another program.

I'd like to use it twice, once as IEBGENER SYSUT1 and once as
TSO RECEIVE INDD.  Either works by itself.  But each utility seems to
FREE its DDNAME before returning (is this documented, or perhaps
common knowledge?), so I can't use it for the other.

There's a principle that utilities should be discreet, do nothing they
aren't required to, and return the caller's evironment with as little
change as possible.

OTOH, there's a contrary principle that common chores should be left
in subroutines, avoiding redundant code in callers.

Which should prevail?

-- gil

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

Re: Should utilities FREE DDNAMEs?

[Tony Harminc]

On 20 November 2015 at 13:58, retired mainframer 
wrote:

> > In a program, I am passed a DDNAME allocated by another program.
> >
> > I'd like to use it twice, once as IEBGENER SYSUT1 and once as
> > TSO RECEIVE INDD.  Either works by itself.  But each utility seems to
> > FREE its DDNAME before returning (is this documented, or perhaps
> > common knowledge?), so I can't use it for the other.
>
> Given IEBGENER's age, this would be surprising.  Have you verified this is
> indeed the case?  It should be simple enough to verify the DDNAME is
> allocated before you call IEBGENER and not after it returns with no other
> processing to muddy up the waters.  Might it also depend on how you invoke
> IEBGENER?


You're sure your caller didn't allocate with FREE=CLOSE ?

Tony H.

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

Re: Deleting all members of a pds

[Paul Gilmartin]

Re: 
https://listserv.ua.edu/cgi-bin/wa?A2=ind1511=ibm-main=R37953&1=ibm-main&9=A=-3=on=C539315E5DAE4A6734=PaulGBoulder%40AIM.COM=No+Match%3BMatch%3BMatches=4

On Fri, 20 Nov 2015 10:51:04 -0800, retired mainframer wrote:
 
>
>
>> When better techniques become available, perhaps the inferior ones should
>> me marked in future editions as deprecated.
>
>So every time IBM makes an update to a marketed product, they should search 
>all the freebies to see if they might need some pedantic update to the code or 
>documentation?  It's not enough that IBM allows people to spend time on the 
>clock to develop this stuff for which they will not charge and make it 
>available to all, even non-customers and competitors?  That would probably 
>kill the incentive to release any "as is/no warranty or support" tools of any 
>kind.
>  
No, but it was implied earlier in this thread that the document contains 
contributed
material.  They might likewise consider suggested updates.

Corequisite updates are a sore point.  Many IBM utilities fail with z/OS UNIX 
files
as input because of something akin to "unsupported device type", while they
continue to support card readers and punches.  Often it appears the check is
gratuitous -- it can be defeated by preconcatenating an empty Classic data set.
Simply, such  checks should be eliminated; deferred to the access method to
succeed or fail.


>Didn't anyone read the reference?  On page 84:  " For PDSs with lots of 
>members, you can improve the performance of the IDCAMS step by deleting the 
>members in reverse order. To do this, just add:
>SORT FIELDS=(1,8,CH,D)
>to CTL2CNTL to sort the members in descending order.
>
It would have been clearer in CTL2CNTL, clearly commented.

Does DFSORT input allow comments?  There are several things every language
should support, such as:

o Comments, like HLASM "*".

o No-op, like HLASM ANOP

o User-generated error messages, like HLASM MNOTE.

There are reasons for all these.

-- gil

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

Re: Should utilities FREE DDNAMEs?

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, November 20, 2015 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Should utilities FREE DDNAMEs?
> 
> In a program, I am passed a DDNAME allocated by another program.
> 
> I'd like to use it twice, once as IEBGENER SYSUT1 and once as
> TSO RECEIVE INDD.  Either works by itself.  But each utility seems to
> FREE its DDNAME before returning (is this documented, or perhaps
> common knowledge?), so I can't use it for the other.

Given IEBGENER's age, this would be surprising.  Have you verified this is 
indeed the case?  It should be simple enough to verify the DDNAME is allocated 
before you call IEBGENER and not after it returns with no other processing to 
muddy up the waters.  Might it also depend on how you invoke IEBGENER?

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

Re: SMF/RMF Reporting question

[Lucas Rosalen]

IIRC, Sysview will only have historical data if "History Datasets" (or
whatever they are called) are allocated, which might or might not be your
case.
Anyway, it's worth a try!

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 792 809 198


2015-11-20 15:39 GMT-02:00 Norman.Hollander 
:

> Chuck-
> SysView definitely has historical reporting (has for many many years).  As
> your
> SysProgs to show you how to access it.  It is very easy to use.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 6:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF/RMF Reporting question
>
> I have access and knowledge of SysView and SDSF.
> What our system programmers have I do not know.
> I'm thinking no, because their first attempt at giving me what I need was
> to
> use SysView.
>
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
>
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile
> +1 (412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com
> |
> www.thermofisher.com
>
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of
> this e-mail or the information herein by anyone other than the intended
> recipient, or an employee or agent of a system responsible for delivering
> the message to the intended recipient, is prohibited. If you are not the
> intended recipient, please inform the sender and delete all copies.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, November 20, 2015 8:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF/RMF Reporting question
>
> Do you have any tools like SAS/MICS or SAS/MXG?
> Any monitoring tools like Tivoli Omegamon, MainView?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Hardee, Chuck
> > Sent: Friday, November 20, 2015 5:23 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SMF/RMF Reporting question
> >
> > Hello Everyone,
> >
> > I am trying to find, from a historical perspective, that is to say,
> > after an
> event has
> > occurred, what units of work were using how much of the available CPU.
> > Is there an SMF and/or RMF report that allows on to ask,
> >
> > "During the interval from hh:mm to hh:mm on a particular day, in
> > increments of
> y
> > units, what was the consumption of CPU on a unit of work basis?"
> >
> > Another way to put it is, I am looking for a report that shows CPU
> > consumption
> in a
> > context similar to the SDSF DA screen as one sits at their terminal
> > and
> presses the
> > enter key.
> >
> > We are trying to find out who, during a specific interval of the day,
> > was
> consuming
> > the greatest amount of CPU to the ultimate effect that it essentially
> > stopped
> one of
> > our database regions from executing and thereby causing it to think
> > some of
> its
> > subtasks had gone into a runaway CPU condition so it aborted them as a
> preemptive
> > action against bad coding. We know that the code is good, it's been
> > literally
> running
> > for years with no changes and, until the last couple of weeks, has had
> > not a
> single
> > hiccup. Over the last couple of weeks, for no reason we can identify
> > as of
> yet, the
> > code has randomly been aborted by the database software in which it
> > runs, as a runaway task.
> >
> > The theory is that the runaway check process is actually reporting a
> > false
> condition
> > since it is based on wall clock time (this is vendor code, not ours
> > and I'm
> not going to
> > debate it one way or another). What the vendor theorizes is that
> > another task
> in the
> > system, yet to be identified, has stolen the CPU away from the
> > database and
> held on
> > to it long enough such that when the database finally regained access
> > to the
> CPU,
> > the runaway interval had been exceeded by the internal task executing
> > our code
> so it
> > was aborted for a potential loop within the code.
> >
> > The database vendor has suggested looking for this kind of information
> > in
> order to
> > confirm or deny that the database had the CPU it needed or if another
> > task
> within
> > the LPAR had control. If we find that the database had the CPU, then
> > the
> vendor has
> > more analysis work to do on the dump with a more powerful magnifying
> > glass, or
> we
> > have to turn our sights on someone else, either ourselves or,
> > possibly,
> another
> > vendor for another product.
> >
> > Thanks for 

Re: Privately owned mainframes (Was Re: I just bought an IBM z890)

[Rupert Reynolds]

I have a yearning for a S/360 box to keep my garage/workshop warm in
Winter. I already have some mods to MVS 3.8J under Hercules, to make it
feel more like home :-)

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

Re: Were you at SHARE in Seattle? Watch your credit card statements!

[Ed Gould]

Maybe someone should raise a requirement that the SHARE Hotels credit  
card system should be secure.


Ed

On Nov 20, 2015, at 12:36 PM, Charles Mills wrote:

The Seattle Sheraton was breached for a time range that included  
March of

2015.

http://www.starwoodhotels.com/Media/PDF/Corporate/Hotel_List.pdf

Also the Orlando Dolphin but not while SHARE was there!

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

TSO RECEIVE under UNIX Rexx (was: REXX-question)

[Paul Gilmartin]

On Thu, 19 Nov 2015 12:47:40 +0100, Leopold Strauss wrote:

>Hi, all
>
>I simply wanted to automize the receiving of a lot of XMIT-files in
>zOS-unix-shell ( not TSO)
>
>Last but not least my problem could be broken down to following
>terminal-input-problem with the RECEIVE-command:
> 
With a lot of patient encouragement from J.O.Skip Robinson, some RTFM, and
too much experimenting, I learn about the SDSF Rexx API:

o I can add fields I want by setting the ISFCOLS2 variable.

o Then the ST command tells me everything I want to know about every
   job data set, SYSIN, SYSOUT, and HELD.

o SDSF supplies me a DDNAME I can use for TSO RECEIVE INDD().

o Because of the mutual hostility between TSO and UNIX, the two-EXEC
  approach is necessary. Something like:

  rexx "address TSO 'exec '''userid()'.CLIST(RCVWRAP)'' ''job00300'''"

Ugh!  (A working kludge.)

-- gil

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

Re: Earlier than a z9?

[Brian Westerman]

We have both a consulting and a software side, on the consulting side the 
oldest machines we have are:

4 z/800's running os/390 2.10, z/os 1.4, 1.7 and 1.13
2 9672's both running OS/390
1 4381 running MVS/XA 

All of these are production systems, and for some very special reasons they are 
at the hardware level specified.  

In the past 2 years I personally have converted 8 sites from 3 9672's and 5 
z/800's to z/114 or newer boxes running z/OS V2.1.  All of them were straight 
jumps to z/OS 2.1 and they were all completely successful.  The oldest jump was 
OS/390 2.7 to z/OS 2.1.

Brian

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

Re: Should utilities FREE DDNAMEs?

[Tony Harminc]

On 20 November 2015 at 14:41, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> >You're sure your caller didn't allocate with FREE=CLOSE ?
> >
> No, I'm not sure.
>
> I shouldn't have implied "caller"   The DDNAME was "passed" in a reply
> from the SDSF API. So I wish there were an option to suppress "FREE=CLOSE.


Dynalloc concatenate a DD DUMMY to it...? The JCL book says:

 *FREE=CLOSE* is ignored when:

   - The data set is a member of a concatenated group

Not clear if concatenating after a dynalloc with FREE=CLOSE will inhibit
it. Seems reasonable that it would.

Tony H.

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

Re: Should utilities FREE DDNAMEs?

[Chris Hoelscher]

Didn’t John Lennon write a song about this??

All we are saying .. is give FREEs a chance .?



Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, November 20, 2015 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Should utilities FREE DDNAMEs?

On 20 November 2015 at 14:41, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> >You're sure your caller didn't allocate with FREE=CLOSE ?
> >
> No, I'm not sure.
>
> I shouldn't have implied "caller"   The DDNAME was "passed" in a reply
> from the SDSF API. So I wish there were an option to suppress "FREE=CLOSE.


Dynalloc concatenate a DD DUMMY to it...? The JCL book says:

 *FREE=CLOSE* is ignored when:

   - The data set is a member of a concatenated group

Not clear if concatenating after a dynalloc with FREE=CLOSE will inhibit it. 
Seems reasonable that it would.

Tony H.

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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

Re: Privately owned mainframes (Was Re: I just bought an IBM z890)

[Mike Schwab]

MVS would not run on a 360, requires 370 with Virtual Storage.
MFT would have a good chance.

On Fri, Nov 20, 2015 at 2:52 PM, Rupert Reynolds  wrote:
> I have a yearning for a S/360 box to keep my garage/workshop warm in
> Winter. I already have some mods to MVS 3.8J under Hercules, to make it
> feel more like home :-)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Earlier than a z9?

[Mike Schwab]

As long as you don't need more MIPS, keep chugging along.
Which is why IBM cuts off the upgrades.

On Fri, Nov 20, 2015 at 4:02 PM, Brian Westerman
 wrote:
> We have both a consulting and a software side, on the consulting side the 
> oldest machines we have are:
>
> 4 z/800's running os/390 2.10, z/os 1.4, 1.7 and 1.13
> 2 9672's both running OS/390
> 1 4381 running MVS/XA
>
> All of these are production systems, and for some very special reasons they 
> are at the hardware level specified.
>
> In the past 2 years I personally have converted 8 sites from 3 9672's and 5 
> z/800's to z/114 or newer boxes running z/OS V2.1.  All of them were straight 
> jumps to z/OS 2.1 and they were all completely successful.  The oldest jump 
> was OS/390 2.7 to z/OS 2.1.
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: (External):Re: Deleting all members of a pds

[Ted MacNEIL]

Or, more recent versions of IDCAMS.

-
-teD
-
  Original Message  
From: J O Skip Robinson
Sent: Thursday, November 19, 2015 19:07
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: (External):Re: Deleting all members of a pds

Can also be accomplished with PDS[85] command or StarTool product. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 19, 2015 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a pds

I have installed the CBTTAPE.ORG utility PDSCLEAN for both PDS and PDSE 
datasets an it works very well. File 693.

Lizette



-Original Message-
>From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Nov 19, 2015 3:51 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Deleting all members of a pds
>
>On 2015-11-19 14:54, Ed Finnell wrote:
>> File 182 on CBT tape contains PDS command. It's a great tool. Can 
>> delete or delete by mask add space, copy, merge and fix. The 
>> commercial version is Startools from Serena. Has saved my bacon numerous 
>> times.
>> 
> STOW DCB,,I
>
>I believe (or hope) PDS uses that nowadays, since its older technique, 
>basically zapping the directory, didn't work for PDSE.
>
>> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time, 
>> johnmattson...@gmail.com writes:
>> 
>> Someone was asking about deleting all members of a pds. I just 
>> noticed that DFSort has a bunch of "samples" one of which includes 
>> how to use ICETOOL to delete all members of a PDS. Hope this helps. 
>> Lots of other neat things in here too.
>
>I hope it (and IDCAMS) uses STOW. Deleting members one-by-one can be expensive.
>But if so, first sort in reverse order.
>
>I'm not going to measure timings
>
>-- 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: Should utilities FREE DDNAMEs?

[Paul Gilmartin]

On Fri, 20 Nov 2015 16:23:28 -0500, Tony Harminc  wrote:
>
>Dynalloc concatenate a DD DUMMY to it...? The JCL book says:
>
> *FREE=CLOSE* is ignored when:
>
>   - The data set is a member of a concatenated group
>
>Not clear if concatenating after a dynalloc with FREE=CLOSE will inhibit
>it. Seems reasonable that it would.
>
In fact, it does.  This feels as if a remark applies here that someone lately
made about use of GDGs:

"But that's not what it's for!"

But it seems to work.  And I use PERMC so I can later clean everything up
with a single FREE.

Thanks,
gil

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

Strange HMC issue

[Tony Thigpen]

Background: HMC software version 2.11.1 connected to a z10.

The HMC is connected to two networks. The first is a small private 
network with just the laptops in the z10 and the HMC. No other HMCs or 
other CPUs. The second network is a local network with several items on 
it, including other HMCs. This network is behind a VPN firewall and is 
used to access the web services on the HMC.


Both interfaces have hard-coded IP addresses.

Today we noticed something strange. We had a DHCP address assigned to a 
box we did not know about. Except for 3 workstations on the network, all 
other boxes have hard-coded IP addresses. In the DHCP assigned addresses 
table, the box had provided a name of BMC_DHCP.


After a bunch of testing, we isolated the assigned address to the HMC, 
but the address does not show up in any of the HMC panels that show IP 
addresses.


Items:
1) When we ping the HMC using the hard-coded address, the response is 
under 3.0ms.
2) When we ping the DHCP assigned address, the response is 10x longer, 
in the 30.0ms range.
3) The arp tables on another PC show both addresses having the same nic 
address.
4) The HMC can ping it's own hard-coded address, but it can not ping the 
DHCP assigned address.
5) We have other CPUs and other HMCs. None of the others are doing the 
same thing. (z900 though z10).

6) This HMC has the latest software version of all the HMCs.
7) nMap (port mapping tool) says that there are no ports open at this 
DHCP assigned address.


Thoughts on what is happening?
Anybody else seeing the same thing?

--
Tony Thigpen

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

Re: SMF/RMF Reporting question

[Ted MacNEIL]

ERBRMFPP

Comes free.

See the RMF USER'S GUIDE



















-
-teD
-
  Original Message  
From: Lizette Koehler
Sent: Friday, November 20, 2015 08:50
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SMF/RMF Reporting question

Do you have any tools like SAS/MICS or SAS/MXG?
Any monitoring tools like Tivoli Omegamon, MainView?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 5:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF/RMF Reporting question
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, after an
event has
> occurred, what units of work were using how much of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in increments of
y
> units, what was the consumption of CPU on a unit of work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU consumption
in a
> context similar to the SDSF DA screen as one sits at their terminal and
presses the
> enter key.
> 
> We are trying to find out who, during a specific interval of the day, was
consuming
> the greatest amount of CPU to the ultimate effect that it essentially stopped
one of
> our database regions from executing and thereby causing it to think some of
its
> subtasks had gone into a runaway CPU condition so it aborted them as a
preemptive
> action against bad coding. We know that the code is good, it's been literally
running
> for years with no changes and, until the last couple of weeks, has had not a
single
> hiccup. Over the last couple of weeks, for no reason we can identify as of
yet, the
> code has randomly been aborted by the database software in which it runs, as a
> runaway task.
> 
> The theory is that the runaway check process is actually reporting a false
condition
> since it is based on wall clock time (this is vendor code, not ours and I'm
not going to
> debate it one way or another). What the vendor theorizes is that another task
in the
> system, yet to be identified, has stolen the CPU away from the database and
held on
> to it long enough such that when the database finally regained access to the
CPU,
> the runaway interval had been exceeded by the internal task executing our code
so it
> was aborted for a potential loop within the code.
> 
> The database vendor has suggested looking for this kind of information in
order to
> confirm or deny that the database had the CPU it needed or if another task
within
> the LPAR had control. If we find that the database had the CPU, then the
vendor has
> more analysis work to do on the dump with a more powerful magnifying glass, or
we
> have to turn our sights on someone else, either ourselves or, possibly,
another
> vendor for another product.
> 
> Thanks for any thoughts you may have on this.
> Chuck
> 
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com |
> www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this
> e-mail or the information herein by anyone other than the intended recipient,
or an
> employee or agent of a system responsible for delivering the message to the
> intended recipient, is prohibited. If you are not the intended recipient,
please inform
> the sender and delete all copies.
> 
> 
> --
> 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

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