That's really just a difference in terminology, not a different concept.
z/OS datasets are mostly record-oriented, quite different from the stream-oriented files familiar to people from Unix-like and Windows platforms.
However, it would be a mistake to think that datasets are record-oriented and files are stream-oriented. z/OS has one type of stream-oriented dataset (VSAM LDS), and other operating systems have record-oriented files (e.g. IBM i, OpenVMS).
In general, "dataset" is just a rare synonym for file.
In the area of z/OS in particular, datasets belong to the non-Unix part of the operating system (non-VSAM datasets, VSAM, PDS(E), etc), while files (or to give their full name, "z/OS UNIX files") belong to the Unix part of the OS. But a VSAM LDS and a z/OS UNIX files are conceptually quite similar, you could say they are two different implementations of the same fundamental concept–the main differences between them being which filesystem namespace they appear in, and which API is the native API for accessing them. (The internals of how they are stored and what filesystem code is used to access them are also somewhat different.)
Languages such as FORTRAN and COBOL didn’t allow recursive calls, and multi-processing wasn’t in the picture, so stack frames could just be given fixed addresses, for example just before the called function’s entry point.
Around 1960, Lisp and ALGOL changed that.
It was later than 1960 on many platforms, including IBM mainframes, where Lisp and ALGOL were always fringe languages, primarily limited to the computing research community, while the vast majority of mainframes were instead being used for business and government data processing, and numerically-oriented scientific computing. On IBM mainframes, it really started when PL/I decided to borrow a lot of concepts from ALGOL, but PL/I wasn't generally available until at least 1966.
A number of later developments increased the demand for reentrancy/recursion: transaction monitors such as CICS; the advent of C and C++ on mainframe platforms (which didn't happen until the 1980s); the decision to add ALGOL-style features to COBOL and FORTRAN.
The real issue is that the original calling convention chosen by OS/360 / MVS / z/OS didn't feature a stack. It was based on the assumption that code would not be recursive/reentrant. Each routine would have a static memory block to save registers in. That was a software design issue (OS and compilers), not a CPU design issue. However, a lot of application code was written in COBOL and FORTRAN, which in their original versions didn't support recursion/reentrancy at all, and a top-down coding style discouraged recursion/reentrancy anyway, so this was less of an issue in practice than it might have been. And lots of other vendors in the 1960s (such as DEC and HP) made the same design decision.
Over time, the demand to support recursive/reentrant code became stronger. The first approach was to have each routine use GETMAIN (equivalent of malloc) to dynamically allocate a save area. This succeeded in providing recursion/reenterancy, but cost a lot in performance. Later they introduced the equivalent of a stack, called a "dynamic save area" (DSA) – rather than having each routine's prologue call GETMAIN to allocate a register save area, they'd just use a slice of that dynamic save area allocated once at the beginning of the program. Newer versions of z/OS introduce a new calling convention XPLINK, which is even closer to what other platforms do – it is more efficient, the stack grows in the normal way (top-down not bottom-up), and overflow is detected using a guard page instead of a manual check in every function prologue.
However, due to the demands of backward compatibility, z/OS has to support all three calling conventions – the original one without a stack, the legacy DSA calling convention, and the new XPLINK stack calling convention – complete with thunking macros to generate code so code using one can call code using the other. At least if you stick to C, the compiler handles all this for you, and you just have to declare which calling convention to use before you declare the function (via `#pragma linkage`). Rather similar to the situation with MS-DOS and 16-bit Windows, where each function had to declare which calling convention it wanted to use (cdecl, pascal, stdcall, fortran, etc)