On 2018-01-29, at 23:00:25, Jon Perryman wrote: >> Paul Gilmartin wrote: > >> The design integrity of OS/360's I/O architecture has been much >> compromised with the advent of utilities which gratuitously >> (sometimes with a goal of performance) enforce device dependence. >> Such utilities should at least support, if possible, a fallback >> to device-independent I/O. > >> As an irritating example, AMATERSE refuses to UNPACK an archive >> from a UNIX file. > > AMATERSE was formally IBMTERSE. I believe it was considered an FDP and used by > I believe it was TRSMAIN, FDP and not IBM component prefix.
> IBM support. Due to customer demand, it was added to MVS. I doubt that much > IBM precipitated that demand because SR consistently required that problem documentation be supplied tersed. Some customers balk at downloading anything from the Internet. I suspect something similar impelled adding the non-POSIX script(1) to OMVS. > effort goes into maintaining this program. It queried the dataset attributes > which don't exist for Unix files. I believe it wanted RECFM=F blksize=2048. > LRECL? Those attributes can be supplied in JCL DD or via DYNALLOC. Really. They are then merged by OPEN into the DCB you so admire. In some cases the utility itself fills in the blanks. I believe the stumbling block is often DSORG which JCL (allocation?) does not permit overriding for UNIX files. > AMATERSE is a bad example. > Out of interest, what other utilities are you talking about? > IEBCOPY PDSU (it would be unreasonable to expect it for IEBCOPY PDS). Especially, Rexx SYSEXEC. There are EXECs I'd like to be able to use both within and outside OMVS with no need to copy them back-and-forth. I found nothing in the doc prohibiting this so I went to SR and was told the obstacle was DSORG. WAD. Again, I can fool it by prefixing an empty temp Classic PDS. -- gil
