| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3023.1 | some thoughts... | FRSTSC::TLAUER | "I've been designed multi-asking." | Mon Apr 21 1997 08:22 | 11 |
| Given the tremendous amount of missing documentation (the given pointers to the
Guide to OpenVMS File Apps and to SET RMS_DEFAULT accvio'ed when trying to
follow them), i'd suspect that while RMS_HEURISTIC will generally put RMS in
magic mode, RMS_DFLRL will determine how long it stays there in examining
a portion of your file. And, if RMS_DFLRL bytes have been analysed without
giving RMS a further clue about the characteristics of a given file, you'd still
get an RTB error, if all the above makes any sense at all.
How did you set RMS_DFLRL, and what sort of file did you try to TYPE?
-- Thilo
|
| 3023.2 | any examples? | GIDDAY::GILLINGS | a crucible of informative mistakes | Mon Apr 21 1997 18:46 | 9 |
| Thilo,
I tried a number of values for RMS_DFLRL (32K, 16K, 8K etc), but there
didn't seem to be any differences in behaviour. The file was originally
variable length (output from an ANALYZE/AUDIT) which I hacked with SET
FILE/ATTRIBUTE. Perhaps someone could give an example of different behaviour
depending on the values of these parameters? Should we turn "magic" mode on
by default? What's a "reasonable" value for RMS_DFLRL? Any downside?
John Gillings, Sydney CSC
|
| 3023.3 | Shouldn't have been documented in V7.1 | STAR::EWOODS | | Mon Apr 21 1997 18:50 | 50 |
| John --
We had initially planned to implement a new RMS "Heuristic" feature
in V7.1. Feedback from layered products in EFT2 indicated it needed
some more knobs. Any descriptions that had already been put into
the V7.1 New Features manual were supposed to be pulled. As Thilo
found out, we were successful in getting most of the writeups pulled.
You happened upon one that wasn't. So you got a little taste, but
you will have to wait until release after V7.1 for the whole
implementation. Only latent support for some bits and pieces are
in V7.1.
However, the real impetus behind it is to help with files created by
PATHWORKS that contain binary data rather than text data. Since you
were trying to "type" a STM file, I presume it contained text data.
And obviously, it had no real STM terminator in first 32767 bytes of
data so TYPE just tried to display on terminal a record as long as the
maximum record buffer TYPE sets up (32,767). Unfortunately, changing the
LRL to 512, for example, on a STM file isn't going to help with TYPE
utility. As currently implemented, TYPE doesn't use the LRL in sizing
the record buffer so changing LRL won't help.
I can give you a workaround with TYPE in V7.1 for a file of the kind
you describe -- STM file larger than MAXBUF but no stream terminator
for a record within first 32767 bytes of file.
$ rfm = F$FILE_ATTRIBUTES("A.STM","RFM") ! save old rfm
$ SET FILE/ATTRIB=(RFM=UDF) A.STM
$ TYPE A.STM
$ SET FILE/ATTRIB=(RFM='rfm') A.STM ! restore old rfm
It happens I made a change in TYPE code in V7.1 for undefined record
format: if UDF record format, it will use a record buffer of 512 bytes
which results in its breaking file up into 512-byte chunks.
Our understanding is that the problem users have with "foreign" files is
with the ones that really contain "binary" data -- and I doubt they
would be using "type" for those files. Could you provide some more
feedback whether as your example suggested, it is common for users to
have "foreign" files that have a record format of STM -- and it
contains TEXT data but does not contain any stream terminator within
first 32767 bytes of file (and file size is greater than MAXBUF).
Feel free, John, to send me off-line mail and bend my ear.
Sorry for the documentation snafu.
-- Elinor
|
| 3023.4 | Customers want everything to just work, DWIM! | GIDDAY::GILLINGS | a crucible of informative mistakes | Tue Apr 22 1997 19:48 | 23 |
| Elinor,
It's good to see that there's some work going on in this area. The more
OpenVMS integrates seamlessly with other operating systems, the beter. We get
calls from customers trying to use various RMS based utilities (TYPE, DUMP,
EDIT, COPY etc...) on "foreign" files, resulting in the RTB error message.
In most cases they want OpenVMS to just "Do What I Mean", even when they
don't really know what they mean. The usual solution is to transfer the file
again using a more OpenVMS friendly mechanism, or hack at it with SET
FILE/ATTRIBUTES.
I couldn't ever imagine a "universal" solution to this problem, so when
I saw the new feature, I wondered what you'd cooked up and how it would work.
The change to TYPE sounds quite useful, I'll remember that one!
I'll try and gather some real world examples and send them to you (saying
that almost guarantees I won't see another RTB call for a few months ;-).
> Sorry for the documentation snafu.
These things happen. Now I know what to tell customers who ask.
John Gillings, Sydney CSC
|