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

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

@Steen
I use DITTO very often - to check VTOC, labels, read BSAM file etc. I like it very much and show my students how to use it. But in this case I need to understand the sysem's behaviore. It seems to be similar to MVS, where allocation is done first only for primary extent and on demand secondary extends are built.

Piotr

Fish thanks for explanation but ... it is different than results of my test.

I have access to z/VSE 6.1 and wrote the program in cobol, which inloop wruet 80 bytes records with increnebted counter and some text. I've declared two extents in JCL? for output file and run the program with different limit for the loop. If the count is low and records fillout only 1st extend, 2nd is not deined in VTOC. I count is bigger, and records cover more tracks, in VTOC are two extents? (on the samevolume). So it seems, that 2nd extend will be allocated only if number of records will exceed the one extent size.?

Declaration in JCL is like below, if you nedd I codein cobol, I can send it also (it's very simple). I know that it is "modern" z/VSE, but I don't think, taht base rukes changed.

Piotr

---

// ASSGN SYS001,A82
// DLBL?? TSTFILE,'VSE3.TEST.DATASET',2024/024,SD
// EXTENT SYS001,VSE001,1,0,960,2
// EXTENT SYS001,VSE001,1,1,970,15
// EXTENT SYS001,VSE001,1,2,962,2

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@...

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
.?

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@...

Hi,

A utility like DITTO might be useful in this case as it can perform a lot of file manipulations on different media, e.g: dasd and tape.

Regard,

Steen

开云体育

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

Hi, Rene,

FYI, OS/360, OS/VS1, and OS/VS2 (SVS and MVS) also had "expiration date protection" of datasets available.? It was mainly used for tape datasets, but it could also be used for DASD resident datasets.? ?Back before RACF, this was one way to protect datasets from accidental deletion.? OS/360 up through MVS also had "password protection" but every shop I ever worked at avoided it like the plague.

Mark

Fish, Mark,

Thanks a lot for this information! I always love to learn something new, specially from people who work on DOS/VS in the past.

Cheers,

Rene FERLAND, Montreal

Hi, Rene 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.

Hope that helps,

Mark S. Waterbury

Piotr Kolasinski wrote:

I know that my questions may be stupid but ..

There are no stupid questions if they are asked. It is only when you don't ask your question that it becomes stupid. ;-)

2. If I define DLBL and EXTENTs in JCL, but phase executing
in JOB STEP does not touch (open, write) the file, will any
extent(s) be allocated and an entry created in the VTOC?

No. If the file is never OPENED, it will never be created.

If it is OPENED however, then the VTOC entries *will* be created with however many EXTENTS you defined in your JCL. If you never write data, then the file will simply remain empty.

3. If I have 2 extents defined, and my program writes data
only for one extent (i.e. only writes a small amount of data,
i.e. only enough to need the first extent), will the second
extent be allocated?

Yes. When a file is created, it is created with however many extents are in your JCL. DOS/VS does not automatically create new extents for you or automatically delete unused extents for you either. You need to MANUALLY maintain all of that yourself in your JCL. DOS is very different than MVS. It does not have any automatic space management logic. YOU, the user, must manage your dasd space manually yourself.

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

mail: fish@...

On Tue, Jan 23, 2024 at 01:56 PM, Piotr Kolasiński wrote:

>> I never heard about this tool.

Me neither, before I asked the same question as you in this group. :-)


>> In real that is not even space management ,but only operation to remove VTOC entries :-)

I can't say for sure, but I would not be surprised if DISP=DELETE on MVS just delete the entries in the catalog and VTOC, not the data set itself on disk.

Cheers,

Rene FERLAND, Montreal

Thanks Rene!

I never heard about this tool . It's really strange that for manage space on dasd volume we have to use "diagnostic" tool (as it is defined in last z/VSE documentation). In real that is not even space management ,but only operation to remove VTOC entries :-)

On Tue, Jan 23, 2024 at 12:44 PM, Piotr Kolasiński wrote:

1. How to remove (delete) BSAM dataset from DASD? In MVS I just use DISP=DELETE and IEFBR14, but how to remove sequenced dataset, previously allocated with DLBL and EXTENTs in JCL?

Hello everybody

I know that my questions may be stupid but ..

1. How to remove (delete) BSAM dataset from DASD? In MVS I just use DISP=DELETE and IEFBR14, but how to remove sequenced dataset, previously allocated with DLBL and EXTENTs in JCL?
2. If I define DLBL and EXTENTs in JCL, but phase exuting in HOB STEP not touch (open, write) the file - will? any extend will be allocated and enty in VTOC created?
3. If I have 2 extents defined, and program write data only for one extend (small record) will second extent will be allocated?

I have strange observation and could not find the answers in available documentation

Thanks
Piotr?

P.S
Sorry for my unfinished previous message, I've incidentally press the enter.

?

Hi,?

I know this thread is somewhat old, but I had exactly the same experience yesterday and managed to recover from it.
I checked both the original POWER input tape as well as the newly created blank tape as both were empty except for two tapemarks on each tape. This was in fact my second attempt to run this job.

I downloaded the POWER input tape again and re-created the blank tape and re-ran the job. On this second (now third) attempt it ran successfully.
My conclusion is; there is nothing wrong with neither the POWER tape nor the DOS/360 utilities. You just have to be very careful when re-running jobs.

Regards,

Steen

The following files and folders have been uploaded to the Files area of the [email protected] group.

• /hello_99bottles_pi.zip

By: Doug Wegscheid <dwegscheid@...>

Description:
"Hello world" and "99 bottles of beer on the wall" in assembler, Cobol, FORTRAN, and PL/I, as well as a PL/I program to calculate digits of pi. All tested on DOS/VS, probably will work on DOS/360. A place for the neophyte to start. Some of these are directly from prior postings in this list (thank you, René!)

On Thu, Jan 4, 2024 at 09:36 AM, Doug Wegscheid wrote:

Prof. Ferland, would you be willing to post your complete job(s)?

Here it is: