Evitare invio messaggi CLRPFM

[tom6]

Ciao a tutti.
Ho un CL, che viene richiamato centinaia di migliaia di volte, che
esegue delle CLRPFM di diversi file di comodo.
Per ogni CLRPFM ovviamente viene inviata alla cosa messaggi il messaggio
di completamento CPC3101 di gravità 00 "Eliminato il contenuto del
membro xxx del file yyy nella libreria zzz".
Di conseguenza il QSYSOPR viene tempestato di messaggi informativi
CPI2417 gravità 40 "Per la coda messaggi di lavoro per aaa/bbb/ccc è
stato eseguito il ritorno a capo".
Faccio presente che la coda messaggi è già impostata all'ampiezza
massima.
Vorrei evitare che il QSYSOPR fosse inquinato da messaggi che non sono
realmente anomalie (l'ideale sarebbe che a monte i messaggi di
completamento CLRPFM non venissero inviati alla coda messaggi).
Avete suggerimenti su come posso risolvere il problema?

[Danilo Cussini]

Post by tom6
Ho un CL, che viene richiamato centinaia di migliaia di volte, che
esegue delle CLRPFM di diversi file di comodo.
Per ogni CLRPFM ovviamente viene inviata alla cosa messaggi il messaggio
di completamento CPC3101 di gravità 00 "Eliminato il contenuto del
membro xxx del file yyy nella libreria zzz".
Di conseguenza il QSYSOPR viene tempestato di messaggi informativi
CPI2417 gravità 40 "Per la coda messaggi di lavoro per aaa/bbb/ccc è
stato eseguito il ritorno a capo".
Faccio presente che la coda messaggi è già impostata all'ampiezza
massima.
Vorrei evitare che il QSYSOPR fosse inquinato da messaggi che non sono
realmente anomalie (l'ideale sarebbe che a monte i messaggi di
completamento CLRPFM non venissero inviati alla coda messaggi).
Avete suggerimenti su come posso risolvere il problema?

RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

[tom6]

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?
Però non è proprio la stessa cosa...
La delete da sql non riorganizza il file come la CLRPFM (e per vari motivi
non posso modificare in *YES l'attributo REUSEDLT su tutti i file
coinvolti).

[Alex]

Post by tom6

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?
Però non è proprio la stessa cosa...
La delete da sql non riorganizza il file come la CLRPFM (e per vari motivi
non posso modificare in *YES l'attributo REUSEDLT su tutti i file
coinvolti).

oltre a probabili differenze di performance...

[Roberto Tempesti]

Post by tom6

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?
Però non è proprio la stessa cosa...
La delete da sql non riorganizza il file come la CLRPFM (e per vari motivi
non posso modificare in *YES l'attributo REUSEDLT su tutti i file
coinvolti).

Prova a compilare il programma con il parametro LOG(*NO)

[tom6]

Post by Roberto Tempesti
Prova a compilare il programma con il parametro LOG(*NO)

Anch'io pensavo potesse funzionare. In realtà così non scrive il joblob ma i
messaggi vengono inviati lo stesso alla coda...

[Danilo Cussini]

Post by tom6
Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?

Devi avere almeno una versione 7.

Post by tom6
Però non è proprio la stessa cosa...
La delete da sql non riorganizza il file come la CLRPFM (e per vari motivi
non posso modificare in *YES l'attributo REUSEDLT su tutti i file
coinvolti).

In determinate condizione la DELETE di tutte le righe viene tramutata dal
DB2 in una CLRPFM. Per la riorganizzazione puoi sempre arrangiarti con una
schedulazione notturna.

[CRPence]

Post by Danilo Cussini

Post by tom6

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE)
al posto di CLRPFM.

Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?

No need to use a system command to effect such a simple dynamic SQL
request. A QM Query [with replacement variables] could easily effect
that, as well a REXX procedure; e.g. the following QMQRY source and a
sample invocation:

DELETE FROM &LIBR/&FILE

