Discussion:
VIO dataset problem
(too old to reply)
Shivang Sharma
2019-09-21 19:33:08 UTC
Permalink
Hi everybody,

I am facing an unusual problem with VIO datasets.
I submit 5 instances of the same job within a span of 5 minutes.
Out of them 3 shows VIO being paged out . The other runs seems to
be fine . Not able to understand what can be causing this?

Thanks in advance.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jon Perryman
2019-09-21 23:55:19 UTC
Permalink
3 show VIO being paged out .  
Paging VIO is not necessarily a bad thing. Check for excessive amount of data being written to VIO. Check storage usage for the system. Maybe another address space is using a lot of storage.  Change to disk and keep the files. Maybe the address space is looping and you are not having a VIO problem. Look at the file sizes to see if they are excessive. Run an IEBGENER from the saved datasets to a VIO dataset to see if it hangs.

Jon.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Shivang Sharma
2019-09-22 01:22:28 UTC
Permalink
Hi ,

We are not storage constraint . We hardly page .The idea behind using VIO is to reduce hard I/O for BDAM . When you say the file size is excessive is there a limit ? Job is not looping that's for sure .

Thanks

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jon Perryman
2019-09-22 03:12:16 UTC
Permalink
I'm sure there must be controls but I familiar with them. 

You mentioned BDAM. Maybe VIO is not fully compatible with BDAM when it pages out a VIO block. 

As for paging, it will occur even if it's only some. At this point, you are trying to find the cause. I'm just giving you what could be possible factors that you may be overlooking. 

Jon.

On Saturday, September 21, 2019, 06:22:25 PM PDT, Shivang Sharma <***@GMAIL.COM> wrote:

Hi ,

We are not storage constraint . We hardly page .The idea behind using VIO is to reduce hard I/O for BDAM . When you say the file size is excessive is there a limit ? Job is not looping that's for sure .

Thanks

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2019-09-22 18:48:31 UTC
Permalink
VIO is at the level of EXCP; it simulates CKD DASD on the paging files. There should be ne dependency on what access method is using EXCP.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Jon Perryman <***@PACBELL.NET>
Sent: Saturday, September 21, 2019 11:12 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: VIO dataset problem

I'm sure there must be controls but I familiar with them.

You mentioned BDAM. Maybe VIO is not fully compatible with BDAM when it pages out a VIO block.

As for paging, it will occur even if it's only some. At this point, you are trying to find the cause. I'm just giving you what could be possible factors that you may be overlooking.

Jon.

On Saturday, September 21, 2019, 06:22:25 PM PDT, Shivang Sharma <***@GMAIL.COM> wrote:

Hi ,

We are not storage constraint . We hardly page .The idea behind using VIO is to reduce hard I/O for BDAM . When you say the file size is excessive is there a limit ? Job is not looping that's for sure .

Thanks

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2019-09-22 03:16:22 UTC
Permalink
If I remember correctly, the limit for a VIO Data set is 65535 tracks.

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks
Post by Shivang Sharma
Hi ,
We are not storage constraint . We hardly page .The idea behind using VIO is to reduce hard I/O for BDAM . When you say the file size is excessive is there a limit ? Job is not looping that's for sure .
Thanks
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOP NM
2019-09-23 10:34:47 UTC
Permalink
IIRC, the limit of a VIO dataset is the size of the emulated Dasd volume.
Non-extended datasets also have the limit of 65535 tracks.

Kees.
Post by Ron Hawkins
-----Original Message-----
Behalf Of Steve Thompson
Sent: 22 September, 2019 5:16
Subject: Re: VIO dataset problem
If I remember correctly, the limit for a VIO Data set is 65535 tracks.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks
Post by Shivang Sharma
Hi ,
We are not storage constraint . We hardly page .The idea behind using
VIO is to reduce hard I/O for BDAM . When you say the file size is
excessive is there a limit ? Job is not looping that's for sure .
Post by Shivang Sharma
Thanks
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOP NM
2019-09-24 06:44:56 UTC
Permalink
When we already ran from 3390, we kept the VIO device a 3380, in order to limit the amount of VIO data.

