Text processing examples with Fortran requested

[DTL]

Hi,

I'm urgently needing some examples of Fortran code to do text
processing, mainly reading a file, doing some strings manipulation
then writing records into a new file.
I trashed all my DEC stuff five years ago. Too bad...

Thanks.

[Richard B. Gilbert]

You may not find much! Fortran's strength was numerical computation.
It would be used for text processing only if nothing else were available.

Is there some reason not to use a text editor?

[Arne Vajhøj]

Silly example:

PROGRAM FCOPY
INTEGER*4 IX
CHARACTER*80 LINE
OPEN(UNIT=1,FILE='ind.txt',STATUS='OLD')
OPEN(UNIT=2,FILE='ud.txt',STATUS='NEW')
100 READ(UNIT=1,FMT=1000,END=300) LINE
IX=80
200 IF(LINE(IX:IX).EQ.' ') THEN
IX=IX-1
GOTO 200
ENDIF
WRITE(UNIT=2,FMT=1100) '>>>>' // LINE(1:IX)
GOTO 100
300 CLOSE(UNIT=2)
CLOSE(UNIT=1)
1000 FORMAT(A)
1100 FORMAT(A)
END

Arne

[Arne Vajhøj]

Richard B. Gilbert wrote:

> DTL wrote:
>> I'm urgently needing some examples of Fortran code to do text
>> processing, mainly reading a file, doing some strings manipulation
>> then writing records into a new file.
>> I trashed all my DEC stuff five years ago. Too bad...
>

> You may not find much! Fortran's strength was numerical computation. It
> would be used for text processing only if nothing else were available.

It has been seen before.

And besides Fortran 77 is not that bad. CHARACTER is fine. Fortran 66
would be painful.

Arne

[Hein RMS van den Heuvel]

Try PYTHON, PERL or AWK or DCL or TPU or BASIC if you have to.
Fortran would be my last resort, right after Cobol.

Do yourself a favor and spend 2 or 3 hours with Perl from
http://www.activestate.com/downloads/ on windows, or on OpenVMS if you
like (EISNER, DEATHROW, TESTDRIVE... )
It will put you in a better, forward moving, position. Garantueed.

Cheers,
Hein.

[Arne Vajhøj]

Hein RMS van den Heuvel wrote:
> On Nov 15, 9:09 am, DTL <didier.mora...@gmail.com> wrote:
>> I'm urgently needing some examples of Fortran code to do text
>> processing, mainly reading a file, doing some strings manipulation
>> then writing records into a new file.
>> I trashed all my DEC stuff five years ago. Too bad...
>

> Try PYTHON, PERL or AWK or DCL or TPU or BASIC if you have to.
> Fortran would be my last resort, right after Cobol.

Python and Basic are nice. Perl and AWK are a bit cryptic in syntax.
DCL and TPU are great but IMHO Not optimal for this particular task.

> Do yourself a favor and spend 2 or 3 hours with Perl from
> http://www.activestate.com/downloads/ on windows, or on OpenVMS if you
> like (EISNER, DEATHROW, TESTDRIVE... )

I am sure that the Perl solution would be less lines than the
Fortran solution, but you could also argue that Perl is less
readable than Fortran (and that says a lot).

> It will put you in a better, forward moving, position. Garantueed.

Not job wise. Perl is last decade.

Arne

[Tom Linden]

Why fortran? Use PL/I or VAXSCAN

--
PL/I for OpenVMS
www.kednos.com

[Richard B. Gilbert]

Without knowing the details, I can't help wondering if perhaps this is a
job for awk/nawk/gawk.

[Richard B. Gilbert]

A lot depends on the tools available. Nobody is going to spring for
PL/1 to solve a problem that can be solved using a tool already at hand.
Fortran would not be my choice of language for word processing but, if
that's all you have. . . .

Without more details of the problem, I see no reason not to use EDT or TPU.

[Bob Eager]

On Sun, 15 Nov 2009 12:07:30 -0500, Richard B. Gilbert wrote:

I would personally use REXX. But then it always depends on what you
actually know, as well as what is available...!

--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Richard B. Gilbert]

If you don't know a tool, you can probably learn it. If you don't HAVE
the tool, somebody may have to cough up some cash!

[Jan-Erik Söderholm]

Or DCL. Definitely available on all (VMS) systems.

[glen herrmannsfeldt]

Richard B. Gilbert <rgilb...@comcast.net> wrote:

>> I'm urgently needing some examples of Fortran code to do text
>> processing, mainly reading a file, doing some strings manipulation
>> then writing records into a new file.
>> I trashed all my DEC stuff five years ago. Too bad...

> You may not find much! Fortran's strength was numerical computation.
> It would be used for text processing only if nothing else were available.

The MORTRAN preprocessors for Fortran 66 were written in
standard Fortran 66. The processors are relatively simple, with
the complications being in the macros.

-- glen

[Tom Linden]

DCL is a bit primitive, here is a better solution
http://www.kednos.com/kednos/Resources/Rexx#NetRexx

[Jan-Erik Söderholm]

Tom Linden wrote:
> On Sun, 15 Nov 2009 09:54:54 -0800, Jan-Erik Sï¿œderholm
> <jan-erik....@telia.com> wrote:
>
>> Richard B. Gilbert wrote:
>>> Tom Linden wrote:
>>>> On Sun, 15 Nov 2009 06:09:41 -0800, DTL <didier....@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm urgently needing some examples of Fortran code to do text
>>>>> processing, mainly reading a file, doing some strings manipulation
>>>>> then writing records into a new file.
>>>>> I trashed all my DEC stuff five years ago. Too bad...
>>>>>
>>>>> Thanks.
>>>>
>>>> Why fortran? Use PL/I or VAXSCAN
>>>>
>>> A lot depends on the tools available. Nobody is going to spring for
>>> PL/1 to solve a problem that can be solved using a tool already at hand.
>>> Fortran would not be my choice of language for word processing but,
>>> if that's all you have. . . .
>>> Without more details of the problem, I see no reason not to use EDT
>>> or TPU.
>>
>> Or DCL. Definitely available on all (VMS) systems.
>
> DCL is a bit primitive, here is a better solution
> http://www.kednos.com/kednos/Resources/Rexx#NetRexx
>

How do you know that DCL is "too primitive" for the actual need ?

The only thing I know is that the need was to :

"...mainly reading a file, doing some strings manipulation

then writing records into a new file."

If this is a one-off kind of thing, hacking together a few lines
of DCL is what I would do...

Rexx would probably be the last tool I would use, b.t.w.

[seasoned_geek]

Get a copy of "The Minimum You Need to Know to Be an OpenVMS
Application Developer" and look at the source code for
FTN_ZILL_IMPORT_SUB.F77. It should show you everything you need.

[Michael Kraemer]

Arne Vajh�j schrieb:

> And besides Fortran 77 is not that bad. CHARACTER is fine. Fortran 66
> would be painful.

F77 can be almost as painful for text stuff because
IIRC the standard does not provide for dynamically allocated
character strings.

[glen herrmannsfeldt]

Michael Kraemer <M.Kr...@gsi.de> wrote:
> Arne Vajh?j schrieb:

F77 doesn't provide for anything dynamically allocated. The form
of expressions allowed for the CHARACTER data type is carefully
designed to avoid the requirement of temporaries of unknown (at
compile time) size.

Even so, a lot was done in Fortran 66 because that was what
was available. Storing one character per INTEGER array element
was inefficient but usually worked.

