On 17-Feb-2015 17:46 -0600, Steinmetz, Paul wrote:
On Tuesday, February 17, 2015 6:43 PM Vernon Hamberg wrote:
Prompt the CPY command - you'll see a couple CCSID parameters.
Change the TOCCSID to 37, I believe - that's what SAVFs will use.
Uhhh, No. The Display File Description (DSPFD) of *every* Device
File with the attribute SAVF should show no CCSID value. A SAVF is the
equivalent of a program-described [aka flat] file with a fixed record
length of 528 for which there is no CCSID and thus to which no CCSID can
be assigned nor a CCSID be changed. The Display File Field Description
(DSPFFD) should show there are zero fields; thus neither are there any
field-level [vs file-level] CCSID designations.
The fact that FTP can use the SAVF extension is an accident or a
gift, depending on your point of view. It is not what happens on
the system - only in FTP.
Reviewing the output from DSPMSGD TCP12C7 MSGF(QTCP/QTCPMSGF) shows
that the .SAVF extension is supported by the TCP/IP FTP feature as part
of a "path-format database file name ... An extension is part of the
file name which follows a period (.) character. The following
extensions are valid in database file names:
.LIB -- specifies a library
.FILE -- specifies a database file
.PF -- specifies a physical file
.LF -- specifies a logical file
.SAVF -- specifies a save file
.SRCPF -- specifies a source physical file
.MBR -- specifies a member."
I would suggest then, that the ability to specify the extensions
besides LIB, FILE, and MBR are an enhancement to [or an /extension/ :-)
as a "gift" beyond] the standard IFS naming. I am unaware of general
support for IFS /QSYS.LIB naming that includes any extensions other than
the _object type_ and the .MBR for the database file member [for which
the symbolic object type is actually *MEM]. Any utility that extends
that standard definition of the extensions for /QSYS.LIB IFS naming,
like the FTP does, would risk an [albeit very unlikely] scenario whereby
the OS adds a new object type that happens to match one of their
privately defined extensions, thus exposing a flaw in their use of a
token that was not formed like a /special-value/ is with the asterisk as
a prefix. I really have no idea [as I have never used\tested] what
using any of .PF, .LF, or .SRCPF should achieve, except perhaps to
sanity-check for a user expectation that the file attributes match the
specification; but unlike specifying .SAVF, using those other extensions
must still require a .MBR extension as a suffix on a third-level name.
That worked, thanks
CPY OBJ('/QOPT/CDROM/Y2SYCBL.SAVF')
TOOBJ('/qsys.lib/temp2e.lib/y2sycbl.file')
TOCCSID(37) DTAFMT(*BINARY) REPLACE(*YES)
Ownership of object Y2SYCBL in TEMP2E type *FILE changed.
File Y2SYCBL created in library TEMP2E.
Ownership of object Y2SYCBL in TEMP2E type *FILE changed.
Object auditing value changed for Y2SYCBL in TEMP2E type *FILE.
Object copied.
That makes no sense. A CCSID can not be assigned to a Save File.
However those messages preceding the "Object copied" completion have
me recalling what were the troubles I had with CPY; IIRC, due to the
definition of the Replace (REPLACE) parameter for CPY acting against the
_object_ instead of solely operating against the _data_ within the
existing object. Apparently an attempt was being made to assign a CCSID
to the object that was created after the original object was deleted per
REPLACE(*YES). If the CPY created a Device File with the attribute SAVF
[to replace an existing SAVF] for the above request, then the implicit
attempt to effect Change Attribute (CHGATR) to set a CCSID should fail
because that operation is not supported. The TOCCSID(*OBJ), the default
specification, is [for the lack of any supported special-value like
*BINARY or *HEX] the only reasonable specification. I would suggest to
avoid coding that [TOCCSID(37)] with an assumption that the feature is
operating properly, because I would expect a /fix/ to cause that
specification to start failing with the msg CPFA098 "The CCSID of the
target file could not be set to match the CCSID of the source file." as
described was happening when using TOCCSID(*OBJ); i.e. the ability to
use the TOCCSID(37) specification to avoid\circumvent the problem seems
a conspicuous defect.
As an Amazon Associate we earn from qualifying purchases.