Kees.
Post by Ron Hawkins
-----Original Message-----
Behalf Of Ron Hawkins
Sent: 24 September, 2019 7:52
Subject: Re: VIO dataset problem
Allen,
I like to think that most sights would manage this with DFSMS, and define
a 3390 device as the VIO model.
I'm not sure what the smallest supported device type is nowadays, but the
2314 disappeared as the device of choice for throttling VIO size a long
time ago.
Having one track geometry makes life easier, even with SDB.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Of Allan Staller
Sent: Monday, 23 September 2019 22:35
Subject: Re: [IBM-MAIN] VIO dataset problem
Typically, the vio default (installation set) is much smaller than the
max. The OP might investigate the size of the specific files involved.
-----Original Message-----
Of Steve Thompson
Sent: Saturday, September 21, 2019 10:16 PM
Subject: Re: VIO dataset problem
If I remember correctly, the limit for a VIO Data set is 65535 tracks.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks
Post by Shivang Sharma
Hi ,
We are not storage constraint . We hardly page .The idea behind using
VIO is to reduce hard I/O for BDAM . When you say the file size is
excessive is there a limit ? Job is not looping that's for sure .
Post by Shivang Sharma
Thanks
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
________________________________
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or may contain
viruses in transmission. The e mail and its contents (with or without
referred errors) shall therefore not attach any liability on the
originator or HCL or its affiliates. Views or opinions, if any, presented
in this email are solely those of the author and may not necessarily
reflect the views or opinions of HCL or its affiliates. Any form of
reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior
written consent of authorized representative of HCL is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.
________________________________
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2019-09-24 07:20:41 UTC
Permalink
Kees,

Possibly a redundant and risky method, given the ease and granularity of the DFSMS approach.

Ron


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, 24 September 2019 16:32
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VIO dataset problem

When we already ran from 3390, we kept the VIO device a 3380, in order to limit the amount of VIO data.

Kees.
Post by Ron Hawkins
-----Original Message-----
On Behalf Of Ron Hawkins
Sent: 24 September, 2019 7:52
Subject: Re: VIO dataset problem
Allen,
I like to think that most sights would manage this with DFSMS, and
define a 3390 device as the VIO model.
I'm not sure what the smallest supported device type is nowadays, but the
2314 disappeared as the device of choice for throttling VIO size a
long time ago.
Having one track geometry makes life easier, even with SDB.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Behalf Of Allan Staller
Sent: Monday, 23 September 2019 22:35
Subject: Re: [IBM-MAIN] VIO dataset problem
Typically, the vio default (installation set) is much smaller than the
max. The OP might investigate the size of the specific files involved.
-----Original Message-----
Behalf Of Steve Thompson
Sent: Saturday, September 21, 2019 10:16 PM
Subject: Re: VIO dataset problem
If I remember correctly, the limit for a VIO Data set is 65535 tracks.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks
Post by Shivang Sharma
Hi ,
We are not storage constraint . We hardly page .The idea behind using
VIO is to reduce hard I/O for BDAM . When you say the file size is
excessive is there a limit ? Job is not looping that's for sure .
Post by Shivang Sharma
Thanks
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
________________________________
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
may contain viruses in transmission. The e mail and its contents (with
or without referred errors) shall therefore not attach any liability
on the originator or HCL or its affiliates. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message
without the prior written consent of authorized representative of HCL
is strictly prohibited. If you have received this email in error
please delete it and notify the sender immediately. Before opening any
email and/or attachments, please check them for viruses and other defects.
________________________________
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOP NM
2019-09-24 07:27:21 UTC
Permalink
Ron,

I must have been in the pre-SMS time.
We do use SMS now.

