Sponsored Content
Operating Systems SCO Strange behaviour on Openserver 5.0.2 after 09/2015 Post 302954607 by jgt on Wednesday 9th of September 2015 10:31:39 AM
Old 09-09-2015
@gallok, are you also using 5.0.2a.

@chipperEs,
Quote:
then you can set the date and reboot
for example:
date -t 1508081210
init 6
You have left off the century. Is that a typo in your post, or is that how you enter the date?
You can use 'exit' in place of 'init 6', and the boot/startup routine returns to the 'enter root password or <ctrl>d' point of the normal start up.
There are no SCO operating systems prior to 5.0.6 with RS506a applied that are Y2K compliant.
It seems to me that there may be something along the lines of the following as a temporary measure.
Code:
if yy < 16
     yyyy=2000+yy
else
     yyyy=1900+yy
endif

Thus giving you 15 years to upgrade. Although why this expires in August and not Dec 31 is beyond me.
This User Gave Thanks to jgt For This Post:
 

9 More Discussions You Might Find Interesting

1. Linux

/etc/passwd strange behaviour!

Hi there, first of all, here is my conf of a uname -a Linux SAMBA 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown on a fedora machine. Here is my problem: every once in a while, the line containing root disappears in the /etc/passwd, disabling all logging on my server. Any one have... (0 Replies)
Discussion started by: penguin-friend
0 Replies

2. Shell Programming and Scripting

A Strange Behaviour!!!

Can some-one give me a view to this : I have a directory in an unix server, having permissions r-xr-xr-x .This directory is basically a source directory. Now there is another directory basically the destination directory which has all the permissions. Note:I log in as not the owner,but user... (5 Replies)
Discussion started by: navojit dutta
5 Replies

3. UNIX for Advanced & Expert Users

Strange sed behaviour

$ echo a.bc | sed -e "s/\|/\\|/g" |a|.|b|c| $ Is the behavior of the sed statement expected ? Or is this a bug in sed ? OS details Linux 2.6.9-55.0.0.0.2.ELsmp #1 SMP Wed May 2 14:59:56 PDT 2007 i686 i686 i386 GNU/Linux (8 Replies)
Discussion started by: vino
8 Replies

4. UNIX for Dummies Questions & Answers

Strange Program behaviour

Had a strange thing going on with my code. It's ok I figured it out for myself.... (2 Replies)
Discussion started by: mrpugster
2 Replies

5. Shell Programming and Scripting

strange behaviour from sed???

Hi all, I want to do a very simple thing with sed. I want to print out the line number of a disk I have defined in /etc/exports, so I do: It's all good, but here's the problem. When I define md0 in a variable, I get nothing from sed: Why is that? can anybody please help? Thanks (2 Replies)
Discussion started by: alirezan
2 Replies

6. Shell Programming and Scripting

Strange behaviour with perl i/o?

Hi All, I got a strange problem here. I have a perl script which is fetching data from a database table and writing a file with that data. If i run that script from linux command line, the file it creates is a normal ascii text file without any binary character in it.But... (9 Replies)
Discussion started by: DILEEP410
9 Replies

7. HP-UX

Strange login behaviour

Hi all, I am using HP-UX and I have just noticed that when I log into the network it seems to save the previous windows that were subsequently closed on previous occasions. Does anyone know when I log in, it seems to display these previous windows, e.g. nedit windows open again? Does... (1 Reply)
Discussion started by: cyberfrog
1 Replies

8. Shell Programming and Scripting

Strange RegExp Behaviour

Hello, I was trying to identify lines who has a word of the following pattern "xyyx" (where x, and ys are different characters). I was trying the following grep - egrep '(\S)()\2\1' This pattern do catches the wanted pattern, but it also catches "GGGG" or "CCCC" patterns. I was trying to... (5 Replies)
Discussion started by: itskov
5 Replies

9. Red Hat

Crontab strange behaviour

Hi all, I'm having this scenario which for the moment I cannot resolve. :( I wrote a script to make a dump/export of the oracle database. and then put this entry on crontab to be executed daily for example. The script is like below: cat /home/oracle/scripts/db_backup.sh #!/bin/ksh ... (3 Replies)
Discussion started by: enux
3 Replies
BACKUP_SETEXP(8)					       AFS Command Reference						  BACKUP_SETEXP(8)

NAME
backup_setexp - Sets the expiration date for existing dump levels. SYNOPSIS
backup setexp -dump <dump level name>+ [-expires <expiration date>+] [-localauth] [-cell <cell name>] [-help] backup se -d <dump level name>+ [-e <expiration date>+] [-l] [-c <cell name>] [-h] DESCRIPTION
The backup setexp command sets or changes the expiration date associated with each specified dump level, which must already exist in the dump hierarchy. Use the -expires argument to associate an expiration date with each dump level. When the Backup System subsequently creates a dump at the dump level, it uses the specified value to derive the dump's expiration date, which it records on the label of the tape (or backup data file). The Backup System refuses to overwrite a tape until after the latest expiration date of any dump that the tape contains, unless the backup labeltape command is used to relabel the tape. If a dump level does not have an expiration date, the Backup System treats dumps created at the level as expired as soon as it creates them. (Note that the Backup System does not automatically remove a dump's record from the Backup Database when the dump reaches its expiration date, but only if the tape that contains the dump is recycled or relabeled. To remove expired and other obsolete dump records, use the backup deletedump command.) Define either an absolute or relative expiration date: o An absolute expiration date defines the month/day/year (and, optionally, hour and minutes) at which a dump expires. If the expiration date predates the dump creation time, the Backup System immediately treats the dump as expired. o A relative date defines the number of years, months, or days (or a combination of the three) after the dump's creation that it expires. When the Backup System creates a dump at the dump level, it calculates an actual expiration date by adding the relative date to the start time of the dump operation. If the command is used to change an existing expiration date associated with a dump level, the new date applies only to dumps created after the change. Existing dumps retain the expiration date assigned at the time they were created. OPTIONS
-dump <dump level name>+ Specifies the full pathname of each dump level to assign the expiration date specified by the -expires argument. -expires <expiration date>+ Defines the absolute or relative expiration date to associate with each dump level named by the -dump argument. Absolute expiration dates have the following format: [at] {NEVER | <mm>/<dd>/<yyyy> [<hh>:<MM>] } where the optional word at is followed either by the string "NEVER", which indicates that dumps created at the dump level never expire, or by a date value with a required portion (<mm> for month, <dd> for day, and <yyyy> for year) and an optional portion (<hh> for hours and <MM> for minutes). Omit the <hh>:<MM> portion to use the default of midnight (00:00 hours), or provide a value in 24-hour format (for example, "20:30" is 8:30 p.m.). Valid values for the year range from 1970 to 2037; higher values are not valid because the latest possible date in the standard UNIX representation is in February 2038. The command interpreter automatically reduces later dates to the maximum value. Relative expiration dates have the following format: [in] [<years>y] [<months>m] [<days>d] where the optional word in is followed by at least one of a number of years (maximum 9999) followed by the letter "y", a number of months (maximum 12) followed by the letter "m", or a number of days (maximum 31) followed by the letter "d". If providing more than one of the three, list them in the indicated order. If the date that results from adding the relative expiration value to a dump's creation time is later than the latest possible date in the UNIX time representation, the Backup System automatically reduces it to that date. -localauth Constructs a server ticket using a key from the local /etc/openafs/server/KeyFile file. The backup command interpreter presents it to the Backup Server, Volume Server and VL Server during mutual authentication. Do not combine this flag with the -cell argument. For more details, see backup(8). -cell <cell name> Names the cell in which to run the command. Do not combine this argument with the -localauth flag. For more details, see backup(8). -help Prints the online help for this command. All other valid options are ignored. EXAMPLES
The following example associates an absolute expiration date of 10:00 p.m. on 31 December 1999 with the dump level "/1998/december": % backup setexp -dump /1998/december -expires at 12/31/1999 22:00 The following example associates a relative expiration date of 7 days with the two dump levels "/monthly/week1" and "/monthly/week2": % backup setexp -dump /monthly/week1 /monthly/week -expires 7d PRIVILEGE REQUIRED
The issuer must be listed in the /etc/openafs/server/UserList file on every machine where the Backup Server is running, or must be logged onto a server machine as the local superuser "root" if the -localauth flag is included. SEE ALSO
backup(8), backup_adddump(8), backup_deldump(8), backup_listdumps(8) COPYRIGHT
IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved. This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell. OpenAFS 2012-03-26 BACKUP_SETEXP(8)
All times are GMT -4. The time now is 10:46 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy