? F$DELTA_TIME returns a non-standard delta time format

[Robert_Boyd]

Does anybody know WHY F$DELTA_TIME returns a string which is not a valid OpenVMS delta time value? This means that if someone wants to use the return value for anything they have to massage it to get the "-" between the day and time portions of the value. It would be much simpler to have the lexical stuff the connector in to begin with.

In general -- I would like to think that system routines that operate on time values will always return a valid time construct whether absolute or delta.

Robert

[Robert_Boyd]

And ... another thing ... why is it that on V8.2 the HELP for the DCL WAIT command still doesn't mention that

$ WAIT

is also a valid command? It has worked as far back as I can remember ... and still works.

Is this an oversight? or a deliberate act of avoidance?

Robert

[Dale A. Marcy]

It will work if you enclose it in quotes with a + i.e.,

$ submit/after="+''f$delta_time(start,end)'" ...

start and end would be symbols containing the appropriate start and end times. I know the quotes are hard to distinguish sometimes in this forum, so I will repeat the above line below adding spaces between each type of quote above:

$ submit/after= " + ' ' f$delta_time(start,end) ' " ...

[Robert_Boyd]

Hmmmm ... that's an interesting proposition but I beg to differ ... for example:


$ say = "write sys$output"
$ say -
f$cvtime("+"+f$delta_time(f$cvtime("YESTERDAY","ABSOLUTE"),f$cvtime("TODAY","ABSOLUTE")))
%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC format
\+ 1 00:00:00.00\

[Robert_Boyd]

I can't get the submit example to work either:

$ xa = f$cvtime("YESTERDAY","ABSOLUTE")
$ xb = f$cvtime("TODAY","ABSOLUTE")
$ submit/after="+''f$delta_time(xa,xb)'" login.com
%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC format
\+ 1 00:00:00.00\

[Dale A. Marcy]

Sorry, you are correct. In my testing, I did not make my delta time larger than a day and it worked fine in that case. Which is interesting, because I would have thought the 0 in the day position would have caused the same error.

[John Gillings · Accepted solution]

Robert,

Excellent point. F$DELTA_TIME is returning a "standard" delta time as returned by SYS$ASCTIM. It's implemented as

$BINTIM P1 => Time1
$BINTIM P2 => Time2
LIB$SUB_TIMES Delta,Time1,Time2
$ASCTIM Delta => Output String

The trouble here is that DCL has extended the standard time string formats, and requires delta times to have a hyphen between the days and time fields.

It seems reasonable that it should return a delta time in DCL delta time format, rather than $ASCTIM format, and maybe trim off any leading white space at the same time. I'll send a suggestion to the engineer responsible.

(since F$DELTA time is new, hopefully not too many people have written code dependent on the output format, otherwise we might need to add a flag "DCL" to request a DCL format string)

[Guy Peleg]

Hi Robert,

Thank you for bringing this to our attention.

I have exchanged mail with John Gillings
based on his feedback I'll modify F$DELTA_TIME
to accept an optinal format argument

F$DELTA_TIME(start-time,end-time [,format])

format = "DCL" or "ASCTIM" (default)

This will show up in a future DCL kit for
V8.2 and V7.3-2 and will be incorporated
into the next VMS version.

Regards,

Guy Peleg
OpenVMS Engineering

[Jan van den Ende]

Robert,

Grab your chance!!

Give Guy (at least) 4 points, and see hime get his (WELL deserved) hat!

Proost.

Have one on me.

jpe

[Jan van den Ende]

Guy,

this thread set me thinking.

At this moment, F$DELTA is returning a time syntax, and you just promised to add a format specifier for ASCTIM or DCL format.

Would it be asking very much extra to add (more or less like F$CVTIM) the format specifiers SECONDS, MINUTES, HOURS, DAYS (WEEKS?, MONTHS?, YEARS?) as rounded-down integer values? I know for sure that at least _WE_ have regular use for them!
I know that this would be fairly easy to do in DCL, but it DOES require a number of string manipulations and arithmatic, and I have for a long time already been pleased with those formats from f$cvtime.

TIA

Proost.

Have one on me.

jpe

[Robert Atkinson]

Robert - can you clarify your statement about the WAIT command. I'm trying it here, but can't get an absolute time to work!

ALPHA_ROB$$$ tim
18-MAY-2005 10:06:44
ALPHA_ROB$$$ wait 18-may-2005:10:08:00
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\0 18-MAY-2005:10:08:00\
ALPHA_ROB$$$ wait "18-may-2005 10:08:00"
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\0 "18-may-2005 10:08:00"\
ALPHA_ROB$$$ wait "18-may-2005:10:08:00"
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\0 "18-may-2005:10:08:00"\
ALPHA_ROB$$$

Rob.

[Ian Miller.]

