Re: SMS question

[Vernooij, CP - SPLXM]

"Vernooij, CP - SPLXM"  wrote in message
news:<3310ac9d797ec94db8d89ccabdea47a702a80...@kl1221tc.cs.ad.klmcorp.ne
t>...
> "Ted MacNEIL"  wrote in message
>
news:<1086025626-1281046879-cardhu_decombobulator_blackberry.rim.net-135
> 11872...@bda026.bisx.prod.on.blackberry>...
> > >Why is it that you think you need to change the dataclass?  Once
the
> dataset has been allocated, changing the dataclass should have no
effect
> that I can think of.
> > 
> > Data Class gets you DSCB attributes, but once the DSN is allocated,
> it's next to meaningless.
> > 
> > -
> 
> To all who suggested this: this is not true anymore. Since the space
> constraint relief parameters, the dataclass attributes are also used
at
> each allocation time after the initial creation of the dataset. E.g.
we
> encountered this situation:
> 
> IEF020I jobname procstep stepname TCT I/O TABLE SIZE EXCEEDS THE 16MB
> MAXIMUM.
> 
> Application Programmer Response:
> If the job that received the message has JCL DD statements which
specify
> a high volume count or the job that received the message uses dynamic
> allocation to allocate data sets and specifies a high volume count,
> reduce the volume count and rerun the job. If the volume count is
> derived from the Data Class, use a Data Class which has a lower volume
> count and dynamic volume count, or contact the Storage Administrator.
> 
> Storage Administrator Response:
> Reduce the volume count or dynamic volume count specified in the
> DATACLAS.
> 
> -OR-
> 
> 04FC (1276) Meaning: The request being processed would cause the TCT
I/O
> table to exceed the maximum allowable size. 
> Application Programmer Action: If the job that received the message
has
> JCL DD statements that specify a high volume count, or the job that
> received the message uses dynamic allocation to allocate data sets and
> specifies a high volume count, reduce the volume count and rerun the
> job. If the volume count is derived from the data class, use a data
> class which has a lower volume count or contact the Storage
> Administrator.
> 
> Storage Administrator Action: Reduce the volume count or dynamic
volume
> count specified in the DATACLAS.
> 
> Corresponding Message: IEF020I
>  
> I found another description that mentions that at allocation time
> control blocks are created to allow the dataset to exend to new
volumes.
> The number of volumes to add is derived from the data set's current
> candidate volumes and/or the dynamic volume count in the dataclas. So
> the dataclass is referenced after the data set has been created. 
> 
> For that reason I think it is not safe to delete a dataclass
definition
> when datasets exist with this dataclass.
> 
> We could solve this by reducing the dynamic volume count in the
> Dataclass, but I can imagine the situation that one might want to
alter
> the Dataclass of the data set. I think there is a valid reason now to
> request IDCAMS to add this Alter function.
> 
> Kees.

Here is how it works:
http://www-01.ibm.com/support/docview.wss?uid=isg3T165

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Linkage conventions (was Re: z/OS 1.12 beta sites)

[Shane]

Cheers Tom, thanks for fighting the good fight. And Peter for the time
and patience.
These sort of exchanges must go on all the time - principally within IBM
I guess. Too little of the "meat and gristle" makes its way into the
public arena. Hence misconceptions accrete.

Interesting read.

Shane ...


On Thu, 2010-08-05 at 09:49 -0500, Tom Marchant wrote:

> Following is a summary of the 
> revised chapter and the email exchange that led to it.  I hope 
> some of the readers of IBM-Main will find it helpful.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Xpeditor

[Ron Thomas]

Hi,

We are facing one issue, is that thru the Xpeditor the Async transactions  we 
are not able to trigger, but thru the background transaction CEDX  we are 
able to capture and the transactions are triggered correctly.  Any idea of 
what could be the problem?

The Xped settings are as below.

-- XPEDITER/CICS - TRAP SUMMARY (1.6) --
---WMA5
COMMAND ===>   SCROLL ===> CSR
MODULE:  CSECT:
MODE: TERM   (IP TERM or ALL) NO IP TRAPS ENTRY 01
LINE COMMANDS:   A (After)   B (Before)   C (Copy)   D (Delete)   I (Insert)
 M (Move)S (Save)

 CMD   USERID NETNAME TERM TRAN PROGRAM   TRAP ABEND
   IF .. TRAP CONDITION ...
         ---
  _   NONE TX41  YES
   IF


