In article <07121214321866_202647DE@antinode.org>,
sms@antinode.org (Steven M. Schweda) wrote:

> From: "P. Sture"
>
> > In article <07120600562608_202002AB@antinode.org>,
> > sms@antinode-org (Steven M. Schweda) wrote:
> >
> > > Directory ALP$DKA0:[SMS.RUNOFF]
> > >
> > > LC.MEM;1 142 <--- Hmmm.
> > > UC.MEM;1 138 <---
> > > VMS_ZIP.RNH;1 131
> >
> > Duplicated on another .RNH file here. The resulting .MEM has page
> > numbers and form feeds, hence the larger size.
> >
> > The setting of SET PROCESS/PARSE doesn't make any difference here.
> >
> > This on Alpha V8.3.
>
> It's a trend. I submitted a "product business feedback" complaint to
> HP (http://h71000.www7.hp.com/fb_business.html), and got a
> thanks-but-it's-old-code response. Conspicuously missing was any
> suggestion that the problem would ever be fixed. (But, optimists may be
> encouraged, in that there was also no promise never to fix it.)

A few memories stirred since I made my post...

Thinking back to about 1985, when I first discovered how to use RUNOFF
for help files, I was surprised that it relied on the file type instead
of having a qualifier (c/f LIBRARY/HELP).

Dumping RUNOFF.EXE reveals arrays containing RUNOFF recognized
filetypes, in uppercase of course, so would not be surprised to find
that a proper solution also had to address the other file types. IOW
substantially more work than fixing only the .rnh issue.

> In any case, future Info-ZIP source kits should contain only ".RNH",
> not ".rnh", files. Be sure to complain if you see a policy violation
> after now.
>

Noted, but I'll add that in the light of my previous paragraph, beware
of other file types too.

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html