Talk:Direct-access storage device

Really ought to create a 'data cells' page that should in turn link to Early_IBM_disk_storage#IBM_2321 instead of that link being in the See Also of this page. Cpeel (talk) 21:33, 19 May 2008 (UTC)

Indexed vs random

There is no "random" access method, and indexed isn't the same as random in any case. This omits partitioned, which is a special case. Peter Flass (talk) 19:38, 24 February 2012 (UTC)

Seems to me that random access is similar to what IBM usually calls direct access. Gah4 (talk) 04:30, 14 September 2017 (UTC)

New Lead

I hated this definition "any secondary storage device which has relatively high access time relative to its capacity." If nothing else it should be fast access time. I'm changing it to paraphrase the IBM manual. Peter Flass (talk) 13:36, 23 December 2013 (UTC)

I think the paraphrase is almost as bad. "Direct" was coined by IBM to distinguish between "Random" as in core and "Sequential" as in tape; slower than core but faster than tape. The current paraphrase misses the speed point and I suspect is a way after the fact attempt to define without much knowledge of history. I'll look for a better source. Tom94022 (talk) 06:34, 14 September 2017 (UTC)

The access methods are responsible for blocking and deblocking logical records as they are written to or read from external media.

The access methods are responsible for blocking and deblocking logical records as they are written to or read from external media. I thought that for BSAM, the user program does deblocking, while QSAM does it for you. Gah4 (talk) 04:32, 14 September 2017 (UTC)

生朱失失吴矢庆朱余朱矢失辰天吴生矢汪矢矢丿矢生矢生尘矢歹矢失矢生生矢矢生生仕上上令至尖女生矢天兰弓点定斗矢仗止 — Preceding unsigned comment added by 218.189.204.101 (talk) 05:58, 29 November 2018 (UTC)

I was about to write this, but I see that I already did. Gah4 (talk) 02:15, 30 April 2020 (UTC)

Acronym

If I remember my days with IBM jargon correctly, DASD would be "detachable asynchronous storage device".

Detachable, because it was a separate cabinet, and asynchronous, because it was NOT sync'd to the processor clock for operation. 134.247.251.245 (talk) 13:50, 22 October 2019 (UTC)

The drives that IBM made for many years are described as synchronous, not because they use the same clock, but because there is minimal buffering between the bits on disk and in memory. For many, it is one or two bytes of buffering. Later on, controllers could buffer a whole disk block, as memory became cheaper. Gah4 (talk) 19:10, 22 October 2019 (UTC)

Never heard that definition, and FWIW there were IBM DASD in the same cabinets of many small IBM systems. As I understand it they started with Random Access as in RAMAC but ran into a trademark issues so went to direct access to distinguish with sequential and truly random access. 00:14, 23 October 2019 (UTC)

Well, now you make it complicated. On the small systems, the same hardware is shared between CPU and channel operation. When reading, the bits are clocked by the bits coming off the disk on all systems. For writing, they might use the same clock as the CPU, but often not. But data moves slow enough that it is retimed for each transition (usually byte) between disk and memory. Memory systems were asynchronous in internal operation up until SDRAM. (Often relying on delay devices.) But as above, IBM called disk data transfer as synchronous, being retimed byte by byte. Controllers with internal buffers result in data transfers to/from disk being asynchronous to transfers from/to main memory. Gah4 (talk) 00:45, 23 October 2019 (UTC)

Address

"in which "each physical record has a discrete location and a unique address". This is certainly not true with modern storage subsystems with deduplication built-in, because there files can share identical blocks of data with other versions of the same file, or even with completely different files where duplicate blocks were found to exist. Storage subsystems keep their own records, and copying a file simply creates a new pointer to the same data. Only when the "new" file gets changed, some blocks are newly assigned, containing those changes, and become part of the second file, but not of the first one. The computer normally has no access to the file structure in a storage subsystem, so all of this is unnoticed by the computer. 134.247.251.245 (talk) 14:43, 22 October 2019 (UTC)

I am not sure about de-duplication, but at the lowest level disk blocks normally have a unique address. At the file system level, it might be that more than one file uses those blocks. Unix uses inodes, where more than one directory entry might link to the same inode, which Unix calls hard links. For flash drives, wear leveling moves blocks around such that repeatedly writing the same block at the file system level doesn't wear out the actual hardware block. Flash memory has limits on how many times each byte can be rewritten. Gah4 (talk) 19:16, 22 October 2019 (UTC)

I suggest the term DASD is applied uniquely to IBM mainframe systems wherein the quoted statement is true at the IBM OS level. It was physically true into this century. Maybe we can clarify the semantics to make this clear. Tom94022 (talk) 00:10, 23 October 2019 (UTC)

IBM DID use the term DASD on small systems, too, I remember the OS/2 device driver being named OS2DASD.DMD.134.247.251.245 (talk) 07:40, 23 October 2019 (UTC)

Maybe, but perhaps the driver is for some sort of mainframe connectivity or emulation in which case the statement might remain true? Or maybe it was just a singular error and not sufficient to redefine the term? As the HDD article suggests DASD is an infrequently used term. Tom94022 (talk) 21:01, 23 October 2019 (UTC)

No, it's the regular disk management driver on every OS/2 (both hard disk and removable media).134.247.251.245 (talk) 12:28, 24 October 2019 (UTC)

Software

The article as written is oriented to OS/360 and successors and to DOS/360 and successors. The material on software should either be extended to cover, e.g., CMS, Linux on IBM Z, or removed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:10, 2 May 2021 (UTC)

This was supposed to go here, not in the article

And often enough the term is disk. Well, disk drive goes back to the days of mountable disk packs, where the storage was separate from the source of rotational power. In the earliest days of personal computers, including IBM, floppy disks and floppy disk drives were what people got to know. In any case, I suspect that disk is now the generic synonym for any non-sequential access storage device, and more specifically flash memory based devices. It might even be the WP:COMMONNAME by now. Gah4 (talk) 00:21, 14 May 2021 (UTC)

