> Hi All, > > One of our application programmer has created a PDS with below attributes : > > > > Data Set Name . . . : > TPUN011.NEWMAPST > > > General Data Current > Allocation > Management class . . : **None** Allocated blocks . : > 741 > Storage class . . . : TPUSC Allocated extents . : > 2 > Volume serial . . . : TPUN01 Maximum dir. blocks : 0 > * > Device type . . . . : > 3390 > Data class . . . . . : > **None** > Organization . . . : PO Current > Utilization > Record format . . . : FB Used blocks . . . . : > 3 > Record length . . . : 80 Used extents . . . : > 1 > Block size . . . . : 800 Used dir. blocks . : 0 > * > 1st extent blocks . : 78 Number of members . : 0 > * > Secondary blocks . : > 100 > Data set name type : > PDS > > > Creation date . . . : 2011/10/18 Referenced date . . : > 2011/10/24 > Expiration date . . : > ***None*** > * Information is unavailable. > > When he tries to allocate a member within the dataset : > TPUN011.NEWMAPST(map), he gets a message as "BLDL error" I tried searching some > error related to PDF as starting with ISRxxxx but I was not able to fetch any error > codes relating to "BLDL" Error in the syslog. > > IBM manual has various explanation for BLDL or I/O processing error, but for the > above I am unable to pin-point the exact cause. > > Looking at the above dataset attribute, I can see a "*" > symbol beside Maximum dir. blocks and Used dir. blocks . : 0, but i am unable to > interpret the exact cause. > > Could anyone please suggest me your comment on query. > > Regards, > Jags >
Jags, Some thoughts. If the member addition to the PDS that got the BLDL error, then the allocation did not include Directory Blocks. If there were members and now it shows 0 Dir Blocks, then someone used an IEBGENER (or similar program) to add a member and did not specify the member name. Thereby writing over the directory blocks at the beginning of the dataset. To allocate in batch the coding should be: // SPACE=(CYL,(xx,yy,dd)) where xx is primary allocation, yy is secondary allocation, and dd is the number of directory blocks. If allocating via TSO ALLOC command, coding should be: ALLOC DD(mydd) DA(mydsn) SPACE(xx yy) DIR(dd) etc... An IEBGENER Example which Trashes the Directory : //S0001 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=some.sequential.data //SYSUT2 DD DISP=SHR,DSN=mypds //SYSIN DD DUMMY Note on SYSUT2 there is no member specified. This will over write the PDS Directory in many cases and there by destroying the PDS. The correct coding for SYSUT2 is //SYSUT2 DD DISP=SHR,DSN=mypds(member) Second, the blksize is not optimal. I typically allocation with 0 Blksize and let SDB (System Determined Blocksize) handle what it should be. The amount of data you can write is dependent on the lrecl and blksize. With today's technology you do not need to worry so much about disk rotation speed. When in turn lead to the use of 1/4 and 1/2 blocking on disks. In most cases full track blocking will work fine. If you wish to experiment, take your syslog data. Create a sequent file with LRECL=133 BLKSIZE=133 and copy the SYSLOG into it. Look at the attributes. Then do the same thing but with full track blocking. You should see a significant amount of dasd space between the two with the same number of records. The same results will be true in most cases for a PDS. A PDSE does not follow the same process so there is not really a comparison. However, some benefits - PDS/E does not need to be compressed. Can handle OBJECTS as well as old style PDS data. PDS data sets need to be compressed and cannot be used to hold OBJECTS. Lizette ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
