Fortran 5

Fortran 5 was a programming language marketed by Data General Corp in the late 1970s and early 80s, for the Nova, Eclipse, and MV line of computers. It had an optimizing compiler that was quite good for minicomputers of its time. The language most closely resembles Fortran 66. The name is a pun on the earlier Fortran IV.

Univac also offered a compiler for the 1100 series known as Fortran V. A spinoff of Univac Fortran V was Athena Fortran.

Fortran VI

Fortran VI was a programming language distributed by Control Data Corporation in 1968 for the CDC 6600 series. The language was based upon Fortran IV.

Specific variants

Vendors of high-performance scientific computers (”e.g.,” Burroughs, CDC, Cray, Honeywell, IBM, Texas Instruments, and UNIVAC) added extensions to Fortran to take advantage of special hardware features such as instruction cache, CPU pipelines, and vector arrays. For example, one of IBM’s FORTRAN compilers (”H Extended IUP”) had a level of optimization which reordered the machine code instructions to keep multiple internal arithmetic units busy simultaneously. Another example is ”CFD”, a special variant of Fortran designed specifically for the ILLIAC IV supercomputer, running at NASA’s Ames Research Center.

IBM Research Labs also developed an extended FORTRAN-based language called “VECTRAN”

for processing of vectors and matrices.

Object-Oriented Fortran was an object-oriented extension of Fortran, in which data items can be grouped into objects, which can be instantiated and executed in parallel. It was available for Sun, Iris, iPSC, and nCUBE, but is no longer supported.

Such machine-specific extensions have either disappeared over time or have had elements incorporated into the main standards; the major remaining extension is OpenMP, which is a cross-platform extension for shared memory programming. One new extension, Co-array Fortran, is intended to support parallel programming.

FOR TRANSIT for the IBM 650

“FOR TRANSIT” was the name of a reduced version of the IBM 704 FORTRAN language,

which was implemented for the IBM 650, using a translator program developed

at Carnegie

in the late 1950s.

The following comment appears in the IBM

Reference Manual (“FOR TRANSIT Automatic Coding System” C28-4038, Copyright 1957, 1959 by IBM):

”The FORTRAN system was designed for a more complex machine than the 650, and consequently some of the 32 statements found in the FORTRAN Programmer’s Reference Manual are not acceptable to the FOR TRANSIT system. In addition, certain restrictions to the FORTRAN language have been added. However, none of these restrictions make a source program written for FOR TRANSIT incompatible with the FORTRAN system for the 704.”

The permissible statements were:

: Arithmetic assignment statements, e.g. a = b

: GO to n

: GO TO (n1, n2, …, nm), i

: IF (a) n1, n2, n3

: PAUSE

: STOP

: DO n i = m1, m2

: CONTINUE

: END

: READ n, list

: PUNCH n, list

: DIMENSION V, V, V, …

: EQUIVALENCE (a,b,c), (d,c), …

Up to ten subroutines could be used in one program.

FOR TRANSIT statements were limited to columns 7 thru 56, only.

Punched cards were used for input and output on the IBM 650. Three passes were required to translate source code to the “IT” language, then to compile the IT statements into SOAP assembly language, and finally to produce the object program, which could then be loaded into the machine to run the program (using punched cards for data input, and outputting results onto punched cards.)

Two versions existed for the 650s with a 2000 word memory drum: FOR TRANSIT I (S) and FOR TRANSIT II, the latter for machines equipped with indexing registers and automatic floating point decimal (bi-quinary) arithmetic. Appendix A of the manual included wiring diagrams for the IBM 533 control panel.

Fortran-based languages

Prior to FORTRAN 77, a number of preprocessors were commonly used to provide a friendlier language, with the advantage that the preprocessed code could be compiled on any machine with a standard FORTRAN compiler. Popular preprocessors included FLECS, MORTRAN, SFtran, S-Fortran, Ratfor, and Ratfiv. (Ratfor and Ratfiv, for example, implemented a remarkably C-like language, outputting preprocessed code in standard FORTRAN 66.)

LRLTRAN was developed at the Lawrence Radiation Laboratory to provide support for vector arithmetic and dynamic storage, among other extensions to support systems programming. The distribution included the LTSS operating system.

The Fortran-95 Standard includes an optional ”Part 3” which defines an optional conditional compilation capability. This capability is often referred to as “CoCo”.

Many Fortran compilers have integrated subsets of the C preprocessor into their systems.

SIMSCRIPT is an application specific Fortran preprocessor for modeling and simulating large discrete systems.

The F programming language was designed to be a clean subset of Fortran 95 that attempted to remove the redundant, unstructured, and deprecated features of Fortran, such as the EQUIVALENCE statement. F retains the array features added in Fortran 90, and removes control statements that were obsoleted by structured programming constructs added to both Fortran 77 and Fortran 90. F is described by its creators as “a compiled, structured, array programming language especially well suited to education and scientific computing.”

Adapted from the Wikipedia article Fortran, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

Apple Lisa and Macintosh (and later, the Apple IIgs)

Beginning in 1979, started by Steve Jobs and led by Jef Raskin, the Lisa and Macintosh teams at Apple Computer (which included former members of the Xerox PARC group) continued to develop such ideas. The Macintosh, released in 1984, was the first commercially successful product to use a GUI. A desktop metaphor was used, in which files looked like pieces of paper; directories looked like file folders; there were a set of desk accessories like a calculator, notepad, and alarm clock that the user could place around the screen as desired; and the user could delete files and folders by dragging them to a trash can on the screen. Drop down menus were also introduced.

