home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / sasl / 5519 < prev    next >
Encoding:
Text File  |  1993-01-05  |  4.6 KB  |  105 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!gatech!usenet.ins.cwru.edu!news.ysu.edu!psuvm!auvm!UMSLVMA.BITNET!NASSER
  3. Message-ID: <SAS-L%93010517160891@UGA.CC.UGA.EDU>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Tue, 5 Jan 1993 16:13:21 CST
  6. Reply-To:     David Nasser <NASSER@UMSLVMA.BITNET>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         David Nasser <NASSER@UMSLVMA.BITNET>
  9. Subject:      Reading Tricky Flat File
  10. Lines: 93
  11.  
  12. Content   : Question(s) / Inquiry
  13. Summary   : How to read VeryStrange gummint file?
  14. System(s) : Large IBM
  15. Name      : David Nasser
  16.  
  17. The file in question is:
  18.    "Thrift Financial Report Quarterly, June 1992"
  19. supplied on tape from:
  20.    US Office of Thrift Supervision, Wash., DC
  21.    National Technical Info Service
  22.    US Dept. of Commerce
  23.  
  24. The doc. for this file is very, *very* sparse: there is no record layout
  25. as such (that we could find).  The data in this file represents
  26. financial info (i.e. assets, net income, etc.) on Savings and Loan
  27. Associations (SNLs) reported to one or more federal agencies.
  28.  
  29. The record length is 128 bytes. All data is character. There are >=180
  30. records per SNL. The first 79 b.  of selected records for the first SNL
  31. follow:
  32.  
  33. G0B192060034904SALEM CO-OP BK                       3 SOUTH BROADWAY
  34. G0C1920600349030790000ROCKINGHAM                  07416033015
  35. G0D192060034933010054110803N NNNNNPAAAAAAAAA     00  PPPPPPPPPPPPPXPPPNPP920731
  36. G0I1920600349SC10   +0000073064SC110  +0000000781SC120  +0000006202SC132  +0000
  37. G0I1920600349SC150  +0000000000SC162  +0000027884SC166  +0000000000SC170  +0000
  38. G0I1920600349SC190  +0000000466SC198  +0000000000SC20   +0000000000SC210  +0000
  39. G0I1920600349SC220  +0000000000SC223  +0000000000SC226  +0000000000SC23   +0000
  40. G0I1920600349SC24   +0000001251SC240  +0000000600SC250  +0000062805SC253  +0000
  41.     (172 similar "G0I" records omitted here)                              +0000
  42. 20S1920600349CSS020348053S.C.B., INC.                         3 SOUTH BROADWAY
  43. 20S2920600349CSS020348053SALEM                       NH000003079
  44. 20S3920600349CSS020348053020187470SALEM CO-OPERATIVE BANK              10001A24
  45. 20S4920600349CSS020348053120+0000000102130+0000000000140+0000000102150+00000000
  46.  
  47. The first 3 recs (starting with "GOB", "G0C", "G0D" resp.) contain
  48. data for identifiers (i.e. name, address, etc.) and are not a problem.
  49. The following 177 "G0I" recs have:
  50.    ID info in the first 13 bytes
  51.    Six repetitions of:
  52.      A  7 b. field with a variable name
  53.      A  1 b. field with a sign associated with:
  54.      A 10 b. field with a data value
  55.    7 bytes of apparent garbage at the end of the record
  56.  
  57. They Have Embedded The Variable NAMES In (nearly) Every Record (some-
  58. thing I have never _ever_ seen before)!
  59.  
  60. For instance, var name SC10 (Cash less valuation allowance) can be read
  61. from bytes 14-20 of the first G0I rec. Similarly, the positive sign and
  62. the actual data value (+0000073064) can be read from bytes 21-31.
  63. SC10=73064. Piece of cake, eh? eh? There are 6(177)=1062 of these
  64. beauties.
  65.  
  66. After the 177 G0I recs are a variable number of 20S recs. These must
  67. be flushed because there are no data definitions (in the non-existent
  68. record layout).
  69.  
  70. It bears mentioning that we also use NTIS bank files which have
  71. conventional record layout with 1 rec/bank, integer binary data rep.,
  72. etc. The G0I recs for 1 SNL occupy 128(177)=22,656 bytes. If the SNL
  73. file were designed like the bank files (they were, previous to 1990),
  74. the same data would occupy 6(177)(4)=4248 bytes, a savings of around
  75. 80%. Say, did someone (i.e. Codd, Date) say something re conservation
  76. of storage being the *essence* of good database design?? Naw, they
  77. were probably just talking about &normalization& (hiccup!).
  78.  
  79. Two Questions:
  80.  1.) Does anyone happen to have any particulars re this file? How was
  81.      it *intended* to be read? Is there a relatively new language
  82.      (i.e. COBOL II or ?) which is engineered to read both variable
  83.      names _and_ values from the same file? Inquiring minds ....
  84.  2.) Does it make sense to try to read / support this data with SAS,
  85.      given that we dont necessarily have 40 daze/40 nites to hand-code
  86.      everything (which will probably change with the next qrtrly file)?
  87.  
  88. Howard, are you out there???
  89.  
  90. TIA. All suggestions welcome.
  91.  
  92. Unrelated:
  93. Has anyone been watching SI dev./testing/support of DEC Alpha AXP?
  94. I will take this (very brief) moment to tip my hat in the direction
  95. of Goodnight/SI.
  96.  
  97.   Prosit,
  98.   David
  99.  
  100.  "I'm sittin' here wonderin',
  101.   would a matchbox hold my clothes?
  102.   I ain't got so many matches,
  103.   but I got so far to go."
  104.     from "Matchbox Blues", Blind Lemon Jefferson, maybe 1927.
  105.