On Mon, Jul 13, 2009 at 9:43 AM, Kris Buelens<[email protected]> wrote: > SYSPROF EXEC was a great enhancement. Before there was only assembler code > (DMSINS). SYSPROF was the step IBM made to make the CMS startup > tailorable. Only later people started thinking: SYSPROF is IBM code one > should not change.
It's a gray area and things evolve over time. When you start shipping working sample code for an exit that a customer may fill in, the risk exists that critical function is shipped in it and you require the customer to rework his exit with an upgrade (or miss function). Ideally the product should work without the exit filled in, and the interface should not changed In IGS the major modification to SYSPROF was to add a dozen hooks to calls a local exit that was filled in. However, there's many fingers in the pie and the interface is so delicate that the IGS platform shipped with a standard local exit that called yet another local exit that the installation could fill in. But again, that was sufficiently complicated that they ship a boilerplate sample where you stick in local processing again. We had a lot of fun moving the customization into VMLINK - there's neat things you can do with pre-exit and post-exit that are pretty isolated. So the code invoked by SYSPROF and friends does a 'VMLINK ABCTOOLS ( FILE ABCDISKS' and that VMLINK control file described which disks to access, at what file mode, including processing that determined the right disk based on the user's credentials, picked up a backup disk when the primary was not available, etc. The advantage is that you don't have to predict all the possible intervention, but the caller will simply "link the disk" and you make it as complex as you need (and resist the temptation to write REXX variables into the caller environment to make up for restrictions in the interface). Rob
