BLDL error Cause

[jagadishan perumal]

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ron Hawkins]

Jags,

Is there a chance that someone has written directly to the PDS without specifying a member name?

I recall past posts have mentioned that this will corrupt a PDS.

A scan of your Type 14/15 SMF records may identify the culprit.

Ron

Ron Hawkins
Complex Test Lab - Mainframe, Technical Operations
HITACHI DATA SYSTEMS
P 408.970.4458 / C 408.332.8566

[R.S.]

W dniu 2011-10-24 08:07, jagadishan perumal pisze: > 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 . : > Volume serial . . . : TPUN01 Maximum dir. blocks : 0 > Device type . . . . : > 3390 > Data class . . . . . : > **None** > Organization . . . : PO Current > Utilization > Record format . . . : FB Used blocks . . . . : > Record length . . . : 80 Used extents . . . : > 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. Look at the Maximum dir. blocks : 0 You created crippled PDS. It cannot have members. BTW: why do you provided blocksize 800? Why not system determined blocksize? (it has nothing to do with the above problem) Radoslaw Skorupka Lodz, Poland tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc e by jedynie jej adresat z wy czeniem dost pu os b trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: in...@brebank.pl d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 0000025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2011 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.346.696 z otych. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Vernooij, CP - SPLXM]

"jagadishan perumal" <jagad...@GMAIL.COM> wrote in message
news:<CANHhCyRSdw_ReiSh_Oibs2_K...@mail.gmail.com
>...

> 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
>

This is not a PDS, it has 0 directory blocks. (Maximum dir. blocks : 0)
Kees.
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

[Linda Mooney]

Hi Jags,



There is no directory.  Directory space is the third parameter on the space allocation when allocating a PDS.  Either he forgot to code it, or it was 0.  Ask the programmer to delete the dataset and create it again, with directory space. 



HTH,



Linda


----- Original Message -----

[jagadishan perumal]

"This is not a PDS, it has 0 directory blocks. (Maximum dir. blocks : 0)"

But it says "Data set name type : PDS "

[Vernooij, CP - SPLXM]

A PDS with zero tracks cannot contain data, a PDS with zero dir. Blocks
cannot contain members.
Specify directory blocks.

Kees.

"jagadishan perumal" <jagad...@GMAIL.COM> wrote in message

news:<CANHhCyS-gcXY8XnJ1QJBQC=6TeqTNMsLZnJi...@mail.gmail.com
>...

[R.S.]

W dniu 2011-10-24 09:05, jagadishan perumal pisze: > "This is not a PDS, it has 0 directory blocks. (Maximum dir. blocks : 0)" > But it says "Data set name type : PDS " Yes, it says, so what?. It says PO, PDS, *and* directory 0. That means your dataset (partially) looks like PDS, but it cannot hold any member. You should provide directory for PDS. This is the solution: delete this crippled PDS and create new one, with directory. Radoslaw Skorupka Lodz, Poland tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc e by jedynie jej adresat z wy czeniem dost pu os b trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: in...@brebank.pl d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 0000025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2011 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.346.696 z otych. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html

[jagadishan perumal]

Hi All,

I will ask the programmer to delete and re-create the dataset. Meanwhile I
will examine His JCL(PDS allocation).

Regards,
Jags

On Mon, Oct 24, 2011 at 12:39 PM, Vernooij, CP - SPLXM <

[Elardus Engelbrecht]

jagadishan perumal wrote:

>"This is not a PDS, it has 0 directory blocks. (Maximum dir. blocks : 0)"

>But it says "Data set name type : PDS "

Believe them. Trust me on this one.

Your dataset is defined on the OUTSIDE as a PDS, but the INTERNAL organization is corrupt (Max Dir Blocks = zero).

Your PDS is unusable.

I would suggest that you ***review*** the actual creation process of that PDS and ensure your PDS is created 100% correct. (Dataset org, Sizing (Cyls, etc), Record Format and Length, directory blocks, optional - Blocksize)

