If you do not understand these things then writing a program with BSAM and/or RECFM=[something clever other than how the dataset was actually written] is not the way to do things -- except perhaps utterly as a learning exercise, not directly justified by an actual business requirement.
If you want to see what is actually on the disk there are utilities that will show you that. I would guess IDCAMS DUMP with RECFM=U would be a good start, although I do not recall that I have ever actually done that, so I might be missing something. People have also suggested CBT tools IIRC. Even if you want to write a BSAM program for your own education or amusement, I would start with an existing dump utility so you can see what you will read with BSAM. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, July 19, 2016 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records One more time: if it is on the disk then RECFM=U will "reveal" it. What you got on disk is what you will get with READ. The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: Tuesday, July 19, 2016 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
