Hay una desconexión entre el vocabulario de los manuales de hardware de IBM y los manuales de software. Los manuales de hardware para CKD DASD utilizan el término registro mientras que los manuales de software utilizan el término bloque o registro físico . Creo que el líder debería mencionar esto. @ Tom94022 : Además, edit special:permalink/1212325573 cambió o una copia de la clave más alta en el bloque, para registros "bloqueados")
a los datos ilegibles o una copia de los primeros
n
bytes en de los primeros datos cuando el registro tiene varios datos "bloqueados" concatenados en un campo de datos
, lo que no se ajusta ni a la nomenclatura de hardware ni de software. Sugiero o una copia de la clave más alta en el registro, para
registros
lógicos
bloqueados
[a]
) -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 16:29, 7 de marzo de 2024 (UTC) [ responder ]
- No estoy seguro de qué distinción sustantiva relevante está haciendo; no conozco ningún manual de referencia para ningún dispositivo CKD que use el término "bloque" para referirse a "registro". Lo mismo ocurre en el nivel del manual de referencia del comando de canal. Sí, en algún nivel (por ejemplo, to_IBM_Direct-Access_Storage_Devices_and_Organization_Methods_Dec75.pdf) IBM distingue entre registro lógico y registro físico, y a veces el "bloque" es lo mismo que "registro físico", pero creo que ese es un nivel de complejidad que no necesitamos aquí. IBM no usa "registro" ni "registro físico" en los manuales de referencia relevantes. Creo que es lo mejor que usamos constantemente en este artículo. Si alguien quiere agregar una nota en algún lugar del artículo que diga que a veces se hace referencia al registro CKD como "registro físico" o "bloque", eso debería ser más que suficiente. Tom94022 ( discusión ) 22:05, 7 de marzo de 2024 (UTC) [ responder ]
- Exactamente lo que escribí; la nomenclatura del hardware y del software difieren.
- El texto citado en la edición citada rompió la coherencia, incluso dentro de una sola oración, y utilizó una nomenclatura que es OR ; desde que lo eliminaste en permalink/1212432070 , ya no es un problema. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 15:33 8 mar 2024 (UTC) [ responder ]
Notas
- ^ IBM utiliza los términos bloque y registro físico en los manuales de software para lo que denomina registro en los manuales de hardware.
Algunas secciones del artículo tratan temas que parecen no estar relacionados con el formato CKD, como Count key data § Dynamic paths , que analiza una característica que parece analizar las rutas de datos; la característica parece ser una que también podría usarse con FBA. Otras que podrían no estar relacionadas con CKD incluyen Count key data § Multiple Requesting y Count key data § Command Retry . Tal vez debería haber una página, o una sección de una página, que analice la arquitectura del hardware y firmware de almacenamiento del mainframe de IBM, y tal vez la noción general de canal, unidad de control y dispositivo. Guy Harris ( discusión ) 06:28, 8 de marzo de 2024 (UTC) [ responder ]
- El artículo principal indica que el artículo también cubre los comandos de canal CKD, pero las secciones citadas anteriormente parecen ser inapropiadas para este artículo. El problema es que los canales de IBM solo se cubren brevemente en los diversos artículos de IBM System, por ejemplo, IBM System/360 Channels, y el artículo global sobre Channel I/O es quizás demasiado genérico para ese tipo de material. Tal vez estas secciones se puedan trasladar al artículo sobre el sistema IBM en el que se anunciaron por primera vez dichas características. Es un proyecto de investigación, pero tal vez algunos de los editores recuerden la fecha y el sistema del anuncio. Tom94022 ( discusión ) 19:22, 8 de marzo de 2024 (UTC) [ responder ]
- Tras un estudio más profundo, me parece que la mayor parte del contenido de la sección de mejoras del canal del multiplexor de bloques de este artículo debería trasladarse al artículo Historial de controladores CKD de IBM . Tom94022 ( discusión ) 21:40, 8 de marzo de 2024 (UTC) [ responder ]
- Parece que History of IBM CKD Controllers puede servir como la página que "analiza la arquitectura del hardware y firmware de almacenamiento de mainframe de IBM", al menos para las unidades CKD. Guy Harris ( discusión ) 21:55, 8 de marzo de 2024 (UTC) [ responder ]
- Los códigos de operación CCW que controlan las rutas dinámicas son específicos de los controladores ECKD y pertenecen a este apartado hasta que haya un artículo sobre ECKD. No conozco ningún controlador FBA que los admita; no sé lo suficiente sobre las unidades SCSI a las que se accede mediante FCP como para comentar al respecto.
- Parte del material pertenece a IBM System/360#Input/Output . Sin embargo, parte es específica de DASD, por ejemplo, los códigos de operación Set Sector y Read Sector CCW.
- Realmente debería haber un artículo de arquitectura desde S/360 hasta z/Architecture , así como un artículo de ECKD; mucho de lo que mencionas encajaría naturalmente allí. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 15:25, 10 de marzo de 2024 (UTC) [ responder ]
- "Artículo de arquitectura", en singular, o "artículos de arquitectura", en plural? Ya existe la arquitectura IBM System/360 , en la que IBM System/360 cubre la familia como línea de productos, y z/Architecture , en la que IBM Z cubre la familia como línea de productos, pero las arquitecturas intermedias no tienen esa división.
- (x86 tiene una sola página x86 , que cubre la línea de productos de chips, y tiene algunos detalles comunes a las arquitecturas de 16 bits, 32 bits y 64 bits, y también IA-32 para la versión de 32 bits y x86-64 para la versión de 64 bits.) Guy Harris ( discusión ) 23:17 10 mar 2024 (UTC) [ responder ]
- La arquitectura IBM System/360 no cubre S/370 , 370/XA , ESA/370 , ESA/390 o z/Architecture , y ya tiene 86K; un solo artículo sobre arquitectura sería demasiado grande. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:27, 11 de marzo de 2024 (UTC) [ responder ]
- En realidad, creo que todas las arquitecturas tienen su hogar, ya sea en artículos o secciones, como S/370 , 370/XA , ESA/370 , ESA/390 o z/Architecture, por lo que todo lo que tenemos que hacer es encontrar la correcta para mover el material irrelevante. Tom94022 ( discusión ) 17:42, 11 de marzo de 2024 (UTC) [ responder ]
La frase
Originalmente, los registros CKD tenían una correspondencia uno a uno con una pista física de un dispositivo DASD; sin embargo, con el tiempo los registros se han vuelto cada vez más virtualizados, de modo que en los mainframes IBM modernos ya no existe una correspondencia directa entre un ID de registro CKD y el diseño físico de una pista.
Tal vez debería haber más texto que explique lo que eso significa. Según tengo entendido, las unidades son simplemente unidades de bloque fijo comunes y corrientes, y alguna combinación de hardware, firmware y software (?) hace que parezca un dispositivo CKD. No sé si los detalles de cómo se hace eso están disponibles en alguna referencia. Guy Harris ( discusión ) 06:34, 8 de marzo de 2024 (UTC) [ responder ]
- ¿ El documento US 5581743A , "Mapeo de CKD a bloques fijos para un rendimiento y utilización del espacio óptimos", describe una forma en que IBM realiza esa emulación de CKD? (US551743A en Google Patents) Guy Harris ( discusión ) 06:53, 8 de marzo de 2024 (UTC) [ responder ]
- Dudo que la existencia de una patente de IBM sea suficiente para establecer que alguna vez se practicó en algún producto real. Tendríamos que encontrar un RS que vincule la patente con un producto para hacer tal afirmación. Es OR, pero estoy bastante seguro de que el primer RAMAC RAID mapeó CKD en dispositivos FBA escribiendo toda la pista física CKD, espacios, ECC, etc. en bloques fijos y luego preparando la pista en un búfer antes de reconectarse para una transferencia. No es un uso muy eficiente del almacenamiento, pero hizo que la virtualización fuera sencilla. Estoy bastante seguro de que las virtualizaciones posteriores fueron más eficientes, pero no conozco los detalles. Además, IBM no fue el primer virtualizador, creo que lo fue EMC y no conozco ningún material publicado sobre su arquitectura de virtualización. De hecho, es una combinación de hardware y principalmente firmware en un subsistema de almacenamiento, pero tal vez eso sea todo lo que podamos decir e incluso entonces encontrar un RS podría ser difícil. Probé BARD y no obtuve ayuda. :-) Tom94022 ( discusión ) 07:45 8 mar 2024 (UTC) [ responder ]
- Esta presentación de diapositivas parece sugerir que el primer dispositivo CKD emulado era de un producto con el nombre en código "Iceberg" de Storage Technology Corporation . Guy Harris ( discusión ) 07:51, 8 de marzo de 2024 (UTC) [ responder ]
- El " EMC Symmetrix Integrated Cached Disk Array ", presentado en septiembre de 1990, era un dispositivo de almacenamiento que emulaba IBM CKD y utilizaba una matriz RAID de discos duros Seagate FBA; probablemente fue el primer sistema de este tipo y mucho antes del Iceberg de STC en 1994. Tom94022 ( discusión ) 19:03 8 mar 2024 (UTC) [ responder ]
- Hay dos cosas. Una es que IBM vende cajas que, en cuanto al hardware, parecen unidades de disco tradicionales, aunque (si abres la caja) encuentras un montón de unidades normales. Sin embargo, sospecho que no se supone que debas abrirlas. La segunda son los archivos utilizados para los sistemas P/370 y P/390, por AWSCKD, donde puedes acceder a los archivos en el sistema host. Los primeros deben considerarse cajas negras, ya que IBM podría cambiarlos en cualquier momento. Gah4 ( discusión ) 08:17, 8 de marzo de 2024 (UTC) [ responder ]
- De todos modos, esa frase es dudosa: es la pista lógica la que estaba en correspondencia 1-1 con la pista física, no los registros individuales, especialmente cuando había varios registros por pista.
- Las pistas virtuales se remontan al menos hasta el IBM 3350 , que podía configurarse para que pareciera un 3330-11 o un par de volúmenes 3330-1; en cualquier caso, los volúmenes lógicos tenían un tamaño de pista diferente al de un volumen nativo. Creo que el 3350 fue el último dispositivo CKD que simuló un dispositivo diferente. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 21:11, 8 de marzo de 2024 (UTC) [ responder ]
- No estoy seguro de qué tiene que ver AWS Cloud Development Kit con esta discusión, pero ¿tal vez tengo el acrónimo equivocado?
- Estoy bastante seguro de que la pista física en un 3350 que emulaba un 3330 era idéntica a la pista virtual: el campo de conteo, los espacios y el ECC eran diferentes en contenido o longitud, pero cada registro estaba en el mismo orden físico y al igual que los campos de clave y datos de cada registro. Lo mismo para el 3344 que emulaba un 3340. Pudieron hacer esto porque la longitud de la pista del 3350/3344 era mucho mayor que la del 3330/3340, por lo que la pista física emulada solo tenía un montón de bytes sin usar al final (G4 más largo). Eso es algo diferente cuando se usan un montón de bloques FBA para emular una pista CKD. Tom94022 ( discusión ) 18:38, 11 de marzo de 2024 (UTC) [ responder ]
- Odio esos acrónimos sobrecargados :-(
- Todos los productos de software de IBM, al menos a partir de la época de OS/360, tienen un código de tres letras que se utiliza para sus módulos y mensajes. Para P/370 es AWS. El módulo que emula CKD para P/370 es AWSCKD. (Nota: no AWSCDK). También existe AWSFBA para emular discos FBA. Gah4 ( discusión ) 06:56 18 mar 2024 (UTC) [ responder ]
- Es plausible que el 3350 haya usado una pista física completa para cada pista lógica del 3330, pero aun así habría sido necesaria cierta virtualización para que solo 13030 (13165) bytes fueran visibles por pista y los factores de sobrecarga produzcan resultados compatibles. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 21:15, 11 de marzo de 2024 (UTC) [ responder ]
- Los espacios tienen que ser los mismos en el tiempo para evitar el desbordamiento, por lo tanto, dada la mayor velocidad de datos, son más largos en el recuento de bytes en un 3350 en modo 3330 que en un 3330, pero un contador simple detiene la transferencia cuando llega a 13330, el número de bytes sin procesar en una revolución 3330. El contador se incrementa por la longitud de cada espacio 3330 cuando se escribe realmente el espacio 3350. Tom94022 ( discusión ) 06:02, 12 de marzo de 2024 (UTC) [ responder ]
- No he pensado en esto durante un tiempo. Son 13030 bytes para el tamaño de bloque de la pista completa, más 135 bytes de sobrecarga por bloque. Por lo tanto, debería ser 13165. Para los 2314, 7294 para la pista completa, y la sobrecarga es solo para las demás pistas excepto la primera. Hasta donde sé, la diferencia tiene cierta importancia. Gah4 ( discusión ) 06:52, 18 de marzo de 2024 (UTC) [ responder ]
- Sí, 13165 es el valor publicado y también el valor utilizado en los cálculos de capacidad. A partir de 3375, el cálculo incluyó otro factor [a] que refleja el tamaño del sector. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:41 18 mar 2024 (UTC) [ responder ]
- Antes del 3330, todos los DASD de IBM tenían una cantidad variable de bytes de índice a índice debido a la variación de velocidad. A partir del 3330 (quizás el 2305), los DASD de IBM escribían en sincronización con el husillo giratorio, por lo que había una cantidad precisa de bytes enteros por pista, 13 330 según recuerdo para el 3330 y, por cierto, exactamente 1,5 veces más que para el SMD de CDC. Es el Gap 1 de IBM y el campo HA lo que explica la diferencia entre los números publicados de IBM y la capacidad de pista completa real, que, por ejemplo, es la razón detrás de la diferencia entre 13 165 publicados y 13 440
13330 reales en el caso del 3330. Tom94022 ( discusión ) 07:21, 19 de marzo de 2024 (UTC) [ responder ]- Para el modelo 3330, la sobrecarga de 135 es por bloque. Por lo tanto, la mitad de la pista es 13165/2-135 y 1/3 de la pista es 13165/3-135. Pero, bueno, la diferencia entre 13330 y 13165 es 165, o 135+30. ¿Existen tanto HA como R0?
- El que nunca supe, desde que supe por primera vez sobre el 3330 hace 51 años: para el 2314 la fórmula de sobrecarga de bloque no tiene sobrecarga para el primer bloque, pero para el 3330 sí la tiene. Debe haber al menos un espacio para la especia de escritura, para activar y desactivar la escritura de bits, siempre y cuando no reescribas toda la pista. Bueno, entonces todavía hay un empalme de escritura al final de la pista. Gah4 ( discusión ) 12:35 19 mar 2024 (UTC) [ responder ]
- Siempre hay una sobrecarga para el primer y el último bloque; hay diferentes formas de documentar esa sobrecarga. Sí, el 2314 y el 3330 tienen HA y R0. Además, el software de IBM asume un R0 estándar (DL=8, KL=0). -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 13:37, 19 de marzo de 2024 (UTC) [ responder ]
- Encontré la tabla en esta página 137. Para el 2314, además del último bloque, tiene una sobrecarga de 101 bytes y también un factor de 534/512. (Más con KL>0). Entonces, la mitad de la pista es 3520, ya que 101+3520*534/512+3520 es 7292,25. Como se indica en la nota al pie, no hay sobrecarga para la última pista. Me parece que esta fórmula complicada proviene de alguna manera del formato de bajo nivel. Y qué conveniente que 3520 sea un múltiplo de 80. Hace 50 años, si no sabíamos si un conjunto de datos era 2314 o 3330, el favorito era 3120, para LRECL=80, no tan lejos de ninguno de los dos. Gah4 ( discusión ) 13:08, 19 de marzo de 2024 (UTC) [ responder ]
- IBM proporciona fórmulas de capacidad 2314 independientes para R1 y registros posteriores, donde la fórmula para R1 incluye la sobrecarga. ITYM último bloque, y hay sobrecarga, pero se tiene en cuenta en otro lugar. Además, todas las fórmulas publicadas suponen que R0 tiene DL=8, KL=0. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 13:37, 19 de marzo de 2024 (UTC) [ responder ]
- En el caso del 2314, parece que la sobrecarga de 534/512 es solo para el bloque que no es el último. Puedes agregar fácilmente el 101 a cualquier último espacio, pero es más difícil explicar el 534/512. Pero los espacios tienen que ser lo suficientemente grandes como para permitir las posibles variaciones, como la velocidad del disco. (A menos que, como señala Tom, esté sincronizado con la velocidad del disco). Cuando escribes un bloque, el hardware tiene que, en algún momento, darse cuenta de que eres el último bloque que cabe. Hasta donde yo sé, solo puede hacer eso tratando de escribirlo y luego descubriendo que no cabe. (Para RECFM=U, no tiene idea de lo que viene a continuación). Entonces, en el caso de que no sea el último bloque, la sobrecarga permitida es ligeramente mayor de lo que debe ser, solo para estar seguros. Gah4 ( discusión ) 18:55, 19 de marzo de 2024 (UTC) [ responder ]
- Estaba tratando de entender el 13330 de Tom, que permite una sobrecarga de 135 bytes (probablemente en su mayoría espacio libre) y 30 bytes de datos. Pero tal vez el 13330 no incluye alta disponibilidad. Gah4 ( discusión ) 18:55, 19 de marzo de 2024 (UTC) [ responder ]
- La memoria me falló, la capacidad real de la pista sin formato del 3330 era de 13.440 bytes. Una prueba sencilla es 13.440 bytes/rev * 60 rev/s = 806.400 kB/s de velocidad de transferencia de datos (publicada redondeada a 806 kB/s). Todos los demás números no llegan a la velocidad de datos. Los diversos números de pista publicados por IBM suponen como mínimo un campo HA que requiere un espacio de índice posterior (G1). Tom94022 ( discusión ) 06:45, 20 de marzo de 2024 (UTC) [ responder ]
- Los números publicados también suponen un R0 estándar (KL=0, DL=8). -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 16:56 20 mar 2024 (UTC) [ responder ]
- Vale, entonces 13440 es suficiente tanto para HA como para R0, y algunos huecos. Si nunca reescribes HA, no necesitas escribir splice para ello. Por lo que sé, además del servo de velocidad de datos, los valores del sector y sospecho que el índice están en esa pista. ¿Hay una pista de servo para cada cilindro? Gah4 ( discusión ) 16:18, 20 de marzo de 2024 (UTC) [ responder ]
- Sí. Técnicamente, hay una superficie de servo en el cilindro dedicada a la información de posición de la pista y el mecanismo de servo que lee esta información de servo centra todas las pistas de datos en un cilindro entre dos pistas de servo. Este enfoque de superficie de servo se volvió obsoleto a partir de fines de la década de 1980 con la introducción de servos integrados, la información de servo se entremezcló con datos en todas las pistas de todos los cilindros, liberando la superficie de servo para los datos. Muy importante en unidades de disco pequeñas con solo unas pocas superficies por cilindro (por ejemplo, ST506 con 4 superficies), menos importante en el 3330 con 20 superficies. Tom94022 ( discusión ) 17:11, 20 de marzo de 2024 (UTC) [ responder ]
- El valor 13165 corresponde a la capacidad total de la pista, incluida la sobrecarga. El valor 13030 es el tamaño de bloque sin clave más grande posible. Como nota al margen, el 3330 tenía una pista de sincronización, cosa que el 2314 no tenía; más precisamente, el 3336 frente al 2316. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 13:37 19 mar 2024 (UTC) [ responder ]
- El 3330 y la mayoría de los DASD de IBM posteriores a la década de 1990 tenían una superficie servo que proporcionaba un reloj de escritura sincronizado a su controlador: en el paquete de discos 3336, por cada pista había exactamente 13440 ráfagas servo por revolución que se usaban para generar la frecuencia de escritura de 13440 bytes/rev * 60 rev/seg = 806,4 KB/seg. Los DASD anteriores, por ejemplo, el 2314, escribían con una frecuencia constante; la velocidad de rotación variaba con el desgaste y el voltaje, lo que daba como resultado una cantidad variable de bytes escritos por revolución. IBM tuvo esto en cuenta al incluir una tolerancia de velocidad dentro de las diversas fórmulas para la capacidad de pista de dichos DASD. Tom94022 ( discusión ) 06:45, 20 de marzo de 2024 (UTC) [ responder ]
Notas
- ^ Cálculo de CKD sobre espacio sectorial
- 3375 con llave
- 224 + ((KL + 191)/32)(32) + ((DL + 191)/32)(32)
- 3375 sin llave
- 224 + ((DL+ 191)/32)(32)
- 3380 con llave
- 256 + ((KL + 267)/32)(32) + ((DL + 267)/32)(32)
- 3380 sin llave
- 256 + ((DL + 267)/32)(32)
