Error codes - OS2

This is a discussion on Error codes - OS2 ; What is a most complete list of possible error codes (as returned by CP's Dos*() functions, and WinGetLastError())? One possible source is to grep toolkit headers; in grep ERR os2emx.h | egrep -v " (PMERR|HMERR|WPERR|ERROR)_" I see (as possible candidates) ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Error codes

  1. Error codes


    What is a most complete list of possible error codes (as returned by
    CP's Dos*() functions, and WinGetLastError())?

    One possible source is to grep toolkit headers; in

    grep ERR os2emx.h | egrep -v " (PMERR|HMERR|WPERR|ERROR)_"

    I see (as possible candidates)

    #define PMERROR_SEND_MSG_FAILED 0x1054
    #define IDS_FILE_DRIVE_SOME_ERROR 1125

    First one is possibly just a misprint (should have been
    PMERR_SEND_MSG_FAILED); the second one probably is not in scope of the
    question at all (I can't find IDS_FILE* mentioned in any doc...).
    What are other codes, not mentioned in os2emx.h?

    ================================================== =====

    The other question is what are the tables to map error codes to error
    names/explanations. I extract these from OSO001.MSG, but the list
    there is too short. Are there any other tables, or do I need to
    actually have

    case PMERR_NOT_IN_A_PM_SESSION:
    name = "PMERR_NOT_IN_A_PM_SESSION";
    break;
    case PMERR_INVALID_ATOM:
    name = "PMERR_INVALID_ATOM";
    break;

    etc in my programs?

    -------------------------------------------------------

    Another question is: when the returned error codes are misleading? I
    know that 0x1001=PMERR_INVALID_HWND is returned in many situations,
    such as when you query the clipboard for a non-existing type. Is
    there a list of other cases?

    Thanks,
    Ilya

  2. Re: Error codes

    In , on 11/11/2008
    at 01:29 AM, Ilya Zakharevich said:


    >What is a most complete list of possible error codes (as returned by CP's
    >Dos*() functions, and WinGetLastError())?


    I don't think there's any one best place. I use a combination of the VAC
    toolkit headers, the CPREF and the PMREF.

    >I see (as possible candidates)


    > #define PMERROR_SEND_MSG_FAILED 0x1054
    > #define IDS_FILE_DRIVE_SOME_ERROR 1125


    Candidates for what?

    >First one is possibly just a misprint (should have been
    >PMERR_SEND_MSG_FAILED); the second one probably is not in scope of the
    >question at all (I can't find IDS_FILE* mentioned in any doc...).


    I suspect the IDS_ definitions have something to do with the internal
    state machine of standard file dialog, but that's just a guess.

    >The other question is what are the tables to map error codes to error
    >names/explanations. I extract these from OSO001.MSG, but the list there
    >is too short.


    Best I can tell, they don't exist.

    > case PMERR_NOT_IN_A_PM_SESSION:
    > name = "PMERR_NOT_IN_A_PM_SESSION";
    > break;
    > case PMERR_INVALID_ATOM:
    > name = "PMERR_INVALID_ATOM";
    > break;


    A more generic solution would be to implement an OSO001X.MSG that would
    contain what is not in OSO001.MSG.

    >Another question is: when the returned error codes are misleading? I
    >know that 0x1001=PMERR_INVALID_HWND is returned in many situations, such
    >as when you query the clipboard for a non-existing type. Is there a list
    >of other cases?


    I hope you are kidding. :-)

    The best one I know of is when chkdsk reports insufficient memory when it
    runs out of threads.

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00.11.18 BETA #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  3. Re: Error codes

    On 11/10/08 06:29 pm, Ilya Zakharevich wrote:
    > What is a most complete list of possible error codes (as returned by
    > CP's Dos*() functions, and WinGetLastError())?
    >

    The Toolkit's "Control Program Programming Guide and Reference" has a
    section called "Errors." It lists all of the errors returned by the API
    functions.
    Similarly there is a "Errors" section in the "Presentation Manager
    Programming Guide and Reference."
    There is no succinct (or otherwise) description of what errors are
    generated by which API functions.
    The ultimate source for error codes are the include files of the
    Toolkit. No descriptions, though.
    >
    > Another question is: when the returned error codes are misleading? I
    > know that 0x1001=PMERR_INVALID_HWND is returned in many situations,
    > such as when you query the clipboard for a non-existing type. Is
    > there a list of other cases?
    >


    WinGetLastError() Considered Harmful

    WinGetLastError() is useless. The return value comes from somewhere
    unrelated to the active thread; it return NO_ERROR when one actually
    occurs, and random values when no error occurs. In fact it's worse than
    useless since it can cause instability where none existed.
    I spent over a week trying to discover why I kept getting "Invalid
    queue" and "micro-presentation space" errors where there were valid queues
    and there were no micro-presentation spaces.
    I finally stopped calling the function. Certain odd and random problems
    simply disappeared.


    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  4. Re: Error codes

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Steven Levine
    ], who wrote in article <491927e3$2$fgrir53$mr2ice@news.west.earthlink.net>:
    > >What is a most complete list of possible error codes (as returned by CP's
    > >Dos*() functions, and WinGetLastError())?


    > >I see (as possible candidates)

    >
    > > #define PMERROR_SEND_MSG_FAILED 0x1054
    > > #define IDS_FILE_DRIVE_SOME_ERROR 1125

    >
    > Candidates for what?


    Candidates for integers which are error codes not catched by the
    egrep regular expression in my search
    " (PMERR|HMERR|WPERR|ERROR)_"

    > A more generic solution would be to implement an OSO001X.MSG that would
    > contain what is not in OSO001.MSG.


    I thought about it too. However, the question of the distribution
    channel (and possible nightmares related to installation) comes to mind...

    > >Another question is: when the returned error codes are misleading? I
    > >know that 0x1001=PMERR_INVALID_HWND is returned in many situations, such
    > >as when you query the clipboard for a non-existing type. Is there a list
    > >of other cases?

    >
    > I hope you are kidding. :-)


    Well, it came to my mind only very recently that I better maintain the
    list of the misplaced error codes I see. I hoped that somebody else
    could have realized it earlier, and already has such a list.

    > The best one I know of is when chkdsk reports insufficient memory when it
    > runs out of threads.


    In fact, I find this one quite understandable. IIRC, the THREADS=
    statement in CONFIG.SYS controls the size of some (static?) memory
    buffer. The kernel may report a failure to create a thread as an
    exhaustion of this memory buffer, and chkdsk propagates this error to
    the caller...

    *IF* there was an ERROR_OUT_OF_A_STATIC_MEMORY_BUFFER, this would
    solve a lot of unclear-error-message problems on OS/2... Now they are
    typically confused with running out of address space, or running out
    of present memory.

    In hindsight, it is quite easy to improve frozen APIs... ;-)

    Thanks,
    Ilya

  5. Re: Error codes

    [A complimentary Cc of this posting was sent to
    Jim Moe
    ], who wrote in article <34KdndyPyNonp4TUnZ2dnUVZ_gidnZ2d@giganews.com>:
    > The Toolkit's "Control Program Programming Guide and Reference" has a
    > section called "Errors." It lists all of the errors returned by the API
    > functions.
    > Similarly there is a "Errors" section in the "Presentation Manager
    > Programming Guide and Reference."


    All these mention errors covered in header files. This way, you do
    not get more error codes. [And I think PRCP contains some more errors...]

    > The ultimate source for error codes are the include files of the
    > Toolkit. No descriptions, though.


    That was my question: are there codes which are not listed in the toolkit.

    > WinGetLastError() Considered Harmful
    >
    > WinGetLastError() is useless. The return value comes from somewhere
    > unrelated to the active thread;


    Are you *sure*? My impression is that at least *the intent* is to
    have it thread-specific.

    > it return NO_ERROR when one actually
    > occurs, and random values when no error occurs. In fact it's worse than
    > useless since it can cause instability where none existed.


    First that I would suspect in such a situation is that my program is
    writing over memory which it is not supposed to touch...

    > I spent over a week trying to discover why I kept getting "Invalid
    > queue" and "micro-presentation space" errors where there were valid queues
    > and there were no micro-presentation spaces.
    > I finally stopped calling the function. Certain odd and random problems
    > simply disappeared.


    Thanks,
    Ilya

  6. Re: Error codes


    > What is a most complete list of possible error codes (as returned by
    > CP's Dos*() functions, and WinGetLastError())?


    > Another question is: when the returned error codes are misleading?


    Likely to be outside of your scope, but sometimes an impossible REX48
    is far better than an irrelevant REX40 (call may be 100% perfect):

    /* Rexx DLL */
    ...
    ULONG example=48;
    rc=DosOpen(...);
    if (rc)
    return example; /* Finally actually returns (REX)40, IIRC */
    ...



  7. Re: Error codes

    [A complimentary Cc of this posting was sent to
    A.D. Fundum
    ], who wrote in article :
    > Likely to be outside of your scope, but sometimes an impossible REX48
    > is far better than an irrelevant REX40 (call may be 100% perfect):


    You mean:

    REX0040: Interpreter croaks: Incorrect call to routine named as unknown
    REX0048: Interpreter croaks: Failure in system service named as unknown

    > /* Rexx DLL */
    > ...
    > ULONG example=48;
    > rc=DosOpen(...);
    > if (rc)
    > return example; /* Finally actually returns (REX)40, IIRC */
    > ...


    You mean: when a service returns 48, the REXX interpreter translates
    this to 40?

    Probably within scope, thanks,
    Ilya

+ Reply to Thread