Freeware FILES_INFO on OpenVMS 8.4 I64 Integrity Servers

[How to use DECset PCA w]

Hi there, 

              I seen on an old post (2008) that a OpenVMS user had the same issue as I'm currently having. I use the FILES_INFO freeware utility on a regular basis and have found it really useful in scripts to check updates to files are happening as expected. We're moving from ES45 running OpenVMS 8.3 to I64 Integerity servers running OpenVMS 8.4.

Hoping someone can give me some info on:

Has anyone used an updated FILES_INFO utility that runs on the I64 Integrity servers with OpenVMS 8.4?

Does it work as expected?

Is there a ported version out there that is Freeware thats been ported or is porting it something I'd need to undertake myself?

I presume this would mean either getting a C Compiler license or paying someone to procude the exe?

All information/guidance appreciated

[Steven Schweda]

> I seen on an old post (2008) [...]

   An actual link might be much more helpful than this "reference".

> [...] really useful in scripts to check updates to files are happening
> as expected.

   What, exactly, are you checking?

> Has anyone used an updated FILES_INFO utility that runs on the I64
> Integrity servers with OpenVMS 8.4?

   Not I.  I took a quick look at it, but I was frightened off by stuff
like:

%ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$w_e_type' has invalid value %XFE00

   It's also too old to deal with ODS5 extended names.  With my
(extremely) weak macro32 knowledge, I'd be looking for another way to do
whatever it is you want to do.

> I presume this would mean either getting a C Compiler license or
> paying someone to procude the exe?

   Yeah, but I'd guess that getting the C code compiled would be the
least of your problems.

[H.Becker]

> %ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$w_e_type' has invalid value %XFE00

Usually the linker prints out more information than that. The complete linker message would be useful. It shows the module. Obviously the linker got an input file, expected an ELF header and didn't find one. Looking at the input file, with the analyze or dump utility will very likely help to understand and resolve the problem.

[How to use DECset PCA w]

Hi,

    the link to the old post: https://community.hpe.com/t5/System-Management/Freeware-FILES-INFO/m-p/5108038#M37507

I have a database files and logs that I monitor for reads and writes to ensure that their being regularly updated. The files are likely to be open when I'm checking.

Thanks

[Steven Schweda]

> %ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$w_e_type' has invalid
> value %XFE00

   Oops.  That was from when I was fooling around.  The normal MMS build
died like this:

IT $ mms

MACROS = "/MACRO=(__DECC__=1,__ALPHA__=1)"
MMS'macros' default
CC /NOLIST/OBJECT=FILES_INFO.OBJ FILES_INFO.C

typedef struct wcbstr
^
%CC-I-USELESSTYPED, This typedef declaration is useless because it does not decl
are a typedef name.
at line number 123 in file IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]files_
info.c;1
If "''F$Search("FILES_INFO.OLB")'" .EQS. "" Then LIBRARY/Create FILES_INFO.OLB
LIBRARY/REPLACE FILES_INFO.OLB FILES_INFO.OBJ
MACRO /NOLIST/OBJECT=FILES_MACRO.OBJ FILES_MACRO.MAR
If "''F$Search("FILES_INFO.OLB")'" .EQS. "" Then LIBRARY/Create FILES_INFO.OLB
LIBRARY/REPLACE FILES_INFO.OLB FILES_MACRO.OBJ
SET COMMAND /OBJECT=FILES_CLD.OBJ FILES_CLD.CLD
If "''F$Search("FILES_INFO.OLB")'" .EQS. "" Then LIBRARY/Create FILES_INFO.OLB
LIBRARY/REPLACE FILES_INFO.OLB FILES_CLD.OBJ
MACRO /NOLIST/OBJECT=LOCK_NONPAGED_CODE.OBJ LOCK_NONPAGED_CODE.MAR
If "''F$Search("FILES_INFO.OLB")'" .EQS. "" Then LIBRARY/Create FILES_INFO.OLB
LIBRARY/REPLACE FILES_INFO.OLB LOCK_NONPAGED_CODE.OBJ
LINK/TRACE/NOMAP/EXEC=FILES_INFO.EXE/NOTRACEBACK/MAP/CROSS/FULL FILES_INFO/INCLU
DE=FILES_INFO/LIBR,
FILES_INFO.ALPHA_OPT/OPTIONS/SYSEXE
%ILINK-W-NUDFSYMS, 5 undefined symbols:
%ILINK-I-UDFSYM, EXE$IPID_TO_EPID (Weak Reference)
%ILINK-I-UDFSYM, FCB$W_ACNT
%ILINK-I-UDFSYM, FCB$W_REFCNT
%ILINK-I-UDFSYM, FCB$W_STATUS
%ILINK-I-UDFSYM, FCB$W_WCNT
%ILINK-I-UDFSYM, WCB$W_ACON
%ILINK-W-USEUNDEF, undefined symbol FCB$W_REFCNT referenced
section: $CODE$
offset: %X0000000000001520 slot: 1
module: FILES_INFO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-W-USEUNDEF, undefined symbol FCB$W_ACNT referenced
section: $CODE$
offset: %X0000000000001670 slot: 2
module: FILES_INFO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-W-USEUNDEF, undefined symbol FCB$W_WCNT referenced
section: $CODE$
offset: %X00000000000016A0 slot: 2
module: FILES_INFO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-W-USEUNDEF, undefined symbol FCB$W_STATUS referenced
section: $CODE$
offset: %X00000000000016D0 slot: 0
module: FILES_INFO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-W-USEUNDEF, undefined symbol WCB$W_ACON referenced
section: $CODE$
offset: %X0000000000001720 slot: 2
module: FILES_INFO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-F-SHRINOFF, linker internal error - an official FD was made for a symbol
defined by a shareable image
relocation section: .relaEXEC$NONPAGED_DATA (section header entry: 13)
relocation type: RELA$K_R_IA_64_VMS_ADD
relocation entry: 1
module: FILES_MACRO
file: IT$DKE0:[UTILITY.SOURCE.FILES_INFO.v2r0.source]FILES_INFO.OLB;1
%ILINK-E-NOIMGFIL, image file not created
%MMS-F-ABORT, For target FILES_INFO.EXE, CLI returned abort status: %X1789EA6C.
%MMS-F-ABORT, For target BUILD_IT, CLI returned abort status: %X10EE8034.

   It did better (no LINK errors) on Alpha.

    Knowing nothing, I assume that the undefined things might be in some
other .STB on IA64, but "help /mess SHRINOFF" was discouraging.  Someone
who knows something about VMS kernel code and Macro32 would have a
better chance than I of making this work.

[H.Becker]

Actual commands and actual output really helps :-)

> It did better (no LINK errors) on Alpha.

No suprise, as there are "#ifdef __alpha" in the C source. I would try to replace them with "#ifdef __ia64".

> Knowing nothing, I assume that the undefined things might be in some
other .STB on IA64, but "help /mess SHRINOFF" was discouraging. Someone
who knows something about VMS kernel code and Macro32 would have a
better chance than I of making this work.

On I64 .STBs are no linker input files.

I agree, the Macro32 code needs to be looked at whether it is OK for I64. To avoid the linker error, get rid of the EXEC$NONPAGED_DATA PSECT in the file_macro.mar and try a JSB to the real routine. The PSECT (and what the compiler generates) causes the linker to create an official function descriptor for something which is defined in the base (shareable) image. But, again, that may not be enough to get this working. 

[Steven Schweda]

> No suprise, as there are "#ifdef __alpha" in the C source. I would try
> to replace them with "#ifdef __ia64".

   I'd try "#ifndef __vax" (or plain "vax", for stone-age
compatibility), which seems to work.  (Wouldn't want to do this again
for x86.  I must have glanced at the MMS macro, __ALPHA__, and figured
that all would be well.  Duh.)

> %CC-I-USELESSTYPED, [...]

   Discarding the useless "typedef" keyword quiets that one.

> [...] To avoid the linker error, get rid of the EXEC$NONPAGED_DATA
> PSECT in the file_macro.mar and try a JSB to the real routine. [...]

   That's well beyond my (negligible) Macro/VMS understanding.  (I could
probably handle the (C) NAM -> NAML conversion, though.)

[H.Becker]

---

@Steven Schweda wrote:

   That's well beyond my (negligible) Macro/VMS understanding.  (I could
probably handle the (C) NAM -> NAML conversion, though.)

---

At the moment I don't have access to an I64 system (that I can crash in case something goes wrong). I have an Alpha emulator running and can do some tests on it. I'm not sure whether (all of) the macro32 code is needed on Alpha or I64. From what I remember, there are standard calling interfaces for most of these internal routines, including CVT_EPID_TO_IPID. I'll try this on Alpha. If this works out as expected, it should work on I64 as well. 

[H.Becker]

Using exe_std$cvt_ipid_to_epid() seems to work on Alpha. Calling it from C can replace the jacket routine in files_macro.mar. I didn't change anything else in the Macro32 sources.

I created a new files_convert_pid.c:

#include <ssdef.h>
extern int exe_std$cvt_ipid_to_epid();
int convert_pid (unsigned int ipid, unsigned int * epid) {
    *epid = exe_std$cvt_ipid_to_epid (ipid);
    return SS$_NORMAL;
}

removed the corresponding code from files_macro.mar:

$ diff/slp files_macro.mar-orig files_macro.mar/out=sys$output
- 67, 69
- 152, 176
/
$

added files_convert_pid to the mms file:

$ diff/slp descrip.mms-orig descrip.mms/out=sys$output
- 55, 57
FILES_INFO_OBJS = FILES_INFO,FILES_MACRO,FILES_CLD,LOCK_NONPAGED_CODE, -
files_convert_pid

FILES_INFO$(OBJ) : FILES_INFO.C
files_convert_pid$(OBJ) : files_convert_pid.c
/
$

OK, this is more or less a quick and dirty change to get over the I64 linker error message and to produce an executable. Again, as I understand this code, for I64 you need to make sure the "#ifdef __alpha" C source code is compiled.

If necessary, I can drop a zip file with what I have for Alpha.

[Steven Schweda]

> I created a new files_convert_pid.c:
> [...]

   It works for me.  I stuck the code into files_info.c, and added some
VAX conditionality to files_macro.mar.  And replaced descrip.mms.  I
haven't tried it with VAX C, but, around here:

IT $ cc /vers
HP C V7.3-019 on OpenVMS IA64 V8.3-1H1

IT $ mms test

   Destination: [.IA64]

if (f$search( "IA64.DIR;1") .eqs. "") then create /directory [.IA64]
mcr [.IA64]FILES_INFO.EXE [.IA64]FILES_INFO.EXE

FILE: ALP$DKC0:[UTILITY.SOURCE.FILES_INFO.files_info_030.source.IA64]FILES_INFO.
EXE;1
Total access count of 1, XQP access 1, writers 0, size 54/64

PID USERNAME READS WRITES ACCESS CHARACTERISTICS
-------- ------------ -------- -------- ----------------------
20E00471 SYSTEM 9 0 Read, Cathedral, Complete, Sequential
, NoWriteShr

ALP $ cc /vers
HP C V7.3-010 on OpenVMS Alpha V8.4

ALP $ mms test

   Destination: [.ALPHA]

if (f$search( "ALPHA.DIR;1") .eqs. "") then create /directory [.ALPHA]
mcr [.ALPHA]FILES_INFO.EXE [.ALPHA]FILES_INFO.EXE

FILE: ALP$DKC0:[UTILITY.SOURCE.FILES_INFO.files_info_030.source.ALPHA]FILES_INFO
.EXE;1
Total access count of 1, XQP access 1, writers 0, size 25/32

PID USERNAME READS WRITES ACCESS CHARACTERISTICS
-------- ------------ -------- -------- ----------------------
20215CEE SYSTEM 10 0 Read, Cathedral, Complete, Sequential
, NoWriteShr

WISP $ cc /vers
Compaq C V6.4-005 on OpenVMS VAX V7.3

WISP $ mms test

   Destination: [.VAX]

if (f$search( "VAX.DIR;1") .eqs. "") then create /directory [.VAX]
mcr [.VAX]FILES_INFO.EXE [.VAX]FILES_INFO.EXE

FILE: _WISP$DUA0:[UTILITY.SOURCE.FILES_INFO.FILES_INFO_030.SOURCE.VAX]FILES_INFO
.EXE;1
Total access count of 1, XQP access 1, writers 0, size 17/18

PID USERNAME READS WRITES ACCESS CHARACTERISTICS
-------- ------------ -------- -------- ----------------------
0000023A SYSTEM 9 0 Read, Cathedral, Complete, Sequential
, NoWriteShr

   The documentation still needs some work, so the following kit is
subject to change (without notice), but:

http://antinode.info/ftp/files_info/files_info-030/files_info-030_src.zip

   Complaints are always welcome.

[Steven Schweda]

> The documentation still needs some work, so the following kit is
> subject to change (without notice), but:
>
> http://antinode.info/ftp/files_info/files_info-030/files_info-030_src.zip

   I made a few more changes, fixed a few bugs (old and new), and ran
one more test:

WIMP $ cc /vers
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\VERS\
WIMP $ cc /noobje /list = tt: nl:
[...]
INPUTFILE                                                       21-NOV-2016 16:3
6:10 VAX C V3.1-051 Page 1
[...]

WIMP $ write sys$output f$getsyi( "version")
V5.4

WIMP $ mms /mac = (VAXC=1, MMS$ARCH_NAME=VAX) test

Destination: [.VAXV]

if (f$search( "VAXV.DIR;1") .eqs. "") then create /directory [.VAXV]
mcr [.VAXV]FILES_INFO.EXE [.VAXV]FILES_INFO.EXE

FILE: _WIMP$DUA3:[UTILITY.SOURCE.FILES_INFO.FILES_INFO-030.SOURCE.VAXV]FILES_INF
O.EXE;1
Total access count of 1, XQP access 1, writers 0, size 16/18

PID USERNAME READS WRITES ACCESS CHARACTERISTICS
-------- ------------ -------- -------- ----------------------
000000A5 SYSTEM 8 0 Read, Cathedral, Complete, Sequential
, NoWriteShr

http://antinode.info/ftp/files_info/files_info-030/files_info-030_src.zip
http://antinode.info/ftp/files_info/files_info-030/files_info-030_vms.zip

   If I get ambitious, I may make an actual Web page for it.

> Complaints are always welcome.

   Still true.

[H.Becker]

---

@Steven Schweda wrote:

http://antinode.info/ftp/files_info/files_info-030/files_info-030_src.zip
http://antinode.info/ftp/files_info/files_info-030/files_info-030_vms.zip

> Complaints are always welcome.

 Here we go: the links don't work. In the directory the file names only contain underscores.

---

[Steven Schweda]

> Here we go: the links don't work. In the directory the file names only
> contain underscores.

   Oops.  Should be better now.  Thanks for the complaint.

[How to use DECset PCA w]

Great, Really appreciated and very much looking forward to giving this a go. Keep you posted on how I get on.

[How to use DECset PCA w]

Sorry, I keep getting a server problem when I try to download the files_info-30_vms.zup file.

[Steven Schweda · Accepted solution]

> Sorry, I keep getting a server problem when I try to download the
> files_info-30_vms.zup file.

   As usual, showing exactly what you did, and exactly what happened
when you did it, would be more helpful than vague descriptions or
interpretations.  "a server problem" tells me nothing useful.  I see no
"files_info-30" or ".zup" in my Web server log file (which is probably a
good thing), and the only relevant 404 errors which I do see stopped
after I adjusted the file names after the last one at
"[22/Nov/2016:06:37:39 -0600]".  I do see multiple successful downloads
since then.  Give me something from which I can extract some useful
info, and I'll look harder.

>    If I get ambitious, I may make an actual Web page for it.

      http://antinode.info/dec/sw/files_info.html

   The links there seem to work (for me), too.

[abrsvc]

FWIW, I downloaded the files after they were "fixed" and have had no problems unzipping the files and using them.

The problem is not with the host of the files.

Dan

[How to use DECset PCA w]

Apologies, the problem was with me. My firewall was blocking it but with no indication. Switched it off and downloaded no problem. Again, apologies for the confusion.

In the past I had modified the source to extend the fmt array from 7 to 10:

char fmt [] = {"!XL !12AS !10UL !10UL !AS!AS!AS!AS!AS!AS!AS!AS!AS"};

and I think changed the header

printf ("\n PID USERNAME READS WRITES ACCESS CHARACTERISTICS");
printf ("\n-------- ------------ ----------- ----------- ----------------------");

this allowed me to cheap track of bigger files.

Thanks for the help on this one, I'm looking forward to trying it out on our new servers.

[Steven Schweda]

> char fmt [] = [...]

   Hmmm.  Under a heading like "  --------", " !7UL" does seem pretty
silly.  I've posted a modified files_info.c which keeps the same total
width, but wastes less white space ("   !7UL" -> " !9UL").

      http://antinode.info/ftp/files_info/files_info-030/files_info.c

As I discovered when I tried to change that format string (fmt[]),
there's a touchy calculation of how much of that format string to use:
       faoFmt.dsc$w_length = 28 + ((j-5)*3);

   That "28" is the length out to the end of the first "!AS", which is
liable to change if that format string is changed.  I'm normally all for
run-time efficiency, but I changed that (brittle) compile-time "28" to a
run-time calculation based on where the "!AS[...]" stuff starts, so if
you want more than nine digits, you should now be able to fiddle with
the format without needing to worry about also fiddling with that
formula.

   I resisted the temptation to add actual status checking to the
sys$fao[l]() instances.

> [...] this allowed me to cheap [keep?] track of bigger files.

   I'd say "busier", not "bigger".

[How to use DECset PCA w]

Steven ... thanks for the changes. 

Your of course correct, busier is what I'm tracking.

[Steven Schweda]

> Steven ... thanks for the changes.

   No problem.  I'll probably let it rest for a while, and perhaps,
eventually, build V3.1 kits with the wider fields.  (Unless someone
persuades me that still-wider fields would be better.)

   By the way, if you're interested in changing that erroneous-looking
username, there's a forum (and a much-used thread) for that:

      https://community.hpe.com/t5/x/x/td-p/4836377