-- glen

[Richard B. Gilbert]

It doesn't dynamically allocate anything at all. At least it didn't the
last time I used Fortran. Dynamic memory allocation is a "C" thing.
IMHO it's a useless hangover on a virtual memory system. On machines
with small address spaces it can be a life saver. These days PCs
support 4GB of RAM and 12 bit or 16 bit machines are mostly antiques.

"Pocket" computers may still need to worry about it.

[Michael Moroney]

Speaking of text manipulation, I'll ask this, though I know it's a real
shot in the dark.

Does anyone know of any tools to manipulate VAX Macro-32 code? By
"manipulate" I mean to find instructions with specific addressing modes
or do things like convert all word instructions whose destination is a
register to longword equivalent and find all MOVAx instructions whose base
is R7, all without being fooled by commented out lines, of course.

I know I'll have to write individual tools, and will have to learn
one of those text manipulation "languages", but I figure I'd ask anyway.

I have to deal with thousands of lines of the most gawdawful macro-32
code ever created.

[Arne Vajhøj]

I have never heard of such a tool.

If it is sufficient many lines of code, then you could write a
parser. It should not that hard to do with flex & bison.

Otherwise manual inspection may be faster in the end.

Arne

[Arne Vajhøj]

Jan-Erik Sï¿œderholm wrote:

> Tom Linden wrote:
>> DCL is a bit primitive, here is a better solution
>> http://www.kednos.com/kednos/Resources/Rexx#NetRexx
>
> How do you know that DCL is "too primitive" for the actual need ?
>
> The only thing I know is that the need was to :
>
> "...mainly reading a file, doing some strings manipulation
> then writing records into a new file."
>
> If this is a one-off kind of thing, hacking together a few lines
> of DCL is what I would do...

DCL is available.

DCL is something everybody knows.

(we are assuming on VMS !)

But the DCL lexicals are not the best string library available.

Arne

[Arne Vajhøj]

Lack of dynamic allocation is not necessarily a problem
for this type of problem.

I don't even think it is likely that it would be used
even if it were available.

Arne

[Arne Vajhøj]

glen herrmannsfeldt wrote:
> Even so, a lot was done in Fortran 66 because that was what
> was available. Storing one character per INTEGER array element
> was inefficient but usually worked.

One - not two or four??

Arne

[Richard B. Gilbert]

Grep or awk,nawk,gawk should be able to do that sort of job if you can
compose a regular expression that will match what you are looking for.
There are VMS versions of both grep and gawk.

[Richard B. Gilbert]

If you use two or more, you are faced with the problem of "packing" and
"unpacking" the data. I don't believe that either Fortran II or Fortran
66 supported a character data type. "Hollerith literals" were the
best you could do and I don't think they could be used outside of FORMAT
statements. My copy of "Guide to Fortran Programming" has vanished in
the mists of time along with the later edition, "A Guide to Fortran IV"
programming. Fortran IV did support a character data type.

[glen herrmannsfeldt]

If you want to move around individual characters, as most text
processing does, then one. If you just need to read them in
and write them back out, then two or four (or more).
(CDC stored 10 six bit characters in a 60 bit word.)

-- glen

[glen herrmannsfeldt]

Richard B. Gilbert <rgilb...@comcast.net> wrote:

(snip)

> If you use two or more, you are faced with the problem of "packing" and
> "unpacking" the data. I don't believe that either Fortran II or Fortran
> 66 supported a character data type. "Hollerith literals" were the
> best you could do and I don't think they could be used outside of FORMAT
> statements. My copy of "Guide to Fortran Programming" has vanished in
> the mists of time along with the later edition, "A Guide to Fortran IV"
> programming. Fortran IV did support a character data type.

Also in DATA statements and actual arguments to subroutine and
function calls.

The MORTRAN processor reads in the first line of the macro
file containing all the characters to be used in input
to avoid the problems with initializing them in the program.
That also allows one to change the meaning of the special characters
as needed.

-- glen

[Michael Kraemer]

Richard B. Gilbert schrieb:

> It doesn't dynamically allocate anything at all. At least it didn't the
> last time I used Fortran.

I know, but in text processing it may bite you first.

> Dynamic memory allocation is a "C" thing.

It's not a C only thing.

> IMHO it's a useless hangover on a virtual memory system.

Huh? You need memory allocation just everywhere.
Just think of avoiding buffer overflows by always
providing buffers of the right length.

> On machines
> with small address spaces it can be a life saver. These days PCs
> support 4GB of RAM and 12 bit or 16 bit machines are mostly antiques.

This only shifts the problem from 640kB to 4GB,
one never has enough RAM.

[DTL]

Whaooo what a success with my poor simple question... :-)

I'll try to answer all of yours:

why not DCL : I did, and it works fine, but the file is 200 000 lines
long
why Fortran : because I know it, well I knew it a few years ago
why not learn a new tool : no time
"there is something better than DCL" : huh ?
Fortran does not allow dynamic allocation : I do not need it

Bye for now. I have all I needed.
Thanks for your time.

[DTL]

FYI this is what I had to perform:
(some lines commented out to disable warnings processing after debug
phase passed)

program read_file
implicit integer*4 (a-z)
character line_1*172, line_2*172, line_3*80
character filename_1*20, filename_2*20
character addr_1*30, addr_2*30, addr_3*30, addr_4*30
character bv*4, nbv*4,canton*2
character delimiter*1

delimiter='!'
filename_1 = ' '
filename_2 = 'result.dat'

type *,'Enter file name '
read (*,11) filename_1
11 format (A)

open (2, file=filename_1,
& status='old',
& access='sequential',
& recordtype='variable',
& form='formatted')

open (3, file=filename_2,
& status='new',
& access='sequential',
& recordtype='variable',
& form='formatted')

20 read (2,21,end=99) line_1
21 format(A)
status=str$element(addr_1,8,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))
status=str$trim(addr_1,addr_1,j)
if (.not. status) call lib$stop(%val(status))

status=str$element(addr_2,9,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))
status=str$trim(addr_2,addr_2,k)
if (.not. status) call lib$stop(%val(status))

status=str$element(addr_3,10,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))
status=str$trim(addr_3,addr_3,l)
if (.not. status) call lib$stop(%val(status))

status=str$element(addr_4,11,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))
status=str$trim(addr_4,addr_4,m)
if (.not. status) call lib$stop(%val(status))

status=str$element(bv,12,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))

status=str$element(nbv,13,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))

status=str$element(canton,14,delimiter,line_1)
! if (.not. status) call lib$stop(%val(status))

line_3 = addr_1(1:j)//' '//addr_2(1:k)//' '//addr_3(1:l)//'
'//
& addr_4(1:m)//'!'//bv//'!'//nbv//'!'//canton

write (3,21) line_3
line_3 = ' '
goto 20

99 close(2)
close(3)
end

[VAXman-]

In article <hdqavr$n8g$1...@pcls4.std.com>, mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>Speaking of text manipulation, I'll ask this, though I know it's a real
>shot in the dark.
>
>Does anyone know of any tools to manipulate VAX Macro-32 code? By
>"manipulate" I mean to find instructions with specific addressing modes
>or do things like convert all word instructions whose destination is a
>register to longword equivalent and find all MOVAx instructions whose base
>is R7, all without being fooled by commented out lines, of course.

