GCOS
This page is currently under heavy construction and undergoing significant revisions. Information may contain errors or inaccuracies until final edits are complete. Please proceed with this in mind!
- GCOS Daemon in Multics MR12.8: The GCOS Daemon in Multics MR12.8 has known issues when handling permanent disk files, which prevent useful job decks from functioning correctly. These issues are scheduled to be resolved in Multics MR12.9. While the GCOS Daemon setup for MR12.8 is documented, we recommend avoiding its use until the fixes are released. Instead, use the
gcoscommand interactively to run your job decks.
If you encounter a Multics GCOS bug, first check Multics Trac (login anonymous, password multics) for the status of all currently known GCOS and/or GTSS related defects.
Contents
GCOS
This page provides information about the GCOS-related offerings on Multics.
Honeywell had three primary operating system offerings for the Honeywell 6000 series: Multics, CP‑6 (another time sharing system), and GCOS (General Comprehensive Operating System).
Many Multics sites were upgrading from GCOS III systems to Multics, or continued running GCOS systems, so they had a large amount of GCOS data files and application programs they wished to—or needed to—keep using.
36-bit GCOS Evolution
Honeywell GCOS began as General Electric GECOS (or GECOS I) for the GE‑600 in 1963 (predating IBM's OS/360 and DOS/360). While Multics was being commercially offered, GCOS III (GCOS‑3) was the version of GCOS primarily in use. (The successor, GCOS‑8, began life in 1979, but GCOS III maintenance continued on, until September 1987.)
Timeline
| Name | Introduction | System |
|---|---|---|
| GECOS | 1963 | GE-600 |
| GECOS II | 1965 | GE-635 |
| GECOS III | 1969 | GE-655 |
| GCOS III | 1971 | Honeywell 6000 |
| GCOS-8 | 1979 | Honeywell DPS-8 |
Note this table presents the generation of the GCOS system software, not the specific version (e.g. 4JS2, 4JS3, SR2500, SR3000).
You might also want to take look at the Family Trees page on the DPS8M Simulator website.
GCOS on Multics
Multics provides an emulator allowing GCOS III programs and JCL to be easily run within the Multics environment.
Multics does not run the actual GCOS kernel. Instead, it provides an OS interface-level simulation sufficient to execute GCOS software. Multics provides implementations of most of the Master Mode Entries (MMEs) and TSS Derails (DRLs) that are used by user-level GCOS programs. Not every GCOS feature or software program is available in this environment, but a large subset of them are.
Running GCOS batch jobs and time sharing under Multics was often faster than running the same jobs natively under GCOS III (due to Multics support for paging, where GCOS would have to swap the entire process when higher priority tasks needed memory).
The standard GCOS service subsystems (i.e. ACCESS, ASCASC ∕ ASCBCD ∕ BCDASC, BPRINT ∕ BPUNCH, FDUMP) are available as usual. The GCOS File Management Supervisor (FMS) (see Honeywell DD45A, 1977) extended functions (such as concurrent access control, delayed posting, test mode, etc.) are not provided. GCOS system operator interfaces are not provided (except for card and IMCV tape input). Paper tape is not supported. The CARDIN subsystem for batch submission (described in Honeywell DD21, 1974) is not supported (only because batch jobs are submitted using the Multics gcos command).
GCOS Environments on Multics
There are three GCOS environments on Multics:
More details about the Multics-specific GCOS environments are available in the following documents:
- GCOS Environment Simulator Manual (Honeywell AN05‑02A, 1986).
- Handbook for Conversion of GCOS III Application Programs to the GCOS Environment Simulator of Multics (ADA044939, RADC‑TR‑77‑241, 1977)
- (Somewhat outdated but still a useful document. TSS is now supported, but was not at the time of writing.)
GCOS System Software on Multics
The version of GCOS software supplied with Multics is GCOS III Release 4JS3.
- This GCOS release is from the 1980s and represents GCOS III near the end of it's life. GCOS III was succeeded by GCOS 8 (or "GCOS 8000") usually styled as "GCOS‑8", which is the GCOS still available today from Eviden (along with the related—but not 36‑bit—GCOS‑7 systems, as well as the GCOS‑derived NEC ACOS line).
Unfortunately, there are a few bits of software missing in the stock Multics GCOS offering, and we do not have a GCOS Total System Tape that would allow us to install them. However, it is still very usable as is, and gives a good feel for how batch processing and time sharing was done in the 1960s and 1970s (and sometimes even in the early 1980s).
Notes on Character Sets
One of the more confusing aspects of running GCOS under Multics is that GCOS really wants everything to be encoded in the 6‑bit GBCD (GCOS Binary Coded Decimal, see Wikipedia:BCD) character set.
Multics, on the other hand, really wants ASCII encoding. This can cause some obscure issues when the two are working together. The Multics interface to GCOS will perform the appropriate character conversions of input decks and printed output, but when dealing with disk files (segments) or tapes, care must be taken to understand which character set in use.
There is a Multics utility, gcu (gcos_card_utility) that can help in converting between GBCD and ASCII. Some examples of it's use will be shown later. You can find the GBCD character set defined in the GMAP Pocket Guide (Honeywell BS16r1, 1974), pg. 31.
GCOS Reference Manuals
- Bitsavers has a large number of GE GECOS and Honeywell GCOS manuals online that can be helpful in using the GCOS simulation under Multics. Additional GCOS documents are available from the Internet Archive and the U.S. DoD Defense Technical Information Center.
Note that many of these reference manuals are for older (and sometimes newer) versions of GCOS. Although the details may be out of sync with regard to the version of GCOS available under Multics (GCOS III 4JS3), many of the concepts are the same and thus highly useful. Where appropriate and relevant, we link to these manuals throughout this Wiki page.
GCOS Software Availability
- For a high-level overview of the GCOS III system software that was distributed by Honeywell in the mid-70s, see the Honeywell Series‑60 ∕ Level‑66 System Software Overview (DE61, 1976) manual.
Note that some software works only in batch mode, some works only in time sharing, and some works in both environments.
Available Software
The following is a list of software and major subsystems that are installed, available, and working in the default Multics GCOS environment:
| Software | Description | References and Notes |
|---|---|---|
| ABC | ABACUS — Interactive algebraic expression evaluator | Honeywell BS01r0, 1972, Honeywell BS01r1, 1973 |
| ALGOL | Algol‑60 programming language | Honeywell BS11, 1972, Honeywell BS11A, 1972, GE XCPB‑1087, 1966 |
| BASIC | Extended BASIC programming language | Honeywell DD16, 1975, Honeywell BR36, 1971, Honeywell DJ31, 1979 |
| COBOL‑68 | COBOL ANSI‑68 programming language | Honeywell DD25A, 1977, Honeywell DD26, 1975, GE CPB‑1007F, 1969 |
| EDIT & RUNOFF | Text Editor and Reformatting Utility | Honeywell DD18, 1975, Honeywell BS01r0, 1972, Honeywell BS01r1, 1973, Honeywell DJ31, 1979, GE CPB‑1515, 1968 |
| FORTRAN | FORTRAN programming language | Honeywell DD02, 1975, Honeywell BJ67, 1973, Honeywell BJ67A, 19973, Honeywell DG75A, 1979, Honeywell DD20A, 1977, GE CPB‑1566, 1968 |
| GMAP | GCOS Macro Assembler Program | Honeywell BS16, 1974, Honeywell AF52, 1972, GE CPB-1078B, 1966, we are still missing the GMAP reference manual |
| JOVIAL | Jules' Own Version of the International Algebraic Language (MIL‑STD‑1588, JOVIAL J3) | Honeywell BS06r1, 1973, GE J3 (Interim), 1967, usable but possibly missing some runtime bits |
Missing Software
We are "missing" the following (PSP, unbundled, separately obtained, and ∕ or third-party) software that was known to exist:
| Software | Description | References and Notes |
|---|---|---|
| ANAPAC | Analysis Package for Integrated Circuit Test Data | Bell Labs Software, sheet AN178, 1981 |
| APL | Array programming language | GCOS‑APL, APL Quote Quad, pg. 26, 1984 |
| B | B Programming Language | Thinkage B, B Introduction, 1979, B Reference, 1979, B Reference, 1978 |
| BCPL | Basic Combined Programming Language | BCPL Home, 2022 |
| BMD | Biomedical Statistical Programs | Honeywell BP82, 1973 |
| C (GE) | Thinkage ∕ GE C | Thinkage C |
| C (PCC) | Alan Snyder's Portable C Compiler | Portable C Compiler (GitHub, source archive), MAC TR‑149, 1975, CSG Memo 149, 1977 |
| COBOL-74 | COBOL ANSI-74 programming language | Available, but seems to be missing runtime files |
| DDS | Data Dictionary System | Bell Labs Software, sheet DD81, 1981 |
| Ecce | Edinburgh Compatible Context Editor | Ecce (source archive), 2008 (re-porting is possible) |
| ECSS II | Simulation language, extension of SIMSCRIPT II | RAND ECSS II, 1975, ADA038657, RADC‑TR‑77‑61, pg. 14, 1977 |
| FRED | Friendly Text Editor | UW Tools FRED (GCOS‑8, but GCOS‑III existed) |
| G | General purpose programmable text editor | Predecessor of modern G, G History, 2021, |
| GPSS | General Purpose Simulation System | Large Systems Product Guide, pg. 241, 1984 |
| Kermit | Honeywell GCOS Kermit 1.1 | Written in B (source archive), 1988, made redundant by Multics Kermit |
| Lisp | Honeywell GCOS Lisp Programming Language | Honeywell AW41, 1976, Report CS‑76‑12, 1976 |
| Pascal | Honeywell GCOS Pascal Programming Language | Waterloo Pascal, distributed by HIS, Pascal News #15, pg. 113, 1979 |
| PCAP | Process Characterization Analysis Package | Bell Labs Software, sheet MP/80, 1981 |
| PL/I | Honeywell GCOS PL/I | Honeywell DE04, 1975, Honeywell DE05, 1976 |
| QED | QED Text Editor | Bell Labs Software, sheet GC178, 1981, TSS QED, MM‑70‑1373‑3/MM‑70‑1371‑2, 1970 |
| ROFF | Text Formatter | Bell Labs Software, sheet RO178, 1981 |
| RPG | RPG-II compiler | Large Systems Product Guide, pg. 212, 1984 |
| S | S: A Language and System for Data Analysis | Predecessor of modern R, Oral History of John Chambers, 2022 (transcript) |
| SIMSCRIPT II.5 | Computer simulation language | Wikipedia:SIMSCRIPT II.5, ADA038657, RADC‑TR‑77‑61, pg. 14, 1977 |
| SIMULA | Simula-67 object-oriented programming language | Large Systems Product Guide, pg. 244, 1984 |
| SNOBOL | String Oriented And Symbolic Language | Multics ∕ GCOS SNOBOL, 1977 |
Time-Sharing Applications Library
- Honeywell provided many GCOS-compatible software and language routines to large systems users (the Series 600 ∕ 6000 Time‑Sharing Applications Library) via the Honeywell DATANETWORK service. The DATANETWORK service, started in 1972 (see Datapro's Remote Computing Services, 1976), offered GCOS remote access via leased lines, dial‑up modems, X.25, and TYMNET.
- The programs that were available are catalogued and documented in the Series 600 ∕ 6000 Time‑Sharing Applications Library Guides in four volumes: Volume I: Mathematics, 1971 (with Addendum A, 1972), Volume II: Statistics, 1971 (with Addendum A, 1972), Volume III: Industry, 1972 (with Addendum A, 1973 and Addendum B, 1973), and Volume IV: Business & Finance, 1973.
- These programs and routines could be used on the remote Honeywell mainframe systems (billed at hourly rates), but source code (in ALGOL, BASIC, FORTRAN, or GMAP) was provided in nearly every case. These source routines would be useful under both Multics and GCOS.
- Unfortunately, we don't have any of this software.
GEIS Mark III ∕ GCOS
- The Honeywell DATANETWORK service itself, described above, was powered by GE‑600 (and later, Honeywell 6000‑series) machines running the General Electric Information Systems "GCOS-adjacent" Mark III time sharing system (see NYTimes, 1972).
- Mark III was a hybrid system consisting of the DTSS-based Mark II operating system enhanced with integrations allowing clients to submit GCOS batch jobs (see Hench, Foster, 1972 and NBS‑TN‑804, pg. 73-74, 1974).
- This GEIS Mark III and GCOS infrastructure was used to run the later GEnie (see Wikipedia:GEnie and Wikipedia:GXS Inc. History) and AppleLink online services (see Wikipedia:AppleLink and Old VCR, 2024).
- Unfortunately, we don't have any of this software, either.
Unsupported Software
The following software is, unfortunately, not supported (at all) in the Multics GCOS simulation (and it would require considerable effort to modify the Multics software to enable support):
- Integrated Data Store (IDS) database (see manuals Honeywell BR69, 1971, GE CPB-1093, 1965, GE CPB-1133A, 1966, and GE CPB‑483A, 1967), and,
- dataBASIC (see manuals Honeywell DA08, 1971 and Honeywell DA09, 1971), a BASIC-like language for interfacing with the IDS database.
Seeking Software
Do you have any of the above missing software? Do you have any other GCOS documentation, listings, tapes, other media, or related paraphernalia? Anything at all, in any condition?
The preservation of GE ∕ Honeywell ∕ Bull computing history relies on the recovery of rare and often rapidly deteriorating software artifacts – such as the GCOS distribution tapes. We are particularly interested in obtaining the GCOS III Release 4JS3 tapes (the version used in the Multics GCOS simulation):
- Total System Tape
- Starter System Tape
- Source Tape
These tapes would allow us to fill in any missing pieces of the Multics GCOS simulation, and also enable bringing up GCOS III "natively" using the DPS8M Simulator. Any other GCOS-related tapes, however, including tapes for the earlier GECOS II release, would be valuable.
If you have anything, please, get in touch with us via e-mail or GitLab Issues (using the gtss label). We would love to talk with you!
GCOS Batch Processing
There are two methods of simulating batch processing, 1) command line via the gcos command, or 2) via a card reader using the GCOS Daemon.
This section will describe general batch processing concepts and building JCL (Job Control Language) decks, and then cover how to run those decks using the two different methods.
JCL Deck Structure
GCOS JCL is used to describe to the system how to perform the tasks you want done.
Basic Card Format
There are four main types of cards in a JCL deck: control, label, data, and EOF.
- Control cards:
- Are identified by a
$in column 1 - The control card name (for example
SNUMB) starts in column 8 - Column 15 must be blank
- The variable field begins in column 16
- On all cards except
COMMENT,FORM,IDENT, andMSGna blank ends the card scan of a field, so no embedded blanks are allowed - In most cases, options in the variable field can be specified in any order (with one exception to this being the
COPYcard)
- Are identified by a
- Label cards:
- Contain a label in columns 2 through 7
- Can be used as the target of a
GOTOcard to perform conditional processing
- Data cards:
- Any card without a
$in column 1 is considered a data card (except for***EOF) - Data cards will typically follow a
$ DATAcard that specifies a file code to be used to collect those cards for processing - If there is no
$ DATAcard, a default file code is assumed
- Any card without a
- EOF card:
- An
***EOFcard is used to indicate the end of a deck file - These cards can be used to separate multiple decks in a single file
- An
JCL Deck Structure
A complete JCL deck will have this basic set of control cards in the following order:
$ SNUMB FORT1,30 $ IDENT CLAYTON,FOO . . . $ ENDJOB ***EOF
- The
SNUMBcard defines a "submission number" that is used to identify the job to the system. When running using the interactivegcoscommand, this card does not do much, however, it is very important when running under the GCOS Daemon. This card is used during daemon processing to uniquely identify a job's input and output files. If you attempt to submit multiple jobs with the sameSNUMB, the GCOS Daemon will prompt you whether to abort or resolve the conflict. This prevents a deferred job from being overwritten.- The first entry in the variable field is a
1to5character identifier. - There is a second, optional field that specifies urgency (from
0to63) that is not used when running under thegcoscommand but is used to determine which absentee queue to use when running under the daemon.- Urgency
0-21will use the third priority absentee queue (note that, when not specified, the default urgency is5). - Urgency
22-42will use the second priority absentee queue. - Urgency
43-63will use the first priority absentee queue.
- Urgency
- The first entry in the variable field is a
- The
IDENTcard provides an identification of the account to use for this job. Under Multics, this is mainly used to provide a banner for theSYSPRINTjob. However, when running under the GCOS Daemon, the first variable field must match a GCOS to Multics user mapping.- The second variable field is required when submitting a deck via the GCOS Daemon but is not actually used.
- The
ENDJOBcard signals the end of the job deck. - The
***EOFcard signals the end of the file. When using the GCOS Daemon, this card will cause the Daemon to release the card reader for use by other processes. Once that happens, another read from the operator console will be required to process additional GCOS job decks.
Control Card Information
Additional card documentation is available:
Utility System
The GCOS Utility system provides batch copying, copying with merge, copying with re-sequencing, comparing, positioning, and printing capabilities (useful for both for operational and debug purposes), accessed via a UTILITY card, documented in the following manual:
See the Utility Copying Files section below for an example.
More to come
The following documentation exists, but functionality in the Multics environment has not yet been confirmed:
- GCOS Bulk Media Conversion (Honeywell DD11B, 1976)
- GCOS UTL2 Utility Routine (Honeywell DC91A, 1978)
Further Reading
More information and additional examples of GCOS III JCL is available in the University of Houston's "Guide to Job Control Language on the Honeywell 66/60".
GCOS Batch Simulator
The GCOS Batch Simulator is invoked using the gcos command and provided as an argument a GCOS card deck in either Multics (ASCII) or GCOS (BCD) format.
An example invocation is:
gcos cob03.ascii
A sample ASCII deck follows (courtesy of Dean Anderson):
$ SNUMB COB03
$ COMMENT THIS IS A COMMENT
$ IDENT SWENSON,FOO
$ OPTION COBOL
$ COBOL LSTOU
$ FILE C*
$ DATA S*
IDENTIFICATION DIVISION.
PROGRAM-ID. COB03.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. 6000.
DATA DIVISION.
PROCEDURE DIVISION.
START.
DISPLAY "HELLO WORLD".
STOP RUN.
END
$ EXECUTE DUMP
$ ENDJOB
You can convert a Multics (ASCII) deck to a GCOS (GBCD) deck with the gcu command:
gcu -input cob03.ascii -ascii -output cob03.gcos -gcos
The deck thus created can be run under the GCOS simulator as in the same way as above:
gcos c0b03.gcos
The result in either case is a SYSPRINT segment, with the name cob03.sysprint.list (or cob03.gcos.sysprint.list), which shows the results of running the job deck under the GCOS simulator.
Here is a sample JOVIAL program (courtesy of Charles Anthony):
$ snumb 0001t
$ ident
$ options jovial
$ jovial lstin,lstou,deck,dump,debug
PROGRM CDOORS
START
FILE PRNT V(NORM) R06 $
ARRAY ISOPEN 100 I 36 S $
ITEM PASS I 36 S $
ITEM PASS1 I 36 S $
ITEM DOOR I 36 S $
OUT (1, PRNT) $
FOR D = 0, 1, 99 $
ISOPEN($D$) = 0 $
FOR P = 0, 1, 99 $
BEGIN
PASS = P $
PASS1 = PASS + 1 $
FOR D = PASS, PASS1, 99 $
ISOPEN($D$) = 1 - ISOPEN($D$) $
END
FOR D = 0, 1, 99 $
BEGIN
DOOR = D $
DOOR = DOOR + 1 $
IF ISOPEN($D$) EQ 0 $
PRINTF (6H(CLOSED), DOOR) $
IF ISOPEN($D$) NQ 0 $
PRINTF (6H(OPEN ), DOOR) $
END
PROC PRINTF (SS, VAL) $
ITEM SS H 6 $
ITEM VAL I 36 S $
ITEM BUF H 12 P 12H( ) $
ITEM CHR H 10 P 10H(0123456789) $
BEGIN
FOR L = VAL $
BEGIN
BYTE ($0, 6$) (BUF) = BYTE ($0, 6$) (SS) $
BYTE ($8$) (BUF) = BYTE ($ REM (L / 1000, 10) $) (CHR) $
BYTE ($9$) (BUF) = BYTE ($ REM (L / 100, 10) $) (CHR) $
BYTE ($10$) (BUF) = BYTE ($ REM (L / 10, 10) $) (CHR) $
BYTE ($11$) (BUF) = BYTE ($ REM (L / 1, 10) $) (CHR) $
IO1(3, PRNT, 0, BUF, 2) $
RETURN $
END
END
TERM $
$ execute
$ endjob
GCOS Daemon
The GCOS Daemon (GCOS.SysDaemon) can be set up such that simply dropping card decks into the reader automatically runs them. In this mode, the GCOS Daemon attaches the card reader (e.g. rdra), making that reader unavailable to other processes, including the Initializer's x read_cards reading, unless another card reader is specified for that operation.
The GCOS Daemon is invoked, and then the attach and read commands are issued to it. It watches for card decks being "in the reader" (under the simulator this is done by dropping card decks in the appropriate host system directory). It then creates an absentee job and submits it for the proxy user Anonymous.GCOS.p (the "p" here means "proxy"). The absentee job sets up its working directory (and default working directory) to be the GCOS user specified on the $IDENT card in the job deck.
GCOS users are administered with the gcos_user command, which basically defines a GCOS user, and the associated Multics PersonId.ProjectId.
The .absin and .absout files are deleted automatically, and the SYSPRINT file is queued for the printer.
Configuring the GCOS Daemon
Note on GCOS Daemon in Multics MR12.8: The GCOS Daemon in Multics MR12.8 has known issues when handling permanent disk files, which prevent many useful job decks from functioning correctly. These issues are scheduled to be resolved in Multics MR12.9. We recommend most users avoid the GCOS Daemon until the fixes are integrated, and use the gcos command interactively to run job decks.
Configuring the GCOS Daemon is a process that involves many steps.
- This
exec_comis only appropriate for Multics MR12.8 — it updates the system libraries with required fixes tobound_gcos_daemon_andgcos_daemon_stat_. - This
exec_comcan be run only once. - It also will not work once the libraries have been updated (e.g. as in Multics MR12.9 or later) to include these fixes.
To send this exec_com to Multics, we recommend using C‑Kermit (on Unix or macOS) and Kermit 95 for Windows.
- Download the
setup_gcos_daemon.ecto your local host. - Issue the following commands to your local Kermit program:
-
ROBUST -
SET TELNET NEWLINE-MODE NVT OFF -
SET FILE NAMES LITERAL
-
- Connect to the remote Multics site.
- Log in as
Repair.SysAdmin. You'll have to use the-cpwcontrol argument if this is your first time logging in to Multics. - Invoke the
kermit -rq receive -quitcommand on the remote Multics system. - Return to your local Kermit program (usually via
Control‑Backslashand thenc) and issue theSEND setup_gcos_daemon.eccommand. - When the file transfer is complete, return to remote Multics system by issuing the
CONNECT(orCcommand) to your local Kermit program. - Execute the script on Multics with
ec setup_gcos_daemon.
Submitting GCOS Daemon jobs
When you submit a GCOS card deck to the GCOS Daemon (by copying the deck to the simulator's reader directory with the prefix xdeck.), the daemon will run the job. The SYSPRINT files and the .absout will end up under your directory under >gcos_directory_dir (>gdd). This directory has the same structure as >user_dir_dir (>udd). So if you have specified a GCOS account ID of "REPAIR" in your $IDENT card, and REPAIR is mapped to Repair.SysDaemon (using the gcos_user command), then your output will be placed under >gdd>SysAdmin>Repair.
NOTE: Despite the setup using set_iacl_seg (sis) to set initial ACLs on this directory to include your PersonId.ProjectId, it appears that the GCOS Daemon does not (for some unknown reason) respect these. You must configure ACLs so you can access your own output files there. (Eric Swenson will look into that and try to come up with a fix.) You will have 'sma' access to the directory.
Sample JCL Decks
This section contains various sample JCL decks that can be submitted to the GCOS Batch Simulator or GCOS Daemon. Do note that while the GCOS Batch Simulator accepts lower-case characters and converts them to GBCD upper-case, the GCOS Daemon does not. When submitting decks to the GCOS Daemon, only valid GBCD mapable characters should be used (see section on character sets above).
ALGOL Towers of Hanoi
- This deck contains an ALGOL program to solve the Towers of Hanoi.
NOTE: This deck currently works fine with gcos Multics command, but not with the GCOS Daemon (as of Multics MR12.8).
$ SNUMB HANOI
$ IDENT CLAYTON,FOO
$ OPTION ALGOL
$ ALGOL LSTOU
$ DATA S*
'BEGIN'
'INTEGER' N;
'PROCEDURE' HANOI(N,P1,P2,P3);
'INTEGER' N,P1,P2,P3;
'BEGIN'
'IF' N=0 'THEN' 'GOTO' EXIT;
HANOI(N-1,P1,P3,P2);
OUTPUT3(6,"/,"MOVE RING\,ZZD" FROM POLE\,ZD," TO POLE\,
ZD\,N,P1,P3);
HANOI(N-1,P2,P1,P3);
EXIT:
'END' OF PROCEDURE HANOI;
N:=4;
HANOI(N,1,2,3);
'END' OF ENTIRE PROGRAM
$ EXECUTE
$ ENDJOB
- In the
SYSPRINToutput you should see:
SNUMB# HANOI, Activity # 2, REPORT CODE = 6 MOVE RING 1 FROM POLE 1 TO POLE 2 MOVE RING 2 FROM POLE 1 TO POLE 3 MOVE RING 1 FROM POLE 2 TO POLE 3 MOVE RING 3 FROM POLE 1 TO POLE 2 MOVE RING 1 FROM POLE 3 TO POLE 1 MOVE RING 2 FROM POLE 3 TO POLE 2 MOVE RING 1 FROM POLE 1 TO POLE 2 MOVE RING 4 FROM POLE 1 TO POLE 3 MOVE RING 1 FROM POLE 2 TO POLE 3 MOVE RING 2 FROM POLE 2 TO POLE 1 MOVE RING 1 FROM POLE 3 TO POLE 1 MOVE RING 3 FROM POLE 2 TO POLE 3 MOVE RING 1 FROM POLE 1 TO POLE 2 MOVE RING 2 FROM POLE 1 TO POLE 3 MOVE RING 1 FROM POLE 2 TO POLE 3
COBOL Hello World
This deck shows a simple COBOL program that displays "HELLO WORLD" in the output.
$ SNUMB COB03
$ COMMENT THIS IS A COMMENT
$ IDENT SWENSON,FOO
$ OPTION COBOL
$ COBOL LSTOU
$ FILE C*
$ DATA S*
IDENTIFICATION DIVISION.
PROGRAM-ID. COB03.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. 6000.
DATA DIVISION.
PROCEDURE DIVISION.
START.
DISPLAY "HELLO WORLD".
STOP RUN.
END
$ EXECUTE DUMP
$ ENDJOB
Notes on this deck:
- The
LSTOUoption on theCOBOLcard will produce an output listing along with the GMAP assembler code that was generated. If you only want a listing of the input, use theLSTINoption. - The
FILEcard forC*is used to suppress punching an object deck. If not present, a punch job will be queued for the object deck. - The
DUMPoption on theEXECUTEwill cause a core dump to be printed if the execution aborts. Removing this option will cause just the registers and EIS information to be output in case of abort. - If you don't have a
STOP RUN.in your program, the program will run but abort at the end of the run instead of successfully ending. TheENDis not enough to get a good run.
Utility Copying Files
- This deck demonstrates the
UTILITYcard being used to copy files, using the previously mentioned Utility system.
It first takes an input file from the job deck and writes to a permanent disk file. Then it makes a copy of the permanent disk file with a new name.
$ SNUMB F0001 $ IDENT CLAYTON,FOO $ AC010: $ UTILITY $ DATA 01 SMITH JOHN 31 DOE JANE 29 SMITH SAMUEL 45 BROWN ROBERT 27 JACKSON MIKE 55 $ PRMFL 02,W,S,NAMES $ FUTIL 01,02,COPY/1F/ $ AC020: $ UTILITY $ PRMFL 01,R,S,NAMES $ PRMFL 02,W,S,NAMES2 $ FUTIL 01,02,COPY/1F/ $ ENDJOB
Notes on this deck:
- Activity labels are shown (though they are not used for anything in this deck). These are the
AC010:andAC020cards. - The
DATAcard in the first activity is used to define the input file that gets copied to the output permanent file. All the cards following theDATAcard are copied to the file code01until another control card is encountered. - The
PRMFLcards define a permanent file. When there is no path given and run under thegcoscommand line utility, the working directory will be used. When run under the GCOS Daemon, the path will be>gdd>[project]>[user]. - The
FUTILcards define the file codes and operation(s) to perform. In both cases above, the file codes are01and02and the operation is to copy 1 file (theCOPY/1F/part of the variable field).
See the Honeywell GCOS Utility Manual (DD12, 1974) for more examples.
Separate Compile and Execute
This section shows two different jobs for doing a compile and separate execution of the program. In this case, the C* file in the compilation job is saved to a permanent disk file so it can be reused.
Compilation Job Deck
- This job will compile a COBOL program and save it to a permanent file.
$ SNUMB COBHW
$ COMMENT THIS JOB WILL COMPILE A PROGRAM THAT INPUTS A NAME
$ COMMENT AND OUTPUTS A HELLO MESSAGE
$ IDENT CLAYTON,COBHW
$ OPTION COBOL
$ COBOL LSTOU
$ PRMFL C*,W,S,CLAYTON/OBJ/COBHW
$ DATA S*
IDENTIFICATION DIVISION.
PROGRAM-ID. COBHW.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. 6000.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 NAME PIC X(20).
PROCEDURE DIVISION.
A010-MAIN.
ACCEPT NAME.
DISPLAY "HELLO " NAME.
A010-EXIT.
STOP RUN.
END
$ ENDJOB
Notes on this deck:
- The
PRMFLcard assigns the compiler object deck output to a permanent disk file. Note that the first part of the pathCLAYTONwill be ignored and replaced with the working directory. This means that there needs to be a directory namedobjunder the current working directory. - The
ACCEPTwill read a card image from a standard input (since it does not specify a source in aFROMclause).
Execution Job Deck
- This job will execute the previously compiled program.
$ SNUMB EXEHW $ COMMENT THIS JOB WILL EXECUTE THE COBOL HELLO PROGRAM $ IDENT CLAYTON,EXEHW $ OPTION COBOL,NOMAP $ SELECT CLAYTON/OBJ/COBHW $ EXECUTE JOHN SMITH $ ENDJOB
Notes on this deck:
- The
OPTIONcard is needed so the correct libraries are available during the link portion of theEXECUTEactivity. - The
OPTIONcard also includes theNOMAPoption which prevents a memory load map from being generated in the job output. The load map is usually only useful when debugging issues. - The
JOHN SMITHcard is automatically loaded into the default input (GIN). Be aware this card must occur after theEXECUTEcard or it will be ignored (the error will be something like non-dollar card(s) skipped).
GCOS Time Sharing
- The GCOS Time Sharing System is invoked with the
gcos_tssorgtssMultics command.
GCOS Time Sharing System Documentation
For a general overview, as well as in-depth details of the GCOS TSS environment, see the following documents:
- GCOS Time Sharing System General Information Manual (Honeywell DD22, 1976) (also available Honeywell BS01, 1972, Honeywell CPB‑1643A, 1971)
- GCOS Time Sharing System Reference Manual (Honeywell DJ31, 1979)
- GCOS Time Sharing System Pocket Guide (Honeywell BS12, 1974)
- GCOS Time Sharing System Programmers' Reference Manual (Honeywell BR39, 1971).
GTSS File Storage and Attributes
- The
gtssenvironment uses the standard Multics hierarchical filesystem, storing GCOS files in Multics segments, making clever use of the Multics altname facility to encode GCOS-specific attributes.
- For example, creating a file named
MYFILE01in GCOS –
GTSS 4JS3 (4.0)
*10
*SAVE MYFILE01
DATA SAVED-MYFILE01
*CATALOG
LIST OF CATALOG GTSS ON 05/18/25 AT 17.996
CATALOGS
FILES
MYFILE01
*
- – creates the segment
myfile01on the Multics filesystem, along with several altnames:
Segments = 1, Lengths = 1.
r w 1 myfile01
myfile01.mode.s
myfile01.maxl.20
myfile01.curl.1
myfile01.busy.no
myfile01.attr.000000000000
myfile01.crdt.051825
myfile01.noal.1
myfile01.null.no
Of course, you can use Multics directories to organize your GCOS GTSS files. In fact, it is highly recommended that you create directories (rather than using your home directory) not just to stay organized, but also because this avoids at least one known GTSS bug in Multics MR12.8 (see Multics Trac:366).
Using GCOS Time Sharing
- When
gtsshas been invoked, it displays a prompt like this:
gcos_tss GTSS 4JS3 (4.0) *
- You can display a directory listing (
catalog) and check your sessionstatus(notice the Y2K formatting issue!):
gtss
GTSS 4JS3 (4.0)
*catalog
LIST OF CATALOG JJOHNSON ON 05/16/25 AT 21.268
CATALOGS
FILES
MBENCH
*status
channel 0400 ts0
user status on may 16,1925 at 21:16:11 log-on at 21:16:02
proc time used 0.09 sec., 0 file i/o 88 char key i/o
list of open files: none
- Below, you'll see a
gcos_tss(gtss) session that runs a simple "hello world" program written in BASIC:
gtss GTSS 4JS3 (4.0) *basic *10 print "hello world" *run hello world ready *bye
- Here is an attempt (that ends in failure!) to compile/run a JOVIAL program under TSS:
gtss GTSS 4JS3 (4.0) *jovial *10 PROC FACTORIAL(ARG) U; *20 BEGIN *30 ITEM ARG U; *40 ITEM TEMP U; *50 TEMP = 1 *60 FOR I:2 BY 1 WHILE I<ARG; *70 TEMP = TEMP*I; *80 FACTORIAL = TEMP; *90 END *run SSA_buf_ptr -> 413|374 File list ptr -> 413|7456 Urgency 163840 (500000) Snumb 0001t Activity name jovial IO time limit 0. Job time limit 1.6666666667e-2 Job io time limit 0. PSW 010004000000 Geload limit 060000070000 $ ident !!!!!!gcos_cobol 00000000000000000[000000000000000000!!!!!! $ comment 000000000000000000000000000000000000000000000000000000000000 file list .. 10 entries syslib L* altlib *L *src S* r* R* h* H* p* P* b* B* *1 *1 *2 *2 *j *J *SRT 0001t-01 @1417.0 jovial ( 8) *EOJ 0001t-01 @1417.0 GCOS sysout files NOT queued for daemon output: >udd>SysAdmin>Swenson>work>gcos_cobol>gtss_task.sysprint.list ERROR..STA.. 0000 MISSING START ERROR..STA.. 0002 SYNTAX ERROR..STA.. 0003 SYNTAX ERROR..STA.. 0004 SYNTAX ERROR..STA.. 0005 MISSING TERM NON FATAL ERROR * MISSING ROUTINE .FSETU NON FATAL ERROR * MISSING ROUTINE .GTLIT NON FATAL ERROR * MISSING ROUTINE .TSGF. NON FATAL ERROR * MISSING ROUTINE .FTSU. NON FATAL ERROR * MISSING ROUTINE .GFLG NON FATAL ERROR * MISSING ROUTINE .ASCB. FATAL ERROR * $ENTRY NAME NOT LOADED NON FATAL ERROR * $ENTRY NAME NOT LOADED NON FATAL ERROR * $ENTRY NAME NOT LOADED
External Resources
- Visit the website of our friends at FEB‑Patrimoine — La Fédération des Equipes Bull.
- "The Federation of Bull Heritage Team" is an organization and museum "dedicated to preserving and promoting the rich history and cultural significance of Groupe Bull and French data processing". FEB houses an exclusive collection of exhibits and historical documents relating to CII‑Honeywell‑Bull systems, including retrospectives and histories of the various GCOS systems (i.e. History of Major GCOS Systems, 1998, GECOS to GCOS‑8 History, 2003: Part I, Part II, Part III) from the European—and especially French—perspective.