Fixes/changes to compatibility wrapper

[Scott-Cam]

Fixed cwclasses to do a strict comparison to null in oldToNewDescriptionItem since that is what the called function is returning on error, prevents things like empty arrays from causing an error.

Changed two functions in cw.php:
1 - i5_spool_list - do not require an outq library use *LIBL if one is not provided
2 - listRead - remove error logging when no more entries found, just clogs the log.

[alanseiden]

For the oldToNewDescriptionItem fix: Adam pointed out that it would be better programming if findValueInArray() returned false instead of null; then compare against false instead of null. Can you make those changes?
Also, did you find that an empty $dsData array causes any problems later in oldToNewDescriptionItem(), such as warnings in foreach statements? I never tested with empty sub-arrays so I don't know.

[Scott-Cam]

Yes I can do that. I think the reason it probably returned null was to
differentiate between a non-existent value (null, no match found) and a
match that has a value of false. But I think that it is valid to return
false in this case since the input array should not contain any boolean
values, just the I5_TYPEs that are defined. The function is only called
in two places so it could probably even be replaced by array_key_exists
but I'll leave that for now.
I don't remember seeing any other warnings/issues but I'll put the code
back and find the exact call so I can say for sure and let you know.

On 11/25/2014 11:29 AM, Alan Seiden wrote:

For the oldToNewDescriptionItem fix: Adam pointed out that it would be
better programming if findValueInArray() returned false instead of
null; then compare against false instead of null. Can you make those
changes?
Also, did you find that an empty $dsData array causes any problems
later in oldToNewDescriptionItem(), such as warnings in foreach
statements? I never tested with empty sub-arrays so I don't know.

—
Reply to this email directly or view it on GitHub
#34 (comment).

[alanseiden]

Thanks, Scott. I agree with your explanation of why I originally used null. Once Adam pointed it out to me, I saw that false does seem clearer as an indication of "unsuccessful." If we were in more of an OO mode, not in the CW, we might have used an exception instead. Thanks for making the update.

[alanseiden]

You are correct regarding the need for *LIBL when searching for spool files by OUTQ. I reviewed an old Easycom test and found that it did not require a library to be specified, so presumably used *LIBL internally; the QGYOLSPL API does support *LIBL. Very good.

[alanseiden]

To clarify, when I asked about warnings from empty $dsData, I meant whether new warnings arose with the updated code when applied to your particular test cases. Before, empty $dsData would be considered an error; now it won't, so that array may flow through various foreach statements, which would generate a warning with empty arrays; so I was suggesting that you look for warnings before we finalize the pull request. Apologies if that was already clear to you.

[Scott-Cam]

No problem, here is how I tested:

1 - Remove the fix and ensure I can create the issue (uses the QSYRUSRI
API) and get the message from php.log and toolkit.log
toolkit - 26 Nov 2014 06:15:4.549616 i5Error: num=37 cat=9 msg="Requested
parameter 'USER' does not exist in the input data" desc="Requested
parameter USER does not exist in the input data"
php.log - [26-Nov-2014 06:15:04 America/Edmonton] PHP Fatal error: Call to
a member function getParamProperties() on a non-object in
/usr/local/zendsvr6/var/libraries/PHP_Toolkit_for_IBMI_i/1.5.0/library/ToolkitServiceXML.php
on line 457

2 - Put the fix back in and re-run the test, checked php.log and
toolkit.log to ensure there were no problems and also look at the events in
ZendServer.for any PHP Error events (z-ray didn't show anything either).

I didn't find any errors or warning generated with the fix back in :)

On Wed, Nov 26, 2014 at 7:31 AM, Alan Seiden notifications@github.com
wrote:

To clarify, when I asked about warnings from empty $dsData, I meant
whether new warnings arose with the updated code when applied to your
particular test cases. Before, empty $dsData would be considered an error;
now it won't, so that array may flow through various foreach statements,
which would generate a warning with empty arrays; so I was suggesting that
you look for warnings before we finalize the pull request. Apologies if
that was already clear to you.

—
Reply to this email directly or view it on GitHub
#34 (comment).

[alanseiden]

Thank you.