STRQMQRY The_Query SETVAR((LIBR THE_LIB) (FILE THE_FILE))

Post by Danilo Cussini
Devi avere almeno una versione 7.

Deferring to the SQL DELETE without a WHERE clause has potential
issues, when contrasted with the Clear Physical File Member (CLRPFM).
First, there is no direct /member/ support for the SQL. Second, the SQL
honors overrides to the file name which is potentially problematic
[because the CLRPFM does not] but also the best means to direct the SQL
to the proper member; i.e. Override With Database File (OVRDBF)
specifying the label\file-name overridden to the intended file name and
to the specified Member (MBR), such as by a properly scoped override
request: OVRDBF MYTABLE TheLib/TheFile MBR(TheMbr) OVRSCOPE(as_required)

That work encapsulated in a CLP along with the Start QM Query
(STRQMQRY) request could work in a release prior to IBM i 7.1

Note: Although there is also support for members via the SQL ALIAS,
for temporary redirection the simplest and least costly means is the
override. If one were to desire\require permanent redirect established
at the cost of permanent objects [DDM device files], then the CREATE
ALIAS for each member is an option. The OP seems to suggest there are
many members being cleared, so that is probably not desirable.?

Note: I recall there was support added for the clear feature to
impact *ALL members in a file [IBM i 6.1?], to provide some support for
the SQL partitioned TABLE [which are implemented as database files with
multiple members]. I suppose if a set of multiple members being cleared
are at least in some cases every member of a file, then in those cases
there may be the option to effect CLRPFM TheFile MBR(*ALL)?

Post by Danilo Cussini

Post by tom6
Però non è proprio la stessa cosa...
La DELETE da SQL non riorganizza il file come la CLRPFM (e per vari
motivi non posso modificare in *YES l'attributo REUSEDLT su tutti i
file coinvolti).

In determinate condizione la DELETE di tutte le righe viene tramutata
dal DB2 in una CLRPFM. Per la riorganizzazione puoi sempre
arrangiarti con una schedulazione notturna.

Or even precede the SQL DELETE with an Allocate Object (ALCOBJ) of
the member and perform that then the DELETE [must be done without
isolation; i.e. COMMIT(*NONE), which is how the CLRPFM runs anyhow] and
finally the Reorganize Physical File Member (RGZPFM) all consecutively;
ensuring the lock along with lacking a WHERE clause for the DELETE
enhances the ability of the database SQL to perform the effective Clear
operation vs the actual I/O.

[tom6]

Post by Danilo Cussini
In determinate condizione la DELETE di tutte le righe viene tramutata dal
DB2 in una CLRPFM. Per la riorganizzazione puoi sempre arrangiarti con una
schedulazione notturna.

Si tratta di file di comodo di cui devo fare la clear centinaia di migliaia di
volte (cioè prima di richiamare il programma principale che li utilizza). La
RGZPFM notturna non è quindi applicabile.
Ho provato la DELETE ma i record cancellati rimangono comunque... Quali sono
le condizioni in cui la DELETE dovrebbe essere tramutata in CLRPFM?

[Danilo Cussini]

Post by tom6
Ho provato la DELETE ma i record cancellati rimangono comunque... Quali sono
le condizioni in cui la DELETE dovrebbe essere tramutata in CLRPFM?

Avrei detto che la tabella non deve essere registrata sul giornale, però Chuck
dice che basta non usare il commit.

[Danilo Cussini]

Post by tom6
Ho provato la DELETE ma i record cancellati rimangono comunque... Quali sono
le condizioni in cui la DELETE dovrebbe essere tramutata in CLRPFM?

Dal manuale SQL:

An SQL DELETE statement that does not contain a WHERE clause will delete all
rows of a table. In this case, the rows may be deleted using either a clear
operation (if not running under commitment control) or a change file operation
(if running under commitment control). If running under commitment control, the
deletes can still be committed or rolled back. This implementation will be much
faster than individually deleting each row, but individual journal entries for
each row will not be recorded in the journal. This technique will only be used
if all the following are true:

