09-01-2011 08:16 PM
Just wanted to check if there is an existing port of the TAIL binary for OpenVMS IA64? We were using previously the TAIL freeware from Hunter Goatley on our Alpha servers, but I was getting errors when I tried to compile it in our Itanium server. I tried doing a type/tail on our Oracle alert log, but I was getting the error "-RMS-F-ORG, invalid file organization value". I also tried a Perl implementation of tail but it was not functioning properly. I don't want to install GNV on our production servers, so we are only looking for a native tail binary on OVMS IA64.
Thanks in advance for your help!
Solved! Go to Solution.
09-01-2011 09:39 PM
> [...] the TAIL freeware from Hunter Goatley [...]
Not a very detailed description of the program, or where you found
> [...] I was getting errors [...]
Not a very detailed description of what happened.
> [...] when I tried to compile it in our Itanium server.
Not a very detailed description of what you did, or of your system.
As usual, showing actual commands with their actual output can be
more helpful than vague descriptions or interpretations.
> [...] but I was getting the error [...]
What was the _whole_ message?
> [...] I also tried a Perl implementation [...]
Not a very detailed description of anything.
> [...] but it was not functioning properly.
Not a very detailed description of what happened, here, either.
09-01-2011 11:07 PM
1. Hunter Goatley's TAIL archive freeware http://vms.process.com/scripts/fileserv/fileserv.c
2. I am attaching the log when I tried to compile the source code for Hunter's program.
3. I am doing the compilation on a standalone HP Integrity rx2660 with OpenVMS 8.3-1H1, and compiling it using HP C v7.3-018.
4. Problem with the Perl script TAIL implementation is if I tried to put the parameter to specify the number of lines I would like to see, e.g $ tail -n10 operator.log, it will still print out the whole file. I am attaching the TAIL Perl script that I got from the internet (already forgot which site I got it).
09-01-2011 11:12 PM
ORACLE10G_S1P0A::> dir s1p0c_prod_alert*.log/size
Total of 1 file, 3576 blocks.
ORACLE10G_S1P0A::> type/tail=10 s1p0c_prod_alert.log
%TYPE-W-OPENIN, error opening DISK$PKG:[1020.ADMIN.PROD.bdump]S1P0C_PROD_alert.l
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
-RMS-F-ORG, invalid file organization value
ORACLE10G_S1P0A::> dir/full S1P0C_PROD_alert.log;1
S1P0C_PROD_alert.log;1 File ID: (16194,4,0)
Size: 3576/3584 Owner: [DBA,ORACLE10G]
Created: 13-JUL-2011 15:38:09.33
Revised: 2-SEP-2011 14:02:26.52 (21300)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: <None specified>
Attributes: <None specified>
Modified: <None specified>
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 3584, Extend: 0, Global buffer count: 0, No version limit
Record format: Variable length, maximum 0 bytes, longest 904 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:, World:
Access Cntrl List: None
Client attributes: None
Total of 1 file, 3576/3584 blocks.
09-02-2011 12:31 AM
$ help type/tail
09-02-2011 07:02 AM
That file might well have the LOG extension, but (based on the posted settings, and particularly that 904 byte record length) it is apparently not intended for use by humans. (A situation which reminds me of this forum software, reading that last and garbled post from Hartmut. But I digress.)
Check with whatever is writing that log, and see if you can adjust the record length to something more appropriate.
Alternatively, I used a gnv tool to wrap gonzo file text to fix a long-line issue with a text file.
09-02-2011 07:20 AM
> 1. Hunter Goatley's TAIL archive freeware http://vms.process.com/scripts/fileserv/fileserv.c
Did you look at the dates in that fossil?
It's too old. It doesn't know about ODS5 extended file names. It
has a very unfortunate default_string. I'm sure that if I looked at it
longer, I could find any number of reasons for a complete re-write.
However, I took out some of the most lame parts ("#ifdef __alpha"), so
that it might get past a modern compiler in more places, and it's
I deny everything.
Well, I would have attached it here, but today I'm on a Mac with
Firefox, so I can post a message normally instead of as a text
attachment (which is all I've gotten to work with SWB on my main VMS
system), but here I can't seem to get an attachment accepted. So, for a
limited time only:
I still deny everything.
09-03-2011 07:29 PM
Roose>>. I tried doing a type/tail on our Oracle alert log, but I was getting the error "-RMS-F-ORG, invalid file
It is unfortunate that the type/tail implementor highjacked a fine error message for a lowly cause.
The error should have been "TYPE-F-ing_too_lazy. We know what is good for you."
One single long record can spoil the fun for a file.
I don't have an Oracle-on-openvms handy, but I suspect Oracle does not keep the file open.
In that case you can just make a white lie about the LRL using SET FILE/ ATTR=LRL=511 and hope for the best.
You could rename it away, have Oracle create a fresh one, and then use SET FILE
HB> It seems the longest record length doesn't meet the above criteria.
Yeah sure, but how LAME are those criteria?
Why would they even bother to validate a record length for a stream-lf file?
Why are fixed length records not allowed? Those are the easiest to implement of all!
(Cobol applications often make those.)
Hoff>> it is apparently not intended for use by humans.
BS. The Oracle alert log is strictly, and only, intended for use by humans.
Now it may have made tricky or even erroneous choices but that is not up to TYPE to judge.
Fwiw, I have raised the type malfunction with engineering in a meeting last month and got some traction.
09-04-2011 06:41 AM
I've seen this sort of code before and know a porting error when I see it. This is an Oracle error.
It might have been the intent of the programmers here to use this log for humans, but (as I stated) that wasn't the result. This isn't a file intended for (VMS-using) humans.
These results are typically usable only after file modifications are made; wrapping or related.
While you're raising this testing coverage issue with Oracle, the test coverage likely need generic LRL and related checks of the resulting files; I'd likely add checks to detect and flag any other questionable RMS file constructions might exist here.
09-04-2011 04:02 PM
I'm with Hein on this, the way TYPE/TAIL works (or rather, doesn't work) is rather silly and could be improved significantly with little effort, if engineering cared about usability.
Something I've seen with log files is the phenomenon of TYPE/TAIL working for a particular log file while it's being actively written, but then failing with -RMS-F-ORG once it's been closed. It's usually a STREAM_LF log file from a C program. What happens is the MRS and LRL of the open file are 0 while the file is being written, so TYPE is happy, but once it's closed, LRL is set to 32767, which TYPE doesn't like.
$ SET FILE/ ATTR=LRL=511 on an affected file is one way around it, another is to reset the DECC default LRL:
$ DEFINE/SYSTEM DECC$DEFAULT_LRL 511
09-05-2011 04:34 AM
>>> Yeah sure, but how LAME are those criteria?
As lame as the implementation of a Unix, aka coreutils tool in VMS. However, this has been this way for years and nobody asked (until last month?) to improve it or got through with her/his request.
>>> $ DEFINE/SYSTEM DECC$DEFAULT_LRL 511
I wouldn't dare to do this, even if I had the privileges. DEFINE/USER is what I use and recommend when setting a CRTL feature logical. No, I didn't write the HELP text:
09-05-2011 05:46 AM
Those DECC$ logical names and the related non-modular morass can be stabiility kryptonite.
I'd recommend those are either defined /USER only, or are embedded within specific and task-dedicated processes. Defining those logical names with /SYSTEM risks knocking over something else, and quite possibly with an obscure error.
And I'm not arguing that TYPE /TAIL is a mess. Just that a "log" file that's over 132 or so characters in width isn't intended for (VMS) humans.
Like TYPE /TAIL's various issues, the lack of baked-in word-wrapping are related parts of the UI-level problems and omissions. (When the easiest way to wrap text is GNV, there's something missing in the base OS.)