March 14, 2020
The Apple Coax/Twinax Card was an expansion card that allowed Macintosh II family of systems to connect to an IBM System Network Architecture network as a 3270 Information Display Systems via coax cabling. The card allowed users to access mainframe-based 3270 applications in the same manner as they would from a terminal while enjoying all of the benefits of Macintosh technology for their local applications. The Apple Coax/Twinax Card also touted a twinax connector for any future 5250 terminal emulation support. This intelligent NuBus interface card had its own 68000 microprocessor, memory, and multitasking operating system. Operating independently of the main Macintosh II processor, the Apple Coax/Twinax Card supported the execution of communications protocols with minimal access to the Macintosh II processor and operating system.
The MacDFT (Distributed Function Terminal) application software worked with the Apple Coax/Twinax Card to allow single-session Control Unit Terminal (CUT) emulation or up to five-session Distributed Function Terminal (DFT) 3270 emulation. Files were transferred to or from mainframes running VM/CMS or MVS/TSO using the IBM
IND$FILE package. MacDFT supported text, binary, and MacBinary file transfers. MacDFT stayed active in the background under MultiFinder Copy and paste functions between the Macintosh and mainframe applications were supported using the Clipboard. This allowed the user to transfer data easily between an application on the mainframe and a local application on the Macintosh desktop. The Apple 3270 API, a high level application programming interface, gave application developers a consistent platform for developing customized 3270 applications.
The Apple 3270 API, a high-level application programming interface, gave application developers a consistent platform for developing customized 3270 applications. Because the Apple 3270 API is based on the IBM 3270 PC High Level Language Application Programming Interface (HLLAPI), application programmers were able to apply their knowledge of HLLAPI to develop Macintosh-to-mainframe applications. The API was designed to allow terminal emulators, file-transfer programs, and other Macintosh applications and tools, such as CL/1 and MacWorkStations to use the 3270 services without being aware of the physical network connection details of coax, Token Ring, and SDLC. The Apple 3270 API established and terminated sessions with a mainframe, maintained context separation between multiple mainframe sessions, and sent 3270 keystrokes to the mainframe.
CL/1 gave Macintosh applications access to shared data on VMS systems while allowing developers to deal with the Macintosh application, not with the network and VMS programming. CL/1 was a new connectivity language that gave Macintosh applications access to data stored in native files and databases on a host computer system.
The host system could have been a Digital VAX, running VAX/VMS, or an IBM mainframe, running MVS or VM/CMS, or a minicomputer running UNIX. CL/1 was developed by Network Innovations Corporation, a wholly owned subsidiary of Apple Computer, Inc. The goal of CL/1 was to provide an open, standard host data-access language that enables plug-and-play connectivity between desktop applications and organizational data. As a result, an out-of-the-box desktop application using CL/1 would have been able to access data on a CL/1-supported host system, and to make that information an integral part of the data available to the desktop application user.
Using CL/1, a desktop application, such as a spreadsheet or word processor, would request and update host data processing (DP) data in a uniform manner, independent of variations in network technology, host system architecture, or database systems. The role of CL/1 was to insulate the desktop application from those details and differences, allowing it to concentrate, instead, on providing better interaction between personal processing on the desktop and organizational computing on the host system.
This is a digitized version of an article from The New York Times’s print archive dated March 3, 1988, Section D, Page 5 →
Apple Computer Inc. said today that it had agreed to acquire the Network Innovations Corporation, its first acquisition of another computer technology company.
Network Innovations, a small privately held company, makes software that allows personal computers to connect to larger mainframe systems and to minicomputers. Its software, known as CL/1, is a crucial cog in a recent alliance of Apple and the Digital Equipment Corporation to allow Apple’s Macintoshes to work better with Digital’s VAX minicomputers.
Terms of the acquisition were not disclosed. The deal seems to reflect a new willingness by cash-rich Apple to buy companies and is expected to be followed by more strategic acquisitions.
Apple has recently made equity investments in several small companies that sell software and hardware, but until today it had not purchased any of those companies. Its only previous acquisition was Miscoe, a tiny Canadian concern that services computers.
Network Innovations, based in Apple’s hometown of Cupertino, Calif., has about a dozen employees and revenues of less than $5 million.
Instead of separate facilities for each host database and network connection, CL/1 allowed the Macintosh developer to implement a single host data-access facility. With CL/1, Macintosh developers focused on integrating host data into the Macintosh application, instead of on network and host programming. Macintosh applications would thus become user-friendly front ends for accessing and manipulating shared data on the host system.
CL/1 was an enabling technology for applications developers. Its benefit to desktop system users came through the desktop applications that supported it. The objectives of CL/1 were to:
CL/1 provided an entirely new reason for Macintosh owners to purchase applications: ease of integration of host information into personal computer documents, spreadsheets, and other files. The burden on the MIS department to create special extract files, download procedures, and other special-case facilities for personal computers could have been greatly reduced as CL/1-capable applications utilized standard facilities to interoperate with the host-processing environment. CL/1 changed the paradigm of host access from simple terminal emulation to more sophisticated integration between desktop and mainframe. As end users learned of the power that this change brought them, applications that included CL/1 became the preferred purchase for many corporations.
In the first half of 1990, the CL/1 client interface became fully integrated into the Macintosh Toolbox, and as such, became part of every Macintosh system, allowing client access to CL/1 services at no additional charge. The imbedded CL/1 client interface was discussed during the 1989 Spring Developers’ Conference and is known as the Database Manager. The CL/1 server was sold by host computer manufacturers, or the server API would be imbedded into host database systems, in addition to direct sales of the CL/1 server by Network Innovations and Apple. Consequently, over time CL/1 became widely available from many sources.
CL/1 became a standard mechanism for developers to utilize across platforms to provide host data access. In addition to the Macintosh, CL/1 became available for MS-DOS, and OS/2 client environments. Host database systems supported by CL/1 included DB2 and SQL/DS on IBM systems, RDB and flat files on Digital VAX/VMS systems, and Oracle, Ingres, Informix and Sybase database servers. This capability provided applications developers with competitive advantages, as well as new challenges, to maintain the Macintosh user interface in a world where data come from any host, anywhere.
Developers could win by providing CL/1 access directly within their application. Immediately, programs would be transformed from a stand-alone application dependent on traditional means for data entry and access to one that could proactively access data on host computers and database systems with CL/1 servers. The end user would continue to use the same familiar application, only in a new more powerful way.
This meant that developers could “free associate” their application design incorporating CL/1. Almost any category of business activity performed on personal computers could be enhanced through access to host computer data. What’s more, the host data originated from the data center, users’ interactions with and manipulation of the data maintained the personal experience between users and their business needs.
Developers Tools Express vol. 1, no.2, page 5 featured the following networking and communications part numbers and their corresponding prices.
Technical Answerline: Networking & Communications (N&C) Option, M0595LL/A | $1,175.00
CL/1 Connectivity Language Description, Second Edition, C0141LL/A | $35.00
CL/1 Developer’s Toolkit for the Macintosh v. 1.1, M9004LL/B, | $695.00
CL/1 Server for VM/CMS v. 1.1, C0163LL/A | $15,000.00
CL/1 Server for MVS/TSO v. 1.1, C0164LL/A | $20,000.00
CL/1 Server for VAX/VMS (9-Track Tape Format) v. 1.1, C0142LL/B | $5,000.00
CL/1 Server for VAXNMS (TK50 Tape Format) v. 1.1, C0143LL/B | $5,000.00
One of the best examples of a CL/1 application would be a form of an Executive Information System (EIS). At the time, while EIS products existed for other computers, they usually required an intermediate data-extraction process from the corporate mainframe into a different database system before the volumes of data could be processed into information that an executive could use. With CL/1, an EIS was able to circumvent the time-consuming process, reduce the workload on the host computer system, and make the data that an executive used much more timely.
Apple wanted developers of virtually all categories and types of applications to consider CL/1 carefully in their development plans. In the latter part of 1989, Apple and Network Innovations provided Developer Technical Support, developer documentation, marketing support, and toolkits to those developers who accepted the challenge and opportunities that CL/1 provided.
To develop CL/1-aware applications for the Macintosh, the equipment and documentation listed below was needed:
The network connection between the Macintosh and host systems can be a direct or dial-up serial connection, over a network using ADSP. CL/1 insulates Macintosh client applications from variations in networks, in host operating systems, and in host database management systems.
CL/1 was a distributed processing facility with a client/server architecture. The key components of a complete CL/1 installation were as follows:
CL/1 presented a coprocessing model of operation to its client application. The client application “saw” a CL/1 runtime environment on the other side of the CL/1 API, which acted as the applications connectivity agent. The application sent requests across the API and received back upon demand the results, if any, of those requests. To the client application, the CL/1 runtime environment appeared to operate in parallel, as if it had its own processor with its own access to various networks, host systems, and host data sources. Control was immediately returned back to the client application, which proceeded with other work.
The coprocessing model used by CL/1 provided great flexibility in the underlying implementation. On desktop systems with limited resources, the runtime environment provided almost entirely by the CL/1 server on the host system, with the client system acting only as a means to forward and receive messages. In a more powerful desktop environment, the CL/1 runtime environment could have been provided locally, making requests of the host server only when host data was specifically required. The model could also be implemented using an actual coprocessor to provide the CL/1 runtime environment, with the advantage of parallelism.
CL/1 had the same basic elements found in programming languages such as C or Pascal. The structure of CL/1 was strongly influenced by the statement orientation of SQL, which formed the basis of its data manipulation facilities; indeed, all CL/1 statements had a SQL style, with an initial verb, one or more English-like clauses, and a statement terminator.
CL/1 provides much more than just a mechanism to allow applications to connect to database systems. It includes:
CL/1 includes automatic data translation when transferring data between the client (workstation) and server (host) systems. The language supports a set of standard data types that are used to represent all data manipulated by CL/1 programs. Data from a host source is automatically mapped into these standard data types when data is accessed. Descriptions of the host data source are also expressed in terms of the standard CL/1 types.
CL/1 provided uniform error handling for all supported host data sources. All errors are mapped into a standard set of CL/1 error codes, which are presented to the client application by the CL/1 API. The runtime environment offered two styles of error handling: one required the application to handle the situation-the CL/1 program aborts; the other continues execution of CL/1-CL/1 handles the error and any required recovery (the client application actually may never know that an error took place).
CL/1 presented the client application with a uniform model of the host access, database organization, and database structure. The CL/1 server was responsible for presenting each supported host DBMS, host system, and network in terms of this model. The objects described below - hostname, DBMS brand, database, tables, rows, columns, and linksets were manipulated by CL/1 language statements to perform the connectivity tasks specified by the client application.
Multiple hosts, identified by hostname, may exist in the network. If the client had sufficient capacity, it may itself be a host system.
Together with the hosts, one or more host DBMS systems, identified as DBMS brand, may be accessible. The DBMS brand may be an Oracle database, or it may be a set of DP tools that together provide DBMS functionality (such as RMS, CDD, and Datatrieve under VAX/VMS). For each DBMS brand on each host, zero or more databases are available.
A database consists of one or more named tables which contain its data, organized into rows and columns. Each row of at a table has the same column structure as the other rows. Each column of a table has a name and an associated data type.
Finally, a database may also contain one or more linksets, which specify one-to-many directed relationships between pairs of tables. Linksets represent the implicit relationships that carry essential data in hierarchical databases, such as IBM’s IMS, and network (CODASYL) databases, such as VAX DBMS.
CL/1 maintained the security and integrity of host data by operating under the facilities provided by the host operating system and DBMS software.
On the host system, the CL/1 server operated as a user-level process, subject to the same security restrictions as other user-level host applications. CL/1 similarly operated under the data-integrity constraints imposed by the host system and DBMS software. If a CL/1 client application attempted to modify host data in a way that would violate a database integrity constraint, the DBMS error caused by the attempt was reported back to the client application by CL/1, and the data remained unmodified. In addition, the CL/1 ROLLBACK and COMMIT statements provided access to the transaction-based integrity features provided by the host DBMS. Because CL/1 operated under existing host and DBMS security and integrity schemes, it introduced no new host security or integrity requirements.
The IBM-Apple alliance implied that more and more Macintosh systems and their successors were likely to turn up linked to IBM mainframes, and to that end, Apple announced the SNA.ps — a family of micro-to-IBM mainframe link products for the Macintosh — stand alone or on AppleTalk.
The family comprised of the SNA.ps Gateway, SNA.ps 3270 and developers toolkits which replaced MacDFT Distributed Function Terminal and MacAPPC. The Gateway was a NuBus board that combines 3270 emulation with APPC, and supported Apple’s Token Ring, Coax-Twinax and SNA/SDLC boards. SNA.ps 3270 featured IBM 3270 terminal emulation and concurrent peer-to-peer access using Advanced Program-to-Program Communications, as well as support for the first level of Advanced Peer-to-Peer Networking. It also supported direct co-axial SNA connections, supporting all IBM screen formats and attributes, used the IBM file transfer protocol, and Macintosh’s copy and paste capability to incorporate mainframe data into local applications. SNA.ps 3287 enabled Apple LaserWriters to emulate IBM’s 3287 printer family and came as a free upgrade to either product. The Gateway came in versions for eight, 32 and 64 sessions at UKP1,105 to UKP3,100. The client program was UKP85 per Mac, and SNA.ps 3270, and included the client software UKP240; MacDFT users were provided free software upgrades.
The Apple Serial NB Card was an expansion card that allowed personal computers in the Macintosh® II family of systems to connect to remote systems via a variety of industry-standard serial communications protocols. The card included four serial ports that supported RS-232, RS-422, X.21, or V.35 communications.
The Apple Serial NB Card was an intelligent NuBus™ card, the Apple Serial NB had its own 68000 microprocessor, memory, and multitasking operating system. Operating independently of the main Macintosh II processor, the Serial NB Card supported the execution of communications protocols with minimal access to the Macintosh II processor and operating system. And because all of the communications processing was done on the card, Macintosh applications ran more effectively under MultiFinder™. When used with Apple’s MacAPPC™ software, the Serial NB Card provided a complete SDLC solution, at the physical and data-link layers, for connectivity in the IBM Systems Network Architecture (SNA) environment.
The Apple® TokenTalk™ NB Card was an expansion card that allowed personal computers in the Macintosh® II family of systems to connect to IBM and IBM compatible Token-Ring networks. Because the card supported a variety of network environments, including AppleTalk,® 3270, APPC, and SMB, users could access local area network (LAN) and mainframe-based services connected to the Token-Ring.
The Apple TokenTalk NB Card was an intelligent NuBus™ interface card that had its own 68000 microprocessor, memory, and multitasking operating system. Operating independently of the main Macintosh II processor, the card supported the concurrent execution of multiple networking protocols with minimal access to the Macintosh II processor and operating system. It incorporated the industry-standard Texas Instruments TMS 380 chip set for all Token-Ring access functions. And because all the communications processing was done on the card, a Macintosh II was free to run other Macintosh applications. The Apple TokenTalk NB Card was compatible with the IEEE 802.5 Media Access Control (MAC) standard for Token-Ring networks, as well as the IEEE 802.2 Logical Link Control (LLC) standard for higher-level software access to 802.5 facilities. The card transmited and received data at 4 megabits per second, and interoperated with other IEEE 802-compatible Token-Ring interface cards at the physical and data link layers.