开云体育

I worked on DOS/VS systems back in the mid- to late 1970's.? While DOS/VS has some extent protections as mentioned, actual management of space on volumes is manually performed.? This was usually managed by the system programmer's.? The sysprog (usually only one) had to know what was where.

Areas for each partition were reserved for work files.? These were usually the same area on separate volumes of the same DASD type and attached to the different partitions by means of the same LU number.? That would allow a programmer to have his batch programs jobs run in any of partitions with the same JCL.

And while a VTOC entry can be removed, its data on the volume remains until physically overwritten, eventually.

Of course, with Hercules it is extremely easy to add physical volumes to the configuration.? But not quite so easy to add them to the DOS/VS Supervisor.? That requires a new assembly.

Like others, I am sure I forgot a lot of details since then.? But the amount of human work to manage the DOS/VS system was significant.? With just a single user, that is not as complicated as it sounds.? I would encourage you to understand exactly how the system is set up.? If you already do understand that, wonderful.? If not do so.? The acts of learning this information will itself educate you.

DOS/VS is dumb.? You are the smart one.

Those who have worked with DOS/VS system you have certainly were smart.? So some of what I refer to may already be inherent in the system.? Still you need to understand it.

WATCH THE OPERATOR CONSOLE.? It will save you! Or KILL you.

I worked in a shop where the operators did not understand the console or the messages.? Shop was new to DOS/VS.? When an operator's message came up they would just hit enter.? That was hell!? ENTER is in many cases NOT the right response.

Harold Grovesteeen

Harold Grovesteen wrote:

I worked on DOS/VS systems back in the mid- to late 1970's.
While DOS/VS has some extent protections as mentioned,
actual management of space on volumes is manually performed.
This was usually managed by the system programmer's. The
sysprog (usually only one) had to know what was where.

I would to add to that, that due to this need for manually maintaining the location of all datasets (files) on the system, many shops wrote their own (or used someone else's) LVTOC ("List VTOC") utility, that would not only produce a report of all of the files and their locations on each disk volume (in both CCHH format as well as in TTTT relative track format as well), but would also identify all "gaps" or free spaces as well, making it much easier to manually "locate" space for new files.

Typically, there were large free spaces on one or more volumes where temporary work files could be allocated (with a zero days expiration date), whereas most permanent files (that never expired) would have their DLBL and EXTENT information added to the system's "STDLABEL" or "PARSTD" startup procedures (PROCs).

That way, when you submitted your job to run the program designed to update your file, your JCL wouldn't need to have any DLBLs or EXTENTs in it (because they were already defined in the system's label area). This made it much less likely to make mistakes.

You can think of the system STDLABEL and PARSTD labels as a type of "catalog". If you wanted to "catalog" a file, you added it to the appropriate label area. If you wanted to delete it, you would removed it.

But as mentioned in my and Harold's posts, it was all MANUAL. The system standard labels (STDLABEL) and partition standard labels (PARSTD) were all MANUALLY maintained, and only updated when needed (which was rarely).

Welcome to the primitive world of DOS/VS! :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Just one minor point,you don't need to rebuild the DOS or DOS/VS supervisor to add devices. You can use Add and Del statements at ipl time, subject to the limit specified in the original build
.?

Eddy Balem wrote:

Just one minor point,you don't need to rebuild the DOS or
DOS/VS supervisor to add devices. You can use Add and Del
statements at ipl time, subject to the limit specified in
the original build.

I was going to mention that too, BUT... It's a lot easier to simply add the new devices to the supervisor (and then shutdown and re-ipl the new supervisor) than it is to have to manually type an 'add' statement each time you IPL. When it comes to DOS/VS, automation is a good thing.

(And before you mention it, yes I know you could also add such statements to a card deck and submit it to the card reader during IPL, but again it's much easier IMO to simply enter the command 'set' (with no arguments) followed by the command 'dpd' (followed by no arguments) during IPL than it is to type a command that submits a card deck to the card reader. But that's just my personal opinion of course. Each person is different.

I also like the fact that by having all of your devices defined in the supervisor that it's all self documenting and all in one place too. It's similar to having one Hercules configuration file with everything need you need in it versus having multiple separate parts spread across multiple file via include statements. Less parts equals less likelihood of mistakes, smoother automation and easier debugging should something go wrong.

But again, that's just my opinion.

Your mileage may vary as they say. :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hi, Harold and Piotr,

From what I recall, from the last century, it was probably the 1980s the last time I actually worked with DOS/VSE at all "for real"... and it was a long time ago.

The way DOS/360 and DOS/VS and DOS/VSE worked, you used // DLBL and // EXTENT cards to define data sets (files) on DASD.? The DLBL was just a way to assign a "label" to the file, e.g. to create a VTOC entry.? It has an optional "date" parameter, where you can specify an expiration date or number of days until the dataset "expires" ... if you do not specify it, it defaults to 7 days.

Anyway, the way I recall it worked is, when you want to "erase" or "delete" a file, you just create a new file over top of it, using the same or overlapping extents. Then, the DOS system checks the VTOC for those extents and if there is an entry, it checks the expiration date. If it has already expired, no problem, and not operator intervention is required.

But, if the entry has not yet expired, the system operator gets a message, the very popular "UNEXPIRED DATASET" ... blah, blah blah ... to which the operator must reply to allow the current job to overwrite those extents.? If the operator allows it, then DOS deletes the old VTOC entry, before creating a new one, based on the new // DLBL card in the JCL.

At least, that's how I seem to remember it worked.

So, you did not really have to use any fancy special utility for "normal" operations and normal jobs.

(OS/360 -> VS1 -> VS2 (SVS and MVS) also had "date protected data sets" e.g. where you assign an EXPDATE via the JCL.? The rules are similar.)

Hope that helps,

Mark S. Waterbury

On 1/24/24 13:14, Fish Fish wrote:

Eddy Balem wrote:

Just one minor point,you don't need to rebuild the DOS or
DOS/VS supervisor to add devices. You can use Add and Del
statements at ipl time, subject to the limit specified in
the original build.

I was going to mention that too, BUT... It's a lot easier to simply add the new devices to the supervisor (and then shutdown and re-ipl the new supervisor) than it is to have to manually type an 'add' statement each time you IPL. When it comes to DOS/VS, automation is a good thing.

(And before you mention it, yes I know you could also add such statements to a card deck and submit it to the card reader during IPL, but again it's much easier IMO to simply enter the command 'set' (with no arguments) followed by the command 'dpd' (followed by no arguments) during IPL than it is to type a command that submits a card deck to the card reader. But that's just my personal opinion of course. Each person is different.

I also like the fact that by having all of your devices defined in the supervisor that it's all self documenting and all in one place too. It's similar to having one Hercules configuration file with everything need you need in it versus having multiple separate parts spread across multiple file via include statements. Less parts equals less likelihood of mistakes, smoother automation and easier debugging should something go wrong.

But again, that's just my opinion.

Your mileage may vary as they say. :)

I vaguely remember this, but at the shops I worked at, it was never used.? The Supervisor was updated.? For all of the reasons Fish gave.? Sorry for my incomplete memory.

Admittedly, in a single user, DOS/VS system, using the at IPL time method would not be that big of a deal, but even then I suspect one would get tired of manually typing stuff at each IPL. I know I do.

Harold Grovesteen

I agree that once you have a fairly static I/O config it makes sense to build a supervisor that matches,
but you always did need the function when building a DOS or DOS/VS system from a distribution tape.
Starting from a supervisor which did not, in general, match your configuration, it was essential to be able to ADD/DEL.
Today with Hercules we are in the fortunate position of being able to define at run-time matching I/O addrs.
Also a supervisor assembly took quite a while on a 360/30 or 370/125.