QASJSNDHST CPA5305 - IBM AS400

This is a discussion on QASJSNDHST CPA5305 - IBM AS400 ; So my QASJSNDHST file was full and we cleared it to make the CPA5305 message go away following instructions here: http://www-1.ibm.com/support/docview...256f74005173d6 Q. What is this file and why was it full, is my question, and one I can't seem to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: QASJSNDHST CPA5305

  1. QASJSNDHST CPA5305

    So my QASJSNDHST file was full and we cleared it to make the CPA5305 message
    go away following instructions here:

    http://www-1.ibm.com/support/docview...256f74005173d6

    Q. What is this file and why was it full, is my question, and one I can't
    seem to get Google to answer.

    Running V5R4.

    Thanks,
    -Bob



  2. Re: QASJSNDHST CPA5305

    On Aug 20, 11:03*am, "just bob" wrote:
    > So my QASJSNDHST file was full and we cleared it to make the CPA5305 message
    > go away following instructions here:
    >
    > http://www-1.ibm.com/support/docview...a8ad48dbcc8625....
    >
    > Q. What is this file and why was it full, is my question, and one I can't
    > seem to get Google to answer.
    >
    > Running V5R4.
    >
    > Thanks,
    > -Bob


    Bob, must be a history file for service agent. According to the link
    under V5R4 you should not have any issues.

  3. Re: QASJSNDHST CPA5305

    just bob wrote:
    > So my QASJSNDHST file was full and we cleared it to make the
    > CPA5305 message go away following instructions here:
    > http://www-1.ibm.com/support/docview...256f74005173d6
    >
    > Q. What is this file and why was it full, is my question, and one I
    > can't seem to get Google to answer.
    >
    > Running V5R4.


    I infer from its name that the database file object is a Service
    Agent file holding a History of Send activity. See the GO SERVICE
    option-3 for its /send/ option; a scheduled QS9SACOL inventory data
    collection for QSRVAGT or QINVCOL may be what /Send/ History is being
    tracked [for PM/400]. DSPSRVAGT TYPE(*SRVINF) apparently shows what is
    in the file QASJSNDHST.

    The file is used as part of Electronic Service Agent processing. The
    error message is a side effect of a _poor design_ of that feature. The
    file should be defined with SIZE(*NOMAX) and the OS software component
    [SJ; Q=System, A=DatabaseFile, SJ=component] should provide an automated
    and manual methods to control the number of rows in the file. Although
    the file may intend to /roll/ data on a 30-day interval, the file does
    not use its own row-delete & reuse, nor the database reuse delete record
    feature [until IBM i 6.1?]. Deleted rows count against the SIZE() limit
    for the number of rows in the file.member. Some OS components add their
    files to the /Cleanup/ function to attempt to avoid taking too much
    storage, while mostly having SIZE(*NOMAX) to prevent reaching a defined
    numeric limit on the number of rows. Other features may provide an
    interface to trim and/or reorganize the data.

    I am not sure why the recovery noted in the support document suggests
    CLRPFM instead of RGZPFM, except to avoid verification that there are
    deleted rows which can be recovered; i.e. not sure why removing active
    rows is acceptable, since that seems to defeat the point in actually
    having maintained them in the first place.? Then to prevent recurrence
    the file probably can be changed using CHGPF to activate the REUSEDLT()
    feature; as alluded may be the new setting on the file for IBM i 6.1.

    Regards, Chuck

  4. Re: QASJSNDHST CPA5305

    Option three on my model 810 gived me "3. Authorize users to access service
    information "

    Sorry I do not know the system well enough to know which option you meant.

    I woudl like to be able to view the file and review the entries.

    Here is an email IBM sent us to deal with it.


    PROBLEM SUMMARY:
    When the QASJSNDHST file is created the maximum number of
    records is 10000 and the REUSEDLT parameter is set to *NO so
    when the QASJSNDHST is rewritten it does not reuse the deleted
    records.

    PROBLEM CONCLUSION:
    Service Agent code will be modified to add parameter REUSEDLT
    set to *YES when the QASJSNDHST file is created... This will be

    completed in a future release

    TEMPORARY FIX:

    COMMENTS:

    MODULES/MACROS:
    RCHMGR

    SRLS:
    NONE

    RTN CODES:

    APPLICABLE COMPONENT LEVEL/SU:
    R530 PSY UP
    R540 PSY UP

    CIRCUMVENTION:
    If the CPA5305 message related to the QASJSNDHST file is being
    received, run the command CHGPF FILE(QASJSNDHST) REUSEDLT(*YES)
    hit F4 for prompt and put in the libraries of qsrvagt and qsys individually.

    MESSAGE TO SUBMITTER:

    ERROR DESCRIPTION:



    Benjamin W. Rabe
    Software Engineer
    IBM Rochester Support Center
    IBM i High Availability Solutions


    "CRPence" wrote in message
    news:lrYqk.24$Jk1.2@newsfe01.iad...
    > just bob wrote:
    >> So my QASJSNDHST file was full and we cleared it to make the
    >> CPA5305 message go away following instructions here:
    >> http://www-1.ibm.com/support/docview...256f74005173d6
    >>
    >> Q. What is this file and why was it full, is my question, and one I
    >> can't seem to get Google to answer.
    >>
    >> Running V5R4.

    >
    > I infer from its name that the database file object is a Service Agent
    > file holding a History of Send activity. See the GO SERVICE option-3 for
    > its /send/ option; a scheduled QS9SACOL inventory data collection for
    > QSRVAGT or QINVCOL may be what /Send/ History is being tracked [for
    > PM/400]. DSPSRVAGT TYPE(*SRVINF) apparently shows what is in the file
    > QASJSNDHST.
    >
    > The file is used as part of Electronic Service Agent processing. The
    > error message is a side effect of a _poor design_ of that feature. The
    > file should be defined with SIZE(*NOMAX) and the OS software component
    > [SJ; Q=System, A=DatabaseFile, SJ=component] should provide an automated
    > and manual methods to control the number of rows in the file. Although
    > the file may intend to /roll/ data on a 30-day interval, the file does not
    > use its own row-delete & reuse, nor the database reuse delete record
    > feature [until IBM i 6.1?]. Deleted rows count against the SIZE() limit
    > for the number of rows in the file.member. Some OS components add their
    > files to the /Cleanup/ function to attempt to avoid taking too much
    > storage, while mostly having SIZE(*NOMAX) to prevent reaching a defined
    > numeric limit on the number of rows. Other features may provide an
    > interface to trim and/or reorganize the data.
    >
    > I am not sure why the recovery noted in the support document suggests
    > CLRPFM instead of RGZPFM, except to avoid verification that there are
    > deleted rows which can be recovered; i.e. not sure why removing active
    > rows is acceptable, since that seems to defeat the point in actually
    > having maintained them in the first place.? Then to prevent recurrence
    > the file probably can be changed using CHGPF to activate the REUSEDLT()
    > feature; as alluded may be the new setting on the file for IBM i 6.1.
    >
    > Regards, Chuck




  5. Re: QASJSNDHST CPA5305

    I do not have access to any systems, so I can not easily find out
    more; option-3 from GO SERVICE was by memory. However as I had alluded,
    the REUSEDLT() is probably not a real solution, even if it might prevent
    the issue in the future for many; any currently affected file can be
    /enhanced/ to match the future implementation [it should be so already,
    in IBM i OS 6.1], by issuing RGZPFM and then the CHGPF REUSEDLT(*YES)
    against the QASJSNDHST file [& member]. At that point I would think it
    moot to review the entries, since the subject issue is resolved.?

    Anyhow... since option-3 was of no help, did the request to DSPSRVAGT
    TYPE(*SRVINF) not do anything that might be inferred to be what is the
    data [optionally verifying the request opened the QASJSNDHST file per
    WRKJOB OPTION(*OPNF)]? Of course there may be the option to just issue
    RUNQRY QRY(*NONE) QRYFILE((QASJSNDHST)) to display the data.?

    Regards, Chuck

    just bob wrote:
    > Option three on my model 810 gived me "3. Authorize users to access
    > service information "
    >
    > Sorry I do not know the system well enough to know which option you
    > meant.
    >
    > I woudl like to be able to view the file and review the entries.
    >
    > Here is an email IBM sent us to deal with it.
    >
    >
    > PROBLEM SUMMARY:
    > When the QASJSNDHST file is created the maximum number of
    > records is 10000 and the REUSEDLT parameter is set to *NO so
    > when the QASJSNDHST is rewritten it does not reuse the deleted
    > records. <>
    >
    > "CRPence" wrote:
    >> just bob wrote:
    >>> So my QASJSNDHST file was full and we cleared it to make the
    >>> CPA5305 message go away following instructions here:
    >>> http://www-1.ibm.com/support/docview...256f74005173d6
    >>>
    >>> Q. What is this file and why was it full, is my question, and one I
    >>> can't seem to get Google to answer.
    >>>
    >>> Running V5R4.

    >> I infer from its name that the database file object is a Service Agent
    >> file holding a History of Send activity. See the GO SERVICE option-3 for
    >> its /send/ option; a scheduled QS9SACOL inventory data collection for
    >> QSRVAGT or QINVCOL may be what /Send/ History is being tracked [for
    >> PM/400]. DSPSRVAGT TYPE(*SRVINF) apparently shows what is in the file
    >> QASJSNDHST.
    >>
    >> <>


+ Reply to Thread