Regards
Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where what to do next - Load modules missing from PDS

[Jan MOEYERSONS]

On Thu, 5 Aug 2010 16:04:30 -0400, William Bishop 
 wrote:

>Had the modules been updated recently?  If so, was there an Endevor
>package backout done?

When Endevor backs out a package, the load module actually stays in the 
PDS. It is renamed to a name with hex characters that make it (almost) 
unreachable for anything else. 

Not sure if you would see this in SMF. But it sure will not be a delete.

Cheers,

Jantje.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Migration to z/os 1.11 causes Paging in DB2 DBM1 address space

[Mark Zelden]

On Fri, 6 Aug 2010 02:45:37 +, Ted MacNEIL  wrote:

>>An increase of HSA could keep you from activating an LPAR, but that's all.
>
>Since they are now independent, why?
>

To be more clear:  "could have".  Before,  HSA counted in customer total
storage.   But my point was that HSA never could have been the problem
even on older processors (unless the box was in basic mode). 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where what to do next - Load modules missing from PDS

[Stocker, Herman]

Thanks for the ideas.

1.  IMS is taken down once a month for maintenance and the compress of the 
library is done at this time.
2.  The person who said that it would not be a program not found was correct it 
is a load failure.
We have not had any load failures, so a compress has not been done.
3.  I must have missed this in the original post there were multiple PDS that 
were hit on different volumes
4.  Logrec did not show any problems
5.  We have regenerated the modules from the Endevor source so we are hole 
again we are looking for the how now.
6.  Endevor has taken over the IDRC record.  The date is not keep there on 
Endevor generated modules

Thank you Bill I will pass your suggestion along to the security people.  
Thanks everyone for your ideas, suggestion 7 comments.

Regards,
Herman Stocker

It is impossible to make anything foolproof, because fools are so ingenious.
 -- Robert Heinlein

The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DB2 8 for z/OS End of Service Date

[Joel C. Ewing]

On 08/05/2010 10:08 AM, Timothy Sipples wrote:
> To provide ample warning, IBM has announced the End of Service date for DB2
> 8 for z/OS:
> 
> http://www.ibm.com/common/ssi/rep_ca/9/897/ENUS910-169/ENUS910-169.PDF
> 
> The EoS date is April 30, 2012. If you haven't started your DB2 upgrade
> yet, please start this year. It's important to enjoy the benefits in the
> newer versions. If you need some help, ask your friendly IBM
> representative.
> 
> - - - - -
> Timothy Sipples
> Resident Enterprise Architect
> STG Value Creation & Complex Deals Team
> IBM Growth Markets (Based in Singapore)
> E-Mail: timothy.sipp...@us.ibm.com
> 

The reticence for prompt upgrades to new releases of DB2 would be much
less if IBM didn't use every new version as an opportunity for
significant increases in licensing fees.  It's very difficult to justify
an upgrade of a working version to upper management any earlier than the
last possible minute under those circumstances, especially when the
economy is still down.  Unless policies change, we will probably start
converting DB2 no sooner than 4Q 2011.

There may be performance improvements and/or feature enhancements with
new versions, but it is very difficult to quantify these benefits in
dollars.  Quantifying the additional cost of the new version is easy and
obvious.

-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: linkage conventions

[Walt Farrell]

On Fri, 6 Aug 2010 01:30:56 +, john gilmore  wrote:

>There is a sense in which all is now clear (or at least very much clearer).
 The exchanges between Tom Marchant and Peter Relson were very helpful.  
> 
>What remains is probably intractable, but I find
> 
>. . . B can never determine.  B documents its requirements and assumes that
its caller has met these requirements . . .
>
>curiously unsatisfying.  
> 
>How and, in particular, where B is to document its requirements is left up
in the air.  All will be well until
>there is an error of substance or a documentation lag, and then . . .  
> 
>My practice---It is habitual in much compiled code too---of supplying
myself with LIFO scratch storage by 
>enlarging DSAs will make my code particularly vulnerable to such errors.  
> 
>We shall all come to regret this state of affairs, but when I think about
how to proceed differently nothing
>useful occurs to me.  The problem is easy to state: DSAs of too many
different sizes are now required in 
>subtly different circumstances; but they may well be practically inescapable.  

