Risk 2000

<?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd">
  <record>
    <leader>00000nab a2200000 i 4500</leader>
    <controlfield tag="001">MAP20071030047</controlfield>
    <controlfield tag="003">MAP</controlfield>
    <controlfield tag="005">20080418122012.0</controlfield>
    <controlfield tag="007">hzruuu---uuuu</controlfield>
    <controlfield tag="008">980424e19970401usa||||    | |00010|eng d</controlfield>
    <datafield tag="040" ind1=" " ind2=" ">
      <subfield code="a">MAP</subfield>
      <subfield code="b">spa</subfield>
    </datafield>
    <datafield tag="084" ind1=" " ind2=" ">
      <subfield code="a">936</subfield>
    </datafield>
    <datafield tag="100" ind1="1" ind2=" ">
      <subfield code="0">MAPA20080237585</subfield>
      <subfield code="a">Baker, Pamela Smith</subfield>
    </datafield>
    <datafield tag="245" ind1="1" ind2="0">
      <subfield code="a">Risk 2000</subfield>
      <subfield code="c">by Pamela Smith Baker</subfield>
    </datafield>
    <datafield tag="520" ind1=" " ind2=" ">
      <subfield code="a">The year 2000 problem is the result of the method used by most computer programmers to code dates used in computer legacy systems. When computer technology was young and memory space was very limited, every line of program space was very limited, every line of program space written was precious. Conserving memory was imperative, so computer programmers coded calendar dating systems usin MM-DD-YY (month, day, year), the shortest method available. As the memory capacity of computers grew, many programmers continued to use the six-digit dating system out of habit. Others did not anticipate that the software they were creating would las into the next millennium. Whatever the reason for continuing to use a six-digit code, it is now apparent that not many programmers or users realized the system would not work for the year 2000. When December 31. 1999 turns into January 1, 2000 most computer programs around the globe will read 01-01-00 and immediately assume that the year is 1900</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080608118</subfield>
      <subfield code="a">Programas informáticos</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080630584</subfield>
      <subfield code="a">Sistemas controlados por ordenador</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080543488</subfield>
      <subfield code="a">Códigos</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080557393</subfield>
      <subfield code="a">Calendarios</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080588953</subfield>
      <subfield code="a">Análisis de riesgos</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080591182</subfield>
      <subfield code="a">Gerencia de riesgos</subfield>
    </datafield>
    <datafield tag="650" ind1="1" ind2="1">
      <subfield code="0">MAPA20080546991</subfield>
      <subfield code="a">Empresas</subfield>
    </datafield>
    <datafield tag="740" ind1="0" ind2=" ">
      <subfield code="a">Risk management</subfield>
    </datafield>
    <datafield tag="773" ind1="0" ind2=" ">
      <subfield code="t">Risk management</subfield>
      <subfield code="d">New York</subfield>
      <subfield code="g">nº 4, April 1997 ; p. 55-58</subfield>
    </datafield>
  </record>
</collection>