Software/Hardware used:
First, was there a reason you used MPUT instead of PUT? It doesn't matter for the content, but a simple PUT is usually easier for transfers of single files.
Anyway, without the error message identifier, there is almost nothing we can say. If we don't know what the system thinks is wrong, we can't guess how it might be fixed.
Two general areas need to be reviewed. First, how did the savefile get to the Windows system in the first place? If it wasn't a binary transfer, then it was corrupted at that time. Second, where did the savefile originally come from? If it came from a different AS/400, it might contain data items from an incompatible system version.
But without more details, we don't know.
Tom
TOM- the .savf files was established by one of our professional services and from where? that I do not know.. so basically tom what are you trying to say is when this .savf files comes to different as400 and is not compatible to the new as400 this might be the reason? thanks.
BIGKAT-I would like to monitor AUTL, CFGL,CNNL CTLD JOBD LIND which more of them are lists and description.. what we do is to get the original details of each objects and monitor it if someone makes some addition,deletion or modification in the line.thanks
RICKMCD- I’m assisting the AS400 admin for this but for the inputs he’s the one doing it. I truly believe he knows what to do.thanks
Also, you may want to expand on what you are trying to do when you say “to monitor config files of as400″ (which may need to splinter off into its own question for traceability reasons – but start here and we’ll see where it goes)
Since you are new to Iseries, did you use right command to look at save file,
DSPSAVF data/savf
Objects in a savfile were created for a given OS version. If an object is at version “X”, then it is often not compatible with version “(X-1)”. However, the OS generally allows you to specify that an object is to be saved for a previous version as long as the target version is not more than two releases behind and the object does not have an attribute that doesn’t exist in the target release.
A system might be at OS level 7.1 and various objects might be requested to save at OS level 6.1 successfully. Those objects could then be restored to a 6.1 system. The savefile would have attributes that a 6.1 system would accept. A V5R4 system would reject that savefile.
That’s not true for all object types. For system configuration objects, there is no way to specify a target release. The intention is only to save for disaster recovery, not to make available for use on a different system.
I’m a little confused, though. The list of objects that you gave doesn’t really fit with what might make sense. A number of those are older ‘legacy’ things that aren’t reasonable to save/restore for testing. There is no way to look at them via a savefile; they must actually be restored which replaces that system’s configuration. (Some of them aren’t generally even used anymore.)
Also, the list contains incompatible objects. There would be at least three separate savefiles for *AUTLs, *CNNLs and *JOBDs for example. Of those three, only *JOBDs might reasonably be restored in a way that would allow some kind of testing or monitoring. And a restore would be the only action that would make “monitoring” feasible.
In short, it’s still not clear what you’re actually trying to accomplish. It’s pretty certain that whatever it is, there’s a much better way to do it.
Tom