Re: Logical File Creation Running a long time....

DSPFD would not be functional against the target of an active CRTDUPOBJ. Thus why a LIC dump would be required.

I am not sure if the *QDDSI would have the number of entries updated [during the /create/], but if so, that would be easier to dump. The address to that object comes from DMPSYSOBJ, so start there for an easier path than navigating the objects within STRSST. It is not complex to perform nor to figure out, what is the entry count; probably even has "ENT" in the token that defines the "entry count" value in a formatted dump, and the value would be changing over time, whereas most everything else but SIZE would remain unchanged. Somebody with access to STRSST D/A/D could probably get a formatted dump of the first few pages of the DSI [dataspace index] of a keyed LFM [logical file member], similarly the IDX [LIC index], then add some entries to the DS [dataspace; e.g. by SQL INSERT INTO], then get new formatted dumps, and find the entry count from the changed data; repeat the same for a file being duplicated.

Regards, Chuck

On 24-May-2010 22:34, Vern Hamberg wrote:

Does DSPFD with number of entries in the LF give the same
information as dumping the LIC index object? I'm not sure how
many of us civilians would know where to look in there - I might
have a guess, but I don't really know. I would start with SST,
but after that I'd be lost, to be truthful.

And I haven't gone out to by the diagnostics manuals yet!!


CRPence wrote:

What does the quoted message have to do with RPG?

An index build at what run priority? How much CPU is the job
using? The only /problem/ with duplicating such an LF is
typically only from poor planning, either for limits or for
performance. Is the approximately 192GB available for the final
storage of the created logical file, along with significant
temporary storage and a good amount of memory available for the
index build activity? Is all other work running at a lower
priority to avoid stealing CPU from the index rebuild? What was
the index rebuild capabilities established within the job
before the CRTDUPOBJ request was started; i.e. per QQRYDEGREE
or a QRYDEGREE from a CHGQRYA [or if available, as established
from a default in the discouraged QAQQINI in QUSRSYS]? To check
the status of the index build, dump the LIC Index object
associated with the dataspace index object, and review the
index entries count; repeat again each minute over several
minutes to gauge a rate to predict when the request might
finish if not impacted by higher priority work.

On 24-May-2010 08:47, George Lopez wrote:

I am doing a CRTDUPOBJ for a logical file with a physical
file that is 413,346,539 (413+ million) records and it has
been running for more than 14 hours. Is there a problem with
doing this big of a LF? How do I know how far along this
CRTBUPOBJ has gone through the PF? I do not want to end this
in the middle of the process. Thank you.

*This is the command I submitted...*
CRTDUPOBJ CXMLVAL3 IGCQUADTA *FILE TOLIB(IGCPRDDTA)

*This is the time I entered it in the system...*
Entered system: Date: 05/23/10 Time: 14:17:57
Current date/time 05/24/10 06:36:11

*This is the field names of the CXMLVAL PF...*

Field Type Length Buffer Description

XMSRC A 4 1 XML Source
XMBT# P 4 0 5 Batch#
XMSTAT A 1 8 Status?
XMXMLN P 9 0 9 Line#
XMXMSL P 9 0 14 Secondary Line#
XMSCFD A 50 19 Field
XMXMVL A 400 69 XML Value
XMRTVL A 80 469 Return Value
XMXMER A 80 549 XML Error
XMXMWR A 80 629 XML Warning

This is the LF keys....
A********
A* LOGICAL FOR XML VALUE FILE
A********
A R CXMLVALR PFILE(CXMLVAL)
A K XMSRC
A K XMBT#
A K XMSTAT
A K XMSCFD
A K XMXMLN
A K XMXMVL
A K XMXMSL