Re: ADRDSSU and encrypted files

[Ron Hawkins]

Cameron,

I have forgotten more than I knew, and searching manuals no longer comes easy. 
Someone earlier mentioned using REPRO to decrypt the file as you back it up.

DF/dss will use REPRO for a logical backup, and the backup file is not 
encrypted.

The question then is, "When restoring, does DF/dss require the target dataset 
to be encrypted from a logical backup?" 

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Glenn Wilcock
Sent: Friday, 5 November 2021 2:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ADRDSSU and encrypted files

Hi Cameron, to answer your base question... No, ADRDSSU does not support 
decrypting an encrypted file during the dump process.

--
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: CICS VSAM LSR pools and IBM DASD PPRC type mirroring.

[Ron Hawkins]

Radoslaw,

Isn't this also the case for VSAM when you lose your OS with the files open?

I may be out of date or have a lapse in memory, but I recall a file journaling 
option that allowed CICS to roll forward/back updates to a file with LSR 
buffered writes.

It could be just another senior moment.

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, 8 October 2021 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] CICS VSAM LSR pools and IBM DASD PPRC type mirroring.

W dniu 23.09.2021 o 22:21, Ward, Mike S pisze:
> Hello, all. I don't know if any of you are doing disk replication to a DR 
> site, but we are, and we are trying to resolve a specific problem with CICS 
> and VSAM file.
>
> CICS, in the case of LSR pools hold the data in the buffers until a buffer 
> shortage\wait type of condition occurs. When that happens CICS flushes the 
> buffers and updates the high used RBA's of the files. In the case of a DR 
> test. We use the data as is. We copy the current replicating data to other 
> DASD so that we can perform the test by bringing up the system and testing 
> it. Well the only way we can think of making sure we get all the VSAM data is 
> by closing the files at the production site which is not feasible. Is anyone 
> else doing this kind of mirroring, and are there things you are doing that 
> fixe the VSAM buffering problem? The only thing I can think of doing is 
> adjusting the LSR buffer pools so that waits occur every so many minutes, I'm 
> staying away from share option 4,4 on the VSAM files which are a real 
> performance hit. Any takers are welcome. Also as an aside the implication 
> here is that in the case of a real disaster there is data missing from the 
> VSAM files, or am I wrong and full of it? Any help, opinions, whatever are 
> welcome.

General rule: PPRC and other methods is for "wise" applications. That mean the 
application/system must survive sudden blackout with no harm to data 
consistency. Otherwise remote copy is fuzzy.
Yes, both asynchronous and synchronous remote copy are for disaster recovery. 
What does it mean? Fire, bomb, flood, power outage, whatever else. In any case 
the applications on the remote site is more or less like someone switched off 
power in the server during... of course, we don't know when and we cannot 
demand prerequisite actions. It is sudden, unexpected. The only difference 
between power outage and DR is the application is restarted on another machine.
Conclusion: your system elements have to be "wise" or DR aware. This is called 
transactional system. Not because it processes business transactions, but it 
processes transactions as Logical Unit of Works. 
Yes, you can loose not finished transaction, but this is all-or-nothing. 
Transaction is committed or not. Whole one.
How does it relate to CICS and LSR? Similarly to DB2 and bufferpools. 
Bufferpools are good, but committed transaction has to be written on DASD, in 
the transaction log.

BTW: SHR(4,4) is good in z/VSE, not in z/OS.


--
Radoslaw Skorupka
Lodz, Poland

--
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: GDG relative number updates

[Ron Hawkins]

I always thought JES2 resolved relative GDG numbers during job initiation. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Joseph Reichman
Sent: Wednesday, 27 May 2020 11:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] GDG relative number updates

Hi

I have have my sdump file DSN as a GDG I save the dsn name in the variable
portion of the SDWA I am wondering when the system updates the relative
number is it after a close and when you open the dataset again  the number
has been updated 

Thanks  

--
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: VIO dataset problem

[Ron Hawkins]

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  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, 24 September 2019 16:32
To: IBM-MAIN@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.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ron Hawkins
> Sent: 24 September, 2019 7:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Allan Staller
> Sent: Monday, 23 September 2019 22:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Steve Thompson
> Sent: Saturday, September 21, 2019 10:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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
> 
> 
> > On Sep 21, 2019, at 9:22 PM, Shivang Sharma  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 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
> ::DISCLAIMER::
> 
> 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 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 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 th

Re: [EXT] Re: VIO dataset problem

[Ron Hawkins]

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  On Behalf Of
Jim Mulder
Sent: Tuesday, 24 September 2019 02:00
To: IBM-MAIN@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


David Betten/Gaithersburg/IBM@IBMUS wrote on 09/23/2019 11:15:05 AM:

> From: David Betten/Gaithersburg/IBM@IBMUS
> To: ibm-main@listserv.ua.edu
> 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
> email:  bet...@us.ibm.com
> 
> IBM Mainframe Discussion List  wrote on
> 09/23/2019 09:58:15 AM:
> 
> > From: "Mullen, Patrick" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 09/23/2019 10:03 AM
> > Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem Sent by: IBM 
> > Mainframe Discussion List 
> >
> > 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  On 
> > Behalf Of Ron Hawkins
> > Sent: Sunday, September 22, 2019 7:39 PM
> > To: IBM-MAIN@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  On 
> > Behalf Of Shivang Sharma
> > Sent: Sunday, 22 September 2019 19:47
> > To: IBM-MAIN@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 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: VIO dataset problem

[Ron Hawkins]

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-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Monday, 23 September 2019 22:35
To: IBM-MAIN@LISTSERV.UA.EDU
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-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Saturday, September 21, 2019 10:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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


> On Sep 21, 2019, at 9:22 PM, Shivang Sharma  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 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
::DISCLAIMER::

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 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: z15 from IBM i perspective

[Ron Hawkins]

I like the scientific phraseology: four-fifths of five-eighths of FA.


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  On Behalf Of 
David Spiegel
Sent: Tuesday, 24 September 2019 10:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] z15 from IBM i perspective

Maybe, you could supply the original expression, Chotsh?

On 2019-09-23 18:28, Seymour J Metz wrote:
> ObPedant "I could care less?"
>
> "I could care less." is the result of translating an ironic question in 
> Yiddish into a meaningless statement in English, probably because somebody 
> had a tin ear and didn't pick up on the inflection indicating that it was a 
> question.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> mu.edu%2F~smetz3data=02%7C01%7C%7Cac626ebb1afb4247665608d74075724
> 3%7C84df9e7fe9f640afb435%7C1%7C0%7C637048745527292386
> sdata=r2SOqQNRVpB4yAxTR%2FeCjZUw0RFjYBIyo%2BZTOt%2B73pE%3Dreserve
> d=0
>
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Phil Smith III 
> Sent: Monday, September 23, 2019 4:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z15 from IBM i perspective
>
> Charles Mills wrote:
>
>> Interesting article even if you could care less about the IBM i (AS/400 for 
>> anyone who has been living under a rock for the past 20 years).
>
>
> "couldn't care less" :)
>
>
>
> BTW, just to be irritatingly pedantic: IBM i is not really AS/400. It's what 
> AS/400 developed into, but it refers to the current generation of the AS/400 
> OS (formerly OS/400) running on IBM Power. From Wikipedia:
>
> IBM i is an operating system that runs on IBM Power Systems and IBM 
> PureSystems. It was named OS/400 when it was introduced with the AS/400 line 
> of computer systems in 1988, was later renamed i5/OS, and was renamed IBM i 
> in 2008 when IBM Power Systems was introduced.
>
>
>
> So it's confusing, because "AS/400" begat "iSeries" begat "System i" begat 
> "IBM i", only IBM i implies "on Power", whereas the others imply "on bespoke 
> hardware". Sort of as if Apple had renamed Mac OS to macOS when they went to 
> Intel hardware (which is not when they did that).
>
>
>
> This doesn't really matter nowadays, since anything old enough to be 
> pre-Power is very obsolete, but it's sorta interesting. I find that customers 
> still say "AS/400"; none of the "i" names appear to have ever really caught 
> on.
>
>
>
> Related: It's "IBM Power", not "PowerPC". PowerPC is the very old precursor 
> to the current generation; this is much like saying your shiny new ThinkPad 
> has a 386-it's sorta kinda in the neighborhood, but really just wrong.
>
>
>
> Signed,
>
> Mr. Pedantic
>
>
> --
> 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

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

Re: VIO dataset problem

[Ron Hawkins]

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  On Behalf Of 
Shivang Sharma
Sent: Sunday, 22 September 2019 19:47
To: IBM-MAIN@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 
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: Erase On Scratch

[Ron Hawkins]

Jesse,

Nowadays you would still be long gone, but depending on media, pool occupancy, 
and page migration, there will likely be large areas of in the clear content, 
unless accessed by CKD.

Next time, ask your vendor about disk scrubbing.


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  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, 12 September 2019 03:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Erase On Scratch

My only experience with EOS was as the *last* step of a DR test conducted 
(across country) at IBM Business Recovery Center in Tampa. Per IBM 
recommendation, we reinitialized all customer DASD volumes with full-volume 
data sets marked as EOS. Then we started a mass delete procedure and left for 
home. This was in the days of SLED. We were long gone when the procedure ended. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, September 10, 2019 11:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Erase On Scratch

Ron,

Was EOS intended for disks that are removed to make sure they contain no 
valuable data or was it intended to prevent deleted data from being read again 
by another application? I thought the latter. Disks are usually removed because 
they break down, with valuable, undeleted data on them.

Does you proposal cover dumping a disk with DFdss/FDR and searching the tape 
for interesting data?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ron Hawkins
> Sent: 11 September, 2019 3:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Erase On Scratch
> 
> Larre,
> 
> EOS operates on the basis that you overwrite the only location where 
> the data has existed on the backend media in your storage. That's was 
> an outdated concept back in the Iceberg/RVA days, and has become even 
> more so with in-system and remote replication, load balancing and 
> migration with thin provisioning, and write levelling in flash storage.
> 
> The reality of EOS is it is a dead concept for data at rest, and 
> vendors are providing encryption and erasure processing to scrub media 
> before removing it. I see the only goal of EOS as making the contents 
> of the data set unavailable to z/OS, which does not require 
> overwriting all the contents of the data set.
> 
> With that in mind, I suggest that an option for EOS that nerfs HAR0 to 
> an empty track, and leave it that. I believe all three vendors now 
> keep HAR0 in a table with good locality of reference, so from the 
> storage perspective this would be very efficient. It also eliminates 
> the often huge amount of data transfer required to overwrite the old 
> data, for the same resulting security from the host, which in turns 
> reduces the latency of EOS when you delete a dataset. In all cases the 
> data transfer reduction would flow on to replication.
> 
> Move out of the past, and stop fooling ourselves that EOS is erasing 
> anything, and optimise it to obfuscate the data from CKD host only, as 
> that is all it is doing anyway.
> 
> 
> 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  On 
> Behalf Of Larre Shiller
> Sent: Wednesday, 11 September 2019 04:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Erase On Scratch
> 
> Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved 
> the performance of the Erase-On-Scratch (EOS) function over the 
> pre-z/OS 2.1 releases by increasing the number of tracks that can be 
> "erased" in each channel program from 1 to 255 to 12,240.  The good 
> news is that with those changes (on the software side) there was a 
> drastic reduction in both elapsed time as well as an I/O count 
> reduction, but these I/O operations are asynchronous and as such, most 
> customers are concerned about suffering the performance hit that it 
> takes to implement EOS, especially with replicated DASD.  IBM believes 
> that there is a lot of latent interest in using this function, but 
> most customers are simply not using it because of the potential 
> performance impact, including myself.  And even if customers are using 
> it, they are using it only for a subset of data sets.  IBM would like 
> to drive the use Erase-On-Scratch use up and get most, if not all 
> customers using it because of the security exposure that exists and that IBM 
> would like to eliminate.
> 
> IBM has been having some internal discussions about improvements that 
> revolve around a combination 

Re: Erase On Scratch

[Ron Hawkins]

Kees,

I believed the design of EOS is your latter case, but I feel there is some 
questionable belief out there that it can address the first case. Nerfing HAR0 
addresses your latter case.

Have you ever swapped out an old DASD controller for a new one? What did you do 
with the old drives? Drives replaced due to failure prediction can still be 
scrubbed, but may require connection to an external interface for single 
drives. There are a rare, few customers that have failed drives sitting on 
shelves, and sometimes they degauss these or have some fun with sledgehammers 
on the weekend (true story). You can have flash drives wiped as well, but it 
would be by a 3rd party. Flash write levelling defeats Controller or software 
secure-erase. Think log-structured files in Iceberg.

Yes, my proposal covers dumping the DASD with a CKD utility. A physical dump 
with DFSMSdss will honour HAR0 empty tracks, and will not read anything else. 
How would it know what to read with no data length information? More 
interestingly, if you could read an empty track, what would the controller 
return from a reclaimed or migrated empty track? For IBM and HDS, HAR0 is just 
a field in a table stored separately from the actual track contents.

Thanks for asking Kees, and making me exercise some brain cells. If I am wrong 
on anything, I hope someone will educate me.


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  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, 11 September 2019 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Erase On Scratch

Ron,

Was EOS intended for disks that are removed to make sure they contain no 
valuable data or was it intended to prevent deleted data from being read again 
by another application? I thought the latter. Disks are usually removed because 
they break down, with valuable, undeleted data on them.

Does you proposal cover dumping a disk with DFdss/FDR and searching the tape 
for interesting data?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ron Hawkins
> Sent: 11 September, 2019 3:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Erase On Scratch
> 
> Larre,
> 
> EOS operates on the basis that you overwrite the only location where 
> the data has existed on the backend media in your storage. That's was 
> an outdated concept back in the Iceberg/RVA days, and has become even 
> more so with in-system and remote replication, load balancing and 
> migration with thin provisioning, and write levelling in flash storage.
> 
> The reality of EOS is it is a dead concept for data at rest, and 
> vendors are providing encryption and erasure processing to scrub media 
> before removing it. I see the only goal of EOS as making the contents 
> of the data set unavailable to z/OS, which does not require 
> overwriting all the contents of the data set.
> 
> With that in mind, I suggest that an option for EOS that nerfs HAR0 to 
> an empty track, and leave it that. I believe all three vendors now 
> keep HAR0 in a table with good locality of reference, so from the 
> storage perspective this would be very efficient. It also eliminates 
> the often huge amount of data transfer required to overwrite the old 
> data, for the same resulting security from the host, which in turns 
> reduces the latency of EOS when you delete a dataset. In all cases the 
> data transfer reduction would flow on to replication.
> 
> Move out of the past, and stop fooling ourselves that EOS is erasing 
> anything, and optimise it to obfuscate the data from CKD host only, as 
> that is all it is doing anyway.
> 
> 
> 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  On 
> Behalf Of Larre Shiller
> Sent: Wednesday, 11 September 2019 04:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Erase On Scratch
> 
> Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved 
> the performance of the Erase-On-Scratch (EOS) function over the 
> pre-z/OS 2.1 releases by increasing the number of tracks that can be 
> "erased" in each channel program from 1 to 255 to 12,240.  The good 
> news is that with those changes (on the software side) there was a 
> drastic reduction in both elapsed time as well as an I/O count 
> reduction, but these I/O operations are asynchronous and as such, most 
> customers are concerned about suffering the performance hit that it 
> takes to implement EOS, especially with replicated DASD.  IBM believes 
> that there is a lot of latent interest in using thi

Re: Erase On Scratch

[Ron Hawkins]

Larre,

EOS operates on the basis that you overwrite the only location where the data 
has existed on the backend media in your storage. That's was an outdated 
concept back in the Iceberg/RVA days, and has become even more so with 
in-system and remote replication, load balancing and migration with thin 
provisioning, and write levelling in flash storage. 

The reality of EOS is it is a dead concept for data at rest, and vendors are 
providing encryption and erasure processing to scrub media before removing it. 
I see the only goal of EOS as making the contents of the data set unavailable 
to z/OS, which does not require overwriting all the contents of the data set.

With that in mind, I suggest that an option for EOS that nerfs HAR0 to an empty 
track, and leave it that. I believe all three vendors now keep HAR0 in a table 
with good locality of reference, so from the storage perspective this would be 
very efficient. It also eliminates the often huge amount of data transfer 
required to overwrite the old data, for the same resulting security from the 
host, which in turns reduces the latency of EOS when you delete a dataset. In 
all cases the data transfer reduction would flow on to replication.

Move out of the past, and stop fooling ourselves that EOS is erasing anything, 
and optimise it to obfuscate the data from CKD host only, as that is all it is 
doing anyway.


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  On Behalf Of 
Larre Shiller
Sent: Wednesday, 11 September 2019 04:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Erase On Scratch

Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved the 
performance of the Erase-On-Scratch (EOS) function over the pre-z/OS 2.1 
releases by increasing the number of tracks that can be "erased" in each 
channel program from 1 to 255 to 12,240.  The good news is that with those 
changes (on the software side) there was a drastic reduction in both elapsed 
time as well as an I/O count reduction, but these I/O operations are 
asynchronous and as such, most customers are concerned about suffering the 
performance hit that it takes to implement EOS, especially with replicated 
DASD.  IBM believes that there is a lot of latent interest in using this 
function, but most customers are simply not using it because of the potential 
performance impact, including myself.  And even if customers are using it, they 
are using it only for a subset of data sets.  IBM would like to drive the use 
Erase-On-Scratch use up and get most, if not all customers using it because of 
the security exposure that exists and that IBM would like to eliminate.

IBM has been having some internal discussions about improvements that revolve 
around a combination of hardware/microcode and z/OS software changes that, if 
implemented in z/OS and the DASD subsystem, would bring the overhead of using 
EOS down to the point where the overhead would not be noticed.

But... the folks involved in bringing that to market need our help.  There's an 
RFE that we can vote for that would show the level of interest in this 
function.  If your Auditors or internal security folks are concerned about 
residual data on DASD and would like to see you using EOS but you are concerned 
about the overhead, please consider voting for the following enhancement to 
help bring this new functionality to market:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=134047

Thanks!

Larre Shiller
US Social Security Administration

--
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: GDPS, Metro Mirror, Global Mirror

[Ron Hawkins]

Jesse,

EMC has a few different types of SRDF, both synchronous and asynchronous.

Hitachi has TrueCopy, which is synchronous and can be mixed on the floor with 
the IBM kit for point in time replication as long as the connection is between 
the same vendor. GDPS can manage TrueCopy for Hyperswap and metro replication. 
Hitachi also has Universal Replicator (HUR) for asynchronous replication. You 
can describe HUR as XRC in a can, but it has some link recovery advantages over 
XRC. You can use HUR with TrueCopy for 3DC. 

I'm out of date on IBM's GDPS support for EMC and Hitachi, but they were 
supporting GDPS services on those platforms 12 months ago, so IBM is not the 
only choice, even if you go the GDPS automation route.


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  On Behalf Of 
Jesse 1 Robinson
Sent: Wednesday, 28 August 2019 09:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDPS, Metro Mirror, Global Mirror

We’ve used XRC for DR for two decades, the first decade without GDPS (in-house 
RYO), much easier after we added GDPS. Some of your 'options' are determined by 
hardware. For example, with XRC, your source volumes must be IBM, but the 
target volumes can be any flavor. Dell/EMC has their own protocol (SRDF?). I 
think Hitachi has yet another one. So start with the options that are available 
for your gear unless your mgmt is so hot to trot that they would sweep the 
floor to get this going.

Having lived with DR in a suitcase for ages before mirroring, I can verify that 
the old Harold Hill technique is strictly last century. 



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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Hawkins
Sent: Tuesday, August 27, 2019 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GDPS, Metro Mirror, Global Mirror

Fred,

Have a look outside the nine dots at what the other vendors are offering.

There is more than one way to skin a cat, and the IBM products and services are 
not necessarily the best or most cost-effective way to get the job done.


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  On Behalf Of Tom 
Conley
Sent: Tuesday, 27 August 2019 03:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDPS, Metro Mirror, Global Mirror

On 8/26/2019 10:11 AM, fred glenlake wrote:
> Hi List,
> 
> I am looking for some direction on how to get up to speed with GDPS, Metro 
> Mirror, Global Mirror, etc.   My site has been a single site for quite some 
> time and DR tests have been go to a DR provider, lug the physical tapes along 
> of the latest backups and spend a few days restoring before turning it over 
> to selected users to break...ertest.
> 
> Now the light bulbs have gone off in the executive suites and they want to 
> establish and second and possibly third site with replication out of state 
> (200+ miles away), the whole ball of wax.   Go from zero to 200MPH right away 
> and of course I have never set one of these up and made them work.
> 
> I am starting to download the IBM manuals on the stuff so I can enhance my 
> insomnia reading collection, I just want to make sure I am reading up on the 
> correct material as there seems to be quite a bit available.
> 
> Hence any suggestions, comments on how to get myself up to speed in a 
> reasonable amount of time would be greatly appreciated.
> 
> Also if this is not the correct list for this type of question and there is 
> another more appropriate list please let me know so I may ask in the 
> appropriate list.
> 
> Many thanks,
> 
> Fred G.
> 

Fred,

GDPS is not just a product, it is a service sold by IBM.  IBM will configure, 
set up, and install GDPS to get you up and running, with periodic visits to 
ensure that you're up to snuff.  Your management needs to brace themselves, 
because even the smallest shops are looking at 7+ figures to install GDPS.  
I've worked with the teams doing it. 
It's an awesome solution for recovery, with a price tag to match.

If your company is a SHARE member, the SHARE GDPS presentations have excellent 
overview information.  GDPS is based on NetView and SA/390, so you should read 
up on them as well.  Metro and Global mirror are PPRC and XRC based, so get 
familiar with them.

Good luck,
Tom Conley


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

Re: GDPS, Metro Mirror, Global Mirror

[Ron Hawkins]

Fred,

Have a look outside the nine dots at what the other vendors are offering.

There is more than one way to skin a cat, and the IBM products and services are 
not necessarily the best or most cost-effective way to get the job done.


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  On Behalf Of Tom 
Conley
Sent: Tuesday, 27 August 2019 03:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDPS, Metro Mirror, Global Mirror

On 8/26/2019 10:11 AM, fred glenlake wrote:
> Hi List,
> 
> I am looking for some direction on how to get up to speed with GDPS, Metro 
> Mirror, Global Mirror, etc.   My site has been a single site for quite some 
> time and DR tests have been go to a DR provider, lug the physical tapes along 
> of the latest backups and spend a few days restoring before turning it over 
> to selected users to break...ertest.
> 
> Now the light bulbs have gone off in the executive suites and they want to 
> establish and second and possibly third site with replication out of state 
> (200+ miles away), the whole ball of wax.   Go from zero to 200MPH right away 
> and of course I have never set one of these up and made them work.
> 
> I am starting to download the IBM manuals on the stuff so I can enhance my 
> insomnia reading collection, I just want to make sure I am reading up on the 
> correct material as there seems to be quite a bit available.
> 
> Hence any suggestions, comments on how to get myself up to speed in a 
> reasonable amount of time would be greatly appreciated.
> 
> Also if this is not the correct list for this type of question and there is 
> another more appropriate list please let me know so I may ask in the 
> appropriate list.
> 
> Many thanks,
> 
> Fred G.
> 

Fred,

GDPS is not just a product, it is a service sold by IBM.  IBM will configure, 
set up, and install GDPS to get you up and running, with periodic visits to 
ensure that you're up to snuff.  Your management needs to brace themselves, 
because even the smallest shops are looking at 7+ figures to install GDPS.  
I've worked with the teams doing it. 
It's an awesome solution for recovery, with a price tag to match.

If your company is a SHARE member, the SHARE GDPS presentations have excellent 
overview information.  GDPS is based on NetView and SA/390, so you should read 
up on them as well.  Metro and Global mirror are PPRC and XRC based, so get 
familiar with them.

Good luck,
Tom Conley

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

[Ron Hawkins]

Shmuel,

I am a novice when it comes to some of the deep dive stuff that you guys
meander off, and into.

I was thinking a GTF SSCH trace off a volume allocating a data set with
IEFBR14 may be a starting point, along with looking for any SMF records
generated at the time of allocation would be a good starting point to test
the hypotheses.

Do you have any additional ideas that would add to what and how SMF
recording occurs when allocating a file with IEFBR14?

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  On Behalf Of
Seymour J Metz
Sent: Tuesday, 27 August 2019 03:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMF PUZZLE

If you are configured for automatic EOF, then Allocation will write an EOF
regardless of the program name; there's nothing special about IEFBR14 except
for a performance tweak. There is no OPEN involved.


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



From: IBM Mainframe Discussion List  on behalf of
Clark Morris 
Sent: Saturday, August 24, 2019 5:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF PUZZLE

[Default] On 24 Aug 2019 13:41:23 -0700, in bit.listserv.ibm-main
martin_pac...@uk.ibm.com (Martin Packer) wrote:

