home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / p_man / cat5 / array_sessions.z / array_sessions
Encoding:
Text File  |  1998-10-20  |  6.7 KB  |  133 lines
  1.  
  2.  
  3.  
  4. aaaarrrrrrrraaaayyyy____sssseeeessssssssiiiioooonnnnssss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeessssssssiiiioooonnnnssss((((5555))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      aaaarrrrrrrraaaayyyy____sssseeeessssssssiiiioooonnnnssss - introduction to array sessions
  10.  
  11. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.      An array session is a group of processes all related to each other by a
  13.      single unique identifier, the  aaaarrrrrrrraaaayyyy sssseeeessssssssiiiioooonnnn hhhhaaaannnnddddlllleeee.  The processes don't
  14.      necessarily have to belong to the same parent-child chain, and don't even
  15.      have to be running on the same system.  However, the default is for a
  16.      child process to inherit the array session handle of its parent, so in
  17.      the average case the processes in an array session are
  18.      parents/siblings/children of each other and reside on the same system.
  19.      An array session is considered to be active from the time it is first
  20.      created until the last process that is a member of it exits.
  21.  
  22.      The goal of an array session is to correlate all the processes that
  23.      belong conceptually to the same login session or batch job, even if those
  24.      processes are running on several separate machines in an array.  Then,
  25.      with the help of external software, the array session can potentially be
  26.      treated as a single unit for the purposes of accounting,
  27.      checkpoint/restart, job control, etc.
  28.  
  29.      A process can create a new array session and place itself in it by using
  30.      the _n_e_w_a_r_r_a_y_s_e_s_s(2) call.  Ordinarily, this would only be done programs
  31.      like login or rshd, which are effectively logging a user into the system,
  32.      and programs like batch queue systems or cron, which are running jobs on
  33.      behalf of another user.  A new array session is assigned an array session
  34.      handle that is unique to the current system only.  If the process is
  35.      actually part of an existing array session on another system (e.g. the
  36.      process is part of a single job running across more than one node in an
  37.      array) it can change the handle of its array session to that of its
  38.      "parent" on the remote system using the _s_e_t_a_s_h(2) call.  The parent's
  39.      array session handle would presumably be unique across the entire array,
  40.      although it would be the parent's responsibility to arrange for that.
  41.      The range of values that the kernel will assign as array session handles
  42.      is configurable so that it would be possible to design a server to
  43.      provide array-unique handles.
  44.  
  45.      An array session is _n_o_t the same thing as a POSIX session, though the two
  46.      concepts are similar on a single system.  One important characteristic of
  47.      a POSIX session is that all of the processes included within it share a
  48.      single controlling terminal.  That distinction does not exist for array
  49.      sessions: processes from two different array sessions might both be using
  50.      the same controlling terminal (e.g. by way of the newproj command) or
  51.      contrarily two processes in the same array session might have two
  52.      different controlling terminals (e.g. when running on different systems).
  53.      However, in the simple case of a local login with no remote interactions
  54.      an array session and a POSIX session would include the same set of
  55.      processes.
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. aaaarrrrrrrraaaayyyy____sssseeeessssssssiiiioooonnnnssss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeessssssssiiiioooonnnnssss((((5555))))
  71.  
  72.  
  73.  
  74. SERVICE PROVIDER INFORMATION
  75.      Associated with every array session is a block of data known as the
  76.      sssseeeerrrrvvvviiiicccceeee pppprrrroooovvvviiiiddddeeeerrrr iiiinnnnffffoooorrrrmmmmaaaattttiiiioooonnnn.  It is typically used to tag the array
  77.      session with certain identifying information for accounting or
  78.      statistical purposes.  For example, a batch queuing system might store
  79.      information about the queue name and job initiator in this area.  The
  80.      service provider information is reported as part of the array session
  81.      accounting data when the array session finally terminates.
  82.  
  83.      The amount of storage available to an array session for holding service
  84.      provider information can vary from 0 to 1024 bytes, though the most
  85.      common lengths are 64 (the system default) or 128 bytes.  If no specific
  86.      action has been taken to associate service provider information with an
  87.      array session, then the default system service provider information will
  88.      be associated with the array session instead.
  89.  
  90.      The _x_a_c_t_l(1m) program or the _a_r_s_o_p(2) and _a_r_s_c_t_l(2) system calls can be
  91.      used to query or modify the contents or size of the system default
  92.      service provider information or the service provider information of a
  93.      particular array session.  A user must generally be privileged to make
  94.      any modifications.  Although the format of the service provider
  95.      information is not enforced by IRIX, there are two recommended formats
  96.      defined in /usr/include/sys/extacct.h:  "format 1" (defined by the
  97.      structure aaaacccccccctttt____ssssppppiiii____tttt) is for systems that use 64 bytes of service
  98.      provider information, and "format 2" (defined by the structure
  99.      aaaacccccccctttt____ssssppppiiii____2222____tttt) is for systems that use 128 bytes of service provider
  100.      information.  Only format 1 service provider information is supported on
  101.      systems running IRIX 6.4 or earlier.
  102.  
  103.      The system default service provider information is 64 bytes in length and
  104.      is always cleared to zeroes when the system is initially started.  If
  105.      desired, the default size can be changed for boot-time array sessions by
  106.      modifying the ssssppppiiiilllleeeennnn kernel variable using _s_y_s_t_u_n_e(1m).
  107.  
  108. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  109.      getash(2), getspinfo(2), newarraysess(2), setash(2), setspinfo(2),
  110.      extacct(5), projects(5).
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.