In addition, regarding a comment somewhere else, it looks like the RAMAC 350 is a disk storage unit, and not a disk drive. I am suspecting that the drive term came in with mountable disks, yet is now commonly used for non-dismountable devices. Gah4 (talk) 01:01, 14 May 2021 (UTC)

IBM used Storage for the 1301 disk and the 7320 drum. IBM used File Control for the 7631, which attached both DASD and the 7340 hypertape drive. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:22, 14 May 2021 (UTC)

I was wondering about the name of SSD, which is either solid-state disk or solid-state drive, even though there is no disk, and nothing that is driven. The description of the 1301 doesn't say removable. It does seem that, just as IBM uses DASD, they don't tend to call them drives, but ordinary people needed a way to separate disk from the thing disks mount on. It seems, overall, that people aren't so consistent in naming as one might hope. Gah4 (talk) 06:09, 14 May 2021 (UTC)

No, the 1301 was not removable. Had IBM done a drive with mountable disk packs each containing 25 24" disks, finding operators strong enough to change packs would have been a challenge. On the bright side, that's only half as many as the 355 had ;-)

BTW, does any museum have one of those puppies in operation? Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:43, 14 May 2021 (UTC)

The Computer History Museum does have a partial RAMAC 350 sometimes operating. It is in many ways it is similar to the 1301, the major difference being one head per surface. Tom94022 (talk) 19:31, 14 May 2021 (UTC)

For a pretty accurate list of the historical names of some IBM storage devices and subsystems you might look at IBM's Storage product profiles. It does indicate that "disk storage drive" may have first occurred in IBM's vernacular with the 1311. "Disk drive" meets the criter1a for a common name as do it's subsets such as "floppy disk drive"; "disk" is probably too broad. DASD is now only used in IBM OSs to refer to a limited set of IBM magnetic disk drive types that are emulated by attached storage subsystems using HDDs and SSDs; somehow that has to be worked into this article with out it being OR. Tom94022 (talk) 19:31, 14 May 2021 (UTC)

The Computer History Museum does have a partial RAMAC 350

Does it also have a 1301 or 1302?

It is in many ways it is similar to the 1301,

Well, I started on the 355 and the 1301 looked radically different to me, both mechanically and architecturally. For one thing, the 355 could only read and write full tracks, while the 1301 had variable length blocks under the control of a format track; all tracks in a cylinder had the same format.

Well the 355 is not a 350 - but they and the 1301 have the same stack of disks, spindle, spindle motor and use hydraulic actuation but the 1301 had a head per surface and two independent hydraulic actuators. Basically the 1301 was derived from the 350 by many of the same people at IBM SJ. The cabinets were very similar and from a distance it might be hard to tell the difference. If you would like to learn more you might read IBM 350 Disk Storage and IBM 1301 - unsigned comment

No, they don't have the same stack. Each module of the 1301 had 25 platters and one actuator. The 1301 Model 1 only had one module, giving it half the number of platter compared to the 350 and 355, and only one actuator. OTOH, the 1302 had two actuators per module, one for inner cylinder and one for outer cylinders. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:10, 16 May 2021 (UTC)

To be precise the 1301 Model 2 and the 1302 Model 2 have two actuators, one on top of the other, while the 1301 Model 1 and 1302 Model 2 have one actuator, see literature at Bitsavers - 1301. The two actuator models have a full stack of disks not unlike the stack in the RAMAC. I've never seen a one actuator 130x nor a picture of one so I can't be sure whether these one actuator devices have a full stack of disks or a short stack. Regardless, the stack was derived from the RAMAC and it may be a short stack in the one actuator 130x's. Tom94022 (talk) 17:38, 16 May 2021 (UTC)

In http://www.bitsavers.org/pdf/ibm/dasd/1301/, the obvious place to look is the reference manual, where there is a table clearly showing that the 1301-1 has only one actuator with 25 platters, the 1301-2 has two actuators with 50 platters, the 1302-1 has two actuators with 25 platters and the 1302-2 has 4 actuators with 50 platters. The only 1 actuator device among those 4 is the 1301-1. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:39, 16 May 2021 (UTC)

Actually an FEMM is a better place to look since that is where the actual physical construction can be disclosed as opposed to the logical view of a reference manual. 1301 Disk Storage FEMM indicates that all four models (-11, 12, 21, 22) of the 1301 have 50 disks (see Section 2.6 Disk Array beginning p13/93 and especially the note at the bottom of p20/93). We don't have the early model FEMM available but it is likely this area is unchanged. Also the distinction between access mechanism (logical) and actuator (physical) is unclear. You may be right that some models of the 1301 were shipped with a short stack of disks; however I have never seen an image of such a short stack device and at least this FEMM seems to indicate all those models had a full stack regardless of the number of access mechanisms and/or actuators. Tom94022 (talk) 20:56, 16 May 2021 (UTC)

Actually, I tried the FEMM manual first but it seemed to concentrate on procedures and I didn't see any obvious entry in the table of contents. Looking at it I see that it doesn't mention the model 1 or 2 at all, only 11, 12, 21 and 22. So far I haven't found any descriptions of those models. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:51, 16 May 2021 (UTC)

FWIW the Models 11 thru 22 are appear to be those used on at least the 1440 see: 1440 Bibliography p4/32 and 11/32. Auerbach 1969 indicates they are also used on the 1401 1301 and 1460. It seems these models all had 50 disks. Tom94022 (talk) 23:39, 16 May 2021 (UTC)

Did you mean also used on the 1401 and 1460 or did you mean also used on the 1460?

