GCOS

From Multics Wiki
Jump to: navigation, search

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.


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, ASCASCASCBCDBCDASC, BPRINTBPUNCH, 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:

(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

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

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

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).
  • 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):

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, and MSGn a 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 COPY card)
  • Label cards:
    • Contain a label in columns 2 through 7
    • Can be used as the target of a GOTO card 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 $ DATA card that specifies a file code to be used to collect those cards for processing
    • If there is no $ DATA card, a default file code is assumed
  • EOF card:
    • An ***EOF card is used to indicate the end of a deck file
    • These cards can be used to separate multiple decks in a single file

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 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.
    • The first entry in the variable field is a 1 to 5 character identifier.
    • There is a second, optional field that specifies urgency (from 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.
      • Urgency 0 - 21 will use the third priority absentee queue (note that, when not specified, the default urgency is 5).
      • Urgency 22 - 42 will use the second priority absentee queue.
      • Urgency 43 - 63 will use the first priority absentee queue.
  • The 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.
    • The second variable field is required when submitting a deck via the GCOS Daemon but is not actually used.
  • The ENDJOB card signals the end of the job deck.
  • The ***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.

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:

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.

An exec_com that will automatically do everything necessary to setup up the GCOS Daemon on Multics MR12.8 is available here.

  • This 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_.
  • This exec_com can 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.

  1. Download the setup_gcos_daemon.ec to your local host.
  2. Issue the following commands to your local Kermit program:
    1. ROBUST
    2. SET TELNET NEWLINE-MODE NVT OFF
    3. SET FILE NAMES LITERAL
  3. Connect to the remote Multics site.
  4. Log in as Repair.SysAdmin. You'll have to use the -cpw control argument if this is your first time logging in to Multics.
  5. Invoke the kermit -rq receive -quit command on the remote Multics system.
  6. Return to your local Kermit program (usually via Control‑Backslash and then c) and issue the SEND setup_gcos_daemon.ec command.
  7. When the file transfer is complete, return to remote Multics system by issuing the CONNECT (or C command) to your local Kermit program.
  8. 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 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

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 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.
  • The 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.
  • The 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.
  • 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. The END is not enough to get a good run.

Utility Copying Files

  • This deck demonstrates the 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:

  • Activity labels are shown (though they are not used for anything in this deck). These are the AC010: and AC020 cards.
  • The 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.
  • The 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].
  • The 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.

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 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.
  • The ACCEPT will read a card image from a standard input (since it does not specify a source in a FROM clause).

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 OPTION card is needed so the correct libraries are available during the link portion of the EXECUTE activity.
  • The 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.
  • The 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 Time Sharing

  • The GCOS Time Sharing System is invoked with the gcos_tss or gtss Multics 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:

GTSS File Storage and Attributes

  • The 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).

Using GCOS Time Sharing

  • When gtss has been invoked, it displays a prompt like this:
gcos_tss
GTSS 4JS3 (4.0)
*
  • You can display a directory listing (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
  • 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

"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.