It might be easier to search the VAX Macro machine listing. Define the
opcodes of interest and masks for the addressing modes you're interested
in.

>I know I'll have to write individual tools, and will have to learn
>one of those text manipulation "languages", but I figure I'd ask anyway.
>
>I have to deal with thousands of lines of the most gawdawful macro-32
>code ever created.

Doubtful. I'll bet I've seen worse. ;)

If you really need to change a MOVW src,dst to MOVL src,dst, writing a
macro to do so might be your better bet.

.MACRO .REDEFINE_MOVW
.MACRO MOVW,src,dst
.MDELETE MOVW
.NTYPE ...ADDR_MODE...,dst
.IF EQ <...ADDR_MODE...@-4&^XF>-5 ; register mode?
.IF_TRUE
MOVL src,dst
.IF_FALSE
MOVW src,dst
.ENDC
.REDEFINE_MOVW
.ENDM MOVW
.ENDM .REDEFINE_MOVW

.REDEFINE_MOVW

:
:

I believe that that's all right. If not, blame it on the fact that I'm not
well caffeinated yet at this hour of the day.

I've done the above quite often for branches. For example, for a BLBx where
the target address is well beyond the byte displacement. The macro figures
out if there's a need to use a just BLBx or a BLBx and a helper BRW or JMP.
It unclutters the code quite a bit. I often put a .PRINT in the conditional
part of the macro to show this in the .LISting.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

http://www.quirkfactory.com/popart/asskey/eqn2.png

"Well my son, life is like a beanstalk, isn't it?"

[Richard B. Gilbert]

Michael Kraemer wrote:
> Richard B. Gilbert schrieb:
>
>> It doesn't dynamically allocate anything at all. At least it didn't
>> the last time I used Fortran.
>
> I know, but in text processing it may bite you first.
>
>> Dynamic memory allocation is a "C" thing.
>
> It's not a C only thing.
>
>> IMHO it's a useless hangover on a virtual memory system.
>
> Huh? You need memory allocation just everywhere.
> Just think of avoiding buffer overflows by always
> providing buffers of the right length.
>

In Fortran you learned to live without dynamic memory allocation! It
may be available in Fortran *now* but back in 1969--1994 memory
allocation in Fortran was static. For most of that period, your input
was via 80 column punched cards.

I got my first VAX in 1984 and after that I didn't use punched cards
that much. 1994 was about the time I last did any serious programming
in Fortran; my employers didn't use it so it wasn't available to me.

[Bob Koehler]

In article <bd4ab99b-395a-4791...@l13g2000yqb.googlegroups.com>, DTL <didier....@gmail.com> writes:
> Hi,
>
> I'm urgently needing some examples of Fortran code to do text

> processing, mainly reading a file, doing some strings manipulation

> then writing records into a new file.

> I trashed all my DEC stuff five years ago. Too bad...

You know, I haven't opened a VMS Fortran manual in a lot of years,
but they used to be full of examples like this.

And they should be online. http://h71000.www7.hp.com/doc/index.html

[Bob Koehler]

In article <guqdnThZW8crkp3W...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>
> You may not find much! Fortran's strength was numerical computation.
> It would be used for text processing only if nothing else were available.

Ever since Fortran-77 introduced CHARACTER data type and operators,
we did tons of string manipulation quite readily in Fortran.

It dosn't have all the power of the C RTL, or string processing
languages like SNPOBOL, but at east you don't have to call
three functions just to contatenate two substrings.

[Bob Koehler]

In article <hdpfl3$c84$1...@naig.caltech.edu>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> The MORTRAN preprocessors for Fortran 66 were written in
> standard Fortran 66. The processors are relatively simple, with
> the complications being in the macros.

So was the RATFOR bootstrap, but only because the RATFOR preprocessor
was run over the RATFOR source and the result shipped with.

[Bob Koehler]

In article <hdq07m$q1n$00$1...@news.t-online.com>, Michael Kraemer <M.Kr...@gsi.de> writes:
>
> F77 can be almost as painful for text stuff because
> IIRC the standard does not provide for dynamically allocated
> character strings.

True, that's in a later standard (99?). Never stopped us, as
Fortran programmers were were used to the idea that your buffers
always had to be at least as large as the largest data sample.

But you only need 95 to start using dynamica allocation. And
all us VMS programmers started calling STR$ library routines
instead. The OP didn't sya he needed portability.

[Bob Koehler]

In article <hdq5rb$gj6$3...@naig.caltech.edu>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> Even so, a lot was done in Fortran 66 because that was what
> was available. Storing one character per INTEGER array element
> was inefficient but usually worked.

Porting code between PDP-10 (5 7-bit characters per INTEGER) and
byte oriented systems (4 8-bit characters per INTEGER) was a
lesson in Fortran-IV portability issues.

[Bob Koehler]

In article <FsydnWrNJf0XOp3W...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>
> It doesn't dynamically allocate anything at all. At least it didn't the
> last time I used Fortran.

Then you're a bit out of date. Fortran-95 can handle this. Hm, 14
years ago?

[Bob Koehler]

In article <hdqavr$n8g$1...@pcls4.std.com>, mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>

> Does anyone know of any tools to manipulate VAX Macro-32 code? By
> "manipulate" I mean to find instructions with specific addressing modes
> or do things like convert all word instructions whose destination is a
> register to longword equivalent and find all MOVAx instructions whose base
> is R7, all without being fooled by commented out lines, of course.

If I were faced with this, I'd brush up on TPU. A routine for each
of these should do, maybe acting as a comment filter sitting on top
of generic search and replace routines from EVE.

[Bob Koehler]

In article <iOudnQ2-U6rSIp3W...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>
> If you use two or more, you are faced with the problem of "packing" and
> "unpacking" the data. I don't believe that either Fortran II or Fortran
> 66 supported a character data type.

Fortran-IV (aka -66) has standard character constants in single quotes.
How they pack into other data types is machine dependent. I know of
a large package developed on IBM mainframes Fortran-IV in which strings
are routinely stuffed into arrays of REAL*8. We ported it to a VAX
under VMS 2.x and these were not a problem.

We've got a ton of code developed on PDP-11 with two characters
per integer, that's been running for a couple of decades on VAX
with the simple expedient of making sure they are all explicity
declared INTEGER*2.

[Bob Koehler]

In article <lvmdnQ1F54yJxZzW...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>
> In Fortran you learned to live without dynamic memory allocation! It
> may be available in Fortran *now* but back in 1969--1994 memory
> allocation in Fortran was static. For most of that period, your input
> was via 80 column punched cards.

And back in the '60s you were told to use no more than 600K, so you
overlaid your program as heavily as you could.

Virtual memory was a thing of the future.

[Richard B. Gilbert]

I left Princeton in May 1994. My access to Fortran since then has been
rather limited! Most of my work since then has been done in C or DCL;
that's what my employers had.

[seasoned_geek]

On Nov 15, 7:47 pm, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:

copy the source to a KUbuntu desktop then install Kate, SciTE, and
jEdit. Read through the on-line doc for regular expression search and
replace each has. One of the three will meet your needs. If you are
really good with regular expressions you might want to install Tea and
use it to edit.

[Rob Brooks]

mor...@world.std.spaamtrap.com (Michael Moroney) writes:

> I have to deal with thousands of lines of the most gawdawful macro-32
> code ever created.

yeah, well, you spent time in SHDRIVER, so you should be well-suited
to the task of dealing with convoluted MACRO-32 :-)

--

Rob Brooks MSL -- Marlborough, MA brooks!cuebid.usa.hp.com

[Bill Gunshannon]

In article <UyLTRt...@eisner.encompasserve.org>,

Maybe, but he did say he wanted Fortran examples and then he posted
a program that was anything but Fortran. Every OS I ever worked with
had non-Fortran, but callable by Fortran, routines to handle things
like characters and strings but as soon as oyu add any of this, it
ceases to be Fortran.

As for the standards beyond Fyortran-77, did nayone ever make
use of them or the new features they brought to the table? I
have seen recent job postings for Fortran positions and they
all specified Fotran-IV or Fortran-77.

It should probably also be noted that the best of these jobs
went unanswered and were later replaced by job announcments
from the same players looking for people short-term to re-write
the Fortran programs. And these jobs included one from a very
large Government Contractor with an opening in GA, just above
the FL border. I leave it to the reader to determine which
contractor at which installation and what that Fortran code
might have been. :-) Yes, I did give it some serious thought
but while I really enjoyed my tenure with that particular employer
in the past, working for them again at this stage of my career
just isn't in my best interests.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[glen herrmannsfeldt]

Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
> In article <iOudnQ2-U6rSIp3W...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:

>> If you use two or more, you are faced with the problem of "packing" and
>> "unpacking" the data. I don't believe that either Fortran II or Fortran
>> 66 supported a character data type.

> Fortran-IV (aka -66) has standard character constants in single quotes.
> How they pack into other data types is machine dependent. I know of
> a large package developed on IBM mainframes Fortran-IV in which strings
> are routinely stuffed into arrays of REAL*8. We ported it to a VAX
> under VMS 2.x and these were not a problem.

Fortran IV had constants in single quotes, Fortran 66 only has the
Hollerith (1Hx) form of constants. In both cases they are valid in
the same places, but one is easier to use.

If you want to move around and compare individual characters,
then it is much easier with one character per array element,
and the only way within the Fortran 66 standard. Fortran IV has
datatypes of other widths. IBM has LOGICAL*1, I believe DEC had
INTEGER*1 or some other one byte type. In that case, one can copy
a larger variable to an EQUIVALENCEd variable, move around characters,
and copy back. Much more work and non-standard.

> We've got a ton of code developed on PDP-11 with two characters
> per integer, that's been running for a couple of decades on VAX
> with the simple expedient of making sure they are all explicity
> declared INTEGER*2.

Within the Fortran 66 standard, strictly you can't even copy
(such as with an assignment statement) a variable with a Hollerith
value and be sure that the character is copied. INTEGER variables
can be wider than the value stored in them. (36 bits to hold a
16 bit signed integer on the 704 through 7090.) Also, with REAL
variables some processors will normalize on assignment. (S/360,
S/370 don't, though.) Fortran 66 doesn't guarantee the ability
to compare two variables, even containg only one character each,
but text processing programs rely on that small extension
to the standard.

-- glen

[glen herrmannsfeldt]

Richard B. Gilbert <rgilb...@comcast.net> wrote:
(snip)

> In Fortran you learned to live without dynamic memory allocation! It
> may be available in Fortran *now* but back in 1969--1994 memory
> allocation in Fortran was static. For most of that period, your input
> was via 80 column punched cards.

It was added in Fortran 90. I would not be surprised if compilers
supporting it didn't exist by 1994. Compilers supporting all the
features of Fortran 2003 are still not available.

> I got my first VAX in 1984 and after that I didn't use punched cards
> that much. 1994 was about the time I last did any serious programming
> in Fortran; my employers didn't use it so it wasn't available to me.

I haven't looked at the VMS Fortran compilers lately. Any support
for Fortran 2003? Fortran 90 or 95?

-- glen

[Ken Fairfield]

On Nov 16, 8:09 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <UyLTRtE1L...@eisner.encompasserve.org>,
>         koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:

>
> > In article <hdq07m$q1n$0...@news.t-online.com>, Michael Kraemer <M.Krae...@gsi.de> writes:
>
> >> F77 can be almost as painful for text stuff because
> >> IIRC the standard does not provide for dynamically allocated
> >> character strings.
>
> >    True, that's in a later standard (99?).  Never stopped us, as
> >    Fortran programmers were were used to the idea that your buffers
> >    always had to be at least as large as the largest data sample.
>
> >    But you only need 95 to start using dynamica allocation.  And
> >    all us VMS programmers started calling STR$ library routines
> >    instead.  The OP didn't sya he needed portability.
>
> Maybe, but he did say he wanted Fortran examples and then he posted
> a program that was anything but Fortran.  Every OS I ever worked with
> had non-Fortran, but callable by Fortran, routines to handle things
> like characters and strings but as soon as oyu add any of this, it
> ceases to be Fortran.
>
> As for the standards beyond Fyortran-77, did nayone ever make
> use of them or the new features they brought to the table?  I
> have seen recent job postings for Fortran positions and they
> all specified Fotran-IV or Fortran-77.

I hate to jump in here (really, I do! :-), but the current
Fortran standard is Fortran 2003, and the most commonly
available compilers are Fortran 95 compliant (that would be
the various versions available on Windows, g95 and gfortran
on linux and Windows, as well as IBM's and Cray's on
their platforms, etc. The Alpha & Integrity VMS compiler
is also Fortran 95 compliant.

Except for Glen, who loves the history of Fortran (and
various other languages and computer-related things),
I really don't understand why people here are so locked
into discussing a 32-year-old version of a language
which has a widely available 13-year-old(!) version,
is under continuing development, and has a new
version (Fortran 2008) in the midst of the public
comment period.

Are we VMS folks really the old dinosaurs that
others label us as?

BTW, F95 is widely used in the government
weather forecasting "business" in the US
and in Europe, and likely elsewhere. (Just one
application that pops to mind...there are others
that are similarly compute intensive that are still
mainly Fortran...)

And yes, I have coded in Fortran 95. Although
sad to say, about the time I started exploring it,
my job position changed, which left me less
and less "interesting" prgramming to do (shucks,
it's mostly DCL these days...soon to be shell
scripting... :-( ).

-Ken

[Michael Moroney]

bro...@cuebid.usa.hp.nospam (Rob Brooks) writes:

>mor...@world.std.spaamtrap.com (Michael Moroney) writes:

>> I have to deal with thousands of lines of the most gawdawful macro-32
>> code ever created.

>yeah, well, you spent time in SHDRIVER, so you should be well-suited
>to the task of dealing with convoluted MACRO-32 :-)

While SHDRIVER was certainly convoluted, it's _nothing_ compared to the
hideousness of what I'm dealing with now. Seriously.

[John Wallace]

On Nov 16, 4:09 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <UyLTRtE1L...@eisner.encompasserve.org>,
>         koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>

> billg...@cs.scranton.edu |  and a sheep voting on what's for dinner.

> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>  

Fortran 90 seemed to be quite popular in parts of the HPC world when I
used to get vaguely involved. That was in the late 90s. No real idea
what the current state of play is, although I suspect these days both
HPC hardware and software may have taken different tactics than back
then, at least for folks who don't have masses of legacy Fortran to
support and who can take advantage of commodity hardware and cheap/
cheerful software.

[Ken Fairfield]

On Nov 16, 10:35 am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
[...]

> Fortran 90 seemed to be quite popular in parts of the HPC world when I
> used to get vaguely involved. That was in the late 90s. No real idea
> what the current state of play is, although I suspect these days both
> HPC hardware and software may have taken different tactics than back
> then, at least for folks who don't have masses of legacy Fortran to
> support and who can take advantage of commodity hardware and cheap/
> cheerful software.

Apparently, from the discussions I've read, parallel processing
of various flavors is a big driver. In particular F2008 implements
something called "co-arrays" which is specifically targeted at
parallel processing.

-Ken

[John Reagan]

"Michael Moroney" <mor...@world.std.spaamtrap.com> wrote in message
news:hds5qo$heq$1...@pcls6.std.com...

Then I'm very afraid for you!

During the port to Itanium, we instrumented the IMACRO compiler to print out
various internal statistics in the .LIS file (near the command qualifier
summary). One of them was the total number of flow blocks found by the
compiler's flow analyzer. This, along with the number of entry/exit points;
routines jumping into each other; etc. was used to compute a "complexity"
factor. SHDRIVER blew everybody else out of the water. By far the most
complex piece of Macro-32 code in the entire system from a compiler analysis
point of view.

Other Macro-32 code like RMS and DCL is complex with having all sorts of
global data in registers which mutates slightly as the code branches
into/outof various routines, but the compiler in general doesn't care about
those (other than nasty code to deal with NaTs that might have leaked into
the Macro-32 code).

John

[Michael Moroney]

"John Reagan" <johnr...@earthlink.net> writes:

>"Michael Moroney" <mor...@world.std.spaamtrap.com> wrote in message
>news:hds5qo$heq$1...@pcls6.std.com...
>> bro...@cuebid.usa.hp.nospam (Rob Brooks) writes:
>>
>>>mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>>
>>>> I have to deal with thousands of lines of the most gawdawful macro-32
>>>> code ever created.
>>
>>>yeah, well, you spent time in SHDRIVER, so you should be well-suited
>>>to the task of dealing with convoluted MACRO-32 :-)
>>
>> While SHDRIVER was certainly convoluted, it's _nothing_ compared to the
>> hideousness of what I'm dealing with now. Seriously.

>Then I'm very afraid for you!

>During the port to Itanium, we instrumented the IMACRO compiler to print out
>various internal statistics in the .LIS file (near the command qualifier
>summary). One of them was the total number of flow blocks found by the
>compiler's flow analyzer. This, along with the number of entry/exit points;
>routines jumping into each other; etc. was used to compute a "complexity"
>factor. SHDRIVER blew everybody else out of the water. By far the most
>complex piece of Macro-32 code in the entire system from a compiler analysis
>point of view.

You remember the code I had a couple of years ago at VMS Engineering's
Porting to Integrity seminar? The code where everyone said "Good luck
with that!" and then hid under their desks? The code that found Macro-32
compiler bugs? *THAT* code. It's not awful due to the number of
code paths (although it *is* plenty complex), it's just such an awful
design. (evolution is a more accurate description).

[VAXman-]

Well, if you just want to find the cases you described in an earlier port,
just use my macro redefining the instruction of choice to .PRINT out where
you need to focus your attention.

[John Reagan]

"Michael Moroney" <mor...@world.std.spaamtrap.com> wrote in message

news:hdsb7t$k62$1...@pcls4.std.com...

Oh yeah. I remember now. I just tasted vomit in my mouth.

That code wasn't complex but just assumed its exactly code location in
memory (IIRC).

John

[Michael Moroney]

VAXman- @SendSpamHere.ORG writes:

>>I have to deal with thousands of lines of the most gawdawful macro-32
>>code ever created.

>Doubtful. I'll bet I've seen worse. ;)

Hoo boy. Don't try to out-awful this code, your ass will be kicked from
here to China. Think of every "nasty" code trick you can think of that
you can do in Macro-32, I'm sure every one is in there somewhere. Plus
a few that nobody else ever thought of.

It took 3 skilled macro coders almost a year just to get the VAX code to
run on an Itanic and be stable enough to replace the VAX, and we feel
lucky that we were able to do so. The Itanic compiler does *not* like
most of the Macro "tricks" used.

I thought about writing a blog documenting all the trials and tribulations
we encountered, but never got around to doing so. I may still do so
(retroactively) since I did make notes.

>If you really need to change a MOVW src,dst to MOVL src,dst, writing a
>macro to do so might be your better bet.

We already have several (bad) redefined instructions. I would sort of
like such a tool that, perhaps, could run inside an editor, find and make
a single change but pause so that I could examine the code and surrounding
code to see that it is correct and make additional changes before going to
the next one, rather than yet another layer of macros. We've already done
a mass change where essentially the same change was made to thousands of
lines, and a second "round" is coming up.

(oh how I wish we could simply start over in another language. Pointy-
haired managers dictate otherwise)

[Michael Kraemer]

In article <hdq5rb$gj6$3...@naig.caltech.edu>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

> Michael Kraemer <M.Kr...@gsi.de> wrote:
> > Arne Vajh?j schrieb:
>
> >> And besides Fortran 77 is not that bad. CHARACTER is fine. Fortran 66
> >> would be painful.

>
> > F77 can be almost as painful for text stuff because
> > IIRC the standard does not provide for dynamically allocated
> > character strings.
>

> F77 doesn't provide for anything dynamically allocated. The form
> of expressions allowed for the CHARACTER data type is carefully
> designed to avoid the requirement of temporaries of unknown (at
> compile time) size.

Not quite. Constructs like

SUBROUTINE xxx( cc )
CHARACTER cc*(*)

print *, '...' // cc

caused subtle differences in implementation to show up (in 1991/92 or so).
Strictly speaking this would require dynamically allocated
temporaries because the length of the print argument is not
known at compile time.
The VAX compiler accepted the statement and pushed the temporary
on the stack.
The IBM compilers (MVS and AIX) issued a warning but used a
a temporary of fixed length, to be specified at compile time
(usually 32K, more than enough).
The Ultrix compiler rejected the "print", and forced a separate
user generated temporary.

[Michael Kraemer]

In article <4b00b9f9$0$276$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
> Michael Kraemer wrote:
> > Arne Vajh�j schrieb:

> >> And besides Fortran 77 is not that bad. CHARACTER is fine. Fortran 66
> >> would be painful.
> >
> > F77 can be almost as painful for text stuff because
> > IIRC the standard does not provide for dynamically allocated
> > character strings.
>

> Lack of dynamic allocation is not necessarily a problem
> for this type of problem.
>
> I don't even think it is likely that it would be used
> even if it were available.
>

If you have to concatenate substrings of lengths unknown at
compile time, the only clean solution is dynamic memory.
I think this is a very common problem in text processing.

[VAXman-]

Well, see my last post. If you want, replace .PRINT with .ERROR. That
will give you a "pause" so you can to examine the code. :)

If I can intercept Itanium instruction streams and revector control,
I don't see what could be all that outlandish in your Macro that's so
difficult to port.

>(oh how I wish we could simply start over in another language. Pointy-
>haired managers dictate otherwise)

What? Like C? Try writing a parser to find all the zany things people
do with that hieroglyphic and you'll be pining for that Macro you have
now.

[JF Mezei]

Michael Kraemer wrote:

> If you have to concatenate substrings of lengths unknown at
> compile time, the only clean solution is dynamic memory.
> I think this is a very common problem in text processing.

