Where do we start?
Begin by recognizing that this is a history lesson; you're working with a computer architecture introduced 50 years ago. The computers were much larger (physically), much smaller (in disk and RAM), and much much slower. Things that we've come to expect from even the least-expensive consumer laptop--including multiple address spaces, virtualization, a file system and file manager, and graphics--were very expensive and very rare. The closest anything came to a "personal computer" experience was time-sharing, something that DOS/360 did not support on its own.
DOS/360 does not have a file system. It does access disk drives, albeit small by current standards. Two models were used on real IBM System/360 mainframes: a 6.9MB Model 2311, and, later, a 27.8MB Model 2314. A mainframe running DOS/360 generally had at least three, and often many more, disk drives.
When creating a file, you had to specify exactly where that file should reside: which disk drive, and exactly where on that drive. Most of the time you specified track addresses and DOS/360 converted that into cylinder-track addresses, but not always, and one always had to keep the track/cylinder relationship in mind. Many system utilities use cylinder and track numbers in their control cards.
Same thing when using a previously created file: disk drive, starting track, and number of tracks. Sometimes you could get away with just specifying the disk drive and DOS/360 would find it, but not always. It depended on the type of file and the nature of the access planned by the program for the file.
To further complicate things, mainframe disks did not use a fixed block or sector size. Record sizes were specified in the program. And while fixed-length records were common, there was no convention that records created by different systems for different purposes should be the same size. The high cost of disk storage created great pressure to allocate record sizes that were just large enough--perhaps with some small space for expansion--and no larger.
Electronic Accounting Machines processed 80-column punched cards, and these can be thought of as 80-character fixed length records with no record terminator. A deck of such cards was considered a file. Disk-based files allowed for increased record lengths, but much of the programming and many systems operated as if they were working on card files. Just very wide cards, and different widths from application to application.
Programmers and system designers spent much time reviewing track capacity tables to determine how to organize data into records and blocks of records for maximum efficiency. Very minor differences in choice of record size or block size could make a dramatic difference in how much data could actually be stored on a nominally 6.9MB 2311 disk drive.
The Student Text Introduction to IBM System/360 Direct Access Storage Devices and Organization Methods gives you an excellent overview of DASD complexities and includes track capacity tables for disks commonly used with DOS/360. If you have never worked on an IBM mainframe, give this text some time. You don't need to become an expert--unless you wish to--but a little time here will help you understand how file placement and allocation works.
If you're looking for an inviting graphical user interface, look elsewhere. Nor will you find an inviting >, $, or # prompt as part of a character user interface. In fact, you will not find a user interface. Users were supposed to stay away from the mainframe and patiently await printouts and, perhaps, card decks.
While certain commands could be typed on an operator console, a card reader was the mainframe's primary source for instructions and programs. Compile a program? Key the program into a deck of cards, insert that deck into a deck of Job Control Language cards, put the whole thing in the card reader, and press start. After a decent interval, results of the compilation were printed on a line printer.
Execution of a program worked the same way: Job Control Language cards named the program to be executed and the names of the files to be processed (read, updated, and/or created). Any report would be printed on a line printer.
A corollary of "no command prompt" is that there is no editor. Making any change to a disk-based parameter file involved keying a card deck, putting it in the reader, pressing start, and waiting for the printout.
It was not uncommon in this environment for Systems Programmers to maintain decks of cards for those parameter files. When changes were needed, the deck was changed and the disk-resident version was simply replaced. Card filing cabinets were common.
Operator commands were primarily used for starting up or shutting down the system, cancelling jobs or directing output from those jobs to printers or card punches.
This should not be a surprise, as DOS/360 is a 1960's creation, and IP was at its earliest a 1970's creation. And the ubiquity of IP-based communications tools didn't happen until much later. The successors to DOS/360 ended up getting an IP stack, albeit as a licensed product for a separate fee to IBM.
But even if you can intellectually accept the absence of decent general-purpose network tools like file transfer and Telnet, it feels really weird. There is no capability to connect to a DOS/360 mainframe to edit a parameter file or load in a data file. Forget about using network tools to reorganize a disk volume. There is no way to leverage your personal computer as a tool to maintain the mainframe. Except for using a text editor to create a card deck to be submitted to the Hercules card reader.
Learn about DOS/360 versus OS/360 in For OS/360 Users, or proceed to a discussion of the available DOS/360 distribution materials.