Re: Fortran Guru requested
From: Paddy O'Brien (paddy.o'brien@tg.nsw.gov.au)
Date: 04/01/03
- Next message: Joseph Huber: "Re: Fortran Guru requested"
- Previous message: Bruin, J.M. de: "RE: Fortran Guru requested"
- Maybe in reply to: Didier Morandi: "Re: Fortran Guru requested"
- Next in thread: Didier Morandi: "Re: Fortran Guru requested"
- Reply: Didier Morandi: "Re: Fortran Guru requested"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Paddy O'Brien <paddy.o'brien@tg.nsw.gov.au> Date: Tue, 01 Apr 2003 17:23:20 +1000
Ken Fairfield wrote:
[snips]
> Paddy (and John Santos) correctly question using DOUBLE PRECISION
> for the TIME variable. Use INTEGER*4 TIME(2) instead. The issue is the
> _potential_ for an HPARITH error for some bit patterns in those 64 bits.
>
Ken, (and Hi it's a long time since we had a conversation)
Your attributions are a little bit wrong. It was John Santos who
originally postulated the problem that you describe. In my reply to
him, I suggested that there should be no problem with TIME being
declared REAL*8 (though I entirely agree that the correct definition
should have been used).
My postulation was that TIME was not "touched" in the SLEEP routine and
should therefore maintain the same bit pattern between the calls to the
system routines..
> However, the address of %x30 looks to me like the TAG variable is
> being passed by address, that is %x30 is 48 decimal, which is "0" ASCII.
> I'd suspect the calling routine, SPECIAL_GRAPHIC in this case, is
> calling
> sleep with a Hollerith argument or a numeric variable that's been
> initialized
> with character data (non-standard, common place old usage). Find all
> the
> callers of SLEEP and make sure that the TAG argument is of type
> CHARACTER,
> or is specified as a character literal (e.g., CALL SLEEP('10:00') ).
>
Yes, this seems to be the real (pun) problem. But the call in
SPECIAL_GRAPHIC uses a descriptor, as it should. At least my knowledge
of VMS Fortran says that CALL SLEEP('10.00') is a descriptor.
Along with (IIRC) Carl Perkins, I cannot see a problem with Fortran
V7.5. on VMS 7.2
The release notes of the FORRTL do not address this, nor do the Fortran
release notes.
My only suggestion now is that Didier bundles up a replay of what caused
the problem and passes it to fortran@compaq.com (might be hp.com, but
they still receive my compiler internal errors) and giving them his
version of Fortran.
Regards, Paddy
***********************************************************************
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now
firstname.lastname@transgrid.com.au"
***********************************************************************
- Next message: Joseph Huber: "Re: Fortran Guru requested"
- Previous message: Bruin, J.M. de: "RE: Fortran Guru requested"
- Maybe in reply to: Didier Morandi: "Re: Fortran Guru requested"
- Next in thread: Didier Morandi: "Re: Fortran Guru requested"
- Reply: Didier Morandi: "Re: Fortran Guru requested"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|