With that [undocumented] API there _was_ never any requirement to
delimit nor blank-pad the values because the two parameters were
declared as CHAR(3) and CHAR(10).
And the CL CALL folds to upper-case and implicitly pads the parameter
values to 32-bytes. Thus each of the following PARM specifications
effect identical invocations; given those aforementioned declarations
[as well for either parameter declaration up to 32-bytes]:
PARM('DLT' 'QSYS2 ')
PARM(DLT QSYS2)
PARM('DLT ' 'QSYS2 ')
The following would also have been the same as the above, but due to
the internal declarations vs the call mechanism:
PARM(dltjunk 'QSYS2 junk')
Though if that API had changed to allow the new long library [SCHEMA]
names, merely by increasing the parameter length, then given valid
standard library names prohibit blanks, there is a chance that some
weird attempt at an enhancement for long library names might have
enabled the 32-byte padded values to be recognized as a short name. If
so, the request still should work the same as in the past, whereby
padding is optional. But to function consistently and correctly while
doing that, probably requires either looking for any long library name
first or validating any double-quote delimited name for which blanks are
allowed; i.e. a new long name could, because of embedded blanks,
accidentally be perceived as a short name [if that was overlooked by dev
as a possibility]. Being undocumented, I suppose the dev could have
felt no obligation to protect the past behavior, such that the old
invocations might no longer function correctly.
Seems doubtful however, that the old invocations would not continue
to work, as any support for the long SCHEMA names would seem more likely
to have been designed to require a length specification per the names
being up to 128-bytes for which command-line calls are somewhat
unpleasant to effect. Even with that, the old function should still
have been preserved, because an optional\unspecified length parameter
should have identified the input value as length=10, knowing that the
value would be padded, and then optionally [IIRC the code does not care
about the actual length] adjust that assumption with effectively:
length=rtrim(substr(newLongerInput,1,10));
Thus I expect likely there was no requirement to pad the values, and
has me wondering what led to the conclusion that such a specification
was required, and wondering what was different when called that way.?
Regards, Chuck
On 06-Jan-2014 17:15 -0800, Steinmetz, Paul wrote:
Larry,
Thanks again for all the help.
1) The fix below was correct, I needed to have both parms in quotes
and the extra spaces.
CHGJOB CCSID(nnn) where nnn is the primary CCSID (which should match
the ccsid of character fields in the QSYS/QADBXREF file)
CALL QSYS2/QSQXRLF PARM('DLT' 'QSYS2 ')
CALL QSYS2/QSQXRLF PARM('CRT' 'QSYS2 ')
and then call QSYS/QSQIBMCHK again to confirm the objects are there.
RSTLICPGM 5770DE1 OPTION(2).
<<SNIP>>
On 1/5/2014 7:36 PM, Steinmetz, Paul wrote:
Larry,
Switched from VLAN 2 to VLAN1, OPTVRT01 now working.
Reinstalled 575770SS1 1 Extended Base Support, issue fixed.
Applied the same fix for 5770DE1 *ERROR DB2 XML Extender that I
given for same previous issue, however, this time still failed.
1) IPL then sing on as QSECOFr
2) DSPFFD QSYS/QADBXREF
- what do you see for the CCSID of the string columns?
3) CHGJOB CCSID() from step 2, the DSPFFD
4) CALL QSYS2/QSQXRLF (DLT QSYS2)
5) CALL QSYS2/QSQXRLF (CRT QSYS2)
6) CALL QSYS/QSQSYSIBM
7) CALL QSYS/QSQIBMCHK
Then run RSTLICPGM 5770DE1 OPTION(2).
midrange.com
