Re: Using QSYGETPH to get profile handle is failing

On 12-Sep-2014 00:58 -0500, Scott Klement wrote:

<<SNIP>>
Also, you must ensure that you are NOT passing parameters 5 & 6
(length & CCSID of password) when you use a special value like
*NOPWD. It will always fail if you specify
*NOPWD/*NOPWDCHK/*NOPWDSTS. (I don't remember when this rule was
added, it might've been V5R3? But I know it was added for security
reasons, and broke backward compatibility with some programs.)
<<SNIP>>

Pretty much /pegged it/ in this past message, AFaIK:
<http://archive.midrange.com/midrange-l/200509/msg00856.html>
"...
So IBM split the API into two different ones called QsyGetProfileHandle and QsyGetProfileHandleNoPwd. And the OPM front-end (QSYGETPH) needed to be similarly protected, and the way they did that was to make parms 5-6 mandatory when a password is supplied. And required that they be *NOT* passed when a special value is used. That way, each program that calls QSYGETPH can only do one or the other at compile time.
..."

Apparently IBM deemed the potential for [m]any existing improper uses whereby the programmers had not been "savvy enough to check the parms for special values before calling the API" [per not even having been warned by a note in the documentation] as providing sufficient justification for forcing those old invocations to be invalidated. Thus at the cost of agitating [m]any who already had accounted for the integrity issue [by prohibiting use of the Special Values *NOPWDxxx when appropriate], per having introduced the incompatible change, and at the additional cost of those having to make the change irrespective of their having accounted for the integrity issue, any future uses of a technique that could have allowed a user to compromise the integrity of a system could not persist.