- The target table is not a view.
- A significant number of rows are being deleted.
- The job issuing the DELETE statement does not have an open cursor on the file
(not including pseudo-closed SQL cursors).
- No other job has a lock on the table.
- The table does not have an active delete trigger.
- The table is not the parent in a referential constraint with a CASCADE, SET
NULL, or SET DEFAULT delete rule.
- The user issuing the DELETE statement has *OBJMGT or *OBJALTER system
authority on the table in addition to the DELETE privilege.

[CRPence]

Post by tom6
Si tratta di file di comodo di cui devo fare la clear centinaia di
migliaia di volte (cioè prima di richiamare il programma principale
che li utilizza). La RGZPFM notturna non è quindi applicabile. Ho
provato la DELETE ma i record cancellati rimangono comunque... Quali
sono le condizioni in cui la DELETE dovrebbe essere tramutata in
CLRPFM?

The database file seems a suspect choice for the data in the
described scenario. Is the data actual row data for which relational
work is required? If relational, can there be a design change to add a
column that indicates if the row is /deleted/, such that the SQL UPDATE
can effectively /clear/ the file; enabling deferral of actual DELETE
[and effective reorg\clear] maintenance for later, perhaps scheduled?

[Dr.UgoGagliardelli]

Post by tom6

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

Non mi accetta il comando RUNSQL. Intendevi RUNSQLSTM?
Però non è proprio la stessa cosa...
La delete da sql non riorganizza il file come la CLRPFM (e per vari motivi
non posso modificare in *YES l'attributo REUSEDLT su tutti i file
coinvolti).

Puoi usare anche qsh, es.:
qsh cmd('db2 ''delete from tabella''')

[Danilo Cussini]

Post by Danilo Cussini
RUNSQL SQL('DELETE FROM MYTABLE') COMMIT(*NONE) al posto di CLRPFM.

E quando avrai una versione 7.2

The TRUNCATE TABLE statement is used for deleting all of the rows in a table
in one fell swoop. You can think of this statement as SQL's version of the
Clear Physical File Member (CLRPFM) command.

[CRPence]

Post by tom6
Ho un CL, che viene richiamato centinaia di migliaia di volte, che
esegue delle CLRPFM di diversi file di comodo.
Per ogni CLRPFM ovviamente viene inviata alla cosa messaggi il messaggio
di completamento CPC3101 di gravità 00 "Eliminato il contenuto del
membro xxx del file yyy nella libreria zzz".
Di conseguenza il QSYSOPR viene tempestato di messaggi informativi
CPI2417 gravità 40 "Per la coda messaggi di lavoro per aaa/bbb/ccc è
stato eseguito il ritorno a capo".
Faccio presente che la coda messaggi è già impostata all'ampiezza
massima.
Vorrei evitare che il QSYSOPR fosse inquinato da messaggi che non sono
realmente anomalie (l'ideale sarebbe che a monte i messaggi di
completamento CLRPFM non venissero inviati alla coda messaggi).
Avete suggerimenti su come posso risolvere il problema?

There are other /methods/ for which the same effect of the member
being cleared can be effected, but without that completion message; some
means to effect an alternate clear however, will have their own
message(s). For example one could use a /copy/ feature that has
something akin to the Member Option (MBROPT) parameter with an option of
Clear=Yes. The Data Management (DM) and the Database (DB) together
provide support for a "Clear upon open" feature, but at present I do not
recall what language(s) provide access to that method, however some
interfaces that might be available [depending on the definitional
attributes of the file] for writing to [stream or database] files could
suffice. For example, if a Physical File Member (PFM) is a Source PF
[PF-SRC] or a Program Described file [CRTPF RCDLEN(specified)], then the
Stream File methods could assist... and thus the file utilities in the
QSH [QSHELL] could suffice; probably there is even an effect clear
feature, but I can not recall a name for one. Any other utility that
can effect the clear for those files probably use a function that is
available to the C language, so even if nothing from the RPG, then with
ILE a private interface to effect the same as CLRPFM should be possible;
look at the Fopen() [and\or Ropen()] features for a clear option.

FWiW, the S/36 Environment might have an OCL\procedure.

[CRPence]

<<SNIP>> the file utilities in the QSH [QSHELL] could suffice;
probably there is even an effect clear feature, but I can not recall
a name for one. <<SNIP>>

For example [although to be clear, this is not a\my recommendation,
just to reveal an example of invoking an alternate method that provides
essentially identical function to the CLRPFM], the Rfile shell utility
can write the null standard input to a [database record] file, for which
the effect is the member cleared. Scripted such that there is just one
invocation of the QSH, only the message for completion of the QSHell
facility itself is logged. Here is an example of how that might be
accomplished for one member; i.e. not scripted, just one request asked
of the shell:

ovrdbf STDIN Empty_File ovrscope(*calllvl)

then to effect the clear of a named member using Rfile:

qsh cmd('Rfile -w /QSYS.LIB/the_lib.LIB/the_file.FILE/the_mbr.MBR')

or to effect clear of the MBR(*FIRST) using Rfile, perhaps:

qsh cmd('Rfile -w -Q the_lib/the_file')

Note: The syntax for specifying a member name when specifying the -Q
option to support "qualified name syntax for file names ... (instead of
Integrated File System path names)" requires enclosing either the fully
qualified name with the parenthetical member name, or just the
parenthetical member name in double quotes, or escaping the
left-parenthesis and the right-parenthesis with the backslash character;
e.g. one of the following in place of the file named in the above
without any member specification [for which *FIRST is cleared]:

• "the_lib/the_file(the_mbr)"
• the_lib/the_file"(clrme)"
• the_lib/the_file\(clrme\)

<<SNIP>> look at the Fopen() [and\or Ropen()] features for a clear option.

The _Ropen() and fopen() [and open() with O_TRUNC or with fclear() or
ftruncate()] might better implement a user-defined clear PFM function
without any messaging, to replace the CLRPFM. The former two open
features include /write/ _mode_ options that effect clearing a physical
file member. Programmed versus scripted is probably best, to allow some
granularity in handling issues; e.g. to diagnose an EBUSY for any one
member, whereas a scripted request likely allows only for terminating
the entire script upon encountering the first error or to
/trudge-onward/ irrespective of errors.

FWiW, the S/36 Environment might have an OCL\procedure.

There apparently is a CLRPF procedure; I have never used that, and do
not know about the messaging. Of course that requires the S/36EE exists
and likely [if not already running in that environment] to activate that
run-time environment; though I suppose not too different than having
deferred the work to the unix-like shell.

[Fabio Terrazzin]

Post by tom6
Ciao a tutti.
Ho un CL, che viene richiamato centinaia di migliaia di volte, che
esegue delle CLRPFM di diversi file di comodo.
Per ogni CLRPFM ovviamente viene inviata alla cosa messaggi il messaggio
di completamento CPC3101 di gravità 00 "Eliminato il contenuto del
membro xxx del file yyy nella libreria zzz".
Di conseguenza il QSYSOPR viene tempestato di messaggi informativi
CPI2417 gravità 40 "Per la coda messaggi di lavoro per aaa/bbb/ccc è
stato eseguito il ritorno a capo".

prova:

clrpfm zzz/yyy xxx
rcvmsg msgtype(*last) rmv(*yes)

[tom6]

Post by Fabio Terrazzin
clrpfm zzz/yyy xxx
rcvmsg msgtype(*last) rmv(*yes)

Funziona! Soluzione semplice ed efficace.
Grazie mille Fabio.
E grazie a tutti per i vostri consigli!

[RENEst]

Post by tom6
Ciao a tutti.
Ho un CL, che viene richiamato centinaia di migliaia di volte, che
esegue delle CLRPFM di diversi file di comodo.

Usare DELETE (SQL o RPG) su file REUSEDLT(*YES),
sempre che cio' sia compatibile con la logica della
tua procedura.