Release 10.1A: OpenEdge Development:
Debugging and Troubleshooting

> ## Logging levels for dynamic objects

> There are two logging levels supported for `DynObjects` entry types: 2 (Basic) and 3 (Verbose). Setting logging to 4 (Extended), logs information as for 3 (Verbose).

> ##### Basic logging level (2)

> The log entries for logging level 2 (Basic) include the following information, and any level above 1 (Errors) logs this information:

> - Action — For objects, this is `Created`, `Deleted`, or `Delete` `Pending`. For `MEMPTR`s, this is `Allocated` or `Deallocated`.

> - Object type — For example, `BUFFER`, `SERVER`, or `BUTTON`.

> - Handle value — `Handle:` followed by the integer value of the handle (`0` for `MEMPTR`s).

> - Routine name — The name of the `.p` or `.w` file or method where this application created or destroyed the object.

> - Line number — The line number in the `.p` or `.w` file or method where the application created or destroyed the object. This line number comes from the debugger listing file. When OpenEdge creates a `SOCKET` object implicitly, the line number always is `0`.

> For other implicitly created objects, the line number is meaningful. For example, for an `ASYNC-REQUEST` handle, it is the line number of the `RUN` statement.

> - `IMPLICIT` — Appears when OpenEdge created the object implicitly.

> - `POOLDEL` — Appears when OpenEdge deleted the object because it was deleting the object's object pool.

> - Other — For specific object types, the log output line includes other attributes:

> - `Name:` followed by the object name. For `BUFFER` objects, the `Name` attribute is the name of the table associated with the buffer, so the entry contains `Table:` followed by the table name.

> `TEMP-TABLE` objects do not show the `Name` attribute. This information is not available when the application creates the `TEMP-TABLE` object, but only after it invokes the `TEMP-TABLE-PREPARE` method.

> - The allocation’s size, for `MEMPTR`s.
> - The procedure name for `PROCEDURE` objects.
> - The name of the procedure associated with an `ASYNC-REQUEST-HANDLE` object (that is, the procedure that ran asynchronously).
> - The `Label` attribute for `BROWSE-COLUMN` objects, if there is no `Name` attribute (for calculated fields, for example). Also, to identify the browse parenting the column, the log entry includes the `BROWSE` name or `BROWSE` handle ID.

> Here are sample `BASIC` log entries (with headers suppressed):

>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Created        MENU               Handle:1098 (x.p Line 4)
>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Deleted        MENU               Handle:1098 (x.p Line 5)
>     Created        BROWSE             Handle:1139 (y.p Line 29)
>     [05/10/31@14:07:17.908-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Created        BROWSE             Handle:1139 (y.p Line 29)
>     [05/10/31@14:07:17.908-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Created        BROWSE-COLUMN      Handle:1143 (y.p Line 63) Name: Cust-Num
>     [Browse Handle:1139]
>     [05/10/31@14:07:17.908-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Created        BUFFER      Handle:1144 (y.p Line 70) IMPLICIT Table:item
>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 2 4GL DYNOBJECTS
>     Deleted        MENU               Handle:1098 (x.p Line 5) POOLDEL

> ##### Verbose logging level (3)

> Setting the logging level to 3 (Verbose), also logs object-pool related information.

> First, level 3 adds pool information to the log entry every time a dynamic object is created that is being tracked, except `PROCEDURE`, `MEMPTR`, and `BROWSE-COLUMN` objects. `PROCEDURE`s always are in the `Session` pool. `MEMPTR` and `LONGCHAR` memory is not stored in a pool. The log entry for `BROWSE-COLUMN` objects contains the browse name or handle ID information in the creation log entry (as described above), so you can refer back to the browse creation entry to find out which pool contains the object.

> Second, level 3 logs an extra entry every time a object-pool is created or deleted. This helps identify when OpenEdge deletes an object in the course of deleting a object pool, as opposed to when the application deletes the object explicitly.

> There are two formats for the messages generated at level `VERBOSE`, depending on the action:

> - Format 1 — OpenEdge logs the following when creating or deleting an object pool:

> - Action — This is `Creating` `Pool` or `Deleting` `Pool`.
> - Pool name — This is <`unnamed>`, `<Session Pool>`, or the name of a named pool.
> - `PERS` — This indicates the pool is persistent. OpenEdge does not log this for `Deleting` `Pool` actions.
> - Routine name and line number — The name of the `.p` or `.w` file or method where OpenEdge created or destroyed the pool, and the line number. The line number comes from the debugger listing file.
> Note: The line number can be the string `IMPLICIT` for an unnamed widget pool if the pool is created implicitly during the instantiation of a user-defined object.

> - `FROM` `routine-name` — `routine-name` is the name of the `.p` or `.w` file or method where OpenEdge created the object pool. OpenEdge logs this only for `Delete` pool.

> Here are sample log entries (with the headers suppressed):

>     Creating pool  <unnamed> (my.p Line 2)
>     Deleting pool  mypool  (x.p Line 9) FROM x.p
>     Deleting pool  mypool2  (x.p Line 10) FROM y.p

> - Format 2 — OpenEdge adds pool information to the Basic log entries when creating and deleting dynamic objects. OpenEdge logs this additional information:

> - Pool name — This is `<unnamed>`, `<Session Pool>`, or the name of a named pool.
> - `FROM` `routinename` — `routinename` is the name of the `.p` or `.w` file or method that created the object pool. OpenEdge logs this only when the pool is not persistent and not the `Session` Pool.

> Here are some sample log entries (with headers suppressed):

>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 3 4GL DYNOBJECTS Created
>     MENU               Handle:1098 (x.p Line 4) Pool:<unnamed> FROM x.p
>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 3 4GL DYNOBJECTS Created
>     MENU               Handle:1098 (x.p Line 4) Pool:<unnamed> FROM z.p
>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 3 4GL DYNOBJECTS Deleted
>     MENU               Handle:1098 (x.p Line 5) Pool:mywp FROM x.p
>     [05/10/31@14:07:15.892-0400] P-002702 T-002867 3 4GL DYNOBJECTS Deleted
>     MENU               Handle:1098 (x.p Line 5) Pool:myperswp FROM y.p

> The following excerpt is from a log file (with headers suppressed) showing an example of how the pool information relates to the other messages:

>     Creating pool  mypool  (x.p Line 2)
>     Created        MENU             Handle:1098 (x.p Line 4) Pool:mypool FROM x.p
>     Deleted        MENU             Handle:1098 (x.p Line 5)
>     Created        TOGGLE-BOX       Handle:1099 (x.p Line 7) Pool:mypool FROM x.p
>     Deleting pool  mypool  (x.p Line 9) FROM x.p
>     Deleted        TOGGLE-BOX       Handle:1099 (x.p Line 9) POOLDEL

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095