Kris Buelens <kris.buel...@gmail.com> 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.
That goes back a way ;-) Yes, I agree that SYSPROF EXEC was a great enhancement (but not without it's downside). Someone who knew what they were doing could modify DMSINS and, I would argue that, you still need to know what you are doing to modify SYSPROF - even though it seems simpler to do. Before I restructured the local changes to SYSPROF to externalise them, it was a nightmare. Whenever there was new VM release with any change to the IBM supplied SYSPROF code then we had to totally rework our local fixes onto the new base or to ignore the new base and go with our old modified SYSPROF as a full part replacement (which is what tended to happen). Now it is a relatively simple job to insert the hooks without messing too much with the IBM supplied function. The problem with modifying a number of things like this is that it is all too easy to break IBM function or to lock yourself out from new/changed function. At least with the PROFILE EXEC's of the TCPIP workers there are hooks for local customisation. Yes, the move to SYSPROF was a good idea but it is a pity it didn't go just that one step further to keep IBM function and any local customisation separate. Colin Allinson Amadeus Data Processing GmbH
