Most if not all of your initialization does not have a true requirement to run under INITRTN. You can create 2 entry points (one that parses INITRTN parms and the other that parses PARM= parms / set KEY0).You need to re-init any fields that that are not current because of a restart and you will need to use an enqueue to ensure single threaded.
You might not even need INITRTN or want to rely on INITRTN? Do you require running early in the IPL process? Do you need functionality that is only available to INITRTN? Do you run without a related STC? If not, then you can probably init during your STC startup and make IEFSSI ADD conditional. You can't depend upon a customer IPL so dynamically add the SSCT if not defined will actually work better and reduce the customization complexity. Several products simply have you add a start command to COMMNDxx or IEACMDxx. Using this method only needs your SSCT functions be loaded to LPA / global. Jon Perryman. >________________________________ > From: "[email protected]" <[email protected]> > >Robert Rosenberg wrote: >>I assume the re-run issue is that the location where the routine >>resides is locked in when you first define the Sub-System and >thus can not >>be replaced with a new copy (which will be ?>somewhere else in memory). Why >>not make the routine have a >static location and be composed of a LOAD of the >>real routine? >That way it would be able to locate a new copy that was >>handled >by the CSVDLYPA routine. > >I have given considerable thought to such a process to test this "A Front End" >Routine or STUB. > >Having stated that I wont be able to re-run the IEFSSI ADD a 2nd and 3rd and >4th time without receieving a "DUPLICATE SUBSYSTEM ID. IS my assesment correct >? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
