New lexical function F$DELTA_TIME
Guy Peleg
I thought you might be interested to know that with the next Alpha VMS
version V7.3-2, we will ship a new
lexical function F$DELTA_TIME.
F$DELTA returns the difference between a beginning and end time. The
first argument is an absolute time,
the second argument can be absolute or delta time. See the following
example.
BLUSKY> start=f$time()
BLUSKY> end=f$time()
BLUSKY> sh sym start
START = "10-JUL-2003 17:38:06.82"
BLUSKY> sh sym end
END = "10-JUL-2003 17:38:30.64"
BLUSKY> write sys$output f$delta(start,end)
0 00:00:23.82
No it won't be backported to VAX 5.5-2 .
As usual, your comments are welcome.
Guy Peleg,
OpenVMS Engineering
Keith A. Lewis
>I thought you might be interested to know that with the next Alpha VMS
>version V7.3-2, we will ship a new
>lexical function F$DELTA_TIME.
>
>F$DELTA returns the difference between a beginning and end time. The
>first argument is an absolute time,
>the second argument can be absolute or delta time. See the following
>example.
>
>BLUSKY> start=f$time()
>BLUSKY> end=f$time()
>BLUSKY> sh sym start
> START = "10-JUL-2003 17:38:06.82"
>BLUSKY> sh sym end
> END = "10-JUL-2003 17:38:30.64"
>BLUSKY> write sys$output f$delta(start,end)
> 0 00:00:23.82
That's a useful addition, Guy.
But there's still one thing missing from DCL date/time lexicals (or maybe
just from my knowledge of them). Suppose I want to add or subtract a delta
time from an absolute time. With a delta of up to 23:59:59.99 I can use
f$cvtime("''base_time'+''delta_time'","ABSOLUTE")
f$cvtime("''base_time'-''delta_time'","ABSOLUTE")
But this only works for delta_time < 24 hours. In system services it's
easy to add and subtract times up to 9999 days. Can it be done in DCL?
--Keith Lewis klewis$mitre.org
The above may not (yet) represent the opinions of my employer.
Dave Greenwood
> Hello DCL gurus,
>
> I thought you might be interested to know that with the next Alpha VMS
> version V7.3-2, we will ship a new
> lexical function F$DELTA_TIME.
>
> F$DELTA returns the difference between a beginning and end time. The
> first argument is an absolute time,
> the second argument can be absolute or delta time. See the following
> example.
>
> BLUSKY> start=f$time()
> BLUSKY> end=f$time()
> BLUSKY> sh sym start
> START = "10-JUL-2003 17:38:06.82"
> BLUSKY> sh sym end
> END = "10-JUL-2003 17:38:30.64"
> BLUSKY> write sys$output f$delta(start,end)
> 0 00:00:23.82
I like it. Presumably the difference between the arguments is limited
to 9999 days? Do you get an absolute time result if the second argument
is a delta time?
> No it won't be backported to VAX 5.5-2 .
Awwwww. ;)
Dave
--------------
Dave Greenwood Email: Green...@ORNL.GOV
Oak Ridge National Lab %STD-W-DISCLAIMER, I only speak for myself
VAXman-
>Hello DCL gurus,
>{...snip...}
Guy, do you have an email address outside of hp.com?
I'd like to ask you a few questions and make a request concerning DCL.
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
David Webb
You mean like :-
Alpha2:sh time
10-JUL-2003 16:41:59
Alpha2:a = f$cvtime("''f$time()' +6-4:0:0.0","ABSOLUTE")
Alpha2:sh sym a
A = "16-JUL-2003 20:42:05.84"
and
Alpha2:sh time
10-JUL-2003 16:44:03
Alpha2:a = f$cvtime("''f$time()' -5-4:0:0.0","ABSOLUTE")
Alpha2:sh sym a
A = "5-JUL-2003 12:44:06.66"
Note there cannot be any space between the + (or minus) and the number of days
else you get
Alpha2:a = f$cvtime("''f$time()' + 6-4:0:0.0","ABSOLUTE")
%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC format
\10-JUL-2003 16:46:11.98 + 6-4:0:0.0\
David Webb
VMS and Unix team leader
CCSS
Middlesex University
David Jones
What I'd like is for f$parse("$3$dka100:[foo]bar.dat",,,"NAME+TYPE") to return
"bar.dat".
David L. Jones | Phone: (614) 292-6929
Ohio State University | Internet:
140 W. 19th St. Rm. 231a | jon...@er6s1.eng.ohio-state.edu
Columbus, OH 43210 | vm...@osu.edu
Disclaimer: I'm looking for marbles all day long.
Guy Peleg
guy....@hp.com, guy....@digital.com and guy....@compaq.com
pe...@star.zko.dec.com
What's wrong with HP mail?
Jim Strehlow
... with the next Alpha VMS version V7.3-2, we will ship a new
lexical function F$DELTA_TIME ...
Having optional parameters for
(..., "day"|"hour"|"minute"|"second", variableName )
would be "nice" to save us from parsing the result string;
but we can parse if we have to do so.
It would save us from writing an extra couple of lines of code (our own subroutine).
Jim, Data911, Alameda, CA, USA
Guy Peleg
I'll give it some thoughts and will get back to you offline.
Guy
VAXman-
>The only one I have are
>guy....@hp.com, guy....@digital.com and guy....@compaq.com
>pe...@star.zko.dec.com
>
>What's wrong with HP mail?
I can't get them to fix it so I can send email to any HP.COM recipient.
See the thread that existed here about 2 months ago.
I host several virtual domains. When I send email to HP.COM, HP sees my
MAIL.TMESIS.COM in the header but reverse translates the IP address to a
virtual domain I host (incorrectly, I might add) and rejects my emails.
Guy Peleg
The next DCL eco for V7.3-1 will include few new pool related item codes for F$GETSYI:
The following item codes have been added to F$GETSYI:
NPAGED_TOTAL, NPAGED_FREE, NPAGED_INUSE, NPAGED_LARGEST, PAGED_TOTAL,
PAGED_FREE, PAGED_INUSE,
PAGED_LARGEST.
$ sh mem/pool
System Memory Resources on 6-JUL-2003 10:30:40.70
Dynamic Memory Usage: Total Free In Use Largest
Nonpaged Dynamic Memory (MB) 9.53 3.98 5.54 3.68
Bus Addressable Memory (KB) 128.00 110.87 17.12 104.00
Paged Dynamic Memory (MB) 4.76 3.04 1.72 3.03
Lock Manager Dyn Memory (MB) 1.77 0.00 1.77
$ write sys$output f$getsyi("npaged_total")
9994240
$ write sys$output f$getsyi("npaged_free")
4183680
Guy Peleg
Michael Unger
First comment: great; it makes it much easier to calculate run times of
batch jobs or similar.
The second comment is a question: What about Daylight Savings Time?
Suppose the first argument is "standard time" and the second one
"daylight savings time" or vice versa.
"system uptime" ("SHOW SYSTEM") is always displayed correctly, but the
difference of the startup time and the current time may be incorrect by
one hour.
Michael
--
Please do *not* send "Security Patch Notifications" or "Security
Updates"; this system isn't running a Micro$oft operating system.
And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)
Guy Peleg
ticks since boot that's why it is not affected by time change.
F$DELTA does not support daylight saving. I try to think what we can do (if
there is something other than just document it.....)
Guy
David J. Dachtera
>
> Speaking of lexicals...
>
> What I'd like is for f$parse("$3$dka100:[foo]bar.dat",,,"NAME+TYPE") to return
> "bar.dat".
f$parse("$3$dka100:[foo]bar.dat",,,"NAME,TYPE") would at least be
consistent with F$EDIT().
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
David J. Dachtera
Just tried these for fun...
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )
0 001:23:45.67
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "day" )
0
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "hour" )
001
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "minute" )
23
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "second" )
45
DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "hundredth" )
67
Seems to me that
$ SAY F$CVTI( F$DELTA( START, END ), "DELTA", field )
...should work just fine. Well, except that the hour field gets
zero-padded to three digits...
Peter 'EPLAN' LANGSTOEGER
>I thought you might be interested to know that with the next Alpha VMS
>version V7.3-2, we will ship a new
>lexical function F$DELTA_TIME.
Good. I can think of one or two uses for it.
While we are on time and lexical functions: Can we also have a F$CVTIME
improvement to convert COMPARISON/ISO timeformat to ABSOLUTE/VMS timeformat ?
Converting only from ABSOLUTE (and DELTA) time is sometimes not enough...
Thanks
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
David Jones
>f$parse("$3$dka100:[foo]bar.dat",,,"NAME,TYPE") would at least be
>consistent with F$EDIT().
I chose "NAME+TYPE" because I think of it as a string concatenation (although
I'd expect "TYPE+NAME" to still produce "bar.dat" rather than ".datbar" the
same result).
John Santos
> Jim Strehlow wrote:
> >
> > Guy Peleg <guy....@hp.com> wrote in message news:<3F0D7BFC...@hp.com>...
> > ... with the next Alpha VMS version V7.3-2, we will ship a new
> > lexical function F$DELTA_TIME ...
> >
> > Having optional parameters for
> > (..., "day"|"hour"|"minute"|"second", variableName )
> > would be "nice" to save us from parsing the result string;
> > but we can parse if we have to do so.
> >
> > It would save us from writing an extra couple of lines of code (our own subroutine).
>
> Just tried these for fun...
>
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )
> 0 001:23:45.67
$ write sys$output f$cvtime( "2 01:23:45.67", "delta" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\2 01:23:45.67\
So trying DDDD-HH:...
$ write sys$output f$cvtime( "2-01:23:45.67", "delta" )
2 01:23:45.67
and for zero days,
$ write sys$output f$cvtime( "0-01:23:45.67", "delta" )
0 01:23:45.67
So now there are only 2 digits of hour, not 3.
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "day" )
> 0
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "hour" )
> 001
$ write sys$output f$cvtime( "0-01:23:45.67", "delta", "hour" )
01
$ write sys$output f$cvtime( "2 01:23:45.67", "delta", "hour" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\2 01:23:45.67\
$ write sys$output f$cvtime( "2-01:23:45.67", "delta", "hour" )
01
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "minute" )
> 23
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "second" )
> 45
> DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta", "hundredth" )
> 67
>
> Seems to me that
>
> $ SAY F$CVTI( F$DELTA( START, END ), "DELTA", field )
>
> ...should work just fine. Well, except that the hour field gets
> zero-padded to three digits...
Maybe not... I don't recall if F$DELTA puts the "-" between the
days and hours in its output. (If I go back and look, I'll lose
this followup and would have to re-create it. Bad Pine!)
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
s...@antinode.org
> In message <3F0E05F8...@fsi.net>, David J. Dachtera writes:
> >f$parse("$3$dka100:[foo]bar.dat",,,"NAME,TYPE") would at least be
> >consistent with F$EDIT().
> I chose "NAME+TYPE" because I think of it as a string concatenation (although
> I'd expect "TYPE+NAME" to still produce "bar.dat" rather than ".datbar" the
same result).
Is there ever a reason to want anything other than an unbroken
sub-string? Would a first_element, last_element argument pair do the
job? (One item gives you that element, two items give you all the
elements from the first through the second, perhaps with an error if
they make no sense that way.)
Without thinking very hard, I can't see a reason for NODE::.TYPE, or
anything else with a hole in the middle. I always seem to want NAME,
TYPE.
I'd tend to vote for whatever's easier to implement, unless it was
particularly ugly.
------------------------------------------------------------------------
Steven M. Schweda (+1) 651-699-9818
382 South Warwick Street s...@antinode.org
Saint Paul MN 55105-2547
Dirk Munk
However there is anothere feature I would like to see in the time lexicals, and
that is a way to do some kind of timezone calculation.
Perhaps it is possible to extend f$time, since it only has a empty argument.
Something like f$time("UTC") that will give me the UTC system time. Since my
system is running in the MET DST zone, that would be 2 hours less then the the
normal system time.
$ write sys$output f$time()
11-JUL-2003 08:30:36.52
$ write sys$output f$time("UTC")
11-JUL-2003 06:30:36.52
The basic rules for these calculations are already hidden somewhere in VMS..
Regards,
Dirk
Bob Koehler
>
> I thought you might be interested to know that with the next Alpha VMS
> version V7.3-2, we will ship a new
> lexical function F$DELTA_TIME.
>
I expect 7.3-2 is Alpha only. Is there a time frame for a 7.4 for
VAXen to expect this to show up in?
8.1 or 8.2 for IA64?
Bob Koehler
>
> ...should work just fine. Well, except that the hour field gets
> zero-padded to three digits...
Must be a bug. We only have those really long days when someone
makes us use Windows.
Bob Koehler
> Without thinking very hard, I can't see a reason for NODE::.TYPE, or
> anything else with a hole in the middle. I always seem to want NAME,
> TYPE.
I can, and any real improvements VMS style would not assume we can't.
Michael Unger
> In article <3F0D7BFC...@hp.com>, Guy Peleg <guy....@hp.com> writes:
>>I thought you might be interested to know that with the next Alpha VMS
>>version V7.3-2, we will ship a new
>>lexical function F$DELTA_TIME.
>
> Good. I can think of one or two uses for it.
>
> While we are on time and lexical functions: Can we also have a F$CVTIME
> improvement to convert COMPARISON/ISO timeformat to ABSOLUTE/VMS timeformat ?
> Converting only from ABSOLUTE (and DELTA) time is sometimes not enough...
Agreed!
Guy Peleg
Keith A. Lewis
>Alpha2:a = f$cvtime("''f$time()' +6-4:0:0.0","ABSOLUTE")
Hahaha, that must be the one syntax I didn't try. Looks like DCL already
does what I requested. Thanks for the info, David, and thanks again for the
new feature, Guy!
David J. Dachtera
>
> On Thu, 10 Jul 2003, David J. Dachtera wrote:
>
> > Jim Strehlow wrote:
> > >
> > > Guy Peleg <guy....@hp.com> wrote in message news:<3F0D7BFC...@hp.com>...
> > > ... with the next Alpha VMS version V7.3-2, we will ship a new
> > > lexical function F$DELTA_TIME ...
> > >
> > > Having optional parameters for
> > > (..., "day"|"hour"|"minute"|"second", variableName )
> > > would be "nice" to save us from parsing the result string;
> > > but we can parse if we have to do so.
> > >
> > > It would save us from writing an extra couple of lines of code (our own subroutine).
> >
> > Just tried these for fun...
> >
> > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )
> > 0 001:23:45.67
>
> $ write sys$output f$cvtime( "2 01:23:45.67", "delta" )
> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
> \2 01:23:45.67\
Hhmmm...
DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\1 23:45:67.89\
Well! Looks like we found a bug in F$CVTIME()!
V7.2-2, BTW. What's yours?
David J. Dachtera
Guess that'll have to be three statements minimum:
$ DELTA_TIME = F$DELTA( START, END )
$ DLTA = F$FAO( "!AS-!AS", F$ELEM( 0, " ", DELTA_TIME ), -
F$ELEM( 1, " ", DELTA_TIME ) )
$ SAY F$CVTIME( DLTA, "DELTA", field )
John Santos
> John Santos wrote:
> >
> > On Thu, 10 Jul 2003, David J. Dachtera wrote:
> >
> > > Jim Strehlow wrote:
> > > >
> > > > Guy Peleg <guy....@hp.com> wrote in message news:<3F0D7BFC...@hp.com>...
> > > > ... with the next Alpha VMS version V7.3-2, we will ship a new
> > > > lexical function F$DELTA_TIME ...
> > > >
> > > > Having optional parameters for
> > > > (..., "day"|"hour"|"minute"|"second", variableName )
> > > > would be "nice" to save us from parsing the result string;
> > > > but we can parse if we have to do so.
> > > >
> > > > It would save us from writing an extra couple of lines of code (our own subroutine).
> > >
> > > Just tried these for fun...
> > >
> > > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )
> > > 0 001:23:45.67
> >
> > $ write sys$output f$cvtime( "2 01:23:45.67", "delta" )
> > %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
> > \2 01:23:45.67\
>
> Hhmmm...
>
> DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" )
> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
> \1 23:45:67.89\
>
> Well! Looks like we found a bug in F$CVTIME()!
>
> V7.2-2, BTW. What's yours?
Same on all systems I tried: Alpha V7.2-1, V7.3, V7.3-1, VAX V7.1, V7.3.
It wants a dash on input, but produces a space on output. So you
can't feed the output back into f$cvtime again.
Carl Perkins
On 7.2-1, you see this interesting thing:
$ write sys$output f$cvtime( "01:23:45.67", "delta" )
0 01:23:45.67
$ write sys$output f$cvtime( "001:23:45.67", "delta" )
0 001:23:45.67
$ write sys$output f$cvtime( "0001:23:45.67", "delta" )
0 0001:23:45.67
The formatting of the output fields matches the number of digits
in the input fields. It isn't just the hour field either:
$ write sys$output f$cvtime( "0001:023:0045.67", "delta" )
0 0001:023:0045.67
You are allowed to have a space in the hour filed if the first digit
is a 0, but not anything else:
$ write sys$output f$cvtime( "0 001:023:0045.67", "delta" )
0 0001:023:0045.67
$ write sys$output f$cvtime( "1 001:023:0045.67", "delta" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\1 001:023:0045.67\
$ write sys$output f$cvtime( "1-001:023:0045.67", "delta" )
1 001:023:0045.67
And finally:
$ write sys$output f$cvtime( "0001-0001:00023:00045.67", "delta" )
0001 0001:00023:00045.67
You can add one more digit before it gives an IVDTIME error (I expect
it is from exceeding the maximum allowed string length for the input).
How strange is that?
--- Carl
Carl Perkins
Following up my own post, since I made a mistake.
Above I said "You are allowed to have a space in the hour filed if the first
digit is a 0, but not anything else" but that is not correct.
You can have a space in the hour field, as long as removing the space
makes it a valid hour:
$ write sys$output f$cvtime( "1 1:023:0045.67", "delta" )
0 11:023:0045.67
$ write sys$output f$cvtime( "2 1:023:0045.67", "delta" )
0 21:023:0045.67
$ write sys$output f$cvtime( "3 1:023:0045.67", "delta" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\3 1:023:0045.67\
This failed because there are not 31 hours in the day. In the various
examples with non-zero first dgits from other people up above they
attempted 3 digit hours (with a space before the last two), which
is why they didn't work.
$ write sys$output f$cvtime( "0002 1:023:0045.67", "delta" )
0 00021:023:0045.67
The space is not a separator for the day, it is a space in the hour field.
For that matter, you can have spaces in any field:
$ write sys$output f$cvtime( "0002 1:0 23:00 45. 67", "delta" )
0 00021:023:0045.67
However any space between a number and the following colon become a zero:
$ write sys$output f$cvtime( "1 :01:45.67", "delta" )
0 10:01:45.67
$ write sys$output f$cvtime( "1 :01 :45.67", "delta" )
0 10:010:45.67
Likewise for a number and a following decimal point:
$ write sys$output f$cvtime( "1 :01 :5 .67", "delta" )
0 10:010:50.67
You should note that in a combination time you can't have a space
after the "+", but other than that one case spaces (and extraneous
leading zeros) in the delta portion don't seem to matter except
that spaces between the number and the following colon are treated
as zeros.
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3: 45.67","absolute")
2-JAN-2222 10:23:45.67
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3 : 45.67","absolute")
%DCL-W-IVATIME, invalid absolute time
\01-JAN-2222 +1-01 : 2 3 : 45.67\
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 : 45.67","absolute")
2-JAN-2222 10:20:45.67
Leading zeros in the numeric parts of an absolute time don't matter either:
$ write sys$output f$cvtime( "001-JAN-002222")
2222-01-01 00:00:00.00
$ write sys$output f$cvtime( "001-JAN-002222","ABSOLUTE")
1-JAN-2222 00:00:00.00
So it may be even stranger than it looked before, but it is strange in
a very orderly way. A space after the "+" in a combination time is invaid.
Spaces between a number and a following punctuation mark (colon or decimal
point) are converted to zeros. All other spaces are removed. The number
of digits remaining is the number of digits that will appear in the output
and this can be influenced by adding leading zeros to increase the size
of the field, or traling zeros in the hundredths of a second part.
$ write sys$output f$cvtime( "1:1:5.7", "delta" )
0 1:1:5.7
$ write sys$output f$cvtime( "001 : 1 : 005.700", "delta" )
0 0010:10:005.700
--- Carl
Michael Unger
> Hello DCL gurus,
>
> I thought you might be interested to know that with the next Alpha VMS
> version V7.3-2, we will ship a new
> lexical function F$DELTA_TIME.
>
> F$DELTA returns the difference between a beginning and end time. The
> first argument is an absolute time,
> the second argument can be absolute or delta time. See the following
> example.
>
> BLUSKY> start=f$time()
> BLUSKY> end=f$time()
> BLUSKY> sh sym start
> START = "10-JUL-2003 17:38:06.82"
> BLUSKY> sh sym end
> END = "10-JUL-2003 17:38:30.64"
> BLUSKY> write sys$output f$delta(start,end)
> 0 00:00:23.82
>
> No it won't be backported to VAX 5.5-2 .
>
> As usual, your comments are welcome.
Another question: are leap years taken into account? (Well, Y2k was a
special case, the next one will be 2400; VMS 43.2 perhaps ... :-)
David J. Dachtera
>
> Following up my own post, since I made a mistake.
>
> Above I said "You are allowed to have a space in the hour filed if the first
> digit is a 0, but not anything else" but that is not correct.
>
> You can have a space in the hour field, as long as removing the space
> makes it a valid hour:
>
> $ write sys$output f$cvtime( "1 1:023:0045.67", "delta" )
> 0 11:023:0045.67
WHOA!!! THAT looks like a major bug to me!
> $ write sys$output f$cvtime( "2 1:023:0045.67", "delta" )
> 0 21:023:0045.67
>
> $ write sys$output f$cvtime( "3 1:023:0045.67", "delta" )
> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
> \3 1:023:0045.67\
>
> This failed because there are not 31 hours in the day. In the various
> examples with non-zero first dgits from other people up above they
> attempted 3 digit hours (with a space before the last two), which
> is why they didn't work. [snip]
Brian Tillman
>version V7.3-2, we will ship a new
>lexical function F$DELTA_TIME.
>No it won't be backported to VAX 5.5-2 .
But will it be in OpenVMS VAX V7.x or V8.x?
--
Brian Tillman Internet: Brian.Tillman at smiths-aerospace dot com
Smiths Aerospace Addresses modified to prevent SPAM.
3290 Patterson Ave. SE, MS 1B3 Replace "at" with "@", "dot" with "."
Grand Rapids, MI 49512-1991
This opinion doesn't represent that of my company