Multi-segmented file issues when upgrading from SCO to Linux
FACTS Support has not encountered this before and suggested I ask here. FACTS Support has also engaged PxPlus Support and they are investigating.
We're in the process of upgrading a client from FACTS 6.07, PVX 5.14, on SCO 5.0.7 (no large file support) to 7.9.2, PxPlus 10.20, on RHEL 6.7. This is a fairly large client: 68 users, 8 companies, 28 warehouses.
FACTS 6.07 has these multi-segmented files: ICWHSE, ICWHSE.001, SOPIND and SOPIND.001. All FACTS 6.07 data and programs were copied to the new Linux server and were run through the normal data conversion for FACTS 7.9.2. 'MB' parameter is zero (off). There were no issues with the data conversion and in the end no multi-segmented files remained -- just a single ICWHSE and SOPIND. Everything seemed OK and record counts matched exactly between 6.07 and 7.9.2.
We were attempting to research some BCC issues and it was suggested to check the data integrity on ICWHSE to make sure there were no problems, even though we were not seeing hard errors like #105 (keyed file error) that are typical indicators of a corrupt file.
The problem started when running *ufac (file integrity check) -- it didn't seem to get past opening the file before it generated 255 errors: "Cannot open /infor/facts79/data/IC/ICWHSE.001" through "Cannot open /infor/facts79/data/IC/ICWHSE.255".
FACTS Support suggested I next run *ufar (reconstruct) on a copy of ICWHSE, and it's a good thing I ran it on a copy because out of about of 2M records, 57% were suddenly and silently purged by *ufar. The *ufar program reported a successful recovery.
PxPlus Support suggested running a KEYED LOAD on the file; it, too, gave no errors but I'm not sure if I can trust KEYED LOAD since *ufar gave no errors but silently purged over a million records. Even after running KEYED LOAD, the files were still in this weird multi-segmented "state."
I tried three other methods to fix ICWHSE to try to remove the multi-segmented file "state" PxPlus assigned to the file. I would create a new, empty temporary file using FIB()/FILE, KEYED and *ufc. For FIB()/FILE and KEYED I would do a loop of read record/write record from the original file to the temporary file. When done, record counts matched, but the newly created temporary file was still flagged as multi-seg, even though no ICWHSE.001 was created.
On further examination I discovered that after the data conversion there were seven files flagged as multi-seg (according to *ufac), all of which are larger than 2GB: ICHITS, IRDST, ICTMLN.UP, ICUSED, ICWHSE, ICWICX and SOPIND. I can sort of understand it if it was only ICWHSE and SOPIND since those were multi-segmented to start with, but it doesn't explain the five other files.
ICWICX is a special case. With the embedded IOL, it appears to cross the 2GB limit. When I ran the FIB()/FILE fix program, the embedded IOL was removed. It appeared to fall below the 2GB limit. *ufac runs just fine on ICWICX.
So that it's clear, PxPlus has created only single copies of these files. There are no .001, .002, etc. pieces.
PxPlus is acting like 'MB' is turned on, which it isn't, even when I try to create fresh read record/write record versions of these files. It's as if PxPlus processed the multi-segmented ICWHSE and SOPIND files from 6.07 and even though the new files are not multi-segmented, it is "remembering" to flag large files as multi-segmented.
It is normal practice for us to run *ufac and *ufar when encountering corrupt files. Switching to KEYED LOAD will take retraining, and that's assuming it is working correctly on these seven weird files, but until then we can't be running *ufar and silently purge massive amounts of records.
Has anyone else seen anything like this? If you've upgraded clients with multi-segmented files, do you write a quick program to "convert" the multi-segmented files into a single one, prior to running the upgrade data conversion?
