× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.