Let me give an example of a relatively simple subsystem that I have encountered. I wrote a product some years ago that interfaced with program source code. Most customers of course had their source code in PDS(E)s. Some customers however had their source code in Panvalet libraries. (Apologies to my friends at CA if I get any of the details wrong.) The Panvalet libraries use a proprietary structure that is not directly readable using any of the IBM xSAM access methods. (Well, probably readable, but the logical source code is not retrievable using xSAM.) Panvalet, however, provides a subsystem (PAM?) that reads their libraries and has a subsystem interface that lets them appear as PDSs. So with relatively little attention on my part, a customer could code //SYSLIB DD SUBSYS=(PAM,LIBRARY=MY.PAN.LIBRARY) or something like that and voila! it appeared to my program to be a PDS. I could do FINDs and READs and so forth.
The emulation was not perfect, or perhaps better to say "not complete." My product supported a COBOL-like COPY capability. When the program hit a COPY it did a NOTE to remember where it was, and then a FIND on the new member. When the member hit EOF, it did a POINT to get back where it had been. I don't remember the details as I write this, but PAM did not support IIRC a TTR POINT -- so I had to (1) be cognizant that it was a SUBSYS situation and (2) do something else -- some kind of FIND as I recall. (I could have done that in all cases but I made the code dual-path because I already had the POINT TTR code working and I assumed it was better performing, assuming it was available). Suppose you wanted to make a product that was a random number generator. One way you could do the API would be to write a SUBSYS so that a program could open a DD and read a "virtual file" of random numbers. (Not the obvious way to solve the problem, but you get the idea.) I think a SUBSYS makes sense where you want to be compatible with existing "normal" I/O -- like Panvalet's PDS emulation -- but have your own code behind it. Drive a network-attached printer of some sort -- that sort of thing. I'm not a SUBSYS expert -- just throwing what I know out here trying to help. > A subsystem is a service provider that performs one function or many functions, but does nothing until it is requested. Definition of a server (as in client and server), right? An awful lot of software documentation is long on trees and short on forest. It's a lot easier to document what each option does than to "why would you want to do this? And suppose you wanted to accomplish X, how would you configure this software to do so?" Would reading the documentation for one of the IBM subsystems most like what you want to accomplish be a help? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Friday, November 3, 2017 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SUBSYS= ? Hmm. That subsystem "documentation" is really long on details about how to do specific minor things, but really short on theology: what a subsystem can and can't do, how it fits into the scheme of things, etc. Example: A subsystem is a service provider that performs one function or many functions, but does nothing until it is requested. Um, ok. I'd suggest that description applies to almost any program, and is thus pretty close to meaningless. Am I just thick, or is there really not a lot here that would let someone create a subsystem without already essentially knowing how? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