HTH!

Groete / Greetings
Elardus Engelbrecht

[Lizette Koehler]

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

[Chase, John]

How can you have a PDS with ZERO directory blocks?

-jc-

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of jagadishan perumal
> Sent: Monday, October 24, 2011 1:07 AM
> To: IBM-...@bama.ua.edu
> Subject: BLDL error Cause
>

[Tom Marchant]

On Mon, 24 Oct 2011 06:57:33 -0400, Lizette Koehler wrote:

>In most cases full track blocking will work fine.

Did I miss the announcement that block sizes greater than 32K are
supported? What release was that?

--
Tom Marchant

[jagadishan perumal]

Hi,

"What release was that?"

Its 1.8

Regards,
Jags

[Lizette Koehler]

> Did I miss the announcement that block sizes greater than 32K are
supported? What
> release was that?
>
> --
> Tom Marchant

Okay a slight clarification. 32K is the largest I know of for full track
blocking on DASD. Not sure about EAVs or Tape. The discussion of Full
Track Blocking revolves around the architecture of the DASD. And of course
that is changing with EAVs and TAPE.

Some of the older dataset technologies do not handle greater than 32K very
well. So for most discussions, a 32K Blocksize might be considered default.
Now, there is the LBI (Large Block Interface) that can change that process.

If you are running on OS/390 2.10 or later, then you know that BSAM, BPAM
and QSAM support LBI on disk, tape, spooled, subsystem and dummy data sets

So if you want OPEN to determine the block size and you want to use LBI,
here are some considerations:

You might assume that the user of the writing program will take advantage of
the new BLKSZLIM keyword on the DD statement (or dynamic allocation), to
limit the block size. The minimum value that the user can code is 32760.
That value of 32760 also is the IBM-provided system default value for
BLKSZLIM. The system programmer can change the system default by setting the
TAPEBLKSZLIM keyword in the DEVSUPxx member of SYS1.PARMLIB.. Coding
BLKSZLIM=32760 will ensure the tape will be readable by non-LBI programs.
Note that with fixed-length records the BLKSZLIM value does not have to be a
multiple of LRECL. This is because BLKSZLIM is only a limit on the BLKSIZE
value that OPEN will calculate.

A reason that someone might want to limit block size to less than the device
maximum is that the user might want to copy the tape to another device type
without relocking. The other device might have a smaller block size limit.

You might assume that the user of the program will code the BLKSIZE
parameter to force an appropriate maximum block size for the data set. This
requires the user to know the maximum block size supported by the device. If
you code BLKSIZE, it overrides any value of BLKSZLIM for the same DD
statement. If the device does not support blocks as large as the coded
BLKSIZE value, OPEN will issue an ABEND unless you are using EXCP, in which
case the device might cause a problem. IBM recommends letting OPEN calculate
a block size if feasible. It is not feasible with unlabeled tape and IBM
also recommends using IBM or ISO/ANSI labeled tape. The latter type of tape
does not support blocks longer than 32760 bytes.

Instead of relying on the BLKSZLIM or BLKSIZE keywords, you might want to
implement an option for the program. IEBGENER and ICEGENER have such
options. The purpose of the option might be to tell the program whether to
use LBI. Note that calling the option something "LBI=YES" will not be
meaningful for most users. You might want to choose for your program to take
advantage of the system-level default for copying programs. IEBGENER and
ICEGENER do that. They test a DFA field that contains the system-level
default for the SDB keyword for IEBGENER. To prevent OPEN from calculating a
block size that exceeds 32760, the easiest way is not to request LBI. In
other words, do not turn on DCBEULBI. These are the values in the DFA:

So when I stated full track blocking, I was thinking (though I did not
specify it) 32K. Or the maximum number of LRECLs that fit in a 32K
Blocksize. I round to 32760 for the following discussion though 32K is
32767 (doing this from memory)

For example, an LRECL of 80 would be 32760/80 or 32720

An LRECL of 133 would be 32760/133 or 32718

Sorry for the confusion. I kept the discussion around 32k blocks rather
than looking at the new technology that many shops are NOT using at this
time.

Lizette

[Tom Marchant]

On Mon, 24 Oct 2011 09:12:00 -0400, Lizette Koehler wrote:

>>Did I miss the announcement that block sizes greater than 32K are
>>supported? What release was that?
>>
>> --
>> Tom Marchant
>
>
>Okay a slight clarification. 32K is the largest I know of for full track
>blocking on DASD.

Ok. 32K has been supported for a long time, but it is less than full track
on 3380 and 3390.

>Track Blocking revolves around the architecture of the DASD. And of course
>that is changing with EAVs and TAPE.

EAVs have more cylinders, but the track size and the number of tracks
per cylinder is the same as for any other 3390.

>If you are running on OS/390 2.10 or later, then you know that BSAM, BPAM
>and QSAM support LBI on disk, tape, spooled, subsystem and dummy data sets

From DFSMS: Using Data Sets for z/OS 1.13: Section 3.2.3.1.1 Large Block
Interface (LBI):

"Currently blocks of more than 32 760 bytes are supported only on tape,
dummy data sets, and BSAM UNIX files."

So still no full track blocking. Thanks for the clarification.

--
Tom Marchant

[Shmuel Metz , Seymour J.]

In <6795006467018006.WA.m...@bama.ua.edu>, on
10/24/2011

at 07:19 AM, Tom Marchant <m42tom-...@YAHOO.COM> said:

>Did I miss the announcement that block sizes greater than 32K are
>supported?

Yes, but it was for tape.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Shmuel Metz , Seymour J.]

In
<CANHhCyRSdw_ReiSh_Oibs2_K...@mail.gmail.com>,
on 10/24/2011
at 11:37 AM, jagadishan perumal <jagad...@GMAIL.COM> said:

>Maximum dir. blocks : 0

?

>When he tries to allocate a member within the dataset :
>TPUN011.NEWMAPST(map), he gets a message as "BLDL error"

1. Was the member name really lower case?

2. If there really is no directory then I would expect BLDL
and STOW to fail.

3. Wasn't there an error code in the message?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Tony Harminc]

On 24 October 2011 02:07, jagadishan perumal <jagad...@gmail.com> wrote:

> 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.

Sigh... The cause has been pointed out by a number of others, but
still, you really need to be more precise in describing problems.
While enough people on this list enjoy the thrill of the chase, so to
speak, that you got your answer based on what little you provided, you
could certainly have solved this yourself quite easily. For that
matter your application programmer could have solved it himself.

What was the actual error message you got, and what produced it? Text
"BLDL error" sounds a lot like an ISPF report, but in that case
hitting PF1 would produce the actual return code, and that can be
looked up.

> 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.

If you will post all and exactly the messages you got, where they
appeared, and what you did to produce them, I am almost 100% certain
that the IBM manuals will have the one correct explanation.

Tony H.

[Gerhard Postpischil]

On 10/24/2011 8:19 AM, Tom Marchant wrote:
> Did I miss the announcement that block sizes greater than 32K are
> supported? What release was that?

It depends on your definition of "supported" - I had a job that
used BSAM to manipulate blocks larger than 32K (disk and tape).
If you have an even number of buffers, it's quite easy to
overlay the relevant BSAM control blocks and CCWs with larger
sizes. QSAM might be a bit harder. These days it's easier to use
EXCP, since much of the detailed error handling can be avoided.

Gerhard Postpischil
Bradford, VT

[Shmuel Metz , Seymour J.]

In <056c01cc924e$84278a70$8c769f50$@mindspring.com>, on 10/24/2011

at 09:12 AM, Lizette Koehler <star...@MINDSPRING.COM> said:

>If you are running on OS/390 2.10 or later, then you know that BSAM,
>BPAM and QSAM support LBI on disk, tape, spooled, subsystem and dummy
>data sets

Not on disk.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)