23 Jun
2026
23 Jun
'26
1:17 p.m.
Yes, DCALGOL is still around and actively used. It is a superset of the standard Extended
ALGOL, and originally exposed some special APIs and data types for talking to the Datacom
Processor front-end. Those APIs are still used, although the "front end" is now
TCP/IP.
The language has since been extended with numerous other APIs for use primarily by
system-programmer types. There is also a DMALGOL compiler primarily used internally with
the DBMS, DMSII. All three ALGOL variants have been compiled from the same source code
since sometime in the '70s.
DCALGOL would have been no different than ALGOL for dealing with tapes, and I'm
surprised you found it harder to do with the MCP than with OS/360 EXCP I/O. Depending on
the block and tape label formats, you may have had to do your own deblocking, and possibly
read the tape as unlabeled, but the MCP I/O Logical I/O subsystem was quite rich even in
1975. You had to understand how the file attribute settings worked when dealing with
non-native tape formats, however -- I've seen that trip a lot of people up. As an
alternative, a variant of Logical I/O called Direct I/O was available, which is user-mode
asynchronous I/O that reads and writes raw blocks. It's basically a thin wrapper
around the MCP's internal Physical I/O mechanism.
I know this is water long over the dam, but I'd be interested in hearing what kinds of
issues you encountered, and if possible, a reference to the DEC formats you were trying to
read.
23 Jun
23 Jun
2:17 p.m.
On Jun 23, 2026, at 4:17 PM, paul.kimpel--- via cctalk
<cctalk(a)classiccmp.org> wrote:
Yes, DCALGOL is still around and actively used. It is a superset of the standard Extended
ALGOL, and originally exposed some special APIs and data types for talking to the Datacom
Processor front-end. Those APIs are still used, although the "front end" is now
TCP/IP.
The language has since been extended with numerous other APIs for use primarily by
system-programmer types. There is also a DMALGOL compiler primarily used internally with
the DBMS, DMSII. All three ALGOL variants have been compiled from the same source code
since sometime in the '70s.
DCALGOL would have been no different than ALGOL for dealing with tapes, and I'm
surprised you found it harder to do with the MCP than with OS/360 EXCP I/O. Depending on
the block and tape label formats, you may have had to do your own deblocking, and possibly
read the tape as unlabeled, but the MCP I/O Logical I/O subsystem was quite rich even in
1975. You had to understand how the file attribute settings worked when dealing with
non-native tape formats, however -- I've seen that trip a lot of people up. As an
alternative, a variant of Logical I/O called Direct I/O was available, which is user-mode
asynchronous I/O that reads and writes raw blocks. It's basically a thin wrapper
around the MCP's internal Physical I/O mechanism.
I know this is water long over the dam, but I'd be interested in hearing what kinds
of issues you encountered, and if possible, a reference to the DEC formats you were trying
to read
DOS labeled tape, so a file header of 14 bytes followed by data blocks followed by tape
mark, repeat for more files.
The trouble I ran into, at least from my reading of the documentation, is that in
unlabeled mode I could read the first file but MCP would treat the tape mark as the end
and not go past it. I wanted to do the normal DEC thing, giving the program a name to
match where it would read the label, see if it matches, if not skip to the tape mark and
repeat. I could find no way to do that.
Quite possibly it was a case of lack of knowledge. I did not know the OS in depth (having
only spent that summer vacation on it). And the staff wasn't too helpful to a
semi-random outsider (son of a prof but not a student there).
On OS/360 the same was true for most I/O modes, except EXCP where I could issue a skip to
tape mark command directly and keep going.
paul
24 Jun
24 Jun
7:32 a.m.
Paul Kimpel
(mobile) +1-619-917-3756
*Subject:* [cctalk] Burroughs DCALGOL vs tapes [from dead computer
language thread]
*From:* Paul Koning <paulkoning(a)comcast.net>
*To:* cctalk(a)classiccmp.org <cctalk(a)classiccmp.org>
*CC:* paul.kimpel(a)digm.com
*Date:* Tue, 23 Jun 2026 14:17 -0700
The way to get past a tapemark in Burroughs ALGOL was (and is) to use
the close-without-rewind statement, "CLOSE(F, *)", where F is the file
identifier. If you were not at EOF at that point, the MCP would space
the tape to the next EOF. You could then continue reading the next file
by doing an explicit open, or just start reading to do an implicit open.
Two adjacent tapemarks was the typical convention for end-of-tape.
That would work with either labeled or unlabeled tapes. The B6700 MCP
would read ANSI (then USASI) standard labels in either EBCDIC or ASCII
from its beginning, but of course each OS had its own interpretation of
the standard. The way to open a specific file on a multi-file labeled
tape was to use a file title of the form "MFID/FID", where MFID is the
tape volume name from the VOL1 label and FID is the name from the HDR1
label. The MCP would spin down the tape looking for that file, crossing
reels as necessary. I don't know how well that would have worked with
DEC tape labels -- there was some issue with doing it with IBM tapes,
and I forget the details -- but you still wold have been able to step
down the tape yourself using the CLOSE(F,*) method.
Sorry that you're learning this 50 years after you needed it.
Paul
> On Jun 23, 2026, at 4:17 PM, paul.kimpel--- via cctalk <cctalk(a)classiccmp.org>
wrote:
<snip>
> DCALGOL would have been no different than ALGOL
for dealing with tapes, and I'm surprised you found it harder to do with the MCP than
with OS/360 EXCP I/O. Depending on the block and tape label formats, you may have had to
do your own deblocking, and possibly read the tape as unlabeled, but the MCP I/O Logical
I/O subsystem was quite rich even in 1975.
<snip>
You had to
understand how the file attribute settings worked when dealing with non-native tape
formats, however -- I've seen that trip a lot of people up. As an alternative, a
variant of Logical I/O called Direct I/O was available, which is user-mode asynchronous
I/O that reads and writes raw blocks. It's basically a thin wrapper around the
MCP's internal Physical I/O mechanism.
I know this is water long over the dam, but I'd be interested in hearing what kinds
of issues you encountered, and if possible, a reference to the DEC formats you were trying
to read
DOS labeled tape, so a file header of 14 bytes followed by data blocks
followed by tape mark, repeat for more files.
The trouble I ran into, at least from my reading of the documentation, is that in
unlabeled mode I could read the first file but MCP would treat the tape mark as the end
and not go past it. I wanted to do the normal DEC thing, giving the program a name to
match where it would read the label, see if it matches, if not skip to the tape mark and
repeat. I could find no way to do that.
Quite possibly it was a case of lack of knowledge. I did not know the OS in depth
(having only spent that summer vacation on it). And the staff wasn't too helpful to a
semi-random outsider (son of a prof but not a student there).
On OS/360 the same was true for most I/O modes, except EXCP where I could issue a skip to
tape mark command directly and keep going.
paul
2
days inactive
3
days old
2 comments
3 participants
participants (3)
-
Paul Kimpel -
Paul Koning -
paul.kimpel＠digm.com