It isn't a problem at Microsoft where they just allow a string to be
moved to a buffer even if the buffer isn't big enough. They just
"borrow" memory from the neighbouring variable(s) and possibly
neighbouring sections of code. Once they are done with it, the allow the
rightful onwers to use that memory again. No different than borrowing a
cup of sugar from a neighbour when you don't have enough.

:-) :-) :-) :-) :-)

[Arne Vajhøj]

Bob Koehler wrote:
> In article <guqdnThZW8crkp3W...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>> You may not find much! Fortran's strength was numerical computation.
>> It would be used for text processing only if nothing else were available.
>
> Ever since Fortran-77 introduced CHARACTER data type and operators,
> we did tons of string manipulation quite readily in Fortran.
>
> It dosn't have all the power of the C RTL,

In many ways I think Fortran is just as good as C for this.

C is not that good at string at all. Among other reasons due to
lack of string type.

Arne

[Arne Vajhøj]

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:

>> glen herrmannsfeldt wrote:
>>> Even so, a lot was done in Fortran 66 because that was what
>>> was available. Storing one character per INTEGER array element
>>> was inefficient but usually worked.
>>

>> One - not two or four??

>
> If you use two or more, you are faced with the problem of "packing" and
> "unpacking" the data.

A problem but a solveable problem.

> I don't believe that either Fortran II or Fortran

> 66 supported a character data type. "Hollerith literals" were the best
> you could do and I don't think they could be used outside of FORMAT
> statements. My copy of "Guide to Fortran Programming" has vanished in
> the mists of time along with the later edition, "A Guide to Fortran IV"
> programming. Fortran IV did support a character data type.

Standard it did not.

Arne

[Arne Vajhøj]

glen herrmannsfeldt wrote:

> Arne Vajh?j <ar...@vajhoej.dk> wrote:
>> glen herrmannsfeldt wrote:
>>> Even so, a lot was done in Fortran 66 because that was what
>>> was available. Storing one character per INTEGER array element
>>> was inefficient but usually worked.
>
>> One - not two or four??
>

> If you want to move around individual characters, as most text
> processing does, then one.

Individual characters can be picked out of integers.

> If you just need to read them in
> and write them back out, then two or four (or more).
> (CDC stored 10 six bit characters in a 60 bit word.)

I have done quite a bit of picking display characters
out of words in Compass. 25 years ago.

Arne

[Arne Vajhøj]

Bob Koehler wrote:
> In article <hdq07m$q1n$00$1...@news.t-online.com>, Michael Kraemer <M.Kr...@gsi.de> writes:

>> F77 can be almost as painful for text stuff because
>> IIRC the standard does not provide for dynamically allocated
>> character strings.
>

> True, that's in a later standard (99?). Never stopped us, as
> Fortran programmers were were used to the idea that your buffers
> always had to be at least as large as the largest data sample.
>
> But you only need 95 to start using dynamica allocation.

90 should be enough.

Arne

[Michael Moroney]

VAXman- @SendSpamHere.ORG writes:

>Well, see my last post. If you want, replace .PRINT with .ERROR. That
>will give you a "pause" so you can to examine the code. :)

>If I can intercept Itanium instruction streams and revector control,
>I don't see what could be all that outlandish in your Macro that's so
>difficult to port.

It's not the _difficulty_ of porting, it's the _sheer volume_ of changes
necessary. We're talking hundreds of modules each with hundreds of
lines of stinking, rotten code, maybe a quarter million total.
It can get very mind-numbing.

>>(oh how I wish we could simply start over in another language. Pointy-
>>haired managers dictate otherwise)

>What? Like C? Try writing a parser to find all the zany things people
>do with that hieroglyphic and you'll be pining for that Macro you have
>now.

If _we're_ writing the C (or whatever), our code will be _much_ cleaner
overall. I may be crazy, but not _that_ crazy.

[Richard B. Gilbert]

Sometimes the standards people needed some time to catch up with
reality. VAX Fortran was Fortran IV and my recollection is that it did
support a character data type. ISTR that IBM System/360 Fortran also
supported a character data type in the mid 1980's.

I do recall that programs coded in IBM Fortran needed a little "touching
up" before it would compile and run on the VAX.

When I got my first VAX I had to port both IBM System/360 Fortran and
HP's Fortran for the 2100 Series machines to VAX/VMS. The experience
taught me to write more portable code!! I had used non standard
features simply because they were there; needless to say no OTHER
Fortran supported an identical set of non standard features.

[Richard B. Gilbert]

The trouble with good intentions is that the bosses don't want it done
right, they want done it right now!

[glen herrmannsfeldt]

Richard B. Gilbert <rgilb...@comcast.net> wrote:
(snip)

> Sometimes the standards people needed some time to catch up with

> reality. VAX Fortran was Fortran IV and my recollection is that it did
> support a character data type. ISTR that IBM System/360 Fortran also
> supported a character data type in the mid 1980's.

The OS/360 compilers, Fortran G, H, and H extended, did (and still
don't) support CHARACTER. VS Fortran from the S/370 era is a
Fortran 77 compiler and does (still) support CHARACTER. Also,
WATFIV from about 1973 supported CHARACTER along with many other
Fortran 77 features. (Sort of a test of the features before
the standard was released.)

> I do recall that programs coded in IBM Fortran needed a little "touching
> up" before it would compile and run on the VAX.

The DEC compilers tended to have many more extensions than
IBM did, though there might be some that IBM had that DEC didn't.

> When I got my first VAX I had to port both IBM System/360 Fortran and
> HP's Fortran for the 2100 Series machines to VAX/VMS. The experience
> taught me to write more portable code!! I had used non standard
> features simply because they were there; needless to say no OTHER
> Fortran supported an identical set of non standard features.

-- glen

[VAXman-]

In article <hdsrvc$9ag$1...@pcls6.std.com>, mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>VAXman- @SendSpamHere.ORG writes:
>
>>Well, see my last post. If you want, replace .PRINT with .ERROR. That
>>will give you a "pause" so you can to examine the code. :)
>
>>If I can intercept Itanium instruction streams and revector control,
>>I don't see what could be all that outlandish in your Macro that's so
>>difficult to port.
>
>It's not the _difficulty_ of porting, it's the _sheer volume_ of changes
>necessary. We're talking hundreds of modules each with hundreds of
>lines of stinking, rotten code, maybe a quarter million total.
>It can get very mind-numbing.

Well, if you need help clearing the air from that stinking, rotten code,
I'm always looking for something to do. ;)

>>>(oh how I wish we could simply start over in another language. Pointy-
>>>haired managers dictate otherwise)
>
>>What? Like C? Try writing a parser to find all the zany things people
>>do with that hieroglyphic and you'll be pining for that Macro you have
>>now.
>
>If _we're_ writing the C (or whatever), our code will be _much_ cleaner
>overall. I may be crazy, but not _that_ crazy.

In your opinion. I've seen C coded projects scarier than waking up naked,
after a night of bar-hopping, in a bed with Nancy Pelosi by your side and
as unprofessionally executed as an Ed Wood film coupled with documentation
as informative as graffiti tags along a railroad siding.

[Michael Moroney]

VAXman- @SendSpamHere.ORG writes:

>In article <hdsrvc$9ag$1...@pcls6.std.com>, mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>>VAXman- @SendSpamHere.ORG writes:

>>>>(oh how I wish we could simply start over in another language. Pointy-
>>>>haired managers dictate otherwise)
>>
>>>What? Like C? Try writing a parser to find all the zany things people
>>>do with that hieroglyphic and you'll be pining for that Macro you have
>>>now.
>>
>>If _we're_ writing the C (or whatever), our code will be _much_ cleaner
>>overall. I may be crazy, but not _that_ crazy.

>In your opinion. I've seen C coded projects scarier than waking up naked,
>after a night of bar-hopping, in a bed with Nancy Pelosi by your side and
>as unprofessionally executed as an Ed Wood film coupled with documentation
>as informative as graffiti tags along a railroad siding.

That description is more like the _current_ code. *Anything* would be
better.

Well, almost anything. There was one set of modules that were too
convoluted to get working under the Itanic macro compiler, that one of us
(not me) finally rewrote in C. But it was rewritten almost line-by-line,
bug-compatible from Macro to C, because that's what the pointy-haired
manager wanted. It was the most hideous C code ever.

[Arne Vajhøj]

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:
>> Richard B. Gilbert wrote:
>>> Arne Vajh�j wrote:
>>>> glen herrmannsfeldt wrote:
>>>>> Even so, a lot was done in Fortran 66 because that was what
>>>>> was available. Storing one character per INTEGER array element
>>>>> was inefficient but usually worked.
>>>>
>>>> One - not two or four??
>>>
>>> If you use two or more, you are faced with the problem of "packing"
>>> and "unpacking" the data.
>>
>> A problem but a solveable problem.
>>
>>> I don't believe that either Fortran II or Fortran
>>> 66 supported a character data type. "Hollerith literals" were the
>>> best you could do and I don't think they could be used outside of
>>> FORMAT statements. My copy of "Guide to Fortran Programming" has
>>> vanished in the mists of time along with the later edition, "A Guide
>>> to Fortran IV" programming. Fortran IV did support a character data
>>> type.
>>
>> Standard it did not.
>

> Sometimes the standards people needed some time to catch up with
> reality. VAX Fortran was Fortran IV and my recollection is that it did
> support a character data type.

VAX Fortran was Fortran 77 since relative early in the history of VAX!

I know that it was in 1986.

Arne

[Arne Vajhøj]

glen herrmannsfeldt wrote:
> Richard B. Gilbert <rgilb...@comcast.net> wrote:
>> I do recall that programs coded in IBM Fortran needed a little "touching
>> up" before it would compile and run on the VAX.
>
> The DEC compilers tended to have many more extensions than
> IBM did, though there might be some that IBM had that DEC didn't.

A lot of Fortran compilers supported "VAX extensions".

But not IBM.

Arne

[Arne Vajhøj]

Michael Moroney wrote:
>>> (oh how I wish we could simply start over in another language. Pointy-
>>> haired managers dictate otherwise)
>
>> What? Like C? Try writing a parser to find all the zany things people
>> do with that hieroglyphic and you'll be pining for that Macro you have
>> now.
>
> If _we're_ writing the C (or whatever), our code will be _much_ cleaner
> overall. I may be crazy, but not _that_ crazy.

It sounds as if the code could be rewritten prettier in any language.

If it is OS close then C may be a decent choice.

If it is more of a regular application there are even higher
level languages - Pascal, Ada, PL/I etc..

Arne

[Arne Vajhøj]

Michael Kraemer wrote:
> Richard B. Gilbert schrieb:
>
>> It doesn't dynamically allocate anything at all. At least it didn't
>> the last time I used Fortran.
>
> I know, but in text processing it may bite you first.
>
>> Dynamic memory allocation is a "C" thing.
>
> It's not a C only thing.
>
>> IMHO it's a useless hangover on a virtual memory system.
>
> Huh? You need memory allocation just everywhere.
> Just think of avoiding buffer overflows by always
> providing buffers of the right length.

Dynamic memory allocation does not prevent buffer overflow.

Checking available length does.

I fact there are many more buffer overflows in C than in Fortran.

Arne

[Arne Vajhøj]

glen herrmannsfeldt wrote:
> Richard B. Gilbert <rgilb...@comcast.net> wrote:

>> I got my first VAX in 1984 and after that I didn't use punched cards
>> that much. 1994 was about the time I last did any serious programming
>> in Fortran; my employers didn't use it so it wasn't available to me.
>
> I haven't looked at the VMS Fortran compilers lately. Any support
> for Fortran 2003? Fortran 90 or 95?

HP Fortran claims to be Fortran 95 compliant.

I believe it.

Arne

[JF Mezei]

VAXman- @SendSpamHere.ORG wrote:

> In your opinion. I've seen C coded projects scarier than waking up naked,
> after a night of bar-hopping, in a bed with Nancy Pelosi by your side and
> as unprofessionally executed as an Ed Wood film coupled with documentation
> as informative as graffiti tags along a railroad siding.

In that scenario, is Nancy Pelosi also Naked or just you ?

And would that be worse than Margaret Thatcher naked on a beach on a
cold rainy day ?

Look at it on the bright side: such a scenario might shrink your big
torx to be small enough to handle small screws :-)

[Arne Vajhøj]

Ken Fairfield wrote:
> I hate to jump in here (really, I do! :-), but the current
> Fortran standard is Fortran 2003, and the most commonly
> available compilers are Fortran 95 compliant (that would be
> the various versions available on Windows, g95 and gfortran
> on linux and Windows, as well as IBM's and Cray's on
> their platforms, etc. The Alpha & Integrity VMS compiler
> is also Fortran 95 compliant.
>
> Except for Glen, who loves the history of Fortran (and
> various other languages and computer-related things),
> I really don't understand why people here are so locked
> into discussing a 32-year-old version of a language
> which has a widely available 13-year-old(!) version,
> is under continuing development, and has a new
> version (Fortran 2008) in the midst of the public
> comment period.
>
> Are we VMS folks really the old dinosaurs that
> others label us as?

The average age is probably relative high compared to most
other newsgroups.

And a significant portion of people are no longer working
with VMS in their day job.

And the number of people working with Fortran 77 two decades
ago were a orders of magnitude higher than the number of
people working with Fortran 95 today.

And very little of the current Fortran work is done
on VMS (I would expect huge Linux farms to be the
typical config).

So ...

Arne

Arne

[Arne Vajhøj]

In most cases you will know max lengths.

Arne

[Richard B. Gilbert]

Ah, there's just nothing like code that has been hacked by eight or ten
different people, each in a hurry to add the feature or fix the bug and
get on with using it.

Frequently the only reasonable fix is to figure out what it does and
then do a proper design for code to do that!

[VAXman-]

OK. I've never partaken in the rewriting Macro in C koolaid. There's
no way an algorithm coded in Macro won't compile and that *exact* same
algorithm coded in C will. Nope, I'm not putting that glass to my lips
to swallow that tainted koolaid.

[VAXman-]

Yikes! Both are too hideous to look at even on a moonless and overcast
night.

[Phillip Helbig---undress to reply]

In article <4b020a32$0$274$1472...@news.sunsite.dk>,
=?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:

Full Fortran 95 support was available on ALPHA 10 years ago. Thus,
current ALPHA compilers will support the full Fortran 95 standard. I
don't know what the situation is with Itanium, but I'm sure there is
full Fortran 95 support. Alas, I don't think there are any plans to
implement the Fortran 2003 standard with a VMS compiler, neither on
ALPHA nor on Itanium. VAX FORTRAN was THE Fortran compiler; DEC's
compilers were the best compilers there were. Now, HP doesn't even plan
to support the next standard. Sic transit gloria mundi.

[Michael Kraemer]

In article <4b0209e1$0$274$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>
> Dynamic memory allocation does not prevent buffer overflow.
>
> Checking available length does.
>
> I fact there are many more buffer overflows in C than in Fortran.

Is there a metric for that or just a wild guess ?
Probably people do things in C that you won't even try in Fortran.
I guess that most buffer overflows arise from programmers being
too lazy to use dynamic allocation, using fixed length buffers.

[Michael Kraemer]

That's the mindset which creates Y2K problems.

[Richard B. Gilbert]

Dynamic allocation is not the answer! Allocating ENOUGH SPACE solves
most problems. Checking the length of what you want to put in a buffer
against the actual length of the buffer works wonders! Trying to put
five pounds in a two pound bag is a recipe for crashes and other
mysterious behavior.

[Bill Gunshannon]

In article <hdtjsp$jpu$1...@lnx107.hrz.tu-darmstadt.de>,

m.kr...@gsi.de (Michael Kraemer) writes:
> In article <4b0209e1$0$274$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>>
>> Dynamic memory allocation does not prevent buffer overflow.
>>
>> Checking available length does.
>>
>> I fact there are many more buffer overflows in C than in Fortran.
>
> Is there a metric for that or just a wild guess ?

Just a wild guess. I was fixing "buffer overflows" in Fortran (and COBOL)
30 years ago, long before I mastered C.

> Probably people do things in C that you won't even try in Fortran.
> I guess that most buffer overflows arise from programmers being
> too lazy to use dynamic allocation, using fixed length buffers.

Or, just plain not knowing what they are doing. 30 years ago there
were a lot of people earning a living writting programs that I would
never call programmers. The ratio is orders of magnitude higher today.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Richard B. Gilbert]