Kees.
Post by Ron Hawkins
-----Original Message-----
Behalf Of Ron Hawkins
Sent: 24 September, 2019 9:20
Subject: Re: VIO dataset problem
Kees,
Possibly a redundant and risky method, given the ease and granularity of
the DFSMS approach.
Ron
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, 24 September 2019 16:32
Subject: Re: [IBM-MAIN] VIO dataset problem
When we already ran from 3390, we kept the VIO device a 3380, in order to
limit the amount of VIO data.
Kees.
Post by Ron Hawkins
-----Original Message-----
On Behalf Of Ron Hawkins
Sent: 24 September, 2019 7:52
Subject: Re: VIO dataset problem
Allen,
I like to think that most sights would manage this with DFSMS, and
define a 3390 device as the VIO model.
I'm not sure what the smallest supported device type is nowadays, but the
2314 disappeared as the device of choice for throttling VIO size a
long time ago.
Having one track geometry makes life easier, even with SDB.
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Behalf Of Allan Staller
Sent: Monday, 23 September 2019 22:35
Subject: Re: [IBM-MAIN] VIO dataset problem
Typically, the vio default (installation set) is much smaller than the
max. The OP might investigate the size of the specific files involved.
-----Original Message-----
Behalf Of Steve Thompson
Sent: Saturday, September 21, 2019 10:16 PM
Subject: Re: VIO dataset problem
If I remember correctly, the limit for a VIO Data set is 65535 tracks.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks
Post by Shivang Sharma
Hi ,
We are not storage constraint . We hardly page .The idea behind using
VIO is to reduce hard I/O for BDAM . When you say the file size is
excessive is there a limit ? Job is not looping that's for sure .
Post by Shivang Sharma
Thanks
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
________________________________
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
may contain viruses in transmission. The e mail and its contents (with
or without referred errors) shall therefore not attach any liability
on the originator or HCL or its affiliates. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message
without the prior written consent of authorized representative of HCL
is strictly prohibited. If you have received this email in error
please delete it and notify the sender immediately. Before opening any
email and/or attachments, please check them for viruses and other
defects.
Post by Ron Hawkins
________________________________
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
********************************************************
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Shivang Sharma
2019-09-22 09:46:56 UTC
Permalink
Hi,

My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
ITschak Mugzach
2019-09-22 10:15:01 UTC
Permalink
You haven't described any problem...

ITschak
Post by Shivang Sharma
Hi,
My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jon Perryman
2019-09-22 14:37:19 UTC
Permalink
My dataset is less the max limit . VIO has support for BDAM as well.

VIO should not cause a hang. Report the problem to IBM. This will have you take a dump so they can look at why your jobs are hanging.

Jon.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2019-09-23 00:39:14 UTC
Permalink
Shivang,

My first thought is you have not described a problem. Page outs are a response to memory conditions, but they don't slow anything down. Page-ins and the page-in rate for all address are indications of a potential problem, and you do not mention page-ins.

You said you are no memory constrained, but how are you verifying that? You can check AFQ and UIC values during the interval when you saw the page-outs happening. SMF Type 71 is usually the starting place for looking for memory contention, especially the page-in rate.

Is there a resource class limit on the service class for these jobs?



RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VIO dataset problem

Hi,

My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mullen, Patrick
2019-09-23 14:58:28 UTC
Permalink
I've heard "my job is paged out" when what is meant is "my job is swapped out", perhaps this is the OP's situation.


-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Ron Hawkins
Sent: Sunday, September 22, 2019 7:39 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXT] Re: VIO dataset problem

Shivang,

My first thought is you have not described a problem. Page outs are a response to memory conditions, but they don't slow anything down. Page-ins and the page-in rate for all address are indications of a potential problem, and you do not mention page-ins.

You said you are no memory constrained, but how are you verifying that? You can check AFQ and UIC values during the interval when you saw the page-outs happening. SMF Type 71 is usually the starting place for looking for memory contention, especially the page-in rate.

Is there a resource class limit on the service class for these jobs?



RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VIO dataset problem

Hi,

