[EMAIL PROTECTED] wrote:
Right. And what device, other than the 2321, ever had meaningful non-zero values for the bb part of bbcchh? In other words, if there had never been any 2321, why would we have needed the extra 2 bytes for the bb in seek and search addresses?

re:
http://www.garlic.com/~lynn/2007e.html#64 FBA rant

for other drift ... if the geometry characteristics were to be ignored then you 
could treat
the six byte seek argument as the track number (allowing the device to 
interpret the physical
characteristics ... somewhat similar to what FBA does in the locate command for 
the record
number).

i.e. CKD seek command is six byte field
http://www.garlic.com/~lynn/gcard.html#26.1

treated as purely a 2**48 bit numeric would allow for nearly 300 trillion tracks

and FBA locate command
http://www.garlic.com/~lynn/gcard.html#26.2

is eight byte number, which could allow for 2**64 512-byte records (i.e. 2**9 
times 2**64 bytes,
2**73 bytes per device)

for something complete different, quicky search engine use turned up this (IBM) 
patent
reference on mapping tof CKD to native FBA hardware
http://www.patentstorm.us/patents/6112277-description.html

and title of above:
        
Method and means for reducing device contention by random accessing and partial track staging of records according to a first DASD format but device mapped according to a second DASD format

... snip ...

The above patent also references another patent:

Reference should be made to Menon, U.S. Pat. No. 5,301,304, "Emulating Records in One Record Format in Another Record Format", issued Apr. 5, 1994. Menon exemplifies the state of the art in format conversion disclosing an emulation method for rapidly accessing CKD records in which the CKD records are stored on a disk drive in FBA format.
... snip ...

now as suggested in previous post
http://www.garlic.com/~lynn/2007e.html#46 FBA rant

what would be the difficulty in modifying whatever MVS calls its current
incantation of CCWTRANS ... to morph application space EXCP CCWs that
are still doing things like multi-track VTOC/PDS search into FBA operations
... aka there are hardware control units and hypervisor software that
perform such morphing ... then if the original VS2 started out with
(cp67's) CCWTRANS moved into the VS2 kernel ... why can't more current
hypervisor technology be moved directly into the VS2 kernel

here is decade-plus old descriptive narative of ECKD (from vm mailing list) ... basically discussing the retrofitting FBA-like channel commands to CKD architecture:
http://listserv.uark.edu/scripts/wa.exe?A2=ind9604&L=ibmvm&T=0&P=9321

from above:

ECKD channel programs completely describe the nature and scope of data
transfer operation before the first data transfer command is executed.
These "predictive" channel programs "remove all possible surprise" from
the storage subsystem during data transfer operations. Like Fixed-Block
Architecture (FBA) DASD, ECKD uses the DEFINE EXTENT channel command to
delimit the range of tracks which may be affected by a channel program.
ECKD is still CKD: each record can contain Count, Key, and Data areas.
However, the count need not be CCHHR, as on conventional CKD DASD; one
could number the records sequentially, like FBA blocks.

... snip ...

as opposed to post
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
with my nearly 25yr old email commenting on ECKD
http://www.garlic.com/~lynn/2007e.html#email820907

slightly older random email reference to CALYPSO and ECKD ... in the
following DMKTRD is the vm370 kernel module responsible for cp
"trace" command related to tracing virtual machine i/o and ccws.

To: wheeler
Date: 10/10/80 15:28:17
Lynn,

The new DMKTRD will trace CALYSPO' new Define Extent and Locate Record
CCW's. A 16 byte argument is displayed on the trace, immediately below the
trace of the CCW itself

Fix was tested virtual VM under VM and will go on 31B at STL by next
Tuesday.

... snip ...


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

Reply via email to