IBM Mainframe Forum

Dear friends
I want to copy a member to a PDS but it hasn't enough space to copy. How I can increase PDS size to copy more members in it? Which utility or JCL needed to do this.
(Note: I compressed this PDS but it doesn't have enough space yet.)

There are two potential problems here. You are whining about a problem, but you have not provided any error codes or error messages that describe the problem you have encountered. The potential problems are -

1. No space remains in the dataset. "Compressing" the PDS may correct this problem.
2. The PDS directory is full. "Compressing" the PDS will not correct this problem. There are utilities that can expand a PDS directory, but not all sites have any of these utilities installed.

First, you must determine what problem you have, either by using error messages or error codes, or by analyzing the dataset itself. The easiest way to analyze the dataset is to use ISPF option 3.2. ISPF will display a screen that looks like this

There is only one way to resolve the first problem. You must copy the PDS to a larger space. In order to do this you (we cannot do this for you) must determine the current allocation for the dataset, and you must write and run the JCL to perform the copy.

There are two ways to resolve the second problem.

• If there is a method the expand the directory installed at your site, which you must determine, you must run the procedure.
• If there is no method to expand the directory, you must copy the PDS to a larger space. In order to do this you (we cannot do this for you) must determine the current allocation for the dataset, and you must write and run the JCL to perform the copy.

Hello,

(Note: I compressed this PDS but it doesn't have enough space yet.)

If this were my situation, i would allocate a new pds with more directory blocks and considerable more space.

Make sure the problem pds will not be used for a short time.

Copy all of the members from the original pds to the new, larger pds.

Rename the origiinal PDS as a backup.

Rename the new PDS with all of the members to the original pds namd.

Do whatever to add/change members.

Make sure the new allocation has unused directory blocks and space.

Here is information from IBM about the advantages of PDSE: http://publib.boulder.ibm.com/infocente ... ts_166.htm

I don't think I have used a old style PDS since sometime in the 1990's when the company from which I retired converted all production PDS to PDSE.

PDSE avoids the problem of running out of directory space and it will reuse space occupied by deleted members, but ...

1. It requires substantially more DASD space than PDS for the same amount of data.
2. It requires more CPU time than PDS.
3. It requires more real I/O than PDS.

Of course, IBM does not bother to tell you about these "advantages."

Of course, IBM does not bother to tell you about these "advantages."

But they'll sell you more iron . . .

d

If you are in an environment with limited resources and the extra effort required to maintain PDS is not an issue, then PDS is fine.

Yes, PDSE can require more "overhead" but are faster and can require less DASD with careful use of the 123 available extents.

In the environment about which I spoke, service level requirements did not allow the continued use of PDS. We were also being pushed by software vendors who warned that their products would not perform well in our high volume environment unless we converted to PDSE.

If PDS is preferable in a particular situation, then by all means use it. Just because I have not seen one of these situations in well over a decade doesn't mean they still don't exist.

jhalley wrote:... Yes, PDSE can require more "overhead" but are faster and can require less DASD with careful use of the 123 available extents. ...

Huh?? If PDSE uses more I/O and CPU - and it does, how can it be faster???

If PDSE uses more space - and it does - what does having more extents buy you??

jhalley wrote:... In the environment about which I spoke, service level requirements did not allow the continued use of PDS. We were also being pushed by software vendors who warned that their products would not perform well in our high volume environment unless we converted to PDSE. ...

Many PDS data sets are basically static. In my opinion, these data sets should not be PDSE. PDS data sets that do require substantial maintenance efforts because they are not especially static probably should be PDSE.

PDS directory search is extremely slow when the directory is very large. I won't try to deny this. In the last year or so I tried to measure this relative to PDSE, but failed. An unmentioned advantage of RAID type DASD is the code in the controller can effectively speed up PDS directory search if it's done right.

Similarly, PDS directory management - deleting and adding members - is also very slow when the directory is large. I don't know about similar issues with PDSE, though one would hope PDSE is better than PDS.

PDSE is "faster" because members are accessed dynamically instead of through a sequential search. Information about this can be found in IBM manuals.

Having 123 extents and no separate directory means that a PDSE can be allocated with relatively few extents unlike a PDS where you must be much more careful to allocate it with adequate primary space due to its 16 extent limit and especially with adequate directory space.

I find this discussion rather odd since I thought using PDSE became a "nonissue" many years ago. But then, I was not working in an invironment where DASD was in short supply.

jhalley wrote:PDSE is "faster" because members are accessed dynamically instead of through a sequential search. Information about this can be found in IBM manuals.

Huh?? Searching PDS directory is basically a serial search. Once the directory entry is located, since the directory entry contains the address of the member, the member is accessed directly. IBM claims a PDSE directory search is more efficient. Since IBM refuses to disclose PDSE formats, you have to take them at their word. What data is available does not backup that IBMs word.

jhalley wrote:... Having 123 extents and no separate directory means that a PDSE can be allocated with relatively few extents unlike a PDS where you must be much more careful to allocate it with adequate primary space due to its 16 extent limit and especially with adequate directory space.

There is a separate directory. It's just scattered through the data set. Since a PDSE can expand somewhat more freely than a PDS, I suppose one can be lazier about the primary allocation. Many data set extents slows processing because it increases CPU usage for each I/O. Period. End of story.

jhalley wrote:... I find this discussion rather odd since I thought using PDSE became a "nonissue" many years ago. But then, I was not working in an invironment where DASD was in short supply.

I do not have the sense PDSE dominates PDS type storage in most shops. PDSEs poor performance as measured and hoggy storage requirements keep its usage relatively low.