On 13 Sep 2013 11:34, Cyndi Bradberry wrote:
I have a file with 3 - 10 position character fields.
FWiW: "Three dash Ten positions character fields" says to me, that
there are an unspecified number of "three to ten byte character fields".
IMO either giving the DDS-like or SQL DDL would be much clearer. Or
perhaps just "three 10-byte character fields". As well, the POSITION
parameter deals with Key fields, so beyond just "character fields", they
are a set of "character fields that define the composite key" of the
file; again, the DDS or DDL would make that obvious.
Having read nearly to the end of the message... the implication is
finally more obvious, wherein the file\keys are more clearly defined.
Seems that might have better have been the lead-in... yet offering DDS
or DDL to describe a file leaves little room for inference about what a
description in words may be confusing or lacking. Again... FWiW.
I am building the key string and using it in the OVRDBF statement.
I have 3 variables which I *cat with the quote variable then *Bcat
the three into the FileKey variable.
Unless there is a need to embed an apostrophe [i.e. an apostrophe is
part of the key], there is no apparent need to do that.
However to build a command-string that will be sent to a
command-processor, rather than performing the command inline to the CLP,
then there may be a requirement to preface and suffix the data with an
apostrophe to make the character data appear as a delimited string by
the command interpreter. However there should be no need to issue the
Override with Database File (OVRDBF) using the Execute Command API
(QCMDEXC) nor any other similar API [e.g. QCAPCMD]. In fact doing so is
potentially problematic, *if* there is any value which includes an
apostrophe, because then the request will have an unmatched apostrophe
unless either the request is formed in hexadecimal or the existing
apostrophes are doubled; i.e. escaped with a preceding apostrophe.
DCL "E *CHAR 1 VALUE('''')
Dcl &FileKey Type(*Char) Len(38)
The following declarations and the assignments [with values
reflecting the apparent intent for a 30-byte composite key buffer]
should enable an easy way to have the &FileKey variable function as
expected for the OVRDBF that follows [from the quoted message]:
dcl &key10Ausr *char 10 stg(*defined) defvar(&FileKey 01) /* 01-10 */
dcl &key10Alib *char 10 stg(*defined) defvar(&FileKey 11) /* 11-20 */
dcl &key10Apgm *char 10 stg(*defined) defvar(&FileKey 21) /* 21-30 */
dcl &keyExtra *char 01 stg(*defined) defvar(&FileKey 31) /* 31-31 */
/* the &FileKey could reduce to 31 bytes */
chgvar &key10Ausr 'USER' /* right-pad implicit; this and next 2 */
chgvar &key10Alib 'XXXLIB'
chgvar &key10Apgm 'XXX001C'
chgvar &keyExtra 'X' /* non-blank; required: keep blank pad */
OvrDbF PGMSEC Position(*Key 3 *N &FileKey)
RcvF RcdFmt(@PGMSEC)
From the Job Log:
4500 - OVRDBF FILE(PGMSEC) POSITION(*KEY 3 *N '''USER '' ''XXXLIB '' ''XXX001C ''')
4600 - RCVF DEV(*FILE) RCDFMT(@PGMSEC) WAIT(*YES) OPNID(*NONE)
/* File name is xxxLIB/PGMSEC. */
Position option for member PGMSEC not valid.
Function check. CPF4137 unmonitored by CKD001C at statement 0000004600,
instruction X'0000'.
CPF4137 received by procedure CKD001C. (C D I R)
The effective joblog [formatted\wrapped to show layout; a scale line
showing positions of each key value] after having made the above changes
in declares and run-time, to assign values to the 30-byte key with a
non-blank 31st byte:
- OVRDBF FILE(PGMSEC)
POSITION(*KEY 3 *N 'USER XXXLIB XXX001C X')
/* ...scale line..: ....+....1....+....2....+....3. */
<<SNIP>>
Message ID . . . . . . . . . : CPF4137
<<SNIP>>
Message . . . . : Position option for member &4 not valid.
Cause . . . . . : The position option for member &4 file &2 in
library &3 is not valid. The conditions that can cause this
error include:
-- The relative record number or key specified with the OVRDBF
command does not exist in the file.
<<SNIP>>
Recovery . . . : Do one of the following and try your
request again:
-- Use the OVRDBF command to specify a record that exists in
member &4.
Presumably the following 38-byte string value [minus the
double-quotes as delimiters, is not found in the file, just as the
message alludes in the first cause and recovery:
"'USER ' 'XXXLIB ' 'XXX001C '"
"....+....1....+....2....+....3....+....+"
Of course, necessarily truncated to the 30-byte key length, that
value is also unlikely to be in the file; most notably, due to the
embedded apostrophes:
"'USER ' 'XXXLIB ' 'XXX"
"....+....1....+....2....+....3"
I see the multiple quotes around the 3 components of the key, but I
can't see how to make them go away.
Do not add the apostrophes :-) Just use *CAT, no *BCAT, and no
"E; e.g. something like the following, although the *DEFINED storage
example declarations and assignments are better IMO:
chgvar &FileKey (&c10_usr *cat &c10_lib *cat &c10_pgm)
My file is keyed on the three fields, User, Library, Program in that
order. There is a record in the file for the above
user/library/program combination.
Given all of the key fields represent apparent object names according
to system-naming rules [in the /QSYS.LIB file system], an apostrophe is
not easily [allowed to be] embedded in an object name [via a command
interface]; i.e. it is probably safe to _assume_ that will not be an issue.
However if any of the key fields were Packed Decimal, integer, or any
/character/ field that allows either unprintable characters or embedded
apostrophes [e.g. names like O'Neil], then the key value should be coded
as a hex string in the form X'hexadecimal_digits' or if all are just
character fields whereby any might contain embedded apostrophes, then
another option is to escape the apostrophes, whenever passing a
command-string to a command processor. Failing to escape the
apostrophes in the data or to code the string as a hexadecimal string
when the x'7D' as apostrophe appears in the data, could result in
CPD0014 "A matching apostrophe not found." and CPF0006 "Errors occurred
in command." when the command interpreter is invoked;;; and horribly, it
could work in all testing and most of the time, and only fail when
something in the data finally has an apostrophe or x'7D' :-(
I am having a senior Friday moment. Can someone please point me at
the explanation ?
I realize a followup post implies the problem was resolved,
apparently calling QCMDEXC. But hopefully some of the above comments
are worthwhile... if not, perhaps to someone perusing the archives.
I suggest avoiding the CALL to QCMDEXC, and just correcting the 4th
element of the POSITION() parameter to use the 31-byte string with the
31st character set to a non-blank [e.g. 'X'].
midrange.com
