title: Coupling Facility
text: # Coupling Facility
  
  En las computadoras centrales de IBM, una Coupling Facility o CF es un componente de hardware que permite a más de un procesador acceder a los mismos datos.
  Los Sysplex Paralelos necesitan como mínimo una Coupling Facility. Una coupling facility se compone de un procesador, memoria, canales especiales llamados Coupling Facility Links (CF Links) y un sistema operativo primitivo llamado Coupling Facility Control Code (CFCC). No tiene más canales de entrada/salida que los CF Links. La información en la CF se mantiene en la memoria, de modo que una CF tiene una gran cantidad de memoria instalada. En teoría, cualquier computadora central de IBM puede funcionar como una Coupling Facility. Las CF no ejecutan ninguna aplicación de software.
  
  # Coupling Facility
  ## Estructuras de la Coupling Facility
  
  Las CF tienen tres propósitos:
  * Mantener información sobre bloqueos compartidos por todos los sistemas conectados.
  * Mantener información en caché (por ejemplo, de una base de datos) compartidos por todos los sistemas conectados.
  * Mantener fuentes de información compartidas por todos los sistemas conectados.
  Estos propósitos funcionan mediante tres tipos de estructuras:
  * Lock
  * Caché
  * List (y su variante Serialised List)
  Una estructura es una porción de memoria de la CF. Las aplicaciones acceden a las estructuras desde cualquier sistema que esté conectado a la CF. Una Sysplex Paralelo contiene diversas estructuras de cada tipo y cada aplicación puede usar varias de cada tipo. Por ejemplo, DB2 en un Data Sharing Group usa una estructura de Lock, una estructura de List y varias de Caché (una por cada Group Buffer Pool).
  
  # Coupling Facility
  ## Replicación de estructuras
  
  Las estructuras de una CF se puede replicar en diferentes CF, manteniendo dos copias de la misma estructura sincronizadas. La replicación es una parte fundamental de las instalaciones para eliminar puntos débiles y dar servicio ante cualquier incidencia por grave que sea. En caso de fallo de la CF, la réplica toma el control para responder a las peticiones.
  
  # Coupling Facility
  ## Niveles y explotación de la Coupling Facility
  
  El código del CFCC se mantiene en forma de niveles, normalmente conocido por "CFLEVEL". Por ejemplo, CFLEVEL 15 fue lanzado en abril de 2007. Cada nivel nuevo proporciona funcionalidades nuevas y mayor rendimiento, aunque en muchos casos las nuevas funcionalidades y las mejoras en rendimiento requieren como correquisito una versión de z/OS o nuevas funcionalidades en subsistemas (como DB2). Uno de esos ejemplos es la replicación de estructuras.
  
  # Coupling Facility
  ## Peticiones a la Coupling Facility
  
  La petición a una estructura de la CF puede ser de dos tipos:
  * Peticiones síncronas. Cuando un sistema z/OS envía una petición a la CF, supervisa continuamente la petición con uno de sus propios procesadores hasta que la petición finaliza. Las peticiones síncronas son rápidas pero el tiempo de respuesta es el mismo que el tiempo de procesador inutilizado.
  * Peticiones asíncronas. Cuando un sistema z/OS envía una petición a la CF no espera a que la petición finalice. Las peticiones asíncronas son más lentas que las síncronas (puesto que tienen menor prioridad en la CF) pero consumen menos tiempo de procesador inutilizado.
  En las aplicaciones de z/OS se usan tanto peticiones síncronas como asíncronas.
  
  # Coupling Facility
  ## Peticiones a la Coupling Facility
  ### Conversión de peticiones dinámica
  
  En el nivel CFLEVEL 4 se introdujo la funcionalidad de conversión de peticiones dinámicas. Esta funcionalidad permite tener sistemas y CF en la misma máquina sin que se produzcan bloqueos mutuos al realizar peticiones síncronas. Sin esta funcionalidad, una petición síncrona podría llegar a quedarse bloqueada puesto que la petición no podría acabar debido a que el procesador que efectuaba la petición era el mismo (debido a que una sola máquina física) que el procesador que tenía que procesar la petición. Una vez el sistema detectaba que se podía crear un bloqueo mutuo, convertía la petición en asíncrona, liberando el procesador.