This discussion has been about standard z/OS linkage conventions, where the
caller provides a savearea and the called program is responsible for
allocating its own dynamic storage by its own means.

Presumably you know whom you're calling, and from their documentation you
know what size savearea each of them requires you to allocate. And you
allocate a savearea large enough to satisfy the maximum required by anyone
you are calling.

If you're worried that you might not have the latest documentation, and thus
someone may require something larger, why not just start modifying your
programs so you always allocate the maximum size currently documented in the
z/OS linkage conventions? Then you can call anyone.

I'm not quite sure what you're talking about here, John, but it seems you
might be talking about some other linkage convention, where the caller
provides all the dynamic storage needed by the called program, and if so
that's something very different. Yes, in that case, the called program might
need a way to figure out how much storage it had been given, but that's not
what we've been discussing.

-- 
Walt Farrell
IBM STSM, z/OS Security Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Migration to z/os 1.11 causes Paging in DB2 DBM1 address space

[Joel C. Ewing]

On 08/05/2010 08:27 PM, Shane wrote:
> I would have thought DB2 might be a more pressing issue for a business.
> 
> Shane ...
> 
> On Thu, 2010-08-05 at 23:42 +0300, Mike Shorkend wrote:
> 
>> z/os 1.9 is going out of service in September IIRC. We have to migrate to
>> z/os 1.11 before then.
>> The LPAR has 4.5 GB
>>  DB2 V8
> 

z/OS 1.9 EoS is 2010-09, and in our experience it takes a minimum of 4
months to adequately check out all the major subsystems and vendor
products under a new z/OS version before a move to production even in a
single-production-LPAR environment.  I once did it in less by working
60+ hour weeks for over a month when the new z/OS was a coreq for a
firmly scheduled hardware upgrade, but I wouldn't recommend it.

DB2  V8 EoS is 2012-04-30, light years away by comparison, and I've seen
DB2 upgrades phased into production in less than 2 months.

Unless there is some new DB2 feature essential to your shop, cost is
often a significant motivator for staying with older versions as long as
they are still supported.

-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Migration to z/os 1.11 causes Paging in DB2 DBM1 address space

[Shane]

Hey Joel, yeah I realised after I sent it that was probably a "senior"
moment.
We've been chasing customers re DB2, but that would have been to get
them off V7.
D'oh.

Shane ...

On Fri, 2010-08-06 at 08:20 -0500, Joel C. Ewing wrote:

> DB2  V8 EoS is 2012-04-30, light years away by comparison, and I've seen
> DB2 upgrades phased into production in less than 2 months.
> 
> Unless there is some new DB2 feature essential to your shop, cost is
> often a significant motivator for staying with older versions as long as
> they are still supported.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Migration to z/os 1.11 causes Paging in DB2 DBM1 address space

[Scott Rowe]

YMMV, DB2 version upgrades take far longer than z/OS releases.  I can go from 
ServerPac order to production in a few months, but a new DB2 version typically 
takes 9-12 months.  I have only 4 LPARs total, but there are about 20 DB2 
subsystems (5 production).

>>> "Joel C. Ewing"  8/6/2010 9:20 AM >>>
On 08/05/2010 08:27 PM, Shane wrote:
> I would have thought DB2 might be a more pressing issue for a business.
> 
> Shane ...
> 
> On Thu, 2010-08-05 at 23:42 +0300, Mike Shorkend wrote:
> 
>> z/os 1.9 is going out of service in September IIRC. We have to migrate to
>> z/os 1.11 before then.
>> The LPAR has 4.5 GB
>>  DB2 V8
> 

z/OS 1.9 EoS is 2010-09, and in our experience it takes a minimum of 4
months to adequately check out all the major subsystems and vendor
products under a new z/OS version before a move to production even in a
single-production-LPAR environment.  I once did it in less by working
60+ hour weeks for over a month when the new z/OS was a coreq for a
firmly scheduled hardware upgrade, but I wouldn't recommend it.

DB2  V8 EoS is 2012-04-30, light years away by comparison, and I've seen
DB2 upgrades phased into production in less than 2 months.

Unless there is some new DB2 feature essential to your shop, cost is
often a significant motivator for staying with older versions as long as
they are still supported.

-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/OS V1.11 and DFHSM performance

[Lizette Koehler]

 

I am running into a strange situation where occasionally when DFHSM is
recalling ML2 data for A user (not many just one) according to SDSF it is
going to 50% + cpu utilization.

 