>Allocation doesn't cause SMF 14/15 to be written. CLOSE (and therefore
>OPEN) does.

If a data set is allocated by IeFBr14 on an SMS disk, as I understand it, it
will have an EOF record as its first record.  Thus it can be read (as a zero
record file) by a subsequent program or job and deleted thus from an SMF
point of view a file can be read and deleted without ever having been
created.

Clark Morris
>
>I guess, from the original post, data is written so presumably some 
>form of OPEN took place.
>
>Cheers, Martin
>
>Martin Packer
>
>zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
>+44-7802-245-584
>
>email: martin_pac...@uk.ibm.com
>
>Twitter / Facebook IDs: MartinPacker
>
>Blog:
>https://secure-web.cisco.com/1jWfMC4FDTdzncrPWLkLBC97mhpriVujWYooUizSQ6
>hb0k9sN_oOVeg_WgS7GzM5YpYMYtZp-nnbEDiUw-EiD_OHn9QfBsrSqe_ImSMiG31ra9yfP
>AKUDO05uAmHYthKUHaVBrfwEeROqG-WIELMpqDHuKRv8kVKLMqhdEKAUDrpYV9DHZXZ-0OU
>wiNug5NoU_--dlnI8GGbV16C0r0eIpD408r2exKQiMLt9N_lvB1-DehKvsvhBCv-pNqRvUn
>E7KCKxVJsXSaBl4TzvUhgoawSvaqvIbVuu3koAvZ5BlDLfaLlacfawRWmzJ1QtVNtACHvb0
>a9SXZvdHjy_B9u1v5t5l-QIF6pOxwaepas8xdB44mVkbr0rn98BFivnfVvuwSi94lP63Xxj
>Ylwb2q5PwrF7_hhdQ30WFCftH1szu91swRPCtGtwhYIxOmYJLfy9/https%3A%2F%2Fwww.
>ibm.com%2Fdeveloperworks%2Fmydeveloperworks%2Fblogs%2FMartinPacker
>
>Podcast Series (With Marna Walle):
https://secure-web.cisco.com/1yhNrHArR0hNFGwHN0qBqalN1WcEEZiI_aRSlqBs8tumOw9
lf_q4tgH_CIKjxvULkgukqhvEv6i_SPyGGT3gLSQRyV4splC5NE73vPb0WAFrSjtXrnOpXkon6CP
64pGjB9Ljwt2lX7dckT8nz-ne7qQci7WWHL7FG1HWQ9UqqBaG1WmEfMYd_d49r81HzdLvkVcMrP0
X1WIuVgsQiENPM5KNuKnIlUkckvt0dqjLV6r-ERIteEtdwuIxTrLiT4aWA_Gy04iLU85zhTLsQi5
g8MILX6vEQ67nzVe2IEiWIQnxBXX9TnONUxqi9OZgaqN_faxWQTWH9oWnqasqa9XlteUhIt0kmnA
c8CMikcnMKd2OqgpCyAgh1EUxe-iazvu3mIgeOJPT40iT0_77fxBjLJF-rHOltCE7N1OkCoyEz73
Z8LMx6SjRfPHLYku3cTxh-/https%3A%2F%2Fdeveloper.ibm.com%2Ftv%2Fmpt%2For
>
>https://secure-web.cisco.com/1W9EfBzfL20vS0dm4Oso2UK0eyDeYRwOuEe-o4U1w8
>_DiX-llP5CA4n_Zs3Yd1S9vNtL1UvCv6w5dPFkMDxS_p0UB57f4hauVw8vPCuCPt09vx2DD
>y3Xov42l6fSafLc96QKFEJURN0tyg3VKXnGLnnvW8q4rhePIT48WgQU2DrLE-wFj_KesthA
>uhbYEaEQjVrN8k0nicbrGTbEjKznyIs4RUAHWPNRUukA-sueWDq4_MUrMiFIWAj8vlzvNGj
>mtsn_6jFw2GS7tmdCwHXB7BNf9pag8xghXcp6YkrDw8pyym_PYTUN-F4GeI9YX-yvuUzGj7
>u5IOWG3Fd5jJu4Ppikdh85_V7kPjjLqpdiQWKgs9bTYLqLvfy5Sp9W2VmBA08KQAMVOazDe
>SyFcUBYV1A7WgNaYgWlP92w02ADvhXyo7fFZK3h87wALc014bMJt/https%3A%2F%2Fitun
>es.apple.com%2Fgb%2Fpodcast%2Fmainframe-performance-topics%2Fid11279435
>73%3Fmt%3D2
>
>
>Youtube channel: 
>https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
>From:   Charles Mills 
>To: IBM-MAIN@LISTSERV.UA.EDU
>Date:   24/08/2019 21:23
>Subject:Re: SMF PUZZLE
>Sent by:IBM Mainframe Discussion List 
>
>
>
>SMF only captures what you tell it to (with SMFPRMxx). Some shops, for 
>example, exclude STC's from certain SMF types "to avoid a performance 
>impact on CICS" or some similar reason. The whole "how to read SMFPRMxx"
>thing is beyond the scope of an e-mail. D SMF,O will give you a 
>not-quite-trivial-to-parse summary.
>
>SMF 15 shows "opened for output and then closed" (for those subsystems 
>for which it is configured, per the above). Harking back to the IEFBR14 
>discussion here a week or so ago, I wonder if a basic "create a DSN 
>with
>IEFBR14 DISP=(NEW,CTALG)" shows up in SMF 15 (because it does not close 
>the dataset). Others may well know.
>
>Charles
&g

Re: SMF PUZZLE

[Ron Hawkins]

All,

Could it be that the EOF mark on the file is a DADSM function outside of the 
control of the program, and that is why there is no SMF record from an 
unopened, empty data set?

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  On Behalf Of 
Brian Westerman
Sent: Sunday, 25 August 2019 16:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMF PUZZLE

Could it be as simple as having been created on one lpar (not the one you are 
processing hte records of) but deleted on the LPAR you are looking at the 
records of?

Brian

--
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: Attitude of companies toward mainframers working from home?

[Ron Hawkins]

Every other month, so 6x7=42. 

5-10 days for onsite, F2F meetings, etc outside of that schedule, so let's say 
7 days, is 49, so 11 calendar days.

I'm not sure how eleven calendar days becomes three weeks, and it still begs 
the question of who pays the California tax if some unforeseen circumstance 
blows the 60 days.


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  On Behalf Of 
Mike Schwab
Sent: Friday, 23 August 2019 02:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
home?

In California.  You said you could do 59 days in California.

On Thu, Aug 22, 2019 at 10:58 AM Ron Hawkins  wrote:
>
> Where?
>
>
> 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  On 
> Behalf Of Mike Schwab
> Sent: Friday, 23 August 2019 01:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
> home?
>
> Well, every other month would leave 3 weeks for training.
>
> On Thu, Aug 22, 2019 at 7:09 AM Ron Hawkins  wrote:
> >
> > Raphael,
> >
> > Calendar days. Vacations, public holidays, sick days, etc are all calendar 
> > days.
> >
> > Arrive on Wednesday, and leave the next Wednesday is seven days, which is 
> > only nine months at a week per month.
> >
> > Most training, customer briefing, etc also happens in California, so there 
> > are 5-10 days a year at least as well.
> >
> > If for some unforeseen we blow the 60 days, who is going to pay the 
> > employee's tax in California? If they were at 50 days and visited the 
> > amusement parks in LA for 1.5 weeks they've blown it.
> >
> > And that's the main reason it was mothballed and made ad hoc.
> >
> > 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  On 
> > Behalf Of Raphaël Jacquot
> > Sent: Thursday, 22 August 2019 17:26
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working 
> > from home?
> >
> > Le 22/08/2019 à 08:54, Ron Hawkins a écrit :
> >
> > > I liked to have our team to train and work face to face 
> > > occasionally and had regular fly-ins of the team for a week. 
> > > California killed this off as they want to declare you a tax 
> > > resident if you spend more than
> > > 60 calendar days in the state. Tell that to someone from Nevada.
> >
> > considering there are 52 weeks in a calendar year, and there are 
> > vacations / holidays / out of the country periods, you should be 
> > fine with once a week
> >
> > Raphael
> >
> > 
> > -- 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
>
>
>
> --
> 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
>
> --
> 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

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

Re: Attitude of companies toward mainframers working from home?

[Ron Hawkins]

Where?


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  On Behalf Of 
Mike Schwab
Sent: Friday, 23 August 2019 01:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
home?

Well, every other month would leave 3 weeks for training.

On Thu, Aug 22, 2019 at 7:09 AM Ron Hawkins  wrote:
>
> Raphael,
>
> Calendar days. Vacations, public holidays, sick days, etc are all calendar 
> days.
>
> Arrive on Wednesday, and leave the next Wednesday is seven days, which is 
> only nine months at a week per month.
>
> Most training, customer briefing, etc also happens in California, so there 
> are 5-10 days a year at least as well.
>
> If for some unforeseen we blow the 60 days, who is going to pay the 
> employee's tax in California? If they were at 50 days and visited the 
> amusement parks in LA for 1.5 weeks they've blown it.
>
> And that's the main reason it was mothballed and made ad hoc.
>
> 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  On 
> Behalf Of Raphaël Jacquot
> Sent: Thursday, 22 August 2019 17:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
> home?
>
> Le 22/08/2019 à 08:54, Ron Hawkins a écrit :
>
> > I liked to have our team to train and work face to face occasionally 
> > and had regular fly-ins of the team for a week. California killed 
> > this off as they want to declare you a tax resident if you spend 
> > more than
> > 60 calendar days in the state. Tell that to someone from Nevada.
>
> considering there are 52 weeks in a calendar year, and there are 
> vacations / holidays / out of the country periods, you should be fine 
> with once a week
>
> Raphael
>
> --
> 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



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

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

Re: Attitude of companies toward mainframers working from home?

[Ron Hawkins]

Not all boomerangs come back.

Not all who throw a boomerang can make it come back.

Take it from an Aussie that has unsuccessfully thrown a few boomerangs.


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  On Behalf Of 
ITschak Mugzach
Sent: Friday, 23 August 2019 00:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
home?

  John, It sounds like the buyer got an ausrellian boomerang, not an insurance 
company. your company migration story reminds me the australian that purchased 
a new boomerang, but was unable to get rid of the old one
;-)

ITschak

On Thu, Aug 22, 2019 at 2:36 PM John McKown 
wrote:

> On Wed, Aug 21, 2019 at 3:46 PM Charles Mills  wrote:
>
> > I am doing a favor for a friend who is writing a blog article on the
> above
> > subject, with an emphasis on the effect of the shrinking mainframe 
> > personnel pool. (This is NOT some disguised headhunter pitch. Reply 
> > to the list or
> to
> > me personally. I will take full responsibility for "sanitizing" your
> e-mail
> > address and so forth out of what I forward to my friend.)
> >
> > Does your employer allow mainframe sysprogs and developers to work 
> > from home?
> >
>
> Yes. The application programmers, both of them, oftern work from home. 
> The sysprogs generally don't. I'm a sysprog. If I were at home, I'd be 
> too tempted to play games.
>
>
> > Any particular restrictions or qualifications?
> >
>
> Restriction: get the job done.
>
>
>
> > Have they changed their policies specifically to address the 
> > shrinking mainframe personnel pool?
> >
>
> Yes. They have said that we will be eliminated as soon as possible. 
> They've been saying this for over 6 years now with 2 failed attempts. 
> We were just bought out by a multinational who has reiterated that the 
> IBM z mainframes will be elimnated and the ;work moved to a software package 
> called Facets.
> They are also said that this cannot occur quickly because we have so 
> many "customized" policies (health insurance) that Facets cannot 
> handle the thousands of variations. So they are waiting until they can 
> refuse renewal, convince the customer to change policies, or the 
> customer dies (I am guessing this later, management would never say 
> that.)
>
>
>
> > Roughly what percentage of your colleagues work from home?
> >
>
> Both programmers, about 50% of the time. 3 sysprogs, almost never 
> because we need to be here to do "operations" duties -- like kicking 
> the accursed
> 3494-B10 when it messes up (a fairly often thing, it being 13 years old).
>
>
>
> >
> > Thanks!
> >
> > Charles
> >
>
> --
> I find television very educational. The minute somebody turns it on, I 
> go into the library and read a good book
> -- Groucho Marx
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

--
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: Attitude of companies toward mainframers working from home?

[Ron Hawkins]

Raphael,

Calendar days. Vacations, public holidays, sick days, etc are all calendar days.

Arrive on Wednesday, and leave the next Wednesday is seven days, which is only 
nine months at a week per month.

Most training, customer briefing, etc also happens in California, so there are 
5-10 days a year at least as well.

If for some unforeseen we blow the 60 days, who is going to pay the employee's 
tax in California? If they were at 50 days and visited the amusement parks in 
LA for 1.5 weeks they've blown it.

And that's the main reason it was mothballed and made ad hoc.

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  On Behalf Of 
Raphaël Jacquot
Sent: Thursday, 22 August 2019 17:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Attitude of companies toward mainframers working from 
home?

Le 22/08/2019 à 08:54, Ron Hawkins a écrit :

> I liked to have our team to train and work face to face occasionally 
> and had regular fly-ins of the team for a week. California killed this 
> off as they want to declare you a tax resident if you spend more than 
> 60 calendar days in the state. Tell that to someone from Nevada.

considering there are 52 weeks in a calendar year, and there are vacations / 
holidays / out of the country periods, you should be fine with once a week

Raphael

--
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: Attitude of companies toward mainframers working from home?

[Ron Hawkins]

Charles,

It may be a bit different for a test environment, but up until I left
Hitachi last year, I was the only MF person that split time between home and
the office.

A year later, the MF itself has moved, and none of the testers works on
site. When I left they were located in both US states and another country. I
am doing some contract work for them n and split my time between Australia
and Philippines.

I liked to have our team to train and work face to face occasionally and had
regular fly-ins of the team for a week. California killed this off as they
want to declare you a tax resident if you spend more than 60 calendar days
in the state. Tell that to someone from Nevada.


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  On Behalf Of
Charles Mills
Sent: Thursday, 22 August 2019 06:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Attitude of companies toward mainframers working from
home?

I am doing a favor for a friend who is writing a blog article on the above
subject, with an emphasis on the effect of the shrinking mainframe personnel
pool. (This is NOT some disguised headhunter pitch. Reply to the list or to
me personally. I will take full responsibility for "sanitizing" your e-mail
address and so forth out of what I forward to my friend.)

Does your employer allow mainframe sysprogs and developers to work from
home?
Any particular restrictions or qualifications?
Have they changed their policies specifically to address the shrinking
mainframe personnel pool?
Roughly what percentage of your colleagues work from home?

Thanks!

Charles 

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

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

Re: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

Yes, you understood my question. Thank you.

I'm surprised by "Repeatability-XYZ encrypts to (perhaps) ABC consistently",
but if it works as you describe, then I think the impact would not be huge.
My observation is that compressing random ciphers is like compressing random
floating-point numbers: keep poking that stick in your eye.

I think this applies equally to things like transaction files, where account
numbers often repeat for many records, which often are sorted or grouped. If
the account number cypher is always the same, then it would get an entry in
the dictionary.

However, from what you explain, prefixes on account numbers, like the first
four of a credit card number, would no longer be the same for groups of
records, so that would mean some loss of repeatability.

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  On Behalf Of
Phil Smith III
Sent: Friday, 9 August 2019 01:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

Ron Hawkins wrote:

>That would be an improvement over a random cypher, but wouldn't the 
>length

>and repeatability of the data patterns after encryption negatively 
>affect

>LZW compression, along with deduplication?

 

Not sure I understand your question, but I'll try.

 

Length-is unchanged

 

Repeatability-XYZ encrypts to (perhaps) ABC consistently, so it's
repeatable. But WXYZ does not encrypt to xABC, so is that what you mean
about repeatability? Yes, that will affect compression to some extent. My
suspicion is that it doesn't make a huge difference: yes, your database of
names with ROB and ROBERT and ROBBIE won't compress the ROB part, but there
will be some magic convergence of strings in the ciphertext that wasn't
there before (less, but some). But my impression is that compression is the
big win on larger fields anyway, like comment fields and the like. And you
probably wouldn't FPE those because they're not structured by definition, so
there's not much win there. We do occasionally have customers who want to
encrypt, say, comment fields because "some of our reps put SSNs or PANs in
those even though they aren't supposed to"; but for those, another AES
encryption mode is a better choice anyway. Of course then you still lose
some compression!

 

Note also that in the case above (comment field with possible SSN/PAN)
another choice is to FPE just the digits. So:

Talked to John; he says his SSN is 123-45-6789, but file has 123-44-6789.

Might encrypt to:

Talked to John; he says his SSN is 761-64-3552, but file has 749-43-7477.

 

If they also had "Will call him back on the 13th", the "13" would also get
encrypted, of course. Kinda weird but it works.

 

Did I answer the question at all, or am I off in far left field?


--
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: CPU time cost of dynamic allocation

[Ron Hawkins]

Charles et al.

Using the TCB time reported in IEF032 to measure and analyse the net CPU
cost of program execution is a bit like a detective investigating a crime
without leaving the office.

As others have said, there is more than one bucket used to measure the CPU
time of a job or step. If you use MXG, then you know that Barry totals all
those buckets into the CPUTM variable. Watch a job sit in privileged
dispatch status while going through space recovery at allocation for an idea
of why TCB time in IEF032 is inadequate.

If you don't have MXG (why) or equivalent software, then I suggest you
enhance IEFACTRT to provide the information or dig around CBT for an up to
date SMF type 30 report program.


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  On Behalf Of
Charles Mills
Sent: Wednesday, 7 August 2019 02:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] CPU time cost of dynamic allocation

I have a batch program that does several SVC 99 allocations. They are fairly
vanilla temporary dataset allocations, or at least that is how I think of
them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a
z196. Is this what others would expect, or does it seem high?

OTOH I have an IEFBR14 batch job on the same machine that allocates 15
temporary datasets in JCL. The entire job lock, stock and barrel uses
(according to IEF032I) .00 CPU seconds.  Can anyone explain why JCL
allocation is apparently much more CPU efficient than SVC 99 allocation?

Charles

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

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

Re: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

FPE - I learn a bit more every day.

That would be an improvement over a random cypher, but wouldn't the length
and repeatability of the data patterns after encryption negatively affect
LZW compression, along with deduplication?

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  On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August 2019 23:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

Ron Hawkins wrote:

>One area where PE encryption, as implemented on z is where it is used

>together with compression. 

 

>The horse must go in front of the cart, meaning compression must happen

>before encryption, because it will be ineffective if you do it after. 

 

Not true with format-preserving data protection. Since the protected data
has the same format as the original, it should compress just as well. With
other forms of encryption, sure.

 

And yes, this is a well-integrated feature of PE encryption!


--
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: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

One area where PE encryption, as implemented on z is where it is used
together with compression. 

The horse must go in front of the cart, meaning compression must happen
before encryption, because it will be ineffective if you do it after. 

It is a simple but important part of the implementation of data at rest, but
with PE extending to data in flight, I think it will have impacts on line
compression effectiveness.

While field-level encryption, given the small window, is less effective and
perhaps more costly than PE, I see PE on z being a less disruptive technique
where compression and encryption are sure to be performed in the right
sequence. 

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  On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August 2019 04:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

ITschak Mugzach wrote:

>PE is much cheaper, CPU wise, than a field level encryption as it use 
>bulk

>encryption. encrypting field by field is much more expensive and affect

>elapse as well.

 

Of course. That's part of the attraction. Yes, field-level is more
expensive. It's also more secure. And with format-preserving data
protection, you often don't need to decrypt to do processing, so it can be
essentially free for many use cases.

 

>I believe that what IBM is doing is to make the mainframe a file server.

>and this is the correct way to use the data. Don't move the entire

>dataset/database outside the mainframe and the ESM domain, but ask for 
>the

>data you need at the record and key levels. much like any other

>file/database server is used.

 

Also a fine idea. But that's not how IBM pushes the encryption, nor how
people use it (yet?).

 

>PE is not for those who have access to the data, from the local domain, 
>but

>to protect the access to data by other terms (shared dasd, backup, etc.).

 

Again, sure, but that isn't how IBM pushes it, nor how people think it will
protect them. That's the real problem: people think it solves problems it
doesn't.

 

.phsiii


--
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: Stay current with what's new in DFSMS

[Ron Hawkins]