Michael Kraemer wrote:
> In article <4b020bf8$0$271$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>> Michael Kraemer wrote:
>>> In article <4b00b9f9$0$276$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>>>> Michael Kraemer wrote:
>>>>> Arne Vajh�j schrieb:
>>>>>> And besides Fortran 77 is not that bad. CHARACTER is fine. Fortran 66
>>>>>> would be painful.
>>>>> F77 can be almost as painful for text stuff because
>>>>> IIRC the standard does not provide for dynamically allocated
>>>>> character strings.
>>>> Lack of dynamic allocation is not necessarily a problem
>>>> for this type of problem.
>>>>
>>>> I don't even think it is likely that it would be used
>>>> even if it were available.
>>> If you have to concatenate substrings of lengths unknown at
>>> compile time, the only clean solution is dynamic memory.
>>> I think this is a very common problem in text processing.
>> In most cases you will know max lengths.
>
> That's the mindset which creates Y2K problems.

The Y2K problem was anticipated at least twenty-five years before it
actually arrived! No manager wanted to take the hit for fixing their
company's code when the problem would not manifest for twenty-five,
twenty-four, twenty-three. . . . Oh my God! It's HERE!!!!!!!!!!!!!!

[Art Wiens]

Just out of curiosity, what does 250,000 lines of macro code actually _do_ for your company/organization? Plant/manufacturing line control or such?

Cheers,
Art
--
"Cheer up ... things could get worse"
So he did ... and they did!

[Bill Gunshannon]

In article <pq-dnfAHIr6TPZ_W...@giganews.com>,

And in the end it turned out to be more hype than reality. Or did no
one here notice that the world didn't end after year "99".

[Bill Gunshannon]

In article <hdu95a$mum$1...@posting2.glorb.com>,

Art Wiens <awi...@canwest.com> writes:
> Just out of curiosity, what does 250,000 lines of macro code actually _do_ for your company/organization? Plant/manufacturing line control or such?

Pick winning Lotto numbers?

[Bob Koehler]

In article <7mdbovF...@mid.individual.net>, bill...@cs.uofs.edu (Bill Gunshannon) writes:
>
> As for the standards beyond Fyortran-77, did nayone ever make
> use of them or the new features they brought to the table? I
> have seen recent job postings for Fortran positions and they
> all specified Fotran-IV or Fortran-77.

The code was probable written in -IV or -77. The only compilers I've
seen since -77 was DEC's -95 which eventually had part of -99.

I'm sure other vendors make at least -95, but I'm not sure gnu ever
went past -77. I understand no one has written a compiler for
standard(s) after -99.

[Richard B. Gilbert]

There was more than a little hype but there were also a few real
problems that needed fixing. I built a test server so we could change
the current date at will. My then employers found one Y2K bug in their
order entry system. That was fixed and tested. Our New Years
celebration was dual purpose that year!

[Richard B. Gilbert]

The news media had a field day with it but the reality was a big yawn!
The world did not end nor was there a bang or even a whimper.

[Bob Koehler]

In article <4b01e512$0$282$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>
> C is not that good at string at all. Among other reasons due to
> lack of string type.

String constants, but not string variable type and no string
operators. But it would take a few lines of Fortran with its
CHARACTER variables and operators to replace a single C RTL
call in many cases.

Still, neither was designed to be a string processing language.

[Bob Koehler]

In article <hdsjeh$9t9$1...@lnx107.hrz.tu-darmstadt.de>, m.kr...@gsi.de (Michael Kraemer) writes:
>
> If you have to concatenate substrings of lengths unknown at
> compile time, the only clean solution is dynamic memory.
> I think this is a very common problem in text processing.

If you have 2GB virtual memory and string operations limitted to
65KB, you just allocate a 65KB static buffer.

And when that fails, you do something fancy.

[Bob Koehler]

In article <4b01e7d4$0$282$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>
> 90 should be enough.

90 will allow you to use dynamic allocation, but did not include
dynamic length strings, and I think did not include standard
allocation routines to call.

[Bob Koehler]

In article <HuGdnQdvw_6WZJzW...@giganews.com>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:

> VAX Fortran was Fortran IV and my recollection is that it did
> support a character data type.

Not for long. VAX Fortran was extended to almost the Fortran-77
standard from the release we had under VMS 1.x on our first 11/780.

It was updated to support the Fortran-77 standard sometime in the
VMS 2.x timeframe.

[Bob Koehler]

In article <hdsul5$d3o$1...@naig.caltech.edu>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> The OS/360 compilers, Fortran G, H, and H extended, did (and still
> don't) support CHARACTER. VS Fortran from the S/370 era is a
> Fortran 77 compiler and does (still) support CHARACTER. Also,
> WATFIV from about 1973 supported CHARACTER along with many other
> Fortran 77 features. (Sort of a test of the features before
> the standard was released.)

We used H Extended, which claimed only to be a FORTRAN-IV. I've
never seen any version of the 370 series compilers that supported
the ".eqs." et.al. operators that guarantee ASCII collating sequence
(on ASCII systems .eqs. is the same operation as .eq. for CHARACTER).

I wonder if IBM ever did that after I last looked?

When we wanted to compare individual characters on our 360 we
stuffed them into LOGICAL*1, which caused warnings after we upgraded
to H Extended.

[Bob Koehler]

In article <7mfno1F...@mid.individual.net>, bill...@cs.uofs.edu (Bill Gunshannon) writes:
>
> And in the end it turned out to be more hype than reality. Or did no
> one here notice that the world didn't end after year "99".

Of course it didn't end. We got paid to fix it. But I did have to
convince my neighbor that diesel engines and truck drivers were not
likely to stop if they weren't fixed.