RE: V7R1 and DDM file attributes

["Paul Nelson" <nelsonp@xxxxxxxxxxxxx>]

Chuck,

We haven't tried any of those other commands. The customer has an open PMR,
so I'm tossing this one to Rochester.

I'm thinking both machines might be short a few PTF's, especially the target
in Mexico.

Paul Nelson
Office 512-392-2577
Cell 708-670-6978
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, March 16, 2011 5:11 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: V7R1 and DDM file attributes

On 3/16/11 2:19 PM, Paul Nelson wrote:
> Anybody tried to use DDM to send a source file member from a 7.1 box
> to a 5.4 box? I'm getting a CPF2816 message that the CPYSRCF command
> ended in error, but the source member does, in fact, show up on the
> target machine.
>
> There's also a CPD9200 error with a DDM message code of X '1251',
> saying the  DDM function is not supported.

   Do other invocations against the DDMF such as DSPFD SYSTEM(*RMT), 
OPNDBF, OPNQRYF, or DSPPFM also fail, or perhaps just the copy 
utilities.  Or maybe only the CPYSRCF request which was enhanced at 6.1 
with new options for how the source change date will be updated?  Might 
a modified CPYSRCF request, one which does not attempt to perform a 
SRCCHGDATE() not available on v5r4 work without error?

   The x'1255' condition reported during the CPYSRCF represents the 
condition name PRMNSPRM "Parameter not supported reply message" which is 
possibly considered a defect, since no matter the specification for 
newer Source change date (SRCCHGDATE) parameter, the copy is probably 
meant to complete.?  I would expect a target-side PTF might exist to 
resolve, although a quick symptom kwd search turned up nothing.  Besides 
a modified CPYSRCF invocation, there may be a CPYF invocation which 
circumvents instead; e.g. using FMTOPT(*NOCHK).

Regards, Chuck