On 29-Dec-2011 13:46 , Jim Oberholtzer wrote:
I am trying to use the SAVRST command to push IFS objects between
machines from a program. The program uses:
SAVRST RMTLOCNAME(&RMTSYS)
OBJ(('/*') ('QSYS.LIB' *OMIT) ('/QDLS' *OMIT)
('/QFPNWSSTG' *OMIT) ('/QNTC' *OMIT)) <<SNIP>>
CHGPERIOD(121911 000000 *ALL *ALL) <<SNIP>>
This statement fails when run from a program with CPF382B which
says: Parameters not valid with multiple file systems.
If I run the exact same command from a submit job it works. The job
log in both cases show the exact same statement after the variables
have been resolved.
Any idea why this would work as a hand submitted job and not work if
called from a program?
V5R4 systems on both ends. Communications is working well.
Although a followup message appears to have concluded the error is
somehow related to the CHGPERIOD parameter specifications, if not, or
for anyone that might find this reply in the archives, perhaps of
interest to someone...
FWiW: A past discussion recording the same message on SAV, with
similar implication both in no differences between the CLP and command
line and being functional in the latter but not the former:
http://archive.midrange.com/midrange-l/200307/msg00592.html
With the specification ('QSYS.LIB' *OMIT) instead of ('/QSYS.LIB'),
the error message CPF382B is normal for SAV, when the current directory
is not '/'.
Another valid origin for SAV would be for a failure to specify *OMIT
as the second element [per *INCLUDE being the default] for any but the
"('/*')" list element specified for the OBJ() parameter. For example,
as described occurs for the SAV command in KB document number 573063958
title "Message BRMS4202 Posted When Running a SAVBRM" (sic: actual msgid
is BRM4202):
http://www-912.ibm.com/s_dir/SLKBase.nsf/a9b1a92c9292c2818625773800456abc/cbe45847ce2b693f862577a00029652f?OpenDocument
"
When saving '/*' using the SAVBRM command, only additional *OMITs are
permitted. If additional *INCLUDEs are added, the save will fail with
message BRM4202.
Examples that will post a BRM4202 error message
SAVBRM OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) ('/DIRA'))
SAVBRM OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) ('/DIRA' *INCLUDE))
Note: If using the SAV command, a CPF382B message...
"
FWiW: A possible variation on the above, a scenario which also would
correctly receive CPF382B, is the following not-so-obvious error in
specification [¿and probably most likely to originate within a CLP?]:
"OBJ(('/*') ('/QSYS.LIB *OMIT') ..." which translates to:
"OBJ(('/*') ('/QSYS.LIB *OMIT' *INCLUDE) ..."
And finally... The following APAR from a defect search on the symptom
msgCPF382B [Hmmm... listed as one of the "*ESCAPE Messages" in the list
of supported error messages that will be issued by the SAV command, but
not noted for the SAVRST command, although that may be moot, as the full
details of the messaging were omitted]:
Is the ObjectConnect option properly upgraded to v5r4 according to
DSPSFWRSC and verified by CHKPRDOPT? Although not tagged "UNPRED", the
"Error Description" text of the following APAR states that the message
is unpredicatable per a suggestion that there is "the potential to
encounter" the message, even though the "problem summary" seems possibly
to suggest that the outcome instead may be expected consistently?:
MA33921 - LIC-MSGCPF382B SAVRST FAILS AT SAVE PHASE
http://www.ibm.com/support/docview.wss?uid=nas2e32ddac5e054508d862571a4003c7c8e
"
_Error Description_
When doing a SAVRST between r530 and r540, the potential to encounter
MSGCPF382B is present.
Circumvention: Use SAV to save into a *SAVF, then FTP the *SAVF
to the target system and use RST to retrieve data.
_Problem Summary_
When doing a SAVRST between v5r3m0 and v5r4m0, fails and CPF382B is sent.
Circumvention: Use SAV to save into a *SAVF, then FTP the *SAVF to the
target system and use RST to retrieve data.
_Problem Conclusion_
Changes in code were made to ensure proper saving phase in SAVRST command.
<<SNIP>>
_Circumvention_
None.
<<SNIP>>
Status..................... CLOSED UR1
<<SNIP>>
"
Although the "conclusion" in that APAR suggests a fix was provided,
the "status" showing closing code of UR1 [which means "Fixed in a future
release"] seems to suggest that no PTF was provided, such that if a
"fix" was made, then the code change was presumably made in the base of
some future and unstated [point] release.... or that could just mean the
problem will no longer exist when the target system code-level gets
beyond v5r3.
Regards, Chuck
midrange.com
