Page 1 of 1

How to start on a mainframe?

PostPosted: Mon Feb 12, 2018 7:11 pm
by Farbauti
Hi there,

I work in IT more than 20 years now, but only recently I got in touch with mainframes.
Perhaps I'm too much into windows/linux thinking but it's hard for me to get used to MVS/zOS.

Just one example: I learned that "files" are called "datasets". But then there is this 'allocate' command, that needs both files and dataset(s) defined. So what's the deal?

I know I lack lots of fundamentals, so my question in general is: Can anyone point me to good introduction documentation? For self study at best.
I have access to a toybox mainframe, but I need some guidance first ;)

Cheers,
Tom

Re: How to start on a mainframe?

PostPosted: Mon Feb 12, 2018 7:49 pm
by enrico-sorichetti

Re: How to start on a mainframe?

PostPosted: Mon Feb 12, 2018 8:38 pm
by steve-myers
Farbauti wrote:... Just one example: I learned that "files" are called "datasets". But then there is this 'allocate' command, that needs both files and dataset(s) defined. So what's the deal?

There is a fundamental difference between a "file" as used in *nix and Windoze: a "file" is a named stream of bytes; a "data set" is a named stream of bytes divided into one or more identifiable "records." This differentiation is most apparent with what are sometimes called text files in *nix and Windoze where what amount to records are separated by an arbitrary byte (in *nix) or bytes (in Windoze).

In some ways the TSO ALLOCATE command is confusing to everyone. It is the link between the batch JCL DD statement which is required for a program to access data sets and a TSO session. The original designers of OS/360 did not want individual programs to specify data sets dynamically for at least three reasons. First, as they envisioned it, the mechanics were quite complex; second, if individual programs did it, each program would have a different appearance because each program would go about it in a different way; and third, given the extremely limited storage resources in the original OS/360, it was not considered suitable for problem programs to litter themselves up with allocating the data they needed. Several years later, when TSO was added to OS/360, a severe subset of dynamic allocation was added, but strictly for TSO. Still later, with MVS, dynamic allocation was generalized to include almost everything that could be done in JCL allocation and made available to all programs.

This not to say everything is perfect. The documentation is in a confusing location, Authorized Assembler Services Guide, which implies it's not available to most programs and programmers, though 99% of dynamic allocation can be used by just about anyone. Most dynamic allocation problems are documented as codes rather than plain text messages that ordinary humans have a chance of understanding. There are at least two service routines to create plain text messages. The one most commonly used is documented among TSO publications, though it can be used by batch programs very easily.

Now you were commenting on the FILE keyword in the ALLOCATE command. I have always thought it was inappropriate. It should have been DDNAME, and, in fact, at some point - I don't know when - DDNAME was added as an alias for FILE in the ALLOCATE command. In truth, DDNAME is rarely used, as most of us dinosaurs have been brainwashed, as it were, to use FILE because that's what it was in 1971 when we started using TSO. By all means, use DDNAME, though it may confuse a dinosaur reviewing your work.

Re: How to start on a mainframe?

PostPosted: Wed Apr 04, 2018 7:48 pm
by Sam Hobbs
I think that something that would help would be a cross-reference of IBM mainframe concepts and terminology with corresponding concepts and terminology for other operating systems. I do not know where something like that is.

There are things like jobs and job steps and processes and tasks that would be of more interest for programmers so I don't know how useful things like that would be for you.

Some concepts that seem unique to IBM are (1) libraries and (2) generations of files. It has been such a long, long time since I worked with those that I don't remember the names.

In the IBM mainframe and COBOL environment there is the concept of fixed-length records. They are extremely common. In Windows fixed-length records are very uncommon and most young programmers choke at the idea of reading and writing fixed-length records directly into and from records or structures in memory.

As for the allocate command I think "allocate command" should be qualified as the TSO allocate command as Steve Myers says. Also as Steve implies, another way to say "allocate command" is to call it dynamic allocation (as in creation of a DD name but not the reservation of the space). As best as I remember dynamic allocation is a SuperVisor Call (SVC); in other words, the OS has a way to do dynamic allocation. I don't know if there is an official explanation for why there was not a dynamic allocation capability in OS originally but my guess is that they just did not think about it. It would be interesting to know if dynamic allocation capability existed in MVT originally.

Re: How to start on a mainframe?

PostPosted: Thu Apr 05, 2018 1:26 am
by steve-myers
Sam Hobbs wrote:As for the allocate command I think "allocate command" should be qualified as the TSO allocate command as Steve Myers says. Also as Steve implies, another way to say "allocate command" is to call it dynamic allocation (as in creation of a DD name but not the reservation of the space). As best as I remember dynamic allocation is a SuperVisor Call (SVC); in other words, the OS has a way to do dynamic allocation. I don't know if there is an official explanation for why there was not a dynamic allocation capability in OS originally but my guess is that they just did not think about it. It would be interesting to know if dynamic allocation capability existed in MVT originally.

MVS dynamic allocation is an SVC. SVC is a hardware instruction that is comparable to the x86 INT instruction. It does not use the call gate (as used in Windoze) like interface provided by the PC instruction. Of course if it was being built today, from scratch, I'm sure the DYNALLOC macro would use the PC instruction.

There was never an intent to provide dynamic allocation in OS/360. Frankly, given its relative complexity and the storage constraints under which the system operated it is hard to fault this decision. The other issue is dynamic allocation is a resource definer; the OS/360 architecture says the resource definer is JCL; perhaps no one wanted a second, competing resource definer. Looking back 40 and 50 years I think the decision was correct.

Dynamic allocation in OS/360 TSO was through a external function called IKJDAIR which could only be used in TSO. I do not recall any discussion about the method IKJDAIR used to perform its allocation functions. I presume it was an SVC - probably SVC 99 as it is today, but the actual interface was never widely discussed. In OS/360 and VS2 Rel 1 I used IKJDAIR. IKJDAIR is still there, and is still documented, but I switched over to MVS dynamic allocation as soon as it was available as it was more flexible than the DAPL/DAPB (those refer to the IKJDAPL and IKJDAPBxx control blocks used by the IKJDAIR) interface. I've been developing a largish TSO command for the last few months (CBT "file" 966 for anyone interested) that uses MVS dynamic allocation. It could use DAPL/DAPB/IKJDAIR just as well as MVS dynamic allocation, but it would have taken me longer to write as dusting off 40 year old memories to create the DAPL/DAPB/IKJDAIR code would create problems. There would be little practical difference in code complexity, though a third party attempting to maintain the code might have more trouble with DAPL/DAPB/IKJDAIR, simply because the maintainer would more likely be familiar with MVS dynamic allocation than IKJDAIR.