Re: Reading Variable record with bad BDW/RDW?

[Barry Schwarz]

I don't know if any of the previous responses satisfied your need.  Another 
approach would be to create a second DCB (PS, BSAM, RECFM=U, and 
BLKSIZE=32760).  Open the DCB, read the first block, and close the DCB.  
Examine the data for whatever attributes you like (such as correct BDW and one 
or more correct RDWs).  Set some flags (such as "definitely not VB") and save 
some values (such as length of first block).  After opening your primary DCB, 
check the fields that are filled in (such as DSORG, LRECL, BLKSIZE) for 
consistency with your flags and saved values.
   
  Not only will this let you catch the case you described (a PDS directory 
would not pass the BDW/RDW check) but possibly other user mistakes such as 
records larger than blocksize, FB blocksize (either DSCB or actual) not a 
multiple of LRECL, F or FB blocks shorter than LRECL, etc

Thomas David Rivers <[EMAIL PROTECTED]> wrote:
  Hi Bill...

Well - yes - you've hit the nail on the head - the routines are very
confused because they are expecting to see VB-type records (with a BDW
and RDW) and they are not.

The program uses BSAM I/O.

The issue here is that the program expects to not be directed to a PDS,
and when that accidently happens - things go, as you mention,
alarmingly wrong.

What I'm looking for is some way for the program to say "Hey! This
isn't a sequentional VB file at all." Instead of miserably blowing
up.

As I mentioned before, I tried looking the DSORG in the DCB, but that
indicates PS (because the PDS was opened with a PS DCB.)

So - is there another way to tell if the file I'm trying to read
with BSAM I/O (doing my own unblocking of the VB records) is at all
reasonable?

Someone else suggested using DYNALLOC to query the organization
of the file before the OPEN... is there a way to accomplish
this after the OPEN?

Then - when the user points the program to a PDS instead of a nice
sequential file (or PDS member), things don't just "blow up", but
can simply inform the user that is an invalid file.


-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.

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

Re: Reading Variable record with bad BDW/RDW?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/25/2006
   at 10:25 AM, Binyamin Dissen <[EMAIL PROTECTED]> said:

>For his needs, only the first had to be checked. I doubt that there
>is much he should do if random unlike datasets were concatenated.

Put out an intelligible error message and as nonzero return code.

>It and the MACRF are required to properly build the DCB

DSORG can be cleared prior to the OPEN to allow a merge.

>and to get the correct access methods loaded.

That's at OPEN time, not assembly time.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Reading Variable record with bad BDW/RDW?

[Gerhard Postpischil]

Richard Tsujimoto wrote:
You could simply code the DCB with DSORG, and at run-time, reinitialize 
the DSORG field.  Why would you want to hand-craft a control block?


Who said I wanted to do so?  Shmuel asked what would happen if a DCB had 
a zero DSORG. Binyamin pointed out that the DCB MACRO requires both a 
MACRF and DSORG, which is true, but not relevant to Shmuel's statement. 
I pointed out that DCBs and other control blocks can be constructed the 
hard way.


As to why anyone would want to do so, I can think of a few scenarios, 
usually involving software written for an environment different from 
that in which it executes. For example, I have a software package that 
uses BTAM on systems licensed for it, but not having it myself, I can't 
assemble the macros, and need work arounds.


Gerhard Postpischil
Bradford, VT

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

You could code multiple DCBs and that's why I suggested doing
a DYNALLOC Info Retrieval *before* OPEN in a previous post.



From: Richard Tsujimoto <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Tue, 25 Apr 2006 10:31:27 -0400

JR wrote:

>The DCB has different layouts for different DSORGs;
>hence the reason that it is required.  If you clear
>the DSORG before OPEN, there may not be sufficient
>information for OPEN to work with.  (I didn't try this.)

I'm not sure why you couldn't code multiple DCBs, but that's another
story.  The whole point of zapping the DSORG field prior to OPEN is to see
if the DCB merge fills it in or not.

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


_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[Richard Tsujimoto]

JR wrote:

>The DCB has different layouts for different DSORGs;
>hence the reason that it is required.  If you clear
>the DSORG before OPEN, there may not be sufficient
>information for OPEN to work with.  (I didn't try this.)

I'm not sure why you couldn't code multiple DCBs, but that's another 
story.  The whole point of zapping the DSORG field prior to OPEN is to see 
if the DCB merge fills it in or not.

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

The DCB has different layouts for different DSORGs;
hence the reason that it is required.  If you clear
the DSORG before OPEN, there may not be sufficient
information for OPEN to work with.  (I didn't try this.)



From: Richard Tsujimoto <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Tue, 25 Apr 2006 09:27:57 -0400

You could simply code the DCB with DSORG, and at run-time, reinitialize
the DSORG field.  Why would you want to hand-craft a control block?




Gerhard Postpischil <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List 
04/25/2006 08:58 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Reading Variable record with bad BDW/RDW?






Binyamin Dissen wrote:
> :>>OPEN will not set DCBDSORG.
> :>If it's 0?
> No such thing. DCB macro requires it.
> It and the MACRF are required to properly build the DCB and to get the
correct
> access methods loaded.

Just to be a bit pedantic, he could build his own DCB without using the
macro. In the past I've committed a few programs that build their own
control blocks, e.g., DCB/DEB/IOB combinations. Would be interesting to
try this without a DSORG.

Gerhard Postpischil
Bradford, VT

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


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


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[Richard Tsujimoto]

You could simply code the DCB with DSORG, and at run-time, reinitialize 
the DSORG field.  Why would you want to hand-craft a control block?




Gerhard Postpischil <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
04/25/2006 08:58 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Reading Variable record with bad BDW/RDW?






Binyamin Dissen wrote:
> :>>OPEN will not set DCBDSORG.
> :>If it's 0?
> No such thing. DCB macro requires it.
> It and the MACRF are required to properly build the DCB and to get the 
correct
> access methods loaded.

Just to be a bit pedantic, he could build his own DCB without using the 
macro. In the past I've committed a few programs that build their own 
control blocks, e.g., DCB/DEB/IOB combinations. Would be interesting to 
try this without a DSORG.

Gerhard Postpischil
Bradford, VT

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


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

Re: Reading Variable record with bad BDW/RDW?

[Gerhard Postpischil]

Binyamin Dissen wrote:

:>>OPEN will not set DCBDSORG.
:>If it's 0?
No such thing. DCB macro requires it.
It and the MACRF are required to properly build the DCB and to get the correct
access methods loaded.


Just to be a bit pedantic, he could build his own DCB without using the 
macro. In the past I've committed a few programs that build their own 
control blocks, e.g., DCB/DEB/IOB combinations. Would be interesting to 
try this without a DSORG.


Gerhard Postpischil
Bradford, VT

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

Re: Reading Variable record with bad BDW/RDW?

[Binyamin Dissen]

On Tue, 25 Apr 2006 01:09:19 -0300 "Shmuel Metz (Seymour J.)"
<[EMAIL PROTECTED]> wrote:

:>In <[EMAIL PROTECTED]>, on 04/24/2006
:>   at 10:52 PM, Binyamin Dissen <[EMAIL PROTECTED]> said:

:>>Get the JFCB, use it (DSNAME + VOLUME) to read the DSCB.

:> 1. There may be more than one JFCB. He show fetcdh all into an ARL.

For his needs, only the first had to be checked. I doubt that there is much he
should do if random unlike datasets were concatenated.

:> 2. Reading a DSCB is not appropriate in all cases.

:>>OPEN will not set DCBDSORG.

:>If it's 0?

No such thing. DCB macro requires it.

It and the MACRF are required to properly build the DCB and to get the correct
access methods loaded.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Reading Variable record with bad BDW/RDW?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/24/2006
   at 10:52 PM, Binyamin Dissen <[EMAIL PROTECTED]> said:

>Get the JFCB, use it (DSNAME + VOLUME) to read the DSCB.

 1. There may be more than one JFCB. He show fetcdh all into an ARL.

 2. Reading a DSCB is not appropriate in all cases.

>OPEN will not set DCBDSORG.

If it's 0?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Reading Variable record with bad BDW/RDW?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 04/24/2006
   at 01:50 PM, "McKown, John" <[EMAIL PROTECTED]> said:

>The directory of a PDS is not VB. It is
>RECFM=F,LRECL=256,BLKSIZE=256,KEYLEN=8.

C '256' '264' 

256 is the right number only if you don't read the key.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Reading Variable record with bad BDW/RDW?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/24/2006
   at 02:40 PM, Thomas David Rivers <[EMAIL PROTECTED]> said:

>OK - admittedly - walking thru the directory entries and trying to
>interpret that as VB isn't the best thing in the world... but, what's
>a program "to do" with what the user types.

Google for "sanity check". One example is testing for a PDS with no
member name for a ddname that must be sequential.

>Or - is there a way to know this is a bunch of bytes from a PDS
>directory... and this READ doesn't make sense?

There's a way to know that the *OPEN* doesn't make sense. Search for
"Allocation Retrieval List" (ARL).
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Reading Variable record with bad BDW/RDW?

[Bruce Hewson]

Hello Dave Rivers,

When I first read your post I thought you were asking how to read a PDS 
directorybut that isnt what you want to do is it. You want to protect 
your VB reading program when it is accidentally handed a PDS.

I cant answer that, coz I am still focused on the read the PDS bit:

Here is some REXX code that can interpret PDS member directory.

Extract_Member_Names: Procedure Expose dsname member. ttr. alist.   
 Parse Arg mem_srch 
 member =   
 member. =  
 alist. =   
 ttr. = 
 mcnt = 0   
 dsinfo = Listdsi(dsname "DIRECTORY")   
 If sysdsorg = "PO" & sysmembers > 0 Then Do
   "ALLOC F(PDSDIR) DS(" || dsname || ") SHR REUS DSORG(PS)" ,  
   "LRECL(256) RECFM(F B)"  
   "EXECIO 1 DISKR PDSDIR"  
   Pull dblk
   blen = C2d(Substr(dblk,1,2)) 
   mem = Substr(dblk,3,8)   
   i = 3  /* index into block */
   Do While mem ¬= ''x  
 Do While mem ¬= ''x & i < blen 
   ttr= C2x(Substr(dblk, i+8  ,3 )) 
   flag   = Substr(dblk, i+11 ,1 )  
   ulen   = C2d(Bitand(flag,'1F'x)) * 2 
   aflag  = Bitand(flag,'80'x)  
   mem= Strip(mem,"B")  
   If aflag = '80'x Then Do 
 alist.ttr = alist.ttr mem  
   End  
   Else Do  
 If Length(Strip(mem_Srch)) = 0 ,   
  | Pos(mem_srch,mem) > 0 Then Do   
   mcnt = mcnt + 1  
   member.mcnt = mem
   ttr.mcnt = ttr   
 End
   End  
   i = i + 12 + ulen
   mem = Substr(dblk,i,8)   
 End
 If mem = ''x Then Leave
 "EXECIO 1 DISKR PDSDIR"
 If rc = 0 Then Do  
   Pull dblk
   blen = C2d(Substr(dblk,1,2)) 
   mem = Substr(dblk,3,8)   
   i = 3  /* index into block */
 End
 Else Leave 
   End  
   member.0 = mcnt  
   ttr.0 = mcnt 
   "EXECIO 0 DISKR PDSDIR ( FINIS"  
   "FREE F(PDSDIR)" 
 End
 Return mcnt


Regards
Bruce Hewson

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

Re: Reading Variable record with bad BDW/RDW?

[Robert A. Rosenberg]

At 16:33 -0400 on 04/24/2006, Kirk Talman wrote about Re: Reading 
Variable record with bad BDW/RDW?:



X_DUMMY  DS0A
 DCAL1(7),AL3(INFMJFCB)


That should be:

 DCXL1"87",AL3(INFMJFCB)

since as the last/only entry you need the x'80' end-of-list flag.

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

"Code DINRTORG to request the return of the data set organization (DSORG) of 
the specified resource."


"Code DINRTMEM to request the return of the member name associated with the 
specified allocation."


By getting this information *before* OPEN you should be able to set up your 
DCB appropriately.




From: Paul Gilmartin <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Mon, 24 Apr 2006 14:20:55 -0600

In a recent note, Thomas David Rivers said:

> Date: Mon, 24 Apr 2006 16:11:15 -0400
>
>   Someone else suggested using DYNALLOC to query the organization
>   of the file before the OPEN... is there a way to accomplish
>   this after the OPEN?
>
I would expect DYNALLOC IR to work equally well after OPEN as
before.  But you must do it before attempting to process any
record.

But, what does DYNALLOC IR indicate if DDNAME identifies a
properly allocated _member_ of a PDS with RECFM=VB, etc.?

-- gil
--
StorageTek
INFORMATION made POWERFUL

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


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 4/24/2006 4:05:12 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

>So far, it seems the only way to do that is to get the JFCB,  etc...


My first inclination was to answer the same way, since I did that  many 
decades ago.  But that approach may not work now for due  to the presence of 
many 
newer components with which I have little (SMS)  or no (HFS) experience.


>But - Gil seemed to think that wasn't the best approach.
Could be.  My experience was during the Jurassic era.

>DYNALLOC looks like another possible answer, but how  expensive
>is that?
The expense is not in executing the DYNALLOC function.  The great  expense is 
in finding the IBM doc, then coding and debugging the convoluted  data 
structure which you have to feed to DYNALLOC.  I did that once long  ago, and 
it was 
not easy.  Basically you must first choose the exact JCL  parameters you 
would need in a batch job to use the file, then you convert  those same JCL 
parameters to their DYNALLOC equivalent.  I would try very  hard to use RDJFCB 
instead.



Bill  Fairchild


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

Re: Reading Variable record with bad BDW/RDW?

[Edward Jaffe]

J R wrote:

I may be wrong but I thought that DSORG
was not optional on the DCB macro.


RECFM is optional.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Reading Variable record with bad BDW/RDW?

[Thomas David Rivers]

Hi again Bill...

 Yeah - that's a good idea...  But - I don't think I'm communicating
 something right...

 But - in this case, the user specified a file name.  OPEN filled in the
 DCBRECFM, etc... and the program went merrily on its way trying to
 do what the DCB said would work...

 This would normally be just fine, if the USER had specified a
 DSN(MEMBER), but instead, the user only specified the DSN.
 In this case, after the OPEN, the DCB is filled with the attributes
 of the PDS members, not the PDS directory.

 So - the filled-in DCB says RECFM=VB.  Which doesn't work
 well for 'reading' the PDS (works correctly for reading a member,
 not the PDS itself.)  Since we're not pointing at a member,
 but pointing at the PDS 'file' - we wind up reading directory
 bytes, which confuses the VB unblocking routines - and we
 wind up with erroneous data, and general "badness."

 Note that sometimes, a "plain" DSN is the right thing, since it could
 be a 'plain' flat/sequential file.  No reason to disallow those.
 So - the program can't apriori simply disallow names without
 members.

 I'd like things to be abstract enough that the program could
 say "hey - you gave me something invalid - wanna try again?"
 instead of S0C4.

 So - in this case, the values found in the DCB can't be used.
 In fact, in this particular situation, the GET and subsequent
 unblocking can't be used either, and I'd like the program
 to fail gracefully.  A check either at read-time or open-time
 would be fine.

 So far, it seems the only way to do that is to get the JFCB, etc...
 But - Gil seemed to think that wasn't the best approach.
 DYNALLOC looks like another possible answer, but how expensive
 is that?


 - Thanks -
- Dave Rivers -


, IBM Mainframe Discussion List wrote:
 
 
In a message dated 4/24/2006 3:12:40 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:




What  I'm looking for is some way for the program to say "Hey!   This
isn't a sequentional VB file at all."



Make sure the DCB in the program does not specify the file  organization.  
Then that field in the your DCB will be filled in with  information from the 
file's external label.  Then test it as Ed Jaffe  showed.


 
Bill  Fairchild




--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

I may be wrong but I thought that DSORG
was not optional on the DCB macro.



From: Paul Gilmartin <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Mon, 24 Apr 2006 14:40:33 -0600

In a recent note, J R said:

> Date: Mon, 24 Apr 2006 16:24:54 -0400
>
> Your inclinations assume that:
> (a) DCBDSORG will change during OPEN, and
>
> I don't believe (a) ever happens.
>
I certainly did assume that.  Have I misunderstood the
following:

Title: z/OS V1R5.0 DFSMS: Using Data Sets
Document Number: SC26-7410-03

#   3.2.2.1 "z/OS V1R5.0 DFSMS: Using Data Sets"

  3.2.2.1 Filling in the DCB

4. From the JFCB, OPEN fills in any field not completed in the DCB or
   DCBE. This completes what is called the forward merge.

??? (I know, it's pretty complicated.)

> >From: Paul Gilmartin <[log in to unmask]>
> >Date: Mon, 24 Apr 2006 13:35:55 -0600
> >
> >My inclination would be to verify:
> >
> >o DSORG != PO in the DCB after OPEN.

-- gil
--
StorageTek
INFORMATION made POWERFUL

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


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[Paul Gilmartin]

In a recent note, J R said:

> Date: Mon, 24 Apr 2006 16:24:54 -0400
> 
> Your inclinations assume that:
> (a) DCBDSORG will change during OPEN, and
> 
> I don't believe (a) ever happens.
> 
I certainly did assume that.  Have I misunderstood the
following:

Title: z/OS V1R5.0 DFSMS: Using Data Sets
Document Number: SC26-7410-03

#   3.2.2.1 "z/OS V1R5.0 DFSMS: Using Data Sets"

  3.2.2.1 Filling in the DCB

4. From the JFCB, OPEN fills in any field not completed in the DCB or
   DCBE. This completes what is called the forward merge.

??? (I know, it's pretty complicated.)

> >From: Paul Gilmartin <[log in to unmask]>
> >Date: Mon, 24 Apr 2006 13:35:55 -0600
> >
> >My inclination would be to verify:
> >
> >o DSORG != PO in the DCB after OPEN.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Reading Variable record with bad BDW/RDW?

[Kirk Talman]

IBM Mainframe Discussion List  wrote on 04/24/2006 
04:11:15 PM:

> The issue here is that the program expects to not be directed to a PDS,
> and when that accidently happens - things go, as you mention,
> alarmingly wrong.

> What I'm looking for is some way for the program to say "Hey!  This
> isn't a sequentional VB file at all."   Instead of miserably blowing
> up.

Before you OPEN the file, use RDJFCB to get the JFCB.

Look at expanded macro list to find the values of JFCDSORG (two byte 
field!) to test for.

RDJFCB MF=(E,$RDJFCB)
.
.
.
$RDJFCB  RDJFCB DUMMY,MF=L
DUMMYDCB   DSORG=PS,MACRF=GL,DDNAME=RMSIRXCW,EXLST=X_DUMMY
*   DATA CONTROL BLOCK 
X_DUMMY  DS0A 
 DCAL1(7),AL3(INFMJFCB)
.
.
.
IEFJFCBN LIST=YES

>  - Thanks -
>  - Dave Rivers -



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed.  The information may also constitute a legally
privileged confidential communication.  If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited.  If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message.  Thank you

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

Your inclinations assume that:
(a) DCBDSORG will change during OPEN, and
(b) the data will appear in his program without an error.

I don't believe (a) ever happens.
I think he already has the error before he sees the data.



From: Paul Gilmartin <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Mon, 24 Apr 2006 13:35:55 -0600

In a recent note, Thomas David Rivers said:

> Date: Mon, 24 Apr 2006 15:18:39 -0400
>
>   So - I suppose - what's the best way to ask "Hey - is this at
>   all a reasonable thing to be trying a VB-read on?"
>
My inclination would be to verify:

o DSORG != PO in the DCB after OPEN.  (But DON'T try to enforce
  DSORG == PS, because that is not set if DDNAME is allocated to
  a UNIX file.)

o BDW consistent with BLKSIZE, and no invalid flag bits set.

o RDW consistent with LRECL (and with BDW), and no invalid
  flag bits set.

(most of which QSAM does NOT verify)  If all tests pass, then
give the user what he asked for.  If any fail, indicate an
I/O error.

Now, suppose the user attempts to open for OUTPUT?  Wnat's a
good way to avoid trashing the PDS directory?

-- gil
--
StorageTek
INFORMATION made POWERFUL

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


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 4/24/2006 3:12:40 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

>What  I'm looking for is some way for the program to say "Hey!   This
>isn't a sequentional VB file at all."

Make sure the DCB in the program does not specify the file  organization.  
Then that field in the your DCB will be filled in with  information from the 
file's external label.  Then test it as Ed Jaffe  showed.

 
Bill  Fairchild

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

Re: Reading Variable record with bad BDW/RDW?

[Paul Gilmartin]

In a recent note, Thomas David Rivers said:

> Date: Mon, 24 Apr 2006 16:11:15 -0400
> 
>   Someone else suggested using DYNALLOC to query the organization
>   of the file before the OPEN... is there a way to accomplish
>   this after the OPEN?
> 
I would expect DYNALLOC IR to work equally well after OPEN as
before.  But you must do it before attempting to process any
record.

But, what does DYNALLOC IR indicate if DDNAME identifies a
properly allocated _member_ of a PDS with RECFM=VB, etc.?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Reading Variable record with bad BDW/RDW?

[Binyamin Dissen]

On Mon, 24 Apr 2006 14:06:11 -0600 Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

:>In a recent note, Binyamin Dissen said:

:>> Date: Mon, 24 Apr 2006 22:52:21 +0300
 
:>> Get the JFCB, use it (DSNAME + VOLUME) to read the DSCB.
 
:>I very much deplore it when people do that, then treat any
:>unexpected result as a failure.  It's an unwarranted flouting
:>of the OS/360 I/O abstraction model.  It prevents extension
:>of the I/O system.  For example, that sort of design now
:>prevents using an HFS directory as the first catenand in
:>SYSEXEC, while it works perfectly well as the second or later.

:>Let the access method detect errors; don't invent your own.

I believe that his intent was to detect a particular case. This will do it.

Of course one can go on with the 001-whatever, but it may be a good idea to
provide an intelligible error or, perhaps, a default member name.

I do agree that this is overkill for application level code, but I doubt that
such code is produced by Cole Software.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Reading Variable record with bad BDW/RDW?

[Edward Jaffe]

Thomas David Rivers wrote:

Hi Bill...

 Well - yes - you've hit the nail on the head - the routines are very
 confused because they are expecting to see VB-type records (with a BDW
 and RDW) and they are not.

 The program uses BSAM I/O.

 The issue here is that the program expects to not be directed to a PDS,
 and when that accidently happens - things go, as you mention,
 alarmingly wrong.

 What I'm looking for is some way for the program to say "Hey!  This
 isn't a sequentional VB file at all."   Instead of miserably blowing
 up.


| TMDCBRECFM,DCBRECUUndefined format ?
| JORECUBranch if yes
| TMDCBRECFM,DCBRECVVariable format ?
| JORECVBranch if yes
|* Handle Fixed Format Records
|RECF DC0H
| .
| .
|* Handle Variable Format Records
|RECV DC0H
| .
| .
|* Handle Undefined Format Records
|RECU DC0H
| .
| .

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Reading Variable record with bad BDW/RDW?

[Thomas David Rivers]

Hi Bill...

 Well - yes - you've hit the nail on the head - the routines are very
 confused because they are expecting to see VB-type records (with a BDW
 and RDW) and they are not.

 The program uses BSAM I/O.

 The issue here is that the program expects to not be directed to a PDS,
 and when that accidently happens - things go, as you mention,
 alarmingly wrong.

 What I'm looking for is some way for the program to say "Hey!  This
 isn't a sequentional VB file at all."   Instead of miserably blowing
 up.

 As I mentioned before, I tried looking the DSORG in the DCB, but that
 indicates PS (because the PDS was opened with a PS DCB.)

 So - is there another way to tell if the file I'm trying to read
 with BSAM I/O (doing my own unblocking of the VB records) is at all
 reasonable?

 Someone else suggested using DYNALLOC to query the organization
 of the file before the OPEN... is there a way to accomplish
 this after the OPEN?

 Then - when the user points the program to a PDS instead of a nice
 sequential file (or PDS member), things don't just "blow up", but
 can simply inform the user that is an invalid file.

- Thanks -
- Dave Rivers -


[EMAIL PROTECTED] wrote:

Your program can know that this bunch of bytes is a PDS directory because  it 
is the first block in the input data of a PDS.  The end of the  directory is 
marked by an end of file record.  That will probably confuse  your program, 
too.  Then the first block of the first member begins  after the end of file 
record, unless the first member has been  deleted after the second member was 
added, in which case what you  will read next is what used to be the first 
member, which also ends with  another end of file record.  More confusion.
 
I would suggest a complete redesign of your program beginning with a  
thorough understand of what your program is supposed to accomplish, followed  by 
research into the internals of a PDS.




Bill  Fairchild





--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Reading Variable record with bad BDW/RDW?

[Paul Gilmartin]

In a recent note, Binyamin Dissen said:

> Date: Mon, 24 Apr 2006 22:52:21 +0300
> 
> Get the JFCB, use it (DSNAME + VOLUME) to read the DSCB.
> 
I very much deplore it when people do that, then treat any
unexpected result as a failure.  It's an unwarranted flouting
of the OS/360 I/O abstraction model.  It prevents extension
of the I/O system.  For example, that sort of design now
prevents using an HFS directory as the first catenand in
SYSEXEC, while it works perfectly well as the second or later.

Let the access method detect errors; don't invent your own.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Reading Variable record with bad BDW/RDW?

[Binyamin Dissen]

On Mon, 24 Apr 2006 15:42:53 -0400 Thomas David Rivers <[EMAIL PROTECTED]>
wrote:

:>  That would work.. the program could avoid even trying the OPEN.

Get the JFCB, use it (DSNAME + VOLUME) to read the DSCB.

The DSCB will indicate whether it is a PDS and what its recorded RECFM and
LRECL are. The JFCB will indicate whether a member name was specified.

:>  In this case, the OPEN succeeds... and then the subsequent READ (BSAM)
:>  gets some bytes, but they aren't valid...

:>  I tried looking at DCBDSORG after the OPEN, but it has the value
:>  DCBDSGPS (Physical Sequential), since PS was specified at OPEN time.

The DSCB or JFCB never override a DCB value.

OPEN will not set DCBDSORG.

:>Binyamin Dissen wrote:
 
:>> It is not clear what your question is.
 
:>> Are you asking if there is a way to determine if a DD statement is pointing 
to
:>> a PDS without a member name specified?

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Reading Variable record with bad BDW/RDW?

[Thomas David Rivers]

Hi Binyamin!

 That would work.. the program could avoid even trying the OPEN.

 In this case, the OPEN succeeds... and then the subsequent READ (BSAM)
 gets some bytes, but they aren't valid...

 I tried looking at DCBDSORG after the OPEN, but it has the value
 DCBDSGPS (Physical Sequential), since PS was specified at OPEN time.

- Thanks! -
- Dave Rivers -



Binyamin Dissen wrote:



It is not clear what your question is.

Are you asking if there is a way to determine if a DD statement is pointing to
a PDS without a member name specified?




--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Reading Variable record with bad BDW/RDW?

[(IBM Mainframe Discussion List)]

 
 
In a message dated 4/24/2006 1:41:01 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

>I've got a program that opens a VB PDS  (RECFM=VB,BLKSIZE=2550,LRECL=255).

>But - note that I said it opens  the PDS, not a member of the PDS.  That
>open succeeds, and  presumably, the program will merrily try to
>read the PDS directory as  Format-V records.

>So - the first read succeeds, and it gets these  bytes back for
>the first 6:

>000E   
>| BDW  | | RDW  


The first block in a PDS is the first block of the directory, which has  a 
fixed format (lrecl=blksize=256 with 8-byte keys).  Presumably your  program is 
not trying to do a Read Key and Data but rather a Read Data CCW, so  you do 
not read the key but instead read only the first data block in the  directory.  
The first 2 bytes in the data area of a PDS directory block  are the number of 
bytes in that 256-byte block that are used.  You show  000E.  I did an 
IMASPZAP dump of a CNTL PDS of mine and found two  blocks with 00FE in the 
first two 
bytes, and the third block had  X'000E' at the 
beginning.  The 8 bytes of FF are  a fake member name of all X'FF' so that it 
will 
always be last when all the  member names are sorted into ascending sequence.  
A PDS directory is  supposed to have its member names in that sequence.  In my 
case, the 000E  is the correct number of bytes used in this block, as the 
minimum length of  one entry is 8 for the member name, 3 more for the relative 
TTR within the PDS  where the member begins, and 1 byte of flags.  The minimum 
entry length  is then 12.  Two more bytes for the obligatory 2-byte block 
length at the  beginning yields 14 bytes.  A block that begins as this one does 
is 
a  block indicating the last directory block with any meaningful information 
in  it, and in this case the meaningful info is the fake member name showing 
the  end of the directory's list of members.  There are more blocks in my  
directory after this one, and they are all X'00'.
 
It looks as if your PDS is completely empty.  That would explain why  you see 
000E in the first 6 bytes.  The read CCW does not move  any bytes 
around, change them, or interpret them.  It reads what is on  the track.  Then 
the VBS access method will assume that the first 2 bytes  are the block length, 
then 2 reserved bytes, then 2 RDW bytes, etc.  In  other words, because you 
told QSAM to read a PDS directory block and to treat  it as VBS data, you have 
thoroughly confused not only the access method but  also yourself.
 
You need to put a lot more logic into your program; i.e., be sensitive to  
file organization type (DSORG=PO for a PDS), etc.  I cannot begin to  suggest 
what extra logic you should add, since I do not know the purpose of  your 
program or why you want to read a PDS with it including its  directory.
 
A much better way to read through a PDS is with BSAM, which can also read  
through any other data set organization.  But you have to code more logic  
after 
each block is read in with the READ/CHECK macros.
 
>what's a program "to do" with what the user types.
I cannot understand the meaning of this phrase.

>Should it look  at the lrecl/blksize in the DCB and decide that
>this doesn't make  sense?  What if it did make sense - then what?
At the very least, your program must look at the data set  organization.  
"Then what" depends on what you want your program to do,  which I don't know.

>Or - is there a way to know this is a bunch of  bytes from a
>PDS directory... and this READ doesn't make sense?
Your program can know that this bunch of bytes is a PDS directory because  it 
is the first block in the input data of a PDS.  The end of the  directory is 
marked by an end of file record.  That will probably confuse  your program, 
too.  Then the first block of the first member begins  after the end of file 
record, unless the first member has been  deleted after the second member was 
added, in which case what you  will read next is what used to be the first 
member, which also ends with  another end of file record.  More confusion.
 
I would suggest a complete redesign of your program beginning with a  
thorough understand of what your program is supposed to accomplish, followed  
by 
research into the internals of a PDS.



Bill  Fairchild

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

Re: Reading Variable record with bad BDW/RDW?

[J R]

Use DYNALLOC Information Retrieval for the DSORG.



From: Thomas David Rivers <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reading Variable record with bad BDW/RDW?
Date: Mon, 24 Apr 2006 15:18:39 -0400

Hi John,

 Yeah... I know the directory portion isn't VB.  But, the program
 doesn't know that.. it "thinks" it's simply been given the name
 of a sequential VB file that it wants to process

 So - it stumbles blindly into the directory - and *whamo* - gets
 this "bad" data.

 So - I suppose - what's the best way to ask "Hey - is this at
 all a reasonable thing to be trying a VB-read on?"

- Thanks -
- Dave Rivers -


McKown, John wrote:



The directory of a PDS is not VB. It is
RECFM=F,LRECL=256,BLKSIZE=256,KEYLEN=8. You can ignore the key, if you
want. You must read all 256 bytes and "deblock" the "logical records"
yourself. They are not compatable with RECFM=VB, but they are "close".
"Close" only counts in horse shoes and nuclear weapons.

I have code, which I got from somewhere, that I can share. I also sure
that there is some available on http://cbttape.org somewhere, but I
don't know where.

--
John McKown
Senior Systems Programmer
HealthMarkets


--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


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

Re: Reading Variable record with bad BDW/RDW?

[Paul Gilmartin]

In a recent note, Thomas David Rivers said:

> Date: Mon, 24 Apr 2006 15:18:39 -0400
> 
>   So - I suppose - what's the best way to ask "Hey - is this at
>   all a reasonable thing to be trying a VB-read on?"
> 
My inclination would be to verify:

o DSORG != PO in the DCB after OPEN.  (But DON'T try to enforce
  DSORG == PS, because that is not set if DDNAME is allocated to
  a UNIX file.)

o BDW consistent with BLKSIZE, and no invalid flag bits set.

o RDW consistent with LRECL (and with BDW), and no invalid
  flag bits set.

(most of which QSAM does NOT verify)  If all tests pass, then
give the user what he asked for.  If any fail, indicate an
I/O error.

Now, suppose the user attempts to open for OUTPUT?  Wnat's a
good way to avoid trashing the PDS directory?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Reading Variable record with bad BDW/RDW?

[Richard Tsujimoto]

You could trying getting the FMT1DSCB for the data set and looking at the 
organization.




Thomas David Rivers <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
04/24/2006 03:18 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Reading Variable record with bad BDW/RDW?






Hi John,

  Yeah... I know the directory portion isn't VB.  But, the program
  doesn't know that.. it "thinks" it's simply been given the name
  of a sequential VB file that it wants to process

  So - it stumbles blindly into the directory - and *whamo* - gets
  this "bad" data.

  So - I suppose - what's the best way to ask "Hey - is this at
  all a reasonable thing to be trying a VB-read on?"

 - Thanks -
 - Dave Rivers -


McKown, John wrote:

> 
> The directory of a PDS is not VB. It is
> RECFM=F,LRECL=256,BLKSIZE=256,KEYLEN=8. You can ignore the key, if you
> want. You must read all 256 bytes and "deblock" the "logical records"
> yourself. They are not compatable with RECFM=VB, but they are "close".
> "Close" only counts in horse shoes and nuclear weapons.
> 
> I have code, which I got from somewhere, that I can share. I also sure
> that there is some available on http://cbttape.org somewhere, but I
> don't know where.
> 
> --
> John McKown
> Senior Systems Programmer
> HealthMarkets

-- 
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


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

Re: Reading Variable record with bad BDW/RDW?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thomas David Rivers
> Sent: Monday, April 24, 2006 2:19 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Reading Variable record with bad BDW/RDW?
> 
> 
> Hi John,
> 



>   So - I suppose - what's the best way to ask "Hey - is this at
>   all a reasonable thing to be trying a VB-read on?"

Ah. NO.

> 
>   - Thanks -
>   - Dave Rivers -

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

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

Re: Reading Variable record with bad BDW/RDW?

[Thomas David Rivers]

Hi John,

 Yeah... I know the directory portion isn't VB.  But, the program
 doesn't know that.. it "thinks" it's simply been given the name
 of a sequential VB file that it wants to process

 So - it stumbles blindly into the directory - and *whamo* - gets
 this "bad" data.

 So - I suppose - what's the best way to ask "Hey - is this at
 all a reasonable thing to be trying a VB-read on?"

- Thanks -
- Dave Rivers -


McKown, John wrote:



The directory of a PDS is not VB. It is
RECFM=F,LRECL=256,BLKSIZE=256,KEYLEN=8. You can ignore the key, if you
want. You must read all 256 bytes and "deblock" the "logical records"
yourself. They are not compatable with RECFM=VB, but they are "close".
"Close" only counts in horse shoes and nuclear weapons.

I have code, which I got from somewhere, that I can share. I also sure
that there is some available on http://cbttape.org somewhere, but I
don't know where.

--
John McKown
Senior Systems Programmer
HealthMarkets


--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Reading Variable record with bad BDW/RDW?

[Binyamin Dissen]

On Mon, 24 Apr 2006 14:40:51 -0400 Thomas David Rivers <[EMAIL PROTECTED]>
wrote:

:>I've got a question for the group-at-large, which I hope
:>will be obvious to someone deeply in-the-know.

:>I've got a program that opens a VB PDS (RECFM=VB,BLKSIZE=2550,LRECL=255).

:>But - note that I said it opens the PDS, not a member of the PDS.  That
:>open succeeds, and presumably, the program will merrily try to
:>read the PDS directory as Format-V records.

:>So - the first read succeeds, and it gets these bytes back for
:>the first 6:

:>  000E  
:>| BDW  | | RDW 

:>The BDW indicates a block-len of 14, but the 'reserved' bytes are not 00.
:>The RDW then indicates a record length of 65535 - which is preposterous
:>given that the BDW said the entire block-len was only 14.

:>And - of course, trying to read 65531 bytes for the remaining record
:>doesn't work, because they aren't there.  The 14 isn't there either.

:>OK - admittedly - walking thru the directory entries and trying
:>to interpret that as VB isn't the best thing in the world... but,
:>what's a program "to do" with what the user types.

:>Should it look at the lrecl/blksize in the DCB and decide that
:>this doesn't make sense?  What if it did make sense - then what?

:>Or - is there a way to know this is a bunch of bytes from a
:>PDS directory... and this READ doesn't make sense?

It is not clear what your question is.

Are you asking if there is a way to determine if a DD statement is pointing to
a PDS without a member name specified?

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Reading Variable record with bad BDW/RDW?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thomas David Rivers
> Sent: Monday, April 24, 2006 1:41 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Reading Variable record with bad BDW/RDW?
> 
> 
> I've got a question for the group-at-large, which I hope
> will be obvious to someone deeply in-the-know.
> 
> I've got a program that opens a VB PDS 
> (RECFM=VB,BLKSIZE=2550,LRECL=255).
> 
> But - note that I said it opens the PDS, not a member of the 
> PDS.  That
> open succeeds, and presumably, the program will merrily try to
> read the PDS directory as Format-V records.
> 
> So - the first read succeeds, and it gets these bytes back for
> the first 6:
> 
>   000E  
> | BDW  | | RDW 
> 
> The BDW indicates a block-len of 14, but the 'reserved' bytes 
> are not 00.
> The RDW then indicates a record length of 65535 - which is 
> preposterous
> given that the BDW said the entire block-len was only 14.
> 
> And - of course, trying to read 65531 bytes for the remaining record
> doesn't work, because they aren't there.  The 14 isn't there either.
> 
> OK - admittedly - walking thru the directory entries and trying
> to interpret that as VB isn't the best thing in the world... but,
> what's a program "to do" with what the user types.
> 
> Should it look at the lrecl/blksize in the DCB and decide that
> this doesn't make sense?  What if it did make sense - then what?
> 
> Or - is there a way to know this is a bunch of bytes from a
> PDS directory... and this READ doesn't make sense?
> 
>   - Many thanks! -
>   - Dave Rivers -

The directory of a PDS is not VB. It is
RECFM=F,LRECL=256,BLKSIZE=256,KEYLEN=8. You can ignore the key, if you
want. You must read all 256 bytes and "deblock" the "logical records"
yourself. They are not compatable with RECFM=VB, but they are "close".
"Close" only counts in horse shoes and nuclear weapons.

I have code, which I got from somewhere, that I can share. I also sure
that there is some available on http://cbttape.org somewhere, but I
don't know where.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

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

Reading Variable record with bad BDW/RDW?

[Thomas David Rivers]

I've got a question for the group-at-large, which I hope
will be obvious to someone deeply in-the-know.

I've got a program that opens a VB PDS (RECFM=VB,BLKSIZE=2550,LRECL=255).

But - note that I said it opens the PDS, not a member of the PDS.  That
open succeeds, and presumably, the program will merrily try to
read the PDS directory as Format-V records.

So - the first read succeeds, and it gets these bytes back for
the first 6:

000E  
| BDW  | | RDW 

The BDW indicates a block-len of 14, but the 'reserved' bytes are not 00.
The RDW then indicates a record length of 65535 - which is preposterous
given that the BDW said the entire block-len was only 14.

And - of course, trying to read 65531 bytes for the remaining record
doesn't work, because they aren't there.  The 14 isn't there either.

OK - admittedly - walking thru the directory entries and trying
to interpret that as VB isn't the best thing in the world... but,
what's a program "to do" with what the user types.

Should it look at the lrecl/blksize in the DCB and decide that
this doesn't make sense?  What if it did make sense - then what?

Or - is there a way to know this is a bunch of bytes from a
PDS directory... and this READ doesn't make sense?

- Many thanks! -
- Dave Rivers -

--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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