home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / sasl / 3379 < prev    next >
Encoding:
Text File  |  1992-07-21  |  8.1 KB  |  207 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!darwin.sura.net!ukma!psuvax1!psuvm!auvm!UNCVM1.BITNET!WDAVIS
  3. Message-ID: <SAS-L%92072120431304@VTVM2.BITNET>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Tue, 21 Jul 1992 20:40:29 EDT
  6. Reply-To:     Walter Davis <WDAVIS@UNCVM1.BITNET>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         Walter Davis <WDAVIS@UNCVM1.BITNET>
  9. Subject:      LIMDEP on IBM
  10. Lines: 195
  11.  
  12. hi SAS-l'ers
  13.   this has nothing to do with SAS, but there are enough users
  14. of LIMDEP and IBM systems types on the list that I thought I
  15. would forward these notes, especially since they don't seem
  16. to be in wide circulation (I got them from STAT-L).
  17.  
  18. There appears to be a problem running the new version of LIMDEP
  19. on IBM systems.  The notes below explain the problem and,
  20. hopefully, provide some fixes.
  21.  
  22. hope this helps,
  23.  
  24. Walter Davis <WDAVIS@UNCVM1>
  25. Department of Sociology
  26. UNC - Chapel Hill
  27.  
  28.  
  29.  
  30.         ----------------------------
  31.           1st note here
  32.         ----------------------------
  33.  
  34.  
  35. I was asked by the vendor of LIMDEP to send this out for the benefit
  36. of those who are having difficulty installing the new mainframe version.
  37.  
  38. +----------------------------------------------------------------------+
  39. | Linda Atkinson, Statistician     | BITNET:  ATKINSON@ERS             |
  40. | U.S. Department of Agriculture   | Tel:     (202) 219-0505           |
  41. | Economic Research Service        | FAX:     (202) 219-1292           |
  42. | Washington, D.C.                 |          (ATTN: RM 240)           |
  43. +----------------------------------------------------------------------+
  44.  
  45. ----------------------------Original message----------------------------
  46. Linda:  (Listen carefully and see if you can pick up my frustration.)
  47.         The problem you are having with LIMDEP, as are several other
  48. IBM system users, is due to a quirk in IBM's Fortran.  I won't call it
  49. a bug, but it is unique to IBM.  The problem is this:  I am trying to
  50. read your data as a string of characters, so that LIMDEP can interpret
  51. it and free you from having to provide a format -- i.e., an unformatted
  52. read.  Since I do not know how many characters there are on a line, or
  53. even if there will be the same number of characters on each line, I
  54. try to read 255 characters.  If the line contains less than 255 characters,
  55. here is what happens:
  56.         IBM mainframes:  Program crashes, as you saw
  57.         All other types of mainframes, and all PCs:  Program reads as
  58.                 many characters are as present, and fills remainder
  59.                 with blanks.
  60. I suppose I will have to program around this.  If I am successful, I will
  61. let you know.
  62.         Perhaps you could send the previous paragraph out on your network.
  63. (I do not access it.)  In any event, it does not have to do with being
  64. unfamiliar with IBM systems.  I know more about them than I wish to  right
  65. now.
  66.  
  67.  
  68.         ----------------------------
  69.           2d note here
  70.         ----------------------------
  71.  
  72.  
  73. This is a second message I received from Dr. Greene about LIMDEP, with
  74. more detailed information on work-arounds for the mainframe version.
  75.  
  76. +----------------------------------------------------------------------+
  77. | Linda Atkinson, Statistician     | BITNET:  ATKINSON@ERS             |
  78. | U.S. Department of Agriculture   | Tel:     (202) 219-0505           |
  79. | Economic Research Service        | FAX:     (202) 219-1292           |
  80. | Washington, D.C.                 |          (ATTN: RM 240)           |
  81. +----------------------------------------------------------------------+
  82.  
  83. ----------------------------Original message----------------------------
  84. Dear Linda:  (Listen closely and see if you can pick up my frustration.)
  85.  
  86.         The problem you are having with LIMDEP is now very familiar to me,
  87. and is arising from two sources:  (1) An incompatibility between IBM's Fortran
  88. and every other Fortran with which I am familiar, which, as you can
  89. imagine, is a lot and (2) A bug in the IBM fortran compiler which, as far
  90. as I know, has always been present, and shows no sign of being eradicated.
  91. For your programmer's benefit, the offending statement is
  92.  
  93.         READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,255)
  94.  
  95. which follows statement number 241 in subroutine LOAD.  This line is
  96. attempting to read a character string of indeterminate length, in
  97. individual bytes.  Since I do not know how long the line is to be, I just
  98. read a long line.  Here is what happens if the line has less than 255
  99. characters:
  100.  
  101.         IBM fortran (MVS, CMS, all of them): Program crashes, as you saw.
  102.         All other fortrans:  Unread characters are filled with blanks.
  103.  
  104. Now, notice that the statement contains an ERR=992.  This is designed to
  105. prevent programs which encounter data errors from crashing.  It is not
  106. working.  That is the bug.  There is no ambiguity about it as far as I can
  107. see.  The odd thing about this, once again, unique to IBM, is that this
  108. whole problem disappears a) if the 255 above is changed to an 80, whether
  109. or not the line read is actually 80 characters long or not and b) if
  110. the line really is 255 characters long, for obvious reasons.
  111.  
  112.         From your point of view, there are a couple of short term fixes
  113. you can use:
  114.         (1)  Use only formatted data sets, and include format statements
  115. in the READ statement.
  116.         (2)  The following block of code can replace its current
  117. counterpart in subroutine LOAD.  This reverts back to the 80 character
  118. limit of version 5.1, but apparently IBM fortran will not choke on it.
  119.  
  120.   240  IRD=ZERO
  121.   241  DO 242 J=ONE,80
  122.   242  LINE(J)=' '
  123.        READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,80)
  124.  2421  FORMAT(255A1)
  125.        IF(LINE(1).EQ.'.'.AND.LINE(2).EQ.' ')LINE(1)='*'
  126.        DO 2473 J=ONE,79
  127.  2473  IF(J.GT.ONE.AND.LINE(J).EQ.'.'.AND.LINE(J-ONE).EQ.' '.AND.
  128.      &    LINE(J+ONE).EQ.' ')LINE(J)='*'
  129.        DO 243 J=ONE,80
  130.        IF(LINE(81-J).EQ.' '.OR.LINE(81-J).EQ.',')GO TO 243
  131.        LINE(82-J)='$'
  132.        GO TO 244
  133.   243  CONTINUE
  134.        GO TO 241
  135.   244  IFR=ZERO
  136.        DO 245 J=ONE,80
  137.        IF(LINE(J).EQ.' ')LINE(J)=','
  138.   245  IF(LINE(J).NE.','.AND.IFR.EQ.ZERO)IFR=J
  139.  
  140. Once again, it is a mystery to me why IBM has locked itself into this 80
  141. character format, but apparently, it is the bottleneck.  Keep in mind,
  142. again, for unformatted data sets, you are limited to 80 character lines.
  143.  
  144.         It might be helpful if you could put this out on to the network,
  145. since I do not access it.
  146.  
  147.                 Regards,
  148.                 Bill Greene
  149.  
  150.  
  151.         ----------------------------
  152.           3rd note here
  153.         ----------------------------
  154.  
  155.  
  156.  
  157.  
  158.  
  159. +----------------------------------------------------------------------+
  160. | Linda Atkinson, Statistician     | BITNET:  ATKINSON@ERS             |
  161. | U.S. Department of Agriculture   | Tel:     (202) 219-0505           |
  162. | Economic Research Service        | FAX:     (202) 219-1292           |
  163. | Washington, D.C.                 |          (ATTN: RM 240)           |
  164. +----------------------------------------------------------------------+
  165.  
  166.  
  167. ----------------------------Original message----------------------------
  168.  
  169.  
  170.  
  171.  
  172. Memo:
  173. To:     Users of LIMDEP 6.0 on IBM Mainframe systems
  174. From:   W. Greene, developer, LIMDEP
  175. Date:   July 21, 1992
  176. Re:     Problems reading unformatted data sets.
  177.  
  178. Dear IBM User:
  179.  
  180.         Several IBM mainframe users have reported problems reading
  181. unformatted data sets with LIMDEP version 6.0.  The program crashes with
  182. an 'END OF RECORD ON UNIT 10' error.
  183.         A LIMDEP user has suggested a patch which deals specifically with
  184. this problem.  The offending line, which should be but apparently is not
  185. protected by its ERR=992 specification, is in subroutine LOAD, and follows
  186. statement 242,
  187.                 READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,255)
  188.  
  189. An approach for getting around the problem is
  190.  
  191.         1.  At the top of the subroutine, add the two lines
  192.  
  193.                 CHARACTER*255 IBMBUF
  194.                 EQUIVALENCE (LINE,IBMBUF)
  195.  
  196.         2.  Replace the aforementioned READ statement with
  197.  
  198.                 READ(IUD,2429,END=993,ERR=993)IBMBUF
  199.           2429  FORMAT(A255)
  200.  
  201. Users of nonIBM mainframe systems need not make this change.
  202.  
  203.                                 Sincerely yours,
  204.  
  205.                                 Bill Greene
  206.                                 EcoSoft
  207.