Linked in is fine by me. It is about as US-centric as FB.(Only Americans think 
they're the only ones using it  )


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  On Behalf Of 
Glenn Wilcock
Sent: Friday, 26 July 2019 23:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Stay current with what's new in DFSMS

The DFSMS team recently created a LinkedIn Group for z/OS DFSMS: 
https://www.linkedin.com/groups/12238880/  Join the group to stay current on 
the latest enhancements, tips, news, etc.  For example, while z/OS release RFAs 
describe all of the major enhancements in a release, they don't include all of 
the minor RAS items and RFEs.  In my latest post to the group, I list all of 
the DFSMShsm RFEs that are included in V2R4... with more to follow later in the 
year.

--
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: Sharing PDSEs in shared DASD Environment

[Ron Hawkins]

CA MII doc also says that PDSESHARING(extended) is unsupported across 
Sysplexes. 

" CA MII is fully compatible with PDSE resource sharing. CA MII does not 
modify, enhance, or restrict PDS/E processing in any way. PDSE sharing is 
limited to a single sysplex in a pure global GRS environment, and the same 
restrictions apply, even when you are running CA MII. In this regard, CA MII 
neither enhances nor restricts PDSE sharing."

I think you are between a rock and a hard place. Perhaps reverting to 
PDSESHARING(NORMAL) and using DISP=OLD to avoid the sharing error.



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  On Behalf Of 
Kevin Mckenzie
Sent: Thursday, 25 July 2019 02:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Sharing PDSEs in shared DASD Environment

The very short answer is you shouldn't share PDSEs outside of a sysplex.
Under certain circumstances, you can get away with it, but you're just asking 
for problems.

However, I'd note that since you're sharing DASD, and master and user catalogs, 
you don't really have separate development and production environments. There 
are a host of ways one environment can affect the other, but without the 
benefits parallel sysplex (or just sysplex) allows.
You could have a parallel sysplex, or sysplex, environment with separate
JES2 spools, if you wanted to go in that direction.

My official suggestion would be to better isolate the two environments, not try 
to combine them. There are ways to copy PDSEs between separate environments.

---
Kevin McKenzie
z/OS Test Services


IBM Mainframe Discussion List  wrote on
07/24/2019 11:23:16 AM:

> From: S B <01439e1549b6-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 07/24/2019 11:30 AM
> Subject: [EXTERNAL] Sharing PDSEs  in shared DASD Environment Sent by: 
> IBM Mainframe Discussion List 
>
> Thisis a simplified description of our environment (for thesake of 
> this discussion)
>
>
> Weare running  z/OS V2.3 and using CA’ MIM
>
> Wehave two LPARs – LPAR1 Development and LPAR2 Production – there two 
> LPARs areshared DASD but separate JES2 Spools and not SYSPlex.
> We have"PDSESHARING(NORMAL)" in IGDSMS00 and clearly onlyhave SMSPDSE 
> running.
>
> Somedevelopers  have PDSEs for their “.JCL” datasets. We used to 
> receive requests to restore their datasets because their PDSE datasets 
> were “corrupted”. At that time and as part of the problem resolutions 
> (and CA' recommendation) we added the following entries to the MIM 
> (CAMIMGR)and that seemed to solve the issue (we did not get any more 
> calls for “corrupteddatasets”
>
>  SYSZIGW0GDIF=YES,
>
>  SCOPE=SYSTEMS,
>
>  EXEMPT=NO,
>
>  ECMF=NO,
>
>  RPTAFTER=30,
>
>  RPTCYCLE=60
>
> SYSZIGW1GDIF=YES,
>
>  SCOPE=SYSTEMS,
>
>  EXEMPT=NO,
>
>  ECMF=NO,
>
>  RPTAFTER=30,
>
>  RPTCYCLE=60
>
> Lookingback at this issue and in preparation for COBOL Enterprise 
> upgrade from V4.2, accordingto many writeups/red books that I could 
> find, in effect we cannot have PDSEs in ourenvironment – this being 
> one of them
>
>  IBM PDSE DATA SET SHARING Basics
>
> I am assuming there areother shops like us - shared DASD but not 
> SYSPlex – what are our options inusing PDSEs if any?
>
> Theseare our thoughts:
>
> SYSPlexingthese two LPARs takes away the separation of Development and 
> Production during systems upgrades and applications development (e.g., 
> test in development for two weeks before moving to production). 
> Alsosharing the JES2 Spool will be complicated
>
> Separatingthe DASD and master/user catalogs seems to be drastic change 
> technically andculturally
>
> Any feedbackand suggestions will be great
>
> Thanks
>
> Shahnaz
>
>
>
>
>
> --
> 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

Re: DASD nostalgia

[Ron Hawkins]

Will,

OK, you are referring to Seymours alleged drum tearing loose on a navy ship.

Mea Culpa. I read this as you disputing that the Navy installed FirstRand 1 on 
its ships.

There are a references to this model being a dancing behemoth, and that the 
counter-rotating drum resolved this. There are a few, unsubstantiated 
references to failures sending the drum through a wall(s).

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  On Behalf Of 
William Donzelli
Sent: Tuesday, 23 July 2019 11:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD nostalgia

> I'm thinking that just because one article says the story is urban legend, 
> there are more references that talk to the FirstRand I actually being 
> installed on a US Navy ship.

I have no doubts about a Fastrand being on installed on a ship. I have my 
doubts about the spinning drum causing havoc.I can buy that the Fastrand beat 
itself to death with the bearings wearing out very quickly.

> I checked the video twice when they talked about the FirstRand I on one of 
> the navy ships, and did not hear them say it was a legend.

Right around the 1:30 mark.

--
Will

--
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: DASD nostalgia

[Ron Hawkins]

Will,

I'm thinking that just because one article says the story is urban legend, 
there are more references that talk to the FirstRand I actually being installed 
on a US Navy ship.

This 1st person posting says that it was on the USS Hunley, and the poster was 
on board they removed it.
http://www.navydp.com/phpBB3/viewtopic.php?t=115


I checked the video twice when they talked about the FirstRand I on one of the 
navy ships, and did not hear them say it was a legend.

Interesting that Australia used them in the telegram messaging systems.


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  On Behalf Of 
William Donzelli
Sent: Tuesday, 23 July 2019 10:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD nostalgia

> We had a professor who was on the inspection team out of the Navy Yard. Said 
> the drum popped out and churned around like a 4000lb weed-eater for several 
> minutes. I believe Adm. Hopper was on the review board and after a short 
> synopsis. "Just stupid!"

If you could dig up the original inspection report - sure, that would be a 
primary source.

Otherwise, no.

There is just too much "not right" about this myth, especially with a little 
marine engineering knowledge and common sense thrown in.

--
Will

--
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: Test Data Generator

[Ron Hawkins]

Baron,

While it is not the only utility available, I have had great success in the 
past with using SAS to write complex data that IEBDG could not handle.

SAS was especially true where I needed uncompressible records - random floating 
point numbers are great for this.

While I have not used it, I believe you can introduce relational constraints to 
SAS indexed files.

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  On Behalf Of 
Baron Carter
Sent: Monday, 15 July 2019 22:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Test Data Generator

Looking for a test data generator that does not require a connection to a DB 
source or DB target.  Must support RI and is able to generate large volumes of 
data to non DB files such as txt or csv.  Platform can be Windows or Mainframe. 
 Any suggestions would be appreciated.

--
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: MXG error reading z/OS 2.3 data

[Ron Hawkins]

Paul,

The problem is not SAS or MXG.

It means you have an out-of-sequence or missing segment of a spanned record
in the file.


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  On Behalf Of
Beesley, Paul
Sent: Monday, 8 July 2019 21:34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] MXG error reading z/OS 2.3 data

Using MXG 32.04 with SAS 9.1.3, reading a mix of z/OS 2.1 and 2.3 data, I
get this message and RC=4
ERROR:  FOR FILE SMF, INVALID VBS SEGMENT DETECTED. PROCESSING IS CONTINUING
TO THE NEXT RECORD.
Also tried using MXG 36.04 (which required hotfix 37166 for SAS).
Processed only the 2.3 dataset to narrow it down.
Is this anything to worry about?
How can I tell which record it is complaining about?

Thanks

Paul

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are
trading names used by the Atos group. The following trading entities are
registered in England and Wales: Atos IT Services UK Limited (registered
number 01245534), Atos Consulting Limited (registered number 04312380), Atos
Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud
Company Limited (registration number 08011902). The registered office for
each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.
The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely
for the addressee, and may contain confidential or privileged information.
If you receive this e-mail in error, you are not authorised to copy,
disclose, use or retain it. Please notify the sender immediately and delete
this email from your systems. As emails may be intercepted, amended or lost,
they are not secure. Atos therefore can accept no liability for any errors
or their content. Although Atos endeavours to maintain a virus-free network,
we do not warrant that this transmission is virus-free and can accept no
liability for any damages resulting from any virus transmitted. The risks
are deemed to be accepted by everyone who communicates with Atos by email.

--
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: Copying portions of a huge data set

[Ron Hawkins]

I would have thought SAS is your friend.


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  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, 27 June 2019 07:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Copying portions of a huge data set

As I said earlier, I can 'browse forward' in the corrupted file to identify the 
beginning of each 'good' segment (syslog) and the beginning of each 'bad' 
segment (user job). Pointing to some random spot in the file may not tell me 
much about where I am at the moment. 

Ironically the bad segments (user output) all seem to end this way:

ICE052I 0 END OF DFSORT  

I see that as just a coincidence of what the user is doing. I wouldn't try to 
count on that for a general case. It turns out we can prevent this problem in 
the future by turning off access to a RACF resource in JES2 Exit 6. That should 
have been done many years ago. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ward Able, Grant
Sent: Wednesday, June 26, 2019 3:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Copying portions of a huge data set

This may be simplistic, but using REXX & EXECIO, as long as you can identify 
the errant data easily enough, you should be able to get this done fairly 
easily. Maybe not as quick as REPRO, but without much hassle. 




Regards – Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else’s computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden




DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: 25 June 2019 23:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copying portions of a huge data set

ATTENTION! This email originated outside of DTCC; exercise caution.

With 22,807,898 lines in the file, it took a lot of 'inspection' to understand 
why our log print program was getting S0C7. The intrusive user junk always 
starts with 'J E S 2  J O B  L O G'. OTOH every true syslog record seems to 
have an alpha character in position 1 that can be found with "f p'@' 1 word". 
Hence the relevant line numbers can be found easily with alternating ISPF 
browse commands. But very hard to turn into a simple algorithm.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jerry Whitteridge
Sent: Tuesday, June 25, 2019 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Copying portions of a huge data set

Can you only identify the bad data by the line numbers or is there a keyword in 
the log entries that you can include/exclude by ?

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/25/2019 01:07:12 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/25/2019 01:08 PM
> Subject: [EXTERNAL] Copying portions of a huge data set Sent by: IBM 
> Mainframe Discussion List 
>
> We have a file that contains one month's worth of syslog/operlog data.
> Unfortunately a user's job output has infiltrated this file at random 
> points by inappropriate use of MSGCLASS. I want to copy the good data 
> (log stuff) to another file and leave the errant user stuff behind. It 
> seems simple, but I can't seem to tweak a utility like REPRO (with 
> SKIP and COUNT) to do what I want. I've browsed the file and 
> identified by line number where each good data starts/ends and where 
> the bad data starts/ends, like this:
>
> 01 - log
> 932964 - job
> 933148 - log
> 0001539016 - job
> ...
> 0022175585 - job
> 0022176053 - EOD log
>
> The output file should contain just the 'log' data. Suggestions?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com<mailto:robin...@sce.com>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

---

Re: Volume compare utility

[Ron Hawkins]

Jesse,

I may be late to the party, but did you look at using DISKCOMP on from CBT?


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  On Behalf Of 
Jesse 1 Robinson
Sent: Tuesday, 18 June 2019 06:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Volume compare utility

We have been devoted fans and customers of TDMF since long before IBM acquired 
it. I stand in awe of its magical properties. But it is a bit clumsy when 
copying/moving thousands of volumes shared by many LPARs. The method we used 
this time was far more suited to our purpose. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jerry Whitteridge
Sent: Monday, June 17, 2019 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Volume compare utility

"What" should have been "way" !

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/17/2019 08:29:34 AM:

> From: Jerry Whitteridge 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/17/2019 08:30 AM
> Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM Mainframe 
> Discussion List 
>
> In the (distant) past we've been able to get a temporary license from 
> the vendor of the target disk for TDMF as part of the deal - might be 
> one
what
> of you getting a portion of your bridge.
>
> Jerry Whitteridge
> Delivery Manager / Mainframe Architect GTS - Safeway Account
> 602 527 4871 Mobile
> jerry.whitteri...@ibm.com
>
> IBM Services
>
> IBM Mainframe Discussion List  wrote on
> 06/16/2019 01:16:35 PM:
>
> > From: Jesse 1 Robinson 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 06/16/2019 01:16 PM
> > Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM 
> > Mainframe Discussion List 
> >
> > Maybe if I could throw in the Brooklyn Bridge...
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com

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

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

Re: Sample JCL for full volume restore

[Ron Hawkins]

Assuming you used DFSMSdss, you could start here.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/lnxdiv6.htm,


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  On Behalf Of 
Peter
Sent: Monday, 10 June 2019 18:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Sample JCL for full volume restore

Hi

I have backed up an entire volume to a virtual tape device .

I would like to test a full volume restore to the same target volume . Does 
anyone have a working sample JCL so that I can test it ?

Peter

--
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: Moving ECKD to FCP

[Ron Hawkins]

Ken,

You need to reformat the logical volume, and mount it as an FCP device.

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  On Behalf Of
Ken Bloom
Sent: Saturday, 25 May 2019 04:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Moving ECKD to FCP

question.  Need to move ECKD Linux to FCP.  is there a simple way to copy
the volumes or do we need to reinstall as FCP?   Currently running as a VM.
Guest. 

Thanks
Ken

Kenneth A. Bloom
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


--
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: Sort - File split

[Ron Hawkins]

Ron,

I'm having a big dose of dumbness today.

Using your sample data, are you saying you need to generate 100 copies of each 
record, 100 copies of each unique record, or 100 copies of the first record of 
each key?

102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  2 <== changed for 
the example
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1

If 100 copies then these thirteen records would generate 1300 records.
If 100 copies of each unique record then there would be 300 records generated
If 100 copies of each unique key then there would be 200 records generated

I'd have to RTFM to figure out the INPUT you provided, so I am relying on the 
description.


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  On Behalf Of Ron 
Thomas
Sent: Wednesday, 22 May 2019 12:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Sort - File split

Ron, I don't need a single record per P.O, what i need is pull 100 P.O in the 
output file . A  P.O will contain multiple records for e.g if  each PO has 5 
rows then the ouput will be 500. I put something like the below but this is not 
working

SORT FIELDS=COPY
INREC IFTHEN=(WHEN=INIT,OVERLAY=(6003:SEQNUM,3,ZD,RESTART=(01,12)))
OUTFIL FNAMES=OUT01,INCLUDE=(6003,3,ZD,LT,101),BUILD=(1,6000)
OUTFIL FNAMES=LEFTOVER,INCLUDE=(6003,3,ZD,GT,101),BUILD=(1,6000)

Thanks
Ron T

--
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: Sort - File split

[Ron Hawkins]

Ron,

I read your OP that you wanted a single record per PO. As your sample shows 
each PO as a duplicate, SUM FIELDS=NONE would give you just one record per PO, 
and you can use INCLUDE to filter that to any 100 records you want.

Based on my reading of the requirement SUM FIELDS=NONE would work. 

What am I missing?

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  On Behalf Of Ron 
Thomas
Sent: Wednesday, 22 May 2019 09:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Sort - File split

Ron . what i need is copy 100 PO numbers details to a new file . One P.O has 
multiple rows . I don't think  that will work

Thanks
Ron T

--
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: Sort - File split

[Ron Hawkins]

Sort it first with the SUM FIELDS=NONE option.


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  On Behalf Of Ron 
Thomas
Sent: Wednesday, 22 May 2019 08:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Sort - File split

Hi . 

i have FB file with lrecl 5000 and here below is layout. key is first 11 bytes 
PO number

102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
102016|  31859949  ||  1613QTTR|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1
104152|  32412273  ||  2373QTBO|  1

Here i need to pull 100 PO numbers . one PO has multiple rows  & hence  when we 
pull all details of one PO should come in the output file. So how in DFSORT 
this can be done ?

Thanks
Ron T

--
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: how to determine dasd subsystem type from console?

[Ron Hawkins]

Martin,

Agree. It's about time z/OS provided for something other than just IBM 
controllers.

However, it would be somewhat redundant, as it is the RCD and RDC that document 
supported feature information for the OS, and not the emulated model.

If you are running Hitachi's MAR you can get the HTC specific model 
information, and more.

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  On Behalf Of 
Martin Packer
Sent: Monday, 20 May 2019 19:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] how to determine dasd subsystem type from console?


“2107-900” I’ve always felt to be a little non-descriptive. It doesn’t really 
document the HDS model.

Cheers, Martin

Sent from my iPad

> On 20 May 2019, at 09:55, Ron Hawkins  wrote:
>
> Itschak,
>
>
>
> The information is in the NED, which you can display with DS QD,devn,RCD.
>
>
>
> Unfortunately, the model information the emulated IBM device, but the
vendor ID and serial number should get you halfway there.
>
>
>
>
> +4 (4)
>
>
>
> 6 Bytes
>
> Device Type, in EBCDIC.
>
>
> +10 (A)
>
>
>
> 3 Bytes
>
> Device Model, in EBCDIC.
>
>
> +13 (D)
>
>
>
> 3 Bytes
>
> Manufacturer, in EBCDIC.
>
>
> +16 (10)
>
>
>
> 2 Bytes
>
> Manufacturing location, in EBCDIC.
>
>
> +18 (12)
>
>
>
> 12 Bytes
>
> Serial number, in EBCDIC. This field is right justified, padded with
leading zeros in EBCDIC.
>
>
> So “C8E3C3 F7F5” is “HTC 75.”
>
>
>
>
> DS QD,D212,RCD
>
> IEE459I 00.45.35 DEVSERV QDASD 683
>
> UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF
>
> 0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O
>
>  READ CONFIGURATION DATA
>
> DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412
>
> D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
>    
>
>    
>
>    
>
> 81852D001E00 0624045001970002 000CC0129269B6FE 00850800
>
>   1 DEVICE(S) MET THE SELECTION CRITERIA
>
>   0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
>
>
>
> The information is also available on in the Type 74 subtype 1 and 5
records, and the RMFPP Cache Summary report.
>
>
>
>
>
> 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  On 
> Behalf
Of ITschak Mugzach
> Sent: Monday, 20 May 2019 04:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] how to determine dasd subsystem type from console?
>
>
>
> Is there a command to display the storage subsystem vendor & model?
>
>
>
> ITschak
>
>
>
> --
>
> ITschak Mugzach
>
> *|** IronSphere Platform* *|* *Information Security Contiguous 
> Monitoring
for Legacy **|  *
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send
email to  <mailto:lists...@listserv.ua.edu> lists...@listserv.ua.edu with the 
message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,  send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

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

Re: how to determine dasd subsystem type from console?

[Ron Hawkins]

Itschak,

 

The information is in the NED, which you can display with DS QD,devn,RCD.

 

Unfortunately, the model information the emulated IBM device, but the vendor ID 
and serial number should get you halfway there.

 


+4 (4)

 

6 Bytes

Device Type, in EBCDIC. 


+10 (A)

 

3 Bytes

Device Model, in EBCDIC. 


+13 (D)

 

3 Bytes

Manufacturer, in EBCDIC. 


+16 (10)

 

2 Bytes

Manufacturing location, in EBCDIC.


+18 (12)

 

12 Bytes

Serial number, in EBCDIC. This field is right justified, padded with leading 
zeros in EBCDIC. 


So “C8E3C3 F7F5” is “HTC 75.”

 


DS QD,D212,RCD   

IEE459I 00.45.35 DEVSERV QDASD 683   

 UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF

0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O

  READ CONFIGURATION DATA

DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412  

D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

     

     

     

81852D001E00 0624045001970002 000CC0129269B6FE 00850800  

  1 DEVICE(S) MET THE SELECTION CRITERIA 

  0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING  

 

The information is also available on in the Type 74 subtype 1 and 5 records, 
and the RMFPP Cache Summary report.

 

 

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  On Behalf Of 
ITschak Mugzach
Sent: Monday, 20 May 2019 04:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] how to determine dasd subsystem type from console?

 

Is there a command to display the storage subsystem vendor & model?

 

ITschak

 

--

ITschak Mugzach

*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

 

--

For IBM-MAIN subscribe / signoff / archive access instructions, send email to  
<mailto:lists...@listserv.ua.edu> 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: Convert ZFS to Expanded format

[Ron Hawkins]

Repro and rename.

It may just be me, but when I see COPY used, I think DFSMSdss.


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  On Behalf Of
Seymour J Metz
Sent: Monday, 20 May 2019 03:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Convert ZFS to Expanded format

Copy and rename.


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


From: IBM Mainframe Discussion List  on behalf of
Gadi Ben-Avi 
Sent: Sunday, May 19, 2019 4:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Convert ZFS to Expanded format

Hi,
Is there a way to convert a ZFS, or any other VSAM file, to expanded format?
We are running z/OS v2.3.

Thanks

Gadi


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

Re: [External] Re: Ancient DASD connectivity

[Ron Hawkins]

Radoslaw,

And who manufactured and shipped the RVA before it was called an RVA? 

I was working with an ICEBERG before IBM and STK had even thought about inking 
a deal. Iceberg 1994. RVA 1996.

I'm pretty sure the EMC Symmetrix 5500 supported LCU before the RVA rebadging 
happened. I'm not sure about the EMC 4800.

I'm not strong on IOCP and such like, but wasn't it the LCU support for the 
3880 that allowed the RAID vendors to provide LCU that looked like more than 
one box? Something tells me that this was why you could cross-connect halves of 
a 3880 controller to different strings.

Prepared to be corrected.


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  On Behalf Of R.S.
Sent: Monday, 20 May 2019 05:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [External] Re: Ancient DASD connectivity

W dniu 2019-05-17 o 14:47, Ron Hawkins pisze:
> Rex,
>
> I cannot find Alan's quoted passage, but I think it is a stretch to say " 
> With the arrival of 2105s, the CU was inside the same cabinet as the drives 
> and Logical CUs (LCUs) were born."
>
> I'm fairly certain that EMC, STK, and HDS delivering this well before IBM 
> could get the E10 and F20 out of the door.
>
> I think it was more like last to market in IBM's case.

Yes, you are right, with one exception: also IBM delivered LCUs before 2105.
Example: RVA (the larger one) had up to 1024 devices. Yes, RVA was STK under 
the cover, but delivered by IBM.
Of course 3990 CU definition allow LCUs.
However 2105 (Shark) was first disk system supporting PAVs.

BTW: I liked HDS 7700C/E aka Comparex Tetragon 2000/2100 boxes. With one
drwaback: number of logical paths. The number was small, 16 per channel. 
So, 4 CUs and 5 LPARs and you have interesting problems with not clue form the 
system. I spent 2 days trying to IPL system from fifth LPAR...

Regards
--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

--
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: [External] Re: Ancient DASD connectivity

[Ron Hawkins]

Rex,

I cannot find Alan's quoted passage, but I think it is a stretch to say " With 
the arrival of 2105s, the CU was inside the same cabinet as the drives and 
Logical CUs (LCUs) were born."

I'm fairly certain that EMC, STK, and HDS delivering this well before IBM could 
get the E10 and F20 out of the door.

I think it was more like last to market in IBM's case.

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  On Behalf Of 
Pommier, Rex
Sent: Thursday, 16 May 2019 05:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [External] Re: Ancient DASD connectivity


It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  


We don't hear much about them, but where did the 9340 subsystem fit in the 
timeline between 3990 and 2105? or the RAMAC2?  Both those devices had the 
controller built in the same frame as the disk spindles.  How about the RVA?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Alan Altmark
Sent: Wednesday, May 15, 2019 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Ancient DASD connectivity

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk 
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2 
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus)? I guess it is "cable1" connecting 
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet 
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)   

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  

We still have switches, of course, but they're no longer pull-turn-push.  :-) 

Alan Altmark
IBM Systems Lab Services

--
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 confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
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: spool volume migration

[Ron Hawkins]

NB if the underlying volumes are thin provisioned, then the unused space is not 
using any capacity.

Worth considering if it makes your migration simpler.

Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m: +61 400029610 | h: +61 387399252 | f: +1 4087912585 | email: 
ron.hawk...@ipsicsopt.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
VinothM
Sent: Wednesday, 13 March 2019 22:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] spool volume migration

Hi All,

i am planning to migrate the spool volumes using $MSPL command and i have 
already completed spool migration on other plexes.

But here the scenario is different, we have 6 Mod-54 volumes and all the 
volumes are not fully allocated and only 50% allocated, so i am planning to 
migrate and make it to 3 MOD-54 volumes with full cylinders allocated.

Volume . :  SPJES1
Command ===>
 
   
Unit . . :  3390
   
   
 Volume Data VTOC Data  Free Space   TracksCyls
 Tracks . :  982,800Tracks  . :14Size  
. . :491,400 32,760
 %Used  . :   50%Used . . : 1
Largest . :491,400 32,760
 Trks/Cyls:   15Free DSCBS:   696Free   

Extents . :   1 
   

All the volumes are active and used and only 20% used on an average.

Below is command to migrate with MAX space

$MSPL(spool1),target=spool2,space=max

Please suggest me that whether this command will make the target spool volume 
to get 100% allocated and migrated successfully.

Thanks,
Vinoth M

--
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: Disk space allocation question [EXTERNAL]

[Ron Hawkins]

If the DSORG supports multivolume, then add UNIT=(,5) to everything that opens 
the file for output.

That does not mean the IEFBR14 that allocates it; you want the program that 
writes to it.

You can do this with the DATACLAS as well, with or without using SCR, but with 
a large number of datasets you need to watch the TIOT.

Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m: +61 400029610 | h: +61 387399252 | f: +1 4087912585 | email: 
ron.hawk...@ipsicsopt.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joel C. Ewing
Sent: Friday, 8 March 2019 02:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Disk space allocation question [EXTERNAL]

On 3/6/19 10:32 AM, Paul Gilmartin wrote:
> On Wed, 6 Mar 2019 08:36:23 +, Sean Gleann wrote:
>> Up until reading the doc regarding ALLOCxx, I was unaware that 
>> "...Primary space may be acquired in up to 5 extents" and that was 
>> the root cause of the problem report that I was given. That doc and 
>> the further testing I've done has allowed me to understand the 
>> numbers seen in the resulting ISPF 'I' command output, and to 
>> communicate that information to the person who reported the 'problem' (I 
>> requested 9000 tracks! Why did I get only 7200?
>> Why did my job go to a B37 after that??)
>>  
> I have routinely done Info on one data set then changed the DSN and 
> Allocated, intending to create one very similar.  I have been dismayed 
> when space is different from what I requested on the original data set.
>
> I consider this a bug.
>
> -- gil
>
> ...
>
Backward compatibility will always leave specifying allocation the old ways in 
units of tracks or cylinders problematic.  If you actually care whether you get 
a specific amount of space, you need to be using newer SMS allocation 
techniques, specifying space using AVGREC and record size, using 
System-Determined Blocksize, specifying (in JCL or via SMS
definitions) multi-volumes, and using extended datasets (which greatly 
increases allowed extents per volume and allows secondary allocations to also 
have multiple physical extents).  It also helps with volume fragmentation 
issues if your SMS rules don't  attempt to allocate huge datasets in the same 
SMS storage pools as smaller datasets.

Yes the old allocation rules are a mess and in retrospect perhaps a bad design 
choice, but since IBM is supplying other ways to solve the allocation problem 
and reduce allocation dependency on physical DASD architecture, don't expect 
the old rules to change.   Another major exposure the old allocation rules 
always had:  While a 16 extent limit per volume implied there was always a 
possibility of adding 11 to 15 secondary extents, If DASD space was getting 
scarce and the primary allocation proved insufficient, there was never any 
guarantee of space for ANY secondary allocations being available for later 
allocation when the primary space limit was exceeded.

Just dynamically adding DASD space from anywhere to files as needed as long as 
some job limit, step limit, or total storage limit wasn't exceeded would 
obviously be a much nicer solution today from a user standpoint (and has been 
used on other mainframe operating systems); but when the original DASD 
allocation schemes were created for OS/360, allowing explicit control to 
restrict the number of extents and encourage allocation of contiguous tracks 
and contiguous cylinders was considered essential for maximizing DASD 
performance.

Joel C Ewing

--
Joel C. Ewing

--
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: Wells Fargo? Well f*&%#d at the moment: Data centre up in smoke, bank website, app down . The Register

[Ron Hawkins]

There is a reasonably large bank I have worked with in the past that fails
over to the DR site and runs production for an extended period (days -
perhaps it was two weeks).

I like this approach as it tests infrastructure, communications, and
resources in a way that a simple DR Test with no failback will never
achieve.

I'm reminded of something I heard once along the lines of "We back up to
restore, not to just have a copy."

Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61
387399252 | email: ron.hawk...@ipsicsopt.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Saturday, 9 February 2019 12:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Wells Fargo? Well f*&%#d at the moment: Data center
up in smoke, bank website, app down . The Register

I am wondering if WF can even get the Halon system recharged and how many
millions it will cost 

