Re: Extracting from a single iso loaded to an image catalog

Chuck

Your points about CCSID and SAVFs are probably true in fact, but they don't seem to apply to SAVFs and CPY.

So the solution is to use a CCSID in the TOCCSID value when there is NOT an object already in place for the CPY to use to determine the *OBJ CCSID

I used 37 because I'm in the US - other places should probably use their default CCSID - NOT QCCSID if it is 65535 - and 65533 is the maximum number to use, BTW.

*JOBCCSID is an option - maybe that would work instead of hard-specifying the number as I suggest.

Things do seem to behave a bit oddly - I mean, the help for the TOCCSID says the parameter is ignored if the object not a regular file - "A regular file is a file that supports the integrated file system input/output (I/O) operations open, read, and write."

I guess I don't want IBM working on this possible "defect" - there are much more important things we need done. I bet you're used to that discussion in your role when at IBM!! I hear it all the time in CAAC meetings.

Cheers
Vern

On 2/18/2015 8:39 AM, CRPence wrote:

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.