There is still some controversy over the amount of influence that Xerox’s PARC work, as opposed to previous academic research, had on the GUIs of Apple’s Lisa and Macintosh, but it is clear that the influence was extensive, because first versions of Lisa GUIs even lacked icons. These prototype GUIs are at least mouse driven, but completely ignored the WIMP concept. Rare screenshots of first GUIs of Apple Lisa prototypes are shown [http://www.pegasus3d.com/apple_screens.html here] and [http://folklore.org/StoryView.py?project=Macintosh&story=Busy_Being_Born.txt&topic=User%20Interface&sortOrder=Sort%20by%20Date&detail=medium here]. Note also that Apple was invited by PARC to view their research, and a number of PARC employees subsequently moved to Apple to work on the Lisa and Macintosh GUI. However, the Apple work extended PARC’s considerably, adding manipulatable icons, a fixed drop-down menu bar and drag&drop manipulation of objects in the file system (see Macintosh Finder) for example. A list of the improvements made by Apple to the PARC interface can be read [http://www.folklore.org/StoryView.py?project=Macintosh&story=On_Xerox,_Apple_and_Progress.txt&topic=Software%20Design&sortOrder=Sort%20by%20Date here] (folklore.org) It’s hard to say which particular features were originated in which project, though. Jef Raskin warns that many of the reported facts in the history of the PARC and Macintosh development are inaccurate, distorted or even fabricated, due to the lack of usage by historians of direct primary sources.

In 1986 the Apple IIgs was launched, a very advanced model of the Apple II successful series, based on 16-bit technology (in fact, virtually two machines into one). It came with a new operating system, the Apple GS/OS, which features a Finder-like GUI, very similar to that of the Macintosh series, able to deal with the advanced graphic abilities of its Video Graphics Chip (VGC).

Graphical Environment Manager (GEM)

Digital Research (DRI) created the Graphical Environment Manager as an add-on program for personal computers. GEM was developed to work with existing CP/M and MS-DOS operating systems on business computers such as IBM-compatibles. It was developed from DRI software, known as GSX, designed by a former PARC employee. The similarity to the Macintosh desktop led to a copyright lawsuit from Apple Computer, and a settlement which involved some changes to GEM. This was to be the first of a series of ‘look and feel’ lawsuits related to GUI design in the 1980s.

GEM received widespread use in the consumer market from 1985, when it was made the default user interface built in to the TOS operating system of the Atari ST line of personal computers. It was also bundled by other computer manufacturers and distributors, such as Amstrad. Later, it was distributed with the best-sold Digital Research version of DOS for IBM PC compatibles, the DR-DOS 6.0. The GEM desktop faded from the market with the withdrawal of the Atari ST line in 1992 and with the popularity of the Microsoft Windows 3.0 in the PC front by the same years.

DeskMate

Tandy’s DeskMate appeared in the early 1980s on its TRS-80 machines and was ported to its Tandy 1000 range in 1984. Like most PC GUIs of the time it depended on MS-DOS. The application was popular at the time and included a number of programs like Draw, Text and Calendar as well as attracting outside investment such as Lotus 1-2-3 for DeskMate.

Amiga Intuition and the Workbench

The Amiga computer was launched by Commodore in 1985 with a GUI called Workbench based on an internal engine which drives all the input events called Intuition, and developed almost entirely by RJ Mical. The first versions used a blue/orange/white/black default palette, which was selected for high contrast on televisions and composite monitors. Workbench presented directories as drawers to fit in with the “workbench” theme.

Intuition was the widget and graphics library that made the GUI work. It was driven by user events through the mouse, keyboard, and other input devices.

Due to a mistake made by the Commodore sales department, the first floppies of AmigaOS which were released with Amiga1000 named the whole OS “Workbench”. Since then, users and CBM itself referred to “Workbench” as the nickname for the whole AmigaOS (including Amiga DOS, Extras, etc.). This common consent ended with release of version 2.0 of AmigaOS, which re-introduced proper names to the installation floppies of AmigaDOS, Workbench, Extras, etc.).

Early versions of AmigaOS did treat the Workbench as just another window on top of a blank screen, but this is due to the ability of AmigaOS to have invisible screens with a chromakey or a genlock – one of the most advanced features of Amiga platform – even without losing the visibility of Workbench itself. In later AmigaOS versions Workbench could be set as a borderless desktop.

Amiga users were able to boot their computer into a command line interface (aka. CLI/shell). This was a keyboard-based environment without the Workbench GUI. Later they could invoke it with the CLI/SHELL command LoadWB which performs the task to load Workbench GUI.

One major difference between other OS’s of the time and for some time after was the Amiga’s fully Multi-Tasking Operating System, a powerful built in Animation system using a hardware blitter and copper and 4 channels of 26k 8 bit sampled sound. This made the Amiga the first Multi Media computer years before other OS’s.

Like most GUIs of the day Amiga’s Intuition followed Xerox, and sometimes Apple’s lead, but a CLI was included which dramatically extended the functionality of the platform, but Cli/Shell of Amiga is not just a simple text based interface like in MS-DOS but it is another graphic process driven by Intuition engine and with same gadgets included in Amiga graphics.library and serving the GUI process and CLI/Shell interface integrates itself with the Workbench, sharing the same privileges with the GUI.

The Amiga Workbech still evolved over the 1990s, far beyond the official withdrawn from Commodore in 1994. See the next section.

MS-DOS file managers and utility suites

Because most of the very early IBM PC and compatibles lack any common true graphical capability (they only shared the 80-column basic text mode compatible with the original MDA display adapter), a series of file managers arose, including Microsoft’s DOS Shell, which features typical GUI elements as menus, push buttons, lists with scrollbars and mouse pointer. The name Text user interface was later invented to name this kind of interface. Many MS-DOS text mode applications, like the default text editor for MS-DOS 5.0 (and related tools, like QBasic), also shared the same philosophy. The IBM DOS Shell included with IBM DOS 5.0 (circa 1992) supported both text display modes and actual graphics display modes, making it both a TUI and a GUI, depending on the chosen mode.

Advanced file managers for MS-DOS were able to redefine character shapes with EGA and better display adapters, giving some basic low resolution icons and graphical interface elements, including an arrow (instead of a coloured cell block) for the mouse pointer. When the display adapter lacks the ability to change the character’s shapes, they default to the CP437 character set found in the adapter’s ROM. Some popular utility suites for MS-DOS, as Norton Utilities (pictured) and PC Tools used these techniques as well.