Sent from my iPhone

Sorry for the finger checks

On Feb 8, 2019, at 19:08, Savor, Thomas (Alpharetta)
 wrote:

>> We've been doing DR mirroring for 20 years. It gets tested often. We've
moved production twice to another >data center using our procedures. What
we've never done is run production in another location >temporarily.
'Temporary' means move it, run it until at least one transaction is
committed, then move it >*all* back. That is hugely complex and costly. 
> 
>> A lot of management fantasizes about a big A-B switch that we throw one
way or the other. So wrong.
> 
> About 5-6 years ago, I was working as a vendor (Daily Support) for Credit
Card Software for Halifax/Bank of Scotland.  I believe the first time I was
given a "heads up" was when we were supporting 12 Million Cardholders.  The
"Heads up" was that on Friday evening at 6pm Main site was going to shut
down and the whole weekend PRODUCTION was going to run on DR site, then 6am
Monday Morning, Main site is to come back up and continue as if nothing
happened !!!  I literally peed  in my pants !!!  Probably everyone in
Atlanta could hear me...NO !!!  Thinking of all the network signons
with Visa and Mastercard...all the credit card Authorizations...there was
absolutely zero chance of this working without issues.
> 
> Well, came in Monday morning after receiving no calls over the week-end
everything was fine.  We ran the Batch Monday night...and that would be
pulling in transactions from over the week-end from DR site.  
> NO ISSUES !!!   Everything was fine.
> 
> Whoever did this, from a Systems perspectiveI tip my hat.  I've never
seen someone do this with Production, but it worked fine...so what do I
know.  Never seen anyone else do this in my 42 years of Mainframing either.
> 
> Unfortunately, Halifax/Bank of Scotland is no longer with us.  They were
absorbed by Lloyds Banking Group. 
> 
> 
> Thanks,
> Tom Savor
> 
> --
> 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

Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Ron Hawkins]

Give that man a cigar!!!

Ron Hawkins
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61 
387399252 | email: ron.hawk...@ipsicsopt.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Friday, 15 February 2019 18:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Wells Fargo? Well f*&%#d at the moment: Data center up 
in smoke, bank website, app down . The Register

It might not be possible in a real (total) disaster to reverse the replication.

However, the DR procedures can also be used in different situations. 
The simplest is a partial disaster or other problem, like a problem in the CPU 
room, without problems in the DISK room. 
Or we executed the procedure when a potential dangerous action was to be 
carries out on the powersupply in one of the buidlings. 
In both situatoins you execute the DR procedure with the clear intent to return 
soon to normal operation. In these cases you will like to reverse replication, 
to keep both mirrors intact.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: 14 February, 2019 17:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up in 
> smoke, bank website, app down . The Register
> 
> On Thu, 14 Feb 2019 07:27:36 +, Vernooij, Kees (ITOP NM) - KLM
> wrote:
> 
> >Just reverse the replication when starting up the DR site.
> 
> That isn't necessarily a real DR test. In a real disaster, you may not 
> be able to replicate the data back to the primary site for a 
> considerable period of time.
> 
> >And reverse replication again after returning to the normal site.
> 
> That part should be easier.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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...@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: OT: Rap music (was Re: opinion: multi-platform program design)

[Ron hawkins]

You're quoting the English version. I am quoting the translation from the 
original German.

Liberally from Google:
Du hast mich gefragt, und ich hab nichts gesagt!
You asked me and I did not say anything! 

And from human:
You have asked me and I have said nothing.


There are several differences between the English and German versions, but your 
version below seems to be a mix of the translation, and the English version. 
For example, the English version uses "hate" instead of "have" (hasst instead 
of hast).

I don't speak German, but I love the song and remembered some of the 
translation.

Ron


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Savor, Thomas (Alpharetta)
Sent: Sunday, June 10, 2018 10:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform program 
design)

Weird, here is the English translation I have:
You
You have
You have me
You have me to say
You have me to say
And I did not obey

Will you until death does sever
Be upright to her forever

Never

Will you 'til death be her rider
Her lover too, to stay inside her

Never

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron hawkins
Sent: Saturday, June 09, 2018 3:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: Rap music (was Re: opinion: multi-platform program design)

You have asked me and I have said nothing.

>From Du Hast - Rammstein.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Friday, June 8, 2018 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform program 
design)

On 9/06/2018 7:03 AM, Ron hawkins wrote:
> You have asked me and I have said nothing.

Are they lyrics from a Barnsey song?

>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Thursday, June 7, 2018 9:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform 
> program design)
>
> Rammstein
>
> Thanks,
>
> Tom Savor
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David Crayford
> Sent: Friday, June 08, 2018 12:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OT: Rap music (was Re: opinion: multi-platform program
> design)
>
> On 8/06/2018 3:15 AM, Peter Hunkeler wrote:
>> It's amost Friday, right. At least here in Zurich
>>> Rap music is performed by those that can not sing so others can not think.
>> rap music? Isn't this a contradiction in terms ;-)
>
> What do you listen to, Beethoven? Ramstein? :)
>
>
>> Apologies to all the rappers out there, and the ones who like that 
>> contradiction, ahem.. music. No offense intended.
>>
>>
>> --
>> Peter Hunkeler
>>
>>
>>
>> -
>> - 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
>
> --
> 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


--
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: OT: Rap music (was Re: opinion: multi-platform program design)

[Ron hawkins]

You have asked me and I have said nothing.

>From Du Hast - Rammstein.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Friday, June 8, 2018 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform program 
design)

On 9/06/2018 7:03 AM, Ron hawkins wrote:
> You have asked me and I have said nothing.

Are they lyrics from a Barnsey song?

>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Thursday, June 7, 2018 9:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform 
> program design)
>
> Rammstein
>
> Thanks,
>
> Tom Savor
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David Crayford
> Sent: Friday, June 08, 2018 12:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OT: Rap music (was Re: opinion: multi-platform program 
> design)
>
> On 8/06/2018 3:15 AM, Peter Hunkeler wrote:
>> It's amost Friday, right. At least here in Zurich
>>> Rap music is performed by those that can not sing so others can not think.
>> rap music? Isn't this a contradiction in terms ;-)
>
> What do you listen to, Beethoven? Ramstein? :)
>
>
>> Apologies to all the rappers out there, and the ones who like that 
>> contradiction, ahem.. music. No offense intended.
>>
>>
>> --
>> Peter Hunkeler
>>
>>
>>
>> -
>> - 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
>
> --
> 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

Re: [EXTERNAL] Re: PPRC-XD vs Async PPRC

[Ron hawkins]

Mike,

Excuse my flippant reply earlier. Are you confusing "one frame at a time" with 
ESCON's path ownership and "one IO at a time?"

Both ESCON and Fiber Channel use receiving buffers and ACK responses to control 
the number of in-flight frames, or DIBs in the channel. Both protocols will 
send frames until the frames in flight is equal to the number of buffers that 
the receiving port can handle. The transmitter then waits for an ACK from the 
receiver before sending the next frame.

If there are enough buffers for the link to be full of frames end-to-end across 
the distance, then data streams continuously from port to port. ESCON cannot 
match the throughput of multiple IO on a channel, but that is not an 
architectural limitation caused by the number of ESCON data buffers or Fiber 
Channel buffer credits.

My memory may be hazy on this, but I think a lost frame on ESCON would cause 
retransmission of all the frames in an IO. I need to find Dr Pat's old DIB 
paper.

Ron

-Original Message-
From: ronjhawk...@sbcglobal.net  
Sent: Friday, June 8, 2018 4:17 PM
To: 'IBM Mainframe Discussion List' 
Subject: RE: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC

Mike,

Then how did ESCON use data buffers for flow control?

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Friday, June 8, 2018 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC

ESCON is synchronous, where after sending a buffer, it would wait for 
acknowledgement before sending the next buffer.
FICON is async, where it sends buffer after buffer without waiting.
If it doesn't get an acknowledgement within a certain time frame it would 
resend the lost buffer.
On Fri, Jun 8, 2018 at 5:15 PM Ron hawkins  wrote:
>
> Radslaw,
>
> Have you confused a few things when explaining the difference between 
> synchronous and asynchronous, and ESCON compared to FICON?
>
> Buffer credits are synonymous to DIBs, and a large number of buffer credits 
> provided by Fiber Channel switches allowed the connection to be full of 
> frames end to end over a greater distance than FICON.
>
> The buffer credits, however, did not have anything to do with reducing the 
> RTD spent in the "talking" as you put it. That is purely a function of two 
> round trips required by Fiber channel compared to 9 (I think) required by 
> ESCON. Buffer credits and number of DIBs affected transfer rate, not RTD.
>
> Asynchronous remote copy still requires the provision of adequate buffer 
> credits over distance to maintain line speed, where the number is a function 
> of line speed and distance. Having no distance related impact on response 
> time at any distance is the advantage of asynchronous. Synchronous cannot 
> guarantee zero data loss, so I struggle with coming up with advantages beyond 
> that myth.
>
> Ron
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: Friday, June 8, 2018 3:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC
>
> 1. PPRC-XD and PPRC are very different animals. PPRC-XD is capable to work on 
> any distance, while PPRC is limited by speed of light which is not planned to 
> change.
> 2. ESCON vs FICON did huge difference not only in speed (bit per second), but 
> also in something called credit buffers. In very simple word A talks to B, 
> but A can say many words before B acknowledge it.
> Many words can be "in transit", which makes the protocol quite independend on 
> link length. This is better visible when A is host and B is CU (DASD or tape).
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2018-06-08 o 06:10, Sankaranarayanan, Vignesh pisze:
> > Hi Skip,
> >
> > Looks like you tried PPRC over "long distance" and had a bad exp back then.
> > PPRC-XD should work fine for actual long distance, assuming that the LPAR 
> > itself can get an outage to let the final delta synchronize.
> >
> > – Vignesh
> > Mainframe Infrastructure
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
> > Sent: Thursday 07-Jun-2018 23:52
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: PPRC-XD vs Async PPRC
> >
> > Data consistency was one of two reasons we chose circa 2000 to use XRC 
> > rather than PPRC. I know the technology has changed, and I've been *told* 
> > that PPRC is now capable of maintaining consistency, but I have not seen it 
> > in action. The other reason for XRC BTW was the synchronizing problem: we 
> > could not tol

Re: [EXTERNAL] Re: PPRC-XD vs Async PPRC

[Ron hawkins]

Mike,

Then how did ESCON use data buffers for flow control?

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Friday, June 8, 2018 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC

ESCON is synchronous, where after sending a buffer, it would wait for 
acknowledgement before sending the next buffer.
FICON is async, where it sends buffer after buffer without waiting.
If it doesn't get an acknowledgement within a certain time frame it would 
resend the lost buffer.
On Fri, Jun 8, 2018 at 5:15 PM Ron hawkins  wrote:
>
> Radslaw,
>
> Have you confused a few things when explaining the difference between 
> synchronous and asynchronous, and ESCON compared to FICON?
>
> Buffer credits are synonymous to DIBs, and a large number of buffer credits 
> provided by Fiber Channel switches allowed the connection to be full of 
> frames end to end over a greater distance than FICON.
>
> The buffer credits, however, did not have anything to do with reducing the 
> RTD spent in the "talking" as you put it. That is purely a function of two 
> round trips required by Fiber channel compared to 9 (I think) required by 
> ESCON. Buffer credits and number of DIBs affected transfer rate, not RTD.
>
> Asynchronous remote copy still requires the provision of adequate buffer 
> credits over distance to maintain line speed, where the number is a function 
> of line speed and distance. Having no distance related impact on response 
> time at any distance is the advantage of asynchronous. Synchronous cannot 
> guarantee zero data loss, so I struggle with coming up with advantages beyond 
> that myth.
>
> Ron
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: Friday, June 8, 2018 3:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC
>
> 1. PPRC-XD and PPRC are very different animals. PPRC-XD is capable to work on 
> any distance, while PPRC is limited by speed of light which is not planned to 
> change.
> 2. ESCON vs FICON did huge difference not only in speed (bit per second), but 
> also in something called credit buffers. In very simple word A talks to B, 
> but A can say many words before B acknowledge it.
> Many words can be "in transit", which makes the protocol quite independend on 
> link length. This is better visible when A is host and B is CU (DASD or tape).
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2018-06-08 o 06:10, Sankaranarayanan, Vignesh pisze:
> > Hi Skip,
> >
> > Looks like you tried PPRC over "long distance" and had a bad exp back then.
> > PPRC-XD should work fine for actual long distance, assuming that the LPAR 
> > itself can get an outage to let the final delta synchronize.
> >
> > – Vignesh
> > Mainframe Infrastructure
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
> > Sent: Thursday 07-Jun-2018 23:52
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: PPRC-XD vs Async PPRC
> >
> > Data consistency was one of two reasons we chose circa 2000 to use XRC 
> > rather than PPRC. I know the technology has changed, and I've been *told* 
> > that PPRC is now capable of maintaining consistency, but I have not seen it 
> > in action. The other reason for XRC BTW was the synchronizing problem: we 
> > could not tolerate the I/O delay waiting for remote confirmation from 120 
> > KM via ESCON. In 2000, everything was slower. Now we use DWDM via FICON.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> > Behalf Of R.S.
> > Sent: Thursday, June 07, 2018 4:10 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: PPRC-XD vs Async PPRC
> >
> > W dniu 2018-06-06 o 18:18, Sankaranarayanan, Vignesh pisze:
> >> Hello All,
> >>
> >> Please could you point me to any doc explaining the differences between 
> >> the 2.
> >> Any important, obscure, techdocs or KB page or some such as well.. ?
> > Fundamental difference is data consistency.
> > PPRC-XD is *inconsistent* copy 

Re: OT: Rap music (was Re: opinion: multi-platform program design)

[Ron hawkins]

You have asked me and I have said nothing.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Savor, Thomas (Alpharetta)
Sent: Thursday, June 7, 2018 9:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OT: Rap music (was Re: opinion: multi-platform program 
design)

Rammstein

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Friday, June 08, 2018 12:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: Rap music (was Re: opinion: multi-platform program design)

On 8/06/2018 3:15 AM, Peter Hunkeler wrote:
> It's amost Friday, right. At least here in Zurich
>> Rap music is performed by those that can not sing so others can not think.
>
> rap music? Isn't this a contradiction in terms ;-)


What do you listen to, Beethoven? Ramstein? :)


>
> Apologies to all the rappers out there, and the ones who like that 
> contradiction, ahem.. music. No offense intended.
>
>
> --
> Peter Hunkeler
>
>
>
> --
> 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

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

Re: [EXTERNAL] Re: PPRC-XD vs Async PPRC

[Ron hawkins]

Radslaw,

Have you confused a few things when explaining the difference between 
synchronous and asynchronous, and ESCON compared to FICON?

Buffer credits are synonymous to DIBs, and a large number of buffer credits 
provided by Fiber Channel switches allowed the connection to be full of frames 
end to end over a greater distance than FICON. 

The buffer credits, however, did not have anything to do with reducing the RTD 
spent in the "talking" as you put it. That is purely a function of two round 
trips required by Fiber channel compared to 9 (I think) required by ESCON. 
Buffer credits and number of DIBs affected transfer rate, not RTD.

Asynchronous remote copy still requires the provision of adequate buffer 
credits over distance to maintain line speed, where the number is a function of 
line speed and distance. Having no distance related impact on response time at 
any distance is the advantage of asynchronous. Synchronous cannot guarantee 
zero data loss, so I struggle with coming up with advantages beyond that myth.

Ron


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Friday, June 8, 2018 3:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC

1. PPRC-XD and PPRC are very different animals. PPRC-XD is capable to work on 
any distance, while PPRC is limited by speed of light which is not planned to 
change.
2. ESCON vs FICON did huge difference not only in speed (bit per second), but 
also in something called credit buffers. In very simple word A talks to B, but 
A can say many words before B acknowledge it. 
Many words can be "in transit", which makes the protocol quite independend on 
link length. This is better visible when A is host and B is CU (DASD or tape).

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-06-08 o 06:10, Sankaranarayanan, Vignesh pisze:
> Hi Skip,
>
> Looks like you tried PPRC over "long distance" and had a bad exp back then.
> PPRC-XD should work fine for actual long distance, assuming that the LPAR 
> itself can get an outage to let the final delta synchronize.
>
> – Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Thursday 07-Jun-2018 23:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PPRC-XD vs Async PPRC
>
> Data consistency was one of two reasons we chose circa 2000 to use XRC rather 
> than PPRC. I know the technology has changed, and I've been *told* that PPRC 
> is now capable of maintaining consistency, but I have not seen it in action. 
> The other reason for XRC BTW was the synchronizing problem: we could not 
> tolerate the I/O delay waiting for remote confirmation from 120 KM via ESCON. 
> In 2000, everything was slower. Now we use DWDM via FICON.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of R.S.
> Sent: Thursday, June 07, 2018 4:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: PPRC-XD vs Async PPRC
>
> W dniu 2018-06-06 o 18:18, Sankaranarayanan, Vignesh pisze:
>> Hello All,
>>
>> Please could you point me to any doc explaining the differences between the 
>> 2.
>> Any important, obscure, techdocs or KB page or some such as well.. ?
> Fundamental difference is data consistency.
> PPRC-XD is *inconsistent* copy during most of the time. Inconsistent is 
> unusable. You have to quiesce the production and wait a little until the 
> delta become zero (the copy become consistent).
> Asynchronous copy like XRC, SRDF/A, HARC is different. It is
> *consistent* copy - data on secondary site is usable, but is not current. Of 
> course the time delta is small, but the most important is you don't have 
> later data while earlier data is missing.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> MARKSANDSPENCER.COM
> 
>   Unless otherwise stated above:
> Marks and Spencer plc
> Registered Office:
> Waterside House
> 35 North Wharf Road
> London
> W2 1NW
>
> Registered No. 214436 in England and Wales.
>
>


==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej 

Re: PPRC-XD vs Async PPRC

[Ron hawkins]

Jesse,

Round trip delay time is the same on ESCON and Fiber Channel, but the 
mother-may-I nature of ESCON protocols used to pump-up the droop factor, even 
at 10km. Fiber Channel links changed the viability of synchronous at metro 
distances substantially.

Personally, I think that the myth of zero data loss is not worth the 
performance impact when compared to asynchronous methods. By the time in-flight 
transactions have been rolled back the delta between application recovery times 
with synchronous and asynchronous is often 3/5 of 5/8 of a poofteenth.

Next time you refresh your storage, you may want to look at other asynchronous 
remote copy technology, as XRC is not necessarily the best option anymore (he 
says with a skewed POV).

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, June 7, 2018 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] PPRC-XD vs Async PPRC

Data consistency was one of two reasons we chose circa 2000 to use XRC rather 
than PPRC. I know the technology has changed, and I've been *told* that PPRC is 
now capable of maintaining consistency, but I have not seen it in action. The 
other reason for XRC BTW was the synchronizing problem: we could not tolerate 
the I/O delay waiting for remote confirmation from 120 KM via ESCON. In 2000, 
everything was slower. Now we use DWDM via FICON. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, June 07, 2018 4:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PPRC-XD vs Async PPRC

W dniu 2018-06-06 o 18:18, Sankaranarayanan, Vignesh pisze:
> Hello All,
>
> Please could you point me to any doc explaining the differences between the 2.
> Any important, obscure, techdocs or KB page or some such as well.. ?

Fundamental difference is data consistency.
PPRC-XD is *inconsistent* copy during most of the time. Inconsistent is 
unusable. You have to quiesce the production and wait a little until the delta 
become zero (the copy become consistent).
Asynchronous copy like XRC, SRDF/A, HARC is different. It is
*consistent* copy - data on secondary site is usable, but is not current. Of 
course the time delta is small, but the most important is you don't have later 
data while earlier data is missing.

--
Radoslaw Skorupka
Lodz, Poland


--
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: [EXTERNAL] Re: PPRC-XD vs Async PPRC

[Ron hawkins]

Vignesh,

Only XRC (Global whatever for z/OS) supports migration between vendors, and
go home only works between Hitachi and IBM (or does EMC support XRC now).

Hitachi and EMC have their own FICON based migration utilities, but I am not
sure about IBM.

There are host software options for migration like FDR/PAS and TDMF.

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Sankaranarayanan, Vignesh
Sent: Wednesday, June 6, 2018 9:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC

Thanks Lizette.
How about using them in the context of migrating b/w IBM boxes or IBM to
other vendors, or other vendors to IBM.
What's supported, what's not, etc. ?

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday 07-Jun-2018 01:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PPRC-XD vs Async PPRC

Have you done any internet searches with the phrase


PPRC-XD vs Async PPRC

I found many hits doing that.

Otherwise - could provide more detail of what type of information you are
looking for.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Sankaranarayanan, Vignesh
> Sent: Wednesday, June 06, 2018 9:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PPRC-XD vs Async PPRC
> 
> Hello All,
> 
> Please could you point me to any doc explaining the differences 
> between the 2.
> Any important, obscure, techdocs or KB page or some such as well.. ?
> 
> - Vignesh
> Mainframe Infrastructure
> 
> 
> MARKSANDSPENCER.COM
> 
> Unless otherwise stated above:
> Marks and Spencer plc
> Registered Office:
> Waterside House
> 35 North Wharf Road
> London
> W2 1NW
> 
> Registered No. 214436 in England and Wales.
> 
> Telephone (020) 7935 4422
> Facsimile (020) 7487 2670
> 
> www.marksandspencer.com
> 
> Please note that electronic mail may be monitored.
> 
> This e-mail is confidential. If you received it by mistake, please let 
> us know and then delete it from your system; you should not copy, 
> disclose, or distribute its contents to anyone nor act in reliance on 
> this e-mail, as this is prohibited and may be unlawful.
> 
> --
> 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

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

Re: empty KSDS behavior - why?

[Ron hawkins]

I think it's more like "why do we have to format disk drives."

Even a VTOC needs to know where things start and end.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Saturday, May 26, 2018 2:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] empty KSDS behavior - why?

W dniu 2018-05-26 o 02:47, Paul Gilmartin pisze:
> On Sat, 26 May 2018 00:20:34 +, Frank Swarbrick wrote:
>
>> Pointless issue of the day.  This has bothered me for 20 years.  I figured 
>> its about time I ask, why?  Why does an "empty" KSDS (a KSDS that has never 
>> been "loaded") have what seems to be to be a "special" behavior, one that is 
>> different than a KSDS that had records but no longer has any (all records 
>> have been deleted).
>>
> I suppose it's like formatting a disk: no VTOC is different from an empty 
> VTOC.
> But, yes, Why‽  Why does SMP/E require me to REPRO GIMZPOOL?  Why 
> isn't this embedded in DEFINE CLUSTER?

Yes, it is like disk ad VTOC, but it *shouldn't* be like.
Indeed empty VSAM file is not the same as ever user VSAM file. It complicates 
VSAM processing in application, or to simplfy, many applications do require to 
"seed" the cluster with some dummy record before use.
Can it be changed? Well, can we relieve JCL syntax? ;-)

--
Radoslaw Skorupka
Lodz, Poland




==


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

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

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


--
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: Replaceing IEBGENER

[Ron hawkins]

Something like this with zHPF:

 

// EXEC SAS

//INDD DD ...DCB=BUFNO=255

//OUDD DD ...DCB=BUFNO=255

//SYSIN DD *

data _null_;

infile indd;

file oudd;

input @;

put _infile_;

return;

run;

 

Ron

 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, May 22, 2018 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Replaceing IEBGENER

 

Just curious: which company delivers FASTGENER?

 

I know ICEGENER (IBM) and SYNCGENER (Syncsort), but don't know FASTGENER.

Are ther more "GENERS"?

 

-- 

Radoslaw Skorupka

Lodz, Poland

 

 

 

 

==

 

 

--

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

 

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

 

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



 

--

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: Replacing IEBGENER

[Ron hawkins]

Steve,

I'm pretty sure that IEBGENER's BSAM buffering is NCP=5.

Google tells me that FASTGENR is from SEA. 
https://seasoft.com/products/solutions-for-system-z/dasd-management/fastgenr


Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Tuesday, May 22, 2018 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Replacing IEBGENER

 IDCAMS: REPRO

OK, maybe.  I have only vague memory that it's QSAM operator, where IEBGENER is 
BSAM, and evidently, one buffer.

It's also a fairly trivial exercise to write your own "fast" copy program.
QSAM is pretty fast with optimal bufferage.  However, I assume that the SORT 
programs are going to win with large datasets.

sas

2018-05-22 15:47 GMT-04:00 R.S. :

> Just curious: which company delivers FASTGENER?
>
> I know ICEGENER (IBM) and SYNCGENER (Syncsort), but don't know FASTGENER.
> Are ther more "GENERS"?

--
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: DFSMSdss Release command

[Ron hawkins]

Gadi,

While this does not help to release the space on currently empty data sets,
you can mitigate the problem by having allocation assign a DSORG.

Set up your ACS rules to have datasets with an unspecified DSORG drop
through to a DATACLAS with DSORG=PS and the EOF is updated at allocation,
and release to 0 tracks will work on unopened datasets in the future.

Ron



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Gadi Ben-Avi
Sent: Tuesday, May 1, 2018 3:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] DFSMSdss Release command

Hi,
I am trying to create a job that will use the DFSMSdss RELEASE command to
release unused space from a list of datasets.
Can anyone help me?

Thanks

Gadi

? ?? ?    ?? ??? ??? ??  ? ??? ??
??. ?? ,  ?? ???  ?, ???   ? ?? ???
? ?? ?? ?. ? ?  ?? ?? ?? ??  ?? 
??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ??
? ??? ?/?? ?? ?? ??.

--
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: unexpected tape issue with RETAIN

[Ron hawkins]

Tony,

I remember some behavior like this from the days of real tape.

Was the behavior that RETAIN would rewind but not dismount the tape, even at 
the end of the step, and it was AVR that found the tape if an ensuing step 
needed it.

If there was another mount request before the ensuing step went into allocation 
and no empty drives were available, an unallocated drive with tape on it is 
selected for the allocation. RETAIN does not retain the allocation, just the 
tape.

We got around this problem by using the Mount command to keep the tape mounted 
between jobs and jobs steps.

Ron



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Sunday, May 6, 2018 12:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] unexpected tape issue with RETAIN

Swaps?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: 04 May 2018 17:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: unexpected tape issue with RETAIN

I currently think it has to do with a combination of a faulty tape and a 
mis-configuration in the IODEF, and a testing environment.

Normally, this CPU has no powered-up real tape drives, just a VTL. For some 
testing of new back-up procedures, they wanted me to use a real
3590 so as to not add a bunch of data to the VTL that would then have to be 
replicated.

So, I powered-up and varied on some tape drives. The IODEF thinks they have 
auto-loaders, but they do not. So, I have get a configuration error when I run 
the job on just the first file.

And, since we don't have a lot of spare real 3590 tapes, I have been using the 
same two tapes repeatedly.

I have noticed that the errors only occur on one of the tapes. I think the 
recovery process wants to re-index the tape position but without the 
autoloader, it is failing then the operating system is switching to a new drive.

Tony Thigpen

