BDAM files

[Sudershan Ravi]

Why BDAM files are infrequently used? what are the complexities we face when we do Direct Access of a file.

Thanks,
Sudershan.

[Ed Jaffe]

On 11/27/2017 10:48 AM, Sudershan Ravi wrote:
> Why BDAM files are infrequently used? what are the complexities we face when we do Direct Access of a file.

Before 3390s, disk geometry used to change every few years. That caused
a lot of folks to switch to VSAM.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Seymour J Metz]

VSAM ESDS has a lot of advantages, and BSAM is as efficient as BDAM in many cases.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Sudershan Ravi <suders...@GMAIL.COM>
Sent: Monday, November 27, 2017 1:48 PM
To: ASSEMBL...@listserv.uga.edu
Subject: BDAM files

[Charles Mills]

In the old days, "efficiency" was considered paramount. There was a lot of "roll your own": BDAM, EXCP, that sort of thing.

More recently, functionality and maintainability have become more important to many, and so VSAM and even DB2 are more preferred solutions to the problems that used to be solved with BDAM.

Charles

[John McKown]

On Mon, Nov 27, 2017 at 12:48 PM, Sudershan Ravi <suders...@gmail.com>
wrote:

> Why BDAM files are infrequently used? what are the complexities we face
> when we do Direct Access of a file.
>

​Off hand, I'd say that we don't use BDAM because 99% of what you can do
with BDAM, you can do with an appropriate VSAM ​variant (KSDS, ESDS, RRN,
VRRN). Enterprise COBOL does not support BDAM. BDAM is a "traditional"
access method, like BSAM. So it cannot be _easily_ used by
AMODE(31),RMODE(31) programs. However, VSAM is ACB based and can be easily
used by AMODE(31),RMODE(31) programs. BDAM is a _basic_ access method, like
BSAM. Which means that I/O is somewhat more difficult. In particular all
I/O is asynchronous, so you _must_ do a CHECK macro to wait on I/O to
complete. As opposed to something like QSAM where it is done for you.
Again, VSAM is superior since you can do either synchronous or asynchronous
I/O as you desire.



>
> Thanks,
> Sudershan.
>



--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

[Gary Weinhold]

We have used BDAM datasets accessed by block number as well as VSAM RRDS
datasets in a software product.  They are equivalent and the advantages
of VSAM have been mentioned. However, although performance is not
usually a critical factor, it is only in the CICS environment that we
have seen a significant difference between using the two access
methods.  CICS did not allow an existing VSAM record to be written
without a preceding read. Since CICS does allow this it for BDAM, our
I/O for writing a block is more efficient in BDAM.

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone +1.613.523.5500 x216
Email: wein...@dkl.com

Visit us online at www.DKL.com

E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

[Ed Jaffe]

On 11/27/2017 11:22 AM, John McKown wrote:
> ​BDAM is a "traditional" access method, like BSAM. So it cannot be _easily_ used by
> AMODE(31),RMODE(31) programs.

Whaaaat?! AMODE(31) callers were supported by the very, very first
release of DFSMS!

Gosh I can't remember how many decades ago that was, but it's been a
long, long time...

[John McKown]

On Mon, Nov 27, 2017 at 1:42 PM, Ed Jaffe <edj...@phoenixsoftware.com>
wrote:

> On 11/27/2017 11:22 AM, John McKown wrote:
>
>> ​BDAM is a "traditional" access method, like BSAM. So it cannot be
>> _easily_ used by
>> AMODE(31),RMODE(31) programs.
>>
>
> Whaaaat?! AMODE(31) callers were supported by the very, very first release
> of DFSMS!
>

​Well, I don't do much basic I/O, so maybe I'm confused. But doesn't an
AMODE(31) program require more work than AMODE(24) or maybe I'm thinking
RMODE(31)? Or is that just for QSAM program (DCBE and so forth)?​

> Gosh I can't remember how many decades ago that was, but it's been a long,
> long time...
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>

[Ed Jaffe]

On 11/27/2017 11:52 AM, John McKown wrote:
>
> ​Well, I don't do much basic I/O, so maybe I'm confused. But doesn't an
> AMODE(31) program require more work than AMODE(24) or maybe I'm thinking
> RMODE(31)? Or is that just for QSAM program (DCBE and so forth)?​