My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Betten
2019-09-23 15:15:37 UTC
Permalink
Just for clarification, I've been working with Shivang on this and he's
since opened a PMR on the problem. When his job uses VIO even for a very
small file, it automatically pages out for the writes and pages in for the
reads. With RMF we clearly see there is plenty of available memory.
We've since tied this to the use of journaling (JOURNAL=YES specified for
the job class). Without journalling, the same job does no VIO paging.
We'll let the normal support process play out and post back the eventual
determination of what's causing this.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 09/23/2019 10:03 AM
Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem
I've heard "my job is paged out" when what is meant is "my job is
swapped out", perhaps this is the OP's situation.
-----Original Message-----
Sent: Sunday, September 22, 2019 7:39 PM
Subject: [EXT] Re: VIO dataset problem
Shivang,
My first thought is you have not described a problem. Page outs are
a response to memory conditions, but they don't slow anything down.
Page-ins and the page-in rate for all address are indications of a
potential problem, and you do not mention page-ins.
You said you are no memory constrained, but how are you verifying
that? You can check AFQ and UIC values during the interval when you
saw the page-outs happening. SMF Type 71 is usually the starting
place for looking for memory contention, especially the page-in rate.
Is there a resource class limit on the service class for these jobs?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Sent: Sunday, 22 September 2019 19:47
Subject: Re: [IBM-MAIN] VIO dataset problem
Hi,
My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2019-09-23 16:00:23 UTC
Permalink
The purpose of journaling is to allow a job to be restarted.

In order to restart a job which is using VIO, the VIO data sets need
to be preserved.

In order for the VIO data sets to be preserved, they must be written
out to page data sets, Real storage owned by a job is not
preserved.

The system is behaving exactly as intended. If your job does not
require restart capability, you should run it in a job class which is
defined with JOURNAL=NO.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date: 09/23/2019 11:53 AM
Subject: Re: [EXT] Re: VIO dataset problem
Just for clarification, I've been working with Shivang on this and he's
since opened a PMR on the problem. When his job uses VIO even for a
very
small file, it automatically pages out for the writes and pages in for
the
reads. With RMF we clearly see there is plenty of available memory.
We've since tied this to the use of journaling (JOURNAL=YES specified
for
the job class). Without journalling, the same job does no VIO paging.
We'll let the normal support process play out and post back the eventual
determination of what's causing this.
Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 09/23/2019 10:03 AM
Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem
I've heard "my job is paged out" when what is meant is "my job is
swapped out", perhaps this is the OP's situation.
-----Original Message-----
Sent: Sunday, September 22, 2019 7:39 PM
Subject: [EXT] Re: VIO dataset problem
Shivang,
My first thought is you have not described a problem. Page outs are
a response to memory conditions, but they don't slow anything down.
Page-ins and the page-in rate for all address are indications of a
potential problem, and you do not mention page-ins.
You said you are no memory constrained, but how are you verifying
that? You can check AFQ and UIC values during the interval when you
saw the page-outs happening. SMF Type 71 is usually the starting
place for looking for memory contention, especially the page-in rate.
Is there a resource class limit on the service class for these jobs?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Behalf Of Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
Subject: Re: [IBM-MAIN] VIO dataset problem
Hi,
My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Hawkins
2019-09-24 05:53:35 UTC
Permalink
But of course you follow up that journaling with CLPA at IPL...


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of
Jim Mulder
Sent: Tuesday, 24 September 2019 02:00
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXT] Re: VIO dataset problem

The purpose of journaling is to allow a job to be restarted.

In order to restart a job which is using VIO, the VIO data sets need to be
preserved.

In order for the VIO data sets to be preserved, they must be written out to
page data sets, Real storage owned by a job is not preserved.

The system is behaving exactly as intended. If your job does not require
restart capability, you should run it in a job class which is defined with
JOURNAL=NO.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date: 09/23/2019 11:53 AM
Subject: Re: [EXT] Re: VIO dataset problem
Just for clarification, I've been working with Shivang on this and
he's since opened a PMR on the problem. When his job uses VIO even
for a
very
small file, it automatically pages out for the writes and pages in for
the
reads. With RMF we clearly see there is plenty of available memory.
We've since tied this to the use of journaling (JOURNAL=YES specified
for
the job class). Without journalling, the same job does no VIO paging.
We'll let the normal support process play out and post back the
eventual determination of what's causing this.
Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 09/23/2019 10:03 AM
Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem Sent by: IBM
I've heard "my job is paged out" when what is meant is "my job is
swapped out", perhaps this is the OP's situation.
-----Original Message-----
Sent: Sunday, September 22, 2019 7:39 PM
Subject: [EXT] Re: VIO dataset problem
Shivang,
My first thought is you have not described a problem. Page outs are
a response to memory conditions, but they don't slow anything down.
Page-ins and the page-in rate for all address are indications of a
potential problem, and you do not mention page-ins.
You said you are no memory constrained, but how are you verifying
that? You can check AFQ and UIC values during the interval when you
saw the page-outs happening. SMF Type 71 is usually the starting
place for looking for memory contention, especially the page-in rate.
Is there a resource class limit on the service class for these jobs?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Behalf Of Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
Subject: Re: [IBM-MAIN] VIO dataset problem
Hi,
My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOP NM
2019-09-24 06:44:27 UTC
Permalink
Jim,

It is obvious that pages must be paged out for Journaling, but must they also be paged in, can't they be reclaimed when plenty memory is available?

Kees.
Post by Ron Hawkins
-----Original Message-----
Behalf Of Jim Mulder
Sent: 23 September, 2019 18:00
Subject: Re: [EXT] Re: VIO dataset problem
The purpose of journaling is to allow a job to be restarted.
In order to restart a job which is using VIO, the VIO data sets need
to be preserved.
In order for the VIO data sets to be preserved, they must be written
out to page data sets, Real storage owned by a job is not
preserved.
The system is behaving exactly as intended. If your job does not
require restart capability, you should run it in a job class which is
defined with JOURNAL=NO.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date: 09/23/2019 11:53 AM
Subject: Re: [EXT] Re: VIO dataset problem
Just for clarification, I've been working with Shivang on this and he's
since opened a PMR on the problem. When his job uses VIO even for a
very
small file, it automatically pages out for the writes and pages in for
the
reads. With RMF we clearly see there is plenty of available memory.
We've since tied this to the use of journaling (JOURNAL=YES specified
for
the job class). Without journalling, the same job does no VIO paging.
We'll let the normal support process play out and post back the eventual
determination of what's causing this.
Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
Date: 09/23/2019 10:03 AM
Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem
I've heard "my job is paged out" when what is meant is "my job is
swapped out", perhaps this is the OP's situation.
-----Original Message-----
Behalf Of Ron Hawkins
Sent: Sunday, September 22, 2019 7:39 PM
Subject: [EXT] Re: VIO dataset problem
Shivang,
My first thought is you have not described a problem. Page outs are
a response to memory conditions, but they don't slow anything down.
Page-ins and the page-in rate for all address are indications of a
potential problem, and you do not mention page-ins.
You said you are no memory constrained, but how are you verifying
that? You can check AFQ and UIC values during the interval when you
saw the page-outs happening. SMF Type 71 is usually the starting
place for looking for memory contention, especially the page-in rate.
Is there a resource class limit on the service class for these jobs?
RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-----Original Message-----
Behalf Of Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
Subject: Re: [IBM-MAIN] VIO dataset problem
Hi,
My dataset is less the max limit . VIO has support for BDAM as well.
Not sure on what is left to check?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2019-09-22 18:54:55 UTC
Permalink
It is normal for VIO to be paged out and it is normal for VIO to not be paged out; why do you believe that what is happening is abnormal or a problem?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Shivang Sharma <***@GMAIL.COM>
Sent: Saturday, September 21, 2019 3:33 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: VIO dataset problem

Hi everybody,

I am facing an unusual problem with VIO datasets.
I submit 5 instances of the same job within a span of 5 minutes.
Out of them 3 shows VIO being paged out . The other runs seems to
be fine . Not able to understand what can be causing this?

Thanks in advance.

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

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