Hi,
I am using IMPORT option from SYSMAIN, and I noticed the following:
If you have an object to be imported, and this object was saved and cataloged in Dez 01, and I solved to import today. After the import process, the date from Natural is the same that the object was developed, however, the date on Linux/Unix is different, it is the current date when it was imported.
So, does anyone know if it is possible to remain the same data, i.e, the save data that the object was developed?
If anyone knows how to do it, even if it is a workaround, I would appreciate receiving the hints.
Please, let me know if it is clear or if you need more information.
Natural doesn’t much care about the file properties maintained by the operating system in the directory structures. Natural relies on the values he maintains (in filedir.sag).
If you want the operating system properties to match Natural’s, you will need to find a Unix/Linux utility to modify them. Then create your own function to pass Natural’s values to that utility.
I created a routine to read the date and time from the object using USR0330N, after this, I used the Linux/Unix command - TOUCH, to change the physical date and time. It works fine, however, I found out other problem when it is used SYSMAIN IMPORT.
If you are IMPORTing Source code and Cataloged code, and you import first the Source code and then the Cataloged code, the date and time on both codes (S/C) will be always the last one, in this case, the cataloged object.
It seems that as you have only one FILEDIR.SAG, and the name of the object is the same, the last one is what Natural will store it.
Does anyone know if it is possible to avoid it or to remain the same for each object - source/cataloged.
I don’t see this behavior. I see matching timestamps on source/target source modules and matching timestamps on source/target object modules. That is, I see Natural maintaining the correct values.
As there are variations to the export/import process, perhaps you could list your specific steps.
I am curious. Why would you want to have the same values in Natural and Linux/Unix?
If I want information on “versions” of an object, I use the Natural date/time. This is also very useful for identifying objects where the source/object has gotten out of synch (someone using SAVE or CAT rather than STOW).
If, however, I want to know which objects I imported over the previous weekend, and it is Tuesday and I forgot, I want the Linux/Unix date/time.
The Natural date/time tells me the “history” of the content of a Natural object. The Linux/Unix date/time tells me the “history” of a copy of the Natural object.
Yesterday, in my tests, the date was different, but, after you said that the date must be the same that the original one, I did several tests again, and you are right, the date remains untouchable as the original, maybe I have not realized something in my previous test.
So, the idea to remain with the same date on both environments, it is to avoid any questions from users - developers. Besides this, the users does not need to know when the import was done, the application that I am building will have this information.
As so far is it is working fine, I can move onto the next step.