Wrkprb needs long time to start - Revision history

PoC: Typo

2020-07-25T10:57:32Z

Typo

← Older revision		Revision as of 12:57, 25 July 2020
Line 1:		Line 1:
	Over time, it might become apparent that '''Wrkprb needs longer time to start''', especially if the problem handling facility was used heavily on a slow machine.<ref>Like a 150.</ref>		Over time, it might become apparent that '''Wrkprb needs longer time to start''', especially if the problem handling facility was used heavily on a slow machine.<ref>Like a 150.</ref>

	This stems from the fact that the used database files grow indefinitely, because they were created with the flag ''REUSEDLT'' disabled. That means, deleted records stay forever, but cannot be accessed. In my case, the PF ~~hat~~ 36 MiB, and the accompanying LF 24 MiB.		This stems from the fact that the used database files grow indefinitely, because they were created with the flag ''REUSEDLT'' disabled. That means, deleted records stay forever, but cannot be accessed. In my case, the PF had 36 MiB, and the accompanying LF 24 MiB.

	A possible solution would be to use ''RGZPFM'' to reorganise the database file. But the command refuses to work on an empty database file.<ref>One with no records, that is.</ref>		A possible solution would be to use ''RGZPFM'' to reorganise the database file. But the command refuses to work on an empty database file.<ref>One with no records, that is.</ref>

PoC: 1150

2020-07-25T10:56:15Z

1150

← Older revision		Revision as of 12:56, 25 July 2020
Line 1:		Line 1:
	Over time, it might become apparent that '''Wrkprb needs longer time to start''', especially if the problem handling facility was used heavily.		Over time, it might become apparent that '''Wrkprb needs longer time to start''', especially if the problem handling facility was used heavily on a slow machine.<ref>Like a 150.</ref>

	This stems from the fact that the used database files grow indefinitely, because they were created with the flag ''REUSEDLT'' disabled. That means, deleted records stay forever, but cannot be accessed. In my case, the PF hat 36 MiB, and the accompanying LF 24 MiB.		This stems from the fact that the used database files grow indefinitely, because they were created with the flag ''REUSEDLT'' disabled. That means, deleted records stay forever, but cannot be accessed. In my case, the PF hat 36 MiB, and the accompanying LF 24 MiB.

PoC: New

2020-07-24T13:37:50Z

New

New page

Over time, it might become apparent that '''Wrkprb needs longer time to start''', especially if the problem handling facility was used heavily.

This stems from the fact that the used database files grow indefinitely, because they were created with the flag ''REUSEDLT'' disabled. That means, deleted records stay forever, but cannot be accessed. In my case, the PF hat 36 MiB, and the accompanying LF 24 MiB.

A possible solution would be to use ''RGZPFM'' to reorganise the database file. But the command refuses to work on an empty database file.<ref>One with no records, that is.</ref>

Another possibility is to delete and recreate the ''members'' of the files in question. Members are bound to the record structure laid out in the file itself. So deleting and re-adding file members does no harm except getting rid of all the deleted records.

RMVM FILE(QUSRSYS/QASXPROB2) MBR(QASXPROB2)
RMVM FILE(QUSRSYS/QASXPROB) MBR(QASXPROB)
ADDPFM FILE(QUSRSYS/QASXPROB) MBR(QASXPROB)
ADDLFM FILE(QUSRSYS/QASXPROB2) MBR(QASXPROB2)

To prevent this from happening again, allow the OS to reuse allocated space.

CHGPF FILE(QUSRSYS/QASXPROB) REUSEDLT(*YES)<ref>Since there's no ''reusedlt'' parameter for ''CHGLF'', I wonder why the index needed so much space.</ref>

This approach applies also to any other database file showing significant slowdown over time.

== Footnotes ==
<references />

[[Category: System Administration‏‎]]