On 18 June 2012 09:34, Shmuel Metz (Seymour J.) <[email protected]> wrote: > In <[email protected]>, on 06/16/2012 > at 02:07 PM, Anne & Lynn Wheeler <[email protected]> said: > >>note that CICS was originally to avoid having to use as few >>os/360 resources as possible ... because os/360 processing was >>horrendously heavy weight and bloated. > > Was that the reason, or was it because PCP and MFT[1] did not have ATTACH?
I don't know CICS, but HASP also used few of the available OS services. Here's an excerpt from a little 1970-ish course handbook (SR23-3697-0) that explains why, with some not so gentle jabs at the performance of the OS services. I'm sure many of the CICS reasons were similar: <quote> HASP STRUCTURE The primary goal in the design of any execution support system such as HASP must be the efficient manipulation of the various resources required for processing. The first design steps must then include the determination of what resources will be required and the careful application of sound programming design techniques to achieve an efficient and consistent solution to the allocation of these resources. A study would reveal that HASP requires the following resources: 1. Main Storage 2. Direct-Access Space 3. Input/Output Units 4. Central Processing Unit Time 5. Input/Output Channel and Unit Time 6. Programs 7. Jobs 8. Interval Timer Since these resources are essentially the basic facilities provided by the Operating System, it would at first seem that these facilities would be sufficient to meet the requirements of HASP. Further studies show, however, that the philosophies of the Operating System's services are not always consistent with the design requirements of a system such as HASP. For instance, the main storage services provided by the Operating System are very flexible and comprehensive but fail to meet the requirements of HASP in the following areas: • As requests for main storage are serviced, memory becomes fragmented in such a way that eventually a request for storage cannot be serviced for lack of contiguous memory even though the total amount of storage available far exceeds the requested quantity. • As the amount of available storage decreases, the requestor becomes more susceptible to being placed in an OS WAIT state or being ABENDed. These conditions are both intolerable to HASP. • The primary use of main storage in HASP is for buffering space for input/output purposes. These input/output purposes require that an Input/Output Block be associated with each segment of main storage which the Operating System Main Storage Supervisor, only naturally, does not provide. This means that HASP would have to construct such a block for each main storage segment it required. In a similar fashion the Direct-Access Device Space Manager (DADSM) provides flexible and comprehensive services for normal job processing requirements but fails to meet the requirements of HASP in the following areas: • Because of the data set concept employed by DADSM, the "hashing" or "fragmentation" problem described above also impacts the allocation of direct-access space. • The data set concept complicates the simultaneous allocation of storage across many volumes (for selector channel overlap). • The DADSM limit of extents per volume tends to cause volume switching, and the associated time delays are intolerable to HASP. • DADSM consists of non-resident routines which must be loaded for each direct-access space allocation service. Because of the frequent allocation requirements, the associated overhead involved in the loading of these routines would degrade the performance of HASP to a certain extent. Since the unit-record Input/output units which the scheduler allocates to the jobs being processed in other partitions must be available for use by HASP, HASP must be responsible for the allocation of its own input/output units. The Operating System Task Supervisor Is responsible for the allocation of Central Processing Unit (CPU) time to all tasks in the system. The different functions of HASP (reading cards, printing, punching, etc.) could be defined as individual OS tasks except for the following considerations: • Defining each function as a separate task would prohibit HASP from being used with anything other than a variable-task system. • Inter-task communication and synchronization is many times more complex than intra-task communication and synchronization. The Operating System Input/Output Supervisor is responsible for the allocation of all input/output channel and unit time. It completely meets all requirements and is used by HASP for all input/output scheduling. The Operating System Interval Timer Supervisor provides complete interval timer management services but limits these services to one user per task. Since HASP has many functions which have simultaneous interval timer requirements, an interface must be provided which will grant unlimited access to the OS Interval Timer Supervisor. </quote> Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