the WAIT dcl command only works with delta time. From the V7.1 help

WAIT

Places a process into a wait state for the specified amount of time. The WAIT command is used in a command procedure to delay processing of either the procedure itself or a set of commands in the procedure.

Format

WAIT delta-time

[Ian Miller.]

The V8.2 help on the WAIT command is the same. Did this used to work? If so parhaps it was not supposed to.

[Robert_Boyd]

The format of the WAIT command that accepts an absolute time is:

$ wait 19-May-2005 00:00:00.00

(for all of the Star Wars fans)
This format has worked for as far back as I can remember.

And ... it's never been documented as far as I can recall, although I've had discussions with various people about it before.

Robert

[Robert_Boyd]

John and Guy,

Thanks for your replies! And have some points on me :-) I didn't expect such quick response. A very nice surprise.

I like the suggestions for the alternative format output from the function.

As you can imagine -- some of us HAVE already written code that has to deal with the ASCTIM format of the result already being supplied. Still, it won't be too much effort to switch over with a DCL format alternative.

I'll look forward to the patch kit with great anticipation!

Robert

[Guy Peleg]

Robert,

If you have a valid support contract, you
may log a service call at your local support
center and ask that your problem will
be elevated to engineering. This will allow
you access to the new DCL image as soon
as it will become available (instead of
waiting for the next kit which could be
several months in the future).

Guy

[Ian Miller.]

Guy, that's a very stylish hat you have one and I hope to see you wear it in Nashua :-)

Robert B. - I've just tried the WAIT command on various versions of VMS and it worked as you said on every one.

For any hp person - I guess this needs a documentation PTR raising so it will get fixed one day.

[Guy Peleg]

Hi Robert,

Problem fixed !

Using the new DCL optional keyword, your
original example now works:

VMS2_SYS> say f$cvtime("+"+f$delta_time(f$cvtime("YESTERDAY","ABSOLUTE"),f$cvtime("TODAY","ABSOLUTE"),"dcl"))
2005-05-20 04:21:31.63

Guy

[Robert_Boyd]

Guy,

That's fantastic! Thanks for the update -- I submitted a ticket to the support center -- so I'll keep an eye out for your update.

Robert

[John Gillings]

re: Jan,

>Would it be asking very much extra to
>add (more or less like F$CVTIM) the
>format specifiers SECONDS, MINUTES,
>HOURS, DAYS (WEEKS?, MONTHS?, YEARS?)
>as rounded-down integer values?

Another good suggestion. You can already parse out fields from delta times using F$CVTIME:

$ hour=F$CVTIME(F$DELTA(t1,t2,"DCL"),"DELTA","HOUR")

but that just gives you the hour field, not the number of hours represented by the delta time.

I'd say the place to put those calculations HOURS, MINUTES etc... would be in F$CVTIME, rather than in F$DELTA.

I'll send another message to Guy ;-)

[Robert_Boyd]

Guy and/or John,

I'm curious if this F$DELTA_TIME format selection capability is in any of the official released patch kits for V7.3-2?

I installed the test kit it on one system right after you did the work on it, but it appears that subsequent officially released patch kits have overwritten it on my system.

Robert

[John Gillings]

Robert,

Releasing a patch is an expensive and time consuming process. It's generally only done for a priority 1 or 2 case elevated through formal channels by a contract customer.

This delta time change has been entered into remedial streams for both V7.3-2 and V8.2. If there is a patch released which happens to include the image(s) containing the fix, then the new F$DELTA_TIME will piggy back out into the open. Note that just because a DCL patch has been released since the discussion started, doesn't mean it was commenced after the checkin. See the release notes to confirm F$DELTA is in the patch.

So, if you need this fix formally released, you need to log a case against a contract. That an informal request in ITRC resulted in an operating system change so quickly is unusual. Please DO NOT expect this as the norm in future. HP is not a charity! Priority is given to contract (ie: paying) customers.

[Robert_Boyd]

Thanks for the explanation of the process. I'm not in a hurry about it -- I was just faced with alternate ways of coding a new DCL procedure and the F$DELTA_TIME output format factored into the process.

I've been working with VMS since 1981 -- and I know it usually takes quite a while to get changes through the whole cycle. I was quite surprised with what happened on this idea.

I'll keep an eye out for references to F$DELTA_TIME in the release notes.

Thanks,

Robert

[Guy Peleg]

Hi Robert,

We are in the process of releasing a new
ECO for DCL. The name of the kit will be
VMS732_DCL-V0400 and it expected to hit
the streets within 3-4 weeks.

The new kit will containt the F$DELTA_TIME
fix.

Guy

[John Gillings]

VMS732_DCL-V0400 has been released. It contains the F$DELTA_TIME modification and an increase in the maximum number of SPAWNed subprocesses.