Talk:Volume Table of Contents

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Other meanings of word VTOC[edit]

The term "Volume Table of Contents (VTOC)" isn't just used on IBM System Z. It is also used by some Unix vendors – Sun/Oracle Solaris and SCO Unixware, among others. Unix vendors use VTOC to mean a partition table. That's consistent with how the term VTOC is used with z/Linux, but different from what it effectively means in the case of z/OS and z/VSE. Mr248 (talk) 23:59, 1 December 2020 (UTC)[reply]

@Mr248:Do you have enough information for an {{About|VTOCs in OSs on IBM S/360 and successors|Article2|and|Article3}} or {{distinguish}} link? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:00, 2 December 2020 (UTC)[reply]
@Chatul: In Solaris, "VTOC" is just the term used for the traditional partition table format on SPARC systems – here, here. As the second document explains, Solaris SPARC now supports GPT (which it calls "EFI disk label") as well as VTOC. On x86, Solaris does something a bit more complex – it sticks a Solaris VTOC inside an MBR partition, for two layers of partitioning (the inner partitions were called slices) – usually you'd just have one MBR partition for the whole disk, unless you wanted a dual boot machine with some other OS such as Linux, Windows, DOS, OS/2, etc. Actually the term "VTOC" for partition table comes from AT&T Unix System V, as this 1982 manual demonstrates. That is where Solaris and SCO Unixware get the term from. And as to where AT&T got it from – quite possibly from IBM! AT&T was a really big IBM mainframe site, certainly back then. And AT&T ported Unix to run under TSS/370 back in 1981. TSS used VTOC as well. I don't know how exactly AT&T's TSS/370-based Unix worked, but I think it is highly likely that it put each Unix filesystem in a TSS/370 dataset. So it would have been using the VTOC as a partition table quite like how z/Linux does it today. As well as that, AT&T had lots of apps running under MVS (and IMS), although they were keen to port them to Unix (which is why they wrote Tuxedo.) But even when they moved stuff off MVS, it often stayed on a 370-compatible hardware platform under Amdahl UTS (which probably used the OS/360-style VTOC as a partition table format too, but I don't know for sure). Mr248 (talk) 03:01, 3 December 2020 (UTC)[reply]
@Mr248:TSS/360 supported two kinds of DASD volumes; Sequential Access Method (SAM) Volume for OS/360 compatibility and page-formatted volume for normal TSS use, including paging and Virtual Access Method (VAM) use. The VTOC for page formatted volumes was organized into 4KiB pages rather than keyed records. It's probably enough to just add a footnote.
TSS had a kernel known as the Resident Supervisor and a user layer known as the Task Monitor. TSS commands used the API for the Task Monitor and had no access to the Resident Monitor API. The AT&T Unix did not run under the Task Monitor but rather directly interfaced with the Resident Supervisor. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 3 December 2020 (UTC)[reply]

Notes section[edit]

The article currently uses <ref group=note>...</ref> for notes, with {{Reflist|group="note"}} in the notes section. I'd like to change it to use {{efn}} for notes, with {{Notelist}} in the notes section, in order to include citations within footnotes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:59, 3 December 2020 (UTC)[reply]