IBM Mainframe Forum

Hello,

I have a PDS with RECFM U, this currently houses the load modules; the format of the same is as below:



I am trying to copy the members of this PDS to a new PDS, which is being modelled on this same PDS, the o/p PDS created has format:



The error received while trying to copy any member to this new PDS is:



I did look up the fine manual, but the blocksizes as being reflected in either PDSs' case is same; am unable to put my finger on what is going wrong here; what did I mess-up now and how is that RECL of 32k reflecting; I am suspecting that my INPDS is where the problem lies, because when I test the same with other load libraries, it is working as expected - copying datasets normally.

Surprisingly, when I try copying the members manually from this same PDS after sometime, they are getting copied; and another 10 minutes later, it fails with the same error. What on earth am I doing wrong here

System programmer response

The IEHLIST utility may be used to display the block size in the data set label. If the error recurs and the program is not in error, look at the messages in the job log for more information. Search problem reporting data bases for a fix for the problem. If no fix exists, contact the IBM® Support Center. Provide the JCL and all printed output and output data sets related to the problem.

Programmer response

If the DCB parameters have been overridden, respecify the correct block size and key length.

the error message You received leads us to murky grounds
are You sure that the input dataset has a 6144 blksize ???
NOO WAY that a member with a 32760 block length can be stored there!

32760 is usually the blksize for PDSEs


most probably Your input PDS is broken
why not try to copy to a PDSe with a 32760 blksize ?

Hello Enricho,

Rightly pointed. The loads in question are located in a PDSE (pertaining to a new change management tools load library), which is copied to a PDS on UAT LPAR of 6k blksize (this being the replica of original SCLM load library; not the new change management tool's), post which it is FTP'd to PROD LPAR into a temp PDS of 6k blksize. Later, it is moved from this temp PDS to actual PROD SCLM PDS (this is a legacy PDS being used for over the years); which again is 6k blksize.

The screenshots I'd shared are of PROD SCLM PDS and a backup PDS created to move the old loads prior to new load movement. It is this backup on PROD LPAR which was failing. Please note all load libraries on PROD LPAR are PDS.

I did suspect that it might be because of PDSE, which does explain the 32k blksize bit, but as you can see from the above flow -- the load on PROD LPAR is still untouched by the load present in PDSE on UAT.

Using a new PDSE as you've suggested, well it'd work, but that would also mean, changing the entire production load module library, and we'd have to wait until the next IPL to refresh the PROD CICS load libraries, which are all currently PDS.

Can there be any other scenario under which this can happen; apart from PDSE?

Thanks.

Can there be any other scenario under which this can happen; apart from PDSE?

it happens ALWAYS for recfm U PDS ( processed by the linkage editor )
when the input blksize is larger than the output blksize

a workaroung could be to use the IEBCOPY COPYMOD command
which instead of copying relinks everything

not wise to do it for PDSE to PDS conversion because of long names.

I've always used the COPYMOD statement in an IEBCOPY when copying load modules since that statement will cause reblocking if necessary.

Enrico,

I owe you one here. It worked like charm. Thank you so much.

I knew it was because of PDSE to PDS movement, but couldn't put my finger on a solution; damn

<Note to self: RTFM RTFM RTFM >

Enrico, Aki88 - This is not all that uncommon. Though it's not well known, program fetch is not aware of the declared BLKSIZE; it will just fetch the module if it is otherwise valid. The easiest way to do the copy is to specify DCB=BLKSIZE=32760 in the input DD statement, and use COPYMOD as suggested by Mr. Heinze to reblock the module to BLKSIZE=6144 if that's what you want. BLKSIZE=6144 is suitable for the IBM 2314. The last real 2314 (or 2314 clone) was scrapped at least 30 years ago! More likely 35 years ago. 12288 might make more sense, though the last 3330 or 3330 clone stopped spinning 25 years ago. For some reason IBM and some ISVs appear to like 6144.

The Binder's default BLKSIZE is wrong by the usual standards, but it really doesn't matter:

• The Binder rarely, if ever, writes that big a record.
• Every text record, except sometimes the last text record, is always followed by at least one record that has a maximum size of 256 bytes, and is usually smaller. The intermediate control or control/RLD records confuse space usage on a track.

Hello Steve,

Plain curious here; just trying to get my understanding a bit more clear.
I have a member in a PDSE of 32k BLKSIZE.
When I copy this to a PDS of BLKSIZE ~6K, the copy is successful, au contraire now when I try to copy this very same member from the new PDS (6k BLKSIZE) location to a another PDS (again 6k BLKSIZE), it fails with IEB188I.

Problem statement here is, how come the first copy (32k to 6k) went through whereas the other movement (6k to 6k) failed.

Agreed that a 6k BLKSIZE can't hold a 32k BLKSIZE, how did the first movement go through, then.

Thanks.

• PDSE "program objects" to PDS "load modules" always go through the Binder.
• BLKSIZE in a PDSE is simulated; the real physical records in a PDSE are 4K. Period. Full stop. End of story. I'm pretty sure that IEBCOPY uses standard BPAM for non load module PDSE data sets.

These users thanked the author steve-myers for the post:

Aki88 (Thu Jun 12, 2014 5:36 pm)