Patch management (or patch management policy or patch policy or patch management process) is concerned with the identification, acquisition, distribution, testing and installation of patches to systems. Proper patch management can be a net productivity boost for an organization. Patches can be used to defend against and eliminate potential vulnerabilities of a system, so that no threats may exploit them. Problems can arise during patch management, including buggy patches that either fail to fix their problem or introduce new issues. Patch management tools help orchestrate all of the procedures involved in patch management. == Description == Patch management is defined as a sub-practice of various disciplines including vulnerability management (part of security management), lifecycle management (with further possible sub-classification into application lifecycle management and release management), change management, and systems management. The practice is broadly concerned with the identification, acquisition, distribution, and installation of patches to systems. Some definitions of patch management are as a software-level practice, while others are as a systems-level process: software, drivers, and firmware. == Cost–benefit analysis == While reserving time for patching takes up enterprise resources, there are balancing factors which can make proper patch management into a net productivity boost for an organization. Up-to-date systems often perform more efficiently, less costly, with less errors, less security risks, and better user workflow. Additionally, compliance with changing local and federal regulations are more likely to be satisfied. Patching security vulnerabilities has been one among many competing priorities for organizations, leading to longer periods before patching for some organizations. Equifax was too slow to implement its 2015 patch management plan to be able to mitigate or prevent the 2017 Equifax data breach, leading to scrutiny from regulators. == Relation to security management == Patches can be used to defend against and eliminate potential vulnerabilities of a system, so that no threats may exploit them; therefore, patch management can be considered a sub-discipline of vulnerability management. Every patchable device in a system presents an attack surface that must be secured. === Time plan === Automatic updates are where the patch is applied automatically with little to know actions or planning required. This approach is recommended for many individuals and organizations. Some organizations also have to prioritize which patches to prioritize given limited resources. Patch Tuesday is the most common process when major companies like Microsoft and Adobe release patches on a known date so that companies can plan resources around implementing the patches more quickly. Linux is open-sourced and patches can be released at any time, leading some to rely on mailing lists or other ways to be alerted to updates. === Inventory === Taking an inventory of software and hardware, including versions can make it easier to correlate with bugs or patches as they become known. Taking stock of how much education and support others in an organization need to install their patches can also help for planning how to implement the patch or design systems to begin with. Streamlining the process by using tools that can communicate with each other can also help to reduce the time of exposure to known vulnerabilities. == Challenges == There are a multitude of problems that can arise during patch management. A common issue is buggy patches, which either fail to fix their problem or introduce new issues. Another issue is deployment synchronization, since various subsystems may receive instructions to update at different times. Similarly, the difficulty of patch management across many devices may grow at an uncontrollable rate depending on organizational size. One prominent demonstration of the challenges facing proper patch management was the buggy Falcon Sensor patch by CrowdStrike which caused one of the worst IT outages of all time. == Implementations == A patch management tool (alternatively patch manager, patch management system, patch management software, or centralized patch management) help orchestrate all of the procedures involved in patch management. Tools can be in-house (applied locally by local administrators), or external, as with managed service providers (applied externally by a provider). === Patch management software === Windows Update for Business, System Center Configuration Manager, and Windows Server Update Services offer control over patch deployment, with features enabling testing, scheduling updates, and setting custom configurations on Windows platforms. === Managed service providers === == Regulatory requirements (United States) == Timely patching of software vulnerabilities is a requirement under multiple regulatory frameworks in the United States. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule requires covered entities to protect electronic protected health information by implementing security measures sufficient to reduce risks to a reasonable and appropriate level, which industry guidance has long interpreted to include timely patch management. A proposed new HIPAA Security Rule would make patch management requirements explicit, mandating that covered entities and business associates deploy security patches and updates within a defined risk-based timeline and maintain written procedures for prioritizing, testing, and applying patches to systems that store, process, or transmit ePHI. The 2025 proposal continues to receive industry pushback as of December 2025. HIPAA was last updated in 2013. The Payment Card Industry Data Security Standard (PCI DSS) requires organizations to protect system components from known vulnerabilities by installing applicable security patches within one month of release for critical patches. The Cybersecurity and Infrastructure Security Agency (CISA) maintains a Known Exploited Vulnerabilities (KEV) catalog that compels U.S. federal agencies to remediate listed vulnerabilities within specified timelines. Agencies are typically required to patch within 3 weeks, though some vulnerabilities must be fixed within 24 hours.
WebGPU Shading Language
WebGPU Shading Language (WGSL, internet media type: text/wgsl) is a high-level shading language and the normative shader language for the WebGPU API on the web. WGSL's syntax is influenced by Rust and is designed with strong static validation, explicit resource binding, and portability in mind for secure execution in browsers. In web contexts, WebGPU implementations accept WGSL source and perform compilation to platform-specific intermediate forms (for example, to SPIR‑V, DXIL, or MSL via the user agent), but such backends are not exposed to web content. == History and background == Graphics on the web historically used WebGL, with shaders written in GLSL ES. As applications demanded more modern GPU features and finer control over compute and graphics pipelines, the W3C's GPU for the Web Community Group and Working Group created WebGPU and its companion shading language, WGSL, to provide a secure, portable model suitable for the web platform. WGSL was developed to be human-readable, avoid undefined behavior common in legacy shading languages, and align closely with WebGPU's resource and validation model. == Design goals == WGSL's design emphasizes: Safety and determinism suitable for web security constraints (extensive static validation and well-defined semantics). Portability across diverse GPU backends via an abstract resource model shared with WebGPU. Readability and explicitness (no preprocessor, minimal implicit conversions, explicit address spaces and bindings). Alignment with modern GPU features (compute, storage buffers, textures, atomics) while retaining a familiar C/Rust-like syntax. == Language overview == === Types and values === Core scalar types include bool, i32, u32, and f32. Vectors (e.g., vec2, vec3, vec4) and matrices (up to 4×4) are available for floating-point element types. Optional f16 (half precision) may be enabled via a WebGPU feature; availability is implementation-dependent. Atomic types (atomic
Glossary of operating systems terms
This page is a glossary of Operating systems terminology. == A == access token: In Microsoft Windows operating systems, an access token contains the security credentials for a login session and identifies the user, the user's groups, the user's privileges, and, in some cases, a particular application. == B == binary semaphore: See semaphore. booting: In computing, booting (also known as booting up) is the initial set of operations that a computer performs after electrical power is switched on or when the computer is reset. This can take tens of seconds and typically involves performing a power-on self-test, locating and initializing peripheral devices, and then finding, loading and starting the operating system. == C == cache: In computer science, a cache is a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. cloud: Cloud computing operating systems are recent, and were not mentioned in Gagne's 8th Edition (2009). In contrast, by Gagne's 9th (2012), cloud o/s received 3 pages of coverage (41, 42, 716). Doeppner (2011) mentions them (p. 3), but only to prove that operating systems "are not a solved problem" and that even if the day of the dedicated PC is waning, cloud computing has created an entirely new opportunity for o/s development ala sharing, networks, memory, parallelism, etc. Gagne (2012) adds that in addition to numerous traditional o/s's at cloud warehouses, Virtual machine o/s (VMMs), Eucalyptus, Vware, vCloud Director and others are being developed specifically for cloud management with numerous traditional o/s features (security, threads, file and memory management, guis, etc.) (p. 42). Microsoft's investment in cloud aspects of o/s tend to support that argument. concurrency == D == daemon: Operating systems often start daemons at boot time and serve the function of responding to network requests, hardware activity, or other programs by performing some task. Daemons can also configure hardware (like udevd on some Linux systems), run scheduled tasks (like cron), and perform a variety of other tasks. == E == == F == == G == == H == == I == == J == == K == kernel: In computing, the kernel is a computer program that manages input/output requests from software and translates them into data processing instructions for the central processing unit and other electronic components of a computer. The kernel is a fundamental part of a modern computer's operating system. == L == lock: In computer science, a lock or mutex (from mutual exclusion) is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy. == M == mutual exclusion: Mutual exclusion is to allow only one process at a time to access the same critical section (a part of code which accesses the critical resource). This helps prevent race conditions. mutex: See lock. == N == == O == == P == paging daemon: See daemon. process == Q == == R == == S == semaphore: In computer science, particularly in operating systems, a semaphore is a variable or abstract data type that is used for controlling access, by multiple processes, to a common resource in a parallel programming or a multi user environment. == T == thread: In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler. The scheduler itself is a light-weight process. The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process. templating: In an o/s context, templating refers to creating a single virtual machine image as a guest operating system, then saving it as a tool for multiple running virtual machines (Gagne, 2012, p. 716). The technique is used both in virtualization and cloud computing management, and is common in large server warehouses. == U == == V == == W == == Z ==
Timeline of operating systems
This article presents a timeline of events in the history of computer operating systems from 1951 to the current day. For a narrative explaining the overall developments, see the History of operating systems. == 20th Century == == 1940s == 1949 EDSAC was considered the first operating system developed by Maurice Wilkes and manufactured by the University of Cambridge == 1950s == 1951 LEO I 'Lyons Electronic Office' was the commercial development of EDSAC computing platform, supported by British firm J. Lyons and Co. 1953 DYSEAC - an early machine capable of distributing computing 1955 General Motors Operating System made for IBM 701 MIT's Tape Director operating system made for UNIVAC 1103 1956 GM-NAA I/O for IBM 704, based on General Motors Operating System 1957 Atlas Supervisor (Manchester University) (Atlas computer project start) BESYS (Bell Labs), for IBM 704, later IBM 7090 and IBM 7094 1958 University of Michigan Executive System (UMES), for IBM 704, 709, and 7090 1959 SHARE Operating System (SOS), based on GM-NAA I/O == 1960s == 1960 IBSYS (IBM for its 7090 and 7094) 1961 CTSS demonstration (MIT's Compatible Time-Sharing System for the IBM 7094) MCP (Burroughs Master Control Program) for B5000 1962 Atlas Supervisor (Manchester University) (Atlas computer commissioned) BBN Time-Sharing System GCOS (GE's General Comprehensive Operating System, originally GECOS, General Electric Comprehensive Operating Supervisor) 1963 ADMIRAL AN/FSQ-32, another early time-sharing system begun CTSS becomes operational (MIT's Compatible Time-Sharing System for the IBM 7094) JOSS, an interactive time-shared system that did not distinguish between operating system and language Titan Supervisor, early time-sharing system begun 1964 Berkeley Timesharing System (for Scientific Data Systems' SDS 940) Chippewa Operating System (for CDC 6600 supercomputer) Dartmouth Time-Sharing System (Dartmouth College's DTSS for GE computers) EXEC 8 (UNIVAC) KDF9 Timesharing Director (English Electric) – an early, fully hardware secured, fully pre-emptive process switching, multi-programming operating system for KDF9 (originally announced in 1960) OS/360 (IBM's primary OS for its S/360 series) (announced) PDP-6 Monitor (DEC) descendant renamed TOPS-10 in 1970 SCOPE (CDC 3000 series) 1965 BOS/360 (IBM's Basic Operating System) DECsys TOS/360 (IBM's Tape Operating System) Livermore Time Sharing System (LTSS) Multics (MIT, GE, Bell Labs for the GE-645) (announced) Pick operating system SIPROS 66 (Simultaneous Processing Operating System) THE multiprogramming system (Technische Hogeschool Eindhoven) development TSOS (later VMOS) (RCA) 1966 DOS/360 (IBM's Disk Operating System) GEORGE 1 & 2 for ICT 1900 series Mod 1 Mod 2 Mod 8 MS/8 (Richard F. Lary's DEC PDP-8 system) MSOS (Mass Storage Operating System) OS/360 (IBM's primary OS for its S/360 series) PCP and MFT (shipped) RAX Remote Users of Shared Hardware (RUSH), a time-sharing system developed by Allen-Babcock for the IBM 360/50 SODA for Elwro's Odra 1204 Universal Time-Sharing System (XDS Sigma series) 1967 CP-40, predecessor to CP-67 on modified IBM System/360 Model 40 CP-67 (IBM, also known as CP/CMS) Conversational Programming System (CPS), an IBM time-sharing system under OS/360 Michigan Terminal System (MTS) (time-sharing system for the IBM S/360-67 and successors) ITS (MIT's Incompatible Timesharing System for the DEC PDP-6 and PDP-10) OS/360 MVT ORVYL (Stanford University's time-sharing system for the IBM S/360-67) TSS/360 (IBM's Time-sharing System for the S/360-67, never officially released, canceled in 1969 and again in 1971) WAITS (SAIL, Stanford Artificial Intelligence Laboratory, time-sharing system for DEC PDP-6 and PDP-10, later TOPS-10) 1968 Airline Control Program (ACP) (IBM) B1 (NCR Century series) CALL/360, an IBM time-sharing system for System/360 HP Real-Time Executive (HP RTE) – Hewlett-Packard HP Time-Shared BASIC (HP TSB) – Hewlett-Packard (time-sharing system for the HP 2000) THE multiprogramming system (Eindhoven University of Technology) publication TSS/8 (DEC for the PDP-8) VP/CSS 1969 B2 (NCR Century series) B3 (NCR Century series) GEORGE 3 For ICL 1900 series MINIMOP Multics (MIT, GE, Bell Labs for the GE-645 and later the Honeywell 6180) (opened for paying customers in October) RC 4000 Multiprogramming System (RC) TENEX (Bolt, Beranek and Newman for DEC systems, later TOPS-20) Unics (later Unix) (AT&T, initially on DEC computers) Xerox Operating System == 1970s == 1970 DOS-11 (PDP-11) 1971 EMAS Kronos RSTS-11 2A-19 (First released version; PDP-11) RSX-15 OS/8 1972 B4 (NCR Century series) COS-300 Data General RDOS Edos MUSIC/SP OS/4 OS 1100 OS/2000 (Honeywell 2000-series) Operating System/Virtual Storage 1 (OS/VS1) Operating System/Virtual Storage 2 R1 (OS/VS2 SVS) PRIMOS (written in FORTRAN IV, that didn't have pointers, while later versions, around version 18, written in a version of PL/I, called PL/P) Virtual Machine/Basic System Extensions Program Product (BSEPP or VM/SE) Virtual Machine/System Extensions Program Product (SEPP or VM/BSE) Virtual Machine Facility/370 (VM/370), sometimes known as VM/CMS 1973 Эльбрус-1 (Elbrus-1) – Soviet computer – created using high-level language uЭль-76 (AL-76/ALGOL 68) Alto OS CP-V (Control Program V) RSX-11D RT-11 VME – implementation language S3 (ALGOL 68) 1974 ACOS-2 (NEC) ACOS-4 ACOS-6 CP/M DOS-11 V09-20C (Last stable release, June 1974) Hydra – capability-based, multiprocessing OS kernel MONECS Multi-Programming Executive (MPE) – Hewlett-Packard Operating System/Virtual Storage 2 R2 (MVS) OS/7 OS/16 OS/32 Sintran III 1975 BS2000 V2.0 (First released version) COS-350 ISIS NOS (Control Data Corporation) OS/3 (Univac) VS/9 (formerly RCA's TSOS, later named VMOS) Version 6 Unix XVM/DOS XVM/RSX 1976 Cambridge CAP computer – all operating system procedures written in ALGOL 68C, with some closely associated protected procedures in BCPL Cray Operating System DX10 FLEX TOPS-20 TX990/TXDS Tandem Nonstop OS v1 Thoth 1977 1BSD AMOS KERNAL OASIS operating system OS68 OS4000 RMX-80 System 88 (Exec) System Support Program (IBM System/34 and System/36) TRSDOS Virtual Memory System (VMS) V1.0 (Initial commercial release, October 25) VRX (Virtual Resource eXecutive) VS Virtual Memory Operating System 1978 2BSD Apple DOS Control Program Facility (IBM System/38) Cray Time Sharing System (CTSS) DPCX (IBM) DPPX (IBM) HDOS KSOS – secure OS design from Ford Aerospace KVM/370 – security retro-fit of IBM VM/370 Lisp machine (CADR) MVS/System Extensions (MVS/SE) OS4 (Naked Mini 4) PTDOS TRIPOS UCSD p-System (First released version) Z80-RIO 1979 Atari DOS 3BSD CP-6 Idris MP/M MVS/System Extensions R2 (MVS/SE2) NLTSS POS Sinclair BASIC Transaction Processing Facility (TPF) (IBM) UCLA Secure UNIX – an early secure UNIX OS based on security kernel UNIX/32V DOS/VSE Version 7 Unix == 1980s == 1980 86-DOS AOS/VS (Data General) Business Operating System CTOS DOSPLUS (TRS-80) MVS/System Product (MVS/SP) V1 NewDos/80 OS-9 RMX-86 RS-DOS SOS Virtual Machine/System Product (VM/SP) Xenix 1981 Acorn MOS Aegis SR1 (First Apollo/DOMAIN systems shipped on March 27) CP/M-86 DRX (Distributed Resource Executive) iMAX – OS for Intel's iAPX 432 capability machine MCS (Multi-user Control System) MS-DOS PC DOS Pilot (Xerox Star operating system) UNOS UTS V VERSAdos VRTX VSOS (Virtual Storage Operating System) Xinu first release 1982 Commodore DOS LDOS (By Logical Systems, Inc. – for the Radio Shack TRS-80 Models I, II & III) PCOS (Olivetti M20) pSOS QNX Stratus VOS Sun UNIX (later SunOS) 0.7 Ultrix Unix System III VAXELN 1983 Coherent DNIX EOS GNU (project start) Lisa Office System 7/7 LOCUS – UNIX compatible, high reliability, distributed OS MVS/System Product V2 (MVS/Extended Architecture, MVS/XA) Novell NetWare (S-Net) PERPOS ProDOS RTU (Real-Time Unix) STOP – TCSEC A1-class, secure OS for SCOMP hardware SunOS 1.0 VSE/System Package (VSE/SP) Version 1 1984 AMSDOS CTIX (Unix variant) DYNIX Mac OS (System 1.0) MSX-DOS NOS/VE PANOS PC/IX ROS Sinclair QDOS SINIX UNICOS Venix 2.0 Virtual Machine/Extended Architecture Migration Assistance (VM/XA MA) 1985 AmigaOS Atari TOS DG/UX DOS Plus Graphics Environment Manager Harmony MacOS 2 MIPS RISC/os Oberon – written in Oberon SunOS 2.0 Version 8 Unix Virtual Machine/Extended Architecture System Facility (VM/XA SF) Windows 1.0 Windows 1.01 Xenix 2.0 1986 AIX 1.0 Cronus distributed OS FlexOS GEMSOS – TCSEC A1-class, secure kernel for BLACKER VPN & GTNP GEOS Genera 7.0 HP-UX MacOS 3 SunOS 3.0 TR-DOS TRIX Version 9 Unix 1987 Arthur (much improved version came in 1989 under the name RISC OS) BS2000 V9.0 IRIX (3.0 is first SGI version) MacOS 4 MacOS 5 MDOS MINIX 1.0 OS/2 (1.0) PC-MOS/386 Topaz – semi-distributed OS for DEC Firefly workstation written in Modula-2+ and garbage collected VxWorks Windows 2.0 1988 A/UX (Apple Computer) AOS/VS II (Data General) CP/M rebranded as DR-DOS Flex machine – tagged, capability machine with OS and other software written
Line splice
In electrical engineering and telecommunications, a line splice is a joint directly connecting lengths of electrical cables (electrical splice) or optical fibers (optical splice). The splices are often protected by sleeves. == Splicing of copper wires == The splicing of copper wires happens in the following steps: The cores are laid one above the other at the junction. The core insulation is removed. The wires are wrapped two to three times around each other (twisting). The bare veins on a length of about 3 cm "strangle" or "twist". In some cases, the strangulation is soldered. To isolate the splice, an insulating sleeve made of paper or plastic is pushed over it. The splicing of copper wires is mainly used on paper insulated wires. LSA techniques (LSA: soldering, screwing and stripping free) are used to connect copper wires, making the copper wires faster and easier to connect. LSA techniques include: Wire connection sleeves (AVH = Adernverbindungshülsen) and other crimp connectors. The two wires to be connected are inserted into the AVH without being stripped, which is then compressed with special pliers. The about 2 cm long AVH consist of contact, pressure and insulation. For wire connection strips (AVL = Adernverbindungsleisten) several pairs of wires (10 = AVL10 or 20 = AVL20) are inserted, the strip is then closed with a lid and pressed together with a hydraulic press, which ensures the connection. == Splicing of glass fibers == Fiber-optic cables are spliced using a special arc-splicer, with installation cables connected at their ends to respective "pigtails" - short individual fibers with fiber-optic connectors at one end. The splicer precisely adjusts the light-guiding cores of the two ends of the glass fibers to be spliced. The adjustment is done fully automatically in modern devices, whereas in older models this is carried out manually by means of micrometer screws and microscope. An experienced splicer can precisely position the fiber ends within a few seconds. Subsequently, the fibers are fused together (welded) with an electric arc. Since no additional material is added, such as gas welding or soldering, this is called a "fusion splice". Depending on the quality of the splicing process, attenuation values at the splice points are achieved by 0.3 dB, with good splices also below 0.02 dB. For newer generation devices, alignment is done automatically by motors. Here one differentiates core and jacket centering. At core centering (usually single-mode fibers), the fiber cores are aligned. A possible core offset with respect to the jacket is corrected. In the jacket centering (usually in multimode fibers), the fibers are adjusted to each other by means of electronic image processing in front of the splice. When working with good equipment, the damping value is according to experience at max. 0.1 dB. Measurements are made by means of special measuring devices including optical time-domain reflectometry (OTDR). A good splice should have an attenuation of less than 0.3 dB over the entire distance. Finished fiber optic splices are housed in splice boxes. One differentiates: Fusion splice Adhesive splicing Crimp splice or NENP (no-epoxy no-polish), mechanical splice
IDMS
The Integrated Database Management System (IDMS) is a network model (CODASYL) database management system for mainframes. It was first developed at BFGoodrich and later marketed by Cullinane Database Systems (renamed Cullinet in 1983). Since 1989 the product has been owned by Computer Associates (now CA Technologies), who renamed it Advantage CA-IDMS and later simply to CA IDMS. In 2018 Broadcom acquired CA Technologies, renaming it back to IDMS. == History == The roots of IDMS go back to the pioneering database management system called Integrated Data Store (IDS), developed at General Electric by a team led by Charles Bachman and first released in 1964. In the early 1960s IDS was taken from its original form, by the computer group of the BFGoodrich Chemical Division, and re-written in a language called Intermediate System Language (ISL). ISL was designed as a portable system programming language able to produce code for a variety of target machines. Since ISL was actually written in ISL, it was able to be ported to other machine architectures with relative ease, and then to produce code that would execute on them. The Chemical Division computer group had given some thought to selling copies of IDMS to other companies, but was told by management that they were not in the software products business. Eventually, a deal was struck with John Cullinane to buy the rights and market the product. Because Cullinane was required to remit royalties back to B.F. Goodrich, all add-on products were listed and billed as separate products – even if they were mandatory for the core IDMS product to work. This sometimes confused customers. The original platforms were the GE 235 computer and GE DATANET-30 message switching computer: later the product was ported to IBM mainframes and to DEC and ICL hardware. The IBM-ported version runs on IBM mainframe systems (System/360, System/370, System/390, zSeries, System z9). In the mid-1980s, it was claimed that some 2,500 IDMS licenses had been sold. Users included the Strategic Air Command, Ford of Canada, Ford of Europe, Jaguar Cars, Clarks Shoes UK, Axa/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Cleveland Clinic, Bank of Canada, General Electric, Aetna and BT in the UK. A version for use on the Digital Equipment Corporation PDP-11 series of computers was sold to DEC and was marketed as DBMS-11. In 1976 the source code was licensed to ICL, who ported the software to run on their 2900 series mainframes, and subsequently also on the older 1900 range. ICL continued development of the software independently of Cullinane, selling the original ported product under the name ICL 2900 IDMS and an enhanced version as IDMSX. In this form it was used by many large UK users, an example being the Pay-As-You-Earn system operated by Inland Revenue. Many of these IDMSX systems for UK Government were still running in 2013. In the early to mid-1980s, relational database management systems started to become more popular, encouraged by increasing hardware power and the move to minicomputers and client–server architecture. Relational databases offered improved development productivity over CODASYL systems, and the traditional objections based on poor performance were slowly diminishing. Cullinet attempted to continue competing against IBM's DB2 and other relational databases by developing a relational front-end and a range of productivity tools. These included Automatic System Facility (ASF), which made use of a pre-existing IDMS feature called LRF (Logical Record Facility). ASF was a fill-in-the-blanks database generator that would also develop a mini-application to maintain the tables. It is difficult to judge whether such features may have been successful in extending the selling life of the product, but they made little impact in the long term. Those users who stayed with IDMS were primarily interested in its high performance, not in its relational capabilities. It was widely recognized (helped by a high-profile campaign by E. F. Codd, the father of the relational model) that there was a significant difference between a relational database and a network database with a relational veneer. In 1989 Computer Associates continued after Cullinet acquisition with the development and released Release 12.0 with full SQL in 1992–93. CA Technologies continued to market and support the CA IDMS and enhanced IDMS in subsequent releases by TCP/IP support, two phase commit support, XML publishing, zIIP specialty processor support, Web-enabled access in combination with CA IDMS Server, SQL Option and GUI database administration via CA IDMS Visual DBA tool. CA-IDMS systems are today still running businesses worldwide. Many customers have opted to web-enable their applications via the CA-IDMS SQL Option which is part of CA Technologies' Dual Database Strategy. == Integrated Data Dictionary == One of the sophisticated features of IDMS was its built-in Integrated data dictionary (IDD). The IDD was primarily developed to maintain database definitions. It was itself an IDMS database. DBAs (database administrators) and other users interfaced with the IDD using a language called Data Dictionary Definition Language (DDDL). IDD was also used to store definitions and code for other products in the IDMS family such as ADS/Online and IDMS-DC. IDD's power was that it was extensible and could be used to create definitions of just about anything. Some companies used it to develop in-house documentation. == Overview == === Logical Data Model === The data model offered to users is the CODASYL network model. The main structuring concepts in this model are records and sets. Records essentially follow the COBOL pattern, consisting of fields of different types: this allows complex internal structure such as repeating items and repeating groups. The most distinctive structuring concept in the Codasyl model is the set. Not to be confused with a mathematical set, a Codasyl set represents a one-to-many relationship between records: one owner, many members. The fact that a record can be a member in many different sets is the key factor that distinguishes the network model from the earlier hierarchical model. As with records, each set belongs to a named set type (different set types model different logical relationships). Sets are in fact ordered, and the sequence of records in a set can be used to convey information. A record can participate as an owner and member of any number of sets. Records have identity, the identity being represented by a value known as a database key. In IDMS, as in most other Codasyl implementations, the database key is directly related to the physical address of the record on disk. Database keys are also used as pointers to implement sets in the form of linked lists and trees. This close correspondence between the logical model and the physical implementation (which is not a strictly necessary part of the Codasyl model, but was a characteristic of all successful implementations) is responsible for the efficiency of database retrieval, but also makes operations such as database loading and restructuring rather expensive. Records can be accessed directly by database key, by following set relationships, or by direct access using key values. Initially the only direct access was through hashing, a mechanism known in the Codasyl model as CALC access. In IDMS, CALC access is implemented through an internal set, linking all records that share the same hash value to an owner record that occupies the first few bytes of every disk page. In subsequent years, some versions of IDMS added the ability to access records using BTree-like indexes. === Storage === IDMS organizes its databases as a series of files. These files are mapped and pre-formatted into so-called areas. The areas are subdivided into pages which correspond to physical blocks on the disk. The database records are stored within these blocks. The DBA allocates a fixed number of pages in a file for each area. The DBA then defines which records are to be stored in each area, and details of how they are to be stored. IDMS intersperses special space-allocation pages throughout the database. These pages are used to keep track of the free space available in each page in the database. To reduce I/O requirements, the free space is only tracked for all pages when the free space for the area falls below 30%. Four methods are available for storing records in an IDMS database: Direct, Sequential, CALC, and VIA. The Fujitsu/ICL IDMSX version extends this with two more methods, Page Direct, and Random. In direct mode the target database key is specified by the user and is stored as close as possible to that DB key, with the actual DB key on which the record is stored being returned to the application program. Sequential placement (not to be confused with indexed sequential), simply places each new record at the end of the area. This option is rarely used. CALC uses a hashing algo
Fifth Estate
The Fifth Estate is a socio-cultural reference to groupings of outlier viewpoints in contemporary society, and is most associated with bloggers, journalists publishing in non-mainstream media outlets, and online social networks. The "Fifth" Estate extends the sequence of the three classical estates (clergy (first), nobility (second), commoners (third)) and the preceding Fourth Estate, essentially the common press. The use of "fifth estate" dates to the 1960s counterculture, and in particular the influential Fifth Estate, an underground newspaper first published in Detroit in 1965. Web-based technologies have enhanced the scope and power of the Fifth Estate far beyond the modest and boutique conditions of its beginnings. Nimmo and Combs asserted in 1992 that political pundits constitute a Fifth Estate. Media researcher Stephen D. Cooper argued in 2006 that bloggers are the Fifth Estate. In 2009, William Dutton argued that the Fifth Estate is not just the blogging community, nor an extension of the media, but "networked individuals" enabled by the Internet, e.g. social media, in ways that can hold the other estates accountable.