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 gcos command 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.'''
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.
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.)
| 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.
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).
There are three GCOS environments on Multics:
More details about the Multics-specific GCOS environments are available in the following documents:
: (Somewhat outdated but still a useful document. TSS is now supported, but was not at the time of writing.)
The version of GCOS software supplied with Multics is GCOS III Release 4JS3.
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).
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.
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.
Note that some software works only in batch mode, some works only in time sharing, and some works in both environments.
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
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 [https://www.thinkage.ca/gcos/expl/fred/expl.html 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
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):
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!
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.
GCOS JCL is used to describe to the system how to perform the tasks you want done.
There are four main types of cards in a JCL deck: control, label, data, and EOF.
Control cards:
$ in column 1SNUMB) starts in column 8COMMENT, FORM, IDENT, and MSGn a blank ends the card scan of a field, so no embedded blanks are allowedCOPY card)Label cards:
GOTO card to perform conditional processingData cards:
$ in column 1 is considered a data card (except for ***EOF)$ DATA card that specifies a file code to be used to collect those cards for processing$ DATA card, a default file code is assumedEOF card:
***EOF card is used to indicate the end of a deck fileA complete JCL deck will have this basic set of control cards in the following order:
$ SNUMB FORT1,30
$ IDENT CLAYTON,FOO
.
.
.
$ ENDJOB
***EOF
SNUMB card defines a "submission number" that is used to identify the job to the system. When running using the interactive gcos command, 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 same SNUMB, the GCOS Daemon will prompt you whether to abort or resolve the conflict. This prevents a deferred job from being overwritten.
1 to 5 character identifier.0 to 63) that is not used when running under the gcos command but is used to determine which absentee queue to use when running under the daemon.
0 - 21 will use the third priority absentee queue (note that, when not specified, the default urgency is 5).22 - 42 will use the second priority absentee queue.43 - 63 will use the first priority absentee queue.IDENT card provides an identification of the account to use for this job. Under Multics, this is mainly used to provide a banner for the SYSPRINT job. However, when running under the GCOS Daemon, the first variable field must match a GCOS to Multics user mapping.
ENDJOB card signals the end of the job deck.***EOF card 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.Additional card documentation is available:
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.
The following documentation exists, but functionality in the Multics environment has not yet been confirmed:
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".
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
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.
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.
An exec_com that will automatically do everything necessary to setup up the GCOS Daemon on Multics MR12.8 is available here.
exec_com is only appropriate for Multics MR12.8 --- it updates the system libraries with required fixes to bound_gcos_daemon_ and gcos_daemon_stat_.exec_com can be run only once.To send this exec_com to Multics, we recommend using C‑Kermit (on Unix or macOS) and Kermit 95 for Windows.
setup_gcos_daemon.ec to your local host.ROBUSTSET TELNET NEWLINE-MODE NVT OFFSET FILE NAMES LITERALRepair.SysAdmin. You'll have to use the -cpw control argument if this is your first time logging in to Multics.kermit -rq receive -quit command on the remote Multics system.Control‑Backslash and then c) and issue the SEND setup_gcos_daemon.ec command.CONNECT (or C command) to your local Kermit program.ec setup_gcos_daemon.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.
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).
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
SYSPRINT output 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
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:
LSTOU option on the COBOL card will produce an output listing along with the GMAP assembler code that was generated. If you only want a listing of the input, use the LSTIN option.FILE card for C* is used to suppress punching an object deck. If not present, a punch job will be queued for the object deck.DUMP option on the EXECUTE will 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.STOP RUN. in your program, the program will run but abort at the end of the run instead of successfully ending. The END is not enough to get a good run.UTILITY card 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:
AC010: and AC020 cards.DATA card in the first activity is used to define the input file that gets copied to the output permanent file. All the cards following the DATA card are copied to the file code 01 until another control card is encountered.PRMFL cards define a permanent file. When there is no path given and run under the gcos command line utility, the working directory will be used. When run under the GCOS Daemon, the path will be >gdd>[project]>[user].FUTIL cards define the file codes and operation(s) to perform. In both cases above, the file codes are 01 and 02 and the operation is to copy 1 file (the COPY/1F/ part of the variable field).See the Honeywell GCOS Utility Manual (DD12, 1974) for more examples.
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.
$ 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:
PRMFL card assigns the compiler object deck output to a permanent disk file. Note that the first part of the path CLAYTON will be ignored and replaced with the working directory. This means that there needs to be a directory named obj under the current working directory.ACCEPT will read a card image from a standard input (since it does not specify a source in a FROM clause). $ 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:
OPTION card is needed so the correct libraries are available during the link portion of the EXECUTE activity.OPTION card also includes the NOMAP option which prevents a memory load map from being generated in the job output. The load map is usually only useful when debugging issues.JOHN SMITH card is automatically loaded into the default input (GIN). Be aware this card must occur after the EXECUTE card or it will be ignored (the error will be something like non-dollar card(s) skipped).gcos_tss or gtss Multics command.For a general overview, as well as in-depth details of the GCOS TSS environment, see the following documents:
gtss environment 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 MYFILE01 in 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 myfile01 on 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).
gtss has been invoked, it displays a prompt like this: gcos_tss
GTSS 4JS3 (4.0)
*
catalog) and check your session status (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
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
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
"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.