Note: This section applies to AIX Version 4 systems.
AIX drivers has been updated to provide for Power Management (PM) support. PM is a technique that enables hardware and software to minimize system power consumption. PM is generally only important to low-end models, such as Notebooks and systems operating on battery.
When Power Management is enabled, the system enters a power-saving mode under a number of conditions including the expiration of the idle timer, a direct command from the user, a low battery, or the closing of the Notebook lid. PM state transitions include: enable, standby, suspend, hibernation, and shutdown. Each transition implies further decreasing the power supply to the various system components. Only the suspend, hibernation, and shutdown states have any impact on X.25 connections.
Refer to "Management Power Management" in AIX Version 4.3 System Management Guide: Operating System and Devices for more detailed information on Power Management and its configuration and function.
From an X.25 standpoint, bringing a system to the suspend, hibernation, or shutdown states results in loss of power to the adapters. All network connections are lost. Externally, this can be viewed as pulling the physical connection (cable), since there is a complete loss of signal power at the physical layer.
Since all signals are dropped at the physical layer, there is no opportunity for the local DTE packet layer to send out clear requests to the DCE packet layer. Similarly, the frame layer does not go through the usual DISC/UA sequence prior to bringing down the link level. All X.25 connections remain down until the system is re-enabled.
Once power is restored, all X.25 physical connections previously up are restored. Two possible exceptions are dial-up connections and ports controlled directly by DLPI applications. For dial-up, even though the physical layer is reinitialized for two-way activation, these connections are only physically reconnected when there is user activity, such as an outgoing call request or an incoming call. Likewise, for DLPI ports, it is necessary for the applications to reconnect (DL_CONNECT request) to activate the port.
Note: Restoring an X.25 connection refers to bringing up the physical, frame, and packet layers between the local DTE and DCE. Switched virtual circuits (SVCs) that were active before the power loss have been cleared. Permanent virtual circuits (PVCs) have been reset. It is up to the corresponding applications to re-establish the SVCs and properly resynchronize the PVCs.
A system shutdown impacts X.25 applications differently than either a suspend or hibernation transition. In the case of a shutdown, all user applications are terminated. With a system shutdown, no attempt is made to preserve the current user state before powering off. On bring-up, those ports and interfaces defined in the ODM are newly configured. All X.25 user application need to be restarted after power-on.
In the case of the suspend and hibernation states, there is an attempt to preserve as much of the current system state as possible in order to make the off-on cycle transparent to user applications. All user applications remain active. For X.25, however, the network connections have been physically lost and restarted. Losing the network connections directly impacts X.25 applications. The Power Management suspend and hibernation power-off and power-on cycles are generally not completely transparent.
The following highlights the expected behaviors during a PM suspend or hibernation power-off and power-on cycle for each of the programming interfaces:
| DLPI | |
| Receives a DL_DISCONNECT indication. It is up to the DLPI application to properly handle the indication. The port is not activated until a new DL_CONNECT request is issued by the application. It is not necessary to re-bind to the port since all the DL_BINDs are maintained. For detailed information on DLPI, refer to the "DLPI Overview". | |
| TCP/IP | Provides a highly robust and transparent interface. In most cases, it is transparent to the application that the underlying virtual circuit was reset or cleared. As long as the application remains active, the X.25 IF driver attempts to re-establish the virtual circuit. If it succeeds in establishing the connection, the power-off/power-on cycle is transparent to the application. For information on sockets, refer to "Sockets Overview" in AIX Version 4.3 Communications Programming Concepts. For information on TCP/IP commands, refer to AIX Version 4.3 Commands Reference. |
| NPI | Receives N_DISCON_INDs on all active SVCs. Likewise, N_RESET_INDs (RESET_reason: N_NET_LINK_DOWN/N_NET_LINK_UP) are received on all configured and bound PVCs. The application needs to properly handle these primitives. Note that all N_BIND_REQs are maintained as long as the application does not unbind, close, or exit. This implies that all PVCs remain bound, and all listens are still active. All SVCs need to be re-established through new N_CONN_REQs/N_CONN_INDs. For detailed information on NPI, refer to the "NPI Overview". |
| COMIO Emulation | In the case of a base X.25 API application running through the COMIO emulator, all active calls (SVCs) are cleared and all PVCs are reset. Before the sessions are re-established, the application needs to ensure that it has properly handled the completion of the aborted sessions. A Library API user needs to read all clears and resets (x25_receive), while an application using the COMIO emulator need to complete a CIO_HALT/ CIO_HALT_DONE cycle for all sessions. It is not necessary for the application to reinitialize (x25_init), reattach any PVCs (x25_pvc_alloc/ CIO_START-logical_channel), or re-establish any listens (x25_listen/ CIO_START-listen_name). However, it is up to the application to re-establish any SVCs (x25_call/CIO_START, x25_call_accept/ CIO_START). For detailed information on the base X.25 API, refer to "X.25 Application Programming Interface" in "Common Input/Output Emulation". |
| PAD | All active PAD connections are cleared. If using the xspad application, a CLEAR is received on all active sessions. PAD sessions can be re-established by issuing the appropriate CALL commands. For more detailed PAD information, refer to "Packet Assembler/Disassembler (PAD) Overview". |
The following is a list of Power Management warnings: