Post by Peter Flass Post by Scott Lurndal Post by J. Clarke
What's the file name? Hint--while the Unix subsystem recognizes
tree-structured directories and the like, that is not the only method
Z/OS uses to recognize files. And what's a "file" anyway? Z/OS
doesn't borrow Unix's conceit that "everything is a file". The
documentation uses the word "dataset", not the word "file". Unix
people think that they're the same. They aren't.
Oh nonsense. A collection of bytes on disk. That's what both
systems are accessing. The nomenclature matters not. The ease
of access does. Unix, as a stream of bytes, allows the application
to impose any structure on the stream of bytes it likes. Given the existence
of symbolic (and hard) links in the filesystem, there is no possible
use for a DD card in unix.
There is _nothing_ better about the MVS/zOS way.
Here we disagree. I wrote the IO subsystem for Iron Spring PL/I to handle
record-formatted data and buffering doesnât play well with length-prefixed
records (RECFM=V). Something very simple in zOS becomes complicated. Of
course CKD disk I/O is all emulated in zOS these days, somitâs the OS
thatâs doing the work.
Unix doesn't have (and never has had) "length-prefixed records".
There is _no_ structure, simply a stream of bytes to which random
access is provided.
Post by Peter Flass Post by Scott Lurndal Post by J. Clarke Post by Dan Espen
If you start a UNIX program (or just a C program) when it
attempts to read STDIN or write STDOUT and there is no allocation,
the system does dynamic allocation.
Which system? The JCL processor? To what does it dynamically
allocate? JCL is not designed to be run from a terminal.
Which again, was a failing on IBMs part. The Burroughs MCP commands
were designed to be run from a card reader, command file (WFL),
operator console or CANDE (timesharing) session or from a programmatic
call to the MCP (SPO message).
?EXECUTE APP; FILE INPUT=FRED CRD; FILE PRINTER=SHORT/OUTPUT PRN FORM
Executes the named application and assigns the internal filename
INPUT to the card reader (waiting for a deck named FRED) and the
internal filename PRINTER is assigned to the printer named SHORT
with special forms loaded.
If you don't want to go to the printer, but rather a printer backup file on
?EXECUTE APP; FILE INPUT=DECK1 DSK; FILE PRINTER=OUTPUT PBK
There is never a need to manually allocate disk space (which consists
of a sequence of fixed-sized sectors; none of the CKD nonsense).
Sequence or checkerboarded? Pre-allocating disk space is an attempt to keep
Burroughs files had one or more areas (up to 100). An area was some multiple
of the files record size multiplied by the blocking factor. Each area
was mapped to a contiguous set of sectors on a device (areas could easily be
allocated across multiple devices within a single file).
As the basic allocation size was a sector (100 bytes each on legacy DISK
media, 180 bytes each on PACK media (Large systems, e.g. B6500 et al, also
used 180 byte sectors), extent-based allocation did lead to fragmentation;
the operator could use the SQ (Squash) and SQP (Squash Pack) command to
initiate a defragmentation operation. I don't recall ever needing to
squash any of our packs during 8 years of MCP development, so it was
If there was need to ensure that the entire file was contiguously allocated
on disk, it was certainly possible, but was very rarely used.
All 100-byte (DISK) media on a system was considered a single filesystem (DISK),
which could be divided into 8 allocation groups at system initailization;
the application could specify which of the allocation groups to use (one
was reserved for the MCP, for log files etc).
180-byte (PACK) media were grouped into one or more pack Families. The family
name was used when creating and accessing the files (much like a directory
name). A given family could consist of one or more packs; in the MCP
department, we had a family for the MCP source, one for the intermediate
object files, and several for other development activities. Additional
space could be added to a family at any time with a simple operator
command (assuming handy spare disk drive hardware and/or removable media).
Copying files was a simple as
?MOVE AND SET (SUMMARY, COMPARE) === FROM OLDFRED(PACK) TO FRED(PACK)
would move every file from the pack OLDFRED to the pack FRED.
?COPY AND SET (COMPARE) === from FRED(PACK) TO FREDBK(TAPE)
?PFM CRDDPK INDECK FRED/DECK12 80 9
would copy the card deck identified by the name INDECK to the file DECK12
on family FRED (with 80 byte records, 9 records per block; 720 bytes or
four 180-byte sectors).
THe card deck would have been introduced with a control card:
<cards in deck>