QUSLOBJ error handleing

[Guest.Visitor]

Opinion Wanted. I used API QUSLOBJ (list objects) to check for the existance of a file. What I was looking for was either CPF9810 or CPF9812. This works, but unlike other APIs this API does not set the Error Available Flag on. I talked to IBM, they said that the error available flag would only be set if the userspace was not defined. So unlike the other API's you could not rely upon normal error logic. Another interesting point is that there seems to not be an error code returned if the user space is invalid. IBM said that they would change the documentation to reflect this. I want them to change the API so it works like the others I've used. What do you think? I'm I barking up a tree? OR does consistency not mean anything anymore? TIA rdkeller@bneinc.com Robin D. Keller Systems Resources Manager Boddie-Noell Enterprises

[Guest.Visitor]

If this were a Retrieve API then I would expect an error; but there is no error if a List API happens to return 0 entries in that 0 is the correct number of "hits" given the search values.

[Guest.Visitor]

On Friday, February 05, 1999, 08:20 AM, Robin D. Keller wrote: Opinion Wanted. I used API QUSLOBJ (list objects) to check for the existance of a file. What I was looking for was either CPF9810 or CPF9812. This works, but unlike other APIs this API does not set the Error Available Flag on. ... rdkeller@bneinc.com Robin D. Keller Systems Resources Manager Boddie-Noell Enterprises Robin, If you want to check whether a file exists and/or is valid, I would consider using the CHKOBJ command. This command can be called in an RPG program or procedure directly using the QCMDEXC or QCAPCMD APIs. The message you are expecting will be contained in the program status data structure. You didn't indicate whether you are using RPGIII or RPGIV, but the following has worked for me and could be modified to work in either the ILE or OPM environment. To check whether an object exists, pass the CHKOBJ command. To receive the message ID or message back, pass the optional parameters. I have not included source for the MOVMSG procedure that is called. That routine could be posted if this is something you think you might want to do. David Morris <pre> DQCmdExc PR EXTPGM('QCMDEXC') Execute a command. D PR_CmdStr 32767A CONST OPTIONS(*VARSIZE) D PR_CmdStrLen 15P 5 CONST D************************* D* CEEDOD API Parameters * D************************* DDscTyp S 10I 0 DDtaTyp S 10I 0 DDscInf1 S 10I 0 DDscInf2 S 10I 0 D********************************* D* Program status data structure * D********************************* DPSDS SDS NOOPT D PSDSExcMsgID 40 46A D PSDSExcMsg 91 170A ************************************************** ****************************** ************** * ExcCmd Execute command via call to QCMDEXC. * ************************************************** ****************************** ************** PExcCmd B EXPORT DExcCmd PI 1 OPDESC D CmdStr 32767A CONST OPTIONS(*VARSIZE) D ExcMsgID 7A OPTIONS(*NOPASS: *OMIT) D ExcMsg 80A OPTIONS(*NOPASS: *VARSIZE) DPrmLen S 10I 0 STATIC Parm length. DPrmPas S 10I 0 STATIC Parm passed. C CALLP CEEDOD(1: C DscTyp: C DtaTyp: C DscInf1: C DscInf2: C PrmLen: C *OMIT) C CALLP QCmdExc(CmdStr: C %LEN( C %TRIMR( C %SUBST(CmdStr:1:PrmLen)))) C* C IF %PARMS >= 2 C CALLP CEETSTA(PrmPas:2:*OMIT) Omitted? C* C IF PrmPas = 1 Yes. C EVAL ExcMsgID = *BLANKS C END C* C IF %PARMS >= 3 C CALLP CEEDOD(3: C DscTyp: C DtaTyp: C DscInf1: C DscInf2: C PrmLen: C *OMIT) C EVAL %SUBST(ExcMsg:1:PrmLen) C = *BLANKS C END %PARMS>=3 C END %PARMS>=2 C* C CALLP MovMsg C* C RETURN *OFF C************************************************* ************************* C* **PSSR - Program status sub-routine return error flag *ON. * C************************************************* ************************* C *PSSR BEGSR C IF %PARMS >= 2 C CALLP CEETSTA(PrmPas:2:*OMIT) Omitted? C* C IF PrmPas = 1 Yes. C EVAL ExcMsgID = PSDSExcMsgID C END C* C IF %PARMS >= 3 C CALLP CEEDOD(3: C DscTyp: C DtaTyp: C DscInf1: C DscInf2: C PrmLen: C *OMIT) C EVAL %SUBST(ExcMsg:1:PrmLen) C = PSDSExcMsg C END %PARMS>=3 C END %PARMS>=2 C* C IF %PARMS < 2 C CALLP MovMsg C END C* C RETURN *ON C ENDSR PExcCmd E </pre>

[Guest.Visitor]

On Friday, February 05, 1999, 10:10 AM, Bruce Vining wrote: If this were a Retrieve API then I would expect an error; but there is no error if a List API happens to return 0 entries in that 0 is the correct number of "hits" given the search values. Is it? The API places the CPF message Data and ID in the proper places for Error messages. But then it does not set the Error flag. The API Error handling instructions plainly state that any error will be posted and the Error Available Flag will become greater than zero (look at format ERRC0100 - System API Reference). The same section also reads that if no error occurred the other fields remain unchanged. But they are changing so either the documentation is wrong or the API is not functioning properly. For all other APIs all I have to do is to check the Error Available Flag for greater than zero, if it is then go process errors. For this API I have to check the Error ID field. Why the inconsistencey? For this project I ended up using the CHKOBJ command. I just don't know why this API works differently. rdkeller@bneinc.com Robin D. Keller Systems Resources Manager Boddie-Noell Enterprises

[Guest.Visitor]

Checking the Bytes Available field of the Error code parameter is indeed the correct method for determining if an error took place (if Bytes provided <blockquote><tt>= 8 anyway). I am not able to reproduce the error though where an error msgid was returned but Bytes Available was not set to reflect that (for instance, parameter one User Space name incorrect). And when using QUSLOBJ to look for a specific (non-existant) object name I received no error (Bytes Available = 0 and Exception id left in its last used state) as expected (the list was simply empty). Can you debug the program and verify the values in the Error code parameter both before and after calling the API? Thanks, Bruce </tt></blockquote>