RE: V7R1 and DDM file attributes

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