Hi Family.

I'm having enough frustration getting cross-system restore to work. But this is SO frustrating:

With my entire environment set up by a script that has been working for years, I made the modification:

/usr/informix/bin/onbar_d -r -p -w -t "2023-11-30 05:00:00"

And it's immediate response is:

4024  4022 Invalid Point In Time value specified: .

...

4024  4022 /usr/informix/bin/onbar_d complete, returning 149 (0x95)

This is INSANE! (Anyone remember the Crazy Eddie ads? :-)  I am being stopped by an unreasonable bouncer right at the door!  And, BTW, the same response if I use single quotes.  Our time zone is US so there is no issue with the date format and I have manually used that date in the recent past.  Our NetBackup guy assures me the tapes for that time slot are still on line.  (Or is he wrong?)

Anyone seen this little horror before?  And what did you do about it?

Thanks much!

-- Jacob S

Thanks, Paul.

No issue with GL-DATETIME.  I had run a similar PIT restore a few weeks ago and used the identical parameters and date/time format. Just to check I just manually did an onbar run with a deliberately bad date format.  It gave me the identical "invalid point in time value" error.  So the bouncer is just being too eager.

Ya just gotta love these clear error messages!

Thank you, Milan.

But as I replied to Paul, that was not an issue a few weeks ago when I did the PIT to Jan1 of this year.  However, recalling that, I did try a manual onbar with date 2025-01-01 <time> and it made no complaint about an "invalid date".  It went straight to the "Successfully connect to storage manager".  (Of course it barfed right afterward because I had not set up my environment.  In my current case it's a monstrous script setting up the environment before running onbar.)

This kinda tells me the date is invalid because NetBackup doesn't like that 2023 date.  Although, as I also mentioned, our NetBackup guy claims our oldest existing backup dates from November 2023.

I may have to do a binary search through 2024 to see what restore date is acceptable.  But that's up my users.

Thanks guys, for helping me devise the experiment.  I'll post if there's something more useful to report.

Have you tried it without the "-w"?

This error, in my view clearly, refers only to the PIT datetime string provided and to onbar's inability to properly parse it - given potential external factors like CLIENT_LOCALE, GL_DATETIME, DBTIME env vars.

What is the contacts of the ixbar file?

Two things:

Why are you doing the onbar deamon?

What is the od dump of you date string?

Good point there, Wayne.

I copy/pasted the command-line in the bar_act.log into my post; Of course I did not run onbar_d directly.  Let that "_d" be stricken from the record. :-)

In any case, I have already posted that it turns out that date was rejected because the backup set for that date had expired and is no longer on the storage manager.  On the other hand, Nov 4 of that year is still on line (different expiration schedule) so I am working on that angle.  Other errors but the date passed muster.

BTW, when I deliberately used a syntactically incorrect date like '1234345 89765" it gave the identical error message. Hence the confusion.  It might be nice if it would tell me "That date was expired" or "Data for that date not on storage manager."  Y'know, something that would actually tell me what's wrong.  This is something I always complained about while at Informix and IBM has always been notorious for unhelpful diagnostics.

Hello Jakob,

I know that before restoring with archecker (Tabel Level Restore), if you use a restore to '<Date>' statement, it is better to set DBTIME to the correct format '%Y-%m-%d %H:%M:%S'. I think this should also work for onbar.  At least, if I set DBTIME to a wrong value for the given date, I get exactly this error message.