Back in the day, you had to be in 24-bit mode to call the services, so
everyone had to write so-called "glue" routines.

The only restriction these days I can think of is that the DCB must
reside below 16MB (virtual). That's because the DCB pointer in the DEB
is only three bytes long.

[Paul Gilmartin]

On 2017-11-27, at 12:42:56, Ed Jaffe wrote:

> On 11/27/2017 11:22 AM, John McKown wrote:
>> ​BDAM is a "traditional" access method, like BSAM. So it cannot be _easily_ used by
>> AMODE(31),RMODE(31) programs.
>
> Whaaaat?! AMODE(31) callers were supported by the very, very first release of DFSMS!
>
> Gosh I can't remember how many decades ago that was, but it's been a long, long time...
>

Can all the data areas; DCB, exits, DECB, IOB, Buffers, ... reside above the line?

How much recoding of a 370 program is needed to support this?

In days of yore, when I was trying to support both 370 and XA, I found it
simplest to keep all the I/O stuff below the line and call a 31-bit interface
interface routine which set AMODE 24 and branched to 24-bit code.

-- gil

[Seymour J Metz]

No, but much of them can with a proper DCBE.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Gilmartin <00000014e0e4a59...@listserv.uga.edu>
Sent: Monday, November 27, 2017 3:02 PM
To: ASSEMBL...@listserv.uga.edu
Subject: Re: BDAM files

[Gary Weinhold]

All our code is 31-bit; we acquire 24-bit storage to hold control blocks
that have to be below the line (3-byte addresses).

[Charles Mills]

You've got to do a little bit more hoop-jumping for AMODE(31) -- separate storage for the DCBs, and remembering the extra parameters on the various macros. Not prohibitive, but a little more to remember, and a few more possibilities for gotchas.

I have not mentioned this in a while, but I wrote a paper on converting an xMODE(24) xSAM program to xMODE(31). If anyone wants a copy, just write me off-line. Not a sales pitch for anything; no salesman will call.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe
Sent: Monday, November 27, 2017 11:59 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: BDAM files

[Paul Gilmartin]

On 2017-11-27, at 14:09:56, Charles Mills wrote:

> You've got to do a little bit more hoop-jumping for AMODE(31) -- separate storage for the DCBs, and remembering the extra parameters on the various macros. Not prohibitive, but a little more to remember, and a few more possibilities for gotchas.
>

Wouldn't it be great if a single SET symbol setting could condition all the
system macros to generate 24/31/64 bit expansions?

Better if 24-bit just went away and never came back. And the horse
it rode in on.

> I have not mentioned this in a while, but I wrote a paper on converting an xMODE(24) xSAM program to xMODE(31). If anyone wants a copy, just write me off-line. Not a sales pitch for anything; no salesman will call.

-- gil

[Charles Mills]

It would be awesome if 24-bit would just go away. But are you volunteering
to convert all those 24-bit programs? (Do they really exist? Heck, there's a
current thread on IBM-MAIN about compatibility with OS/390 1.5.")

IBM has made the philosophical decision that slavish upward compatibility is
non-negotiable, except when that principle conflicts with the principle of
integrity. I think IBM over-learned the lesson of the "Future System"
(https://en.wikipedia.org/wiki/IBM_Future_Systems_project#Project_end, last
paragraph of section) but that is just IMHO.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, November 27, 2017 4:19 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: BDAM files

[Seymour J Metz]

It would help if they had ACB support for BSAM, BPAM and QSAM.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Gilmartin <00000014e0e4a59...@listserv.uga.edu>

Sent: Monday, November 27, 2017 7:18 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: BDAM files

[Roger Bolan]

Do they really exist? Yes (sort of). In about 1990 we converted a big
application program from 24-bit to 31-bit. Basically we just divided our
load modules into two halves. One part ran below the 16M line to do all
the 24-bit I/O code and the rest was 31-bit AMODE(31), RMODE(ANY).
That code is still running fine today on z/OS 2.3. I'm sure we'd have
more options today, but that worked in 1990.