From: joemonk64@gmail.com   
      
   > Well, as I wrote. it is possible that 360 architects thought that    
   > 360 does not need relocation register. But but practice showed    
   > that base registers do not work for relocation.    
   >    
   > I am not sure what you wanted to say in second sentence: 360/67 and    
   > 370 series suport paging, so they really have no need for relocation    
   > register. But for other 360 models, there is no replacement and    
   > relocation register would be quite useful.   
   >   
      
   The 360/370/390/z/arch memory model has been flat since day 1.   
      
   The concept of relocation was handled by the way the 360 object format was   
   done. For programs that were too big, they would be written as overlays ...   
   pieces of code that would not be loaded unless needed.   
      
   Remember, for OS/360, there were two different modes of operation: MFT   
   (multitasking - fixed # of tasks) and MVT (multitasking - variable # of   
   tasks). In the IBM mainframe world, a program of any size can be run by what   
   is known as an initiator. The    
   initiator processes the JCL and looks at EXEC statements for a REGION=   
   parameter. That says how much memory a given job step needs.   
      
   So, an initiator would go looking for chunks of memory to allocate to the job   
   step.  It would start the job step, and then as GETMAIN requests were issued,   
   if not on a VS system, the job would wait until enough real memory became   
   available. On a VS    
   system, this would never happen because the real memory was always back by   
   DASD.   
      
   When DAT came along, it helped tremendously. So, each job could in essence   
   have access to its own exclusive 16M address space. Hence the term MVS ...   
   multiple instance virtual storage.   
      
   Joe   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)