home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / statl / 1188 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.7 KB  |  51 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Newsgroups: bit.listserv.stat-l
  3. Path: sparky!uunet!paladin.american.edu!auvm!uvvm!klassen
  4. References:  <CMM.0.90.2.711665776.wgreene@option.stern.nyu.edu>
  5. Message-ID: <92204.101520KLASSEN@UVVM>
  6. Date:         Wed, 22 Jul 1992 10:15:20 PDT
  7. Sender:       "STATISTICAL CONSULTING" <STAT-L@MCGILL1.BITNET>
  8. Comments:     Warning -- original Sender: tag was NETNEWS@UVVM.UVIC.CA
  9. From:         Melvin Klassen <KLASSEN@UVVM.BITNET>
  10. Subject:      Re: LIMDEP
  11. Lines: 38
  12.  
  13. Linda Atkinson <ATKINSON@ERS> writes:
  14. >This is a second message I received from Dr. Greene about LIMDEP, with
  15. >more detailed information on work-arounds for the mainframe version.
  16. >----------------------------Original message----------------------------
  17. >        The problem you are having with LIMDEP is now very familiar to me,
  18. >and is arising from two sources:  (1) An incompatibility between IBM's Fortran
  19. >and every other Fortran with which I am familiar, which, as you can
  20. >imagine, is a lot and (2) A bug in the IBM fortran compiler which, as far
  21. >as I know, has always been present, and shows no sign of being eradicated.
  22.                                          ?????????????????????????????????
  23. > ...
  24. >        IBM fortran (MVS, CMS, all of them): Program crashes, as you saw.
  25. >        All other fortrans:  Unread characters are filled with blanks.
  26. >Now, notice that the statement contains an ERR=992.  This is designed to
  27. >prevent programs which encounter data errors from crashing. It is not working.
  28. >That is the bug.  There is no ambiguity about it as far as I can see.
  29. >The odd thing about this, once again, unique to IBM, is that this
  30. >whole problem disappears a) if the 255 above is changed to an 80, whether
  31. >or not the line read is actually 80 characters long or not and b) if
  32. >the line really is 255 characters long, for obvious reasons.
  33. > ...
  34. >Once again, it is a mystery to me why IBM has locked itself into this 80
  35. >character format, but apparently, it is the bottleneck.  Keep in mind,
  36. >again, for unformatted data sets, you are limited to 80 character lines.
  37.  
  38. All these problems with FORTRAN and LIMDEP can easily be solved if the user
  39. of LIMDEP is using the current release of IBM's VS FORTRAN Program Product.
  40. In 1990, IBM fixed the problem in Release 3 of Version 2 of their product.
  41. Note that both Release 3 and Release 4 have now been obsoleted
  42. by Release 5 of their product.
  43.  
  44. The solution is just to specify the "CNVIOERR" run-time option
  45. (as documented on page 92 of "VS FORTRAN Version 2, Programming Guide
  46. for CMS and MVS, Release 5").  Then, FORTRAN error 212 (end-of-record)
  47. **will** be intercepted by the 'ERR=' option.
  48.  
  49. As an alternate solution, the user can turn to page 96,
  50. specify the "RECPAD" run-time option, and FORTRAN will perform blank-padding.
  51.