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].
midrange.com
