IBM Mainframe Forum

after creating 7 PS files it shows that there is no space in the directory..why it shows like that and how many PS can be created and saved in a Single PDS?

lgokul17 wrote:after creating 7 PS files it shows that there is no space in the directory..why it shows like that

Very possibly because there is no space in the directory. How many blocks is it?

how many PS can be created and saved in a Single PDS?

How long is a piece of string? The number of members that can be placed in a PDS is a function of

1. The size of the PDS
2. The size of the members
3. The number of directory blocks
4. The format of directory entries

As you miscall the members "PS files" it's not unreasonable to guess that this is not a load library, but beyond that nothing meaningful can be said.

ok bro thanks since am new to mainframe am trying to learn more..please suggest me to learn in easier way!!

lgokul17 wrote:ok bro

You may address me as "Akatsukami-sama"

thanks since am new to mainframe am trying to learn more..please suggest me to learn in easier way!!

Well, you are undertaking a task that can be compared only to Thor's attempting to drink the ocean in a single draft. I suggest though, that you bookmark the following:

• IBM Information Management Software for z/OS Solutions Information Center (which, despite the name, also includes DB2 manuals)
• IBM System z Application Development Help System (COBOL and PL/I, as well as various tools such as File Manager)
• z/OS V1R13 information center (pretty much everything else you'll want, except CICS)

Note on this and our sister site we will answer questions (although the answers may be "RTFM!" and "STFW!" where appropriate) and offer suggestions and even code fragments, we will generally not write your program for you (unless paid our usual billing rates). An exception to this are the *Sort fora, where the developers of the products themselves, and several other senior and skilled people, will often provide you with complete control decks. Even if you take advantage of this, however, I recommend that you study them and try to understand them; if you just blindly use them to fulfill your requirement-of-the-moment, you may find that when things go pear-shaped, you are left with a "solution" that you do not understand and cannot modify, and for which the original developer is no longer available.

1. Since you claim to be creating a PDS you are creating members in the PDS. A member of a PDS is similar to a "PS file," but it is not identical.
2. A PDS has a directory with the number of directory blocks you specified when the PDS was created. Each member of a PDS has a directory entry that varies in size from 12 bytes to 74 bytes. A directory block has 254 bytes that can be used for member entries; the last directory block requires 12 bytes for an end of directory "member."
3. Members created by ISPF often have "ISPF statistics" in the member entry in the directory. These member entries use 42 bytes: 12 bytes for the member name and PDS control information and 30 bytes for "ISPF statistics." You can get 5 of these members + the 12 byte end of directory "member" in one directory block. ISPF will complain the directory is full when you attempt to add the sixth member.
4. There is no standard way to add more directory blocks to a PDS dataset. You usually create a new PDS dataset with more directory blocks and copy the original PDS to the new PDS when you need a larger directory. You can use the IEBCOPY program to copy a PDS in batch. ISPF also provides an ISPF utility that can copy a PDS; this utility uses IEBCOPY under the covers.

Hello and welcome to the forum,

As you are new to the forum as well as the mainframe, suggest you pick up "bits at a time" rather than absorb everything right away.

If you post the info requested earlier, we should be able to help.

Note that a pds may be "full" when it really is not. It may need to be compressed. From the little posted so far, i suggest you copy the existing pds to a new pds of a larger size, with more directory blocks and then post the info from that new dataset as well as the original.

Akatsukami listed 4 things that affect PDS capacity -

1. The size of the PDS, in other words the total space allocated to the PDS.
2. The size of the members. A PDS used as a PROCLIB generally has relatively small individual members, so you can get a lot of members in a relatively small amount of space. The members in a PDS used to store source programs, on the other hand, tend to be much larger, so you will get fewer, though much larger members, in the same amount of space as the PROCLIB dataset.
3. The number of directory blocks. This has already been discussed.
4. The format of the directory entries. This, too, has already been discussed.

Mr. Scherrer mentioned that a PDS may be "full" when it really is not. This is more complicated. When you delete or replace a member, the space occupied by the member is not automatically reused for other members. After a while the PDS may have a large amount of unused space. This space can be recovered in two ways.

• You can copy the entire PDS to another PDS. The unused space is not copied.
• You can "compress" the PDS using, generally, IEBCOPY in a batch job, The DSLIST function in ISPF also has this capability, though it uses IEBCOPY under the covers, as it were. "Compressing" a large PDS may require quite a lot of time. The compress utility must read through the entire dataset to find unused space, and then physically copy members to reuse the space. While this is being done the dataset cannot be used by other users. Another problem is if anything interrupts the compress the PDS will not be usable. Fortunately, this is a rare problem any more.

This discussion does not apply to the PDS directory. The space occupied by a member entry is reused when the member is deleted.

Hi Gokul -

A Partitioned Dataset is a special form of a Sequential Data-set. Every PDS has a directory(just like Yellow-Pages), to keep track of how its allocated disk space, or data space, has been divided into parts. Each part(slice) is called a member.

Say for example, you have a PDS with 5 Members, on the disk -



The PDS directory will contain a list of all the PDS Member-names, and a disk-pointer. The minimum directory block room, you need for each member is 12 Bytes. It has the 8-Byte member-name and a 4-byte binary value called the TTRC(Relative Track Number). The TTRC indicates the relative Track Number and the block where the member starts.



zOS also allows applications like TSO to store "user-data" in PDS Directory entries for each member via Assembler Macros. If you retain the ISPF statistics about each member, as TSO/ISPF normally does, each member takes 42 bytes of directory block space. The last 12 bytes of a directory is specially meant for End-Of-Directory Member.

When you allocate a partitioned data set, you reserve/set-aside space for it on the disk. You generally do this with the TSO/ISPF Function 3.2. At that time, you decide how big its directory will be. 1 Directory block is 256 bytes large. This implies, if you reserve 1 block for the PDS Directory(256 Bytes), with each member occupying 42 bytes of directory block space, the directory would be able to store information about (256 - Last 12 bytes)/42 = 5 Members.

Therefore, a rule of thumb in creating a PDS is to estimate how many members you will want to house in the PDS, and divide it by five to calculate the number of directory blocks.

Its quite possible for a partitioned-data set to have member storage space available, but no ability to house more members, as its directory is filled up. You'll get a system completion code SB14-0C.



Thanks,
Quasar

You can use the IEHLIST Utiltity, to actually explore, how a PDS Directory looks like. Run the following Job-Stream :



The contents of SYSADM.MY.PDS Directory


Thanks,
Quasar