Lizette Koehler wrote on 05/04/2018 06:12 PM:
> I am not sure if this was covered,
>
> But would the combination of
>
> VOL=REF=*  and DISP=(,PASS) not work at keeping the tape up?
>
> Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Tony Thigpen
>> Sent: Friday, May 04, 2018 1:32 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: unexpected tape issue with RETAIN
>>
>> No go. Unit=Aff is only applicable within the same job step.
>>
>> Tony Thigpen
>>
>> Chris Hoelscher wrote on 05/04/2018 04:05 PM:
>>> Unit=aff=step.ddname  ???
>>>
>>> Chris Hoelscher
>>> Technology Architect, Database Infrastructure Services Technology 
>>> Solution Services Humana Inc.
>>> 123 East Main Street
>>> Louisville, KY 40202
>>> Humana.com
>>> (502) 476-2538 or 407-7266
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List
>>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
>>> Sent: Friday, May 4, 2018 3:35 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: [IBM-MAIN] unexpected tape issue with RETAIN
>>>
>>> I have a 50+ step backup job (using real 3590s) that has steps like:
>>>
>>> //STEP049 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
>>> // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>> //*
>>> //STEP050 EXEC PGM=ADRDSSU
>>> //SYSPRINT DD  SYSOUT=*
>>> //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
>>> //BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
>>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
>>> // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
>>> //SYSINDD  *
>>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>>> /*
>>>
>>> This job always worked on OS/390 2.10, but under z/OS 1.13, 
>>> randomly, when
>> going to a new step, it wants the current tape mounted on a different 3590.
>> Additionally, it does not unload the tape from the first drive.
>>>
>>> Also: If I have only one drive online, it runs to completion. If I 
>>> have two
>> drives, but the other one is busy, it runs to completion.
>>>
>>> Info: This system is using RMM as a tape manager, but the files 
>>> being
>> created on the tape are not defined in any storage group or RMM.
>>>
>>> It is driving me batty. I have to be 'not seeing' something.
>>>
>>>
>>> --
>>> Tony Thigpen
>>>
>
> --
> 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 

Re: OA53355 - USERKEY COMMON MIGRATION SUPPORT

[Ron hawkins]

Carmen,

Indeed, David would have to have a copy of MXG to use the SAS code that you 
shared.

That was my point: you didn't share MXG code.

Ron

-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Carmen Vitullo
Sent: Wednesday, April 25, 2018 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] OA53355 - USERKEY COMMON MIGRATION SUPPORT

I've never had an issue, or Barry has never had an issue with me sharing code, 
David would indeed need to have SAS or WPS and MXG to make my samples work. 



Carmen Vitullo 

- Original Message -

From: "Ron hawkins" <ronjhawk...@sbcglobal.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, April 25, 2018 1:57:15 AM
Subject: Re: OA53355 - USERKEY COMMON MIGRATION SUPPORT 

David, 

If there us an MXG program to run through this, then it will be in the product 
SOURCLIB. 

I don't think anyone can share MXG with you if you don't have it licensed 
already. 

I'm not trying to be a dick about it, and you may have just meant to say SAS. 
It just seemed like an odd request. 

Ron 

-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Jousma, David
Sent: Tuesday, April 24, 2018 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] OA53355 - USERKEY COMMON MIGRATION SUPPORT 

So, has anyone written a SAS/MXG program to read through these SMF30 records 
yet, that they would care to share? Seems to be the easiest method to run 
through the daily data to determine who is using USER Key common? I see the 
slip noted in the APAR, and I could go that route, but still have to look 
through GTF data it seems. 

I know I have one long running home-grown system task for sure using it, but 
what I do not know if there are any short lived usage. We are already working 
on retiring the home-grown system task. 

SA38-0667-XX z/OS MVS System Management Facilities (SMF) Add the following new 
SMF Type 30 record fields in the Storage and Paging Section: 
Offsets Name Length Format... 
178 B2 SMF30_RAXFLAGS 1 binary... 
Description
Bit Meaning
0 When SMF30_USERKEYCOMMONAUDITENABLED is on, auditing of user key common 
storage usage attempts enabled for this step/job. 
SMF30_USERKEYCSAUSAGE, SMF30_USERKEYCADSUSAGE and SMF30_USERKEYCHANGKEYUSAGE 
are only applicable when this flag is on. 
1 When SMF30_USERKEYCSAUSAGE is on, attempts were made to obtain user key CSA 
storage for this step/job. 
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on. 
Once this bit is set on for an interval record, this bit will also be set on 
for all subsequent interval records for this step. 
Once this bit is set on for a job interval or step-end record, this bit will 
also be set on for step-total and job-end records. 
2 When SMF30_USERKEYCADSUSAGE is on, attempts were made to create a user key 
CADS for this step/job. 
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on. 
Once this bit is set on for an interval record, this bit will also be set on 
for all subsequent interval records for this step. 
Once this bit is set on for a job interval or step-end record, this bit will 
also be set on for step-total and job-end records. 
3 When SMF30_USERKEYCHANGKEYUSAGE is on, attempts were made to change the key 
of common ESQA storage to a user key (via CHANGKEY) for this step/job. 
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on. 
Once this bit is set on for an interval record, this bit will also be set on 
for all subsequent interval records for this step. 
Once this bit is set on for a job interval or step-end record, this bit will 
also be set on for step-total and job-end records. 



_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f
616.653.2717 

This e-mail transmission contains information that is confidential and may be 
privileged. 
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated. 




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

Re: OA53355 - USERKEY COMMON MIGRATION SUPPORT

[Ron hawkins]

David,

If there us an MXG program to run through this, then it will be in the
product SOURCLIB.

I don't think anyone can share MXG with you if you don't have it licensed
already.

I'm not trying to be a dick about it, and you may have just meant to say
SAS. It just seemed like an odd request.

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Jousma, David
Sent: Tuesday, April 24, 2018 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] OA53355 - USERKEY COMMON MIGRATION SUPPORT

So, has anyone written a SAS/MXG program to read through these SMF30 records
yet, that they would care to share?   Seems to be the easiest method to run
through the daily data to determine who is using USER Key common?   I see
the slip noted in the APAR, and I could go that route, but still have to
look through GTF data it seems.

I know I have one long running home-grown system task for sure using it, but
what I do not know if there are any short lived usage.   We are already
working on retiring the home-grown system task.

SA38-0667-XX  z/OS MVS System Management Facilities (SMF)
  Add the following new SMF Type 30 record fields in the
  Storage and Paging Section:
  Offsets  NameLength  Format...
  178  B2  SMF30_RAXFLAGS  1   binary...
  Description
  Bit   Meaning
  0 When SMF30_USERKEYCOMMONAUDITENABLED is on,
auditing of user key common storage usage attempts
enabled for this step/job.
SMF30_USERKEYCSAUSAGE, SMF30_USERKEYCADSUSAGE and
SMF30_USERKEYCHANGKEYUSAGE are only applicable when
this flag is on.
  1 When SMF30_USERKEYCSAUSAGE is on, attempts were made
to obtain user key CSA storage for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
and job-end records.
  2 When SMF30_USERKEYCADSUSAGE is on, attempts were made
to create a user key CADS for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
and job-end records.
  3 When SMF30_USERKEYCHANGKEYUSAGE is on, attempts were
made to change the key of common ESQA storage to a user
key (via CHANGKEY) for this step/job.
This bit is only valid when
SMF30_USERKEYCOMMONAUDITENABLED is on.
Once this bit is set on for an interval record, this
bit will also be set on for all subsequent interval
records for this step.
Once this bit is set on for a job interval or step-end
record, this bit will also be set on for step-total
   and job-end records.



_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
616.653.2717

This e-mail transmission contains information that is confidential and may
be privileged.
It is intended only for the addressee(s) named above. If you receive this
e-mail in error, please do not read, copy or disseminate it in any manner.
If you are not the intended recipient, any disclosure, copying, distribution
or use of the contents of this information is prohibited. Please reply to
the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




--
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: DFSMSdss dump fix after binary transfer

[Ron hawkins]

If you change it to RECFM=U first, and restore the DCB attributes after restore.

Works with SMF data, so you aren't stripping the length descriptors.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Monday, April 23, 2018 10:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DFSMSdss dump fix after binary transfer

That sequence won't work, when you upload it the the PC the blocks will be 
messed up.  DFDSS (and FDR) both use special blocking that gets broken if you 
don't handle it correctly.  

If you need to go to the PC, then you should terse it or use AWStape as 
previously offered.  If you can go directly to z/OS either under hercules or 
z/pdt from the mainframe z/OS, then you can use the TYPE and MODE commands I 
offered.  

Those are the only ways that I am sure will work, there are likely others, but 
regular FTP even in binary mode won't suffice if the PC (windows or linux or 
chrome) is the recipient.  

You can find a good discussion of this "problem" on the Hercules forum, and I 
think there are some other odd ideas that may or may not work, but it will also 
explain exactly why plain old FTP won't work if you are going to the PC for 
intermediate storage.

Brian

On Mon, 23 Apr 2018 16:58:32 -0500, Mike Schwab  wrote:

>ADRDSSU backup to dasd then FTP the backup to PC and restore to Hercules.
>
>On Mon, Apr 23, 2018 at 3:05 PM, John McKown 
> wrote:
>> On Mon, Apr 23, 2018 at 2:45 PM, Brian Westerman < 
>> brian_wester...@syzygyinc.com> wrote:
>>
>>> z/pdt and Hercules both run z/OS on PC's.  That's the platform 
>>> combination I meant.  Getting your volumes to your PC based z/OS is 
>>> what I thought the purpose was for this op.
>>>
>>
>> I would think, in that case, that it would be "better" to dump the 
>> volumes onto an actual tape media (likely virtual) , then use AWSTAPE 
>> to create a "virtual tape" DSN on disk. This could then be binary 
>> ftp'd down to the PC running zPDT and the file "mounted" to z/OS on a 
>> virtual (AWS) tape device.
>>
>>
>>>
>>> Since the op wanted to transmit their Volume to their PC, my 
>>> assumption was that they "probably" wanted to use it there for some 
>>> purpose other than just something to take up space on their hard 
>>> drive :)
>>>
>>
>> I was thinking it was an intermediate node. z/OS -> PC -> z/OS.
>>
>>
>>
>>>
>>> Brian
>>>
>>>
>>
>> --
>> We all have skeletons in our closet.
>> Mine are so old, they have osteoporosis.
>>
>> Maranatha! <><
>> John McKown
>>
>> -
>> - 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

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

[Ron hawkins]

Venkat,

There have been some recommendations to MXG with SAS to do the analysis, and I 
think that is the best way to go.

However, from the framing of your question, I think there would be a large 
learning curve if you were to start doing this from scratch. Not just learning 
SAS (MXG is easy), but what to look for in the analysis itself. For example, 
you probably want to be using the Type 30 interval records, and make sure you 
include STC in the captured records (DFSMShsm may be the culprit.)

I would suggest bringing in a consultant or company to do the analysis and 
recommendations.

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
venkat kulkarni
Sent: Thursday, April 19, 2018 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] SMF record analyze

Hello Group,

we are experiencing performance issue on every month 10th and our MSU usage 
reach to maximum but we are unable to find reason. So, we wanted to analyze our 
batch jobs, if any one of them causing this issue.

But we do not have any tool for performing this activity. So, is it possible 
that we extract only record 30 into different dataset from our monthly smfdump 
and then RMF can give us report with history of batch jobs and CPU used by 
these jobs.


Please help.

Thanks & Regards
Venkat

--
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: ADRDSSU ignored migrated datasets?

[Ron hawkins]

Vignesh,

I think you have bigger problems than this if your scheduled backups don't
run for a week and no one notices.

You can set up DFSMShsm does not delete datasets that do not have a backup.

Ron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Sankaranarayanan, Vignesh
Sent: Monday, April 16, 2018 1:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] ADRDSSU ignored migrated datasets?

Hello All,

Recently discovered that an ADRDSSU DUMP job ignores datasets from the
INCLUDE selection if the source is migrated.
Looked at the documentation to find that there isn't a keyword I can use to
force it to consider MIGRATx datasets too.

Is this ideal, or is there a case for an RFE here?
Think of a case where there's an SMS class that deletes datasets left
untouched for a year or so.
But there's a backup job for a dataset (in that class) that runs daily.
In the case where the job hasn't run for a week or so, the dataset gets
migrated, the backup job just completes without any warning (maybe?) about
the exclusion of migrated datasets.
So one may be led to believe the dataset is being backed up when it is not,
and then after a year, it's totally gone...

Thoughts?

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us
know and then delete it from your system; you should not copy, disclose, or
distribute its contents to anyone nor act in reliance on this e-mail, as
this is prohibited and may be unlawful.

--
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: DASD problem

[Ron hawkins]

Tommy,

The RTD at 30km is quite small, and the benefit of write spoofing will be small.

There is an option to turn on write spoofing with the FCP PPRC links on IBM 
storage, but you should check with them that it is a benefit at small distances 
on your model of storage at all write rates.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tommy Tsui
Sent: Tuesday, February 20, 2018 8:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem

Is there any way to improve the pprc command latency and round trip delay time?
Anything can tune on DASD Hardware or switch side?
Anything can tune on os side? BUFNO,

Rob Schramm <rob.schr...@gmail.com> 於 2018年2月21日 星期三寫道：

> It used to be 20 or 25 buffers to establish the I/o sweet spot.  Maybe 
> with the faster dasd the amount is different.
>
> Rob
>
> On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui <tommyt...@gmail.com> wrote:
>
> > Hi Ron,
> > You are right when I changed BUFNO to 255,  The overall elapsed time 
> > reduce from 12mins to 6 mins, So what can I do now,? Change BUFNO 
> > only ? How about vsam or db2 performance?
> >
> >
> > Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月21日 星期三寫道：
> >
> > > Tommy,
> > >
> > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed 
> > > are independent of one another, but the stepped down speed 
> > > elongate the
> > Remote
> > > IO.
> > >
> > > In simple terms a block that you write from the host to the P-VOL 
> > > takes 0.5ms to transfer on 16Gb FICON, and but then you do the 
> > > synchronous
> > write
> > > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to
> transfer.
> > > This time is in addition to command latency and round-trip delay time.
> As
> > > described below, this impact will be less for long, chained writes
> > because
> > > of the Host/PPRC overlap.
> > >
> > > I'm not sure how you simulate this on your monoplex, but I assume 
> > > you
> set
> > > up a PPRC pair to the remote site. If you are testing with BSAM or 
> > > QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single 
> > > block
> impact.
> > If
> > > you are using zHPF, I think you can vary the BUFNO or NCP to get 
> > > up to
> > 255
> > > chained blocks.
> > >
> > > I'm not aware of anything in GRS that adds to remote IO disconnect
> time.
> > >
> > > Ron
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Tommy Tsui
> > > Sent: Tuesday, February 20, 2018 2:42 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [IBM-MAIN] DASD problem
> > >
> > > Hi Ron,
> > > What happens to if our ficon card is 16gb, and fcp connection is 
> > > 2gb, I try to do the simulation on monoplex  lpar , the result is 
> > > fine, now we
> > are
> > > suspect the GRS or other system parm which will increase the 
> > > disconnect
> > time
> > >
> > > Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月
> > >
> > > 15日 星期四寫道：
> > >
> > > > Tommy,
> > > >
> > > > This should not be a surprise. The name "Synchronous Remote Copy"
> > > > implies the overhead that you are seeing, namely the time for 
> > > > the synchronous write to the remote site.
> > > >
> > > > PPRC will more than double the response time of random writes 
> > > > because they the Host write to cache has the additional time of 
> > > > controller latency, round trip delay, and block transfer before 
> > > > the write is complete. On IBM and HDS (not sure with EMC) the 
> > > > impact is greater
> for
> > > > single blocks, as chained sequential writes have some overlap 
> > > > between the host write, and the synchronous write.
> > > >
> > > > Some things to check:
> > > >
> > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then 
> > > > settings on the storage host ports to cater for 30km B2B credits
> > > > 2) Channel speed step-down - If your FICON channels are 8Gb, and 
> > > > the FCP connections are 2Gb, then PPRC writes will take up to 
> > > > four times longer to transfer. It dep[ends on the block size.
> > > > 3) Unbalan

Re: DASD problem

[Ron hawkins]

Rob,

The sweet spot for Basic Access Methods (BAM) and half track blocking used to 
be 16. It is much larger with zHPF

BSAM and QSAM are limited to a chain length of 240KiB (please correct me if I 
remember incorrectly), so the sweet spot used to be FLOOR(240KiB/blocksize)*2. 
For 27998 it is 8 blocks data transfer, but you double the buffer size to get 
access/IO overlap. For 4KiB blocksize the optimal buffering would have been 120.

VSAM used to be limited to one CYL data transfer, so it did not use anything 
more than the number of CI/CA, assuming allocation used CYL.

zHPF has trashed all the old rules of thumbs as it supports much longer block 
chains, and TCW chaining is more efficient than CCW. Sequential IO with zHPF is 
now a case of just setting everything in the red, meaning bigger is better.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, February 20, 2018 6:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem

It used to be 20 or 25 buffers to establish the I/o sweet spot.  Maybe with the 
faster dasd the amount is different.

Rob

On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui <tommyt...@gmail.com> wrote:

> Hi Ron,
> You are right when I changed BUFNO to 255,  The overall elapsed time 
> reduce from 12mins to 6 mins, So what can I do now,? Change BUFNO only 
> ? How about vsam or db2 performance?
>
>
> Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月21日 星期三寫道：
>
> > Tommy,
> >
> > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed are 
> > independent of one another, but the stepped down speed elongate the
> Remote
> > IO.
> >
> > In simple terms a block that you write from the host to the P-VOL 
> > takes 0.5ms to transfer on 16Gb FICON, and but then you do the 
> > synchronous
> write
> > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to transfer.
> > This time is in addition to command latency and round-trip delay 
> > time. As described below, this impact will be less for long, chained 
> > writes
> because
> > of the Host/PPRC overlap.
> >
> > I'm not sure how you simulate this on your monoplex, but I assume 
> > you set up a PPRC pair to the remote site. If you are testing with 
> > BSAM or QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single 
> > block impact.
> If
> > you are using zHPF, I think you can vary the BUFNO or NCP to get up 
> > to
> 255
> > chained blocks.
> >
> > I'm not aware of anything in GRS that adds to remote IO disconnect time.
> >
> > Ron
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tommy Tsui
> > Sent: Tuesday, February 20, 2018 2:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] DASD problem
> >
> > Hi Ron,
> > What happens to if our ficon card is 16gb, and fcp connection is 
> > 2gb, I try to do the simulation on monoplex  lpar , the result is 
> > fine, now we
> are
> > suspect the GRS or other system parm which will increase the 
> > disconnect
> time
> >
> > Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月
> >
> > 15日 星期四寫道：
> >
> > > Tommy,
> > >
> > > This should not be a surprise. The name "Synchronous Remote Copy"
> > > implies the overhead that you are seeing, namely the time for the 
> > > synchronous write to the remote site.
> > >
> > > PPRC will more than double the response time of random writes 
> > > because they the Host write to cache has the additional time of 
> > > controller latency, round trip delay, and block transfer before 
> > > the write is complete. On IBM and HDS (not sure with EMC) the 
> > > impact is greater for single blocks, as chained sequential writes 
> > > have some overlap between the host write, and the synchronous write.
> > >
> > > Some things to check:
> > >
> > > 1) Buffer Credits on ISLs between the sites. If no ISLs then 
> > > settings on the storage host ports to cater for 30km B2B credits
> > > 2) Channel speed step-down - If your FICON channels are 8Gb, and 
> > > the FCP connections are 2Gb, then PPRC writes will take up to four 
> > > times longer to transfer. It dep[ends on the block size.
> > > 3) Unbalanced ISLs - ISLs do not automatically rebalance after one
> drops.
> > > The more concurrent IO there is on an ISL, the longer the transfer 
> > > time for each PPRC write. There may be one opr more ISL that are 

Re: DASD problem

[Ron hawkins]

Tommy,

That's a really big question. You're talking about a complete batch tuning 
exercise. The increased buffering is an old tuning hack, but with synchronous 
replication, the primary benefit is for sequential writes where you can achieve 
the Host/RIO overlap. It works equally well for the QSAM, BSAM, and VSAM. 

For VSAM though, be sure it is sequential write IO, because with random NSR 
VSAM adding buffers can degrade performance. The best tuning trick I've used 
with replication and VBSAM random writes is to use LSR with deferred writes. 
Deferring writes will stop VSAM from writing the CI every time a record is 
updated, and change the writes to buffer replacement based on LSR. For truly 
random updates there will only be a small benefit, but for updates and inserts 
with good locality or in key order the result can be a huge reduction in 
writes, and therefore the impact of remote IO. You can specify LSR with 
deferred writes in JCL using AMP=('ACCBIAS=DO',' SMBDFR=Y').

DB2 database often writes after the fact, and it is the log performance that is 
important to externalize harden updates and speed up batch. If you are not 
using zHyperwrite, then I suggest you look at implementing that first before 
anything else. zHyperwrite in simple terms is host RAID-1 for the DB2 logs, but 
the storage is aware that the host is writing directly to the P-VOL and S-VOL. 
It means you have to use FICON across the DWDM, stepping down to 2Gb, but at 
30km the RTD is small and you should get the benefit of eliminating the RIO 
from the write path.

If you are using DFSMS compression, you may want to look at turning it off for 
the data sets that you think will benefit from large buffers. DFSMS compression 
limits the IO data length to just one track, increasing the number of write IOs 
and reducing the IO/RIO overlap.

I would suggest that you need to understand the batch critical path and use 
that to identify the longest jobs and job steps to identify the tuning 
opportunities where writes can be sped up or eliminated. You're looking at a 
large batch tuning exercise.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tommy Tsui
Sent: Tuesday, February 20, 2018 4:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem

Hi Ron,
You are right when I changed BUFNO to 255,  The overall elapsed time reduce 
from 12mins to 6 mins, So what can I do now,? Change BUFNO only ? How about 
vsam or db2 performance?


Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月21日 星期三寫道：

> Tommy,
>
> With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed are 
> independent of one another, but the stepped down speed elongate the 
> Remote IO.
>
> In simple terms a block that you write from the host to the P-VOL 
> takes 0.5ms to transfer on 16Gb FICON, and but then you do the 
> synchronous write on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer 
> to transfer.
> This time is in addition to command latency and round-trip delay time. 
> As described below, this impact will be less for long, chained writes 
> because of the Host/PPRC overlap.
>
> I'm not sure how you simulate this on your monoplex, but I assume you 
> set up a PPRC pair to the remote site. If you are testing with BSAM or 
> QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single block 
> impact If you are using zHPF, I think you can vary the BUFNO or NCP to 
> get up to 255 chained blocks.
>
> I'm not aware of anything in GRS that adds to remote IO disconnect time.
>
> Ron
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tommy Tsui
> Sent: Tuesday, February 20, 2018 2:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] DASD problem
>
> Hi Ron,
> What happens to if our ficon card is 16gb, and fcp connection is 2gb, 
> I try to do the simulation on monoplex  lpar , the result is fine, now 
> we are suspect the GRS or other system parm which will increase the 
> disconnect time
>
> Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月
>
> 15日 星期四寫道：
>
> > Tommy,
> >
> > This should not be a surprise. The name "Synchronous Remote Copy"
> > implies the overhead that you are seeing, namely the time for the 
> > synchronous write to the remote site.
> >
> > PPRC will more than double the response time of random writes 
> > because they the Host write to cache has the additional time of 
> > controller latency, round trip delay, and block transfer before the 
> > write is complete. On IBM and HDS (not sure with EMC) the impact is 
> > greater for single blocks, as chained sequential writes have some 
> > overlap between the host write, and the synchronous write.
> >
> 

Re: DASD problem

[Ron hawkins]

Tommy,

With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed are independent 
of one another, but the stepped down speed elongate the Remote IO.

In simple terms a block that you write from the host to the P-VOL takes 0.5ms 
to transfer on 16Gb FICON, and but then you do the synchronous write on 2Gb FCP 
to the S-VOL it will take 4ms, or 8 times longer to transfer. This time is in 
addition to command latency and round-trip delay time. As described below, this 
impact will be less for long, chained writes because of the Host/PPRC overlap.

I'm not sure how you simulate this on your monoplex, but I assume you set up a 
PPRC pair to the remote site. If you are testing with BSAM or QSAM (like 
OLDGENER), then set SYSUT2 BUFNO=1 to see the single block impact. If you are 
using zHPF, I think you can vary the BUFNO or NCP to get up to 255 chained 
blocks.

I'm not aware of anything in GRS that adds to remote IO disconnect time.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tommy Tsui
Sent: Tuesday, February 20, 2018 2:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem

Hi Ron,
What happens to if our ficon card is 16gb, and fcp connection is 2gb, I try to 
do the simulation on monoplex  lpar , the result is fine, now we are suspect 
the GRS or other system parm which will increase the disconnect time

Ron hawkins <ronjhawk...@sbcglobal.net> 於 2018年2月

15日 星期四寫道：

> Tommy,
>
> This should not be a surprise. The name "Synchronous Remote Copy" 
> implies the overhead that you are seeing, namely the time for the 
> synchronous write to the remote site.
>
> PPRC will more than double the response time of random writes because 
> they the Host write to cache has the additional time of controller 
> latency, round trip delay, and block transfer before the write is 
> complete. On IBM and HDS (not sure with EMC) the impact is greater for 
> single blocks, as chained sequential writes have some overlap between 
> the host write, and the synchronous write.
>
> Some things to check:
>
> 1) Buffer Credits on ISLs between the sites. If no ISLs then settings 
> on the storage host ports to cater for 30km B2B credits
> 2) Channel speed step-down - If your FICON channels are 8Gb, and the 
> FCP connections are 2Gb, then PPRC writes will take up to four times 
> longer to transfer. It dep[ends on the block size.
> 3) Unbalanced ISLs - ISLs do not automatically rebalance after one drops.
> The more concurrent IO there is on an ISL, the longer the transfer 
> time for each PPRC write. There may be one opr more ISL that are not 
> being used, while others are overloaded
> 4) Switch board connections not optimal - talk to your switch vendor
> 5) Host adapter ports connections not optimal - talk to your storage 
> vendor
> 6) Sysplex tuning may identify IO that can convert from disk to 
> Sysplex caching. Not my expertise, but I'm sure there are some red books.
>
> There is good information on PPRC activity in the RMF Type 78 records. 
> You may want to do some analysis of these to see how transfer rates 
> and PPRC write response time correlate with your DASD disconnect time.
>
> Final Comment: do you really need synchronous remote copy? If your 
> company requires zero data loss, then you don't get this from 
> synchronous replication alone. You must use the Critical=Yes option 
> which has it's own set of risks and challenges. If you are not using 
> GDPS and Hyperswap for hot failover, then synchronous is not much better than 
> asynchronous.
> Rolling disasters, transaction roll back, and options that turn off 
> in-flight data set recovery can all see synchronous recovery time end 
> up with the same RPO as Asynchronous.
>
> Ron
>
>
>
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tommy Tsui
> Sent: Thursday, February 15, 2018 12:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] DASD problem
>
> Hi,
> The distance is around 30km, do you know any settings on sysplex 
> environment such as GRS and JES2 checkpoint need to aware?
> Direct DASD via San switch to Dr site , 2GBPS interface , we check 
> with vendor, they didn't find any problem on San switch or DASD, I 
> suspect the system settings
>
> Alan(GMAIL)Watthey <a.watt...@gmail.com> 於 2018年2月15日 星期四寫道：
>
> > Tommy,
> >
> > This sounds like the PPRC links might be a bit slow or there are not 
> > enough of them.
> >
> > What do you have?  Direct DASD to DASD or via a single SAN switch or 
> > even cascaded?  What settings (Gbps) are all the interfaces running 
> > at (you can ask the switch for the switch and RMF f

Re: Any way -- DIV map LDS into data space?

[Ron hawkins]

John,

Have you thought about how to signal updates to pages in the LDS to other jobs 
and LPARs?

Hiperbatch is a great way to accomplish what you are trying to do, but there is 
exposure if you share the data set.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, February 20, 2018 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Any way -- DIV map LDS into data space?

Look up HIPERBATCH (been around since MVS/ESA). It is pretty much exactly what 
you are looking for.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, February 20, 2018 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any way -- DIV map LDS into data space?

I know that it is possible to use DIV (Data In Virtual) to "map" an LDS into an 
address space. And then use "windowing services" to move the "window" around 
within the LDS.

What I would really like to do is have an LDS. And, somehow, have an API which 
would take this LDS and create a data space for me which simply "maps" the 
entire LDS into the data space. Basically making the LDS a "private page 
dataset". I would also like to have a way to "harden" all the changed pages in 
the data space into the LDS (e.g. force pageout changed).
And, of course, it would write all the changed pages (and delete the data
space) when I request that the LDS be "closed".

I just don't see a way to do this. Not even in the 2.3 books. But I'm hoping 
that I missing something. And, if you're interested, this idea/desire was 
triggered by the UNIX "mmap()" type functions which map a regular UNIX file as 
a range of memory.

Seems to me that IBM has basically "functionally stabilised" DIV. Like an idea 
that just didn't pan out.

--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
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 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: SMS dataset oddity with COM-Plete

[Ron hawkins]

Binyamin,

Does the Management class have space release YI?

Decades ago I had a problem with SAS (V6 I think) doing an Open/Close/Open
on its datasets that would trigger space release, and then the EXCP would
point to a location beyond the EOF. This did not result in an SOC1, but
rather a x37 and pinned data in the storage.

Altering the space release in the Management class fixed the problem. Just
an "out there" suggestion for you to look at.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Monday, February 19, 2018 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMS dataset oddity with COM-Plete

As it is a S0C1, I would look to a branch to low core and if so, look at the
calling module for some link error.

On Sat, 17 Feb 2018 20:21:59 -0600 Brian Westerman
 wrote:

:>No, the volumes are identical (same raid, same channels, etc.) except that
the one (that results in an s0C1) is in an SMS pool and the other is not.
The data got to the pool because we sent it there via a dfdss batch job to
move all of the development datasets to a "new" 48 volume development pool
instead of just a few development 3390-3's.  

:>The only difference between them via 3.4 seems to be that one has a
storage class and management class (no dataclass) and the other doesn't
(because it's not on an SMS volume.

:>The vendor (SAG) is no help at all, as they feel that since Com-Plete
6.8.1 works fine with it on either volume that we should just migrate to the
new version now.  Unfortunately, that's not a viable option because they
have to upgrade Natural and Adabas first and that project has just started
(that's why the Com-Plete cutover is January of 2019).

:>Strangely enough, we have another customer, at the same level of
Com-Plete, exactly same PTF level and compile dates on the programs, and
they have no problem editing dataset from the SMS volumes.

:>I have compared the sites com-plete (s) and they are not just virtually
identical, they are exactly identical.  

:>One site though (the site that works) is z/OS 1.8 (in the process of
moving to z/OS 2.3), but the other (the one where it fails) is at z/OS 2.2.

:>I have no real doubts that the issue is something within SMS under z/OS
2.2 (or something that changed between 1.8 and 2.2), but the problem is to
locate and neutralize it before the site that is currently converting to 2.3
ends up with the same issue.  They have no plans to upgrade their Software
AG environment (it's slowly disappearing).

--
Binyamin Dissen  http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you
should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially
those from irresponsible companies.

--
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: TSO temp dataset

[Ron hawkins]

Elardus,

Thanks for the correction.

I had read your reply, but the thread at that stage sounded to me like zSECURE 
built the JCL, and then the OP manually submitted it.

I see that was incorrect, and we're just rehashing your original advice.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, February 15, 2018 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] TSO temp dataset

Ron Hawkins wrote:

>We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates 
>before copying to INTRDR.

Correct, but actually, in this specific thread, it is about how the allocation 
is done by zSecure and how to fix it.

zSecure has its own version of Submit running REXX programs to do the 
allocations which I have described earlier in this thread.

The OP has asked on RACF-L how to delete 200 000 ids (yes, one fifth of 1 
million) and now asking space related question on IBM-MAIN.

That is a lot of ids and he got the advice to split that job in parts. Perhaps 
this is why he has trouble submitting his extrememly large jobs.

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

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

Re: TSO temp dataset

[Ron hawkins]

We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates 
before copying to INTRDR.

I think you're talking about the temp data sets in the submitted JCL. Not the 
same thing.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Thursday, February 15, 2018 7:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] TSO temp dataset

Not sure whether I fully understand the problem here, but anyways.
 
You can override the number of extents that can be allocated to your temp 
dataset(s) by specifying the maximum number of volsers to use - in which case 
*each* volume will be allocated up to 16 extents, e.g.
   SPACE=(CYL,(50,50),RLSE),VOL=(,,,60)
will allocate up to 960 (16*60) extents of up to 50 CYLs each on up to
60 DASD volumes (if available), hence with total up to ~ 48,000 CYLs.
So, just edit and fix whatever JCL is submitted by zSECURE to specify something 
like the above SPACE= etc. to avoid your "temp dataset keeps on running out of 
space".
 
HTH CP (retired sysprog)
 


On 15/02/2018 15:05, Nai, Dean wrote:
> I'll look into this...thanks everyone.
>
>
> Dean Nai  
> Senior z/OS Systems Programmer
> Mainframe Technical Support Group 
>
>
>
>
>
>
>
>
> On 2/15/18, 9:54 AM, "IBM Mainframe Discussion List on behalf of Elardus 
> Engelbrecht"  elardus.engelbre...@sita.co.za> wrote:
>
>> Nai, Dean wrote:
>>
>>> The problem is it gets submitted by a RACF product called zSECURE so I have 
>>> no control over it. I just generate the commands it uses and then tell it 
>>> to submit a job.
>> In that case, check in zSecure option SE.0 that 'TSO SUBMIT' is not used.
>>
>> Also check SCKRCLIB(CKRESUB) these line:
>>
>> "SELECT CMD(ALLOC FI(CKRSUBMI) DA('"workdsn"') SPACE(1 1)",
>>
>> Alternatively, ask the zSecure people at this forum:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_deve
>> loperworks_community_forums_html_forum-3Fid-3D-2D-2D-
>> 2D-2D1255-26ps-3D25=DwIFaQ=vYl7KJMDeuM7F-Nqf_hfailBif
>> Pmyspo7hrJGlNN7nU=Jrkg6Kqkg1RuQHbN9OpjcGoj051_POke_QQnGwsdEE8=4Ks
>> cBsAZd4S4EFZOvTbHS3ReZISbdRqbiyFZRC9S3Tc=cr5PL6vbpTc4A74zB-ENCxaD2a
>> d79aSSBXbUWJ-1SAk=
>>
>> HTH!
>>
>> 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
> --
> 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

Re: TSO temp dataset

[Ron hawkins]

I'm guessing the OP is referring to ISPCTLx data sets.

You can preallocate these to larger datasets in your logon PROC.

You may be able to preallocate them with REXX or CLIST before you run
zSECURE command(s). I have not tried this.

Ron


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, February 15, 2018 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] TSO temp dataset

What do you mean by "through TSO"? SUBMIT from the READY prompt? ISPF? "E,
none of the above"?


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


From: IBM Mainframe Discussion List  on behalf of
Nai, Dean 
Sent: Thursday, February 15, 2018 9:01 AM
To: IBM-MAIN@listserv.ua.edu
Subject: TSO temp dataset

When you submit a job through TSO your temp dataset gets created. I'm trying
to submit a big job and my temp dataset keeps on running out of space. Any
way of increasing the size of itthanks


Dean Nai
Senior z/OS Systems Programmer
Mainframe Technical Support Group




>

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

Re: DASD problem

[Ron hawkins]

Tommy,

This should not be a surprise. The name "Synchronous Remote Copy" implies the 
overhead that you are seeing, namely the time for the synchronous write to the 
remote site. 

PPRC will more than double the response time of random writes because they the 
Host write to cache has the additional time of controller latency, round trip 
delay, and block transfer before the write is complete. On IBM and HDS (not 
sure with EMC) the impact is greater for single blocks, as chained sequential 
writes have some overlap between the host write, and the synchronous write.

Some things to check:

1) Buffer Credits on ISLs between the sites. If no ISLs then settings on the 
storage host ports to cater for 30km B2B credits
2) Channel speed step-down - If your FICON channels are 8Gb, and the FCP 
connections are 2Gb, then PPRC writes will take up to four times longer to 
transfer. It dep[ends on the block size.
3) Unbalanced ISLs - ISLs do not automatically rebalance after one drops. The 
more concurrent IO there is on an ISL, the longer the transfer time for each 
PPRC write. There may be one opr more ISL that are not being used, while others 
are overloaded
4) Switch board connections not optimal - talk to your switch vendor
5) Host adapter ports connections not optimal - talk to your storage vendor
6) Sysplex tuning may identify IO that can convert from disk to Sysplex 
caching. Not my expertise, but I'm sure there are some red books.

There is good information on PPRC activity in the RMF Type 78 records. You may 
want to do some analysis of these to see how transfer rates and PPRC write 
response time correlate with your DASD disconnect time.

Final Comment: do you really need synchronous remote copy? If your company 
requires zero data loss, then you don't get this from synchronous replication 
alone. You must use the Critical=Yes option which has it's own set of risks and 
challenges. If you are not using GDPS and Hyperswap for hot failover, then 
synchronous is not much better than asynchronous. Rolling disasters, 
transaction roll back, and options that turn off in-flight data set recovery 
can all see synchronous recovery time end up with the same RPO as Asynchronous. 

Ron






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tommy Tsui
Sent: Thursday, February 15, 2018 12:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem

Hi,
The distance is around 30km, do you know any settings on sysplex environment 
such as GRS and JES2 checkpoint need to aware?
Direct DASD via San switch to Dr site , 2GBPS interface , we check with vendor, 
they didn't find any problem on San switch or DASD, I suspect the system 
settings

Alan(GMAIL)Watthey  於 2018年2月15日 星期四寫道：

> Tommy,
>
> This sounds like the PPRC links might be a bit slow or there are not 
> enough of them.
>
> What do you have?  Direct DASD to DASD or via a single SAN switch or 
> even cascaded?  What settings (Gbps) are all the interfaces running at 
> (you can ask the switch for the switch and RMF for the DASD)?
>
> What type of fibre are they?  LX or SX?  What kind of length are they?
>
> Any queueing?
>
> There are so many variables that can affect the latency.  Are there 
> any of the above that you can improve on?
>
> I can't remember what IBM recommends but 80% sounds a little high to me.
> They are only used for writes (not reads).
>
> Regards,
> Alan Watthey
>
> -Original Message-
> From: Tommy Tsui [mailto:tommyt...@gmail.com]
> Sent: 15 February 2018 12:15 am
> Subject: DASD problem
>
> >
> > Hi all,
>
>
> Our shop found the most job elapse time prolong due to pprc 
> synchronization versus without pprc mode. It's almost 4 times faster 
> if without pprc synchronization. Is there any parameters we need to 
> tune on z/os or disk subsystem side? We found the % disk util in RMF 
> report over 80, Any help will be appreciated. Many thanks
>
> --
> 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

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

Re: AW: Re: AW: Re: Dataclass question

[Ron hawkins]

Radoslaw,

You mean VSAM extent consolidation.

The extent counter does not increment when a new extent abuts the previous one.

Net-net it achieves a similar thing.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, February 7, 2018 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: AW: Re: Dataclass question

W dniu 2018-01-30 o 20:48, Ron hawkins pisze:
> Peter,
>
> Start using PDS-E 
>
> I used to like to have maxextents set to 8. That worked for all but the most 
> pathological of PDSs with many members updated per day. PDS-E ended up 
> resolving that (but Lizette has some horror stories about large PDS-E).
>
> Extent reduction as I recall it does not need adjacent extents. It's was a 
> migrate/recall cycle to ML1 that reallocates the Primary as the size of the 
> current data set. Are you thinking of DEFRAG?

There are two flavours of extent reduction. One - as you described, the dataset 
is migrated/recalled. Of course it cannot be in use during the process.
The second flavours came with z/OS 1.5 is applies to VSAM files. In that case 
extent have to be adjacent otherwise consolidation will not occur.

--
Radoslaw Skorupka
Lodz, Poland




==


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

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

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


--
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: GDG Cleanup

[Ron hawkins]

Emeffers,

 

Below is some JCL I use to clean up data sets that have a repeatable naming 
pattern. It is usually a mass delete of 1000s of data sets.

 

Being a lab, I use the NSCR step because sometimes the volumes have been blown 
away without cleaning up the data sets first. Also good for deleting a years 
worth of SMF data sets.

 

//PERFDEL$ JOB (ACCT#),'STGADM1',CLASS=H,MSGCLASS=X,MSGLEVEL=(1,1),  

// NOTIFY=

//***

//* QUICK DELETE OF FILES USING A MASK   

//***

//DEL  EXEC PGM=IDCAMS,REGION=6M 

//SYSPRINT DD   SYSOUT=* 

//SYSINDD   *

  DELETE RAID800.E*.B*.U0*.C*   MASK PURGE   

/*   

//***

//* QUICK UNCATALOG OF FILES USING A MASK

//***

//DELNSCR  EXEC PGM=IDCAMS,REGION=6M 

//SYSPRINT DD   SYSOUT=* 

//SYSINDD   *

  DELETE RAID800.E*.B*.U0*.C*   MASK PURGE  NSCR 

/*   

 

You can achieve similar results with DFSMSdss dump and delete of data sets to a 
dummy output, using filters. I just find this method cleaner when I have a lot 
of missing data sets.

 

Ron

 

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Mingee
Sent: Monday, February 5, 2018 9:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDG Cleanup

 

I intended to specify this cleanup is for DISK GDG files.  Old unused files can 
be left when an application is retired or a dsn is changed or when a tape gdg 
with NSCR is changed to DISK file.  Also, there is an TMS Utility - TMSOSCAT 
that will fix tapes that have been uncat'd put are not eligible for SCRATCH and 
those that have been TMS SCRATCHED but are still Catalogued.  I think if a new 
disk GDG has not been created in over a year, it is almost certain a new gen 
will not be created today or tomorrow.  I successfully completed this task at 
two different sites.  The only error or problem was one job created a file dsn 
equal to the GDG BASE, but the jcl did not use (+1), so when I deleted the 
GDG's and the BASE GDG this job failed.  Each site had over 100K files deleted 
and 100 to 200 3390-3 disk freed up and these were no longer backed up in the 
weekly backup jobs.  Not a bad savings for those who are interested, have the 
time, and permission.

 

-Original Message-

From: IBM Mainframe Discussion List [  
mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith

Sent: Monday, February 05, 2018 10:52 AM

To:   IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: GDG Cleanup

 

lol, I guess the OP may have accidentally sent this advice to the wrong address.

 

Rocket CR+ would make this easier

 

However, you would in general hope that GDGs are defined to satisfy actual 
requirements, and not pile up garbage indefinitely.

 

sas

 

On Mon, Feb 5, 2018 at 7:13 AM, John McKown < 
 john.archie.mck...@gmail.com>

wrote:

 

> On Sun, Feb 4, 2018 at 11:55 PM, David Mingee <  
> ming...@prodigy.net> wrote:

> 

> > For those who might have the time or inclination, I suggest running 

> > a LISTC for your GDG's and then SORT the output file by LAST ALTER 

> > DATE.  Then consider deleting all of them that are older than one 

> > year old. You may find 1000's of these for various reasons.  Also, 

> > you could run IEHLIST and find old gdg files that were mistakenly 

> > set to NOSCRATCH and then delete them.

> >

> >

> ​Well, just speaking for my shop, one year is way too short. We create 

> annual tapes for end-of-year data. And we often need them going back

> 10 years. Actuarial people love historical data. Some financial people 

> do too.​

> 

> 

> --

> I have a theory that it's impossible to prove anything, but I can't 

> prove it.

> 

> Maranatha! <><

> John McKown

> 

> --

> For IBM-MAIN subscribe / signoff / archive access instructions, send 

> email to   lists...@listserv.ua.edu with the 
> message: INFO IBM-MAIN

> 

 

 

 

--

sas

 

--

For IBM-MAIN subscribe / signoff 

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Dave,

What are you expecting changes to REUSE to change?

You can open a data set with the REUSE attribute as empty, by setting the
HURBA to 0. 

I think that would be the last thing the OP wants to do.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Mingee
Sent: Sunday, February 4, 2018 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

I agree. Just curious if the file needs to be defined as REUSE or could it
be ALTERED to NOREUSE and tested?

-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron hawkins
Sent: Friday, January 26, 2018 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM Performance - CPU reduction

Arun,

I think you are very close to having this running as optimally as you can
unless you start including the COBOL parsing with Strobe and looking for
changes to the program that can improve the access,

Thanks for trying the reduction of BUFND from 240 to 2, and sharing the
increased IO and CPU usage you observed. I still have a gut feeling that
BUFND=240 is excessive, and you are reading Cis into storage that the
program never processes. If that is the case, then there may be the
potential to reduce CPU by reducing the chain length.

I'd like to suggest that you try a binary search or bracket test of sorts to
see if there is an optimal value for BUFND that reduces the CPU time. I'd
suggest starting with one cylinder or BUFND=30 as a starting point for a
binary search. For example,  if CPU is reduced at 30, see if it reduces at
15. If it does reduce, try 8 to see if it reduces further. Alternatively, if
30 increases CPU and IO try BUFND=120, then 60, etc, etc, etc.

Ron

-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron hawkins
Sent: Thursday, January 25, 2018 2:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

Clark, 

it is a 15GB KSDS, with 564,000 Cis, and 32,448,318 records.

It is very optimistic to think that after he verified increased IO when
reading one CI, it will be more than offset LRU buffer hits when there is
bursts of sequential IO walking the buffer pool a cylinder at a time. 

NSR behavior will not let the random hit that you describe occur outside of
one CI in the chain as COBOL only uses one string. The program can read all
the other CI's in, but the program only looks at them in sequential mode. In
skip (random) it only looks at the CI currently pointed to by the string,
and ignores everything else in memory. 

What sort of buffers were you thinking of? 5GB worth?

Ron

-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Wednesday, January 24, 2018 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 24 Jan 2018 09:53:39 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:

>Clark,
>
>It's not that the process is reading a 2nd record in the same CI.
That 
>would result in a buffer hit irrespective of whether it is LSR or
NSR.
>
>The empirical evidence of his test with BUFND=2 reduced from
BUFND=240 
>is that the program reads more than one CI sequentially for each
skip.
>That alone makes the file a poor candidate for LSR.

The original poster also said that under certain circumstances after reading
a record skip sequential on the second file by finding a match, under x
conditions another record was retrieved from the same file.  Depending on
the frequency of this condition occurring and the access pattern LSR might
help for that condition.  Program caching of hits and misses may be more
appropriate depending on circumstance.  I had a case in one shop where
thousand of read not found conditions occurred for about 12 records.  This
was a table file and around 20 years ago so the exact details escape me but
the point is that much depends on the overall processing.

Clark Morris 
>
>Ron
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Clark Morris
>Sent: Wednesday, January 24, 2018 4:50 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 23 Jan 2018 17:35:50 -0800, in bit.listserv.ibm-main 
>ronjhawk...@sbcglobal.net (Ron hawkins) wrote:
>
>>Clark,
>>
>>If you had time to read through this lengthy thread you will find
that 
>>the 2nd file uses skip-sequential access. LSR is usually not an 
>>appropriate strategy for this access pattern.
>
>I realize he was using skip sequential.  My point was that random 
>access looks like it could be a better fit for this file than skip 
>sequential especially 

Re: AW: Re: AW: Re: Dataclass question

[Ron hawkins]

Peter,

Start using PDS-E 

I used to like to have maxextents set to 8. That worked for all but the most 
pathological of PDSs with many members updated per day. PDS-E ended up 
resolving that (but Lizette has some horror stories about large PDS-E).

Extent reduction as I recall it does not need adjacent extents. It's was a 
migrate/recall cycle to ML1 that reallocates the Primary as the size of the 
current data set. Are you thinking of DEFRAG?

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Tuesday, January 30, 2018 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] AW: Re: AW: Re: Dataclass question

>What is your concern with secondary extents on a PDS?


I don't have a problem with secondary extents as such. It is only that I fear 
the 16 extent limit may me reached sooner with space release. Extent reduction 
may help, but only if the device has low "extent" allocation activity. 
Otherwise, chances are lower to get an adjacent extent.


>I don't think my "more appropriate" is an absolute in the same way as 
>"not appropriate for PDSs in any form."



Yeah, my statement was probably too absolute :-) I just don't see a problem 
with highly overallocated space of PDSs. YMMV, though.


--
Peter Hunkeler



--
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: Dataclass question

[Ron hawkins]

Peter,

I'd agree with your directive if you have extent reduction disabled.
Otherwise, I'll stick to my recommendation. 

I don't think my "more appropriate" is an absolute in the same way as "not
appropriate for PDSs in any form."

What is your concern with secondary extents on a PDS?

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, January 29, 2018 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] AW: Re: Dataclass question

>I probably would not have DSORG=PO sharing the same MGMTCLAS with batch
files.


Interesting differentiation. I do not contradict per se, but attributes
should be different for DSORG=PS versus DSORG=PO, and DSORGP=PO-E. 


>I agree COND IMMED or CONDITIONAL is more appropriate for PDS. 
 

No, space release is not appropriate for PDSs in any form. PDSs are still
limited to 16 extents (if memory serves me right), and each new member as
well as each update of existing members will write at the end of the data
set's allocated space. After space was releases, each write will add another
secondary extent.


--
Peter Hunkeler




--
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: VSAM Performance - CPU reduction

[Ron hawkins]

Arun,

I think you are very close to having this running as optimally as you can
unless you start including the COBOL parsing with Strobe and looking for
changes to the program that can improve the access,

Thanks for trying the reduction of BUFND from 240 to 2, and sharing the
increased IO and CPU usage you observed. I still have a gut feeling that
BUFND=240 is excessive, and you are reading Cis into storage that the
program never processes. If that is the case, then there may be the
potential to reduce CPU by reducing the chain length.

I'd like to suggest that you try a binary search or bracket test of sorts to
see if there is an optimal value for BUFND that reduces the CPU time. I'd
suggest starting with one cylinder or BUFND=30 as a starting point for a
binary search. For example,  if CPU is reduced at 30, see if it reduces at
15. If it does reduce, try 8 to see if it reduces further. Alternatively, if
30 increases CPU and IO try BUFND=120, then 60, etc, etc, etc.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ron hawkins
Sent: Thursday, January 25, 2018 2:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

Clark, 

it is a 15GB KSDS, with 564,000 Cis, and 32,448,318 records.

It is very optimistic to think that after he verified increased IO when
reading one CI, it will be more than offset LRU buffer hits when there is
bursts of sequential IO walking the buffer pool a cylinder at a time. 

NSR behavior will not let the random hit that you describe occur outside of
one CI in the chain as COBOL only uses one string. The program can read all
the other CI's in, but the program only looks at them in sequential mode. In
skip (random) it only looks at the CI currently pointed to by the string,
and ignores everything else in memory. 

What sort of buffers were you thinking of? 5GB worth?

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, January 24, 2018 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 24 Jan 2018 09:53:39 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:

>Clark,
>
>It's not that the process is reading a 2nd record in the same CI. That 
>would result in a buffer hit irrespective of whether it is LSR or NSR.
>
>The empirical evidence of his test with BUFND=2 reduced from BUFND=240 
>is that the program reads more than one CI sequentially for each skip.
>That alone makes the file a poor candidate for LSR.

The original poster also said that under certain circumstances after reading
a record skip sequential on the second file by finding a match, under x
conditions another record was retrieved from the same file.  Depending on
the frequency of this condition occurring and the access pattern LSR might
help for that condition.  Program caching of hits and misses may be more
appropriate depending on circumstance.  I had a case in one shop where
thousand of read not found conditions occurred for about 12 records.  This
was a table file and around 20 years ago so the exact details escape me but
the point is that much depends on the overall processing.

Clark Morris 
>
>Ron
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Clark Morris
>Sent: Wednesday, January 24, 2018 4:50 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 23 Jan 2018 17:35:50 -0800, in bit.listserv.ibm-main 
>ronjhawk...@sbcglobal.net (Ron hawkins) wrote:
>
>>Clark,
>>
>>If you had time to read through this lengthy thread you will find that 
>>the 2nd file uses skip-sequential access. LSR is usually not an 
>>appropriate strategy for this access pattern.
>
>I realize he was using skip sequential.  My point was that random 
>access looks like it could be a better fit for this file than skip 
>sequential especially since a second record may have to be read after 
>the first record is found on the second file.
>
>Clark Morris
>>
>>The OP has tried reducing BUFND on the second file, and observed a 
>>reduction in throughput, which verifies the extent to which the 
>>sequential access is taking advantage of chained Cis.
>>
>>Ron
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>On Behalf Of Clark Morris
>>Sent: Tuesday, January 23, 2018 4:57 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>>
>>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main 
>>arun.venkatrat...@cognizant.com (Arun Venkatratnam) 

Re: Dataclass question

[Ron hawkins]

Chris,

I think it is a case of whatever floats your boat.

I probably would not have DSORG=PO sharing the same MGMTCLAS with batch files.

I agree COND IMMED or CONDITIONAL is more appropriate for PDS.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Taylor
Sent: Friday, January 26, 2018 9:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Dataclass question

I tend to be a bit careful when using Yes Immediate to release space. I got 
burned once during a product conversion when we ended up releasing space 
against a VERY large PDS being used by a change management product. Batch 
sequential files are usually fair game but I still prefer coding Conditional 
Immediate so that the data set has room to extend if needed.

Chris

--
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: VSAM Performance - CPU reduction

[Ron hawkins]

Clark, 

it is a 15GB KSDS, with 564,000 Cis, and 32,448,318 records.

It is very optimistic to think that after he verified increased IO when
reading one CI, it will be more than offset LRU buffer hits when there is
bursts of sequential IO walking the buffer pool a cylinder at a time. 

NSR behavior will not let the random hit that you describe occur outside of
one CI in the chain as COBOL only uses one string. The program can read all
the other CI's in, but the program only looks at them in sequential mode. In
skip (random) it only looks at the CI currently pointed to by the string,
and ignores everything else in memory. 

What sort of buffers were you thinking of? 5GB worth?

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, January 24, 2018 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 24 Jan 2018 09:53:39 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:

>Clark,
>
>It's not that the process is reading a 2nd record in the same CI. That 
>would result in a buffer hit irrespective of whether it is LSR or NSR.
>
>The empirical evidence of his test with BUFND=2 reduced from BUFND=240 
>is that the program reads more than one CI sequentially for each skip. 
>That alone makes the file a poor candidate for LSR.

The original poster also said that under certain circumstances after reading
a record skip sequential on the second file by finding a match, under x
conditions another record was retrieved from the same file.  Depending on
the frequency of this condition occurring and the access pattern LSR might
help for that condition.  Program caching of hits and misses may be more
appropriate depending on circumstance.  I had a case in one shop where
thousand of read not found conditions occurred for about 12 records.  This
was a table file and around 20 years ago so the exact details escape me but
the point is that much depends on the overall processing.

Clark Morris 
>
>Ron
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Clark Morris
>Sent: Wednesday, January 24, 2018 4:50 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 23 Jan 2018 17:35:50 -0800, in bit.listserv.ibm-main 
>ronjhawk...@sbcglobal.net (Ron hawkins) wrote:
>
>>Clark,
>>
>>If you had time to read through this lengthy thread you will find that 
>>the 2nd file uses skip-sequential access. LSR is usually not an 
>>appropriate strategy for this access pattern.
>
>I realize he was using skip sequential.  My point was that random 
>access looks like it could be a better fit for this file than skip 
>sequential especially since a second record may have to be read after 
>the first record is found on the second file.
>
>Clark Morris
>>
>>The OP has tried reducing BUFND on the second file, and observed a 
>>reduction in throughput, which verifies the extent to which the 
>>sequential access is taking advantage of chained Cis.
>>
>>Ron
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>On Behalf Of Clark Morris
>>Sent: Tuesday, January 23, 2018 4:57 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>>
>>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main 
>>arun.venkatrat...@cognizant.com (Arun Venkatratnam) wrote:
>>
>>>Hi All,
>>>
>>>We are looking to improve the performance of a COBOL program that 
>>>processes
>>2 VSAM files. The first file is the I/P file and every record read 
>>from the input VSAM file is searched for a matching record in the 
>>other file and a report is written. The program also applies some 
>>business rules while comparing each matching record.
>>>
>>>The I/P file is read sequentially while the other file is read in a 
>>>skip
>>sequential basis. The test files that were used had 32M records each 
>>while production files have 110M records each.
>>
>>I assume using random access for the second file was tried with 
>>adequate buffering for index and data. BLSR or the more current means 
>>of doing random access buffering should have been used.  It may also 
>>help to save any randomly read record that were read based on 
>>information in records from the second file based on the match with a 
>>record from the first file.  Knowing access patterns can help in
>determining the best solution.
>>
>>Clark Morris
>>>
>&

Re: Dataclass question

[Ron hawkins]

Yes there is.

YI
Yes Immediate. Release unused space at Space Management cycle time, when close 
is issued for a data set that was open for output, and on subsequent volumes.

CI
Conditional Immediate. If secondary space has been allocated, release unused 
space at Space Management cycle time, when close is issued for a data set that 
was open for output, and on subsequent volumes.

I have always assumed that sites used Yes Immediate for most management classes.

Ron


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gadi Ben-Avi
Sent: Wednesday, January 24, 2018 11:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Dataclass question

Isn't there a way to have it done at the end of the step, like when you use JCL?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shorkend
Sent: Thursday, January 25, 2018 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataclass question

Gadi
You specify the release on the management class and not on the data class.
Set the 'PARTIAL RELEASE' field to 'YES'.
Of course you will need a product like DFHSM to actually do the release during 
its space management cycle.


HTH

Mike



On Thu, 25 Jan 2018 at 08:28 Gadi Ben-Avi  wrote:

> Hi,
> I was asked to define a dataclass that would create a dataset with
> SPACE=(CYL,(200,200),RLSE)
>
> I defined:
> Avgrec  . . . . . . K
> Avg Value . . . . . 850
> Primary . . . . . . 200
> Secondary . . . . . 200
>
> Which defined a dataset with 3118 tracks primary space, which is close 
> enough.
> How do I defined the dataclas to release the unused space.
>
> Thanks
>
> Gadi
>
> ?? , ? ?  ??? ?? ??"? ?/?? ??  ?? ?/?? 
> ? ??? ( : "?") ??? ?? ???, ?? ,  ?? ???
>  ?, ???   ? ?? ??? ? ?? ?? ?, ? ??
>  ? ?? ??? ?? ??? ? ?. ?  ? (? 
> ) ?? ??   ???, ??? ? ? ?? ??? 
> ? ?,  ??  ?? ? ? ?? ?? ?.
> Please note that in accordance with Malam and/or its subsidiaries 
> (hereinafter :
> "Malam") regulations and signatory rights, no offer, agreement, 
> concession or representation is binding on the Malam, unless 
> accompanied by a duly signed separate document (or a scanned version 
> thereof), affixed with the Malam seal.
>
> --
> 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 לתשומת ליבך, בהתאם 
לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : "החברה") 
וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד 
וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף 
חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני 
זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה 
עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its 
subsidiaries (hereinafter : "Malam") regulations and signatory rights, no 
offer, agreement, concession or representation is binding on the Malam, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the Malam seal.

--
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: CKD details

[Ron hawkins]

Tony,

I am way in over my head here, and I am sure I will use the wrong terminology.

As I remember it RPS was implemented by passing seek and set sector to the DASD 
together so there was only one disconnect sequence? Without RPS there was a 
disconnect/reconnect sequence for the seek, followed by set sector.

Or something like that. My curiosity is crying out for someone to correct me 

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, January 24, 2018 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] CKD details

On 24 January 2018 at 10:57, Seymour J Metz  wrote:
I wrote:
>> What use is Set Sector without a block multiplexor channel (which 
>> allows disconnect/reconnect)? Were those available for some S/360 
>> models?
> Of course they were available; the model number for the 230 should be a clue 
> that it was announced for the S/360.  For that matter, the model number of 
> the 2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.

I understand the model numbering. But there's no *requirement* to use Set/Read 
Sector in your channel programing for a device that supports RPS; it's just a 
performance issue. A 3330 (and a fortiori, a 2305) should be able to be plugged 
into a 2860 selector channel and still work.

Tony H.

--
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: VSAM Performance - CPU reduction

[Ron hawkins]

Clark,

It's not that the process is reading a 2nd record in the same CI. That would
result in a buffer hit irrespective of whether it is LSR or NSR.

The empirical evidence of his test with BUFND=2 reduced from BUFND=240 is
that the program reads more than one CI sequentially for each skip. That
alone makes the file a poor candidate for LSR.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, January 24, 2018 4:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 23 Jan 2018 17:35:50 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:

>Clark,
>
>If you had time to read through this lengthy thread you will find that 
>the 2nd file uses skip-sequential access. LSR is usually not an 
>appropriate strategy for this access pattern.

I realize he was using skip sequential.  My point was that random access
looks like it could be a better fit for this file than skip sequential
especially since a second record may have to be read after the first record
is found on the second file.

Clark Morris
>
>The OP has tried reducing BUFND on the second file, and observed a 
>reduction in throughput, which verifies the extent to which the 
>sequential access is taking advantage of chained Cis.
>
>Ron
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Clark Morris
>Sent: Tuesday, January 23, 2018 4:57 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction
>
>[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main 
>arun.venkatrat...@cognizant.com (Arun Venkatratnam) wrote:
>
>>Hi All,
>>
>>We are looking to improve the performance of a COBOL program that 
>>processes
>2 VSAM files. The first file is the I/P file and every record read from 
>the input VSAM file is searched for a matching record in the other file 
>and a report is written. The program also applies some business rules 
>while comparing each matching record.
>>
>>The I/P file is read sequentially while the other file is read in a 
>>skip
>sequential basis. The test files that were used had 32M records each 
>while production files have 110M records each.
>
>I assume using random access for the second file was tried with 
>adequate buffering for index and data. BLSR or the more current means 
>of doing random access buffering should have been used.  It may also 
>help to save any randomly read record that were read based on 
>information in records from the second file based on the match with a 
>record from the first file.  Knowing access patterns can help in
determining the best solution.
>
>Clark Morris
>>
>>Attached is the strobe report from the execution of the test job. The 
>>test
>job takes nearly 7 CPU minutes and was profiled to capture about 1 CPU 
>minute of execution time.
>>
>>We are attempting to optimize the VSAM access to these files as it is 
>>seen
>to take more than 50% of the CPU consumed by this job.
>>
>>In the 'Attribution of CPU execution time' section, we see that the 
>>major
>contributors are the components 'QSAM INIT I/O  & EXITS' (Module 
>IGZEQBL) and PARTITION COMMUNICATION.
>>
>>Could you please help us understand:
>>
>>1.What these components are
>>2.Why is QSAM access used instead of VSAM I/O access.
>>3.What needs to be done to reduce the CPU consumption by these components.
>>
>>Thank you
>>
>>Arun
>>
>>
>>--
>>-
>>--
>>-
>>
>>
>>1Strobe* PERFORMANCE PROFILE PROGRAMA
>01/02/2018   PAGE  42 
>>
>
>>-  #ACE   ** ATTRIBUTION OF CPU EXECUTION
>TIME **
>>-.COBLIB  IGZCPCO  IGZEVIO   VSAM INPUT/OUTPUT
>
>> ---WAS INVOKED BY-
>-VIA---  CPU TIME %
>> XACTION   MODULE   SECTION  DESCRIPTION   MODULE
>SECTION  DESCRIPTION  SOLO  TOTAL
>>
>
>>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERM
>.32   32
>>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
>QSAM INIT I/O  & EXITS1.93  1.93
>>
>
>> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE
>SECTION  DESCRIPTION

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Clark,

If you had time to read through this lengthy thread you will find that the
2nd file uses skip-sequential access. LSR is usually not an appropriate
strategy for this access pattern.

The OP has tried reducing BUFND on the second file, and observed a reduction
in throughput, which verifies the extent to which the sequential access is
taking advantage of chained Cis.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, January 23, 2018 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
arun.venkatrat...@cognizant.com (Arun Venkatratnam) wrote:

>Hi All,
>
>We are looking to improve the performance of a COBOL program that processes
2 VSAM files. The first file is the I/P file and every record read from the
input VSAM file is searched for a matching record in the other file and a
report is written. The program also applies some business rules while
comparing each matching record.
>
>The I/P file is read sequentially while the other file is read in a skip
sequential basis. The test files that were used had 32M records each while
production files have 110M records each.

I assume using random access for the second file was tried with adequate
buffering for index and data. BLSR or the more current means of doing random
access buffering should have been used.  It may also help to save any
randomly read record that were read based on information in records from the
second file based on the match with a record from the first file.  Knowing
access patterns can help in determining the best solution.

Clark Morris 
>
>Attached is the strobe report from the execution of the test job. The test
job takes nearly 7 CPU minutes and was profiled to capture about 1 CPU
minute of execution time.
>
>We are attempting to optimize the VSAM access to these files as it is seen
to take more than 50% of the CPU consumed by this job.
>
>In the 'Attribution of CPU execution time' section, we see that the major
contributors are the components 'QSAM INIT I/O  & EXITS' (Module IGZEQBL)
and PARTITION COMMUNICATION. 
>
>Could you please help us understand:
>
>1.What these components are
>2.Why is QSAM access used instead of VSAM I/O access.
>3.What needs to be done to reduce the CPU consumption by these components.
>
>Thank you
>
>Arun
>
>
>---
>---
>
>
>1Strobe* PERFORMANCE PROFILE PROGRAMA
01/02/2018   PAGE  42 
>

>-  #ACE   ** ATTRIBUTION OF CPU EXECUTION
TIME **
>-.COBLIB  IGZCPCO  IGZEVIO   VSAM INPUT/OUTPUT

> ---WAS INVOKED BY-
-VIA---  CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE
SECTION  DESCRIPTION  SOLO  TOTAL
>

>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERM
.32   32
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
QSAM INIT I/O  & EXITS1.93  1.93
>

> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE
SECTION  DESCRIPTION 
>

>  PROGRAMA PROGRAMA   003522
1.30  1.30
>
- -
>
3.55  3.55
>-.VSAMIDA019L1   VSAM RECORD MANAGEMENT

> ---WAS INVOKED BY-
-VIA---CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE
SECTION  DESCRIPTION   SOLO  TOTAL
>

>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
QSAM INIT I/O  & EXITS  1.84  1.84
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
CURRMEM  QSAM INIT I/O  & EXITS   4.34  4.38
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
DVFILE   QSAM INIT I/O  & EXITS.03   .03
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
PREVMEM  QSAM INIT I/O  & EXITS  22.48 22.51
>

> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE
SECTION  DESCRIPTION 
>

>  PROGRAMA PROGRAMA   003522   IGZCPCO
CURRMEM  PARTITION COMMUNICATION4.15  4.19
>  PROGRAMA PROGRAMA   003522   IGZCPCO
IGZEVIO  VSAM INPUT/OUTPUT   .57   .57
>  PROGRAMA PROGRAMA   003522   IGZCPCO
PREVMEM  PARTITION COMMUNICATION  16.80 16.80
>
- -
>

> 50.22 50.32
>
>--
>For IBM-MAIN subscribe / signoff / 

Re: Extended format internals

[Ron hawkins]

Radoslaw,

Just a SWAG.

Have you checked if you can see this in GTF Trace records using something
like CCW=(SI,DATA=128,CCWN=32000)?

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Monday, January 22, 2018 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Extended format internals

Curiosity only. Or rather willingness to learn...

Regards
-- 
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 16:35, Christopher Y. Blaicher pisze:
> I don't think it is published.  In the past I used the direct media
manager interface (the code that VSAM uses to build the CCW's), and even
there I didn't have to worry about it.
>
> You could do a CCW with data GTF trace on a data set and see what it
shows.
>
> Why do you need it, or is it just curiosity?
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
> Sent: Monday, January 22, 2018 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Extended format internals
>
> W dniu 2018-01-19 o 10:51, R.S. pisze:
>> Is is possible to print the content of additional 32-byte sufix using
>> AMASPZAP or maybe other tool?
>> Is the sufix content documented anywhere?
>>
> For record purposes:
> AMASPZAP refuse to open Extended Format with a clear message saying it is
not supported.
> dss PRINT does print the suffix as it would be a part of the block.
>
> I'm still looking for the description of the format of the suffix.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
>
>  --
>   Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
zapisane na dysku.
>
>   This e-mail may contain legally privileged information of the Bank and
is intended solely for business use of the addressee. This e-mail may only
be received by the addressee and may not be disclosed to any third parties.
If you are not the intended addressee of this e-mail or the employee
authorized to forward it to the addressee, be advised that any
dissemination, copying, distribution or any other similar activity is
legally prohibited and may be punishable. If you received this e-mail by
mistake please advise the sender immediately by using the reply facility in
your e-mail software and delete permanently this e-mail including any copies
of it either printed or saved to hard drive.
>
>   mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r.
kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488
złotych.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
>
>
> ATTENTION: -
>
> The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.
>
> --
> For IBM-MAIN subscribe / signoff / archive 

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Great detective work.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, January 19, 2018 7:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

On Fri, 19 Jan 2018 14:37:31 +0100, R.S. wrote:

>IMHO the CISZ was up to 32kB for a veeery long time (since VSAM 
>beginning perhaps).
>The most important is one could use any CISZ on any disk geometry, 
>including 3380 or 3350, or older.
>Of course PB (Physical Block) could be different, as well as number or 
>PB per CI.

The OS/MVS Overview manual, GC28-0984-0, dated June, 1978, is available on 
bitsavers at 
http://bitsavers.trailing-edge.com/pdf/ibm/370/OS_VS2/Release_3.7_1977/GC28-0984-0_OS_VS2_MVS_Overview_Rel_3.7_Jun78.pdf

On pages 8-18 and 8-19 (151-152) talks about control intervals and has this:


The size of the control interval need not correspond to the size of a track on 
the device. Figure 8.9 shows the independence of control intervals from 
physical records, which are limited by the capacity of a track on a particular 
device.


This confirms Ron's and Radoslaw's memory.

--
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: What about 3390-9 track???

[Ron hawkins]

All is it referring to the physical track size of the "real 3390-9?"

The 3390-9 spun at 1/3 the speed of the 3390-3, and each physical track 
presented 3 logical tracks to the channel program. Probably on of the earliest 
examples of virtualization for CKD.

I think Amdahl and Hitachi virtualized the mod 9 differently to IBM, and the 
performance was a better because of that. Never got to test the PCM kit first 
hand, so I'm not 100% sure on that. Can you say RPS 
Miii?


Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, January 18, 2018 6:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] What about 3390-9 track???

OK, the manual is little bit out of date. ;-) It is SC26-7408-10, a book from 
z/OS 1.13 Collection. However IMHO nothing has changed in that area during last 
10-20 years.
I checked in z/OS 2.2 - it is fixed.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-01-18 o 14:55, Steve Smith pisze:
> I don't know what you mean by "current one", as I have V2R3 manual
> (SC23-6852-30), and it has no such inconsistency in Appendix E, Table
> 71, on page 428.
>
> sas
>
> 2018-01-17 19:08 GMT-05:00 R.S. :
>> I just read some chapter of DFSMS Macro Instructions for Datasets, the
>> current one.
>> And I found the manual claims a 3990-9 hac longer track size: it is 56669 -
>> not 56664.
>> Is it a typo or there is something I don't know???
>> (it is Appendix 1.5.4)
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


==


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

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

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


--
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: VSAM Performance - CPU reduction

[Ron hawkins]

Peter,

Spanned records on VSAM are not the same as DSORG=PS.

I need to verify this, but my memory says that even with spanned records, VSAM 
will write a record in a new CI if it will not fit in the current CI. I thought 
that spanned records are only written when the record is greater than the CISZ.

That means spanned records space efficiency with VSAM depends on the number of 
records greater than the CISZ. I think that is why it is good for SMF ESDS.


Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Vander Woude
Sent: Wednesday, January 17, 2018 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

Arun,

In the IDCAMS listing, I see that the files are defined NONSPANNED.  With the 
records being variable length, you could have as few as 2 records per ci, since 
the max is around 11000.  if all the records are the minimum of 170, then you 
would have around 156 records per ci.

Have you looked at changing NONSPANNED to SPANNED?  That will allow variable 
length records to go across CI's, and might help in some small way, by 
decreasing the actual space that the files use up.  As such the # of records 
read in, as defined by the BUFND, will be higher.

for the skip sequential file, if you are doing a point and then read next, what 
is the average number of records that are being processed?  Having the BUFND so 
high, if it's only processing a few records in the data component, then you are 
reading in, and spending higher cpu time, just to throw away those records and 
read in the next set of ci's.  Anytime you reduce the BUFND, of course your 
EXCP's will go up, as VSAM I/O counts are the number of times it had to read a 
group of ci's, as opposed to sequential files, where each block counts as an 
I/O, no matter what BUFNO is set to.

Peter

--
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: VSAM Performance - CPU reduction

[Ron hawkins]

Clark,

I don't know where it is written up, but it has been this way as long as I
can remember, which is 5 minutes when I go to the shop, and a bit longer for
IDCAMS.

Following example look at the CISZ(32768) versus the physical record size
(16384). Physical record size is the block size used for each record on the
track, so each CI uses two blocks or records and can span a track boundary.

DATA --- HAWKINS.KSDS.DATA

  IN-CAT --- CATALOG.VHDSUSR

  HISTORY

DATASET-OWNER-(NULL) CREATION2018.019

RELEASE2 EXPIRATION--.000

ACCOUNT-INFO---(NULL)

  PROTECTION-PSWD-(NULL) RACF(NO)

  ASSOCIATIONS

CLUSTER--HAWKINS.KSDS

  ATTRIBUTES

KEYLEN44 AVGLRECL-435
BUFSPACE--530432 CISIZE-32768 
RKP0 MAXLRECL2040
EXCPEXIT--(NULL) CI/CA-22 
SHROPTNS(3,3)  SPEED UNIQUE   NOERASE INDEXED
NOWRITECHK UNORDEREDNOREUSE 
NONSPANNED

  STATISTICS

REC-TOTAL--0 SPLITS-CI--0
EXCPS--0  
REC-DELETED0 SPLITS-CA--0
EXTENTS1  
REC-INSERTED---0 FREESPACE-%CI--0
SYSTEM-TIMESTAMP: 
REC-UPDATED0 FREESPACE-%CA--0
X''  
REC-RETRIEVED--0 FREESPC---720896

  ALLOCATION

SPACE-TYPE--CYLINDER HI-A-RBA--720896

SPACE-PRI--1 HI-U-RBA---0

SPACE-SEC--1

  VOLUME

VOLSERHDSUS5 PHYREC-SIZE16384
HI-A-RBA--720896 EXTENT-NUMBER--1 
DEVTYPE--X'3010200F' PHYRECS/TRK3
HI-U-RBA---0 EXTENT-TYPEX'40' 
VOLFLAGPRIME TRACKS/CA-15

EXTENTS:

LOW-CCHH-X'0006' LOW-RBA0
TRACKS15  
HIGH-CCHHX'0006000E' HIGH-RBA--720895



Ron 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, January 16, 2018 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 16 Jan 2018 06:54:52 -0800, in bit.listserv.ibm-main
ronjhawk...@sbcglobal.net (Ron hawkins) wrote:

>Tim,
>
>Things changed a couple of decades ago.
>
>VSAM physical block is not always the same as the CISZ. 
>
>32K CISZ does not waste any space on the track. 

Where is this written up?  Being retired, I missed this and didn't realize
this was true on the OS390 system I worked on in the 1990s.

Clark Morris
>
>Ron
>
>--
>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

Re: Finding the names of hsm's BCDSs

[Ron hawkins]

Would obtaining the data set names from SDSF meet your requirement?

//DFHSMJOB MSGLEVEL=1  
//STARTING EXEC DFHSM,CMD=00   
XX 
XX*  DFHSM 1.3 -  START PROCEDURE* 
XX*  * 
XX* THE FOLLOWING START PROCEDURE COULD BE DUPLICATED, AND RENAMED   * 
XX* FOR ANOTHER CPU IN THE CASE WHERE A MULTI-HOST ENVIRONMENT WILL  * 
XX* BE USED. CHANGES WOULD BE REQUIRED FOR THE CMD= AND THE HOST=* 
XX* PARAMETERS, AND THE ARCLOGX AND ARCLOGY DATA SET NAMES.  * 
XX*  * 
XX 
XXDFHSM  PROC CMD=00, USE PARMLIB MEMBER ARCCMD00  
XXEMERG=NO,   ALLOW ALL DFHSM FUNCTIONS
XXLOGSW=NO,   DON'T SWITCH LOGS AT STARTUP 
XXSTARTUP=YES,STARTUP INFO PRINTED AT STARTUP  
XXUID=DFHSM,  DFHSM AUTHORIZED-USER ID 
XXSIZE=0M,REGION SIZE FOR DFHSM
XXDDD=50, MAX DYNAMICALLY ALLOCATED DATA SETS  
XXHOST=1Y PROC.UNIT ID AND LEVEL FUNCTIONS 
XXDFHSM  EXEC PGM=ARCCTL,DYNAMNBR=,REGION=,TIME=1440, 
XXPARM=('EMERG=','LOGSW=','CMD=','UID=',   
XX'STARTUP=','HOST=') 
IEFC653I SUBSTITUTION JCL - PGM=ARCCTL,DYNAMNBR=50,REGION=0M,TIME=1440,
'UID=DFHSM','STARTUP=YES','HOST=1Y')   
XXHSMPARM  DD DSN=SYS1.PARMLIB,DISP=SHR
XXMSYSOUT  DD SYSOUT=A 
XXMSYSIN   DD DUMMY
XXSYSPRINT DD SYSOUT=A,FREE=CLOSE  
XXSYSUDUMP DD SYSOUT=A 
XXMIGCAT   DD DSN=,DISP=SHR  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.MCDS,DISP=SHR
XXJOURNAL  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.JRNL,DISP=MOD
XXARCLOGX  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMLOGX1,DISP=MOD
XXARCLOGY  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMLOGY1,DISP=MOD
XXARCPDOX  DD DSN=,DISP=SHR   
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMPDOX,DISP=SHR 
XXARCPDOY  DD DSN=,DISP=SHR   
XX*  */
XX* REMOVE THE NEXT DD STATEMENT IF YOU DO NOT INTEND TO USE */
XX* BACKUP AND DUMP. */
XX*  */
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMPDOY,DISP=SHR 
XXBAKCAT   DD DSN=,DISP=SHR  
XX*  */
XX* REMOVE THE NEXT DD STATEMENT IF YOU DO NOT   */
XX* INTEND TO USE TAPE VOLUMES FOR DAILY BACKUP VOLUMES, SPILL   */
XX* BACKUP VOLUMES, OR MIGRATION LEVEL 2 VOLUMES.*/
XX*  */
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.BCDS,DISP=SHR
XXOFFCAT   DD DSN=,DISP=SHR  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.OCDS,DISP=SHR

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, January 17, 2018 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Finding the names of hsm's BCDSs