One of the 1460 manuals explains that model 11 is a single module master, 12 is a two module master, 21 is a one module additional unit and 22 is a two module additional unit. Head of string comes to mind. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:52, 17 May 2021 (UTC)

So do you agree that at least these models of the 1301 all have only 50 disks? Tom94022 (talk) 01:30, 17 May 2021 (UTC)

I agree that none of them have more than 50 disks. I don't agree that the models 1, 11 and 21 have more than 25 disks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:31, 17 May 2021 (UTC)

You do agree that there is nothing in the FEMM for the -11 and -21 that indicates less than 50 disk don't you? For example, all the images show a full size spindle and there is no indication in the images or text of a spacer that would be required if there were less than 50 disks. Tom94022 (talk) 18:40, 17 May 2021 (UTC)

Of course not. None of the pictures is labelled as a model 1, 11 or 21, and there is absolutely no reason to assume that those models have twice as many platters as they actually use. Absent evidence to the contrary, single module really means single model.Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:28, 17 May 2021 (UTC)

For a pretty accurate list of the historical names of some IBM storage devices and subsystems you might look at IBM's Storage product profiles.

The list is incomplete. Off the top of my head it's missing

• IBM 353: Disk drive (7030 Stretch)
• IBM 727: Magnetic Tape Reader/Recorder (650, 701, 702, 704, 705, 709)
• IBM 729: Magnetic tape drive models 1 and 3 (705); other models, 14xx and 70xx
• IBM 731: Magnetic Drum Reader/Recorder (701)
• IBM 732: Magnetic Drum Storage Unit (702)
• IBM 733: Magnetic Drum (704, 709)
• IBM 734: Magnetic Drum Storage (705)
• IBM 7300: Disk Storage (7070)
• IBM 7303: Disk Storage (7030 Stretch)
• IBM 7320: Drum Storage (7090, 7094)

Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:53, 14 May 2021 (UTC)

Thank you for adding some more accurate IBM storage device names. The combined list is still far from complete is interesting to notice the very limited use of DASD in the names of these devices. Tom94022 (talk) 22:10, 14 May 2021 (UTC)

There's a reason that I wrote Off the top of my head. The list is missing a lot of low performance tape drives, but as far as I recall the only other missing mainframe DASD prior to the 3390 is the 3375, unless you count devices internal to other units, e.g., cartridge drive in 2044, floppy drive in 2835.

That's the same reason I wrote "historical names of some ..." BTW off the top of my head, some other IBM mainframe DASD missing from the list include the 2312, 2313, 2318 and 3344 which AFAIK were all "disk storage" devices. Any of the above missing from List_of_IBM_products#Direct-access_storage_devices should be added using the actual IBM names for these devices - many or the names in that list are not IBM's. Tom94022 (talk) 17:38, 16 May 2021 (UTC)

3344 is a good catch. I would consider all of the repackaged 2314s to be 2314, and if I listed them I would make them subheadings under 2314, just as I would lump 3330 and 3333 together. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:39, 16 May 2021 (UTC)

Notes

References

Update to terminology section

The current terminology section ends with the following somewhat inaccurate sentence:

Both drums and data cells have disappeared as products, so DASD remains as a synonym of disk, flash and optical devices. Modern DASD used in mainframes only very rarely consist of single disk-drives. Most commonly "DASD" means large disk arrays utilizing RAID schemes. Current devices emulate CKD on FBA hardware

I suggest replacing it with something along the lines of:

Today IBM uses the term DASD as a synonym for disk, flash and optical storage but no longer markets any device explicitly as a direct access storage device. In certain of its operating systems IBM uses the term DASD to define a limited set of virtual devices (e.g., 3380, 3390 and 9340) that are then emulated in storage systems using disk and flash devices.

I am pretty sure I can find reliable sources for all of the above but I thought I would put it here for comment first. Comments? Suggested improvements? Tom94022 (talk) 17:55, 16 May 2021 (UTC)

The original is more accurate. I've seen IBM referring to Direct Access Storage Facility when describing individual IBM products, but I've only seen Direct Access Storage Device when referring to multiple device types. IBM marketing has used specific terms for specific devices. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:39, 16 May 2021 (UTC)

I agree that IBM infrequently used the phrase "direct access storage" in a device name but almost always used it in conjunction with the device product description manual for the device and/or in the hardware service for consultants manuals for the device listing. For example, in the 1979 IBM Service for Consultants Manual DP Hardware, the 3340 is the "IBM 3340 Direct Access Storage Facility" and its description describes all three models as having "disk storage drives" whereas the 3344 is the "IBM 3344 Direct Access Storage" The problem is I can find no such conjunction with any modern device - even the OS's do not link DASD to a modern device, all the IBM OS's that I look at link DASD to an emulated device such as the 3390 that is emulated by a storage system. A system is not a device; DASD has device in its name. The systems providing emulation state they use HDDs and SDDs, not DASDs

Usage in modern mainframes

You state the original is more accurate, so given:

Modern DASD used in mainframes only very rarely consist of single disk-drives

@Chatul:Would you please identify any such modern IBM mainframes using "single disk-drives"?

As I told you before, the AIX documentation still refers to floppy disk drives as DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 20 May 2021 (UTC)

OK, AIX is a mainframe OS and not a mainframe. Do any of the IBM mainframes actually have a FDD any more? Tom94022 (talk) 17:48, 20 May 2021 (UTC)

I have no idea what the P systems typically have, but AIX is the normal OS for those systems, and the OS is where there is a need for an umbrella term, so the OS documentation is relevant. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:40, 20 May 2021 (UTC)

Usage in large disk arrays

You state the original is more accurate, so given:

Most commonly "DASD" means large disk arrays ...

@Chatul:Would you please identify any large disk arrays that are called a device or a DASD?

Giving a fragment out of context conveys something quite different from what I actually wrote. Quote the two versions here if you want an honest discussion. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 20 May 2021 (UTC)

