On Mon, 8 Jan 2024, at 09:17, Bret Busby wrote:
> But, apart from the functionality that I have not seen in any other
> operating system, of using an extra file descriptor of version number,
> so the whole filename would be something like
> <filename>.<extension>;<version number>
IBM's MVS & its successors, most recently z/OS, have something
similar called a GDG (or Generation Data Group).
It's handed via system catalogs - which are the indexes which tell
you where specific files are. Dataset names do not contain disk
(or tape, or virtual tape) names and don't have the sort of
hierarchical names relating to a root & mount point like most
files in Linux.
For a lot of files the catalogs say which disk a file is currently on
& the disk's "VTOC" - volume table of contents - says where on
the disk that file is.
Anyway if one defines eg
DEFINE GENERATIONDATAGROUP -
(NAME(PQR.TEST.THIS) LIMIT(8) SCRATCH NOEMPTY)
then the system will maintain 8 separate copies of a file
named "PQR.TEST.THIS".
You can refer to the newest created one as PQR.TEST.THIS(0)
or the next oldest by PQR.TEST.THIS(-1) or its ancestor by
PQR.TEST.THIS(-2) etc. You can refer to the whole lot (so
eg to read all the contents of as many of these files as
happen to exist at some point in time) simply by leaving
the (n) part off the name.
To create a new file you refer to PQR.TEST.THIS(+1); after
you finish using the file the system throws away the very
oldest one & rejigs its index of them all so this latest one
is now able to be referred to via (0) - and the specific
files previously referred to by -1, -2, -3 etc all shift up by
one.
For the whole duration of the process that creates a new
generation of such a file, the index of subsidiary versions
is locked so that no other process can simultaneously
create new ones or delete any of them (ie not just delete
the one about to be the oldest, no longer required one).
The files are typically used for storing chunks of
continuously occurring data, eg transactions or logs. You
might start each business day with no files in such a GDG
then accumulate any number of successive tranches of some
sort of transaction data in them, then - perhaps at the end
of day process the whole lot into one "daily" file & reset
the GDG ready for the next day's processing. You might
then have a set of daily GDGs which get merged into
weekly files, monthly ones etc.
You can also find out the internal name by which a
specific generation of the file is named & refer to it
directly, eg PQR.TEST.THIS.G00
- thus meaning one doesn't have to know such a file's
relationship to the successive generation structure.
Back in the 1990s when I last used these there could be
up to 255 or so files in each GDG. That limit might have
increased since then.
Ref:
https://www.ibm.com/docs/en/zos/2.2.0?topic=files-processing-generation-data-groups
--
Jeremy Nicoll - my opinions are my own.
