Hello,
I've been using Dollar Universe for quite some time (back to V4) and was regularly running the IU_PUR / uxpurge purge. The job was launched every day to ensure $U data files would not grow out of control.
I have recently upgraded from V500 to V513 on Unix boxes and V500 to V523 on Windows boxes and I was now considering the use of the purge on the fly (online purge).
Have you any insight / recommendations / comments on the purge on the fly? Should I make the move?
Eric JT
3
1 votes
Solved : Purge : uxpurge (IU_PUR) vs Purge on the fly
Started by cartman, Apr 23 2008 10:16 AM
11 replies to this topic
#2
-
- Root Admin
-
- 4,387 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 14 May 2008 - 05:56 PM
Hello Eric,
the purge on the fly has a clear advantage : the load of the purge is spread over the whole day, and not concentrated on a short period of time.
However, the purge "uxpurge" allows to have different retention delays depending on the files to purge.
An enhancement of the purge on the fly has been accepted by Orsyp R&D to include this feature in a future version of Dollar Universe.
One important thing : some customers have asked if they could run both purges. Orsyp do not recommend it, but if you want to do so, the retention delays of the "uxpurge" must be higher than the ones of the purge on the fly to avoid creating data inconsitency.
So I guess you should make your choice depending on your IT operations constraints like the load generated by the uxpurge.
Hope this helps,
Michel
the purge on the fly has a clear advantage : the load of the purge is spread over the whole day, and not concentrated on a short period of time.
However, the purge "uxpurge" allows to have different retention delays depending on the files to purge.
An enhancement of the purge on the fly has been accepted by Orsyp R&D to include this feature in a future version of Dollar Universe.
One important thing : some customers have asked if they could run both purges. Orsyp do not recommend it, but if you want to do so, the retention delays of the "uxpurge" must be higher than the ones of the purge on the fly to avoid creating data inconsitency.
So I guess you should make your choice depending on your IT operations constraints like the load generated by the uxpurge.
Hope this helps,
Michel
#3
-
- Members
-
- 32 posts
Junior Member
- Gender:Male
- Location:Earth
Posted 15 May 2008 - 11:02 AM
men, on May 14 2008, 06:56 PM, said:
Hello Eric,
the purge on the fly has a clear advantage : the load of the purge is spread over the whole day, and not concentrated on a short period of time.
However, the purge "uxpurge" allows to have different retention delays depending on the files to purge.
An enhancement of the purge on the fly has been accepted by Orsyp R&D to include this feature in a future version of Dollar Universe.
One important thing : some customers have asked if they could run both purges. Orsyp do not recommend it, but if you want to do so, the retention delays of the "uxpurge" must be higher than the ones of the purge on the fly to avoid creating data inconsitency.
So I guess you should make your choice depending on your IT operations constraints like the load generated by the uxpurge.
Hope this helps,
Michel
the purge on the fly has a clear advantage : the load of the purge is spread over the whole day, and not concentrated on a short period of time.
However, the purge "uxpurge" allows to have different retention delays depending on the files to purge.
An enhancement of the purge on the fly has been accepted by Orsyp R&D to include this feature in a future version of Dollar Universe.
One important thing : some customers have asked if they could run both purges. Orsyp do not recommend it, but if you want to do so, the retention delays of the "uxpurge" must be higher than the ones of the purge on the fly to avoid creating data inconsitency.
So I guess you should make your choice depending on your IT operations constraints like the load generated by the uxpurge.
Hope this helps,
Michel
Heya Michel,
It surely does help. On some of our boxes the load generated by the uxpurge is quite important (high CPU usage), so I guess we'll give the purge on the fly a try.
Cheers,
Eric JT
#4
-
- Members
-
- 39 posts
Junior Member
- Gender:Female
Posted 04 July 2008 - 12:04 PM
Hello Eric,
how did you decide?
Our experience is that uxpurge purges more data in different files than purge-on-the-fly does.
That's why we are one of those customers who run both, though Orsyp does not recommend that. One side effect of running both is the following: Sometimes it happens that after reorganisation (ux_vrf_rgz_rst) prevously deleted entries are back.
We tolerate this as the disadvantage of running no uxpurge is much bigger: Files are growing too much (our biggest system has app. 15.00 jobs running per day...)
Regards
Monika
how did you decide?
Our experience is that uxpurge purges more data in different files than purge-on-the-fly does.
That's why we are one of those customers who run both, though Orsyp does not recommend that. One side effect of running both is the following: Sometimes it happens that after reorganisation (ux_vrf_rgz_rst) prevously deleted entries are back.
We tolerate this as the disadvantage of running no uxpurge is much bigger: Files are growing too much (our biggest system has app. 15.00 jobs running per day...)
Regards
Monika
#5
-
- Members
-
- 32 posts
Junior Member
- Gender:Male
- Location:Earth
Posted 23 July 2008 - 02:32 PM
Hello Monika,
we now run both purges but respecting the constraints given by Orsyp (retention delays of uxpurge set higher than the ones of the purge on the fly). No side-effects noticed so far, and the uxpurge does not have the CPU peaks it used to have on some boxes
Cheers,
Eric JT
we now run both purges but respecting the constraints given by Orsyp (retention delays of uxpurge set higher than the ones of the purge on the fly). No side-effects noticed so far, and the uxpurge does not have the CPU peaks it used to have on some boxes
Cheers,
Eric JT
#6
-
- Root Admin
-
- 4,387 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 23 October 2008 - 04:04 PM
Hello,
the online purge has been enhanced in V533 via FX24567 (please note it is not in General Availability yet).
Find below the information regarding this enhancements:
New online purge
The new build of online purge is not activated by default. It can be activated by the environment variable, U_IO_PURGE_ENABLE, set to Y in the uxsetenv files.
When activated, the online purge is composed of a dynamic purge performed by the launcher and of a non-dynamic purge performed cyclically by an IO server thread. These two purges use the same parameters that are defined for each area in a configuration file, u_purge_param.ref, that is located in data directory of the considered area.
For dynamic purge, the master purge file is the launch file,(u_fmsb). Purging a record in u_fmsb file triggers a purge of the
associated records in the dynamic files(u_fmcx, u_fmhs, u_fmph,u_fmfu, u_fmev, u_fmtp, u_fmsp, u_fmer, u_fmeq). As far as the dynamic purge is concerned, the retention criterias for the dynamic files are therefore those of the launch files.
Statuses purged by the dynamic purge are final statuses.
In the case of changes in the purge parameters file, the purge dates determined by the launcher are updated in order to ensure that the changes are taken into account.
The non-dynamic purge will delete the records that were not removed by the dynamic purge.
In that case the retention criterias are those of the launches file u_fmsb for the u_fmtp/u_fmsp/u_fmcm files ;those of the control file u_fmcx for the u_fmer/u_fmeq/management criterias files and those of the history file u_fmhs for the u_fmph/u_fmfu files.
It is the purge thread of the IO server that manages the reading of the purge parameter files. While the thread reads parameter files at regular intervals or if the loadPurParFic <SOC> <ESP> <NODE> binary is used; the IO server is queried by the launcher to retrieve the purge parameters so that the dynamic purge takes into account any update of the parameters. Upon detection of a modification the purge date is updated according to the new parameters.
The purge parameters file - located in UXDEX/UXDAP/UXDSI/UXDIN and named : u_purge_param.ref - is specific for each area.
The file's format is the following:
# for comments
Empty lignes are ignored
A significant line has the following format: PARAM=VAL
Available parameters are the followings:
PUR_DYN Y/N
Activate/Disable the "dynamic purge" part of the online purge
CHK_FIC DDD:HH:MM
check cycle of the purge parameter file default 001 :00 :00
PUR_CYC DDD:HH:MM
Non dynamic purge cycle performed by IO default --- :-- :--
PUR_HHMM HH:MM
The hour of the non dynamic purge performed by IO default 00 :01
PUR_LOG Y/N/F
Define the options of the purge's log
default N
PUR_FREEZE Y/N
Stop/Start the online purge default N
LAN_RET_DEF JJJ:HH:MM
Default retention time for the launches file default 007 :00 :00
LAN_RET_'XX' JJJ:HH:MM
Retention time specific to a status default LAN_RET_DEF
Possible status list
H Disabled status
D Started status
W Event wait status
R Refused status
WO Time Overrun status after at least one time condition check
LO Time Overrun status without any condition check
E Execution status in effect
A Pending execution status
I Aborted status
T Completed status
F Completion in progress status
CTL_RET_DEF JJJ:HH:MM
The retention time by default for the contol file default 007 :00 :00
CTL_RET_'XX' JJJ:HH:MM
The retention time specific to a status default CTL_RET_DEF
The possible status list :
D Started status
W Event Wait status
R Refused status
O Time Overrun status
E Running status
A Pending status
I Aborted status
T Completed status
F Completion in progress status
HST_RET_DEF DDD:HH:MM
Default retention time for history file
default 007 :00 :00
HST_RET_'XX' DDD:HH:MM
Default retention time for a status default HST_RET_DEF
The possible status list :
D Started status
W Event Wait status
R Refused status
O Time Overrun status
E Running status
A Pending status
I Aborted status
T Completed status
F Completion in progress
No parameter is mandatory. If a parameter is not defined the default value will be considered.
The default value is also considered if a parameter of DDD :HH :MM format is set as --- :-- :-- or if a parameter of HH :MM format is set as -- :--.
For the retention time, the zone defined as 000 :00 :00 means an infinite retention time.
In the case where the parameter file would be missing or if there is an issue to read or parse this file - the default values will be considered during the first loadi of the parameters and for the next loads the values that were already loaded will be retained.
PUR_CYC and PUR_HHMM are incompatible; one of the two parameters should be left to --- :-- :-- or -- :-- ;
If PUR_HHMM is used, the cycle of the IO purge is set to 1 day. And if PUR_CYC is defined, the first non-dynamic purge is triggered 1 minute after the load of the parameters; then the IO cycle purge is implemented.
For the u_fmcm file and the management criterias, the retention time that is considered is the biggest related retention time
in the file that is taken account, respectively launches and control files.
If the PUR_LOG parameter is put into Y, a log file is created for the relevant area, named u_purge.log. ( UXLEX, UXLAP, UXLIN, UXLSI respectively)
When set to Y, the list of the purge parameters is displayed for every load of the parameters and also during the startup of the non-dynamic purge.
When set to F (meaning full), the log file will also list the records deleted by the non-dynamic purge and also the list of records of the u_fmsb that are deleted by non-dynamic purge.
The chkPurParFic <file> binary allows for the verification of the correct syntax of the parameters file; the parsing stops at the first error and displays the line in error. chkPurParFic <help> displays the help facility for this binary.
The loadPurParFic <SOC> <ESP> <NODE> binary can be used to force the load of the parameters outside the normal
cycle of the parameters file load by IO. The loadPurParFic <help> binary displays the help facility for this binary.
Every time the parameter file is loaded, if the file has not been not modified, the loading does not trigger any update of the purge parameters; if the file syntax is incorrect, the purge parameters that are already loaded are retained. If PUR_CYC is defined, at every load, the non-dynamic purge will start up 1 minute after the load.
The non-dynamic purge will execute first in the case where the non-dynamic purge and the load of the parameters would be set to execute at the same time.
Examples of log with PUR_LOG into Y:
##### LOAD OF PURGE PARAMETERS ##### [20080619141700]
ENABLE [Y] / FREEZE [Y] / DYN [N] / LOG [d] / CHECK PARAM CYCLE [001:00:00] /
IO PURGE CYCLE [000:00:10] / IO PURGE HOUR [--:--]
CTL_RET_A 000:00:05
CTL_RET_D 000:00:05
CTL_RET_DEF007:00:00
CTL_RET_E 000:00:05
CTL_RET_F 000:00:05
CTL_RET_I 000:00:05
CTL_RET_O 000:00:05
CTL_RET_R 000:00:05
CTL_RET_T 000:00:05
CTL_RET_W 000:00:05
HST_RET_A 000:00:05
HST_RET_D 000:00:05
HST_RET_DEF007:00:00
HST_RET_E 000:00:05
HST_RET_F 000:00:05
HST_RET_I 000:00:05
HST_RET_O 000:00:05
HST_RET_R 000:00:05
HST_RET_T 000:00:05
HST_RET_W 000:00:05
LAN_RET_A 000:00:05
LAN_RET_D 000:00:05
LAN_RET_DEF007:00:00
LAN_RET_E 000:00:05
LAN_RET_F 000:00:05
LAN_RET_H 000:00:05
LAN_RET_I 000:00:05
LAN_RET_LO 000:00:05
LAN_RET_R 000:00:05
LAN_RET_T 000:00:05
LAN_RET_W 000:00:05
LAN_RET_WO 000:00:05
--------------------------------------------
##### START OF IO PURGE [20080619141800] #####
CTL_RET_A 000:00:05
CTL_RET_D 000:00:05
CTL_RET_DEF007:00:00
CTL_RET_E 000:00:05
CTL_RET_F 000:00:05
CTL_RET_I 000:00:05
CTL_RET_O 000:00:05
CTL_RET_R 000:00:05
CTL_RET_T 000:00:05
CTL_RET_W 000:00:05
HST_RET_A 000:00:05
HST_RET_D 000:00:05
HST_RET_DEF007:00:00
HST_RET_E 000:00:05
HST_RET_F 000:00:05
HST_RET_I 000:00:05
HST_RET_O 000:00:05
HST_RET_R 000:00:05
HST_RET_T 000:00:05
HST_RET_W 000:00:05
LAN_RET_A 000:00:05
LAN_RET_D 000:00:05
LAN_RET_DEF007:00:00
LAN_RET_E 000:00:05
LAN_RET_F 000:00:05
LAN_RET_H 000:00:05
LAN_RET_I 000:00:05
LAN_RET_LO 000:00:05
LAN_RET_R 000:00:05
LAN_RET_T 000:00:05
LAN_RET_W 000:00:05
LAN_RET_WO 000:00:05
--------------------------------------------
##### END OF IO PURGE [20080619141800] #####
--------------------------------------------
Examples of log with PUR_LOG into F:
[SIO] [HS] [ ]/[000] [PURGE_OK ]/[000] [MUPURGE ] [T]
[0000000]/[0000147]/[0000174] [20080619140601]
[LAN] [SB] [ ]/[000] [PURGE_OK ]/[000] [CALPMFSO ] [T]
[0000000]/[0000236]/[0000279] [20080619143432]
[SIO] / [LAN] Part that performs the purge
[HS] / [CX] / [SB] Considered file
[ ]/[000] Session / Session's number
[PURGE_OK ]/[000] Uproc / Uproc's number
[MUPURGE ] MU
[T] Status
[0000000]/[0000147]/[0000174] session's number/uproc's number/launch's number
[20080619140601] purge date YYYYMMDDHHMMSS
the online purge has been enhanced in V533 via FX24567 (please note it is not in General Availability yet).
Find below the information regarding this enhancements:
New online purge
The new build of online purge is not activated by default. It can be activated by the environment variable, U_IO_PURGE_ENABLE, set to Y in the uxsetenv files.
When activated, the online purge is composed of a dynamic purge performed by the launcher and of a non-dynamic purge performed cyclically by an IO server thread. These two purges use the same parameters that are defined for each area in a configuration file, u_purge_param.ref, that is located in data directory of the considered area.
For dynamic purge, the master purge file is the launch file,(u_fmsb). Purging a record in u_fmsb file triggers a purge of the
associated records in the dynamic files(u_fmcx, u_fmhs, u_fmph,u_fmfu, u_fmev, u_fmtp, u_fmsp, u_fmer, u_fmeq). As far as the dynamic purge is concerned, the retention criterias for the dynamic files are therefore those of the launch files.
Statuses purged by the dynamic purge are final statuses.
In the case of changes in the purge parameters file, the purge dates determined by the launcher are updated in order to ensure that the changes are taken into account.
The non-dynamic purge will delete the records that were not removed by the dynamic purge.
In that case the retention criterias are those of the launches file u_fmsb for the u_fmtp/u_fmsp/u_fmcm files ;those of the control file u_fmcx for the u_fmer/u_fmeq/management criterias files and those of the history file u_fmhs for the u_fmph/u_fmfu files.
It is the purge thread of the IO server that manages the reading of the purge parameter files. While the thread reads parameter files at regular intervals or if the loadPurParFic <SOC> <ESP> <NODE> binary is used; the IO server is queried by the launcher to retrieve the purge parameters so that the dynamic purge takes into account any update of the parameters. Upon detection of a modification the purge date is updated according to the new parameters.
The purge parameters file - located in UXDEX/UXDAP/UXDSI/UXDIN and named : u_purge_param.ref - is specific for each area.
The file's format is the following:
# for comments
Empty lignes are ignored
A significant line has the following format: PARAM=VAL
Available parameters are the followings:
PUR_DYN Y/N
Activate/Disable the "dynamic purge" part of the online purge
CHK_FIC DDD:HH:MM
check cycle of the purge parameter file default 001 :00 :00
PUR_CYC DDD:HH:MM
Non dynamic purge cycle performed by IO default --- :-- :--
PUR_HHMM HH:MM
The hour of the non dynamic purge performed by IO default 00 :01
PUR_LOG Y/N/F
Define the options of the purge's log
default N
PUR_FREEZE Y/N
Stop/Start the online purge default N
LAN_RET_DEF JJJ:HH:MM
Default retention time for the launches file default 007 :00 :00
LAN_RET_'XX' JJJ:HH:MM
Retention time specific to a status default LAN_RET_DEF
Possible status list
H Disabled status
D Started status
W Event wait status
R Refused status
WO Time Overrun status after at least one time condition check
LO Time Overrun status without any condition check
E Execution status in effect
A Pending execution status
I Aborted status
T Completed status
F Completion in progress status
CTL_RET_DEF JJJ:HH:MM
The retention time by default for the contol file default 007 :00 :00
CTL_RET_'XX' JJJ:HH:MM
The retention time specific to a status default CTL_RET_DEF
The possible status list :
D Started status
W Event Wait status
R Refused status
O Time Overrun status
E Running status
A Pending status
I Aborted status
T Completed status
F Completion in progress status
HST_RET_DEF DDD:HH:MM
Default retention time for history file
default 007 :00 :00
HST_RET_'XX' DDD:HH:MM
Default retention time for a status default HST_RET_DEF
The possible status list :
D Started status
W Event Wait status
R Refused status
O Time Overrun status
E Running status
A Pending status
I Aborted status
T Completed status
F Completion in progress
No parameter is mandatory. If a parameter is not defined the default value will be considered.
The default value is also considered if a parameter of DDD :HH :MM format is set as --- :-- :-- or if a parameter of HH :MM format is set as -- :--.
For the retention time, the zone defined as 000 :00 :00 means an infinite retention time.
In the case where the parameter file would be missing or if there is an issue to read or parse this file - the default values will be considered during the first loadi of the parameters and for the next loads the values that were already loaded will be retained.
PUR_CYC and PUR_HHMM are incompatible; one of the two parameters should be left to --- :-- :-- or -- :-- ;
If PUR_HHMM is used, the cycle of the IO purge is set to 1 day. And if PUR_CYC is defined, the first non-dynamic purge is triggered 1 minute after the load of the parameters; then the IO cycle purge is implemented.
For the u_fmcm file and the management criterias, the retention time that is considered is the biggest related retention time
in the file that is taken account, respectively launches and control files.
If the PUR_LOG parameter is put into Y, a log file is created for the relevant area, named u_purge.log. ( UXLEX, UXLAP, UXLIN, UXLSI respectively)
When set to Y, the list of the purge parameters is displayed for every load of the parameters and also during the startup of the non-dynamic purge.
When set to F (meaning full), the log file will also list the records deleted by the non-dynamic purge and also the list of records of the u_fmsb that are deleted by non-dynamic purge.
The chkPurParFic <file> binary allows for the verification of the correct syntax of the parameters file; the parsing stops at the first error and displays the line in error. chkPurParFic <help> displays the help facility for this binary.
The loadPurParFic <SOC> <ESP> <NODE> binary can be used to force the load of the parameters outside the normal
cycle of the parameters file load by IO. The loadPurParFic <help> binary displays the help facility for this binary.
Every time the parameter file is loaded, if the file has not been not modified, the loading does not trigger any update of the purge parameters; if the file syntax is incorrect, the purge parameters that are already loaded are retained. If PUR_CYC is defined, at every load, the non-dynamic purge will start up 1 minute after the load.
The non-dynamic purge will execute first in the case where the non-dynamic purge and the load of the parameters would be set to execute at the same time.
Examples of log with PUR_LOG into Y:
##### LOAD OF PURGE PARAMETERS ##### [20080619141700]
ENABLE [Y] / FREEZE [Y] / DYN [N] / LOG [d] / CHECK PARAM CYCLE [001:00:00] /
IO PURGE CYCLE [000:00:10] / IO PURGE HOUR [--:--]
CTL_RET_A 000:00:05
CTL_RET_D 000:00:05
CTL_RET_DEF007:00:00
CTL_RET_E 000:00:05
CTL_RET_F 000:00:05
CTL_RET_I 000:00:05
CTL_RET_O 000:00:05
CTL_RET_R 000:00:05
CTL_RET_T 000:00:05
CTL_RET_W 000:00:05
HST_RET_A 000:00:05
HST_RET_D 000:00:05
HST_RET_DEF007:00:00
HST_RET_E 000:00:05
HST_RET_F 000:00:05
HST_RET_I 000:00:05
HST_RET_O 000:00:05
HST_RET_R 000:00:05
HST_RET_T 000:00:05
HST_RET_W 000:00:05
LAN_RET_A 000:00:05
LAN_RET_D 000:00:05
LAN_RET_DEF007:00:00
LAN_RET_E 000:00:05
LAN_RET_F 000:00:05
LAN_RET_H 000:00:05
LAN_RET_I 000:00:05
LAN_RET_LO 000:00:05
LAN_RET_R 000:00:05
LAN_RET_T 000:00:05
LAN_RET_W 000:00:05
LAN_RET_WO 000:00:05
--------------------------------------------
##### START OF IO PURGE [20080619141800] #####
CTL_RET_A 000:00:05
CTL_RET_D 000:00:05
CTL_RET_DEF007:00:00
CTL_RET_E 000:00:05
CTL_RET_F 000:00:05
CTL_RET_I 000:00:05
CTL_RET_O 000:00:05
CTL_RET_R 000:00:05
CTL_RET_T 000:00:05
CTL_RET_W 000:00:05
HST_RET_A 000:00:05
HST_RET_D 000:00:05
HST_RET_DEF007:00:00
HST_RET_E 000:00:05
HST_RET_F 000:00:05
HST_RET_I 000:00:05
HST_RET_O 000:00:05
HST_RET_R 000:00:05
HST_RET_T 000:00:05
HST_RET_W 000:00:05
LAN_RET_A 000:00:05
LAN_RET_D 000:00:05
LAN_RET_DEF007:00:00
LAN_RET_E 000:00:05
LAN_RET_F 000:00:05
LAN_RET_H 000:00:05
LAN_RET_I 000:00:05
LAN_RET_LO 000:00:05
LAN_RET_R 000:00:05
LAN_RET_T 000:00:05
LAN_RET_W 000:00:05
LAN_RET_WO 000:00:05
--------------------------------------------
##### END OF IO PURGE [20080619141800] #####
--------------------------------------------
Examples of log with PUR_LOG into F:
[SIO] [HS] [ ]/[000] [PURGE_OK ]/[000] [MUPURGE ] [T]
[0000000]/[0000147]/[0000174] [20080619140601]
[LAN] [SB] [ ]/[000] [PURGE_OK ]/[000] [CALPMFSO ] [T]
[0000000]/[0000236]/[0000279] [20080619143432]
[SIO] / [LAN] Part that performs the purge
[HS] / [CX] / [SB] Considered file
[ ]/[000] Session / Session's number
[PURGE_OK ]/[000] Uproc / Uproc's number
[MUPURGE ] MU
[T] Status
[0000000]/[0000147]/[0000174] session's number/uproc's number/launch's number
[20080619140601] purge date YYYYMMDDHHMMSS
#7
-
- Members
-
- 39 posts
Junior Member
- Gender:Female
Posted 06 November 2008 - 03:03 PM
Hello Michel,
could you please help me define this new io purge to avoid inconsistencies with dynamic purge?
Dynamic purge:
U_DYNAMIC_PURGE=Y
export U_DYNAMIC_PURGE
U_RETENTION_DELAY=007:00:00
export U_RETENTION_DELAY
U_RETENTION_DELAY_COMPLETED=001:12:00
export U_RETENTION_DELAY_COMPLETED
U_RETENTION_DELAY_ABORTED=000:00:00
export U_RETENTION_DELAY_ABORTED
U_RETENTION_DELAY_REFUSED=001:00:00
export U_RETENTION_DELAY_REFUSED
U_RETENTION_DELAY_TIME_OVERRUN=001:00:00
export U_RETENTION_DELAY_TIME_OVERRUN
U_RETENTION_DELAY_SUSPENDED=001:00:00
export U_RETENTION_DELAY_SUSPENDED
U_PURGE_NOLAUNCH=Y
export U_PURGE_NOLAUNCH
How has io purge to be defined?
Thanks for your help.
Monika
could you please help me define this new io purge to avoid inconsistencies with dynamic purge?
Dynamic purge:
U_DYNAMIC_PURGE=Y
export U_DYNAMIC_PURGE
U_RETENTION_DELAY=007:00:00
export U_RETENTION_DELAY
U_RETENTION_DELAY_COMPLETED=001:12:00
export U_RETENTION_DELAY_COMPLETED
U_RETENTION_DELAY_ABORTED=000:00:00
export U_RETENTION_DELAY_ABORTED
U_RETENTION_DELAY_REFUSED=001:00:00
export U_RETENTION_DELAY_REFUSED
U_RETENTION_DELAY_TIME_OVERRUN=001:00:00
export U_RETENTION_DELAY_TIME_OVERRUN
U_RETENTION_DELAY_SUSPENDED=001:00:00
export U_RETENTION_DELAY_SUSPENDED
U_PURGE_NOLAUNCH=Y
export U_PURGE_NOLAUNCH
How has io purge to be defined?
Thanks for your help.
Monika
#8
-
- Root Admin
-
- 4,387 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 07 November 2008 - 03:47 PM
Hello Monika,
with the info you provided, you have to:
1/ define and export the following variable in the uxsetenv* files on Unix and in the uxsetenv.bat & UNIVERSE.def & 'Company'.def files
U_IO_PURGE_ENABLE to Y
2/ in a new file u_purge_param.ref to be in the data directory of each concerned area (UXDEX/UXDSI/UXDIN/UXDAP):
PUR_DYN=Y
CHK_FIC=001:00:00 (check cycle of the purge settings file, ex: 1 day)
PUR_CYC=JJJ:HH:MM (choose the cycle you want for the non dynamic purge or set to --- :-- :--, which is the default)
PUR_HHMM=HH:MM (choose the time of the non dynamic purge or set to -- :--, default is 00 :01)
Just give a value to one of the 2 preceding variables Choose to set only one of them - as they are incompatible - the other must only contain the "-".
PUR_LOG=Y (or N or F) if you want (or don't want) to log the purge activity (F will list all purged records)
PUR_FREEZE=N
LAN_RET_DEF=JJJ:HH:MM (set your general retention cycle for Launches, ex : 007:00:00)
LAN_RET_H=JJJ:HH:MM (set your retention cycle for Disabled/Held Launches, ex : 001:00:00)
LAN_RET_D=JJJ:HH:MM (set your retention cycle for Started Launches, ex : 001:00:00 or 000:00:00)
LAN_RET_W=JJJ:HH:MM (set your retention cycle for Event Wait Launches, ex : 001:00:00 or possibly more!)
LAN_RET_R=JJJ:HH:MM (set your retention cycle for Refused Launches, ex : 001:00:00)
LAN_RET_WO=JJJ:HH:MM (set your retention cycle for Time Overrun Launches (after having been in Event Wait), ex : 001:00:00)
LAN_RET_LO=JJJ:HH:MM (set your retention cycle for Time Overrun Launches (which have not been in Event Wait before), ex : 001:00:00)
LAN_RET_R=JJJ:HH:MM (set your retention cycle for Executing Launches, ex : 001:00:00 or possibly more! or or 000:00:00)
LAN_RET_A=JJJ:HH:MM (set your retention cycle for Pending Launches, ex : 001:00:00 or 000:00:00)
LAN_RET_I=JJJ:HH:MM (set your retention cycle for Aborted Launches, ex : 000:00:00)
LAN_RET_T=JJJ:HH:MM (set your retention cycle for Completed Launches, ex : 001:12:00)
LAN_RET_F=JJJ:HH:MM (set your retention cycle for Finishing Launches, ex : 001:12:00 or 000:00:00)
Then you have to do the same for the Execution file (fmcx, Job monitor and associated files) through variables
CTL_RET_DEF=JJJ:HH:MM
and
CTL_RET_'XX'=JJJ:HH:MM
where XX is
D
W
R
O
E
A
I
T
F
as above (O being for Time Overrun jobs)
and the same for the history file
HST_RET_DEF=JJJ:HH:MM
and
HST_RET_'XX'=JJJ:HH:MM
with XX being the same as for the Execution!
Hope this helps!
Michel
with the info you provided, you have to:
1/ define and export the following variable in the uxsetenv* files on Unix and in the uxsetenv.bat & UNIVERSE.def & 'Company'.def files
U_IO_PURGE_ENABLE to Y
2/ in a new file u_purge_param.ref to be in the data directory of each concerned area (UXDEX/UXDSI/UXDIN/UXDAP):
PUR_DYN=Y
CHK_FIC=001:00:00 (check cycle of the purge settings file, ex: 1 day)
PUR_CYC=JJJ:HH:MM (choose the cycle you want for the non dynamic purge or set to --- :-- :--, which is the default)
PUR_HHMM=HH:MM (choose the time of the non dynamic purge or set to -- :--, default is 00 :01)
Just give a value to one of the 2 preceding variables Choose to set only one of them - as they are incompatible - the other must only contain the "-".
PUR_LOG=Y (or N or F) if you want (or don't want) to log the purge activity (F will list all purged records)
PUR_FREEZE=N
LAN_RET_DEF=JJJ:HH:MM (set your general retention cycle for Launches, ex : 007:00:00)
LAN_RET_H=JJJ:HH:MM (set your retention cycle for Disabled/Held Launches, ex : 001:00:00)
LAN_RET_D=JJJ:HH:MM (set your retention cycle for Started Launches, ex : 001:00:00 or 000:00:00)
LAN_RET_W=JJJ:HH:MM (set your retention cycle for Event Wait Launches, ex : 001:00:00 or possibly more!)
LAN_RET_R=JJJ:HH:MM (set your retention cycle for Refused Launches, ex : 001:00:00)
LAN_RET_WO=JJJ:HH:MM (set your retention cycle for Time Overrun Launches (after having been in Event Wait), ex : 001:00:00)
LAN_RET_LO=JJJ:HH:MM (set your retention cycle for Time Overrun Launches (which have not been in Event Wait before), ex : 001:00:00)
LAN_RET_R=JJJ:HH:MM (set your retention cycle for Executing Launches, ex : 001:00:00 or possibly more! or or 000:00:00)
LAN_RET_A=JJJ:HH:MM (set your retention cycle for Pending Launches, ex : 001:00:00 or 000:00:00)
LAN_RET_I=JJJ:HH:MM (set your retention cycle for Aborted Launches, ex : 000:00:00)
LAN_RET_T=JJJ:HH:MM (set your retention cycle for Completed Launches, ex : 001:12:00)
LAN_RET_F=JJJ:HH:MM (set your retention cycle for Finishing Launches, ex : 001:12:00 or 000:00:00)
Then you have to do the same for the Execution file (fmcx, Job monitor and associated files) through variables
CTL_RET_DEF=JJJ:HH:MM
and
CTL_RET_'XX'=JJJ:HH:MM
where XX is
D
W
R
O
E
A
I
T
F
as above (O being for Time Overrun jobs)
and the same for the history file
HST_RET_DEF=JJJ:HH:MM
and
HST_RET_'XX'=JJJ:HH:MM
with XX being the same as for the Execution!
Hope this helps!
Michel
#9
-
- Members
-
- 39 posts
Junior Member
- Gender:Female
Posted 10 November 2008 - 03:49 PM
Hello Michel,
I defined what you described. In log file uxioserv.log I received an error message:
u_parsePurgeFileParam : syntax error in [CTL_RET_H=001:00:00]
u_loadFilePurgeParam : parsing of purge parameters file in error [-1]
u_loadFilePurgeParam : assuming default purge parameters
When I looked at the sample file, I recognised that neither launch nor ctl or history parameters use "H".
What happens to disabled launches then?
Thanks a lot
Monika
I defined what you described. In log file uxioserv.log I received an error message:
u_parsePurgeFileParam : syntax error in [CTL_RET_H=001:00:00]
u_loadFilePurgeParam : parsing of purge parameters file in error [-1]
u_loadFilePurgeParam : assuming default purge parameters
When I looked at the sample file, I recognised that neither launch nor ctl or history parameters use "H".
What happens to disabled launches then?
Thanks a lot
Monika
#10
-
- Root Admin
-
- 4,387 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 10 November 2008 - 05:04 PM
Hallo Monika!
Ha! Ha!
Let me double-check this and come back to you asap.
Michel
Ha! Ha!
Let me double-check this and come back to you asap.
Michel
#11
-
- Root Admin
-
- 4,387 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 10 November 2008 - 05:27 PM
Well Monika,
your remark caused me to have doubts about "H" being available for the 3 categories and not only for Launches.
So I got in touch with the Maintenance team, and they confirmed what I suspected: "H" is indeed possible but only for launches, through LAN_RET_H.
I will create an internal Document Enhancement ticket so the documentation is fixed, and I have made the appropriate changes in this thread
Michel
your remark caused me to have doubts about "H" being available for the 3 categories and not only for Launches.
So I got in touch with the Maintenance team, and they confirmed what I suspected: "H" is indeed possible but only for launches, through LAN_RET_H.
I will create an internal Document Enhancement ticket so the documentation is fixed, and I have made the appropriate changes in this thread
Michel
#12
-
- Members
-
- 39 posts
Junior Member
- Gender:Female
Posted 10 November 2008 - 05:33 PM
Hi Michel,
thanks a lot.
Best regards
Monika
thanks a lot.
Best regards
Monika
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