You didn't write the phrase, you just asserted the original paragraph is "more accurate" so I really don't see a lack of context I suppose leaving off RAID adds JBODs, so here is complete sentence and do you still assert it is more accurate:

Most commonly "DASD" means large disk arrays utilizing RAID schemes

@Chatul:Would you please identify any large disk arrays that are called a DASD by their manufacturers? Tom94022 (talk) 18:00, 20 May 2021 (UTC)

How is it relevant who wrote the paragraph? What is so difficult about quoting the entire text in dispute instead of cherry picking? And what is RAMAC if not a disk array? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:40, 20 May 2021 (UTC)

Should DASD be limited to CKD devices on mainframes

When DASD was first used it applied only to CKD devices on mainframes. It does not ever appear to have been used on IBM's small systems other than System 3 but those devices were devices formatted as CKD with KL=0 and DL=256. As far as the rest of the small systems goes I went thru the following manuals using word search, and reading table of contents, indices, glossaries and in some cases sections looking for DASD or "direct access" with the following results:

• System 32 Intro, May 1975, neither DASD nor "direct access", "magnetic disk same as disk"
• Systerm 34 Introduction, Mar 1978, neither DASD nor "direct access", "Every System/34 has either one or two disk storage devices housed within the 5340 System Unit. "
• System 36 Reference Manual, Oct 86, neither DASD nor "direct access", "disk drive. Themechanism used to read and write information on disk."
• System 38 Introduction, Oct 78, neither DASD nor "direct access", "In this way, the System/38 physical file is similar to disk files on previous systems. A physical file contains fixed-length records, all of which have the same format."
• System 7 Summary, Sep 71, neither DASD nor "direct access", "5022 Disk storage module" contains "magnetic disks" See also announcement press release.
• System 23 Using your 5247 disk, Apr 82, neither DASD nor "direct access", The word "disk" appears 837 times.

As near as I can tell z/OS only supports at most 7 emulated CKD DASDs and perhaps as low as 3 such emulated CKD devices (3380. 3390 and 9340). IBM past OS's did support other CKD DASD starting with the 2302, 2311, 2321 & 7320 but only a very limited number. One of the tricks the PCMs used to get IBM OSs to support a device that IBM never made was to redefine the characteristics an unused DASD type in a specific OS embodiment, as for example to attach a double density 3350.

Note that with the introduction of FBA devices they were also referred to as providing "direct access" but that seems to have dropped at least in so far as z/OS which seems to distinguish between DASD as CKD devices to be emulated and distinct from FBA devices as follows:

Defining a special FBA device (FBA)

HCD defines both the operating system configuration and the processor hardware configuration for a system. Defining a special FBA device (FBA)

You can use a new type of disk devices, known as Fixed Block Architecture (FBA) or Fixed Block (FB) devices. Devices of this type may be considered as a data bridge between z/OS systems and Linux, UNIX®, and Windows® operating systems.

...

— z/OS 2.4.0 HCD (Hardware Configuration Definition)

I haven't looked into AIX or IBM's flavor of Linux but I suspect the term will only be used in the context of CKD and only as emulating a CKD device. And I am pretty sure IBM PC DOS used the terms like fixed disk, disk and/or block device to the exclusion of DASD or direct access.

It maybe best for purposes of this article that DASD is a IBM mainframe software construct only and currently limited to three emulated devices in z/OS and historically limited to those device types that could be specified as DASD in IBM's mainframe OSs. Alternatively we might distinguish between the use of DASD in IBM's mainframe OS products and "direct access storage device" in IBM's hardware products, afterall IBM has indeed separated software and machine products. Tom94022 (talk) 19:58, 19 May 2021 (UTC)

AIX uses the term DASD for floppy disks. VM does not restrict the term to CKD. Both Adaptec and IBM used the term DASD for direct-access devices on PC's. When you're looking for the use of generic terms, it's pointless to only look at manuals describing only one device; the best place to look is in manuals referring to multiple device types, which is why software manuals are more relevant than hardware manuals. However, even in hardware manuals for DASD arrays IBM has used the term DASD, e.g., "RAMAC 3 DASD provides up to 128 volumes in a storage frame (rack)." Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:06, 20 May 2021 (UTC)

And when I do look at software manuals, as for example in z/OS "Summary of Device Information", I find only the following "Direct Access Devices (DASD)" "Device Types" listed: 9345, 3390, 3395 (a 3390 variant) & 3380. The fact that these "Device Types" are emulated in a storage system by HDDs or SSDs does not make their common name DASD.

@Tom94022: Is 3395 a typo for 9395? I can't find it in the IBM search page. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:05, 23 May 2021 (UTC)

@Chatul:See z/OS v2.3.0 Summary of Device Infromation, Table 1. If we are going to use OS documentation as opposed to machine documentation then should the definition of "device" be that of the OSs so that in this instance these are the DASD devices supported by z/OS? They are all CKD DASD as opposed to FBA DASD aren't they?Tom94022 (talk) 20:09, 23 May 2021 (UTC)

As previously mentioned, z/OS now supports FBA, in a limited fashion. IBM’s OTHER OS, VM, has always supported FBA dasd along with CKD, albeit the CKD is formatted with fixed length blocks. This thread is getting a bit long, and I’m not sure we’re going to come to a definitive conclusion. For my part I’l like to see this article focused on mainframe devices, and leave out AIX, PC, and OEM devices, but that’s just me. In general I’m reasonably happy with the way the article is structured now. Peter Flass (talk) 21:16, 23 May 2021 (UTC)

Early CMS uses 800 byte blocks. At least back to the CMS used in the first VM/PC, CMS allowed FB-512, as that mapped well onto PC/XT drives. I believe, though, that it was implemented for all CMS by then, and commonly used on mainframe systems CKD drives, too. I thought that many AIX machines are big enough to qualify as mainframes, though not all of them. But I agree not PC or OEM devices, even OEM devices emulating IBM devices. Gah4 (talk) 23:57, 23 May 2021 (UTC)