I am not sure what I need to do to isolate a performance issue in DFHSM like
this.

 

Could someone provide me with the steps or areas to review that might help
me understand why this is occurring.

 

Last time it did this we had to cancel DFHSM because it would not stop.

 

 

Thanks

 

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Hal Merritt]

Open a software PMR: "Excessive CPU during ML2 Recall". Let IBM tell you what 
they need. That's why we pay them the big bucks :-)

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, August 06, 2010 9:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS V1.11 and DFHSM performance

 

I am running into a strange situation where occasionally when DFHSM is
recalling ML2 data for A user (not many just one) according to SDSF it is
going to 50% + cpu utilization.

 

I am not sure what I need to do to isolate a performance issue in DFHSM like
this.

 

Could someone provide me with the steps or areas to review that might help
me understand why this is occurring.

 

Last time it did this we had to cancel DFHSM because it would not stop.

 

 

Thanks

 

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Mike Schwab]

No APARs, so I would assume a new problem.  Take a dump the next time
it happens. and open the ETR.  This does sound like an unintended
tight cpu loop.

On Fri, Aug 6, 2010 at 9:52 AM, Hal Merritt  wrote:
> Open a software PMR: "Excessive CPU during ML2 Recall". Let IBM tell you what 
> they need. That's why we pay them the big bucks :-)
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of Lizette Koehler
> Sent: Friday, August 06, 2010 9:38 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: z/OS V1.11 and DFHSM performance
>
> I am running into a strange situation where occasionally when DFHSM is
> recalling ML2 data for A user (not many just one) according to SDSF it is
> going to 50% + cpu utilization.
>
> I am not sure what I need to do to isolate a performance issue in DFHSM like
> this.

-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Lizette Koehler]

I am in the process of doing that.  But for some reason every time I open a
ticket to HSM or SMS they throw me over the wall to Q&A.

I was also inquiring to see if anyone else has seen this issue.  However,
off to IBM I go.

Lizette



> Hal Merritt wrote:   Subject: Re: z/OS V1.11 and DFHSM performance
> 
> Open a software PMR: "Excessive CPU during ML2 Recall". Let IBM tell
> you what they need. That's why we pay them the big bucks :-)
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Friday, August 06, 2010 9:38 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: z/OS V1.11 and DFHSM performance
> 
> I am running into a strange situation where occasionally when DFHSM is
> recalling ML2 data for A user (not many just one) according to SDSF it
> is
> going to 50% + cpu utilization.
> 
> I am not sure what I need to do to isolate a performance issue in DFHSM
> like
> this.
> 
> Could someone provide me with the steps or areas to review that might
> help
> me understand why this is occurring.
> 
> Last time it did this we had to cancel DFHSM because it would not stop.> 
> 
> Thanks
> 
> 
> 
> Lizette
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: linkage conventions

[Tom Marchant]

On Fri, 6 Aug 2010 01:30:56 +, john gilmore wrote:

>I find
> 
>. . . B can never determine.  B documents its requirements and 
>assumes that its caller has met these requirements . . .
>
>curiously unsatisfying.  
> 
>How and, in particular, where B is to document its requirements 
>is left up in the air.

How is this any different from documenting the input parameters 
that are required and the results that are returned?

If you have an existing program that uses a 72-byte save area, 
it is not safe to change it to require a larger save area unless you
can control all of your callers.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Norman Hollander]

There are many fixes for ALL products with 1.11.  Check IBMLink or open an 
incident. 
--Original Message--
From: Lizette Koehler
Sender: IBM Mainframe Discussion List
To: IBM-MAIN@bama.ua.edu
ReplyTo: IBM Mainframe Discussion List
Subject: z/OS V1.11 and DFHSM performance
Sent: Aug 6, 2010 7:37 AM

 

I am running into a strange situation where occasionally when DFHSM is
recalling ML2 data for A user (not many just one) according to SDSF it is
going to 50% + cpu utilization.

 

I am not sure what I need to do to isolate a performance issue in DFHSM like
this.

 

Could someone provide me with the steps or areas to review that might help
me understand why this is occurring.

 

Last time it did this we had to cancel DFHSM because it would not stop.

 

 

Thanks

 

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



nor...@desertwiz.biz  
Sent from my Verizon Wireless BlackBerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[John Kelly]

 I am running into a strange situation where occasionally when DFHSM is 
