🚀 go-pugleaf

John Levine <jo...@taugh.com> writes:
> OS/360 QSAM worked pretty much the same way, device I/O in and out of
> a ring of user space buffers.  This shows up in the PL/I LOCATE mode
> for file I/O, where it gives you a pointer to the record it just read
> or that you are about to write.
>
> I suppose it still does in z/OS although these days it's likely all
> faked with copies from memory mapped buffers since modern disks don't
> have variable sized records like CKD disks did.

z/OS still requires CKD disks ... even tho they haven't been made for
decades, emulated (out in the hardware, not back in the system software)
on industry standard fixed block disks. Array/disk controllers have CKD
configuration setups as to simulated disks specified as some variation
on 3380CKD and/or 3390CKD ... simulate 3380 or 3390 track size, simulate
3380 or 3390 tracks per cylinder ... but are allowed to specify number
of cylinders (from much less than any real 3380/3390 to significantly
more than any real 3380/3390).

Even when there were real disks that claimed to be CKD ... there were
already moving to fixed-sized cells (as part of CRC) and number of
records/track calculations included rouding record size up to cell size.

significantly cutting storage requirements, os/360 i/o applications
libraries included building channel programs in user space ...  and then
passing pointer to the (application built) channel program via
EXCP/SVC0. when os/360 moved to virtual memory, EXCP processing faced
the same problem that virtual machine cp67/vm370 faced ... channel
programs required real addresses ... and the application channel
programs were all virtual addresses. The initial OS360 EXCP
implementation for virtual memory borrowed CP67's CCWTRANS which builds
copy of the passed channel program, substituting real addresses for the
virtaul (and some fiddling when buffer crosses non-contiguous page
boundary).

-- 
virtualization experience starting Jan1968, online at home since Mar1970