MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2014

Re: cpyf with key that is packed



fixed

On 16-May-2014 12:34 -0500, tim.dclinc wrote:
I can do the following from command line:

CPYF FROMFILE(LIBR/FILE) TOFILE(QTEMP/IT) CRTFILE(*YES)
FROMKEY(1 (X'0563278F')) TOKEY(1 (X'0563278F'))

The file key field is defined as 7,0 packed.

I would like to do this in a cl program with a variable like:

CPYF FROMFILE(LIBR/FILE) TOFILE(QTEMP/IT) CRTFILE(*YES)
FROMKEY(1 (&key)) TOKEY(1 (&key))

I'm not sure how to define the &key variable and how to initialize
it with hex data.

The following is how to the declare the CL variable named &KEY to be initialized with the hex value shown used in the command-line request:

DCL &KEY *CHAR 04 VALUE(X'0563278F')

Any suggestions?

Beyond the aforementioned, depending upon the [unstated] requirements:

• The method suggested by Bruce <http://archive.midrange.com/midrange-l/201405/msg00691.html> is probably a much better approach [than the aforementioned resolution offered as a direct response to the implied inquiry of "how to"], because then a numeric variable declared as TYPE(*DEC) LEN(7 0) could be used as the basis for the redefined storage; i.e. as TYPE(*CHAR) LEN(4) STG(*DEFINED). That allows the numeric data type to be used for the key value, more easily requested from the user; e.g. input from a display file or from another program that already uses the decimal numeric representation, rather than expecting the user to input the value in hexadecimal form.

If the key value is passed as a parameter to a CLP\CLLE, a program that possibly will be invoked from a command line with a literal input value, then the parameter is best declared as TYPE(*DEC) LEN(15 05) according to the convention for passing numeric literals; again, allowing for a decimal numeric input rather than the hexadecimal string to represent that value. Then the value of the parameter would be copied to the TYPE(*DEC) LEN(7) variable; e.g.:

Dcl Var(&ParmFromKy) Type(*Dec) Len(15 05) /* parameter */
Dcl Var(&FromKeyN) Type(*Dec) Len(7 0)
Dcl Var(&FromKeyC) Type(*Char) Len(4) +
Stg(*Defined) DefVar(&FromKeyN)

ChgVar Var(&FromKeyN) Value(&ParmFromKy)

• The Open Query File (OPNQRYF) might be a nicer interface in that scenario, and the result can be manifest as a shared Open Data Path (ODP) rather than as an actual created database file. The overhead of the query request might not be much more than the overhead of creating the file. If the [keyed] file is required to exist in QTEMP, then the addition of Copy From Query File (CPYFRMQRYF) to create the file beyond just creating the query ODP, then obviously the query is not going to be a better performer; yet the easier specifications of numbers for selection [i.e. avoiding hexadecimal strings] might have some value, ameliorating performance concerns.

• The Copy File (CPYF) utility is easily replaced by program(s) that do the identical work, without the nuances, caveats, and restrictions of the CPYF request. The Create File (CRTFILE) specification is the most difficult to deal with, but a CLLE module that does either a Create Duplicate Object (CRTDUPOBJ) or Create Physical File (CRTPF) could effect that part of the work, and bind seamlessly with an ILE [e.g. RPG] that does the open, read, write, close.

• Also with program(s) replacing the work of CPYF, the SQL is an option. The SQL provides a CREATE TABLE ... AS, but the result would be a non-keyed file [a UNIQUE or PRIMARY key is not an option in QTEMP]. As alluded earlier, the added overhead of a query must be considered. However if this is a common query or repeated several times in the job but for different values of the "&key", then the SQL is probably the best option because the statement could be cached and the query ODP [as a pseudo-closed SQL cursor being reused] can significantly improve the speed of the repeated like requests.

Given there is no Member Option (MBROPT) specification on the sample source, this option seems unlikely to be compatible, because the implication [per default MBROPT(*NONE)] is that the target file must not exist and so the file is created and populated only once in the job; though possibly instead, the worst-case for performance, the file is repeatedly deleted to allow that CPYF to proceed without error on additional\repeated invocations. If that were the case, then the SQL does offer the CREATE OR REPLACE TABLE ... AS, but I would recommend the best performing option regardless of implementation; i.e.: create-once, replace only data [not the object].






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact