File size of Open File..

[R. Verkerk]

hello,

I am using the f$file_attributes to find the file size of an open file using f$file_attributes. This fails.

a = F$FILE_ATTRIBUTES("SMSC_DAT1:[SMH00]smh00_own_file.dat", "eof")
%SYSTEM-W-ACCONFLICT, file access conflict
\SMSC_DAT1:[SMH00]smh00_own_file.dat\

This file is opened in a global section.
$ install list/global
Group Global Sections

SMH00_OWN_FILE.DAT
(00000000) WRT DZRO TMP GRP =000100 Pgltcnt/Refcnt=360944/22559


If I do it for a normal file it works..

Is there a way around it. Or an other way

gr,

Robert Verkerk

[Hein van den Heuvel]

No, sorry, not with straight DCL.
F$FILE always use RMS SYS$OPEN to have it load details into FAB's and XAB's.
For the open to succeed, the sharing conditions must be correct.

DIR/FULL on the other hand oly uses RMS for remote (DECNET) files. For local files is uses a QIO to get the Attributes.

So you can either parse DIR/FULL output, or write a (not to hard!) program to do that QIO yourself and return the data in any way you like (dcl symbols probably).

IMHO F$FILE should use QIO and blow through sharing... it is not about to share data it only want meta data! And/or RMS should get a 'Display Only' option. Like a SYS$DISPLAY call without a prior open, or an other flag.
RMS also needs the ability to use the SYSLCK option to be able to code up IGNORE=INTERLOCK like BACKUP.

Met vriendelijke groetjes,
Hein van den Heuvel

[R. Verkerk]

Thanks,

Than we will just use some very crude commands:

$ PIPE DIRECTORY -
SMSC_DAT1:[SMH00]smh00_own_file.dat -
/SIZE /GRAND_TOTAL | -
SEARCH SYS$INPUT "Grand total" /NUM /NOHIGHLIGHT | -
(READ SYS$INPUT TMPI ; -
TMPI = F$ELEMENT(12," ",TMPI) ; -
DEFINE/JOB/NOLOG TMP_RESULT &TMPI -
)

$ sho log TMP_RESULT

gr,

Robert

[Heinz W Genhart]

Hi Robert

be carefull!
In case you have more than one version of your file, you will get the total size of all versions of this file.

You may change the Directory Command to

DIRECTORY -
SMSC_DAT1:[SMH00]smh00_own_file.dat; -
/SIZE/GRAND
(file.ext; or file.ext;0)

Regards

Heinz

[Hein van den Heuvel]

Hmmm,


Why not use:

dir/size=allo/nohead/notrai/wid=file=200 xxx

The you do not need the SEARH.
Just pick up element 2 from a compressed string with space seperator

Oh... be sure to ask for the last version only.

$ PIPE DIRECTORY /size=allo/nohead/notrai/wid=file=100 X.X. | (READ SYS$INPUT X ; X=F$ELE(1," ",F$EDI(X,"COMPRESS")) ; DEF/JO XX &X)


Hein.

[Hoff]

The file looks to be 360,944 pages in size.

Another (massively brute force, unsupported, subject to change without notice) approach would involve capturing and parsing the output of INSTALL.

What might you be up to here?

[R. Verkerk]

Hello,

Thanks for the reply's. The task at hand is as follows. We know this particular file can be very big. We want to know before we make a backup if the file will fit on a specific volume. But we want to know the size before the backup. While the file is still live, The file does not grow. Once it is created it has a fixed format.

That's why we try to do this.

gr,

Robert Verkerk.

[Wim Van den Wyngaert · Accepted solution]

I would do a
$ dir /select=size=min=1000000 file.ext;/size=all
$ if $status .eq. %x00000001 then say "to big"

Wim

[Hein van den Heuvel]

Yeah, For a specific, single file copy you could do like Wim suggests. Take the space available (F$GETDVI), subtract some fudge factor (at least 2 clusters: EOF rounding, DIRectory expansion, INDEXF.SYS expansion being very unlikely) and let DIRECTORY do the compare.

Hein.

[Hoff]

There are second-level factors here, such as the efficiency of the tape compression -- the answer to this simple "will it fit?" question can become quite intriguing. Other factors include the capacity of the media -- and upgrades aside, BACKUP is quite willing to span tape volumes. (This question ended up in the OpenVMS FAQ, just because it looks so easy, and can become so, um, intriguing.)

Or consider compression. There are various tools that can compress data, including BACKUP and its latent compression. Most section files I've encountered would compress very nicely.

Or you can exclude this file from the operation, and potentially create a tool which maps to the section and extracts its data into a file that BACKUP can then process.