Similarly, I was going to suggest calling TSO to invoke HSEND WAIT.

But QUERY CDS doesn't reveal the names of the HSM CDS's, just space information 
about them. Neither does Q SETSYS, but it does show the names of the CDS backup 
datasets. Quite often the backup dataset names are the same as the CDS', 
suffixed with BACKUP or BKUP or something.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Graham Harris
Sent: Thursday, 18 January 2018 6:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Finding the names of hsm's BCDSs

Whilst you're waiting for IBM to deliver a proper API, you could trap the 
console output from a F DFHSM,Q CDS.
DFHSM may well not be called DFHSM of course, so that will add a little extra 
work, perhaps using an ISGQUERY on ARCENQG




On 17 January 2018 at 13:29, Manfred Lotz  wrote:

> On Wed, 17 

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Tim,

Things changed a couple of decades ago.

VSAM physical block is not always the same as the CISZ. 

32K CISZ does not waste any space on the track. 

Ron

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

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Arun,

Don't bother, mate. I kind of give up.

People can't help when you keep the kimono shut.

I recommend you engage someone that works with Strobe, or the vendor directly.

Ron

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

Re: AW: Re: Number of Cylinders per Volume

[Ron hawkins]

Oops, forgot about plain text formatting. I hope this is easier to read.

