need routine to parse combination time

[Jess Goodman]

Does anyone have a Fortran or C routine that will take as input a date-time string in combination time format, parse it itself, and return an absolute time?

I already know how to define a .CLD module with type=$DATETIME, pass the string to CLI$DCL_PARSE and call CLI$GET_VALUE, but unfortunately I have an application for which that approach is not an option.

[John Gillings · Accepted solution]

Jess,

NOTE THIS IS STRICTLY UNSUPPORTED!

I've attached a MACRO32 Module extracted from them OpenVMS sources which implements LIB$CVT_TIME. It's an internal routine used by DCL to parse combination times. I've replaced the names of the engineers in comments with "Engineer#n", to comply with privacy rules, but otherwise, it's directly from the V7.3-2 sources.

RENAME the .TXT file to .MAR and compile with:

$ MACRO CVTTIME

You'll get a few %AMAC-I messages which can be ignored (or fixed... left as an exercise ;-)

Pass it your combination time string, it will return the binary time, and optionally a string. See comments for full details.

(aside... learnt something new, the strings "LOGIN" and "BOOTTIME" may be used just like "YESTERDAY", "TODAY" and "TOMORROW" in combination times - not documented but seems to work back as far as V6.2)

[John Gillings]

Oops, forgot the attachment...

[Robert_Boyd]

Is there some good reason why this routine has never been made a callable LIB$ routine?

If it were already provided in the system runtime libraries -- wouldn't it be simpler just to set up a call to the lib$ routines to

1. turn the combination time into an absolute binary time, then
2. turn the binary time back into a string?

I mean ... why add the burden of having to maintain the macro code?

Robert

[Jan van den Ende]

just half a sentence to complete Robert:

... if it is already there, and has to be maintained, for the benefit of DCL?

Proost.

Have one on me.

jpe

[Jess Goodman]

John,

In my original post I asked for a C or Fortran routine - weren't you paying attention? No points for you! :)

Just kidding - THANK YOU VERY MUCH for this macro routine. I was hoping for a routine that worked pretty much the same as the CLI$ type=$DATETIME interface, but I expected that it would be impossible to match some of its more obscure "features". To get the actual VMS routine was far more than I could have hoped.

I do wonder about your "STRICTLY UNSUPPORTED" caveat. This seems to be a stand-alone module that only uses VMS system services and a RTL routine ($BINTIM, $ASCTIM, $GETTIM, $GETSYI, $GETJPI, LIB$SCOPY_DXDX) in the supported way.

Now just to be safe I have removed the weak reference to DCL$SCOPY_DXDX and stripped the LIB$ prefix from the names of the module's three entry points.

Therefore I would expect that these routines would continue to work the same way they do now under any future version of VMS. Am I missing something?

[Hein van den Heuvel]

>> I do wonder about your "STRICTLY UNSUPPORTED" caveat.

It is just a CYA clause. John, nor HP, will support that code, but full expect it to work and keep on working. But if it were to behave oddly, for example a poor reaction to a random input addres, then do not try to complain about that code. It will be just as if you written it, and you support it. No you may solicit HP's help, but it would not be under a support contract but under some time & material agreement.

>> This seems to be a stand-alone module that only uses VMS system services and a RTL routine ($BINTIM, $ASCTIM, $GETTIM, $GETSYI, $GETJPI, LIB$SCOPY_DXDX) in the supported way.

Right. So we expect it to work for ever.


>> Now just to be safe I have removed the weak reference to DCL$SCOPY_DXDX and stripped the LIB$ prefix from the names of the module's three entry points.

Excellent!

>> Therefore I would expect that these routines would continue to work the same way they do now under any future version of VMS.

Right

>> Am I missing something?

No, just a place to complain if the code does not always do exactly what you expect.


hth,
Hein.

[John Gillings]

Jess,

>Therefore I would expect that these routines would continue to work the same way they do now under any future version of VMS. Am I missing something?

Hein is right. The "STRICTLY UNSUPPORTED" is an "all care, no responsibility" thing. I can give you the code, but I can't make a committment to support it into the future.

There's no reason to expect it will stop working, BUT, if anyone changes, fixes or adds stuff to the DCL code, it will be your responsibility to keep it up to date.

That said, I've entered a suggestion that this routine be added to LIBRTL for general consumption (but no promises that it will be accepted).

[Robert Gezelter]

Jess,

For the record, I second John's suggestion that this routine be added to the official LIBRTL.

A suggestion on the LIBRTL and a possible relatively innocuous integration: LIB$TABLE_PARSE already has support for "subexpressions" the full date example is a good possible use of subexpressions (it would also provide a clean way to provide internationalization).

- Bob Gezelter, http://www.rlgsc.com

[Speers]

Jess, you'll need to upgrade to VMS 7.3 before you can do any of that stuff...

Bill