IBM Mainframe Forum

Hello !!

I tried using IEBCOPY to merge/Concatenate multiple PDS into a single PDS. But I am not able to do so. Please Help. Below is the code that I used


But getting below error



Then I Tried below code


But it is giving an error message as below


Please let me know how Can I make a Single PDS by Merging/concainating Multiple PDS.

your space parameter is not correct for a PDS file

• As Mickeydusaor says, the SPACE parameter for MYDD2 does not specify the number of PDS directory blocks.
• The "CONCATENATED DATA SETS NOT ALLOWED. USE MULTIPLE INDD= OPERANDS" message is telling you what do do - if you bothered to read the message rather than cry here so you can be flamed.
• It is unusual, though not illegal, to define PDS data sets as members of a generation data group. Indeed, among my personal data sets are 15 or so GDG data sets that are, in fact, PDS data sets. As I write this post, it is up to true generation 301 after creating 3 or 4 every month. A couple of years ago I created more, but for the last 18 months or so it has been 3 or 4.
• Are the data sets specified by MYDD1 actually PDS data sets? If not, you will have to use a different approach, as IEBCOPY will only process PDS data sets
• IEBCOPY ignores DCB=BUFNO=xx if the data sets specified by MYDD1 are actually PDS data sets. It achieves the same effect using different means.
• Assuming the data sets specified by MYDD1 are actually PDS data sets, are all the member names unique? If not, I'm sure you're aware a single PDS can have just one member with a unique name. In other words, if two or more of the PDS data sets have a member like URAIDIOT, the combined PDS will have just one URAIDIOT member. I couldn't merge those 15 or so PDS data sets I mentioned a couple of bullets ago into a single PDS even if I wanted to for that reason.

I've said this before, and I'm sure I'll say it again. A "file" in MVS is the data on a magnetic tape between two "file marks," or the beginning of the tape and a "file mark." Period. End of story. There are no "files" on disk. A "file" in toy and baby machines consists of a stream of undifferentiated bytes. An MVS "data set," on the other hand, has a defined structure. If you learn nothing else in your association MVS, do not forget this.

If they are sequential datasets then concatenate them together on SYSUT1 in an IEBGENER job.

Thanks for the reply. Please guide me to fix this SPACE/DCB or SYSIN definition to get the desired single PDS (MYDD3).
This is what I used for my output dataset definition. (for first example)



Input PDS are MYDD1 & MYDD2 and both the PDS has below definition

I have got the solution. I have used SPACE as

Thanks All for your hints.
Now, as my input PDS MYDD1 MYDD2 ... MYDD6 contains duplicate 'member name' , while merging duplicate names are being ignored in o/p data set .
example MYDD1 has 3 members MEM1 MEM2 MEM3 and MYDD2 has 2 member MEM2 MEM4 . So after merging my O/P MYDD3 contains 4 members MEM1 MEM2 MEM3 MEM4. But I want to get 5 members. I know that duplicate member name is not possible in a PDS. So, I am wondering if there is any way to rename all the member of MYDD2 before doing the merge operation. Lets say (MYDD2 hold 500 members as MEM2,MEM4,MEM5........MEM501) and I want to rename those as (#EM2,#EM4,#EM5.... #EM501). Please advice.

Thanks once again

Farhaan4mf wrote:I have got the solution. I have used SPACE as

Select all

SPACE=(CYL,(500,500,500)),       
DCB=(RECFM=FB,LRECL=132,DSORG=PO)

Hint: If you specify directory blocks in the SPACE parameter, JCL understands you intend for the data set to be a partitioned data set; you do not have to specify DSORG=PO.

It seems to me 500 directory blocks is excessive, but I should not criticize since I do not know the attributes of the input. A moderately dark semi secret about PDS data sets with a large number of members is directory management can be slow. I do not think, in 45 years of fiddling with PDS data sets I have encountered a broken directory from "too many" members, or even complaints about "slow" directories or "slow" directory updates, but the potential is there. One never really resolved issue in the system design of System/360 type disk storage is the designers got kind of hung up on the idea of hardware assisted data lookup. In the early 1960s, B-tree indexing, the standard most commonly used these days, was the stuff of university research. The designers had to get something out the door, and they wanted to offload at least some CPU clicks to off board hardware. At the system level, this resulted in some true disasters like data set lookup in a VTOC, member lookup in a PDS directory, and, in general, ISAM. By the late 1970s or early 1980s, ISAM was being replaced by VSAM, the VTOC problem was mostly resolved with "indexed" VTOCs, and the PDS member search problem was supposed to be resolved by PDSE in the late 1980s, though the general lack of massive interest in PDSE suggests PDSE was a solution for what, in retrospect, was a minor problem. Of course part of the problem with PDSE is it is based on the now discredited and mostly abandoned HFS scheme for the sort of *nix in what is called Unix System Services this week. Most interest in PDSE these days appears to be related to its ability to automagically manage space within the data set slightly better than PDS, not for its possibly better directory, and definitely not for superior performance or superior space utilization. Specific case resolution for the member lookup issue is LLA, but LLA is mostly for link list data sets, not for the general PDS directory search problem.

We often see queries about mass renames of PDS members in these forums, but I do not think I have ever seen a hint about a tool to do it. Renaming PDS members is not terribly difficult, but defining rules to select member names to rename and the rule for the new member name is quite difficult. Personally, I've been thinking about this for years, and never came up with an idea sufficiently well baked to start an implementation. I'm not afraid of trying to implement something, though I often abandon something when I found the idea was not as well "baked" as I thought when I started.