PDSFAST

[John Thinnes]

Is there anyone out there still using PDSFAST from SEA?
This is an IEBCOPY replacement/enhancement.

We are a long time user, coming up for a 3 year renewal.
We are preparing to run comparisons between z/OS 2.2 IEBCOPY and the current release of PDSFAST.
Has anyone done this recently? Anything you would be willing to share?

Thanks

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

[Allan Staller]

Long long ago, in a galaxy far far away.....

IEBCOPY required authorization, PDSFAST did not.
For (*SOME*) functions, PDSFAST was a noticeable improvement over IEBCOPY.
ISTR some additional functions in PDSFAST, not in IEBCOPY (it was long long ago!)

I do not know what the license charge is , but at this time, I believe the benefit is marginal.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Thinnes
Sent: Tuesday, September 26, 2017 6:31 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: PDSFAST

Is there anyone out there still using PDSFAST from SEA?
This is an IEBCOPY replacement/enhancement.

We are a long time user, coming up for a 3 year renewal.
We are preparing to run comparisons between z/OS 2.2 IEBCOPY and the current release of PDSFAST.
Has anyone done this recently? Anything you would be willing to share?

Thanks

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John Eells]

Post by Allan Staller
Long long ago, in a galaxy far far away.....
IEBCOPY required authorization, PDSFAST did not.
For (*SOME*) functions, PDSFAST was a noticeable improvement over IEBCOPY.
ISTR some additional functions in PDSFAST, not in IEBCOPY (it was long long ago!)

<snip>

IEBCOPY no longer requires authorization in any supported release of
z/OS. We removed that requirement in z/OS V1.13 when we did some
performance work. The elapsed time for the things I think people use
IEBCOPY for most often (PDS-PDS copy, PDS unload/load, PDS compress)
fell pretty sharply, in the 19-70% range for the things we tested at the
time, with higher block sizes and record lengths showing greater benefit
as one might expect. (Details can be found in my SHARE presentations
from 2011-2012 by searching Google with this argument: "what's new in
z/OS V1.13 eells share 2011".)

I have no CPU time numbers, nor have I spent any time playing with BUFNO
to see whether IEBCOPY could be given more performance help that way.

[Edward Gould]

Post by John Thinnes
Is there anyone out there still using PDSFAST from SEA?
This is an IEBCOPY replacement/enhancement.
We are a long time user, coming up for a 3 year renewal.
We are preparing to run comparisons between z/OS 2.2 IEBCOPY and the current release of PDSFAST.
Has anyone done this recently? Anything you would be willing to share?
Thanks

Its been a few years, but I seem to remember trying to reblock a load lib and it got really choked up on this.
I had to call the vendor and figure out a way around it.

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

[Paul Gilmartin]

Post by John Eells
IEBCOPY no longer requires authorization in any supported release of
z/OS. We removed that requirement in z/OS V1.13 when we did some
performance work.

Once, prior to 1.13, I received the message:
IEB1099I *** IEBCOPY IS NOT APF AUTHORIZED ***
System action
IEBCOPY will continue to determine if it can proceed without authorization and
will issue IEB1099E when it can not avoid using a service requiring authorization.

This implied that some unauthorized use of IEBCOPY was supported. I
submitted an RCF asking for a clarification of when IEBCOPY might be
used without authorization. Rejected; reason; "subject to change".

ISTR that in the day unauthorized IEBCOPY succeeded (not always) on
PDSE but failed (more often) on PDS.

ISTR that either IBM continued to distribute the older IEBCOPY which
(sometimes) required authorization, or that some installations kept
such a restricted outdated copy available. Why? Auditor phobia?

How much performance advantage does PDSFAST provide on PDSE?
(And might it use PDSE interfaces documented only under NDA?)

-- gil

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

[John Eells]

Paul Gilmartin wrote:
<snip>

Post by Paul Gilmartin
ISTR that either IBM continued to distribute the older IEBCOPY which
(sometimes) required authorization, or that some installations kept
such a restricted outdated copy available. Why? Auditor phobia?

<snip>

This had nothing to do with auditing. It was just the native caution of
the DFSMS developers. IEBCOPY is *so* fundamental a utility they wanted
to make sure people had a copy of the old one...just in case something
happened that made it necessary.

And...something did. The zPDT systems of the day did not support the
necesary subset of the ECKD command set, exposing a bug that could be
circumvented by using the old one until the fix was available. We never
found this in testing because (suprise!) no real disk devices are
available that do *not* support ECKD as far as I know, and those from
IBM have not been available for 20 years or more.

[Paul Gilmartin]

Post by John Eells
And...something did. The zPDT systems of the day did not support the
necesary subset of the ECKD command set, exposing a bug that could be
circumvented by using the old one until the fix was available. We never
found this in testing because (suprise!) no real disk devices are
available that do *not* support ECKD as far as I know, and those from
IBM have not been available for 20 years or more.

Clearly IBM has a sunset policy for support of hardware: You can't run
z/OS 1.13 on a 3031. But is it different for peripheral devices? Was
IBM claiming to support the device that exposed the problem, or could
it have been called user error; unsupported sustem?

-- gil

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