My comment about deprecation was limited to the SUBSYS= keyword. I saw from other replies that Panvalet and Librarian use the keyword. I also discovered a few in-house PROCs with it, several in the context of DB2. Of course the fundamental Subsystem Interface is not going away. I guess the JCL keyword won't either. As I said, never mind.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, November 06, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SUBSYS= ? On 6 November 2017 at 11:49, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > Throughout this thread, I've been haunted by a dim memory of some > SUBSYS action in the distant past. We have not had any in-house SUBSYS > dependencies for decades, so I did not pay very much attention. > > Did IBM announce long ago that SUBSYS was being deprecated? If so, > that might explain the dearth of doc. If not, then never mind. > A couple of comments on this thread... The OP was asking specifically about SUBSYS= on a DD statement (and one might infer, the same via dynamic allocation). Keep in mind that this is but one aspect of the larger Subsystem Interface (SSI) provided by MVS. I think it most unlikely that the SSI would be deprecated any time soon, and I have no recollection of any such announcement. What is clear is that *effectively* the documentation for many subsystem functions has disappeared, because there never was formal doc for much of it, and the source code that was the reference has now mostly gone OCO. Along with the disappearance of the source-code-as-doc is the appearance of warnings in the doc that does exist that only the documented SSI calls may be used. That doc is less than clear about the notion of a user-defined subsystem that defines its own SSI calls (presumably outside the range of the IBM ones) and thus provides services to callers who know how to use them. But I guess that IBM would say that this *is* a supported thing to do, but of course when your subsystem code breaks, don't call IBM. The fuzzy part in the middle is writing your own subsystem that supports IBM-defined calls that are not in the doc, and/or writing your own SSI caller that makes such calls. Is it possible, for instance, to write your own Job Entry Subsystem (JES4, perhaps)? Certainly not using the current IBM doc. The GPSAM doc itself contains some musing on the subsystem interface and its level of doc and support, written at a time when OCO was not even on the horizon. Yet it may even today explain some of why it is as it is. Gil suggests that the z/OS UNIX VFS interface might be an SSI replacement. (I think PFS is the more likely interface, but no matter.) I doubt that this is likely, if only because the PFS/VFS interface comes up relatively late in the game, but the SSI is available very early. And a simple subsystem can be very concise but powerful (GPSAM is less than 200 lines of actual code). Writing even a simple PFS would probably require thousands of lines of code, and there are many subtle and complex calls that must be handled. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
