UNIX for Beginners Questions & Answers

I uninstalled the licenses and then reinstalled. I had kept the Registration Keys from March of 2017, the last time I registered, and they still worked!! And it turns out I had my network cable plugged into the wrong LAN port, so now I am connected and everything is working as before we went down. I am considering this an official miracle. The thing I noticed on the last boot up is that the system time thinks it is 2002, so I'd like to change that the next time I boot, but I always get the format wrong. Can anyone give me the format of the century, date, time I should enter when I do that? Again, many thanks!

The cmos date is prior to the install date.
Either correct the date in the mb setup or enter the correct date I system startup as yyyymmddhhmm.
Or.

Code:

date -t 201812111736; setclk -r

Yes, I realized I could change it in the BIOS and now everything is fine, with the exception of the MicroLite BackupEDGE license is showing as invalid but it won't let me remove it. But I have a contact person there too so I'll get it sorted out.

Further to my post#56 I have now checked on my SCO system here and you can indeed re-enter license numbers and keys using the 'brand' command (so my memory was serving me well). As I said though, this function is now part of 'scoadmin'. Sorry for the confusion.

@spock9458......you can avoid having to constantly say thank you in your posts by simply pressing the thumbs-up icon at the bottom left of posts if the reply is useful to your cause, or not press it if it's not useful. See the forum rules page.

So my legacy machine is now humming along great, but I still want to try one more thing to get the VM I've been working on fully operational. The details are in another thread, but since this is my most recent question I will make an attempt to be brief about what I would like to try. I suspect that the reason my VM is not fully functional with our legacy program is because I have not copied over the entire /etc directory. The reason I did not do this is because I was told one time not to copy the /etc/conf directory, which makes sense because the configurations would be different for the two machines. I have an idea to try with cpio, and I just want to make sure I'm not going to break anything before I try, so here is my plan:
1) make a cpio archive of the /etc/conf directory in the VM and save it to a /tmp directory
2) maka a cpio archive of the entire /etc directory in the Physical, and then FTP the archive over to the VM
3) cpio "in" the archive from the Physical to the /etc of the VM
4) then either delete the /etc/conf directory from the VM and immediately cpio "in" the backup archive I created in step 1; or just cpio "in" and overwrite the /etc/conf directory with the backup from step 1


Will this work to try and see if this clears up my problems? It seems possible just from the way SCO operates that messing with the /etc/conf directory without doing a reboot or relinking the kernel might be OK, but I'd like to know for sure.

Hi,

Here's my tuppence worth on the matter;

You'll almost certainly be able to do what you suggest, however a reboot is highly likely to cause lots of things to break - if I'm reading your intentions correctly.

I'd be tempted to clone the VM, bring it up without the legacy application and test the OS bit first - at least that way you'll be relatively sure that the OS is viable when you do it for real.

Attempting to sort out something like a legacy application in a VM is difficult enough, but adding the complexity layer of a potentially broken OS as well is a bit like persuading the Grandparents to tell their Grandchildren that Santa Clause has been assassinated - It's going to bring you a lot of grief from both sides.

Best to tackle these things one at a time.

I suppose if you are going to bring all the /etc/conf directory over, you could knock up a quick script and create a differences file - so what's missing what's added and any files that are different.

Regards

Gull04

i would start with the following:
1. compare the files in /etc/rc2.d and /etc/default in both machines. this is where services are started, and various system defaults are stored.



2. run

Code:

 

cd /etc
ls -l |grep -v @

This will list files in /etc that are not part of the operating system.
3. run

Code:

cd /etc
ls -lt |more    # or into a file

The purpose of this is to list files that have modification date newer than either the operating release date, or the installation date.
Rrun scoadmin ->software manager ->list modified configuration files.
Modify the .profile of the application user so that the user is not logged off if the application fails. The .profile may contain the following last lines:

Code:

exec application
or
application 

exit

Either remove the word exec or delete the line exit.
If when you then run the application, if any files are not on the VM system, you should recieve a 'file not found' message when the application fails.