recalling ML2 data for A user (not many just one) according to SDSF it
 is going to 50% + cpu utilization


Maybe if you look at the FSR type5's FSRCPU to determine HSM perspective 
of CPU usage and FSRTRKW to see how many tracks are being restored, you 
may more info to go to IBM with. You could tell if it's allocation too by 
reviewing the mount time, etc...

Jack Kelly
202-502-2390 (Office)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: I'm amazed

[Shmuel Metz (Seymour J.)]

In , on
08/05/2010
   at 10:59 AM, zMan  said:

>You seem ... angry and hostile.

I tend to get that way when someone responds "nonsense" without even
understanding what they're responding to.

>I hope you feel better soon!

I hope your reading skills improve soon.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Question on size of IEFBR14 and z/OS V1.11

[Shmuel Metz (Seymour J.)]

In , on 08/04/2010
   at 11:16 PM, Barbara Nitz  said:

>The recommendation has been for some time to code region only on the
>job card.

Whose recommendation? Where?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: History of Hard-coded Offsets (Was: TSSO problems)

[William H. Blair]

Ted MacNEIL started this latest sub-discussion within this thread with:

> I was one of the ones, in Canada, complaining about the constant
> changes in geometry. 3330->3350->3380->3390 (and don't forget
> 'compatability' mode.

Seymour J. Metz responded to Ted:

> Because you didn't use system services to insulate yourself from
> changes.

Rick Fochtman interjected:

> Most of those geometry-related "System Services" didn't exist!

Paul Gilmartin then asked Rick:

> Not even by the advent of the 3390, the "last ever" conversion?

Seymour J. Metz responded to Paul:

> Not even close. Those services came in decades earlier.

Seymour J. Metz then asked Rick:

> What year are you talking about?

To which Rick Fochtman responded:

> Just about the time the 3390 first hit the street. 
> Don't remember the exact year.

And then Mike Schwab interjected:

> Late 1980s with SMS and the 3380 - 3390 transition.  BLKSIZE=0.

Seymour J. Metz rebutted with this:

> Those services were long in the tooth by then.

Shmuel is correct (although that is, of course, not unusual).

The TRKCALC routine, at least [I do not remember if the TRKCALC _macro_
appeared this early or not] -- or (as we knew it then) the STAR (System
Track Algorithm Routine) service -- was first introduced with DF/DS
(concurrently with DF/EF) for MVS/SP R1 [what would eventually come to be
called MVS/SP V1 R1, or SP1.1] and was available in January 1981, although
3380 ESP sites had all three long before then (but that's another story). It
was claimed (but I never bothered to verify) that this routine was actually
available pre-MVS/SP1.1, but was not documented; regardless, POK hid it
neatly inside of the existing, well-known 3330/3350 RPS sector calculation
routine pointed to by the CVT using a non-obvious entry linkage, which
survives to this day.
   
There were other, somewhat ad-hoc sector and/or track balance calculations
spread all over MVS and JES2 [and I'm sure JES3]. TRKCALC was, no doubt, an
attempt to eliminate most of those, so that every component didn't need to
RYO. The advent of the cellular DASD devices, which gave SAS so much trouble
(as has been mentioned in previous posts in this thread), necessitated
significant changes to the sometimes-simplistic (albeit working for 3330 &
3350 devices) algorithms used in these disparate ad-hoc routines inside of
MVS and other IBM products. In fact, many attempted to continue to RYO
(i.e., not use TRKCALC) and they got it wrong in some corner cases. I
suspect they got their hands slapped.

--  
WB
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Lizette Koehler]

What I have found out so far is our Primary Space management gets started
and then all of a sudden, DFHSM, is running at 60% or higher cpu
utilization.  In fact, RMF shows it PROC: 96%
And it stays that way until I cancel DFHSM.  STOP has no affect.

So something is definitely going on.

If IBM finds out anything interesting, I will let you know.

Thanks for everyone's input.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Gibney, Dave]

I didn't run into this one. What level of z/OS 1.11 did you convert to?
I went at RSU1005 plus one fix to IDGZILLA marked RSU1006.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Friday, August 06, 2010 12:34 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS V1.11 and DFHSM performance
> 
> What I have found out so far is our Primary Space management gets
> started
> and then all of a sudden, DFHSM, is running at 60% or higher cpu
> utilization.  In fact, RMF shows it PROC: 96%
> And it stays that way until I cancel DFHSM.  STOP has no affect.
> 
> So something is definitely going on.
> 
> If IBM finds out anything interesting, I will let you know.
> 
> Thanks for everyone's input.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Roberto Halais]

Just for the record.
We had a similar problem and the culprit turned out to be Tivoli Allocation
Optimizer.

On Fri, Aug 6, 2010 at 5:06 PM, Gibney, Dave  wrote:

> I didn't run into this one. What level of z/OS 1.11 did you convert to?
> I went at RSU1005 plus one fix to IDGZILLA marked RSU1006.
>
> Dave Gibney
> Information Technology Services
> Washington State University
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Lizette Koehler
> > Sent: Friday, August 06, 2010 12:34 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: z/OS V1.11 and DFHSM performance
> >
> > What I have found out so far is our Primary Space management gets
> > started
> > and then all of a sudden, DFHSM, is running at 60% or higher cpu
> > utilization.  In fact, RMF shows it PROC: 96%
> > And it stays that way until I cancel DFHSM.  STOP has no affect.
> >
> > So something is definitely going on.
> >
> > If IBM finds out anything interesting, I will let you know.
> >
> > Thanks for everyone's input.
> >
> > Lizette
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
"It is no measure of health to be well adjusted to a profoundly sick
society." -Krishnamurti

"I am as you, in you, for you. One as you in all, as all, forever. My call
is your call."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Lizette Koehler]

We are probably about the same RSU Level.  I will check on Monday to be more
accurate.

What WLM class is your DFHSM running at?

Lizette


> 
> I didn't run into this one. What level of z/OS 1.11 did you convert to?
> I went at RSU1005 plus one fix to IDGZILLA marked RSU1006.
> 
> Dave Gibney

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Lizette Koehler
> Sent: Friday, August 06, 2010 2:14 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS V1.11 and DFHSM performance
> 
> We are probably about the same RSU Level.  I will check on Monday to
be
> more
> accurate.
> 
> What WLM class is your DFHSM running at?

STCMED   medium priority stc
 Base goal:

 CPU Critical flag: No

 #  Duration   Imp  Goal description

 -  -  

 1  3   Execution velocity of 30


> 
> Lizette
> 
> 
> >
> > I didn't run into this one. What level of z/OS 1.11 did you convert
> to?
> > I went at RSU1005 plus one fix to IDGZILLA marked RSU1006.
> >
> > Dave Gibney
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[O'Brien, David W. (NIH/CIT) [C]]

WLM class is STCLO. HSM, currently dormant, has a DP is F0, often runs at E9. 

When I got here HSM was running at STCHI, IIRC. I had the performance person 
lower it. The IBM reccommendation is for HSM to run above Batch and below the 
Onlines. Of course I can't find that documented anywhere.

Thank You,
Dave O'Brien
NIH Contractor

From: Lizette Koehler [stars...@mindspring.com]
Sent: Friday, August 06, 2010 5:13 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS V1.11 and DFHSM performance

We are probably about the same RSU Level.  I will check on Monday to be more
accurate.

What WLM class is your DFHSM running at?

Lizette


>
> I didn't run into this one. What level of z/OS 1.11 did you convert to?
> I went at RSU1005 plus one fix to IDGZILLA marked RSU1006.
>
> Dave Gibney

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Who are the TOP Mainframe Tapesubsystems Vendors?

[BOB COSBY]

No STK developed ICEBERG (RAID 6 architecture); Kodeack (RAID 5
architecture) and Arctic Fox (Solid State device) which FROZEN DOG never
got out of development.
 
The VSM is RAID 6 architecture under the covers and yes SUN bought STK
then Oracle bought SUN/STK.

The point I am try to make is there are only 2 mainframe real tape
vendors out there and they are IBM and Oracle and from this agency's
perspective the VSM/SL8500 is an outstanding architecture and it works
very well in this environment.  
We still use FTAM/CTAM (Ford or Chevy Truck Access Method) for Disaster
Recovery:  TRUCK TAPE.

Although we were shipping 3,000 3490/9490 tapes to Iron Mountain daily
and now we ship less than a hundred of the 9840D tapes. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of R.S.
Sent: Wednesday, August 04, 2010 1:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Who are the TOP Mainframe Tapesubsystems Vendors?

So?
Did anyone claim that Oracle developed VSM or SL8500?
The notice below says that someone bought some product from Oracle, 
nothing else. Nowadays SL8500 is onwed by Oracle - so it's Oracle
product.

BTW: many IBM products are developed by still existing independent 
companies. Examples: all tape libraries except the largest (Quantum, 
previously ADIC), some FASt aka DS dasd (Ingenico), 
N-something_I_forgot (NetApp), all the FC/FICON switches...


Regarding to the Silo-SL change: a single SL8500 in maximum 
configuration is huge library, with approx. 1 tape slots. We don't 
know what drives are inside, but the technolgical jump could be really 
big as well.


W dniu 2010-08-04 19:58, Staller, Allan pisze:
> Oracle just bought SUN. SUN recently bought STK. The VSM and SL8500
were
> developed by STK, not ORACLE.
>
> 
> Our agency just replaced 10 (ten) STK 9310 silos with 2 (two) Oracle
> VSMs (Virtual Storage Manager) and  2 (two) Oracle SL8500 tape
> subsystems.  They are working GREAT!!
> 


-- 
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w
caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI
WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika
2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w
podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Pinnacle]

- Original Message - 
From: "Lizette Koehler" 

Newsgroups: bit.listserv.ibm-main
Sent: Friday, August 06, 2010 5:14 PM
Subject: Re: z/OS V1.11 and DFHSM performance


We are probably about the same RSU Level.  I will check on Monday to be 
more

accurate.

What WLM class is your DFHSM running at?

Lizette




I always run HSM SYSSTC.

Regards,
Tom Conley 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Pinnacle
> Sent: Friday, August 06, 2010 5:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS V1.11 and DFHSM performance
> 
> - Original Message -
> From: "Lizette Koehler" 
> Newsgroups: bit.listserv.ibm-main
> Sent: Friday, August 06, 2010 5:14 PM
> Subject: Re: z/OS V1.11 and DFHSM performance
> 
> 
> > We are probably about the same RSU Level.  I will check on Monday to
> be
> > more
> > accurate.
> >
> > What WLM class is your DFHSM running at?
> >
> > Lizette
> >
> >
> 
> I always run HSM SYSSTC.

Since I don't do any kind of flash or instant back-ups, in my view,
DFHSM does nothing I can't wait for a bit.
If my CPU is to busy with important online work, TSO and batch recalls
can wait. And with virtual tape, most recalls occur pretty damn fast
anyway.

> 
> Regards,
> Tom Conley
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.11 and DFHSM performance

[Mark Zelden]

On Fri, 6 Aug 2010 18:16:32 -0700, Gibney, Dave  wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Pinnacle
>> Sent: Friday, August 06, 2010 5:39 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: z/OS V1.11 and DFHSM performance
>>
>> - Original Message -
>> From: "Lizette Koehler" 
>> Newsgroups: bit.listserv.ibm-main
>> Sent: Friday, August 06, 2010 5:14 PM
>> Subject: Re: z/OS V1.11 and DFHSM performance
>>
>>
>> > We are probably about the same RSU Level.  I will check on Monday to
>> be
>> > more
>> > accurate.
>> >
>> > What WLM class is your DFHSM running at?
>> >
>> > Lizette
>> >
>> >
>>
>> I always run HSM SYSSTC.
>
>Since I don't do any kind of flash or instant back-ups, in my view,
>DFHSM does nothing I can't wait for a bit.
>If my CPU is to busy with important online work, TSO and batch recalls
>can wait. And with virtual tape, most recalls occur pretty damn fast
>anyway.
>
>>

Exactly how it should be.  That is why I don't really like questions like
this because each shop has to decide what is the correct goal / business
importance for themselves.

BTW, I run it in an IMP=2 STC service class.Some of the HSM activities
bleed over into online hours... at least at times.  Very little runs IMP=1. 
IMP=2 is equal with CICS so it still is a high priority task.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

AUTO: Timothy Sipples is out of the office until August 16, 2010.

[Timothy Sipples]

I am out of the office until 08/16/2010.

I am on vacation and have no access to e-mail. For urgent issues, please
contact my manager:

David Byron/Australia/IBM

I have received your e-mail and will reply when I return.


Note: This is an automated response to your message  "IBM-MAIN Digest - 5
Aug 2010 to 6 Aug 2010 (#2010-218)" sent on 8/6/10 22:00:01.

This is the only notification you will receive while this person is away.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html