-RMS-F-ORG _ What error is this?

[Joewee]

Hi All,

I can normally type these files, but when ever I give /TAIL qualifier, I get the following error. These files are pretty big and I cant type it normally. Please help.

ty/tail $1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_xxx.LOG;
%TYPE-W-OPENIN, error opening $1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_xxx.LOG;1 as input
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
-RMS-F-ORG, invalid file organization value

[Joewee]

dir $1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_XXX.LOG;/full

Directory $1$DKD1000:[ORACLE817.NETWORK.LOG]

LISTENER_XXX.LOG;1 File ID: (10143,7,0)
Size: 576207/576216 Owner: [RY404B,ORACLE]
Created: 10-MAR-2003 19:06:14.73
Revised: 2-AUG-2010 12:15:40.59 (61)
Expires: 5-FEB-2016 16:44:00.64
Backup:
Effective:
Recording:
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 576216, Extend: 0, Global buffer count: 0, No version limit
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 576207/576216 blocks.

[John Gillings · Accepted solution]

Joewee,

TYPE/TAIL is a bit of a kludge. Counting back records from the end of the file is a rather ugly, hit or miss algorithm (see source code). In order to make the heuristics being used work at all, it's necessary to limit the organisation and record length of the files for which it works. See HELP TYPE/TAIL:


-------
... You can use TYPE/TAIL only if all of the following criteria are true:

o File organization is sequential.

o The longest record is less than 512 bytes.

o The record format is either VAR, VFC, STM, STRCM or STMLF (for more information, see the description of FAB$B_RFM in the OpenVMS Record Management Services Reference Manual).

o The file being typed is on a device that supports random access. The TYPE/TAIL command does not work on magnetic tape drives.

Even with this criteria, some file conditions cannot be anticipated and may not allow display of the last several lines of a log file, resulting in the following error message:

%TYPE-W-READERR, error reading DEVICE:[DIRECTORY]FILE.EXT;1
-SYSTEM-E-UNSUPPORTED, unsupported operation or function

-------
In your case the most likely offending attribute is:

>Record format: ... longest 32767 bytes

As it happens, this may be an incorrect value, being an artefact of another OpenVMS kludge, in the way the DECC RTL deals with RMS file attributes. You could try:

$ SET FILE/ATTRIBUTE=(LRL:511) $1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_xxx.LOG;
$ TYPE/TAIL
$1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_xxx.LOG;

(now restore to original value)
$ SET FILE/ATTRIBUTE=(LRL:32767) $1$DKD1000:[ORACLE817.NETWORK.LOG]LISTENER_xxx.LOG;

[of course, if your file really does have records longer than 512 bytes in the /TAIL window, you might not get the results you want]

[RBrown_1]

HELP TYPE /TAIL tells us that several things must be true of a file for TYPE/TAIL to work. One of the requirements is "the longest record is less than 512 bytes" (VMS 7.1).

Your DIRECTORY/FULL says the longest record is 32767 bytes. True? Maybe a convert would help? Or a SET FILE/ATTRIBUTES. Personally, I would try the SET FILE/ATTRIBUTES first. Maybe something like:

$ SET FILE/ATTRIBUTES=MRS=512

I have heard that there are other "freeware" tail programs. One of them might help you.

Good luck.

[Hein van den Heuvel]

John is too nice.

Type/tail is not just a kludge, it is a total disgrace with arbitrary, artificial, un-needed restrictions. :^)

It does not handle the simplest of files like fixed length record...

It worries about longest record length too early. To some extend that might actually be fault as I suggested an early heuristic! (walk backwards for 'words' with a small value likely to be a record length, then check whether they point to the start position). Looks like that was taken too directly / too inflexible

Anyway... so yeah... try lying about the LRL and hope there are no actual very long records at the tail.

cheers,
Hein

$ convert login.com tmp.tmp/fdl="record; form fix; size 20"/pad/trunc
$ type/tail tmp.tmp
%TYPE-W-OPENIN, error opening TMP.TMP as input
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
-RMS-F-ORG, invalid file organization value


$ copy login.com tmp.tmp
$ set file/attr=lrl=2000 tmp.tmp
$ type/tail tmp.tmp
%TYPE-W-OPENIN, error opening TMP.TMP as input
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
-RMS-F-ORG, invalid file organization value

[Joseph Huber_1]

GNU textutils tail works well in most cases, where VMS type/tail fails.
On VMS GNV/bash tail, can be used from DCL command line as long as no wildcard file specs are involved.

I have also a perl tail implementation from PerlPowerTools working quite well.

[H.Becker]

"Most cases" for GNV's tail seem to be Stream_LF with longer longest record lengths. It fails for fixed as well as for VFC and variable length.

GNV's tail, when invoked from the DCL command line, expects a Posix path specification to the file. So manually translate the [.sub]file.txt;1 to sub/file.txt. And no, you can't 'tail' the version ;-1 of a file.

On the other hand, the type/tail error message in the OP is misleading, at least I wouldn't have expected the big LRL to be an "invalid file organization value".

[Joseph Huber_1]

Yes, there seems to be no single tail implementation being perfect for VMS.
The perl implementation I mentioned comes nearest, it understands VMS and Unix style file/path names, and handles stream as well as var files.

I stumbled in my archive over a VMS tail implementation from a VMS SIG tape:

V2.4 - 09/10/91
Author:
D. Shepperd, Atari Games, Corp. shepperd@dms.UUCP

It analyses the file format and then chooses the right access method.

[Joewee]

Hi All,


Many thanks for your time and reply. file attribute changing worked fine. Thanks.

Im closing this thread