home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!darwin.sura.net!ukma!psuvax1!psuvm!auvm!UNCVM1.BITNET!WDAVIS
- Message-ID: <SAS-L%92072120431304@VTVM2.BITNET>
- Newsgroups: bit.listserv.sas-l
- Date: Tue, 21 Jul 1992 20:40:29 EDT
- Reply-To: Walter Davis <WDAVIS@UNCVM1.BITNET>
- Sender: "SAS(r) Discussion" <SAS-L@UGA.BITNET>
- From: Walter Davis <WDAVIS@UNCVM1.BITNET>
- Subject: LIMDEP on IBM
- Lines: 195
-
- hi SAS-l'ers
- this has nothing to do with SAS, but there are enough users
- of LIMDEP and IBM systems types on the list that I thought I
- would forward these notes, especially since they don't seem
- to be in wide circulation (I got them from STAT-L).
-
- There appears to be a problem running the new version of LIMDEP
- on IBM systems. The notes below explain the problem and,
- hopefully, provide some fixes.
-
- hope this helps,
-
- Walter Davis <WDAVIS@UNCVM1>
- Department of Sociology
- UNC - Chapel Hill
-
-
-
- ----------------------------
- 1st note here
- ----------------------------
-
-
- I was asked by the vendor of LIMDEP to send this out for the benefit
- of those who are having difficulty installing the new mainframe version.
-
- +----------------------------------------------------------------------+
- | Linda Atkinson, Statistician | BITNET: ATKINSON@ERS |
- | U.S. Department of Agriculture | Tel: (202) 219-0505 |
- | Economic Research Service | FAX: (202) 219-1292 |
- | Washington, D.C. | (ATTN: RM 240) |
- +----------------------------------------------------------------------+
-
- ----------------------------Original message----------------------------
- Linda: (Listen carefully and see if you can pick up my frustration.)
- The problem you are having with LIMDEP, as are several other
- IBM system users, is due to a quirk in IBM's Fortran. I won't call it
- a bug, but it is unique to IBM. The problem is this: I am trying to
- read your data as a string of characters, so that LIMDEP can interpret
- it and free you from having to provide a format -- i.e., an unformatted
- read. Since I do not know how many characters there are on a line, or
- even if there will be the same number of characters on each line, I
- try to read 255 characters. If the line contains less than 255 characters,
- here is what happens:
- IBM mainframes: Program crashes, as you saw
- All other types of mainframes, and all PCs: Program reads as
- many characters are as present, and fills remainder
- with blanks.
- I suppose I will have to program around this. If I am successful, I will
- let you know.
- Perhaps you could send the previous paragraph out on your network.
- (I do not access it.) In any event, it does not have to do with being
- unfamiliar with IBM systems. I know more about them than I wish to right
- now.
-
-
- ----------------------------
- 2d note here
- ----------------------------
-
-
- This is a second message I received from Dr. Greene about LIMDEP, with
- more detailed information on work-arounds for the mainframe version.
-
- +----------------------------------------------------------------------+
- | Linda Atkinson, Statistician | BITNET: ATKINSON@ERS |
- | U.S. Department of Agriculture | Tel: (202) 219-0505 |
- | Economic Research Service | FAX: (202) 219-1292 |
- | Washington, D.C. | (ATTN: RM 240) |
- +----------------------------------------------------------------------+
-
- ----------------------------Original message----------------------------
- Dear Linda: (Listen closely and see if you can pick up my frustration.)
-
- The problem you are having with LIMDEP is now very familiar to me,
- and is arising from two sources: (1) An incompatibility between IBM's Fortran
- and every other Fortran with which I am familiar, which, as you can
- imagine, is a lot and (2) A bug in the IBM fortran compiler which, as far
- as I know, has always been present, and shows no sign of being eradicated.
- For your programmer's benefit, the offending statement is
-
- READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,255)
-
- which follows statement number 241 in subroutine LOAD. This line is
- attempting to read a character string of indeterminate length, in
- individual bytes. Since I do not know how long the line is to be, I just
- read a long line. Here is what happens if the line has less than 255
- characters:
-
- IBM fortran (MVS, CMS, all of them): Program crashes, as you saw.
- All other fortrans: Unread characters are filled with blanks.
-
- Now, notice that the statement contains an ERR=992. This is designed to
- prevent programs which encounter data errors from crashing. It is not
- working. That is the bug. There is no ambiguity about it as far as I can
- see. The odd thing about this, once again, unique to IBM, is that this
- whole problem disappears a) if the 255 above is changed to an 80, whether
- or not the line read is actually 80 characters long or not and b) if
- the line really is 255 characters long, for obvious reasons.
-
- From your point of view, there are a couple of short term fixes
- you can use:
- (1) Use only formatted data sets, and include format statements
- in the READ statement.
- (2) The following block of code can replace its current
- counterpart in subroutine LOAD. This reverts back to the 80 character
- limit of version 5.1, but apparently IBM fortran will not choke on it.
-
- 240 IRD=ZERO
- 241 DO 242 J=ONE,80
- 242 LINE(J)=' '
- READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,80)
- 2421 FORMAT(255A1)
- IF(LINE(1).EQ.'.'.AND.LINE(2).EQ.' ')LINE(1)='*'
- DO 2473 J=ONE,79
- 2473 IF(J.GT.ONE.AND.LINE(J).EQ.'.'.AND.LINE(J-ONE).EQ.' '.AND.
- & LINE(J+ONE).EQ.' ')LINE(J)='*'
- DO 243 J=ONE,80
- IF(LINE(81-J).EQ.' '.OR.LINE(81-J).EQ.',')GO TO 243
- LINE(82-J)='$'
- GO TO 244
- 243 CONTINUE
- GO TO 241
- 244 IFR=ZERO
- DO 245 J=ONE,80
- IF(LINE(J).EQ.' ')LINE(J)=','
- 245 IF(LINE(J).NE.','.AND.IFR.EQ.ZERO)IFR=J
-
- Once again, it is a mystery to me why IBM has locked itself into this 80
- character format, but apparently, it is the bottleneck. Keep in mind,
- again, for unformatted data sets, you are limited to 80 character lines.
-
- It might be helpful if you could put this out on to the network,
- since I do not access it.
-
- Regards,
- Bill Greene
-
-
- ----------------------------
- 3rd note here
- ----------------------------
-
-
-
-
-
- +----------------------------------------------------------------------+
- | Linda Atkinson, Statistician | BITNET: ATKINSON@ERS |
- | U.S. Department of Agriculture | Tel: (202) 219-0505 |
- | Economic Research Service | FAX: (202) 219-1292 |
- | Washington, D.C. | (ATTN: RM 240) |
- +----------------------------------------------------------------------+
-
-
- ----------------------------Original message----------------------------
-
-
-
-
- Memo:
- To: Users of LIMDEP 6.0 on IBM Mainframe systems
- From: W. Greene, developer, LIMDEP
- Date: July 21, 1992
- Re: Problems reading unformatted data sets.
-
- Dear IBM User:
-
- Several IBM mainframe users have reported problems reading
- unformatted data sets with LIMDEP version 6.0. The program crashes with
- an 'END OF RECORD ON UNIT 10' error.
- A LIMDEP user has suggested a patch which deals specifically with
- this problem. The offending line, which should be but apparently is not
- protected by its ERR=992 specification, is in subroutine LOAD, and follows
- statement 242,
- READ(IUD,2421,END=993,ERR=992)(LINE(J),J=ONE,255)
-
- An approach for getting around the problem is
-
- 1. At the top of the subroutine, add the two lines
-
- CHARACTER*255 IBMBUF
- EQUIVALENCE (LINE,IBMBUF)
-
- 2. Replace the aforementioned READ statement with
-
- READ(IUD,2429,END=993,ERR=993)IBMBUF
- 2429 FORMAT(A255)
-
- Users of nonIBM mainframe systems need not make this change.
-
- Sincerely yours,
-
- Bill Greene
- EcoSoft
-