C Code Returning Unreadable File ID String

[Robert Atkinson]

The C code below (from ExecSymb) returns this string as the File ID, which is unusable :-

FILE_IDENTIFICATION
␊_$1$DGA151␤␤␤␤␤ú#M␤␤d-␤␤


Anybody know the code to return it in the (n,n,n) format?

Rob.


C
C Look at the identification of the file being processed. Strip off the
C device name, and get the fileid and directory id values.
C
STREAM(NSTREAM).ENTRY=LONG(MESSAGE(IP:IP+3))
IP=STREAM(NSTREAM).POS(SMBMSG$K_FILE_IDENTIFICATION)
STREAM(NSTREAM).DEVICE_NAME_LEN=BYTE(MESSAGE(IP:IP))
STREAM(NSTREAM).DEVICE_NAME=MESSAGE(IP+1:IP+15)
STREAM(NSTREAM).FID(1)=WORD(MESSAGE(IP+16:IP+17))
STREAM(NSTREAM).FID(2)=WORD(MESSAGE(IP+18:IP+19))
STREAM(NSTREAM).FID(3)=WORD(MESSAGE(IP+20:IP+21))
DID(1)=WORD(MESSAGE(IP+22:IP+23))
DID(2)=WORD(MESSAGE(IP+24:IP+25))
DID(3)=WORD(MESSAGE(IP+26:IP+27))
C

[Hein van den Heuvel]

File ID's are often treated as 3 consecutive 16-bit words, even though that wrong. The code sample shown appears to attempt this. To print that data you want to do something similar to:

printf ("%s(%d,%d,%%)\n", device, did[1], did[2], did[2])


To do this properlyy you need to add the 1st 16 bits to 65536*times 8 bits from the 3rd word and display that as file ID.

See layout in the RMS NAMDEF.
Uage example for that:

i = atoi (argv[1]);
nam.nam$w_fid_num = (short) i;
nam.nam$b_fid_nmx = (unsigned char) (i >> 16);
nam.nam$w_fid_seq = (short) atoi ( argv[2] );
nam.nam$w_fid_rvn = (short) atoi ( argv[3] );


Enjoy,
Hein.

[GuentherF]

Rob,

I don't see how the listed code lines can return this:

FILE_IDENTIFICATION
â _$1$DGA151⠤⠤⠤⠤⠤ú#M⠤⠤d-⠤⠤

Do you?

Hint...show us the code that produced the lines above.

/Guenther

[Steven Schweda]

> The C code below [...]

Uh, comments which have a "C" in column one
are not usually described as "C code".

[John Gillings · Accepted solution]

This looks more like FORTRAN then C to me.

Maybe you could post an example with your formatting code? Put hardcoded values into the FID fields for illustration.

Here's an example in MACRO32 showing how to format a FID from a NAM block.

.TITLE FormatFid
.PSECT data,RD,WRT,NOEXE
$NAMDEF
MyNAM: $NAM

BinFid: .WORD 14426 ; FID (79962,17,0)
.WORD 17
.BYTE 0
.BYTE 1

outstr: .ASCID /12345678901234567890/
fmtstr: .ASCID /(!UL,!UW,!UB)/
.PSECT code,RD,NOWRT,EXE
.ENTRY start,^M

; first set up the NAM block with our canned FID
MOVC3 #NAM$S_FID,BinFid,MyNAM+NAM$R_FID_FIELDS

; Calculate NUM from FID_NUM and FID_NMX
MOVZBL MyNAM+NAM$B_FID_NMX,R2
ASHL #16,R2,R2
MOVW MyNAM+NAM$W_FID_NUM,R2

$FAO_S ctrstr=fmtstr outlen=outstr outbuf=outstr -
p1=R2 p2=MyNAM+NAM$W_FID_SEQ p3=MyNAM+NAM$B_FID_RVN

; display result
PUSHAB outstr
CALLS #1,G^LIB$PUT_OUTPUT
RET
.END start

[Steven Schweda]

> This looks more like FORTRAN then C to me.

But look at all those C's!

(You're no fun.)

[labadie_1]

Steven

Thanks for the good laugh !

[Robert Atkinson]

Sorry Guys - I'd got a mental block and purely assumed it was written in 'C'.

I've attached the original code, taken from http://vms.process.com/scripts/fileserv/fileserv.com?EXECSYMB

There's actually a section in the code which says :-

C
C Item conversion information
C
C Each item has an item name, the length of the name, and an item
C conversion type, used for converting the item value to ASCII for
C streams requiring ASCII-format item values. The following table
C lists the possible item types:
C type meaning
C ---- -------
C 1 No translation (already ASCII, or item not easily
C translated to ASCII, so left in original form)
C 2 Binary longword, converted to hexadecimal in the
C format "%Xnnnnnnnn"
C 3 Date and time, converted to dd-mmm-yyyy hh:mm:ss.cc
C format (with one space between date and time)
C 4 UIC, converted to [gggggg,mmmmmm] format with octal
C group and member numbers containing leading zeroes.
C 5 Bitstring, converted to a list of which bits are
C set. Up to 16 bytes of data can be included in the
C item (since the CHARACTERISTICS item is 16 bytes long.)
C The list is a series of decimal numbers separated by
C commas (e.g. hex 641 becomes "0,6,9,10")
C


Perhaps it's simply a case of defining FILEID as a type '5'? :-

DATA SMBITEM(SMBMSG$K_FILE_IDENTIFICATION) /'FILE_IDENTIFICATION'/
DATA SMBITEMLEN(SMBMSG$K_FILE_IDENTIFICATION) /19/
DATA SMBITEMTYPE(SMBMSG$K_FILE_IDENTIFICATION) /1/


Rob.

[Volker Halle]

Rob,

the item type of the file specification is probably defaulted to '1', because that binary data can not easily be converted to an ASCII string.

There is a LIB$FID_TO_NAME RTL routine, which could help in this regard. There is a C example of using this routine on the V8 freeware CD.

Volker.

[Volker Halle]

Rob,

you would need to improve the ITEMEDIT subroutine to accept a new item type (e.g. 6), which would represent the FILE_IDENTIFICATION binary string and then enhance that routine to convert this type of item to a readable ASCII string.

Volker.

[Robert Atkinson]

Unfortunately, I neither program in C++ or Fortran, which is really why I can to the list.

Nor do I have any compilers, so I'm completely reliant on offers from people to code and compile the changes.

Hunter Goatley has done some of the work on porting some of these utilities to IA64, but as this is a code change, I thought it better to seek out a willing programmer to help.

By the way - you can't imagine how frustrating it is to use these utilities, have the source code, but no be able to change them yourself!

Rob.

[Volker Halle]

Rob,

until someone picks up this 'enhancement request' and provides a solution, what do you try to do with this string ?

Could you read that string from DCL and parse it into the various fields ? Then call F$FID_TO_NAME ?

The FILE_IDENTIFICATION binary string seems to be in NAM$T_DVI format, i.e.

16 byte device name
6 byte FILE-ID
6 byte DIR-ID

See the $NAMDEF definition in SYS$LIBRARY:STARLET.REQ.

Volker.

[Hein van den Heuvel]

Well, Hunter Goatley occasuionally stops by here, so he might be able to advice. I think he checks comp.os.vms and EISNER:: more frequently, as do others, so you may want to cross-post there.

( http://forums11.itrc.hp.com/service/forums/publicProfile.do?userId=CA1182816&forumId=1 )

The bit representation would be tedious, but more importantly 3 bytes too short.
The first code suggests it is not tightly packed, so you would miss out on 3 critical bytes out of which you can only fake 1 (the rvn).

You may be better of TRYing to tret the umprintable as a bit string in DCL and hope is all glues together nicely.
Somthing LIKE...

$id=0
$seq=0
$rvn=0
$id[0,16] = f$cvui(16*8,16,record)
$id[16,8] = f$cvui(21*8,8,record)
$seq[0,16] = f$cvui(18*8,16,record)
$rvn[0,8] = f$cvui(20*8,8,record)
! I could well be off by one
! I could well have FID(3) swapped
! Some of this can be expressed as string bytes, but I believe bit strings is more clear.

Capture the 'garbage' for a known file in a file and $DUMP it. See if you can make the HEX bytes for the file line up with the HEX represenation for the FID:

$ fid = f$file("login.com","FID") - "(" - ")"
$ show sym fid
FID = "78215,881,0"
$ f_id = 'f$eleme(0,",",fid)
$ f_se = 'f$eleme(1,",",fid)
$ f_rv = 'f$eleme(2,",",fid)
$ show sym f_*
F_ID = 78215 Hex = 00013187 Octal = 00000230607
F_RV = 0 Hex = 00000000 Octal = 00000000000
F_SE = 881 Hex = 00000371 Octal = 00000001561

fwiw,
Hein

[Robert Atkinson]

Went with another solution instead of ExecSymb in the end.