In order to do the equivalent of UNIX

$ cp file1.txt file2.txt

on CTSS, I'm using

UPDATE 1 FILE1 TXT
COMFIL 1
RENAME FILE1 TXT FILE2 TXT
UPDATE 0 FILE2 TXT
DELETE FILE2 TXT
COMFIL 0

Is there a better way to do that? Once I learn how RUNCOM parameter substitution works I might be able to script it but I'm wondering how something so basic requires so many steps.

Acceptable Name <metta.crawler@gmail.com> writes:
>In order to do the equivalent of UNIX
>
>$ cp file1.txt file2.txt
>
>on CTSS, I'm using
>
>UPDATE 1 FILE1 TXT
>COMFIL 1
>RENAME FILE1 TXT FILE2 TXT
>UPDATE 0 FILE2 TXT
>DELETE FILE2 TXT
>COMFIL 0
>
>Is there a better way to do that? Once I learn how RUNCOM parameter substitution works I might be able to script it but I'm wondering how something so basic requires so many steps.

Very few systems in that era had a file copy function embedded
into the command interpreter[*]. DEC had PIP, HP had FCOPY,
IBM had IEBGENER, Burroughs had DMPALL and SYSTEM/COPY.

[*] Generally due to space constraints.

On Monday, March 21, 2022 at 12:47:30 PM UTC-4, Scott Lurndal wrote:
> Acceptable Name <metta....@gmail.com> writes:
> >In order to do the equivalent of UNIX
> >
> >$ cp file1.txt file2.txt
> >
> >on CTSS, I'm using
> >
> >UPDATE 1 FILE1 TXT
> >COMFIL 1
> >RENAME FILE1 TXT FILE2 TXT
> >UPDATE 0 FILE2 TXT
> >DELETE FILE2 TXT
> >COMFIL 0
> >
> >Is there a better way to do that? Once I learn how RUNCOM parameter substitution works I might be able to script it but I'm wondering how something so basic requires so many steps.
> Very few systems in that era had a file copy function embedded
> into the command interpreter[*]. DEC had PIP, HP had FCOPY,
> IBM had IEBGENER, Burroughs had DMPALL and SYSTEM/COPY.
>
> [*] Generally due to space constraints.

Thanks, Scott. However, the CTSS UPDATE and COPY commands
are not embedded into the supervisor, which is the CTSS command
interpreter, module RUNCOM which interprets simple scripts.

On CTSS:

comfil 2
W 1257.2
R .016+.000

listf update *
W 1257.3

UPDATE TSSDC. 000 5 03/21/14

R .016+.016

listf copy *
W 1257.3

COPY TSSDC. 104 M1416 CMFL02 UPDATE

R .016+.016

Files on CTSS and ITS have two names, usually called NAME1 NAME2.
File names are each a 36-bit word containing 6-bit BCD characters
on CTSS or ASCII on ITS which ran on a PDP-6 and later PDP-10s.

I haven't found it in writing yet but I think the TSSDC. NAME2
stands for Time Sharing System Disk Command. The 1969 CTSS
Programmer's Guide uses the term "disk commands" repeatedly.

http://www.bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf

COPY is the same as UPDATE except that the "source directory"
and "target directory" are swapped. It would take more steps to copy
a file using COPY because I would have to backtrack to remove the
intermediate copy of the file.