DESQview was a text mode multitasking program introduced in July 1985. Running on top of MS-DOS, it allowed users to run multiple DOS programs concurrently in windows. It was the first program to bring multitasking and windowing capabilities to a DOS environment in which existing DOS programs could be used. DESQview was not a true GUI but offered certain components of one, such as resizable, overlapping windows and mouse pointing.

Applications under MS-DOS with proprietary true GUIs

To take the maximum advantage possible in lack of a true common GUI under MS-DOS, the most of the graphical applications which worked with EGA, VGA and better graphic cards had proprietary built-in GUIs, before the MS-Windows age. One of the best known was Deluxe Paint, a popular painting software with a typical WIMP interface.

The original Adobe Acrobat Reader executable file for MS-DOS was able to run on both the standard Windows 3.x GUI and the standard DOS command prompt. When it was launched from the command prompt, it provides its own true GUI (on VGA), which provides the full of its functionality to read PDF files.

Microsoft Windows (16-bit versions)

Windows 1.0 was a GUI for the MS-DOS operating system that had been the OS of choice for IBM PC and compatible computers since 1981. Windows 2.0 followed, but it wasn’t until the 1990 launch of Windows 3.0, based on Common User Access that its popularity truly exploded. The GUI has seen minor redesigns since, mainly the networking enabled Windows 3.11 and its Win32s 32-bit patch. The 16-bit line of MS Windows were discontinued with the introduction of Windows 95 and Windows NT 32-bit based architecture in the 1990s. See the next section.

The main window of a given application can occupy the full screen in ”maximized” status. The users must then to switch between maximized applications using the Alt+Tab keyboard shortcut; no alternative with the mouse except for de-maximize. When none of the running application windows is maximized, switching can be done by clicking on a partially visible window, as is the common way in other GUIs.

In 1988, Apple sued Microsoft for copyright infringement of the LISA and Apple Macintosh GUI. The court case lasted 4 years before almost all of Apple’s claims were denied on a contractual technicality. Subsequent appeals by Apple were also denied. Microsoft and Apple apparently entered a final, private settlement of the matter in 1997.

GEOS

GEOS was launched in 1986. Originally written for the 8-bit home computer Commodore 64 and shortly after, the Apple II series it was later ported to IBM PC systems. It came with several application programs like a calendar and word processor, and a cut-down version served as the basis for America Online’s DOS client. Compared to the competing Windows 3.0 GUI it could run reasonably well on simpler hardware. But it was targeted at 8-bit machines and the 16-bit computer age was dawning.

The X Window System

The standard windowing system in the Unix world is the X Window System (commonly X11 or X), first released in the mid-1980s. The W Window System (1983) was the precursor to X; X was developed at MIT as Project Athena. Its original purpose was to allow users of the newly emerging graphic terminals to access remote graphics workstations without regard to the workstation’s operating system or the hardware. Due largely to the availability of the source code used to write X, it has become the standard layer for management of graphical and input/output devices and for the building of both local and remote graphical interfaces on virtually all Unix, Linux and other Unix-like operating systems, with the notable exception of Mac OS X.

X allows a graphical terminal user to make use of remote resources on the network as if they were all located locally to the user by running a single module of software called the X server. The software running on the remote machine is called the client application. X’s network transparency protocols allow the display and input portions of any application to be separated from the remainder of the application and ‘served up’ to any of a large number of remote users. X is available today as free software.

NeWS

The PostScript-based NeWS (Network extensible Window System) was developed by Sun Microsystems in the mid 1980′s. For several years SunOS included a window system combining NeWS and the X Window System. Although NeWS was considered technically elegant by some commentators, Sun eventually dropped the product. Unlike X, NeWS was always proprietary software.

Adapted from the Wikipedia article History of the graphical user interface, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

”SCO v. IBM” is a civil lawsuit in the United States District Court of Utah. The SCO Group asserted that there are legal uncertainties regarding the use of the Linux operating system due to alleged violations of IBM’s Unix licenses in the development of Linux code at IBM.

Adapted from the Wikipedia article SCO v. IBM, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

File compression routines date back to at least the 1960s: IBM had a compression program called SQUOZE that was commonly used to pack programs on the 709 and 7090 mainframes as part of the SHARE operating system.

By the 1970s file archiving programs were distributed as standard utilities with operating systems. They include the Unix utilities ar, shar, and tar. These utilities were designed to gather a number of separate files into a single archive file for easier copying and distribution.

Other archivers also appeared during the 1980s, including Rahul Dhesi’s ZOO, Dean W. Cooper’s DWC, LHarc by Haruhiko Okomura and Haruyasu Yoshizaki and ARJ which stands for Archived by Robert Jung.

The development of PKZIP was first announced in the file SOFTDEV.DOC from within the PKPAK 3.61 package, stating it would develop a new and yet unnamed compression program. The announcement had been made following the ARC lawsuit between System Enhancement Associates (SEA), Inc. and PKWARE, Inc. Although SEA won the suit, it literally lost the compression war as the user base in protest switched to PKZIP as the compressor of choice. Led by BBS Sysops who refused to accept or offer files compressed as .ARC files, users began recompressing any old archives that were currently stored in .ARC format into .ZIP files. Within a year of SEA’s victory, an estimated more than 95% of files available for downloading from BBS systems worldwide were compressed using PKZIP.

The first version was released in 1989 as a DOS command-line tool, distributed under shareware model with a $25US registration fee ($47US with manual).

Version history

PKZIP 0.8 (1989-01-11) initial version

PKZIP 0.9 (1989-02-10) supported Reducing algorithm (from SCRNCH by Graeme McRae) with 4 compression settings and shrinking. In addition to PKZIP and PKUNZIP, it also included ZIP2EXE, which required an external self-extracting executable header created by MAKESFX from the PKZIP executable package.

PKZIP 0.92 (1989-03-06): In addition to bug fixes, PKZIP included an option to automatically choose the best compression method for each file. New tools included with PKZIP include PKZipFix.

PKZIP 1.01 (1989-07-21) added Implode compression, while Reduced files can only be extracted from ZIP archive. Imploding was chosen based on the characteristics of the file being compressed. New utility included Thomas Atkinson’s REZIP conversion utility (part of ZIP-KIT). PKZIP’s default compression behavior was changed from fastest (Shrink) to best (Implode). Supported platforms include OS/2, DOS.

PKZIP 1.02 (1989-10-01) includes new utility BIOSFIX.COM, which preserved the entire 80386 register set during any mode switches via INT 15H. OS/2 version added ZIP2EXE and 2 self-extracting archive headers.

PKZIP 1.10 (1990-03-15): New features included Authenticity Verification, “mini” PKSFX self-extracting module, integrating self-extracting module into ZIP2EXE, ability to save & restore volume labels. Imploding was up to 5X faster and compression ratio was improved over 1.02. EAX register was always saved on 80386 or above CPU. Removed tools included BIOSFIX, REZIP, MAKESFX.

In 1993, PKWARE released PKZIP 2.0. This new version dispensed with the miscellaneous compression methods of PKZIP 1.x and replaced them with a single new compression method which Katz called “deflating” (although several compression levels of deflating were provided by the program). The resulting file format has since become ubiquitous on Microsoft Windows and on the Internet – almost all files with the .ZIP (or .zip) extension are in PKZIP 2.x format, and utilities to read and write these files are available on all common platforms. PKZIP 2.x also supported spanning archives to multiple disk, which simply split the files into multiple pieces, and using volume label on each drive to differentiate each other. A new Authenticity Verification (AV) signature format was used. Registered version included PKUNZJR, PK Safe ANSI, PKCFG utilities.

PKZIP 2.06 was released in 1994. It was a version of PKZIP 2.04g licensed to IBM.

PKZIP 2.50 was the first version released for Windows 3.1, 95, NT platforms. DOS version of PKZIP 2.50 was released on 1999-03-01, as its final MS-DOS product. PKZIP 2.50 supported long file names on all builds, and Deflate64 extraction. DCL Implode extraction was supported on non-DOS ports. A new command-line product was introduced in Windows 95, OS/2, UNIX platforms, called “PKZIP Command Line” (later expanded to “PKZIP Server”), which featured new command line syntax.

PKZIP 2.6 was the last version to support Windows 3.1 and Windows NT for the Alpha and PowerPC platforms.

PKZIP 2.70 added Email MAPI (i.e. Send To) Support. Registered version included creation of configurable self-extracted archives, added Authenticity Verification (AV) Information. Distribution Licensed versions included enhanced self-extractors. Professional Distribution Licensed version could create Self-Extracting Patch Files, and includes Self-Extractors for Several New Platforms.

PKZIP 4.0 was an updated version of PKZIP 2.7. Version 3 was skipped as a result of PKZIP 3.0 trojan. It supported Deflate64 and DCL Implode compression, and the use of X.509 v3 certificate-based authentication., creation of Span or Split large .ZIP archives. Old PKZIP command line conversion tools were introduced.

On 2001-08-21, PKWARE announced the availability of PKZIP 4.5. PKZIP 4.5 included ZIP64 archives support, which allowed more than 65535 files per ZIP archives, and storing files larger than 4 gigabytes into .ZIP archive. A version called PKZIP Suite 4.5 also included PKZIP Command Line 4.5, PKZIP Explorer 1.5, PKZIP Attachments 1.1, and PKZIP Plug-In 1.0.

PKZIP 5.0 was announced in 2002, which introduced Strong Encryption Specification (SES) for the Professional version of the product, which initially included DES, 3DES, RC2, RC4 encryption formats, and the use of using X.509 v3 certificate-based encryption.

PKZIP 6.0 was released in 2003, which supports BZip2 (based on Burrows-Wheeler transform) compression, with Professional Edition supporting 256-bit AES.

PKZIP 7.0 changed SES to use non-OAEP key wrapping. Support of creating AV authenticity verification archives was dropped. PKZIP could now create archives of the following types: ZIP, BZIP2, GZIP, TAR, UUEncoded, XXEncoded.

PKZIP 8.0 was released on 2004-04-27. In addition, PKWARE renamed its PKZip Professional to SecureZIP. Creation of ZIP archives with encrypted headers was available.

PKZIP 9.0 was the first version to unofficially support Windows Vista (as administrator). Creation of RC2, DES-encrypted ZIP archives are dropped.

PKZIP 10 Enterprise Edition and SecureZIP 10 were released on i5/OS. It offered the ability to create ZIP64 archives for the target platform. Desktop PKZIP version was no longer developed beyond version 9.

On 2007-04-24, PKWARE announced the release of SecureZIP Standard Version 11 as freeware, available on www.securezip.com. SecureZIP comes with SecureZIP Standard (SecureZIP for Windows Desktop), SecureZIP Enterprise, SecureZIP Command Line Interface, SecureZIP for Server, SecureZIP for Server with Directory Integration Module. At this point, only PKZIP for server remained in development. It added UTF-8 file name support, secure exchange of emails and attachments directly from Outlook or Office applications.

SecureZIP 11.2 added SHA-2 hashing (SHA-256, SHA-384, SHA-512 supported), FIPS-140 security mode.

SecureZIP 12 was released on 2008-2.

SecureZIP 12.1 was released on 2008-06-03 Freeware SecureZIP includes a free digital certificate and inclusion in the SecureZIP Global Directory. The certificate was supplied by Comodo. Registration key was changed so keys from versions 8 or earlier no longer work.

SecureZIP 12.2 introduced SecureZIP Express, while SecureZIP Standard became shareware. SecureZIP Express did not include the Microsoft Office integration, but the registration cost was reduced to $19.95. Registration key was changed so previous keys no longer work.

SecureZIP 12.3 added support of PPMd, LZMA compressions. Desktop version added Federal Desktop Core Configuration compatibility, 64-bit OS support, ability to rename a ZIP attachment when sending email, improved support for Windows Vista dialogs. Enterprise version added expanded support for setting policy for 64-bit systems.

SecureZIP 12.4 was released on 2009-12-14 now supports operation on Windows 7, option to switch to “Office fluent”-style ribbon GUI, 64-bit edition for use with 64-bit versions of Windows Vista and Windows 7.

SecureZip 12.5 (released on 2010-05-12) added integration with Microsoft Office 2010, custom alternative extensions for mailed .ZIP archives, extraction WavPack files within ZIP archives, extraction files from archives created on IBM z/OS using hardware compression tools, changes in FIPS Mode to support NIST algorithm changes affective end of 2010.

Adapted from the Wikipedia article PKZIP, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

In recent years, SGI has continued to enhance its line of servers (including some supercomputers) based on the SN architecture. SN, for Scalable Node, is a technology developed by SGI in the mid-1990s, that uses cache-coherent non-uniform memory access (cc-NUMA). In an SN system, processors, memory, and a bus- and memory-controller are coupled together into an entity called a node, usually on a single circuit board. Nodes are connected by a high-speed interconnect called NUMAlink (originally branded CrayLink). There is no internal bus, and instead access between processors, memory, and I/O devices is done through a switched fabric of links and routers.

Thanks to the cache coherence of the distributed shared memory, SN systems scale along several axes at once: as CPU count increases, so does memory capacity, I/O capacity, and system bisection bandwidth. This allows the combined memory of all the nodes to be accessed under a single OS image using standard shared-memory synchronization methods. This makes an SN system far easier to program and able to achieve higher sustained-to-peak performance than non-cache-coherent systems like conventional clusters or massively parallel computers which require applications code to be written (or re-written) to do explicit message-passing communication between their nodes.

The first SN system, known as SN-0, was released in 1996 under the product name Origin 2000. Based on the MIPS R10000 processor, it scaled from 2 to 128 processors and a smaller version, the Origin 200 (SN-00), scaled from 1 to 4. Later enhancements enabled systems of as large as 512 processors.

The second generation system, originally called SN-1 but later SN-MIPS, was released in July 2000, as Origin 3000. It scaled from 4 to 512 processors, and 1,024-processor configurations were delivered by special order to some customers. A smaller, less scalable implementation followed, called Origin 300.

In November 2002, SGI announced a repackaging of its SN system, under the name Origin 3900. It quadrupled the processor area density of the SN-MIPS system, from 32 up to 128 processors per rack while moving to a “fat tree” interconnect topology.

In January 2003, SGI announced a variant of the SN platform called the Altix 3000 (internally called SN-IA). It used Intel Itanium 2 processors and ran the Linux operating system kernel. At the time it was released, it was the world’s most scalable Linux-based computer, supporting up to 64 processors in a single system node. Nodes could be connected using the same NUMAlink technology to form what SGI predictably termed “superclusters”.

