Re: HMC network install of i5OS V7R1 from DSLO image, can't fine load source B2003110

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).