On Tue, 29 Jan 2019 at 11:07, Bob Bridges <[email protected]> wrote: > > I'm the Top-Secret admin for a client whose system programmer retired a > couple years ago. The client tapped another employee to take his place, and > she's learning the job with frantic haste but insists with some justification > that she's not a system programmer yet. Me, I came into security through the > applications-development side so I'm not even close. > > Together she and I are trying to learn SMP/E. The immediate purpose is so we > can apply some TSS-related PTFs, but really, it's become clear to me that we > need no excuses to make it a priority; SMP/E is kind of important.
Lots of good info already. I have just a comment or two, more in passing than specifically answering your questions. > Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran > this thing in the past never did any ACCEPT, ever, except for the original > function code. Your use of LIST XREF is Very Good. As an ISV we are forever asking customers to send us the result of SMP/E LIST . commands, and half the time we get the output from LIST SYSMODS or LIST PTFS or the like, which doesn't tell us everything. You can always ask SMP/E something specific, or you can say "tell me everything you know", and save that large chunk of output and then search it with ISPF or on your desktop or wherever you like to do that kind of thing. If you want to document the situation at a given time, I highly recommend storing the result from a LIST ALLZONES XREF. Then you can do simple find commands on PTF IDs or module names or even things like the comments in PTFs that you no longer can find the source for. The earlier suggestion to use the z/OS UNIX interface is an alternative if you are comfortable with UNIXy line commands. You could probably send its output to your favorite tool(s) which could even be a desktop spreadsheet. > Question #3) My partner the not-sysprog has in mind that maybe we need to set > aside this CSI (which is dedicated to Top Secret) and create another one > starting with the base software and build up from there. I didn't realize > this could be done, but she thinks she can do it. If it'll work, I like it; > we'll know in that case what we have, which we do not at present. Anyone > have any thoughts on this plan? If you are in any doubt as to what you have, then it's a good idea. It may be obvious, but let me say it: the SMP/E CSI is a bit like the catalog on z/OS. It has all kinds of information about what's where, and so on, but the actual datasets as defined by the DDDEF entries are definitive as to what the data *is*. If you update one or the other independently, then you are likely to be in big trouble, just as you would be if you restored a catalog from a backup independent of the datasets it points to, or the other way around. So treat the CSI and the datasets it points to as a unit when it comes to backup/restore operations. It's not impossible to manage the pieces independently, but it's usually a bad idea. Also, it is certainly possible for someone to have updated a target or DLIB dataset known to SMP/E outside SMP/E using the Binder or IEBCOPY etc, and then you have no reliable way of knowing what your state of affairs is. This is perhaps unlikely if your predecessor was a wise and experienced person, but it happens. Someone needs to bang on a quick fix or apply a ZAP in a rush, and then the "paperwork" (CSI) doesn't get updated to match. Simple, standalone products maintained by SMP/E are, well - simple and standalone. Typically the target zone's LOAD dataset is used as the production STEPLIB'd load library. Or a promote to production or staging through test layers scheme that is outside of SMP/E is used to make an exact copy of that module data to one or more production datasets. But something like TSS, and certainly some of the z/OS components, have specific requirements as to where the modules live, such as LPALIB or Linklist datasets. The promotion process in this case can be more complex, and with any system-level product you run the risk of breaking the system if you get it wrong. SMP/E will do its best (for example, recovering from an out of space condition while building a load module), but it can't fix what it doesn't know about. Any such product will come with detailed instructions for initial installation and ongoing maintenance, which you need to follow carefully. Again, this may be obvious, but if you are both new to sysprogging, I think it can't hurt to sayit. Best of luck in learning about and using what you have inherited! Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