Quantiles (Definition 5)
Level   Quantile
100% Max5.02530E+04
99% 3.60866E+02
95% 3.89331E+01
90% 1.60667E+01
75% Q3  2.26616E+00
50% Median  1.1E-01
25% Q1  6.62619E-02
10% 6.62619E-02
5%  6.62619E-02
1%  0.0E+00
0% Min  0.0E+00

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron hawkins
Sent: Sunday, January 14, 2018 1:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: Number of Cylinders per Volume

Radoslaw,

 

I'm not sure I follow. I replied to your example that specifically talked to 
datasets of 50cyl allocated in CMA. I assume you chose 50 rather than 10, 
because 10 is the default BPV.

 

If your shop has a preponderance of datasets between 10 and 50 cyls then change 
the BPV so they are track managed. Then the waste is 0% and it addresses your 
example exactly. You would find this skew in the univariate output. In my 
sample data, the 95th percentile is 38.9 cyl.

 


Quantiles (Definition 5)


Level

Quantile


100% Max

5.02530E+04


99%

3.60866E+02


95%

3.89331E+01


90%

1.60667E+01


75% Q3

2.26616E+00


50% Median

1.1E-01


25% Q1

6.62619E-02


10%

6.62619E-02


5%

6.62619E-02


1%

0.0E+00


0% Min

0.0E+00

 

The creation of 200,000 small datasets, where  I think you mean less than 1 
track, is not an EAV problem. You're talking about200,000 tracks of space per 
day, or 42 2290-54 per year. 200K tracks is less than the track managed area of 
a single volume so I don't see the problem. There would have to be an overpaid 
storage admin for these datasets to end up in the cylinder managed area.

 

Even fragmentation can't stop you allocating trk(1) in the TMA. There are 
better options with less waste suggested by Mike and Gil, and I've seen exact 
matches to this other problem you described with Control/D solved with SDSP.

 

Ron

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Saturday, January 13, 2018 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: Number of Cylinders per Volume

 

Ron,

While your solution can keep "small" datasets away from EAS, it is not a 
solution for a need I described.

I mean a scenarion when many thousands of relatively small datasets need to be 
kept on disk. Colleague of mine administer a system, where ~200

000 datasets are created during EOD.

 

Of course when we talk about big storage needs it's  usually not-so-many 
datasets, but big or huge ones.

Last, but not least, we have limited choice - up to 64(-256) non-EAV volumes or 
bigger EAV volumes (with the same limit for quantity).

 

Regards

--

Radoslaw Skorupka

Lodz, Poland

 

 

 

 

 

 

 

W dniu 2018-01-13 o 19:02, Ron hawkins pisze:

> Radoslaw,

> 

> That's why you can change the threshold for the track allocation area.

> 

> DCOLLECT and PROC UNIVARIATE will probably give you all the guidance you 
> need. DCOLLECT does not have the primary space allocation size so this code 
> is not 100% accurate. It is good enough to give some guidance.

> 

> I executed this against one of our general purpose lab systems, and this is 
> the CMA waste estimate with break point value at 5, 10 and 20 cylinders.

> 

> EAV Breakpointvalue 10 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 610787.607878009

> Percent Wasted CMA8.1%

> 

> EAV Breakpointvalue 5 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 783635.165880735

> Percent Wasted CMA   10.4%

> 

> EAV Breakpointvalue 20 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 309321.636811143

> Percent Wasted CMA4.1%

> 

> You could use SAS code like this to come up with a  good starting point for 
> your shop when you go EAV.

> 

> options obs=max bufno=256 nosource2 nomacrogen nosymbolgen nomlogic 
> nomprint sortsize=6G msglevel=i;

> goptions reset=all;

> 

> %let BPV=20;

> 

> Title1 "EAV Breakpoint Value  Cylinders";  *** 
> Main Output Title ;

> 

> FILENAME DCOLLECT FTP  (  

> 
> "MY.DCOL'"

> 
> )

>USER='myuid' HOST='111.222.333.444' DEBUG

>S370VS RCMD='SITE RDW' L

Re: AW: Re: Number of Cylinders per Volume

[Ron hawkins]

Radoslaw,

 

I'm not sure I follow. I replied to your example that specifically talked to 
datasets of 50cyl allocated in CMA. I assume you chose 50 rather than 10, 
because 10 is the default BPV.

 

If your shop has a preponderance of datasets between 10 and 50 cyls then change 
the BPV so they are track managed. Then the waste is 0% and it addresses your 
example exactly. You would find this skew in the univariate output. In my 
sample data, the 95th percentile is 38.9 cyl.

 


Quantiles (Definition 5)


Level

Quantile


100% Max

5.02530E+04


99%

3.60866E+02


95%

3.89331E+01


90%

1.60667E+01


75% Q3

2.26616E+00


50% Median

1.1E-01


25% Q1

6.62619E-02


10%

6.62619E-02


5%

6.62619E-02


1%

0.0E+00


0% Min

0.0E+00

 

The creation of 200,000 small datasets, where  I think you mean less than 1 
track, is not an EAV problem. You're talking about200,000 tracks of space per 
day, or 42 2290-54 per year. 200K tracks is less than the track managed area of 
a single volume so I don't see the problem. There would have to be an overpaid 
storage admin for these datasets to end up in the cylinder managed area.

 

Even fragmentation can't stop you allocating trk(1) in the TMA. There are 
better options with less waste suggested by Mike and Gil, and I've seen exact 
matches to this other problem you described with Control/D solved with SDSP.

 

Ron

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Saturday, January 13, 2018 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: Number of Cylinders per Volume

 

Ron,

While your solution can keep "small" datasets away from EAS, it is not a 
solution for a need I described.

I mean a scenarion when many thousands of relatively small datasets need to be 
kept on disk. Colleague of mine administer a system, where ~200

000 datasets are created during EOD.

 

Of course when we talk about big storage needs it's  usually not-so-many 
datasets, but big or huge ones.

Last, but not least, we have limited choice - up to 64(-256) non-EAV volumes or 
bigger EAV volumes (with the same limit for quantity).

 

Regards

--

Radoslaw Skorupka

Lodz, Poland

 

 

 

 

 

 

 

W dniu 2018-01-13 o 19:02, Ron hawkins pisze:

> Radoslaw,

> 

> That's why you can change the threshold for the track allocation area.

> 

> DCOLLECT and PROC UNIVARIATE will probably give you all the guidance you 
> need. DCOLLECT does not have the primary space allocation size so this code 
> is not 100% accurate. It is good enough to give some guidance.

> 

> I executed this against one of our general purpose lab systems, and this is 
> the CMA waste estimate with break point value at 5, 10 and 20 cylinders.

> 

> EAV Breakpointvalue 10 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 610787.607878009

> Percent Wasted CMA8.1%

> 

> EAV Breakpointvalue 5 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 783635.165880735

> Percent Wasted CMA   10.4%

> 

> EAV Breakpointvalue 20 Cylinders

> Total Used   Cylinders 7516066.07911661

> Total Wasted Cylinders 309321.636811143

> Percent Wasted CMA4.1%

> 

> You could use SAS code like this to come up with a  good starting point for 
> your shop when you go EAV.

> 

> options obs=max bufno=256 nosource2 nomacrogen nosymbolgen nomlogic nomprint 
> sortsize=6G msglevel=i;

> goptions reset=all;

> 

> %let BPV=20;

> 

> Title1 "EAV Breakpoint Value  Cylinders";  *** 
> Main Output Title ;

> 

> FILENAME DCOLLECT FTP  (  

> 
> "MY.DCOL'"

> )

>USER='myuid' HOST='111.222.333.444' DEBUG

>S370VS RCMD='SITE RDW' LRECL=32760

>PASS='mypw';

> 

> proc datasets lib=pdb kill noprint;

> run;quit;

> 

> proc datasets lib=work kill noprint;

> run;quit;

> 

> %include sourclib(typedcol);

> run;

> 

> data dcolsp;

> set dcoldset;

> usedcyl=dcdusesp/(15*56664);

> if usedcyl> then wastecyl=mod(usedcyl,21);

> output;return;

> run;

> 

> title2 "Data set size distribution in Cylinders";

> proc univariate data=dcolsp;

> var usedcyl;

> histogram;

> run;

> 

> title2 "Cylinder Managed Area - Data set size distribution in Cylinders";

> proc univariate data=dcolsp;

> where usedcyl>

>

Re: AW: Re: Number of Cylinders per Volume

[Ron hawkins]

Paul,

Agree. zFS leaps out as an option immediately.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, January 13, 2018 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: Number of Cylinders per Volume

On Sat, 13 Jan 2018 21:19:54 +0100, R.S. wrote:

>Ron,
>While your solution can keep "small" datasets away from EAS, it is not 
>a solution for a need I described.
>I mean a scenarion when many thousands of relatively small datasets 
>need to be kept on disk. Colleague of mine administer a system, where 
>~200
>000 datasets are created during EOD.
> 
PDS(E) members?  UNIX files?  Why not?

-- 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: Number of Cylinders per Volume

[Ron hawkins]

Ed,

The way I remember it is that not long after the first 3390 started to ship, 
IBM "promised" that they would not change track geometry again.

The proof of the pudding was that the real 3390-9 kept the same track geometry, 
using three logical tracks on a physical track when there was an opportunity to 
go for something more like 64KiB.

The same opportunity was there when the ESS shipped, but they have stuck with 
their promise. I would not call SDB an SMS thing. It has helped with changes in 
optimal blocking for EF data sets, but I don't recall it being protection 
against changing form factors. I don't know that DFSMSdfp was ever going to 
deliver that while the track size is in the Base config.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Thursday, January 11, 2018 7:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Number of Cylinders per Volume

> On Jan 11, 2018, at 6:44 AM, R.S.  wrote:
> 
> Ed:
> I am sure I had read that. Of course such promise can be broken in the future 
> (why not?), but whole idea of so called mod-27, mod-54 and finally EAV was to 
> extend volume size with no change to geometry.
> 
> (speculation mode)
> IMHO the most likely change in the future we can expect is CKD - > FBA 
> migration. Unless FBA storage world will change current FBA model to 
> something, let's say "more flash lilely". For example FBA world changed 
> (actually came back *) the sector size which was 512B net for ages and now 
> it's commonly extended to 4096kB. That introduces some incompatibility 
> problems.
> (*) bigger sector sizes were used in magneto-optical removable media drives. 
> With big pain for some Unix systems and not only.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland

Radoslaw:

I was a project manager at Guide in the 90’s for storage. I vaguely remember 
being invited to San Jose (as part of SHARE+side story at bottom). IBM 
supposedly laid out their 10 year plan for DASD. Here is where it gets a little 
fuzzy. I believe the “future” was to be SMS PERIOD. IBM during one of the small 
sessions said that by being completely SMS you would no longer care about 
device geometry as long as you used the IBM SDB and  the appropriate space 
allocations. I was a "not in my lifetime person after the session". I talked 
with the other project managers and they had reservations as well but after 
years and years of changing track size and block size issues and getting gray 
hair along the line I think we were happy to finally rid ourselves of one more 
PITA.  At the time (IIRC) not all of the new SMS features were available. We 
were told to hold on it was being worked on. 

To complete the story, I am a semi believer never made it to 100 percent 
believer.

Now the side story: One (or two?) project managers were employed by OEM 
vendors. IBM put a restriction of attendance that if you were a OEM vendor you 
couldn’t attend. Its been so long that I do not remember if IBM backed down or 
the people were disinvited or what.

Ed


--
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: Number of Cylinders per Volume

[Ron hawkins]

Radoslaw,

That's why you can change the threshold for the track allocation area.

DCOLLECT and PROC UNIVARIATE will probably give you all the guidance you need. 
DCOLLECT does not have the primary space allocation size so this code is not 
100% accurate. It is good enough to give some guidance.

I executed this against one of our general purpose lab systems, and this is the 
CMA waste estimate with break point value at 5, 10 and 20 cylinders.

EAV Breakpointvalue 10 Cylinders
Total Used   Cylinders 7516066.07911661
Total Wasted Cylinders 610787.607878009
Percent Wasted CMA8.1%

EAV Breakpointvalue 5 Cylinders
Total Used   Cylinders 7516066.07911661
Total Wasted Cylinders 783635.165880735
Percent Wasted CMA   10.4%

EAV Breakpointvalue 20 Cylinders
Total Used   Cylinders 7516066.07911661
Total Wasted Cylinders 309321.636811143
Percent Wasted CMA4.1%

You could use SAS code like this to come up with a  good starting point for 
your shop when you go EAV.

options obs=max bufno=256 nosource2 nomacrogen nosymbolgen nomlogic nomprint 
sortsize=6G msglevel=i;
goptions reset=all;

%let BPV=20;

Title1 "EAV Breakpoint Value  Cylinders";  *** Main 
Output Title ;

FILENAME DCOLLECT FTP   (   
"MY.DCOL'" 
)
  USER='myuid' HOST='111.222.333.444' DEBUG
  S370VS RCMD='SITE RDW' LRECL=32760
  PASS='mypw';

proc datasets lib=pdb kill noprint;
run;quit;

proc datasets lib=work kill noprint;
run;quit;

%include sourclib(typedcol);
run;

data dcolsp;
set dcoldset;
usedcyl=dcdusesp/(15*56664);
if usedcyl> then wastecyl=mod(usedcyl,21);
output;return;
run;

title2 "Data set size distribution in Cylinders";
proc univariate data=dcolsp;
var usedcyl;
histogram;
run; 

title2 "Cylinder Managed Area - Data set size distribution in Cylinders";
proc univariate data=dcolsp;
where usedcyl>
var usedcyl;
histogram;
run; 

proc summary data=dcolsp nway;
var usedcyl wastecyl;
output  out=dcolsum
sum=
;
run;

data _null_;
set dcolsum;
pctwaste=wastecyl/usedcyl;
put "EAV Breakpointvalue  Cylinders"
/   "Total Used   Cylinders " usedcyl   best16.
/   "Total Wasted Cylinders " wastecyl  best16.
/   "Percent Wasted CMA " pctwaste  
percent16.1
;
run;


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Friday, January 12, 2018 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AW: Re: Number of Cylinders per Volume

W dniu 2018-01-12 o 13:15, Tom Marchant pisze:
> On Fri, 12 Jan 2018 01:32:07 +0100, R.S. wrote:
>
>> BTW: an "awful waste of storage" is MCU on EAS which is 21 cyl. (315 
>> trk). It is much more than 4kB and more than 4MB.
> Not such a big deal for very large data sets, which are the most 
> appropriate ones to go into the cylinder-managed space. When you have 
> a quarter of a million cylinders, allocating space on increments of 21 
> cylinders isn't so bad, IMO.
>

Of course. However sometimes people need a lot of not-so-big datasets. 
For ~1000 cyl datasets average lost is ~1% ( (21/2)/1000 ), but for 50 cyl 
datasets is ~20%.

--
Radoslaw Skorupka
Lodz, Poland




==


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

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

Re: Number of Cylinders per Volume

[Ron hawkins]

With Hitachi DP-Vols each 7 cyl control area manages 1113 cyls of usable
space per volume. The 3390-A volumes, however, do not have to be allocated
in units of 1113 cyls. You can specify any custom size volume you want in
cylinder units.

The 1120 cyls is allocated in 672 track pages, and the 7 cyls control area
is in the first page. The control area has things like record zero, bitmaps,
etc.

The pages are not allocated contiguously on the media, and there can be gaps
of unallocated pages if nothing is written to them. For a simple example, a
1344 track data set with 1300 unused tracks will only allocate one page, and
the next data set starting on track 1345 will be on a new page. The page for
track 673 to 1344 will not be used in the pool.

There is a huge impact on SMS if track geometry changes, because it is used
for allocation. Look at bytes/track in the Base Configuration.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Gould
Sent: Wednesday, January 10, 2018 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Number of Cylinders per Volume

> On Jan 10, 2018, at 5:26 AM, R.S.  wrote:
> 
> W dniu 2018-01-09 o 23:59, Mike Schwab pisze:
>> EAV volumes must be an exact multiple of 1,113 cylinders.  Under 64K 
>> volumes some storage devices allow multiple of 1,113 cylinders others 
>> multiples of 1 cylinder.
> 
> AFAIK it's not.
> 1113 multiple is a feature of DS8k arrays.
> EAV can be any number of cylinders, but EAS (the part above 65520 cyl)
should be multiple of MCU (MCU=21 cyl).

Radoslav:

I am not sure I have heard any such promise. The only promise I have ever
heard that if you are fully SMS any change in geometry would be unfelt, i.e.
no JCL changes.

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