In February 2004, SGI announced general support for 128 processor nodes to be followed by 256 and 512 processor versions that year. In April 2004, SGI announced the selling of Alias for approximately $57 million. [http://www.sgi.com/newsroom/press_releases/2004/april/alias.html Press release].

In October 2004, SGI built the supercomputer Columbia for the NASA Ames Research Center, which broke the world record for computer speed. It was a cluster of 20 Altix supercomputers each with 512 Intel Itanium 2 processors running Linux, and achieved sustained speed of 42.7 trillion floating-point operations per second (teraflops), easily topping Japan’s famed Earth Simulator, of 35.86 teraflops. But about a week later IBM’s upgraded Blue Gene/L clocked in at 70.7 teraflops. As of November 2005, Columbia ranked No. 4, behind Blue Gene/L (now achieving 280.6 teraflops), a smaller Blue Gene, and ASC Purple, all built by IBM.

In July 2006, SGI announced an SGI Altix 4700 system with 1,024 processors and 4 TB of memory running a single Linux system image. [http://www.sgi.com/company_info/newsroom/press_releases/2006/july/stream_1024p.html Press release]

Adapted from the Wikipedia article Silicon Graphics, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

The first release of the CICS Program Product developed by IBM became available on July 8, 1969, not long after IMS. CICS was originally developed in the United States at an IBM Development Center in Des Plaines, Illinois, beginning in 1966. The first CICS product was released in 1968, named Public Utility Customer Information Control System, or PU-CICS. CICS was originally developed to address requirements from the public utility industry, but it became clear immediately that it had applicability to many other industries, so the Public Utility prefix was dropped with the introduction of the first release of the CICS Program Product. In early 1970 a number of the original developers, including Ben Riggins, the principal architect of the early releases, relocated to California and continued CICS development at IBM’s Palo Alto Development Center. In 1974, CICS development responsibility was shifted to IBM’s Hursley, United Kingdom Laboratory, where development work continues today.

When CICS was first released, it supported programs written in IBM Assembler, PL/I and COBOL. Programs needed to be quasi-reentrant in order to support multiple concurrent transaction threads. Its modular design meant that, with judicious “pruning”, theoretically it could be executed on a computer with just 32K of physical memory (including the operating system). Because of the limited capacity of even large processors of that era every CICS installation was required to assemble the source code for all of the CICS system modules after completing a system generation process to establish values for conditional assembly statements. This process allowed each customer to exclude support from CICS itself for any feature they did not intend to use, such as device support for terminal types not in use. CICS services emulated the functions of the operating system, but provided services tailored to support only transaction processing that were more efficient than the generalized services in the operating system and much simpler for programmers to use, particularly with respect to communication with terminal devices. Considerable effort was still required from CICS application programmers to make their programs as efficient as possible. A common technique was to limit the size of individual programs to no more than 4,096 bytes, or 4K, so that CICS could easily use the memory occupied by any program not currently in use for another program or other application storage needs. As the efficiency of compiled high level language programs left much to be desired, many early CICS application programs were written in assembler language. CICS owes its early popularity to its relatively efficient implementation, its multi-threaded processing architecture, and its relative simplicity for developing terminal based applications.

An earlier, single thread, transaction processing system IBM MTCS existed prior to CICS and an ‘MTCS-CICS bridge’ , a type of middleware, was developed to allow these transactions to execute under CICS with no change to the original application programs.

Each unique CICS “Task” or transaction was allocated its own dynamic memory at start-up and subsequent requests for additional memory were handled by a call to the “Storage Control program” (part of the CICS nucleus – or “kernel”), which is analogous to an operating system.

Because application programs could be shared by many concurrent threads, the use of static variables embedded within a program (or use of operating system memory) was restricted (by convention only).

Unfortunately, many of the “rules” were frequently broken, especially by COBOL programmers who were frequently unaccustomed to the internals of their programs or else did not use the necessary restrictive compile time options. This resulted in “non-re-entrant” code that was often unreliable, leading to many spurious storage violations and entire CICS system crashes.

The entire partition, or region, operated with the same memory protection key including the CICS kernel code and so program corruption and CICS control block corruption was a frequent cause of system downtime.

These shortcomings nevertheless persisted for multiple new releases of CICS over a period of more than 20 years and, as stated above, were often critical applications used by large banks and other financial institutions.

It was possible to provide a good measure of advance protection by performing all testing under control of a monitoring program that also served to provide Test/Debug features. One such software offering was known as OLIVER, which prevented application programs corrupting memory by using instruction set simulation of the application code, providing partial virtualization.

System calls to CICS (for example to read a record from a file) were elicited by a macro call and this gave rise to the later terminology “Macro-level CICS”. An example of a call to the “File Control Program” of CICS might look like this:-

DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,….etc

This was converted by a pre-compile Assembly which expanded the conditional assembly language macros to their COBOL or PL/I CALL statement equivalents. Thus preparing a HLL application was effectively a “two-stage” compile; output from the Assembler fed straight into the HLL compiler as input.

Command-level CICS

During the 1980s, IBM at Hursley produced a “half-way house” version of CICS which supported what became known as “Command-level CICS”. This release still supported the older programs but introduced a new layer of execution to the new Command level application programs.

A typical Command-level call was given in the first MAPSET example above. This was pre-processed by a pre-compile batch translation stage, which converted the embedded Command-level commands (EXECs) into Call statements to a stub subroutine. So, preparing application programs for later execution still required two stages. It was possible to write “Mixed mode” applications using both Macro-level and Command-level statements.

At execution time, the carefully built Command-level commands were converted back using a run-time translator (“The EXEC Interface Program”; part of the CICS-supplied nucleus) to the old Macro-level call, which was then executed by the mostly-unchanged CICS nucleus programs.

CEDF: This IBM-produced “Command Execution Diagnostic Facility” helped debug ‘EXEC CICS’ commands by showing before and after results. The “OLIVER” software predated this free add-on by more than 10 years, and yet CEDF came without any form of memory protection. It was, however, complementary to OLIVER, and both could be used simultaneously.

The Command-level-only CICS introduced in the early 1990s offered some advantages over earlier versions of CICS. However, IBM also dropped support for Macro-level application programs written for earlier versions. This meant that many application programs had to be converted or completely rewritten to use Command-level EXEC commands only, usually by programmers without exposure to earlier versions or to the original code.

By this time, there were perhaps millions of programs worldwide that had been executing fairly reliably; for decades in many cases. Rewriting them inevitably introduced new bugs without necessarily adding new features.

Run-time conversion

It was, however, possible to execute old Macro-level programs using conversion software such as “Command CICS” produced by APT International, a former CICS Software Specialist company which had earlier produced OLIVER, described above. It was possible to take advantage of the new features of later versions of CICS while, at the same time, retaining the original unaltered codebase. It is believed that there are still programs running today using this same technology.

The overhead was minimal, since additional overhead was limited to the CICS calls only.

Z notation

Part of CICS was formalized using the Z notation in the 1980s and 1990s in collaboration with the Oxford University Computing Laboratory, under the leadership of Sir Tony Hoare. This work won a Queen’s Award for Technological Achievement.

New programming styles

Recent CICS Transaction Server enhancements include support for a number of modern programming styles.

CICS Transaction Server Version 2.1 introduced support for Enterprise Java Beans (EJB). CICS Transaction Server Version 2.2 supported the Software Developers Toolkit. CICS provides the same runtime container as IBM’s WebSphere product family so EJB applications are portable between CICS and Websphere and there is common tooling for the development and deployment of EJB applications.

Also introduced with CICS TS 2.1 was the capability for CICS transactions to be invoked via an HTTP request. This allowed CICS transactions to participate as servers in a POX or REST conversation.

CICS Transaction Server 2.3 added new EJB tracing capabilities, and new JCICS classes, allowing the invocation of CICS services using Java. End-to-end debugging was also introduced, making it easier to debug applications, from the Java client to the CICS application.

The Web services support in CICS Transaction Server Version 3.1 enables CICS programs to be Web service providers or requesters. CICS supports a number of specifications including SOAP Version 1.1 and Version 1.2, and Web services distributed transactions (WS-Atomic Transaction).

The CICS Web Services Assistant includes two batch processing utilities, DFHWS2LS and DFHLS2WS, which are used to map WSDL to programming language structures and vice versa, respectively.

The input to DFHWS2LS is a set of control statements governing its processing and file containing WSDL for a web service to be accessed. The output is a set of language structures, each corresponding to a method in the WSDL, and a WSBIND file. This utility is intended for use by an application developer who wishes to access a web service as a client and has been provided its WSDL.

In this case, the application developer populates the language structure corresponding to the method they wish to invoke, writes the structure to the DFHWS-BODY CICS container, and executes the INVOKE WEBSERVICE API. Execution of the API is synchronous, on return the DFHWS-BODY contains the response from the invoked web service mapped to a language structure.

The input to DFHLS2WS is a set of control statements governing its processing and file containing the language structure corresponding to the invocation parameters of a CICS application program. The output is the WSDL corresponding to the language structure, and a WSBIND file. This utility is intended for use by an application developer who wishes to expose a program’s functionality as a web service.

In this case, the application program is invoked when an HTTP request for its services is received by the CICS region. The application program sees the request as language structure in either a CICS container or a commarea, which one is governed by the control statements fed into DFHLS2WS. The application program performs its processing and writes the response back to the language structure with which it was invoked.

In either case, whether the CICS application is acting as a web services client or server, the mapping of data to and from XML is governed by the generated WSBIND file. The message body is wrapped in, and unwrapped from, a SOAP envelope by CICS Web Services “plumbing” code external to the application program.

The connections between a web service, the WSBIND file, the WSDL, and the CICS transaction requesting or providing the service is done with CICS system level definitions and a configuration file.

Also introduced with CICS TS 3.1 was the capability for CICS applications to act as HTTP clients. This allowed CICS transactions to participate as clients in a POX or REST conversation.

CICS TS can be extended with additional programming features using SupportPacs. For example SupportPac CA8K introduces support for Atom feeds, and SupportPac CA1S adds support for the PHP scripting language, using the same Java-based PHP engine as Project Zero.

Adapted from the Wikipedia article CICS, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

In general, different physical sizes of floppy disks are incompatible by definition, and disks can be loaded only on the correct size of drive. There were some drives available with both 3½-inch and 5¼-inch slots that were popular in the transition period between the sizes.

However, there are many more subtle incompatibilities within each form factor. For example, all but the earliest models of Apple Macintosh computers that have built-in floppy drives included a disk controller that can read, write and format IBM PC-format 3½-inch diskettes. However, few IBM-compatible computers use floppy disk drives that can read or write disks in Apple’s variable speed format. For details on this, see the section ”More on floppy disk formats”.

3½-inch floppy disk

Within the world of IBM-compatible computers, the three densities of 3½-inch floppy disks are partially compatible. Higher density drives are built to read, write and even format lower density media without problems, provided the correct media are used for the density selected. However, if by whatever means a diskette is formatted at the wrong density, the result is a substantial risk of data loss due to magnetic mismatch between oxide and the drive head’s writing attempts. Still, a fresh diskette that has been manufactured for high density use can theoretically be formatted as double density, but only if ”no” information has ever been written on the disk using high density mode (for example, HD diskettes that are pre-formatted at the factory are out of the question). The magnetic strength of a high density record is stronger and will “overrule” the weaker lower density, remaining on the diskette and causing problems. However, in practice there are people who use downformatted (ED to HD, HD to DD) or even overformatted (DD to HD) without apparent problems. Doing so always constitutes a data risk, so one should weigh out the benefits (e.g. increased space or interoperability) versus the risks (data loss, permanent disk damage).

The holes on the right side of a 3½-inch disk can be altered as to ‘fool’ some disk drives or operating systems (others such as the Acorn Archimedes simply do not care about the holes) into treating the disk as a higher or lower density one, for backward compatibility or economical reasons . Possible modifications include:

* Drilling or cutting an extra hole into the right-lower side of a 3½-inch DD disk (symmetrical to the write-protect hole) in order to format the DD disk into a HD one. This was a popular practice during the early 1990s, as most people switched to HD from DD during those days and some of them “converted” some or all of their DD disks into HD ones, for gaining an extra “free” 720 KB of disk space. There even was a special hole punch that was made to easily make this extra (square) hole in a floppy.

* Taping or otherwise covering the bottom right hole on a HD 3½-inch disk enables it to be ‘downgraded’ to DD format. This may be done for reasons such as compatibility issues with older computers, drives or devices that use DD floppies, like some electronic keyboard instruments and samplers where a ‘downgraded’ disk can be useful, as factory-made DD disks have become hard to find after the mid-1990s. See the section ””Compatibility”” above.

**Note: By default, many older HD drives will recognize ED disks as DD ones, since they lack the HD-specific holes and the drives lack the sensors to detect the ED-specific hole. Most DD drives will also handle ED (and some even HD) disks as DD ones.

* Similarly, drilling an HD-like hole (under the ED one) into an ED (2880 kB) disk for ‘downgrading’ it to HD (1440 kB) format if there are many unusable ED disks due to the lack of a specific ED drive, which can now be used as normal HD disks.

*Even if such a format was hardly officially supported on any system, it is possible to “force” a 3½-inch floppy disk drive to be recognized by the system as a 5¼-inch 360 kB or 1200 kB one (on PCs and compatibles. This can be done by simply changing the CMOS BIOS settings) and thus format and read non-standard disk formats, such as a double sided 360 kB 3½-inch disk. Possible applications include data exchange with obsolete CP/M systems, for example with an Amstrad CPC.

5¼-inch floppy disk

The situation was even more complex with 5¼-inch diskettes. The head gap of an 80-track high-density (1.2 MB in the MFM format) drive is shorter than that of a 40-track double-density (360 kB) drive, but will format, read and write 40 track diskettes with apparent success provided the controller supports double stepping (or the manufacturer fitted a switch to do double stepping in hardware). A blank 40 track disk formatted and written on an 80 track drive can be taken to a 40 track drive without problems, similarly a disk formatted on a 40 track drive can be used on an 80 track drive. But a disk written on a 40 track drive and updated on an 80 track drive becomes permanently unreadable on any 360 kB drive, owing to the incompatibility of the track widths (special, very slow programs could have been used to overcome this problem). There are several other bad scenarios.

Prior to the problems with head and track size, there was a period when just trying to figure out which side of a “single sided” diskette was the right side was a problem. Both Radio Shack and Apple used 180 kB single-sided 5¼-inch disks, and both sold disks labeled “single sided” that were certified for use on only one side, even though they in fact were coated in magnetic material on both sides. The irony was that the disks would work on both Radio Shack and Apple machines, yet the Radio Shack TRS-80 Model I computers used one side and the Apple II machines used the other, regardless of whether there was software available which could make sense of the other format.

For quite a while in the 1980s, users could purchase a special tool called a disk notcher which would allow them to cut a second write-unprotect notch in these diskettes and thus use them as “flippies” (either inserted as intended or upside down): both sides could now be written on and thereby the data storage capacity was doubled. Other users made do with a steady hand and a hole punch or scissors. For re-protecting a disk side, one would simply place a piece of opaque tape over the notch or hole in question. These “flippy disk procedures” were followed by owners of practically every home-computer with single sided disk drives. Proper disk labels became quite important for such users.

Flippies were eventually adopted by some manufacturers, with a few programs being sold in this medium (they were also widely used for software distribution on systems that could be used with both 40 track and 80 track drives but lacked the software to read a 40 track disk in an 80 track drive). The practice eventually faded with the increased use of double-sided drives capable of accessing both sides of the disk without the need for flipping.

Adapted from the Wikipedia article Floppy disk, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

Keyboard layouts have evolved over time. The earliest mechanical keyboards were used in musical instruments to play particular notes. With the advent of printing telegraph, a keyboard was needed to select characters. Some of the earliest printing telegraph machines used a layout similar to a piano keyboard.

The center, alphanumeric portion of the modern keyboard is based on the QWERTY design by Christopher Sholes, who laid out the keys in such a way that common two-letter combinations were placed on opposite sides of the keyboard so that his mechanical keyboard would not jam, and laid out the keys in rows offset horizontally from each other by three-eighths, three-sixteenths, and three-eighths inches to provide room for the levers. Although it has been proven that the QWERTY layout is not the most efficient layout for typing, it has become such a standard that people will not change to a more efficient alphanumeric layout.

Sholes chose the size of the keys to be on three-quarter inch (0.75-inch) centers (about 19& mm, versus musical piano keys which are 23.5& mm or about 0.93& inches wide). Actually, 0.75& inches has turned out to be optimum for fast key entry by the average size hand, and keyboards with this key size are called “full-sized keyboards”.

The following layouts assume that the physical locations of the keys are the same as a standard 101/102-key PC keyboard. This keyboard layout was invented by Mark Tiddens of Key Tronic Corporation in 1982, which IBM adopted on its PC AT in 1984 (after previously using an 84-key keyboard which did not have separate cursor and numeric key pads).

The U.S. PC keyboard has 101 keys, while the PC keyboards for most other countries have 102 keys. If you use an operating system configured for a non-English language, the keys are placed differently; “dead keys” appear in red, and characters accessed using the AltGr key appear at the bottom right of the corresponding key, or in some images in blue.

“National” layouts may change the physical configuration of keys. Keyboards designed for typing in Spanish have some characters shifted, to release the space for Ñ ñ; similarly, those for French and other European languages may have a special key for the character Ç ç. Keyboards designed for Japanese may have special keys to switch between Japanese and Latin alphabets, and the character ¥ instead of . Using a keyboard for alternative languages leads to a conflict: the image on the key does not correspond to the character. In such cases, each new language may require an additional label on the key, because the standard keyboard layouts do not even share similar characters of different languages.

Most operating systems allow switching between keyboard layouts, using a key combination involving register keys that are not used for normal operations (e.g. Microsoft reserve Alt+Shift or Ctrl+Shift register control keys for sequential layout switching; those keys were inherited from old DOS keyboard drivers). Keyboard manufacturers usually print the second alphabet on the empty part of the key. The second alphabet can also be added with keyboard stickers manufactured by third parties.

Apple Keyboards have ”Command” and ”Option” keys instead of ”Alt” and ”AltGr”. Option is used much like Alt Gr and Command like control on PCs, to access menu options and shortcuts. There is also a Fn key on modern Mac keyboards, which is used for switching between use of the F1, F2 etc. keys either as function keys F1, F2 etc. or for other functions like media control, accessing dashboard widgets, controlling the volume, handling exposé &c. The control key is not used much by most Macintosh users, unless they use X11 Window programs (Mac OS comes with an X11 Windows environment out of the box in addition to the more familiar Macintosh Finder) or have Windows installed on their Macs. In the past some glyphs for drawing ASCII “window” glyphs commonly used on BBSes were found by using the ctrl key combined with other keys in some keyboard layouts.

Many Unix workstation keyboards place the Control key to the left of the letter A, and the Caps Lock key in the bottom left. This layout is often preferred by programmers as it makes the Control key easier to reach. This position of the Control key is also used on the XO laptop, although the XO does not have a Caps Lock.

Adapted from the Wikipedia article Keyboard layout, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

CCSID 930 (sometimes known as CP930 or codepage 930) is one of several Japanese EBCDIC code pages created by IBM for representation of Japanese text. It is commonly used on IBM z/OS and IBM System i operating system.

It encodes halfwidth Katakana, fullwidth Katakana, Hiragana and Kanji.

Adapted from the Wikipedia article EBCDIC 930, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

X/Open Company, Ltd. was a consortium founded by several European UNIX systems manufacturers in 1984 to identify and promote open standards in the field of information technology. More specifically, the original aim was to define a single specification for operating systems derived from UNIX, to increase the interoperability of applications and reduce the cost of porting software. Its original members were Bull, ICL, Siemens, Olivetti, and Nixdorf—a group sometimes referred to as BISON. Philips and Ericsson joined soon afterwards, at which point the name X/Open was adopted.

The group published its specifications under the name X/Open Portability Guide (or XPG). Issue 1 covered basic operating system interfaces, and was published within a year of the group’s formation. Issue 2 followed in 1987, and extended the coverage to include Internationalization, Terminal Interfaces, Inter-Process Communication, and the programming languages C, COBOL, FORTRAN, and Pascal, as well as data access interfaces for SQL and ISAM. In many cases these were profiles of existing international standards.

XPG3 followed in 1988, its primary focus being convergence with the POSIX operating system specifications. This was probably the most widely used and influential deliverable of the X/Open organisation.

By 1990 the group had expanded to 21 members: in addition to the original five, Philips and Nokia from Europe; AT&T, Digital, Unisys, Hewlett-Packard, IBM, NCR, Sun Microsystems, Prime Computer, Apollo Computer from North America; Fujitsu, Hitachi, and NEC from Japan; plus the Open Software Foundation and Unix International.

X/Open managed the ”UNIX” trademark from 1993 to 1996, when it merged with the Open Software Foundation to form The Open Group.

Adapted from the Wikipedia article X/Open, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.