COMFIL 1 (change directory to common files 1)
COPY 0 FILE1 TXT (copy file from common files 0, which is really
a personal user file directory (U.F.D.)
RENAME FILE1 TXT FILE2 TXT
COMFIL 0
COPY 1 FILE2 TXT
COMFIL 1
DELETE FILE2 TXT
COMFIL 0

One other thing I discovered is that David Pitts' asm7090 which is
not 64-bit clean also cannot assemble these FAP statements:

$ grep =VO *.fap
cpyc8b.fap: LDQ =VO18/UCOMBT+UCMLBT SET COMMAND SWITCHES CPYC0041
cpyc8b.fap: LDQ =VO18/SB.CMD INDICATE SUBSYS TRAPPED COMMAND CPYC0054
ctrl8f.fap: ORA =VO36/RSYSBT .. ADD SUBSYSTEM PRIVILEGES CTRL0164
ctrl8f.fap: LDQ =VO18/UCOMBT+UCHNBT+UCBFBT SET UP COMMAND SWITCHES CTRL0251
ulod8a.fap: ANA =VO18/TPWRSW .. MASK ULOD0605
util8c.fap: LDQ =VO18/LOGTBT SET COMMAND SWITCHES UTIL0110

IBM FAP has VFD and OPVFD pseudo operations. For MIT CTSS FAP
a new literal statement was introduced, the VFD literal. The syntax is =V which
follows =H for Hollerith literals and =O for octal ones.

I'm guessing that =VO is a VFD octal literal based on reading the source for CTSS FAP.
I don't know why anyone would want to take the numbers 18 or 36 as octal values so
I'm still not sure if =VO is is octal or has some other meaning.

David Pitts' asm7090 does have support for VFD literals but when I try to
assemble =VO36/RSYSBT it truncates RSYSBT to RS and outputs a symbol RS
which is undefined causing linking via his lnk7090 to fail.

I don't know how David Pitts got a working CTSS despite that. I haven't
tried building a system from the tapes that are generated despite those errors
yet and seeing if it runs.

Acceptable Name <metta.crawler@gmail.com> writes:

[ snip ]

> Files on CTSS and ITS have two names, usually called NAME1 NAME2.
> File names are each a 36-bit word containing 6-bit BCD characters
> on CTSS or ASCII on ITS which ran on a PDP-6 and later PDP-10s.

ObPedantry: ITS file names are in SIXBIT, DEC's name for an encoding derived
from ASCII by subtracting 40(8) from the 7-bit ASCII representation.

[ snip ]

> One other thing I discovered is that David Pitts' asm7090 which is
> not 64-bit clean also cannot assemble these FAP statements:

> $ grep =VO *.fap
> cpyc8b.fap: LDQ =VO18/UCOMBT+UCMLBT SET COMMAND SWITCHES CPYC0041
> cpyc8b.fap: LDQ =VO18/SB.CMD INDICATE SUBSYS TRAPPED COMMAND CPYC0054
> ctrl8f.fap: ORA =VO36/RSYSBT .. ADD SUBSYSTEM PRIVILEGES CTRL0164
> ctrl8f.fap: LDQ =VO18/UCOMBT+UCHNBT+UCBFBT SET UP COMMAND SWITCHES CTRL0251
> ulod8a.fap: ANA =VO18/TPWRSW .. MASK ULOD0605
> util8c.fap: LDQ =VO18/LOGTBT SET COMMAND SWITCHES UTIL0110

> IBM FAP has VFD and OPVFD pseudo operations. For MIT CTSS FAP a new literal
> statement was introduced, the VFD literal. The syntax is =V which follows =H
> for Hollerith literals and =O for octal ones.

> I'm guessing that =VO is a VFD octal literal based on reading the source for
> CTSS FAP. I don't know why anyone would want to take the numbers 18 or 36 as
> octal values so I'm still not sure if =VO is is octal or has some other
> meaning.

I suspect that "O<value>" is supposed to tell the assembler to allocate either
an 18 or a 36 bit field to hold the calculated constant in the symbol table. I
base this on my own recent work on PDP-10 Macro-20, including changes to the
symbol table handling there.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Scott Lurndal <scott@slp53.sl.home> wrote:
> Acceptable Name <metta.crawler@gmail.com> writes:
>> In order to do the equivalent of UNIX
>>
>> $ cp file1.txt file2.txt
>>
>> on CTSS, I'm using
>>
>> UPDATE 1 FILE1 TXT
>> COMFIL 1
>> RENAME FILE1 TXT FILE2 TXT
>> UPDATE 0 FILE2 TXT
>> DELETE FILE2 TXT
>> COMFIL 0
>>
>> Is there a better way to do that? Once I learn how RUNCOM parameter
>> substitution works I might be able to script it but I'm wondering how
>> something so basic requires so many steps.
>
>
> Very few systems in that era had a file copy function embedded
> into the command interpreter[*]. DEC had PIP, HP had FCOPY,
> IBM had IEBGENER, Burroughs had DMPALL and SYSTEM/COPY.
>
> [*] Generally due to space constraints.
>

I don’t think it was “embedded.” I assume it’s a separate program invoked
from the shell. VM has COPYFILE. Multics has copy, abbreviated cp. TSO has
COPY.

--
Pete

On Monday, March 21, 2022 at 1:42:03 PM UTC-4, Acceptable Name wrote:
> On Monday, March 21, 2022 at 12:47:30 PM UTC-4, Scott Lurndal wrote:
> > Acceptable Name <metta....@gmail.com> writes:
> > >In order to do the equivalent of UNIX
> > >
> > >$ cp file1.txt file2.txt
> > >
> > >on CTSS, I'm using
> > >
> > >UPDATE 1 FILE1 TXT
> > >COMFIL 1
> > >RENAME FILE1 TXT FILE2 TXT
> > >UPDATE 0 FILE2 TXT
> > >DELETE FILE2 TXT
> > >COMFIL 0
> > >
> > >Is there a better way to do that? Once I learn how RUNCOM parameter substitution works I might be able to script it but I'm wondering how something so basic requires so many steps.

You should not need to go through comfiles to copy a file. I think the command you are looking for is:

MOVE dest source

were dest and source are name pairs.

These commands should be in src/basic. All executables have the name TSSDC. I am not sure what the TSSDC name means, but I believe that "Save" internal command generates it.

Also most users would not have write access to the COMFIL's directories. They would only link to things they wanted.

Rich

On Tuesday, March 22, 2022 at 2:15:16 PM UTC-4, Richard C wrote:
> On Monday, March 21, 2022 at 1:42:03 PM UTC-4, Acceptable Name wrote:
> > On Monday, March 21, 2022 at 12:47:30 PM UTC-4, Scott Lurndal wrote:
> > > Acceptable Name <metta....@gmail.com> writes:
> > > >In order to do the equivalent of UNIX
> > > >
> > > >$ cp file1.txt file2.txt
> > > >
> > > >on CTSS, I'm using
> > > >
> > > >UPDATE 1 FILE1 TXT
> > > >COMFIL 1
> > > >RENAME FILE1 TXT FILE2 TXT
> > > >UPDATE 0 FILE2 TXT
> > > >DELETE FILE2 TXT
> > > >COMFIL 0
> > > >
> > > >Is there a better way to do that? Once I learn how RUNCOM parameter substitution works I might be able to script it but I'm wondering how something so basic requires so many steps.
> You should not need to go through comfiles to copy a file. I think the command you are looking for is:
>
> MOVE dest source
>
> were dest and source are name pairs.
>
> These commands should be in src/basic. All executables have the name TSSDC. I am not sure what the TSSDC name means, but I believe that "Save" internal command generates it.
>
> Also most users would not have write access to the COMFIL's directories. They would only link to things they wanted.
>
> Rich

Thanks, Rich. Works like a champ.

The 1969 CTSS Programmer's Guide table of contents does describe MOVE as "Copy files" but in Section AH.3.11 MOVE is only described as copying files from disk to tape and back so I missed it.

Speaking of ITS and CTSS. Before ITS had separately powered
calendar clock hardware installed, it relied on CTSS for providing
the time. When ITS boots up, it uses a dial-out line to connect
to CTSS and check the login prompt for the time and date.

Source: ITS versions around 673 from 1971.

On Wednesday, March 23, 2022 at 2:01:50 AM UTC-4, lars.br...@gmail.com wrote:
> Speaking of ITS and CTSS. Before ITS had separately powered
> calendar clock hardware installed, it relied on CTSS for providing
> the time. When ITS boots up, it uses a dial-out line to connect
> to CTSS and check the login prompt for the time and date.
>
> Source: ITS versions around 673 from 1971.

"Symbolic Mathematical Laboratory" William Arthur Martin 1962 MIT, describes a PDP-6 which is connected to the Project MAC 7094 running CTSS both are running LISP. It does not mention ITS.
https://dspace.mit.edu/bitstream/handle/1721.1/13494/25739127-MIT.pdf

Acceptable Name wrote:
> Lars Brinkhoff wrote:
> > Speaking of ITS and CTSS. Before ITS had separately powered
> > calendar clock hardware installed, it relied on CTSS for providing
> > the time. When ITS boots up, it uses a dial-out line to connect
> > to CTSS and check the login prompt for the time and date.
> > Source: ITS versions around 673 from 1971.
> "Symbolic Mathematical Laboratory" William Arthur Martin 1962 MIT, describes a PDP-6 which is connected to the Project MAC 7094 running CTSS both are running LISP. It does not mention ITS.
> https://dspace.mit.edu/bitstream/handle/1721.1/13494/25739127-MIT.pdf

The most recent date in that document is January, 1967. At that point
there was no ITS, or maybe work on ITS had just about started.

On Wednesday, March 23, 2022 at 10:42:00 AM UTC-4, lars.br...@gmail.com wrote:
> Acceptable Name wrote:
> > Lars Brinkhoff wrote:
> > > Speaking of ITS and CTSS. Before ITS had separately powered
> > > calendar clock hardware installed, it relied on CTSS for providing
> > > the time. When ITS boots up, it uses a dial-out line to connect
> > > to CTSS and check the login prompt for the time and date.
> > > Source: ITS versions around 673 from 1971.
> > "Symbolic Mathematical Laboratory" William Arthur Martin 1962 MIT, describes a PDP-6 which is connected to the Project MAC 7094 running CTSS both are running LISP. It does not mention ITS.
> > https://dspace.mit.edu/bitstream/handle/1721.1/13494/25739127-MIT.pdf
> The most recent date in that document is January, 1967. At that point
> there was no ITS, or maybe work on ITS had just about started.

In general it indicates that dataphone networking was used between the Project MAC 7094 running CTSS and the Project MAC PDP-6 for more than one thing.. There may be other use cases that I have yet to come across in print.

Martin's thesis implies that the reason his system was split between the two mainframes is that there was not enough core on the PDP-6 at the time it was created so some of had to be run on CTSS. He states on page 17 that it would have been possible at the time he wrote the thesis to host the entire system just on the PDP-6 as the core had been upgraded.

Acceptable Name wrote:
> In general it indicates that dataphone networking was used between the Project MAC 7094 running CTSS and the Project MAC PDP-6 for more than one thing. There may be other use cases that I have yet to come across in print.

Oh sure, I didn't mean to imply getting the calendar time was the only use.

> Martin's thesis implies that the reason his system was split between the two mainframes is that there was not enough core on the PDP-6 at the time it was created so some of had to be run on CTSS. He states on page 17 that it would have been possible at the time he wrote the thesis to host the entire system just on the PDP-6 as the core had been upgraded.

Have you encountered any preserved Mathlab software? Archived footage shows equations rendered quite nicely on the PDP-6 340 display.

Lars Brinkhoff <lars.brinkhoff@gmail.com> writes:
> Speaking of ITS and CTSS. Before ITS had separately powered
> calendar clock hardware installed, it relied on CTSS for providing
> the time. When ITS boots up, it uses a dial-out line to connect
> to CTSS and check the login prompt for the time and date.

some of the CTSS
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
people went to the 5th flr to project mac to do multics,
https://en.wikipedia.org/wiki/Multics

others went to the ibm science center on the 4th flr and did
cp40/cms (on hardware modified 360/40 with virtual memory) and then
morphs into cp67/cms when 360/67 standard with virtual memory becomes
available.
https://en.wikipedia.org/wiki/History_of_CP/CMS
https://en.wikipedia.org/wiki/CP/CMS

The science center (360/40 & then 360/67) machines also had external
timer box for reading date/time on startup ... and also supported
virtual machine simulated external box for reading date/time
(channel/device I/O address "0FF' ... aka virtual machine specified as

UNIT 0FF,TIMR

http://www.bitsavers.org/pdf/ibm/360/cp67/
configuration pg32 (I had scanned & contributed 2013)
http://www.bitsavers.org/pdf/ibm/360/cp67/GH20-0856-0_CP-67_Operators_Guide_Oct1970.pdf

--
virtualization experience starting Jan1968, online at home since Mar1970

According to Anne & Lynn Wheeler <lynn@garlic.com>:
>The science center (360/40 & then 360/67) machines also had external
>timer box for reading date/time on startup ...

The 360/91 at Princeton had a box built by a student called TOAD for
Time Of Any Day. I believe it appeared to be a console that typed a
command to set the time when the machine rebooted, as it did a couple
of times a day.

It had a picture of a toad on the front with eyes that lit up on its
creator's birthday.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly