Mike,

Have a look here:
? ?/g/H390-DOSVS/files/Yahoo-Archive

The "files.zip" is all the files from the old yahoo groups DOSVS "files" area, and contains many old DOS/360 "optional source" tapes, zipped.? Perhaps you might find what you are looking for in there?? I admit it will be older, DOS/360 Rel. 26, but may be better than nothing and may not be that different.

See also:
? ??

where you can find a copy of the original distribution tapes for DOS/360 and TOS/360.

Hope that helps,

Mark S. Waterbury

开云体育

Hi Mike,

I believe most of the files are already present in the distribution by George Shedlock - mostly as macros and source books. I think you will be able to find the code for the DOS supervisor, most of Power and the assembler. However I don't think you will find the code for VTAM, Cobol, PL/I and Fortran.
Are you looking for something specific?

Regards,

Steen

Does anyone have the DOS/VS R34 source files or know where to get them?

@Daug

Unfortunatelly I use "modern" DITTO running under CICS/ICCF in z/VSE. This edition has standard panels and is fully interactie. Of course it also has batch mode, but it is less usable.

Piotr

Fish - please don't apologize. You are doing fantastic work, thank's for that!


I asked on this group, because I it was unexpected for me, because all books and materials I read, didnt notice such behavior.
A few years ago I was aked about preparing and executing training aobout z/VSE for some group of z/OS system programmers. I didn't touch VSE many years and had to refresh and expand my knowledge (many things chnaged since VSE 2.4, the last version used by me). Today we don't have real tapes (but is the tape emulation in VSE which supports AWS format), connectuin to system may be supported on z/VM by Linux TCPIP stack, Java connectors are provided for VSE POWER, VSAM etc.
But now VSE is not an IBM system anymore, it was sold to external company (https://21cs.com/vsen/).
After preparing that training I did that four times yet for different teams, with 2 years period between them. Maybe I'm one? of few persons on this planet, who do such things in 2024 :-)
My love to the old opersting systems (nt only IBM, but also DEC PDP), give me many happy ours, and part of that is thanks to your work.

Piotr? ?

On Wed, Jan 24, 2024 at 04:27 PM, Piotr Kolasiński wrote:

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.

Is there some material you can share on how to use DITTO for those tasks? I'm conversant with MVT and it's progeny, but I'm a total DOS neo.

Piotr Kolasinski wrote:

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:

// 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

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
same volume). So it seems, that 2nd extend will be allocated
only if number of records will exceed the one extent size.

You could be right. I apologize. I was going from memory.

It might be because the files is declared "SD" and not "DA"? Maybe with "SD" (sequential data) files, the behavior is like you say, but it is different when the file is declared "DA" (direct access)? I forget! It had admittedly been many, many years since I have messed with DOS/VS(E). I'm too busy with Hercules to have the luxury of playing with / experimenting with the many operating systems it is capable of running. If/when I find the time, I will try the experiments you suggest. But I believe you are probably correct. Please accept my apologies.

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

mail: fish@...

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.

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