I believe that CP-67/CMS used a different block size and that 800 came in with VM. VM supported CMS minidisks on 3310 and 3370 well before VM/PC. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:08, 24 May 2021 (UTC)

While all this may be true about CMS and CP-67 the devices were CKD DASD using CKD CCWs weren't they? FBA devices use FBA CCWs which weren't introduced until 1979 - correct? Does formatting a CKD device with KL=0 and a fixed sized RL make it an FBA device - I don't think so. The more I think about it, at least for mainframes, the type DASD is defined by the CCWs used. Tom94022 (talk) 20:27, 24 May 2021 (UTC)

All the DASD supported by CMS prior to the 3310 and 3370 were CKD. The 3310 and 3370 used Define Extent and Locate commands similar to those used in ECKD, and also had commands unique to FBA. A CKD device formatted with KL=0 and fixed DL is still CKD and cannot be read with FBA commands, only CKD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:47, 24 May 2021 (UTC)

CP could emulate FBA channel commands on CKD disks, or the other way around for appropriately sized blocks. I have no idea if any version does that. But again it is back to the physical vs. logical question. CMS wants logical (or virtual physical) blocks, which the hardware, or emulated hardware, has to provide. Both are useful to know about. Gah4 (talk) 00:50, 25 May 2021 (UTC)

AIX apparently does use DASD but it also supports SCSI devices including HDDs. Do you have a reference for IBM's usage of DASD in PC DOS? Same question for Adaptec?

Apparently both IBM, Adaptec and some third party software driver suppliers used DASD to refer to some devices in some OS/2 drivers, again application in software not in hardware. Again it is not clear that referring to an HDD in software as a DASD makes it the common name for HDDs. Tom94022 (talk) 19:26, 20 May 2021 (UTC)

DASD is not the common name for any specific device type, it is an umbrella term, as you well know. The z/OS documentation only lists specific types of DASD because that is all that it currently supports. It would be pointless to list, e.g., 2311.

As I've repeatedly stated, there is no need for a manual devoted to one device to use all of the umbrella terms that might be needed in a different context. Do you expect an automobile maintenance manual to use the term vehicle? The software manuals are precisely where an umbrella term is needed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:40, 20 May 2021 (UTC)

I suggest the problem is in the meaning of device as a part of the phrase "Direct Access Storage Device (DASD)." I do agree that IBM has been inconsistent in applying DASD to hardware ("machines" in IBM vernacular) as in your example, the RAMAC 3 is a system and not a device just as the 3850 is a "Mass Storage System" and not a device, both provide direct access storage to IBM systems. It seems there are lots of different in application of the term but its current usages seems to be limited to some IBM OS's. If so, that's how this article should be structured. Tom94022 (talk) 17:43, 20 May 2021

How is a system in a single box not in a device? For that matter, is the 3081 not a device? It contains multiple boxes.

Using IBM's nomenclature the 3081 it is a Processor Complex or a Processor Unit. Do you seriously contend the 3081 is a device in anyone's terminology?

The article is restricted to IBM products. How is IBM's nomenclature not relevant? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:40, 20 May 2021 (UTC)

IBM's nomenclature is relevant but it usage is inconsistent between machine products and software products and has changed over time. Today various IBM storage systems emulate specific direct access storage devices - IBM's current storage systems are not described as direct access storage or DASD in any of IBM's machine literature which should be relevant in this article. Some current IBM OSs enumerate specific DASD type numbers to be emulated, at one time were for the most part manufactured by IBM but all such type numbers have been withdrawn. The fact that these storage systems can emulate DASD does not make them DASD. Tom94022 (talk) 23:26, 20 May 2021 (UTC)

The convenience of DASD is that it describes what it looks like to the user or OS, independent of the physical realization. As far as emulation, if IBM makes it and calls it something, that is close enough for me. If someone else makes it, then it is emulation (of the IBM device). But I agree, that there is a gray area, so it isn't completely obvious. Gah4 (talk) 00:13, 21 May 2021 (UTC)

I think I may have the question backwards, Is the term DASD in z/OS and z Systems limited to CKD DASD which are emulated by conventional HDDs in RAID storage systems? Some thoughts

• The term "device" as in DAS Device should be thought of in the context of IBM's architectural definition which is basically the end point of I/O addressing, see z/OS architecture definitions of I/O Device.
  A control unit is not a device nor is a Mass Storage System. The former is part of a path to a device while the latter may contain one or more physical or virtual devices.
• When originally defined DAS devices were physical devices, one or more in a cabinet, today they can be either physical or virtual with many in one cabinet.
• The originally defined DAS devices were only CKD devices on mainframes, mainly HDDs. In 1979 IBM added a second type of DAS devices to its mainframes, FBA devices, originally only HDDs, to its mainframe systems.
• IBM's small systems (S/23-S/38, S/7) initially did not use DASD in its hardware manuals. Don't know about OS's.
• Today there are no physical CKD DASD being manufactured, all such devices are emulated in storage systems. Only FBA DASD are in current production and the common terms for such are HDD and SSD.
• IBM usage of term DASD must be considered in both the context of time and documentation. It may mean just CKD DASD, just FBA DASD or both.
  • Since there are no longer any CKD DASD being manufactured today in general it means HDDs and SSDs.
  • As used in current z/OS and z Systems DASD refers to a limited set of emulated CKD DASD located in attached storage systems.
  • IBM rarely uses the term DASD in any of its current storage product literature using the terms HDD or SDD or their variants. Virtual devices are created as addressable devices in IBM storage systems, for example, in the IBM DS8900 as either CKD volumes or FBA volumes. see: Creating volumes.

At this point I'm not sure about current AIX and IBM Linux but I think the current versions should be addressed. Not sure about small systems history or but I think P Systems need be added.
At this point I'm not sure how much of the above will turn out to be OR but I think some of the bullet points about belong in the article. I'll try to craft another trial balloon and see if Chatul can accept it. Any suggestions as to breath of content? Tom94022 (talk) 19:22, 24 May 2021 (UTC)

Remapping versus simulation of geometry

@Gah4:CP support for minidisks only does remapping of DASD, preserving the geometry of a cylinder. However, programs such as Hercules do full bore simulation; they support FBA and CKD logical devices implemented using the file system of whatever OS they are running on. Originally CMS used an SIO instruction for DASD I/O, which CP intercepted. Since then IBM has added hypervisor for CMS.

In S/370 mode CMS can use DIAG X'18', which requires that CMS construct a virtual channel program. In ESA/XC and z/XC modes, CMS can use DIAG X'A4', which does not require a virtual channel program; CMS does not do a virtual SSCH, as it would have more overhead.

I'm not sure how much, if any, the article should say about remapping and simulation, although all current DASD for z do simulation for both CKD and FBA. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:08, 25 May 2021 (UTC)

Hercules maps them to a disk file, but pretty much the same way as IBM does for P/370. (As well as I know, track overflow is not compatible, but otherwise it is.) Then there is CMS emulation of OS data sets, but at a higher level. But yes, it makes more sense for CMS to figure it out than for CP to cross-emulate between CKD and FBA. For for other than CMS, it could be useful. In any case, I don't suspect it would be a complicated addition to CP if it was needed. Does it matter if it is IBM or someone else doing it? Gah4 (talk) 11:27, 25 May 2021 (UTC)

CMS provides access methods for OS and DOS datasets, but it doesn't map between CKD and something else. I don't expect anybody, IBM or not, to add any kind of DASD simulation to CP beyond the simple remapping needed for minidisks; that sort of thing is only needed in the DASD subsystems.

Track overflow is interesting from a historical perspective, but I don't know of many people actually using it. I won't loose any sleep over it if, e.g., Hercules, P/390, PDT, doesn't support it.

All of which still leaves the question of how much, if anything, the article should say about remapping and simulation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:08, 25 May 2021 (UTC)

If we are trying to cover IBM devices, then sometimes we should cover IBM simulations of devices. In other words, they are simulations (of IBM) if someone else does it, but they are IBM if IBM does it. It seems that some OS use track overflow, so it was important in the early years of Hercules. Gah4 (talk) 19:58, 25 May 2021 (UTC)

The access methods in IBM operating systems supported track overflow when requested with, e.g., RECFM=FBT, but no IBM software exploited that. Current IBM operating systems don't support any of the DASD with track overflow, and there's no real use case for it with ECKD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:35, 25 May 2021 (UTC)

It was some time ago by now, but I believe it is the paging data sets for MVS 3.8j. It slowed down getting it to run on Hercules, until that was figured out. And then when it was, it was done different from the way IBM did it for P/370. Gah4 (talk) 21:05, 25 May 2021 (UTC)

With or without DF/EF? MVS/SE? MVS/SP? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:49, 25 May 2021 (UTC)

I'm not sure there is any substantive difference between simulation, virtualization or emulation but it is clear that all current DASD on Z systems, both CKD and FBA, are emulated (or simulated or virtual) and IMO this should be in the article. Tom94022 (talk) 22:56, 25 May 2021 (UTC)

Or just progress. The older ones were made the way they were, as that was the technology of the time. Each advancement is a little bit away from the previous, and so might be a virtualization. The 3330 uses ECC, so it isn't really the bits that are written! As mentioned earlier, the 2301 uses four tracks to store one track of data! Virtual tracks! As memory got cheaper, more buffering was done, which IBM calls asynchronous. Some are more obvious, though, but it has been going for a long time. Some argue that anything microprogrammed is an emulation of the actual (not-microprogrammed) hardware! But yes, how do we explain each of these steps? Gah4 (talk) 00:14, 26 May 2021 (UTC)

I don't think there is anything virtual about the 2301, just bits (tracks) in parallel, like tape drives have done since the beginning, and so did the 2305.

The ECC in the 3330 was appended to the data and key fields so it really is the bits that are written, allbeit in MFM format.

Actually they still make HDDs the same old way and in some OSs they are addressed the same old way too, that is directly, but in at least zOS the devices addressed are virtual devices (volumes in a storage system) and it seems in zOS DASD means virtual CKD HDDs which is a point that should be made in the article. Tom94022 (talk) 07:07, 31 May 2021 (UTC)

Well it was, at least slightly, meant as a joke, but also that it is sometimes not so easy to say. Yes tapes traditionally used parallel tracks, and so the bits-per-inch values should have been labeled bits-per-track-per-inch. But then later we got tapes that record serial data on a single track, maybe starting with QIC and then helical scan drives. And I suppose I would agree if it was eight for the 2301, to match the byte width, but it isn't. So, I don't think it is so strange to call the 2301 track length virtual. As for tapes, the GCR recording for 6250BPI tapes writes more than 6250 after the GCR conversion, but (rightly) they don't count that. But counting bits easily becomes confusing. How do you explain to someone just learning about bits how there are 3.32 bits in a decimal digit? In any case, what I mostly wanted to say is that it is often not as obvious as it seems. Gah4 (talk) 08:40, 31 May 2021 (UTC)

A slight clarification on the 2305; the 2305-1 had two heads per track, but the 2305-2 had only one. The -1 had half the capacity at twice the speed, hence the two-byte interface feature on the 2835 and 2880. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:32, 31 May 2021 (UTC)

A further clarification on the 2305; AFAIK, each head has 8 tracks in parallel; the heads of course were fixed. I was wrong - there are multiplements elements per head; they are not read in parallelTom94022 (talk) 00:25, 2 June 2021 (UTC)

FWIW, the tape and disk folk never agreed upon density specifications, the tape folk preferring bytes/inch while the disk folk preferring bits/inch².

We are long way from the subject of this section, in summary and IMO I don't think remapping belongs in the article but I do think virtualization of DASD does given its varying definitions between hardware, software and over time. AFA Hercules goes, it is rather recent and might deserve a sentence that it too creates virtual CKD devices. I suspect it doesn't per se create virtual HDDs but instead uses both real direct attached HDDs (mapped or not) and virtual ones on attached storage systems. Again the challenge is "device" has very specific meaning in OSs and a very different meaning in general and how do we get that across in this article? Tom94022 (talk) 17:31, 31 May 2021 (UTC)

No, the 2305 reads the track serial by bits and the 2305-1 has two heads per track; neither reads tracks in parallel. The 2835 assembles bits into 8-bit bytes for transmission over the channel.

The tape and DASD folks were mostly in perfect alignment in the open reel era. What is different from DASD is the number of R/W heads that operate in parallel. All of IBM's mainframe tape drives operate multiple R/W heads in parallel; originally 7 for a six bit byte, latter 9 in parallel for an 8-bit byte. With the cartridge drives the tape widths were multiples of 9 and B/s was the same multiple of b/s.

The term device is actually a bit fuzzy in the OS. A 2321 has ten bins; is it one device or ten? A 2305 has 8 exposures; is it one device or 8? The same question applies to all of the subsequent multiple exposure devices. 17:01, 1 June 2021 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

Not so fuzzy in the architecture and OS manuals, it is the thing addressed as for example:

I/O devices are attached to the channel subsystem through control units. The connection between the channel subsystem and a control unit is called a channel path. ... A device identifier is an address, not apparent to the program, that is used by the channel subsystem to communicate with I/O devices ... The device address identifies the particular I/O device.

z/Architecture Principles of Operation

The 2321 is the device. I am not familiar with the term "exposure" but I think at least in z/OS the device is the thing addressed by those bits in the device identifier. Tom94022 (talk) 00:25, 2 June 2021 (UTC)

That text describes the viewpoint of an XA style channel subsystem, where alternate controllers and alternate channels are hidden from the I/O Supervisor. In S/3700 mode, there can be multiple addresses for the same volume even with single exposure devices. The quoted paragraph never defines device, and if you interpret it as meaning that each device identifier is a separate device then a 2321 has ten devices and a 2305 has eight.

The text describes devices (that is, "I/O devices") supported by zOS on System z under which a device can have multiple addresses. Are there any direct access storage devices support by zOS on System z that are not channel attached? Tom94022 (talk) 06:42, 5 June 2021 (UTC)

Yes and no. Flash Express uses SSDs on a PCIe bus and gets assigned PCHPIDs but not CHPIDs. both z/OS and CFCC support it, but newer models use VFlash instead.

Shouldn't your comment about the 2321 be here rather than below? Shmuel (Seymour J.) Metz Username:Chatul (talk) 05:03, 6 June 2021 (UTC)

Some control units allow multiple device addresses on the same channel for the same volume, such that multiple channel programs can be operating concurrently. The major use cases are fixed-head DASD with RPS and buffered ECKD DASD. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:22, 2 June 2021 (UTC)

A 2321 has one address or two depending upon whether the two channel switch is installed. To quote the 2305 manual "The function [multiple requesting] is implemented by associating up to eight logical (system) device addresses with a single physical module." Of course they could double with a two channel switch but still one device with multiple addresses. Tom94022 (talk) 06:42, 5 June 2021 (UTC)

I remember RPS mostly from the 3330. Does it need the multiple channel programs, too? Gah4 (talk) 01:49, 4 June 2021 (UTC)

RPS was implemented with a then new channel command, Set Sector - it does not need multiple channel programs. Tom94022 (talk) 06:42, 5 June 2021 (UTC)

I haven't thought about this for a while. With RPS, the channel can do other things while waiting for the sector. As I understand the comment about the 2305, it can transfer whichever block comes up next. A channel attached to a string of 3330's can only transfer on one at a time, but with RPS, the next drive that has the right sector will be the one? Or does the processor have to queue up the channel programs based on the current sector? I knew this some years ago, but forgot by now. Gah4 (talk) 18:36, 5 June 2021 (UTC)

On a 2305 you can have up to 8 concurrent channel programs to the same volume, each waiting to reconnect on a Set Sector. On a 3330 you can only have one channel program. However, you can have many concurrent channel programs on the same channel for different volumes, including multiple volumes on the same string. I've created Talk:History of IBM magnetic disk drives#Multiple requesting to split of any further discussion of multiple requesting and multiple exposure controllers, since this is getting a bit long and different issues are getting intermixed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 05:03, 6 June 2021 (UTC)

See Rotational Position Sensing and the subsequent example. An SCU can disconnect on a BlockMux channel for both the Seek and Set Sector Commands; I seem to recall the term "disconnected command chaining" used to describe this. ASFAIK, it has nothing to do with multiple requesting. Tom94022 (talk) 18:45, 6 June 2021 (UTC)

The only connection between disconnected command chaining and multiple requesting is that multiple requesting would be pointless without disconnected command chaining. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:59, 7 June 2021 (UTC)

(too much indentation...) Do any non-IBM and/or FBA devices do RPS? It would seem like this would be a useful feature on disk attached to almost any system. Peter Flass (talk) 19:09, 6 June 2021 (UTC)

What most disks do now, that is, those that you buy in a store like SATA/SAS, is seek to the track and then read the whole track, starting from wherever it is in the rotation, into the cache. Maybe even read successive tracks. NFS also does read-ahead assuming you will do sequential access. Having huge (relative to the 3330) cache changes the optimal stragegy. Gah4 (talk) 11:51, 7 June 2021 (UTC)

Reading the whole track is good for sequential access, but not for random access.

Don't SCSI disks sort commands to optimize performance?

For IBM ECKD disks, a channel program that uses LOCATE has no need for RPS. That was also true for the 3310 and 3370. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:06, 7 June 2021 (UTC)

Yes, I believe SCSI disks can reorder commands, I don't know what OS do now, though. Also, as well as I know, SATA disks accept SCSI commands if the system wants to use them. There is no reason not to buffer the blocks up to the one requested. The rest of the track is less obvious. Also, I know that NFS likes to do read-ahead. It might be that it considers recent history to detect sequential vs. random access.

And then there is writes. An old NFS rule, which can be turned off, is that it doesn't acknowledge writes until the data is on disk. (The server could crash or be powered down if it is only in cache.) Some RAID controllers have battery backed cache to allow for cached writes. Now, if there are reads and writes in the queue, what order do you do them in? Fastest overall, or get the write data to disk first? I used to know NFS from version 2, and they are now version 4. These things are changing faster than we can learn them! Gah4 (talk) 20:51, 7 June 2021 (UTC)

OK, it seems that there is Tagged Command Queuing or some similar function for SATA and SCSI, and seems to be well described on that page. Gah4 (talk) 08:49, 8 June 2021 (UTC)

Also, it seems that some description of RPS is in Unit_Control_Block#Handling_parallel_I/O_operations but maybe it should have its own description somewhere. Gah4 (talk) 09:04, 8 June 2021 (UTC)

There is a huge amount of material in Unit Control Block that doesn't belong there, but that section does belong there; the only connection to RPS is that the 2305 was the first DASD to support disconnected channel programs, without which multiple requesting would be pointless. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:34, 8 June 2021 (UTC)

Any DASD competing in the z/OS or z/VM marketplace supports RPS, and I suspect that all the new ones support PAV and EAV. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:59, 7 June 2021 (UTC)

Thanks for mentioning PAV; I suggest the article PARALLEL ACCESS VOLUMES AND MULTIPLE ALLEGIANCE contains two images that illustrate two definitions of DASD that need to be explained in this article. The first image illustrates the historical definition, a physical device capable of direct access, in this case and HDD. The second image illustrates today's two definitions in z/OS, either a virtual disk addressed by the system or a member of an array of physical devices. Note the article says, "Spinning disks are virtualized." I believe this is true System z regardless of the OS but not necessarily true for IBM Power Systems so careful wordsmithing is important. Tom94022 (talk) 17:22, 8 June 2021 (UTC)

(too much indentation...) Do any non-IBM and/or FBA devices do RPS? It would seem like this would be a useful feature on disk attached to almost any system. Peter Flass (talk) 19:07, 6 June 2021 (UTC) Interesting question. We all recognize a device when we trip over one, but coming up with a definition is not so easy. Obviously a physical device doesn’t necessarily correspond one-for-one with a UCB. If a device is a physical box what do you do with a 2314? I guess the definition of a device depends on what you’re looking at.

Respectively the 2314 DASF is a facility which has from an OS viewpoint 8 online 2314 type devices, the 2312 Disk Storage has one 2314 type device, the 2313 Disk Storage has four 2314 type devices, etc. I think it depends upon where you are looking at something from. See the z System architectural view quoted above, which I believe to be an OS view also. Tom94022 (talk) 00:25, 2 June 2021 (UTC)

And then there is shared DASD, along with RESERVE and RELEASE, so one physical device belongs to more than one processing system. Yes counting is complicated. Gah4 (talk) 21:54, 1 June 2021 (UTC)

Sure but it isn't it still one device with multiple addresses? Tom94022 (talk) 00:25, 2 June 2021

I would count such things as alternate controllers on different channels, shared DASD, multiple exposure devices and EMIF as a single device per drive. Likewise, each drive on a 2314, 3330 or 3340 has its own access mechanism and R/W heads. But what about something like the IBM 2321 or the RCA 3488 RACE, where the same access mechanism and R/W heads are used for each of the cells (bins)? Logically distinct volumes, addresses and UCBs, but shared hardware. IMHO, what is important is not what definition we use, but that we be clear and consistent. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:22, 2 June 2021 (UTC)

I agree we need to be clear and consistent and hopefully that is where this dialog is taking us. The 2321 in not unlike any other removable medium device, but is still only has one address or two if it is on a two channel switch. Volume management and their TOCs are a whole other story and not a part of this article other than the virtual DASD on modern attached storage systems are typically called volumes when they are allocated on the system. Tom94022 (talk) 06:42, 5 June 2021 (UTC)

Up thru I think S/390 provisioning was pretty straight forward, the bits of the device address portion of appropriate I/O instruction were installed in the device, either in its backplane or in some devices a removable plug (e.g. 2314 and 3330). Usually those with backplane bits had a label visible to an operator that has the full device addresses, one to four depending upon the number of channels switched, typically with the last three bits having a one to one correspondence with the last three bits of the I/O instruction. There are a lot more devices on System z and therefore lot more bits/device and zOS hides a lot of the translation from a data set on a volume to the address of the device but in the end there has to be an equivalence between the device address of the System z hardware and the virtual volume in an attached storage system. I've poked around in zOS documentation and find how it creates the equivalence quire obscure. Perhaps some one more familiar with zOS can explain provisioning on z systems with zOS; specifically how do volumes on an IBM storage system get assigned to one or more direct access storage device addresses in a System Z? I doubt if we still put jumpers in a backplane :-) Tom94022 (talk) 18:45, 6 June 2021 (UTC)

Notes

References

Live video call and chatting with friends and family

I am find with my friend video call and chatting now. But how can I get online video call and chatting with friends 196.191.251.16 (talk) 13:33, 27 September 2023 (UTC)